#ubuntu-kernel 2005-03-28
<zul> echo echo
<zul> its usually quiet tonight
<crimsun> yes, it is usually quiet ;-)
<zul> er...UNusually
<jbailey> Most of the usual culprits are testing the array stuff.  I'm completing an install so that I can test md stuff.
<crimsun> I'm tackling a weird usb sound issues and trying to push through the rest of the Python 2.4 transition
<crimsun> issue, rather
<zul> what sound issue?
<crimsun> a disconnect issue that was fixed in -28 via the alsa patch
<zul> https://www.ubuntulinux.org/wiki/KernelBazNotes
<crimsun> register-archive, no?
<crimsun> (updated)
<zul> oh crap...i think i should go to beed soon
<zul> yes..bed..
<zul> hmmm...lets see what rhel 4 have
<zul> later
<fabbione> morning
<lamont> morning fabbione 
<fabbione> hey lamont
<svenl> fabbione: ARG.
<fabbione> svenl: ?
<svenl> fabbione: i forgot to remove the non-powerpc configs yesterday, and it has not finished building :/
<fabbione> ah ok
<svenl> (its at power4-smp though)
<svenl> fabbione: did you get my email ?
<fabbione> don't worry.. i am already building on our buildd
<fabbione> yes i did
<svenl> fabbione: with my patch ?
<svenl> patches even ? 
<fabbione> i am buildining only the driver patches
<fabbione> not the initrd thingy
<svenl> fabbione: why not both ? 
<fabbione> because i need to test one thing at a time :-)
<fabbione> and see if one of them break
* svenl don't get it what you all have against the mkinitrd support thingy ? 
<fabbione> it makes it easier for me
<svenl> fabbione: bah.
<fabbione> svenl: i will add it immediatly after this build cycle
<fabbione> it's not an upload
<fabbione> + everything is ccached
<fabbione> it takes only 30 minutes or so to build *
<fabbione> i promised to look at both of them
<fabbione> and i am doing it
<fabbione> so i don't see what the problem is
<svenl> fabbione: they are two different things, the driver thingy will build you the modules, while the mkinitrd support thingy will copy stuff into the kernel-image.
<svenl> i want a build box like yours :)
<fabbione> i know they are 2 different things. but since we have a policy to do atomic commits
* svenl should maybe decide to use the augsbourg 8-way 1.6GHz power5 box for test build :)
<fabbione> i test A and commit A
<svenl> fabbione: ok.
<fabbione> i add B -> test B -> commit B
<fabbione> it is seriously 100 times easier for me
<fabbione> svenl: that box is nothing special.. the ccache i have is
<svenl> ok then, you have a fast box anyway.
<svenl> you have a fast ccache ? 
<fabbione> well i have a fast disk with the ccache already full
<fabbione> so it becomes fast
<fabbione> processor       : 0
<fabbione> cpu             : PPC970FX, altivec supported
<fabbione> clock           : 2000MHz
<fabbione> + 2GB of ram
<fabbione> and 500 or more GB of disk
<svenl> fabbione: well, trick has 8GB of ramand who knows how much disk space.
<svenl> fabbione: saddly we can't use it for upload-related development.
<fabbione> why not?
<svenl> we have not full control over the box, so we cannot use it to build packages to upload.
<fabbione> i see...
<fabbione> suckage
<svenl> as soon as i have time, i will use it to do ppc64 kernels though.
<svenl> and hopefully i will get a virtual cpu on it someday.
<fabbione> you will need a libc6-64 and gcc-64 first
<fabbione> doko is working on those afaik
<svenl> waldi already compiled a biarch toolchain two days ago.
<fabbione> i know doko had them for a while
<fabbione> not sure where tho
<fabbione> but i am sure they have been working together on it
<svenl> fabbione: just the compiler, but with suse headers.
<svenl> ok need to go, see you.
<fabbione> cya
<svenl> fabbione: i wonder if it is possible to share a ccache cache setup with a chroot ? 
<fabbione> yes it is
<fabbione> just use a dedicated partition that you mount under .ccache
<fabbione> and share it between chroots
<fabbione> it's up to you where you mount it
<fabbione> you have the env var to define it
<fabbione> just remember that you need to have the same UID under both the chroots
<fabbione>   Changes by Sven Luther:
<fabbione>   * Fix mv643xx driver for powerpc:
<fabbione>     - Add patches powerpc-mv643xx-enet.dpatch and powerpc-mv643xx-eth-pegasos.dpatch.
<fabbione>     - Obsolete patch marvell-pegasos-2.dpatch.
<fabbione> svenl: testing the initrd thingy...
<fabbione> how can i verify that it actually did something?
<svenl> fabbione: do you have a /boot/vmlinuz-2.6.10-powerpc ? 
<fabbione> svenl: i will in a short time..
<fabbione> it's building with the mkwhatever patch
<svenl> fabbione: what version of mkvmlkinuz do you have ?
<fabbione> the one you have sent to me via email
<svenl> fabbione: the mkvmlinuz package, not the patch ? 
<fabbione> no idea....
<fabbione> let me check
<fabbione> 12
<fabbione> but it is not installed
<fabbione> is it required as build-dep?
<svenl> can you get mkvmlinuz 13 instead ? 
<svenl> altough not sure, it is more cosmetic.
<fabbione> no
<fabbione> we are in UVF
<fabbione> and that package is in main
<svenl> mkvmlinuz 13 installs a postinst hook which asks the user.
<svenl> fabbione: ok.
<svenl> no problem, you don't really need mkvmlinuz, and it is just dead code right now.
<fabbione> ok
<svenl> but make sure you mention this to me post-release as there will be some things to check, which may not be identic in debian and in ubuntu.
<svenl> version 13, it asks for a debconf variable, if you want to use mkvmlinuz to create the vmlinuz kernel, nothing more.
<svenl> (and adds support for 2.4 kernel, but you don't care about this).
<fabbione> svenl: after a release, a script is executed to sync * from unstable
<fabbione> so we will see what is in unstable after hoary
<svenl> fabbione: version 13 is in testing. 
<svenl> fabbione: when will you have the package for me to test ? 
<fabbione> svenl: it doesn't matter if it is in testing or not
<fabbione> we are too close to release to get a new upstream version
<fabbione> and i am quite busy right now....
<fabbione> i will let you know when they are ready
<svenl> fabbione: i said it is in testing, so we will have at least that in unstable after hoary.
<fabbione> http://people.ubuntu.com/~fabbione/ppc-diff
<fabbione> this is the output of debdiff
<fabbione> first deb is the old
<fabbione> second deb is the patched one
<svenl> Mmm.
<svenl> the script removes the .coff.
<fabbione> i don't like the fact that the /boot/vmlinux.coff-2.6.10-5-powerpc has been removed
<svenl> I am not sure you want that, but i seriously doubt you are interested in the .coff.
<fabbione> and it installs in kernel-image
<fabbione> while it whould be linux-image
<svenl> yep, but this is only because kernel-package is years outdated.
<fabbione> uh?
<svenl> fabbione: you can generate the .coff with mkvmlinuz if you really want.
<svenl> fabbione: the .coff is something that predates both quik and yaboot.
<svenl> fabbione: nobody uses it anymore.
<fabbione> svenl: well i am not going to break ppc. we can remove it AFTER hoary
<svenl> and like said, you can spare yourself the 1-2MB * 6 of space, since mkvmlinuz allows you to generate it.
<svenl> fabbione: please ask Kamion first, but you can comment out one line in postinst-install.powerpc to keep it.
<svenl> fabbione: but seriously, the .coff thingy is for a kernel which can be booted on oldworld pmacs through the serial console.
<fabbione> http://people.ubuntu.com/~fabbione/
<fabbione> the images are there
<svenl> fabbione: do you really envision a ubuntu/powerpc user doing that ? 
<fabbione> svenl: listen.. i don't need to know all the history of ppc
<fabbione> and i don't really care
<fabbione> right now i have 2 problems:
<fabbione> 1) do not break the kernel
<svenl> fabbione: ok, fine with you, just uncoment the line, ok ? 
<fabbione> 2) fix major bug fixes
<fabbione> svenl: please just update the patch and send it to me
<svenl> fabbione: it is just cruft because kenrel-package was never updates since ages.
<fabbione> oh perfect
<fabbione> ops
<svenl> fabbione: come on. 
<fabbione> ECHAN
<fabbione> that was for Jane
<svenl> edit postinst-install.powerpc, and put a # before the line which says rm .... .coff.
<svenl> fabbione: do you really want a patch from me ? 
<fabbione> ok done
<fabbione> and changed the thing to linux-
<svenl> fabbione: that said, mdz mentioned space problems on the powerpc isos, so i would check before removing this.
<svenl> it may well be worth it to save almost 10MB of archive space, not sure.
<svenl> but then you can always uncoment the line later on.
<fabbione> Victor Ferns <victor.ferns@standardbank.com> <- right?
<fabbione> AMEN
<fabbione> i am too busy now...
<svenl> fabbione: mmm, come to think of it, there is no chance of the .coff kernel being usefull, since it doesn't include the initrd,.
<fabbione> i need to do one thing at a time...
<svenl> fabbione: ok.
<svenl> fabbione: no problem.
<svenl> fabbione: do you want me to mention this to Kamion/mdz and ask them if it is worthwhile ? 
<fabbione> yes please
<fabbione> i am not the ppc porter
<svenl> Ok, will do.
<svenl> hehe.
<fabbione> i need people to work on it
<fabbione> without me
<svenl> post-hoary i may take over that job for kernel stuff maybe.
<svenl> fabbione: ok, installed the kernel and rebooting, i generated the mkvmlinuz kernel, will try to boot it directly.
<svenl> fabbione: rebooted kernel worked.
<svenl> mmm, i think we didn't enable the config option for the marvell gigabit ethernet driver :/
<fabbione> yes we did
<fabbione> the driver is there
<fabbione> or did they changed again?
<svenl> fabbione: well, i think it doesn't get autoloaded by hotplug.
<svenl> mmm.
<fabbione> that is something that was fixed in the marvel-pegagos2.dpatch
<svenl> fabbione: ah, will look at the patch, this means we need an additional patching step.
<svenl> you sure ? I just looked at the marvel-pegasos2 dpatch from .27, and there is nothing in there relative to hotplug ? 
<fabbione> no i am not sure
<svenl> fabbione: can i access the kernel's changes list or something ? 
<fabbione> svenl: there is no kernel changes list
<fabbione> we have 2 ml
<fabbione> kernel-team and kernel-bugs
<svenl> fabbione: the one from the revision system repo (arch i think).
<fabbione> the latter collects all the stuff from the bug reports
<fabbione> there is none...
<fabbione> we don't have a ml with changes
<fabbione> there is only the repo
<fabbione> at the URL in /topic
<svenl> fabbione: i mean the arch equivalent to svn log.
<fabbione> svenl: yes. you can access it doing a baz get of the archive in /topic
<svenl> baz ?
<fabbione> or tla
<fabbione> doesn't matter
<svenl> http://people.ubuntu.com/~lamont/Archives/kernel-team@ubuntu.com--2005/ this one ? 
<fabbione> yes. register THAT archive
<fabbione> and get the branch pre29 in topic
<svenl> mmm, need a crash course in tla :/
<svenl> damn, all that and the module doesn't seem to work as it should :/
<svenl> fabbione: no need to do an upload, i need to fix it first, and get the hotplug stuff worked out.
<fabbione> i am not going to upload until it is fixed
<svenl> ok.
<svenl> this will need more backport work, will not do this until this evening or tomorrow.
<svenl> fabbione: what tla command do you use to do the checkout ? 
<fabbione> did you register the archive first?
<svenl> fabbione: i never used tla.
<fabbione> http://people.ubuntu.com/~fabbione/irclogs/ubuntu-kernel-2005-03-15.html
<fabbione> svenl: read there what lamont told to zul
<fabbione> you should be able to do s/baz/tla/
<svenl> fabbione: thanks.
<svenl> fabbione: i am baffled, the driver works fine on 2.6.11, but fails in 2.6.10, need to look in details.
<svenl> mmm, didn't work 
<svenl>  tla make-archive tla-archive/luther@debian.org--2005
<svenl> usage: tla make-archive [options]  [name]  location
<svenl> i am baffled.
<svenl> later though, need to go now.
<fabbione> svenl: just look at tla register-archive and tla get
<fabbione> you don't need to create your own archive
<fabbione> otherwise install bazaar
<fabbione> and make your life simpler
<svenl> $ tla register-archive http://people.ubuntu.com/~lamont/Archives/kernel-team@ubuntu.com--2005
<svenl> arch_archive_connect: attempt to connect to incompatible archive
<fabbione> than you need baz
<svenl> oh well, will try again later.
<svenl> baz is in ubuntu/hoary, right ?
<fabbione> yes afaik it is also in debian
<svenl> E: Couldn't find package baz
<fabbione> package bazaar
<svenl> no it doesn't seem to be.
<svenl> oh, ok.
<fabbione> svenl: can you give me the changelog entry so i can commit the changes?
<svenl> fabbione: added support files for mkvmlinuz
<svenl> or do you want something more formal or more complete ? 
<svenl> maybe "mkvmlinuz support files added" even.
<svenl> or mkvmlinuz support files added (Sven Luther) 
<svenl> don't know what the policy is.
<fabbione> +  * Add support files for mkvmlinuz.
<fabbione> same as X
<fabbione> imperative form
<fabbione> or whatever is called
<svenl> Ok.
<svenl> what about attribution ?
<fabbione> you are already credited :-)
<fabbione> dude....
<svenl> ok, cool.
<fabbione> i am NOT a PUNKASS!
<svenl> just curious.
<fabbione>   Changes by Sven Luther:
<fabbione>   * Fix mv643xx driver for powerpc:
<fabbione>     - Add patches powerpc-mv643xx-enet.dpatch and powerpc-mv643xx-eth-pegasos.dpatch.
<fabbione>     - Obsolete patch marvell-pegasos-2.dpatch.
<fabbione>   * Add support files for mkvmlinuz.
<fabbione> + some spaces that IRC cuts away
<svenl> hehe.
<fabbione> i do always respect credits
<fabbione> if i miss one it's for a mistake
<svenl> quite verboser than the debian changelog format, but hey.
<fabbione> i am paranoid on changelog
<svenl> well, the debian kernel changelog adopted the other form, because Jens vetoed the above (or rather d-i) format
<svenl> claimed it did loose ordering of changes.
<fabbione> that's because he has no clue on how to use a RCS
<svenl> fabbione: bah, he is inactive now anyway.
<fabbione> if you know how to use an RCS properly, there is no need to preserve the order of changes in the changelog
<svenl> fabbione: provided all users who are interested need to know how to handle said RCS properly and have access too.
<svenl> fabbione: i did the baz registering, how is the baz get done ? 
<fabbione> baz get kernel-team@ubuntu.com--2005/kernel-debian--pre29--2.6.10 debian
<fabbione> it will get the archive for the debian/ dir
<fabbione> since it's the only one under rcs
<svenl> thanks, altough i doubt the hotplug patch was ever included, i think.
<fabbione> afaik adding hotplug support is very simple
<fabbione> you need a table and one export of a function
<fabbione> pretty simple
<fabbione> just check how other drivers do that
<svenl> yep.
<svenl> fabbione: but the mv643xx_eth driver is not a pci driver, so ...
<svenl> fabbione: how do i check the log or changeset of a file in baz ? 
<fabbione> baz help
<fabbione>                  logs : list patch logs for a version in a project tree
<fabbione> baz logs --summary
<fabbione> for the short logs
<svenl> WARNING: no rule found for checking signatures from kernel-team@ubuntu.com--2005
<svenl>   Consider creating ~/.arch-params/signing/kernel-team@ubuntu.com--2005.check
<svenl>   or ~/.arch-params/signing/=default.check
<svenl> PANIC: Unhandled arguments. Did you forget to use -r or -d?
<svenl> its not helpfull, and baz help seems pretty useless to me :/
<svenl> mmm, 
* svenl guesses baz/tla don't allows to do per file logs like subversion does.
<fabbione> svenl: hold on.. you need to files to allow gpg checking of each commit
<fabbione> cat ~/.arch-params/signing/\=\=default.check
<fabbione> gpg --verify-files -
<fabbione> cat ~/.arch-params/signing/kernel-team@ubuntu.com--2005
<fabbione> gpg --default-key 63549F8E --clearsign
<fabbione> of course you need to change the keyid
<fabbione> but you don't have commit access on our repo
<fabbione> so it's kinda pointless
<svenl> yep.
<svenl> let's forget it.
<svenl> for now.
<svenl> about hotplug, do you have a hint of the name of the structure or whatever ?
<fabbione> svenl: just check any other driver
<fabbione> it's a table with the pci ids
<fabbione> almost impossible to miss
<svenl> something like this : 
<svenl> static struct pci_device_id rhine_pci_tbl[]  =
<svenl> {
<svenl>         {0x1106, 0x3043, PCI_ANY_ID, PCI_ANY_ID, 0, 0, }, /* VT86C100A */
<svenl>         {0x1106, 0x3065, PCI_ANY_ID, PCI_ANY_ID, 0, 0, }, /* VT6102 */
<svenl>         {0x1106, 0x3106, PCI_ANY_ID, PCI_ANY_ID, 0, 0, }, /* 6105{,L,LOM} */
<svenl>         {0x1106, 0x3053, PCI_ANY_ID, PCI_ANY_ID, 0, 0, }, /* VT6105M */
<svenl>         { }     /* terminate list */
<fabbione> yes
<svenl> };
<fabbione> that is correct
<svenl> i have such a one for doing a pci_dev_present thingy.
<fabbione> and there is an export of that table
<svenl> so the hotplug is either : 
<svenl> MODULE_DEVICE_TABLE(pci, rhine_pci_tbl);
<fabbione> if you grep for rhine_pci_tbl
<svenl> or : 
<svenl> static struct pci_driver rhine_driver = {
<svenl>         .name           = DRV_NAME,
<svenl>         .id_table       = rhine_pci_tbl,
<svenl>         .probe          = rhine_init_one,
<svenl>         .remove         = __devexit_p(rhine_remove_one),
<svenl> #ifdef CONFIG_PM
<fabbione> yeah  exactly
<svenl>         .suspend        = rhine_suspend,
<svenl>         .resume         = rhine_resume,
<svenl> #endif /* CONFIG_PM */
<svenl>         .driver = {
<fabbione> it depends how is the driver
<svenl>                 .shutdown = rhine_shutdown,
<svenl>         }
<svenl> };
<svenl> thanks will investigate.
<fabbione> i know both ways work
<svenl> fabbione: its a none-pci-driver :/
<fabbione> well.. i have no idea of non pci driver
<svenl> but will ask around, i even know the guy to ask.
<fabbione> check how it is done in other non-pci drivers
<svenl> but he is in awake-at-midnight timezone
<svenl> Mmm, i think it is more complicated because the driver is no pci driver, but i will investigate.
<mjg59> svenl: What sort of driver is it?
<mjg59> The .id_table field is used by the kernel at driver load time - it goes through every device in the system, and calls .probe against each device that matches the contents of the table
<mjg59> MODULE_DEVICE_TABLE is used to export the information at build time
<svenl> mjg59: the pegasos marvell northbridge gigabit ethernet driver. It is outside of the pci bus.
<svenl> mjg59: the driver works, but i need to get hotplug to automatically load it.
<mjg59> Right. What sort of driver does it declare itself as being?
<mjg59> (As in, what's the type of the struct that contains the .probe and .remove functions)
<mjg59> svenl: Which driver is this? mv643xx?
<mjg59> If so, it doesn't seem to use the new driver model. There's no way to get it loaded via hotplug.
<svenl> mv643xx_eth
<mjg59> Yeah. It looks like you're out of luck.
<svenl> mjg59: huh ? 
<svenl> mjg59: well, we can adapt it, where can i find good info on the hotplug infrastructure ? 
<mjg59> Documentation/driver-model/
<svenl> ok, thanks.
<zul> hey
<lamont> morning
<zul> hey lamont how is it gonig?
<fabbione> morning lamont
<zul> hey fabbione 
<fabbione> hi zul
<fabbione> we can be funny here.. right?
<zul> of course
<zul> most of us have a sense of humor except for lamont
<zul> and maybe jbailey
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | check the new abichecker code and GET familiar with it | http://people.ubuntu.com/~lamont/Archives/kernel-team@ubuntu.com--2005/ kernel-team@ubuntu.com--2005/kernel-debian--pre29--2.6.10 | Get it or http://www.getoffmynuts.com/gallery/images/asys.jpg
<jbailey> zul: I have no sense of humor.  I'm Canadian.
<jbailey> zul: We have a sense of 'humour'.
<zul> jbailey: well excuse me i went to an american high school
<zul> fabbione: lol
* lamont makes it back around to this channel, whaps zul with wet noodles
<lamont> ENOTROUT
* jbailey hands lamont a brick of tofu.
<jbailey> It's all I have to offer, sorry.
<lamont> zul: my sense of humor is merely misunderstood. :-)
<lamont> jbailey: yum
<jbailey> You can carve it to look like a trout.
<zul> heh
<zul> hey guys do you want to dump the 2.5 stuff in universe?
<zul> er...2.4
<fabbione> http://www.getoffmynuts.com/gallery/images/chefno.jpg
<fabbione> aahah that looks so much like me
<jbailey> zul: It's probably a good idea.  I know that the initrd-tools stuff that I've done hasn't been tested against 2.4 at all
<jbailey> fabbione: OooOooOoo!
<zul> heh its dom delouise
<jbailey> That could be the "Kernel Strike Force" page to go against the XSF one. =)
* fabbione *coughs*
<fabbione> jbailey: i am kinda part of both.. you know?
<fabbione> but we can do something funny
<jbailey> fabbione: Yes, well, we forgive you. =)
<dholbach> hi
<zul> dholbach: im thinking dump the 2.4 stuff since its not really supported afiak
<dholbach> zul: don't let fabbione hear that :-)
<dholbach> zul: i had the whole lot on wiki/MorgueCandidates already, when he stopped me :-)
<zul> ah..
<zul> fabbione: wanna comment?
<dholbach> we're talking about the "kernel" section on wiki/UniverseUnmetDeps
<fabbione> zul: yes. we need to have at least one version of 2.4 around in universe
<fabbione> supported or not
<zul> k
<fabbione> because there are some admin that are pretty conservative
<fabbione> or cannot upgrade a kernel to 2.6
<fabbione> (like me)
<dholbach> but we could chuck out stuff like kernel-patch-2.4.26-m68k
<jbailey> fabbione: They'll probably see errors on their screen with the initrd-tools changes if they downgrade from a new install.
<fabbione> dholbach: you kidding right?
<fabbione> dholbach: i am porting ubuntu to m68k
<fabbione> !
* dholbach pipes innocently
* dholbach didn't say anything
<fabbione> jbailey: i am more concerned about people upgrading from woody
<fabbione> dholbach: just kidding.. kill it
<jbailey> fabbione: I think that case will still behave sanely.  I haven't tested it, though.
<dholbach> but we need to fix the linux-2.4-meta packages
<jbailey> But the suspend-to-disk stuff only should kick in if someone sets it intentionally, or does a clean install.
<dholbach> apt-cache -i unmet | grep kernel   should be empty :-)
<dholbach> i don't want to meddle in any kernel packages :-)
<dholbach> even not meta ones
<fabbione> dholbach: we simply cannot commit to maintain 2.4 too
<fabbione> that's MOTU stuff
<fabbione> but we did never remove 2.4 from universe for that reason
<fabbione> if MOTU's are absolutely sure that it is ok to kill 2.4, than just go ahead
<dholbach> i'm not suggesting chucking stuff out
<dholbach> but the linux-meta packages should be sorted out
<dholbach> -2.4 that is
<fabbione> there is no linux-meta for 2.4
<fabbione> and there is no need to have one
<dholbach> that's all the list is saying 
<dholbach> what are all those   version 100   then?
<fabbione> the version 100 afaik are meta packages coming from DEbian
<fabbione> that have the same meaning as our linux-meta
<fabbione> but
<fabbione> they are not packages we did
<fabbione> so i am sure you can clean these ones
<dholbach> what about the *-2.6-* ones?
<fabbione> it's the same
<fabbione> debian uses kernel-*
<fabbione> we use linux-*
<dholbach> ok, so if you have no objections, i'll re-add them to the list and talk to elmo at some stage
<dholbach> cool
<dholbach> thanks :-)
<fabbione> it's your decision
<dholbach> removal of uninstallable meta packages shouldnt hurt, right? :-)
<fabbione> it shouldn't
<fabbione> given that they don't break other packages
<dholbach> i'd prefer if someone of the kernel-team would verify ;-)
<lamont> meta package doesn't actually deliver anything, other than dependencies to pull in other packages..
<lamont> that it's uniinstallable may be an issue, but removing it shouldn't hurt
<fabbione> ahah i found the best picture for badger :-)
<fabbione> http://www.getoffmynuts.com/gallery/images/aznraccoonstick.jpg
<lamont> fabbione: that's a racoon
<lamont> != badger
<fabbione> hmm they looked pretty much the same
<lamont> but they taste completely different
<zul> fabbione: racoon are more evil then badgers
<zul> they go through your garbage
<lamont> and about half as big as a badger, too
<fabbione> ok got that
<lamont> so they fit in the garbage can better... :-)
<lamont> should we get mark to do 'randy racoon' next?
<fabbione> hahha better not suggesting it :-)
<fabbione> some pics on that site are amazing
<fabbione> http://www.getoffmynuts.com/gallery/images/appleadcrackborrow20.jpg
<fabbione> there PPC users!
<lamont> fabbione: that'd be better than 'raunchy racoon'
<fabbione> ehheh
<dholbach> bbl
<Mithrandir> hm, should I whine about stuff to go into d-i kernel packages here or just to Kamion?
<zul> Kamion
<fabbione> here
<fabbione> we do create the udebs
<fabbione> Mithrandir: what do you need exactly?
<Mithrandir> fabbione: 7800; the i2o modules.
<Mithrandir> i2o_block.ko  i2o_config.ko  i2o_core.ko  i2o_proc.ko  i2o_scsi.ko
<fabbione> on what arches?
<fabbione> something like an i2o-udebs
<fabbione> but what should pull it in?
<Mithrandir> amd64
<Mithrandir> it could just go in the scsi-modules udeb?
<fabbione> is it used only by scsi hw?
<Mithrandir> TTBOMK, yes
<fabbione> TTBOMK"FHHIDJAWI ????
<Mithrandir> to the best of my knowledge
<Mithrandir> it's an abstraction layer which providers can write their hardware to conform to.
<fabbione> ok :-)
<Mithrandir> makes it easier to write drivers
<fabbione> yes i know the description, but i didn't know if there were actually drivers using it
<fabbione> the 7800 is the scsi drivers that uses it, right?
<Mithrandir> 7800 is the bug #
<Mithrandir> :P
<fabbione> ahhh
<Mithrandir> some Adaptec stuff uses it
<Mithrandir> 0000:02:07.0 RAID bus controller: Adaptec (formerly DPT) SmartRAID V Controller (rev 01)
<Mithrandir> so we might want the dpt_i2o in there as well
<Mithrandir> hmm, the dpt_i2o is i386 only, though
<fabbione> hmmm ok
<fabbione> to do it clean we need a new kernel-wedge
<fabbione> + some investigation on the depends of the modules
<fabbione> what module is the one used for the controller?
<Mithrandir> typically, the i2o_block gives you access to the block devices (that is, RAIDs or JBODs the controller sees)
<Mithrandir> the i2o_scsi is the scsi interface, I think
<fabbione> hmmmm
<Mithrandir> config is for running configuration tools
* fabbione scratches his head
<fabbione> is it critical to get it in for hoary?
<fabbione> it will need me a bit of investigation on how to merge the overall crack
<fabbione> or talk with Kamion on what's the best way
<Mithrandir> it would be _very_ nice to have for hoary, yes.
<fabbione> ok
<Mithrandir> it's a PITA to install without it
<fabbione> yup. i understand
<Mithrandir> it's in the kernel, it's just missing from d-i
<fabbione> yes..
<fabbione> we need to get a proper udeb out
<fabbione> and since this is scsi stuff
<fabbione> the scsi-modules needs to Depend on it
<fabbione> but if in one month from now, a new keyboard will use that stuff
<fabbione> we will not need to split the hell
<fabbione> it will be already there
<fabbione> i just want to be sure which modules (per arch) needs to go where
<fabbione> and this is Kamion "the d-i allmighty" decision ;)
<Mithrandir> I doubt you'll ever have an i2o keyboard. :P
<fabbione> you get my point :P
<fabbione> but yes it is doable
<Mithrandir> cool, I'll see what kamion says to the bug
<Mithrandir> but now I should be packing
<fabbione> are you flying tomorrow?
<Mithrandir> train tonight, then drop off a bit of baggage in Oslo then bus to Copenhagen tomorrow mid-day
<fabbione> cool!
<fabbione> Mithrandir: you have my phone numbers.. anything you need, you just call me
<Mithrandir> sure
<Mithrandir> :)
<fabbione> (other than my money!)
<fabbione> (but you can have my wife as souvenir from dk)
* fabbione hides
<Mithrandir> has she turned evil already?
<fabbione> she did even before
<fabbione> but i can say "WIFE"
<fabbione> ehehhe
<Mithrandir> I'm looking forward to meet her
<Mithrandir> I'm sure she rocks.
<Mithrandir> just like you
<fabbione> eheheh
<fabbione> she is not a nerd tho
<fabbione> and she doesn't like computer talking
<fabbione> talk to her about flowers and traveling :)
<Mithrandir> I
<Mithrandir> I'll just make Karianne talk to her and she'll be a geek in no time.
<Mithrandir> :)
<fabbione> AHAHHA
<fabbione> good plan!
<fabbione> i think i will take Ulla with me at the next conf in EU
<Mithrandir> bring her to Debconf?
<fabbione> i am not sure i will be there
<Mithrandir> ok :(
<Mithrandir> I'm actually considering bringing my mother(!).  She's a social antrophologist and interested in free software and geeks and such
<fabbione> ahaha
<fabbione> that would rock so hard!
* lamont tries to end-run the phone company
<zul> heh..mama's boy :)
<lamont> well, it didn't work.  those wimps at earthlink are no help.
<lamont> my issue is that there are free pair in the T^*&)^)*_() path all the way to my house... I just want one.  Qwest doesn't want to free it up....
<zul> frig...its like im doing cobol all over again
<zul> pure hell
<fabbione> lamont: just steal it :-)
<lamont> fabbione: unfortunately, that would require learning about DSL hookup methods, hacking their switch, and hacking the CO computer... while fun, it would not go unnoticed, and those last 2 are federal offenses...
* lamont doesn't want to live in kansas
<zul> its better than ioaw
<zul> iowa
<fabbione> or alaska
<lamont> alaska would be nice - as long as they have DSL. :-)
<zul> or *shock* tenesse
<lamont> and leavenworth doesn't have DSL
<lamont> at least not in the inmate areas.
<fabbione> lamont: did you ever consider upgrading the wireless link and get somehow uncapped?
<lamont> fabbione: for a mere $600 + $70/mo, I can have 500kbps over satellite.
<lamont> fat, but _VERY_ long pipe.
<zul> what is the upload like?
<lamont> probably bidirectional these days - at least 128kbps
<lamont> now, for $349/mo + tarriffs (== ~$1000/mo), I can have a T1.
<lamont> and for about that much a month, I can get another house in DSL land... :-)
<fabbione> that's too expensive
<fabbione> i was talking about the wireless link you have now
<lamont> ah, that just involves getting the co-op to change rate plans yet again on my behalf...
<fabbione> + latency only kills irc...
<lamont> (the most recent change benefits pretty much _me_
<lamont> and no one else
<fabbione> but you are still bounded to traffic or speed limit
<fabbione> i can't believe i cannot make flumotion to work with my webcam
<fabbione> and jdub keeps ignoring that....
<lamont> fabbione: and will be so long as I'm using the co-op
<lamont> fabbione: I could have ~400kbps 24x7 if I was willing to pay for it...
<lamont> but the surcharges _HURT_ 
<fabbione> yeah i can imagine
<fabbione> or get all your boxes colocated
<lamont> they're structured to make it cheaper to get the T1 if you're a steady-state heavy user
<fabbione> and use only the laptop as ws
<zul> ill take that ppp bug - 7763
<fabbione> lamont: have you consider splitting the T1 with the neibourgh?
<lamont> pb is that i need to get the bits to test with, so I'd need to co-lo my office, and we're still talking ~$1000/mo
<lamont> ENONTECHY
<fabbione> yeah colo the entire office no...
<fabbione> zul: ok...
<lamont> actually, I co-lo'ed a 1U box down at my buddy's
<zul> see im cordinating :)
<lamont> so I can go hit his driveway and do a fast-fetch of everything I'm missing
<fabbione> eheh
<lamont> zul: that is like, so _ON_ topic. :-)
<fabbione> zul: i don't use ppp at all...
<fabbione> so you can take also pppoe and mppe
<lamont> I use it when forced
<zul> neither do i but if debian includes it well do the same
<fabbione> lamont: last thing i tried was ppp over ssh
<fabbione> than i stopped
<lamont> gag
<zul> last time i used ppp was 3 years ago
<lamont> fabbione: btw, ipv6 iptables connection tracking... any word on that?
<fabbione> it was easier to put a machine with 2 eth at work than to go via the corporate firewall
<fabbione> lamont: right.... now we are kernel maintainers...
<fabbione> see 
<fabbione> i totally forgot about it
<fabbione> we are going to put it in for bendy
<fabbione> since i maintain the kernel.. we can do the effort to merge it
<lamont> once we have it, I'll deploy ipv6 here...
<lamont> need it for the firewall.
<fabbione> lamont: you will be surprise to know that you don't need that much firewalling on ipv6
<lamont> fabbione: because no one is using it?
<fabbione> no, because if you carefully configure the services, you don't need one
<fabbione> not all services listen on IPv6
<fabbione> and the few that do, is because you want them on ipv6
<fabbione> like bind, apache2
<fabbione> ssh
<lamont> yeah, but I'm kinda strict on the firewall rules...
<fabbione> sure..
<fabbione> there were some limitations when i tested a year ago
<lamont> it's not even there in our 2.6.10 :)  severely limits things... :)
<fabbione> you know.. i got so frigging busy that i really forgot about it
<lamont> it's OK.  I'll just pester you each day at UDU about it. :-)
<fabbione> no need to 
<lamont> LOL
<fabbione> i will merge the day after hoary is out
<zul> heh...you guys are going to have too much fun at udu
<fabbione> and upload for bendy
<Mithrandir> breezy
<Mithrandir> no, windy
<Mithrandir> wasn't it?
<fabbione> yeah breezy
<Mithrandir> breezy badger
<Mithrandir> crazy name, imho
<Mithrandir> :)
<fabbione> wife i want bendy!
<fabbione> s/wife//
<fabbione> no.. i do NOT want my wife to bend(y)
<fabbione> not yet at least :P
<Mithrandir> TMI!
<lamont> fabbione: -28 has the abi stuff, not 27, right>?
<fabbione> lamont: correct
<fabbione> time to get offline
<fabbione> wife is back
<zul> c ya
<fabbione> cya
<lamont> later
<zul> im going to a movie tonight with my wife so im not sure if im going to be online or not
* lamont wonders if we have a target upload date for -29
<zul> next week i think
<zul> or not..
<zul> later
#ubuntu-kernel 2005-03-29
<mjg59> fabbione: I think we're really going to need that ACPI embedded controller patch, even if it does break the ABI
* lamont wimpers
<mjg59> The alternative is actually really bad
<zul> hey
<lamont> yeh?
<lamont> s/e/3/
<zul> wha
<zul> ah..ok..
<fabbione> morning
<fabbione> mjg59: can you be more specific?
<lamont> hrm.. fabbione woke up.. must be bed time
<fabbione> ehehe
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | http://people.ubuntu.com/~lamont/Archives/kernel-team@ubuntu.com--2005/ kernel-team@ubuntu.com--2005/kernel-debian--pre29--2.6.10 | Get it or http://www.getoffmynuts.com/gallery/images/asys.jpg
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | http://people.ubuntu.com/~lamont/Archives/kernel-team@ubuntu.com--2005/ kernel-team@ubuntu.com--2005/kernel-debian--pre29--2.6.10 | Get it or http://www.getoffmynuts.com/gallery/images/asys.jpg | Last call for patches (-29) is 22nd of March. See k-team ml.
<fabbione> hmm kteam
<fabbione> sounds cool
<fabbione> Hannibal, P. E.
<fabbione> etc..
<crimsun> asys.jpg rocks
<fabbione> i think i will prepare a "kteam" webpage soon
<fabbione> i have better than that :-)
<crimsun> like branden's old cup of stfu? :-)
<fabbione> i really have better than that :-)
<crimsun> :-)
<fabbione> but considering how old is the XFS page
<fabbione> that one really rocks hard
<fabbione> branden is one of the most amazing DD i know
<fabbione> and personally i would love to work more with him
<mjg59> fabbione: Without that patch, HP laptops will (a) fail to switch on fans, (b) go into a mad state of kacpid using 100% of the CPU
<fabbione> mjg59: but Keybuk said that reverting the IPMI was enough...
<fabbione> anyway.. eating time...
<fabbione> if you want to send me the dpatch
<fabbione> i can give it a shot and check the ABI
<mjg59> Well, the issue is that without that patch, interrupts from the embedded controller can get missed
<mjg59> Sent
<fabbione> ok
<fabbione> svenl: what is the status for the mv driver?
<fabbione> i got another person with a pegasos to test on
<svenl> fabbione: who ? 
<fabbione> a friend of mine
<svenl> fabbione: sorry, but i won't have the time to fix it today, and the hotplug thingy may need more profund investigation.
<fabbione> svenl: see /topic
* svenl believes he knows every pegasos owner who runs linux :)
<fabbione> svenl: i am pretty sure you don't :-)
<svenl> hehe.
<svenl> i will try for march 22, if not, ...
<svenl> the current patch is better than the older one in any case.
<svenl> fabbione: but in any case, he probably knows me :)
<fabbione> probably
<fabbione> didn't bother to ask
<fabbione> your light and glory sheds all over the world already
<svenl> bah only the pegasos/linux part of it
<fabbione> HMMMMMM
<fabbione> i saw something i don't like
<jbailey> Ther'es a kernel team mailing list?  *sigh*
<fabbione> jbailey: yes. and one for bugs
<jbailey> Is it already on gmane?
<fabbione> no idea
<zul> morning
<fabbione> hey zul
<zul> hey fabbione how is it going?
<zul> so the 22nd eh?
<fabbione> zul: it's going ok...
<fabbione> yes..
<fabbione> i think it is a fair date
<fabbione> 8 days before Release Candidate
<zul> yep...gives me the weekend to work on stuff
<fabbione> so we have a week more or less to get it tested
<fabbione> yeah
<zul> i think its fair
<zul> fabbione: whats the kernel-image-2.4-586tsc version 100 in universe?
<fabbione> ENOIDEA
<zul> ok im just going through the unmet dependencies for kernel stuff in universe
<fabbione> i am off for the weekend
<fabbione> cya around on monday
<fabbione> i might pass by tomorrow.. but i doubt
<zul> ok have fun dont get into trouble
<fabbione> ehhe no no
<zul> esp with your wife :)
<fabbione> ahaha
<zul> hey T-Bone 
<zul> oh yah i saw the trailer to episode 3 last night
<T-Bone> heh
<zul> cant wait
<T-Bone> :)
<zul> well i can but...no i cant
<zul> brb...need to reboot
<zul> :wq
<zul> oops
<jbailey> mjg59: there?
<zul> reho
<jbailey> who you callin' a ho?
<zul> uhhhhh uhhhhhh...
<zul> run
<zul> heh steaming mst3k :)
* lamont misses mst3k...  really went downhill after they booted joel.
<zul> mst3k.nofadz.com
<lamont> ENOBANDWIDTH
<zul> oh yes i keep forgetting
<kylem> never underestimate the bandwidth of a pile of cds and the us postal service?
<lamont> s/cds/dvds/
<kylem> well, it would just be a considerably bigger pile. 8)
<lamont> kylem: you in willy-land, or other side of things?
<lamont> kylem: keep floppies out of this....
<kylem> heh, i'm in ottawa.
* lamont kind of remembered it that way...
<kylem> hehe. :)
<kylem> brb.
<zul> that didnt take too long 15 hours  	torvalds  	1.2229
<zul> v2.6.12-rc1 	Linux 2.6.12-rc1
<lamont> Build needed 01:01:29, 1690972k disk space
<lamont> now _that_'s a hauling kernel  build (i386)
<lamont> Build needed 03:12:33, 1690972k disk space
<lamont> same build 3 days ago, without the ccache primed
<lamont> so I guess there's a good win sometimes. :-)
<zul> ps auxw
<zul> damn it
<mjg59> jbailey: Hi
<jbailey> Ah, looks like Fabio already grabbed 7838, cool.
<jbailey> Oo, and you replied to it.
<jbailey> mjg59: Thanks! =)
<lamont> fabbione: you around?
<zul> left a while ago
<fabbione> more or less
<fabbione> on the way out in 2 minutes
<fabbione> -1
<fabbione> i must go
<fabbione> if there is something i have my mobil phone with me
<fabbione> bya
<lamont> bah
* lamont hates it when he obscures windows
<zul> you wanna do what im doing right now...its kind of cobol related 
<lamont> gak!
<zul> convert fields of crud into ical format
* lamont is testing his defoma/fontconfig cluserful mess
<zul> fun fun
<lamont> oh, better than that... I need to find all the packages that use dh_installdefoma, and rev them. :-(
<lamont> probably
<zul> gah? icky poo.
<lamont> it's not too bad... I have the whole logfile tree on a machine I can grep....  :-(
<zul> well it can be too bad
<lamont> OTOH, 23 GB is a lot to grep....
<zul> jus a tad
* T-Gone slaps lamont with a britney stick before leaving :)
<lamont> T-Gone: I suppose I could just check packages that build-depend defoma, but that would be more work
<zul> what is defoma anyways?
<lamont> dunno
<lamont> debian font manager
<zul> ah
* lamont read the description. :-)
<zul> you are so smart
<lamont> lol
<zul> whee...forkbomb :)
<zul> slashdot is suxor
<zul> brb
<T-Bone> arg
<T-Bone> now he runs away :)
<zul> its instinct :)
<T-Bone> gah ;)
* T-Bone needs to try Hoary on the new Mac Mini he just received before his mom takes over it (for it's hers :)
<zul> bleah...mac
<T-Bone> you're so obviously jealous ;o)
<zul> not really
<zul> since it is your moms computer
<T-Bone> lol
<T-Bone> otoh, i got my hands on an old pbook 3400, but it seems to have hw trouble
<T-Bone> either bad PSU and/or dead battery. Could made it boot only once and not for long
<zul> surprise surprise :)
<T-Bone> i wonder if a dead battery can prevent a laptop from booting. Kinda odd
<zul> actually yes...with some ibms you have to plug it in to the wall if you had a dead battery
<zul> for example
<T-Bone> well that's the whole oddity of the thing: it's plugged and has battery and still, it won't boot
<zul> try removing the battery
<T-Bone> maybe both the PSU and the battery are dead tho, but the PSU is hot
<T-Bone> tried, doesn't change
<zul> then it could be the psu then
<T-Bone> yeah
<zul> proccess of elimination
<T-Bone> huh?
<zul> you keep elimination one combination until it is either or
<T-Bone> yeah
<T-Bone> and everything seems to point me toward good PSU and dead battery, meaning the silly thing can't boot with a dead battery
* T-Bone needs to buy a multimeter one of these days
<zul> i am so going home soon i cant hardly stay awake
<T-Bone> err
<T-Bone> it's like 1PM for you no?
<zul> 3 pm
<zul> i was up at 2 last night
<T-Bone> lol
<T-Bone> so you need a nap, maybe? :)
<zul> had to go to the bathroom and couldnt go back to sleep
<zul> well that is what im going to do on the bus
<T-Bone> hehe
<zul> you know what was strange i think i killed esound and mozilla was running really slow
<T-Bone> -EGRAMMAR
<T-Bone> dunno how to understand what you said :)
<zul> yeah my grammar is shitty
<zul> it gets like that when i need a nap
<T-Bone> wow
<T-Bone> i'm booting Warty on the Mini
<T-Bone> (i'm seeing the radeonfb invalid sig bug btw, doesn't seem much troublesome)
<zul> heh...you can close that one then ;)
<T-Bone> i'll close it when I'll have X up and running :)
<T-Bone> but I've always suspected it was a non-bug
<T-Bone> hope to be proven right
<T-Bone> urg. security.u.c is slow... 130KB/s
<zul> later time for beddy bye
<T-Bone> ok, the radeon bug can be closed
<T-Bone> and to whom it may concern, warty installs just fine on Mac Mini
<T-Bone> and voila, one less bug
<zul> hola
<zul> frig...when bk goes down it goes hard
#ubuntu-kernel 2005-03-30
<T-Bone> zul: i killed two bugs ;)
<zul> i saw..
<zul> 2 more and you have beaten me ;)
<zul> not! :)
<T-Bone> lol
* zul kicks bk
<zul> T-Bone: you are too quiet tonight
<T-Bone> yeah
<T-Bone> i might be ill
<zul> oh that sucks
<T-Bone> really?
<T-Bone> i mean, you enjoy me being verbose? :o)
<zul> not really ;)
<T-Bone> lol
<T-Bone> damn you
<zul> arrgh..fscking bk
* T-Bone uses ketchup for good reasons
<zul> whats ketchup?
<zul> besides the sauce
<T-Bone> a very nice script that gets you whatever flavour of the kernel you want
<T-Bone> google it
<T-Bone> ;)
<zul> hmm...neat
<zul> ill try it tomorrow but right now ill just bitch about bk :) arrgh bk!!
<zul> wohoo...its up
<zul> frig...
<zul> T-Bone: when did -devel become support?
<T-Bone> screw me if i know ;P
<zul> why?!! why me...heh
<zul> okies...usb-storage-unsual-dev have been updated
<lamont_r> sup zul?
<zul> not much how are you?
<lamont_r> about to get kicked out of my buddy's place, and go back home
<zul> ooo...fun fun
<T-Bone> lamont_r: thank your buddy for me ;)
<lamont_r> h3h
<lamont_r> we'll do
<T-Bone> and tell him his invaluable contribution to the ubuntu effort will long be remembered ;o)
<zul> he jus wants you to work on hppa all the time dont be fooled
<lamont_r> he says 'who?'
<lamont_r> zul: duh
<T-Bone> lamont_r: some nerd you know ;o)
<zul> its like the madusa but only slightly more uglier
<lamont_r> don't even bring up that PoS software from france.
<T-Bone> zul: are you suggesting i look like a medusa? :)
<lamont_r> oh,wait.  that was hp-internal.  nm
<zul> uh...no...
* zul whistles
<T-Bone> lamont_r: oh. Now you've said either too much or not enough. Please elaborate! :)
<zul> madusa?
<lamont_r> medusa was (is?) a piece of "security" software that much of HPIT was running on their machines over time, at least until a couple years back.
* T-Bone considers p4wN1nG zul's box to 3duc4t3 him about paying due r3sp3ct to l33t m45t3rZ ;)
<lamont_r> source was not available, because that would "compromise the security of the package"
<T-Bone> rotfl
<zul> T-Bone: i dont read idiot :)
<T-Bone> zul: that may get you into trouble ;)
<lamont_r> T-Bone: and it was brought to us by the fine folks in grenoble, iirc.
<zul> nah idiot would be "T-Bone considers p4wN1nG zul's box to 3duc4t3 him about paying due r3sp3ct to l33t m45t3rZ ;)"
<T-Bone> huhuhu
<lamont_r> T-Bone: idiot the language, not idiot t-bone... ;)
<zul> well it can go either way ;)
<T-Bone> zul: yeah. Not reading what is said might get you into trouble when you'll realize what it *meant* ;o)
<lamont_r> lol
<T-Bone> zul: that would actually get you into trouble for sure ;)
<zul> nah...
<lamont_r> not sure what pawning would have to do with it...
<lamont_r> that requires a trip to the pawn shop, after all.
<T-Bone> lol
<T-Bone> all your bases are belong to me anyway. Resistance is futile
<zul> heh...all your babies belon to me. Resistance is fertile
<T-Bone> rotfl
<T-Bone> quoting that one
<T-None> high time to get some sleep. bye
<zul> toodles
<kylem> hmm, do you guys have hostap in the warty kernel?
<zul> nope
<kylem> poop.
<zul> prolly for hoary+1
* kylem shakes his fist.
<zul> dont look at me
<lamont> "Ya - now I'm trying to get the pchdtv HD-3000 card working on it with MythTV - a number of us at HP are setting MythTV up at home ... Yes - just need the pchdtv.com HD-3000 to be supported/work and we are set.... We are close - the provided driver doesn't quite seem to work on Hoary Hedgehog"
<lamont> told him to get me a patch and we'd see if we could make it happen... :-)
<zul> so people at hp are converting from debian to ubuntu? cool
<mjg59> zul: (cough)
* mjg59 looks at the large pile of HP kit he has sitting here
<zul> mjg59, i was going to ask you about that asus bug in bugzilla today so dont worry about it
<mjg59> The Asus bug is crack
<mjg59> It's a broken DSDT, we can't work around it properly
<zul> that was what i thought
<mjg59> I /do/ have to work out why these HPs are misbehaving, though
<mjg59> And I've got until the 22nd. Argh.
<zul> blame lamont
<mjg59> Haha
<mjg59> After his time, I feel
<zul> that is my motto
<mjg59> EEZ LAMONT'S GTK BOOG
<zul> hehe
<zul> heh...i cant get enough of this concert video
<lamont> no, no, no.. blame bdale
<kylem> lol.
<zul> you are more convient though :)
<lamont> yeah, but I don't work there.
<zul> you are just my scapegoat though
<lamont> heh
<mjg59> Grah. I'm going to have to engage mad ACPI debugging skills here,
<lamont> mjg59: you going to UDU?
<kylem> drillinger.
<mjg59> lamont: Yeah
<lamont> mjg59: maybe I'll pester you from some suspend help on my vaio there...
<mjg59> Haha
<lamont> haha vaio is hopeless?
<zul> night folks
<mjg59> Vaio might well work
<mjg59> I've had love with them in the past
<mjg59> What happens if you just enable it now?
<lamont> dunno - been too scared. :-)
<lamont> what do I do to enable it?
* lamont prepares to receive the cluebat
* lamont upgrades the laptop to current hoary
<mjg59> Upgrade to Hoary, edit /etc/defaults/acpi-support and uncomment the second line, save, reboot, login, select logout/suspend computer to ram
<lamont> ok.  will take a bit still... was kinda out of date.. but only because it's been a couple weeks since the last upgrade.
<mjg59> If you're lucky, the sleep button will work
<lamont> ??
<lamont> hrmpf.
<lamont> do I need the -28 kernel, or is -27 good enough?>
<lamont> mjg59: and suspend-to-disk?
<lamont> fabbione: do the abi files get delivered as part of the deb? or can we just rename them forward (assuming the builds succeed, of course...)
<lamont> looks like the answer to the first question is 'no'.  that sucks.
* lamont reboots the laptop
<dilinger> lamont: delivering them as part of the deb means hacking kernel-package
<lamont> bad fabbione: changelog lines > 80 chars wide.  :-)
<lamont> dilinger: not delivering them means that the buildd removes them and they're gone.
<dilinger> that's correct
<dilinger> fabbione's idea was to make a separate abi package
<lamont> but the check is to make sure that they're identical, yes?
<lamont> in which case one could just rename the directory
<dilinger> what are you trying to do?  get around the check, or actually make sure the check is useful?
<lamont> make sure that it's useful
<lamont> given that the build of 28 fails if 27 doesn't match, then success in building 28 would tend to indicate that the files you had in 27 could roll forward, once 28 had built everywhere, no?
<dilinger> not necessarily
<lamont> mjg59: don't have a logout/suspend to ram option.  and hitting the power button detected that power button was hit, hit the disk a bit, and then powered down.  on pushing it again, the machine cold-booted.
<dilinger> it only fails if a symbol has changed or been removed
<dilinger> if a symbol has been added, it merely warns
<lamont> ah, not if added.
<lamont> ok
<dilinger> anyone know if fabbione will be around today (saturday)?
<lamont> dunno - neither answer would surprise me though
<dilinger> what do you guys do w/ nonfree drivers that prune-non-free strips out?
<dilinger> (if anything)
<lamont> what way non-free?
<lamont> pretty much, they wind up in the linux-restricted-modules packages
<dilinger> they include firmware
* dilinger blinks
<dilinger> is linux-restricted-modules source package really another copy of the kernel?
<dilinger> guess not. wow, those ati and nvidia source directories are huge
<lamont> binary blob drivers suck, btw.
<lamont> where it's just the firmware, ISTR that the driver is in main, but the firmware blob is in lrm.  haven't really looked in quite some time though
<lamont> at any rate, time to go fall over
<dilinger> i don't see it in the linux-restricted-modules source
<dilinger> stuff like qla22xx
<dilinger> either way, i've got a new prune-non-free that strips stuff out nicely
<dilinger> and generates a new tarball w/ pruned drivers, for !main
<fabbione> morning
<fabbione> lamont: were you searching for me yesterday?
<lamont> fabbione: was just going to (1) grumble about the abicheck causing the build to fail before creating the abi files, and (2) grumble further about how the abi files do not survive the build.
<lamont> then I tried to go to bed and we had a fire call.
<fabbione> lamont: the abichecker in -28 is broken
<fabbione> i fixed it in -29
<fabbione> the abi files are not supposed to survive the buildd for the version you are building.
<fabbione> only the prev_version
<lamont> fabbione: I hit it with a hammer and will merge in hppa abi files tomorrow night
<fabbione> mdz asked to keep the changes for hoary down to minimum
<fabbione> lamont: that's what i did for sparc yesterday
<lamont> ok
<fabbione> i didn't notice the breakage in -28 until sparc attempted the build
<fabbione> but -29 is ok.
<lamont> http://www.thinkgeek.com/cubegoodies/toys/71bc/
<fabbione> ahhahaha
<fabbione> lamont: if you have time, it would be nice to have a "startnewsecurityrelease:" target
<fabbione> on the same line of startnewrelease:
<fabbione> except that it will create point releases
<lamont> right
<fabbione> that will be usefull for pitti after release
* lamont adds that to monday's todo list
<fabbione> well just if you get the time
<fabbione> i might get there on monday morning
<fabbione> no need for a strict TODO entry :-)))
<lamont> heh
<lamont> I'll poke you before I work on it.
<fabbione> sure
<fabbione> or just baz update :-)
<fabbione> i need to take my wife shopping pretty
<lamont> actually baz merge
<fabbione> soon
<fabbione> better i get ready
<fabbione> uh why? aren't you working on pre29 ?
<fabbione> or did you create your own branch?
<lamont> local copy, to avoid the net traffic
<fabbione> ahh
<lamont> baz tree-version
<lamont> lamont@ubuntu.com--2005/kernel-debian--pre29--2.6.10
<fabbione> make sense :-)
<lamont> yeah, then it's just the merge back that hurts
<fabbione> i guess so :-)
<fabbione> anyway...
<fabbione> good night lamont :-)
<fabbione> i am off from here
<lamont> g'night
<lamont> likewise
<svenl> fabbione: hi.
<svenl> fabbione: the gentoo guys did get my gige patch working with 2.6.10, so it may be an issue with the port configuration.
<svenl> fabbione: the debian kernel enables just port1, whcih is the connected port, while you enable all three of them.
<svenl> mmm, seems it is not that, but they got it working on 2.6.10, i don't know why ubuntu failed here.
<svenl> strange.
<svenl> will try again, see you later.
<svenl> fabbione: maybe you could ask your friend with a pegasos to try, but he needs a OF revision of at least the august 2004 version
<Mithrandir> svenl: how do you upgrade the firmware on a peg1 (or can't you?)
<svenl> Mithrandir: the same as on peg2, you launch the upgrade from the OF.
<Mithrandir> well, how? :)
<svenl> i need to build a peg1 OF from the new development tree and test it first, its on my TODO list for the next couple of weeks.
<svenl> Mithrandir: boot cd upgrade
<Mithrandir> ook
<Mithrandir> any chance you could give me an ISO or send me a cd when you've done that?
<svenl> Mithrandir: it is just a 640KB file, you can put it on a cd iso all by yourself, you can also boot it from harddisk.
<Mithrandir> ok
<dilinger> heh.  i should probably get to bed
<dilinger> i went to that link lamont posted earlier, and read the first line as "Every first person shooter has a level where you have to get pasta"
<Mithrandir> yeah, sleeps sounds like a good option for you. :P
#ubuntu-kernel 2005-03-31
<zul> hey
<mjg59> fabbione: Another for the hit list - intel_agp needs ICH6 PCI ids
<zul> mjg59: do you have a patch i can put it in my baz archive and fabbione can pull it in
<mjg59> zul: http://linux.bkbits.net:8080/linux-2.6/gnupatch@41ef33a3i1pywQS0NkI1N2y-dqvnHA and http://linux.bkbits.net:8080/linux-2.6/gnupatch@41f070210pJjnvc4hst_7S3kq_JwOQ
<mjg59> http://linux.bkbits.net:8080/linux-2.6/gnupatch@421bf1ba7VqHiwacwODv7TFxIAN-kQ and http://linux.bkbits.net:8080/linux-2.6/gnupatch@42084e8cvqBwS7wKou-PvCGW4Stpug are probably also wanted
<mjg59> Gar. We also need http://linux.bkbits.net:8080/linux-2.6/gnupatch@42307fe1_IGeH1Vsciya0MYbowgWzg
<mjg59> (Unrelatedly)
<mjg59> The last one needs an obvious change to get it to apply
<zul> gotem
<mjg59> Thanks!
<zul> mjg59: http://zulinux.homelinux.net/Archive/zulcss@gmail.com--2005/kernel-debian--pre29--2.6.10/patch-16/log
<mjg59> zul: And those all apply? Excellence.
<zul> er...i should check..:)
<mjg59> The typo fix one needs to go after the i915 support one
<zul> yep...that how it is in my 0029-List
<mjg59> zul: I'm off to bed now - I'm happy to take a look at this in the morning if you'd like
<zul> sure..its up to you
<zul> but ill work on it abit tonight been sick all day mostly
<dilinger> http://svn.debian.org/wsvn/kernel/trunk/scripts/prune-non-free?op=file&rev=0&sc=0
<dilinger> generates http://www.acm.rpi.edu/~dilinger/kernel-source-2.6.11/ and http://www.acm.rpi.edu/~dilinger/kernel-source-nonfree-2.6.11/
<zul> cool
<zul> crappers...
<zul> night...must go back to throwing up
<crimsun> ni zul
<zul> fabbione: do you have a script that is pulling stuff from my Archive?
<fabbione> nope..
<fabbione> i have baz
<fabbione> but i didn't pull anything from your archive directly..
<fabbione> is there anything pending?
<zul> no i was just curious because there is alot of hits from dk
<zul> im working on a couple of things
<fabbione> i have only one ip
<fabbione> and that's the same i am connected here
<zul> yeah a couple of hits from the same ip :)
<fabbione> i did register and abrowse the archive once
<zul> ah ok
<zul> i was just going through my long files when i wasnt throwing up today
<fabbione> other ips != me
<zul> i know
<zul> so how is it going?
<fabbione> just woke up
<fabbione> and going to meet Mith and out all day
<zul> cool im almost going to go bed
<fabbione> i didn't get laid..
<fabbione> what else...
<zul> thats too bad...and probably too much info
<fabbione> the sparc buildd did catch up with all main
<fabbione> you did ask :)
<zul> cool..
<zul> i know but there is sometings you keep to yourself
<fabbione> i was just kidding :-)=
<zul> i know
<zul> so was i
<zul> thats is one large huge hunking patch
<zul> -rw-r--r--  1 chuck chuck 1.2M 2005-03-19 17:58 sk98lin_v8.15.1.3_2.6.10_patch
<zul> intrusive as well...
<zul> night night
<crimsun> http://www.ubuntulinux.org/wiki/KernelBazNotes corrected
<mjg59> Ah, bugger.
<mjg59> Can http://linux.bkbits.net:8080/linux-2.6/gnupatch@41f8b1833aRMvNReQ1N83hc7Zm0JBg be added?
<mjg59> Oh, hang on, it has
<mjg59> Hrm
<crimsun> the extra pci ids you mentioned, correct?
<mjg59> Wait a sec
<mjg59> That patch is already in, but doesn't seem to do the right thing
<mjg59> I'll generate one now
<mjg59> http://www.codon.org.uk/~mjg59/tmp/i915drm.diff
<crimsun> morn' zul, feeling better?
<mjg59> (needed for i915GM DRM)
<zul> little bit
<zul> mjg59: got it
<mjg59> zul: Thanks!
<zul> applied cleanly and commited
<zul> bbl
<zul> whee
<zul> mjg59: the ppc suspend patch didnt apply cleanly mucking around with it now
<mjg59> zul: Mm?
<mjg59> Oh, yes. In the third hunk, the last line of context needs to be changed
<zul> the uninorth agp the config_pm chunk got rejected so im inserting into it now
#ubuntu-kernel 2005-04-01
<mjg59> Did something like http://lkml.org/lkml/2005/3/11/96 get applied?
<zul> lemme check
<zul> no it conflicted with the pmac_pdisk patch
<mjg59> Ok
<mjg59> Can you do one that just adds device_shutdown() as the first line of the PM_DISK_PLATFORM case?
<mjg59> (Context is that without doing that, we cut power to disks before their cache has been flushed)
<zul> sure..
<mjg59> So just before the local_irq_save() stuff
<zul> so like this?
<zul>   case PM_DISK_PLATFORM:
<zul>                 device_shutdown();
<zul>                 local_irq_save(flags);
<zul>                 error = pm_ops->enter(PM_SUSPEND_DISK);
<zul>                 local_irq_restore(flags);
<zul>                 break;
<zul> brb
<mjg59> Yup, that's perfect
<zul> cool
<mjg59> Hm. I may have this ACPI issue sidestepped.
<zul> what acpi issue?
<mjg59> kacpid taking all CPU time after resume from disk.
<zul> ah ok
<zul> mjg59: done
<mjg59> zul: Rocking, thanks!
<zul> np
<dilinger> mjg59: is that related to the 0xff-after-resume problem you were having?
<mjg59> dilinger: Nope
<mjg59> I haven't tracked that one down yet
* zul is debating whether to update the sata driver for ich5
<calc> update the ipw2200 driver too :)
<calc> the one from dec doesn't work on amd64
<zul> it was a rhetorical debate i wasnt actually going to update it
<calc> oh :\
<zul> fabbione: i dont think im going to make any changes to my tree so you should be able to pull it in now
<zul> later
<crimsun> later
<fabbione> morning
<fabbione> mjg59: still around?
<fabbione> 3
<fabbione> mjg59:
<fabbione>   * s/CONFIG_pm/CONFIG_PM/g :
<fabbione>     Update uninorth-agp-ppc-suspend.dpatch
<fabbione> otherwise you don't get to build it at all :-)
<mjg59> fabbione: Ugh. Yeah.
<fabbione> i applied also the other patches you submitted to zul
<fabbione> they will be in for -29
<mjg59> fabbione: Rocking
<zul> hey
<zul> fabbione: the config_pm was my bad
<mjg59> fabbione: So we're expecting -29 on Wedensday or so?
<zul> am at meeting bbl
<fabbione> re
<fabbione> zul: ok.. doesn't matter.
<fabbione> anytime tomorrow...
<fabbione> mjg59: ^
<fabbione> after 15:00 UTC
<mjg59> Rock
<svenl> fabbione: BTW, the 2.6.10 marvell gige patch worked fine on a gentoo kernel, so i wonder if there is some ubuntu-specific breakage that this causes ?
<mjg59> svenl: What's the failure mode?
<svenl> mjg59: failure mode ? 
<mjg59> In what way does it not work on the ubuntu kernel?
<svenl> mjg59: wait, i need to re-image the partition to check.
<svenl> mjg59: the module loads, the interface comes up, but you can't communicate through it.
<mjg59> Do you get interrupts?
<svenl> didn't check.
<mjg59> Right. Interrupt routing is the most likely issue.
<svenl> i will reimage the partition, and give it a try.
<svenl> may well be that this is the issue.
<svenl> mjg59: thanks.
<zul> wow...that was a fun meeting...not
<zul> hey T-Bone 
<T-Bone> howdy
<zul> how is it going?
<T-Bone> ermm. "couci couca" i would say in french ;P
<zul> been better?
<T-Bone> yeah
<T-Bone> but it should getter better soon. I've decided to take a few non paid vacation days to unplug and "reset the hardware"
<T-Bone> but it should getter better soon. I've decided to take a few non paid vacation days to unplug and "reset the hardware"
<T-Bone> oops
<T-Bone> that should have been "going to ski in the french alps between Mar 25 and Mar 29"
<zul> cool...right before release ;)
<T-Bone> yeah
<T-Bone> i'm used to "run on D day" thing ;)
<T-Bone> been pretty good at it
<zul> fabbione: what do you want to do about the dell perc stuff?
<zul> fabbione: never mnid 
<T-Bone> zul: i assume he didn't, anyway 8))
* T-Bone ducks
* zul smakcs T-Bone for good measure
<T-Bone> lol
<zul> hah im not going crazy
<T-Bone> <offtopic>hmm. Does anyone remembers what's the max number of files per directory on Linux?
<T-Bone> (ext3)
<T-Bone> hmm. nm, found the proc file where that value is
<mjg59> Isn't that the maximum number of open files, not the maximum number of files per directory?
<T-Bone> indeed
<T-Bone> looks like i'm being confused
<zul> right im heading home
#ubuntu-kernel 2005-04-02
<zul> hey
<fabbione> morning
<dilinger> did you guys see http://linux.bkbits.net:8080/linux-2.6/cset@41fdb84aBJklcjU85o1N1_dsch6HBw ?
<dilinger> oh, nm, you did
<dilinger> hrm
<dilinger> fabbione: what is this vfs-f-maxcount thing that was committed in -16.11?
<dilinger> s/committed/added/
<fabbione> dilinger: better you ask pitti for warty security. i am not 100% sure about all of warty changes
<fabbione> goody.. i got xen to work
<fabbione> hmmm the xen patch is not that intrusive at all....
<fabbione> at least on the non-arch specific code
* fabbione yawns
<fabbione> guys... anybody has to submit any patch?
<fabbione> we are close to deadline
<zul> hey
<zul> fabbione: the bugs with the dell perc drivers wait til hoary+1 correct
<fabbione> zul: what bug?
<zul> the megaraid2 drivers
<fabbione> yes it will wait hoary+2
<fabbione> meh
<zul> k
<fabbione> +1
<fabbione> i did drop your patch becuase it is not correct
<zul> thats what i thought
<zul> ok no probelm
<fabbione> it is not enough to enable the compilation option
<fabbione> the big issue is the PCI ids
<fabbione> they share an amount of common ids
<zul> bleah..
<fabbione> that means that hotplug might load one or the other driver
<fabbione> = mes
<fabbione> fuck i can't type
<fabbione> = mess
<zul> hehe...i noticed :)
<zul> so how is it going?
<fabbione> i am in the middle of a build orgy
<zul> ooh...fun 
<fabbione> testing ABI and stuff on all arches
<zul> so tool late for submitting patches ;)
<fabbione> no
<fabbione> you still have up to 15:00 UTC
<fabbione> i am just building.. so if nobody submit .. i can just upload :-)
<zul> nah...i was just trying to pull your chain
<fabbione> zul: hmmm let me find an appropriate answer...
<fabbione> GO FUCK YOU LITTLE TINY BITCH!
<fabbione> :P
<zul> hehe..
<zul> fine i will..
<zul> good weekend?
<fabbione> yeah it was ok
<fabbione> i met with Mithrandir
<fabbione> and were at LegoLand
<fabbione> pretty funny
<fabbione> amd64 is GO
<fabbione> btw.. i did check XEN
<fabbione> i think we can manage to add it for hoary+1
<zul> cool
<zul> i wouldnt mind going to lego land
<fabbione> it is quite fun :-)
<zul> i loved lego when i was a kid my wife still has alot of her old lego
<fabbione> so do i :-)
<fabbione> it's a good one/two days trip..
<fabbione> but no more than that
<fabbione> two if are really into Lego to death
<zul> heh
<zul> we have to come and visit you then ;)
<fabbione> welcome to :-)
<zul> just have to find the money
<fabbione> ia64 is GO
<zul> damn...how many pcs do you have?
<fabbione> i have 7 or 8 i386's one sparc and a couple of m68k
<fabbione> all the others (amd64/ppc/ia64) are at the datacenter :-)
<zul> but you own the ia64 or is that an ubuntu machine?
<fabbione> ubuntu machine
<fabbione> it's still in the datacenter
<zul> ah
<zul> that aic7xxx bug is eating away at me
<zul> flakey hardware
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | http://people.ubuntu.com/~lamont/Archives/kernel-team@ubuntu.com--2005/ kernel-team@ubuntu.com--2005/kernel-debian--pre29--2.6.10 | Last it or http://www.getoffmynuts.com/gallery/images/asys.jpg | There are no kernel bugs.. only broken hardware
<zul> lol
<fabbione> we need to give a name to team....
<fabbione> and put up some webpages :-)
<fabbione> just for the pure fun of it
<zul> kernelfriedchickens
<zul> im just hungry right now and i want chicken
<fabbione> ahhaha
<fabbione> ppc is GO
<lamont> fabbione: just confirming that the hppa abi files are in your build?
<lamont> and do we have something in place to capture the abifiles from the buildd?
<lamont> we could consider doing something horribly hacky like adding a new .udeb beyond what the build process tries to give us. :-)
<zul> heh.. <pitti> 20 people can already DoS launchpad?
<fabbione> lamont: yes. abi files for hppa are in place. and no.. we don't have any system to get them out of the build yet. mdz was very strict to NOT do it for hoary...
<fabbione> i will be back in 20/30 minutes. i need to get a shower
<lamont> right
<fabbione> if there are no changes, abi files for -29 will be the same as -28
<fabbione> just keep an eye on the build log
<fabbione> if there is an abi change will FTBFS
<fabbione> if there are new symbols it will give a warning
<fabbione> otherwise it is silent
<fabbione> in the latter we will just rename -28 to -29
<fabbione> and zack
<fabbione> bbl
<lamont> hrm... if there are new symbols, could it just embed the diff in the build log?
<lamont> anyway, good idea... bbiab
<fabbione> lamont: it is...
<fabbione> i had the same idea while i was taking the shower
<fabbione> we can actually just parse the build logs :-)
<fabbione> i386 is GO
<fabbione> i am preparing the upload...
<zul> cool
<zul> smashy smashy
<fabbione> should we dedicate this upload to somebody?
<zul> crispy chicken
<zul> still hungry ;)
<fabbione> ahhaha
<fabbione> i would suggest to jdub that all the names that will not make an official ubuntu release, can be used for the kernel
<lamont> fabbione: if there's a diff in the build logs, then we have a way to extract the info from the build. :-)
<fabbione> licky lion
<lamont> I was just fearing that we'd have to use a manual build to get it...
<fabbione> lamont: there is..
<zul> scarlet pimperneal
<lamont> right
* lamont prefers the chalise with the palice
<lamont> palace
<fabbione> lamont: that's what i was afraid of.. until i got a shower 30 minutes ago :-)
<fabbione> should we start from this release to add release names to our kenrels? or wait for hoary+1?
<zul> my shower sucks release
<zul> hell...do it for this release
<zul> no one reads the changelogs ;)
<fabbione> that's what you think :P
<zul> hehe
<fabbione> let's start with crispy chicken
<zul> and the next one can be codron bleu
<fabbione> nah .. it needs to have a similar form of the ubuntu
<zul> and the one after that can be shake and bake...i need to get something to eat
<zul> brb
<fabbione> warty wartogs.. hoary hedgehogs..
* fabbione starts the baz magic
<zul> mmm...food
<fabbione> fried fishbones <-
<zul> heh
<fabbione> ok food is our Release Codename source :-)
<fabbione> patetic potatoes
<zul> podantic potatos
<lamont> must be good adjectives
<lamont> look what happened to grumpy and perky
<lamont> hrm.. perky might still be there
<lamont> crispy corn.
<lamont> after all, it's a kernel....
<fabbione> ehhe ok...
<dilinger> percipient prunes
<fabbione> ok.. let's vote for -30 codename :-)
<fabbione> crispy corn +
<dilinger> they're watching you!
<dilinger> hrm.  hungry.
<zul> creamy chocolocate
<zul> i just had a candy bar
<zul> so -30 is still bug fix release correct?
<zul> and i vote for crunchy celery
<dilinger> machiavellian meatloaf
<zul> thats not bad
<dilinger> i have way too much fun w/ gnome's dictionary
<zul> rocky road
<zul> type of ice cream
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | http://people.ubuntu.com/~lamont/Archives/kernel-team@ubuntu.com--2005/ kernel-team@ubuntu.com--2005/kernel-debian--pre30--2.6.10 | Get it or http://www.getoffmynuts.com/gallery/images/asys.jpg | There are no kernel bugs.. only broken hardware
<zul> flaming filion
<fabbione> zul: want to close the bugs?
<zul> sure
<fabbione> thanks
<lamont> hazardous horse?
<fabbione> ehhe
<fabbione> guys should we have a meeting next week?
<zul> yep
<fabbione> like wed 14:00 UTC?
<fabbione> or 20:00 UTC
<lamont> 30 mar?
<lamont> 1400utc would make me cry
<fabbione> meh.. that's a bad date
<zul> 14:00 utc is better for me because im usually on my way home by then
<lamont> 1600 is more palatable
<zul> 20:00 utc sucks for me
<fabbione> lamont: 16:00 UTC and my wife will make so that i won't be able to procreate anymore
<zul> 1600 is good
<lamont> I see.
<lamont> but 2000 is OK?
<lamont> ah, you miss dinner.  got it.
<fabbione> yeps...
<zul> 22 is bad for me
<fabbione> 2000 she is mostlikely asleep
<zul> 2000 is ok
<lamont> anything after about 1500 is fine by me
<lamont> 2000 would be most cool
<zul> did you add the patch for snd_nm stuff?
<fabbione> ok 2000 UTC than....
<zul> never mind
<fabbione> zul: yes of course i did ;)
<fabbione> iirc the 30th is RC release.. right?
<zul> afaik yes
<lamont> sounds correct
<lamont> 6th is release
<lamont> 5th is panic
<lamont> done been scheduled. :-)
<fabbione> ok let's do it the day after RC
<fabbione> nah
<fabbione> let's do it next tuesday
<fabbione> day before RC
<fabbione> at least if there is something with the kernel we can discuss it before RC
<zul> sure
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | http://people.ubuntu.com/~lamont/Archives/kernel-team@ubuntu.com--2005/ kernel-team@ubuntu.com--2005/kernel-debian--pre30--2.6.10 | Get it or http://www.getoffmynuts.com/gallery/images/asys.jpg | There are no kernel bugs.. only broken hardware | Kernel Team Meeting in this chan: Tue 29th March 20:00 UTC
<fabbione> lamont: mind to mail kernel-team?
<fabbione> i would say as agenda:
<fabbione> - last hoary details
<fabbione> - start planning for bendy
<fabbione> - aob
<fabbione> (where topic 2 is low pri)
<fabbione> and -pre30 is started...
<fabbione> i already added the abi files from -29
<fabbione> the only one that is uncertain is hppa....
<fabbione> all the others are identical to -28
<fabbione> bbl
<fabbione> wife is back
<dilinger> bendy or breezy?
<fabbione> breezy ;)
<fabbione> but i love bendy more
<lamont> breezy
<lamont> fabbione: will verify hppa once it builds
<lamont> aob?
<fabbione> - any other business?
<zul> post maintenance of hoary
<fabbione> gotta love ccache
<fabbione> Build needed 00:24:03, 1433504k disk space
<fabbione> see ya for the CC meeting
<fabbione> lamont: i have some work for you this night :-)
<lamont> fabbione: OK
<lamont> which work would that be? besides emailing the agenda
<fabbione> lamont: check your mails :-)
<lamont> fabbione: yeah.  thanks much
<T-Bone> howdy!
* T-Bone notices the topic, gacks he wont be there :P
<zul> Hey T-Bone 
<T-Bone> heya
* T-Bone reands lamont's mail, doesn't quite get everything, resumes buildd hacking in the meantime
<T-Bone> fabbione: ping?
<zul> heh...anyone tryed using cdrecord -dev=/dev/hd<whatever> -data backup.iso
<zul> blah...im a chrack head
<zul> i only break the big ones at the least convient times
<T-Bone> lamont_r: ?
<lamont_r> note.  running firefox over ssh _SUCKS_
<zul> brb
<T-Bone> lol
<zul> later
<lytefyre>  anyone know how to boot off external usb hdd , ive got the kubuntu preview
<T-Bone> lytefyre: ask on #ubuntu
<lytefyre> T : i have a kernel problem
<lytefyre> install went fine
<T-Bone> ?
<lytefyre> have grub on MBR of the usb all entries i can see..when i boot i manage to load the kernel as well as initrd images
<lytefyre> it fails at a later stage with pivot_root and no dev/console errors , any ideas ?
<T-Bone> nope
<lytefyre> k thanks 
<T-Bone> lamont: ?
<jbailey> Hmm, hadn't noticed lytefyre.  I doubt we have the evil magic to bring in all of USB to the initrd.
<fabbione> hell...
<fabbione> the sparc abi files were not sorted properly
* T-Bone needs a tiny little help to finish setting up wanna-build on hppa... *sigh*
<T-Bone> fabbione: you wouldn't happen to have time/knowledge to answer a few quick questions, would you? :)
<fabbione> T-Bone: in 4 minutes?
<fabbione> would that be ok?
<T-Bone> sure
<T-Bone> just fine :)
<T-Bone> ping me then
<fabbione> re
<fabbione> go ahead
<jbailey> fabbione: Are you the right one to ask to get a channel logged?
<fabbione> jbailey: yes
<fabbione> jbailey: but only if it is ubuntu related...
<jbailey> fabbione: #ubuntu-java
<fabbione> jbailey: ok.. can you send me an email so i will remember to do it?
<fabbione> i am not really wake enough to do it right away
<jbailey> fabbione: No prob.  I'v ebeen wondering for the last day or so who to ask. =)
#ubuntu-kernel 2005-04-03
<zul> jbailey: are you handling udev?
<mdz> zul: you found a possible fix for my irqpoll issue?
<jbailey> zul: I've looked through the code a bunch, what do you need?
<zul> mdz: i might have gimme a sec..
<mjg59> Hrm. I meant to test the new kernel but went to the pub instead.
<zul> mdz: http://linux.bkbits.net:8080/linux-2.5/gnupatch@41d8ffffTqVUXXYJ_W0XUlqj90uQGg
<fabbione> mjg59: pub > kernel
<zul> jbailey: could you have a look at #3069?
<mdz> zul: I'm happy to test it, since it's in the sound driver and not (as I feared) another general IRQ routing mess
<mjg59> fabbione: I agree
<zul> mdz: ok...i should have something for you tomorrow
<zul> my fast pc is at work
<jbailey> zul: That's a closed evo bug.  EBUGNUM?
<zul> grr
<fabbione> btw.. we might need to release -30 pretty soon
<zul> 3609...sorry am a bit dyslexic :)
<zul> fabbione: how come
<fabbione> so if you have pending stuff, let's get it tested during eastern
<fabbione> zul: some more security stuff that is all public already
<zul> easter you mean :)
<zul> ah
<zul> ok
<fabbione> yeah that kind of holidays
<fabbione> i might as well get -30 out tomorrow if i can manage to
<fabbione> we need to get these bits tested asap
<zul> sure
<fabbione> mdz: do you think you can test that patch within the next 5/6 hours?
<fabbione> zul: please add the bk info to the bugs so i can merge the patch if it works
<zul> fabbione: no problem
<fabbione> or sync your archive.. or whatever you prefer :-)
<zul> its in my archive already
<fabbione> ok.. i will merge from you than
<jbailey> zul: Fine, I can take this.  I have another wishlist bug against udev assigned to me that I was planning on nailing anyway (same sort of thing)
<zul> cool...merci buckets
<fabbione> oki doki
<fabbione> i am off for the night...
* fabbione has to wake up in 4:30 hours
<zul> c ya
<fabbione> night
<zul> mdz: are you running a 686 kernel?
<zul> i can try to get this started so it might be possible to test tonight
<mdz> zul: k7 on the affected system
<mdz> zul: 2.6.10-3-k7 in fact ;-)
<mdz> I haven't rebooted it in some time
<mdz> but I'm happy to do so in order to test if needed
<zul> ok
<zul> ill start a build now
<lamont> fabbione: you around yet:
<fabbione> morning
<fabbione> sorry.. i overslept
<fabbione> lamont: go ahead :-)
<fabbione> mjg59: 7377
<fabbione> is that some ACPI fucks up?
<mjg59> fabbione: I honestly have no idea. It's very, very odd.
<fabbione> mjg59: do you have any idea on how to debug it?
<mjg59> The only real hope is to build a kernel with acpi debugging and try to work out where the event is coming from
<mjg59> It certainly /look/ like the poweroff method is being called
<fabbione> mjg59: ok.. what do you want me to do to give them a test kernel?
<fabbione> or can you do it directly?
<mjg59> Let me take a look at their dsdt first, and see if I can work out what's up
<fabbione> ok
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | http://people.ubuntu.com/~lamont/Archives/kernel-team@ubuntu.com--2005/ kernel-team@ubuntu.com--2005/kernel-debian--pre30--2.6.10 | Get it or http://www.vijaygill.com/pics/stfu.gif | There are no kernel bugs.. only broken hardware | Kernel Team Meeting in this chan: Tue 29th March 20:00 UTC
<fabbione> Hejsa nowlin 
<zul> hey
<mjg59> -29 is absolutely rocking on my available hardware. Thanks!
<zul> dont thank just him ;)
<zul> I hate writing documentation
<zul> heh..fabbione you have been busy this morning
<zul> or afternoon whatever..
<zul> T-None, http://kmuto.jp/open.cgi?buildd
<mdz> we should set a deadline for kernel changes for the release candidate
<mdz> what would you be comfortable with?
<zul> uh...there hasnt been any major changes to the kernel afaik we are just doing major bug fixes right now but fabbione can clarify
<mdz> right, but at some point we must lock it down entirely, no more changes
<mdz> this should be well in advance of the release candidate
<zul> true...thats fabbione's call since he is doing the uploads
<mdz> Mar 09 14:32:28 <sabdfl>         - get kernel sorted TWO WEEKS BEFORE :-)
<mdz> that would be today ;-)
<mdz> but we do need to set a cutoff
<zul> i think fabbione is doing one more upload for some security fixes and the snd_via82xx patch as well
<jbailey> mdz: Jordi and I are looking at the new instance of 1440 as we speak.
<mdz> jbailey: jordi has hardware which exhibits the problem?
<jordi> plop!
<mdz> speaking of the jordevil...
<jbailey> mdz: He has the matching pci:id and reported the problem.  I had him check the array6 first for the known working config.
<jbailey> We're just about to try a nightly from a couple days ago.
<jordi> jbailey: ok, dmesg sent.
<jordi> jbailey: should I wipe it and install the nightly now?
<jbailey> I think if you get as far as wiping it that you don't have the problem from what I understand.
<jbailey> I was just wondering whether or not I should have you move from the 686 kernel to the 386 one first, since that's what you'll actually be running on the installer.
<jordi> nod, ie, I should just check that d-i likes the cd
<jordi> jbailey: good idea.
<jbailey> Yup, please.  It's a quick enough test.
<jordi> scsi1 : ata_piix
<jordi> piix 0wnz the cd drives and they work
<jordi> kernel 2.6.10-5-386
<jordi> inside the daily d-i system. it looks good
<jbailey> Luvly.  Do you have the other CD burned?
<jordi> array6 and the daily, which is what I just booted.
<jbailey> Ugh.
<jbailey> So I wonder what's different?
<jordi> I haven't tried with the 386 image on the installed system yet.
<jbailey> No, that should be enough.
<jbailey> It's not happening on your hardware then. =(  You have matching PCI id's though.
<jordi> jbailey: what's different where? All my three tests worked: array6 d-i, installed system old 386 kernel, installed system new 686 kernel and now daily d-i 386 kernel
<jordi> nod
<jbailey> jordi: Between you and the original reporter.
<jordi> it does happen with debian's 2.6.8 though.
<jordi> AFAIK, not with Debian's 2.6.10.
<jbailey> Right, we've got a patch in our kernel to tell it to cope.
<jordi> I wonder if it's in debian too
<mdz> so jordi has the right PCI IDs but can't reproduce the bug?
<jordi> apparently
<mdz> gaah
<jordi> is there any /proc bit that I can send to you guys that gives you more info about my ide stuff?
<zul> lunch time
<mdz> jordi: lspci -v, I supopse
<mdz> suppose
<jordi> k
<mdz> fabbione: we are going to need to freeze the BOF list now; I am making the schedule
<mdz> I'll add a note to the page
<mdz> actually it already says "do not edit", only I mean it now ;-)
<jordi> jbailey: sent lspci
<jordi> jbailey!
<jbailey> jordi: Heya!
<jordi> jbailey: anything else?
<jordi> got lspci?
<jbailey> I did thanks.
<jordi> ok
<jbailey> I need to run off for a bit soon.  I've emailed the guy who originally reported the problems.  Thanks for the help.
<jordi> ok
<jordi> I'll be gone in a short while too.
<jordi> And won't be back in office for a week.
<fabbione> mdz: yes we planned to freeze the kernel with -29, but we have 5 security fixed on the way (4 already committed and one we are still waiting for the patch)
<fabbione> and the only other thing is the via fix for you.
<fabbione> let me check...
<mdz> I will test the via fix shortly
<fabbione> mdz: there is a very trivial bug fix (comment out one printk())
<fabbione> and one change for d-i requested by Mithandir and KAmion (7800)
<fabbione> there is only one last thing left to do, to make pitti's life easier for security, but it is nothing that will affect the kernel itself. it's an extra target in debian/rules to automatically prepare changelog and 00list-* files for point releases.
<fabbione> zul: btw.. we need to talk about a couple of things when you have time
<fabbione> mdz: all of the above (excluding the via thing) has been already tested and verified
<fabbione> mdz: for the BOF schedule i am ok with what is on the wiki. I did ping kernel-team and no answers, so i want to believe that it is ok
<zul> fabbione: sure now would be good
<fabbione> zul: i did merge from you the via patches... 
<fabbione> 3 things:
<fabbione> 1) check that the patch actually applies. the DPATCH header was broken
<zul> yeah i realized that last night and i didnt check it in
<fabbione> 2) the * dummy entry can be removed as soon as there is the first commit. it is there just to make dpkg-buildpackage happy
<zul> ok
<fabbione> 3) please try to follow the same rules for the changelog
<fabbione> Example:
<fabbione> * Fix foo bar in driver X:
<fabbione>   - Add patch <fullpatchname>.dpatch.
<fabbione> writing the way you do imho is redundant
<zul> ok will do in the future
<fabbione> * Added patch foobar to fix X.
<fabbione>   - Add patch blabla
<fabbione> see? :)
<zul> :)
<fabbione> btw.. it's just that i am farly anal on the changelog :-)
<zul> heh i noticed :)
<fabbione> because a good changelog is a big help to track down stuff
<zul> i always did it a different way in gentoo
<fabbione> that's something i learned from the good branden robinson
<zul> so are you going to upload -30 today?
<fabbione> i am waiting for mdz to confirm that it fixes the bug
<zul> ah
<fabbione> but we also have 2 security things without patch yet
<fabbione> so if i upload today there will be for sure another upload
<fabbione> what scares me is the possibility of an ABI change....
<fabbione> that's why i am slightly more happy to wait and see
<T-Bone> ola
<T-Bone> fabbione: ah ok thx for the hint. Anything special the CurrentlyBuilding file should contain?
<fabbione> T-Bone: yes. but don't bother for now. 
<fabbione> it's not worth the pain
<T-Bone> well
<T-Bone> speeding up the kernel build would be quite a gain
<fabbione> T-Bone: just touch the file for now...
<T-Bone> ah ok
<T-Bone> cool
<fabbione> it really depends on how you created the chroot
<T-Bone> debootstrap
<fabbione> did you use the buildd version?
<T-Bone> yeah
<fabbione> s/version/variant?
<fabbione> well just touch that file for now...
<T-Bone> done
<T-Bone> though i suppose it'll only work for next build?
<fabbione> yeps and only for the kernel
<T-Bone> ok
<fabbione> no other packages makes use of it for that
<T-Bone> ok
<fabbione> otherwise you can still mark the kernel as "Not-for-US"
<fabbione> and build it manually
<T-Bone> well, next time ones upload a kernel, it'll build faster on hppa :)
<T-Bone> i'd rather have it mostly automated
<fabbione> mdz: i am off for dinner.. i will be back pretty soon
<lamont> fabbione: kernel build is using /CurrentlyBuilding????
* T-Bone guesses lamont doesn't like that :)
<lamont> given that it only exists in the data center, and would therefore be an FTBFS if such source were shipped, yeah...
<lamont> I'd hate to have to file an ftbfs bug against the kernel...
<T-Bone> actually it's not exactly that
<T-Bone> fabbione told me that the build process would use concurrency *only* if that file existed
<lamont> fabbione: no abi change on hppa
<lamont> ah, I suppose that's OK
<lamont> but it still feels wrong
<fabbione> lamont: i only check if the file exists. afaik there is no other way to determine if we are at the datacenter or not
<lamont> fabbione: and we check because we don't want builds to go fast outside the data center???
<fabbione> lamont: the use of -j is quite delicate
<lamont> heh
<fabbione> people might have SMP and don't want the kernel compilation to fork and blabla
<fabbione> that's why there is a line debian/rules to override what is autodetected
<lamont> right
<fabbione> # DO NOT UNCOMMENT THIS LINE WITHOUT READING make-kpkg man page.
<fabbione> # export CONCURRENCY_LEVEL := 15
<fabbione> and later:
<fabbione>                 if [ -e /CurrentlyBuilding ]  && [ -z "$(CONCURRENCY_LEVEL)" ] ; then \
<fabbione> so basically the check of CurrentlyBuilding is harmless
<fabbione> it will never produce a FTBFS
<lamont> fabbione: nonetheless, I find myself reminded of the 'if [ $(uid -un) = "buildd" ] " in oo.o
<fabbione> yeah i remember that :-)))
<fabbione> but does exist a more clean way to know if we are in a DC buildd?
<lamont> no
<fabbione> the "feature" doesn't kill other buildds or stop producing _all.deb packages..
<lamont> probably because we didn't design one in
<fabbione> that's why i was comfortable to use it
<lamont> yeah, yeah.  I understand.  it just makes me a little sick
<fabbione> yes and i understand your point :-)
<fabbione> i recog is a hack...
<zul> heh ubuntu actualy made slashdot
<fabbione> for the worst kernel?
<dilinger> for being created by a single person?  (mako)
<T-Bone> fabbione: if you're running as uid 'buildd', i guess you can reasonnably assume that concurrency is *wanted*
<zul> nah...userlinux and ubuntu 
<fabbione> T-Bone: i run my buildd as sparcbuildd user...
<T-Bone> tssks
<T-Bone> ;)
<T-Bone> if /buildd/ then (perlish) :)
<kylem> didn't your mother tell you slashdot rots your brain?
<fabbione> kylem: ahaha
<zul> kylem: yes slashdot bad mmkay?
<lamont> T-Bone: checking user id in the build will get you hurt
<kylem> oh piss. i didn't know about CONCURRENCY_LEVEL
<fabbione> kylem: CONCURRENCY_LEVEL + ccache + distcc > *
<kylem> fabbione, it takes me 7 hours to build the debian hppa images, heh.
* T-Bone wonders if there's a way to change the Real name in a gpg key uid without revoking/recreating
<kylem> and that's on a /fast/ machine with gobs of ram.
<fabbione> kylem: wel... you know what i did?
<fabbione> i just RTFM :)
<kylem> ;-)
<fabbione> sorry.. i couldn't resist
* kylem bearhugs fabbione 
<T-Bone> oh behave 8)
<zul> oh hey T-Bone 
<fabbione> kylem: /topic
<fabbione>  http://www.vijaygill.com/pics/stfu.gif <-
<fabbione> meh ^^T-Bone
<zul> fabbione: yeah showed that to a bunch of people you got me into trouble
<kylem> :)
<fabbione> zul: how? ;)
<zul> fabbione: bastard!
<T-Bone> fabbione: i knew that one :)
<lamont> fabbione: in case you haven't noticed, I'm still getting to the meeting announcement
<lamont> likewise the kernel stuff you sent me last night
<fabbione> lamont: i did the security stuff today
<lamont> thansk
<fabbione> lamont: usually if i see you don't manage across my night, i do the morning after :-)
<fabbione> it's just that i didn't feel very happy to start security at 8pm
<fabbione> mdz: if you want -30 out today, can you please test the via fix?
<lamont> heh
<mdz> fabbione: I will
<fabbione> http://www.vijaygill.com/pics/give_a_damn_progress.gif
<fabbione> ahahha
<lamont> glad I said something before digging into it
<fabbione> lamont: do always a baz update :-)
<mdz> I need about 10 minutes to finish what I am doing before I shut down and reboot
<fabbione> that's how i know if it has been done or not ;)
<fabbione> mdz: ok thanks
<mdz> it is my primary desktop which has the issue
<fabbione> roger that
<fabbione> (btw some pics on that website are really NOT nice)
<lamont> fabbione: "done" != "in progress", fwiw
<mdz> fabbione: hmm, forgot we had a kubuntu meeting scheduled for right now; it will have to wait until after
<fabbione> mdz: ok.. i might not be online, but everything is committed to baz
<mdz> fabbione: can someone else do the upload?
<fabbione> mdz: sure.. lamont can.. otherwise i can do it tomorrow morning
<mdz> fabbione: also another meeting in one hour
<fabbione> 12 hours won't make any difference
<mdz> depending on how long the kubuntu meeting runs, I may not have time until after lunch
<fabbione> mdz: did i miss any meeting call?
<mdz> fabbione: no
<fabbione> ok
<fabbione> mdz: anyway i wouldn't panic too much. i am pretty sure there will be another upload of the kernel before release
<fabbione> (if not 2)
<lamont> fabbione: but this time, lets do the final upload at least 24 hours before release, eh>?
<fabbione> lamont: it's not up to me :(
<fabbione> we don't even have patches for a public security issue....
<fabbione> becuase there is none
<mdz> we should freeze the kernel this week
<mdz> for the RC
<fabbione> mdz: RC can go with -29
<lamont> fabbione: RC means RELEASE CANDIDATE
<fabbione> or -30
<lamont> not 'mostly release candidate'
<fabbione> lamont: yes.. i know that :-)
<lamont> once you plan to replace something in the build, it's no longer release candidiate
<mdz> I would like to get the via fix in if it works; that means no more boot options on any of my test systems
<lamont> so if we're planning on -30 being in the release, it really needs to be in before they build the RC isos
<fabbione> mdz: ok.. just take your time
<fabbione> lamont: yes i get that. but if i upload -30 now or tomorrow morning, it will still make it for RC
<fabbione> the relevant changes are only the security stuff and the via fix
<fabbione> if the via fix is go now
<fabbione> than it's all done
<fabbione> we only need Kamion to upload a new d-i to build on top of the new kernel
<fabbione> end of the story
<fabbione> i am sure we can manage easily :-)
<lamont> are there actual d-i changes, or just needs a new daily-build?
<fabbione> lamont: just a rebuild like the daily
<fabbione> no changes are required
* T-Bone notices that glibc produces a _all.deb
<fabbione> T-Bone: tell jbailey :)
<T-Bone> hehe
<lamont> T-Bone: s/deb$/deb in binary-arch target/
<T-Bone> true
<T-Bone> hmm
<lamont> </pedantic>
<T-Bone> fabbione: gah, your trick seems not to work
<T-Bone> binutils_2.15-5ubuntu2: not registered yet.
<T-Bone> :(
<lamont> T-Bone: for messing with setting things in w-b, it's best if it actually gets fed the right packages file to begin with
<T-Bone> ?
<fabbione> T-Bone: i get that warning too once in a while
<fabbione> afaik it's harmless
<lamont> fabbione: is error
<lamont> at least on take
<lamont> --take
<T-Bone> fabbione: afaict, it discarded all other packages sent to the line
<fabbione> lamont: hmm i get that when i mark a package in Uploaded
<T-Bone> lamont: that's on -u
<lamont> well, it's an error it'll abort processing
<T-Bone> gosh --merge-* is taking ages
<lamont> and you get it because w-b doesn't know about that version of the package
<lamont> yeah
<fabbione> lamont: but w-b gave me that version :-)
<T-Bone> lamont: which is rather stange given w-b gave that package to buildd...
<T-Bone> as fabbione said :)
<fabbione> exactly
<lamont> actually, takes next to no time for me... but I don't have universe.....
<lamont> interesting
* T-Bone will definitely not schedule it more than once a day
<T-Bone> lamont: i call that a bug, but that's my 2cents ;)
<lamont> T-Bone: the DC does it every 30 min, x5 architectures
<T-Bone> well
<T-Bone> either having a flat archive makes things awfully slow
<fabbione> ah we might have a fix for the av_dc thingy that sucks 100% of the CPU
<T-Bone> or you have hell of machines
<T-Bone> it's been running for 8+ minutes here already
<T-Bone> truth told it's the first time it's that long
<T-Bone> i wonder if i have fucked up something
<T-Bone> i should have run it -v
<fabbione> ah hell.. the patch is big
* lamont works on the meeting announcement
<zul> yay!
<zul> heh
<T-Bone> lamont: any reason why w-b doesn't publish its stats, btw?
<lamont> ?
<T-Bone> $web_stats = "/home/buildd/public_html/buildd/stats.txt";
<zul> fabbione: i saw that it hasnt been proven though
<T-Bone> lamont: ^^
<T-Bone> lamont: that file isn't created
<fabbione> zul: the patch is clean, but it changes the ABI afaict
* T-Bone considers 10' as much too long to be honest, considers killing w-b
<zul> fabbione: heh..
<lamont> T-Bone: have you run do-merge-quinn?
<T-Bone> no
<T-Bone> it's currently deadlocking on a --failed
<lamont> well, that's the only file that references $web_stats....
<T-Bone> afaict
<T-Bone> err
<T-Bone> do-merge-quinn != w-b --merge-quinn?
<lamont> nope
<lamont> t
<lamont> it's yet more cruft that we don't care about
<T-Bone> erf
<zul> fabbione: i say hoary+1 for it
<fabbione> zul: let me check something
<fabbione> i want to see if it is upstream
<zul> i already did and i believe it isnt
<fabbione> it might be worth extracting only the changes for the acxxx driver, try to build (for the ABI change) and ask him to tetst
<zul> i can do it if you want
<fabbione> that would be neat
<fabbione> he uses 686-smp
<zul> ok ill throw one together right now
<fabbione> ok great
<T-Bone> fabbione: interestingly enough if you pass only 1 changes file to -u at a time, there's no error
<fabbione> T-Bone: hmm possibly
* T-Bone wonders what happen if a package is marked -u twice or more
* T-Bone hopes that's harmless
<T-Bone> seems to be
<zul> fabbione, just the scsi stuff no 3com or acpi in that patch correct?
<fabbione> zul: one sec...
<T-Bone> wow
<T-Bone> seems that touching the file during the build made it work anyway
<T-Bone> cool
<fabbione> zul: we mostlikely have the acpi changes already. worth to check anyway
<zul> k
<fabbione> mjg59: ping?
<fabbione> iirc the 3com drivers are broken with suspend resume and the patch is not intrusive... but hell we are so close to RC
<zul> they are broken with suspend resume
<fabbione> zul: skip the generic scsi stuff and push him only the ahc driver changes
<zul> ok 
<fabbione> we should ask mjg59 if the patch looks sane
<fabbione> plus i have a 3com to test on
<zul> but the generic scsi stuff contain some CONFIG_PM stuff
<fabbione> yes htat is correct, but that's a more intrusive change
<zul> ok
<fabbione> it's the driver we really care about
<zul> i understand
<fabbione> i am ok to fix a driver, but not to change an entire subsystem
<fabbione> + the scsi change is an ABI change
<fabbione> it adds 4 more functions around
<fabbione> atleast it looks like
<T-Bone> lamont: btw, do you want to be posted about the kind of message i've mailed you?
* T-Bone sees dbus failing on missing kdelibs-dev, wonders
<fabbione> zul: apparently none of the changes in the driver require the changes to the scsi layer
<fabbione> and they shouldn't change the ABI afaict
<zul> ah ok...i made the patch starting it right now
<fabbione> all the changes are confined inside the module
<fabbione> let me check an extra thing...
<fabbione> -
<zul> 686-smp
<lamont> topic changed in #ubuntu-meeting, guess I should email kernel-team, eh>?
<lamont> T-Bone: kdelibs has no love quite yet, in my mirrror
<lamont> but it will soon
<T-Bone> kdelibs is in main?
<fabbione> lamont: ehhe
<T-Bone> lamont: no need, it'll be built here
<T-Bone> just rsync it when it's there
<lamont> kdelibs is in main
<T-Bone> urg
<lamont> T-Bone: quicker to just build it here...
<lamont> since the source is already here, I think
<fabbione> zul: yes.. all the changes are confined inside the modules. in any case the modules seem not to depend on each other. that means that we are ok with it
<lamont> fabbione: you saw that -29's hppa is no change from -28 (abi), right?
<T-Bone> lamont: well, much slower to upload from your place :P
<fabbione> lamont: yeps.. the abi files for hppa are there already
<lamont> T-Bone: yeah. and equally slow to upload
<lamont> s/up/down/.
<zul> fabbione: that is what im going with http://zulinux.homelinux.net/ubuntu/kernel/aic7xx-sleep.dpatch 
<T-Bone> lamont: if you don't need it you don't have to download it, otoh :)
<fabbione> zul: looks sane
<zul> nifty...building now
<T-Bone> lamont: just for you http://archive.slashdirt.org/incoming/
<T-Bone> that's the unsigned archive
<zul> should take about 45 minutes for it to build since i removed everything except for 686-smp
<T-Bone> lamont: rsync'able at rsync://rsync.slashdirt.org/incoming
<fabbione> zul: no ccache?
* zul has a p4 3 ghz on his desktop
<zul> nope
<fabbione> zul: time to install it...
<fabbione> it's easy and very fast
<zul> i know cc=ccache gcc
<zul> or something ;)
<fabbione> zul: even simpler than that
<zul> eh?
<fabbione> if [ -d /usr/lib/ccache ] ; then
<fabbione>     export PATH=/usr/lib/ccache:"${PATH}"
<fabbione>     export CCACHE_DIR=/usr/src/.ccache
<fabbione>     export CCACHE_NLEVELS=8
<fabbione> fi
<fabbione> given that you want your ccache in /usr/src/.ccache
<fabbione> ccache -s to see the stats
<fabbione> ccache to see what you can configure
<zul> hmmm...ill have to try that tonight
<fabbione> i use that in my .bashrc
<fabbione> so it is always there and i don't need to bother
<fabbione> just make sure that .ccache is somewhere on a fast disk :-)
<fabbione> the first time you will not notice any difference
<zul> .ccache can be in your home directory correct?
<fabbione> but check the build time the second run :-)
<fabbione> zul: it can be everywhere
<fabbione> it's just a VAR you set
<fabbione> for me ~ would be a loss
<fabbione> since it's nfs shared.. so i prefer local disk
<zul> its not nfs shared for me though so no biggy
<zul> bzImage is ready
<T-Bone> fabbione: ccache wants loads of diskspace/mem, right?
<fabbione> nop
<fabbione> only a bit of diskspace that you can configure
<T-Bone> i wonder if it'd be quite a gain on a buildd
<T-Bone> honestly i doubt it
<fabbione> to be a real gain on a buildd the ccache storage must be big
<T-Bone> i guess so
<T-Bone> currently i can't afford it
<fabbione> but for example vlc takes 1:30 hours to build on sparc without ccache
<fabbione> ccached less than 20 minutes
<T-Bone> that'll cahnge once i'll get my hands on the disk arrays that are coming my way :)
<fabbione> make your numbers...
<T-Bone> doh
<T-Bone> how can that be?
<fabbione> because ccache stores the objects on the disk at the first compilation and re-use them at the second run?
<fabbione> catching all the changes?
<fabbione> and recompiling only what is really needed?
<T-Bone> err
<fabbione> a lookup is faster than recompiling the entire code ;)
<T-Bone> sure
<T-Bone> but it's only useful upon consecutive builds. ie: for it to be worthwhile on a buildd, it'd have to cache the *entire archive's objects*
<T-Bone> something so big I'd rather don't know how big it is :)
<fabbione> T-Bone: that's why i wrote that you need a big cache in a buildd
<T-Bone> heh
<fabbione> but take into account that you have some limitations
<T-Bone> eg?
<fabbione> each time libc or gcc gets updated the entire ccache becomes garbage
<T-Bone> yum
<fabbione> so it is pointless to make the cache too big to contain everything
<fabbione> + you will notice that some huge packages like X that takes like 5GB of disk to build, only uses a few hundred Megs of ccache
<fabbione> even the kernel is ccache is like 100MB or something
* T-Bone wonders how that's possible
<fabbione> T-Bone: because X builds heaps load of extra crap, twice and non-cacheable?
<fabbione> like spending litteraly hours processing fonts in perl?
<T-Bone> schweet
<lamont> ccache -F 2000000 -M 100.0G
<lamont> that's what the buildd's in the DC (that can handle it) have
<lamont> the others use somewhat less - only 10GB of cache
<fabbione> yeah.. except that my sparc buildd is struggling with 2,5GB of ccache
<lamont> roughly 20% of the available disk space
<fabbione> lamont: why do you force -F ?
<zul> whee...buuilding scsi modules
<fabbione> there is no limit to file nums by default..
<lamont> files in cache                    224153
<lamont> cache size                           8.7 Gbytes
<lamont> max files                        2000000
<lamont> max cache size                      10.0 Gbytes
<lamont> that's on my hppa machine
<lamont> fabbione: because the default is way too small :-)
<fabbione> if i don't set -F i don't have max files at all
<lamont> hrm.. ISTR that wasn't always the case... dunno
<fabbione> i really have no idea :-)
<fabbione> but i remember only setting the size
* lamont ^5s fabbione 
* lamont is happyl clue-free about that too.
<fabbione> ehhehe
* T-Bone guesses he'll enable ccache when the two 10x18GB arrays will be there :)
<fabbione> you all suck
<T-Bone> sure :)
<fabbione> i need an external SCSI disk array for my sparc
<fabbione> and i did get none
* fabbione needs one
<T-Bone> i can give you a pile of 4GB disks ;)
<fabbione> T-Bone: i don't really care the size of the HD
<T-Bone> you'll have to build the array by yourself, tho :)
<fabbione> do they have an external disk array?
<T-Bone> alas no
<fabbione> ok
<fabbione> that sucks
<T-Bone> these are raw IBM scsi disks
<T-Bone> if they had an array, i'd have used them :)
<fabbione> http://www.anysystem.com/storedge-t3-660gb.html
<fabbione> something like this would do
<fabbione> :)
<T-Bone> wow
<T-Bone> that's kinda cool indeed :)
<fabbione> yeah
<fabbione> i think i can host both differential and non differential scsi stuff
<fabbione> but i can't remember what is the default in my sparc
<fabbione> in the worst case i have a scsi controller hanging somewhere in a box.. and i am sure it is differential
<fabbione> and.. actually....
<fabbione> hmmmm
<fabbione> it's an ADAPTEC!
<fabbione> i wonder if the ahc_dv process starts without any device connected....
<T-Bone> lol
* fabbione must do a hardware inventory list
* T-Bone finds the stats output of buildd rather strange "building time: 0%, idle time: 0%"
<T-Bone> i wonder what that bitch has been doing all the time then :)
<fabbione> ok i am off for the evening
<fabbione> lamont, mdz: please drop me a mail if you are going to upload -30 or you want me to do it tomorrow when i wake up
<zul> fabbione: ok ill put the .ko on my webpage for the users to test
<fabbione> zul: fine by me
<zul> and if they are ok ill put it in my archive or you can just grap the copy on the page as well
<fabbione> ok thanks
<fabbione> zul: make my life simpler.. merge from branch so that i can easily merge from you
<zul> pl
<zul> doh..ok
<fabbione> all this merging is a bit work of work for everybody, but it makes everything simpler at the end
<fabbione> good night everybody
<zul> night
<zul> whee...its linking now
<T-Bone> kylem: Finished at 20050323-2132
<T-Bone> Build needed 05:23:49, 909288k disk space
<T-Bone> that was linux-source
<kylem> hate you so much. :)
<kylem> i need to compare our .config
<T-Bone> ;)
<T-Bone> i told you I/O were *fast* on that machine :)
<kylem> i just started build-64-smp
<T-Bone> you just can't fight :)
<T-Bone> kylem: they'll be available soon at the incoming URL i posted before
<kylem> i think my /home disk is only FAST-20 for some reason.
<kylem> T-Bone, heh, mine is a dual 550MHz too...
<T-Bone> here it's FAST-20 WIDE 40MB/s
<T-Bone> two 9GB disks. RAID-0, XFS
<T-Bone> and it's dual 440MHz
<T-Bone> so you *really* suck 8)
<T-Bone> and most of the build happened single threaded too :)
<T-Bone> err
<T-Bone> i can't believe there's been *yet another glibc upload today*
<T-Bone> sigh
<zul> yay ers use somewhat less - only 10GB of cache
<zul> fabbione yeah.. except that my sparc buildd is struggling with 2,5GB of ccache
<zul> lamont roughly 20% of the available disk space
<zul> doh..
<kylem> T-Bone, my build is entirely single threaded.
* T-Bone guesses he wants to kill jbailey :)
<mjg59> fabbione: Yo?
<jbailey> T-Bone: Careful.  It's the fact that I did the source build on glibc that caused the need for the second upload...
<T-Bone> glibc takes about 3h to build. I wonder why it's not "-j" enabled
<jbailey> err.
<jbailey> ia64, I mean.
<jbailey> T-Bone: It is.
<T-Bone> /usr/bin/make -C build-tree/hppa-libc -j 1 2>&1 | tee -a /bu
<T-Bone> jbailey: "-j1" heh? :)
<T-Bone> how threaded is that?
<T-Bone> ;)
* jbailey lart thibaut
* T-Bone larts jbailey back, asking for explanation :)
<jbailey> NJOBS:=$(shell getconf _NPROCESSORS_ONLN 2>/dev/null || echo 1)
<T-Bone> jbailey: next time you do a glibc upload, remove the arch indep files from binary arch :)
<T-Bone> ~$ getconf _NPROCESSORS_ONLN
<T-Bone> 2
<jbailey> Then trace the setup in your chroot or something.
<T-Bone> $ sudo chroot-hoary getconf  _NPROCESSORS_ONLN
<T-Bone> sudo: chroot-hoary: command not found
<T-Bone> err
<T-Bone> my bad
<T-Bone> $ sudo chroot chroot-hoary getconf  _NPROCESSORS_ONLN
<T-Bone> 2
* T-Bone double larts jbailey 
<T-Bone> with 2 online CPUs, i can lart you in parallel :)
<zul> right i have to go move furniture back tonight
<jbailey> T-Bone: *lol*
<jbailey> T-Bone: So why is it detecting only one processor for you? =)
<T-Bone> jbailey: building glibc was threaded on warty chroot, so something's fucked up
<T-Bone> jbailey: if you want to look at the ongoing build log to figure out: http://buildd.slashdirt.org/logs/glibc_2.3.2.ds1-20ubuntu12_20050323-2133
<jbailey> There's nothing a build log would tell me - It's all what variables are set when.
<T-Bone> well
<T-Bone> # How many makes to run at once?
<T-Bone> NJOBS = 1
<T-Bone> from glibc-2.3.2.ds1/debian/rules
<T-Bone> i guess that answers the question?
<jbailey> T-Bone: Right, but the various things from debian/sysdeps are pulled in after that.
<jbailey> NJOBS has to have a default, since we can't use this getconf on non-Linux
<jbailey> If you look in sysdeps/linux.mk, you'll see the detection code.
<T-Bone> NJOBS:=$(shell getconf _NPROCESSORS_ONLN 2>/dev/null || echo 1)
<T-Bone> ifeq ($(NJOBS),-1)
<T-Bone>  NJOBS:=1
<T-Bone> endif
<T-Bone> ifeq ($(NJOBS),0)
<T-Bone>  NJOBS=1
<T-Bone> endif
<T-Bone> NJOBS:=1
<T-Bone> somehow i have the feeling that this is *utterly* stupid :)
<T-Bone> note the ending "NJOBS:=1"
<T-Bone> jbailey: i guess *that* answers the question :)
<jbailey> wtf?
<kylem> get shuttleworth to buy a superdome and just run make -j ;-)
<T-Bone> kylem: lol
<lamont> T-Bone: you do have /proc mounted in the chroot, yes?
<lamont> (and /dev/pts)
<T-Bone> jbailey: that's exactly what i'm asking you :)
<T-Bone> lamont: yes
<T-Bone> lamont: i just pointed that the build will never be threaded anywhere, no matter what
* lamont finally catches up on reading things
<T-Bone> btw i'm doubtful about the "NJOBS=1" in the second if case
* T-Bone wonders if he can larts -j jbailey :)
<jbailey> T-Bone: Sure, but only -j 1 apparently. =)
<jbailey> You mean if it comes back as 0?
<jbailey> Given that you're unlikely to have 0 processors online and still succesfully execute the instruction, 1 seems like a safe fallback. =)
<T-Bone> jbailey: i think it should be "NJOBS:=1" instead of "NJOBS=1" for consistency reason. But that's not the cause of what we're seeing
<T-Bone> though i wonder if someone fucked up willing to change exactly what I just said, and wrote the change *outside* the if case
<T-Bone> jbailey: so for ubuntu13, remove arch indep from binary arch target and GET IT TO BUILD THREADED, dammit :o)
<jbailey> First I want to know why that NJOBS:=1 is in there.  I don't see a refernece to it in the changelog.
<T-Bone> i'm pretty sure that's someone's local change that went into mainline :)
<T-Bone> anyway, off for dinner, bbiab
<T-Bone> gah
<T-Bone> so you guys just uploaded glibc again :P
<jbailey> Right with the bug fixed.
* T-Bone kills current build
<jbailey> Current build?
<T-Bone> ubuntu12 on my builder
<jbailey> ia64?
<T-Bone> hppa
<T-Bone> why would i build ia64?
<jbailey>  thought you ran the autobuilder for it.
<T-Bone> hell
<T-Bone> no
<T-Bone> it's in DC
<jbailey> Is hppa a target for Breezy?
<T-Bone> my business is hppa you see
<T-Bone> i don't know
<T-Bone> hppa is a target for me, that's a good beginning :)
<jbailey> If it is, it's incentive for me to setup the hppa box here.
<T-Bone> dude
<T-Bone> have you been sleeping on this chan and #parisc lately?
<T-Bone> ;P
<jbailey> #parisc, yes.
<T-Bone> we've discussed at length that topic on #parisc
<jbailey> This channel?   Maybe. =)
<T-Bone> it eventually gave birth to http://ubuntu-hppa.pateam.org/
<T-Bone> (which is currently rather empty, but I'm trying to improve it as much as possible. Contribution welcome)
<jbailey> I remember the Vancouver proposal coming up in #parisc, but it doesn't look like there's nay reason why it shouldn't be a full arch, so I didn't follow it after that.
<T-Bone>    * debian/rules.d/control.mk: Mark debian/control target as phony.
<T-Bone> that's supposed to fix the parallel build issue?
<T-Bone> jbailey: then you haven't read your mails carefully enough
<T-Bone> hppa is planed for removal from etch
<jbailey> On what grounds?
<T-Bone> not enough builders
<T-Bone> not enough downloads
<T-Bone> and all kind of crap alike
<jbailey> Hmm, not enough downloads I can see, I guess.
<jbailey> No, the issue wasn't parallel build, the issues was fubar depends from a race condition.
<kylem> i think "not worth the release teams time"
<T-Bone> jbailey: if you've looked at the requisite for an arch to be part of etch, you'd noticed that *only* i386 can make it
<kylem> don't worry, if nobody else does, i will do stable releases for etch for hppa.
<T-Bone> amd64 and ia64 have been "exempted" of a few prerequisites
<jbailey> Since I did the original build on ia64, libc6-i686 depended on libc6.1 =)
<T-Bone> jbailey: ok. So it will still build single threaded?
<jbailey> T-Bone: Yes, dear.
<T-Bone> schit
<jbailey> T-Bone: The issue -j issue isn't important enough to have me risk breaking it when I don't know why the change went in in the first palce.
<T-Bone> i can imagine
<T-Bone> kylem: you're into self-inflicted pain, aren't you? :)
<kylem> no.
<T-Bone> doing QA release of etch looks much to me like you're in it, tho :)
<kylem> meh.
* jbailey tried to remember where Kyle works.
<jbailey> T-Bone: Perhaps it's inflicted by others. =)
<kylem> jbailey, i don't work at all.
<T-Bone> he's a darn student :)
<jbailey> Ah, lucky.
<kylem> not really. i work full time and get nothing out of it. :)
<jbailey> I'm going to spend a bunch of this weekend on my universitiy stuff.  I'm so behind. =)
<kylem> "work" rather.
<jbailey> kylem: I'm doing my degree by distance ed, and wish I could afford to take the time off to go to school.
<kylem> jbailey, *nod* i was thinking about finishing part time, but it would just take too long.
<T-Bone> mv: cannot stat `chroot-hoary/build/buildd/linux-headers-2.6.10-5_2.6.10-29_hppa.deb': No such file or directory
* T-Bone wonders
* T-Bone guesses that's harmless since the package successfully built anyway
<mdz> the snd-via82xx change does not resolve my problem
<mdz> well, not entirely
<mdz> I don't seem to be getting the crash I was getting before, but that didn't always happen anyway
<mdz> but it still behaves in the same way
<T-Bone> Build daemon statistics from 19700101-0100 to 20050322-2050 (12864.83 days) <- must be the oldest buildd ever run ;)
<mdz> when I play a sound, it repeats indefinitely
<mdz> any information I should collect before I go back to irqpoll mode?
<mdz> ok
<T-Bone> ok ok
<T-Bone> well, it's time for me to say goodbye
<T-Bone> i'll have a quick look at the backlog tomorrow morning but then I won't be back until next wednesday. Will read email tomorrow until 1700 CET, then no net access. Vacation rulez! :)
<mjg59> I need to go out - can someone point mdz at http://seclists.org/lists/linux-kernel/2005/Mar/6078.html ?
#ubuntu-kernel 2006-03-27
<zul> heylo
<childe> Hi, do I need a debug kernel to use addr2line?
<childe> Where can I get a debug kernel to use with addr2line?
<zul> heylo
<mjg59> BenC: Any chance you could pick up the patches that dwmw2 has been posting to the bcm43xx mailing list?
<Keybuk> BenC, mjg59, Mithrandir, etc.: just had a thought;  ProbeForRootFilesystem won't work with lvm/md/evms/etc.
<mjg59> Keybuk: Mm?
<Keybuk> no /dev/disk/by-uuid for those
<fabbione> great thinking :)
<fabbione> same as i had when we discussed by-uuid at UBZ :P
<mjg59> Keybuk: Don't lvm and md and uuids on the partitions?
<Keybuk> mjg59: we'd end up mounting the actual partition, not the volume group
<mjg59> Keybuk: ?
<mjg59> I mean, don't they have uuids to signify which disks are parts of which sets?
<Keybuk> no idea
<mjg59> Which is how the old autostart stuff worked
<Keybuk> none of them are new-world-order-compliant (they make their own device nodes)
<mjg59> Sorry, I'm (again) not seeing what awkwardness this leads to
<Keybuk> well, they only exist as /dev/dm/blahblahblah
<Keybuk> no /dev/disk/by-uuid/* for it
<mjg59> Oh! You mean the kernel is just being shit?
<Keybuk> so it's a whole class of filesystem we can't do mount-by-uuid for
<Keybuk> right
<mjg59> Rather than there being any fundamental problem. Right, ok.
<Keybuk> yeah, it doesn't block uuid for anything else
<mjg59> But the aim of having uuids for fs mounting is only because there's the potential for the device nodes to change, which isn't true for lvm and so on
<Keybuk> I have lvm and friends
<Keybuk> hate
<Keybuk> not have
<Keybuk> H A T E
<Keybuk> I wish to rupture their collective colons with my engorged genetalia
<fabbione> Keybuk: get them right.. we are going to have a lot of -server installs on raid/lvm :)
<Keybuk> fabbione: I've so far avoided touching them at all
<Keybuk> which in theory means they have a better chance of working than anything I do touch <g>
<fabbione> Keybuk: i know.. i mean.. don't break more than it is now ;)
<Keybuk> I think it broke because of the mods made to initramfs this morning post the ide-generic discussion
<Keybuk> I made the "wait" critical path for everything
<Keybuk> rather than just definitely-scsi-subsystem stuff
<Keybuk> so suddenly we waited for /dev/device-mapper or /dev/dm/ or whatever to turn up ... before we ran lvm, evms, etc.
<Keybuk> I've moved the wait to local-top so it comes after those now
<fabbione> Keybuk: ok.. it's installing right now the ubuntu21
<fabbione> from people..
<fabbione> Keybuk: rebooting right now
* fabbione gets ready to enjoy 4 seconds of silence
<Keybuk> AWOOOOOOOOOOOOOOOOGHA!
<fabbione> Keybuk: it's still waiting
<fabbione> Begin: Mounting root file system... ...
<fabbione> Begin: Running /scripts/local-top ...
<fabbione> Begin: Waiting for root file system... ...
<Keybuk> hmm
<Keybuk> that's odd
<Keybuk> it fiiixed it for hunger
<Keybuk> console me up, I guess
<fabbione> Keybuk: sure.. just a minute
<fabbione> i want to get my snack first
<Keybuk> I think I'll probably just put that while loop into initramfs itself
<Keybuk> because it is the sux0r
<Mithrandir> BenC: do you have a useful way to track down why a kernel fails to boot without acpi=off?
<Ju> Hi all !
<Ju> I'm on dapper and uname -v gives me : #1 SMP PREEMPT  I didn't ask for a smp enabled kernel, linux-image-686 only here (is it the good place for this question ?)
<mjg59> Ju: That's fine
<mjg59> On a single CPU system, the SMP instructions will be rewritten
<Ju> there won't be any loss of performance, even small ? (for my personnal info)
<mjg59> Nothing that can be measured, no
<Ju> so package x and x-smp will merge ?
<mjg59> Yes
<Ju> ok great, thanks for the info
#ubuntu-kernel 2006-03-28
* netjoined: irc.freenode.net -> brown.freenode.net
<doko> how are device files for the parallel interface named?
<Keybuk> do you mean the old-fashioned parallel port?
<doko> Keybuk: yes, /dev/parportN
<Keybuk> there isn't a device for those, is there?
<doko> sure, but there should be one?
<Keybuk> I doubt it
<Keybuk> do you see computers with them these days?
<doko> at least MAKEDEV had support to create these device files
<Keybuk> really?
<doko> dude, every thinkpad has a parpart ...
<Keybuk> I always thought you just talked to parallel ports directly via io, rather than through a device file
<doko> >>> import parallel
<doko> >>> p=parallel.Parallel()
<doko> Traceback (most recent call last):
<doko>   File "<stdin>", line 1, in ?
<doko>   File "/usr/lib/python2.4/site-packages/parallel/parallelppdev.py", line 186, in __init__
<doko>     self._fd = os.open(self.device, os.O_RDWR)
<doko> OSError: [Errno 2]  No such file or directory: '/dev/parport0'
<Keybuk> ok
<Keybuk> loading the parport and parport-pc modules doesn't create that device
<doko> yes
<Keybuk> seems nobody's bothered to driver-core them
<mjg59> Mm?
<mjg59> Don't they appear as /dev/lp0?
<Keybuk> that's a parallel printer
<Keybuk> which is the "lp" driver
<Keybuk> not raw parport access
<mjg59> Ah, yes, that does assume a printer
<Keybuk> mjg59: err @ your bug reassign
<Keybuk> where does the docs say rmmod is the same as modprobe -r
<Keybuk> all the docs say you should use modprobe -r as its better
<infinity> Keybuk: So, when you changes how root mounting works in initramfs-tools, did you break LVM along the way?
<infinity> Keybuk: There seems to be some murmuring to that effect.
<Keybuk> I did, yes
<Keybuk> I fixed it again though
<Keybuk> the upload to initramfs-tools is the fix, not the cause
<Keybuk> (worth an explanation)
<infinity> Indeed..
<Keybuk> we worked out, thanks to mjg59's knowledge of strange things called "reserved regions" that once a SATA driver was loaded there was no way ide-generic could steal the devices
<Keybuk> when I'd investigated I was looking as to when udev got the "ADD /dev/sda" event, which is some time later
<mjg59> Keybuk: Yeah, my mistake
<Keybuk> so we were able to do away with the "if ide do this, if scsi do that" branching code in udev
<Keybuk> and thus we can mount root filesystems with:
<Keybuk> - load PCI drivers
<Keybuk> - load ide-generic
<Keybuk> - wait for up to three minutes for root to appear
<Keybuk> PCI IDE drivers it'll appear instantly, so it won't wait
<Keybuk> ide-generic will be a no-op if a PCI driver was loaded
<Keybuk> if ide-generic runs the device, it'll appear instantly, so it won't wait
<infinity> Didn't we have some bizarre race in the past when doing it that way?
<Keybuk> for SATA drivers the driver will reserve the regions immediately so ide-generic won't break it, but it'll be a few seconds before udev gets the real "device add" events (which we wait for)
<infinity> I vaguely recall my /dev/sda being /dev/hda on 3 out of 4 boots...
<Keybuk> for SCSI drivers we get the devices after waiting for a few seconds
<Keybuk> three minutes is a good upper limit on any device waiting
<Keybuk> right
<Keybuk> we had a bug certainly, but that has gone away
<Keybuk> and that was partially caused by an old kernel patch which I removed
<infinity> Ahh, well that's nice to know.
<Keybuk> and the fact we loaded ide-generic *first*
<Keybuk> we had a strange patch on our kernels that made loading ide-generic mandatory to get any PCI IDE driver to actually probe
<Keybuk> rather than just probing in the PCI IDE drivers
<infinity> Special.
<Keybuk> ok
<Keybuk> so I modified udev to do the above sequence
<Keybuk> and all was good
<Keybuk> except for LVM, EVMS, MD, etc.
<Keybuk> which suddenly would "hang for three minutes" on boot
<Keybuk> the fact they didn't before was actually a bug :)
<Keybuk> and I fixed that bug when I rewrote the udev initramfs script, which made them break
<Keybuk> they should have been breaking all through dapper
<Keybuk> the bug is obvious; doing the three minute wait in the udev init-premount means that evms/lvm/etc. haven't been run yet (they're run in local-top)
<Keybuk> so we're waiting for a root device to appear before running the magic that makes it
<infinity> Right.
<Keybuk> I thought about putting the wait in a udev local-top script, but couldn't get PREREQS to play nice (it's not possible to "DEPEND ON EVERYTHING")
<Keybuk> and if you depend on something that doesn't exist, your script never gets run and initramfs goes into infiniloop territory
<infinity> You could prereq *, perhaps.
<makx> yeah that's a bug
<Keybuk> I couldn't put it in local-premount because that's after mountroot() has already panic'd
<infinity> Or something equally fucked up.
<Keybuk> infinity: I tried that :p  you can't
<infinity> But I'm pretty sure it wasn't designed to be used that way. :)
<Keybuk> then I realised, that that loop code should be in mountroot() anyway
<infinity> I could rewrite it to work that way, but icky corner case.
<infinity> And yeah, it's better living in mountroot()
<infinity> Debian may appreciate that change too.
<Keybuk> so mountroot() now runs local-top, loops for up to three minutes to wait for the root to appear, then if it still hasn't appearered, loops calling panic to let the user fix it, and then carries on
<Keybuk> for dapper+1 we can think about changing it to loop forever with a pretty message asking the user to insert the damned root filesystem, or press any key to get a shell, or something
<Keybuk> tbh
<Keybuk> for initramfs-tools, I'd rather get rid of PREREQS and just use run-parts and NN-* like everything else <g>
<infinity> I don't like magic shell for dependencies either.
<Keybuk> anyway
<Keybuk> this should fix all occurances of the bug
<Keybuk> as now we have
<Keybuk> - probe for PCI devices
<infinity> Not everything about Jeff's code gives me warm fuzzies, just enough to work on it. :)
<Keybuk> - load ide-generic
<Keybuk> - run evms, lvm, md, etc.
<Keybuk> - wait for root to appear
<Keybuk> - mount root
<infinity> Rock.  Thanks, dude.
<infinity> These little bugs have been biting us since dapper opened.
<Keybuk> it actually makes the boot a bit cuter too, because 9/10 now your scsi card gets its act in gear while initramfs is working up to getting to mounting the root
<makx> the fixed revsion of initramfs-tools is -25?
<infinity> makx: Any chance of shoving the udev side of these changes down Md's throat, so you can make the initramfs changes to match ours?
<infinity> makx: Yes, 24-25 would be the patch Scott did, then obviously, his new udev hooks are important to go with it.
<makx> haven't looked at the udev changes.
<makx> infinity: atm i work around Md with udev_helper which prequs udev
<infinity> (And make sure Debian's kernels don't have that buggy behaviour mentioned above with ide-generic)
<makx> which is suboptimal
<Keybuk> ubuntu20->ubuntu21
<Keybuk> infinity: Debian's kernels probably still do, because that's where we got the patch
<Keybuk> it was a Xuism
<Keybuk> something to do with making the old initrd "load every PCI driver" stuff less icky
<makx> na it got dropped since 2.6.14
<Keybuk> ok
<Keybuk> actually, you want udev ubuntu19->ubuntu21
<infinity> makx: Well, just from reading the description on IRC (haven't looked at the hooks yet), Keybuk's new udev hook is probably a fair bit simpler than before, so maybe Md wouldn't be too unhappy to include it.
<makx> cool i'll take a look in some hours, will work on that.
<makx> thanks
<mjg59> BenC: Do we have anything other than bcm43xx using softmac yet?
<BenC> not that I know of
<infinity> Keybuk: Ahh, yes, init-premount/udev looks MUCH cleaner now.  Awesome.
<mjg59> Ok, cool
<infinity> Keybuk: Also, usplash_write calls don't need a || true on them, it exits zero even if your computer's on fire.
<Keybuk> heh, everything else does || true
<infinity> Yeah, not sure who to blame for the first || true. :)
<mjg59> BenC: You have patches
<BenC> patches!? we don't need no stinkin' patches!
<mjg59> They ought to be enough to get bcm43xx to work nicely without hacky scripts
<infinity> BenC: when do you want to co-ordinate the ipw3945 junk?
<BenC> infinity: I think I'll just do the lrm end of it too, I need to add fwcutter aswell
<infinity> Ahh, cool, all you, then.
<mjg59> BenC: No joy with negotiating bcm43xx firmware?
<infinity> fwcutter can go in LRM-common (which will need to become arch:any, I assume, unless it's a script), but the ipw3945 daemon appears to be versioned with the kernel module, so it should go in lrm-`uname -r` to keep lockstep (and the binary will need to be versioned on the filesystem)
<infinity> BenC: If you'd prefer I do any of it, just poke me.  LRM and I are close personal friends (or enemies) at this point.
<mjg59> The sooner we get the 3945 stuff in, the sooner we actually start getting bug reports about how broken it is
<infinity> makx: What problem, exactly, did you have with moving the module lists to files?  I just tried it and it went smashingly...
<BenC> mjg59: none so far
<infinity> mjg59: Is that assuming someone has the hardware in their grubby little hands already?
<mjg59> infinity: Oh, people /do/
<makx> infinity: creation time of initramfs
<mjg59> BenC: Yeah, that's because we're not shipping it...
<makx> was 1/2 longer
<infinity> makx: I get no slowdowns here... You must have been doing something scary weird...
<BenC> mjg59: no I meant no luck with bcm43xx firmware
<mjg59> BenC: Oh, right
<makx> infinity: ok cool
<infinity> makx: Perhaps you've been too heavily influenced by jbailey's shell. ;)
<mjg59> BenC: Shame
<mjg59> Wonder if I can get it out of the Broadcom UK people (who are all embedded MIPS)
<infinity> mjg59: ISTR suggesting that once before...
<infinity> The MIPS folk are very friendly with Debian, at any rate.
<mjg59> I'll ask tbm about it
<mjg59> He's been in touch with them before
<infinity> Yes, he has a machine or two from them.
<infinity> I wouldn't mind one myself.
<Keybuk> infinity: random thought ...
<Keybuk> we could split the udev script even further
<Keybuk> start udevd, and probe for existing buses in init-premount
<Keybuk> then move the local code to local-premount
<Keybuk> and the network code to nfs-premount
<Keybuk> or something
<infinity> Yeah, when looking at your switch on $BOOT, I was noting you could do that.
<Keybuk> (actually, probably nfs-top and init-top)
<infinity> Not that it would make much difference, it would just seem "cleaner"
<infinity> OTOH, if it's working how it is now, why break it again? :)
<Keybuk> cleanliness? :p
<Keybuk> it'd fix the bug where if you change the boot options on the kernel command line, udev ignores it
<infinity> Next to godliness, I hear.
<Keybuk> (it gets $BOOT by reading conf/initramfs.conf)
<infinity> Oh, really?  Yeah, that's kinda icky, then.
<infinity> By all means, muck with your stuff how you want.  They're your hooks. ;)
<Keybuk> infinity: "while I was in there" ...
<Keybuk> I moved the lvm and md scripts to lvm-common and mdadm
<infinity> Gar.
<Keybuk> Gar?
<infinity> Our uploads collided.
<Keybuk> lol
<Keybuk> what did you upload?
<infinity> And soyuz happily accepted both.  AWESOME.
<infinity> Go soyuz!
* infinity wonders which one will win.
<Keybuk> yeah, it does that
<infinity> Clearly it has a different concept of "ACCEPT" than katie does...
<Keybuk> I think whichever one gets mailed second wins
<infinity> That would be me, then.
<infinity> I wasn't going to move the lvm and md stuff until Debian did, but I don't mind seeing it go either. :)
<Keybuk> I long ago gave up "waiting for Debian" :p
<Keybuk> actually, it was about the time I resigned from Debian
<Keybuk> lol
<infinity> I assume lvm-common and mdadm have appropriate Replaces: on them?
<Keybuk> they do
<infinity> (Of course, the Replaces will now be wrong..)
<Keybuk> I found that if we do stuff for them, it gets into Debian quicker
<Keybuk> lol
<infinity> (Cause my version still has those scripts)
<Keybuk> actually, one of them will be right
<Keybuk> because I mucked up the Replaces
<Keybuk> LOL
* infinity laughs.
<infinity> Right, well you may as well bang up new uploads with fixed Replaces, and then we can yank the scripts AGAIN.
<Keybuk> who wants to make a 28 with the right things?
<Keybuk> do you want to, or shall I?
<infinity> 27, even.
<Keybuk> 27?
<Keybuk> you want to upload a THIRD 27? :p
<infinity> Unless you're skipping one out of deference to the one that got lost in the queue. :)
<Keybuk> or did we both upload clashing 26s?
<infinity> We did 26. :)
<Keybuk> ahh
<Keybuk> I did a 27 seconds later
<Keybuk> well, minutes later
<Keybuk> Accepted:
<Keybuk>  OK: initramfs-tools_0.40ubuntu27.dsc
<Keybuk>      -> Component: main Section: utils
<Keybuk>  OK: initramfs-tools_0.40ubuntu27.tar.gz
<infinity> Oh, so I need a 28 with my changes? :)
<infinity> Rock.
<infinity> I'll do that when yours beats mine, then. :)
<infinity> FUN GAME.
<Keybuk> ok
<Keybuk> http://people.ubuntu.com/~scott/packages
<Keybuk> that has my 0.40ubuntu27 source
<Keybuk> grab that, add your patch, then upload a 28
<Keybuk> and see if we can get four accepteds for the same daily run <g>
<zul> gday..
<zul> BenC: new patch for you i sent in email..
<BenC> zul: ok
<zul> im not dead yet...just resting ;)
<zul> oops...it bounced
<Keybuk> infinity: what is the NM patch to madwifi?  does that make it support background scanning?
<infinity> Sadly, no, just WPA extensions.
<infinity> Background scanning would probably be an unwieldly backport, although the NM keeners are looking into it.
<infinity> (I've not even tried to find the bits required)
<infinity> Also, our ubuntu26 uploads got under the wire for the last cron.daily, so we didn't get 4 in one cycle.. *sad*
<infinity> (That also means that my ubuntu26 is building right now... Or yours.. One of them)
<infinity> In the end, looks like mine won. :)
<crimsun> BenC: pong
<BenC> crimsun: unping, current patches fixed hda problems that people were seeing
<Keybuk> In Soviet Distro ... Soyuz accepts you!
<crimsun> BenC: ok. Were these the sigmatel or realtek folks?
<crimsun> ah, analog
<BenC> zul: already got the patch in
<zul> BenC: ok good to know
<BenC> mjg59: Can you look at https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/33704
<BenC> mjg59: User claims his amd64 system wont boot unless he removed the ATI IO-APIC block from you (timer pin fixup)
<mjg59> BenC: Yes, some newer BIOSes "fix" it in a way that breaks that
<mjg59> We should revert my fix and go to the one used in 2.6.16
<mjg59> Hang on, I'll dig it out
<BenC> ok
<dilinger> hm
<dilinger> BenC: so davem claims he's got silo booting from iso9660 on the sunfire 280 i sent him
<BenC> dilinger: as far as I know silo 1.4.11 contains all the fixes needed
<dilinger> BenC: cool, ok
<dilinger> BenC: hm, is there a changelog anywhere or anything?  i'm curious what the actual fix involved?
<BenC> there's a subversion repo
<BenC> svn.sparc-boot.org
<dilinger> s-b.o/websvn is a 404
<dilinger> what's the full path for the repo?
<BenC> that's not an http url
<BenC> it's svn:// url
<dilinger> yea, i tried that
<dilinger> svn: PROPFIND of '/': 405 Method Not Allowed (http://svn.sparc-boot.org)
<BenC> svn co svn://svn.sparc-boot.org/silo/trunk silo
<dilinger> thanks
<fabbione> dilinger: yes.. i got the iso to boot here too on the netra
<mjg59> BenC: More network drivers for you
<mjg59> (You love it really)
<mjg59> BenC: And there go the apic fixes
#ubuntu-kernel 2006-03-29
<BenC> mjg59: thanks, however the x86_apic.diff was empty
<mjg59> Hm.
<mjg59> Ok, resent
<BenC> mjg59: do I need to backout your old patch before applying these?
<mjg59> BenC: Yup
<BenC> ok, thanks
<mjg59> Oh, hang on
<mjg59> No
<BenC> ok
<mjg59> Just apply them as is
<mjg59> (I think)
<mjg59> The guy with the softmac prism54 vanished before he could tell me what the firmware needed to be called
<BenC> I'm talking about the ioapic patches
<mjg59> Yeah
<mjg59> I was just mentioning my caveat in the other mail :)
<BenC> so the disable_timer_pin_1 thing for ATI remains?
<BenC> ah, ok
<BenC> I can check the driver file to find that out
<mjg59> BenC: disable_timer_pin_1 should still be there (it can be set on boot), but it shouldn't automatically be set anywhere now
<mjg59> Instead timer_over_8254 gets set to 0
<mjg59> It's actually the inverse of my original patch
<BenC> ok, so I need to backout the patch that does that for ATI
<mjg59> The one I provided ought to do that
<mjg59> -                                               disable_timer_pin_1 = 1;
<BenC> yeah, it does
<BenC> I wasn't looking at the x86_64 one, my mistake :)
<mjg59> Heh
<Keybuk> I HATE NETWORK MANAGER
<Keybuk> that is all
<Keybuk> :p
<mjg59> I'd been getting that impression...
<mjg59> What's up with it now?
<Keybuk> won't play WPA
<Keybuk> something about NM, WPA and madwifi causes unhapiness
<Keybuk> I think it's not getting the message that it WORKED
<Keybuk> so it keeps blacklisting and retrying
<Keybuk> while the AP log says "Associated"
<mjg59> Hm.
<mjg59> I'm sure I've seen other people bitching about that.
<mjg59> rml sent a patch to the list last week, IIRC
<Keybuk> yeah lots of bitching, no working
<Keybuk> I checked the list and we have all the patches
<Keybuk> without the patch rml sent, even non-WPA doesn't work
<Keybuk> (because wpa_supplicant fouls up the association, I assume)
<mjg59> Right
<Keybuk> at least normal and WEP work right now
<mjg59> And you can connect just using wpa_suppository?
<Keybuk> so I've declared success and uploaded it
<Keybuk> yup
<mjg59> Fun
<mjg59> Probably some exciting timing issue
<Keybuk> stuck wpa-driver madwifi, wpa-ssid linksys, wpa-pks blahblah in /etc/network/interfaces and that just works
<mjg59> Never mind. You've got more broken patches to look forward to.
<Keybuk> so don't think it's a suppository issue
<Keybuk> indeed
<mjg59> Ah. For an equivalent test, shouldn't you be using the wext driver?
<mjg59> Or does nm hardcode it to madwifi?
<Keybuk> wext doesn't work at all
<Keybuk> one of rml's patches it to use madwifi
<Keybuk> without that one, it fails to associate to any AP
<mjg59> Right
<mjg59> Well, my only madwifi card is in London right now
<Keybuk> tomorrow I'll get around to installing Umbungo on my Powerbook and test it on that
<Keybuk> eek out a whole new world of corner case pain
<mjg59> How recent is the powerbook? Airport or express?
<Keybuk> neither
<mjg59> Ah
<Keybuk> pcmcia wireless card
<mjg59> Ancient :)
<Keybuk> Cheap :)
<mjg59> Hmm. I worry about the way that the madwifi tree in the prism54_softmac driver source appears to have been mutilated to look like ieee80211_softmac
<mjg59> In a "Does this thing actually work with the in-kernel stack?" sort of way
<Keybuk> heh
<mjg59> Well, it /loads/ with it
<mjg59> But I don't have the hardware to test
<mjg59> Fuckit. We'll see who complains.
<mjg59> I'm getting really irritated with people bitching that us shipping a proper bcm43xx driver has broken their ndiswrapper setup
<mjg59> BenC: Did that set of bcm patches I sent you apply ok?
<mjg59> They ought to get things a lot closer to working out of the box, rather than requiring precise timing...
<mjg59> The driver exports a number of sysfs interfaces in
<mjg59> /sys/class/islsm/$(DEVICE)/
<mjg59> HNGH.
<mjg59> I'm fairly sure that's not the correct approach.
<Keybuk> evil
<Keybuk> nothing under /sys/class/net ?
<mjg59> Oh, probably
<Keybuk> if islsm are the "upper" devices, that's not so bad
<Keybuk> a whole subsystem just for one driver
<mjg59> Yeah
<Keybuk> wooo
<mjg59> It's just so you can tweak some values per-interface
<mjg59> Which I thought you could do by sticking stuff under the per-device sysfs stuff /anyway/
<mjg59> Since ipw* seem to manage it
<mjg59> Ok, looks like it has been ported to softmac
<mjg59> Hurrah
<BenC> yay, my unread bug email list is below 100!
* lamont notes that the pedants among us would say that the __d_path call in fs/dcache.c sys_getcwd() should use PATH_MAX, not PAGE_SIZE
<zul> heylo
<hub> hi guys, apparently the PPC kernel does not provide the old iBook clamshell or PowerBook G3 modem
<hub> while there is a kernel module in the tree
<hub> (used to be in older version)
<hub> has it just been forgotten?
<infinity> please file a bug at launchpad.net/malone (package: linux-source-2.6.15) and mention the module that's gone missing.
<infinity> BenC will no doubt attack it with vigor when he's around.
<hub> okay. I just wanted to make sure that it was not on purpose
<hub> a bug will be filed, off course
<infinity> We don't tend to remove many drivers on purpose. :)
<infinity> But when we switched to 2.6.15 and upended the packaging completely, some stuff got dropped on the floor, lost, forgotten, etc.
<hub> I know
<hub> but sometime it is
<hub> I understand
<hub> no problem
<infinity> Also, xandros.com.  Nice.
<infinity> Don't let anyone from the dccalliance know you're running the evil ubuntu. :)
<hub> infinity: they know that. I wear ubuntu t-shirt, and I run ubuntu/gnome on my laptop
<hub> that is the one I'm typing from atm
<infinity> :)
<infinity> Even I don't wear Ubuntu t-shirts, and I get 'em for free...
<infinity> Though maybe that's why I don't wear them.
<infinity> I don't wear any of my free Microsoft or IBM t-shirts either.  Could be a pattern.
<hub> infinity: I have a t-shirt of my former company atm. it is sort of a competitor
<hub> I don't wear MSFT t-shirt because I don't want any
<mjg59> infinity: I'll wear the brown one when I get low on them, but that's because it's actually a good t-shirt
<infinity> It is rather nice fabric, yes.  Sadly, I popped mine in the dryer without turning it inside out first, and the logo got a bit melted.
<infinity> Whoops.
<mjg59> Nf. Must tidy my room.
<mjg59> Maybe I'll also try to fix vga16fb on the craptop
<hub> mjg59: uh oj vga16fb. was a topic around at the office
<hub> infinity: I only have on whit t-shirt that I got at ubz
<hub> filed bug 36499
<hub> for the pmac modem
<mjg59> hub: Yeah, I brought it up on dcc-devel
<mjg59> (due to ACPI not working too well with non-vga16fb)
<hub> yeah, pat told me that
<hub> I don't read the dcc mailing list
<hub> c'ya
#ubuntu-kernel 2006-03-30
<angeliang>  anyone having problem when tried to recompile gtk+?
* #ubuntu-kernel  [freenode-info]  channel trolls and no channel staff around to help? please check with freenode support: http://freenode.net/faq.shtml#gettinghelp
<mulima> hi
<mulima> anyone could tell me if this patch is natively included in ubuntu kernel http://www.tls-technologies.com/CPU/cpu-main.html ?
<mjg59> mulima: Given that the patch there is for kernel 2.4, no
<mulima> hooo yes, read ut too quickly
<mulima> is there anything to make the same thing under 2.6.x ?
<mulima> not the right place i suppose  .. will ask in an other chan ;)
<mulima> thanks mjg59
#ubuntu-kernel 2006-03-31
<IceTox> so how do I do this in ubuntu? How do I upgrade my kernel to the newest and safest one?
<zbbb> hello, i'm looking for some way to throttle my ubuntu network throughput. any ideas?
<JanC> zbbb: try shorewall (or just plain iptables)
<zbbb> thanks!
#ubuntu-kernel 2006-04-01
<heatxsink> anyone in here have a Sound Blaster Audigy 2 ZS, I'm trying to get the firewire port working on it, it still doesn't work
<Mithrandir> hmm, is it just for me that doing git pull results in rsync: link_stat "/scm/linux/kernel/git/bcollins/ubuntu-2.6.git/refs/heads/people-adconrad" (in pub) failed: No such file or directory (2)
<fabbione> Mithrandir: you have an old tree
<fabbione> you better trash and resync again
<fabbione> otherwise you need to poke some stuff in .git manually
<Mithrandir> git should cope.
<fabbione> it doesn't. kthxbye
<Mithrandir> git is teh suck, then. :-P
<Mithrandir> good thing bandwidth is cheap around here
<fabbione> i wonder how much tailor work is to import the kernel in brsz
<fabbione> brzs
<fabbione> AMEN
<fabbione> bzr
<zul> heylo
<zul> BenC: ping..
<BenC> zul: pong
<zul> BenC: i am going to have a couple of patches for you this week...when are you going to do the next upload?
<zul> i cherry picked the assign-buses blacklist from linus' tree and i have to figure out how to backport it..
<BenC> zul: hoping tomorrow
<zul> ok...ill send you it on wednesday then
<zul> i have to do a compile test first
<BenC> ok
<fabbione> hey Ben
<fabbione> hi zul
<fabbione> BenC: mjg59 did send you a patch to fix some acpi regression. i confirm that it does indeed fix some stuff :)
<fabbione> and that it would be really nice to get in like.. yesterday ;)
<cjb> Huh.  swsup doesn't support swapfiles, only swap partitions?
<mjg59> Correct
<mjg59> Well, not strictly true. It'll suspend to them, but there's no mechanism for resuming.
<cjb> Would it be difficult to get it working?
<mjg59> You need to provide some mechanism for passing the address of the swap file to the kernel on boot
<mjg59> So, yes
<cjb> I suppose I'm asking whether the fs would need to be involved.  For swapfiles, the kernel uses a map of swap offset->disk blocks, so it's just raw on the disk.
<mjg59> No, there's no need for fs involvement, but you still need to pass a block address
<cjb> How does it handle passing the (partition) address at the moment?
<mjg59> That's passed as a kernel argument
<cjb> Okay.  Which means that the last step of swsusp is to set up grub for the resume, or something?  So couldn't it, at that point, grab the swap mapping and use a block argument just as it uses a partition argument now?
<mjg59> No, we always suspend to the same partition
<cjb> Ah.
<mjg59> The issue with swapfiles is whether that assumption would still hold or not...
<cjb> I see.  I wonder what suspend2 does.
#ubuntu-kernel 2006-04-02
<cjb> mjg59: suspend2 uses procfs to create a file that says "for swapfile /foo, use resume2=swap:/dev/hdX:0xblock", and you put that in your bootloader config.  It implies that the block argument won't change unless you do something to change it.
<cjb> So I think we can do that with sususp too.
<adoudoux> hi there !
<adoudoux> I have a little question about the Dapper kernel
<mjg59> adoudoux: Yup?
<adoudoux> have RT patchs been applied to it ?
<adoudoux> (not very good english, I think ! :p)
<mjg59> No
<adoudoux> is the Dapper kernel ready for realtime and music stuff ?
<adoudoux> no ?
<mjg59> No, no RT patches have been applied (as far as I know)
<adoudoux> oh... I read somewhere that it did
#ubuntu-kernel 2007-03-26
<mjg59> BenC: Why do we suddenly have the linux-phc insanity?
<mjg59> BenC: It provides the ability for people to fry their hardware in exceedingly nasty ways
<BenC> mjg59: We don't
<mjg59>     UBUNTU: speedstep-centrino: Include linux-phc built-in tables.
<mjg59>     Bug: 63789
<mjg59> 
<BenC> mjg59: All we have is the tables for speedstep-centrino
<mjg59> Oh. No, you don't want that either.
<BenC> none of the sysfs twiddling is there
<mjg59> There's four different sets of tables for dothans
<mjg59> And no way of telling which one is correct
<mjg59> Using the wrong one risks hardware damage
<BenC> I thought each table was matched
<BenC> at least that's the way I read it
<BenC> we had the tables in dapper/edgy
<mjg59> BenC: No, it's matched on cpuid as far as I can tell - that's not sufficient
<mjg59> There's a chance it'll either overvolt it (potential hardware damage) or undervolt it (potential instability)
<BenC> mjg59: fuck, as it is now we have cpu's that are running hot to the point that user's can't even watch a video on youtube without it shutting down :/
<mjg59> Their hardware is broken
<mjg59> "fixing" it risks breaking other people's hardware
<BenC> but "it works on windows"
<mjg59> The Windows vendor knows what CPU they shipped
<BenC> and "linux-phc makes this work"
<BenC> I hate this
<BenC> I have to pick between two groups, but definitely the group that risks hw damage wins
<BenC> I wonder if I can disable use of the tables by default
<BenC> use a kernel cmdline options to enable it
<BenC> sounds like a plan
<mjg59> http://lkml.org/lkml/2006/7/3/240
<BenC> yeah, I've read the threads
<BenC> which is why I yanked the sysfs twiddling
<BenC> but I though the tables were safe
<mjg59> Check Arjan's message in that thread
<BenC> mjg59: Gotcha
<zul> hola
<reitblatt> where is l-r-m-2.6.20-13?
<tritium> Hi BenC 
<BenC> doko: I reproduced your gelic_net problem, I'll fix that for next upload
<BenC> doko: wow, I'm not sure...I think it might be caused by the last firmware update
<BenC> doko: reverting to an older kernel doesn't fix it
<reitblatt> BenC: where's l-r-m-2.6.20-13 ?
<BenC> reitblatt: last I checked it was on the build systems being processed
<tritium> reitblatt: I was able to download it.  (it built correctly)
<tritium> But, Atheros support didn't improve.  Still no wireless networking for me with AR5212...
<tritium> reitblatt: https://launchpad.net/+builds/+build/313591
<reitblatt> BenC, tritium: thanks
<mjg59> BenC: That patch I sent you is kind of important - fixes a fairly major regression from edgy
* Starting logfile irclogs/ubuntu-kernel.log
<glick> hi
<reitblatt> howdy
<glick> hey reitblatt 
<glick> hey has anyone here read the book linux device drivers third ed. ?
<glick> is anyone up?
<tepsipakki> BenC: I searched lp but couldn't find a bug open about megaraid (PERC2/DC) not being fired up properly on boot. Installing Feisty beta went fine
<tepsipakki> that's a friend of mine reporting
<tepsipakki> the hd's weren't found on boot
<BenC> tepsipakki: there was some problems with dapper, and pre-release edgy, but feisty should be ok
<BenC> dapper requires the -security kernel to work, IIRC
<tepsipakki> he said that edgy didn't work either :/
<tepsipakki> but I'll ask for more information
<AlinuxOS> BenC, well done, everything is perfect. Thank You!
<BenC> AlinuxOS: np
<BenC> AlinuxOS: I found the bug about 5 minutes after you logged off last week from our debug session :)
<BenC> tepsipakki: so it works with feisty?
<BenC> AlinuxOS: so you went a long way to helping me find it, thanks
<AlinuxOS> BenC, so I've helped in something :)? 
<AlinuxOS> BenC, great :) feel free to use my computers sources.. :)
<AlinuxOS> always happy to help you all guys.
<tepsipakki> BenC: installation works, but on reboot the disks are not found
<BenC> tepsipakki: I'm not sure how that can be...
<tepsipakki> BenC: yep, doesn't make sense :)
<tepsipakki> hum, there is no l-r-m for -13?
<reitblatt> tepsipakki: was uploaded several hours ago
<reitblatt> try updating
<Mithrandir> I NEWed it this morning, iirc.
<tepsipakki> ok, thanks
<tepsipakki> there were some bugs on nvidia "crashing" :)
<reitblatt> yeah, several of them
<giri> BenC: ping
<BenC> giri: pong
<giri> BenC: hi, I am ndiswrapper developer
<BenC> giri: hey
<giri> I notice that on Summer of Code 2007, ubuntu proposes to improve ndiswrapper installtion
<BenC> giri: It wasn't something I was aware of
<giri> ah, ok
<BenC> I thought it was already pretty easy
<giri> I have been trying to find out who to contact about it
<giri> actually, I am proposing to improve stability of ndiswrapper
<giri> esp with SMP
<giri> would you know if I should contact someone else about it?
<giri> BenC: right now, ndiswrapper crashes with smp with certain drivers
<BenC> giri: For the driver installation, not sure
<BenC> giri: For making it more stable under smp, I can help
<giri> BenC: actually, what I need is hardware (smp box, various cards to test)
<giri> not sure if soc2007 is the way to go about it
<giri> or some kind of sponsorship (either through ubuntu or through some other means) would be better?
<giri> BenC: sorry to repeat, but could you clarify how you and/or ubuntu can help?
<BenC> giri: me, I'm willing to test and channel bugs :)
<BenC> giri: Ubuntu, I'd have to talk to some folks
<giri> BenC: ok, tia
<BenC> giri: Honestly, I think Ubuntu's more willing to sponsor people making opensource drivers, rather than ndiswrapper work, but I can find out
<giri> BenC: yes, I am all to aware of ndiswrapper being smudgy
<giri> BenC: in fact, that has been one of the major handicaps of this project
<BenC> giri: You're probably more than aware of the outside view of ndiswrapper by most of the kernel community :)
<giri> BenC: I have spent _way too much time_ on ndiswrapper, with not much help from others (either materially or code contribution)
<giri> BenC: talking of kernel community, I have a patch to fix an issue in kernel, but not in the mood for dealing with people ranting about ndiswrapper
<giri> BenC: although patch has nothing to do with ndiswrapper
<giri> BenC: if you are interested, the patch fixes __vmalloc to allocate memory in GFP_ATOMIC
<giri> BenC: right now, if you use __vmalloc with GFP_ATOMIC, it will result in BUG_ON
<giri> BenC: __vmalloc is used in couple of places in kernel
<giri> BenC: coming back to ndiswrapper, if you could find if/how ubuntu can help, that will be great
<giri> BenC: please let me know if anything works out - my address (pgiri@yahoo.com) should be in ndiswrapper project info
<tepsipakki> BenC: ok, a bit more info about that megaraid-issue: it's a Dell Poweredge 2400 and he has a mirrored disk pair and installed Feisty on them, LVM in between. Booting it makes drops it to busybox after local-premount, but I could see the megaraid being loaded _after_ that, and it fails
<tepsipakki> BenC: clarification; hw-mirrored disks, and LVM on top of that
<tepsipakki> err, s/makes //
<tepsipakki> he's doing an installation without LVM now
<BenC> tepsipakki: sounds more like a sw issue with the initramfs detecting the lvm and such
<tepsipakki> that could be it
<tepsipakki> there's also an error from modprobe right after local-premount
<tepsipakki> but I couldn't trace the source
<tepsipakki> it shows the usage of modprobe, so maybe a typo somewhere
<tepsipakki> BenC: it worked without LVM
<tepsipakki> so not a kernel issue
<BenC> giri: Will do, thanks
<tritium_> BenC: got the latest l-r-m updates this morning.  I'm using Atheros AR5212 at the airport :)
<BenC> tritium_: sweet
<tritium_> Many thanks!
<tepsipakki> BenC: seems that the root-cause was that the megaraid was in I2O-emulation mode, not in "mass storage" mode :)
<pochu> hi all :) I don't know to which package set this bug, any idea? bug 96545
<pochu> hi all :) I don't know to which package set this bug, any idea? bug 96545
<pochu> is not ubotu here?
<Mithrandir> no
<ivoks> pochu: you didn't have linux-386 installed before
<ivoks> this is a bug that's old as hoary
<pochu> LoL
<pochu> not my bug though :)
<xipietotec> oh...haven't submitted this as a bug yet...been to busy trying to fix my feisty install, but if someone else wants to. The kernel-386 packages for dist-upgrade do not point correctly to the -generic kernels, ergo, no kernel gets installed, but the config files for the kernel does....ergo...no booting. I had to chroot from the live cd into my hd, delete the -386 kernels, and install the -generic kernel
<xipietotec> actually I had to download the -generic kernel directly from the packages site, and install it that way...couldn't use the repository method
<thotz> BenC: which is the main bug for the update from nvidia-glx (96xx) --> nvidia-glx (97xx) affecting some gforce users? could you tell me this. have we one?
<BenC> thotz: Not that I know of
<BenC> xipietotec: the -386 should point to -386, not -generic
<Mithrandir> thotz: what do you mean?
<thotz> BenC: https://launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.20/+bug/96430
<xipietotec> BenC: I thought in feisty -386 had been merged with generic?
<BenC> xipietotec: No, -686 and -k7 merged together into -generic
<BenC> actually, -686, -686-smp, -k7 and -k7-smp have all merged into -generic
<xipietotec> ah, okay...bizzare, well anyways, for some reason I had to delete my -386 and install generic...because it did not install the latest -386 kernel when I dist upgraded
<anti_pop> 9755 doesnt support cards older than geforce FX series. and it doesnt seem to be possible to use the 9631 from nvidia.com with 2.6.20-13
<xipietotec> installed the config for it, but not the kernel
<BenC> xipietotec: Were you missing some linux-386 meta packages?
<BenC> you should at least have had linux-386 or linux-image-386
<thotz> BenC: Do you know now what I mean?
<BenC> xipietotec: There's no way to get the config without the image
<BenC> thotz: you mean a bug that others can be set as duplicate of, right?
<mjg59> anti_pop: Issues with nvidia code generally have to go to nvidia
<BenC> yeah, I'm not sure what people are wanting us to do here
<BenC> nvidia dropped support, not us
<BenC> we can pretty much ship what they provide
<xipietotec> BenC: I had configs and kernel images for earlier versions of the -386 kernel, but for the lastest version, ending in .20 or whatever, I had the config file, but no kernel image. Even trying to reinstall the kernel-image to rebuild my initrd wouldn't fix it (it would just hang after checking the root file system) so I had to delete all of them, and then I switched to -generic
<Mithrandir> BenC: they want us to ship three sets of nvidia drivers, not just two.
<BenC> we vary from that and we start making problems for us and users
<thotz> BenC: yes -> http://www.nvnews.net/vbulletin/showthread.php?t=81668
<thotz> BenC and http://www.nvnews.net/vbulletin/showthread.php?t=75603
<xipietotec> oddly, even if I switched to the older versions of the -386 kernel image, I could not finish booting
<thotz> BenC: 2 legacy drivers + 1 new driver = 3 drivers
<BenC> No, I know exactly what's going on, I just don't get why this is "Ubuntu better fix it" and not "nvidia better fix it"
<mjg59> = more pain and misery
<anti_pop> cause its the new feisty kernel that doest work with the 9631 driver ?
<BenC> we provide the drivers as a courtesy to users, so they can get the most from their hw
<anti_pop> -12 did
<BenC> anti_pop: No, that's not it
<BenC> 9631 only worked with feisty kernel because I patched it
<anti_pop> i see
<BenC> you can get 9631 working with feisty if you hand patch it and build it
<BenC> google can show you this
<anti_pop> well im a user not a developer and have no idea how to do this
<mjg59> anti_pop: I recommend contacting nvidia
<BenC> but that doesn't lay the responsibility on our laps to make it work
<anti_pop> so if you once patched it, why didnt you use that patch for -13 too ?
<BenC> we're going above and beyond any other distro already, sticking our necks out to provide the drivers that nvidia makes available. Asking us to go further than that is a little much
<mjg59> anti_pop: Because we're not shipping 9631
<BenC> anti_pop: the patch isn't for the kernel, it's for the nvidia driver
<thotz> BenC: Sure. I still need a master bug for this. I would call it "Master" then. If you don't tell me, I can't help to make launchpad.
<BenC> our kernel is perfectly fine
<anti_pop> so there is no support for geforce 4,3 on ubuntu ?
<BenC> thotz: The one you pointed to is fine
<mjg59> anti_pop: There is. Use the 7xxx series driver.
<anti_pop> i will not
<BenC> anti_pop: There's no support for it in the driver we get from nvidia
<BenC> anti_pop: If the driver nvidia ships doesn't work, we can't help it
<thotz> thotz: ok, thanks. should i assign it to somebody? 
<BenC> thotz: ubuntu-kernel-team, mark it confirmed and medium for now
<anti_pop> so concerning that bug, ubuntu will not have 9631 legacy ?
<BenC> thotz: thanks
<mjg59> anti_pop: Correct
<BenC> anti_pop: nvidia is not maintaining drivers that support your card on linux
<BenC> anti_pop: hence, we cannot do so either
<anti_pop> until yesterday they did
<thotz> BenC: I can't set priority. Sorry...
<BenC> anti_pop: if we ship the 9631 driver, we cannot ensure that it will remain secure over the lifetime of feisty, which means we open our users up to unsupported and possibly insecure code
<BenC> anti_pop: I'd rather not have that hanging on my conscience
<BenC> thotz: Ok, I'll get it
<anti_pop> hmm, but what would be the difference to the 7xxx legacy driver ?
<anti_pop> this is supported, secure code
<mjg59> anti_pop: Every extra set of binary-only drivers shipped adds to the support load
<mjg59> anti_pop: This results in security updates taking longer, and increases the risk of extra issues being introduced
<mjg59> anti_pop: The 7xxx drivers support your hardware. They will be shipped.
<thotz> I still not understand why a 7xxx legacy works and a 9xxx legacy shouldn't work. But that's my own oppinion.
<mjg59> thotz: Every set of binary-only drivers shipped adds to the suppotr load
<BenC> 7xxx driver is maintained by nvidia still
<mjg59> thotz: This results in security updates taking longer, and increases the risk of extra issues being introduced
<BenC> they've been updating it and fixing issues in it
<thotz> BenC: and the 9xxx legacy not?
<BenC> thotz: No, nvidia supports 7xxx legacy driver and 9xxx tip driver
<BenC> for us to keep supporting new cards, and retain security fixes, we have to follow the latest in both those lines
<BenC> we are at nvidia's mercy as to whether or not they drop support for particular chipsets
<anti_pop> what does "tip" driver mean ?
<BenC> the 7xxx series legacy driver is a direct result of users, like you guys, complaing to nvidia, not Ubuntu, about losing support
<BenC> anti_pop: It means the newest version of their driver
<anti_pop> http://www.nvnews.net/vbulletin/showthread.php?t=81668
<BenC> 7xxx driver is a fork maintained to support older cards that they stopped supporting in the latest driver
<anti_pop> they realease a 9631 legacy and dont maintain/support it ?
<BenC> anti_pop: Yes, they support it until 9632 comes out, then you have to use that
<BenC> each time they release a new version, you have to update to the newer version if you want security and stability fixes
<anti_pop> so there is only 1 real legacy driver (7xxx)
<BenC> yes
<anti_pop> so everyone with a nvidia card <FX who will install feisty fawn is forced to use this old legacy driver
<anti_pop> not good imo
<BenC> what's not good about it?
<BenC> anti_pop: Is there something wrong with the 7xxx driver on those chipsets?
<anti_pop> fixed problems in updated drivers ?
<mjg59> Which ones?
<BenC> the "fixed problems" are problems affecting cards > than the ones dropped
<BenC> 7xxx is maintained, let's not forget this
<xipietotec> anti_pop: everyone who has a <FX card, who upgrades to any latest version of any distro out there, will have to use the 7xxx driver, because Nvidia dropped support for the chipset in *their* latest driver releases.
<BenC> hence using it isn't a problem
<anti_pop> ok, thanks for all this useful input
<BenC> anti_pop: If you installed a linux distro today that didn't come with nvidia drivers, and went to nvidia's site to download them, you'd get the 7xxx driver
<anti_pop> what is the way to setup stuff like twinview with legacy driver ?
<BenC> same way as with the regular driver
<BenC> it has a control panel and all
<anti_pop> nvidia-settings ?
<BenC> yes
<xipietotec> anti_pop: don't like the state events? support nouveau
<anti_pop> definitly!
<anti_pop> i think i have to add a comment to that bug
<mjg59> Please don't add comments to bugs unless they add new information
<anti_pop> i think most people dont know what the 7xxx legacy is
<anti_pop> and maybe the packages nvidia-glx and nvidia-glx-legacy should contain for which card they are
<anti_pop> on information
<anti_pop> sorry for my english
<anti_pop> well the legacy driver is not working here
<mjg59> anti_pop: Please file a bug about it
<anti_pop> i have to make sure i didnt do something wrong first
<alucard> my make-kpkg won't do anything, it just stops and says "nothing to be done" can anyone help me
<alucard> my make-kpkg won't do anything, it just stops and says "nothing to be done" can anyone help me
<ScottK> Is this the best place to discuss network related kernel bugs? I'm specifically interested in [Bug 86742]  D-Link AirPlus DWL-G650 Wireless (rev.C) - Atheros AR5212 (rev 01) does not work in Feisty
<Lure> ScottK: from earlier today:
<Lure> [Mon Mar 26 2007]  [16:30:47]  <tritium_> BenC: got the latest l-r-m updates this morning. I'm using Atheros AR5212 at the airport :)
<BenC> ScottK: Make sure you have latest -13 kernel + lrm
<ScottK> I do have the latest (-13 kernel).  
<ScottK> l-r-m?
<JoseStefan> restricted modules
<ScottK> OK.  I'll check that then.  Thanks.
<lifeless> BenC: ping
<BenC> lifeless: hey
<lifeless> am I confused ? :). I thought you had previously been involved closishly with svn (and I know you're not sussman)
<BenC> lifeless: yeah, a few years ago I was doing a lot in regards to memory consumptions and stuff in svn
<lifeless> right
<BenC> but I'm only involved by name anymore
<lifeless> thats cool
<lifeless> we have this bug (OT here) :) that would be nice to get someone at svn to care about.
<lifeless> and I thought you might know who to prod to make that happen.
<BenC> sussman is one
<lifeless> it breaks the cscvs package's test suite.
<BenC> doesn't svn have a channel on freenode?
<lifeless> yah
<lifeless> it would suck to ship feisty broken though; if we dont get traction through regular channels soon, perhaps you could email sussman an introduction ?
<BenC> sure
<lifeless> thanks
<ScottK> It was lack of lrm that did it.  Installing that solved my problem.  Thank you very much Lure, BenC, and JoseStefan.  I'll update that bug.
<JoseStefan> make sure you have the meta package, so you can avoid that, dont remember the name right now
<BenC> ScottK: sudo apt-get install linux-generic
<BenC> that will keep things up-to-date
<BenC> ScottK: Please just set the bug to rejected or fix-released whichever you feel is appropriate
<ScottK> BenC: Will do.  I'll also update the wireless wiki support page too.
<BenC> ScottK: for reference on that page, note we have madwifi 0.9.3 now
<BenC> link to it's support page would probably make things a lot easier to maintain
<ScottK> OK.  I'll take a look at that too.
<[g2] > crimsun, around ?
<ScottK> BenC: Which "that page" - I don't think I was thinking the same page needed updating that you did?
<[g2] > BenC, how crazy are things for the release ?
#ubuntu-kernel 2007-03-27
<BenC> [g2] : They only get crazier from here out :)
<[g2] > BenC, when's release ?
<BenC> April 21st
<BenC> kernel freeze is coming up too
<[g2] > when's the freeze ?
<BenC> April 4th
<[g2] > thx
<JoseStefan> !schedule
<JoseStefan> ubotu :(
<[g2] > lazy bots
<[g2] > BenC is netconsole supported by Feisty ?
<[g2] > or usb serial console ?
<BenC> No idea, never used either
<zul> BenC: ping is the meeting tomorrow?
<mjg59> BenC: http://article.gmane.org/gmane.linux.ide/17444/raw looks relevant
<BenC> zul: No, next week
<zul> sweet, have a good night
<crimsun> [g2] : hi
<[g2] > hey crimsun :0
<ivoks> odd...
<ivoks> dapper's doesnt recognize modem on ttyS0, while debian's kernel does
<raffytaffy> hi guys ; do the generic kernels for buntu have SpeedStep enabled as module?
<kkubasik> not as a single module exactly, but yes, in the generic kernels speedstep is supported
<jsaw> hi, anybody around that can help me booting the install CD on a computer with a Promise SX6000...?
<jsaw> or how to avoid that the ata subsystem probes harddisks/loads the pdc202xx driver...?
<abogani> jsaw: Put the name of the driver in /etc/modprobe.d/blacklist
<jsaw> eh, boot-CD?
<jsaw> (I'm trying the Feisty-Beta,i386,alternate)
<jsaw> ah, ic
<jsaw> mount image, edit... ?
<abogani> jsaw: It is a very rough way(but works): debootstrap
<jsaw> ...damn...
<jsaw> btw, will the 2.6.20 be the final kernel for end of April, or is there a chance for 2.6.21, even rc?
<jsaw> (because the sx6000 issue seems to be related to commit ca4266359d0c1199af088447f209ab5bcc32a989, http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.21-rc4)
<fabbione> .20
<fabbione> no way we will change kernel now
<jsaw> anyway, I'll try editing the boot CD.
<jsaw> ok
<jsaw> thanks, I'll come back and report.
<jsaw> bye
<anti_pop> BenC, around ?
<badpsyche> who
<rikai> Internets been down for 7 hours. ~.~
<thotz> BenC: Am I correct: We only do not want to release the 96xx driver because it does _not_ appear on the nvidia driver download page? Or have I misunderstood something yesterday?
<BenC> thotz: no decision is made yet, we are actually discussing what we are going to do
<thotz> BenC: I have contacted nvidia support. I can send you the answer they gave me about this driver. I think this will be supported through nvidia as a "new" legacy driver. sending you the mail...
<BenC> thotz: thanks, that's useful information
<thotz> BenC: This should give you the answer :-)
<BenC> thotz: +10 points for following up with the vendor, thanks :)
<thotz> BenC: No problem. Hopefully we can find a good solution for this soon.
<ivoks> BenC: have some time for dapper kenel debugging? :)
<BenC> ivoks: not at the moment (meeting), but for dapper, kylem is da man
<ivoks> oh, sorry
<mvo> hi kernel team! I'm currently working on making sure in the release upgrader that a new kernel is installed. I got some reports that didn't happen during a upgrade (they were left with 2.6.17 that didn't boot anymore for some reason). what is the most sensible thing to check against? linux-image-generic? this seems to be ok for amd64 and i386, but what about the other arches?
<mvo> BenC, kylem: do you have a opinion about the kernel upgrades handling?
<kylem> i don't think we renamed any flavours for feisty
<BenC> mvo: they need one of the linux-image-* or linux-* or linux meta-packages installed
<BenC> mvo: In most cases, linux-image-generic, the linux-generic will include the lrm stuff
<BenC> linux for amd64 and i386 is just the same as linux-generic
<mvo> ok, thanks. I will ensure that its linux-image-generic if possible 
<mjg59> mvo: -386 is also acceptable on i386
<mvo> thanks
<mvo> [Arch-powerpc] 
<mvo> Kernel=linux-image-generic
<mvo>  ^--- does that make sense on ppc as well? 
<mjg59> mvo: linux-image-powerpc
<mjg59> mvo: I'm a little worried about this approach - what about machines using server or bigiron kernels and so on?
<mjg59> There isn't a right kernel per architecture, as such
<mvo> mjg59: I can give it a list, this is the approach I plan
<mjg59> mvo: In that case, just check what packages are built from linux-meta?
<mvo> mjg59: but I'm open for suggestions of course. I want to ensure that after the upgrade there is a updated kernel as well
<mjg59> Installing a -generic kernel on a system that's been using -386 may break stuff
<mjg59> And installing a -powerpc kernel on a system that's running -powerpc64 isn't a good plan
<mvo> right. I'm trying to solve the case if the user does not have any linux-image-$flavour package installed (but just linux-image-$ver-$flavour),  does it make sense to auto-install linux-image-$flavour (+ dependencies) in this case?
<mjg59> If $flavour is the same in both cases, yes
<mvo> the idea with the kernel-arch-list was to check if any of the kernels is installed, fine do nothing. otherwise do something
<mvo> ok, I think that is the better approach then
<mjg59> $flavour is probably best taken from the running kernel, if possible
<mvo> that should be possible, yeah
<AnAnt> Hello, I got a question, if there is an application that can enables reading & writing arabic  in virtual console, it used to work in  Edgy, but not in Feisty, can that be kernel related or what ?
<mvo> thanks mjg59!
<AnAnt> ping
<anti_pop> tepsipakki, i tested 2.0 of nv driver, no success. see Bug #96833 for the logfile and let us know, if you need more log's or stuff like that
<bdmurray> BenC: ping
<BenC> bdmurray: yo
<bdmurray> I'm probably late to the party about the nvidia drivers, bug 96430 but one comment mentioned restricted-manager in it.
<bdmurray> That seems like it could be an issue to me.
<BenC> It wont be
<bdmurray> Okay, the restricted-manager won't recommend the nvidia driver for "legacy" cards?
<BenC> pitti, mvo and I already discussed the implementation and it will actually be invisible to users whether they are using 9631 or the 9755 driver
<bdmurray> okay, cool.  I am late then.
#ubuntu-kernel 2007-03-28
<holycow> hey guys
<holycow> i have an issue with dapper installer on intel chipsets
<holycow> the terminal gets hosed 3/4's of the way through with no appearent way to continue or fix it
<holycow> i suspect its a driver issue but hard to tell, would this be a kernel issue or a d-i issue?
<newz2000> Hi, I reported bug #96679 and I want to fill in the additional info needed to diagnose the bug...
<newz2000> I can't get online when I boot 2.6.20-13, the bug is related to power management
<newz2000> is there anything besides uname, dmesg and lspci that will help?
<newz2000> ok, well, I'll get that and get back to you
<Mithrandir> BenC: do you think including the kqemu module by default would make sense?
<Mithrandir> BenC: also, I'm thinking about removing all kernel modules older than 2.6.20 ones (like multiverse/misc/vmware-player-kernel-modules-2.6.15-23, restricted/misc/linux-restricted-modules-2.6.17-10-386 ); I guess you don't mind if I do that?
<jml> suspend and resume works on my macbook now.
<jml> I love you guys so much.
<AnAnt> Hello, the -12 & -13 kernels won't boot on my laptop
<AnAnt> I just done an update now
<AnAnt> ping ?
<varka> AnAnt: perhaps you have more luck in #ubuntu+1
<AnAnt> isn't that a kernel issue that should be reported ?
<BenC> Mithrandir: I can look into the qemu thing...removing old modules sounds fine
<Mithrandir> BenC: I can't get it to boot in vmware either, so either it's really busted or I am incompetent.  I haven't tried on real hardware yet.
<AnAnt> BenC: the -12 & -13 kernels won't boot on my laptop, I just done an upgrade today
<shawarma> Should http://launchpad.net/bugs/94637 be fixed in the daily server images from the 26th?
<pkl_> AnAnt: can you file a bug in launchpad, giving the usual details (dmesg, lspci, dmidecode etc.).  Thanks
<shawarma> Ah... uname -v says "Mar 21", so I guess not.
<AnAnt> pkl_: I can't boot, so can I give dmesg,lspci,... output ?!
<pkl_> AnAnt: can you boot using an older kernel (i.re. -10 or -11) and use that?
<AnAnt> pkl_: ok, is there something else other than dmesg,lspci & dmidecode
<pkl_> AnAnt: plus when you're booting the -12 and -13 kernels, removing quiet and splash from the Grub kernel line may allow you to see what happened (does it go to a busybox prompt?)
<pkl_> no, dmesg, lspci and dmicode should be everything needed :)
<AnAnt> pkl_: nope, I just get a message like waiting for root partition
<pkl_> AnAnt:  I think there's a couple of other users experiencing similar problems.
<shawarma> AnAnt: https://launchpad.net/bugs/75681  ?
<AnAnt> shawarma: no, I don't use LVM
<shawarma> AnAnt: Ok.
<pkl_> shawarma: no, that's quite an old bug.  This bug look like it's caused by recent libata changes to the -12 and -13 kernels.
<pkl_> AnAnt: if you file a bug with the above info, it will be looked at.  If it is a duplicate, we'll deal with it then.
<shawarma> pkl_: Alright. I just joined the conversation just now and it sounded familiar.
<pkl_> shawarma: no problem, there's a lot of these bugs. all looking the same :)
<shawarma> pkl_: There sure is. :-)
<ph8> hi guys - has anyone complained about .13 latest shutting down their PCs because they're 'too hot' ?
<ph8> -13 sorry
<ph8> i've switched back to -12 and it's not happening anymore
<gicmo_> whois kylem
<gicmo_> args
<gicmo_> ;-)
<gicmo_> kylem: ok, you are that kyle ;-) Just wanted to let you know that I am also here and alive if you have any questions regarding https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/96692
<kylem> thanks.
<mjg59> gicmo_: I've just added a comment
<gicmo_> hey Matthew!
<gicmo_> long time no see
<gicmo_> former youth-hostel roommate in stuttgardt ;-)
<gicmo_> personally I am more bothered of https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/96480 though
<gicmo_> mjg59: *sigh* ;-)
<mjg59> Gralghngh.
<mjg59> Maybe that's why my battery status has vanished.
<gicmo_> mjg59: so any idea how to solve that nasty IDE slowness bug? .. maybe its claims to be and old IDE because of bootcamp or something
<mjg59> Kyle and I have a couple of ideaas
<mjg59> But it involves special-casing Apple hardware
<gicmo_> mjg59: you get a beer in Birmingham if you make my MacPro fast again. My X60 tablet is faster
<gicmo_> of course on the tablet the pen doesnt work when display is rotated, I wanted to file another bug for that, but I forgot
<gicmo_> linux & hardware ;-)
<gicmo_> also, if you need somebody to test stuff regarding https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/96480, I am very willing to do that
<sterwill> Me too.  I've love to run the latest kernel.  :)
<sterwill> Since Boot Camp's BIOS stuff is magic (there's no user interface as far as I know), would it be possible to write a Linux utility that set the SATA controller to show up as an AHCI device (like a PC BIOS can do)?  Maybe that's impossible or it wouldn't survive a reboot.  I don't know much about these things.
<kylem> sterwill, yes.
<kylem> man setpci
<mjg59> It wouldn't survive a reboot
<sterwill> That was my worry.
<kylem> mjg59, so do it in the initramfs.
<kylem> ;-)
<gicmo_> ohh
<gicmo_> sounds magic
<sterwill> I understand the bind the kernel AHCI maintainers are in.  Apple doesn't follow the rules, and they don't want to hack up the detection code because it may affect other uses of this controller (which were specifically assigned to run in "piix mode" or whatever the term).
<sterwill> Am I right in thinking that if the Apple firmware allowed boot-time configuration of the controller like a PC BIOS might, the card would be correctly detected via AHCI?
<kylem> yes
<mjg59> That would depend on what configuration it allowed
<kylem> all the PC BIOS does is poke config space and initialize the controller
<sterwill> Assume it has a "[X]  AHCI mode" setting.  I've seen SATA controllers have these options in PC BIOSes.
<exoide> Hi, can someone give me some reference about the .symtab section in an ELF file?
<mjg59> sterwill: Assuming it had that option, then yes, it would come up as ahci
<kylem> exoide, http://flint.cs.yale.edu/cs422/doc/ELF_Format.pdf
<sterwill> The initramfs thing intrigues me.  I don't know much about it.  I stopped building all my own Linux kernels back before boot-time RAM filesystems were used.  :)
<sterwill> I know what the RAM fs is used for, but I don't know how to build in scripts/utilities.
<exoide> kylem, Is that pdf the TIS specification 1.2?
<ivoks> kylem: dapper kernel is under your survailance? :)
<kylem> ivoks, yeah
<gicmo_> hmm but since it was already working correctly with the AHCI driver if I hacked in that thing in the ahic table if we did that setpci magic in initramfs the ahci driver would pick up the device and it would work just fine? ;-)
<ivoks> kylem: there are some funny stuff with serial ports
<sterwill> gicmo: Hope so.  :)
<mjg59> gicmo_: If you did it early enough, yes
<ivoks> kylem: i can't get modem to work :/
<mjg59> But less than ideal
<kylem> ivoks, file a bug? i'll look at it after feisty kernel freeze.
<ivoks> kylem: i did...
<kylem> ah
<kylem> what bug #
<ivoks> sec...
<gicmo_> mjg59: hmm right, if you find something better i'll be happy
<ivoks> bug #77467
<ivoks> kylem: 77467
<exoide> kylem, I've read that documentation and It's not enough for me
<exoide> kylem, I'm doing a code generator for Linux and I need to know a little more about that section
<kylem> so look at binutils, this isn't on topic for this channel.
<kylem> ivoks, thanks
<exoide> kylem, Can you suggest me a channel?
<exoide> kylem, I've tried a lot of channel but nobody answer my question :-(
<mjg59> gicmo_: If it needs to be done, it should be done in the kernel
<gicmo_> mjg59: fair enough
<sterwill> mjg59: Adding the ID to the AHCI list is bad for two reasons: it's hacky because Apple should be using the correct AHCI ID class in the first place; the controller can also be piix and maybe the user wants it that way.  Is this right?
<sterwill> Just trying to get things straight for my own knowlege.
<mjg59> Yes
* gicmo_ kicks apple
<sterwill> I had similar fun getting the sound card to work right.  They use Intel's HDA audio chipset but changed all the mixer assignments around.
<crimsun> oh, but sigmatels are Oh So Fun.
<crimsun> (I suppose they're a bit "better" than Realteks, but that's not any consolation.)
<sterwill> I poked through the sigmatel and realtek driver code.  There are a ton of configurations out there.
<crimsun> And there will be many more. There are at least three for Mac/Pros alone.
<gicmo_> crimsun: omg
<sterwill> I didn't know there was more than one Mac Pro sound configuration.  MacBook Pro has a few.
<yorokobi> Is SELinux built into any of the kernels for Fiesty?
<BenC> it is there but must be enabled with a kernel command line option
<BenC> selinux=1 I think?
<BenC> mjg59: ping
<yorokobi> I've tried that with the generic kernel. dmesg says SELinux is initialized but all of the command-line commands say its disabled.
<BenC> I think there's some userspace stuff to it too
<yorokobi> And there are no audit entries in /var/log/messages
<BenC> if the kernel says it's enabled, then userspace has to take care of the rest
<yorokobi> Yeah, I have /selinux and all that 
<Mithrandir> you need to install a policy
<yorokobi> Targeted is installed
<BenC> right, there's a lot to it, from what I understand
<yorokobi> Yeah, I had it working in 6.06 then decided to format/reinstall ... 
<yorokobi> oh well, I'll play around a bit more and try to find out what I missed.
<BenC> selinux-basics, selinux-policy-default packages for starters
<BenC> yorokobi: probably some info on wiki.ubuntu.com
<mjg59> BenC: Hi
<BenC> mjg59: after talking with jgarzik, I've synced our kernel to libata-dev#upstream git
<BenC> mjg59: Checking through some things, I noticed that prior to that, "int noacpi;" in libata-core.c was not initialized, so I suspect it was always disabling acpi by default
<yorokobi> Argh, gotta put out a fire :) Thanks for your help everyone.
<kylem> BenC, uh.
<BenC> mjg59: In the new code base, libata_noacpi is set to 1 to by default, jeff says there were regressions
<kylem> BenC, global variables are initialized to 0.
<BenC> kylem: non-static globals are initialized to 0?
<mjg59> BenC: The GTM/STM stuff is required
<kylem> BenC, yes
<kylem> by .bss
<kylem> if you put = 0, they end up in .data and take space in the binary. kind of funny.
<BenC> I didn't think global vars went into bss
<BenC> maybe I need to refamiliarize myself with some compiler basics :)
<BenC> mjg59: Ok, so if I use your patch, then I should be able to have libata_noacpi=0 by default?
<kylem> maybe i'm on glue. but i don't think so.
<mjg59> BenC: The _GTF code still needs cleaning up a little, so may need to be disabled
<mjg59> BenC: But I've got a cleaner patch for you
<mjg59> Just let me take a look at what's in -upstream
<BenC> mjg59: I already applied yours, so can you patch against git?
<mjg59> BenC: Ah, hrm. Might be easiest to revert mine. Give me a couple of minute?
<BenC> sure
<BenC> 0000000c g     O .bss   00000004 noacpi
<BenC> kylem: You were right
<kylem> BenC, i don't think i am...
<kylem> oh. maybe i am.
<BenC> I wonder if that's implementation dependent type stuff
<mrec> BenC: I wonder if you had a look at the em28xx stuff lately, you can just pull the changes over the v4l-dvb repository which is on linuxtv.org or pull it directly/completly from mcentral.de now
<BenC> mjg59: ata_acpi_push_timings() needs to be static inline for the !CONFIG_SATA_ACPI case
<BenC> get multiple defs when building otherwise
<BenC> it was defined extern void
<BenC> *declared
<mjg59> BenC: Ok. Can you revert mine, and add http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/broken-out/libata-acpi-add-infrastructure-for-drivers-to-use.patch
<mjg59> and http://www.codon.org.uk/~mjg59/tmp/libata-pata-gtm
<BenC> mjg59: yep, thanks
<mjg59> If you can push those, then I'll tidy up the integration with Jeff's changes
<BenC> mjg59: I get a good chunk of rejects on the second patch
<BenC> maybe I can munge it, looks related to the noacpi -> libata_noacpi name change
<mjg59> Probably, yeah
<BenC> there, patch applies with a little fuzz now
<mjg59> Let me know when it's pushed and I'll sort stuff out
<BenC> mjg59: pushed
<BenC> build tested
<mjg59> Pulling
<mjg59> BenC: http://www.codon.org.uk/~mjg59/tmp/libata-acpi-cleanup
<gicmo_> re
<BenC> mjg59: So with this patch we'll have acpi for pata, but not for sata (by default), correct?
<mjg59> Yes
<BenC> ok
<mjg59> Though, strictly, it's not sata/pata
<mjg59> It's IDE-style interfaces and non-IDE-style interfaces
<BenC> gotcha
<BenC> so is non-IDE-style unsafe with acpi?
<mjg59> Right now, it's not strictly correct
<mjg59> The implementation, that is
<BenC> but this gives us at least the same level of support as with ide drivers instead of pata, right?
<mjg59> Yes
<mjg59> Uhm. I'm assuming you mean that we get the same amount of support in libata as we had in drivers/ide
<BenC> right
<BenC> mjg59: thanks
<tepsipakki> BenC: I merged ndiswrapper from debian.. I don't use it myself, but there was a report it should fix some issues
<tepsipakki> I know that the kernel has the latest driver already
<tepsipakki> but the tools..
<tepsipakki> BenC: do you think it's worth UVFe?
<tepsipakki> bug 92155
<tepsipakki> hm, no ubugtu here
<BenC> tepsipakki: definitely
<tepsipakki> cool, I'll file one
<BenC> mjg59: ping, re: memstick
<mjg59> BenC: Ah, yeah, I'll look into that
<mjg59> Need to get a fresh install on the machine with the hardware
<BenC> mjg59: Do you have the code handy?
<BenC> if you can send it, I can test it (I have memstick hw)
#ubuntu-kernel 2007-03-29
<owh> Greetings. I am trying to determine if the FAT as implemented by the kernel supports the dirty flag. I have conflicting information going back to 1998, but no definitive answer either way. I've looked in include/linux/msdos_fs.h where I would expect the definition. There is a mark_inode_dirty call in fs/fat/file.c, but I cannot see it relating to the boot sector in any way. Can anyone here enlighten me?
<owh> Some background: Initially bugs were being reported where dosfschk was checking clean file systems and changing them, causing all manner of grief. Some of the bugs are/have been fixed, but the check should never have happened in the first place. I wrote a spec to handle the (v)FAT flag for dosfschk but stayed away from kernel comments because I do not know the state.
<owh> The spec was updated to comment about the kernel, but I now need to know for sure if it isn't supported, which is what it's beginning to look like.
<owh> I suspect that once dosfstools implements dirty flags, that can then be used within the kernel, seeing that it doesn't currently appear to be there.
<mjg59> BenC:      - pata_oldpiix: Stable, allows us to disable piix.ko IDE module.
<mjg59> BenC: Does that mean you've added IDs back to ata_piix that had been taken out previously?
<mjg59> I'd noticed a couple vanish
<BenC> yes
<BenC> I had shifted some back to piix because ata_piix was getting some weird errors
<owh> Am I asking too much, in the wrong channel, at the wrong time?
<lifeless> owh: well, this is the ubuntu-specific kernel channel
<lifeless> owh: I'm not sure that the folk here know the answers offhand. Though they may.
<lifeless> BenC: any comment on owh's thing ?
<BenC> no idea
<lifeless> owh: there you go. :)
<owh> lifeless: Any suggestions where to ask?
* owh suspects that sending an email to lkml will get burried.
<owh> I've been trying to track this down since January 2, I've sent emails to ubuntu-dev, ubuntu-dev-discuss, the maintainer of dosfstools, #ubuntu-motu, LP and here. I'm getting a whole lot of nada.
* owh would think that FAT implementation would be high on the list of importance given it's pervasive nature in the interaction with the rest of the world.
<owh> I'm happy to be patient, realise that people are busy with other things, but the response level I'm seeing is a little disheartening.
<owh> How do I get this issue in front of the appropriate eye balls?
<fabbione> morning guys
<fabbione> BenC: you still awake?
<owh> It has just been suggested that I write the patch to implement FAT dirty flag support for the kernel. If I actually do that, how do I get someone to look at it?
<owh> Do I bring it here and show it like a cat comes into your home with it's catch for the night?
* owh apologises for the bastardisation of the English language in that previous contribution.
<fabbione> owh: make a patch first :) then post it to kernel-team@lists.ubuntu.com for review
<fabbione> if the patch is good it will eventually land in Linus tree
<owh> Excellent, now that's what I call progress. Thanks for that fabbione, that pays for the past four hours of banging my head against the keyboard.
<fabbione> owh: you are only fighting against different people living in different TimeZones
<fabbione> you can start complaining only after 48 hours of nobody answering (excluding the weekend ;))
<owh> :)
<raffytaffy> i have i915 chipset - ditching all the i810 and ati/amd stuff is safe correct?
<Mithrandir> I wouldn't drop the i810 stuff, no
<raffytaffy> ok thanks
<raffytaffy> for character devices - ( im using nvidia go 6600) i dropped ATI and AMD, seems safe. i kept nvidia nforce/geforce
<raffytaffy> im trying to configure my kernel to be minimal.
<mjg59> BenC: There's a missing ! in the check for acpidata in ata_acpi_push_id
<mjg59> Sorry about that
<BenC> mjg59: Yes, we caught that :)
<mjg59> Excellent
<BenC> Tim is moving the check for !acpidata to skip_acpi_operation()
<Mithrandir> BenC: did you see my question about whether we can include kqemu in feisty?
<mjg59> BenC: As long as he's arranging the order of checks so that doesn't dereference a null, that's fine
<BenC> mjg59: Am I correct that the check for skip_acpi_operation() in do_drive_get_GTF() is bogus (already done from the calling function)?
<mjg59> BenC: do_drive_get_GTF is exported
<mjg59> Oh, sorry, no it's not
<mjg59> I was thinking of GTM
<mjg59> Yeah, in that case it can probably go
<fabbione> BenC: i committed the fixes to OCFS2 local mount.. 3 small patches.. no ABI change
<fabbione> BenC: we need to get those in feisty before relase
<BenC> Mithrandir: Yeah, as soon as I get the ata stuff settled down, finish my ps3+powerpc64-smp merge, and do the nvidia 9631 stuff, I'll see if I can get to it :)
<BenC> fabbione: We have an ABI bump anyway...thanks for the merges
<Mithrandir> BenC: ok, cool.  It was more of a "would it make sense" than "please do asap".
<BenC> Mithrandir: I'd like to have it in there...the more virt stuff we have the better
<Mithrandir> BenC: it seems that the problem with the live cd not working in qemu is limited to amd64; i386 works fine.
<zul> BenC: I can look at the kqemu stuff if you want
<BenC> Mithrandir: I heard there's problem with amd64 under vmware too...guess I need to check on that today
<BenC> zul: Yes, please
<Mithrandir> zul: it should be easy enough; the module builds fine as is, so it's just build-system integration.
<zul> Mithrandir: sure no problem
<Mithrandir> BenC: great, thanks.  If you want bugs about this, then tell me.
<mjg59> BenC: I'm still trying to track down the HPA issue
<mjg59> That's basically a blocker to release
<BenC> mjg59: April 4th is kernel freeze...I don't want to have to revert all the libata-pata drivers back to ide counterparts :)
<kylem> mjg59, it doesn't work with piix or ahci, does it
<mjg59> Seems fine with ahci
<mjg59> Breaks on ata_piix on Apple hardware
<kylem> can i get an lspci -vvnn from your MBP?
<mjg59> Not right this second, but what are you looking for?
<mjg59> The controller is 8086:27c4
<mjg59> And it comes up with an IDE class, not an AHCI one
<kylem> right.
<kylem> that's fixable though.
<kylem> ;-)
<mjg59> Subdevice code is an Intel one, not an Apple one
<mjg59> Otherwise it'd be really easy
<mjg59> So, yeah, one fix would be to bodge it over to ahci
<mjg59> And hope that we're only going to hit the issue on Apples
<mjg59> Though I suspect we still need to make udev smarter in initramfs-tools in order to guarantee that ahci binds rather than ata_piix
<kylem> gnrrr.
<kylem> i was hoping i could just install a pci quirk and check the dmi table for Apple
<mjg59> That ought to be fine
<mjg59> But the device ID is still present in ata_piix, so both will be loaded
<mjg59> And I don't think we have guarantees about which will bind first
<mjg59> So it's either (a) fix udev so that it doesn't load ata_piix unless the class ID is 0x0101, or fix ata_piix so it refuses to bind if the class id is 0x00601 (or whatever ahci is)
<kylem> argh.
<fabbione> BenC: ok ..
<kylem> mjg59, i think my ich8 changes the devid too.
<mjg59> kylem: Really? Wow. ich6 and ich7 don't.
<kylem> 1sec whiel i rboot
<mjg59> Ok
<kylem> 00:1f.2 IDE interface: Intel Corporation Mobile SATA IDE Controller (rev 03)
<kylem> turns into blah blah AHCI, and sets the prog-if doodly
<mjg59> And the device ID?
<kylem> well, if the string changed, it's different, i didn't bother to save it
<mjg59> Which bit of the string changed? Just the "IDE interface" to "AHCI interface"?
<mjg59> If so, surely that's just because the class ID changed?
<kylem> no
<kylem> the device id.
<kylem> *AND* the class id
<kylem> 00:1f.2 SATA controller: Intel Corporation Mobile SATA AHCI Controller (rev 03)
<mjg59> Ah, got you
<mjg59> Yeah, in that case it seems to change
<kylem> this is what all implementations *should* do.
<mjg59> That doesn't seem to be the case for ICH7 and ICH6
<kylem> since rarely do we match on classid.
<mjg59> That's why ahci and ata_piix share a load of device IDs
<kylem> have i mentioned how much i hate BIOS writers today?
<mjg59> Not helped by the fact that ata_piix will deliberately try to reprogram your ahci hardware back to piix mode
<mjg59> ahci has the class ID in it now
<kylem> will to-be-driven-by-piix devices always be 0x0101?
<mjg59> Should be
<kylem> hmm. ok.
<BenC> zul: You interested in doing a openvz package like the xen one for feisty universe?
<BenC> zul: I can get you in contact with the openvz folks who seem ready to do just about anything to get it done
<zul> BenC: sure
<zul> whats one more 
<BenC> What's your preferred email?
<zul> gmail account
<BenC> zul: Sent
<zul> BenC: thanks
<BenC> zul: No, thank you :)
<zul> BenC: no thank you
<zul> I can do this all day
<BenC> hehe
<shawarma> Any idea when the kernel in the ubuntu-server daily images will be updated? 
<shawarma> I'm unable to boot it in qemu and I suspect this bug: https://bugs.beta.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/94637
<shawarma> ...which appears to have been fixed on the 23rd, but uname -v on the ubuntu-server daily image from yesterday says "Mar 21".
<shawarma> Er.. Not unable to boot, but unable to access either emulated hard drive or cd-rom.
<zul> BenC: depending on what happens with liam I can probably get it done this weekend
<BenC> zul: sounds good
<shawarma> BenC: ^^
<BenC> shawarma: what kernel is on that CD?
<shawarma> 2.6.20-12-generic
<shawarma> BenC: uname -v says:"Linux (none) 2.6.20-12-generic #2 SMPWed Mar 21 20:55:46 UTC 2007 i686 unknown"
<BenC> shawarma: Guess it has to wait on debian-installer being rebuilt with the latest kernel
<shawarma> BenC: That's it?I think I saw a new d-i on feisty-changes earlier today..
<shawarma> BenC: That would put it on the daily image for today?
<BenC> either today or tomorrow
<shawarma> BenC: Apparantly so. The changelog even says:"* No-change rebuild to pick up new components."
<shawarma> :-)
<shawarma> I didnt' make the connection for some reason. 
<shawarma> BenC: Great. Thanks for clarifying.
<zul> BenC: http://www.linuxsymposium.org/2007/view_abstract.php?content_key=110
<BenC> zul: whack
<shawarma> zul: Is that a Xen hypervisor as a module?
<zul> shawarma: i think so I havent read the paper yet 
<shawarma> zul: Interesting. 
<shawarma> zul: Well... if you have the appropriate hardware, that is. :-(
<Lure> BenC: is current kernel in git in flux? it oops-es on boot here in ata code (scsi_error_handler)...
<BenC> should be fixed now
<BenC> git is always in flux
<Lure> BenC: ok, expected
<Mithrandir> BenC: could you take a look at 91009 and tell me what you think?
<BenC> Mithrandir: well, we're using stock 2.6.20 wireless extensions, so if userspace needs to catch up, then that's what has to happen
<BenC> I can't revert the kernel stack back, else we risk breaking dozens of drivers
<Mithrandir> gnr, ok.
<Mithrandir> oh well, let's go for it then.
<bdmurray> Is there any documentation about kernel hdX: command errors?
<cr3> BenC: I seem to be experiencing the same problem as reported in bug #84603, should I log another bug, attach to the existing bug or would you even want me to try anything beforehand?
<BenC> cr3: let me check
<BenC> cr3: More dmesg might help
<cr3> BenC: shall I attach it to the same bug or to another bug?
<BenC> same one
<cr3> BenC: I'm experiencing the problem on a System76 Z35F which is not exactly the same as the original poster, so I'll make sure to mention that in my comment.
<BenC> cr3: Ok, then lspci -vvn output too please
<BenC> compare notes
<cr3> BenC: done
<BenC> cr3: thanks
#ubuntu-kernel 2007-03-30
<doko> BenC: any news on the gelic driver?
<BenC> doko: pulling in some changes now that should fix it
<BenC> doing a build to test in about an hour
<doko> cool
<bdmurray> BenC: there?
<Mithrandir> BenC: can you assign #98714, #96486 and #98643 to somebody on the kernel team?
<zul> hey
<bdmurray> morning
<BenC> Mithrandir: in progress
<bdmurray> BenC: Does the low latency kernel have different kernel modules?
<BenC> bdmurray: Nope, it's built using the -generic config, just with some options changed (HZ and PREEMPT)
<bdmurray> okay I was looking at a bug where somebody wanted p4-clockmod
<BenC> bdmurray: however, it's entirely possible that some modules disable themselves when CONFIG_PREEMPT=y, so that might change things unknowingly
<BenC> bdmurray: probably not compatible with preempt, not to mention we close all bugs that pertain specifically to -lowlatency
<BenC> it's not supported
<bdmurray> close them all? is that documented?
<JanC> I think maybe assigning -lowlatency bugs to a team of -lowlatency volunteers (if those exist) might be more useful ?
<BenC> bdmurray: it was understood by the team before I even created the package
<BenC> and I believe it is in the package name that it is unsupported
<BenC> s/name/description/
<bdmurray> BenC: right my point was just that it might be worth adding to the KernelBugPolicies page
<BenC> bdmurray: If they expose a real bug, have them verify it on -generic, or it can be closed
<BenC> bdmurray: true, I hadn't thought about that when I wrote it
<bdmurray> BenC: incidentally I can get some kernel smb error messages on my feisty system
<bdmurray> smb_lookup and smb_add_request errors
<BenC> passive errors, or oopses?
<bdmurray> passive errors I guess, it did cause amarok to hang once
<bdmurray> BenC: does passive errors mean that are harmless?
<BenC> yeah
<BenC> like just kmsg traffic as opposed to "oh damn, the machine is going down" :)
<bdmurray> okay, no bug then.  so people won't have to see what music I have. ;)
<BenC> lol
<bdmurray> well, some of the songs were disturbing or revealing
<kylem> er?
<bdmurray> well, I'm certainly not gonna say. ;)
<kylem> lol
* ^^CatTuX^^ is away: I am tired, exhausted, tensed, angry.
* ^^CatTuX^^ is away: I am tired, exhausted, tensed, angry.
<mjg59> ^^CatTuX^^: Please don't use public away messages. They're unnecessarily distracting.
<^^CatTuX^^> ooopppsssss sorry, okay
<mjg59> Thanks!
<bdmurray> somebody is reporting that some of their thinkpad special keys don't work after suspend, would that be a kernel bug?
<bdmurray> or hotkey-setup?
<eean> I did some updates with Feisty, now I get kernel panics on startup
<eean> of the Unable to mount root fs variety
<eean> its still on a kernel that worked before
<eean> .20-12
<BenC> eean: probably need kernel 2.6.20-13
<BenC> bdmurray: it's likely a BIOS bug, but I've seen the same reports (it's a dupe, I assigned to ubuntu-kernel-acpi team)
<bdmurray> BenC: okay thanks
<eean> BenC:  another user told me they had the same problem
<eean>  /etc/initramfs/modules doesn't have what it needs apparently
<BenC> eean: Then they probably need the same kernel update :)
<eean> its not a kernel issue
<eean> he couldn't boot any of his kernels
<BenC> not having modules doesn't cause a kernel panic
<bdmurray> the bug I was looking at was bug 98793
<eean> yes it does
<eean> if you can't access the hard drive
<BenC> eean: yes, I know, there was a kernel oops that was causing people to drop to a busybox shell
<pkl_> eean: as BenC says it may be a libata problem. However, if you replaced your grub, and/or updated your fstab, this could also cause problems.
<eean> even without a root=?
<eean> I might have replaced my grub
<eean> I updated feisty 
<BenC> eean: if there's no root= in the kernel command line, then that's a whole different issue
<eean> a bunch of packages
<BenC> not even related initramfs modules
<eean> BenC: no I mean, can you get a busybox without a valid root
<BenC> yes
<eean> BenC: ok, but .20-12 was working for me before
<eean> I had booted from it several times
<pkl_> eean: you have to check any files using /dev/hdx have been correctly changed to /dev/sdx (or use labels).
<BenC> check your /proc/cmdline
<BenC> check dmesg
<BenC> check lsmod, check lspci
<eean> pkl_: my fstab is fine, I've cated it with grub
<eean> lol how do I check dmesg ;)
<BenC> eean: fstab means nothing
<BenC> it's root= in grub's menu.lst that counts for this problem
<eean> I can see dmesg when I boot, but I can't scroll up after a kernel panic
<eean> and I have it set correctly
<BenC> eean: dd if=/proc/kmsg of=/tmp/dmesg bs=1 &
<BenC> eean: Then you can more /tmp/dmesg
<eean> with what?!
<eean> kernel panic!
<BenC> if it's a kernel panic, then you aren't at a busy box shell
<eean> no shit ;)
<BenC> then you are arguing the wrong case
<BenC> if the kernel complains "panic: no root, check root=" or some such, then you aren't even passing it an initramfs
<eean> yes I am :|
<eean> I see it in grub
<BenC> then the initrd is broken
<BenC> sudo update-initramfs -u
<eean> yes thats what the other use told me to do
<eean> other *user
<eean> like I said, I don't think its a kernel issue
<eean> can I burn cd iso on to dvd-r's?
<pkl_> can you take a digital photo of the problem, and raise a bug.
<eean> suppose I could
<eean> wait no, my digital camera doesn't work
<BenC> it's not a bug in the kernel for sure
<pkl_> mobile phone with camera capability?
<BenC> eean: did you run the update-initramfs command? or do you not have an older kernel to boot from?
<eean> it costs some unreasonable amount to email them and I don't have a connector :)
<eean> BenC: I don't have an older kernel to run from
<newz2000> hi crimsun, was wondering if you may be able to help me with bug # 92171 sometime when you have a chance
<eean> why I need to burn a cd
<eean> but I have no cd-r's :)
<eean> just dvd-rs
<BenC> eean: dvd-r should work so long as the drive in that system can read them
<eean> well sure
<eean> I wonder if I could do a network boot, that would be nifty...
<pkl_> network boots are not trivial at the best of times, especially if you don't actually know what's gone wrong :)
<eean> oh well I won't try too hard ;)
<pkl_> best to use boot from a liveCD.
<bdmurray> BenC: the bug I was looking at was 98793 what should that be a dupe of?
<BenC> bdmurray: Please assign bugs to ubuntu-kernel-team once you Confirm them
<BenC> bdmurray: I'll check for the dupe in a sec
<eean> BenC: well k3b says it has to be a cd-r :/
<BenC> eean: cdrecord dev=/dev/scd0 foo.iso
<eean> heh ok, I hope you know better then k3b :)
<eean> yea it errored out before writing
<eean> what should be in my /etc/initramfs-tools/modules
<eean> ?
<BenC> eean: nothing
<BenC> crimsun: patches applied
<BenC> eean: /etc/initramfs-tools/initramfs.conf should have MODULES=most
<BenC> your problem has nothing to do with missing modules anyway
<eean> but update-initramfs will work anyways?
<BenC> that's how Ubuntu works by default
<eean> well it didn't have MODULES=most
<BenC> what did it have?
<eean> nothing
<eean> just comments
<BenC> egrep -v '^(#|$)' /etc/initramfs-tools/initramfs.conf
<BenC> Can you show me the output of that command?
<eean> already rebooting, just a sec if it doesn't work
<eean> ok not working :)
<eean> well this will take a while actually, gentoo's install cd takes a while
<eean> BenC:  MODULES=most, BUSYBOX=y, DEVICE=eth0, NFSROOT=auto
<eean> except on seperate lines of course
<BenC> eean: Then it doesn't have just comments
<BenC> eean: ls -l /boot/initrd.img-*
<eean> we're talking about two different files ;)
<BenC> BenC> eean: /etc/initramfs-tools/initramfs.conf should have MODULES=most
<BenC> no, I was talking about that file
<eean> ah
<eean> well that wasn't my question
<eean> anyways, its workign now :)
<BenC> so it booted properly?
<eean> yes
<BenC> ok
<eean> could be the extra modules I added to the modules file
<eean> or maybe just running it again
<BenC> has nothing to do with that
<BenC> that panic wont happen because of missing modules
<eean> so just running it again then
<BenC> it's because the initramfs didn't mount
<BenC> right, most likely
<eean> before I didn't mount /boot into my chroot
<eean> so running update-initramfs did nothing :)
<BenC> yeah, that'll do it too :)
<BenC> make sure you have enough freespace on your /boot
<BenC> that can cause improper initrd.img creation as well
<eean> yes there's like 40mb free
<eean> I wonder what caused the issue to begin with
<BenC> if it fails, then the install/update will tell you
<BenC> could have been a million things
<BenC> just keep an eye on it, if it happens again try to collect as much info as possible about your setup and anything leading up to it
<eean> ok
<BenC> mjg59: ping...memstick is running out of time :)
<bdmurray> Are there multiple chipsets that use ipw3945?
<BenC> bdmurray: there's only two PCI ID's that can use ipw3945
<BenC> both are called "Intel Pro Wireless 3945"
<bdmurray> I've seen some bugs regarding the ipw3945 but my laptop with one seems fine
<BenC> 9 times out of 10, it's because they don't have linux-restricted-modules-2.6.20-xx-generic installed
<BenC> have them do "sudo apt-get install linux-generic linux-image-generic linux-restricted-modules-generic"
<BenC> those meta packages will make sure they work over updates
<bdmurray> okay
<JanC> I have been talking with several other people about feisty, and one thing that (almost) everybody seems to see is that there is more "stuttering" of applications compared to previous Ubuntu-versions
<JanC> did anything in the kernel change which could cause that ?
<Mithrandir> JanC: we have an libX11 fix which should fix most of that, I think.  At least if this is for X apps.
<JanC> this is mostly a feeling, as nobody has exact data on this (how could we get that?), but considering that I have seen so many people express this...
<JanC> hm, it might be only for X apps
<JanC> if music/media players can be infected because they use X
<Mithrandir> bug #88815 might be the one.
<Mithrandir> if you're on i386, can you try tepsipakki's packages from http://users.tkk.fi/~tjaalton/dpkg/ and see if they help for you?
<JanC> personally I even see this when doing upgrades using synaptic, which may cause other applications to stall since using feisty...
<JanC> I'm using the i386 -generic kernel yes
<JanC> I'll try that
<Mithrandir> thanks.
<JanC> hm, will that work with a closed source driver ?
<Mithrandir> shouldn't matter.
<crimsun> newz2000: I'll do some alsa triaging tonight - been very busy this week
<newz2000> crimsun: no doubt. Let me know what I can do to help. I'm obviously very interested in getting my sound back and am eager to help.
<newz2000> For me, this is a show stopper and I will likely go back to Edgy if thats whats needed to have sound.
<Lure> crimsun: do you also look at sound issues after resume, like bug 94036 ?
<crimsun> Lure: it's lower priority atm, but eventually
<Lure> crimsun: ok, no problem - let me know if more info or testing with patched kernel is required
<JanC> Mithrandir: this seems to make a *real* difference
<Mithrandir> JanC: it made your system much happier?
* JanC is now listening to music without hickups while under a system load of > 5
<Mithrandir> tepsipakki: ^^
<JanC> I can ask some other people to test if you want
<Mithrandir> if you'd like, but please make sure to add your experiences on the bug.
<JanC> hm, what was the bug # again  :)
<Mithrandir> 88815
#ubuntu-kernel 2007-03-31
<Simira> Lure: still no progress with the hibernation-bugs?
<tritium> BenC: I spoke too soon on my success with the latest atheros driver.
<rambo3> need help with passing argument to module . i have added argument for e100 module in /etc/modprobe.d/options with option e100 eeprom_bad_csum_allow=1 . and its not picking it up on boot . what have i forgot
<maks_> update-initramfs -u
<maks_> nic's are loaded in initramfs
<rambo3> thanks
<^^CatTuX^^> Hi! i need some help. actually i am willing to create a linux for educational purpose and i am using LFS as my standard, cna i use ubuntu 6.06 Kernel as base?
<Mithrandir> yes, but wouldn't it make more sense to join forces with edubuntu?
<_ion> Hi
<_ion> Is there a VCS branch for linux-restricted-modules development?
#ubuntu-kernel 2007-04-01
<swimmerino88> hi!i'm writing from italy...but in italy we don't have a channel who can speak of the kernel...I have just installed the last kernel from kernel.org...now,when i boot my computer i receive a kernel bug
<swimmerino88> the bug says... "bug:8254 timer not connected to io-apci" what does it means?what to i have to do?
<swimmerino88> is here somebody?
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-14.22 Uploaded - If you aren't using it, then you risk your bugs not getting fixed. | BUG STATUS (2.6.20): 352 Open, 6 Unconfirmed, 6 Unassigned
#ubuntu-kernel 2008-03-24
<lyhana8> hi, is it ok to blacklist intel_rng ? to solve the boot slowing ?
<BenC> Good morning people
<alex_joni> hi BenC 
<animefan> Hi
<animefan> where can I get older ubuntu development kernels?
<animefan> the mirrors I checked have only the most recent one
<alex_joni> source or package?
<animefan> source
<BenC> animefan: About the only way is to access the git repo
<alex_joni> look around launchpad
<alex_joni> or in git
<BenC> or launchpad, true
<BenC> git repo is tagged per upload
<animefan> the reason is kernel 2.6.24-12 breaks a lot on my notebook and i want to debug it further before reporting
<alex_joni> https://launchpad.net/ubuntu/hardy/+source/linux/+builds
<alex_joni> sorry.. without the +builds
<alex_joni> animefan: looking for a certain version?
<alex_joni> https://launchpad.net/ubuntu/hardy/+source/linux/2.6.24-7.12 <- one I needed at some point, not sure how to find other versions without entering the exact numbers
<animefan> last working version was 2.6.24-11.17, then I updated to 2.6.24-12.22, which breaks readeonfb/suspend/xorg
<alex_joni> https://launchpad.net/ubuntu/hardy/+source/linux/2.6.24-11.17
<mjg59> radeonfb should be fixed in the next upload
<animefan> I'm looking through changelog to find a suspected breakage
<animefan> ah, is radeon known to be broken?
<mjg59> Yes
<mjg59> I've no idea what's up with your suspend/xorg issues
<animefan> radeonfb is absolutely needed for resuming, so without it I can't resume. Besides that starting xorg with radeonfb lets my notebook reboot
<cradek> I'm currently building the fb fix
<cradek> will let you know soon
<animefan> Is there a bug I can look up and read about the known issues?
<cradek> bug 201591
<ubotu> Launchpad bug 201591 in linux "atyfb regression - screen blank except for blinking cursor after fbcon vtswitch " [Undecided,Confirmed] https://launchpad.net/bugs/201591
<animefan> thanks, I will check it
<animefan> I'll come back in few minutes .... must go and pick up my girl friend ...
<cradek> mjg59: your patch fixes the bug for me
<cradek> mjg59: thank you
<mjg59> cradek: Excellent
<butt3rz> anyone around
<bullgard4> me.
<smb> BenC: Ben, would it be ok if I now add the patches required to deal with bug 198619?
<ubotu> Launchpad bug 198619 in linux "USB stress test failure on AMD SB600" [Medium,In progress] https://launchpad.net/bugs/198619
<BenC> smb: Yes
<smb> BenC: Ok, good. Then I go ahead. 
<amitk> smb: Canada isn't off today?
<smb> amitk: Partially. Only one day is granted. The other only optional. I took mine on Friday
<amitk> aah
<amitk> same with the US?
<smb> Might be different. I am even unsure whether it is the same in all Canada or whether Quebec is special there
<majost> So I am stuck using Dapper for a turnkey product.... and I have been forced to backport some ALSA stuff. I am wondering if anyone here could assist me with the abichecker or point me to some information on how to do ABI bumps for the 2.6.15 dapper kernel.
<majost> I suppose my question should be... is the information at https://wiki.ubuntu.com/KernelMaintenance   relevent to dapper. =P heh
#ubuntu-kernel 2008-03-25
<kraut> moin
<BenC> Good morning kernel folks
<cking> Morning BenC
<amitk> Morning BenC 
<tjaalton> BenC: hey, could you drop the commit mentioned on bug 197929?
<ubotu> Launchpad bug 197929 in linux "Backlight adjustment no longer works on Thinkpad X61s" [Medium,Triaged] https://launchpad.net/bugs/197929
<BenC> tjaalton: We have a fix in git for that, I believe
<tjaalton> BenC: oh cool
<BenC> mjg59: The backlight patch you sent to kernel-team@ a few days ago, does it fix 197929?
<mjg59> No
<mjg59> Completey unrelated. The one mentioned in 197929 should be reverted.
<BenC> mjg59: Ok, thanks
<mjg59> BenC: Based on the comment that #201591 is causing freezes when changing to X, I think we want that for hardy
<mjg59> BenC: If another l-u-m upload is going to happen, #147087 would be nice to fix instead of having to direct people to some wiki page
<BenC> mjg59: 201591 is already milestoned for release
<buttterz> morning
<BenC> mjg59: Added 147087
<mjg59> BenC: Thanks
<BenC> amitk, smb: These are the bugs we should be looking at (filter to the ones assigned to kernel team) https://launchpad.net/ubuntu/+milestone/ubuntu-8.04
<smb> BenC: ok
<buttterz> hello, i am interested in helping on the kernel side of the house -- i'm new to ubuntu and have read some of your documentation concerning contributions -- any recommendations
<BenC> buttterz: The URL I pasted above is most interesting at this point
<buttterz> BenC , i figured as much :) so i was going to look into that anyways for giggles
<BenC> hmm, I'm not sure what to do with this ralink driver problem
<BenC> disabling the in-kernel drivers and moving the serial monkey stuff to lum seems like the right approach
<buttterz> BenC , there has also been a few rumblings about wireless in +1 
<buttterz> i was considering looking into that today -- i'm off for the week so i have some time
<BenC> in +1?
<buttterz> the testing channel
<buttterz> for heron
<tjaalton> hmm, something between -8 -> -10 broke hibernate on thinkpad X61, the laptop is not powered off
<buttterz> tjaalton , i heard that too -- my buddy has been working on that because he has one i have a toughbook though so its not been an issue
<tjaalton> buttterz: cool.. the hibernation itself works, ie. it resumes correctly etc
<buttterz> but you are referring to the physical state of the machine correct?
<tjaalton> yes
<mjg59> tjaalton: And it works if you revert to -8?
<tjaalton> mjg59: yes. I wonder if the drm changes broke it
<tjaalton> I don't have -9 around
<mjg59> Hm. Possible. Easiest way to tell would be to move i915 out of the way
<tjaalton> cool, I'll try
<mjg59> X will start without it, and that avoids DRM being an issue
<tjaalton> yep, that did it
<mjg59> Ok, cool
<mjg59> Can you boot with the kernel option no_console_suspend
<mjg59> And without quiet
<mjg59> And see whether you get any interesting kernel output when it hangs?
<smb> BenC: call?
<tjaalton> mjg59: sure, one sec
<tjaalton> mjg59: 2x "[ xxx ] drm_sysfs_suspend" is all I see
<tjaalton> hmm, seems that bug 197064 is related
<ubotu> Launchpad bug 197064 in linux "Hibernate fails on Centrino-laptop" [Medium,Triaged] https://launchpad.net/bugs/197064
<mjg59> tjaalton: Hm. Ok, interesting. Is the machine hard frozen at that point?
<tjaalton> yep, feels like it
<mjg59> tjaalton: Ah, hang on. Might have something
<tjaalton> also, there's a patch upstream: http://lkml.org/lkml/2008/2/23/269
<mjg59> Yeah, that's what I was just looking at
<mjg59> Could you give it a go with that?
<tjaalton> yeah, I'll build a new kernel from git
<mjg59> Sweet
<BenC> tjaalton, mjg59: if that works, I'll target it for release
<johanbr> Is there any chance the one-line patch from bug #39414 could be applied? Without it, headsets will be unusable for many people.
<ubotu> Launchpad bug 39414 in linux-source-2.6.15 "syslog is flooded with messages after connecting bluetooth usb dongle" [High,Fix released] https://launchpad.net/bugs/39414
<BenC> johanbr: For dapper or hardy?
<johanbr> Hardy.
<alex_joni> sounds assigned wrong (2.6.15..)
<BenC> johanbr: That patch looks a little scary
<BenC> johanbr: Is that in upstream kernel?
<johanbr> Really? It's just a one-liner that turns off eSCO.
<BenC> johanbr: it hardcodes SCO_LINK for everything, which to me is pretty scary :)
<johanbr> No, it's not upstream yet. Marcel Holtmann had a patch, but the fix is buggy. No proper fix exists.
<BenC> if there isn't a proper fix, I don't want to apply one that may be buggier than the original code
<mjg59> BenC: It's disabling a feature which is buggy
<johanbr> Right now, SCO does not work at all when talking to devices without eSCO support. I can't see how the patch could be buggier than that.
<BenC> mayeb I'd feel better if I knew the difference between SCO/ESCO
<mjg59> So the choice is really whether we support the buggy feature, or disable it
<BenC> do ESCO devices support being used as SCO-only?
<johanbr> Basically, eSCO allows retransmission of lost packets.
<mjg59> Yes, esco is supposed to be backwards compatible
<BenC> ah, then that's less scary
<johanbr> BenC: There is also another patch in the bug that reverts the state to exactly what was there before, if you prefer that.
<BenC> the one-liner is preferred at this point (beta/release)
<johanbr> See also http://bugzilla.kernel.org/show_bug.cgi?id=9871
<ubotu> bugzilla.kernel.org bug 9871 in Network "hci0 SCO packet for unknown connection handle 1" [Normal,New] 
<BenC> marked for release now
<johanbr> Wonderful. Thank you.
<elmargol> Hi, BenC do you have a minute?
<elmargol> You changes bug #183928 to fix commited... somehow I don't see how you fixed this :/
<ubotu> Launchpad bug 183928 in network-manager "update iwlwifi to latest version" [Medium,Confirmed] https://launchpad.net/bugs/183928
<BenC> elmargol: How do you now see how I updated iwlwifi to the latest version?
<BenC> *not
<elmargol> BenC: last version is from 03/11
<BenC> elmargol: Latest iwlwifi is 1.2.25 from 02/04
<BenC> amitk, cking, smb: ping
<smb> BenC: ack
<amitk> ack
<BenC> Well, let's get started
<smb> ok
<BenC> Not much to discuss other than wanted to make sure we focus on release milestoned bugs at https://launchpad.net/ubuntu/+milestone/ubuntu-8.04
<BenC> Final kernel upload is scheduled for 4-7/4-10, but I think we want to make sure to hit that on the early side (that's the latest)
<BenC> smb, amitk: Anything you've come across that you think is extremely important for release?
<BenC> mjg59: Same question for you ^^
<mjg59> Nothing further I'm aware of
<BenC> So far, all the bugs I've seen are "let's try to get it fixed for release", but none should really hold up the release
<smb> BenC: Nothing in that category. 
<amitk> BenC: bug 197929, haven't had a chance to revert the patch though
<ubotu> Launchpad bug 197929 in linux "Backlight adjustment no longer works on Thinkpad X61s" [Medium,Triaged] https://launchpad.net/bugs/197929
<BenC> amitk: Right, that one is milestoned for release, so should be on the list
<BenC> 197929 seems to be the most important
<BenC> anyone had a chance to look at ralink wireless drivers yet?
<smb> The fix (but thats sauce) to 140511 might be "nice to have" and it should not be intrusive
<smb> no not yet
<BenC> bug #140511
<ubotu> Launchpad bug 140511 in linux "Belkin USB bluetooth device loads wrong module" [Medium,In progress] https://launchpad.net/bugs/140511
<BenC> smb: If you think it's could be done for release, and is warranted, milestone it
<smb> BenC: ok
<BenC> Ok, anything else from anyone?
<BenC> Great, thanks everyone
<tjaalton> BenC, mjg59: the patch worked fine, my laptop powers down again when hibernating :)
<tjaalton> I wanted to try the wlan-led patch as well, but that should be applied on top of lum?
<mjg59> tjaalton: Sweet. Can you attach it to the bug if it's not there already?
<tjaalton> mjg59: sure
<mjg59> tjaalton: Winning, thanks
<tjaalton> that commit was already mentioned, but it needs a patch to fix a compile error
<JanC> hm, do I understand correctly that Ralink wireless is finally supposed to be fixed after 4 years ?  or will it only be "less bad" in hardy ?
<buttterz> hey all, is there a real reason we don't supply seperatly patched kernels? say prepatches and andrew morton patches -- i know this is a release base OS but as an option?
<adinc> is someone involved to the bug 185470 regarding the iwl3945 kernel module for intels wireless 3945 device ?
<ubotu> Launchpad bug 185470 in linux "iwl3945 not functioning : microcode error" [Unknown,In progress] https://launchpad.net/bugs/185470
<adinc> there are many some people using this device, specially with notebooks, since hardy comes with this kernel module and has problems with microcode SW error i would like to ask if this can be expected to be solved with the release of hardy?
<tjaalton> adinc: you mentioned that you are willing to test any fixes if needed, so add those upstream patches to the current version and build it. the wiki-page has all the instructions
<adinc> yes
<adinc> i'm new to ubuntu, if you can point me to the said wiki page i can do the testing
<adinc> and which patches are we talking about?
<tjaalton> adinc: https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
<tjaalton> adinc: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/185470/comments/25
<ubotu> Launchpad bug 185470 in linux "iwl3945 not functioning : microcode error" [Unknown,In progress] 
<adinc> tjaalton: i see, but i'm not familiar with the term upstream patch
<tjaalton> adinc: ok, in that case just wait for someone to test it
<adinc> tjaalton: but this can not be that complicated, aren't there patches available? applying the patches and compiling it is not that difficult
<tjaalton> adinc: you'd need to dig them up from git.kernel.org
<adinc> ok
<adinc> with upstream patch, you were trying to say patches from the developer below ubuntu, the kernel patches
<adinc> ok, thank you very much so far
<tjaalton> ah, right
#ubuntu-kernel 2008-03-26
<JanC> adinc: I have a laptop that uses iwl3945 fine, so I wonder what your issue is exactly...
<JanC> (what your issue is exactly caused by)
<adinc> JanC: it is not only my issue
<JanC> yeah, I saw the bug
<adinc> the problem is described in the bug 185470
<ubotu> Launchpad bug 185470 in linux "iwl3945 not functioning : microcode error" [Unknown,In progress] https://launchpad.net/bugs/185470
<adinc> JanC: so i wonder how this device works for you
<JanC> but it works fine for me, so I guess the driver can work properly
<adinc> that would be great
<JanC> maybe it's just not working fine on some variations or combinatiosn with other hardware?
<adinc> but unfortunately it doesn't here, i'm just downlaoding the kernel sources in order to make use of the bugfix from mohamed abbas
<adinc> JanC: possible, but how should we figure this out, i'm not very well involved into driver programming for wireless devices. we wouldneed to do a lot of work, theonly ones who could do this actually are the developers
<adinc> of this driver
<adinc> cool the kernel now supports hsdpa
<JanC> I guess the Intel developers, with some help of the Ubuntu kernel developers, would be the best people to investigate  ;)
<adinc> yes, you are right, but as i can see there is already work done.
<JanC> might be, looking at that comment
<adinc> JanC: which kernel version are you running?
<adinc> comment 25
<JanC> latest hardy kernel available this afternoon (8 hours ago or so)
<JanC> maybe 10h
<adinc> there hasn't beeen any kernel changes in hardy, was there?
<adinc> if you do a uname -a, what do you get?
<JanC> I haven't checked in the last 8-12h  ;)
<JanC> let's check on my laptop
<JanC> kernel build based on linux-meta 2.6.24.12.13, which seems to be the last (according to packages.ubuntu.com)
<adinc> i've 2.6.24-12-generic
<JanC> yeah, that's what uname says
<adinc> so your kernel is 2.6.24-12-generic?
<JanC> uhu
<adinc> i suppose uhu means yes
<JanC> yes ã
<adinc> i don't know the numbering you showed above, there must be a mistake in your kernel versioning scheme
<JanC> my laptop seems to have a 3945 "rev 2" wireless with PCI-ID 8086:4222 
<JanC> the version number I showed is for the kernel meta package--it shows the internal build number used by the Ubuntu kernel developers I suppose
<adinc> http://packages.ubuntu.com/hardy/allpackages
<adinc> here are the kernel packages listed
<JanC> linux-meta is the source package (it's called "meta" because it builds several different kernals)
<JanC> see http://packages.ubuntu.com/hardy/linux-generic and then in the bar at the right
<JanC> anyway, it's just an internal Ubuntu kernel version number
<adinc> i see
<adinc> is there a way to see when the latest kernel was published for ubuntu hardy?
<JanC> http://packages.ubuntu.com/source/hardy/linux-meta should be pretty up-to-date
<JanC> otherwise, if you update hardy from the main servers, it should be obvious  :-)
<adinc> a dist-upgrade i suppose would download the latest kernel build, wouldn't it
<JanC> yes, it should
<JanC> what device ID does 'lspci -nn' give for your wireless?
<JanC> or 'lspci -n' maybe
<adinc> 8086:4222
<JanC> hm, so it's supposed to be exactly the same hardware
<adinc> yes
<adinc> JanC: have you got a smp kernel?
<adinc> somehow a dual core or more than one cpu?
<JanC> the -generic kernel is SMP  ã
<JanC> and I have a Core Duo, so it's actually using SMP too
<JanC> fro mthe upstream bug report: """Guess what... I enabled the iwl3945 debugging (and disabled CGROUPS to get system back to usable state), and problem is no longer reproducible easily."""
<JanC> sounds like a fun bug to "debug" that way  ;-)
<adinc> i'm compiling the kernel now.
<adinc> does he mean debugging enabled by adding something like debug=0x44444 for modprobe iwl3945
<JanC> something like that
<adinc> what about cgroups?
<JanC> if I understand things correctly (but I am not a kernel devloper in any way), it seems like the firmware crashes or gives errors when it's under load (sometimes)
<adinc> i think that is a different bug
<adinc> when the module loads a firmware, which is the case when the device is configured, then the problem appears
<Ng> has the behaviour of cpu frequency scaling intentionally changed since <=gutsy?
<Ng>  /sys/devices/system/cpu/cpu1/cpufreq is a symlink to cpu0/cpufreq
<Ng> (which gets lost on suspend/resume because we save the value of each and then reset it to performance for the actual suspend)
<Ng> bug #162652
<ubotu> Launchpad bug 162652 in pm-utils "pm-utils changes default cpu policy after resuming from suspend-to-ram" [Undecided,Confirmed] https://launchpad.net/bugs/162652
<kraut> moin
<adinc> can someone have a look into the kernel config file of hardies kernel if it has a driver compiled in called IWL3945, for config-2.6.24-12-generic
<soren> soren@butch:~$ grep IWL /boot/config-2.6.24-12-generic 
<soren> # CONFIG_IWLWIFI is not set
<soren> soren@butch:~$
<soren> adinc: ^^
<pwnguin> your server names are strange ;)
<adinc> soren: sorry?
<adinc> i see
<adinc> well but what about this bug 185470 then
<ubotu> Launchpad bug 185470 in linux "iwl3945 not functioning : microcode error" [Unknown,In progress] https://launchpad.net/bugs/185470
<adinc> so this module is not even enabled
<adinc> soren: could you please have a look for me if this module exists in your /lib/modules/2.6.24-12-generic/ubuntu/wireless/iwlwifi/iwlwifi/compatible/iwl3945.ko
<soren> adinc: It's probably in linux-ubuntu-modules.
<adinc> soren: but still it would need to be enabled in the kernel
<adinc> the .config file should show that this module is enabled or not, valid for the whole kernel
<soren> adinc: Erm.. no?
<adinc> no?
<soren> lum has it's own config.
<adinc> lum?
<soren> s/it's/its/
<adinc> what is lum?
<soren> linux-ubuntu-modules
<pwnguin> isn't ubuntu kernel packaging fun?
<adinc> soren: can you please tell me where this config is?
<soren> I'm laughing on the inside.
<adinc> i'm new to ubuntu
<soren> It's in git.
<adinc> pwnguin: looks like...
<soren> I don't know if it's installed anywhere.
<adinc> soren: ok, how can i get it
<adinc> with git
<adinc> i mean where from
<soren> WEll, you can use look at it through gitweb?
<soren> http://kernel.ubuntu.com
<adinc> i don't know why this is done this way, but makes look through more complicated
<adinc> so we won't be able to compile the same kernel here withouth this config file
<soren> The main repo tracks the upstream kernel + a few patches here and there. Extra drivers that we add are in lum.
<pwnguin> apt-get source should help you
<adinc> what does lum mean
<pwnguin> Linux
<pwnguin> Ubuntu
<pwnguin> Modules
<pwnguin> its a package
<adinc> ohh
 * soren chuckles
<soren> 09:05:37 < adinc> what is lum?
<soren> 09:05:40 < soren> linux-ubuntu-modules
<adinc> yes, but i didn't realize this was the shortened way for linux-ubuntu-modules
<adinc> my mistake
<adinc> ;)
<soren> No worries.
<alex_joni> adinc: as an exercise you'll have to figure out lrm by yourself :P
<pwnguin> heh
<pwnguin> Is there a published guide to rebuilding the ubuntu kernel packages, for sysadmins and beginning hackers?
<pwnguin> i used to build my own kernel years ago on debian, but its become so much more complicated
<alex_joni> there is a guide around wiki.ubuntu.com
<adinc> https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
<alex_joni> pwnguin: actually it's a bit easier once you know the steps to do it :)
<alex_joni> I never had a thing for make-kpkg :)
<pwnguin> i liked make kpkg
<pwnguin> much easier to revert when i screw up things
<alex_joni> pwnguin: oh, it still builds debs which you install
<alex_joni> and revert easily
<alex_joni> but not using make-kpkg, using debian/rules from the ubuntu linux source
<pwnguin> the wiki page adinc pointed out uses make-pkg =/
<abogani> https://wiki.ubuntu.com/KernelMaintenanceStarter 
<abogani> make-pkg isn't support at all
<adinc> no, he means make-kpkg
<alex_joni> look at https://help.ubuntu.com/community/Kernel/Compile
<chaosmaster> Hi
<chaosmaster> I've done some pm-utils and suspend testing over the holidays and found an issue with resuming on my Samsung P35 notebook and radeon 9700 (r300) based card.
<chaosmaster> In contrast to current ubuntu practice radeonfb is *absolutely* needed for working resume
<chaosmaster> anyone interested?
<alex_joni> chaosmaster: there was a bug related to this reported at launchpad.net, I'd suggest you search there first
<chaosmaster> "[Bug 201591] atyfb regression - screen blank except for blinking cursor after fbcon vtswitch"  is another issue and I already commented it
<ubotu> Launchpad bug 201591 in linux "atyfb regression - screen blank except for blinking cursor after fbcon vtswitch " [Medium,In progress] https://launchpad.net/bugs/201591
<alex_joni> did you try the recent fix?
<chaosmaster> "81722 Laptop sometimes fails to resume from ACPI S3 suspend"  is the only one mentioning radeonfb with resume/suspend and mentions another issue
<alex_joni> the one from mjg on the 23.03.2008 ?
<alex_joni> chaosmaster: then I suggest you file a new bug report for the issue you're having :)
<chaosmaster> yes, I patched my kernel - without radeonfb breaks completely
<chaosmaster> I wanted to ask about the ubuntu policy in not allowing any framebuffer drivers, as they are blacklisted
<chaosmaster> alex_joni: for which component - the kernel?
<alex_joni> chaosmaster: sorry, not in a real position to be more precise.. :(
<chaosmaster> alex_joni: OK, I'll file a new bug
<soren> I have a laptop that since upgrading to hardy doesn't suspend nor hibernate anymore. Both end up with a blank vt with a blinking cursor in the top left corner. AFAICS, all the quirks listed on the pm-{suspend,hibernate,suspend-hybrid} man page deal with the resuming process..
<soren> ..so I'm at a bit of a loss. What to do?
<chaosmaster> soren: what laptop do you use and what is your graphics card?
<soren> I believe it's called a Uniwill something-something. It's got Intel graphics.
<soren> Suspend and hibernate have both worked flawlessly since breezy on it, afair.
<soren> Hm... I could try booting the gutsy kernel.
<chaosmaster> soren: please paste the output of: lspci | grep VGA
<soren> That might provide a hint as to whether it's a pm-utils issue or a kernel on.e
<chaosmaster> soren: not really :)
<soren> Why?
<soren> It's an intel 855.
<soren> chaosmaster: Why couldn't booting an older kernel provide a hint as to whether it's a pm-utils issue or a kernel one?
<chaosmaster> soren: the suspend/resume process is very delicate and complex with a lot of parts beeing integrated. in Hardy a lot of new technologies (kerne, xorg, pm-utils) are updated so it's not that easy to pinpoint it to a single part
<soren> Er... Sure it is.
<soren> Don't start X, boot an older kernel, and presto! All you've got left is the new pm-utils.
<adinc> does someone know how to get the processes below the window with top ? sorry for asking here, but i suppose not many people are using it
<alex_joni> assuming it works with the older kernel
<soren> alex_joni: 09:54:20 < soren> Suspend and hibernate have both worked flawlessly since breezy on it, afair.
<soren> adinc: I don't understand the question?
<elmargol> Where can I ask iwlwifi specific questions?
<chaosmaster> soren: are you ready to test some quirks?
<adinc> soren: if you call top, the process listing application, it shows the processes listed till the bottom of the current window. what do you do in order to see the rest of the processes
<adinc> elmargol: have you got a problem with iwl3945?
<soren> adinc: Stretch the window? :)
<soren> chaosmaster: Which ones, for instance?
<adinc> soren: cool, but i can't find a 24 inch monitor for the time beeing
<elmargol> adinc, yes  I have bug #176271
<ubotu> Launchpad bug 176271 in linux-ubuntu-modules-2.6.24 "major throughput difference (between upload and download) when using iwl3945" [Undecided,Confirmed] https://launchpad.net/bugs/176271
<elmargol> http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1592
<soren> adinc: You can make the window larger than your screen, you know..
<ubotu> bughost.org bug 1592 in data transfer "Speed drops when downloading at high speeds" [Normal,Assigned] 
<adinc> elmargol: do you use hardy
<elmargol> adinc, yes
<chaosmaster> soren: I don't have intel GMA specific knowledge, but vbestate-restore works for me on my ATI radeon 9700 M
<adinc> soren: heheh, but thats not the solution
<adinc> elmargol: so you are one of those lucky guys, you at least get a connection
<soren> chaosmaster: This is hibernation and suspension. Not resuming.
<elmargol> My connection is fast 2-3MB/s after about 100-200MB traffic I get stuck at 1Mbit/s
<chaosmaster> soren: best way is to find the most similar notebook / card and try the quirks listed there
<adinc> do you have kernel 2.6.22 or 2.6.24?
<elmargol> 2.6.24-12-generic
<chaosmaster> soren: suspend is (almost) never the problem - it's always about the resuming
<soren> chaosmaster: Look... vbestate-restore is about loading the vbestate on *resume*.
<soren> chaosmaster: It doesn't suspend!
<chaosmaster> soren: oh, then I misunterstood your problem
<elmargol> I'm using Ben Collins git tree
<adinc> strange, here i can't get it running at all with a samsung q45, but lets wait i'm compiling a fresh git tree
<adinc> see bug 185470
<ubotu> Launchpad bug 185470 in linux "iwl3945 not functioning : microcode error" [Unknown,In progress] https://launchpad.net/bugs/185470
<soren> Just tested with 2.6.22. It suspends just fine.
<soren> It doesn't resume properly, though, but that's just quirks, so that's easy.
<adinc> how is ubuntu managing firmware loading, is it hotplug doing?
<soren> adinc: I belive it's udev.
<adinc> soren: i see
<elmargol> I try iwlwifi HEAD now...
<adinc> those changes should bit in kernel git
<chaosmaster> soren: do you use only ubuntu kernels?
<soren> chaosmaster: Yes.
<adinc> elmargol: what device are you using it
<elmargol> 0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
<adinc> elmargol: same here, whichnotebook is it?
<elmargol> Dell inspiron 9400
<adinc> ohh, my new kernel hangs when loading acpi modules with init
<elmargol> I'm using v1.2.25
<adinc> of what?
<elmargol> iwl3945
<elmargol> thats from 02-04-08
<chaosmaster> soren: if the same system suspends fine just with an older kernel, the you have to try other kernels between 2.6.22-working and 2.6.24-nonworking - the problem is I don't know of any mirror with all older ubuntu versions
<soren> chaosmaster: I know how to use git.
<soren> chaosmaster: I'm just not unambiguously a fan of bisecting as a debugging tool.
<chaosmaster> soren: but then you have to compile them and I tried it yesterday - it was not funny, as I didn't find a way to compile only one flavour. By default debuild compiles -generic -386 -server ....
<soren> I also know my way around Ubuntu's kernel build system by now :)
<soren> Building just a single flavour is even documented on the wiki.
<chaosmaster> soren: so you know more than me :)
<elmargol> Is there a way to have the card in g only mode?
<alex_joni> chaosmaster: iirc it's something like debian/rules binary-image-i386
<BenC> Good morning everyone
<chaosmaster> good morning (even if it's past 12 here in DE) :)
<elmargol> adinc, switching my accesspoint do mode b seems to fix the issue
<elmargol> at least it takes longer to happen
<AnAnt> Hello, will bug #201591 be fixed in next kernel upload ? will it use that patch suggested by Garrett ?
<ubotu> Launchpad bug 201591 in linux "atyfb regression - screen blank except for blinking cursor after fbcon vtswitch " [Medium,In progress] https://launchpad.net/bugs/201591
<soren> mjg59: Maybe you could help me out a bit? I have a laptop where 2.6.22 suspends and hibernates just fine, but on 2.6.24, it fails. I get a blank vt (blinking cursor in the top-left corner) and then it just sits there, never actually suspending or hibernating. I'm happy to fiddle around with the kernel to try to fix it, but do you have a few pointers about where to look?
<mjg59> soren: Did any of the 2.6.24 kernels work?
<soren> mjg59: It's my wife's laptop which I only just upgraded yesterday.
<soren> mjg59: So I've only tried the most recent one, I'm afraid.
<mjg59> soren: Hm. Can you boot with the kernel argument no_console_suspend and without quiet?
<mjg59> Then give it a go
<soren> Sure.
<soren> mjg59: Just to be sure: I call pm-suspend to suspend. That's the way to do it, right?
<mjg59> soren: No.
<soren> Ah.
<mjg59> soren: What desktop are you running?
<soren> I've killed X.
<mjg59> Don't do that
<soren> To keep that out of the equation.
<soren> Hm... Ok. Is it likely to work better with X running? That's surprising.
<mjg59> I suspect it's unrelated to the problem you're having, but please try from X
<soren> WEll, if it matters, I discovered the problem while trying to hibernate from GNOME. Since then, I've used the terminal to make reduce the number of places it could fail.
<soren> ...but ok, I'll try from GNOME.
<soren> mjg59: Oh.
<soren> mjg59: pm-hibernate oopsed.
<soren> i915_suspend
<mjg59> soren: Hm. How about suspend?
<soren> mjg59: I'll try.
<soren> mjg59: ba8bbcf6ff4650712f64c0ef61139c73898e2165 says: "i915: add suspend/resume support". If it didn't have suspend/resume support before, how is it that this laptop used to suspend just fine?
<soren> It has an i855 graphics adapter, by the way.
<mjg59> We attempted to restore graphics state from userspace
<mjg59> Hm. Ok, interesting.
<mjg59> If it oopses on suspend, that's something I'll have to look at
<soren> The i915 driver *is* supposed to handle i855, I suppose?
<mjg59> Yes
<adinc> elmargol, i could get it the connect and request a dns with a new kernel but still i get errors
<adinc> elmargol: is it running without any problems at all now?
<elmargol> no
<elmargol> Its the same... this was just random (
<adinc> `so same here, i'm sure this is nothing we can solve
<adinc> only the developer of this driver can do this
<elmargol> And i was thinking intel wireless cards are well supported :(
<adinc> or someone who is involved in developing this module
<tjaalton> soren: I debugged that issue yesterday (hibernate fails to power down) :)
<adinc> elmargol: yes, my intention was the same actually when looking to this device
<soren> tjaalton: Any luck?
<tjaalton> soren: yes
<soren> tjaalton: Do tell.
<elmargol> I'm wondering if I can change my wireless card
<tjaalton> soren: see bug 197064
<ubotu> Launchpad bug 197064 in linux "Hibernate fails on Centrino-laptop" [Medium,Triaged] https://launchpad.net/bugs/197064
<tjaalton> it's probably the same
<soren> Might be.
<soren> mjg59: When suspending, I just get a VC with "[  120.351344] drm_sysfs_suspend" and nothing else.
<tjaalton> suspend works here
<soren> mjg59: I can't help but wonder if I mistyped the kernel option..
<mjg59> soren: That's with no_console_suspend?
<soren> mjg59: I think so, but I may have mistyped it. I'll try again.
<mjg59> Ok
<mjg59> And make sure you don't have quiet on the command line
<soren> Sure.
<Ng> soren: is this on your x40?
<soren> /proc/cmdline only lists "root=UUID=blahblahb ro no_console_suspend", so I'll try again.
<soren> Ng: Nope.
<soren> Ng: It might do the same, though. I haven't tried.
<soren> mjg59: Hm... No, I don't get anything but the drm_sysfs_suspend line. After that, it's quiet.
<mjg59> soren: Does alt+sysrq+t print anything at that point?
<soren> mjg59: Nope.
<soren> sysrq+o does power it off, though.
<soren> alt+sysrq+o, that is.
<mjg59> Hm.
<mjg59> I'll see if I can reproduce
<soren> So the kernel's somewhat alive, but I get no VC love.
<mjg59> My X40 is still around somewhere
<soren> mjg59: This is not an X40, though. I realise it's the same graphics card, I'm just saying.
<Ng> soren: purely out of interest, does it work if you call acpi-support's sleep.sh?
<soren> Ng: I doubt it will, but I can try.
<Ng> I get different suspend/resume behaviour between acpi-support and pm-utils. Reading through their scripts last night they seem to do fairly different things
<mjg59> Ng: What sort of different behaviour?
<Ng> mjg59: well specifically for me I need to unload e1000 for suspend to work, which acpi-support did because it seems to unload all network modules, where pm-utils doesn't unload any modules by default (if I was reading the scripts properly)
<mjg59> Ok. Have you got a bug filed about that?
<Ng> mjg59: I filed one originally about suspend not working, which I've kept updated, bug 201037. It may need to be moved to a different package or so
<ubotu> Launchpad bug 201037 in pm-utils "suspend fails on Thinkpad X300" [Undecided,New] https://launchpad.net/bugs/201037
<Ng> and I guess the description should be more generic
<soren> I've never been able to really figure out if more or less generic is preferred in these cases.
<soren> I'm leaning towards less.
<soren> It's easier to mark a bug a as a dupe than to split it into two.
<Ng> I can't answer that, but I would guess this affects more than just the x300 and it's a fairly significant behaviour change that's very undiscoverable. the price of unloading/reloading networking modules can't be very high, but it may make some weird problems go away.
<Ng> having said that, it just seems like its masking driver bugs
<Ng> anyway, I'll stop hijacking soren's bugtime ;)
<soren> FWIW, I think don't-unload-by-default would be a good idea early in the dev cycle and then switch to unload-by-default at around beta time.
<Ng> I'd buy that for a dollar
<soren> It gives us a chance to spot the issues and perhaps fix them early on, and then switch to the safer approach for the release.
<mjg59> Ng: Ok, I've poked pitti about that. I'll try to hack up a patch later on if I get a chance.
<soren> My not-up-to-date X40 suspends just fine. I'll try getting it current and see if it changes.
<mjg59> soren: Just pull the kernel
<Ng> mjg59: nice, thanks
<soren> mjg59: Alright.
<soren> mjg59: Oh, kernel seems to be up-to-date.
<mjg59> soren: -12?
<soren> uname -a is identical.
<mjg59> Ok
<mjg59> Hrmph.
<soren> pm-utils is not up-to-date, though.
<mjg59> /shouldn't/ matter, but yeah, give it a go
<soren> No, the X40 still suspends just fine.
<mjg59> Bother
<mjg59> Makes it harder for me to try to reproduce, then :)
<soren> Quite.
<mjg59> soren: On the broken machine, can you try moving i915.ko out of the way so it doesn't get loaded?
<soren> mjg59: I could. 
<soren> The bug tjaalton linked to suggested that it'd end up in an infinite loop. I've left the machine alone for a while and the fan is rather quiet, so I have a hunch that's not it.
<soren> mjg59: Without i915, it suspends just fine.
<mjg59> soren: Yeah, the failure we've seen with hibernate shouldn't happen on suspend
<soren> mjg59: Oh?
<mjg59> It's specific to the suspend call being made twice
<mjg59> Which only happens in hibernate
<soren> Oh, ok.
<soren> (hibernate works just fine now, too)
<soren> Why does hibernation cause two calls to the suspend code?
<mjg59> Because it's somewhat broken
<mjg59> soren: Hm. Ok. Anyway, on the off-chance that it's actually the same problem - any chance you can grab the oops on hibernation?
<mjg59> Camera or something would be good
<soren> Sure.
<soren> Just modprobe i915 and recycling X should do the trick, I guess.
<smb> BenC: Morging Ben. One question: I was looking over the milestone bugs and there is one (bug 176090) assigned to Tim which is about iwlwifi. Does it make sense to add LED support (kernel driver would have that but is different version)?
<ubotu> Launchpad bug 176090 in linux-ubuntu-modules-2.6.24 "WiFi / WLAN LED not working on notebooks with Intel iwl4965 | iwl3945" [Medium,Confirmed] https://launchpad.net/bugs/176090
<BenC> smb: Is it just a matter of enabling the right config option?
<soren> mjg59: Hm... Guess not. It looks suspiciously like a font-less vc.
<smb> BenC: No, there is more code change involved
<BenC> smb: looks to me like enabling MAC80211_LEDS would do the trick...what else is there?
<mjg59> soren: Heh. Well, if you can get it again, that would be helpful :)
<soren> mjg59: I'm on it, I'm on it. I think my phone takes decent enough pictures to be useful. Do you happen to know of a relevant bug to attach it to, or should I just throw them somewhere for you to see.
<soren> ?
<smb> BenC: If I am not wrong, it requires *-led.c files in both specific drivers and at least one other file that isn't there right now (something with hbus)
<smb> BenC: if you want a quick look. I just moved the patch that enabled leds to zinc (my home)
<mjg59> soren: Just file a new one for now
<smb> BenC: It might be doable. I just wanted to be sure it is agreed because there there certainly is a reason we use the lum driver and not the kernel version
<chaosmaster> Hi again
<chaosmaster> as mjg59 is here I'm asking again about my suspend issue
<chaosmaster> I've done some pm-utils and suspend testing over the holidays and found an issue with resuming on my Samsung P35 notebook and radeon 9700 (r300) based card. In contrast to current ubuntu practice radeonfb is *absolutely* needed for working resume
<chaosmaster> shall I file a bug for the kernel or another component?
<mjg59> There's not really anything we can do about that case
<chaosmaster> I can't believe I'm the only one with this problem
<soren> mjg59: Will do.
<soren> mjg59: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/207098
<ubotu> Launchpad bug 207098 in linux "i915 drm driver fails to hibernate with certain i855's" [Undecided,New] 
<BenC> smb: Hold off a sec and let me test one thing real quick
<smb> BenC: sure
<BenC> chaosmaster: does it work with fglrx?
<BenC> brb
<BenC> smb: Just pushed that patch out for iwlwifi
<BenC> smb: it was gruesome getting it to apply, but it's there
<chaosmaster> BenC: I never used fglrx
<smb> BenC: Ah, ok. Great
<elmargol> BenC, I'm using your kernel from git. And still have this http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1570 bug. Any chances to get this fixed for hardy?
<ubotu> bughost.org bug 1570 in data transfer "iwl3945 speed capped at 100 kB/sec" [Normal,Assigned] 
<BenC> elmargol: first off, using the kernel wont help anything...you need to use latest lum in git
<BenC> elmargol: second off, I'm using iwl3945, and I don't see any cap...I was just transferring at 1.5M/s
<elmargol> BenC, sorry I mean I'm using your lum tree
<BenC> elmargol: Ah, and I am using 11g, so that explains that part
<elmargol> BenC, works for me too i transfer at 2-3Megabyte/sec after 200M speed drops to 100kb/s
<BenC> elmargol: well, I transferred 1.2gigs, so...
<elmargol> I'm using 11g
<elmargol> BenC, do you use wpa?
<BenC> elmargol: yes
<elmargol> aes or psk?
<elmargol> wpa1 or wpa2
<BenC> wpa tkip
<soren> BenC: You work on the kernel, which is one of the most widely available pieces of software on the planet, and AIUI the only living creatures within miles of you are cows... and you're using WPA.
<BenC> soren: a) I like to test the latest and greatest (for testing sake) and b) I'm paranoid over my bandwidth :)
<BenC> never know what those mad cows will do
<soren> You must be. :)
<mjg59> soren: 2.6.24-12-generic-12.22, right?
<soren> mjg59: Yup.
<BenC> soren: but mainly I worry about my financial transactions over-the-air
<soren> BenC: Yeah, I figured. That spoils the joke, though.
<BenC> elmargol: at 400Megs transfer and still holding at 1.4M/sec
 * lamont` wonders if vmware 6.0.2 works with the current hardy kernel...
<BenC> elmargol: anyway, if latest doesn't fix it, it's not going to get fixed for release
<BenC> lamont: you'll want the vmmon.tar I have on chinstrap
<lamont> thanks
<lamont> hrm... vmmon.tar or vmmon-161/vmmon.tar?
<BenC> try one, if you get an error about mismatched API version, try the other
<elmargol_> BenC, is there a way to set the card to g only mode?
<BenC> elmargol: My AP is set to G-only
<BenC> so that has the same affect, I would think
<AnAnt> Hello, will bug #201591 be fixed in next kernel upload ? will it use that patch suggested by Garrett ?
<ubotu> Launchpad bug 201591 in linux "atyfb regression - screen blank except for blinking cursor after fbcon vtswitch " [Medium,In progress] https://launchpad.net/bugs/201591
<elmargol_> [  131.230353] wmaster0: TKIP decrypt failed for RX frame from 00:16:b6:19:5e:0a (res=-3) :/
<mjg59> BenC: Do you have an M1330 with Intel graphics?
<BenC> mjg59: No, nvidia
<mjg59> Ah, ok
<BenC> I think rtg's is Intel
<BenC> mjg59: might also ask jono, not sure what graphics his has
 * BenC is off to lunch
 * lamont wonders if he should care that the hardy upgrade is gonna nuke restricted-manager
<mjg59> soren: Can you do objdump -d /lib/modules/2.6.24-12-generic/kernel/drivers/char/drm/i915.ko and stick the output somewhere?
<soren> mjg59: Sure.
<Ng> lamont: I think it's called jockey these days
<soren> mjg59: http://people.ubuntu.com/~soren/i915.disassembled.txt
<lamont> ah, of course.
<mjg59> soren: Did you start X, or was this just from the console?
<soren> mjg59: From X as you requested.
<mjg59> soren: Ok, tanks
<mjg59> Thanks
<mjg59> Urgh. h key failure.
<soren> mjg59: i915_suspend+0x51d is the I915_READ(I915REG_INT_IDENTITY_R) call isn't it?
<mjg59> soren: We think it's the FBC reads
<soren> mjg59: Hm.. Ok.
<mjg59> soren: Can you try http://www.codon.org.uk/~mjg59/tmp/915.diff ?
<soren> IS_MOBILE is true for which devices?
<soren> (just curious)
<soren> mjg59: I'm on my way out the door right now, I'm afraid. I'll try it when I get back sometime later this evening.
<mjg59> Should be any of the mobile varients of the chipsets
<mjg59> soren: Cool, thanks
<soren> mjg59: Oh, thank *you* for looking into it. Much appreciated.
<nowhereman> hi everybody
<nowhereman> why are make-kpkg builds so much bigger than their ubuntu own git counterparts?
<nowhereman> I've built 2.6.25-rc7 and it's around 233M
<nowhereman> nvm, found out
<BenC> nowhereman: find /lib/modules/`uname -r` -name \*.ko | sudo xargs strip --strip-debug
<nowhereman> BenC: yes thanks found that out already :)
<sectech> I have an  AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ and athcool doesn't pick up that I have an Athlon... I am running 2.6.24-12-generic... Is there something special that I have to do?
<adinc> is someone her who is involved into bug 185470? i've used a new kernel dig and iwl3945 makes still problems
<ubotu> Launchpad bug 185470 in linux "iwl3945 not functioning : microcode error" [Unknown,In progress] https://launchpad.net/bugs/185470
<soho> is the new kernel 2.6.24-4 with all it's new features (intel 945 stuff etc.) going into hardy final?
<soho> i mean 2.6.24.4
<tjaalton> duh, I don't see any i945 goodness in 24.4
<mjg59> soren: Had a chance to test that patch? :)
<soren> mjg59: I've gotten as far as setting up an i386 chroot to compile it in. Give me half an hour. :)
<mjg59> Ha
<mjg59> Col
<soren> mjg59: Ok, kernel module built. I just need to get my hands on the laptop and try it.
<soren> mjg59: Hm... Different oops.
<soren> mjg59: This time at i915_suspend+0x60.
<soren> mjg59: Actually..
<soren> mjg59: I think that's what it said the first time I saw it, too.
<soren> mjg59: I just thought I was on crack, so didn't think much of it when I saw the oops on the photos.
<mjg59> soren: Hm. Can you try adding similar blocks around some of the other registers?
<soren> mjg59: Any particular ones?
<soren> mjg59: Or just a random (sub)set?
<mjg59> Whichever ones you think it might be oopsing on access to :)
<soren> mjg59: Hm.. In any case, I should be adding similar blocks around the resume code, I suppose.
<soren> but let's deal with that, when we've found the offending ones.
<soren> mjg59: kees and I are looking at the assembler code. We're having trouble making sense of some of it. Well, *I* am, that's for sure.
<mjg59> soren: Heh
<soren> mjg59: A bit before i915_suspend+0x60, there's a "call 1b6", which is one byte into the call instruction.
<soren> wtf?
<mjg59> soren: Hrm. Can you stick the disassembly up somewhere again?
<soren> http://people.ubuntu.com/~soren/i915.disassembled.txt
<mjg59> soren: That's the current module, not the old one?
<soren> keescook: Welcome.
<soren> mjg59: Old one, but that bit's the same.
<keescook> whee
<mjg59> soren: Sure? Ok
<soren> mjg59: Yes.
<soren> I can toss up the new one instead, just to be sure.
<mjg59> soren: Passing it on now
<soren> http://people.ubuntu.com/~soren/i915-new.disassembled.txt
<keescook> fun.  i386 compiler appears to have calculated the relative offset wrong.
<soren> Yeah. Something doesn't smell right.
<mjg59> soren: Hm. You're definitely starting X, right?
<mjg59> And triggering the hibernate with X still running?
<soren> mjg59: Hibernating from X, yes.
<mjg59> Ok, cool
<mjg59> soren: jbarnes is the guy to speak to about this
 * mjg59 goes to play Portal for a bit
<jbarnes> soren: lspci -v somewhere?
<keescook> the disassembly is showing a busted compiler -- a -3 relative jump target is nonsense.
<soren> keescook: But if that was really the problem, I wouldn't be getting invalid page requests, but invalid instructions and shit.
<soren> jbarnes: Hang on, I'll reboot it.
<jbarnes> soren: no it probably wouldn't generate bad opcodes, rather bad memory requests
<jbarnes> and/or might overwrite important stuff
<soren> jbarnes: Did mjg59 mention the weird looking disassembly?
<jbarnes> no, I haven't seen it
<keescook>      192:   e8 fc ff ff ff          call   193 <i915_suspend+0x33>
<keescook>      197:   8d 8e e0 00 00 00       lea    0xe0(%esi),%ecx
<keescook> it's calling into it's own call instruction.
<keescook> amd64 compile of the same code shows a regular self-call thunk (e8 00 00 00 00)
<jbarnes> it's a rel32 call
<keescook> I was about to say -- I can't possibly be right -- the modules are filled with it.
<jbarnes> the loader should fix it up
<soren> I'll probably figure out what that means when I grow up.
<soren> :)
<jbarnes> it's probably calling the palette save routine
<keescook> ooohhhh
<keescook> it's what the prelink targets look like.
<keescook> sorry, I haven't disasm'd .o's before.  I'm used to looking at executables
<soren> http://pastebin.ca/958866
<soren> the lscpi -v (finally)
<jbarnes> ok well not the palette routine (that's befcffff) but something
<sleepster> how do I become a kernel hacker like you guys?
<sleepster> for Ubuntu I mean
<sleepster> would you guys offer any advice on how to learn?  I've read the linux kernel books by O'Reilly
<jbarnes> sleepster: that's a good start
<soren> sleepster: Then you're way ahead of me :)
<jbarnes> kernelnewbies has some good tips too
<jbarnes> beyond that, I'd recommend finding bugs and fixing them
<jbarnes> and don't get too caught up in the janitorial stuff
<soren> jbarnes: I tried  http://www.codon.org.uk/~mjg59/tmp/915.diff, but that seems insufficient.
<sleepster> yeah. I tend to do that.  I wrote my own OS from scratch, so I know a lot of concepts.
<jbarnes> soren: yeah I don't think that's the real issue here
<jbarnes> sleepster: well if you wrote your own OS there's not much I can tell you :)
<sleepster> I just see you guys talk about the Ubuntu kernel stuff in here .. and it seems interesting.. I want to hop on the band wagon
<soren> jbarnes: The new oops is at i915_suspend+0x60, which makes it just before  I915_READ(PIPEACONF);
<jbarnes> is that the pci config space read in your case?
<soren> pci_read_config_byte(dev->pdev, LBB, &dev_priv->saveLBB);
<soren> AFAIUI
<keescook> ah, readelf -r.
<soren> If the oops says it's at i915_suspend+0x60, that's the address immediately *After* whatever failed, right?
<sleepster> can you guys recommend maybe.. an easy device driver I could implement to learn?
<jbarnes> soren: where are the original oopses again?  do you have a complete dmesg from the machine possibly?
<soren> jbarnes: The oops happens as I hibernate, so it's unresponsive after it.
<jbarnes> sleepster: you should look for the linux driver project, gregkh is running that, they have all sorts of hw that needs linux drivers
<soren> jbarnes: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/207098
<ubotu> Launchpad bug 207098 in linux "i915 drm driver fails to hibernate with certain i855's" [High,Triaged] 
<jbarnes> soren: you could try echo test > /sys/power/disk
<jbarnes> then echo disk > /sys/power/state
<jbarnes> but that may not help...
<soren> jbarnes: I've seen two different oops'es.
<soren> jbarnes: The one in the bug and one at i915_suspend+0x60 (but otherwise identical, AFAICS)
<jbarnes> ok, so the actual oops is from the access of dfcef0a4
<sleepster> thanks guys for the info
<sleepster> it's much appreciated
<soren> jbarnes: The what now?
<jbarnes> soren: I think the cause is the "unable to handle paging request at ..."
<jbarnes> and 0xdfcef0a4 is the addr
<soren> jbarnes: How do I translate that into something useful?
<keescook> soren: where is the +0x60 coming from?
<jbarnes> soren: well, looking at the registers, eax has 0xdfced000
<soren> keescook: The monitor on the laptop behing me.
<soren> behind me, even.
<keescook> ah, the photos from 207098 are 0x51d, then?
<jbarnes> and 0xdfcef0a4 - 0xdfced000 = 0x20a4
<jbarnes> which corresponds to 72a:	8b 80 a4 20 00 00    	mov    0x20a4(%eax),%eax
<soren> keescook: Yes.
<jbarnes> which is why I suspected the fbc regs at first, since they're at 0x2xxx
<jbarnes> but now I think your whole register window is getting lost somehow
<soren> I'll see if I can get the +0x60 oops again and take new photos. Gimme a few minutes.
<mjg59> jbarnes: Hm. This is without the diff that ensures suspend only gets usefully called once
<mjg59> (for hibernation)
<mjg59> You don't unmap anything during suspend, do you?
<jbarnes> mjg59: we'll disable the device in the suspend path
<mjg59> jbarnes: Ah. Perhaps that's the issue.
<jbarnes> but it could also be X somehow unmapping the regs
<soren> jbarnes: I did the "echo disk > /sys/power/state ; echo disk > /sys/power/state" thing and then it hanged.
<mjg59> soren: test, rater than disk?
<soren> mjg59: YEs, sorry.
<jbarnes> yeah echo test > /sys/power/disk
<jbarnes> then echo disk > /sys/power/state
<soren> That's what I did.
<jbarnes> but yeah the oops might still cause you to hang
<soren> I did it from X. Perhaps that was optimistic.
<jbarnes> soren: no, that *should* work fine
<jbarnes> but there may be a specific interaction with the versions you have on your system
<soren> Ok.
<soren> test > /sys/power/disk does what?
<jbarnes> it'll make your system hibernate, wait 5 seconds, then resume
<soren> Increse debugging or something?
<jbarnes> w/o actually powering off
<soren> Oh.
<jbarnes> so you can debug things a lot faster
<soren> Ah... Clever.
<jbarnes> but as you discovered, it's only useful in some cases :)
<soren> I got the system back up now... What was I about to try?
<soren> Oh, right. Getting the +0x60 oops again.
#ubuntu-kernel 2008-03-27
<soren> Er... Now it's at i915_suspend+0x7e
<soren> unable to handle kernel paging request at virtual address dfddc040
<jbarnes> soren: and what's in eax?
<soren> dfdd6000
<soren> http://people.ubuntu.com/~soren/i915-new.disassembled.txt by the way
<jbarnes> yeah
<jbarnes> just seems to be happening at random spots while we read registers
<jbarnes> mjg59: are you preparing a multiple suspend fix patch?
<mjg59> jbarnes: I /think/ it's filed
<jbarnes> soren: can you take out the calls to pci_disable_device and pci_set_power_state and see if that helps?
<soren> Sure.
<soren> You're saying this code gets called twice during hibernation?
<jbarnes> yeah
<soren> I can blacklist a module from the kernel commandline, right?
<jbarnes> you can rmmod it first, sure
<soren> Man, this stuff is tedious. patch, compile, boot faulty laptop, copy module, reboot, hibernate.
<soren> Well, if this is a bug due to calling the suspend code twice, it won't fix my suspend problem, I suppose. :(
<soren> (Assuming the double call to the suspend code is not done when it's "just" suspending)
<jbarnes> right, suspend just calls it once
<jbarnes> you see it during suspend too though?
<soren> Now it fails at i915_suspend+0x21d (unable to handle paging request at dfe3501c)
<soren> jbarnes: Nope.
<soren> jbarnes: suspend just fails silently.
<jbarnes> are you using any fb modules?
<jbarnes> like intelfb, uvesafb, vesafb?
<soren> I can't spot any in the list of modules in the oops output.
<jbarnes> ls /sys/modules/fb?
<jbarnes> err /sys/module
<soren> Well, it's hanged right now.
<jbarnes> heh oh yeah
<soren> Do you need more info from the oops output?
<jbarnes> nope
<soren> If not, I can just reboot and look.
<soren> rebooting
<soren> *fb* only matches fbcon
<jbarnes> oh you have fbcon?
<jbarnes> that must mean some other fb stuff is builtin to your kernel
<jbarnes> which kernel are you running?
<soren> The ubuntu one.
<soren> 2.6.24-12-generic
<jbarnes> can you try upstream?  2.6.25-rc7 or so?
<jbarnes> and/or try disabling CONFIG_FB in your current kernel
<jbarnes> soren: also, can you post your lspci -v somewhere?
<soren> jbarnes: I did that an hour ago or thereabouts.
<jbarnes> where?
<soren> 23:41:01 < soren> http://pastebin.ca/958866
<jbarnes> oops missed it sorry
<soren> No worries.
<soren> jbarnes: I think our i915_drv.c matches current upstream..
<soren> jbarnes: Or do you mean the entire kernel?
<jbarnes> I meant the entire kernel... it sounds like your i915 is missing a little according to mjg59
<jbarnes> but mainly I wanted to get the fb stuff out of the equation, you can do that with your current kernel
<jbarnes> if that doesn't work, then upstream would be worth trying, just to isolate it against any ubuntu patches
<soren> Isn't the a kernel command line option to disable fb altogether?
<soren> Like fbcon=no,thankyou?
<jbarnes> dunno how to disable it at runtime
<jbarnes> would be best to rebuild with CONFIG_FB unset
<soren> If I'm using git correctly, our i915_drv.c is identical to Linus's except for a an inb(st01) call in the restore code.
<jbarnes> hm ok
<soren> It's getting late. My debugging skills are starting to fail me :(
<soren> Everything was fine in gutsy, which predates the suspend/resume code in the kernel, afair.
<jbarnes> I should be getting a 855 laptop soon, hopefully I can reproduce & fix
<soren> jbarnes: I have another 855 laptop that doesn't do it.
<jbarnes> soren: yeah, lemme dig up a link
<soren> My Thinkpad X40 suspends/resumes just fine.... I'm not sure if I tried hibernation on it. I forget.
<jbarnes> you could try this patch on your 855
<jbarnes> http://marc.info/?l=linux-kernel&m=120657458816261&w=2
<jbarnes> there are enough weird issues with 855 at this point that it's probably best to disable the suspend/resume code in 2.6.25 for them
<soren> Heh.. Yeah, that'll certainly fix it.
<soren> The X40 even hibernates just fine (with unpatched i915.ko)
<jbarnes> cool
<jbarnes> it's nice when it works :)
<soren> It's just the other laptop. It's spethial.
<jbarnes> but something weird is going on with this... it's like the iomap for the registers is disappearing
<soren> My mom says it's ok to be special. I'm not so sure.
<soren> At random times.
<jbarnes> but iounamp breakage should show up elsewhere too
<soren> Well, if the fb suspend code and the i915 suspend code runs at about the same time, that would explain why it happens at seemingly random times (it fails when the fb code unmaps the registers or whatever).
<jbarnes> yeah
<jbarnes> they shouldn't be happening in parallel though
<jbarnes> anyway, if you get a chance to test w/o fb and it works I'd like to hear about it :)
<jbarnes> otherwise I'll try to reproduce when I get my 855
<soren> Which machine is it?
<jbarnes> it's a dell latitude d500
<soren> Mine's a uniwill something-something (Taiwanese or Korean thing).
<mjg59> jbarnes: No idea why fbcon is getting loaded, but there's no fb stuff in the kernel
<mjg59> And vesafb and intelfb won't bind unless vga= is passed
<jbarnes> ok
<soren> $ grep CONFIG_FB_.*=y /boot/config-2.6.24-12-generic  | wc -l
<soren> 32
<soren> ?
<mjg59> Some core FB stuff is built in, but none of the actual drivers
<jbarnes> well another thing to try is doing iounmap(dev_priv->mmio_map->handle) at the top of suspend somewhere
<jbarnes> if that bugs & gives you a backtrace it means it was already unmapped which would be bad
<soren> The patch in http://marc.info/?l=linux-kernel&m=120657458816261&w=2 sounds like a good idea to me.
<mjg59> soren: Yeah, we need that merged. I /thought/ it was in a bug somewhere
<soren> I'll take it for a quick spin, just to be sure.
<jbarnes> soren: please reply to lkml with your results...
<soren> jbarnes: Sure.
<jbarnes> thanks
<soren> mjg59: Oh..
<soren> mjg59: This box was originally a hoary install.
<mjg59> soren: Shouldn't matter
<soren> upgraded breezy-> dapper->etc.
<soren> Maybe fbcon is in /etc/modules from ancient times?
<soren> I'll check when it's done booting.
<mjg59> Ah, yeah, could be
<mjg59> But fbcon won;t be used unless a driver is loaded
<mjg59> So it's harmless
<soren> Oh, ok.
<mjg59> soren: Oops, sorry, was looking at wrong patch. While I agree we want that one, we also want the "avoid double suspend on hibernation" one. Which I'm sure was in a bug.
<mjg59> Someone here was testing it
<soren> mjg59: tjaalton perhaps?
<mjg59> Could have been
<soren> Gah...
<soren> Setting irssi's timestamps to UTC is good for having a common reference when looking in my irclogs, but it's not very good for making sure I get some sleep (at least once in a while).
<soren> I thought it was only 1 AM.
<mjg59> soren: Ha. Sleep :)
<alex_joni> overrated
<alex_joni> <- @ GMT+2
<soren> mjg59: suspend now works as expected.
<soren> Blimey! Resume does too.
<soren> grep -irl fbcon /etc gives no results, by the way. I've no clue why it gets loaded.
<soren> refcount is 0.
<soren> no aliases. Weird.
<mjg59> soren: With the disablement patch? Ok, cool. Please push that to Ben for now.
<mjg59> I suspect we're not going to rescue it sanely in time
<soren> mjg59: Could you do it? power management patches simply look more correct coming from you :)
<mjg59> soren: Ok. sure
<soren> Thanks.
<mjg59> soren: #207496
<soren> This laptop is really asking to be replaced. It's started doing stuff like http://people.ubuntu.com/~soren/borken.jpg recently, too.
<soren> Spontaneously. While still running gutsy, which worked fine for months and months.
<soren> I blame Korean sweat shops.
<soren> jbarnes: I don't suppose you have a patch for aging hardware, too? :(
<jbarnes> soren: yeah, I regularly patch my hw up to the latest circuits
<mjg59> BenC: #201086 is also helpful
<mjg59> soren: ^
<jbarnes> keeps me running smooth since I can fix hw *and* sw bugs :)
<soren> mjg59: That's not the same issue, I think.
<mjg59> soren: No, but we want it anyway
<soren> mjg59: Oh, right.
<mjg59> soren: Since you're seeing failure on suspend as well as hibernate, I'm pretty sure it's unrelated
<jbarnes> soren: yeah that's werid
<soren> mjg59: YEah, and mine does't go into an infinite loop.
<jbarnes> weird... looks like the display base is getting hosed
<soren> mjg59: Trust me.. With the fan in that thing, I'd know.
<jbarnes> have you run memtest86 recently?
<soren> jbarnes: Yep.
<mjg59> soren: I suspect it's not actually an infinite loop
<soren> mjg59: The code is:
<soren> while (1);
<soren> AFAIR
<soren> mjg59: Let me find another bug about it...
<mjg59> soren: Heh
<soren> I was thinking about this one:
<soren> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/197064
<ubotu> Launchpad bug 197064 in linux "Hibernate fails on Centrino-laptop" [Medium,Triaged] 
<soren> specifically https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/197064/comments/12
<mjg59> soren: Ah, no, that's a misdiagnosis
<soren> What? There's something on the internet that's not true? I'm shocked!
<soren> jbarnes: memtest didn't find anything.
<mjg59> Why is dealing with duplicates in Launchpad so hard?
<soren> jbarnes: The machines still works fine. If I hibernate it, it comes up with the desktop as I left it. If I connect to vino, I can work with the desktop etc., etc..
<mjg59> I want to say a is a duplicate of b, and c (which is a duplicate of a) should therefore be changed to being a duplicate of c
<mjg59> Ugh. Can't be bothered at this time of night
<soren> *shrug*
<soren> jbarnes: I totally blame hardware.
<jbarnes> yeah, maybe cpu is overheating or there are some faulting traces now
<soren> jbarnes: I considered heating problems for a while, but sometimes it could be *Really* hot and not do it, and other times it could be just luke warm and do it.
<soren> *shrug* It's served my wife well for a couple of years now and myself for a year before that. It belongs on a shelf.
<soren> jbarnes: Thanks for all your help today. Much appreciated. I'm sure my wife will be thankful, too, seeing as it's her laptop :)
<JanC> hello, some people I know were asking if this 2-year-old bug will finally be fixed in hardy: https://bugs.launchpad.net/ubuntu/+source/bluez-utils/+bug/32415  ;)
<ubotu> Launchpad bug 32415 in bluez-utils "Bluetooth Mouse and Keyboard Broken in Dapper/Edgy/Feisty" [Medium,Confirmed] 
<JanC> seems like a catch-22 is occuring with hid2hci  ;)
<jbarnes> soren: np, hopefully we can fix that bug right soon
<juliux> ogasawara_, ping
<juliux> ogasawara_, dholbach said i should speak with you about the open kernel bugs, does it helps if somebody has the reporter of the bug if this happens also with a newer kernel? there are a lot of bugs against the dapper kernel and the edgy kernel that nobody touched until now
<amitk> juliux: ogasawara_ won't be online for a few hours, she is on the US west coast
<juliux> amitk, thxs, i will wait;)
<amitk> juliux: bugs against dapper that are still seen in hardy should be marked such - use the "also affects project" in launchpad
<juliux> amitk, the problem is atm nobody knows if they also affekt an other kernel version
<juliux> amitk, the bugs are not yet touched or triggered
<amitk> juliux: in that case you better wait for ogasawara_ to guide you on handling them :)
<juliux> ok
<abogani> BenC: Please ping me when you'll be online. About Bug #177895 and Bug #200057
<ubotu> Launchpad bug 177895 in linux "Kernel 2.6.24-2 causing ~1000 wakeups by "Rescheduling Interrupts"" [Medium,In progress] https://launchpad.net/bugs/177895
<ubotu> Launchpad bug 200057 in linux "HP / Compaq laptops crash with port 0x80 delay write" [Medium,Triaged] https://launchpad.net/bugs/200057
<BenC> abogani: I'm here
<mjg59> JanC: It's not filed against the kernel?
<abogani> BenC: Good morning Ben.
<abogani> BenC: 200057 Seems to be simple as doing cherry-pick of two commits. Seems also that these commits change something about KVM related stuff so IMHO we should cherry-picked KVM related fix also.
<abogani> BenC: 177895 An other cherry-pick fix (is constitued by two revert commits). Already checked and it works on my laptop. Only one problem is that this change /kernel/sched* files a lot.
<abogani> BenC: In both cases I don't idea if this is compatible with kernel freeze policy :-(
<BenC> abogani: From just reading the basic description, they sound very important
<BenC> abogani: Would you be willing to put these fixes into a tree we can pull from?
<abogani> BenC: Ok.
<abogani> Ok Now it's lunch time!
<BenC> abogani: thx
 * BenC gives abogani a Big Mac
<zul> ewww
<cking> abogani: Hi there, looking at bug 177895, which cherry pick fix is there for this?
<ubotu> Launchpad bug 177895 in linux "Kernel 2.6.24-2 causing ~1000 wakeups by "Rescheduling Interrupts"" [Medium,In progress] https://launchpad.net/bugs/177895
<lamont> BenC: I'm seeing a user report of "[ubuntu lacks] the mpt scsi driver in the boot/install kit" - any chance of getting that fixed for hardy?
<BenC> $ gunzip -c /boot/initrd.img-2.6.24-12-generic | cpio -t | grep mpt
<BenC> lib/modules/2.6.24-12-generic/kernel/drivers/message/fusion/mptfc.ko
<BenC> lib/modules/2.6.24-12-generic/kernel/drivers/message/fusion/mptsas.ko
<BenC> lib/modules/2.6.24-12-generic/kernel/drivers/message/fusion/mptspi.ko
<BenC> lib/modules/2.6.24-12-generic/kernel/drivers/message/fusion/mptscsih.ko
<BenC> lib/modules/2.6.24-12-generic/kernel/drivers/message/fusion/mptbase.ko
<BenC> lamont: ^^
<BenC> lamont: that should be the case for anything as far back as edgy (and now 6.06.2 as well)
<lamont> that's what I kind of thought...
<BenC> cking: I have a one line fix in lum for that btsco problem, good catch
<cking> BenC: great, what is it?
<BenC> cking: CFLAGS_snd-bt-sco += $(srctree)/sound/alsa-kernel/include
<BenC> in ubuntu/Makefile
<BenC> *CFLAGS_snd-bt-sco.o
<cking> BenC: Do you want me to put it in and give it a thorough test
<BenC> Yeah, I added it just after the snd-bt-sco-objs line
<cking> BenC: Thanks for the rune, I was unsure if that kind of include path hack was OK.
<BenC> cking: We're going to revisit all this junk in prague, but for now, it's perfect
<cking> BenC: Makes sense for now. OK, I will put the change in and see if there are any other hidden issues.
<abogani> BenC: Seems to me that $(srctree) point to KSRC DIR and $(src) to SRC DIR of itself sources.  Or not?
<abogani> cking: Are you around?
<BenC> abogani: you may be right
<BenC> but ubuntu/sound/ uses $(srctree) already to point to those headers, so I assume it's correct
<BenC> could be unneeded in that usage though
<abogani> I suppose that this is a problem. If $(srctree) point to KSRC when you compile gcc will use pcm.h in /usr/src/linux-headers-2.6.24-12/ that are different by pcm.h in LUM-DIR/ubuntu/sound/alsa-kernel/include/pcm.h
<abogani> Or i misunderstand something? :-)
<abogani> I said a silly thing? :-)
<soren> I've seen much talk about dkms, but haven't looked into the details of it. Is it much different than what we could accomplish with a kernel-img.conf postinst_hook call to module-assistant?
<soren> I realise that calling m-a from a postinst won't work, but I'm sure something could be put together to make it fly.
<adinc> hi
<adinc> has there been a new kernel released for hardy?
<rtg> adinc: https://launchpad.net/ubuntu/+source/linux is the current release.
<soren> rtg: You're back?
<rtg> soren: its my ghost typing :)
 * soren hides
<smb> rtg: Welcome ghost of Tim. :)
<soren> Have any of you guys looked into dkms?
<rtg> soren: dkms has been on my todo list for months. I know its well supported by mdomsch et al.
<soren> rtg: How does it compare to module-assistant?
<rtg> soren: I've never used m-a, so I could not venture an informed opinion.
<soren> Ah.
<soren> Well, e.g. kvm provides a kvm-source package that contains the source for the kvm modules. m-a can do all of downloading that package, downloading the kernel headers for your kernel, compile the modules against said kernel headers, generate a .deb with the modules, and finally install it. When its working as expected (which it usually does, actually), it's a simple matter of calling "sudo m-a a-i kvm".
<adinc> rtg: thank you very much, can i also find out which modules are the latest released?
<soren> rtg: Is that about the same as what dkms offers?
<rtg> adinc: https://launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24
<rtg> soren: dkms (as I understand it) will rebuild itself against current headers each time the kernel is updated.
<soren> rtg: So adding a call to m-a whenever a new kernel is installed makes it about equal?
<rtg> soren: in my uninformed opinion, yes.
<mdomsch> good morning
<soren> rtg: Wonderful. Thanks. (I'll keep your disclaimer in mind. Don't worry)
<rtg> soren: it would be nice to have _one_ way of doing these kind of updates.
<mdomsch> I never got the hang of using m-a
<smb> rtg: Since you are just back to ask. ;-) But maybe BenC and amitk could have a look, too. I had a look into bug 134660 and I had the feel that it might be better to stay with the rt2x00 driver in the kernel. Gutsy had it in lum and not any legacy ones. So I prepared a patch that would update the driver to latest upstream code (seehttp://kernel.ubuntu.com/git?p=smb/ubuntu-hardy.git;a=summary) 
<mdomsch> I spent days trying to get a package built that m-a cound consume
<ubotu> Launchpad bug 134660 in linux-ubuntu-modules-2.6.24 "Ralink rt2400 / rt2500 / rt2570 / rt61 / rt73 do not work out of the box in Gutsy/Hardy" [High,Confirmed] https://launchpad.net/bugs/134660
<mdomsch> and gave up and just ported dkms into Ubuntu/Deb
<soren> mdomsch: Heh.. There are quite a few useful examples out there. kvm and open-vm-tools to name a few that I've had the pleasure of dealing with.
<mdomsch> soren, see how dkms drops files into /etc/kernel/postinst.d/  to be executed as a trigger when the kernel is updated
<mdomsch> m-a could do likewise
<soren> Precisely.
<mdomsch> fedora does this now too, yea!
<soren> mdomsch: dkms keeps an entire kernel tree somewhere, correct?
<mdomsch> no
<soren> Ok.
<BenC> soren: it's basically m-a but portable
<mdomsch> dkms presumes you have kernel-source installed visible at /lib/modules/$kernelversion/build
<soren> So twice in one day, I've found something on the internet, that's not true. I'm *shocked*!
<amitk> rtg: welcome back, you survived! :)
<BenC> rtg: does this mean you will be on the call in 5 minutes? :)
<soren> BenC: "portable" as in distro agnostic?
<mdomsch> soren, dkms keeps a tree of the source to the modules it's managing
<BenC> soren: right
<rtg> smb: the rt drivers from the serial monkey website should go into lbm since they conflict with PCI/USB IDs.
<rtg> BenC: its too early for the kernel call isn't it?
<BenC> rtg: we have lum setup in module-init-tools to override the kernel ones, right?
<soren> mdomsch: Ok.
<soren> They sound pointlessly similar :)
<BenC> rtg: well I moved it because it conflicted with another call that actually got canceled this morning
<BenC> rtg: not knowing you would be able to make it
<rtg> BenC: oh, can do.
<rtg> BenC: the usual numbers?
<BenC> rtg: welcome back, btw
<BenC> rtg: yeah
<BenC> rtg: I have a few patches for alsa that need to be applied (agenda for the call)
<rtg> BenC: you cannot believe how much email I accumulated.
<BenC> rtg: Oh, I can...if I were away for 3 weeks, I'd have to just delete everything and start fresh
<smb> BenC: is that a kernel call for team or something else?
<BenC> would be roughly 10k new emails in that time
<BenC> smb: vendor call
<smb> BenC: ah ok
<adinc>  i've installed my custom kernel for testing, now i removed it again and apt gives errors when i try to install any other package, it says cannot find /lib/modules/2.6.25-rc6-custom which was the modules for the kernel i build. how can i fix this quickly?
<soren> mdomsch: How do you handle the need to have the kernel headers installed at the kernel image's postinst time?
<zul> rtg: welcome back
<BenC> adinc: no idea...this is a better question for #ubuntu
<rtg> zul: thanks
<BenC> soren: the trigger is on the kernel-headers install, not the kernel image
<soren> rtg: Yeah, welcome back, Tim! Great to have you back!
<BenC> soren: so it will build modules for any headers you have installed, rather than any kernel
<smb> rtg: The thing I am not sure is whether the legacy drivers from serial monkey are the way to go since the rt2x00 stuff in kernel and from serial monkey seem to be the same and the one that is more developed. But maybe I am just conused...
<soren> BenC: Wow..That was embarassingly obvious.
<soren> :)
<mdomsch>  soren, it's a nasty hack in ubuntu I admit
<mdomsch> the same hook is invoked twice - once after linux-image is installed, and once after linux-headers is installed
<mdomsch> because I can't know the ordering
<mdomsch> in Fedora, I do it in an rpm %posttrans hook, which runs after all the packages in the transaction are finished being installed
<soren> You can dpkg-trigger your way out of that.
<mdomsch> oh?
<soren> Yeah. Each of the postinst will call a trigger, and this trigger will do the actual stuff at the end.
<soren> See e.g. /sbin/ldconfig (it's shell script these days)
<Kano> hi, how will you call the kernel with 2.6.24.4 base?
<Kano> -13?
<soren> mdomsch: Each will call "dpkg-trigger --no-await somerandomname" or something. dkms will "register its interest" in this trigger and thus be called after all packages are done being configured.
<soren> mdomsch: /var/lib/dpkg/info/libc6.triggers has "interest ldconfig". It means that whenever dpkg-trigger ldconfig has been called, libc6's postinst will be invoked as "$0 triggered" (iirc).
<mdomsch> ah yes
<mdomsch> I looked into those
<mdomsch> I forget if I had problems or if I just got sidetracked
<mdomsch> probably the latter
<soren> Heh.
<Kano> so: when will be a new kernel based on 2.6.24.4 and how will it be called?
<soren> Kano: Dude... Calm down.
<Kano> hi juliank 
<juliank> Kano: hi
<mjg59> Kano: It will be called -13 if it changes ABI. Otherwise it won't be.
<Kano> well it will change anyway as you disabled 2 ide drivers, didnt you
<Kano> at least the ones which are really needed
<mjg59> No, that doesn't change ABI
<lamont> * The update-modules command is deprecated and should not be used!
<lamont> go nvidia-kernel-common!
<rtg> smb: the serialmonkey code used to be legacy only, but I see they've updated the web site to indicate that rt2x00 is mainstream. Perhaps we should evaluate dumping them in lum if they are demonstrably better then whats in the kernel.
<smb> rtg: I had the impression that they now do a lot in the kernel as well. But maybe I have a closer look at the rt2x00 code on serialmonkey to see
<rtg> smb: it looks like the web site code is a superset of the kernel code, e.g., enhanced with bug fixes (at least that is according to the web site comments)
<smb> rtg: Definitely right as far as 2.6.24 is concerned. There were ~60 patches to it in the meantime
<rtg> smb: so, are you thinking about spinning a version of lum with these drivers?
<smb> rtg: That was the point I became unsure. Is it better to have the latest serialmonkey stuff in lum (or lbm) or pull the latest kernel code. With the latest kernel code we would be closer to upstream but might get ABI problems so maybe it is better to do it in lum/lbm
<rtg> smb: I would do it in lum so as to continue a maintain a relatively virgin kernel source code base.
<smb> rtg: hm, right. and i guess updates there are simpler to handle than in the kernel
<rtg> smb: indeed
 * smb starts the lum patchwork
<rtg> BenC: a handy site posted by jgarzik: http://linux-ata.org
<mjg59> rtg: Do you have an Intel-graphics M1330?
<rtg> mjg59: the only one we had (or BenC had) was sent back for repair.
<rtg> mjg59: we have other Intel-graphics based laptops.
<mjg59> rtg: Hm. No, got a complaint specific to the M1330.
<rtg> mjg59: mine is nv based.
<mjg59> Yeah, so is Ben's
<mjg59> Anyway, thanks!
<rtg> mjg59: np
 * lamont grumbles at hardy vs nvidia
<lamont> how do I get the good screen resolution back again?
<tjaalton> lamont: is it actually using nv or vesa?
<lamont>         Driver          "nv"
<tjaalton> you could try the package here https://edge.launchpad.net/~tjaalton/+archive
<tjaalton> there's a patch from fedora which could help
<lamont> tjaalton: I imagine a server restart is required for that, yes?
<tjaalton> right
<lamont> ok. brb
<lamont> tjaalton: the heart of the issue is that the preferences/screen resolution widgit doesn't even show 1680x1050..
<mjg59> lamont: What does it have?
<lamont> all the way up to 1280x1024 :(
<mjg59> lamont: also, what's the output of xrandr ?
<lamont> 02:0b.0 VGA compatible controller: nVidia Corporation NV34GL [Quadro NVS 280 PCI] (rev a1)
<mjg59> lamont: Yeah, so nv is picking the wrong set of modes
<lamont> xrandr stops at 1280x1024 as well
<tjaalton> lamont: is it a toshiba?
<lamont> HP workstation
<tjaalton> ok..
<tjaalton> lamont: did it work in gutsy?
<lamont> yes
<tjaalton> hrm
<lamont> I just upgraded and my screen is now very crowded-feeling...
<tjaalton> time to blame the server it seems..
<lamont> and no changes in /etc/X11/xorg.conf
<rtg> mjg59: ogasawara_ asked me to apply http://launchpadlibrarian.net/12911605/disable_pre_915_drm_pm.diff, but it looks garbled.
<tjaalton> lamont: hum, you could try fedora9 beta livecd to see if the new xserver gets the correct resolution :)
<lamont> actually, I'm not sure that gutsy did either, now that I think about it more
<lamont> I'll see if I get where I have enough bandwidth to make fetching fedora9 live worthwhile
<mjg59> rtg: Hm. What do you think's up with that patch?
<tjaalton> lamont: at least F9b got a better resolution (12x10, hardy does 8x6) with vesa on a GF7050PV
<rtg> mjg59: a line is missing, there is bogus line feed, etc. I could do it by hand, but we ought to have the right bits attached to the LP report.
<mjg59> rtg: It's certainly the right patch
<mjg59> And that's what hit lkml
<rtg> mjg59: I agree the code looks right.
<rtg> but the diff attached to the LP report is malformed, thats all. 
<mjg59> rtg: What's the bug number again?
<rtg> Bug #207496
<ubotu> Launchpad bug 207496 in linux "Disable DRM suspend/resume on pre-915 Intel chips" [Medium,Triaged] https://launchpad.net/bugs/207496
<mjg59> rtg: http://launchpadlibrarian.net/12923810/disable_pre_915_drm_pm.diff
<rtg> mjg59: http://launchpadlibrarian.net/12911605/disable_pre_915_drm_pm.diff is what I'm looking at.
<rtg> are the paths relative to the user login?
<mjg59> rtg: No, I just uploaded a new diff
<rtg> mjg59: oh, duh.
<mjg59> :)
<rtg> mjg59: applied.
<mjg59> rtg: Thanks
<smb> mjg59: Hi Matthew, I saw the diffs for Tim and just got notified of bug 207615. Is there a chance this is a very similar problem?
<ubotu> Launchpad bug 207615 in linux "[hardy] beta can not hibernate successfully with 965GM" [Medium,Triaged] https://launchpad.net/bugs/207615
<mjg59> smb: No - that's the issue where the suspend methods are called twice on hibernation
<mjg59> smb: I think there's already a patch filed for that
<smb> mjg59: in drm or the driver? The only patch in drm I am aware of since then is "drm: Fix race that can lockup the kernel"
<mjg59> smb: #201086
<smb> bug 201086
<ubotu> Launchpad bug 201086 in linux "X41 fails to hibernate in hardy" [Medium,Triaged] https://launchpad.net/bugs/201086
<smb> mjg59: Ah, ok. Since I am not yet very familiar with that stuff, the i965 also uses the i915 drm driver?
<mjg59> smb: Yes, i830 and up all use i915 drm
<smb> mjg59: Ok, thanks. :) 
<smb> mjg59: Errm, just for sanity. I can't really say it is important. this post (http://lkml.org/lkml/2008/2/22/488) had two changes for i915_drv. Linus objected one line (if I don't misunderstand) (http://lkml.org/lkml/2008/2/22/554). After that i915 isn't touched at all and the second change doesn't seem to be upstream. 
<mjg59> smb: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3a2d5b700132f35401f1d9e22fe3c2cab02c2549
<mjg59> smb: The fix doesn't actually touch i915
<tjaalton> that's bug 197064
<ubotu> Launchpad bug 197064 in linux "Hibernate fails on Centrino-laptop" [Medium,Triaged] https://launchpad.net/bugs/197064
<tjaalton> smb: ^
<smb> tjaalton: ok, so the change to pci_set_powerstate also belongs to that one
<smb> replacing PCI_D3hot with pci_choose_state(dev->pdev, state)
<tjaalton> 201086 already has a dupe, so maybe mark 197064 and 207615 as dupes
<tjaalton> smb: http://lkml.org/lkml/2008/2/23/269 <- this thread mentions a patch that's needed or the compilation fails, and the commit-id is 038eb0ea04b2453..
<smb> tjaalton: Yes, saw that as well. Just wanted to make sure that dropping the whole i915 changes was ok. So basically all three might be cured with those two patches
<tjaalton> yep
<smb> tjaalton: dumb question: how do I mark bugs as duplicate in launchpad?
<tjaalton> actions - mark as duplicate
<tjaalton> from the left panel
<smb> tjaalton: oops. really dumb question. ok found it
<tjaalton> :)
<adinc> has someone got a samsung q45 with an intel iwl3945 and kernel 2.6.24 running successfuly?
#ubuntu-kernel 2008-03-28
<abogani> cking: Are you around?
<cking> abogani:  Hi there..
<abogani> cking: About Bug #177895
<ubotu> Launchpad bug 177895 in linux "Kernel 2.6.24-2 causing ~1000 wakeups by "Rescheduling Interrupts"" [Medium,In progress] https://launchpad.net/bugs/177895
<abogani> cking: Interesting commit is 62fb185130e4d420f71a30ff59d8b16b74ef5d2b in mainline.
<cking> Yes, I am very familiar with this one :-)
<cking> Yep - apparently it removes two earlier commits 
<abogani> So I let thi Bug to you :-)
<cking> ..well I had a look at it and I was not sure if these commits are actually in our kernel
<abogani> It isn't a trivial merge.
<abogani> cking: Do you have hw that incurr evidently in this bug?
<abogani> cking: What is your TZ?
<cking> abogani: I have a Centrino duo which I see 200-300+ Rescheduling Interrupts. But not 5000+ as some are seeing
<cking> cking: My TZ is UTC. I start early :-)
<abogani> cking:so  Good Morning! :-)
<abogani> cking: Mainline give the same result on my Centrino duo!
<cking> abogani: Back to commit 62fb185130e4d420f71a30ff59d8b16b74ef5d2b... I believe it reverts 58e2d4ca581167c2a079f4ee02be2f0bc52e8729 and 6b2d7700266b9402e12824e11e0099ae6a4a6a79
<cking> abogani: however, I was unsure if these commits were actually made to our current kernel tree
<cking> abogani: have you investigated this to any depth yourself?
<abogani> cking: I'm already cherry-picked and my laptop works perfectly. 
<cking> abogani: do you have a patch that I can pick from so that I can give it a run through?
<abogani> cking: But i don't have hw that expose evidently thus bug. I'm not sure that this fix... :-(
<abogani> cking: Do you prefer git or email?
<cking> abogani: yes this is the same kind of problem I am facing too. And the patch is a bit "radical" as it does touch a lot of the important parts of the  scheduler
<abogani> Agreed
<cking> abogani: git - if that's OK, but email if that's easier for you.
<cking> abogani: I have some tests with powertop and so forth that I can apply to see what's going on.
<abogani> cking: Ok i'll push it in my git tree. Please Let me some minutes...
<cking> abogani: The main thing is to see if the rescheduling interrupts are legitimate - a lot of them really are due to correct load balancing
<cking> abogani: so it will take me 3-4 hours to shove in some diagnostics and see if the fix really is OK
<cking> abogani: OK - much appreciated - this saves me a lot of work. :-)
<abogani> cking: Sorry I don't know why but my git don't work anymore! :-(
<cking> abogani: Ah. Problem :-(
<abogani> cking: Mhhhh .gitignore conflict
<abogani> No way to understand why git stop work... 
<cking> abogani: perhaps I should try the patch on my git tree and toy with the fix that way
<abogani> cking: Are you registered user on Freenode?
<cking> abogani: I thought so - why?
<abogani> cking: I'm trying to send you a file
<cking> abogani: perhaps try Emailing it to colin.king "at" ubuntu.com 
<cking> abogani: meanwhile I check my Freenode and IRC settings 
<abogani> cking: Mailed. I send you my adaptation of the cherry-pick fix 
<cking> abogani: many thanks!
<abogani> Sorry but my git is completely break ... :-(
<cking> abogani: ..I know the feeling, when it breaks, it *really* breaks - and usually at the worst time.
<abogani> :-)
<abogani> Murphy docet ;-)
<amitk> abogani: what seems to be the problem with git?
<abogani> amitk: Hi Amit! I cherry-pick a commit from a remote tracked repo, use git-mergetool and git-status. And all is ok. I execute git-commit and all things disappear. git-log and git-status don't show nothing! Work seems completely lost!
<abogani> Seems to me a index problem...
<abogani> s/index/git index/
<amitk> abogani: interesting. And you weren't working on a branch?
<abogani> amitk: No. Just created with 'git-checkout -b'
<amitk> abogani: that is a branch
<cking> abogani: Hi again..
<abogani> cking: Hi
<cking> can you gzip the patch and re-send it to me as a gzip attachment. My mail client is silently putting in white spaces that cause git-apply to fail :-(
<cking> ..by the way I can reproduce the 10,000+ Rescheduling Interrupts quite predictably now - so it will be straight forward to test the patch.
<abogani> cking: The fault is my webmail!
<abogani> cking: Mailed.
<cking> abogani: no worries - thanks again for the speedy response!
<abogani> cking: How can you reproduce the bug? Is it necessary something special actions?
<cking> abogani: It's a case of getting the right suite of apps to generate loads of timer actions and get enough free CPU cycles so that both cores are incorrectly balanced... 
<cking> ...then one can see the scheduler working hard to try to rebalance the load and cause zillions of IPI events.
<Ng> cking: is that going to be easily fixable for hardy? :)
<abogani> Not easily...
<cking> ..I hope so.. it will take a few hours of analysing the IPI events under different loads before I can say. I think it's not easily fixable..
<cking> ...I've been looking at an answer on and off for a few weeks on this one - and tinkering with the scheduler is risky for Beta
<Ng> yeah
<Ng> just curious because my laptop seems to do several hundred wakeups a second for that
<cking> After a lot of consideration I believe a lot of the rescheduling interrupts are legitimate.
<cking> A lot of apps do very frequent timer events .. they wake up and the scheduler tries to spread the load across cores
<cking> For laptops with Centrino Duo cores it is better to spread the load across cores so that they are busy rather than have one core running at full speed 
<amitk> cking: what happens if IRQ balancing is disabled? the interrupts only go to the core on which the app is running?
<cking> amitk: Not sure if this is just a IRQ balancing. My understanding is that the scheduler is rebalancing the load across cores in probably too agressive a manner 
<cking> ..OR...
<cking> ..that we can now see the IPI events because the Rescheduling Interrupts are more visible 
<cking> amitk: Any wise input on this?
<amitk> cking: not really. Though I wonder if the rebalancing behaviour will change if the scheduler is changed.
<cking> amitk: looking at all the scheduler tweaking in 2.6.25+ I am very concerned that this type of issue has a lot of life in it..
<cking> amitk: my big worry is that the problem may be resolvable for Hardy, but need a lot more work for later kernels.
<cking> ..and also the scheduler is not a trivial piece of code to tinker with - if one goofs up, one goofs up big time.
<amitk> cking: how so?
<cking> amitk: sorry.. I misunderstand: how so what?
<amitk> cking: why would it be harder to fix for later kernels? It should be fixed upstream, right?>
<cking> amitk: true
<cking> I'm just concerned with a fix now in Hardy LTS which makes the scheduler diverge from upstream in a (perhaps significant and) unmaintainable way
<amitk> cking: i see you point now. But with LTS, it is unlikely that we will upgrade to a newer kernel.
<amitk> *your
<cking> amitk: indeed.. but I'm always keen to reduce risk.. especially wrt key kernel components.
<amitk> cking: agreed
<cking> Hi BenC
<BenC> hey
<cking> another day, another bug :-)
<BenC> hehe
<BenC> cking, amitk: If either of you wants to follow up on my work on cpu1 losing cpufreq capa, I found some interesting bits after some debug last night
<BenC> after suspend, when bringing up cpu1, there are some acpi errors about unknown op codes
<cking> BenC: Sounds like something meaty that I could get my teeth into..
<BenC> bringing cpu1 down/up before suspend/resume works fine (the cpufreq symlink returns in sysfs)
<BenC> doing so after suspend resume repeats the acpi errors though
 * amitk gives up the bug to cking reluctantly - not :)
<BenC> mjg59: Does the acpi subsystem reread the acpi tables after suspend/resume, or rely on it's internal copy?
<cking> BenC: Sounds like https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+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] 
<BenC> cking: That's the one
<mjg59> BenC: They're never re-read
<mjg59> Hm. In principle, SSDTs can be loaded and unloaded at runtime.
<cking> mjg59: Not sure what happens in reality though. I will look into it.
<mjg59> BenC: Curious. acpidump and iasl -d should let you figure out where that object is meant to live
<BenC> mjg59: Then my first guess is that the internal copy is getting corrupt somehow
<BenC> maybe acpidump before and after suspend will confirm that
<mjg59> BenC: acpidump will dump direct from the hardware, not the kernel's representation
<mjg59> /proc/dsdt /might/ give you the kernel version of the dsdt
<mjg59> /proc/acpi/dsdt, that is
<mjg59> BenC: What hardware are you seeing this on?
<mjg59> A d630 has literally just turned up at my front door, so I can poke it there
<cking> mjg59: This bug also occurs on my Lenovo 3000N200 Centrino Duo 
<BenC> mjg59: Lots of systems
<cking> BenC: so at least I can dig into the bug on my hardware straight away
<mjg59> Ok. I'm not seeing it on my HP.
<BenC> I reproduced it on two of my dell laptops
<Ng> fwiw, not seeing it on my thinkpad
<BenC> hoping this isn't a BIOS bug
<BenC> or if it is, hopefully we can work around it somehow
<BenC> mjg59: Should acpidump and /proc/acpi/dsdt match?
<mjg59> BenC: The dsdt hunk of acpidump should I believe, yes
<mjg59> Certainly after passing them through iasl -d
<BenC> mjg59: Are the CPU related bits we are concerned about in the dsdt?
<mjg59> BenC: Not sure. If you disassemble the dsdt and find the _PCT methods, then yes :)
<BenC> mjg59: Thanks :)
<BenC> cking: Ok, sounds like you've got plenty to go on...I expect a patch in upstream kernel and a full report when I return in 3 hours :)
<mjg59> Otherwise, probably in an SSDT
<cking> BenC: Of course ;-)
<BenC> See you guys in a bit
<adinc> if i download the packaged ubuntu kernel sources, where does it install them?
<abogani> adinc: apt-get source linux-image-2.6.24-12-generic will install source in current dir
<adinc> abogani: no it did install to AAAAAAAAAAAAAAAAAAAAAAAA/AAAAAABBBBBBBBBBB
<adinc> pardon to /usr/src
<adinc> can i disable CGROUPS on a running kernel, or do i have to disable it in the kernel configuration before compiling?
<rtg> adinc: its a compilation config macro, so I don't think you can change the way the scheduler works at runtime.
<adinc> is this essential in ubuntu kernel? or can i safely disable it
<rtg> adinc: you can set it however you like. the current value is targeted to desktop single user environments.
<adinc> where can i get the complete config file for the hardy kernel packages kernel?
<adinc> the config file which is in /boot is unfortunately not complete
<rtg> adinc: install a headers package, then look for a .config in /usr/src/linux-headers*
<adinc> which one is complete linux-headers-2.6.24-12 or linux-headers-2.6.24-12-generic
<adinc> generic
<adinc> ...
<rtg> adinc: alternatively you could 'debian/rules prepare-generic', then look in debian/build/build-generic for a .config for that specific flavour.
<adinc> rtg: no this can't be the complete .config file since the .config in linux-headers is IWL3945 module missing, i mean it is not set
<mjg59> adinc: iwl3945 comes from linux-ubuntu-modules
<mjg59> Not linux-image
<rtg> adinc: thats because iwlwifi is built in LUM, not the kernel.
<adinc> so how do i get a complete config file
<mjg59> adinc: That is a complete config file
<adinc> i don't understand
<rtg> adinc: its the complete kernel config.
<mjg59> adinc: The Ubuntu kernel does not include iwl3945. It's in a separate package.
<adinc> but the kernel needs to be prepared in order to accept this module, doesnt it
<mjg59> adinc: No
<rtg> adinc: have you read https://wiki.ubuntu.com/KernelMaintenance?
<adinc> i've read several wiki pages, but let me see if i know this aswell
<adinc> i'm thankfull for any information
<adinc> this would mean that i could compile this particular module only with the kernel headers, but without the source. only this particular modul, is this right?
<adinc> rtg: thank you for the link,  here it tells that the config files are concatenated into one file
<tseliot> BenC: did you review my patch?
<lamont> BenC: which version of things was that vmmon, I wonder... no networking here.. FTL
<infinity> BenC: Is the patch from #201591 queued for the next kernel upload, by any chance?
<infinity> BenC: I'd love to be able to see myself type in consoles. :)
<rtg> infinity: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=4cbe826672e05ace08a4848e53135d652772feae will appear with the next upload.
<infinity> rtg: Danke.
<infinity> rtg: (For the record, despite the bug title, it's a regression for all *fb drivers, not just atyfb... I have the same bug on vesafb)
<rtg> infinity: you are correct, the commit title is disingenuous, but the code is correct.
<infinity> rtg: Yeah, I know the code is correct, the heads up was just for the Debian changelog to be accurate. :)
<rtg> infinity: I'll try to remember when I do the upload.
<infinity> rtg: Is there a timeframe on that?  There's nothing scarier for me than running a devel release without consoles. :)
<rtg> infinity: by next Friday for sure, perhaps sooner. 
<cradek> rtg: thanks, that patch is the one that fixed my system too
<BenC> rtg: I'm doing an upload this evening
<BenC> or, soon after on the weekend
<tseliot> BenC: did you review my patch (or read my email)?
<rtg> BenC: good. I was gonna ask Steve if there was any reason I shouldn't do an upload today.
<deb> Am i connected
<deb> I have downloaded 8.04 and found it is not a viable distro for me, and many others.
<deb> The reason is the lack of internet apps
<alex_joni> you do know that on the CD there's only a tiny amount of installed packages
<alex_joni> there are about 18-19000 other apps in repositories, which you can easily install
<deb> Pardon?  There are more apps on the CD
<deb> ?
<deb> Oh, that. That  is my point.  As presently setup, I cannot get to the repositories with 8.04
<deb> Reason is the internet access apps are so skimpy.
<infinity> Define "internet access apps".
<infinity> Also, please define it in another channel (#ubuntu, perhaps?), this is A) not a support channel, and B) dedicated to kernel discussion.
<deb> I have two locations and two different ISP's that I connect through - as setup I cannot connect from either with 8.04
<deb> One location has a wireless network and the main computer on it has a D-Link DWA-552 wireless card, which 8.04 does not recognize (There is a GPL driver for it beause Sabayon uses it)
<deb> There is also no "ndiswrapper."
<deb> So I can use the Windows driver
<deb> The other location uses PPPOE -complete with user name and password - for each log on, there are no apps to allow me to do that (they are available as PCLinuxOS uses thenm)(
<alex_joni> then use PCLinuxOS
<alex_joni> as infinity pointed out, this is a place to discuss kernel development, which you obviously aren't interested in
<deb> A less than "sensitive" anwer
<infinity> We ship ndiswrapper and ppoeconf, both installed by default no less.
<deb> No I am not interested in kernel development, but your folks on the desktop sent me here 
<deb> Where are they, I looked but did not find them.
<infinity> deb: pppoeconf is in /usr/sbin, ndiswrapper modules are provided by the default kernel setup, though you might need ndiswrapper-utils-1.9, if you need the userspace apps.
<soren> ndisgtk is.. Oh, he buggered off.
<soren> *shrug*
<infinity> It's always unforunate when we lose a "IS THIS THE KERNEL CHANNEL, GIVE ME FREE SUPPORT NOW, UR DISTRO SUCKS, U ALL SUXORS!!" type.
<alex_joni> infinity: you forgot "I HAVE NO CLUE WHAT I'M DOING, BUT THERE IS SOMETHING WRONG WITH WHAT YOU DID"
<infinity> alex_joni: I'm fine with people lacking clue but, yes, I agree that it's irksome when they blame their lack of clue on us clearly having broken their computer from afar.
<alex_joni> and sometimes even meaning to do that (breaking their computers)
<zul> if everyone based their stuff off of pclinuxos then a world will be a happier place
<alex_joni> how do you guys debug machine crashes.. if there's nothing in syslog?
<desrt> hai!  i can has kernel hacker?
 * desrt requires patch application
#ubuntu-kernel 2008-03-29
<gribelu> hello. How could i enable the old PATA drivers in the current hardy kernel? google says that hwprobe=-modules.pata in my menu.lst should do it but that doesn't seem to work..
<ClaesBas> Any chance that the release kernel for 8.04 server is going to have ipmisensors (which make lmsensors able to get info from Proliantservers for ex.)?
 * lamont wonders if there's any reason _not_ to enable building uswsusp on ppc
<dade`> hi guys
<dade`> let's talk about https://bugs.launchpad.net/ubuntu/+source/linux/+bug/177895
<ubotu> Launchpad bug 177895 in linux "Kernel 2.6.24-2 causing ~1000 wakeups by "Rescheduling Interrupts"" [Medium,In progress] 
<dade`> it's been there for weeks, and the guy working on it does not make me feel comfortable -- no offense
<juliux> ogasawara__, ping
<bullgard4> Why shows System > Administration > Services [Services settings] apmd switched on but acpid switched off although there is a process 'kacpid'?
<mjg59> kacpid is part of the kernel
<mjg59> acpid isn't
<bullgard4> Thank you for explaining.
#ubuntu-kernel 2008-03-30
<_stress_> hi, I'd need some help to find some cpufrequtils files in the kernel tree...could someone help me?
<_stress_> I'd like to know where the pot files are but I can't find them...any help?
<_stress_> ok.....what do I need to translate kernel packages for my native language?
<_stress_> someone knows how to create .po s files?
<tjaalton> I added a file to unload snd_hda_intel (SUSPEND_MODULES="snd_hda_intel" in /etc/pm/config.d/snd), but it doesn't seem to work. shouldn't it be possible to unload modules when the user processes are frozen?
<asabil> hi all
<asabil> I have some troubles with a usb thumb drive being detected as a cd rom reader
<JanC> asabil: some USB thumb drives say they are (also) a CD-ROM drive; quite stupidly  ;)
<asabil> JanC: that's not the case for this one
<asabil> it says that it is *only* a cd-rom drive
<asabil> nothing gets created in /dev/sdb*
<JanC> well, I think you should kick the manufacturer where it hurts, and maybe the udev scripts maintainers can fix this if you report a bug...
<asabil> okidoki, I will report a bug
<asabil> againt which package ?
#ubuntu-kernel 2009-03-23
<Kano> hi rtg , when do you add my aufs compile fix to git
<Kano> i dont want to update my patch everytime, just add it
<rtg> Kano: I'm not sure I'm going to. We are considering either upgrading to current aufs or using a different in-kernel solution.
<Kano> rtg: you can update it later if needed, why not have something working before?
<Kano> what solution is in kernel?
<rtg> a device mapper snapshot. I'm stioll not sure of the details, but then I don't have to worry about it for awhile. I'm still busy with Jaunty.
<Kano> thats a tiny patch, i think you can do it
<Kano> you just removed squashfs, that will require a tiny change
<Kano> in the makefile after the patch
<Kano> http://kanotix.com/files/kernel/unused-patches/2.6.29-ubuntu-aufs-compile-fix.patch
<Kano> it was correct 5 days ago when i posted the patch in the mailing list
<rtg> amitk: do you have anything that absolutely has to make into the Beta release?
<rtg> s/make /make it /
<amitk> rtg: naah. Most of my stuff can now wait.
<rtg> amitk: k, thanks
<dandel> 0o' yuck... gotta figure out how to get 2.6.25 to boot.
<bradF> cooloney: ping
<cooloney> bradF, pong
<amitk> cooloney: bradF: check latest commit to git tree. No need to work on mv78xx0 and orion5x anymore
<cooloney> amitk, got it, 
<bradF> amitk: got it, thanks
 * cafetiere looks grumpy
 * smb_tp waves to cafetiere 
<cafetiere> smb_tp: me and jaunty are not getting on at all
<smb_tp> Yeah, I guessed that much but the timing was reasonably well :)
<nanomad> Hi all, can anyone please have a look at bug #21367 . It has been un-fixed for 3 years with a solution ready since the first report. :(
<ubot3> Malone bug 21367 in linux-source-2.6.22 "Wifi-enabled led is not lit on ipw2200 cards" [Low,Won't fix] https://launchpad.net/bugs/21367
<IntuitiveNipple> nanomad: lol... I was looking at that bug quite independently of your request :)
<dandel> hmm... fun... now i need to figure out how to get 2.6.25 to boot... apw, mind helping?
#ubuntu-kernel 2009-03-24
<elwood> hi
<elwood> i've a broken usb-port on my pc, the kernel.log is full of "garbage" about it. There is a way to stop the scan for this port? it'a kernel or udev question?
<IntuitiveNipple> A port or a host controller?
<IntuitiveNipple> short of disconnecting it physically, there's no way to disconnect a port from a host... often the ports are shared by multiple host controllers, too.
<elwood>  hub 1-0:1.0: unable to enumerate USB device on port 4
<elwood> this is the log, just and always the port 4
<elwood> with hal i can drop all the log to /dev/null? this is the first thing that pop-ups in my mind :)
<IntuitiveNipple> no, the report is from the kernel module.
<elwood> ok, and i suppose there is no parameter for the module
<IntuitiveNipple> maybe try repairing or disconnecting the port?
<elwood> so i can remove it physically, this is the way
<IntuitiveNipple> maybe not 'remove' it but electrically disconnect it so the hub doesn't try to select it... but that would require some in-depth systems knowledge. There's no way to isolate it from the kernel that I know of.
<elwood> IntuitiveNipple, even if i recompile without log info for the kernel?
<IntuitiveNipple> That's rather a drastic approach - what if something else happens and there's no reports?
<elwood> a disaster, well thanks IntuitiveNipple 
<IntuitiveNipple> You could add a rule to syslog.conf
<elwood> uhm
<elwood> a filter on this warning
<IntuitiveNipple> no, you can't filter on text, but you can set a rule so it doesn't log messages from particular facilities.priorities
<elwood> this is what i means with "filter", well you make me find a reasonable solution, thanks again IntuitiveNipple 
<dandel> apw, you there?
<IntuitiveNipple> He's probably fast asleep in bed this time of morning
<dandel> uck... i need a rebuilt copy of the 2.6.25 mainline
<dandel> the one that is on the ubuntu mainline section won't boot enough to help with generating a git disection. 
<dandel> i keep having 2.6.25 stall just after saying done on the section, Begin: Running /scripts/local-premount ...
<IntuitiveNipple> You could use break=top to drop into the initrd and poke around
<dandel> add that where?
<IntuitiveNipple> kernel command line
<dandel> ok
 * dandel checks
<IntuitiveNipple> In the /init script is loads of calls to maybe_break XXXXX and if XXXX matches the command-line's break= it'll stop
<IntuitiveNipple> Or, use just "break" and it'll stop at top anyhow
<IntuitiveNipple> You can break at other places; need to look in the /init script (in the initrd) to decide which ones to use)
<dandel> it appears that it gets stuck mounting
<dandel> 2.6.24 and 2.6.26 work, but 2.6.25 stalls out
<IntuitiveNipple> What I sometimes do is add "set -x" to the top of the /init script so I can see all the script commands executing... if it pauses/gets stuck the last ones on screen are a bug clue
<dandel> ?
<IntuitiveNipple> It causes the shell to write out all commands it is about to execute
<dandel> where do i put that exactly?
<IntuitiveNipple> 2nd or later lines in /init, in the initrd. You'll need to extract and then repackage the initd image
<dandel> ><;
<IntuitiveNipple> I've got some documentation on how to do that as part of a laret article
<IntuitiveNipple> http://tjworld.net/wiki/Linux/Ubuntu/NetbootPxeLiveCDMultipleReleases#ExtractInitrd
<IntuitiveNipple> To extract the image see the section "Extract Initrd" and after changing the script, see "Rebuild Initrd"
<dandel> ok...
<dandel> ok.
<dandel> add set -x just after...  #!/bin/sh ?
<IntuitiveNipple> Yes
 * dandel boots to see what happens.
<dandel> oops lol... forgot to add it to grub.
<IntuitiveNipple> :p
<IntuitiveNipple> did it spew the commands though?
<dandel> i'll find out
<dandel> it's not finding it ><;
<IntuitiveNipple> which 'it' is not finding what 'it' ?
<dandel> the custom initrt... found the issue tho
<dandel> although, i wish i could flat out disable system beep on a lot of things
<dandel> hmm
<dandel> interesting
<dandel> stops at the command... mount -w -t ntfs -o locale=en_US ( ya get the rest )
<dandel> it appears it's running the mount commands wrong
<maxb> smb_tp_: Hi, ubuntu-intrepid-lbm.git doesn't contain the final debian/changelog update and tag for the latest package, did it remain accidently unpushed locally with you, perhaps?
<smb_tp_> maxb, hi, let me check
<smb_tp_> maxb, Yeah, sorry. Pushing in a sec
<smb_tp_> done
<maxb> thanks :-)
<maxb> Hmm. my git is claiming there is no tag for this release?
<smb_tp> maxb, Too early in the morning to do two steps...
<maxb> heh
<smb_tp> Now
<maxb> I guess that answers my next question: the insertchanges/commit/tag isn't automated anywhere?
<smb_tp> maxb, No, has to be done manually. And it has to be pushed separately (it least I had problems doing it in one go)
<smb_tp> So This time the tag was created, but I had to "push --tags"
<maxb> Yeah, git's a bit mystical to me. I don't really understand when you do and don't need --tags
<smb_tp> To me it looks like a extra thing just for tags. So git fetch --tags just updates the local tags and git push --tags sends them
<smb_tp> Without tags it seems only to do the actual contents
<maxb> the fetch/push documentation hints that it tries to transfer tags relating to commits that are being transferred. But I have a feeling that's not always worked as claimed for me.
<maxb> or I've not quite understood the algorithm, anyway
<smb_tp> Same with me. So I use it in that way that seems to work with my thinking (if I do not forget the steps)
<_ruben> bugger .. dkms isnt picking up my second make command as specified in dkms.conf :(
<IntuitiveNipple> syntax issue?
<_ruben> could very well be .. but im not seeing it .. lemme pastebin my conf
<_ruben> http://paste.ubuntu.com/136597/ .. i tried both MAKE[1] and MAKE[10] .. as the result of the 2nd make are marked with [10] directives
<IntuitiveNipple> _ruben: Why not simply use a Makefile and call it once?
<IntuitiveNipple> _ruben: but, to use MAKE[10] you need a MAKE_MATCH[10] rule too
<_ruben> IntuitiveNipple: hmm .. didnt think of the MAKE_MATCH directive .. but i can think i can solve it at makefile level indeed
<IntuitiveNipple> MAKE_MATCH is required if you use MAKE[>0]
<_ruben> then there's a bug in the docs:
<_ruben> https://help.ubuntu.com/community/Kernel/DkmsDriverPackage#Configure%20DKMS
<_ruben> it mentions just a MAKE[1]
<IntuitiveNipple> _ruben: man dkms
<apw> IntuitiveNipple, hey ... bug #331415 ... have you a current status on that one, its on our regressions list :)
<ubot3> Malone bug 331415 in linux "request_firmware() fails on resume from suspend" [Medium,Triaged] https://launchpad.net/bugs/331415
<IntuitiveNipple> apw: WIP it's a biggie. I'll update it later on
<apw> IntuitiveNipple, thanks ... be good to sync up on it before the meeting this evening
<IntuitiveNipple> It's a time-consumer! every driver has to be examined and figured out... I'm doing a little bit at a time
<IntuitiveNipple> apw: I think it can loose it's regression-potential since it's always been like that :)
<IntuitiveNipple> apw: removed tag
<apw> IntuitiveNipple, thanks for that ... one less to worry about
<IntuitiveNipple> yeah... I was combing the list yesterday, managed to find a few that moved closer to a resolution
<amitk> hehe... Linus' 2.6.29 release mail got flagged as SPAM in gmail :)
<amitk> apw: can you pull the levers on a new mainline build?
<amitk> apw: or tell me how to
<apw> amitk, which one you missing.  there is a build in progress right now, so its probabally the one you wanted
<amitk> apw: 2.6.29 final?
<apw> i think i saw it doing a .27 and a .28 ...
<apw> ok will check when these finish
<apw> and i will get the thing running out of cron this week
<apw> the triggers are automatic in theory
<apw> amitk, yeah its just done 27.21, its on 28.9 and will do .29 next i believe
<apw> so in the next hour or so
<amitk> cool, thanks apw 
<TheMuso> c
<apw> i have been monitoring the builds, and so hand triggering what is meant to be a cron job
<apw> so its a simple matter of shoving it in cron (or should be)
<dandel> apw, the bug i'm on is stuck until the 2.6.25 kernel gets fixed on boot ><; (it gets stuck on mounting )
<amitk> apw: do you do a allmodconfig?
<apw> nope, they are built using our ubuntu configs
<apw> make oldconfig from those
<apw> we can override config options where neceessary
<apw> like for hardy we reenable some wireless stuff which is in lbm
<amitk> ok
 * Kamping_Kaiser gazes at the wall
<amitk> apw: bug #322311 and bug #338316 marked as 'Won't Fix' for the two arm flavours
<ubot3> Malone bug 322311 in qcontrol "orion5x armel flavour should provide input-modules" [Undecided,New] https://launchpad.net/bugs/322311
<ubot3> Malone bug 338316 in linux "Please add a MV78XX0 arm flavour" [Wishlist,Won't fix] https://launchpad.net/bugs/338316
<apw> amitk, cool
<rtg> apw, amitk: were there other bug fixes besides VFP for those flavours that we can remove?
<apw> i don't recall doing any
<amitk> rtg: I mentioned ce65d39bbcfaa3c0150891122df79f5ab2db550d needed to be reverted
<rtg> amitk: see 14b2f940288288774f74414a0902d578d29d9076
<rtg> amitk: oops, nm
<amitk> hehe
<rtg> amitk: ok, you're right. tehre were 2 VFP patches and I missed the second.
<rtg> amitk: I'm not familiar with all of the ARM model names. To which flavour does the Feroceon CPU belong? orion5x or mv78xx0 ?
<amitk> rtg: mv78xx0
<rtg> amitk: thanks
<_ruben> http://paste.ubuntu.com/136726/ .. i forgot skipabi=true on the first run .. do am i missing here? or is a clean+rebuild needed or something?
<cooloney> bradF, did you boot up with your own rootfs
<cooloney> bradF, amitk i also boot up my own kernel.
<cooloney> as bradF said, we need to download the kernel to 0x00100000
<cooloney> that is the entry point of the kernel image
<amitk> right
<cooloney> amitk, how about the kernel command line of your board?
<cooloney> i try to mount the rootfs with my own kernel
<cooloney> after replacing the kernel of ogra image with my own, the kernel cannot mount rootfs
<amitk> root=/dev/sda2
<amitk> i use root on a usb stick
<cooloney> OK, i will try, thx
<cooloney> it is so weird
<cooloney> http://pastebin.ubuntu.com/136755/
<cooloney> amitk, what kind filesystem are you using on the usb stick?
<amitk> cooloney: ext2
<rtg> amitk: is ext3 built in?
<amitk> rtg: yes, i think so
<amitk> yes, it is
<rtg> amitk: it even says so
<amitk> rtg: what does?
<cooloney> rtg, yes, ext3 built in
<rtg> amitk: No filesystem could mount root, tried:  ext3 ext2 cramfs vfat msdos
<amitk> aah, right
<amitk> cooloney: do you have initramfs loaded?
<rtg> amitk: noinitrd on the command line
<cooloney> amitk, currently no
<cooloney> RedBoot> fconfig
<cooloney> Run script at boot: true
<cooloney> Boot script: 
<cooloney> .. clock 800
<cooloney> .. fis load kernel
<cooloney> .. exec -c "console=ttymxc0,115200 console=tty1 root=/dev/sda2 rootdelay=10 ro noinitrd"
<amitk> USB_STORAGE is built-in. Is your usb disk supported w/o modules?
<amitk> and is the rootfs on /dev/sda2?
<cooloney> amitk, do you think i should add "fis load initramfs"
<cooloney> sorry, what is "w/o modules?"
<rtg> yeah, shouldn't root be /dev/sda1 ?
<amitk> cooloney: do you need any special modules besides usb-storage
<cooloney> OK, let me try it.
<anubhav> cooloney: can you append "rootwait" to your command line
<cooloney> anubhav, i will try it
<cooloney> amitk, rtg anubhav thanks, i found root is sda1 as ext3 on my usb stick
<rtg> cooloney: makes sense to me
<cooloney> since this usb stick is from colleague freeflying
<cooloney> i did change it's content at all
<cooloney> amitk, should i build my own rootfs from scratch?
<amitk> cooloney: you don't have to
<cooloney> i just need to boot the board to command line console over serial for development, i guess
<amitk> right
<rtg> cooloney: babbage?
<cooloney> rtg, yes
<cooloney> babbage early version
<rtg> cooloney, amitk: does it work with SATA yet? I'cve got one, but the USB drive is _really_ slow.
<cooloney> rtg, i dont have sata on my side, just know SD and USB stick is ok 
<rtg> cooloney: looks like you build the kernel? Our Freescale port using the cross compiler tools?
<amitk> rtg: it was native built
<cooloney> rtg, right, i cross compiler our jaunty kernel to zImage
<amitk> rtg: but you can replace the kernel with a cross-compiled one
<rtg> amitk: Sourcery G++ Lite 2008q3-72
<cooloney> and downloaded the zImage to boot up now
<amitk> rtg: yeah, good enough
<cooloney> amitk, i replaced the kernel from ogra image with my own kernel from cross-compiled one
<rtg> amitk: its interesting because its the first time I've seen the cross compiled kernel booted. Its just verification that it works taht way.
<amitk> rtg: you mean the first time you've seen cross-compilation used for something other than build verification?
<rtg> amitk: in this particular case, yes
<amitk> rtg: I've been using cross compiled kernels for the last month or so while we were integrating and testing the babbage flavour
<rtg> amitk: its certainly a much faster way to build, isn't it?
<amitk> rtg: hell yeah! I'd go nuts doing this in Qemu or natively
<rtg> the babbage was taking several hours per flavour
<bradF> cooloney: haven't tested my own rootfs yet, just the kernel
<amitk> rtg: it takes about 15-20 minutes on my rather old desktop machine for the babage kernel
<rtg> amitk: :) I can beat that by 15 minutes.
<cooloney> amitk, rtg are you talking about cross-compiling babbage kernel on x86 machine?
<amitk> rtg: showoff!
<amitk> cooloney: yes
<rtg> cooloney: dual quad core w/18GB RAM.
<bradF> cooloney: that's how I am building my kernels
<bradF> cooloney: rtg likes to brag :-)
<cooloney> rtg, really cool
<cooloney> bradF, lol
<cooloney> guys, let me test on my side
 * rtg thinks bradf has computer envy.
<amitk> cooloney: you were _not_ cross-compiling until now?
<bradF> rtg feels sad for rtg
<cooloney> i always cross built
 * bradF feels sad for rtg
<cooloney> but dont know the time
<rtg> amitk: that was the whole point of this discussion, e.g., I noticed that he booted a cross compiled kernel.
<cooloney> hehe, let me collect the timing info
<amitk> right... 
<bradF> amitk: what's the word on the 'securityfs' for AA? should I chase that?
<bradF> amitk: just saw your email...will try it
<rtg> is there still an AA upstream to send it to ?
<amitk> bradF: it certainly seems worth a shot to see if enabling securityfs is all thats needed. Though I vaguely recall having tried that.
<amitk> rtg: If there isn't, then what're we doing carrying around that patch and letting it bitrot?
<rtg> amitk: Its a topic for UDS, but I'm thinking this is the last release with AA.
<amitk> interesting
<cooloney> can i reproduce this bug on my side?
<cooloney> if bradF needs help, i can join in
<bradF> cooloney: are you talking about the apparmor bug?
<cooloney> right
<cooloney> AA = apparmor, if i am not wrong?
<rtg> cooloney: correct
<bradF> it's easy to repro, just go into your config and change the CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE from 0 to 1
<bradF> cooloney: then if you don't have my patch, it will oops
<rtg> bradF: with your latest patch (which I have not applied), how does it behave? Just the usual VFS can't find root halt?
<cooloney> ok, booting oops?
<bradF> cooloney: yes, booting oops, every time
<cooloney> great, i will try 
<bradF> rtg: yes on "can't find root"
<cooloney> cross-compiling imx51 deb package on my side nees 13m
<rtg> bradF: so, we're just trading on oops for another? albeit a bit more understandable.
<rtg> one*
<bradF> rtg: going to hook up a rootfs and see if it comes all the way up (looks like cooloney will probably try this as well)
<bradF> rtg: are you talking about the securityfs?
<rtg> bradF: yes
<cooloney> bradF, yes, i plan to do it. but it seems that it will take too much time to build a root fs on my side
<amitk> rtg: if AA truly needs securityfs, then it should be a autoselected dependency
<bradF> rtg: the missing securityfs doesn't cause an oops, just that AA is not doing anything
<rtg> bradF: ok, thats what I wanted to know. With the patch you can boot a rootfs, but without AA support, correct?
<bradF> rtg: let me run a couple of tests, but yes that is what I believe
<rtg> bradF: ok, when you're comfortable send me a pull request.
<bradF> rtg: will do
<bradF> amitk: i understand your point and depending on my testing my submit another patch 
<bradF> s/my/may/
<amitk> bradF: sure, take your time.
<charlie-tca> I downloaded today's images, they passed md5sums. I burned the Xubuntu jaunty-alternate-i386.iso to a cd-r. It passes the cd integrity check with no errors. I attempt to install to a hardware system. It fails with 
<charlie-tca> Warning: file:///cdrom/pool/main/x/xkeyboard-config/xkb-data_1.5-2ubuntu9_all.deb was corrupt
<charlie-tca> (I burned another cd-r that works) Should I report this as a bug?
<amitk> charlie-tca: this is best reported on #ubuntu-devel
<charlie-tca> Okay, thanks
<bradF> amitk: the kernel I just booted with the securityfs enabled seems to be working!
<amitk> interesting
<amitk> so it _is_ a dependency
<bradF> amitk: [42949373.670000] AppArmor: AppArmor Filesystem Enabled
<bradF> amitk: yup
<rtg> bradF: so I should expect some config changes along with the oops prevention?
<bradF> rtg: they are independent of each other but the config change is necessary to run AA on imx51 (and all other flavours)
<apw> the oops prevention is moot if its a dependancy and so recorded in the config
<amitk> bradF: this kernel is w/o your oops prevention patch?
<bradF> amitk: it has both
<bradF> amitk: however, it should work without my oops patch, will test
<rtg> bradF: see if it works with just the config change
<amitk> bradF: yeah, that would be interesting
<bradF> apw: I see your point
<apw> it does sounds like an unrecorded interdependancy to me
<amitk> though the oops prevention is what triggered the securityfs config light-bulb if I understood bradF correctly.
<bradF> apw: it still seems like it should handle a missing securityfs a little better than an oops
<bradF> amitk: yes
<apw> bradF, not if its a depanancy, it should just be linked in the Kconfig magic
<apw> and then become impossible to enable without the securityfs enabled
<cooloney> bradF, is this boot oops?
<cooloney> [42949373.670000] AppArmor: Error creating AppArmor securityfs
<cooloney> [42949373.700000] AppArmor: AppArmor protection removed
<bradF> cooloney: after that you should get am actual oops and a backtrace
<cooloney> bradF, right, i reproduce it
<cooloney> thx
<bradF> cooloney: http://pastebin.ubuntu.com/136819/
<bradF> cooloney: it looks like you just need to enable the security fs and you don't need the patch I put out
<cooloney> bradF, thx, i can test your method on my side
<apw> cking, any idea waht a bcdDevice means in the context of usb?
<Keybuk> apw: device id in binary coded decimal
<Keybuk> USB is *all about* bcd
<apw> hrm, so something above and beyond its normal id's
<apw>   idVendor           0x04ce ScanLogic Corp.
<apw>   idProduct          0x0002 SL11R-IDE IDE Bridge
<apw>   bcdDevice            0.78
<apw> so that is a triplet in usb land?
<Keybuk> i think so yea
<Keybuk> it's basically the version number
<_ruben> hmm .. recompiling kernel is taking up a fair amount of cpu sys % .. i'd expect just usr .. then again, havent rebuilt kernels in ages :p
 * apw learns yet another new thing today
<cooloney> apw, IMO, it is right, 
<cooloney> idVendor           0x05ac Apple, Inc.
<cooloney>   idProduct          0x8242 
<cooloney>   bcdDevice            0.16
<apw> Keybuk, any  idea what waht base the output is in 
<apw> is it decimal, or hex or?
<cooloney> it is just a version number as Keybuk said
<apw> right but the output of the lsusb command what base is it in there
<cooloney> yes, lsusb will convert the binary code to such version number
<IntuitiveNipple> apw: decimal
<Keybuk> apw: binary coded decimal
<cooloney> it should be 0x1600
<cooloney> right?
<Keybuk> http://en.wikipedia.org/wiki/Binary-coded_decimal
<apw> hrm, i see, so its literally in hex in some sense
<Keybuk> right you literally read the hex
<Keybuk> 0110 is read is 1.10
<Keybuk> 0206 is 2.06
<Keybuk> etc.
<apw> ok, so yeah bcd is hex format but you arn't allowed to use some of the combos
<apw> thanks
 * apw puts USB on his idiot idea list
<rtg> IntuitiveNipple: I'm just looking at your RCU backport. Is that patch in response to smb_tp's RFC on boot pauses?
<Keybuk> apw: USB is great!
<Keybuk> it's ALL about the ids ;)
<Keybuk> every gadget has a vendor and a product id
<cooloney> Keybuk, really, it should be 1.10 = 1001
<Keybuk> and a device version number
 * apw slaps Keybuk ... get a grip man :)
<Keybuk> and each device may have multiple configurations
<cooloney> 2.06 = 0602
<apw> cooloney, that _all_ depends on your endiannes
<IntuitiveNipple> rtg: Yes, it is backported from the upstream commit 
<Keybuk> depending on the configurations, you then have multiple interfaces
<cooloney> apw, for usb it should be lsb little endian
<rtg> IntuitiveNipple: I got that part. I was wondering _why_ you did the backport.
<Keybuk> and only then do you actually find out what the device *is* :p
<Keybuk> cooloney: err, is it?
<Keybuk> I'm pretty sure it's big endian
<IntuitiveNipple> rtg: Ingo Monar in the upstream bug thought the commit may solve the issue, so I figured we should try it against our tree
<IntuitiveNipple> s/Monar/Molnar/
<apw> the kernel is behaving as if 0074 -> 0.74
<rtg> IntuitiveNipple: is there a repeatable test case that you know of?
<sconklin> maria/join #ubuntu-meeting
<cooloney> idVendor           0x1d6b Linux Foundation
<cooloney>   idProduct          0x0002 2.0 root hub
<cooloney>   bcdDevice            2.06
<cooloney> 0x002 = 2.0
<Keybuk> cooloney: right, and if you cat the usb device's bcdDevice
<IntuitiveNipple> rtg: No - I was waiting for Stefan to produce some test kernels for the users reporting on the bug 
<Keybuk> you'll see 0206 in there
<Keybuk> 0206 -> 2.06
<rtg> IntuitiveNipple: ok, I'll annoy smb_tp
<IntuitiveNipple> rtg: :)
<smb_tp> rtg, I am not listening
<Keybuk> idVendor and idProduct are 32-bit words
<BUGabundo> hi
<Keybuk> idVendor assigned by a central naming authority
<Keybuk> idProduct assigned by the vendor
<rtg> smb_tp: take your hands off your ears, I can't hear you.
<Keybuk> then for each product, you have a bcdDevice which supplies its version number
<BUGabundo> 6 out of 10 resumes my laptop gets so slow that I'm required to reboot it
<Keybuk> err 16-bit words
<BUGabundo> how can I debug this?
<smb_tp> rtg, Huh?
<Keybuk> bcdDevice is 4 4-bit bcd numbers, representing the version number of the device
<BUGabundo> I noticed that setting cpu to performance "fixes" this
<rtg> smb_tp: kind of wrecks your mind, huh?
<BUGabundo> but once I set it back to OnDemand slowness returns
<cooloney> Keybuk, but we should firstly receive lsb until msb
<Keybuk> cooloney: ?
<smb_tp> rtg, Not _that_. But to answer, yeah aÃ wanted to do that, I'll write it down to remember as soon as I am finished with what I am doing right now
<cooloney> Keybuk, first receiv 06 then 02 for 2.06 bcdDevice
<rtg> smb_tp: k, just note that the window for Jaunty is closing.
<Keybuk> cooloney: why?
<BUGabundo> ok, you guy are busy... I'll come back latter
<smb_tp> rtg, yeah, I hope I am done with that stupid thing in a little
<cooloney> Keybuk, usb device should send out 06 firstly then 02
<Keybuk> cooloney: err, why?
<IntuitiveNipple> Spec 8.1 Byte-order is LSb
<Keybuk> bcdDevice is not specified as a byte
<Keybuk> the things specified as a byte are the ones beginning b, like bNumInterfaces
<cooloney> Keybuk, you are right, i confused bcdDevice with some values like wLength
<Keybuk> the entire bcd field is sent in reverse, yes
<Keybuk> but as one unit
<cooloney> right,
<Keybuk> wLength is a word, so that entire word would be sent in reverse
<Keybuk> not each individual byte
<cooloney> exactly, cause i met a bug before which took me last of time
<cooloney> right, for wLength we need so le16 helper function to get their value
<cooloney> s/so/some
<Keybuk> (I could be massively wrong, but I'm fairly sure I'm not :p)
<cooloney> Keybuk, you're right on bcdDevice
<IntuitiveNipple> all bits and fields are sent least-significant _bit_ first according to the spec
<Keybuk> right, it's a serial bus ;)
<IntuitiveNipple> multi-byte packets travel LSB wise
<IntuitiveNipple> s/packets/fields/
<Keybuk> LSB or LSb? :p
<cooloney> 0x00, 0x02, /*  __le16 bcdUSB; v2.0 */
<cooloney> we need set lower byte to 0x00 and higher one to 0x02
<IntuitiveNipple> both... bits are LSb fields are LSB
<cooloney> when we initialize a usb2_rh_dev_descriptor in drivers/usb/hcd.c
<cooloney> right
<cooloney> IntuitiveNipple, right
<cooloney> wLength  = le16_to_cpu (cmd->wLength); 
<cooloney> we need le16_to_cpu for word value,
<cooloney> drivers/usb/core/hcd.c:	0x00, 0x02, /*  __le16 bcdUSB; v2.0 */
<cooloney> drivers/usb/core/devices.c:	u16 bcdUSB = le16_to_cpu(desc->bcdUSB);
<Keybuk> that could be the HCI bit
<Keybuk> it all gets complicated ;)
<Keybuk> bus sends it one way, the host in the computer turns that around and sets it another way, but then the CPU in the computer turns it around and sends it yet another
<cooloney> i think we just need take care of those 16bits field in usb descriptor structures. 
<cooloney> usb le16_to_cpu to help us out
<cooloney> s/usb/use
<Keybuk> depends where in the kernel you're looking
<Keybuk> everything above the hcd uses CPU ordering, I think
<Keybuk> so bcdDevice=0x0110 -> 1.10
<Keybuk> might be wrong on that one
<Keybuk> the hcd spec might end up needed that as Intel-CPU ordering (since Intel wrote it :p)
<Keybuk> so that becomes 0x10, 0x01  (0001 0000, 0000 0001)
<Keybuk> but then the bus spec says the entire field is LSB, so over the wire it's 0000 1000 1000 0000 I thijnk
<Keybuk> feel free to go mad any point
<cooloney> i guess so, 
<cooloney> hcd is a driver which should take care of this order
<Keybuk> (bearing in mind of course that on an Intel machine, bcdDevice=0x0110 ends up as 0x10, 0x01 in memory *but* 0x01, 0x10 in memory on something MSB)
<cooloney> but the order from usb hardware controller should be fixed as spec said
<Keybuk> the kernel doesn't talk to such a device
<Keybuk> the kernel talks to the Host Controller
<Keybuk> which is a different spec
<Keybuk> the host controller does the wire stuff
<cooloney> right, host controler is a hardware which take case of the data transfer
<Keybuk> anyway, if there was an original question here, we've strayed a long way from an answer to it ;)
<cooloney> but hcd is host controller driver which is a software driver in kernel to handle that data from hardware
<cooloney> yes,
<cooloney> but i do like to discuss something with you guys here 
<Keybuk> no, the host controller is the pci device
<Keybuk> the host controller driver talks to the host controller
<Keybuk> the host controller talks to the hardware
<cooloney> oh, pci stuff is in pc domain
<cooloney> if in SOC like iMX51, the usb host controller is directly memory mapped
<cooloney> hcd controls it directly.
<Keybuk> sure, but they talk the hcd protocol, not the usb protocol
<Keybuk> so you'd have to pick up the xhci, ehci, ohci or uhci spec and see what that says for data transfer ;)
<Keybuk> if mucking around with the hcd driver
<Keybuk> everything about the hcd driver, ie. when writing usb drivers, just do what the Linux kernel docs say
<cooloney> right, 
<cooloney> for imx51 or other soc, the usb host controller does not support ehci/ohci/uhci 
<Keybuk> it doesn't?
<cooloney> they use their own register layout and need a new driver
<cooloney> drivers/usb/musb
<cooloney> it is a usb driver for Davinci/omap/Blackfin
<cooloney> mentor graphic ip
<Keybuk> it at least vaguely pretends to be ehci
<Keybuk> not that I can get my imx51 to boot today
<cooloney> oh, imx51 does includes EHCI host and USB OTG from ARC
<cooloney> the host mode driver in USB OTG should not be EHCI
<Keybuk> oh yeah, I remember why I hate this thing
<cooloney> usb is always my headache.
<cooloney> -:))
<cooloney> especially in embedded world
<Keybuk> yeah, this has that silly fsl-ehci thing that's a platform device
<cooloney> Keybuk, sorry, my mistake
<cooloney> the USB OTG of imx51 also supports EHCI
<cooloney> drivers/usb/host/ehci-arc.c
<cooloney> drivers/usb/host/ehci-fsl.c is for the EHCI host
<Turl> hi
<Turl> can you suggest any other information for https://bugs.launchpad.net/bugs/348093 ?
<ubot3> Malone bug 348093 in linux "Brightness keys ACPI events are not translated to keycodes" [Undecided,New] 
<Turl> (and confirm & set priority maybe?)
<sourcemaker> are there known problems with the 2.6.29 kernel?
<Kano> hi rtg , could you fix at least the linux-headers package when you dont add my aufs fix?
<Kano> there are some missing files
<Kano> acpi/acpica/ dir is missing
<Kano> there are 3 headers in it
<Kano> well there are more, but fglrx needs 3
<Kano> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=tree;f=include/acpi;h=5ef3a2cd591223bf069be60037f2c576023752aa;hb=HEAD
<Kano> this is not in the headers
#ubuntu-kernel 2009-03-25
<tjaalton> apw: I noticed that you were assigned to bug 256296
<ubot3> Malone bug 256296 in linux "USB id 0af0:6911 should use hso and not 'option' driver" [Medium,Fix committed] https://launchpad.net/bugs/256296
<apw> tjaalton, hrm ... 
<tjaalton> I've got a similar(ish) device, id 0af0:7011 that uses option by default, but removing it and loading hso doesn't seem to work
<tjaalton> :)
<apw> hm i didn't remember it, as it seems to have been one where a stable update fixed it for us
<apw> so i didn't really do anything to it :)
<tjaalton> bummer
<tjaalton> this one doesn't work in jaunty, but I'll go hunt a patch for it
<apw> when you say removing it and loading hso, do you mean litteraly just rmmod modprobe?
<tjaalton> yes
<tjaalton> probably isn't enough
<apw> that i wouldn't expect to do anything, one of them will be tied to that PCI id
 * apw checks
<tjaalton> right..
<Kano> hi, is anybody working on 2.6.29 today
<Kano> the acpi dir is missing from header package
<apw> yeah hso has those usb id's in it
<apw> drivers/net/usb/hso.c:	{default_port_device(0x0af0, 0x7011)},
<apw> so i would have expected that one to be loaded not option
<apw> but that is what you wanted me thinks?
<tjaalton> does it need an entry in unusual_devs.h?
<apw> is it a disk?
<tjaalton> both
<apw> that is for storage
<tjaalton> the storage part has windows drivers..
<apw> it only needs an entry there if is its broken
<apw> ie non-standard in some way
<tjaalton> https://lists.one-eyed-alien.net/pipermail/usb-storage/2009-January/004498.html
<apw> thats not the same id's tho
<tjaalton> no, but similar fashion
<apw> you could try duplicating that one
<apw> and putting your id's on it
<apw> assuming you have nothing on it you care about
<tjaalton> nope
<apw> you presumably are ok making your own kernels to test this?
<apw> you should file a bug for this either way of course
<tjaalton> yes, sure
<tjaalton> sigh, hal should've picked it up but didn't
<tjaalton> or maybe it really needs the kernel patch first
<apw> Keybuk, hey ... was it you who told me they had tried booting in OnDemand and it was slower
<Kano> tjaalton: do you play with aufs?
<tjaalton> Kano: no
<Kano> anybody else?
<tjaalton> apw: silly question; how do I get the correct hex values for UNUSUAL_DEV? the first two are obvious, but the rest aren't
<apw> the first two are the usb id, the next two are the bcdDevice range, low, high
<apw> i see in the one you are copying they are 0000 and 9999 so use those
<apw> ie _all_ devices in that id
<tjaalton> ok, thanks
<tjaalton> apw: tried this http://users.tkk.fi/~tjaalton/foo/option-7011.diff but it didn't seem to work
<tjaalton> duh
<apw> ?
<tjaalton> maybe I should've used US_FL_IGNORE_DEVICE instead of 0
<apw> heh
<tjaalton> because jaunty doesn't have option_ms_init, the "0" was a leftover from the other patch
<_ruben> when having just ssh access at your disposal .. how can one increase the entropy pool? .. generating a 2048 rsa key on a remote seems to have stalled
<lool> apw: Given you last touched the prerm, I think you'd be the best person to review the proposed changes to fix https://bugs.launchpad.net/ubuntu/+source/linux/+bug/348395
<ubot3> Malone bug 348395 in linux "Leaves /lib/modules/$(uname -r)/*.bin files behind" [Undecided,New] 
<apw> lool ack
<apw> as in i'll look
<NCommander> The lpia configuration currently has CONFIG_ATA as a module, can we change that to be compiled in? Its causing the installer to break down and cry since it can't find the HDD or the CD-ROM
<apw> lool there is no fix on there
<NCommander> (I'd actually like to copy the current i386 config to lpia, since there are quite a few differences it seems
<apw> but its also a duplicate of a bug which is in progress
<apw> i'll get it sorted out
<lool> apw: There's a description of what to change, which is to list the three files in the @files_to_remove array
<apw> lool.  yes indeed
<lool> Which I think is as long to do for someone than merging a patch or a git tree, but really much faster for me
<apw> thanks for the heads up
<lool> apw: Didn't find the duplicate though, sorry
<apw> don't worry i never ever find anything in launchpad either
<apw> its search and i do not get on
<lool> (I only found users with this issue in forums etc. when googling)
<apw> dammit launchpad is soooo slow
* lool changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest news: Released 2.6.28 kernel for Jaunty/9.04. | Kernel git trees: http://kernel.ubuntu.com/git | Latest kernel upload: 2.6.28-11.36 based on 2.6.28.8 final
<lool> (removed quotes in topic)
<lool> apw: Today?
<lool> :-P
<apw> now, always,
<apw> you watch anyone who uses it a lot
<apw> and they have loads of tab based tricks to get round its immense slowness
<apw> prefetching bugs and stuff
<lool> Yeah, I don't think I would notice if it becomes fast in the future, I'll continue loading pages in the background while context switching to something else
<apw> heh see, you do it too
<lool> Yeah, and my ADSL doesn't help, it's sluggish and loses packets; anyway => lunch &
<NCommander> second question, is there an easy way to build the lpia kernel on amd64?
<tjaalton> apw: huh, hso claims that "not our device" when modprobing it
<tjaalton> sorry, "Not our interface"
<tjaalton> looking at hso.c doesn't list the id as USB_DEVICE
<Kano> hi rtg , did you get what i worte yesterday, that the acpi dir is missing from 2.6.29 header package? I have no idea how to fix it, please do
<apw> Kano, wahts the bug number
<Kano> i guess there is none,because the error is in git only
<Kano> but the result of this problem is that: http://www.phoronix.com/forums/showthread.php?t=16173
<Kano> the correct fglrx patch does not work due to missing files
<apw> if the headers package is missing files, then its a bug on your machine.  so lets get a bug filed
<apw> we have someone looking at a different missing header at the moment and would make sense to fix both at the same time
<Kano> the headers are installed, that dir is new and missing
<Kano> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=tree;f=include/acpi;h=5ef3a2cd591223bf069be60037f2c576023752aa;hb=HEAD
<Kano> thats new
<apw> bang all that info in a bug and let me know the number
<Kano> but somehow i do not even see that acpica subdir in it...
<apw> the directories which get put in there are selected manually
<Kano> i guess that acpica sub dir inside acpi is created when you compile it
<Kano> or it is completely missing there as it is in drivers/acpi/acpica/acconfig.h
<Kano> but fglrx needs those includes somehow
<IntuitiveNipple> apw: ping (re bug #337929)
<ubot3> Malone bug 337929 in linux-backports-modules-2.6.28 "ieee80211_regdom=EU now causes oops after latest update" [Medium,In progress] https://launchpad.net/bugs/337929
<apw> IntuitiveNipple, hi ... wassup?
<IntuitiveNipple> apw: got a couple of minutes to discuss ^^^
<apw> sure
<IntuitiveNipple> apw: I debugged it last evening based on max's oops log and building the same version lbm and tracing the disassembly.
<apw> ok, what did yo ufind
<apw> can't say i've done much with it as yet
<IntuitiveNipple> apw: It got to the point I was bog/bug-eyed and not clear in my thinking because I chased down several false trails, *but* I think the reason for the bug is an off-by-one or out-of-bounds write issue
<apw> ok makes sense
<rtg> IntuitiveNipple: I think you ought to be able to produce the same result with 2.6.29. If thats the case, you could annoy the upstream guys with this bug.
<IntuitiveNipple> The crux of the issue *seems* to be that in wiphy_update_regulatory() at the end is a test on wiphy->reg_notifier
<IntuitiveNipple> If that is non-zero it is expected to be a function call-back pointer
<apw> and what we putting in there
<IntuitiveNipple> I may be wrong here because I was getting tired, but I'm pretty sure what is happening is in the wiphy struct that pointer is stored immediately after the bands[xxx] array pointers, and the value in it is 0x00000004 - I *think* bands[xxxxx] is going out of bounds and writing into reg_notifier
<IntuitiveNipple> causing the attempt to call the function 
<apw> that would be bad ... will have a look
<IntuitiveNipple> It's annoying to trace, I got lost in all the back-n-forth. 
<IntuitiveNipple> My other question about it is, find out what max has in the module options setting - is the setting he has for the lbm_cw_cfg80211 module or cfg80211 
<apw> yeah its not at all clear fromt ehb ug
<apw> though he's not dumb
<apw> it should fail to laod if its for the normal module
<apw> you filed the bug for that one i think
<IntuitiveNipple> Because there is another potential issue I discovered: when we have OLD_REGULATORY enabled *and* CRDA in use, there's some unusual code paths and potential forced changes to the domain/bands that could potentially lead to this issue. I didn't find evidence of that, but had the suspicion
<IntuitiveNipple> No, you misunderstand me... I was wondering if the module option was being picked up by lbm_cw_cfg80211 even though it is set for cfg80211. I wondered that because at one point I was doubting the symbol munging
<Keybuk> apw: yes
<IntuitiveNipple> Later I resolved some of those doubts but... :)
<apw> Keybuk, i forget what i asked, damn
<Keybuk> apw: whether I said booting with ondemand was slower
<apw> ahh yes, thanks
<apw> Keybuk, that needs recording somewhere so we don't think its a good idea to undo it again
<Keybuk> do we have somewhere where we record kernel config decisions?
<apw> i am suspecting not, and that we should
<apw> rtg do we have a wiki page with anything about our config that you remember?
<rtg> apw: we did something for the last UDS, but I've lost track of it.
<apw> yeha we did didn't we
<apw> we could do with a meta something pointing to that
<apw> and listing generaly things like this
<IntuitiveNipple> was it this? https://wiki.ubuntu.com/KernelTeam/Specs/BootPerformance
<IntuitiveNipple> which links to: https://wiki.ubuntu.com/KernelTeam/2.6.28-2-generic-config
<apw> yeah that later one
<tjaalton> apw: ok, adding the usb id in hso.c makes it load the module, but it still says "Not our interface", grr
<Kano> rtg: http://kanotix.com/files/kernel/unused-patches/2.6.29-ubuntu-aufs-compile-fix.patch
<Kano> rtg: that patch works against current git, please commit
<apw> Keybuk, ok have recorded it here: https://wiki.ubuntu.com/KernelTeam/KernelConfig
<mdz> apw: can I get an update on bug 319825?  it's in progress / assigned to you
<ubot3> Malone bug 319825 in linux "acer_wmi in Jaunty on Aspire One exposes non-functional (always disabled) rfkill device" [Medium,In progress] https://launchpad.net/bugs/319825
<smb_tp> mdz, I believe the current state is that we are intending to selectively disable the software rfkil for the aa1
<mdz> smb_tp: thanks, so it should be fixed shortly after beta?
<smb_tp> mdz, Yes
<apw> mdz.  it looks very much like t
<apw> the rfkill is not required, and we will want to quirk it away for this device
<apw> oh what smb_tp said ... doh
<smb_tp> apw, sorry I thought I jump in for you
<apw> i have half a patch to do that.  need to clean it up and get smb_tp to re-test
<apw> smb_tp, no was fine, just not reading whats in front of me
<rtg> apw: I'm feeling dumb this morning. How do I rebase a branch _onto_ master, assuming I've checked out the branch under consideration?
<apw> is you want all the non common commits then its just git rebase master
<apw> if you are doing a rebase of the top 20 commits from here to master
<apw> its git rebase --onto master <last commit before the ones you want> <branch name>
<rtg> apw: where '<last commit before the ones you want>' is on the branch ?
<apw> yeah, say you want the last three then its the pointer to the commit before those
<apw> HEAD~4 sort of thing
<rtg> apw: ok, thats a bit more intuitive
<apw> for next time you can tag the new place
<apw> ie tag master now with 'base-point'
<apw> and then it become git rebase --onto master base-point <branch>
<rtg> apw: ok, that ain't working for me. what I want is to take the 4 extra commits that I have on my branch and plop them on top of master. 'git checkout lp152626;git rebase --onto master HEAD~4 lp152626' didn't do the right thing.
<apw> hrm what did it do instead?
<rtg> apw: it sis some shit, but not what I wanted. master did not end up with those 4 commits.
<rtg> s/sis/did/
<apw> hrm, that should be the right incantion as far as i understand the world
<apw> it should reset to master, then move the commits which git log HEAD~4..lp152626 would have shown
<apw> if you have the text it produced on your window i'd like to see it
<rtg> apw: if I checkout master, HEAD is _not_ one of the commits from the branch.
<apw> right, but its supposed to be expanded before the command starts
<rtg> apw: here it is exactly:
 * apw goes test
<rtg> rtg@lochsa:~/jaunty/kern/ubuntu-jaunty$ git rebase --onto master HEAD~4 lp152626
<rtg> First, rewinding head to replay your work on top of it...
<rtg> Applying Revert Staging: at76_usb: update drivers/staging/at76_usb w/ mac80211 port
<rtg> Applying Staging: at76_usb: fix bugs introduced by "Staging: at76_usb: cleanup dma on stack issues"
<rtg> Applying Staging: at76_usb: Add support for OQO Model 01+
<rtg> Applying UBUNTU: Enabled drivers/staging/at76_usb
<apw> and are those 4 commits the ones you wanted?
<rtg> yep
<apw> so that looks like it did the right thing to me
<rtg> should I be _on_ master when I rebase?
<apw> nope on lp152626
<apw> and you should end up on thre still
<apw> ie the lpNNN is modified to be based on master
<rtg> correct, but none of those commits ended up in master anywhere
<apw> right master is not modified
<apw> you asked for this branch to be remade relative to master
<apw> now it will merge into master as a fast-forward
<rtg> apw: no, what I want is for the unique commits in the branch to get plopped on top of master.
<apw> ok there is no single command to do that that i know of
<apw> what i would do is the rebase that you did
<apw> and then git checkout master; git merge lpNNNN
<apw> and it should simply fast-forward master
<apw> and you are done
<rtg> I really dislike merging.
<apw> as a complete asside from the man page the last lpNNNN on the rebase is optional as you are on there
<apw> rtg rigth, but it won't be a merge
<apw> if it makes a merge, ie. does not say fast-forward then it went wrong
<apw> and in the fast-forward case master is effectivly
<apw> git reset --hard lpNNNN
<apw> git merge which says fast-forward is not a merge at all
<rtg> apw: the merge appears to have done what I wanted. How do I get rid of the 'Merge branch' message? It doesn't mean anything outside of my local repo
<apw> did it not say fast-forward?
<apw> there will be no merge commit in that case
<apw> if there is a merge commit it did not do what you wanted
<apw> as you just rebased lpNNN onto master, ie it should be relative to master and based on master
<rtg> apw: nope, it did not say fast-forward. 
<apw> a merge cannot be anything other than a fast-forwar
<apw> if it makes a merge life has gone bad
<apw> the way i do an update is as follows
<apw> git checkout master
<rtg> which is why I dislike merges. maybe I'll just go with cherry-picking
<apw> git merge origin/master
<apw> git checkout lpNNN; git rebase master
<apw> git checkout master; git merge lpNNN
<apw> none of that ever should make a real merge commit, ever
<apw> and then push
<apw> the first two make my master the same as upstream.  git checkout master; git reset --hard origin/master in effect
<apw> then i get my branch connected to the tip of master, and then merge it in
<apw> and that can never be a real merge
<rtg> apw: ok, that worked as expected. I think its the 'git checkout lpNNN; git rebase master' step that syncs the root commit tree
<cooloney_> apw, i submitted the patch to fix that missing files to remove
<apw> right that line is rebuiliding things from master upwards
<apw> then it can only ever be a ff of master
<apw> by definition, and thus merge will do the right thing
<apw> the reason i use merge instead of reset, is if i have done something wrong
<apw> i get a merge commit and go OOOPS and can unpick it easily
<apw> cooloney_, sounds good
<cooloney> apw, my nick is a typo. -:))
<apw> heh
<IntuitiveNipple> This works for me with master=1,2,5 wip=3,4 ... git rebase --onto master HEAD~2 wip ends up with 1,2,5,3,4
<cooloney> actually, it takes me a long time to recompile the jaunty kernel and tested it on my amd64 machine
<Kano> rtg: that patch works against current git, please commit
<Kano> err, did not want to repeat it ;) but would be nice if you would do
<Kano> i checked that the driver/acpi/acpia makefile is in the header package but no header
<apw> right headers other than those which are exposed via the official userspace headers are manually selected
<apw> file a bug asking for them and we can get then in there
<Kano> apw: tell me where to add those
<Kano> then i will try
<apw> do you have a fobia of bug trackers?
<rtg> Kano: I've already said that _if_ aufs is enabled, it won't happen until _after_ I talk to the installer people about upstream alternatives.
<Kano> that kernel is not released, so how to make a bug against it
<apw> there is a bug in progress right now to re-add some headers which are missing
<apw> it would go in the same spot, there is a commit in the hardy tree to export
<apw> some drm headers for lum
<Kano> rtg: you can use something else,but what hurts if a module is built?
<apw> it will be similar to those
<Kano> the module works
<Kano> if you want to fix unionfs or use whatever that is not important
<Kano> but it is needed to have a least one of those modules to build live images
<apw> kano, the patch to put the first set of headers in has this subject: UBUNTU: Copy header files for various kernel media
<Kano> ok, found it, will try
<Kano> mandriva simply adds all .h files to the devel package
<Kano> apw: can you tell me how to disable the virtual package when you build the server kernel?
<apw> not sure there is any way without editing the configs
<apw> that makes the thing double in size, i have already starrted the discussion on whether that is acceptable
<Kano> i see no real reason to have got the same kernel in 2 packages
<Kano> if it is stripped from some modules or not, that does not really matter
<NCommander> rtg, ping, I'd like to discuss with you changing the lpia config to match that of the i386, especially w.r.t.  to CONFIG_ATA which should hopefully fix d-i on lpia; unfortunately, making that config change would cause an ABI bump, so I'm not sure the best solution. Any ideas?
<apw> IntuitiveNipple, which version of lbm were you seeng this regulatory oops with?
<IntuitiveNipple> I haven't reproduced it 'in real life' - I was reverse-engineering the oops in the report, using the same build as max reported (2.6.28-8 I think?)
<IntuitiveNipple> That's my next step. I've just put a build-server together to produce custom debug builds
<apw> i jsut tried it here on 2.6.28-11 and it lets me do it
<apw> and it also even seems to work
<IntuitiveNipple> is your module-list comparable to the list in the oops report?
<apw> i am only loading the base cfg driver which explodes
<rtg> NCommander: send a pull request to the k-t list. I assume you've coordinated this request with sconklin ?
<apw> IntuitiveNipple, the problem is is don't have an ath9k ... so its not 100% trivial to test
<apw> IntuitiveNipple, i am not convinced that this is the call at the bottom of the function btw
<sconklin> rtg, NCommander: no. This would be a good one to review at the sprint, since it falls right into the netbook repo changeover
<NCommander> rtg, no, I've need working out what specifically has gone boom with d-i on lpia, and I got pointed to you.
<apw> as the fault is not a jump to 0x000004 but a data reference to 0x00004
<NCommander> sconklin, I have a branch which has the updated config, but I'm not sure what to do about the ABI bump (its too large to ignore, since a lot of things move around, and a LOT of new symbols ...)
<sconklin> NCommander: that's why it needs to be reviewed by the kernel-team mailing list, an ABI bump touches a lot of projects at the moment.
<sconklin> so please do a git-format-patch, and send that to the mailing list. Which hardy repo is your change against? (I hate that I even have to ask that)
<NCommander> sconklin, er, this is jaunty.
<NCommander> not hardy
<sconklin> NCommander: Oh, well then that's a lot easier. Still send a patch to the mailing list, but it's much less complicated from a project management view
<NCommander> sconklin, sure, I haven't finished doing a test build with the bumped ABI, so I'll probably push it in an hour or so
<sconklin> NCommander: cool, thanks
<rtg> sconklin: why are we caring about Jaunty lpia? do we have products based on it? 
<apw> IntuitiveNipple, bah no this is only triggered if you have a card reporting a phy
<IntuitiveNipple> ahhh, what hardware were you testing on?
 * NCommander sighs
<NCommander> EE: Missing modules (start begging for mercy)
<apw> something without wifi :)
<sconklin> No, I only care about jaunty lpia because 1) I'm responsible in a general sense for lpia maintenance and 2) Future development projects will soon be based on jaunty. There's nothing in progress that would affect a decision about lpia in jaunty.
<NCommander> Now what do I do?
<IntuitiveNipple> apw: :p
<apw> add a modules.ignore file listing the modukes wh
<apw> which are gone to the abi directory
<apw> IntuitiveNipple, heh i tried :)
<rtg> NCommander: I'm not at all interested in ABI bumping config changes for no particular reason, other then homogenizing i386 and lpia
<IntuitiveNipple> apw: I'll carry on with the debug once I've got the server to behave... installed Jaunty on it earlier, great. Then decided to move the live /var to a separate LVM, but now, for some reason, mountkernfs.sh fails to mount the varrun and varlock tmpfs so networking doesn't start. Interesting Times.
<apw> do you have the h/w ?
<IntuitiveNipple> apw: Yeah... tons of it
<apw> heh one day i need to sit you down with some beer ...
<IntuitiveNipple> orange juice is better for you :)
<IntuitiveNipple> right... back to the cold windy shed to fix the server :(
<apw> IntuitiveNipple, ok i think i have found a very compelling bug
<apw> i will build a fixed version (i hope) and upload it for testing
<IntuitiveNipple> The lbm_cw_cfg80211 ?
<apw> the regulatory oops in in lbm yes.
<apw> think i can see how it can happen
<apw> not that i can trigger it without an ath5k
<apw> will write it up in the patch, so you can see what i found
<IntuitiveNipple> ok :)
<rtg> IntuitiveNipple: speaking of wireless, I think huaxu.wan@linux.intel.com awaits an updated patch from you for the rfkill oops.
<IntuitiveNipple> rtg: Apparently the whole rfkill patch series isn't upstream yet. I got the impression the alternate work-around was being done
<IntuitiveNipple> rtg: it's still sloppy programming having work queued after the module is exiting
<rtg> IntuitiveNipple: Helmut's comment didn't make _any_ sense to me. Regardless, we still have this problem for 2.6.28.
<rtg> IntuitiveNipple: I think it goes a bit beyond sloppy :)
<IntuitiveNipple> rtg: I'll test a V2 of my patch for you, and get it posted to the list
<IntuitiveNipple> rtg: I was trying to be polite, since we're being logged :D
 * maxb waves: I may not be immediately responsive, but I'm semi-around if you want testing for that lbm regulatory oops
<IntuitiveNipple> maxb: whilst you're here. The module option... is it "options lbm_cw_cfg80211 ieee802.... " ?
<maxb> ieee80211_regdom=EU
<IntuitiveNipple> maxb: this is in /etc/modprobe.d/options.conf ? I want to verify the module name specified is lbm_cw_cfg80211
<maxb> Yes (I may have had one of the underscores as a hyphen, but IIUC those are equivalent in module names)
<IntuitiveNipple> no, that's fine. I had a suspicion it was matching on cfg8011 because the symbol munging looked 'off' but that answers that one :)
<Kano> rtg: cp -a drivers/acpi/acpica/*.h $(indep_hdrdir)/drivers/acpi/acpica
<Kano> please add that
<Kano> mainly for fglrx
<Kano> 2.6.29 only
<Kano> you just added some others, i never needed em but why not.
<mjg59> What the fuck is fglrx doing consuming stuff from acpica?
<mjg59> That's so far outside the exported API it's not even funny
<Kano> well there is no official patch for 2.6.29 + fglrx, but the unofficial ones needs it
<mjg59> Then it's very, very broken
<Kano> i guess you have to wait 3 month for a real one ;)
<Kano> when 2.6.30 out or so *g*
<mjg59> The only code that should be using the acpica headers is acpica itself
<mjg59> There's defined exported interfaces for interacting with the acpica code
<Kano> you are free to create a better 2.6.29 patch
<Kano> if you do that, no problem
<Kano> what would be the include line for something that is in driver dir <acpi.. > does not seem to work
<mjg59> There isn't one
<mjg59> You can't #include stuff that's not in the exported API
<Kano> well ../drivers works ;)
<mjg59> If you're inside the source tree, yes
<mjg59> But that means you're doing something wrong
<Kano> mjg59: it is not my fglrx patch, how about providing one?
<mjg59> All I'm saying is that the code is horribly roken
<mjg59> I'm not interested in rewriting stuff for a closed driver
<mjg59> Oh, wow, this code is horrific
<mjg59> It changes internal kernel state without any locking
<mjg59> Utterly, utterly insane
<mjg59> Kano: It can't be fixed without having the soure code to the binary component
<mjg59> But it's also racy and likely to cause oopses under certain circumstanes
<Kano> well those parts are only the the wrapper
<mjg59> So?
<Kano> couldnt you fix that part?
<mjg59> No
<mjg59> Not without modifying the closed part
<apw> IntuitiveNipple, pushed the LBM packages for bug #337929, URL is in the bug
<ubot3> Malone bug 337929 in linux-backports-modules-2.6.28 "ieee80211_regdom=EU now causes oops after latest update" [Medium,Incomplete] https://launchpad.net/bugs/337929
<apw> if you have a test bed, then it would be good if you can test
<rtg> apw: I'd kind of like to see the patch too, can you attach it to the LP report?
<apw> rtg its in the rookery link
 * maxb wonders if apw meant to publish udebs, not debs ?
<maxb> and empty udebs, at that
<IntuitiveNipple> apw: I was just off out. I'll take a look later :)
<apw> maxb, no he did not.  arrg
 * apw goes hit the build system with larger hammers
<maxb> hehe
<IntuitiveNipple> well that'll fix it for sure!
<apw> rtg, does one need anything other than the headers as reported as build deps to build lbm?
 * maxb will fetch coffee and then build locally
<rtg> apw: that patch is kind of a stop-gap measure, which will disappear when next LBM is updated. Can you bug folks on linux-wireless as well?
<apw> maxb, cool.  will try and resolve why my build are bust
<rtg> apw: just the kernel headers
<apw> rtg, sure this is just to get this tested by those with the issue
<apw> if its works, i will propose a cleaner version upstream
<apw> FATAL: Could not load /lib/modules/2.6.28-11-generic/modules.dep: No such file or directory
<apw> i am getting those in the build ... yet the build doesn't complain
<apw> does one need the kernel installed too?
<rtg> apw: its just bitchy, but build anyway
<apw> heh nice
<apw> who chose ^Q for blow my application away violently, and ^W for close this window and keep running
<IntuitiveNipple> apw: I built lbm against just the headers
<apw> dpkg-deb: --extract takes at most two arguments (.deb and directory)
<apw> Type dpkg-deb --help for help about manipulating *.deb files;
<apw> Type dpkg --help for help about installing and deinstalling packages.
<apw> make[1]: *** [do-binary-udebs] Error 2
<apw> make[1]: Leaving directory `/home/apw/local/git2/ubuntu-jaunty-lbm'
<apw> make: *** [binary-udebs] Error 2
<apw> dpkg-buildpackage: failure: fakeroot debian/rules binary gave error exit status 2
<apw> 	  dpkg -x $(ls ../linux-backports-modules-$i\_*i386.deb) \
<apw> i _HATE_ debian packaging
<rtg> apw: c;ean out the .debs in the directory above ubuntu-jaunty-lbm
<apw> thats soooo annoying
<rtg> apw: I'll fix it
<apw> rtg you are a scolar ... pints++
<apw> EOVERFLOW
<rtg> apw: I've done it several times now, but evidently missed this one.
<apw> we have a large number of packages sadly
<apw> and annoyingly i've fixed my kernels build to ship the branch into a nice clean empty build directory separated from all other build to avoid this ever happening
<apw> but the automation doesn't work for this thing
<apw> yet anyhow
<IntuitiveNipple> I've been setting up a cross-compiling distributed build server network. hopefully it'll cut build times down and increase the range I can work with.
<maxb> IntuitiveNipple: fancy! What software are you using? I looked at buildd and cringed a bit
<apw> i do something similar using a couple of bigger servers
<apw> and my laptop can also be a client of itself
<IntuitiveNipple> maxb: distcc and gcc
<IntuitiveNipple> What I'm trying to do is create a package to manage it all for deployment to EC2
<maxb> Ah, compile farm, rather than package building network
<IntuitiveNipple> maxb: both
<IntuitiveNipple> but cross-compilation is the biggest hurdle to solve
<apw> IntuitiveNipple, maxb, ok hopefully there are some actual .deb's at that URL now
<rtg> apw: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty-lbm.git;a=commit;h=3988ab032ae12e86da8228945299bc4cd84f4f95
<apw> rtg most excellent
<rtg> apw: when did you last update from  the LBM repo? I pushed the current wireless-testing about 1.5 hours ago.
<apw> ahh crap about 2.5 hours ago
<apw> though the code in error was the same in upstream testing
<maxb> Fortunately I updated *my* lbm before I started my build :-)
<apw> so i belive the issue is till there and the fix the same
<maxb> rebooting with apw's patch now
<apw> fingers crossed
<maxb> apw: well.... wifi worked.... but I don't see your printk either
<apw> ?
<apw> hrm
<apw> you got the appropriate option?
<apw> or in-appropriate in this case
<maxb> So it's possible something unrelated in the latest wireless-testing/compat-wireless fixed the bug
<apw> yep is possible
<apw> maxb, perhaps try the module i built which should have missed that update
<maxb> I'll fetch your .deb *without* those changes and see if that helps, and build the latest without your patch
<apw> maxb, sound plan, thanks
<maxb> ah, yup, now I see your printk
<apw> hrm.  so it may be fixed some other way now
<apw> ok will take that to look at
<maxb> Build of master-2009-03-24 for verification is in progress
<apw> maxb, thanks a lot
 * maxb gets the do-binary-udebs error you got, and says bad things about the buildsystem
 * apw hands maxb a hand full of rm
<rtg> maxb: buildsystem issues fixed and pushed
<maxb> apw: Confirming bug gone (or at least, no longer reproducing) in unpatched ubuntu-jaunty-lbm.git, i.e. master-2009-03-24
<apw> maxb, thanks ... grumble... should have ignored it for longer
<apw> rtg are we looking to have an lbm update shortly give you are updating it
<Kano> rtg: how about a patched drm radeon driver for 2.6.29?
<Kano> anything against that?
<yago> hi all people. I would like ask if is it possible make a kernel write all in "ada"?
<tannewt> could someone enlighten me about the correlation between linux version numbers in ubuntu and the version numbers released on kernel.org?
<tannewt> ubuntu released version 2.6.27.7.11 before upstream released 2.6.27.7
<johanbr> the ".7" in those two kernels have no relation to each other
<tannewt> johanbr: ah, that makes sense, shouldn't it be part of the package revision then?
<johanbr> tannewt: no, the Ubuntu ".7" is increased whenever the ABI changes.
<tannewt> johanbr: based on patches?
<johanbr> yes
<tannewt> johanbr: okay, are there any packages the correspond more closely to upstream numbers?
<johanbr> there is a build service that builds packages of the upstream kernel
<johanbr> if that's what you're looking for
<johanbr> if you'd like to know which 2.6.27.X upstream kernel has been included in the ubuntu kernel, you'll have to read the changelog.
<tannewt> johanbr: ah, okay, I'm studying the mgiration of packages from upstream to downstream and like to assume version number correlations
<johanbr> tannewt: alright. Keeping an eye on the ubuntu kernel mailing list can also be helpful.
<tannewt> johanbr: thanks for the tip but I'm automating it all, I'll just note it'll be wrong ;-D
<johanbr> oh :)
<tannewt> johanbr: pretty interesting stuff,  also have gripes about ubuntu version numbers that include the word "really" :-)
<johanbr> tannewt: I think those are a trick to fool the build system.
<tannewt> johanbr: I believe that, a way of dealing with weird version numbers like I'm trying to deal with
<johanbr> if a kernel is uploaded with too high a version number, I think the build machines won't accept a kernel with the correct (lower) version number, so that's why
<johanbr> or something like that
<tannewt> hmm, weird
<maxb> tannewt: It's not really weird. Fundamentally, version numbers can't go backwards.
<maxb> The 'really' hack is just about the only way to accomplish that when an upstream version must be reverted.
<maxb> I agree it's ugly though
<maxb> Debian has epoch's for this purpose, but Ubuntu can't use them without sacrificing all possibility of automatedly syncing the package from Debian again in the future
#ubuntu-kernel 2009-03-26
<tannewt> maxb: ah, I see, is it because versions are compared alphabetically?
<johanbr> tannewt: if you're doing this automatically, you may want to do it via git, since that'll carry all the version tags
<johanbr> both ubuntu + upstream
<JanC> tannewt: basically alphabetically with some added quirks  ;)
<tannewt> johanbr: hmm, I just do it based on tarballs for the kernel.  I can't spend too much time on it because I'm tracking all packages not just the kernel
<johanbr> oh, I see
<tannewt> johanbr: probably not the smartest decision I've made :-)
<tannewt> johanbr: for 8 distributions at this point too, oswatershed.org
<johanbr> wow :)
<johanbr> sounds like a pretty ambitious project
<tannewt> johanbr: yeah, it is, its pretty cool data though
<johanbr> "Parse error: syntax error, unexpected $end, expecting ')' in /var/www/oswatershed.org/htdocs/gen/data_2009032523.php on line 3"
<tannewt> johanbr: hmm, let me look
<tannewt> johanbr: I've been messing with things :-)
<johanbr> :)
<tannewt> johanbr: not much to see, I'm redoing it anyway
<tannewt> johanbr: http://abstract.cs.washington.edu/~tannewt/ is another copy of it going
<johanbr> alright
<dtchen> how does it account for different distributions' stable/development release policies?
<tannewt> dtchen: it compares stable releases versus different stable releases
<tannewt> dtchen: in other words, it crawls multiple repos and classifies them as different branches of a single distro
<tannewt> dtchen: past, lts, current, future and experimental are the current branch classifications
<tannewt> dtchen: however, there is no independent notion of when a distro is stable
<domas> hi! I'm staring at 2.6.24-18-server being idiotic: http://p.defau.lt/?WB6QRUQKJK19nVoZNQlNCA ;-)
<domas> it swapped out a working process for 2G of 'cache' that isn't really used in any way
<soren> domas: From here it looks like you're used all your RAM.
<soren> 47048k free is not much, and you have less than 1 MB cached?
<domas> soren: thats 1G cached
<soren> In swap.
<IntuitiveNipple> domas: 2G (almost) cached :)  ... can you show the complete ps -efly - we can see mysqld is using almost all RAM already, so it wouldn't be surprising if it swaps, especially if the vm's 'optimistic' allocation has been caught out
<domas> mysql is using 15G on 16G machine
<domas> see, on most machines you'd say "1G for OS is enough"
<domas> if I had _lots_ of processes eating 1G each, it wouldn't be an issue
<domas> but it seems to be an issue with single big process
<IntuitiveNipple> how big are the databases mysqld is handling?
<domas> 200G
<domas> (thats why I prefer mysqld to handle the dataset, not OS :)
<IntuitiveNipple> Is it using temporary tables during processing?
<domas> nope, none at all
<domas> just writing few logs
<domas> append-only operation, but they seem to take a fair share in the cache :)
<domas> I can probably flush any cache with fadvise(MDONTNEED) :)
<mdz> apw: I just got a new false positive with the apport suspend check
<mdz> apw: is there anything I can check to help diagnose?
<IntuitiveNipple> mdz: Is it because the resume took slightly over 5 seconds?
<IntuitiveNipple> mdz: grep 'PM: resume devices took' /var/log/kern.log usually identifies that
<soren> domas: "ps -efly" would still be convenient...
<domas> http://p.defau.lt/?J_3IkiT90__D6PXxReo_EA
<IntuitiveNipple> domas: the xargs -P 16 spawning the simultaneous jobs would explain the cache usage because all those gzip jobs need memory
<domas> few megs each
<domas> each
<domas> but that would be not 'cached: 1G'
<IntuitiveNipple> how much data is being sent in as a result of those?
<domas> ~1MB packets
<IntuitiveNipple> how many threads is mysqld using?
<domas> 16
<IntuitiveNipple> what does this report: SHOW STATUS LIKE '%key_read%';
<domas> this is innodb mostly
<domas> all i/o is single file 
<domas> 10000 for key_read ;-)
<IntuitiveNipple> ok.
<IntuitiveNipple> what does it show for mem usage then? SHOW INNODB STATUS;
<domas> Total memory allocated 15965703304; in additional pool allocated 7059968
<domas> thats 14.8G
<IntuitiveNipple> domas: I saw a reference to that which said "...Note that the real usage is maybe 2 - 4 times bigger than what it reports..."
<domas> probably bad reference then
<IntuitiveNipple> domas: in reference to the reported additional pool value
<IntuitiveNipple> I doubt it, it was from one of the innodb dev's
<domas> additional pool doesn't matter much
<IntuitiveNipple> It will when the memory limit is hitting the RAM limit... if the additional pool is larger than that value it would explain the swap
<domas> no, it is not
<domas> :)
<domas> mysql real rss should be ~15G
<soren> I'm still not completely sure what the problem is. free says you've used all your RAM, so naturally, there's some swapping going on.
<domas> yup, but then there's lots of caching
<domas> which isn't needed
<domas> I don't want that to have any VM pressure :)
<soren> Swap caching.
<soren> It's not caching files from the filesystem.
<domas> Cached:         637916 kB
<domas> SwapCached:      76608 kB
<domas> well, I changed swapiness to 1 now
<soren> domas: I'm still looking at http://p.defau.lt/?WB6QRUQKJK19nVoZNQlNCA
<domas> thats file cache
<soren> No.
<soren> Well.. "that"?
<soren> Which "that"?
<domas> the 2G number
<soren> I disagree.
<domas> I checked meminfo, it was in 'cached:' line, not 'swapcached'
<soren> Mind you, this is ancient knowledge, so it might have changed, but back in the good old days, what was reported as cached in swap was stuff that had been in swap recently, but was loaded back in to RAM, but hadn't been written to, so if it  were to be swapped back out, it wouldn't have to be rewritten to disk.
<domas> mhm
<soren> I'm happy to be corrected if that's not the case anymore.
<IntuitiveNipple> That is my understanding of it too
<domas> right now after the swapiness decreased it seems that swap usage has fallen down, so does kswapd weirdness
<domas> it is max 33% cpu now
<domas> though the workload changed a bit
<domas> ghm, maybe I didn't set O_DIRECT :)
<IntuitiveNipple> what does vmstat show? lots of active swapping?
<domas> nah
<domas> around ~1MB/s swap-oin
<domas> swap-in
<domas> occasional swapout
<IntuitiveNipple> O_DIRECT would help
<IntuitiveNipple> soren: interesting overview: http://feedblog.org/2007/09/29/using-o_direct-on-linux-and-innodb-to-fix-swap-insanity/
<domas> I'm usually using O_DIRECT, the problem is that filesystems are stupid a bit
<domas> only XFS allows parallel writing to O_DIRECT files, and even then it has limits (there have to be _no_ cached pages for that file at all)
<domas> so you have to either flush oages with fadvise() or remount filesystems
<domas> gotta patch mysql to do that for me
<domas> btw, when process really goes oom, linux panics nowaday
<domas> instead of killing the process 
<soren> domas: You can flush caches using /proc/sys/vm/drop_caches
<domas> yep, not selective though
<domas> (on the other hand, who cares about selectivity ;-)
<domas> I have seen few more problems with kswapd behavior - especially with LVM. it seems that LVM marks some data required for snapshots as 'reclaimable', so kswapd goes crazy when gets some VM pressure and tries to free them up
<IntuitiveNipple> I've just been looking at the Innodb tuning stuff, and the discussion of this particular issue. There it says, "...Make sure however the swapping is not happening ie your VMSTAT âsi/soâ columns are zero on Linux. Couple of swaps per minute would not hurt bad but if youâre doing 100+ pages per second of swap IO youâre in trouble."
<IntuitiveNipple> See: http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/
<domas> IntuitiveNipple: I know that :) but I want OS not to swap my reasonably sized buffers
<domas> I just want that 15G dataset would stay in memory :)
<domas> on 16GB machine
<domas> (or 30GB dataset on 32GB machine)
<IntuitiveNipple> The recommendation suggests 14G for a 16G machine, so maybe your expectations aren't realistic
<domas> this is 13G btw
<Kano> hi rtg , could you build a 2.6.29 server kernel?
<domas> IntuitiveNipple: I have worked on InnoDB memory consumption more than actual InnoDB devs, or mysqlperformanceblog people, or nearly anyone in the industry 
<dandel> domas, read this... http://www.novell.com/coolsolutions/feature/18990.html
<domas> dandel: that link has too simplistic information
<dandel> what does cat /proc/sys/vm/swappiness reveal tho?
<domas> for now I solved it way easier, my process does not do any non O_DIRECT operation 
<domas> dandel: right now it is at 1
<domas> our default is 10
<dandel> could always do a ramdisk swap instead of hd based swap.
<domas> dandel: the problem is not actual swapping, but kswapd taking extra cycles to manage the buffers
<amitk> rtg: is the -11.37 tag set correctly?
<rtg> amitk: checking
<domas> IntuitiveNipple: actually, if anyone would set 14G buffer pool, they'd definitely go OOM 
<apw> Kano, cna't you build that from the karmic tree?
<domas> IntuitiveNipple: that setting made sense on earlier versions, which didn't have high per-page mutex overhead :)
<Kano> apw: i could only build the generic one
<rtg> amitk:  it looks close, why?
<apw> Kano, why so?
<Kano> i always got errors with the server one, not finding some modules or so
<rtg> Kano: I'm running 2.6.29-1-server
<amitk> rtg: 'close' ? I am tracking some regression in ARM flavours (versatile) due to AA being enabled.
<Kano> rtg: hmm, maybe i need more free space then, but i deleted already much...
<rtg> amitk: AFAICT the tag is planted right on the commit message that I would expect.
<Kano> will test again.
<amitk> rtg: but the commit after it (updateconfigs) was required
<rtg> amitk: hmm, you might be right. I don't actually remember doing that, but I might have. (wouldn't be the first time)
<rtg> amitk: I'm about to push some other stuff, so I'll fix the tag.
<amitk> rtg: thanks.
<amitk> rtg: any uploads planned?
<rtg> amitk: yeah, I'd like to get one uploaded today.
<rtg> amitk: ok, fixed the tag. the other commits I'm still testing.
<amitk> rtg: could I push this trivial fix to linux-meta onto you then when you upload? https://bugs.edge.launchpad.net/ubuntu/+source/linux-meta/+bug/345992
<ubot3> Malone bug 345992 in linux-meta "The one-line package description for the linux-image-imx51 and linux-image-versatile meta-packages appears wrong" [Undecided,Confirmed] 
<rtg> sure
<domas> right, once all I/O is O_DIRECT, no swapping/caching is done
<rtg> amitk: were you wanting to get something in today's upload?
<amitk> rtg: I'm not done yet. Please go ahead. I'll commit tomorrow
<rtg> amitk: I'm out tomorrow, so smb_tp will have to help if its something urgent. Otherwise, Monday
<amitk> sure
<smb_tp> Yessir :)
<rtg> amitk: I'm doing a scorched earth Jaunty update on  my dev box, so perhaps Monday is optimistic :)
<amitk> rtg: :)
<BUGabundo> apw: so I don't keep confusing things
<BUGabundo> what's is different with backports kernel?
<apw> backports modules not kernel
<BUGabundo> ahh
<apw> its a collection of updated drivers for things.  currently wireless things which are moving fast
<BUGabundo> so that's it
<BUGabundo> so just about any one needs to have it?
<BUGabundo> or only ppl with modules not compiled into kernel?
<apw> people only need it if they have trouble with the main kernel drivers, or there is none
<rtg> BUGabundo: only ppl that want the features offered by 2.6.29 wireless drivers and protocols
<BUGabundo> ah so when I installe it my self without the need for it, am I doing it wrong?
<apw> wrong is a relative term, you are putting together things which are less suited to each other
<apw> they may work better or worse, better than nothing clearly
<rtg> apw: actually, I think 2.6.29 wireless is beginning to work pretty well.
<BUGabundo> since I have and intel 4965
<BUGabundo> I guess the kernel support should be fine
<apw> yeah i am more saying that your mixing things, that is likely to add risk, but is the only way for people who need it
<BUGabundo> no great changes recently
<rtg> BUGabundo: if the 2.6.28 driver is working for you, then why change?
<BUGabundo> ehe
<BUGabundo> don't fix what aint broken
<apw> indeed
 * BUGabundo looks at installed stuff
<BUGabundo> 'cause I remember that change to kernel to fix kill_switch
<BUGabundo> came on backports
<apw> that'd be the definition of not working for you
<laga> jau
<laga> oops
<laga> wrong window, sorry
<BUGabundo> actually haven't tested the soft switch
<kees> amitk: if you need help with AA, ask jjohansen on #apparmor on oftc, he's usually around and very helpful.
<amitk> kees: we got it fixed for now. Thanks
<amitk> kees: I did get in touch with him btw.
<kees> amitk: ah, excellent
<apw> dtchen, those two alsa write pointer fixes ... do they fix up the issues with pa and glitch-free do you know?
<bradf> bradf: test
<bradf> bradf: another
<bradf> bradf: another
<dtchen> apw: yes
<apw> dtchen, most excellent
<dtchen> apw: note that jaunty's pulseaudio version is a bit dated, so performance will be less optimal than with 0.9.15ish (or whatever Fedora 11 will have)
<dtchen> still, users have been reporting markedly improved stability and performance
<TheMuso> It seems that Lennart aims his releases for Fedora's release schedule, which is always going to mean we're behind the 8 ball so to speak.
<TheMuso> As far as I understand things anyway.
<dtchen> right, unless we obtain an exception for PA similar to what the GNOME desktop has
<dtchen> of course that would mean updating the ALSA stack, too, which uh...
<dtchen> anyhow, happy with what we're given
<TheMuso> dtchen: Yep totally agree.
<TheMuso> cd
<TheMuso> woops wrong tab
#ubuntu-kernel 2009-03-27
<LLStarks> yo.
<LLStarks> yo. i need help with a patch.
<pwnguin> heh, should i be concerned that 2.6.29 doubles rsa performance?
<apw> sounds like you shoud be happy
<mdz> apw: any luck quashing the false positive suspend/resume failure reports?
<apw> no luck in finding the source, i have a  branch for apprt which i am about to test to paper over it
<IntuitiveNipple> apw: is that unrelated to TEST_SUSPEND_SECONDS?
<dandel> i got a suspend/resume failure on my laptop which is triggered each time ( but first i need the acpi to stop ignoring irq 9 (
<apw> IntuitiveNipple, my answer is about completely false failures which are being reported by apport, not your 5 second timeout thingy
<IntuitiveNipple> apw: OK, sounds harder to fix :)
<apw> heh, not really
<Kamping_Kaiser> sigh. 
<IntuitiveNipple> apw: smb_tp: Could one of you guys clue me in on how you build the ~lpXXXX test kernels so I can use it on my build servers to create test kernel packages too?
<apw> IntuitiveNipple, as in how we add that
<apw> literally just before the build you edit the debian/changelog
<apw> if its UNRELEASED you can add ~lpNNNtj1
<apw> it its like jaunty you should leave out the ~
<IntuitiveNipple> Is that it? so it is just a plain fakeroot debian/rules binary-generic  (or whatever) ?
<apw> yep
<smb_tp> too easy :)
<IntuitiveNipple> doh! and there was me thinking it was something clever!
<IntuitiveNipple> yeah, far too easy. these things are supposed to be brain-strainers :)
<IntuitiveNipple> OK, that means I don't need to ask you guys to build/publish the kernels.. I can punt them into my PPA I guess, too.
<smb_tp> The only special thing would be for me, that I usually base the checkout on the last updates version
<IntuitiveNipple> The only thing I can think - for non-PPA builds - is my lack of a kernel.ubuntu.com address (would people be concerned at pulling test kernels from my own domain?)
<smb_tp> The thing for me against ppa builds is, that it only has one version there
<IntuitiveNipple> Yeah. I've got several builds in the queue for testing core kernel bug-fixes which I have high hopes for
<smb_tp> btw apw I installed the test kernel for the i915 performance issue on the aa1 and it still works the same as before 
<apw> oh nice
<smb_tp> which was meant as a positive "no side effects" here, but  I realize it could be interpreted as nag, which it isn't :)
<apw> smb_tp, i interpreted it as a helpful test on real hardware
<smb_tp> good, such it should be 
<apw> mdz you will be pleased to hear i just found a way in which you can get a normal looking suspend/resume in concert with it reporting a failure at next reboot.  in concert with my symptom of not wanting to suspend any more
<mdz> apw: nice! bug#?
<apw> it seems that there is a window after we wake up enough to see working, before the offial wakeup is complete and if we get stuck here (and video post has done that in the past for me) then we seem up to the user
<apw> but really really the suspend/resume is broken
<apw> i'll put the details in your bug as i am working the issue there
<apw> it really is broken, it just seems ok to the user.   we need to tell those two appart so we can inform the user better and get more information when it occurs
<mdz> apw: ok, please update the title of the bug to something more meaningful if you would
<apw> mdz will do
<zilleplus_> hey anny one know a lot of ubuntu server??
<zilleplus_> can't get internet on myn
<zilleplus_> my dhcp server on route does not shows anny connection from my server
<manjo> zilleplus_, #ubuntu-server 
<zilleplus_> can't get internet on new ubuntu server 8.10 can aanyone help (sudo route -nee shows not IP ore gateway)
<manjo> zilleplus_, your interface is up ? 
<zilleplus_> manjo are you still there??
<manjo> yes
<zilleplus_> okey this is my problem
<zilleplus_> i installed my server angain
<zilleplus_> ubuntu 8.10
<zilleplus_> and cant get inthernet on it
<zilleplus_> but config -a gives tath my eth divice is there
<zilleplus_> wath do i do
<mjg59> zilleplus_: This is the kernel development channel. Support is best found in #ubuntu.
<zilleplus_> ooh sorry
<mjg59> no problem
<IntuitiveNipple> apw: That 'easy' kernel build failed with "Previous or current ABI file missing!" - looks like the changelog version caused debian/abi/2.6.28-11.38lp284377v1 instead of the expected "debian/abi/2.6.28-11.38/". Does that mean I *do* need ~ in the version or do I create an ABI?
<apw> was the top of the thing 'jaunty' ?
<apw> IntuitiveNipple, 
<apw> if so its possible the upload has not yet had the abi files pulled down into it
<apw> so it really will fail for all of us
<apw> which abi files _do_ you have
<IntuitiveNipple> you mean head? yeah, I did a git fetch; git rebase --hard origin/master then checked out the wip branch, applied the patch, and built
<IntuitiveNipple> apw: 2.6.28-11.37  2.6.28-11.38lp284377v1
<apw> and what are the first two versions in your changelog
<apw> fdr printenv will show you what versions its really using
<IntuitiveNipple> apw: 2.6.28-11.38lp284377v1 2.6.28-11.38
<apw> ok what did you do
<apw> did you add a whole new version in the top
<apw> i was trying to suggest you simply _edit_ the existing top most version
<IntuitiveNipple> apw: Yes, added a new changelog entry with the details of the change... as always :)
<IntuitiveNipple> apw: ahhh!
<apw> heh no no no don't do that for the kernel
<apw> the changelog gets made by the automation on relase
<IntuitiveNipple> If I don't I'll forget what the changes are :D
<apw> then commit them using git
<apw> and put the changelog on there
<apw> thats where it should be
<IntuitiveNipple> oh, as in the commit message flag? I included my new changelog entry in the patch commit as I do with other packages
<apw> the kernel is odd as we cherry pick a lot
<apw> so you never update debian/changelog, it just makes life hard when you rebase
<apw> (as i just found rebaseing just three commits in bzr)
<IntuitiveNipple> I knew that for 'regular' kernels but didn't realise it'd be so drastic for a test build :)
<apw> when the release is done we do a fdr insertchanges which makes a debian changelog for us
<apw> well the abi checks are very strict
<IntuitiveNipple> yeah... I've done that myself in the past
<IntuitiveNipple> I guess I'm too used to doing skipabi on out-of-tree builds
<IntuitiveNipple> apw: thanks for that... trying again now
<apw> luck
<manjo> lieb, why does rmmod crasher just hang ? 
<lieb> hang?  I tested and it unloaded fine.
<lieb> it did hang w/ an earlier version
<manjo> after an oops
<lieb> ok, you did an oops and then unloading hung?
<manjo> the one that is on your people page is the lastest ? 
<manjo> yes I did an oops and then the unload hangs
<lieb> hmm.  l'll look at it.  yes, the people page one is the latest (or should be)
<manjo> also, if I wanted to make the oops appear at a function XXXXX() do I just move the *page0 = tmp; to a function XXXXX() and call it in its place ? 
<lieb> I'm not sure what you mean
<manjo> instead of EIP: [<f7f60271>] oops_store+0x61/0x70
<manjo> I wouild like to see EIP: [< .....>] XXXX+0x../0x..
<lieb> just a sec, let me pull up the code...
<manjo> so if I call a function in oops_store() to do the same thing it should appear that the eip is now in that new function correct ? 
<lieb> yes it would.
<manjo> k
<manjo> but after  *page0 = tmp; I need to have another instruction like return X;
<lieb> also note the extra bit there w/ tmp.  I had to add that to fool the optimizer into doing the store at *page0 = tmp
<lieb> and looking at it, I can see why the unload might hang
<manjo> we can compile it unoptimized ? 
<lieb> this is the sysfs write callback so that chunk of sysfs is left hanging.  I'll have to figure out a way to
<lieb> delay the actual oops...
<lieb> optimize, yes.  I forget exactly but it gets optimized out.  actually, if I remember, I wanted the DEADBEEF
<lieb> to be in a register so we could recognize it.  the optimizer turned the store into a store immediate which
<lieb> would not show up in the reg dump
<lieb> do you really need this to be unloadable here?  the other opts (panic etc.) whack the kernel so there is nothing to unload from.
<manjo> yeah not in the case of panic ... but unload after bug and oops will be nice but not critical I think
<lieb> I'd have to look but I think there are some locks held when we get down here in sysfs.  since we never
<lieb> return via the normal path, they would not get released.  If that is true, the unload wouldn't work because
<lieb> the module exit would hang on the sysfs attr destructor(s)
<manjo> right agree
<lieb> that might be hard to do
<lieb> some other poor sot of a task would have to take the sharp stick in the eye in order to let this task ret to userland
<lieb> we can't use a tasklet/workq cuz that would kill a kernel thread and really bring it down.
<lieb> yup, the source is the latest.
<lieb> I have an idea.  as soon as my jaunty beta downloads complete, I'll try it out.
<calc> mjg59: loving your posts to lkml :-)
<lool> Hi folks
<lool> CONFIG_BLK_DEV_RAM_SIZE was bumped for imx51 from 4MB to 8MB
<lool> It turns out this is the uncompressed size, and we didn't bump it enough
<lool>     gunzip -c </boot/initrd.img-2.6.28-11-imx51 | wc -c
<lool>     8460800
<lool> This results in ENOSPC:
<lool> [42949379.640000] RAMDISK: Compressed image found at block 0
<lool> [42949380.210000] RAMDISK: incomplete write (-28 != 32768) 8388608
<lool> Could someone please bump it again to the same value as amd64/i386: 65535?
<lool> Bug #349842
<ubot3> Malone bug 349842 in linux "Please bump CONFIG_BLK_DEV_RAM_SIZE to 64MB" [Undecided,New] https://launchpad.net/bugs/349842
<vadi2> hi, in regards to the suspend/resume testing, are you interested in machines with nvidia cards and the proprietary driver?
<IntuitiveNipple> vadi2: Yes, any. I've got nvidia here (7600) and suspend/resume has been fine... so far :)
<vadi2> ok. I haven't had any issues on mt 8600 either before but might as well test to be sure
<vadi2> (if someone is willing to look at results and not say "oh, proprietary, your reports are useless")
<manjo> lieb, note submitted patch to kernel-crasher
<lieb> where?
<manjo> ukml
<lieb> ????
<manjo> :)
<manjo> ubuntu -kernel -mailing list
<manjo> if someone has apport setup to report to kerneloops they will get a lot of false positives from this module... this patch takes care of that
<lieb> manjo, you realize that this is boardering on loony, right?
<manjo> the reporting part ? 
<lieb> What was a testing tool is turning into a metastisizing code cancer.  I do not want to be responsible for the next re-incarnation of emacs! ;)
<lieb> or gnome
<lieb> or perl
<manjo> heh
<lieb> not a bad idea though... the function signature as a filter...
<lieb> next thing I suppose is a .deb or whatever
<manjo> haha
<manjo> yeah I am sure there will be a request foir that soon
<manjo> atually we can also add another case for loops ... for(;;);
<lieb> I'll take the patch and update what I have.  We can talk next week on where to put this thing. right now it is on my local server
<manjo> i know its on ur ppl page 
<manjo> that might have to move if this is going to be useful 
<lieb> and that is only a tarball
<manjo> probably should be builnt in as a test module under misc or something 
<manjo> with config options
<lieb> yea.  to be discussed, probably in the kerneloops session.
<manjo> its pretty cool tool ... was very useful in my kerneloops testing 
<manjo> I think the arm part can be omitted ... who care if someone wants to shoot themselfs in the foot ? 
<manjo> just have /sys/kernel/crash/test and have it take oops, bug, warn, etc as values
<lieb> that part is quesionable.  what I thought of doing is spawning a kernel thread to take the bullet.
<manjo> so if you cat /sys/kernel/crash/test it will show all the values that you can echo to it 
<lieb> the arm part should remain for that reason.  that is why I was questioning the propagation of this beyond a small testing group
<manjo> heh its beyond that now 
<manjo> something to talk abt the next time we have this discussion with team
<lieb> given that kerneloops+kexec/kdump has turned into "something else" it should probably be part of the test infrastructure
<manjo> that is a good idea too
<manjo> btw kerneloops on 32bit is still broken I think coz of kexec tools
<manjo> kdump I mean
 * manjo breaks for coffee
<lieb> one of the things that I fell into with this pre-in-post berlin was discovering all these disjoint packages
<lieb> that, in reality, are really bits of one single "package" intimately tied to the kernel.  Imagine my surprise ;)
<cody-somerville> When I attempt to mount a squashfs, I get: mount: mounting /dev/loop0 on /mnt failed: No such device
<IntuitiveNipple> cody-somerville: what's the command you're using?
<cody-somerville> mount -t squashfs -oloop /cdrom/casper/filesystem.squashfs /mnt/
<IntuitiveNipple> not sure about this, but shouldn't there be a space between -o and loop ?
<IntuitiveNipple> I know I use that form and I've not had a problem
<IntuitiveNipple> I've just used this: sudo mount -t squashfs -o loop casper/filesystem.squashfs /mnt/usb
<IntuitiveNipple> And without the space... and it works... so not a missing space issue
<IntuitiveNipple> Is the loop device operational?
<cody-somerville> How can I tell?
<IntuitiveNipple> which kernel version are you using?
<IntuitiveNipple> obvious thing first is to look for the loop devices: ls /dev/loop*
<cody-somerville> 2.6.28-11-generic
<cody-somerville> they're all there
<IntuitiveNipple> okay, module is built-in
<IntuitiveNipple> does losetup report anything? sudo losetup -a
<cody-somerville> losetup -a doesn't work
<cody-somerville> I'm using busybox version
<IntuitiveNipple> ahhhh
<IntuitiveNipple> I don't believe busybox supports -t auto or -t squashfs
<cody-somerville> It must
<cody-somerville> how would d-i mount a squashfs?
<cody-somerville> Maybe I should try doing this two step?
<IntuitiveNipple> check what file-systems are available.
<IntuitiveNipple> I'll boot a PXE image here and break into init and see if it is the same 
<cody-somerville> Maybe I need to use unionfs?
<IntuitiveNipple> no there's no squashfs: grep squash /proc/filesystems
<cody-somerville> How do I get that?
<cody-somerville> squashfs-modules doesn't seem to exist in ubuntu
<IntuitiveNipple> The module isn't loaded at that point, presumably not in the initrd. (CONFIG_SQUASHFS=m)
<cody-somerville> If I try to load the module, it says the module doesn't exist
<IntuitiveNipple> from busybox/initrd? that might be correct. The module is ubuntu/squashfs/
<cody-somerville> So do I need to get cjwatson to recompile d-i's initrd to include the squashfs module?
<ogasawara> smb_tp: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/349655
<ubot3> Malone bug 349655 in linux "[hardy][sparc]: new kernel in security doesn't boot" [High,Triaged] 
<IntuitiveNipple> No
<IntuitiveNipple> cody-somerville: the module is in /lib/modules/`uname -r`/kernel/ubuntu/squashfs/
<cody-somerville> It isn't there
<cody-somerville> /lib/modules/2.6.8-11-generic/kernel/ubuntu/ only has dm-loop, dm-raid4-5 and misc
<IntuitiveNipple> I got it here ... let me check which version of the CD this is
<IntuitiveNipple> 2.6.28-9-generic... let me try 2.6.28-11
<IntuitiveNipple> cody-somerville: 2.6.28-11-generic live-CD i386 ISO does have squashfs here
<IntuitiveNipple> cody-somerville: (in the initrd) I modprobed it and it shows in /proc/filesystems
<cody-somerville> I wonder why it isn't showing up in my custom build for OEM Services
<IntuitiveNipple> different config for the initrd possibly? 
<cody-somerville> I use the same initrd from archive.ubuntu.com
<IntuitiveNipple> is that the casper initrd?
<cody-somerville> no, d-i's
<IntuitiveNipple> what's the path to the one you use?
<cody-somerville> http://archive.ubuntu.com/ubuntu/dists/jaunty/main/installer-i386/current/images/
<IntuitiveNipple> which do you use? the cdrom/ ?
<cody-somerville> yup
<IntuitiveNipple> The initrd from there  doesn't have the ubuntu/ modules path in it
<cody-somerville> So what do I have to do to fix that?
<IntuitiveNipple> I'm not sure. I've not touched those before.
<cody-somerville> Does the kernel provide subsets of modules in udebs or anything like that?
<IntuitiveNipple> yes, in http://archive.ubuntu.com/ubuntu/pool/main/l/linux/
<cody-somerville> Whats the name of the udeb I need for squashfs support?
<IntuitiveNipple> fs-secondary-modules....
<cody-somerville> I figured as much...
<cody-somerville> I have that in the pool
<IntuitiveNipple> But, that doesn't contain squashfs... need to dig deeper :)
<cody-somerville> yea, I was just going to say
<cody-somerville> IntuitiveNipple, could any of these be it? http://pastebin.ubuntu.com/139208/
<IntuitiveNipple> I've opened several to find it but not seen it so far
<cody-somerville> squashfs-source claims to have the source for the kernel modules
<smb_tp> ogasawara, thanks
<cody-somerville> IntuitiveNipple, is there no lum for 2.6.28?
<IntuitiveNipple> cody-somerville: that's correct. L-U-M was dropped for Intrepid and merged into the main kernel source, in the ubuntu/ directory
#ubuntu-kernel 2009-03-28
<dandel> bah... kernel errors ><;
#ubuntu-kernel 2009-03-29
* abogani changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest news: Released 2.6.28 kernel for Jaunty/9.04. | Kernel git trees: http://kernel.ubuntu.com/git | Latest kernel upload: 2.6.28-11.38 based on 2.6.28.9
* abogani changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest news: Released 2.6.28 kernel for Jaunty/9.04. | Kernel git trees: http://kernel.ubuntu.com/git | Latest kernel upload: 2.6.28-11.38 based on 2.6.28.9 final
<liw> anyone here know about "SEMB device ignored"? I'm trying to get my new SATA hard disk to work, and new kernels refuse to recognize it (but Debian etch beta1 kernel does recognize it, as does bios)
<liw> gutsy kernel recognizes the disk, hardy/intrepid/jaunty beta kernels do not
<liw> my problem seems to be #257790
#ubuntu-kernel 2010-03-29
<mdz> apw, do we still need /proc/version_signature now that uname() provides all of the relevant information?
<cnd> where is the modules.alias file in the initramfs generated?
<cnd> anyone know?
<smb> cnd, Not for sure. Either when running update-initramfs or taking the one generated when installing the kernel. Probably depmod -a and then update-initramfs helps
<cnd> smb, thanks, I think I've found what I need
<JFo> hi folks, I have been having some issues getting to a few systems, so I don't have the weekly buglist e-mail out. I'll send the few I have to the list in just a minute for the call.
<cnd> apw: install vga16fb /sbin/load-vga16fb $CMDLINE_OPTS
<cnd> that in /etc/modprobe.d/vga16fb.conf
<ia> hello. could anyone tell me, please, does linux kernel in lucid with proprietary nvidia driver has kms support for nvidia [ion] cards?
<jjohansen> ia: no the proprietary driver will never have kms support
<ia> jjohansen: ok, thanks for information.
<ia> and how about gma500/poulsbo?
<mjg59> ia: No
<nosse1> Is there some nifty tool for comparing two kernel config files?
<bladernr_> Can anyone tell me real quick what package opens up the "Default Application" windows to open when a USB device is connected to a Lucid box?
<bladernr_> I'm only asking here as it has something to do with the USB subsystem
<bladernr_> I just don't know what to open the bug against yet...
<nosse1> Where can I find representative kernel settings for Ubuntu (ARM Lucid)? I'm trying to build an ARM kernel in which to run Lucid, however I need to know which kernel feats that needs to be enables (e.g. upstart req'd DEVTMPFS)
<bjf> nosse1, which arm proc are you targeting? have you looked at the lucid topic branches in our git repo?
<nosse1> I'm targeting AM3517. I'm trying to bring up Lucid on the TI AM3517-evm
<nosse1> What's the URL to your git repo?
<bjf> nosse1, git://kernel.ubuntu.com/ubuntu/ubuntu-lucid.git
<amitk> nosse1: meld is a great tool
<nosse1> amikt: Thanks, but that a ordinary diff tool. Many times the kernel settings are out of order, so you need to sort the file or something in advance
<bjf> nosse1, we don't have anything better than meld (no special tools)
<nosse1> oh, ok
<nosse1> Ush. Same as last time upstart dies with "procps main process terminated with status 255"
<nosse1> ..so what kernel option have I forgot to enable.... hmmm
<nosse1> I have now cloned the ubuntu kernel repo. Where can I start to find kernel settings?
<nosse1> .. I found it
<bjf> nosse1, if you are interested in the arm configs you want to checkout one of them
<bjf> nosse1, there are 4 arm topic branches
<nosse1> Yes, I found some in debian.master/
<nosse1> debian.master/config/*
<amitk> nosse1: as bjf pointed out, the arm configs are in the arm branches in git (git branch -a). You'll find them in the respective debian.<soc>/config/
 * nosse1 is noob: How do I switch the branch including the checked out files? "git checkout -b remotes/origin/ti-omap" ?
<bjf> nosse1, in your clone tree do a 'git branch -r'
<bjf> nosse1, that will show you all the topic branches
<bjf> nosse1, I then (for example) 'git branch --track ti-omap origin/ti-omap;git checkout ti-omap'
<nosse1> bjf: I think I messed up my git repo. How can I reset everything the way it was, without cloning everything for scratch?
<mjg59> git reset --hard
<mjg59> Will let you go to a specific sha
<mjg59> But it kind of depends what you're trying to do
<nosse1> I have messed up using git branch, and now I just junk branches which I'm trying to rid myself of.
<nosse1> bjf: Thanks
<crimsun> manjo: thanks for following up on those mic bugs. :-)
#ubuntu-kernel 2010-03-30
<DanaG> hmm, anyone know why the kernel-ppa stuff hasn't been updated in a while?  the only 34-rc2 kernel there says "karmic" specifically, and the same is true of the latest drm-next kernel there.
<DanaG> Does it matter that it says "karmic", if I want to use it on Lucid?  I've seen it matter before, on ARM, at least.... try a karmic kernel with lucid userspace, it doesn't boot.
<JanC> I guess "karmic" means it was compiled with karmic's configuration file?
<DanaG> beats me.  I'm about to try the drm-next "karmic" kernel.
<DanaG> I've also noticed that the kernel-ppa kernels all have the STAGING dir entirely disabled... as well as MMC_RICOH_MMC
<DanaG> Something about "symbol 'm' not valid for ... "
<nosse1> How do I build a (fresh git) kernel when I dont have the debian/ dirs installed and get it installed on the system (preferrably via a deb-file)
<nosse1> Will make-kpkg handle that?
<smb> preferably (if you don't want to use git) by apt-get source linux-image-2.6.x-y-generic which gives you the kernel source including the debian dirs
<nosse1> smb: I can't use the ubuntu source, as there are none for my target, so I need to go with a 3rd part kernel branch.
<nosse1> So I have the kernel source and a working config, but I need to wrap this into ubuntu-world
<smb> You could clone the git tree and copy the debian* dirs into your tree
<nosse1> smb: Thats all that's needed? What happens to my local kernel config?
<smb> nosse1, You would need to see how you get it integrated with debian.master/configs/...
<smb> nosse1, Maybe it does work with make-kpkg but I never use that
<nosse1> smb, I'm trying to integrate debian* right now.
<nosse1> smb, What do you do to compile kernels then?
<smb> nosse1, I only do the Ubuntu kernels. No need for me to do anything special. :-P
<nosse1> But you use make-kpkg to build them, right?
<smb> nosse1, No. Either debuild, or dpkg-buildpackage or fakeroot debian-rules ... when I am in a hurry
<nosse1> OK, thanks
<mozmck> smb: did you see my post here about the kernelconfig script not working because DROOT is not defined?
<smb> mozmck, I cannot recall it. Where did you post it?
<mozmck> here on IRC a couple days ago.
<mozmck> To fix it here I just added DROOT=debian to debian/debian.env
<mozmck> this is in the lucid git tree
<smb> IRC is quite prone to loose things. But on Lucid debian.env should be always set
<smb> Are you using a special tree?
<smb> Actually it should be debian.master which it points to
<mozmck> no
<smb> ~/src/ubuntu-lucid/kernel$ cat debian/debian.env 
<smb> DEBIAN=debian.master
<mozmck> I'm using kernel.ubuntu.com/ubuntu/ubuntu-lucid.git
<mozmck> yes, but DROOT is used in the kernelconfig script and is not defined anywhere.
<mozmck> this is both on karmic and in 10.04 beta1
<mozmck> and looking at the kernelconfig script, line 29 is bindir="`pwd`/${DROOT}/scripts/misc"
<smb> which script are you talking about?
<mozmck> so I figured DROOT had to be 'debian'
<smb> ok found it
<smb> apw, Is that meant to be called directly
<apw> mozmck, smb, nope thats not menat to be run directly
<mozmck> all the instructions I found have you call "kernelconfig editconfig" to edit the configs.  this worked on karmic fine but not in lucid
<apw> its used from debian/rules updateconfigs and the like
<mozmck> so how are you supposed to edit the configs now?
<apw> where are those instructions?  they are wrong
<smb> Right, where does it say to call it directly?
<apw> debian/rules editconfigs would make sense
<smb> yep
<apw> and should work for all releases too
<smb> mozmck, To call "debian/rules editconfig" was always the intended way
<mozmck> http://blog.avirtualhome.com/2009/11/03/how-to-compile-a-kernel-for-ubuntu-karmic/
<mozmck> That's linked to from here: https://help.ubuntu.com/community/Kernel/Compile
<apw> yay ... random community randomness
<Keybuk> https://wiki.ubuntu.com/KernelTeam/KernelForIdiots ;-)
<apw> Keybuk, heh yeah i like that one better :)
<mozmck> I see.  It seems quite hard to find good information on this subject!
<apw> i wonder if we should rename that dummies :)
<apw> mozmck, mostly because there is such a lot of bad information out there
<mozmck> I've seen that link, but it doesn't mention editconfig, and I am a dummy so I need menuconfig :)
<apw> do feel free to help us make the ForIdiots page better ... Keybuk only did the bits he needed :)
<mozmck> oh, ok! I forget I can change those pages.
 * apw adds a comment to the random blog telling them they are wrong :)
<mozmck> thanks for the help.
<Keybuk> it's basically where I put notes so I don't have to keep rediscovering them each time
<mozmck> is there a way to tell it to just edit the config for one flavour or do you just have to step through them all?
<Keybuk> I just tend to edit the config file itself
<Keybuk> then use updateconfigs to fill in the bits I missed
<apw> mozmck, no you have to step through them all with that interface
<mozmck> ok
<apw> yeah mostly i am in bulk update mode and want to do them all at once, so i tend to do the update by adding things to the toplevel common files and doing an updateconfigs
<mozmck> I'm working on a custom flavour with rtai patches for running CNC machines with EMC2, so I just add and change settings for that one flavour.
<mozmck> 'debian/rules editconfig' -> make: *** No rule to make target `editconfig'.  Stop.
<mozmck> 'debian/rules editconfigs' -> dh_testdir: cannot read debian/control: No such file or directory
<Keybuk> mozmck: fakeroot debian/rules clean first
<mozmck> ah, that works
<mozmck> thanks
<bjf> ##                                                                                     
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting                    
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting                             
<bjf> ##                                                                                     
<IdleOne> ogasawara: Congrats!!! awesome,incredible,great news :D
<ogasawara> IdleOne: thanks!
<cnd> apw: I'm interested in cleaning up the linux-firmware-nonfree package, partially to learn more about packaging
<cnd> rtg is gone for a bit, and I'd like my changes to get into lucid
<cnd> would you be able to review them?
<apw> cnd sure thing
<ogasawara> apw: https://launchpad.net/~leannogasawara/+archive/ppa/+build/1590208/+files/buildlog_ubuntu-lucid-i386.linux_2.6.34-1.1~oga2_FAILEDTOBUILD.txt.gz
<JFo> bug 507416
<ubot3> Malone bug 507416 in linux-fsl-imx51 "CONFIG_NEON=y causes platform lockups with certain application/platform combinations" [Medium,Fix committed] https://launchpad.net/bugs/507416
<smb> JFo, That should be ok as far as I know, they just don't bother update their bug status. :/
<JFo> ok :)
<crimsun> pgraner: JFo: could you ping Jane S and ask her permission to put a Reported-by in the git changelog for LP 551606, 548661?
<crimsun> (ideally an e-mail address, too, but I understand if she doesn't want it in the kernel changelog)
<JFo> crimsun, will see what I can do about that. :)
<bjf> crimsun, you're doing an upstream fix for 551606?
<crimsun> bjf: yes, I'm about to push the button on git commit -e -a -s
<bjf> crimsun, ok, you are doing a quirk for her SSID?
<crimsun> bjf: no, for all models using that quirk; I'll attach the diff
<bjf> crimsun, ack
<crimsun> bjf: also, I believe I have a fix for her hp mute issue, but there are at least two further debugging steps necessary, one of which requires rolling a new alsa-driver snap (I'll attach a diff to 548661 if the first option is insufficient)
<bjf> crimsun, when does takashi "release" new alsa-driver versions? is there a schedule or just when he feels things are "right"
<crimsun> bjf: he doesn't generally roll those; Jaroslav tends to push the buttons
<bjf> crimsun, ah, ok
<cnd> apw: while I work with #launchpad to figure out the merge request, feel free to review the last four commits at https://code.launchpad.net/~chasedouglas/lucid/linux-firmware-nonfree
<crimsun> smb: do you know when the window for 2.6.32.11 closes? I have possibly two more patches to push to stable (both Jane S's bugs), and I'd like to get them in if feasible.
<JFo> I think it is tomorrow morning iirc
<JFo> but I defer to smb
<smb> crimsun, Not for sure. Normally this amount of activity I would say he might close on Friday
<JFo> ah, see I was wrong ;-)
<smb> crimsun, But sometimes he is quicker.
<crimsun> smb: JFo: ok, thanks
<smb> JFo, ITs hard to say. I have not really found a regular schedule in Greg. 
<JFo> true, I was thinking of something else entirely I am sure
<cnd> apw: ignore my previous bzr branch, I figured out the merge process, so use it instead please
<bjf> apw, can you comment on crimsun question ^^
<crimsun> (actually I'm awaiting on her ack to submit the first patch :-)
<crimsun> awaiting her *
<rackerhacker> jjohansen: have you had reports of a microtime issue in linux-ec2?
<rackerhacker> i couldn't find a relevant bug
<jjohansen> hrmm, not any that I have heard of
<jjohansen> what are you seeing?
<rackerhacker> lemme slip it into pastie right quick
<rackerhacker> http://pastie.org/895689
<rackerhacker> jjohansen: here's a normal karmic server (bare metal, not in a VM): http://pastie.org/895692
<rackerhacker> which is more of what i'd expect
<rackerhacker> if i pop in an old hardy 2.6.24 kernel, all is well
<rackerhacker> domU w/2.6.24-23 -> http://pastie.org/895696
<rackerhacker> it's not perfect in 2.6.24, but it's worse in linux-ec2 from lucid
<rackerhacker> but it could be a silly kernel config on my part
<jjohansen> hrmm, well that does look odd, I'll have a look and run a few tests
<rackerhacker> i can set you up on one of our environments if that'd help
<jjohansen> rackerhacker: sure, that would be worth snooping at
<rackerhacker> gimme a second to get one rolling
<rackerhacker> jjohansen: want me to pile the details into a launchpad bug?
<soren> rackerhacker: Just for giggles, could you try booting a machine with clocksource=acpi_pm and run the same test?
<soren> rackerhacker: (A physical machine, that is)
<rackerhacker> a physical machine running linux-ec2?
<soren> rackerhacker: Running the same as the machine in http://pastie.org/895689 was running.
<rackerhacker> soren: that particular example was within a domU
<soren> rackerhacker: Sorry, wrong pastie.
<soren> rackerhacker: http://pastie.org/895692 this one.
<rackerhacker> let me see if i can spare that machine for a moment ;-)
<jjohansen> rackerhacker: hrmm, not yet.  I haven't been able to replicate on EC2, I have run through 10 different instance size/kernel combinations and every one was good.  I haven't tried your config on EC2 yet though
<rackerhacker> jjohansen: you might be right, soren walked over and gave me a run down
<JFo> crimsun, thumbs up from Jane
<JFo> crimsun, 
<JFo> That's fine - I have no problem with my name and/or email going in there.
<JFo> thanks,
<JFo> Jane
<rackerhacker> jjohansen: call off the search, soren just beat me up with some knowledge
<rackerhacker> it turns out i was using clocksource=jiffies
<rackerhacker> soren's suggestion of clocksource=acpi_pm fixed it immediately
<jjohansen> ah, yeah that can cause so problems
<rackerhacker> soren also says hello
<jjohansen> yeah, say hi to soren for me too
<rackerhacker> can do
<rackerhacker> jjohansen: i owe you three cases of beer at this point
<rackerhacker> my tab is increasing :/
<jjohansen> hehe, not at all
<jjohansen> after all soren fixed this problem :D
<rackerhacker> other than acpi_pm being a little more expensive than jiffies, should i be worried about anything?
<jjohansen> rackerhacker: not really it is consider the best practice to use acpi_pm on more modern kernels
<soren> rackerhacker: Just make sure you keep proper time on the host.
<rackerhacker> soren: can do
<rackerhacker> jjohansen: thanks ;)
<jjohansen> np
<jjohansen> :-)
#ubuntu-kernel 2010-03-31
<ManDay> cross posting hurray, i hope you dont mind:
<ManDay> <ManDay> Any ACPI experts arround? The problem is that pressing the Power-Button causes another kind of shutdown (HIBERNATION In my case) than choosing "Hibernate" from the Gnome-Menu - does anyone know where that difference stems  from or how to make the PB behave just like the Menu-Button?
<crimsun> JFo: the first of Jane's patches has been merged (http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=commitdiff;h=b8e80cf386419453678b01bef830f53445ebb15d); probably want that pulled in as pre-stable (stable was Cced). I would add the note to the LP bug, but LP is in maint mode, it seems.
 * crimsun -> work
<smb> crimsun, I am not sure it will be in the immediate next batch as Greg (just to prove how much you not can predict him) started the review yesterday. Seems he is catching up after moving so the next update after that will probably come sooner.
<JFo> smb, he heard us talking about him yesterday :)
<smb> JFo, Maybe. :)
<apw> smb, wahts that patch about?
<smb> apw, that. what that?
<apw> you were talking to crimsun about it
<smb> apw, Oh, I have not looked into it. Assuming its alsa and Janes computer. But he asked yesterday whether it could get into 2.6.32.y
<smb> I thought there could be time till the weekend but apparently Greg finished unpacking his boxes now. :)
<apw> smb, so we can wait for that one via stable i guess
<smb> It sounded like Greg was sitting on a huge pile to be sent out. So I think if crimsun succeeds in getting them upstream and cc'ed to Greg we see it back before release
<sebj> amitk: Hi, I would like to build a lucid kernel to test on beagle. I was expecting to use ubuntu/ubuntu-lucid.git / ti-omap head, but get an error on building. Is this the git tree I shall use or is it preferable to use amitk/lucid.git tree / ti-omap head?
<amitk> sebj: ubuntu/ubuntu-lucid.git ti-omap should compile just fine. The other is my devel tree (lots of pending patches there)
<amitk> what error do you get?
<sebj> amitk: here is the erro I get: debuild: fatal error at line 630: cannot find readable debian/changelog anywhere!
<sebj> amitk: I used the build instructions you provided here: http://idlethread.blogspot.com/2009/01/recipe-of-day-cross-compiling-armel.html
<amitk> sebj: please run 'fakeroot debian/rules clean' and then re-run the build. I need to fix that old blog post
<sebj> amitk: all right, build starts, thanks!
<amitk> apw: smb: pull request for ti-omap sent, need upload for beta-2
<apw> amitk, nurgle, thanks
<apw> its next on my list
<amitk> apw: mucho thanks
<amitk> apw: We can skip abi to make it easier, I've not added the debian magic patches in the set
<amitk> will save a meta upload
<JFo> mmmm gravy
<apw> amitk, yep ...
<apw> amitk, this fsl-imx51 update, any idea who/what it is for?
<apw> karmic/lucid
<apw> ?
<amitk> apw: upstrea, don't bother
<apw> amitk, thanks ... handy
<amitk> apw: I might have to push one more config change for USB peripherals (ti-omap
<amitk> )
<psurbhi> I have been looking at the sync() system call and saw that it calls wakeup_flusher_threads() which ultimately calls bdi_alloc_queue_work() with WB_SYNC_NONE, 
<psurbhi> then again sync_filesystems(0); would do the same thing.
<psurbhi> it calls writeback_inodes_sb() which finally calls bdi_alloc_queue_work() with WB_SYNC_NONE for every filesystem.
<psurbhi> Can anyone let me know why this is called twice? Isnt one of the calls unneeded? or is there a reason for this call?
<apw> amitk, no problem not touched it yet
<apw> psurbhi, i can't have i have enough context to give you a good answer
<apw> it doesn't sound like an issue
<psurbhi> apw, i wanted to know the reason for doing it through two different calls which ultimately end up doing only the same thing (and nothing else)
<apw> it may behistoryical
<psurbhi> there certainly has to be a reason to do that.
<psurbhi> ok
<ogasawara> smb: I'm on the fence if the following should qualify for Hardy SRU - https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/551855
<ubot3> Malone bug 551855 in linux "[hardy] Support for NC522SFP Gb network card is broken" [Undecided,New] 
<ogasawara> smb: your thoughts?
<smb> a sec
<smb> ogasawara, Yeah, if the changes are big it is not really something for normal sru. I think I have been telling that probably it could become a l-b-m update if it is important
<smb> And they need to be aware that there are no CD rebuilds for Hardy anymore as far as I have been told of
<ogasawara> smb: yah, I already relayed the message that no new ISO will be built
<lamalex> Hey kernel team, my lenovo t400 has started consitently failing to suspend on lucid
<lamalex> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/550479
<ubot3> Malone bug 550479 in linux "fails to suspend on Lenovo t400 laptop" [Undecided,New] 
#ubuntu-kernel 2010-04-01
<crimsun> JFo: do you happen to have access to an identical model ThinkPad as the reporter's in #548661?
<crimsun> (I'm not convinced that it's a kernel issue)
<JFo> crimsun, I don't, but I can find out if someone else does
<crimsun> JFo: much obliged
<JFo> my pleasure
<crimsun> I'm attempting to shift my work schedule to accomodate her responses, but it's difficult
<JFo> yeah, :-/ UK time...
<JohnFlux> smb: hey :)
<smb> JohnFlux, Not here right now. I haven't had my first coffee. :-P 
<JohnFlux> smb: :-)
<JohnFlux> smb: we added support for my driver to the kernel...  do you know roughly when that means I can use that kernel and be able to have the nvidia drivers?
<JohnFlux> smb: I'm just being spoilt now :-)
<JohnFlux> smb: getting the nvidia drivers isn't a high priority, just a niceity
<smb> JohnFlux, your id quirk should have been in since around this Monday. "The" nvidia drivers I fail to make a connection to right now
<JohnFlux> smb: yes, quite possibly my question is nonsense.  At the moment I have a "custom" kernel.  Can I install the proprietary nvidia drivers?
<JohnFlux> smb: actually I should just stop bothering you and go google
<smb> JohnFlux, I think I saw Alberto tell people they are "safe" now. 
<JohnFlux> cool
<JohnFlux> smb: the nvidia drivers gave an error when installing, but worked anyway
<JohnFlux> smb: thanks for the help
<smb> JohnFlux, Sounds good. Welcome.
<smb> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/539655
<ubot3> Malone bug 539655 in linux "nouveau hard lockup in nouveau_gem_ioctl_cpu_fini" [Medium,Triaged] 
<apw> http://patchwork.ozlabs.org/patch/48906/
<Kevin`> hi, cjwatson says this should be handled here, so: simple fix to this bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/160366
<ubot3> Malone bug 160366 in linux "Add xen netboot support" [Wishlist,Triaged] 
<Kevin`> 03:30 < cjwatson> xen-blkfront should go in scsi-modules, and xen-netfront  should go in nic-modules
<Kevin`> 03:31 < cjwatson> (feel free to copy and paste that)
<Kevin`> to be clear, a seperate version of the installer isn't needed, like the original author suggested
<smb> Kevin`, Ok, yeah. So just those two. Should be doable. Thanks
<Kevin`> np :)
<Kevin`> might be proper to include the framebuffer/keyboard interface, assuming it isn't already included. I don't know if there's a way to do a graphical netboot install anyway though?
<Kevin`> I certainly never do
<apw>  *      <xres>x<yres>[M][R][-<bpp>][@<refresh>][i][m][eDd]
<apw> video=VGA1:stuff
<tseliot> mjg59: I'm getting this with the open radeon driver "ACPI: ACPI brightness control misses _BQC function" with a Mobility Radeon HD 4200 (1002:9712). No backlight for me?
<tseliot> well, backlight management
<mjg59> tseliot: Lacking _BQC won't inherently result in missing ACPI backlight
<mjg59> Do you have anything in /sys/class/backlight?
<tseliot> mjg59: yes, I have /sys/class/backlight/acpi_video0/ but my problem is that dimming the backlight freezes X
<mjg59> tseliot: Unrelated to the kernel message, then
<mjg59> Probably implemented via some SMI that interacts badly with the native driver. What machine is this?
<tseliot> mjg59: it's an Inspiron
<tseliot> dell inspiron
<mjg59> What model?
<tseliot> mjg59: fglrx gets this right
<mjg59> Still via the acpi_video backlight?
<tseliot> mjg59: it's from series 11, I can't say more
<tseliot> mjg59: ah, that's a good question but I don't how fglrx works
<mjg59> That makes fixing things difficult
<mjg59> You're best going via Dell, then. They'll be able to work out what the BIOS is doing
<tseliot> mjg59: can it be a BIOS issue?
<mjg59> Given that it works with fglrx, it's clearly a radeon bug
<tseliot> ok, thanks for your help
<mjg59> But if it's via an SMI call, there's no way to work out what the BIOS is doing
<mjg59> It's probably writing to some chip register directly
<mjg59> And failing for one reason or another
<tseliot> oh
<mjg59> Due to a difference in chip setup between radeon and fglrx
<mjg59> But without knowing what it's doing, fixing this is difficult
<mjg59> You presumably can't send me the acpidump
<mjg59> And even if you could, it'd probably just show an SMI trigger
<mjg59> So you'll need to ask Dell what the backlight setting is doing, and then work out why that conflicts with radeon
<tseliot> ok, I'll definitely ask Dell, thanks
<mjg59> tseliot: Note that the correct fix for this is *not* a bios update
<mjg59> The bug is definitely in radeon, and that's where the fix should be
<tseliot> mjg59: yes, we should fix radeon after seeing what's going on
<tseliot> got it
<cnd> is there a place where bugs that weren't picked up for lucid are monitored for M?
<cnd> There's bug 333990, which should be a simple config option in the kernel, and I don't want it to forget about it for M like seems to have happened since jaunty
<ubot3> Malone bug 333990 in linux "[Karmic]Please enable PCI express ASPM (powersave)" [Medium,Won't fix] https://launchpad.net/bugs/333990
<cnd> Is the Ubuntu later milestone used for such purposes?
<crimsun> bjf: my inbox exploded thanks to the tagging. Had to add another filter. :-)
<bjf> :-)
<crimsun> so, we could probably halve these mic bugs by doing these two things:
<crimsun> 1) making sure *Mic Boosts are raised to max
<crimsun> 2) grepping the HDA codec dumps to make sure the correct init is made
<crimsun> (and of course the underlying init keeps changing from under me...)
<bjf> ack
#ubuntu-kernel 2010-04-02
<spikey> Hi! The execve doesn't close the file descriptor. I'm search a execve similiar function that instead it close the file descriptor and it will open their in the new process. Tips please?
<bryceh> could someone take a look at this (kernel?) issue I'm having?  https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/553675
<ubot3> Malone bug 553675 in linux "Yorkfield/Eaglelake system hang during boot (and no splashscreen)" [High,New] 
<bryceh> ogasawara, JFo: ^ I got the apport info and didn't see anything useful in /var/log after rebooting, but let me know if there's a way I can get better info on it
<tacpilot> does any one have experience with real time kernels ???
<JFo> crimsun, no joy so far on the hardware matching for Jane
<JFo> bryceh, will do
<eggonlea> Hi all, in Ubuntu kernel, when restoring from hibernation, is "resume=/dev/xxx" needed in bootcmd? Or kernel would scan all connected harddisk for the swap partition which contains the swapfile signature?
<crimsun> JFo: ok, no worries. Thanks for checking.
#ubuntu-kernel 2010-04-03
<JFo> crimsun, any word on that patch for Jane's bug?
<crimsun> JFo: oh, I've had one rolled for a couple days, but I'd really like to avoid ping-pong, hence asking for another tester first
<crimsun> JFo: also, I haven't heard back whether the symptom is reproducible from a current Lucid live cd
<JFo> ah, right
<crimsun> what's really quite strange is either her wording or the actual symptom; jack sensing appears to have worked in Lucid prior to the use of some app
<crimsun> s/Lucid/Karmic/
 * crimsun digs into the pulse-on-ARM bug in frustration
<crimsun> smb's stable branch for 2.6.32.11 has the BugLinks munged for my commits
#ubuntu-kernel 2010-04-04
<nosse1> Hi. If I have checked out the ubuntu kernel git, how can I get the .config?  I know its debian/rules something
<owen1> there is a serious bug with many asus and dell laptops but it was not assigned to any developer. what can I do to get the attention of canonical? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/512192
<owen1> this thouchpad is too sensitive which forces me to use external keyboard.
<ubot3> Malone bug 512192 in linux "Can't configure Elan tech touchpad on Dell Inspiron 11z, Asus K7I0C and maybe also Dell Mini 10 (not V), ASUS k40in, Asus U81A and ASUS UL80-VT." [Undecided,Confirmed] 
<crimsun> owen1: please use the mailing list
<nosse1> Are any of the Ubuntu specific drivers required for system operation. I.e. can I build a vanilla kernel without the Ubuntu patches on Ubuntu?
<crimsun> nosse1: that utterly depends on the hardware. In general, no, the ubuntu sauce isn't necessary for mainstream consumer (e.g., Best Buy-/Microcenter-type) hw.
<nosse1> thanks.
<nosse1> I'm trying to build a kernel for a new ARM HW target. Ubuntu lucid kernel (ti-omap branch) is not working OOB and I need to recompile.
<nosse1> I have a working kernel from the vendor, that I need to Ubuntuize for it to work
<nosse1> That's why I was looking for the config
<owen1> crimsun: sure. googling for it now
<owen1> crimsun: what mailing list should i post it on? ubuntu-devel ?
<crimsun> owen1: kernel-team
<owen1> crimsun: got it, thanks
<owen1> do i have to subscribe in order to post something?
<crimsun> owen1: no, will just be moderated
<owen1> crimsun: great. i just posted it
#ubuntu-kernel 2011-03-28
<hyperair> sb levelclear -level clientcrap,crap,joins,parts,quits,nicks,clientnotice
<fairuz> morning
<ppisati> smb: ping
<ppisati> [flag@newluxor kteam-tools]$ ./stable/create-stable-tracker
<ppisati> Traceback (most recent call last):
<ppisati>   File "./stable/create-stable-tracker", line 11, in <module>
<ppisati>     from lpltk.service                      import LaunchpadService, LaunchpadServiceError
<ppisati> ImportError: No module named lpltk.service
<ppisati> [flag@newluxor kteam-tools]$ dpkg -l | grep launchpad
<ppisati> ii  launchpad-integration                0.1.38                                            launchpad integration
<ppisati> ii  liblaunchpad-integration1            0.1.38                                            library for launchpad integration
<ppisati> ii  liblaunchpad-integration1.0-cil      0.1.38                                            CLI bindings for liblaunchpad-integration
<ppisati> ii  python-launchpad-integration         0.1.38                                            library for launchpad integration
<ppisati> ii  python-launchpadlib                  1.6.1-1                                           Launchpad web services client library
<ppisati> ii  python-launchpadlib-toolkit          0.2.1                                             convenience library for launchpadlib
<ppisati> [flag@newluxor kteam-tools]$
<ppisati> smb: which pkg am i missing?
<DrDetroit> jjohansen: I have finished testing the 30 kernel and have not had any problems
<DrDetroit> what do we do now?
<jjohansen> DrDetroit: hrmm well I would say stick with the 30 kernel :)
<jjohansen> I'll add a note to the bug, and mark it as incomplete or maybe invalid
<DrDetroit> jjohansen: ok, I think we should probably delete my bug report, or mark it no good. I also want to thank you for helping me, and apparently fixing my problem
<DrDetroit> Also, in appreciation of all your efforts, I am willing to help out test stuff if you ever need me to
<jjohansen> I would like to say fix released but we don't know what it was etc.., so I will leave it a slightly less final state
<jjohansen> DrDetroit: sounds good, I may just have to take you up on that
<DrDetroit> its the least I can do to show my appreciation and to be of some help
<DrDetroit> If this happens again, I will file a new bug report.
<jjohansen> sounds good
<DrDetroit> thank you so much
<jjohansen> DrDetroit: your welcome
<fairuz> Hi
<fairuz> if I have a device registered with platform_device_register, how can I use it?
<DrDetroit> good morning
<fairuz> DrDetroit: morning
<smb> ppisati, pong. I would guess the wrapper and the arsenal toolkit. In the stable directory there is a README with instructions how to get those
<ppisati> smb: doh! i really missed the README... :P
<smb> ppisati, There are these very rare occasions where those actually contain useful information. :D
<ppisati> smb: yep, but i really didn't see it... :)
<smb> hehe
<fairuz> Hi, any idea why when i compiled my kernel, it adds + at the end of the kernel name
<Shred00> why are the kernel-source packages not available for mainline kernels beyond v2.6.32.10-lucid?
<smb> Shred00, because the way those were generated they were not that useful. Now you can just take a vanilla tarball and apply the patches in that are provided to get the same source as was used for the build.
<Shred00> smb: ahhh.  ok.
<smb> fairuz, Only a plus or some number too?
<fairuz> smb: only a +
<fairuz> smb: i suspect the LOCALVERSION is the culprit?
<smb> fairuz, Not really sure then. That should normally end in having some git sha with it. Has that plus somehow made its way into your changelog's version number?
<fairuz> smb: It was LOCALVERSION. I recompile with LOCALVERSION= and the + sign disappeared
<fairuz> hmm werid. Never happens before
<fairuz> *weird
<smb> Normally that LOCALVERSION should get updated/modified by the builds environment to contain the version extension from the changelog. If you use the debian/rules calls
<fairuz> smb: ok
<ppisati> tgardner: ping
<tgardner> ppisati, yo
<ppisati> tgardner: i've some questions about the ti-omap4 pull/tracker/etcetc
<ppisati> tgardner: for example, which version shall i pass to create-stable-tracker?
<ppisati> tgardner: previously, you used the version of the kernel upon which you rebased
<ppisati> tgardner: but in this case?
<tgardner> Use the ti-omap4 version since it is what we're tracking
<ppisati> ok
<ppisati> so
<ppisati> ../kteam-tools/stable/create-stable-tracker --version 2.6.35-903.22 <= prev. one was .21
<tgardner> ppisati, that looks right. it also makes sense since a single rebase can contain multiple master stable updates.
<Specialist> hi there! i could use some help debugging an s2ram issue... i already used /sys/power/pm_test to isolate the issue and problems start at the 'processor' level ('platform' still works correctly)
<tgardner> Specialist, have you tried the firmware test suire (fwts) ? It might give you some ideas.
<tgardner> suite*
<Specialist> tgardner: nope, i'll have a look at fwts
<Specialist> the ugly thing is that this is a regression since 2.6.35 where s2ram worked like a charm...
<tgardner> smb, doesn't seem like it would be too hard to produce a test kernel for bug #730765. those are SRU'able patches (I think).
<tgardner> and quite testable.
<smb> tgardner, Testable should be no problem. The main issue is that those are the upstream versions which only need changing a single place. While the same code is spread over several places in one file (lucid) or two files (hardy)
<ppisati> tgardner: about entries in changelog, some of them have a LP# while others don't have one, and i can't find any entry in LP about them
<ppisati> tgardner: http://paste.ubuntu.com/586452/
<Kano> hi apw , can you tell my why the mainline 38.1 kernel has got no FB_VESA module?
<tgardner> smb, I checked Hardy. It seems correct.
<ppisati> tgardner: i.e. the first one "ALSA: seq/oss - Fix double-free at error path of snd_seq_oss_open(), CVE-2010-3080" i can't fine any entry in LP about it
<ubot2> ppisati: Double free vulnerability in the snd_seq_oss_open function in sound/core/seq/oss/seq_oss_init.c in the Linux kernel before 2.6.36-rc4 might allow local users to cause a denial of service or possibly have unspecified other impact via an unsuccessful attempt to open the /dev/sequencer device. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3080)
<Kano> apw: # CONFIG_FB_VESA is not set
<tgardner> ppisati, it seems that not all of the CVEs got bug reports. they may be quite old. you could ask bjf when he comes online.
<ppisati> tgardner: ok
<Kano> also CONFIG_FB_BOOT_VESA_SUPPORT is not set
<tgardner> or, the fix may have come via stable updates.
<smb> tgardner, Last time I looked there was interrupts regstered somewhere in arch/x86/xen and drivers/xen/ and the proposed patch only covered one place
<ppisati> and the funny thing is that LP keeps timing out everytime i try to access a /bugs/cve/...
<smb> tgardner, Well for Lucid it did
<tgardner> smb, for Hardy it patches archx86/xen/events.c
<smb> tgardner, Sadly drivers/xen/events.c is not used for lucid.ec2
<tgardner> smb, well, lets see if we can fix Hardy first. that seems the simplest approach.
<smb> tgardner, I think drivers/xen/core/evtchn.c might be another place to check
<Specialist> hm... fwts segfaults during the hotkey test... is there a way to exclude this specific test?
<smb> tgardner, IIRC in HArdy one file did the virqs and ipis and the other the rest of them
<tgardner> cking, see Specialist comment above re fwts.
<Kano> tgardner: did you work on 38.1?
<Specialist> cking: i guess it is the hotkeys test as that is the last entry in the log file
<smb> tgardner, Oh and of course one needs to make very sure that anything we change is actually used for the xen custom binary. Those patchsets seem to have the nasty habit of modifying the config options in a way the things looking ovious to be used are not always
<cking> Specialist, yes, use fwts --skip-test=foo where foo is the name of the test
<tgardner> smb, have you actually looked at the patch?
<cking> Specialist, which version of fwts?  fwts -v
<smb> tgardner, Only very quick and roughly I must admit
<Specialist> cking: 0.18.04 (the version from maverick)
<cking> Specialist, may be worth checking out ppa:firmware-testing-team/ppa-fwts-stable as this has some newer code and may fix the issue. If not, please file about against fwts
<smb> tgardner, Just to make sure, we are talking about this one? http://launchpadlibrarian.net/66557764/combined.diff
<Specialist> cking: afaics --skip-test is not yet implemented in that version
<tgardner> smb, yeah, that look right.
<tgardner> Specialist, get the Natty version
<cking> Specialist, apologies, you're right, it's quite an old version now - so use the one it my ppa-fwts-stable PPA as this has a maverick build with the latest stable code
<smb> tgardner, My feeling is that the Hardy patch is ok for ipi and virq, but might miss the same changes for the other types (in evtchn.c). And probably does not do the "use per cpu irq for virq and ipi" thing
<tgardner> smb, hmm, I'll rely on your expert opinion. I'm not that familiar with the inner workings of xen
<smb> tgardner, Actually its not so much the inner workings of xen as the magic working of the patchset, but let say, give me and hour and I try to see how far I get
<ppisati> bjf: ping
<Shred00> hrm.  http://www.kernel.org/pub/linux/kernel/v2.6/patch-2.6.32.12.bz2 is the patch one applies to http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.32.11.tar.bz2 to get 2.6.32.12 isn't it?
 * ogasawara back in 20min
<hyperair> 
<hyperair> whoops
<cking> Specialist, if the newer version of fwts still segfaults, please file a bug and I will try and get it fixed
<Specialist> cking: will do (tests are currently running)
<cking> ok
<cking> I expect the keymap parsing may have got confused
<Specialist> sorry... lost connectivity
<Specialist> back to my original s2ram issue. i now have the fwts results available at: https://secure.tgbyte.de/dropbox/aiLiNi8b.txt
<Specialist> i had to skip the hotkey, s3 and s4 tests (both freezing)
<tgardner> Specialist, have you started a bug report? sometimes there known issues with certain platforms. 'ubuntu-bug linux'
<Specialist> tgardner: i have both an ubuntu and a linux kernel bug open,which do not seem to mke much progress as my original kernel was tainted by the nvidia module. the issue, however also occurs with nouveau. i'll attach the fwts output to those reports, though.
<tgardner> Specialist, ack
<tgardner> sconklin, are you available for a mumble chat ?
<cking> Specialist, is this based on an ASUS P5QL motherboard?
<sconklin> sure, will fire it up
<Specialist> cking: yes
<Specialist> cking: any known issues with that hardware?
 * cking can't recall of anything, but I've not dealt with that H/W
 * cking has a quick google
<cking> Specialist, have you tried the advice in https://wiki.ubuntu.com/DebuggingKernelSuspend and/or https://wiki.ubuntu.com/DebuggingKernelSuspendHibernateResume
<Specialist> cking: yep, the suspend works until the 'platform' mode (including), but fails once the processor suspend is also tested
<Specialist> cking: further diagnostics turn out to be pretty difficult as the screen is turned off before the freeze happens
<cking> Specialist, try booting with no_console_suspend and switch to a console and re-do the test, maybe you will see something pop onto the console before it does
<cking> s/does/dies/
<Specialist> cking: ok, i'll give it a try
<cking> it could be one of several issues, maybe a broken driver, or perhaps the BIOS, but w/o more debug it's hard to tell. 
<Specialist> cking: aren't drivers ruled out by the fact that the 'platform' test still works?
<cking> probably, I missed that
<Specialist> cking: hm... my screen still turns off despite no_console_suspend being in place
<cking> Specialist, hrm.  I see you have the latest firmware, so updating that is not a route we can look at either
<Specialist> cking: ack. i did a bios update recently hoping that it would solve the issue
<cking> has S3 always failed, no matter which release you have used?
<Specialist> nope, it worked with kernel 2.6.35
<fairuz> Hi, is there any way to check if the soource folder is dirty or not? 
<Specialist> unfortunately, i had to upgrade to 2.6.38 as 2.6.35 has a terrible latency for dmcrypt/luks
<Specialist> i also tried a bisect, but the results do not make much sense (cf. https://bugzilla.kernel.org/show_bug.cgi?id=31562)
<ubot2> bugzilla.kernel.org bug 31562 in Hibernation/Suspend "Suspend to RAM (S3) sporadically hangs" [Normal,Reopened]
<Specialist> my guess is that there was a false negative during the bisect
<cking> yep, especially as the bug seems sporadic
<Specialist> the weird thing is, that recently i have been able to reproduce it consistently
 * tgardner swipes bug #630748 from ogasawara
<ubot2> Launchpad bug 630748 in module-init-tools "iwlagn degrades quickly during normal wifi session" [High,In progress] https://launchpad.net/bugs/630748
<cking> Specialist, it seems quite a popular motherboard, but I've not seen anyone else report similar issues
<Specialist> cking: well, maybe there aren't too many people that have a core 2 quad running on that hardware. or there aren't too many people already on 2.6.38 so far...
<ogasawara> tgardner: from my understanding there's not much more we can do unless there's new firmware to test
<cking> Specialist, true. at this point, I'd start putting debug into the appropriate pm paths and the S3 suspend path and see if that shows anything up.
<ogasawara> tgardner: but sabdfl is able to reproduce if we need someone to test
<cking> Specialist, I think you've run down every reasonable debug avenue I can think of
<Specialist> cking: yep, i'll compile a new kernel with debug acpi output enabled
<tgardner> ogasawara, I corresponded with Mey-Yi. She thinks now that the drivers are split that we can turn 802.11n on for non-legacy devices. 3945 is gonna be broken forever
<Specialist> cking: it may be tricky, though, to read the output considering that the display turns off ;-)
<tgardner> ogasawara, what model iwlwifi device does sabdfl have?
<Specialist> i guess there is no way to tap into the machine's state to still read data (network is already down) without any special hardware... or would a serial console work?
<cking> Specialist,  it depends - I sometimes use the RTC to save state, or if possible I use a port $80 PCI card. Serial only goes so far because most machines I work on don't have a serial port, and one has to use USB/serial dongles and these only work so far in S3 
<tgardner> cking, but his MB likely has serial.
<Specialist> well, the board still has a serial port connector
<cking> in which case, it's well worth a spin 
<Specialist> it requires an adapter, but that should be possible to get
<cking> if that's not possible, I generally resort to saving debug state in the RTC - it's limited and painful
<cking> from the photo of the MB I google'd I couldn't see a serial port
<ogasawara> tgardner: I'd have to double check with him, but i think 4965?
<tgardner> ogasawara, ok, I'm trying to get my patch reviewed.
<Specialist> cking: the P5QL Pro does have a COM1 header next to the super-i/o chip
<ppisati> tgardner: about the changelog in LP, does it get filled automagically? or do i have to do it manually?
<cking> Specialist, sweet - maybe you are in debug luck
<tgardner> ogasawara, non-sequitur - did you notice 2.6.38.2 came out over the weekend?
<diwic> cking, is the RTC still a separate chip? If so you could snoop it and use it as a serial port :-)
<smb> tgardner, Just a quick feedback on where I am with xen and hardy: Turns out that (of course) arch/x86/xen is not used at all for the custom-binary-xen kernel. And while newer code does the handler calls when binding, the old code does that quite soon and only distinguishes between pirq and dynirq.
<ogasawara> tgardner: I did, and I've already rebased and pushed it back up to master-next
<tgardner> ogasawara, doh! I should have done my homework :)
<ogasawara> ;)
<smb> tgardner, So I think I may just try to get dynirqs to be fasteio and see what happens. And leave the use percpu for virq and ipi for a second approach.
<tgardner> smb, if not arch/x86/xen, then where is the equivalent support in the patched kernel?
<smb> tgardner, drivers/xen/core/evtchn.c as for Lucid
<tgardner> smb, ah.
<tgardner> how inconvenient.
<tgardner> smb, is lucid-ec2 this borked as well?
<smb> tgardner, yep, what you see may not be what you get. Everything that seems to be xen (or a lot) is only build with CONFIG_PARAVIRT_XEN set, which is not used/is not set for the topic branch (and hardy xen)
<tgardner> smb, I think I'm beginning to feel your pain.
<smb> tgardner, At least it makes my head hurt when trying to keep the various versions apart in my head.
<tgardner> thats no surprise.
<cking> smb,  you need an head expansion pack
<smb> cking, Wished I could use those big micro sd cards on myself. At some point one surely does want not to remember. :-P
<cking> yeah, back it all onto a micro sd card and put it in a box which will never see daylight again
<herton> ogasawara: bug 733780 should be fixed by rebase to 2.6.38.2 on natty (sent patch had buglink but was changed)
<ubot2> Launchpad bug 733780 in linux "[126167.230394] BUG: unable to handle kernel paging request at 00100104" [Undecided,Incomplete] https://launchpad.net/bugs/733780
<ogasawara> herton: thanks, I'll fix up the changelog
<Kano> why is vesa fb not available in 38.2/38.1?
<ogasawara> Kano: I thought that was enabled as a module in the recent Natty upload?
<Kano> you think, but thats not the case
<tgardner> debian.master/config/config.common.ubuntu:CONFIG_FB_VESA=m
<Kano> # CONFIG_FB_BOOT_VESA_SUPPORT is not set
<Kano> # CONFIG_FB_VESA is not set
<Kano> when you check the resulting kernel
<Kano> tgardner: i saw it too, but the result is something different
<tgardner> debian.master/config/amd64/config.common.amd64:CONFIG_FB_BOOT_VESA_SUPPORT=y
<tgardner> debian.master/config/amd64/config.common.amd64:CONFIG_FB_UVESA=m
<tgardner> d
<tgardner> are we looking at the same kernel? this is Natty
<Kano> tgardner: 32 bit .38.2 mainline (same for 38.1 mainline)
<manjo> Bug #744419
<ubot2> Launchpad bug 744419 in linux "[NATTY] [ Kernel oops installing natty @tty_write()" [Undecided,New] https://launchpad.net/bugs/744419
<tgardner> oh, I guess the mailine builds are lagging behind natty
<tgardner> ogasawara, gonna need meta package support for natty as soon as LBM is new'ed
<ogasawara> tgardner: ack, will get a patch ready
 * tgardner --> lunch
<jjohansen> sconklin: I don't know if you followed the performance regression I was trying to bisect but, we weren't able too, the problem seem to surface unreliably and he is currently using the -30 kernel without problems
<bjf> jjohansen, you were never able to reproduce it yourself ?
<jjohansen> bjf: no, /me should add that to the bug
<jjohansen> bjf: I was going to run the lucid install longer and see if it surfaced
<bjf> jjohansen, i run that on my regular dev system here, and have not seen that issue
<jjohansen> bjf: though I do have a perf dump from cfreak on his similar issue with .38
<jjohansen> bjf: right, it seems to maybe be at least partially hardware related, cfreaks trace has issue with the hpet (it seems)
<sconklin> jjohansen: I did see that in the bug email. Thanks for the effort bisecting. It would be nice to understand this one
<jjohansen> sconklin: indeed
<sconklin> tgardner: any news on the hppa failure?
<tgardner> sconklin, nope, but thanks for the reminder. I sent lamont an email last Friday, but I've not followed up on it.
<tgardner> sconklin, or at least I thought I did, but sure can't find it.
 * jjohansen -> lunch
<tgardner> ogasawara, you still have git repo commit rights, don't you?
<ogasawara> tgardner: I do
<tgardner> ogasawara, then just push the meta package update
<ogasawara> tgardner: ack
<ogasawara> tgardner: did you happen to ping cjwatson about the lbm-2.6.38 upload?  I recall andy mentioning we'd need to have him add it to some uploaders list.
<ogasawara> tgardner: if not, I'll ping him
<tgardner> ogasawara, not yet, we'll likely have to wait until Beta thaws
<ogasawara> tgardner: yep, was just gonna give him a heads up
<tgardner> ogasawara, sure. I uploaded it, but its stuck in NEW
<herton> jjohansen, sconklin, bjf: there is a new performance regression report about 2.6.32, bug 743907
<ubot2> Launchpad bug 743907 in linux "Performance degradation after resume" [Undecided,New] https://launchpad.net/bugs/743907
<sconklin> herton: thanks
<herton> but this one is different, the issue is after resume from suspend
<herton> from the one you were looking with DrDetroit
<jjohansen> hrmm, I've seen behavior like that before
<DrDetroit> The one I was working on didn't show anything using resources, that is what made it so difficult
<DrDetroit> but it has gone away on my machine.
<jj-afk> back on in an hour
 * ogasawara back on later
<skaet> ogasawara, when you're back on later, could you take a pass at https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview and make any changes necessary to describe the kernel a bit better?
<Specialist> hi all, i am currently trying to debug the linux kernel through a serial console. after getting the pinout right, everything is working - except for the fact that past a certain point in the boot sequence the kernel messages are no longer sent to the serial console
<Specialist> is there any daemon active by default that redirects all kernel messages?
<BenC> Specialist: getty
<BenC> After initial boot it goes to the "console" which is usually the monitor
<BenC> Specialist: http://www.linuxquestions.org/questions/linux-kernel-70/how-to-capture-kernel-panic-messages-on-serial-console-691396/
<BenC> should be useful
<Specialist> thx
<Specialist> so configuring the console using console=ttyS1,115200n8 during boot is not sufficient, right?
#ubuntu-kernel 2011-03-29
<Specialist> there must be something i am mising. everything is set up as per the tutorials i read, but still the last kernel message that ends up on the serial console is:
<Specialist> [   27.571317] EXT4-fs (dm-2): mounted filesystem without journal. Opts: (null)
<Specialist> then follows silence until i reboot, which is again indicated on the console: [ 1762.680197] Restarting system.
<BenC> Specialist: are you sure there are actually kernel messages to be printed?
<Specialist> yes, i can see them using dmesg
<BenC> Perhaps the console level for kernel messages is set to mask them being sent to the console?
<BenC> Is "quiet" on the kernel command line?
<Specialist> BenC: no, quiet is not on the command line
<BenC> Check printk level for console output then
<BenC> Read and edit /etc/sysctl.d/10-console-messages.conf
<Specialist> BenC: it's 4 4 1 7 - what would i need to specify if i wanted to see all messages (googling did not help to figure this out - most hits just list the defaults)
<BenC> Specialist: http://www.makelinux.net/ldd3/chp-4-sect-2.shtml
<BenC> Section 4.2.2 and the line above it where you "echo 8 > ..."
<BenC> Specialist: So changing the values to 8 should do it
<Specialist> thanks!
 * BenC found that with google
<Specialist> BenC: just out of curiosity: what were your search terms?
<BenC> linux kernel printk console level
<ogasawara> skaet: alpha3 to beta1 blurb added for the kernel section in the TechnicalOverview wiki, will add the more substantial Maverick to Natty blub in a bit.
<skaet> ogasawara, awesome.  thanks!
<beata|lemur> Howdy hi. Encryption question: How do I tell if pcrypt is actually being used? I don't seem to see it in ps, and the module use count is 0.
<fairuz> hi morning
<fairuz> hi, is it a problem if i got a compiled kernel with -dirty behind it's name? I already did make clean but no luck, still it adds -dirty.
<ohsix> it just means you changed it
<fairuz> ohsix: what do you mean by changed? afaik, if you do make clean, the dirty will go away
<jjohansen> fairuz: do you have uncommitted changes?  That can cause the dirty tag to be applied
<fairuz> jjohansen: of course! why i dont think of that before
<fairuz> jjohansen: what is the command to reset again (i tend to forget everything). something like git reset --hard master?
<jjohansen> fairuz: to reset the head git reset --hard origin/master (if on the master branch)
<jjohansen> fairuz: git checkout -f will throw away uncommitted changes
<fairuz> jjohansen: cool, ty
<fairuz> jjohansen: still bug hunting?
<jjohansen> fairuz: not at the moment, but I do have several queued up
<fairuz> jjohansen: i suppose it's very time consuming? Seen that you and DrDetroit did test a lot of kernels
<jjohansen> fairuz: yeah it can be, it just depends on the bug
<DrDetroit> hehe i should turn off my sound when I am napping
<DrDetroit> or mark myself away i guess
<fairuz> DrDetroit: oh sorry :D
<DrDetroit> fairuz: don't worry about it, you did nothing to apologize for
<jjohansen> rebooting
<ppisati> how long does it take to move from master-next to master?
<Specialist> hi there, my struggle to figure out what is breaking s2ram for my machine on 2.6.38 continues. i got a serial console working. unfortunately, during suspend the serial console output changes to garbage (with no_console_suspend enabled) rather early during the suspend phase so that i cannot read the most interesting information. is this to be expected?
<jjohansen> Specialist: it can happen, some further ideas might be found at
<jjohansen> https://wiki.ubuntu.com/DebuggingKernelSuspend
<jjohansen> https://wiki.ubuntu.com/DebuggingKernelSuspendHibernateResume
<Specialist> jjohansen: thanks! i have to say that i have read those documents already a couple of times ;-) the only untested hypothesis that remains is the possibility of a kernel panic during suspend. i guess a usb keyboard will not indicate that event by flashing the keyboard led as usb will probably already be down, right?
<jjohansen> Specialist: ugh, yeah usb keyboard making the flashing led trick less than useful
<jjohansen> or less useful
<Specialist> well, then it's time to resurrect my ps/2 keyboard ;-)
<Specialist> yesterday someone also mentioned storing debug information in the cmos using the rtc. instead of using the current time (causing the information to decay) wouldn't it make sense to set a (disabled) alarm with the intended payload instead? that data should not decay...
<ohsix> Specialist: theres actually in practice lots of places to store that information, but the rtc is the lowest common denominator
<Specialist> ohsix: are you aware of any code sample that i may re-use?
<ohsix> Specialist: don't know what you're doing, i just saw the rtc comment and something about debugging suspend
<Specialist> ohsix: i am trying to figure out why my system sporadically freezes during s2ram. i alreadt tried serial console, but that becomes corrupted during suspend. so i thought that i'd modify the rtc state using a bitmask to record certain checkpoint information during the suspend phase
<sconklin> ppisati: thanks for verifying your bug!
<ohsix> Specialist: i used netconsole
<Specialist> ohsix: the thing is that for me the suspend fails so low-level that the rtc may be the only device that will still work reliably at that time
<diwic> Specialist, I think the kernel uses the upper bits only and you have a few minutes only to read the information out of the rtc when you boot up again
<Specialist> ohsix: well, that's ok for me. i just spotted the implementation in drivers/base/power/trace.c, which seems like a good starting point for my debug code
<fairuz> Hi, when compiling a external module, can I specify the output folder for *.ko file? I use this right now to compile : make ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C $(KERNEL_SRC) M=$(PWD) modules
<jjohansen> fairuz: O=
<jjohansen> but its not just the output folder for the .ko its all object files
<sforshee> fairuz, have you tried using using MOD_INSTALL_PATH with make modules_install ?
<sforshee> e.g. 'MOD_INSTALL_PATH=/foo make modules_install'
<fairuz> sforshee: I'm compiling __a__ module
<fairuz> an external one
<sforshee> fairuz, yes, but what does it do if you run that from your module's source dir? I don't know, but might be worth trying
<fairuz> sforshee: it will install the modules from the source tree not my module :D
<fairuz> jjohansen: already tried that before but no luck
<sforshee> fairuz, that's too bad
<jjohansen> fairuz: hrmm, it should work I know I have used it with external modules, mind you that was years ago
 * ogasawara back in 20min
<fairuz> jjohansen: that's why..i wonder myself whhy it didn't work.
<sforshee> fairuz, I just tried it and it did work
<fairuz> sforshee: what did you try?
<sforshee> make -C /path/to/kernel M=$(pwd) INSTALL_MOD_PATH=/path/to/modules modules_install
<sforshee> fairuz, that installed my module to /path/to/modules
<fairuz> sforshee: it will install just the external module? and not the other kernel modules?
<sforshee> fairuz, yes
<sforshee> fairuz, note that if you use a relative path it will be relative to the kernel source directory, not your module source dir
<fairuz> sforshee: it will just move the files or it will compile and move the files
<jjohansen> fairuz: it should set the compiler to write the files to the target location
 * jjohansen has used it in the past for source trees that were read only
<fairuz> I use this -> make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -C /home/x0152532/kernel-src M=/home/x0152532/remote-x0152532/tools/caches/pl310 INSTALL_MOD_PATH=/home/x0152532/remote-x0152532/tools/caches/pl310/bin modules_install
<sforshee> jjohansen, fairuz, just using the modules_install target didn't build for me, I had to do the modules target as well
<fairuz> and it installs lib/modules directory in my target folder
<fairuz> and no sign of my own modules
<sforshee> fairuz, see my comment above, you'll have to do a 'make modules' first
<sforshee> in my testing anyway
<sforshee> and that will build to your local directory
<sforshee> unless you use O=...
<fairuz> sforshee: done that
<sforshee> fairuz, don't know what to say, it installs my module
<fairuz> sforshee: in your case, it did not install /lib/modules/kernel-name in your target folder?
<sforshee> fairuz, no, it does create lib/modules/..., and installs the module there
<fairuz> sforshee: ah ok i got what you mean
<sforshee> fairuz, if you want something different I guess you could make a custom target in your local makefile
<fairuz> sforshee: it puts the module in /lib/modules/kernel-name/extra/*
<sforshee> fairuz, yes
<fairuz> sforshee: hmm not really what i want actually.. 
<fairuz> I'm searching something like target-folder/mymodule.ko
<sforshee> fairuz, that may be the only thing the kernel makefile provides
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<fairuz> sforshee: there's O= too but unfortunately, it didn't work for me..will dig it out later
<fairuz> sforshee: jjohansen: btw, thanks for helping
<sforshee> fairuz, iirc O= puts all the build targets in that dir, which probably isn't what you want anyway
<sforshee> fairuz, np
<fairuz> sforshee: that's ok for be. As long as the source folder is clean :)
<fairuz> *me
<fairuz> jjohansen: if we make a package, it will create headers, image, and src package automatically ? 
<fairuz> or there is some work to do by hand
<jjohansen> fairuz: make a package how?
<fairuz> *.deb files
<fairuz> jjohansen: something like this https://launchpad.net/ubuntu/+source/linux-ti-omap4/2.6.38-1204.5/+buildjob/2313441
<jjohansen> fairuz: hrmm, I'm sure what you are doing to build, a package can create each of those
 * jj-afk steps away for 20
<fairuz> jjohansen: (i'm not really want to create packages, but just to fill my curiousity =))
<tgardner> ogasawara, do you remember if bug #630748 was on skaet's radar last week?
<ubot2> Launchpad bug 630748 in linux-firmware "iwlagn degrades quickly during normal wifi session" [High,Confirmed] https://launchpad.net/bugs/630748
<ogasawara> tgardner: it was
<tgardner> ogasawara, great, thanks.
<sforshee> tgardner, for the eeepc-wmi backports, is it best to base the branch for the pull request off of master-next ?
<tgardner> sforshee, that works, but its not critical.
<sforshee> tgardner, yeah, there probably aren't any differences between master and master-next for that file, I was just wondering
<sforshee> thanks
<tgardner> sforshee, the advantage of using master is that it gives you a stable merge point, whereas master-next often gets rebased. however, small pull requests aren't that hard to figure out.
<ppisati> sconklin: you are welcome :)
<bjf> ##
<bjf> ## Kernel team meeting in 30 minutes
<bjf> ##
<maks_> dudes your meeting is finished before one has time to follow it
<maks_> wanted to raise debian drm tree sync
<maks_> :P
<maks_> 2.6.32.y-drm33.z.git misses some of our stuff.
<ogasawara> smb: ^^
<smb> maks_, Ah yes
<smb> I think it was mentioned that you had some drm things. Do you have a git tree I can pull from?
<maks_> yes mirror didn't change
<maks_> http://git.debian.org/?p=kernel/linux-2.6.git;a=summary
<bjf> maks_, you can always request to get something on the meeting agenda
<maks_> I was just to slow and got distracted in middle of the meeting, thanks bjf 
<smb> maks_, Thanks, I was about to ask cause I tend to forget
<bjf> maks_, if you blink, we are gone
<maks_> ok cool.
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Natty Kernel Version: 2.6.38 (Kernel Freeze - April 14) || Ubuntu Kernel Team Meeting - March-29 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<bjf> ogasawara, the April 14 freeze date, is that when you'll upload or the last day we put changes into the repo ?
<ogasawara> bjf: ideally, we'll make no changes to the kernel past that date, which means we'd have to upload ~2days prior for the builds to finish by the 14th
<ogasawara> bjf: we can still apply changes, they'll just be subject to SRU
<ogasawara> bjf:  but there's no guarantee that those changes will warrant another upload
<bjf> ogasawara, right, i'm just thinking that one way of thinking is that the code is actually frozen on the 12th
<ogasawara> bjf: yep
<JFo> headset died
<JFo> thanks pgraner :)
<JFo> <-need food
 * jjohansen -> lunch
<tgardner> kees, sconklin, I think we're OK to release Hardy. HPPA LBM hasn't built since 2.6.24-19.17 (2008-10-27). Clearly nobody cares.
<sconklin> tgardner: bwahahaha ok
<sconklin> why haven't we seen  the fails indicated in the PPA builds?
<tgardner> sconklin, this should _never_ have taken me so long to figure out. maybe I need ritalin.
<tgardner> sconklin, https://launchpad.net/ubuntu/+source/linux-backports-modules-2.6.24/+publishinghistory
<sconklin> well, now we know whether anyone cares
<tgardner> sconklin, as it turns out, compat-wireless has never built on HPPA. dunno why we didn't notice it in c-k-t PPA. I'll upload a new package here in a bit.
<tgardner> my test build on wongi seems to be completing
<tgardner> sconklin, [PPA canonical-kernel-team] [ubuntu/hardy]	linux-backports-modules-2.6.24 2.6.24-29.41 (Accepted)
<sconklin> ok, lbm builds fast, so we should know soon
<tgardner> sconklin, I'll check back in a couple hours.
<sconklin> no hurry I think
 * ogasawara back on later
<beata|lemur> Oh hey guys. I don't suppose there's a way from the user side to tell if pcrypt is doing its job? Or, does it need to be loaded *before*?
#ubuntu-kernel 2011-03-30
<^AndreA^> Hi everyone
<^AndreA^> sometimes (when I transfer big files) my Ubuntu freezes...
<^AndreA^> just before doing that it logs some errors in the messages and kern.log logs (that's why I'm here) :-)
<beata|lemur> Freezes *hard* or just turns into molasses? I'm just a user these days, I'm afraid.
<^AndreA^> it simply stops responding...
<^AndreA^> and needs to be turned off manually....
<^AndreA^> I was wondering if anyone could help me "translating" those messages to English... LOL
<^AndreA^> something like:
<^AndreA^> ata8.00: failed command: READ FPDMA QUEUED
<^AndreA^> ata8.00: status: { DRDY }
<^AndreA^> ata8: hard resetting link
<^AndreA^> ata8: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
<^AndreA^> etc etc...
<^AndreA^> any idea anyone?
<^AndreA^> if i limit the transfer (eg: rsync --bwlimit=xyz) the computer works fine...
<^AndreA^> maybe if I'm in the wrong chat someone could also direct me to the right one...
<beata|lemur> I'm unsure myself, but it sounds more of a hardware issue than a driver one.
<^AndreA^> for SMART the disk seems to be fine...
<^AndreA^> this error says "host bus error"
<^AndreA^> res 40/00:04:49:21:3d/00:00:01:00:00/40 Emask 0x32 (host bus error)
<^AndreA^> I've also thought it might be the SATA cable...
<^AndreA^> even though that one should always work or not...
<^AndreA^> it shouldn't be something random...
<rsalveti> can someone help updating the natty meta package for ti-omap4?
<rsalveti> latest kernel available is 2.6.38-1207.10, that was published at march 26, but meta still needs an update
<rsalveti> meta is using Ubuntu-2.6.38.1206.5
<rsalveti> cooloney: ^
<rsalveti> apw: ^ :-)
<cooloney> rsalveti: ok, i will take a look at it
<rsalveti> cooloney: thanks!
<cooloney> rsalveti: or let apw and rtg know that
<cooloney> rsalveti: np, man
<cooloney> rsalveti: it's time for you to go to sleep
<rsalveti> cooloney: yeah, going afk now :-)
<fairuz> morning
<ogra_> apw, is anyone working on the meta update for omap4 ?
 * ogra_ sees you were pinged above for it 
<cooloney> ogra_: i'm working on that. 
<smb> ogra_, That apw is only virtual (bip)
<smb> The real one is on holiday. :)
<cooloney> ogra_: will try to ping rtg to update 
<cooloney> smb: hehe, yeah, long time no chat, man
<cooloney> how's going
<smb> cooloney, Not too bad. :) Beside all the winching about xen. :-P
<smb> cooloney, Are you doing well?
<cooloney> smb: cool, so you do like the word "virtual" now
<cooloney> smb: i'm very good, thx. 
 * cooloney gonna out for an early dinner. 
<ogra_> smb, cooloney-afk, ahh, thanks !
<ogra_> tgardner, !
<tgardner> ogra_, dude
<ogra_> we are in the pretty urgent need of an omap4 meta for the beta images 
<ogra_> would you mind uploading one ? :)
<tgardner> ogra_, checking. I thought I had.
<tgardner> ogra_, indeed, you're right.
<ogra_> :)
<tgardner> ogra_, [ubuntu/natty] linux-meta-ti-omap4 2.6.38.1207.6 (Waiting for	approval)
<ogra_> thanks
<ogra_> i'll care for the rest
<rsalveti> cool
<ogasawara> sweet, 2.6.39-rc1.  /me gets ready to open the O tree
<tgardner> ogasawara, did you get a chance to use bjf's create-cve-tracker tool?
<ogasawara> tgardner: I did when I was previously working some cve's
<ogasawara> tgardner: has it changed recently?
<tgardner> ogasawara, no, but its had many improvements since I last used it. its pretty handy.
<doko> ogasawara: please could you have a look at https://launchpadlibrarian.net/67694047/buildlog_ubuntu-natty-i386.linphone_3.3.2-3ubuntu1_FAILEDTOBUILD.txt.gz
<doko> linux/videodev.h not found
<doko> I did see something similiar in xine-lib and just disabled something in the build. but is this really expected?
<ogasawara> doko: looks correct, linux/videodev.h doesn't exist.  I suspect it should be linux/videodev2.h
<Sarvatt> doko: http://www.mail-archive.com/linux-media@vger.kernel.org/msg27519.html
<doko> Sarvatt: could you care about this build failure?
<cooloney-afk> tgardner: hey tim, could you please update the natty meta package to use our latest 1207.10 ti-omap4 release?
<tgardner> cooloney-afk, it was upload a couple of hours ago. 2.6.38.1207.6	 release (main)	 1 hour 50 minutes ago
<cooloney> tgardner: ah, great, thx. i'm just back to home and forget to ping about that before i left for dinner
<tgardner> cooloney, ogra_ is trying to build some release iamges from it as we speak
<cooloney> tgardner: actually i tried to update meta package myself before you are online, but not sure about how to do that
<tgardner> cooloney, it takes a special kind of magic.
<cooloney> tgardner: so for this mapping, need i just an entry at debian/changelog file?
<tgardner> cooloney, yep. I use 'dch -i' to start the entry.
<cooloney> tgardner: yeah, it is, because i just saw an entry in every git commit log
<tgardner> cooloney, the meta packages don't have as much infrastructure in the rules file as the rest of the kernel packages. its much simpler
<cooloney> tgardner: interesting, how does the system know the kernel mapping? just get that info from the changelog file? 
<tgardner> cooloney, the binary packages are constructed using the ABI which is extracted from the changelog.
<cooloney> tgardner: so just adding an entry in changelog is enough, right? magic to me
<cooloney> and it looks like this:
<cooloney> linux-meta-ti-omap4 (2.6.38.1206.5) natty; urgency=low
<cooloney> +
<cooloney> +  * linux-ti-omap4 2.6.38-1206.7
<cooloney> +
<cooloney> + -- Tim Gardner <tim.gardner@canonical.com>  Thu, 24 Mar 2011 06:33:55 -0600
<cooloney> tgardner: oh, i think you didn't update the natty-meta tree in our git server
<tgardner> cooloney, you're right. lemme check whats there 'cause its clashing when I push
<cooloney> tgardner: no worries, as long as ogra_ got what he want, -:)
<tgardner> cooloney, well, I do have to get the repo consistent
<tgardner> cooloney, uh, it helps if I push the right branch. all up to date now.
<cooloney> tgardner: great, i got updates now, thx
 * cooloney is going to sleep.
<JFo> <-need food
<JFo> bbiab
<kristian-aalborg> jjohansen: hey
<jjohansen> ki kristian-aalborg
<kristian-aalborg> I was thinking of something... would you perhaps be interested in putting together a tutorial for the procedure I'm trying to do? 
<kristian-aalborg> I'm planning to start a website about using old laptops for this and that ;)
<bjf> brb
<jjohansen> kristian-aalborg: hrmm, I'm not sure what there is to add on the current procedures, but if they aren't sufficient then I will definitely do some updating
<kristian-aalborg> I'd say the whole "build from (tweaked) old config" guide is missing
 * bjf -> lunch
<jjohansen> -> lunch
<bekks> hi
<bekks> I'm here cause I'm supporting a "case" in #ubuntu-de - someone has a SAS attached LTO4 tape drive, which doesnt show up neither in lsscsi, nor in /dev/*mt*, BUT has an entry in /dev/sg*
<bekks> Ubuntu version is 10.10 32bit, using the .35-28 kernel.
<bekks> Any suggestions on how to debug this further?
<bekks> If needed, I have his dmesg and lspci outputs handy on nopaste.
<tgardner> bekks, start a bug report from the affected machine using 'ubuntu-bug linux'. that way we can capture some dmesg info
<JFo> you just did beat me to it tgardner-server- 
<JFo> :)
<bekks> dmesg is this one: http://paste.pocoo.org/show/362851/
<bekks> lspci is this one: http://paste.pocoo.org/show/362856/
<bekks> Still needing the ubuntu-bug?
<JFo> yep
<bekks> Ok.
<BenC> mptsas...never a good start to a bug report
<bekks> Thats what I feared...
<bekks> Ah, there he is. Hi northalpha 
<northalpha> hi all
<bekks> northalpha: You're already on working out the "ubuntu-bug linux"
<northalpha> working, bu unsure which catergory
<bekks> Not having it handy - I guess something like "hardware" would be ok.
<northalpha> Choices:   1: Audio   2: Filesystem   3: Graphics   4: Kernel Config   5: Networking   6: Hibernate/Resume   7: Suspend/Resume   8: Other   9: I don't know   C: Cancel 
<bekks> I'd choose 4 then.
 * BenC wonders why "storage" isn't a choice
<bekks> or 9.
<northalpha> dont want to fill in a bug report wrong
<northalpha> A bug is considered a regression if the issue did not exist on a previous kernel.  Is this a regression?
<northalpha> yes or no
<bekks> no
<bekks> Since we dont know that for sure.
<northalpha> ok
<northalpha>   https://bugs.launchpad.net/ubuntu/+source/linux/+filebug/0929f4fc-5b03-11e0-9b98-002481e7f48a? 
<bekks> Thankyou
<bekks> JFo: done :)
<JFo> danke
<northalpha> hopefully i did niot mess it up
<northalpha> =) my first bug report
<northalpha> if it s a bug
<JFo> bekks, got a bug number?
<bekks> Just one moment - I'm completing the report.
<northalpha> thanks m8
<JFo> ah, ok :)
<bekks> northalpha: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/745981 please read the comment I created and do as you are told there :)
<ubot2> Launchpad bug 745981 in linux "Quantum Ultrium LTO4 tape drive not recognized" [Undecided,New]
<northalpha> ok will add files
<northalpha> have to create an account?
<bekks> I guess so, yes.
<bekks> No, it's free, and you won't get a fridge delivered.
<bekks> northalpha: After you created an account, please give me your launchpad nick, so I can ask for changing the owneship onto your account.
<northalpha> ok guys, no fridge, its ok ;) files uploaded
<northalpha> bekks: <--
<bekks> perfectly :)
<bekks> I guess, now you can just follow the progess of that bug.
<northalpha> ok thanks if you need something, i will try to help
<northalpha> but i am far away from pro
<JFo> brb, need to take an eye break
<MeanEYE> Did someone test 2.6.38? Does it really bring that many improvements from users point of view?
<bekks> I did, yes it did. :)
<bekks> It eliminated some asymc I/O bugs regarding ext4/xfs, it supports automatic cgroup scheduling.
<MeanEYE> Can I just download it, compile and use it? Or is there a drawback to that. :)
<tgardner> MeanEYE, subscribe to https://launchpad.net/~kernel-ppa/+archive/ppa and get the backport.
<MeanEYE> Whoa, thanks. :) <3
<MeanEYE> Hm, am using Maverick, can I install that? 
<tgardner> MeanEYE, yeah, it'll install just fine.
<MeanEYE> Can you tell me which package to install?!
<tgardner> sudo apt-get install linux-image-server-lts-backport-natty
<tgardner> or generic, whatever you prefer
<MeanEYE> Ok thanks.
<MeanEYE> Nope, no such package. Nvm, I'll just wait for Natty. Thanks anyway.
<kees> where is /usr3 on tangerine go?
<Sarvatt> kees: I still see it?
<sforshee> kees, are you in a chroot ?
<kees> AARGH
<kees> sforshee: yeah, durr. thanks
<Sarvatt> I do that at least once a week :P
<sforshee> I've started doing all my clones from /home/usr3 so I can do pulls from inside chroots
<kees> ah-ha, smart. I'll have to switch to that.
<Sarvatt> well try to scp kernels from tangerine onto zinc from inside a chroot
<slangasek> ogasawara: hi, I see that at least one bug has been fix-committed for the kernel in natty; is there a post-beta upload schedule for the kernel packages?
<slangasek> I'd be interested to see if we could get linux-libc-dev made multiarch-safe before release, since this needs to be fixed before any other work on multiarch cross-compilation can go forward
<slangasek> (I would request a separate FFe for this)
<kristian-aalborg> what would the minimum requirements be for running screen + ncmpcpp?
<kristian-aalborg> I'm getting a machine with 96 MB of ram tomorrow
<bryceh> hey what was the outcome of all the hybernate support discussions?  Do we still support it or should we be wontfix'ing hibernate graphics bugs now?
#ubuntu-kernel 2011-03-31
<Kano> hi, could somebody add the new r8169 firmware for .39?
<jj-afk> running errands back in a bit
<ogasawara> slangasek: hi, I plan to do another kernel upload on this friday.  I suspect we'll have at least 1-2 more uploads past that up until kernel freeze on april 14th.
<slangasek> ogasawara: ok, thanks - I'll pass that on to wookey who's working on linux-libc-dev
<skaet> JFo, ogasawara - interesting one from tonights scan through the beta bugs... https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/745947
<ubot2> Launchpad bug 745947 in debian-installer "Fails to display video after grub (kernel lacks video output)" [High,New]
<smb> cking, Good morning. Has the noise and dust ceased? :)
<cking> smb, not quite - windows being fitted as we speak 
<smb> cking, Oh no, you got Windows into the house! (quite lame I know)
<cking> de da
<cking> At least I don't need any service packs
<smb> That is what you think now. :-P
<_ruben> unless you about painting and stuff yourslef, you'd need a service pack ;)
<_ruben> (typing over a high latency connection sucks)
<tgardner> ugh! speaking of patch bombs. 2.6.35.12 has 275 patches.
<tgardner> ogra_, how is ti-omap4 going? did you get your image constructed with the new kernel?
<ogra_> tgardner, yep, all fine, the beta is already being pre-published
<ogra_> tgardner, thanks for the quick fix
<tgardner> ogra_, did it solve many of the bugs that are outstanding? or do you know yet?
<ogra_> well, the highest outstanding one is still the highmem issue, thats not solved, but it adds a proper HDMI driver again
<ogra_> we are still waiting for userspace fixes for sound, kernel wise it should be fine though
<ogra_> beyond that i think all hardware kind of works now with that kernel
<tgardner> ogra_, ok. pgraner was just mentioning to me that there are a number of outstanding bugs that we should follow up on
<ogra_> oh, i dont know which ones he refers to then
<ogra_> do you have a list ?
<ogra_> and is that natty or maverick =
<ogra_> ?
<tgardner> ogra_, he mentioned something about iso tracker.
<tgardner> natty (AFAIK)
<pgraner> ogra_, https://bugs.launchpad.net/bugs/746133
<ubot2> Launchpad bug 746133 in linux-ti-omap4 "Video loses sync on omap4" [Undecided,New]
<pgraner> https://bugs.launchpad.net/bugs/746137
<ubot2> Launchpad bug 746137 in linux-ti-omap4 "Page allocation failure on omap4" [Undecided,New]
<pgraner> https://bugs.launchpad.net/bugs/651302
<ubot2> Launchpad bug 651302 in alsa-lib "No sound in omap (beagle, beagleXM)." [Low,New]
<ogra_> 746133 ... heh, the .38 kernel uses the .35 driver now, so the bug was forward ported alongside i think
<pgraner> ogra_, they were reported against beta1
<ogra_> pgraner, trhe alsa-lib one is the bit i mentioned above, no kernel bits involved anymore
<ogra_> we're waiting for alsa-lib and pulse fixes from TI for that
<JFo> I iz back
<JFo> skaet, that is an interesting bug
 * skaet glad Jfo finds it interesting....   and glad pgraners forward on the other interesting ones too.  :)
<JFo> skaet, well, 'interesting' in a "I have no idea what to do with it." way ;-)
<skaet> :)
<tgardner> ogasawara, the archive has thawed. you could fire up a kernel today (just to keep the mirrors busy)
<ogasawara> tgardner: cool, I'll get it goin
<tgardner> ppisati, do you have the right HW to help debug natty ti-omap4 issues?
<tgardner> GrueMaster, isn't there an ARM enablement team to which you ought to subscribe the omap4 bugs you're filing?
<tgardner> ah, ubuntu armel porters
<GrueMaster> tgardner: I usually do when I go through and triage.  I hardly ever triage when filing bugs during release testing.
<tgardner> GrueMaster, thats a fine distinction that is lost on me
<GrueMaster> Ubuntu-armel-porters is usually added to the subscribed list.
<GrueMaster> Try testing 8 images on 2 different very slow platforms in one day and you will understand why I didn't add them
<tgardner> ogra_, since you administer Ubuntu-armel-porters, how about adding Paolo Pisati and Bryan Wu ?
<ogra_> i do ?
<ogra_> hmm, sure, np
<tgardner> ogra_, you are listed as an admin
 * ogra_ wonders why cooloney isnt in that team 
 * tgardner does as well
<ogra_> not that it has any use though apart from bugmail subscriptions 
<ogra_> added both
<tgardner> I'm convinced that they don't get enough bug mail
<ogra_> haha
<ogra_> i could subscribe them to unity-2d, that generates about 50-100 per day
<tgardner> ogra_, thats probably not necessary :)
<tgardner> ogasawara, I'm also working on getting linux-backports-modules-2.6.38 NEWed
<tgardner> I wonder if Clint can do that now?
<ppisati> tgardner: yep, panda is ti-omap4
<tgardner> ppisati, I've gotten you subscribed to a couple of omap4 natty bugs
<ppisati> tgardner: k
<ppisati> GrueMaster: any tickets in particular?
<tgardner> ppisati, bug #746137
<ubot2> Launchpad bug 746137 in linux-ti-omap4 "Page allocation failure on omap4" [High,New] https://launchpad.net/bugs/746137
<tgardner> bug #746133
<ubot2> Launchpad bug 746133 in linux-ti-omap4 "Video loses sync on omap4" [Undecided,New] https://launchpad.net/bugs/746133
<GrueMaster> tgardner: Those are the most recent bugs.
<GrueMaster> I'll have to dig a little to see if there are others.  We just had this kernel dumped in last minute for release testing, so I haven't had a chance to do thorough testing yet.
<ppisati> lp653002 and lp746133 look very similar
<rsalveti> ppisati: it's probably the same one, but the newer happens with 38
<rsalveti> and the new hdmi driver 
<rsalveti> at that time we closed for natty because we were still using 35
<ppisati> rsalveti: how to reproduce it? because with xperf -copywin i don't get the "omapdss DISPC error: GFX_FIFO_UNDERFLOW, disabling GFX"
<rsalveti> ppisati: from current discussion at linaro it seems to be related with pm
<rsalveti> and cpu frequency scaling
<rsalveti> ppisati: bug 732912
<ubot2> Launchpad bug 732912 in linux-linaro-omap "omapdss DISPC error: GFX_FIFO_UNDERFLOW" [Undecided,Confirmed] https://launchpad.net/bugs/732912
<rsalveti> also happens with omap 3
<rsalveti> ppisati: interesting that you're unable to reproduce with xperf -copywin
<rsalveti> that didn't happen even with 35
<ppisati> rsalveti: FWIW i can't even do cpu scaling :)
<ppisati> flag@flag-desktop:~$ uname -a
<ppisati> Linux flag-desktop 2.6.38-1207-omap4 #10 SMP PREEMPT Thu Mar 31 18:12:49 CEST 2011 armv7l GNU/Linux
<rsalveti> ppisati: yeah, just noticed it's not activated at our kernel
<rsalveti> so the omap 3 bug is probably not related with this
<rsalveti> ppisati: were you able to hit this issue at least once?
<rsalveti> I'm not, and I'm using my panda for days
<ppisati> rsalveti: just booted this kernel
<ppisati> rsalveti: tried with xcopywin but no blank
<rsalveti> GrueMaster: what did you do to hit this bug?
<ppisati> rsalveti: letf it there, idle, screensaver kicked in, but i can resume it
<tgardner> ogasawara, Natty LBM is NEWed. do you suppose the dep-wait gizmo will work if you just upload LBM before the kernel headers are built?
<GrueMaster> rsalveti: I was hitting it while filing a bug report on it.
<ppisati> rsalveti: i'll leave it there a bit, let's see
<ppisati> perhaps it's really connect to pm and cpu scaling
<GrueMaster> Monitor directly plugged in.
<ppisati> since we don't have it
<ogasawara> tgardner: no idea
<kamal> when might we expect the ubuntu-oneiric.git repo to be created?  (I can haz 2.6.39 now? ;-)
<ogasawara> tgardner: I can give it a try though
<tgardner> kamal, patience lad, she's working on it.
<ogasawara> kamal: I'm half way through getting it created
<tgardner> kamal, but I keep bugging her to do other stuff.
<kamal> ogasawara: thanks very much :-)
<kamal> tgardner: well quit it!
<tgardner> kamal, can;t help it. I'm just naturally annoying.
<ogasawara> wasted the better have of yesterday and this morning figuring out that some of the reverts didn't completely revert the original patch, but have that fixed up and am on track again now.
<rsalveti> ppisati: but the omap 3 one is related with the ondemand governor 
<rsalveti> and we're probably already using full speed
<rsalveti> but something we should check, I'm not that sure
<ogra_> rsalveti, heh, define full speed
<ogra_> we wanted to push XM to 1GHz and i dont think we did 
<rsalveti> ogra_: not xm, panda
<ogra_> ah, you mentioned omap3 above
<ogra_> omap4 runs at full speed 
<rsalveti> yeah, but was also talking about the omap 4 issue
<rsalveti> that's something I'm not yet sure 
<rsalveti> I mean, the cpu seems to be running at full speed
<rsalveti> but don't know about the rest, like the bus that could affect the video
<ogra_> ah
<ogra_> yeah, that makes sense
<ogasawara> tgardner: lbm uploaded, we'll see what happens
<tgardner> ogasawara, indeed, I see 2.6.38.2 has a bunch of ath9k goodness, so I think I'll update compat-wireless for Lucid/Maverick.
<tgardner> plus some mac80211 stuff
<ogasawara> tgardner: cool, I was also going to strip natty lbm of the older cruft like compat-wireless-2.6.37 etc.
<tgardner> ogasawara, ack
<ogasawara> tgardner: hrmph, "Rejected:
<ogasawara> The signer of this package is lacking the upload rights for the source package, component or package set in question."
<tgardner> ogasawara, bummer. guess I can do it, or you can annoy cjwatson about it.
<ogasawara> tgardner: I suspect it needs to be added to the right ACL's before I can pull the trigger, I'll ping cjwatson
<tgardner> ogasawara, k, lemme know
<ogasawara> tgardner: upload issue is fixed
<tgardner> ogasawara, cool
<slangasek> tgardner: hi, I just noticed that the change for bug #663090 has the effect of raising not only the hard limit for NOFILE, but also the soft limit, and the latter isn't wanted; for the moment the impact is minimal because pam has to shadow these defaults anyway so I can selectively fix up for purposes of user sessions, but how can we fix the kernel default too?
<ubot2> Launchpad bug 663090 in linux "Please raise file descriptor hard limit to 4096 (but keep soft limit at 1024)" [Medium,Fix released] https://launchpad.net/bugs/663090
<slangasek> technically this bug is not fixed because both hard and soft limits are now at 4096 :)
<tgardner> slangasek, um, I though that was just the hard limit.
<slangasek> tgardner: asm-generic/resource.h:
<slangasek>         [RLIMIT_NOFILE]         = {       INR_OPEN,       INR_OPEN },   \
<tgardner> oops.
<tgardner> lemme look closer
<slangasek> ok 
<tgardner> slangasek, how are these numbers used in practice? In the kernel the limits really have no impact as far as initial memory allocation.
<slangasek> tgardner: if your process is at the limit, you cannot open another fd
<tgardner> I guess I'm wondering the difference between soft and hard
<slangasek> the process itself can adjust the soft limit
<slangasek> the hard limit is a hard limit that only root can adjust
<slangasek> well, that only root can /raise/ - you can lower your own hard limit
<slangasek> so we want these limits to be different because 1024 is a safe default for all processes, but some processes need to opt in to using more fds
<slangasek> in this case the soft limit is a safeguard to protect processes from themselves when they don't know what to do with that many fds, rather than a resource limit
<tgardner> slangasek, ok, makes sense. I suspect the 2 entries in that structure imply hard and soft limits. do you think the soft limit should be proportional to hard, e.g., INR_OPEN/2 ?
<slangasek> I dimly recall that there are some old userspace paradigms that assume 1024 is the max number of fds they ever need to care about, so a hard-coded value of 1024 is probably best
<slangasek> heh, when I say "I dimly recall", it's written in the first line of the bug description :)
<tgardner> slangasek, ok, I'll fix it as soon as I can drill into the bizarre macro depths used to init this struct
<tgardner> ok, found it
<tgardner> ogasawara, so, I'm gonna squash 0ad40e118007ff770e2479f5afcdb9103782b4ba and the update to INR_OPEN into one patch so that we're not carrying 2 SAUCE patches for the same fix. you cool with that? you'll just have to remember the next time you rebase master-next.
<bdmurray> I ran across bug 745511 and did a quick search of oops reports and found ~40 similar ones.  Would it help and be correct to consolidate them?
<ubot2> Launchpad bug 745511 in linux "WARNING: at /build/buildd/linux-2.6.38/drivers/gpu/drm/radeon/radeon_fence.c:248 radeon_fence_wait 0x36f/0x3e0 radeon " [Undecided,New] https://launchpad.net/bugs/745511
<ogasawara> tgardner: cool, works for me
<tgardner> ogasawara, k, just pushd +master-next
<tgardner> must have food
<bjf> SURGEN GENERAL WARNING
<bjf> The following reports can induce depression:
<bjf>    http://people.canonical.com/~kernel/reports/regressions-update-report.html
<bjf>    http://people.canonical.com/~kernel/reports/regressions-release-report.html
<bjf>    http://people.canonical.com/~kernel/reports/regressions-potential-report.html
<bjf> .
<bjf> the last column "C" is time from last update the last comment was added
<bjf> the age column is time from last update the bug was created
<bjf> the date text in those columns is: days.hours.minutes   so 5.1.13  is 5 days, 1 hour, 13 minutes ago
<bjf> note: if you hold down the shift you can sort using multiple columns
<bjf> .
<bjf> These are in addition to:
<bjf>    http://people.canonical.com/~kernel/reports/sru-report.html
<bjf>    http://people.canonical.com/~kernel/reports/versions.html
<bdmurray> bjf: just an fyi I have a script that retags bugs tagged natty and regression-update to regression-release
<bjf> bdmurray, good to know, right now i'm just trying to formulate my attack plan
<bdmurray> bjf: I was thinking the apport hook could use an SRU removing regression-potential as an option for Maverick and earlier
<bjf> bdmurray, agreed, we should not be creating any more of those
<bdmurray> also I'm not really sure it makes sense to tag apport-package bugs a regression
<mdz> I just resumed from suspend, and it was very slow, lots of disk activity, and I noticed a whole bunch of kworker kernel threads running
<mdz> any guesses what this means?
<tgardner-lunch> mdz, natty? I was just reading an LKML discussion from Dave Jones complaining about something similar.
<mdz> tgardner-lunch, yes, natty
<mdz> tgardner-lunch, I saw a thread on lkml about worker threads with dave jones in it, but they were talking about them consuming a lot of CPU
<mdz> mine are all idle, but there are 92 of them
<mdz> hmm, looks like they've started to die, it's down to 10
<mdz> dmesg is quiet, no indication of what they were doing
<tgardner> mdz, hard to say what was going on. how many worker threads? should only be one per hyper-thread.
<tgardner> 92, nm
<tgardner> I'm also thinking of kswapd
<mdz> I seem to be using a lot of swap (1G)
<tgardner> mdz, does slabtop show anything interesting?
<mdz> tgardner, hmm, I've never used slabtop before. I wonder what's interesting
<mdz> biggest thing is ext4_inode_cache at nearly 200M
<tgardner> mdz, excessive consumption of memory indicating a possible application leak
<mdz> http://paste.ubuntu.com/587937/
<tgardner> mdz, mine is about 54M
<tgardner> mdz, how about 'top' with meminfo
<mdz> shutting down chromium freed 500M of the swap
<tgardner> ah, kind of a hog
<mdz> top (now) says:
<mdz> Mem:   3065212k total,  1923540k used,  1141672k free,    55888k buffers
<mdz> Swap:  2955924k total,   567932k used,  2387992k free,   695928k cached
<mdz> wow, it actually freed 1G of memory too
<tgardner> seems like it might have a leak
<mdz> maybe time to give firefox 4 a chance
<tgardner> mdz, how many tabs did you have open?
<mdz> tgardner, maybe 25?
<mdz> there were 31 chromium processes running
<tgardner> mdz, it just seems like 92 kworker treads is a lot
<tgardner> thread*
<mdz> tgardner, could a memory shortage account for the kworker threads somehow
<mdz> ?
<tgardner> mdz, not the number of threads, just the activity under low mem pressure (I think)
<tgardner> I'd think the number of threads is proportional to the number of tabs
<mdz> tgardner, closing chromium didn't cause any kworkers to go away (once things were calmed down to 10 of them)
<tgardner> mdz, confused. you said there were 92, now there are 10, right?
<mdz> tgardner, shortly after resume, there were 92. after I came on here and started talking about it, I went back to count them, and there were only 10 running (I used scrollback to count the 92)
<mdz> so most of them exited on their own apparently
<tgardner> mdz, dunno, maybe chromium was firing up worker threads to refresh pages or something.
<JFo> jjohansen, are you around?
<jjohansen> JFo: yep
<JFo> do you have a moment to take a look at a bug for me?
<JFo> it is https://bugs.launchpad.net/ubuntu/+source/linux/+bug/746751
<ubot2> Launchpad bug 746751 in linux "kernel: [Firmware Bug]: the BIOS has corrupted hw-PMU resources (MSR 38d is 30)" [Critical,New]
<JFo> hggdh just pinged me about it
<jjohansen> ewww, just the discription is ugly
<JFo> if not, it can wait until tomorrow
<JFo> heh, yeah :-/
<JFo> thought maybe you would have some insight on it, or at least more than I have :)
<jjohansen> JFo: nothing off of the top of my head but it certainly looks to be a regression that we should be able to bisect
<JFo> ok, thank you for looking. I'll see about getting more eyes on it tomorrow
<JFo> well, I am off to grab some food... and perhaps a beer :)
<jjohansen> JFo: I'll poke a little, but I expect it won't be too hard to track down
<jjohansen> JFo: enjoy
<JFo> cool, thanks jjohansen :)
<JFo> I will try :-D
#ubuntu-kernel 2011-04-01
<cdbs> 3.12-1ubuntu5 of module-init-tools has produced a regression as it passess 11n_disable=1 to iwl3945 which the iwl3945 driver isn't able to recognize, as it doesn't support it at all
<fairuz> Hi morning
<fairuz> __raw_readl is used with pa or va?
<cdbs> Anyone around who can sponsor my debdiff?
<smb> cdbs, I don't think here. We rather work git oriented for the kernel. I'd probably try #ubuntu-devel
<cdbs> smb: :o
<smb> cdbs, Oh I see, module init tools
<cdbs> smb: bug #747059
<smb> cdbs, Sorry missed that in the scrollback
<cdbs> smb: sorry its bug #747025
<ubot2> Launchpad bug 747025 in module-init-tools "Modprobe passes 11n_disable=1 option to iwl3945 which doesn't support the option" [High,Triaged] https://launchpad.net/bugs/747025
<RAOF> Hm.  There appears to be an entirely blank Yes/No dialog box in the kernel's apport hookâ¦
 * RAOF guesses âyesâ
<smb> RAOF, maybe
<RAOF> Eat hot aufs kernel warning!
<smb> cdbs, The patch looks ok to me, but I do not seem to have the necessary rights to upload. But I will talk to the right person later today.
<qwebirc44173> hello
<qwebirc44173> need help to shutdown  the computer
<qwebirc44173> cpu and chassis fans keep spinning
<qwebirc44173> my motherboard is amd pc chips m810lmr
<qwebirc44173> im uusing ubuntu server 32bit
<qwebirc44173> i tried with pci=noacpi option un grub
<qwebirc44173> tried to disable apm/acpi in bios
<qwebirc44173> any tips?
<cdbs> smb: okay, thanks a lot!
<qwebirc44173> can anyone help me with my issue above
<smb> qwebirc44173, I sort of feel inclined to say pull the power cable... There is a lot of 32bit ubuntu server versions around too (hardy, lucid, ...). But you may try to look at /sys/power/disk. It should be either set to platform or shutdown and you may try the other one
<qwebirc44173> smb: happened the same xubuntu 10.04
<qwebirc44173> i could not shutdown completly
<qwebirc44173> smb: what do you mean with pull the power cable
<smb> qwebirc44173, That will surely stop the fans. Sorry I should have used sarcasm tags.
<qwebirc44173> :P
<qwebirc44173> i though it was just an expression
<qwebirc44173> thought
<soren> qwebirc44173: Like I already explained... Disabling ACPI is only going to make absolutely sure the machine won
<soren> 't shut down.
<qwebirc44173> soren: ei
<qwebirc44173> output of /sys/power/disk is test testproc [shutdown] reboot
<qwebirc44173> Why is shutdown between []
<smb> that is active
<qwebirc44173> hm?
<smb> Is that still a boot with disabled acpi?
<qwebirc44173> smb: what is active?
<qwebirc44173> yes
<qwebirc44173> i think
<qwebirc44173> let me reboot
<qwebirc44173> smb: it's using pci=noacpi
<smb> That would explain why there is now platform. I mean the option within [] is selected
<smb> I mean there is no platform
<qwebirc44173> smb: no platform to shutdown?
<smb> qwebirc44173, Platform would be the default on most machines, but that uses acpi methods, so if acpi is disabled I won't expect platform. Well actually without acpi and probably no apm there is hardly any way to shutdown automatically as soren told you
<qwebirc44173> smb: yes but i tried with those enabled
<qwebirc44173> before
<qwebirc44173> i dont know what else i can do
<qwebirc44173> im gonna try another distro
<smb> qwebirc44173, well I suspect rather another bios or a newer release/kernel... 
<soren> No matter what you do, if you keep disabling acpi, there's no way it's going to shut down.
<soren> If you can't turn on the lights in your hours, and you think it's due to the light switch, removing the light switch and shouting at the hole in the wall where it used to be isn't going to turn on your lights.
<soren> s/hours/house/
<soren> ..and moving into a different house, and removing all the light switches there will yield the same results.
<smb> soren, Still when people want to move I won't stand in front of the truck. :)
<_ruben> unless it uses apm (which is not tied into acpi, is it?)
<smb> _ruben, right, that would be independent. But it could be disabled in the bios or not implemented
<soren> _ruben: apm is a different system, yes. With its own set of problems. Like, say, not supporting SMP.
<soren> I seriously doubt is very well tested these days.
<qwebirc44173> smb: now I tried with everything enabled
<qwebirc44173> it still shows [shutdown]
<qwebirc44173> and wont turn off fans
<smb> IT sounds a bit like something is wrong with the acpi bios interface, but that is not something that can easily be solved on irc. You should file a bug report about it, and possibly see whether you can try newer kernels from the mainline builds.
<qwebirc44173> im gonna try acpi=force
<qwebirc44173> the bios supports APM and ACPI
<smb> you would see what is used in dmesg
<qwebirc44173> k
<qwebirc44173> smb: it's using IRQ
<smb> ??? most computers do... Without context this makes not much sense. 
<qwebirc44173> Allocate IRQ for PCI VGA yes
<smb> Really, it would be better to open a bug report with gathered info. Depending on release that is done with "ubuntu-bug -p linux" or without the need for -p.
<qwebirc44173> This is the exact problem that I have http://ubuntuforums.org/showthread.php?s=c9437dac0fddfb56461dc26eadd4fb11&t=1692877
<qwebirc44173> smb
<qwebirc44173> apm -s No APM support in kernel
<qwebirc44173> :O
<qwebirc44173> bah
<qwebirc44173> How do I enable APM support?
<qwebirc44173> need to know
<fairuz> qwebirc44173: you have CONFIG_APM=y in your kernel config?
<fairuz> or M
<qwebirc44173> it's M
<qwebirc44173> :\
<fairuz> ah it's a module
<qwebirc44173> how to change to y
<fairuz> qwebirc44173: just load it then? using modprobe?
<qwebirc44173> oh
<qwebirc44173> :)
<qwebirc44173> like sudo modprobe apm?
<qwebirc44173> fairuz: im not linux geek :)
<qwebirc44173> ill try
<fairuz> qwebirc44173: i'm not too. just a user
<qwebirc44173> fairuz: "Yes the kernel is not processing the APM command (advanced power management). Try this command as the root user: /sbin/modprobe apm."
<qwebirc44173> brb
<qwebirc44173> error
<fairuz> i don't know either, just giving ideas :D
<fairuz> take a look at this, maybe can give you some ideas
<fairuz> http://www.linuxquestions.org/questions/debian-26/no-apm-support-in-kernel-266977/
<qwebirc44173> FATAL: Module amp not found.
<qwebirc44173> through ssh
<qwebirc44173> from local machine is different but gives error
<fairuz> but do you know where they store this module?
<qwebirc44173> no idea
<fairuz> :D afaik, you have to know the path to use modprobe
<qwebirc44173> lolz
<fairuz> the path of the module of course
<qwebirc44173> Sometimes a Linux kernel is not configured properly for shutting down a computer properly. You can recompile the kernel to fix this problem.
<qwebirc44173> fail
<fairuz> search the path for the apm module
<fairuz> and load it from there
<qwebirc44173> modprobe apm FATAL: Error inserting apm (/lib/modules/2.6.35-28-generic-pae/kernel/arch/x86/kernel/apm.ko): No such device
<qwebirc44173> fail
<qwebirc44173> yea ikonia :) 
<qwebirc44173> fairuz need to know path :x
<smb> modprobe does not need a path, insmod would. But the reason for the module failing to load is only visible in dmesg. And even when loaded, at least that is how it used to be, apm will only be used when acpi is not active at all. And again using apm will take away other features only acpi has.
<qwebirc44173> smb: i dont care about acpi
<qwebirc44173> :p
<qwebirc44173> smb: ERROR: Module acpi does not exist in /proc/modules
<qwebirc44173> it's disabled right
<smb> No its build-in
<qwebirc44173> in motherboard?
<qwebirc44173> hmhmh
<qwebirc44173> like ac97 codec and stuff?
<smb> No into the kernel. But sort of into you motherboard too because its part of the bios
<fairuz> qwebirc44173: tried to modify grub and enable apm + disable apci from there?
<qwebirc44173> yes
<qwebirc44173> fairuz: acpi=off apm=on apm=power_off"
<qwebirc44173> and /etc/modules
<qwebirc44173> apm power_off=1
<fairuz> damn i forgot, what is the function to convert hexa in string (e.g. "0x68") to int? :D
<_ruben> "brain"
<smb> echo "ibase=16; 68"|bc ? :)
<fairuz> :D
<qwebirc44173> smb fairuz apm: BIOS not found.
<qwebirc44173> fail
<smb> tgardner, Did you do uploads to module-init-tools in the past? At least the changelog seems to say so...
<tgardner> smb, yes
<smb> There was a proposal fix here https://bugs.launchpad.net/ubuntu/+source/module-init-tools/+bug/747025
<ubot2> Launchpad bug 747025 in module-init-tools "Modprobe passes 11n_disable=1 option to iwl3945 which doesn't support the option" [High,Triaged]
<smb> It looked ok to me, but I believe I got no rights for that package
<qwebirc44173> smb: so linux cant work with my bios?
<tgardner> smb, for Natty? I just uploaded something a couple of days ago
<smb> tgardner, For natty, yes. It seemed newer that current bzr and apt-get source at least
<smb> qwebirc44173, It sounds at least like your bios does not provide the interfaces to enable apm at least.
<qwebirc44173> smb: there is an option to enbale
<qwebirc44173> enable
<qwebirc44173> :x
<qwebirc44173> it shows APM and ACPI
<smb> qwebirc44173, Just to make sure, have you checked with the mainboard vendor whether ther is any newer bios?
<qwebirc44173> smb: there is but im afraid to flash it
<qwebirc44173> :(
 * smb bites into his desk...
<qwebirc44173> smb: http://www.pcchipsusa.com/PCCWebSite/Downloads/ProductsDetail_Download.aspx?detailid=175&DetailName=New&DetailDesc=M810  (V7.1)&CategoryID=1&MenuID=82
<qwebirc44173> broken link
<qwebirc44173> not
<qwebirc44173> check this link pls http://www.pcchipsusa.com/PCCWebSite/Downloads/ProductsDetail_Download.aspx?detailid=175&DetailName=New&DetailDesc=M810  (V7.1)&CategoryID=1&MenuID=82
<smb> So the "newer" bios still is 2003... Quite old... Maybe you want to check out the firmware test suite to see how badly your current state is or is not...
<smb> https://launchpad.net/~firmware-testing-team
<smb> tgardner, So I would have a source deb, though I got no doubt that you probably have that done already by now
<tgardner> smb, pretty close to done.
<smb> tgardner, Yeah too slow is me
<Shred00> how come linux-source-2.6.32_2.6.32-02063212_all.deb has nothing in it except an empty ./usr/src/linux-source-2.6.32/ and a few ./usr/share/doc/ files?
<qwebirc44173> smb: sorry but how can I use firmware test
<smb> qwebirc44173, If you follow that link, there are PPAs for various releases. If you add the one for yours then you can apt-get install fwts and use the command of the same name
<qwebirc44173> smb: im going to use Firmware Test Suite (Maverick Stable)
<Shred00> where can i get the patches that were applied to the mainline 2.6.32.12 kernel?
<smb> Shred00, Hm, the separate patches started only later and I am pretty sure the kernel-source package was broken often. Maybe it works taking a 2.6.32.12 kernel and try to get the patches from http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32.20-lucid/ applied...
<Shred00> wouldn't it be closer to use 2.6.32.11-lucid's patches?
<Shred00> it's a real shame that i can't reproduce the mainline build exactly since it's that build that i need to start bisecting patches out of to find the breakage
<smb> Yeah. Funny why those are there
<qwebirc44173> smb: just sudo poweroff in archlinux
<qwebirc44173> it worked
<smb> qwebirc44173, Ok, so its something in the kernel between whatever version archlinux uses and Maverick. And maybe it is fixed in the kernel Natty uses.
<qwebirc44173> I hope so :)
<qwebirc44173> smb: maybe it's fixed in Lucid?
<qwebirc44173> smb: can I boot up using only cli in desktop livecd?
<smb> qwebirc44173, Not sure it works on the livecd but you may try to add "text" to the boot commandline
<qwebirc44173> will try
<smb> cd
<tgardner> ogasawara, have you tried natty this morning? my hp mini restarts gdm every time I touch the mouse.
<ogasawara> tgardner: I haven't, /me tries
<tgardner> cnd, you around? I see an xserver-xorg-input-synaptics upload this AM. I cannot correlate my GDM mouse crash, but it does look coincidental.
<cnd> tgardner, yes
<cnd> there was an upload last night
<cnd> it has a bug
<cnd> a new upload has been made
<cnd> it just needs to be built in the archive and published
<cnd> you can downgrade to a previous version for now
<tgardner> cnd, ah, known issue. good.
<cnd> tgardner, this is a temporary fix too: http://people.canonical.com/~cndougla/utouch/xserver-xorg-input-synaptics_1.3.99+git20110116.0e27ce3a-0ubuntu10~test1_i386.deb
<cnd> if you're running i386
<tgardner> ogasawara, did you catch that ? ^^
<ogasawara> tgardner: yep
<tgardner> cnd, amd64
<cnd> tgardner, ogasawara: https://launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/1.3.99+git20110116.0e27ce3a-0ubuntu8
<cnd> that's the previous version that works fine
<tgardner> cnd, ok, that fixes it.
<cnd> good
<tgardner> ogasawara, are there any show stoppers on skaet's kernel bug list?
<ogasawara> tgardner: not that I see
<skaet> tgardner, ogasawara - bug list not updated yet with input from yesterday.
<ogasawara> ah, so there may be some surprises
<skaet> will let you know as I do the processing if anything kernel specific makes the list that wasn't already there.
<tgardner> skaet, I'm going on last weeks search. there are still some linux bugs in there.
<skaet> there's a draft with today's date there
<skaet> just didn't link it to agenda
<skaet> however,  not all bugs are scrubbed, and pulled in from yesterday's triaging.
<skaet> has bugs from wednesday at bottom if you want to scan.
<tgardner> skaet, s'alright. there are plenty on the list I have that are worthy of cleanup.
<skaet> :)
<skaet> yeah, no shortage of things to work on, I'm sure.
<skaet> lol
<JFo> never is :)
<ogasawara> tgardner: I think the powerpc bug that you already applied the patches for was the only one that really caught my eye
<tgardner> ogasawara, yeah, that one was a real problem for older ppc platforms.
<ogasawara> tgardner: is apw back on mon or wed?
<tgardner> ogasawara, not sure. perhaps pgraner knows.
<pmatulis> can one do a net install with an LTS backports kernel?
<tgardner> pmatulis, only from the DVD bits
<pmatulis> tgardner: the DVD bits?
<pmatulis> tgardner: so no net install?
<tgardner> jjohansen, I just assigned you to bug #746751. can you see if you can diagnose it?
<ubot2> Launchpad bug 746751 in linux "kernel: [Firmware Bug]: the BIOS has corrupted hw-PMU resources (MSR 38d is 30)" [Critical,In progress] https://launchpad.net/bugs/746751
<tgardner> pmatulis, frankly, I'm not sure. Can you develop a net install from the DVD ?
<tgardner> pmatulis, the CD had no space.
<pmatulis> tgardner: ok.  btw, the DVD does not work in this regard for a server install
<tgardner> pmatulis, "does not work" ? what do you mean?
<pmatulis> tgardner: bug #730690
<ubot2> Launchpad bug 730690 in ubuntu-cdimage "10.04.2 DVD not made to allow server install with 2.6.35 kernel" [High,Fix released] https://launchpad.net/bugs/730690
<pmatulis> bug #730764
<ubot2> Launchpad bug 730764 in ubuntu-cdimage "10.04.2 DVD does not install server with 2.6.35 kernel when told to" [High,Triaged] https://launchpad.net/bugs/730764
<tgardner> pmatulis, well, shit. that was the whole point of the backport.
<pmatulis> :(
<tgardner> pmatulis, ok, they are on my todo list, though its likely an installer issue.
<pmatulis> tgardner: yeah, colin is looking at that
<tgardner> pmatulis, I wonder if we can release a 10.04.2.1 DVD ?
<pmatulis> tgardner: i asked colin the same.  no response yet
<tgardner> well, he _is_ kinda busy with the natty release.
<pmatulis> yes, absolutely
<JFo> tgardner, did you see that bug I showed jjohansen last night?
 * JFo digs for the #
<JFo> bug 746751
<ubot2> Launchpad bug 746751 in linux "kernel: [Firmware Bug]: the BIOS has corrupted hw-PMU resources (MSR 38d is 30)" [Critical,In progress] https://launchpad.net/bugs/746751
<tgardner> JFo, I just assigned it to him 15 minutes or so ago.
<JFo> ah :)
<tgardner> it came up in the release meeting
<JFo> I see that now :-D
<JFo> ok cool
<JFo> I thought it might
<tgardner> yeah, it seems like kind of a pisser
<JFo> yeah
<JFo> I just let it slip my mind earlier or I'd have asked right off
<tgardner> JFo, I keep a dynamic todo list. that way I only have to remember _1_ thing, look at my todo list.
<JFo> heh
<JFo> I do too, sadly it was toward the bottom
<JFo> not of importance, of course, just where I put it
<jjohansen> JFo, tgardner: ack.  I started poking but didn't get to far yesterday
<tgardner> jjohansen, thanks. this likely has overall priority until we make some progress on it. I think the server team is pretty well stuck.
<jjohansen> tgardner: axk
<jjohansen> ack even :)
<JFo> gonna grab some lunch, bbiab
 * tgardner is finding 2.6.23.12 quite tedious to apply. so damn many patches.
 * tgardner --> lunch
<tgardner> bjf, sconklin: pushed 2.6.35.12 stable update
<bjf> tgardner, whee!
<sconklin> \o/
<tgardner> bjf, checkout the patch list: http://bugs.launchpad.net/bugs/747520
<ubot2> Launchpad bug 747520 in linux "Maverick update to 2.6.35.12 stable release" [Undecided,Fix committed]
<sconklin> tgardner: jebus!
<bjf> tgardner, the good news is most of those already have some testing in other series
<tgardner> bjf, you mean the patches we already had? there were 12
<bjf> tgardner, no, many of those also hit Lucid already and have been tested there
<tgardner> bjf, ah, right
<bjf> .me -> food
 * bjf -> food
<ailo> I'm trying to debug the kernel. Never done this before. 
<ailo> These are the commands I've been instructed to use:
<ailo> sudo -s
<ailo> cd /sys/kernel/debug/tracing
<ailo> echo 0 > tracing_enabled
<ailo> echo wakeup_rt > current_tracer
<ailo> echo 1 > tracing_enabled 
<ailo> I'm wondering, how can I catch the output?
<ailo> Is it logged somewhere?
<manjo> ailo, are you using ftrace ? 
<ailo> manjo, What's that? I really don't much about this tbh.
<manjo> ailo, I guess you could start here http://lwn.net/Articles/289558/
<manjo> ailo, or Documentation/ftrace.txt in the kernel src 
<manjo> ailo, are you debugging a kernel oops ? 
<manjo> ailo, there is some debugging tricks here: https://wiki.ubuntu.com/Kernel/Debugging
<ailo> manjo, Thanks. I'm doing realtime testing for audio. Using jackd. I'm supposed to see what causes xruns.
<manjo> ailo, ftrace might be useful
<manjo> ailo, you might want to set CONFIG_DYNAMIC_FTRACE in your kernel 
<manjo> config
<ailo> manjo, It's set to =y. I'm on 2.6.38-7. Haven'
<manjo> ailo, you could search for Steven Rostedt's presentation on google he migh have a quick how to some place 
<manjo> ailo, he presented it at various conf and also demoed it .. so a video probably exists as well 
<vanhoof> wasnt there a tpm related s3/s4 issue that was fixed in the last couple of SRU updates?
<vanhoof> sound familiar to anyone
<tgardner> vanhoof, maverick?
<ailo> manjo, Great info. Thanks. I was only supposed to do this one thing right now, but I'll want to learn more anyway, so :P
<vanhoof> tgardner: yeah
<tgardner> vanhoof: glp v2.6.35..HEAD -- drivers/char/tpm8436f415bc7343a99b284661762456e697dae489 tpm_tis: Use timeouts returned from TPM
<tgardner> 9555b769cd6d973d6e84c805371eaa5d5986a25c TPM: Long default timeout fix
<tgardner> 123c6a0ede60b268266c3cce0c341f6427bc7044 tpm: fix panic caused by "tpm: Autodetect itpm devices"
<tgardner> 7d0809ee4b9eaaf7436e23c992aaebfc2408d782 tpm: Autodetect itpm devices
<tgardner> vanhoof, those are the stable updates.
<vanhoof> tgardner: cool let me check those out
<vanhoof> thanks tgardner 
<tgardner> np
<manjo> tgardner, looks like the patch that was SRUed and applied got dropped ? PM / Hibernate: Make default image size depend on total RAM size
<manjo> tgardner, or is it some other tree for maverick ?
<manjo> tgardner, it was applied around 03/18
<manjo> 03/21 rathr 
<tgardner> manjo, checking
<tgardner> manjo, 0a2fa938da1cc726477a3a94239132fe0973ae49 in master-next
<robbiew> tgardner: hey...have you all announced the chosen kernel for 11.10 yet...or is that something normally done at UDS
<manjo> tgardner, ah see it!
<tgardner> robbiew, oh, we won't know for sure by then. it'll be an educated guess at best.
<manjo> tgardner, any idea when it might get to proposed ?
<vanhoof> manjo: believe its available in pre-proposed right now
<robbiew> tgardner: ok, figured it was something like that
<manjo> vanhoof, was looking for a wag on the timeframe it might make proposed 
<tgardner> robbiew, likely 2.6.41, maybe .42
<robbiew> tgardner: ok...works for me
<robbiew> thnx
<vanhoof> manjo: once this current one gets out of the door, and post natty
<vanhoof> manjo: there are some delays to expect for the next sru cycle for maverick
<tgardner> manjo, inquire of sconklin or bjf
<vanhoof> manjo: not kernel team related
<bjf> manjo, we are more or less following: https://wiki.ubuntu.com/NattyReleaseInterlock
<manjo> bjf, so possibly May time frame then 
<manjo> for it to get to updates 
<vanhoof> manjo: so once -28.50 (which is in proposed) ships, it gives a bit more flexibility on the hwe team to look at
<bjf> manjo, yes
 * tgardner is off to trash a server by installing ESXi
<savvas0> hello! I was asked to test kernel mainline builds for Bug 721493 -- is it ok if I download the ubuntu 11.04 beta-1 live cd and test it through the live environment?
<ubot2> Launchpad bug 721493 in linux "dmidecode shows wrong memory information" [Undecided,Incomplete] https://launchpad.net/bugs/721493
<herton> savvas0: it isn't the same thing, because the live cd doesn't come with mainline kernel, but it helps anyway if you get latest natty livecd as it's a 2.6.35 vs 2.6.38 kernel
<herton> s/mainline kernel/mainline build/
<savvas0> thank you :)
<savvas0> I suppose I could install these 3 little packages
<jbarnes> yay /sbin/installkernel is fixed!
<jbarnes> thanks to whomever finally fixed it
#ubuntu-kernel 2011-04-02
<vanhoof> have a good weekend everyone
<jj-afk> back on later
<lamont> name/address: Need IPv6 code in mroute_extract_addr_from_packet
<lamont> wtf does that mean, I wonder?
<kristian-aalborg> hey jjohansen1 
#ubuntu-kernel 2012-03-26
<snadge> i think i've got a fairly simple one i was hoping someone with some more kernel experience could help me with
<snadge> yeah its a problem only with recent kernels and virtualbox.. but still
<snadge> https://forums.virtualbox.org/viewtopic.php?f=7&t=47078
<snadge> exactly the same oops as this guy has.. except hes using some 3.2 rc and mint.. im using ubuntu precise, and latest mainline nightly (3.3.0 #201203250407)
<snadge> code dissassembly is the same.. and the same call trace
<snadge> id like to know how to find module_put .. and the section of code that disassembly is referring to
<snadge> no source packages for the mainline nightlies?
<snadge> i suppose i have to use git for that
<snadge> git://kernel.ubuntu.com/ubuntu/linux.git  <-- that is mainline ?
<snadge> *tumbleweed* .. i wonder if i'll finish this git clone before anyone says anything
<bullgard4> [Ubuntu 11.10 GNOME Shell 3.2.2.1] Super key > Applications > System tools > Power statistics > Prozessor > Wake-up processes lists 2 types of wakeup processes: i.) Symbol is a rhombus, ii.) Symbol is a gear. What is the name of these two types?
<RAOF> bullgard4: App vs IRQ handler, apparently.
<smb> morning
<ppisati> moin smb :)
<smb> Just for forgetting to upgrade on Friday... now its about 230M... at least nothing that wants to get removed...
<ppisati> did you reboot already?
<ppisati> is it safe?
<smb> no just started the dist-upgrade
<smb> will let you know in a bit...
<ppisati> 135 pkgs here...
<ppisati> wtf?!?!? we still have evolution and banshee around, did we sack them in this release?
<ppisati> *didn't
<snadge> enjoy unity 5.8 ;)
<snadge> for some people it causes a blank desktop upon login.. hehe
<smb> ppisati, It probably won't get deleted when you got them already
<ppisati> doh!
<ppisati> snadge: unity2d?
<ppisati> snadge: is it safe?
<RAOF> unity2d works; and after a unity --reset, so should 3d.
<ppisati> smb: btw i still have emacs around, but that's my heritage...
 * ppisati uses only 2d, cool...
 * smb pretends not to know those 5 letters... ;-P
<ppisati> well, personally i really like unity (design-wise)
<ppisati> is all i liked from windowmaker + a status bar with all the indicators&c
<ppisati> btw, did they revert the secondo screen+second launcher thing?
<RAOF> ppisati: It's now configurable in the âDisplaysâ capplet; there's a toggle for on-all-screens/a drop box for which screen you want it on.
<ppisati> RAOF: nice
 * ppisati -> reboot
 * smb reboot
<snadge> unity2d is good
<ppisati> so far so good...
<smb> So far... as long as you are through the blank (or background only) screen, unity --reset segfaulting and compiz crashing parts...
<ppisati> ouch
<snadge> i ran unity --reset from console myself
<snadge> but my work pc.. didnt need to.. so maybe its related to fglrx
<snadge> work pc is intel
<smb> This machine is on ati/radeon
<snadge> possibly related to amd/ati then
<smb> Running reset from console just hang, repeating went a bit further and finally running it again from gfx resulted in a segfault of the command.
<snadge> thats pretty harsh
<smb> (not really making one trust in its ability to fix things... ;-P)
<snadge> maybe it'll work now
<smb> I am up and running right now
<smb> Fingers crossed
<snadge> yeah it must be a new compiz setting or an old one that glitches with the update
<snadge> theres a launchpad bug for it.. i dont have the link offhand
<snadge> https://bugs.launchpad.net/unity/+bug/963633
<ubot2> Launchpad bug 963633 in unity "Unity 5.8: Login to blank screen (all black or just wallpaper)" [Critical,In progress]
<snadge> that one has the most heat
<smb> Yep, sounds like it. 
<snadge> launchpad is great now that heaps of people use ubuntu
<snadge> bug affects 56 people :P
<snadge> reported 2 days ago
<smb> And someone has assigned it at least. Well, there was a weekend in between... :)
<snadge> 14 duplicates tagged already
<snadge> i know this isnt a kernel problem.. but i *really* want someone to fix this
<snadge> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/770283
<ubot2> Launchpad bug 770283 in compiz-core "[fglrx]title bar does not update on non-maximized windows" [Medium,In progress]
<smb> snadge, Then you may tell "them" in #ubuntu-unity... maybe 
<snadge> tried that ;) but yeah.. i will remind them hehe
<fsancho> Hi all. Is there any good reason to not activate "CONFIG_DRM_GMA500=m", "CONFIG_DRM_GMA3600=y" and "CONFIG_DRM_GMA_600=y" in config for 3.3 kernel?
<snadge> yes.. the universe will explode if you do
 * ogra_ thought the universe does that anyway since the big bang
<snadge> right.. but little did you know, thats what caused the big bang
<snadge> some chose those specific kernel options.. and boom.. here we are now ;)
<ogra_> ah, k ... thats the physics lesson i missed at school then :)
<fsancho> i mean, these options are deactivated in 3.3 builds from kernel.ubuntu.com. Is there a good reason for that? Is there a way to ask the manager of the site to activate it?
<snadge> well i dont know who manages the daily builds on kernel.ubuntu.com
<snadge> but i can tell you that more often than not.. those builds suck
<snadge> i tried out the radeon/drm stuff yesterday.. granted with experimental options and mesa from git
<fsancho> snadge: My builds with make-kpkg doesn't look as good as those builds
<snadge> but still.. it caused my computer to reboot after a few minutes of playing minecraft ;)
<bullgard4> RAOF: Thank you very much for your help.
 * ppisati -> lunch
<cking> mjg59, what's the current state of play with the patch "PCI: ignore pre-1.1 ASPM quirking when ASPM is disabled" - you mentioned you were working on this: https://lkml.org/lkml/2012/3/19/408
<mjg59> cking: Haven't been able to reproduce, nobody's sent me a bug report containing any worthwhile information
<cking> mjg59, that's a bummer, we're seeing some machines hang with this patch, bug 961482
<ubot2> Launchpad bug 961482 in linux "3.2.0-19 kernel fails to boot (-18 OK)" [Critical,Confirmed] https://launchpad.net/bugs/961482
<mjg59> Yes, I know - but I can't reproduce and mere inspection doesn't seem to be getting me anywhere. I really need a full backtrace.
<cking> ah, so in the short term, would pulling this patch be a more sensible option?
 * cking trying to work out the pros vs cons of keeping this patch
<mjg59> No, that breaks a different set of hardware
<cking> mjg59, OK - so reverting 3c076351c4027a56d5005a39a0b518a4ba393ce2 "PCI: Rework ASPM disable code" may at least allow these machines to boot?
<mjg59> I really don't know at this point
<mjg59> I'd like to see some effort to fix the bug from people who have access to users who see the bug
<mjg59> The ones who have contacted me about it are not especially useful in terms of actually giving me feedback...
<cking> I realise this, just trying to explore options at the mo. 
<tgardner> cking, do we have any affected machines within OEM or somewhere else ni the company ?
<mjg59> Reverting all ASPM changes back to the 3.2 baseline will probably boot things, but you'll be back to spending 5W extra per machine
<cking> tgardner, not that I know of, I've seen zero reports on this from OEM
<tgardner> cking, well, see if you can get one of the affected folks in the bug report to respond.
<cking> tgardner, ack
<cking> mjg59, so a *full* backtrace is required, anything else especially useful to add in?
<mjg59> cking: They're probably going to need either a serial console or USB debug to get it
<cking> sigh
 * cking will check with OEM to see if we have one of the offending Dells
 * ogasawara back in 20
<jjohansen1> ogasawara, tgardner: is there going to be 1 more kernel upload before beta2?
 * jjohansen1 knows the answer is no but needs to ask
<tgardner> jjohansen1, certainly one more before freeze
<tgardner> likely april 3
<ogasawara> jjohansen1: I wasn't planning on one before beta-2, but definitely one more before kernel freeze
<jjohansen1> tgardner: right, but not before beta2
<jjohansen1> ogasawara: okay thanks
<tgardner> jjohansen1, that would almost require a freeze exception from the release team
<jjohansen1> tgardner: right, I will let the server team request that if they want
<ogasawara> tgardner: I am concerned though about bug 961482 being unresolved for beta-2, but there does seem to be a workaround so I was going to release note it.
<ubot2> Launchpad bug 961482 in linux "3.2.0-19 kernel fails to boot (-18 OK)" [Critical,Confirmed] https://launchpad.net/bugs/961482
<tgardner> ogasawara, cking is working on it
<ogasawara> tgardner: ack.  if we did get a fix in time for beta-2, I'd lobby the release team for an upload.
<cking> ogasawara, I'm not sure yet if we can get a fix in time though, it's pretty tight
<ogasawara> cking: indeed, we'd have to get something in by tomorrow which is not a large window.
<ogasawara> cking: were you able to get a hold of anyone in OEM who could reproduce?
<cking> ogasawara, not yet, but they possibly have some H/W which I will try and get shipped to me
<ogasawara> cking: I think bryceh might have a system showing the issue?
<cking> ogasawara, this kinda bug requires gathering most of the oops, so it's kinda serial console kinda work
<jjohansen1> ogasawara, tgardner: sounds like server team is going to work around the issue for beta 2 so no freeze exception request for the kernel
<tgardner> jjohansen1, ack. what was theissue ?
<jjohansen1> tgardner: its around containers and apparmor confinement
<jjohansen1> tgardner: there is a pseudo workaround, that they will use for beta2
<cking> rats, hit an inode race bug in btrfs
<henrix> smb: thanks for the background info on iscsitarget, in your email
<henrix> smb: about the bug itself, in my (quick) investigation, i found that the bug has been solved already upstreams
 * henrix kept a link to thread somewhere...
<smb> henrix, welcome. Ok, I have not  seen a good pointer in the debian changelogs, but have not yet check upstream
<henrix> smb: let me take a look at my notes, i'm sure i found a reference to this
<smb> Seems version-wise we are back a few versions compared to debian testing but that late in the game I would rather not try to get someone to re-sync.
<henrix> ah! found the reference
<henrix> smb: https://bugzilla.novell.com/show_bug.cgi?id=676803
<ubot2> bugzilla.novell.com bug 676803 in Kernel "iscsi enterprise target just hangs" [Critical,Resolved: fixed]
<henrix> i guess it's the same issue, and they closed the issue with a newer version of the package
<smb> Ok, 1.4.20.3 is newer than what the Debian version says. But I remember that there was an odd versioning thing with the sourceforge project. In their svn files there was references to the new number but not tarballed and released as is...
<henrix> smb: yeah, can't remember the details, but when i was looking at that i found 1.4.20.3 only on the svn (or cvs...)
<henrix> smb: but not on the tarballs
<smb> Hm, so svn is at version470, if I read the Debian changlog correctly they went to 453
<smb> the suse report has someone claiming it works with 466...
<smb> henrix, Hm, that might be the relevant commit... http://iscsitarget.svn.sourceforge.net/viewvc/iscsitarget/trunk/kernel/iscsi.c?r1=462&r2=461&pathrev=462
<henrix> smb: yeah, it could be
<henrix> smb: i can take a closer look at this bug again if you want me to
<henrix> smb: right now i'm working on the sru cycle, but i may get some time later on
<henrix> smb: (tomorrow, probably)
<smb> henrix, Since I have been poking at that package already, I could carry on as well. Just don't want to rip it from you in case you wanted to go on...
<henrix> smb: well, from my activity report, this bug was not on my todo list anyway :)
<henrix> smb: so, feel free to have some fun with it
<smb> henrix, :) Ok, then let me try to find out whether we can fix it by that upstream change. 
<henrix> smb: cool. anyway, if you're busy, feel free to "delegate" it on me :)
<smb> henrix, I would never say I am not busy (that just conjures new issues)... But it should fit in. ;)
<tgardner> sforshee, are you seeing any video tearing on your MB Air ? maximize a shell, then click on the wi-fi icon a few times.
<tgardner> cking, otp
<cking> tgardner, ack
<sforshee> tgardner, I haven't noticed any tearing, and I'm not seeing any doing what you described either
 * tgardner relocates
 * tgardner -> EOD
<RAOF> We would appear to be missing some ivybridge fixes in our kernel.  The mainline build of drm-intel-next is stable, but our 3.2-20 kernel tends to hard-lock in Unity.
<RAOF> I'm seeing if I can get some netconsole output when it dies to narrow down what the problem is.
<ohsix> are there too many patches between drm-intel-next and 3.2-20 to see what one it may be?
<RAOF> ohsix: There's almost two full kernel releases worth of development.
<ohsix> ic
<RAOF> Which is why I'm looking for some sort of error message other than âthe system goes entirely unresponsiveâ - that should help point to a patch.
<RAOF> Of course, now that I've got a netconsole hooked up it's not hanging.
<ohsix> gpu hangs are scary
<bryceh> RAOF, see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/961482
<ubot2> Launchpad bug 961482 in linux "3.2.0-19 kernel fails to boot (-18 OK)" [Critical,Confirmed]
<bryceh> (in case you hadn't already run across it)
<bryceh> (and in case it's the same bug.  that one is not ivybridge-specific afaik)
<RAOF> That's not it; the system comes up fine, and works for an indeterminate period of time.
<RAOF> And then, at some point (usually associated with alt-tab?) it hangs.
<bryceh> ok
<RAOF> Bah.  That's highly annoying.
<RAOF> netconsole stays around *just* long enough to print the timestamp of the kernel message when everything freezes.
#ubuntu-kernel 2012-03-27
<MAbeeTT> hi I recently updated to oneric (3.0.0-16-generic x86_64 x86_64 x86_64 ) I tought that suspend problems will desapear with 3.0 kernel
<MAbeeTT> but I've been wrong :(
<MAbeeTT> How could I help to solve the suspend problems? 
<MAbeeTT> I suspend, when I start again the system, the keybard doesn't work, there is no screen, or it stars "from zero".
<MAbeeTT> thanks
<bullgard4_> When booting, Ubuntu 11.10 performs: " * Starting Mount network filesystems. [OK]". But why does it immediately therafter perform the opposite:" * Stopping Mount network filesystems. [OK]" ?
 * smb mornings
<apw> smb, morning
<smb> apw, A very good morning back :)
<apw> cking, henrix, morning
<cking> morning apw
<apw> sunny where you are?  i am being blinded :)
<smb> cking, henrix morning
<henrix> apw: morning!
<henrix> smb: morning for you too
 * apw hands out liberal ammounts of vitamin-D harvested from the blinding rays
 * smb fails to catch them... too bright here...
<apw> heheheh
 * diwic notices ppa-pre-proposed is about to run out of 16 GB of disk space
 * smb grabs a shovel and pitch fork
 * diwic forks the shovel for a new pitch
<smb> Removed all superseded packages. Though it takes some time for the actual removal to happen...
<snadge> the more you drink moonshine mixed with dr pepper.. the better it tastes
<sashal> Hello all
<sashal> A question to the security team: It looks like only half of the CVE-2011-4347 fix was pulled into the tree, was the 2nd part skipped on purpose?
<ubot2> sashal: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4347)
<apw> sashal, that number is familiar
<sashal> apw, It's the KVM device assignment problem
<apw> sashal, the second fix was added to the CVE late (after it was USNd I suspect) and I beleive it is being released (the second part) in this round of SRU updates.
<sashal> apw, It was done in the same patch series as the original fix, that's why I thought it's weird in the first place
<apw> sashal, yep, somehow the original security report only had one, the second was added some days later and we'd already spun the security update
<sashal> Ah, Cool
<sashal> Thanks!
<apw> anyhow, its being done for sure if its not already out for testing
<apw> no idea how they will handle the USN given it went out once already
<sashal> btw, is there a timeframe in which the USN comes out after the release? Some times it takes couple of days after the kernel was moved into the production repository for the USN to come out
<apw> sashal, i am unsure, thats handled by the ubuntu-security team, they have some manual process to ensure eyes are on things; probabally how the error was spotted in the first place
<apw> ppisati, are you planning a further rebase for precise/ti-omap4, or waiting till leanns next upload??
<ppisati> apw: more stuff to come, don't upload yet 
<ppisati> apw: i just found out there's a critical still open for P/omap4 (i was lost in perf land till yesterday)
<ppisati> apw: so either i fix it by tonight or i'll ask for a revert to the previous TI BSP + stuff we have on top of HEAD now
<ppisati> tgardner: FYI - ^^
<tgardner> ppisati, ack
<apw> ppisati, ok thanks
<apw> ppisati, i assume you are saying that will occur as a quick fix for B2 and then you'll fix it properly sort of thing ?
<apw> cking, did i hear rumours you were talking to people about the aspm-1.1 issues ?
<cking> yep
<apw> tgardner, i see that ericm said that they were sending out that ath5k thing with a new version number, but i recall you applying the firware with the current name, are we going to be broken in the future by that ?
<tgardner> apw, only if the firmware _isn't_ backward compatible, though Atheros says it is.
<tgardner> apw, besides, I assume that'll be 3.4 material
<apw> tgardner, does this mod_probe stuff have a CVE associated with it, i have a vague feeling it might
<tgardner> apw, not that I could find. jdstrand stumbled across it this weekend, so I picked it up myself
<apw> tgardner, i could swear i have read a cve for it, but cannot find it in our list ... sigh
<ppisati> apw: yes, if i can't make HDMI output to work by tonight, i'll take latest master + previous TI BSP (where hdmi output was working) + latest patch on top of P/omap4 (cross compile fixes + pperf revert) just for beta2
<Teduardo> howdy, does anyone know if there will be a new version of the kernel for lts 10 installer so that we can install it on Dell 12 Gen servers?
<ppisati> apw: in the meantime i'll keep trying to find the root cause of the breakage with the new TI BSP code
<tgardner> Teduardo, by Tuesday.
<Teduardo> oh thats good news i read somewhere that 10.04.4 was going to be the "FINAL" release
<tgardner> Teduardo, oh, lts 10. I'm thinking 12.04.
<Teduardo> and that made me want to curl up in a ball and cry
<tgardner> Teduardo, 10.04.4 _is_ the last release
<Teduardo> ack
<tgardner> Teduardo, you can't get an install to work from the 10.04.4 DVD ? Every kernel through Oneiric is available on it
<Teduardo> ah, we can't do dvd installs, everything we use is pxe =(
<tgardner> Teduardo, well, you could craft your PXE boot _from_ the DVD
<Teduardo> all I really need is a kernel and initrd that supports the new NIC and new LSI controller
<tgardner> Teduardo, which is why I pointed you at the DVD. the installer supports multiple kernels.
<bullgard4> When booting, Ubuntu 11.10 performs: " * Starting Mount network filesystems. [OK]". But why does it immediately therafter perform the opposite:" * Stopping Mount network filesystems. [OK]" ?
<Teduardo> tgardner: okay, I think currently the only one that works on this platform is 11.10, I'll have to just use that it seems
<tgardner> Teduardo, well, you'll have 12.04 soon
<tgardner> Teduardo, in fact, you should be testing it now
<Teduardo> hopefully the installer works in the first release, usually there is almost always some kind of LVM menu loop that breaks kickstart
<Teduardo> or it tells me it can't find a disk to install on even though fdisk -l shows /dev/sda... etc
<tgardner> Teduardo, I've been doing 12.04 PXE installs on a variety of platforms.
<Teduardo> ah i'm talking about my experience with 11.10
<tgardner> Teduardo, have you filed a bug ?
<tgardner> apw, are you gonna ACK the kmod patches ?
<apw> tgardner, working through them now
<apw> b smb
<apw> tgardner, ok ... i think as much as a huge pile like that can be, they are ok.  acks in your inbox
<tgardner> apw, I've been through them pretty thoroughly myself. I've also booted each kernel.
<smb> I mumble broken only for me?
<jsalisbury> smb, no mine is bouncing
<smb> Meh, no
<ppisati> yep
<tgardner> apw, has your mumble connection just bailed ? 
<ppisati> "serve connectio failed: connection refused"
<tgardner> how annoying
<smb> #is is already buggered
<apw> tgardner, not on it, without headset for a few hours
 * tgardner kills mumble
<apw> tgardner, look like is think it is back now
<tgardner> apw, huh?
<tgardner> -ENOPARSE
<Nafallo> s/is/IS/
<apw> IS think m,umble is back
<tgardner> apw, yes
<apw> right ... /me makes a run for home .. back in 1.5
<cking> mjg59, for these PCIe ASPM hangs on boot it seems we could be hitting a BUG_ON in pcie_aspm_configure_common_clock() because the child isn't apparently pcie capable.
<mjg59> Just. What?
<cking> mjg59, it makes no sense, but we got a user to get a full stack dump and it seems (I may be wrong!) that BUG_ON is being called
<mjg59> cking: Oh right I see. Argh.
<mjg59> Yes, this is just about possible.
<cking> I suspect the BUG_ON is being a bit harsh
<cking> for the life of me I can't see why this is biting us now
<mjg59> cking: http://fpaste.org/bOQm/
 * cking mulls on that for a moment
<mjg59> cking: Prevously we'd bail if any children weren't pcie. Now we won't.
<mjg59> We need to continue to do so in order to avoid the BUG_ON
<cking> ah, that's we are being caught out
<cking> got it
 * cking will give it a spin
<cking> methinks mjg59 is always at least 24 hours ahead of me 
<mjg59> cking: Thanks for that - I don't think there's any way I'd have figured it out otherwise
<cking> mjg59, no problem, getting a full stack dump and walking it through was the easy bit, I got stumped at why the BUG_ON was happening
<mjg59> cking: I think I'll just send that - it's Obviously Correct(tm)
<cking> heh, I can also get the users to verify it to sanity check that, but it normally takes ~24 hours 
<ogasawara> cking: let me know when you get confirmation on the patch, there may be time to squeeze it in for Beta-2
<cking> ogasawara, yep, will do
 * ogasawara back in 20
<tgardner> ogasawara, I just plucked it from the stable mailing list and applied it.
<cking> we cross our fingers ;-)
<tgardner> cking, you should build current master-next and post it as a test kernel to your various testers
<cking> tgardner, ack
<ogra_> ppisati, any idea about bug 963512 ? the release team just asked about it 
<ubot2> Launchpad bug 963512 in linux-ti-omap4 "Latest kernel updates broke video on omap4" [Critical,Confirmed] https://launchpad.net/bugs/963512
<ppisati> ogra_: i'm on it
<ppisati> ogra_: will upload a new kernel with working hdmi by tonight
<ogra_> ppisati, how late is "tonight" we would like to have working images for the beta release 
<ppisati> ogra_: in a couple of hours
<ppisati> ogra_: is it soon enough?
<ogra_> ppisati, couple of hours should be fine
<MAbeeTT> hi I recently updated to oneric (3.0.0-16-generic x86_64 x86_64 x86_64 ) I tought that suspend problems will desapear with 3.0 kernel
<MAbeeTT> but I've been wrong :(
<MAbeeTT> How could I help to solve the suspend problems? 
<MAbeeTT> I suspend, when I start again the system, the keybard doesn't work, there is no screen, or it stars "from zero".
<MAbeeTT> of course, I didn't found logs with interesting info about suspend.
<MAbeeTT> the problem existis via pm-suspend command or "suspend option in unity/gnome"
<MAbeeTT> thanks
<ogasawara> tgardner: I'm inclined to upload it
<tgardner> ogasawara, I was gonna ask if you were willing to.
<ogasawara> tgardner: I am, as I think that bug is going to affect a few systems if we don't
<tgardner> absolutely
<cking> yep
<tgardner> ogasawara, I've smoked tested it, but not on an affected platform. cking should get one via fedex yet today perhaps
<ogasawara> cking: Ooo, you're sure you'll get a system today?
<ogasawara> cking: if that's the case, I'd maybe wait to upload to get confirmation of the fix
<cking> ogasawara, normally they arrive after lunch, now it's past 4pm, so it's looking slim
<tgardner> ogasawara, I still think its worth it. besides, there are abunch of other patches that need to get into the pipeline
<ogasawara> cking: my thoughts are I'd upload even without test verification.  we've already rendered the machines unbootable, it can't get too much worse.
<cking> indeed
<ogasawara> tgardner: I was only planning to pick this single patch, are there other's you wanted in?  as I'd need to justify them to the release team.
<tgardner> ogasawara, seccomp ?
<tgardner> ogasawara, bunch of AA fixes as well.
<tgardner> I forgot we're still awaiting B2
<ogasawara> tgardner: right, seccomp should already be uploaded as I squeezed it in before beta-2 freeze.  the latest AA patches I didn't think were critical for Beta-2 and could wait till after.
<tgardner> ogasawara, ah right. I missed the Ubuntu-3.2.0-20.32 patch in master-next. 
<tgardner> ogasawara, how about the AMD KVM pacthes ?
<ogasawara> vanhoof: ^^ bug 960466 how critical is that for you guys to land in Beta-2
<ubot2> Launchpad bug 960466 in linux "Provide correct reporting of BMI1/AVX2/BMI2 support" [Medium,Fix committed] https://launchpad.net/bugs/960466
<ogasawara> vanhoof: or can it wait till first upload post Beta-2
<vanhoof> ogasawara: can wait for first upload post b2
<ogasawara> vanhoof: ack, thanks
<vanhoof> ogasawara: critical for release, but not for b2
<vanhoof> ogasawara: is there any chance of them missing the release if we dont land it for beta 2?
<ogasawara> vanhoof: nope.  kernel doesn't freeze until next thurs Apr 5.  I'll make sure they make it before kernel freeze.
<tgardner> vanhoof, no, they are in the pipeline
<vanhoof> ogasawara: cool, that works
<tgardner> jsalisbury, top 10 mumble ?
<jsalisbury> tgardner, we started having it an hour from now, to keep it 30 minutes before the IRC meeting.
<arges> jsalisbury, did the invite not get moved in the calendar?
<tgardner> jsalisbury, well then, I'll just fix the calendar
<jsalisbury> arges, I don't think so, but it sounds like tgardner will do it :-)
<cking> stupid summer time clock changes
<cking> ogasawara, so the box I need to test it with was last seen in MEMPHIS, TN, so it's unlikely to arrive today
<ogasawara> cking: ack, thanks.  I'll prep the upload anyways.
<cking> stymied by fexex this time
<cking> fedex
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<ppisati> tgardner: ok, pull sent
<tgardner> ppisati, ack
<tgardner> ppisati, you're wanting this uploaded for B2 ?
<ppisati> tgardner: yep
<adam_g> win 15
<tgardner> ppisati, so that is some seriously bizarre shit you did with the ti-omap4 branch. are you gonna work on what regressed ? might have been something in the 3.2.13 stable updates.
<ppisati> tgardner: yes, it came with latest rebase
<ppisati> tgardner: i'll figure out but i want beta2 to be safe
<ppisati> tgardner: TI BSP is the same, so there's something from upstream that kills hdmi output
<tgardner> ppisati, ok, I'm packaging....
<ppisati> tgardner: cool, thanks
<tgardner> ppisati, do you not have the right HW to have detected the HDMI regression ?
<ppisati> tgardner: no, it's just that the bug was opened on friday and i saw it this morning
<ppisati> tgardner: i was working with the server install
<tgardner> ah, ok
<ppisati> for the perf bug
<apw> tgardner, are you looking for acks for that pre-stable patch ?
<tgardner> apw, nope, just advertising that I applied it.
<apw> tgardner, wfm
<tgardner> apw, I am, however, looking for ACKs on the Oneiric tsc stabilization patch
<tgardner> ppisati, your kernel is in the queue awaiting approval. go bang on the release team to get it through
<ppisati> tgardner: k, thanks
<ppisati> tgardner: what's the channel?
<tgardner> ogasawara, can you help out ppisati ?
<ogasawara> ppetraki: #ubuntu-release
 * tgardner hasn't requested a freeze exception in awhile
<ogasawara> bah ppisati ^^
<ppisati> k
<ppisati> will do
<ogasawara> ppisati: ping skaet in there
<ogasawara> ppisati: or I can just do it, just a sec
<tgardner> ppisati, [ubuntu/precise] linux-ti-omap4 3.2.0-1411.14 (Accepted)
<ppisati> cool, thanks everyone
<tgardner> ogra_, ^^
<ppisati> next time i won'd do any upload around FF, i swear...
<apw> ppisati, is building on both armel and hf
 * ogra_ hugs the kernel team
<tgardner> ogra_, we prefer beers
<apw> or a glass of fine red wine
<ogra_> non virtualized i guess ... so that has to wait until UDS :)
<cking> mjg59, user has given positive feedback - that patch works fine.
<mjg59> cking: Great
<mjg59> cking: I've posted it to LKML and linux-pci - would be great if you could follow up with confirmation it works
<cking> ack, 
<jsalisbury> bug 961482
<ubot2> Launchpad bug 961482 in linux "3.2.0-19 kernel fails to boot (-18 OK)" [Critical,Fix released] https://launchpad.net/bugs/961482
<smb> bjf, Just fyi, I did a spring cleaning on the kernel-ppa pre-proposed ppa and sent all superseded packages away. It was reaching its limit
<bjf> smb, thanks, last time i tried, LP just kept timing out
<smb> bjf, Yes it did that to me as well when I tried them all at once. It seems ok when slecting only 10 at a time
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues Apr 3rd, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
 * ppisati goes for some groceries, back in a bit
 * apw reboots ...
<apw> abogani, about ?
<infinity> apw: You probably want TheMuso. :P
<infinity> apw: Oh, while I'm being annoying, though, could you have a poke at bug #965840 for precise and possibly SRUs?
<ubot2> Launchpad bug 965840 in linux "Need to apply patch: "ARM: Do not call flush_cache_user_range with mmap_sem held"" [Undecided,Confirmed] https://launchpad.net/bugs/965840
<apw> ppetraki, ^^ more arm fun :)
<infinity> ppisati: ^ You too. :P
<infinity> apw: I poked you since we'd want it applied to omap as well (and then wouldn't paolo get it for free when he rebases?)
<apw> infinity, bah you slave driver you
<infinity> Hahaha.
<apw> TheMuso, we need to get some SOPs for the lowlatency kernel when we need to do emergency updates such as was desired today
<infinity> apw: AIUI, the patch will break pre-v6 (which is why it's not yet upstream), but we don't give a hoot about anything pre-v7, so it seems sane to me to carry the fix.
<apw> infinity, assuming you've tested it on some of the affected kit that seems fine
<apw> infinity, have we ?
<infinity> The user who reported it has.  I can certainly spin something up "later", FSVO "later".
<infinity> (If it's any comfort, it's also in 95% of the v7 Android trees out there)
<apw> heh no comfort at _all_ frnakly
<infinity> Hahaha.
<infinity> Yeah, that's a fair point. :P
<infinity> Well, once I get this grub bug nailed to a wall, I'll see if I can do some local testing of this patch.
<infinity> Unfortunately, there's no particularly sane way to test it beyond smoketesting that it boots and doesn't crash.
<infinity> Since the condition required to reproduce the bug it's fixing is "lots of random luck".
<apw> i more care that the boards we care about continue to boot with it
 * apw spins a kernel with it
<infinity> Yeah.  That's almost certainly true just from eyeballing the patch, but I can test to confirm.
<ppisati> apw: do you want me to take care of 965840?
<apw> ppisati, s'ok for now as i have the patch and its likely master material
<apw> infinity, that reminds me where are all the other deviant kernels on that bug, the source trees ?
<infinity> apw: mx5 is a linaro kernel, and ac100 is jani's baby, not sure where he keeps the tree.
<ppisati> apw: ok
<infinity> apw: In both cases, I'll probably just update the precise kernels myself, and let the respective maintainers sort out their gits later.
<infinity> apw: (And I'm not wildly concerned about SRUs for the weird kernels, just for omap/omap4, since we use them as buildds)
<apw> infinity, which random old crap are you wanting this on
<apw> infinity, ^^
<infinity> apw: omap4 natty and newer, and for master, everything you're still doing SRU napalm runs for, I guess.
<apw> infinity, can we not get those buildds onto one release, at least to reduce the exposure when we have something real bad
<infinity> apw: My hope is that all the buildds will be precise "soon".  But it's not really up to me. :/
<infinity> apw: If I still had root on them, they'd all be 3.2.x right now. :P
<apw> infinity, a plan indeed.  anyhow, i'll get you a P binary-omap to test out and if that sails i'll commit it for the next P after B2
<apw> smb, what colour are your osb backgrounds ... ?
<cking> unity 3d feels really much snappier nowadays even on my old crate of a laptop
 * tgardner relocates
 * cking -> EOD
 * tgardner -> EOD
<lamont> can I reshape a raid1 into raid5?
<infinity> lamont: If you drop a disk, and call it a degreaded raid5 with 1 disk, then add more, possibly.
<infinity> apw, ppisati: Do I get a new meta for that omap4?
<lamont> infinity: hrm
<lamont> given that I'm actually trying to take a 3-drive raid5 and make it a different 3-drive raid5, that could be interesting
<infinity> lamont: I wouldn't hold my breath though, as raid0,5,6 all use clever striping algorithms and do fancy things with superblocks.
<infinity> lamont: raid1 isn't really terribly clever at all, in comparison.
<infinity> lamont: Oh, for 5->5, my home upgrade strategy is "never upgrade the array until the largest disk on the market is bigger than my entire array".
<infinity> lamont: So I can drop a disk, run degraded, backup to one of the new disks, create new degraded array, profit.
<TheMuso> apw: SOP?
<apw> 'standard operation proceedures'
<apw> TheMuso, ^^
<TheMuso> ok
<apw> TheMuso, so we know where the master branch is, how to get you an update when we've had to step on your toes, that sort of thing
<apw> something to think about after the freeze is lifted probabally, as you arn't the only outside tree, and there are only becoming more
<TheMuso> apw: Right well the plan is to get the studio guys to do the majority of the work, and I just review/upload, but we're not there yet, and we still need to devide where the kernel tree will eventually be hosted such that we all have access.
<TheMuso> decide
<apw> TheMuso, right and its unlikely all the trees will work quite the same, so likely there will be some common wiki page or something with the 'how, who, where' bits of information etc... and you get to help work out the game
<TheMuso> Yep gotcha.
 * apw heads for the couch
<TheMuso> apw: BTW when I've tried to rebase recently, apparmor stuff has seemed to be applied on top of the most recent Ubuntu-x-y-z commit... Am I doing something wrong? I am just using "git fetch precise master" git rebase refs/remotes/precise/master
<TheMuso> ...or is anybody else able to answer?
#ubuntu-kernel 2012-03-28
<smb> apw, green (the same as the desktop) :)
 * smb wonders what apw did at the keyboard in the middle of the night anyway...
 * apw yawns
<ppisati> ok, so it's either my lcd or my panda board but i can't get any video output anymore.. i tested 3 kernels already with not output at all
<henrix> apw: do you know where the stable shank script is executed? i guess it should be some sort of cron job, but not sure...
<henrix> apw: i was hoping to get some sort of logs from its execution.
<henrix> apw: any idea?
<apw> henrix, now you mention it no i don't.  i'd start with people.c.c, much runs there
<apw> as the kernel user
<henrix> apw: ok, thanks. i'll check that
<apw> henrix, if its not there yell and i'll think more
<henrix> apw: it looks like that's the place
<apw> good stuff
<henrix> apw: now, i just need to figure out if there are any logs being kept
<apw> henrix, it keeps some information in the top of the bugs it updates, transitions etc
<henrix> apw: yeah, i would expect that. any idea where?
<apw> henrix, other than somewhere in the kernel user, not a clue, though i also think it may mail out things
<henrix> apw: ok, thanks. already found something, but not quite what i'm looking for
<apw> damn
<henrix> apw: don't bother. if i can't find it, i'll ask brad later on
<henrix> apw: not that urgent anyway
<apw> henrix, ok :)
 * ppisati -> lunch
<tgardner> cking, bug #966782 may indicate an ASPM regression
<ubot2> Launchpad bug 966782 in linux "irqs disabled after kernel update" [Undecided,Confirmed] https://launchpad.net/bugs/966782
<cking> tgardner, ok will look at it
<stgraber> hello kernel people, I just went through my list of kernel related bugs for thin clients and I have 3 upstream commits that I'd appreciate if we could cherry-pick
<stgraber> bug 911920, bug 911916 and bug 907055
<ubot2> Launchpad bug 911920 in linux "hp st5747 Thin Client Needs LDVS removed" [Medium,Triaged] https://launchpad.net/bugs/911920
<ubot2> Launchpad bug 911916 in linux "hp t5745 Thin Client Needs LDVS removed" [Medium,Triaged] https://launchpad.net/bugs/911916
<ubot2> Launchpad bug 907055 in linux "Clientron E830 Thin Client Needs LDVS removed" [Medium,Fix committed] https://launchpad.net/bugs/907055
<stgraber> all of them very simple LVDS quirks being added, all of them landed in the upstream kernel and all of them making the thin client pretty much unusable by default
 * cking slips off to attend to a sick head
<stgraber> as LTSP would configure a dual-head setup with a non-existing screen, thereby hiding a significant part of the screen from the user
<tgardner> stgraber, I'll have a look
<stgraber> tgardner: thanks
 * ogasawara back in 20
<cnd> bjf, ogasawara: where's the code that creates the kernel bug reports like http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/_kernel_hot_.html
<ogasawara> cnd: should be kteam-tools git repo
<cnd> ok, thanks :)
<tgardner> ppisati, jsalisbury, ayan, henrix: rebooting tangerine for kernel update
<ppisati> k
<henrix> tgardner: ack
<jsalisbury> tgardner, ok, thanks
 * ppisati -> back in 10m
<apw> ogasawara, just rebuilt a beta2 config review and pushed it to the blueprint
<ogasawara> apw: ack, thanks
<bjf> cnd, it's not in kteam-tools it is in  a "kteam-bugs" repo
<bjf> cnd, there is quite a bit of data that goes along with it
<cnd> bjf, what do you mean by that?
<bjf> cnd, i mean that the git repo is approx. 1GB due to the data+scripts
<cnd> whoa
<apw> ppisati, here is a config review matrix but with ti-omap4 included (based on the tip of the tree as of today)
<cnd> maybe I'll just copy the spec from the repo :)
<bjf> cnd, if you give me some idea what you are trying to do maybe i can give you a good suggestion
<cnd> bjf, so we have a handful of projects, like utouch-grail, utouch-geis, utouch-frame, etc.
<cnd> they are all subscribed by the utouch-bugs team
<cnd> then we manually subscribe bugs in other projects, like linux, that we care about
<cnd> what we want is a report showing all the bugs subscribed by utouch-bugs
<cnd> however, lp times out when you try to query that
<cnd> we can, however, list all the bugs in our projects
<bjf> cnd, there is other code that can do that
<bjf> cnd (i think)
<cnd> and then ask lp for all the bugs that we subscribe directly
<cnd> and then it doesn't time out
<cnd> so I'd like to create a report that does that for us
<apw> isn't that the old chesnut where you have to search in each series for all the open bugs with your criteria and manually merge the lists to get a real list
<ppisati> apw: where is it?
<apw> ppisati, https://wiki.ubuntu.com/KernelTeam/Specs/PreciseKernelConfigReviewBeta2omap4
<ppisati> apw: ok, i'll review it, thanks
<apw> ppisati, cool
<tgardner> ogasawara, am adding cw-3.3 to Lucid LBM. what a pain in the ass to build.
<ogasawara> tgardner: yah, lucid lbm takes forever
<ogasawara> tgardner: why you add 3.3 there?  should they upgrade to precise?
<tgardner> ogasawara, unless they hate unity
<tgardner> ogasawara, I already updated oneiric
<ogasawara> tgardner: I'll do precise
<tgardner> ogasawara, um, I think I did precise too
<ogasawara> tgardner: ah, so you have
<tgardner> ogasawara, which reminds me, I think I forgot to do precise meta
<ogasawara> tgardner: I can do that
<tgardner> ogasawara, works for me
<ogasawara> tgardner: although I think I crafted meta so that it should "just work", but I'll double check
<tgardner> ogasawara, "just work" ? how so ?
<tgardner> are you generating the flavour stub on the fly ?
<ogasawara> tgardner: in that I generically named it linux-backports-modules-cw-3.3-RELEASE_NAME-generic
<tgardner> ogasawara, but you still have to wave your magic wand over it....
<bullgard4> '~$ uname -r; 3.0.0.17-server' /var/log/boot.log: " * Starting network connection manager [OK]." Google: "Ergebnisse fÃ¼r "network connection manager" site:ubuntu.com: Keine Ergebnisse fÃ¼r "netork connection manager" site:ubuntu.com gefunden." What Process is here meant by Â»netork connection managerÂ«?
<ogra_> check in /etc/init/ ;)
<ogra_> (its likely the network-manager backend printing that)
<bullgard4> ogra_: I determined that it is the process NetworkManager the file /usr/bin/NetworkManager from the DEB program package network-manager. --  Thank you very much for your help. 
<ogasawara> hrm, cat ubuntu-precise/debian.master/d-i/modules/nic-modules | grep "ipw3945"
<ogasawara> ipw3945 ?
 * ogasawara assumes that's a typo
<tgardner> ogasawara, there are a couple of other wifi drivers as well; ipw2100, ipw2200
<tgardner> ogasawara, I don't think any of them are necessary
<ogasawara> tgardner: I was looking at bug 965116
<ubot2> Launchpad bug 965116 in linux "Precise Beta 1 Desktop Alternate CD does not enable Wireless on HP 8440p" [Medium,Confirmed] https://launchpad.net/bugs/965116
<tgardner> ogasawara, but there is no network manger running in the alternate installer, is there ?
<tgardner> ogasawara, none of the wifi drivers are in udebs, so I odn't think its a reasonable expectation to be able to update wirelessly during a d-i install
<ogasawara> tgardner: I'm seeing a commit from cjwatson in Oneiric stating that d-i now supports WPA
<tgardner> hmm
<ogasawara> commit 02adc47b87f8812c85bdbe64625f94f256bca875
<ogasawara> Author: Colin Watson <cjwatson@ubuntu.com>
<ogasawara> Date:   Thu Aug 11 01:01:53 2011 +0100
<ogasawara>     UBUNTU: Deliver more Atheros, Ralink, and iwlagn NIC drivers to d-i
<ogasawara>     
<ogasawara>     d-i now supports WPA in Oneiric.  While soliciting testing of this, I
<ogasawara>     heard from testers with Atheros, Ralink, and Intel AGN chipsets, none of
<ogasawara>     whom were able to test WPA support in d-i because the relevant drivers
<ogasawara>     weren't delivered to d-i.
<ogasawara>     
<ogasawara>     This patch adds these drivers to nic-modules or nic-usb-modules as
<ogasawara>     appropriate.
<tgardner> ogasawara, well then, why not any of the iwl* drivers? we'll also have to add some firmware to the linux-firmware udeb
<ogasawara> tgardner: good question, seems like we should add them
<ogasawara> tgardner: and I suspect the ipw3945 line already in nic-modules was really meant to be iwl3945
<tgardner> oh right. I forgot about the original quest :)
 * ogasawara whips up a few patches
<tgardner> ogasawara, that is indeed the right name: drivers/net/wireless/iwlegacy/Makefile:obj-$(CONFIG_IWL3945)	+= iwl3945.o
<Sarvatt> bcm43xx bcm43xx-mac80211 are obsolete too
<tgardner> ogasawara, so whatever drivers you add to nic-modules, make sure any related firmware is also in linux-firmware/debian/nic-firmware.lst
<ogasawara> tgardner: ack
<ogasawara> Sarvatt: I'll get them removed
<tgardner> ogasawara, and Sarvatt is right about b43*. they should be replace by the brcm80211 stack
<mjg59> b43 is still needed for SSB-based Broadcoms, no?
<mjg59> I thought the brcm80211 stack only handled the BCMA ones
<tgardner> mjg59, I thought there was PCI ID overlap. maybe tahts been fixed.
<mjg59> tgardner: There is, because b43 tries to claim some of the bcma devices as well
<tgardner> its been my experience that bcma is working better these days then b43. at least on the MacBook Air
 * ppisati -> EOD
<awe_> Sarvatt, got a sec for a build question?
<awe_> I'm trying to reproduce bug #953205 for cking
<ubot2> Launchpad bug 953205 in linux "System shuts down due to CPU temp exceeding critical thresh-hold (100C)" [Medium,Incomplete] https://launchpad.net/bugs/953205
<Sarvatt> whats up?
<Sarvatt> need a kernel build?
<awe_> I'm trying to load my system, so I figured I'd start a kernel build, however when I follow the instructions on the wiki, my build fails
<awe_> it's saying there's no rule for binary-generic
<awe_> I'm following instructions on: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
 * awe_ admits it's been a long time since he's built the kernel
<awe_> I grabbed the precise tree from bzr
<tgardner> awe_, 'fdr clean;dpkg-buildpackage -Tbinary -us -uc'
<Sarvatt> guessing you're starting from a git checkout? did you fakeroot debian/rules clean first? i'm kind of a bad person to ask specifically because i dont follow any of that and its very convoluted :)
<awe_> yes
<awe_> tgardner, right, that always should work... guess I was trying to follow the instructions since it's been so long
<awe_> tim?  when did you change your irc nick?
<tgardner> awe_, if you're wanting load, the dpkg-buildpackage does it the best
<awe_> cool
<awe_> yes, I want load
<tgardner> awe_, since someone registered rtg
<awe_> load == heat
 * Sarvatt didn't even know there were bzr branches of the kernel
<awe_> d'oh
<awe_> ;)
<awe_> thanks tgardner...  working like a charm
<tgardner> awe_, the wiki instructions look right. guess I'd better figure out whats wrong
<apw> Sarvatt, the package uploader braches one assumes
<awe_> ok
<tgardner> awe_, I should point out that 'fakeroot' is single threaded and won't allow processes to run in parallel. Hence the use of dpkg-buildpackage. it only uses fakeroot during the packaging phase.
<awe_> ok... good to know for future reference...
<apw> yep dpkg-buildpackage is fast cause it does debian/rules build; fakeroot debian/rules binary
<apw> which amortises the fakeroot cost in the safe area
<apw> you can do the same with 'debian/rules build-generic; fakeroot debian/rules binary-generic' 
 * apw decamps to the couch
 * ogasawara lunch
<tgardner> apw, is there a way to avoid the unknown RSA key message for a subnet? 
<tgardner> rtg@dearborn:~$ ssh ubuntu@10.0.2.131
<tgardner> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
<tgardner> @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
<tgardner> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
<tgardner> IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
<tgardner> Someone could be eavesdropping on you right now (man-in-the-middle attack)!
<tgardner> It is also possible that a host key has just been changed.
<tgardner> The fingerprint for the RSA key sent by the remote host is
<tgardner> 56:ae:dc:36:04:30:d4:12:f1:1d:22:e2:85:5a:81:44.
<tgardner> Please contact your system administrator.
<tgardner> Add correct host key in /home/rtg/.ssh/known_hosts to get rid of this message.
<tgardner> Offending ECDSA key in /home/rtg/.ssh/known_hosts:293
<tgardner>   remove with: ssh-keygen -f "/home/rtg/.ssh/known_hosts" -R 10.0.2.131
<tgardner> RSA host key for 10.0.2.131 has changed and you have requested strict checking.
<tgardner> Host key verification failed.
<mdeslaur> tgardner: add the following to your ssh config file:
<mdeslaur> Host 192.168.0.*
<mdeslaur>    StrictHostKeyChecking no
<mdeslaur> tgardner: and then promptly forget that someone from the security team told you to do that
<tgardner> mdeslaur, well, these are just for PXE booted machines that get reinstalled several times per day
<mdeslaur> tgardner: you may need UserKnownHostsFile /dev/null too
<mdeslaur> so you don't add it to your known_hosts all the time
<tgardner> mdeslaur, nope, I'll keep a special rule for 10.0.2.*
<kees> mdeslaur: heheh "and promptly forget..."
<mdeslaur> :)
 * tgardner -> EOD
#ubuntu-kernel 2012-03-29
 * smb yawns
 * apw yawns bigger
<smb> apw, Have you done any fresh installs recently?
<apw> smb, nope
<smb> Wonder whether it is just me, but the two I did yesterday (alternate 32/64 bit) just run into the "background only" problem after first boot... :/
<smb> (both i915)
<apw> smb, both alternate... that is the one QA tests no?  so you could ask them
<smb> It likely is as its relatively easy to pre-seed. Actually the 64bit install was a pre-seeded install, the 32 from a cd... Hm, since I did the latter late while watching TV I am not sure it was first boot or the one after upgrading (which would be more expected)
<gema> smb, that was a known problem for updates, not sure if we've encountered it yet on fresh installs
<smb> gema, Right, I asked on #unity and it seemd upgrade only
<smb> But it could be a similar issue (just not the same)
<smb> In my case it is not the black screen
<gema> it wasn't on the other either, it seemed like the background was on the front and everything else hiding behind, so to speak
<gema> smb: pete could actually type on his shell that was behind the background
<smb> Not sure I had one somewhere, but I could launch one with ctrl+alt+t
<jibel> smb, there are different type of corruption when compiz tries to load plugins that doesn't actually exist
<smb> According to didrocks its compiz removing unity from the config or so
<jibel> smb, one is the background being on the top layer
<jibel> smb, there is this one too, I got it on one of my machine
<smb> It sounds to match cause I would not see unity anywhere is ps ax
<jibel> smb, when you're logged in with the broken session, starts a terminal, run:  "gconftool-2 -g /apps/compiz-1/general/screen0/options/active_plugins" and check if unityshell is in the list
<smb> jibel, Thanks, I take a note and check next time I run into it. By now I forced those installs by unity --reset
 * henrix is back online!
 * ppisati notes that dding the preinstalled image on an sd takes FOREVER!!!
<ohsix> if you pick the right block size it can go quite a bit faster
<ppisati> ohsix: i remember reading about it
<ppisati> ohsix: but it's card dependant IIRC
<ohsix> yea, but the ones complying with the sd card spec generally have known page sizes and stuff
<ppisati> ohsix: the only thing that i know was a talk/article about sd card, sector size, spec compliance, etcetc made by abergman
<ppisati> ohsix: and he basaically said "almost all cards are fake, and if are not fake, they are lying on you"
<ohsix> basically SD cards are crap if they're not formatted with FAT in a special way that aligns the access with the sectors and stuff
<ohsix> oh yea, and there's that
 * tgardner -> appt. back in an hour
 * ppisati -> back in 10mins
 * ogasawara back in 20
<tgardner> herton, I pushed some hacks to fix the i386 FTBS in Lucid/Oneiric LBM
<herton> tgardner, ack
<tgardner> herton, I should probably get that fix (or the actual correct fix) upstream to Luiz
<henrix> tgardner: ack, will re-spin lucid -lbm
<ogasawara> apw, tgardner: I think beta freeze will be lifting relatively soon.  I want to start prepping an upload, anything else you want to push?
<tgardner> ogasawara, gobs of stuff. perhaps a new benet driver.
<tgardner> ogasawara, buts there is nothing to prevent us from uploading a couple of times between now and tuesday
<ogasawara> tgardner: indeed, I'm expecting at least one more upload after this
<tgardner> ogasawara, ok, we've already got a pile of patches in the hopper, so lets get them uploaded soonest. I'll get my bits in (or I won't).
<ogasawara> tgardner: ack
<henrix> tgardner: i see a new commit on oneiric lbm, but not on lucid
<tgardner> henrix, Everything up-to-date
<henrix> tgardner: hmm... ok, let me re-fetch it
<tgardner> henrix, top commit should be 'UBUNTU: undef CONFIG_OLPC'
<henrix> tgardner: yeah, i see that on oneiric
<henrix> tgardner: ok, got it now...
<tgardner> henrix, when I _know_ I want the upstream branch I always 'git fetch origin && git fetch origin $branch && git reset --hard FETCH_HEAD'
<henrix> tgardner: yeah, i though i did that, but probably i missed the reset on the lucid tree :)
<henrix> tgardner: sorry for the noise
 * ppisati -> back in a bit
<apw> [23200.722118] delay: estimated 133, actual 0
<tgardner> apw, perhaps the result of 'x86, tsc: Fix SMI induced variation in quick_pit_calibrate()' ?
<apw> tgardner, no ... seems it is my udb speakers ... sound/usb/endpoint.c:
<apw> tgardner, will whine at diwic when i hear from him next
<apw> tgardner, got a bug number for this encryp0ted disk thing
<tgardner> apw, hang on...
<tgardner> apw, bug #942846
<ubot2> Launchpad bug 942846 in linux "encrypted install fails to boot as long as vt.handoff=7 is used" [High,In progress] https://launchpad.net/bugs/942846
<apw> tgardner, this install from todays alternate seems to work ok as in i get the prompt, but i am not convinced it used handoff or not, it didn't feel like it
<apw> tgardner, i worry they have put a work around in already and i am not seeing it
<tgardner> apw, this is i915 GPU, right ?
<apw> tgardner, yes its i915, but its not going graphical in grub at the mo, which is odd
<apw> tgardner, will talk to cjw and see if they have changed anything
<tgardner> apw, ack
<smb> apw, Do you have the vt handoff in /proc/cmdline?
<apw> yeah its there, but... it didn't really feel like it was in a purple mode
<apw> tgardner, ahh it seems that we cannnot load the fonts etc to go graphical so handoff may be impossible in this scenario.  and saying we are doing it when we are not may not 
<apw> be right at all, investigating
<tgardner> apw, ok, I'm off to get some brain food
 * smb thinks he rather needs stomach food...
<apw> tgardner-lunch, you said in your case you had to take off splash, and only splash. /me will talk you through booting it when you get back
 * apw turns taxi-driver for a bit
 * tgardner does something similar
 * cking_ gives up chasing a stupid non-bug after the EC decides to suddenly work once he'd pulled out the AC and battery. Urgh!
 * cking_ -> EOD
 * ogasawara lunch
<tgardner> bjf, why is "Quirk for enabling backlight hotkeys on Samsung N510P" a (no-up) ?
<pgraner> jsalisbury, can you add this to the top 10
<pgraner> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/968520
<ubot2> Launchpad bug 968520 in linux "i915 GPU hang with WARNING: at /build/buildd/linux-3.2.0/drivers/gpu/drm/i915/i915_drv.c:413 __gen6_gt_wait_for_fifo+0x94/0xa0 [i915]()" [Undecided,New]
<pgraner> jsalisbury, I'm trying to reproduce since I have the same box
<tgardner> pgraner, looks like the GPU froze. it timed out after 5 msec
<pgraner> tgardner, yea, robbiew is also saying there are other video issues he's hitting now
<pgraner> [15:23] <robbiew> pgraner: I've also recently noticed resume doesn't always bring back my graphics (can ctrl-alt-f# to terminal)...I suspect that's related
<pgraner> [15:23] <robbiew> next time it happens I'll file a bug
<tgardner> pgraner, so, it _is_ dependent on udelay() which might be affected by "x86, tsc: Fix SMI induced variation in quick_pit_calibrate()". I wonder...
<pgraner> tgardner, ^^^^
<tgardner> pgraner, does he remember which version it started with ?
<pgraner> tgardner, he said recently, dosen't  remember exactly but within the last week or so
<tgardner> pgraner, that implies that it was happening with B2
<pgraner> tgardner, yea
<tgardner> apw, so the server encrypted LVM install is working fine for me. I'm pretty sure I did a desktop yesterday. lemme try that.
<jsalisbury> pgraner, will do
<jsalisbury> tgardner, should I ask robbiew to try disabling RC6 as a test?
<tgardner> jsalisbury, can't hurt
<jsalisbury> tgardner, ok, I noticed it's a Sandybridge
<tgardner> jsalisbury, he lives near a current bush
<apw> tgardner, i don't think you can do an encrypted install from a desktop cd ?
<apw> tgardner, oh you mean a desktop-alternate, ignore me
<tgardner> apw, I think you can from the alternate
<tgardner> apw, I'll have it installed in 20 mins or so
<bjf> tgardner: because the 'quirk' is already upstream as part of a much larger code refactoring.
<tgardner> bjf, ok, then while you're fixing the problem sforshee spotted, you should note that its a partial backport, blah, blah, blah
<bjf> tgardner: ack
<cking_> personally, I doubt it's RC6, it's had a lot of exercising lately, but you never know.
<tgardner> cking_, seems like its worth a try
<cking_> yep, it's easy to factor out
<tgardner> apw, I'll catch up with you tomorrow on the LVM encrypted desktop vt issue. I'm EOD
 * tgardner -> EOD
#ubuntu-kernel 2012-03-30
<zruty> Do I get a chance to edit the bug report before it gets sent?
<RAOF> zruty: You mean, when sending a report via apport?
<zruty> ubuntu-bug linux 
<RAOF> zruty: There is no report before it gets sent; what happens is the data gathered gets attached to the bug you create.  There is not a way to edit that data before you've created the bug, though.
<zruty> It collects all kinds of data which is fine, but does that also send what is the bug as experienced by me?
<zruty> Okay, then I think I will do it a little differently, hoping that actual bug data will be included in that report
<zruty> thanks!
<RAOF> You should always describe your bug in the report; although the data attached should be useful, it doesn't contain all the context that you can provide (like âthis happens each time I plug in my USB mouseâ)
<zruty> Yes exactly. And when I do ubuntu-bug linux I do not get a chance to add that before it gets sent
<zruty> So I think I better crate the bug and then snd the report. 
<zruty> After the bug gets filed, can I add to it? 
<zruty> In launchpad somewhere, was it?
<zruty> RAOF: ?
<zruty> Now I am getting 'Can not connect to crash database, please check your internet connection. <urlopen error [ErrNo8]_ssl.c:503:EOF occured in violation of protocol>
<zruty> Firefox can browse websites. 
<RAOF> zruty: Sorry.  You can add to a report after filing it; running âapport-collect $BUGNUMBERâ will attach all the information you would have got.
<RAOF> zruty: Hm.  You might want to try running ubuntu-bug again; maybe that error was transient?
<zruty> OK
<RAOF> What'll happen when you run ubuntu-bug is that it'll upload the data to a staging area and open a browser window at the "file a bug" page, with some of the fields pre-filled.
<RAOF> After you create the bug, the data in the staging area will be attached to it.
<zruty> Ah, that sounds good. 
<zruty> The upload progress bar is not moving.... 
<zruty> I have a running ping to my ISP's DNS server which replies nice and quick
<RAOF> That's odd.  Sorry, I don't think I'll be of much help.
<zruty> Now I get a ErrNo32 broken pipe
<zruty> I'll try it again another way
<zruty> Yes, now it is working
<zruty> Done. 
 * apw yawns
 * ppisati waves at apw
<apw> morning
<ppisati> moin
 * smb tries to open eyes...
 * jussi dumps a bucket of water over smb then hands him a coffee
 * smb appreciates the coffee but would rather have nicely warm water over and not in front of the keyboard... :-P
 * ppisati -> reboot
<cking> testing always takes me longer than I anticipate...
<apw> cking, testing is never anticipated ...
<davmor2> apw: does that not make you like the spanish inquisition?
 * apw smiles at davmor2
<davmor2> apw: I prefer the testing misquote from a popular Meatloaf Song... Object in the rear view mirror may appear more broken than they are.....
<apw> heh
<cking> tyhicks, you merged a bunch of my ecryptfs changes but seem to be missing the changes to allow for ext2, xfs and btrfs mount flags as well as a test for the clearing of ECRYPTFS_NEW_FLAG during truncate. can these be merged?
 * apw goes splash about
 * ppisati -> conf call
<tgardner> apw, what hacks did you want me to try on the encrypted LVM desktop ?
<apw> tgardner, ok so on the grub menu there is a bit ... /me gets the right wording
<apw> tgardner, set gfxpayload=$linux_gfx_mode which i'd like changed to =text
<apw> tgardner, and could you separatly retest to confirm removing vt.handoff=7 is not sufficient
<apw> tgardner, and finally both in combination, and let me know which work
<tgardner> apw, working on it....
<apw> tgardner, thanks
<tgardner> apw: some discussion of hyperv on LKML that you might find interesting, though it a difficult post to parse: "Linux on Hyper-V -- use hv_storvsc instead of ata_piix to handle the IDE disks devices ( but not for the DVD-ROM / CD-ROM device handling) Fw: [PATCH RFC] ata_piix: ignore disks in a hyper-v guest"
<tgardner> apw, oh, never mind. you're on the Cc:
<apw> is that that V<sometign> guy ... if so i have read and replied to them all
<smb> ogasawara, Are you planning to bundle up a new precise kernel today
<ogasawara> smb: I wasn't planning one for today, still finishing up yesterday's upload.  but I can if there is a fix you need uploaded.
<smb> ogasawara, There will be a fix but its not that urgent that it requires desperate actions. Just wanted not to miss the next upload by seconds. :)
<tyhicks> cking: Strange, I wonder how I missed those
<tyhicks> cking: I'm working on merging them now
<ogasawara> smb: I'll likely wait and upload again on Tuesday (which will be the last upload before Kernel Freeze)
<smb> ogasawara, Ok, that works for me
<tgardner> ogasawara, have you hassled anyone about NEWing your kernel? looks like itsready.
<apw> ogasawara, i have some hyper-v changes in testing as well which i would like in the tuesday one
<apw> tgardner, oh has powerpc finally made it
<tgardner> last I checked
<ogasawara> tgardner: yep, pitti new'd em for me earlier this morning
<ogasawara> apw: ack
<ogasawara> tgardner: and I've just uploaded lbm
<tgardner> ogasawara, hopefully I've fixed all the build failures in LBM
<ogasawara> tgardner: I did lbm test builds on amd64 and i386 and they all built ok
<ogasawara> tgardner: I was also going to upload linux-firmware if that's ok with you?
<tgardner> ogasawara, huh?
<ogasawara> tgardner: I added the brcm firmware to the nic-firmware.lst udeb
<tgardner> ogasawara, ah, ok - no problem
 * ogasawara assumes I have upload rights for linux-firmware... I guess I'll find out
<tgardner> ogasawara, you might not if you haven't done it for precise
<cking> tyhicks, thanks!
 * ogasawara back in 20
<tgardner> apw, as far as I can tell, the only thing that makes the LUKs prompt appear is by removing "splash". the password prompt _does_ however appear on VT 7 (which is not unexpected given the vt_handoff setting)
<tgardner> apw, I suspect the right thing to do for a LUKs install is to remove both splash and vt.handoff
<vanhoof> tgardner: ogasawara: also issues with luks + vt.handoff?
<tgardner> vanhoof, with an nVidia setup that I have
<vanhoof> tgardner: ogasawara: I was mulling over ideas of a creative way to not have vt.handoff added myself (for the cedarview/poulsbo case) where it also breaks things
<tgardner> vanhoof, seems that its only on the desktop install
<vanhoof> looks like a grub script looks for splash and adds vt.handoff by default
<vanhoof> just not sure of the proper place to make such a change, plymouth, grub, etc
<tgardner> vanhoof, dunno. could be a cjw question
<apw> vanhoof, why does it break things, or more specifically in ways does it break things
<vanhoof> apw: you never actually get to a login screen, why it breaks cedarview/poulsbo we're not sure yet
<apw> vanhoof, and whats the 
<apw> vanhoof, and whats the  bug number
<vanhoof> apw: all that magic is in grub2's ubuntu_vt_handoff.patch
<vanhoof> apw: theres a couple: 914311 and 899244
<apw> vanhoof, are they both binary only drivers ?
<vanhoof> apw: psb_gfx is not
<apw> and what is the total symptoms? b
<apw> black/purple/other?
<vanhoof> tseliot: ^^ what does it look like w/ vt.handoff added on cedarview?
<vanhoof> Sarvatt: ^^
 * vanhoof doesnt have one in hand to tell ya :)
<vanhoof> just know its broken :)
<apw> so very helpful indeed
<tgardner> apw, ogasawara: in the https://wiki.ubuntu.com/KernelTeam/Specs/PreciseKernelDeltaReview Rationale section we reference v3.1 in a couple of places. I think we should update it to correctly reference v3.2 (with an appropriate statistics update)
<tseliot> apw: not even Intel is sure as to why it breaks cedarview
<ogasawara> tgardner: ack
<ogasawara> tgardner: I'll rerun the scripts and update it
<tgardner> ogasawara, cool
<vanhoof> apw: on the machines we have, what we see is a long pause (from the purple screen) ~30-60 seconds, until it looks light lightdm respawns and takes over
<apw> so you just don't see plymouth?  you get bios, purple, lightdm
<tseliot> apw: cedarview hardware + psb_gfx = black screen, I'm not even sure vt.handoff matters. As for cedarview hw + poulsbo + vt.handoff = I don't think lightdm gets you to the desktop at all
<tseliot> but hey, maybe my machine is possessed by goblins ;)
<apw> vanhoof, have you tried disabling vesafb ?  vesafb._broken_=true or similar on the kernel command line
<apw> that might not interact well with the new drivers if they arn't KMSd correctly
<tseliot> apw: removing vesafb would automatically disable vt.handoff (which in turn depends on "splash"), right?
<apw> tseliot, nope not at all, it just a potential fallback when a drm driver isn't found quickly enough, and then we rely on vesafb to new driver handover to work properly
<apw> which its not been found to do well, and upstream said "don't do that, it smells"
<tseliot> oh
<apw> so it'd be good to know if vesafb is getting loaded when we might not want it to be
<tseliot> ok
<apw> and one way to find out is to disable it
<tseliot> vanhoof, apw: I guess if bug #944929 is fixed, then we can boot into a non garbled screen and then we can install my cedarview package which can disable vt.handoff
<ubot2> Launchpad bug 944929 in linux "psb_gfx boot hang on Atom N2600 (GMA3600 Cedarview)" [High,Triaged] https://launchpad.net/bugs/944929
<vanhoof> tseliot: yeah I was hoping there would be something like grub-gfxpayload-lists where we could blacklist certain devices vs adding vt.handoff by default for anything that sees "splash"
<apw> vanhoof, "for anything that sees splash
<apw> " ? what does that mean.  you can blacklist handoff for broken h/w in those -lists i believe
<vanhoof> apw: http://paste.ubuntu.com/907349/
<apw> vanhoof, i know what vt.handoff is i wrote the code for it, but i don't understand you "remove it for splash" comment
<apw> that makes no sense as they go together
<apw> if your board doesn't work with handoff you can quirk that i beleieve so grub won't supply it
<vanhoof> if you remove splash from /etc/default/grub vt.handoff is never added is what I was saying
<apw> they go together indeed, it makes no sense to handoff without splash
<tseliot> apw: how can you quirk it?
<tseliot> apw: using the splash works fine here, as long as there's no vt.handoff
<apw> right and thats not the depedancy its the other way, it makes no sense to handoff to splash when splash isn't there
<tseliot> right
<apw>     if hwmatch \${prefix}/gfxblacklist.txt 3; then
<apw> vanhoof, tseliot^^ that part there, that blacklist defines if you can use handoff, if not then it sets linux_gfx_payload to text which should stop the handoff being added i believe
<apw> cirtainly worth trying adding there to see if ti fixes things
<apw> ogasawara, i closed my penultimate work item
<ogasawara> apw: \o/
<tseliot> apw: wait, wouldn't that also block vesafb?
<apw> tseliot, no its unrelated to vesafb
<tseliot> apw: and set linux_gfx_mode to "text"?
<apw> tseliot, thats what the blacklist does, says 'keep' or 'text' which defines grubs part of handoff, whether it zaps the purple back to normal text, or stays graphical and uses handoff to maintain it through to splash
<tseliot> apw: http://paste.ubuntu.com/907360/
<apw> tseliot, ?
<tseliot> it's the whole patch
<apw> yes
<tseliot> apw: what I'm trying to say is that we need a graphical splash without vt.handoff, without having to switch plymouth's text plugin
<tseliot> apw: is this what you're suggesting too?
<apw> tseliot, no it just turns off handoff, the maintenance of purple until splash starts
<apw> that is what it does, and why its there, its for bust hardware which doesn't handle handoff
<apw> that osunds like your case to a tee
<apw> if that doesn't fix you up we need to work out why as it should
<tseliot> apw: ok, I think I know why I'm so confused about this. When I did it for Nvidia, it switched to text mode because Nvidia won't use the drm plugin. This driver, though, should use the drm plugin and avoid the whole handoff thing
<apw> tseliot, that is my expectation yes, now there is a hint that perhaps grub is not going to do quite what we intended, and if so we need to fix that or the kernels handling but that would be a bug
<tseliot> apw: ok, let me try here...
<apw> tseliot, thanks
<cking> bjf, looks like those two final changes were merged in ~1 hr ago
<apw>     sched: tg->se->load should be initialised to tg->shares
<bjf> cking, let me dbl check, i just pulled and seeing the same failures
<cking> lemme check too :-/
<bjf> cking, i see a mistake on my part
<cking> bjf, ah ;-)
<bjf> cking, stupid thing did what i told it not what i wanted
<cking> bjf, now isn't that simply annoying
<smb> cking, bzr is like tea on the heart of gold... very much like it but not the same
 * apw shares and enjoys a beer with smb
<cking> bjf, just tried it out, works fine for ext2, xfs, etc
<bjf> cking: yes, working better here as well
<cking> \o/
<cking> hrm 4 machines all busy doing s4 cycles, what fun
<apw> cking, time for a beer me thinks.  and you only have 40m left
<cking> yep
<apw> tgardner, if you boot with the default options (on your encrypted lvm configuration) does double tapping ESC from the blank screen work ?
<tgardner> apw, lemme try
<apw> tgardner, all sorts of variants of this issue are popping out the woodwork, likely all nvidia
<tgardner> apw, you're a genius
<tgardner> pops right up
<tgardner> it even accepts my password and boots right
<apw> tgardner, ok good then your issue is the same as the others ... good
<apw> tgardner, could you now try booting with plymouth:force-drm added to your command line
<tgardner> apw, still needed to hit <ESC> 
<apw> tgardner, ok thanks
<tgardner> apw, it looks like _without_ "sched: tg->se->load should be initialised to tg->shares" that load averages are much lower. dunno if thats a good thing, but I'm thinking not.
<apw> tgardner, its interactibility that matters, though the time to complete a known job is interesting
<apw> tgardner, perhaps this is a job for super-cking, he is very rigorous
<tgardner> apw, I can't tell any difference in interactivity
<tgardner> apw, I think he has all of his bits doing S4 testing
<apw> yeah i am sure ... we'll i'll add it to my list
<cking> yep, all my kit is glowing at the mo
<tgardner> apw, so I'm doing a build without that patch and load averages appear to level out around 70. I'm pretty sure I've seen averages in the 150-200 range prior to this
<apw> cking, heh ... i bet ... anyhow _you_ have 10m left
<cking> such interactivity must be somehow testable, but darned if I can think of a way to easily automate that
<apw> tgardner, that may be an accounting issue introduced by the patch though
<tgardner> apw, right, my suspicion as well. guess I should be timing
<apw> cking, well i'd think it would be things like "ask window to change, watch pixel till it does"
<apw> tgardner, yeah, i am hoping it might improves some of the interactibility issues i am seeing
<cking> here be the realms of subjectivity
<apw> once i finally get this lvm poo on a CD so i can test my radeon box, which won't boot from USB!?!?!?!
<apw> cking, well indeed, actually, latencytop is probabally the sort of thing we should defer to for interactibility
<tgardner> jsalisbury, herton: rebooting tangerine for kernel update
<jsalisbury> tgardner, ok, thanks for the heads up
 * cking calls it a wrap
<apw> tgardner, ok all my intel and radeon testing of encrypted LVM is 'good' and so a bust from fixing the bug
<tgardner> apw, hmm, well at least the workaround is simple.
<tgardner> on nVidia
<apw> tgardner, yeah, and we know what that does, it switches to text and back
<tgardner> apw, has anyone dropped that gem on Gema ?
<apw> tgardner, ... i think we might need some volunteers with nvidia to test so we can confirm its widespread with nvidia
<apw> if so, i think we need to switch off handoff for nvidia en-toto when encrypting
<apw> tgardner, heh ... not me
 * tgardner goes in search of brain food
 * apw wanders to find self some boozage
 * tgardner -> EOD
<kees> ogasawara: two patches for precise (related to seccomp) sent to the list.
<ogasawara> kees: ack
<ogasawara> kees: applied
<kees> ogasawara: thanks!
 * bjf -> heads off to give blood
<Wrostek> Im trying to compile a kernel with 'fakeroot debian/rules binary-headers binary-generic' after around 20 minutes, sub-make returns error 2 while compiling 'LD [M]  drivers/w1/wire.o' ... but there is no debug info... Is there a way to get the kernel build to be more descriptive?
<Wrostek> ( i would disable Dallas Wire from the config, but you cant, its either built in or module, and I dont know how to fix the problem without debug )
<Wrostek> after making a git clone git://kernel.ubuntu.com/ubuntu/ubuntu-precise.git , is it normal for the kernel build to not work?  I had to turn off quit a few things from the menuconfig, not it is making it as far as wire.o, but there is no option to disable that... Am i missing something?
#ubuntu-kernel 2012-03-31
<wrostek> Im trying to make a kernel bisect, but my compile is failing, and not outputting an error.. can someone tell me where the error is occurring? http://pastebin.com/Ms19YxMm
<wrostek> whoops i found it ndiswrapper way at the top
<wrostek2> Im trying to bisect a problem with my rt2x00 wireless drivers. In 3.0.0-16-generic oneiric it works, but in 3.1.0-1-generic precise it does not.   How do I get a git pull of changes between those kernels? they are on two separate repositories no?  git://kernel.ubuntu.com/ubuntu/ubuntu-precise.git and git://kernel.ubuntu.com/ubuntu/ubuntu-oneiric.git
<wrostek2> Im trying to bisect a problem with my rt2x00 wireless drivers. In 3.0.0-16-generic oneiric it works, but in 3.1.0-1-generic precise it does not.   How do I get a git pull of changes between those kernels? they are on two separate repositories no?  git://kernel.ubuntu.com/ubuntu/ubuntu-precise.git and git://kernel.ubuntu.com/ubuntu/ubuntu-oneiric.git
<ohsix> you can add the other one as a remote head
<ohsix> dunno how bisect will work with that, but they're like any other label afaik
<wrostek2> thanks
<pkh> i'm running a machine on 12.04 and the last few kernel updates have failed to find my network driver. i'm wondering what I should do wrt to reporting that.
<ohsix> is it an rt2x00 driver device?
<ohsix> there are a lot of people that have been talking about network drivers disappearing and stuff, if not the changelog for the kernel; there should be other people asking in bug reports
<pkh> k, will keep searching launchpad -- and add what info I can find there.
<wrostek> I have precise beta2 installed, can I run a 2.6 kernel?
<wrostek> The first commit in the git://kernel.ubuntu.com/ubuntu/ubuntu-precise.git is for a 2.6.0-r2 kernel, can I compile this and run it on my precise machine?
<wrostek> I Have to bisect test my r2x00 wireless drivers, they worked in oneiric, but not in precise.  I have the git://kernel.ubuntu.com/ubuntu/ubuntu-precise.git cloned, and tried to checkout from the very first commit ( to see if the earliest version in precise works ) but that version gives debian/rules: No such file or directory
<wrostek> Is there a trick to finding which commit in precise begins, and oneiric ends?
<wrostek> Precise git doesn't start where oneiric ends does it?
<ohsix> have you looked at git log from precise for the files related to your driver?
<wrostek> yes
<ohsix> when you say it doesn't work; how do you mean
<wrostek> and I tried compiling at points where those happened, but the problem still persistsâ¦ It works in oneiric 3.0.0-18-generic
<ohsix> describe "doesn't work" with the precise kernel
<wrostek> The wifi driver will work, but if I go to speediest and check the speed, it will get half way through the test, then stallâ¦.  I have to restart my network to get it running again
<ohsix> ok
<wrostek> sorry speediest ( speediest.net )
<wrostek> speedtest.net
<ohsix> you may find it easier to bisect linux-wireless
<ohsix> did you ask anyone if they knew about this problem already?
<wrostek> in oneiric it works fine, precise is broken..   So I checked out precise, I thought precise would start at a version where oneiric ends
<wrostek> Yes, they hadn't, and I created a bug in ubuntu https://www.google.ca/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&ved=0CD4QFjAD&url=https%3A%2F%2Fbugs.launchpad.net%2Fbugs%2F965043&ei=2rJ2T5y0D8ehgwer3dnTDg&usg=AFQjCNFHRs4kuBd6E1IcL1Enbb14B6r_vw&sig2=BDeONK-wyDkWkskMTANcgg&cad=rja
<wrostek> sorry
<wrostek> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/965043
<ubot2> Launchpad bug 965043 in linux "rt2x00 random stalls in AP Mode - 12.04 Beta 1" [Medium,Confirmed]
<wrostek> They asked me to bisect it, Im trying to find a good point in precise ( where the drivers work ) but so far nothing
<wrostek> I wanted to checkout precise to the very first commit in that repository, but that is a 2.6 kernel.. weird, I thought it would be like 3.0.18, ( like where oneiric ended )
<ohsix> well they're both copies of the same repo, with some stuff on top
<wrostek> So, in precise , should I be able to find 3.0.18 kernel?
<wrostek> Because I couldnt
<ohsix> there's no tag for it?
<wrostek> I greped for Ubuntu ( as in Ubuntu-3.0.18 )
<wrostek> no, they only have two tags
<wrostek> Oh, sorry more than two, but they start at Ubuntu-3.1.0-1.0 ( and I built that one and it didn't work, same problem )
<wrostek> How can I find the changes between oneiric ( 3.0.18 ) and precise ( 3.1.0-1.0 ) ?
<ohsix> get the commit hash for 3.0.18 in oneiric and use it as "good" in the precise tree, i dunno how to find the closest common commit but there are lots of common commits
<tdmackey> wrostek: there are plenty of ubuntu tags in precise
<tdmackey> maybe you didn't pull all the tags down
<wrostek> git log master -g --grep=Ubuntu-
<wrostek> that didn't pull them down?
<tdmackey> that doesn't pull down anything
<wrostek> ( sorry I'm kind of new at this )
<tdmackey> git tag -a will list all the tags
<tdmackey> or just git tag rather
<wrostek> oh cool,
<tdmackey> then you can to a git checkout <tagname>
<tdmackey> and build from there
<wrostek> ok thanks
<tdmackey> I wouldn't start at the first tag, I'd start at the last known good tag.
<wrostek> i will try this
<tdmackey> unless you've never run precise before, then you're out of luck I guess.
<wrostek> I think it is v3.0-rc7 ( i think thats the last oneiric )
<wrostek> thanks tdmackey
<tdmackey> yeah, I'm just saying going in order will take a long time. Binary search is a better approach if you have no other knowledge as to a decent version.
<tdmackey> wrostek: also of note, if you look at the top of the tag list youll see the ubuntu-version tags. the non-ubunutu tagged points are the vanilla kernel tags. 
<ohsix> you can still just bisect net/ or net/wireless plus your driver too
<wrostek> Maybe, I think they were giving me the impression the problem may be somewhere else than the driver though
<ohsix> did you already see git log 3780d038fdf4b5ef26ead10b0604ab1f46dd9510 ?
<wrostek> Is that about stalled rt2x00
<ohsix> yes, from march 9th
<wrostek> Yes, that did not fix this problem it was weird, 
<wrostek> I think that guy needs to take another look
<ohsix> the log entry is pretty concise
<ohsix> http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2012-March/004651.html
<wrostek> Yes,  I mentioned that in my bug report, ( and that fix is already in the precise rt2x00 drivers in beta1 ) but it did not help https://bugs.launchpad.net/ubuntu/+source/linux/+bug/965043
<ubot2> Launchpad bug 965043 in linux "rt2x00 random stalls in AP Mode - 12.04 Beta 1" [Medium,Confirmed]
<ohsix> i didn't suggest it solved your problem, but that you may contact him
<ohsix> or respond to the thread
<wrostek> One question, is Ubuntu-3.0.0-1208.19 later than Ubuntu-3.0.0-13.21
<wrostek> Yes, I was thinking about it, but I don't know how much spam he gets already from people with driver issues
<ohsix> -13 is later
<wrostek> thansk
<wrostek> thanks
<dileks_> hi
<dileks_> I have installed precise-beta1 and updated to recent kernel
<dileks_> this is linux-image-3.2.0-21-generic (3.2.0-21.34)
<dileks_> (also I did all other software updates)
<dileks_> I installed via wubi on an existing win7 partition on samsung series-5 ultrabook
<dileks_> on shutdown the machine freezes
<dileks_> I have to power-off via power-button
<dileks_> (I had no look into syslogs, yet)
<dileks_> with 3.2.0-17.27 and 3.2.0-20.33 kernels I am not aware I had this new issue
<dileks_> any known issue?
<dileks_> I can paste dmesg and more if this helps you
<dileks_> dmesg: http://paste.debian.net/161537/
<kklimonda> AceLan: ping
<kklimonda> AceLan: just heads up, the patched kernel from bug 969576 fixes one oops but creates another ;)
<ubot2> Launchpad bug 969576 in linux "BUG: unable to handle kernel NULL pointer dereference at (null) [asus_wmi_rfkill_init]" [Critical,In progress] https://launchpad.net/bugs/969576
 * popey wonders what our btrfs support is like in 12.04.
<AceLan> kklimonda: >_<
<AceLan> kklimonda: I just add a comment, and it's 4/1 here, I really hope you're joking me 
<kklimonda> AceLan: no, it's still 31/3 in Europe ;)
<kklimonda> AceLan: ok, I've attached both lsmod and dmesg from 3.2.0-20
<AceLan> kklimonda: thx
<AceLan> kklimonda: i got the bug, compiling the new kernel
<kklimonda> AceLan: great, thanks - any idea if it's somehow related to the fact that I don't get neither X nor terminal o 3.2.0-21? ;)
<kklimonda> unless I boot into the rescue mode and then select "continue" from the recovery screen
<AceLan> kklimonda: I think the asus-wmi module lead the system hang, so there is no X nor terminal
<AceLan> kklimonda: rescue mode may not load any kernel module, so it works
<kklimonda> AceLan: hmm, no - I get the oops in the rescue mode
<kklimonda> AceLan: so at least in the rescue mode it doesn't hang
<AceLan> @_@
<kklimonda> oh well, if it keeps happening after this bug is fixed I'll just report a new one :)
<AceLan> no~~~~~~~~~, it won't happen again
<kklimonda> that's the spirit! ;)
<AceLan> kklimonda: http://people.canonical.com/~acelan/bugs/lp969576/2/ # new kernel
<AceLan> kklimonda: I'm wating your result, so that I can fall asleep with smile :)
 * AceLan bites kklimonda 
<kklimonda> AceLan: I'm already rebooting ;)
<AceLan> kklimonda: hehe
<kklimonda> AceLan: mm, everything looks fine
<AceLan> yooooooooooooooooooooo
<kklimonda> no oops, and I got lightdm
<AceLan> kklimonda: cool
<AceLan> kklimonda: time to sleep, bye~
<kklimonda> AceLan: good night :)
<ohsix> anyone have some idea what a high delay for "creating block layer request" in latencytop might indicate what is going on, and what i can do about it
<ohsix> ah, it may be fuse related; but it destroys other disk io when it happens
#ubuntu-kernel 2012-04-01
<beata|lemur> Is there a way to update a local git tree from one release to the next? Or would it be recommended to start over with a fresh clone? I'm using the tree to support a device-specific custom build.
#ubuntu-kernel 2013-03-25
 * apw yawns
 * apw yawns
 * ppisati hands apw some coffee
 * apw bites your hand off :)
<ppisati> brb
<ppisati> every time i send a patch upstream i tend to create new and creative ways to bork it...
<cking> ppisati, practice makes perfect I suppose
<ppisati> cking: right :)
<zequence> apw: both kernels ready at ppa:ubuntustudio-kernel/linux-lowlatency-sru
<apw> zequence, ta
<zequence> apw: Should I do the metas too?
<apw> you should, do you know what to do there?
<apw> it is a matter of making a new section with the right numbers
<apw> in debian/changelog ... typically for lowlatency i have _not_ had a git repo for the metas
<apw> as it is not worth it, i just get the one from the archive with pull-lp-source, edit it, and dpk-buildpackage -S
<zequence> I was suspecting as much. Alright, I'll prepare them in a moment
<apw> zequence, if you want to make a debdiff and pastebin it, i can verify
<apw> though they are very simple :)
<zequence> apw: sure
<zequence> apw: http://paste.ubuntu.com/5646132/
<apw> why do you have a nochange on ther ?
<apw> and your diff is backwards ?
<apw> zequence, ^^
<zequence> apw: I set the release to raring the first time I uploaded
<zequence> So, I rebuilt
<apw> ahh ... doh
<apw> zequence, you'll need to be careful about that one ... you can wreck your PPA and have to dlete it to recover
<apw> if you get the series wrong in the wrong way, a later one is probabally ok
<apw> and previous one, and all bets are off
<apw> zequence, so on your nochange you really should have used -v like for the main kernel
<apw> you should use -v always really
<zequence> apw: Ok. This is quantal http://paste.ubuntu.com/5646142/
<zequence> apw: So, I'll do another nochange build, with -v<previous-published-release>?
<apw> zequence, i guess so yes ... it is all a learning experience
<apw> zequence, the other one looks great
<zequence> apw: O/win50
<zequence> sorry :P
<apw> heh i do that all the time tooo
<zequence> apw: all uploaded. let me know if I should do anything else
<rtg_> cking, jsalisbury: rebooting gomeisa for kernel update
<rtg_> AceLan_, jjohansen: rebooting tangerine for kernel update
<jjohansen> rtg_: ack
<ppisati> apw: when yuo have time, can you point me to the script you use for the config review? thanks
 * ogasawara back in 20
 * henrix -> *really* late lunch
<apw> ppisati, kteam-tools.git ... devel ... devel-config-sumarry --html ubuntu-raring outprefix>
<apw> ppisati, kteam-tools.git ... devel ... devel-config-sumarry --html <ubuntu-repo> <outprefix>
<bjf> apw, heads-up, quantal and precise kernel respins are coming
<apw> bjf, again ... sigh
<rtg_> apw, can you have a look at raring unstable-3.9 to determine why aufs-update mis-applies aufs3-standalone.patch ? it appears to _not_ get the patch to '+EXPORT_SYMBOL(iterate_mounts);' correctly, causing build failure.
<apw> rtg_, will do
<rtg_> apw, thanks, back in a few
<ppisati> apw: thanks
<apw> rtg_, ok ... just rememberd the base and standalone patches arn't updated with the current script, i've just done them by hand and all builds ok
<tseliot> apw, cking: do you have any ideas as to what could be causing rfkill to report my wireless card as "Hard blocked"? (the card is enabled in the BIOS)
<apw> rtg_, as this builds i'll push it anyhow
<rtg_> apw, ack
<rtg_> apw, what did you have to so beyond running the aufs-update script ?
<rtg_> to do*
<apw> rtg_, i just manually reverted and reapplied t
<apw> the two anciallary patches
<apw> they so rarely change once -rc2 is past the script doesn't track them
<apw> maybe it should
<apw> in the past they used to have to be wiggled cause they collided with overlayfs, but that seems to not happen now
<apw> which can only be luck
<rtg_> apw, I'm trying to get sbuild to run with the 3.9 kernel. it insists on having overlayfs and aufs.
<apw> it should only need one or the other i would have thoruhg
<apw> it seems odd to need both
<rtg_> kind of what I thot
<cking> tseliot, which card, driver and kernel are you using?
<cking> hard to guess w/o being specific..
<tseliot> cking: I'm using Broadcom's proprietary driver and here's the rest of the data: http://pastebin.ubuntu.com/5646858/
<cking> tseliot, hrm, is there some physical switch to toggle?
<tseliot> cking: no, I don't see any
<cking> what machine is it?
<apw> tseliot, have you tried toggling it with rfkill, i assume that fails
<tseliot> apw: yes, nothing changes
<tseliot> cking: it's a Lenovo B475e
<cking> tseliot, just curious, but does Fn+F5 do anything?
<tseliot> cking: it switches "Soft blocked" in rfkill but that's it
<tseliot> it's always Hard blocked
 * cking running out of ideas
<rtg_> apw, hmm, sbuild seems to be happy now since your aufs update.
<apw> rtg_, odd
<rtg_> apw, well, I'm good with it.
<apw> heh
<tseliot> cking, apw: it seems to be a driver regression...
<apw> tseliot, as in the binary drivers have regressed
<cking> oh joy
<tseliot> :)
<ogra_> tseliot, did that laptop run windows recently ? 
<tseliot> ogra_: I have no idea. They shipped it to me last week
 * ogra_ remembers a bunch of bcm cards that get into a completely locked state by the windows driver, you can only get them unlocked by using the windows driver again
<cking> bet you can faff with the nvram settings to coerce it back
<tseliot> loading the previous driver seems to unlock it
<ogra_> ah
 * ppisati -> workout
<ppisati> later
 * rtg_ -> lunch
<rtg_> bjf, 'causes the hand of cartridge' seems ungrammatical in bug #1159863
<ubot2> Launchpad bug 1159863 in linux (Ubuntu Quantal) "udevadm info --attribute-walk command hangs on Marvel 9125 controller" [Undecided,In progress] https://launchpad.net/bugs/1159863
<bjf> rtg_, fixed
<rtg_> tanks
<jdstrand> jjohansen: hey, sorry to bother you-- I was looking at CVE-2013-1858 and it seems that only kernels that have CLONE_NEWUSER are affected, no? the CVE in the tracker is missing the 'break' bit of 'break-fix' which is why, for example, hardy is marked as affected
<jdstrand> jjohansen: iiuc
<jdstrand> jjohansen: hmm, maybe not, I see that on precise we have CONFIG_USER_NS=y
<jdstrand> jjohansen: that said, https://bugzilla.redhat.com/show_bug.cgi?id=917708#c5 seems to suggest that 5eaf563e53294d6696e651466697eb9d491f3946 is the candidate for 'break'
<ubot2> bugzilla.redhat.com bug 917708 in kernel "Re-enable CONFIG_USER_NS" [Unspecified,New]
<jjohansen> jdstrand: hrmmm, I'll have to look at it closer but yeah my guess is me need to fill in a commit where this starts causing problems, hardy certainly should not be affected
<jdstrand> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5eaf563e53294d6696e651466697eb9d491f3946
<jdstrand> jjohansen: I'm happy to update the CVE to use 5eaf563e53294d6696e651466697eb9d491f3946
<jjohansen> jdstrand: be my guest :)
<jdstrand> jjohansen: ok, once I do, can you do/coordinate the magic to update the CVE?
<jdstrand> jjohansen: it is a 'high', which is why I am in your hair (again, sorry about that)
<jjohansen> jdstrand: well there shouldn't be much to coordinate, if all goes well it should work automagically
<jdstrand> jjohansen: ok, cool
 * ogasawara lunch
 * rtg_ -> EOD
#ubuntu-kernel 2013-03-26
<ppisati> moin
<smb> moin
<ppisati> brb
<apw> zequence, did you see there is yet another respin ?
<apw> zequence, also which is the latest version you have tested ... just so we can work out which ones can be released
<zequence> apw: I usually don't test until they end up in -proposed, so for this ABI, no tests so far
<zequence> I'll build new ones this evening
<zequence> apw: Doesn't seem like people are getting assigned as usual. I've marked the eariler bug reports as duplicates. bug #1160196
<ubot2> Launchpad bug 1160196 in Kernel SRU Workflow "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1160196
<zequence> ..to these
<zequence> bug #1160182
<ubot2> Launchpad bug 1160182 in Kernel SRU Workflow "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1160182
<apw> zequence, marking dup, that seems appropriate ... henrix, bjf, sounds like shankbot may not be assigning things right
<apw> zequence, sounds good, poke me when they are done and i'll get them copied out, before they can find an issue with them this time
 * cking grabs some nosh
 * smb is surprised to find that in the dictionary
<rtg_> smb, makes me think he's grabbing something out of a bucket
<smb> rtg_, Apparently (according to my dictionary at least) it seems to be something you (Americans) invented for a snack. But then nosh-up seems to mean the opposite (of small)
 * ogra_ thinks that fits well and points smb to http://www.addedbytes.com/blog/if-php-were-british/
<ogra_> :)
<smb> ogra_, Its not as if the UK folk would not slam in new words into their language if they feel like it. ;) 
<ogra_> heh
<ppisati> rtg_: wait with the phablet kernel
<ppisati> rtg_: i misread the email
<rtg_> ppisati, ack
<ppisati> ppisati: the brightness bug was on the desktop img
<ppisati> rtg_: &
<ppisati> argh
<ppisati> ^
<ogra_> iirc the plan was to use the same kernel on both 
<ogra_> but we dont have a proper plan how to upgrade it on phablet yet 
<rtg_> cking, smb, henrix: need to reboot gomeisa for kernel and SSL update
<henrix> rtg_: can it wait 1 min? my build should be finish soon
<ppisati> ogra_: and it uses a separate partition where we can't write, right?
<rtg_> henrix, yep, just lemme know
<henrix> rtg_: will do
<henrix> thanks
<smb> rtg_, I am off
<ogra_> ppisati, theoretically it shouldnt differ much so abootimg on /dev/mmcblok0p2 should work to just update it ... but nobody tried yet
<ppisati> ogra_: no i mean
<ogra_> */dev/mmcblck0p2
<ppisati> ogra_: i flash my nexus, ssh into it
<ppisati> ogra_: can't i mount it?
<ogra_> mount ?
<rtg_> ppisati, jjohansen: bouncing tangerine for kernel and SSL update
<ppisati> rtg_: ack
<jjohansen> rtg_: give me 30s
<ppisati> ogra_: ok, redo from start
<rtg_> jjohansen, ack
<jjohansen> rtg_: okay I'm good
<ppisati> ogra_: where does the kernel reside?
<ogra_> ppisati, to update the kernel on desktop we run "abootimg -u /dev/mmcblk0p2 -k /path/to/vmlinuz"
<henrix> rtg_: ok, i'm off gomeisa
<ogra_> from flash-kernel
<ppisati> ogra_: ok
<ogra_> ppisati, to update on phablet we should theroetically be able to do: "abootimg -u /dev/block/mmcblk0p2 -k /path/to/vmlinuz"
<ogra_> but practically nobody tested that 
<ppisati> ogra_: since the bootloader is untouched, there's no bricking risk, right?
<ogra_> right, but check with abootimg -i if /dev/block/mmcblk0p2 is actually the right partition
<ppisati> ogra_: i'll do
<ogra_> (flash-kernel loops over all devices with abootimg -i to find teh biggest one and then flashes to that)
<rtg_> tangerine is back
<bjf> apw, shankbot fixed (i broke it with my previous change)
<rtg_> ogra_, is there a trick to getting adb to talk to an N7 running 4.2.2 ?
<ogra_> rtg_, https://wiki.ubuntu.com/Touch/Install#Step_3_-_Initial_Device_Setup ... see step 2 and the different suggestions there 
<ppisati> rtg_: usb debugging?
<ogra_> 4.2.2 adds a silly host key check to the process
<rtg_> ppisati, how to enable USB debugging in that Android version ?
<ogra_> and they have hidden the developer options 
<ppisati> rtg_: tap 7 times in a row on the release version field
<rtg_> ah, both 4.1 _and_ 4.2 require this
<ppisati> rtg_: in... settings -> ... status?
<ogra_> right
<ogra_> it tells you "now you are a developer" if you did it right ... 
<ppisati> right
<ogra_> if you dont, you will never be a developer :''(
<ppisati> then go back one level, enter the developer menu and enable usb debugging
<cking> the magic 7 taps is a fun hidden feature
<rtg_> ok, got that far
<rtg_> alright, phablet-flash appears to be working
<gQuigs> I can't seem to find documentation on the Ubuntu 10.04 Kernel Backports; the best I could find was http://askubuntu.com/questions/29961/why-are-only-some-versions-of-the-kernel-backported-to-certain-releases
<gQuigs> specifically I'm wondering if support for the 3.0 kernel ends in April with Oneiric 
<ogasawara> apw, rtg_: so beta freeze is on Thurs and I see ppisati has sent his highbank pull request.  I'm thinking we get ppisati's pull request applied and upload today or tomorrow.  Thoughts?
<bjf> gQuigs, yes it does end in April with Oneiric
<rtg_> ogasawara, I'm in the middle of it
<ogasawara> rtg_: sweet
<rtg_> ogasawara, I'm a sweet guy :)
<rtg_> ppisati, am looking at your highbank patch. it appears we can drop the highbank flavour and load the OF enabled common kernel on the highbank platform ?
<ppisati> rtg_: right
<ppisati> rtg_: i wanted to send a patch later to axe the highbank flavour
<rtg_> ppisati, cool, then I'll rip out the highbank cruft from the tree as well
<ppisati> rtg_: but if you want to do that now, go ahead
<rtg_> ppisati, I assume I can set CONFIG_SATA_HIGHBANK=n for x86'en ?
<ppisati> rtg_: i guess so
<rtg_> ppisati, its na OF driver. I don't think thats supported on x86, right ?
<rtg_> its an*
<ppisati> rtg_: yep
<ppisati> rtg_: at least until highbank is arm based :)
<rtg_> ppisati, you mean, "at least as long as highbank is arm based"
<ppisati> rtg_: yes
<rtg_> ok
<ppisati> apw: besides, i was using your tool to do a cfg review
<ppisati> apw: and a) i'm doing something stupid or b) there's something wrong with our cfg/flavour setu
<ppisati> apw: since i got: 
<ppisati> apw: amd64-generic - armhf-armhf - armhf-generic - armhf-highbank - i386-generic
<ppisati> apw: notice the second one
<ppisati> apw: ok, i just updated kteam-tools (fetch & rhard), and i think it's broken
<ppisati> apw: http://paste.ubuntu.com/5649520/
<ppisati> apw: '/home/flag/git2/.../'
<gQuigs> thank you bjf
 * ogasawara back in 20
<gQuigs> bjf: is that written down somewhere?
<bjf> gQuigs, i'm sure it's in the wiki somewhere but I can't point you at it right off the top of my head
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<rtg_> apw, can you take a pass through the Raring enforcer and annotations to harmonize them wrt dropping highbank and omap
<robher> ppaisati, rtg_: btw, for highbank you need to revert "UBUNTU: SAUCE: arm highbank: add support for pl320-ipc driver" and there is a SATA fix needed to avoid matching the ahci_platform driver. I can send a patch for the latter.
<rtg_> robher, sooner is better please
<robher> rtg_: okay. Now that things seem to be moving I'll review the config and provide anything else I find. I do also need to add cpufreq driver that went into 3.9.
<rtg_> robher, note that beta freeze is thursday, so it would be great if you could get that done soonest.
<robher> rtg_: should be all doable by today or tomorrow.
<rtg_> ack
<rtg_> robher, what is the name of the cpufreq driver ? perhaps I can work on cherry-picking it whilst you are looking at other stuff.
<ppisati> ogra_: mmcblk0p1 is the biggest, so that should be
<robher> rtg_: git log --oneline -6 74c46c6
<robher> plus "091930a mailbox, pl320-ipc: remove __init from probe function"
<ppisati> robher: btw, do you know that there's a problem with reboot?
<robher> ppisati: this is the bug from 3.5?
<ppisati> robher: don't know where it comes from
<ppisati> robher: but i know 9 out of 10 times, when i issue a reboot
<ppisati> robher: using a 3.8 kernel
<ppisati> robher: it gets stuck at the end
<ppisati> robher: didn't debug it yet
<robher> ppisati: hadn't seen that. there had been some intermittent problems, but those were more like 1 out of 10 and I thought I'd fixed all of them. I'll look into it.
<rtg_> robher, rebased 'UBUNTU: SAUCE: arm highbank: add support for pl320-ipc driver' et al out of existence and cherry-picked the patches you requested. pushed +master-next
<ppisati> rtg_: about the R/omap4 kernel, what do we do? shall i send a pull req to sync it with Q or do we just copy the package from Q to R?
<rtg_> ppisati, I think that is a good question for infinity. are we ever gonna touch omap4 again ?
<rtg_> ppisati, AFAICT the raring ti-omap4 branch has never been used, right ?
<ppisati> rtg_: never touched it
<ppisati> rtg_: it's an old Q/omap4 kernel
<rtg_> right, still stuck on 3.4
<ppisati> rtg_: but i think R/omap4 desktop images are generated out of it
<rtg_> ppisati, generated from the Q kernel ?
<ppisati> rtg_: yeah, since they need the pvr kernel module to work (unity 3d opengl etcetc)
<rtg_> ppisati, so I guess the issue is what if we ever change the Q kernel ? The Q kernel won't get auto-synced into R
<rtg_> ppisati, rmadison linux-ti-omap4
<ppisati> ogra_: my kernel update didn't go as expected
<ppisati> ogra_: first i 'abootimg -u .../mmcblk0p1 -k vmlinuz', rebooted
<ppisati> ogra_: but i still had the old one
<ppisati> ogra_: so i thought "maybe is mmcblk0p2"
<ppisati> ogra_: redo
<ogra_> what was the output of abootimg doing that ?
<ppisati> linuz-3.1.10-10-nexus7 ablet# abootimg -u /dev/block/mmcblk0p2 -k foobar/boot/vm
<ppisati> reading kernel from foobar/boot/vmlinuz-3.1.10-10-nexus7
<ppisati> Writing Boot Image /dev/block/mmcblk0p2
<ogra_> (and also the output of abootimg -i )
<ppisati> ogra_: for both p1 and p2
<ogra_> hmm
<ppisati> ogra_: anyhow, i ended up in cynogen recovery
<ogra_> we probably need to update abootimg 
<ogra_> might be that 4.2.2 needs a newer version of it or so
<ppisati> ogra_: let me tinker with it a bit more
<ogra_> ok, i'll jump on it myself around the weekend ... currently i'm busy convincing the amd64 livefs builder to produce pahblet android cross built images
<ogra_> that will keep me busy until friday
<ppisati> ogra_: ok so, the correct partition is mmcblk0p2 since it's LNX
<ppisati> ogra_: p1 is recovery
<apw> rtg_, will do indeed
<apw> rtg_, given i have been playing with that across n7 today, it is all shiney and fresh in my mind
<rtg_> apw, there are a number of references to omap, etc that are no longer appropriate
<apw> rtg_, now to work out why i am not being given notifications in irc any more
<rtg_> no flashy thingy ?
<jsalisbury> apw, fyi, commit 3e8f4f40 fixed bug 1157952 but it introduced other errors, posted in comment #19
<ubot2> Launchpad bug 1157952 in linux (Ubuntu) "SCSI keysense errors on console with Raring (3.8 kernel) within Windows Azure" [High,Incomplete] https://launchpad.net/bugs/1157952
<apw> jsalisbury, heh ... oh so typical of that lot
<apw> rtg_, yep will 'redo' the review and sort them out
<apw> rtg_, indeed i have no OSDs fro irc all of a sudden, strange thing
<apw> ppisati, i take it the armhf-generic is bootable on omap4 as it is currently
<ppisati> apw: yep
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
 * ppisati goes to find some food, later
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues April 2nd, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<apw> rtg_, ok ... initial fixups for arm -generic etc pushed ...
<rtg_> apw, ack
<apw> there are some bits which need investigation which i'll poke next
<apw> ppisati, know of any reason we cannot enable CONFIG_SERIAL_8250_DMA on armhf -generic ?
<rtg_> apw, ACPI was an issue, but I think there is a patch for it
<zequence> apw: I'm a little confused on versions. pull-lp-source pulls 3.5.0-26.28, but when I look here https://launchpad.net/ubuntu/+source/linux-lowlatency, it seems it's still in proposed. What's the best way to check which is the last released kernel? I'm about to build quantal and need to know which version I should use (suddenly, I'm not that confident on this)
<zequence> I mean, which version I should use for the -v argument..
 * rtg_ -> lunch
<apw> zequence, for -v you can use 'rmadison -a source linux-lowlatency' which will show you the versions in alll pockets
<apw> linux-lowlatency | 3.5.0-25.25 | quantal-security/universe | source
<apw> linux-lowlatency | 3.5.0-25.25 | quantal-updates/universe | source
<apw> linux-lowlatency | 3.5.0-26.28 | quantal-proposed/universe | source
<apw> zequence, for exasmple that is quantals entries which shows -25.25 in -security and -updates, and -26.28 in -proposed
<apw> ppisati, CONFIG_USB_MUSB_HDRC is marked as =y (boot essential on omap) but is m on -generic, any issues or shall i lose the annoataion
<apw> ppisati, CONFIG_EXT2_FS isn't that 'flash-kernel essential' on arm ?
<apw> ppisati, let me knwo on those and i'll get them cleaned up
<zequence> apw: kernel sources ready
<ppisati> apw: loose annotation on MUSB
<ppisati> apw: vfat is essential on omap
<ppisati> apw: ext2 might be essential on imx6, lemme check
<rtg_> ppisati, did you figure out the magic runes for updating an N7 kernel after installing the touch image ?
<ppisati> rtg_: not yet
<ppisati> rtg_: 'abootimg -u /dev/block/mmcblk0p2 -k vmlinuz' should be enough
<ppisati> rtg_: but it's not :P
<rtg_> hmm, too bad. it seems like it wuold be rightr
<ppisati> rtg_: rtg_ i'll give it another shot later
<rtg_> ppisati, ok, it'll come in handy for testing where one doesn't wanna reinstall the whole image (nor make one from scratch)
<ppisati> apw: ok so, ext2 is not mandatory for imx6
<ppisati> apw: but on highbank, /boot is uses it
<ppisati> apw: actually we can mount using ext3 on it
<ppisati> apw: so it's either ext2 or ext3
<ppisati> apw: uhm no
<ppisati> apw: it's really ext3
<ppisati> apw: /dev/sda1       /boot           ext3    defaults        0       2
<ppisati> apw: i think you can turn off ext2 and leave ext3 compield in
<rtg_> CONFIG_EXT2_FS=m
<rtg_> which looks OK
<apw> rtg-afk, yep, it is the annotations which are wrong in that case, ppisati lets catch up in the morning :)
 * ogasawara lunch
<mdalacu> Hi, how can i report a kernel bug, if it does not boot? Can someone help me? I have read the guidlines, but it is very difficult for me to follow them.
<mdalacu> The problem is simple, i can't boot with IOMMU option in BIOS active with any kernel above 3.7 version. It drops to busybox.
<jsalisbury> mdalacu, Can you boot from a LiveCD, or a prior kernel, or even with the IOMMU option disabled?  You should be able to report a bug with 'ubuntu-bug linux' if you can boot with one of these three options
<infinity> apw: BenC fixed the ACPI/CONFIG_SERIAL_8250_DMA conflict in linux-ppc.  If that's not upstream, you might want to cherry-pick from him.
<mdalacu> With kernel version 3.6 and oneric kernels i can boot raring just fine. Any raring live cd with IOMMU disabled boots fine.
<BenC> infinity: rtg said he was grabbing it, IIRC
<BenC> It is upstream
<infinity> BenC: Ahh, cool.  Check.
<mdalacu> I have already reported the bug, but this is as far as i can go...
<mdalacu> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1159219
<ubot2> Launchpad bug 1159219 in linux "Ubuntu Raring , IOMMU, fails to boot" [High,Triaged]
<jsalisbury> mdalacu, ok, I've seen that bug.  I can perform a bisect to identify the commit that introduced the regression in 3.6.  I'll post some comments to the bug.
<mdalacu> Thank you , should i post any new files to that bug, a dmidecode or something?
<rtg_> BenC, 'serial: 8250_dw: Use ifdef with ACPI' ?
<BenC> rtg_: yep
<jsalisbury> mdalacu, no need to post additional info.  The apport data should be good enough for now.
<mdalacu> jsalisbury, OK, thank you very much. I will go now. Bye.
 * rtg_ -> EOD
<markus-j> does someone here know if the next precise/quantal-lts kernel will contain the patches mentioned here? https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1157649/comments/15
<ubot2> Launchpad bug 1157649 in xserver-xorg-video-intel "GPU hang" [Undecided,Fix released]
<greearb> hello!  I'm starting work on re-mastering a 12.10 live-cd image, and I'm curious if anyone knows if the 'raging' kernel can be used on 12.10 (as live-cd)?
#ubuntu-kernel 2013-03-27
<maxb> I have a weird issue where my Ubuntu machine has decided that it doesn't want to honour ICMP fragmentation needed for PMTU discovery, whilst other Linux machines on the same subnet connecting to the same destination are fine, can anyone think of any useful avenues to investigate?
<maxb> (I'm assuming something this deep into the networking stack must be a kernel issue)
<ppisati> moin
<diwic> I got a question from upstream about how Ubuntu deals with the power_save parameter for HDA codecs. I don't think we do anything (i e, just follow upstream), but is there a way to verify?
<RAOF> diwic: I guess check the module parameters in /etc/modprobe.d?
<diwic> RAOF, nothing there, I was more thinking of kernel patches
<RAOF> You'd find them in the kernel git tree, then.
<RAOF> The kernel tree is based on whatever upstream commit is most recent, with all our patches on top of that, so âgit log 3.8-rc3..â should get you all the patches we apply.
<diwic> RAOF, ok, thanks
<apw> diwic, i don't recall anything specific any more for hda, but worth looking indeed
<diwic> apw, ack. As a side note, I think we once had a larger buffer size for hda, but that patch must have been removed again
<apw> maxb, pmtu discovery does not require fragmentation, indeed it requires you request no fragmentation
<apw> maxb, on the expectation you get a 'fragmentation required' icmp in response to anything too large.  you should be able to see those in your network traces if things are right
<maxb> apw: Yes indeed. My problem is that I can see ICMP fragmentation needed packets arriving, but Linux doesn't seem to be taking them into account. It continues trying to use a too-large MTU with DF set
<apw> maxb, i wonder if they are being firewalled into the bit bucket
<maxb> I can see them in tcpdump on the client host
<apw> you would expect to see them in tcpdump even if they get dropped i think, as the copies for tracing are taken very early
<apw> do you have iptables rules on this box
<maxb> only one, a nat/POSTROUTING/MASQUERADE rule, and all the chain default policies are ACCEPT
<apw> maxb, not that than
<maxb> Indeed :-/
<apw> maxb, i assume /proc/sys/net/ipv4/ip_no_pmtu_disc is 0
<maxb> yes. Of course, disabling pmtu is a workaround for the original communications problems that set me to investigating this, but it's not ideal
<maxb> In theory this is a fairly average ubuntu workstation install running raring :-/
<maxb> Perhaps I should boot a live USB and see if the problem persists
<apw> maxb, well now we need to try and acertain if this has always been this way or has regressed, so i would probabally grab a live CD and see if that is affected, adn then if so, grab a quantal kerenl and boot that against the raring user space
<apw> maxb, is it possible to test without the MASQ rule you mentioned too, as there was a case in 2.6.11 where loading rules there broke this
<apw> maxb, finally can you tell me which host you are having the issue with server side (privatly is fine) so perhaps i can test here and see with my raring system
<maxb> I deleted that rule, no change. But I'll try without it from a clean reboot too
<maxb> The problem host is on the other side of a private IPsec tunnel
<apw> yeah it is 'having ipt_MASQUERADE loaded' which was the trigger, though it should be fixed in theory
<apw> maxb, fair enough not going to be doing that then
<apw> maxb, a quick survey of places i visit often i do not get any icmp-fragneeded packets, sigh
<smb> morning
<apw> smb, moin
<smb> apw, insomnia?
<apw> smb, sunny day and no curtains
<smb> ah
<smb> unexpected but seems there is something bright outside here too
 * smb has curtains, though
<maxb> Well, not loading the MASQUERADE rule doesn't seem to have changed matters
<maxb> Hmm, but quantal kernel raring userspace works
<apw> maxb, ok that implies a regression in v3.8
<apw> maxb, so ... next we would normally ask you to try the v3.8 mainline, v3.7 mainline and v3.6 mainline kernels
<apw> maxb, https://wiki.ubuntu.com/Kernel/MainlineBuilds
<maxb> will do
<apw> maxb, and ... get a bug filed and let jsalisbury know so he can help us get the bisect done
<apw> (jo and me of course the bug number)
<maxb> I'll file a bug later today once I have some kernel-ppa tests done
<apw> maxb, ack
<brendand> henrix, do you know why the certification-testing task is marked Invalid in the lucid tracking bug? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1158939
<ubot2> Launchpad bug 1158939 in kernel-sru-workflow/verification-testing "linux: 2.6.32-46.107 -proposed tracker" [Medium,In progress]
<henrix> brendand: hmm... i'm not aware of any specific reason, so most likely a bot bug
<henrix> brendand: you can go ahead and just change the state to 'New' i believe
<henrix> brendand: i'm ping bjf later about that
<ppisati> brb
<maxb> My pmtud-related bisection has established the interval of v3.5.7.8-quantal .. v3.6-rc1-quantal :-/
<apw> maxb, ok ... what is v3.5-foo like, as that is on the same mainline
<maxb> Oh, as in determine whether a fix landed during 3.5.x ?
<apw> maxb, and if not it is easier to bisect v3.5->v3.6-rc1 than from .8
<maxb> Just doing a quick side trip into 3.9-rc4 to see if anything changes there, then I'll try out 3.5
 * ppisati rush out to get some food before the conf call
<maxb> A colleague has just observed that 3.6 saw the removal of the IPv4 routing cache
<maxb> Which would kind of be a good reason for this to have broken
<maxb> Except, I've also discovered an additional wrinkle.
<maxb> I'm connecting to several different sites via the same IPsec gateway. And some behave differently to others
<maxb> Accessing some, my local machine just magically decides to operate an IP MTU of 1420, and I can't see any evidence why
<rtg_> ppisati, I assume you want those 2 patches mentioned in your response to robher applied ?
<rtg_> if so, please submit them on the public k-t list.
<rtg_> apw, the kbuild test robot email re: 'lib/dynamic_debug.c:1059:6: warning: passing argument 7 of 'parse_args' from incompatible pointer type' looks legitimately broken. can you have a look ?
<apw> rtg_, sure
<apw> maxb, it is not making your life easy is it
<maxb> I've just figured out that the ones when it works, is because a router in the remote site is doing MSS clamping
<maxb> So I think as far as Ubuntu in general is concerned, the question is "did 3.6 break pmtud?"
<apw> maxb, yep
<maxb> This commit message is quite scary - https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3c4cfadef6a1665d9cd02a543782d03d3e6740c6
<apw> heh yep, it is :)
<apw> rtg_, ok ... fixed and pushed
<rtg_> apw, just going through the rest of them to see which are legit
<apw> rtg_, great, any you want me to poke send 'em over
<rtg_> ack
<maswan> henrix: anything more we should do for 1111416 or is it all in hand now?
<henrix> maswan: nop, everythings good. the next kernel to go to updates will now have CONFIG_NFS_V4_1 ;)
<ppisati> rtg_: i'm building another kernel to grab a stack trace, then ill send the email
<rtg_> ppisati, ack
<apw> ppisati, your "MUSB annotation can be dropped" comment does that apply to CONFIG_USB_MUSB_OMAP2PLUS CONFIG_TWL4030_USB and CONFIG_TWL6030_USB
<apw> rtg_, did i see you say you had the 8250_DMA thing in hand ?
<maswan> henrix: excellent
<rtg_> apw, yes, I think so
<ppisati> apw: no, we need TWL4030 for booting
<ppisati> apw: does it depend on MUSB?
<henrix> maswan: enjoy ;)
<apw> ppisati, those are both M in armhf-generic but marked as 'y' in our annotations
<apw> ppisati, i suspect from your bootting comment 'y' is correct
<ppisati> apw: that's what i recalled, but if you tell me they are 'm' now (and everything works) we should just keep them as is
<ppisati> apw: bu let me check
<apw> ppisati, ack
<apw> (to letting you check)
<maxb> So I *think* I've figured out what's going on now, it looks like in the refactorings in 3.6, support for fragmentation needed packets which don't supply next hop mtu information (i.e. set the field to zero) got dropped
<maxb> Off to file an actual bug at this point
<apw> maxb, great
<maxb> The bug that I have been talking about for most of today is now bug 1160966
<ubot2> Launchpad bug 1160966 in linux (Ubuntu) "PMTU discovery no longer works in Linux 3.6+ with routers that do not send next hop MTU information" [Undecided,New] https://launchpad.net/bugs/1160966
<jsalisbury> rtg_, apw should we be building the ddeb packages for Precise?  bug 1160674
<ubot2> Launchpad bug 1160674 in linux (Ubuntu) "ddeb package missing for 3.2.0-31-generic kernel (and 3.2.0-30 too)" [Medium,Confirmed] https://launchpad.net/bugs/1160674
<rtg_> jsalisbury, they prolly _are_ getting built, but perhaps they aren't getting copied. bjf ?
<ppisati> apw: ok so, booting from mmc doesn't work
<ppisati> apw: let me check if making them =y fixes it
<ppisati> apw: i recall it was mmc related
<apw> maxb, if i am reading this commit correctly the issue is that there is a 6 year old router which does not support pmtu correctly in the channel?
<rtg_> jjohansen, 'UBUNTU: SAUCE: apparmor: Add the ability to mediate mount' is broken in raring. the prototype for struct security_operations.sb_mount has changed. apparmor_sb_mount() needs to be changed accordingly. I wonder how this even works.
<rtg_> jjohansen, oh , never mind. I was looking at the wrong function.
<apw> rtg_, we may only use that support for lxc ?
<rtg_> apw, its just the addition of 'const' to a couple of the parameters.
<maxb> apw: It supports PMTU, it just uses the original RFC792 definition of what an ICMP fragmentation needed packet should look like
<apw> maxb, i assume this means you can work round it by mss clamping at the source end
<apw> maxb, ie at your linux box
<apw> maxb, 792 isn't exactly helpful in defining the PMTU form clearly is it
<apw> maxb, ok this is better described in rfc1191 which says
<apw> "Hosts MUST be able to deal with Datagram Too Big messages that do not
<apw>    include the next-hop MTU, since it is not feasible to upgrade all the
<apw>    routers in the Internet in any finite time. "
<apw> maxb, so you might want to add that to the two bugs, indicating we stopped being compliant there
<apw> maxb, but i would not be too hopeful of upstream ever putting this back, they seem to think your router is too old to care about, is there a reason it is not upgraded to a later version of openbsd there seems to be a bunch of later versions
<apw> maxb, either way i would be interested if a simple mss clamp would sort you out
<maxb> Reason for not upgrading is merely round tuits.
<maxb> A MSS clamp should work.
<apw> lets see what they say on your bug, but i am expecting ... "heee, that would hurt" or something helpful
<apw> jsalisbury, i don't think reverting that patch will fly on its own, i am expecting you will find it is part of a larger series you'll never unpick
<jsalisbury> apw, ack.  
<apw> maxb, that said it is not clear we could not just pass the 0 down and handle it as a 'mtu -= 16' or something until it works
<maxb> The prior behaviour was to pick from a descending list of common MTU sizes
<apw> well ... based on some random info in the packet
<rtg_> ppisati, I pushed your 2 highbank patches on raring master-next. please check that they are correct.
<apw> the issue is that changing the mtu there is not allowed
<apw> but ... it must be changed lower down
<ppisati> apw: ok, i don't have any mmc-only installation anymore
<ppisati> apw: drop the annotation and leave these as modules
<apw> ppisati, thanks
<apw> maxb, this is a raring box yes ?
<maxb> yes, that is right
<ppisati> rtg_: i think you lost part of robher cfg
<ppisati> rtg_: let me do that
<rtg_> ppisati, ack
<apw> maxb, ok ..  i have had a go at just reinstating the most basic 'step down until it works'
<apw> maxb, down in the bit where we normally update mtu anyhow, i'll get you a kernel to test
<rtg_> ppisati, I'm off to grab a bite. ping me when you have those config options done. I need to upload this stuff today.
 * rtg_ -> lunch
<ppisati> rtg_: yep, i'm building another kernel
<ppisati> rtg_: houston, we have a problem
<ppisati> rtg_: i'm checking if it's our stuff or robher but
<ppisati> rtg_: http://paste.ubuntu.com/5652876/
<ppisati> rtg_: on highbank
<robher> ppisati: you need the cpuidle disable by default patch.
<ppisati> robher: was it part of your pull?
<ppisati> robher: ok, saw what's missing
<dobey> anyone around knowledgeable enough about intel/ivybridge to look at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1021924 perhaps?
<ubot2> Launchpad bug 1021924 in linux "Multiple Displays not working on Core i7 3770S + Intel DQ77MK motherboard" [Medium,Confirmed]
<apw> dobey, did you try any if the 3.9-rc kernels as yet ?
<ppisati> rtg_: ok, all sent
 * apw calls it a day
<rtg_> ppisati, both batches of patches ?
<rtg_> ppisati, pushed
<ppisati> rtg_: k
 * ppisati -> dinner
<fragmede> Hi all; I'm not seeing a tag for Ubuntu-3.8.0-14.24 in git://kernel.ubuntu.com/ubuntu/ubuntu-raring.git.
<rtg_> fragmede, oops, just re-pushed
<fragmede> Great, thanks!
<rtg_> ogasawara, ok, looks like I'll be able to upload raring pretty quick. I was beginning to wonder if this highbank stuff was gonna come together in time for the Beta freeze.
<ogasawara> rtg_: ack
<dobey> apw: i haven't. given the lack of comments on the upstream bug though, i doubt it will fix it if i do try one
 * rtg_ -> EOD
<FUF>  Greetings.. I was just wondering how the linux-image-virtual kernel packages differs from the -generic images - what advantages do they offer for my VMs compared to generic?
<FUF> should the differences I see when I diff their /boot/config* be enough to answer my question?
<dobey> probably
 * ogasawara lunch
<apw> dobey, i'll get you some test kernels with this patch for tommorrow, and put a pointer in the bug
#ubuntu-kernel 2013-03-28
<ppisati> moin
<smb> morning
<ppisati> brb
<zequence> apw: Is everything good with my kernels now? I realize I've made a couple of administrational misses in the past. Want to make sure it's all ok now
<ppisati> grub?!?!
<ogra_> ppisati, what about it ?
<ogra_> its a bootloader :)
<ppisati> ogra_: i was upgrading a calxeda node from Q to R
<ppisati> ogra_: and i tried to install grub
<ogra_> lovely 
<ppisati> *it
<ogra_> fis the kernel deps then ?
<ogra_> *fix
<ppisati> ogra_: didn't hapend on panda&c
<ppisati> ogra_: shouldn't be the kernel
 * ppisati notes he can't type this morning...
<ppisati> ogra_: is there a way to know who pulled it in?
<ogra_> you could dig through the redepends 
<ogra_> or check the apt log 
<ogra_> *rdepends ... 
<ppisati> ah never mind
 * ogra_ cant type either
<ogra_> i know linaro works on grub for arm ... but i doubt its even remotely usable yet
<ppisati> ogra_: ah never mind, wrong console, it wasn't the calxeda node
<ogra_> heh
 * henrix -> lunch
<jsalisbury> rtg_, apw, fyi. there are a lot of bug reports this morning of failures to upgrade to 3.8.0-15.  bug 1161306 for example.
<ubot2`> Launchpad bug 1161306 in linux (Ubuntu) "package linux-image-3.8.0-15-generic (not installed) failed to install/upgrade: subprocess new pre-installation script returned error exit status 128" [High,Confirmed] https://launchpad.net/bugs/1161306
<rtg_> jsalisbury, hmm. what failed ?
<jsalisbury> rtg_, it looks like a failure in a python script: https://launchpadlibrarian.net/135490864/DpkgTerminalLog.txt
<jsalisbury> rtg_, maybe not related to the kernel?
<apw> jsalisbury, it looks like it might be a dpkg issue
<rtg_> jsalisbury, where are you seeing that ?
<rtg_> DpkgTerminalLog.txt
<jsalisbury> rtg_, that is in the DpkgTerminalLog.txt file
<jsalisbury> :-)
<rtg_> jsalisbury, yeah, doesn't look like a kernel issue. nothing changed wrt packaging.
<jsalisbury> apw, rtg_, thanks for looking.  I'll chase it down with dpkg
<apw> jsalisbury, it looks to be a bit worrying if it is generic
<jsalisbury> apw, yeah.  And there are a bunch of duplicate reports in a small time frame
<rtg_> apw, jsalisbury: last dpkg upload was 22 Mar
<apw> yeah that is a while ago ... thought
<jsalisbury> hmm
<jsalisbury> it looks like the first bug report on this was around 1AM UTC
<rtg_> jsalisbury, you should try to attract infinity's attention on this one
<jsalisbury> rtg_, ack
<jsalisbury> infinity, infinity help! bug 1161306
<ubot2`> Launchpad bug 1161306 in linux (Ubuntu) "package linux-image-3.8.0-15-generic (not installed) failed to install/upgrade: subprocess new pre-installation script returned error exit status 128" [High,Confirmed] https://launchpad.net/bugs/1161306
<apw> jsalisbury, already poked him on #ubuntu-devel
<jsalisbury> apw, :) thanks
<rtg_> jsalisbury, my laptop updated correctly. it even autoremoved old kernels correctly when requested.
<jsalisbury> rtg_, ok.  I'm going to see if I can reproduce it as well
<dobey> apw: hi. did you have a specific patch in mind for my ivybridge link train issues? i could probably rebuild a kernel locally to test with it if so
<rtg_> apw, ogasawara: looks like the N7 kernel is under control for now, so I'm gonna see if I can finish the N4 kernel packaging and get it tested.
<ogasawara> rtg_: sounds good
 * rtg_ spent the morning thus far reading the various power articles and emails
<ogasawara> rtg_: I'm gearing up for some meeting hell this morning, but I was thinking of hammering on a raring lbm this afternoon.  at least looking into an updated compat wireless stack for it.
<rtg_> ogasawara, do you think its worth the bother for an interim release ?
<ogasawara> rtg_: we've always done it, so I figured it wouldn't hurt
<bjf> ogasawara, it's one more thing that we'd have to support 
<ogasawara> rtg_: and it seems we always get a request for some driver to land in it at the last minute
<rtg_> I'm thinking that folks ought to be using our backport kernels instead
<ogasawara> rtg_: wasn't tseliot wanting it for something this cycle, I can't remember the details
<rtg_> ogasawara, he has a blueprint for modaliases that I've been dragging my feet on
<rtg_> I'm becoming less enthused about LBM in light of our kernel backports
<ogasawara> rtg_: actually, Intel requested wifi drivers from 3.9 for 13.04 in my call last night.  and I mentioned lbm would be the path of least resistance.
<rtg_> ogasawara, if they are new then why don't we dump them in the main kernel repo ?
<ogasawara> rtg_: I'm fine with that too
<rtg_> ogasawara, did they give you some pointers as to which driver(s) were of inetrest ?
<ogasawara> rtg_: I think they were vague saying wilkens peak support, but not direct pointers to patches
<ogasawara> rtg_: so I'll circle back with them and then look to getting our main kernel updated and hold off on an lbm
<rtg_> ogasawara, only 96 patches to drivers/net/wireless/iwlwifi sine v3.8 :)
<ogasawara> bug 1011422
<ogasawara> no bot?
<ogasawara> hrmph
<rtg_> bug #1011422
<rtg_> huh. dead bot.
<smb> https://bugs.launchpad.net/intel/+bug/1011422
<smb> grumble mumble
<bjf> private bug
<bjf> the bot is probably ignoring you
<bjf> kamal, please verify bug 1154238 (just a reminder)
<ubot2`> Launchpad bug 1154238 in linux (Ubuntu Quantal) "update alx Ethernet driver" [Medium,In progress] https://launchpad.net/bugs/1154238
<ppisati> sconklin: i'm having issues with maint-startnewrelease and P/omap4
<sconklin> ppetraki: ok
<sconklin> what sort of issues?
<ppisati> sconklin: since the previous kernel wasn't released it can't find the pkg to extract&c to get abis&c
<ppisati> sconklin: i moved it manually to kernel.ubuntu.com
<ppisati> sconklin: as i always did
<ppisati> sconklin: but it keeps saying it can't find it
<ppisati> sconklin: what does --local do exactly?
<sconklin> ppetraki: we had this problem with regular precise. I fixed it by ignoring ABIs since we knew we had an ABI bump. But I think there's a better way.
<sconklin> oops ppisati ^^
<sconklin> ppisati:  I'd have to look at getabis to see how it works
<sconklin> doing that
<sconklin> local just runs it against the local repos as opposed to those on anotehr host you have ssh access to
<sconklin> ppisati: using --ckt-ppa should fetch them from the PPA, which should have the ones you want
<sconklin> I think?
<ppisati> sconklin: no luck :(
<sconklin> ok, let me pull your branch and have a look
<sconklin> I'm uploading Quantal ti-omap4 now
<sconklin> ppisati: I'll just fix it for you, as you're near EOD
<ppisati> sconklin: no prob, i'm debugging it now
<ppisati> sconklin: after having opened getabis, i'll leave it to you
<sconklin> :-)
<greearb> For the record, the 3.8 dev kernel works fine on a re-mastered 12.10 desktop live cd...
<greearb> (3.8 raring kernel that is)
<rtg_> cking, the N4 kernel builds now.
<ogra_> nice !
<cking> rtg_, yay
<rtg_> ogra_, now to figure out how to update the touch kernel image. any thoughts ?
<ogra_> no, and i need a device for that 
 * cking in london at mo, so can't test it
<ogra_> you can try abootimg ... 
<ogra_> iterate over all /dev/block/mmcblk0p* devices with abootimg -i and see if it recognizes an android bootimg signature 
<ogra_> if you find one thats a good first step
<ppisati> it should be
<ppisati> abootimg -u /dev/mmcblk0p2 -k vmlinuz
<ppisati> it *should*
<ppisati> work
<ppisati> but it didnt' when i tried
<ogra_> ppisati, well, abootimg doesnt recognize the bootimg partition on my galaxy S2 at all here
<ppisati> ogra_: no no
<ppisati> ogra_: it recognizes it
<ogra_> its totally device specific
<ppisati> ogra_: but i'll have to tinker a bit more with it
<ppisati> ogra_: but i really had no time these days
<ogra_> ppisati, thats N4 ... LG device ... might be completely different 
<ogra_> N7 is easy and we should get it to work ... i can even help with that since i have one here 
<ogra_> (i have an N4 too, but thats my private phone and i definitely wont tinker with it)
<rtg_> I'm gonna get some lunch first before I start wrecking my gizmos
 * rtg_ -> lunch
<Sarvatt> ogasawara, rtg_: cw actually got a lot more interesting recently when they started doing compat-drivers also, it builds backported drm drivers too which could potentially save some headaches backporting things into the main kernel. just plopping in cd instead of cw builds all the juicy stuff :)
<Sarvatt> its not really documented that well but i was playing with it a few days ago https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.8.3/ChangeLog-3.8.3-2
<Sarvatt> things like pulling most of drm changes from 3.6 into 3.5 for i915_hsw could have been avoided with that. well not really because theres no lts-quantal lbm and it wasn't around at the time but in the future..
<davmor2> Hey guys I hit an issue with an install on my ideapad Y580 with secure boot  cjwatson is under the impression is might be a kernel/firmware issue from the info he got from the installers syslog see http://ubuntuone.com/7AYGMhTAuDswfLCCn9y8W5  but it basically means it isn't booting into Ubuntu
<davmor2> I get the folowing message appear on reboot post install "Ubuntu has been blocked by the current security policy."
<davmor2> jsalisbury: do you know who would be the best person to talk to about this would be ^
<jsalisbury> davmor2, just curious, is there a bug open?
<jsalisbury> davmor2, also, did this just start happening on this machine recently?  Was there a prior release that worked with Secure Boot?
<davmor2> jsalisbury: Not looked for a bug.  I did a fresh install about 2 weeks 4 days ago ready to do the for purchase app migration testing , that is complete and a machine with 500+ apps on is a bit clunky so I've done a fresh install of todays iso and got this
<jsalisbury> davmor2, so this didn't happen on this machine with images prior to todays iso?
<davmor2> jsalisbury: I've done maybe 20 installs on this machine testing uefi + secure boot and the result went to the canonical mailing list :)  So Nope todays is the first that has played up
<jsalisbury> davmor2, thanks for the info.  Can you open a bug for this, since it appears to be a regression. I can then perform a bisect to identify the commit that introduced this.
<davmor2> jsalisbury: let me get the the exact date I last installed I think there has only been 1 or maybe 2 kernel upgrades since then.  Is there any info you would need from the installed system as I can't actually access it except from the live cd
<davmor2> jsalisbury: Friday the 8th was when I updated and installed ready for the testing
<jsalisbury> davmor2, just the kernel version.  You might be able to get it to boot if you disable secure boot in theBIOS
<davmor2> jsalisbury: ah true give me 5 minutes then.
 * henrix -> EOW
<jsalisbury> davmor2, thanks.  and it would be great if you can open a bug so we can track all of this info.  I'll post some links to test kernels in the bug for the kernel bisect.
<davmor2> jsalisbury: it looks like disabling secureboot has got me into the system so I'll report a bug from there now
<jsalisbury> davmor2, cool, thanks
<davmor2> jsalisbury: bug #1161566
<ubot2`> Launchpad bug 1161566 in linux (Ubuntu) "Regression on enabling the system for secureboot" [Undecided,New] https://launchpad.net/bugs/1161566
<jsalisbury> davmor2, thanks
<davmor2> jsalisbury: I included the installer syslog too 
<davmor2> jsalisbury: let me know if there is anything else you need, and I want be around now till Tuesday.
<davmor2> s/want/won't
<jsalisbury> davmor2, will do.  I'll post any questions/requests to the bug, so you can review them when you have time
<davmor2> jsalisbury: no worries
<jsalisbury> davmor2, this may have been introduced by upstream 3.8.3 or 3.8.4 stable.  It would be great to test them.  I'll post links to the kernels in the bug
<davmor2> jsalisbury: actually do you know when the lastest kernel image hit the cd?  If there is an older cd image about that has the kernel image before I can try that and see if it is just the latest kernel
<jsalisbury> davmor2, i'm not sure which kernels are on which cd images.  The latest image you used was based off upstream 3.8.4, so testing 3.8.3 and 3.8.2 should tell us which one has the commit that introduced this
<davmor2> jsalisbury: 3.8.0-15-generic
<davmor2> jsalisbury: with uname -a the date there is that the date the kernel was built
<davmor2> okay so I'm grabbing the 27ths cd and I'll check what kernel is on there
<jsalisbury> davmor2 3.8.0-14.24 and 3.8.0-15.25 were based off of upstream 3.8.4, so I think they would both have this bug. 3.8.0-13.22 was rebased to upstream v3.8.3 and 3.8.0-12.21 was rebased to upstream v3.8.2.
<davmor2> jsalisbury: the issue I'm going to hit is figuring out how to apply the other kernels and get them to magically rebuild the missing bit 
<davmor2> or is that some thing the kernel + grub should handle
<jsalisbury> davmor2, yes, you can do a 'sudo dpkg -i' kernel-package-name.deb and it will install the kernel and update grub 
<jsalisbury> davmor2, this wiki page might be helpful as well: https://wiki.ubuntu.com/KernelMainlineBuilds 
 * rtg_ -> EOD
<bjf> jsalisbury, ogasawara we're getting a rash of install bugs reported against the latest raring
<tjaalton> jsalisbury: there's no need for all the bisecting on bug 1140716, comment #33 already found the bad commits
<ubot2`> Launchpad bug 1140716 in linux (Ubuntu Raring) "[regression] 3.5.0-26-generic GPU hangs" [Critical,Confirmed] https://launchpad.net/bugs/1140716
<tjaalton> or maybe it's just 899b550 on the quantal kernel, would be useful to bisect with just that reverted
<tjaalton> and then if it is, revert it from precise too
<jsalisbury> bjf, yes I saw those, and pinged rtg and apw about them this morning.  I've upgraded a couple of machines and couldn't reproduce it.
<jsalisbury> tjaalton, ack.  Thanks for commenting on the bug.
<jsalisbury> bjf, infinity is also aware of this, in bug 1161306  It looks like it only may be reproducable with the Software Updater and not from the terminal.
<ubot2`> Launchpad bug 1161306 in linux (Ubuntu) "package linux-image-3.8.0-15-generic (not installed) failed to install/upgrade: subprocess new pre-installation script returned error exit status 128" [Medium,Confirmed] https://launchpad.net/bugs/1161306
<kamal> infinity, bjf, jsalisbury: I'm not convinced that the problem is specific to Software Updater ... bug 1161528 shows the same problem happening from "apt-get install -f" from a terminal
<ubot2`> Launchpad bug 1161528 in linux (Ubuntu) "unable to install linux-image, which is required by update-manager" [Undecided,Confirmed] https://launchpad.net/bugs/1161528
<kamal> (but I've not been able to reproduce it either)
<infinity> That's a subtly different error than the other ones...
<infinity> Hrm.
<infinity> Random googling suggests that having /var/cache in a tmpfs could lead to this...
<kamal> infinity: some of the bug reports include 'df' output, which show no such weirdness
<infinity> Yeah, was a shot in the dark.
<infinity> The fundamental issue seems to be, potentially, a corrupted debconf DB, but if a bunch of people all got corruption at the same time, that points at a package bug... Somewhere.
<bjf> kamal, thanks for the update
#ubuntu-kernel 2013-03-29
<ppisati> yawn
<ppisati> brb
<s3boun3t> bonjour, je viens ici pour demander s'il est possible d'inclure le dernier pilote openchrome (version 3.2) http://cgit.freedesktop.org/openchrome/xf86-video-openchrome/  pour la release finale de raring, je vous remercie.
<ppisati> do you know where are the src of the kernel used in the phablet img?
<ppisati> rtg_: ^
<rtg_> ppisati, shuold be in teh changelog, lemme check
<rtg_> ppisati, http://phablet.ubuntu.com/gitweb
<rtg_> http://phablet.ubuntu.com/gitweb?p=CyanogenMod/android_kernel_asus_grouper.git;a=summary
<rtg_> http://phablet.ubuntu.com/gitweb?p=CyanogenMod/lge-kernel-mako.git;a=summary
<rtg_> N& and N4 respectively
<rtg_> N7*
<rtg_> ppisati, is that what you were looking for ?
<ppisati> rtg_: well, i'm pretty sure the abootimg method to update the kernel is ok
<ppisati> rtg_: so i wanted to rebuild a 'vanilla' phablet kernel from scratch and flash it
<rtg_> ppisati, can you put that in a wiki ?
<ppisati> rtg_: when it's done, i'll do
<rtg_> ppisati, will it work for both N4 and N7 (with different mmc partitions I assume) ?
<ppisati> rtg_: yep, should be
<ppisati> rtg_: but i'll give n4 a try when i'm done with n7
<ogra_> ppisati, there is a "mkbootimg" in the repo that brunch builds when rolling the image ... worst case we should be able to package that and use it instead of abootimg
<ppisati> ogra_: the problem is not abootimg, is the kernel
<ogra_> (i'm not sure if you can easily build it ut of tree though ... and i dont really want a 12G sourcepackage just for it :) )
<ppisati> ogra_: there's something skewed/missing in the ubuntu-nexus7 kernel
<ogra_> thats what i mean, probably mkbootimg adds a signature or some such ... 
 * ogra_ will happily invest on a non-vacation day :)
<ogra_> *investigate :)
 * ogasawara back in 20
<ppisati> ogra_: and in fact flashing the phablet kernel with abootimg works
<ppisati> ogra_: so
<ogra_> aha
<ppisati> abootimg -u /dev/block/mmcblk0p2 -k $zImage
<ppisati> is the right method
<ogra_> well, i tried to inspect the boot.img that brunch creates with abootimg ... 
<ppisati> 127|root@android:/ # uname -a
<ppisati> Linux localhost.localdomain 3.1.10test1-g06b7e9c #1 SMP PREEMPT Fri Mar 29 15:34:28 CET 2013 armv7l GNU/Linux
<ogra_> and that told me "no android signature"
<ppisati> notice 'test1'
<ogra_> yep
<ppisati> tools are good
<ppisati> kernel is bad
<ogra_> phew, k 
<ppisati> now i've to find why...
 * ogra_ would dance now ... but forbidden by german law today :)
<marvin24> where is the "official" 3.1 kernel?
<marvin24> I like to use its config
<ppisati> marvin24: nexus 7 you mean?
<marvin24> yes
<ppisati> marvin24: http://phablet.ubuntu.com/gitweb?p=CyanogenMod/android_kernel_asus_grouper.git;a=summary
<marvin24> maybe not so clever if I think about it because it is configured for android
<ppisati> marvin24: ah wait, touch or desktop edition?
<ogra_> the former ones werent 
 * ogra_ wonders if we still have a tree around for that one
<marvin24> well, the one which fitst best to a linux distro 
<marvin24> but i forgot that ubuntu moves away from linux desktops ...
<ogra_> haha
<ogra_> doesnt ... only from linux kernels on arm 
<marvin24> he, sarcasm is allowed today AFAIK
<ogra_> yeah, if you cant dance you can at least be sarcastic, granted :)
<marvin24> you mean *for* linux kernels on arm
<ogra_> the arm images are moving to android kernel (which some config changes) 
<ogra_> *with
<ogra_> even the nexus7 desktop image does now 
<ogra_> its all cyanogenmod now 
 * ppisati notes he is making progress with the nexus7 kernel...
 * ppisati -> gym
 * rtg_ -> lunch
 * ogasawara lunch
 * rtg_ -> EOD
#ubuntu-kernel 2013-03-31
<snadge> WARNING: at /build/buildd/linux-3.8.0/drivers/gpu/drm/i915/intel_display.c:3891 intel_modeset_check_state+0x582/0x610 [i915]()
<snadge> not sure what this is about.. but an old dell inspiron 1525 is spamming my dmesg with that
<snadge> current raring kernel
<snadge> might try an upstream one
<snadge> kernel.ubuntu.com not responding for me ?
<snadge> looks like its fubar ;)
<snadge> hmm ok current mainline does same thing
<snadge> people just update drivers and dont bother to test if it works on old broken crap? :p
<snadge> drm-nightly kernel same
<snadge> 3.5 kernel from quantal, no problems
#ubuntu-kernel 2014-03-24
<BenC> infinity: *groan, apology*
<caribou_> Do we build kernels for the arm64 architecture ?
<apw> yes
<rtg> caribou_, x-gene SOC and the arm64 simulator. see dannf for more info
<caribou> rtg: ok, thanks
<sbeattie> bjf, ppisati: FYI, I added a couple of simple tests for bug 1295948 to QRT. This might fail for older releases on arm; if it does, please let me know, and I'll special case those.
<ubot2> Launchpad bug 1295948 in linux-manta (Ubuntu Trusty) "mako kernel doesn't support xattrs in the security namespace" [Undecided,Fix released] https://launchpad.net/bugs/1295948
<rtg> sbeattie, I uploaded fixes for that yesterday. Do the tests succeed now ?
<sbeattie> rtg: I don't have access to a mako or manta device, and the people who do aren't online yet; I'll recheck with them later this morning.
<rtg> sbeattie, k, thanks
<bjf> sbeattie, which kernel test set are these new tests part of ? kernel-security ?
<lordievader> Good afternoon, I was wondering if the Saucy kernel support the tickless timer.
<sbeattie> bjf: yes, kernel-security
<rtg> apw, hmm, I don't think 3.13.7 was built for powerpc unless its some cruft that we've added.
<rtg> maybe its just missing an include
<apw> rtg, yeah not build tested it on anything other than x86 yet
<apw> we do have a fair bit of tat on the top sadly
<vlad_starkov> QUESTION: Can't boot on freshly installed 12.04.4 64bit. Got multiple CPU soft lockup messages. Could someone point me how to boot in verbose/debug mode to figure out what's going on?
<\sh> guys, what's the right way to adjust some config settings in the ubuntu linux source pkg, besides adjusting debian.master/config/config.common.ubuntu ... especially the part how to produce the source package for it...
<bjf> vlad_starkov, you want to remove the "quiet spash" options from the boot command line
<vlad_starkov> bjf: I have 12.04.4 64Bit Server
<vlad_starkov> bjf: where can I get full list of kernel boot parameters that my system support? This link https://www.kernel.org/doc/Documentation/kernel-parameters.txt does not contain some of them. For example in this article https://wiki.ubuntu.com/DebuggingKernelBoot says about "debug=vc" param. Another example is "nomodeset" param that Ubuntu supports but which is not included in the kernel-parameters.txt.
<bjf> vlad_starkov, i don't know of a complete list
<vlad_starkov> bjf: Ok
<arges> apw: http://pastebin.ubuntu.com/7147434/ test case
<JanC> \sh: ah, so I'm not the only one trying to figure out how the linux package spaghetti works?  :)
<\sh> JanC, nope...I found this: http://blog.avirtualhome.com/how-to-compile-a-new-ubuntu-11-10-oneiric-kernel/ but somehow this is not true anymore, it bails out with a lot of 'no permissions' error, because scripts are not 755 at least
<JanC> \sh: you have to chmod some scripts
<bjf> \sh what exactly are you trying to do?
<JanC> "chmod a+x" on "debian/scripts/*" & "debian/scripts/misc/*"
<\sh> bjf, I need to find a good and easy way, to add some kernel config settings into  the ubuntu kernel source package (linux ;)) and then something like 'debuild -S -sa' and feeding it into sbuild but the usual way of rebuilding source packages is not true for the linux kernel package
<\sh> JanC, well, yes, but it feels broken^Wwrong? ;)
<JanC> but it's documented: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<\sh> bjf, so changing debian.master/config/config.common.ubuntu is first step.
<JanC> (not much else about it is documented)
<\sh> JanC, agreed...I'll try...but building the un-changed linux debian source tree from ubuntu results in i.e. empty linux-source-<version>_<deb_version> package
<apw> \sh do you care abuot hte linux-source pacakge ?
<\sh> means: dget linux*.dsc from launchpad, and just sbuild -A -d <my schroot> *.dsc 
<\sh> apw, not really, but I want the same binary packages when I build from source.
<apw> and most likely that is because the packaging eliminates the things you arn't likely to need if you arn't on a real builld
<apw> \sh so you need to set full_build=true to avoid those smarts
<\sh> apw, I have my sbuild with buildd variant ... and where do I set full_build=true?
<\sh> injecting to sbuild?
<apw> \sh not sure, never have wanted to 
<apw> build the debug, src etc packages when building for myself
<apw> you could also add "/CurrentlyBuilding" with "Build-Debug-Symbols: yes" in it to your chrrot, which better simulates what a real buildd has in its environemnt
<apw> but expect the build to take a heck of a lot longer
<apw> \sh, you can probabally do that via a --pre-build-command or something
<\sh> well actually I just need to add CONFIG_SOUND_OSS_CORE = y and CONFIG_SOUND_OSS_CORE_PRECLAIM=y and CONFIG_SOUND_PRIME=y set because this is missing for my project in our ubuntu generic kernel...and yes I know it seems deprecated, but I need it :)
<infinity> \sh: Those are more than deprecated, they actively break some bits of userspace, which is why we have them disabled.
<apw> cirtainly you'll need to futz with pulseaudio to make it not collide majorly with oss
<antarus> I thought there was some weird userspace oss emulation availble
<infinity> antarus: There is, and it doesn't work if you have CONFIG_SOUND_OSS_CORE_PRECLAIM=y
<\sh> infinity, well, I don't need the kernel for a 'desktop' usecase...it's a particular piece of HW I need to support, and it's only running on those :) and if we can do that with gentoo, I am sure I am able to produce a nice ubuntu/debian package with this ;) 
<\sh> apw, no pulseaudio involved on this hardware
<ogra_> geez, think of lennart !
<infinity> Heh.
<apw> well clearly it is being done wrong, if you don't need systemd-pulseaudio
<\sh> ogra_, I am in berlin now, so I can complain personally  ;) 
<ogra_> heh
 * apw thinks about stopping using systemd-his-keyboard pretty soon
 * ogra_ waits for systemd-bash
<apw> if you think you need shell access ... sigh
<\sh> ogra_, and I didn't like the decision which we announced...but that's just eventually me
<infinity> I suspect Kai and Lennart won't be able to absorb any FSF projects, so we're safe there.
<antarus> ogra_: systemd-dash
<infinity> (But they might NIH a new libc and POSIX shell instead!)
<ogra_> antarus, oh, right, we're ubuntu :P
<antarus> infinity: we have some hardware that has no X, but uses OSS emulation to provide beeps to the operator
<antarus> its pretty classy stuff
<ogra_> but systemd-dash wont need a binary compiled ~/.bashrc 
<infinity> antarus: Anything that beeps is okay in my book.
<antarus> .bashrc.c
<antarus> I'm liking where this is headed
 * infinity heads out for systemd-breakfast.
<\sh> ogra_, systemd-dash needs a byte-compiled .dashrc written hacklang (http://hacklang.org/) ;) 
<antarus> \sh: too far sir, too far
<\sh> it's from facebook...so it must be good ;)
<ogra_> \sh, nah. in german please ... http://esolangs.org/wiki/German
<\sh> ogra_, oh man...I just had a schnitzel today and now a beer...so, if ( schnitzel & beer)== beerschnitzel then result = bretzel?
<JanC> PlankalkÃ¼l?
<ogra_> ++
<\sh> looks like my 8 core workstation has some fun...when I see 8 cores piling up to 50% cpu time...I think 3 kernel compiles at a time is no good 
<ogra_> you still have 50% left then 
<ogra_> not that bad ... 
<JanC> that hello world example is pretty stupid, at least they could have taken the time to write a story in German containing those words  :p
<\sh> anyone wants to work for BMW ? just got an offer from a headhunter...
<antarus> is that in germany?
<ogra_> doe they pay in schitzel and beer ?
<\sh> I hope in hard Europ
<\sh> well EUR ;)
<\sh> antarus, germany yes
<antarus> I suppose knowing german is a requirement
<antarus> so I'm out ;p
<ogra_> nah, thats in bavaria
<ogra_> they dont know german either
<antarus> touche
<antarus> I lived in munich for 6 months and still didn't learn
 * antarus is a terrible person
<\sh> antarus, I am working in an office in germany where german is not pre-requisite, english is much better
<JanC> I'm pretty sure English is okay in such an international company
<JanC> or probably even a requirement
<\sh> and no private life...for sure, while working with the SoCal guys...I feel Jonos pain every day 
<ogra_> private life is overrated, it only only has the risk in it that you get spyed on by NSA ... 
<\sh> ogra_, hope I see you at linuxtag 2014 here in berlin :) 
<ogra_> i'll try my best 
<ogra_> i need to come over anyway ... but my cars are all down atm
<\sh> ogra_, there is still the train ;) but cool...we can have some nice dinner and drinks with dholbach ;)
<ogra_> yep
<\sh> time to head home...tomorrow I have flat inspection...hopefully I have the flat rented from next week on :)
<\sh> thanks for the help btw
<apw> rtg, i've pushed the daemon cleanup for the hv-kvp stuff, plus the meta change ... 
<rtg> apw, ack.
<rtg> apw, I suppose I should upload this pile tonight.
<apw> rtg, arn't we past the freeze now
<apw> ie it'll have to wait till fri or so 
<rtg> they'll just hold it for a couple days
<apw> yeah there is that i guess indeed
<rtg> maybe I'll finish up the config changes first
#ubuntu-kernel 2014-03-25
 * smb initiates the yawning sequence
<ppisati> smb: you are not supposed to yawn, go back o your bed
<ppisati> *to
<smb> ppisati, Its late enough for me to yawn. ;-P Good morning
 * cking now yawns
 * cking does a clean install, back later
<infinity> cking: Any interest in hanging out with humans for release sprinty things, or would you prefer not?
<cking> infinity, i'd prefer not, I think if any iso testing is required I have loads of kit at home so its more productive if I'm in my office
<infinity> cking: So, on the one hand, ECHAN, on the other hand, alright, thought I'd ask. :)
<cking> thanks for asking, it's always good to be at the release sprint, but in the past i've always found I've needed kit that I can't bring into the office
<infinity> cking: Right.  Well, pop in for finger sandwiches later. :P
<infinity> (Made with real fingers)
<cking> yeah, I'll try and do that, cant' miss the fingers
<Kano> hi, do you update the unstable branch soon?
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<arges> jsalisbury: hey
<jsalisbury> arges, o/
<arges> jsalisbury: bug 1283604 can I add it to teh list
<ubot2> Launchpad bug 1283604 in linux (Ubuntu) "WARNING: CPU: 0 PID: 5517 at /build/buildd/linux-3.13.0/fs/sysfs/group.c:214 sysfs_remove_group+0xc6/0xd0()" [High,Confirmed] https://launchpad.net/bugs/1283604
<jsalisbury> arges, sure thing
<arges> jsalisbury: i have a fix already for it btw
<jsalisbury> arges, awesome
<jsalisbury> arges, I can't hear anything on mumble, its all breaking up, so I may reboot
<arges> jsalisbury: ok
<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 April 1st, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<rtg> dannf, how is 3.13.0-19.40 working for you ?
<dannf> rtg: according to ikepanhc, quite well (he's done more testing than i)
<rtg> dannf, ok, thats good to hear.
<dannf> there are a couple more drivers we'd like to get in if we can get 'em tested in time (ipmi/xgene-gpio), but they may have to wait for an SRU proposal or 14.04.2
<rtg> dannf, I can accommodate a new driver under SRU policy as long as there is no risk of regression to other subsystems.
<dannf> understood
<rtg> dannf, unless that happens this week, though, it ain't gonna make it until after release
<dannf> rtg: also understood :) luckily these drivers aren't installtime requirements, so hopefully we can install w/ 14.04 and upgrade to a kernel w/ that support
<dannf> should they be SRU'able
<rtg> that works for me
<dannf> rtg: 19.40 is the one from last week right - there hasn't been a second upload supporting x-gene correct?
<dannf> wondering if we've been testin gthe latest
<rtg> 19.40 is current
<dannf> rtg: oh sweet - that has the udeb fix. time for me to start hacking on d-i :)
<rtg> dannf, right, that spelling change was about the last fix I had for x-gene (that I knew of)
<dannf> yep, that's all we have for you atm
<ParkerR> Have their been any plans on an updated kernel for the Nexus 7? The latest even in trusty in 3.1 https://launchpad.net/ubuntu/trusty/armhf/linux-image-grouper
<ParkerR> *is
<rtg> ParkerR, all of the touch kernels are ging to stay at their Android release versions. Grouper will forever be 3.1
<ParkerR> D:
<ParkerR> I've been attempting a compile on my own but the 8MMB boot partition limit is kinda annoying
<ParkerR> *8MB
<ParkerR> rtg, Thaks for the response.
<ParkerR> *Thsnks. I swear I can't type today
<rtg> gotta love embedded systems
<ParkerR> I give up :|
<ParkerR> Mainly I've been compiling to get DRM_TEGRA. Plus the kernel has had many ARM improvments since 3.1. Oh well, I'll continue on this adventure.
<rtg> arges, is bug #1297307 a duplicate of bug #1283604 ?
<ubot2> Launchpad bug 1297307 in linux (Ubuntu) "sysfs group <address> not found for kobject 'target6:0:0'" [Undecided,Incomplete] https://launchpad.net/bugs/1297307
<ubot2> Launchpad bug 1283604 in linux (Ubuntu Trusty) "WARNING: CPU: 0 PID: 5517 at /build/buildd/linux-3.13.0/fs/sysfs/group.c:214 sysfs_remove_group+0xc6/0xd0()" [High,Fix committed] https://launchpad.net/bugs/1283604
<arges> rtg: i filed 1297307 and marked it a dup of 1283604
<arges> i filed it first, then found the duplicate later
<rtg> arges, ok, I was just catching up on my bug mail backlog
<arges> rtg: i guess i didn't mark it as a dup... oh well thought i did ... fixing it
<rtg> there is sure a slew of resume bug reports
<rtg> sforshee, why is bug #1297370 invalid ?
<ubot2> Launchpad bug 1297370 in linux (Ubuntu) "iwlwifi firmware error: 0x00000038 | BAD_COMMAND" [Low,Invalid] https://launchpad.net/bugs/1297370
<sforshee> rtg: because I triggered it by writing to a sysfs file whose sole purpose is to create that error
<sforshee> rtg: those bugs are just me testing some changes to apport to collect the real firmware crash bugs
<rtg> sforshee, ah
#ubuntu-kernel 2014-03-26
<rsalveti> apw: hey, as we're going to set the brightness level using the android hal, we don't need the following patch anymore (for flo): http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-trusty.git;a=commit;h=c8bbd5315bc7d0ad69c2911cd59c807814e7def2
<rsalveti> apw: reverting that also fixes a stack trace during boot, and sets up the default framebuffer device as used by the stock android image
<rsalveti> apw: would you mind reverting that patch and pushing a new package to the ppa?
<rsalveti> that was only needed because we could only set the brightness level via sysfs (using a specific device class), and the stock config provides a lcd-backlight device under the leds class
<rsalveti> so with the patch we can set brightness using the current indicator-power logic, but can't using the android hal as the device is different
<rsalveti> so that's why we need the revert, as once we merge https://code.launchpad.net/~ycheng-twn/indicator-power/indicator-power_set-brightness-via-powerd/+merge/209200 we'll be setting it via hal (which is how powerd is currently using it as well), making it more compatible with the android stack
<rsalveti> and compatible with more devices
<ppisati> yep
<dholbach> hey
<dholbach> can somebody check what's still missing on this bug: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1256949??
<ubot2> Launchpad bug 1256949 in linux (Ubuntu) "Dell Latitude E5420 doesn't boot if killswitch is turned to "radio off"" [Undecided,Expired]
<ogra_> apw, since you had so brilliant ideas about the systremsettle test on the phones when we discovered that the CPU core are hotplugged, i was wondering if you have an idea about upstart in that regard .... it is supposed to crop a chart if the system goes idle after a certain app started, but i cant seem to get it to sense that on the phone 
<ogra_> http://people.canonical.com/~ogra/touch-bootcharts/ has daily bootcharts ....  http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-trusty-255.png is the only one where the cropping happened, the CPU usage looks like it is close to zero, so i suspect thats a similar issue as the systemsettle idle issue
<rsalveti> guess apw is not around today
<ogra_> rsalveti, nope, on friday again
<rsalveti> rtg: mind handling http://paste.ubuntu.com/7157292/?
<ogra_> (probably bootchart simply doesnt consider the system idle because the kernel writes 100 battery state messages to syslog all the time :P )
<rtg> rsalveti, ack
<rsalveti> rtg: thanks
<rtg> rsalveti, Uploading linux-flo_3.4.0-3.9.dsc: done.
<rsalveti> rtg: thanks!
<rtg> rsalveti, c-k-t PPA as usual. Note the ABI bump (if that is relevant)
<rsalveti> rtg: thanks, did you also update the meta package?
<rsalveti> rtg: I can migrate to the archive
<rsalveti> after testing it
<rtg> rsalveti, yup, hence the ABI update
<rsalveti> awesome, thanks so much
<rtg> np
<infinity> rsalveti: I can just copy it to the archive, if you think it's sane.
<rsalveti> infinity: np, will land it together with another silo
<rsalveti> but thanks
<infinity> rsalveti: Whee, silos.  Please copy it instead of reuploading. :P
<infinity> (with binaries)
<rsalveti> sure, will just copy them :-)
<infinity> BenC: Daily ping re: http://launchpad.net/bugs/1291125
<ubot2> Launchpad bug 1291125 in Kernel SRU Workflow "linux-ppc: <version to be filled> -proposed tracker" [Medium,In progress]
<BenC> infinity: Build in progress
<infinity> BenC: \o/
<infinity> BenC: Can I trust that you're doing a full build so I don't have to do it again before I upload? :)
<BenC> infinity: Yes :)
<infinity> Shiny.
<infinity> BenC: Was there a defensible reason why CONFIG_KVM was =y in powerpc rather than =m?
<infinity> BenC: Or "just cause"?
<BenC> infinity: I don't think it can be =m
<infinity> BenC: It can (and is) on other platforms, and qemu --enable-kvm forced a load.
<infinity> BenC: Hence the curiosity.
<infinity> s/forced/forces/
<BenC> Then my argument is that qemu --enable-kvm doesn't require root (if /dev/kvm is set to a specific group) :)
<BenC> But to be honest, I have no good reason, and I haven't tried it as =m
<infinity> BenC: That should still work, through the magic of udev and things.
<infinity> BenC: Alright, we'll give it a whirl as =m and see if the world explodes.
<infinity> BenC: But there's no reason why your platform(s) would be special in this regard, right?  Like, if it works for me on IBM kit, it should work for you too?
<BenC> Right
<infinity> Cool.
<infinity> rtg: ^
<rtg> infinity, ack
<BenC> As long as there aren't really weird module naming that program have to be aware of (e.g. vx and such)
<strikov> Hi guys. Kernels for armhf have flash-kernel in recommends. Due to this fact when you try to use curtin (fast-path installer) inside the virtual instance it crashes. Curtin installs kernel, kernel recommends flash-kernel and flash-kernel crashes because it can't get arch name (dtb is not available and /proc/cpuinfo shows 'Dummy Virtual Machine' which is not in flash-kernel's db). What is the best way to solve this? Thanks
<infinity> strikov: How are kernels meant to be booted in these VMs?
<infinity> strikov: Is it currently "feed it to qemu externally"?
<infinity> It's entirely possible that kernels recommending bootloaders is a silly idea we should stop doing.
<infinity> But since it might be a bit late to easily validate that, adding a no-op flash-kernel DB entry for VMs might do.
<strikov> infinity: there is no way to boot them right now (when we have grub working inside vm instance that can be the way)
<strikov> infinity: db entry looks good to me, just wanted to make sure that we can't drop this recommendation
<strikov> infinity: thanks
<infinity> strikov: File a bug on flash-kernel with the details and a dump of /proc/cpuinfo on such a setup.
<strikov> infinity: will do
<infinity> strikov: I'm pretty sure the right answer here is to make kernels on all arches stop recommending bootloaders, it should be up to your installer to pick one for you, not the kernel package to make sure you have one, but final beta time is probably not the right time to make changes like that.
<strikov> infinity: agreed
<strikov> infinity: and do you have example of this no-op entry?
<strikov> infinity: how it should look like to avoid any work done
<dannf> infinity: if we do this for just arm64 (remove recommends), and we verify that d-i still works on supported platforms, is that good?
<infinity> dannf: Possibly, but the above was about armhf. :P
<dannf> oh - nm, strikov says it related to armhf, and yeah - too late to validate that
<dannf> we have the same problem on both, but no-op entry would fix it for both
<infinity> I'd imagine that "Machine: Foo\nKernel-Flavors: generic generic-lpae" and nothing else in the stanza would do pretty much nothing on Foo.
<infinity> Though please do test. ;)
<infinity> Though, this conversation did highlight a bug on ppc64el, where loader is wrong.
<strikov> infinity: http://paste.ubuntu.com/7158987/ at the end of db list did the trick
<infinity> strikov: Erm, what's that second line for?
<strikov> infinity: well, we have different /proc/cpuinfo lines on armhf and arm64 :(
<strikov> infinity: inside the vm instance i mean
<infinity> Oh, that's for the two arches.  Kay.
<infinity> Awkward that the second one is so ugly.
<infinity> Is this with hallyn's qemu 2.0 packages?
<strikov> infinity: it is
<strikov> infinity: oh, sorry, i'm using 1.7
<strikov> infinity: https://bugs.launchpad.net/ubuntu/+source/flash-kernel/+bug/1298070 Thanks for helping
<ubot2> Launchpad bug 1298070 in flash-kernel (Ubuntu) "Flash-kernel shouldn't raise any errors while running inside vm instance" [Undecided,New]
<infinity> Not sure I entirely agree with the Foundation Model being in there, but I guess it doesn't hurt terribly.
<infinity> Since, in theory, if we ever have a bootloader there, it's going to be grub.
<infinity> Which I assume it also true for our VM story.
<infinity> s/it/is/
<strikov> infinity: yeah, i don't think that we have any chance to see u-boot inside any virt environment
<strikov> infinity: and flash-kernel is about u-boot
<hallyn> ok, i apparently misread the memo - 12.04 has a very long chain of hwe kernels;  do i understand right that 14.04 will only have 2 years of kernel support?
<infinity> hallyn: No.
#ubuntu-kernel 2014-03-27
<bjf> hallyn, it's an lts so it gets the full lts treatment (5 years). it will also get it's own long chain of hwe kernels
<hallyn> bjf: thanks, that's what i would have thought :)
<rtg> ppisati, can you have a look at https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes
<rtg> there are some references to OMAP4
<ppisati> rtg: looking
<ppisati> rtg: and bogus
<rtg> ppisati, you can likely edit it
<ppisati> rtg: that's for kernel using the drm kernel module
<ppisati> rtg: i assume we are going for a server-only install this time around, since we can't provide any gl acceleration
<ppisati> actually i can't edit it
<rtg> ppisati, ok, I'll take care of it. thanks for the review.
<jho_> I am trying to get the following card reader up and running: 5d:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. Device 5249 (rev 01)
<jho_> currently I run 3.11.0-18-generic #32-Ubuntu SMP Tue Feb 18 21:11:14 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux / Ubuntu 13.10
<jho_> the 3.14-rc8 does not recognize the card either..
<jho_> does anyone have a suggestion what the easiest method is to get the card up and running?
<jjohansen> rtg: the apparmor kernel patch is still in testing, hopefully in a few hours
<rtg> jjohansen, by noon ? 2.5 hours from now ?
<jjohansen> rtg: I don't know
<rtg> jjohansen, well, let me know as soon as you're comfortable with them.
<jjohansen> rtg: ack, if you want to peek at the diff that is in testing it is the aa3ipc branch in ubuntu-trusty on zinc
<rtg> jjohansen, ok
<rtg> still working through broadwell patches
<infinity> BenC: How did your kernel test builds end up yesterday?
<BenC> infinity: Builds errored, fixed and redoing build now to verify
<rtg> arges, https://launchpadlibrarian.net/170877586/buildlog_ubuntu-quantal-amd64.linux_3.5.0-49.73~pre201403271230_FAILEDTOBUILD.txt.gz
 * arges looks
<rtg> "module: do percpu allocation after uniqueness check. No, really!" is breaking my rice bowl on Quantal
<arges> rtg: ok i did test build on my own machine. i'll check the logs
<arges> rtg: feel free to NAK it and I'll resubmit
<rtg> arges, I'll just lop it off tip of master-next
<arges> rtg: ok. so i hit the same thing on my local build... but for some reason I have a build of this when I built remotely... 
<rtg> arges, ghost in the machine
#ubuntu-kernel 2014-03-28
<ppisati> yo
<smb> yo
<smb> RAOF, You still around? Who would be the guy caring about llvm-pipe/xserver-modeset these days? 
<RAOF> smb: You're probably after mlankhorst, mostly.
<smb> RAOF, Ah, ok. Thanks. I am always unsure there...
<RAOF> Also tjaalton and Sarvatt can still be of assistance, probably :)
<RAOF> Well, and me, depending on the question :)
<smb> RAOF, I put it out on #ubuntu-desktop
<smb> RAOF, Basically gnome term in virtual machines is not a happy bunny
<tjaalton> I'll check out what it looks like here..
<tjaalton> oops, need to migrate the images somewhere other than btrfs..
<smb> tjaalton, The key piece (if you where responding to my question kinda) is to have a kvm or xen guest using the default cirrus graphics
<tjaalton> the default is wrong imo
<tjaalton> iirc
<smb> tjaalton, It is the historical default and its that (or potentially svga) that you get with xen
<smb> tjaalton, I know some people like to push for vmvga but that is only available for kvm. And it is usually not working in different ways. Last time I looked it always went for an insanely big screen and crashed when trying to change that.
<tjaalton> I need to make some room on my ssd first to check the situation, but iirc I switched off from cirrus immediately after the install
<smb> tjaalton, Yeah, which is a failure from my point of view ;)
<tjaalton> i'm using qxl it seems
<smb> One does not have that luxury with Xen. I mean we should be better with cirrus now as both KVM and Xen can use the kernel-mod driver
<smb> And the boot issues should be solved too
<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've to open an upstream bug report. There is this wiki page: https://wiki.ubuntu.com/Bugs/Upstream/kernel
<cristian_c> I've read it, but I've got some doubts yet. for example: [7.7.] Other information that might be relevant to the problem (please look in /proc and include all information that you think to be relevant):  While booted into the newest upstream mainline kernel only, execute the following via a terminal, and paste the results
<cristian_c> what information from /proc can I add to the upstream bug report?
<cristian_c> and then: [X.] Other notes, patches, fixes, workarounds:  Please provide a link to your Launchpad bug report
<cristian_c> What exactly can I do about this specific point? Any ideas?
<ogra_> apw, there are two (untested) patches for flo and mako on bug 1270248, could i get a PPA build with them to test ?
<ubot2> Launchpad bug 1270248 in logrotate (Ubuntu) "/var/log fills up disk space on phone" [High,Confirmed] https://launchpad.net/bugs/1270248
<apw> ogra_, ack
<ogra_> apw, thx
<rsalveti> ogra_: I still think we should fix this differently somehow
<rsalveti> ogra_: otherwise we'd need to patch every kernel
<rsalveti> from every vendor
<rsalveti> we need a way for the log to have a limit in size, and drop the rest that overflows it
<rsalveti> like a ring-buffer but for whatever we store in syslog
<ogra_> rsalveti, you still dont want a notice message every 20sec
<rsalveti> ogra_: that's fine
<rsalveti> as long it doesn't cost you anything
<ogra_> it eats the log
<rsalveti> right, but we shouldn't care about that, as long we limit the log
<rsalveti> this is not a desktop, it's a phone
<rsalveti> android is ridiculously verbose, but it's not storing anything in the disk
<ogra_> rsalveti, only the chargers are 
<ogra_> the rest is normal
<rsalveti> right, but do we really want to keep those logs around?
<rsalveti> and still, it's specific to a device
<rsalveti> which annoys me as we need to start preparing a similar change for every build we have (and will have)
<ogra_> can we discuss this at or after the meeting 
 * ogra_ tries to get something in his stomack atm ... had no chance to eat today yet
<rsalveti> sure, I believe it'd be good to have some sort of uds session (but out of uds) :-)
<ogra_> done
<ogra_> rsalveti, so the issue is that the kernel logs to a ringbuffer ... dmesg will be completely spammed away with batteray messages after 2min
<rsalveti> ogra_: but that is fine
<rsalveti> and expected
<ogra_> i agree we need to limit logging more as well, but we also need to get rid of tehse spammers, 
<ogra_> no
<rsalveti> we don't need to care, really
<rsalveti> and we shouldn't care
<rsalveti> as that's specific to the kernel we have
<ogra_> thats not expected by me ... if i want to see kernel messages i dont want to see 2000 the same battery message 
<ogra_> it is *only* one place in the klernel that spams 
<rsalveti> well, then just run dmesg right after boot
<ogra_> then iu can use /var/log/dmesg, that gets copied on boot 
<rsalveti> you shouldn't be able to get a useful dmesg output (since boot) after you used the phone for a while anyway
<ogra_> but i want to be able to read normal kernel messages too 
<rsalveti> right, but you're expecting too much
<ogra_> and writing rubbish to all logs every 20sec is not acceptable
<rsalveti> as I said, this is specific to vendor/device/kernel
<ogra_> no
<rsalveti> and I want us to have a solution that is common for whatever kernel we use
<ogra_> this is specific to only power mgmt drivers
<ogra_> look at the patches
<rsalveti> right, a kernel tree
<rsalveti> we don't even know if the vendor will be using the same drivers
<ogra_> its as quiet as my desktop with these added
<ogra_> i'm willing to maintain patches for this 
<ogra_> i'm not willing to lose my logs to spam for that 
<ogra_> esÃ¼pecially if we restrict them in size and you lose them way earlier
<apw> ogra_, i have kernels ready to upload, are we a go, or not go
<apw> rsalveti, ^
<ogra_> apw, please upload to the PPA, i want to test on the weekend
<ogra_> (we can still wipe them, right ?)
<rsalveti> ogra_: I got a pending flo kernel in there that I want to upload today still
<rsalveti> but I believe it's fine to upload this anyway
<ogra_> apw, can you hold back until that landed ? 
<rsalveti> until we work on a better solution
<rsalveti> ogra_: I'm fine to land this today
<ogra_> good
<rsalveti> all I'm saying is that I want us to work on a more generic solution as well
<rsalveti> apw: so please, push them to the ppa :-)
<apw> rsalveti, ack
<apw> rsalveti, ok both are built and published in the ppa
<rsalveti> apw: great, thanks for the heads up
<ogra_> apw, oh, and since i had pinged you about that, i worked around the bootchart CPU issue i had by simply forcing all cores online during boot, but i could imagine the server team will want bootcharts for their arm devices too and will run into something similar, so the CPU logic in bootchart probably deserves some attention
<bladibla> does anyone have a hint how to get this one "Realtek Semiconductor Co., Ltd. Device 5249 " up and running?
<wmp> hello, i build my own kernel package, and i have problem with brx2 (broadcom ethernet NIC)
<wmp> i dont know why this NIC dont work on my kernel, i have check options for this NIC, but dont work
<wmp> aughhhh... it isn't problem with NIC but with nat...
#ubuntu-kernel 2014-03-29
<infinity> BenC: *elbow jab to the ribs*
#ubuntu-kernel 2014-03-30
<stochastic> Hi there, I'm looking into kernel stuff for the Ubuntu Studio team and was wondering what the exact patches are that go into the LowLatency Kernel.  I don't see it listed at https://wiki.ubuntu.com/Kernel/Dev/Flavours
<zequence> stochastic: You could just ask me, since I'm the maintainer :)
<zequence> stochastic: In the past, there was only one patch - one which made threadirqs default. But now, since linux-lowlatency is "merged" with the master branch, making threadirqs default is done with a config
<zequence> so, no patches at all. The only diff is the config
<zequence> stochastic: You can find the kernel sources for stable releases at https://github.com/ubuntustudio-kernel
<zequence> stochastic: From trusty, and beyond, linux-lowlatency is maintained by the Canonical kernel team - while the ubuntustudio-kernel team still maintains the config diff
<stochastic> Ahh, thanks zequence, I should have just checked with you. :P
<infinity> (The config diff is 3 things)
<infinity> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-trusty.git;a=blob;f=debian.master/config/amd64/config.flavour.lowlatency;h=23a8a6513fc580bd5364fbacdcc758ef87dc2071;hb=refs/heads/master
#ubuntu-kernel 2015-03-23
<nvez-> Hello everyone.. I have identified a bug that has regressed (few other people reported it). I created a new bug here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1435363
<ubot5> Ubuntu bug 1435363 in linux (Ubuntu) "KSM causing performance and instability issues" [Undecided,New]
<apw> henrix, ^
<henrix> looking...
<henrix> nvez-: there's a new kernel in -proposed that should be released soon... have you tried it?
<nvez-> henrix: I haven't tried anything yet, I just wanted to make sure to get the ball rolling on it by starting first steps of opening a bug, etc.
<nvez-> I just saw the same exact behaviour when I first had that bug, made that change and it's worked fine now.
<nvez-> made that change = disable KSM
<henrix> ack
<nvez-> I haven't done more in depth testing but I think servers running mdraid are affected but those with hardware weren't
<nvez-> But don't quote me on that yet, it's just something I've noticed but don't have 100% confirmation on
<nvez-> The iowait was insanely high on mdraid machines for no reason, but hardware had no issues.  I didn't check if they were affected or not.
<infinity> henrix: The "new kernel in proposed" is in updates/security.
<mnaser> sorry, i disappeared.. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1435363
<ubot5> Ubuntu bug 1435363 in linux (Ubuntu) "KSM causing performance and instability issues" [Undecided,Incomplete]
<mnaser> added data here
<mnaser> i'll look at the proposed kernel if i can run it on a server and replicate
<henrix> infinity: ack, thanks
<henrix> mnaser: looks like the kernel is now in -updates (and security)
<infinity> mnaser: Just a simple update/dist-upgrade should get you -48 ... Would be worth seeing if the bug's still there.
<mnaser> henrix: just out of curiosity, are you proposing to upgrade just to see if its still there, or because it was patched/seen?
<mnaser> oh ok
<mnaser> henrix i might be making noise..
<mnaser> the server which i suspect was seing most of the issues
<henrix> mnaser: i was simply wondering if the issue was fixed in the new kernel
<mnaser> was running 3.13.0-32-generic
<henrix> mnaser: ah, that's a much older kernel...
<mnaser> *sigh* i guess this machine wasnt updated
<mnaser> let me do some more checks :X
<mnaser> i'm very sorry about this if this is the case
<henrix> mnaser: yeah, i was looking at the bug logs and i see a few ooops there, so i would definitely upgrade and see what happens with a newer kernel
<mnaser> nope i can confirm
<mnaser> this issue exists on a machine running 3.13.0-46-generic
<mnaser> i'll be setting up a new machine either today or tomororw
<mnaser> similar specs
<mnaser> ill tets it out
<mnaser> *test it out
<henrix> mnaser: ack, thanks.  please update the bug report with those results (and the logs)
<mnaser> good idea
<mnaser> can i just run apport again?
<henrix> mnaser: or, if it's easier for you, just open a new bug and simply mark this one as a dup ;)
<henrix> mnaser: yes, re-running apport should do be enough (i guess...)
<mnaser> i'll remove the logs i uploaded there
<mnaser> just in case that someone looks over itagaina
<mnaser> and dismisses it because they see -33
<apw> df
<smb> apw, you use too much space
<apw> smb, always
<mnaser> henrix: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1435363 bug updated
<ubot5> Ubuntu bug 1435363 in linux (Ubuntu) "KSM causing performance and instability issues" [Undecided,Confirmed]
<henrix> mnaser: ack, thanks.  i'll have a look in a bit
<henrix> mnaser: is the bug easily reproducible?  if so, could you add the steps to reproduce in the bug report?
<henrix> mnaser: probably, it's a perf degradation, right?  or do you actually see a crash/hang...?
<Sleaker> I'm curious what the linux-lts-utopic package is for, and what the benefit of moving to the 3.16 kernel over the 3.13 provides.
<Sleaker> oh maybe I found it on the 14.04 section of the Ubuntu wiki under Kernels.
<Sleaker> support cycle for 3.13 is the full 5 yrs and the 3.16 is only 18 months
<infinity> Sleaker: It's purely for hardware enablement reasons.  If 3.13 is working for you, there's no reason to use the HWE kernel(s).
<Sleaker> infinity: alright, thanks.  do the point releases come with the newer kernel preinstalled?
<Sleaker> like 14.04.2
<apw> yes
<infinity> Sleaker: Depending on what media you install from, but yes.
<Sleaker> infinity: hmm ok. Seems odd for canonical to not support the default install media for as long as the LTS is valid.
<Sleaker> thanks for the answers though, that's what I needed.
<infinity> Sleaker: When 16.04 ships, we strongly encourage (and tools yell at you) people using one of the HWE kernels to upgrade to the 16.04 lts backport kernel, which is supported for the rest of 14.04.
<infinity> Sleaker: It's just the interim ones we drop support for.
<Sleaker> right.
<infinity> Sleaker: For instance, on 12.04, the 12.10, 13.04, and 13.10 kernels are no longer supported, but the 12.04 (3.2) and 14.04 (3.13) kernels are supported until 12.04 EOL.
<Sleaker> just seems odd to ship a kernel that wont be supported across the full release but label it as such.
<Sleaker> ie, 14.04.2 ships the 3.16kernel, but support gets dropped after 18 months, wheras the full release is supported long past that?
<infinity> Sleaker: You're not the only person who thinks that.  Many of us are just cogs trying to make do with the requirements given to us. ;)
<Sleaker> mhmmm
<Sleaker> just glad I didn't get that kernel in atm.
<Sleaker> :D
<Sleaker> hopefully don't need it for the new hardware we'll be testing on either.
<mnaser> henrix: sorry, went afk, ill update more details on how i identify the issue
<backjlack> Hello!
<backjlack> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18.9-vivid/ is missing MEMCG configuration.
<backjlack> The entire memory cgroup is missing.
#ubuntu-kernel 2015-03-24
<apw> backjlack, yes, that i am sure we have talked about before, and it is because upstream renamed that config section, and the debug kernel builder cannot know that they did so, so it is disabled
<apw> those builds are not intended to be used for anything other than bug isolation, so they are dirty builds
 * ogra_ lols seeing apw's typo in the last linux upload 
<ogra_> (ubuntus kernel is now 100% probiotic thanks to dracult)
<apw> ogra_, spelling is definatly not one of my strong suits
<ogra_> but i love this one :)
<amitk> ogra_: probiotic is what healthy yogurt is, isn't it? good thing....
<ogra_> :)
<cking> the latest kernel keeps you healthy and regular
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting today @ 17:00 UTC
<jsalisbury> ##
<backjlack> apw: I've just reported that in case it wasn't known, nothing less, nothing more.
<apw> backjlack, ack
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
<jsalisbury> ##
<jsalisbury> ## Meeting starting now
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues March 31st, 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.
<infinity> zequence: http://launchpad.net/bugs/1435582
<ubot5> Ubuntu bug 1435582 in Kernel SRU Workflow "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress]
<rbasak> Terrible performance using IPv6 (IPv4 was fine) over a Precise kernel bridge running 3.2.0-77.114. Down to about 2 MB/s. I tried linux-image-generic-lts-trusty and it's fine (~90 MB/s as expected).
<rbasak> I wonder why Precise's kernel was so bad, but for IPv6 only?
#ubuntu-kernel 2015-03-25
<yossarianuk> hi - I have a question that really is related to the launchpad process.
<yossarianuk> I started this bug  - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1434842
<ubot5> Ubuntu bug 1434842 in linux (Ubuntu) "Due to lack of OSS kernel modules, have to recompile the kernel to enable sound in old games - aoss/padsp do not work" [Medium,In progress]
<yossarianuk> and some kind person has responded and given me a kernel to test.
<yossarianuk> I have tested and test worked - do I need to chance the status of the bug or it is a matter of just waiting now?
<infinity> yossarianuk: You commenting was enough.
<yossarianuk> infinity: thanks !
<infinity> apw: See my last comment on LP: #1434842 but, other than those two things, +1 from me on the patch.
<ubot5> Launchpad bug 1434842 in linux (Ubuntu) "Due to lack of OSS kernel modules, have to recompile the kernel to enable sound in old games - aoss/padsp do not work" [Medium,In progress] https://launchpad.net/bugs/1434842
<yossarianuk> infinity: apw: thanks for your efforts.
<apw> infinity, yep and yep
<infinity> apw: And yay for leveraging a feature we introduced all of a week ago. :P
<apw> infinity, who me .. never :p
<jsalisbury> smoser, just wanted to give you a heads up about bug 1435946 .  The bug description is for Power8, but I'm also hitting it with a moonshot cartridge.  There is a cloudinit stack trace in the bug report.
<ubot5> bug 1435946 in linux (Ubuntu) "IBM Power8 PPC MAAS images booting with no network" [High,Confirmed] https://launchpad.net/bugs/1435946
<cristian_c> jsalisbury, hello
<jsalisbury> cristian_c, hi
<smoser> jsalisbury, so can you explain more what is happening ?
<jsalisbury> smoser, After a trusty deployment, I can log into the system.  However, after a reboot or two, the network fails to come up and that cloudinit trace is printed on the console.  It just started happening yesterday for me and it seems for the power8 system too.
<smoser> "after a reboot or two"
<jsalisbury> smoser, yeah, I need to redeply to see if it's actually just one reboot, I'll confirm that
<smoser> but it installs ? and the reboots and everything is good
<smoser> and then another reboot (or two) and gone ?
<jsalisbury> smoser, yeah.  But its not gone, the system is still there and I can get to the console, the network devices don't come up.  You happen to know the default password for the ubuntu user?  If so, I can log in from the console and dig deeper
<smoser> jsalisbury, there is no default password.
<jsalisbury> smoser, hmm, so I should probably set it after the first deploy, so I can get back in from the console
<smoser> yeah
<jsalisbury> smoser, I just scrolled back on the console a bit and see some more details:
<jsalisbury> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1435946/comments/5
<ubot5> Ubuntu bug 1435946 in linux (Ubuntu) "IBM Power8 PPC MAAS images booting with no network" [High,Confirmed]
<bjf> jsalisbury, i'm trying it here on an intel nuc
<jsalisbury> bjf, ack.  
<jsalisbury> smoser, I'm re-deplying the node note, so I should have more details in a bit.
<jsalisbury> s/note/now/
<smoser> k. thanks.
<bjf> jsalisbury, smoser so far it's working fine here
<jsalisbury> bjf, did you try a couple of reboots?
<bjf> jsalisbury, i'm on my 4th
<jsalisbury> bjf, ok.  I'm starting from scratch again too, so I'll have some more info in a bit.
<bjf> jsalisbury, a dozen reboots and it's still just working
<jsalisbury> bjf, ack
<smoser> jsalisbury, i suspect your maas region controller went up in flames :)
<smoser> if yo udo reproduce and get in, then /var/log/cloud-init.log should have some WARN in it.
<cristian_c> jsalisbury, I'd like to know where I can find info about reverts
<jsalisbury> cristian_c, The git documentation has some good info: http://git-scm.com/docs/git-revert
<jsalisbury> cristian_c, or you can do a 'man git-revert'
<cristian_c> jsalisbury, revert of a commit
<cristian_c> ah, ok, seen
<cristian_c> sorry
<cristian_c> :)
<neoark> jsalisbury https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1436319 started happening somewhere in 3.13
<ubot5> Ubuntu bug 1436319 in linux (Ubuntu) "Unable to increase nr_requests & change I/O scheduler ..." [Medium,Confirmed]
<jsalisbury> cristian_c, I'm still trying to get a test kernel built for you for bug 972604 .  I'm having some build failures after reverting the suspect commit.
<ubot5> bug 972604 in linux (Ubuntu) "168c:001c [HP Compaq Presario C700 Notebook PC] Wireless led button doesn't switch colors" [Low,Triaged] https://launchpad.net/bugs/972604
<cristian_c> jsalisbury, ah, ok
<jsalisbury> neoark, thanks for the update.  we should be able to perform a bisect to figure the commit that caused this
<jsalisbury> neoark, I'll dig deeper into that bug and see why it was changed, if it was changed on purpose
<neoark> Thanks I wasn't sure if was bugged or changed.
<jsalisbury> neoark, I'll figure that out for you.  If it's a bug, we should be able to figure what caused it.
<jsalisbury> smoser, bjf It figures, after re-deploying the node, I can't reproduce the bug anymore.  Maybe it was just something related to yesterday and the MAAS controller.  Anyway, I'll keep a close eye on things and see if I can make it happen again.
<smoser> jsalisbury, ok. well, as i said, i suspect that your region controller went up.
<smoser> cloud-init is attached to it on every boot. for better or worse.
<jsalisbury> smoser, could be.  I don't administer any of the controller stuff
<smoser> and cloud-init doesn't do a good job of telling you whats going wrong.
<jsalisbury> smoser, thanks for looking. 
<nuno> Hello. May I ask a question regarding the iperf tool ?
<apw> nuno, no point in asking to ask, ask and we may know or redirect you to someone who might
<nuno> ok. So I have a network where I A can reach B and vice versa
<nuno> that link has a queue with a max rate limit of 20mbps (using linux-htb qdisc)
<nuno> when I run iperf tool sending for example 50mbytes of data, I get a value around 18mbps (which does not exceed the 20mbps) on the server
<nuno> On the client I get a value exceeding the 20mbps (around 24mbps)
<nuno> If I reverse and make B client and A the server, the A reports now ~18mpbs and B around 24mbps
<nuno> So, what's the difference between the client and the server values when doing iperf ? On which values should I rely on ?
<apw> nuno, how long are the tested transfers, as i find the first seconds are miss counted due to buffers
<infinity> nuno: iperf, or iperf3?
<infinity> nuno: iperf is, as some would say, "full of lies".  iperf3 slightly less so.
<nuno> let me check, just a second
<nuno> the command I run is just iperf so guess its just iperf (version 2.0.5)
<nuno> apw: I've tested for 6 minutes
<nuno> it was a "1gbyte file"
<nuno> But why server is giving me the "correct" values and client always exceeding ?
#ubuntu-kernel 2015-03-26
<AceLan> apw: I found that lts-backport-vivid branch in trusty kernel tree didn't get update for 3 weeks, could you help to check it out?
<apw> AceLan, i didn't realise anyone was using it, but yes, seems i have been lax pushing the current state of that
<apw> AceLan, and all pushed now
<apw> nuno (N,BFTL), well i'd say as its not machine specific and always the same end, that is is as likely iperf is miss counting on send or recieve which ever is the "wrong" one
#ubuntu-kernel 2015-03-27
<AceLan> apw: got it, thanks. BTW, I always use lts-backport-xxx branch on precise and trusty tree :p
<Odd_Bloke> Hello kernel friends; I have a task for adding PTS/smoke testing in to the CPC image testing.  Is this something I can run with the kernel-testing/autotest stuff, or is this a different beast?
<Odd_Bloke> apw, bjf: ^ ?
<apw> Odd_Bloke, not quite sure what you are asking there, are you asking if running the kernle tests would be a good smoke test ?
<apw> and remind me what PTS means
<Odd_Bloke> apw: That makes two of us. ;)
<Odd_Bloke> apw: I _think_ PTS==Phoronix Test Suite.
<Odd_Bloke> But if it's not obvious to you, then I should probably check what utlemming meant by it.
<apw> Odd_Bloke, could be, not a phrase i use most days for sure
<apw> Odd_Bloke, smoke testing is mormally "basic does it boot and give me a prompt" style testing
<Odd_Bloke> Yeah; I think this is a bit of a confused task.
<Odd_Bloke> I'll check with Ben when he's back in on Monday.
<Odd_Bloke> apw: Sorry for the noise! :)
<apw> Odd_Bloke, np and good luck with that
<bguthro> Greetings - A question about packaging, that I'm hoping someone can help with: Is there a way to do an iterative kernel build, without doing a clean? I'm debugging something that is part of the kernel proper (i.e., not a module) - and have been trying to avoid doing a full clean / build cycle...but so far have been unsuccessful. Despite placing a #error in a .c file as a test, my compile happily packages everything up, seemingly without recompiling
<bguthro>  this file. I'm using "AUTOBUILD=1 NOEXTRAS=1 skipabi=true skipconfig=true skipmodule=true fakeroot debian/rules binary" as a compile line, if it matters.
<bguthro> I suspect there's a wiki page out there somewhere, but I've been unable to find it.
<apw> bguthro, you need to remove the build stamp, and then you can rerun the command, stamps are in debian/stamps
<bguthro> apw, fantastic - thank you much!
<Odd_Bloke> apw: Turns out http://bazaar.launchpad.net/~server-workload-testing-team/server-workload-testing/trunk/files/head:/pts/ is what we were talking about. :)
<apw> Odd_Bloke, so it is phoronix, just a local copy
<Odd_Bloke> It's a wrapper around the Ubuntu package.
<Odd_Bloke> (TIL there's an Ubuntu package for Phoronix)
<flexiondotorg> I been discussing https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1368784/ with cjwatson in #ubuntu-devel
<ubot5> Ubuntu bug 1368784 in virtualbox (Ubuntu) "Vivid and Utopic Virtualbox guest gets only up to resolution of 640x480" [High,Confirmed]
<flexiondotorg> I've got the following work around - https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1368784/comments/17
<flexiondotorg> cjwatson is prepare to update grub-gfxpayload-lists if someone here can confirm "fixing" this issue at a kernel level is hopeless.
<flexiondotorg> So, thoughts?
<flexiondotorg> ogasawara, Can you direct me to someone I can discuss the above with please?
<apw> flexiondotorg, "fixing" at the kernel level, do we know what the issue is ?
<apw> flexiondotorg, the implication of the (admittedly older) comments is that you need virtualbox-guest-x11
<apw> flexiondotorg, and indeed i can confirm that installing the said package does sort things out, who knows what i has in it mind
<apw> seems it has a vbox specific video drivers
<apw> i wonder if they should be being installed by jockey
<flexiondotorg> apw, So the issue is the default resolution when virtualbox-guest-x11 is not installed.
<apw> the default resolution is that offered by the vesa settings i assume ?
<flexiondotorg> apw, The vmware video devices are already blacklisted by  grub-gfxpayload-lists
<apw> ok, so then it sounds like whatever this is using now is a candidate for blacklisting ?
<flexiondotorg> apw, Must be. vesa is used by vbox when the guestadditions-x11 is absent.
<apw> so that is a vbox issue really, offering stupid resolutions by default
<flexiondotorg> apw, Since 14.04. Yes.
<flexiondotorg> apw, The 640x480 thing started sometime during 14.10.
<apw> and presumably it does that because they don't care about you if you don't install their video driver
<flexiondotorg> apw, I couldn't possibly comment ;)
<apw> i wonder why i makes a difference to blacklist it in grub though, vesa must be very broken
<apw> and so i would think rather than being a fallback option to blacklist more things in grub, it might
<apw> be the appropriate option instead
<flexiondotorg> apw, It is odd because when booting from the live media, resolution is 1024x768.
<flexiondotorg> But on first install, resolution is 640x480.
<apw> right, that doesn't use grub, nor initialise the display
<apw> it uses syslinux
<flexiondotorg> apw, Indeed.
<apw> grub initialises the display, because you know the vesa modes offered should be the preferred size of your display, so setting it up early makes sense and makes things prettier
<apw> unless your vesa config is spam
<apw> and has "1 1024x768 2 640x480 (default)" in it ... or equiv
<flexiondotorg> So, possibly a regression in what Virtualbox provides.
<apw> but if we are blacklisting for vbox video anyhow, it may well make sense to blacklist everything when vbox is found
<apw> which is what i assume the wildcard you added does
<flexiondotorg> apw, Yes.
<flexiondotorg> Although, AKAIK, vbox have only ever used one device ID for video.
<apw> flexiondotorg, not that i really know why one would use vbox if you had any other choice
<flexiondotorg> The other "work around" is to configure grub to use 'console' for all video output.
<flexiondotorg> apw, It is very popular with people who just want to test. Low barrier of entry.
<apw> flexiondotorg, i don't find virtmgr any more complex to drive, and it idoesn't have these issue at least
<flexiondotorg> apw, Agreed.
<apw> and i don't need 30k lines of random out of tree junk loaded into my kernle to make it work either
<flexiondotorg> But, people do use vbox. Clearly the Ubuntu GNOME team do who reported this issue.
<flexiondotorg> apw, So the question is. Is this fixable by the kernel team? Seems like a big fat "No" based on what we've discussed?
<apw> well they had much more ufn, they were just exploding in the host when they tried
<apw> flexiondotorg, i am not sure what we would fix, grub handed us a configured terminal, and we continued to use it as instructed
<apw> flexiondotorg, and presumably because vesa, it was at a stupid resolution
<flexiondotorg> apw, That is a good answer.
<apw> i'll try your workaround on that same gnome image in vbox and see how it looks
<flexiondotorg> apw, So I think that blacklisting the vbox video device in grub is the way forward.
<flexiondotorg> apw, OK. Thanks for testing.
<flexiondotorg> apw, I am the maintainer of Ubuntu MATE BTW. This issue was flagged up in Beta 2 QA and I decided to take a peek.
<apw> flexiondotorg, and i think the behaviour with the blacklist seems more useful, and i assume if i install the -guest-x11 i'll get go faster stripes
<flexiondotorg> apw, Yes with guest-x11 install you get dynamic resizing and such.
<apw> flexiondotorg, but yes, i htink my prefrered option is this blacklist, and if it fixes the issues you have with locked disks that sounds liek a win
<flexiondotorg> apw, Agreed. Although the inability to enter encryption pass phrases affects actual hardware too. By blacklisting vbox for grub you get a text mode plymouth which always works.
<apw> flexiondotorg, yeah, i assume we have a lot of issues there now we have systemd fun to play with
<apw> i guess i ought to reinstall some of my kit with that to find out
<flexiondotorg> apw, systemd isn't to blame for passphrase entry. That was present in 14.10 also.
<flexiondotorg> apw, My "solution" was not to ship a graphical plymouth theme in 14.10. That way only test mode available and pass phrase entry worked.
<flexiondotorg> apw, Are you still testing this on an Ubuntu GNOME image or have we concluded that blacklisting is the solution?
<apw> i think we concur blacklisting is the way forward for the size issue
<apw> the plymouth not working is separate
<flexiondotorg> apw, Thanks for your time.
<apw> flexiondotorg, thanks for paying attention to it :)
<flexiondotorg> apw, I'll report back to cjwatson and he can make the blacklist change.
<flexiondotorg> apw, Most welcome :)
<apw> ack, thanks
<bubba2> I'd like to test a recent mainline bugfix that was "queued for 4.0".  Someone on the launchpad bug page said "no longer affects: linux-lts-vivid".  Can someone explain what that means?
<bubba2> The lts and vivid part confuses me.  I'm on 14.04.2 - can I install that kernel build?  Or do I go to 15.04 vivid and install it (why the lts)?
<bubba2> This is the issue: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1414930?comments=all
<ubot5> Ubuntu bug 1414930 in HWE Next "[Lenovo ThinkPad X1 Carbon 20BT] Buttons of Synaptics trackpad doesn't work" [Medium,In progress]
<bubba2> Is this more of a dev chat?
<bubba2> squirrel
#ubuntu-kernel 2015-03-28
<apw> bubba2 (N,BFTL), that lts version is a backport for trusty of the vivid kernel, it isn't available yet
<kripper> how can I find out which process is calling "systemctl stop vdsmd"?
<kripper> strace is telling me that PID 1 (init) is SIGTERM'ing a given process
<kripper> but how can I identify what is calling systemctl?
<kripper> is there something to dump a stacktrace?
#ubuntu-kernel 2015-03-29
<cheater> hi
<cheater> can someone tell me how to get aufs support (for docker) on ubuntu 14.04 64-bit?
<cheater> on a vanilla system docker uses device mapper and its support is buggy (it cannot be worked around, i need to start using aufs)
<cheater> (but apparently aufs is better anyways)
<cheater> i would appreciate any sort of help with this
<pkern> cheater: Depending on your environment you need to install linux-image-extra-* for aufs.
<apw> otherwise it should just be there to use by default, not sure i know any more about the docker configuration to help with that though
<cheater> pkern: as i said, i managed to do that already. i just wonder if btrfs has any advantages over aufs.
<cheater> pkern: oh sorry i said that in another channel :)
<cheater> pkern: thanks for your help :) i guess i managed to figure this stuff out before you answered and then forgot i came here to ask, and after that i mixed up the channel windows!
<pkern> cheater: http://www.projectatomic.io/docs/filesystems/
<pkern> cheater: Especially the last section.
<cheater> hey that's an interesting link, thanks pkern
#ubuntu-kernel 2016-03-28
<lamont> jsalisbury: good kernel, will update the bug shortly
<jsalisbury> lamont, ack
<lamont> once I recover my work environment... I'll be running on it for a bit (tbf, its -14, not the now-current -15..)
<lamont> jsalisbury: updated.  (and if there's a new kernel, highlighting me in IRC is advisable...
<lamont> jsalisbury: I'm inclined to reopen 1543683 unless you object
<jsalisbury> lamont, that's fine.  I send the current update to upstream.  It's probably best to reopen until we know if the commit needs to be reverted or a new commit to fix the interaction between them is needed.
<lamont> ack
<lamont> in progress, it is
#ubuntu-kernel 2016-03-29
<stefannnn> Hello, last times I have problems with my Ubuntu 14.04.4 because the cpus get stalled and the server becomes unresponsive. Kernel:  3.13.0-83-generic x86_64
<stefannnn> I uploaded a textfile containing the dmesg output to a webspace and could provide it to you if necessary
<stefannnn> thanks in advance
#ubuntu-kernel 2016-03-30
<fg__> cking: is there any roadmap on ubuntu's plans for zfs in xenial/kernel 4.4? are you planning to stay on 0.6.5(.6?), or will you switch to 0.7 once that is released upstream?
<fg__> or 0.6.6, whichever happens first ;)
<cking> fg__ i think that is a discussion point that has not yet been worked through
<cking> fg__, being an LTS, we go for fixes and stability 
<cking> so generally, I expect I will be picking important fixes and back porting them rather than moving to 0.7 
<fg__> that's what I expected as well :)
<mIKEjONES> windos 10 is superior
<pkern> Hi. I seem to have a hard time to get pstore to persist a panic (both with efi and esrt backends). Does anyone happen to know how to turn it on properly? I set "pstore.backend=efi/esrt printk.always_kmsg_dump=Y" to test, but then I guess the latter might not work because CONFIG_PSTORE_CONSOLE isn't set...
#ubuntu-kernel 2016-03-31
<genkgo> jsalisbury: good news regarding the backup issue, great you find a version that does not exhibit the bug
<caribou> smb: do you know of a way to have zfcp devices made available upon reboot without having to use chccdev -e ?
<smb> caribou, yeah, I think that was touch /etc/sysconfig/hardware/<devid> iirc
<caribou> smb: and devid being what ?
<smb> like the argument you give chccwdev 0.0.xxxx
<smb> caribou, but I might have the path wrong... a sec
<smb> caribou, So I am a bit confused as I have found some installs without it... maybe I forgot to actually do those... hm... but if /etc/sysconfig is there its .../hardware/config-ccw-0.0.xxxx
<caribou> smb: ok, I'll try that
<caribou> smb: I don't have a /etc/sysconfig
<JanC> sysconfig sounds like a RH thing
<smb> Yeah I think it might have been a thing they got rid of
<smb> Initially it was there but I know have two guests I did install but ended up being different
<smb> caribou, So for that case you probably can add a modprobe.d file that adds the device numbers with the device parameter
<JanC> udev?
<JanC> well, probably needs more than udev (this is SCSI over fibre, I understand)
<smb> Yeah, well also its common (especially LPARs) to not want to enable all devices on the channel subsystem that are visible. 
<JanC> I don't have that sort of equipment, but I can see why you won't want that
<caribou> smb: JanC: googling about it yesterday brought back RHEL hits about a /etc/zfcp.conf file containing a list of devices to enable
<smb> caribou, I guess in our case that will need some part of sysvinit or systemd to care about it... 
<caribou> well, looks like we will need a zfcp specific kernel which needs to be smaller than 32Mb
<caribou> apw: smb ^^
<smb> caribou, I believe I remember needing a kernel not sure about the memory limitation
<caribou> smb: well, if I try to use our standard kernel, I get MLOLOA018E: DUMP memory limit reached: 0x2000000 bytes. which is coherent with what inaddy said
<smb> caribou, ah ok... 
<pkern> smb: https://packages.qa.debian.org/s/sysconfig.html does it on Debian
<smb> pkern, Yeah thanks. It just sounded like RH (which iirc have most of their config there). For s390x it would have been sysconfig-hardware. And my confusion because there are slightly differing installations around
<popey> hello!
<popey> My 14.04 machine (x220) freezes a LOT!
<popey> probably heat related, it's in a docking station. I am getting https://bugs.launchpad.net/ubuntu/+source/thermald/+bug/1543046
<ubot5`> Launchpad bug 1543046 in thermald (Ubuntu) "thermald spamming kernel log when updating powercap RAPL powerlimit" [High,Fix released]
<popey> which says it's fix released.
<popey> I'm on 4.2.0-34-generic but I am seeing that still  - is the fix in 14.04?
<cking> popey, i'd like to answer that right away, but I'm completely snowed under with some other higher priority items. I believe the fix should be in 14.04, but I need to check and I've not got the free cycles at the moment
<popey> ok cking 
<cking> popey, can you file a bug, and attach the output from dmesg. I have an x220 so I can see if I can reproduce the error if need be
<cking> but I probably can't devote much time on this until late tomorrow or monday
<popey> cking: ok
<popey> cking: no hurry
<popey> cking: done bug 1564443
<ubot5`> bug 1564443 in linux-lts-wily (Ubuntu) "System freezes, dmesg spammed, overheating laptop" [Undecided,New] https://launchpad.net/bugs/1564443
<jsalisbury> genkgo, The Ubuntu 3.13.0-17 kernel also for almost 24 hours without hittting the bug, so we're getting closer.  It will take a few days to narrow down the commits since it takes at least 8 hours to reproduce
<genkgo> jsalisbury: hehe, awful debugging
<genkgo> jsalisbury: but great we are getting close
<jsalisbury> genkgo, just time consuming.  Yeah we are getting there.  Once I find the last good and first bad commit, I should be able to review the commits between them and figure it out.
<genkgo> jsalisbury: the user that reported the bug first was running 3.13.0-49
<genkgo> was was the earliest kernel with the bug you found?
<genkgo> i.e. what is the gap between the tested good version and bad version?
<jsalisbury> genkgo, I thinkg -49 is the last know earliest version with the bug.  So right now -17 is good and -49 is bad, but there are allot of commits between the two.  I'm going to test in between those versions and then repeat when I have those test results.
<genkgo> alright, that leaves at least 5 more tests
<jsalisbury> genkgo, we should have it figured out within a week or sooner
<genkgo> great, really great
<jsalisbury> genkgo, it would be easy to say the bug doesn't happen after 8-9 hours of testing, but giving it a ful 12 - 24 hours gives more confidence
<genkgo> jsalisbury: i understand, i also think that the earlier versions should exhibit the bug easier
<jsalisbury> genkgo, yes, I was able to reproduce the bug in an hour or two with earlier kernels, so I hope the first next bad kernel I hit happens fast in the testing.
<genkgo> jsalisbury: is it already where it is the kernel or the integration services?
<genkgo> clear
<jsalisbury> genkgo, I think it's definatly in the kernel, since I tested all the different versions of LIS with CentOS and could not reproduce the bug.
<genkgo> alright
<leitao> ogasawara, Hello Leann. I just answered 1556096, but I am not able to assign back to ckt.
<ogasawara> leitao: thanks, I'll take a look
<leitao> ogasawara, thanks. Also, 1564487 is a regression after the cherry pick of 8244062ef1e54502ef55f54cced659913f244c3e
<ogasawara> leitao: ack, I'll get the team to take a look at that as well
<leitao> ogasawara, thank you!
#ubuntu-kernel 2016-04-01
<erle-> is the ZFS in 16.04 a port of  Solaris code or a different implementation?
<rtg> erle-, https://github.com/zfsonlinux/zfs.git
<erle-> thanks
<erle-> that's exactly what I was looking for
<rharper> xenial s390x, loading bcache module, I see no /sys/class/block/bcache dir ... is that expected? 
<rharper> indeed, I was looking for /sys/fs/bcache; 
<pkern> Hi. I seem to have a hard time to get pstore to persist a panic (both with efi and esrt backends). Does anyone happen to know how to turn it on properly? I set "pstore.backend=efi/esrt printk.always_kmsg_dump=Y" to test, but then I guess the latter might not work because CONFIG_PSTORE_CONSOLE isn't set...
<stgraber> cking: hey, so zfsutils-linux pulls in zfs-zed right now which then pulls in an e-mail server, that doesn't seem ideal. Could we have zfs-zed be demoted to suggests?
<cking> stgraber, yep, sounds like a good idea
<cking> i'll do that right now
<stgraber> cking: thanks
<stgraber> cking: zfs supports s390x now right?
<cking> stgraber, s390x, aarch64, powerpc64 and amd64
<stgraber> cking: hmm, maybe I'm a bit behind on my ubuntu kernels then, not seeing a zfs.ko on s390x
<cking> stgraber, yep, wait for next kernel
<stgraber> ok, I see it in -16 but I'm on -15 for some reason
<stgraber> lets reboot that box
<infinity> stgraber: As of -17 (or -18?), it'll be all 64-bit kernels.
<infinity> stgraber: But yeah, I think it's on in -16 on s390x.
<stgraber> yeah, I just tested it on s390x with -16 and it works great
<infinity> stgraber: Shame about the lack of 32-bit kernel support for people like you who are (I assume) building userspace on top. :/
<infinity> stgraber: I guess you're doing some if zfs; elif btrfs; elif overlay; else FUCK; fi thing? :P
<stgraber> yeah, we tested it on i386 just for fun a while back, had that machine kernel panic a dozen times in a day :)
<stgraber> nah, lxd by default does plain old dir, you have to opt into anything fancier or run "lxd init" which does the setup for you based on a few questions
<stgraber> but yeah, we've had to push back on pressure to always setup zfs due to not having it on all arches which means all the docs and stuff have to cover all the storage backends (zfs, btrfs, lvm+ext4, lvm+xfs and plain-old-slow-dir)
<infinity> stgraber: Oh, good, lvm too.  You haven't forgotten people like me who live comfortably in the past.
<stgraber> yeah, we do lvm with thin provisioning but it kinda sucks when you try to migrate things between machines, doesn't let us resize the container up and down while it's running and is kinda slow in general, but yeah, we have it
#ubuntu-kernel 2017-03-27
<_Frank_> Hello! - When compiling an unmodified xenial hwe kernel 4.8.0.41 some deb-packages are not generated compared to xenial 4.4 kernel. e.g. linux-tools-common*.deb. My command sequence: fakeroot debian/rules clean; fakeroot debian/rules binary-indep binary-perarch binary-generic   Which commands do I have to use instead?
<Osirus126> hello everyone, i am in need of some advice. I am using KDE Neon and when i update my system using apt, it says i have updated to the latest version of the kernel which i think is 4.4.0-70-generic. Now when i reboot my system and check what version of the kernel i am running with "uname -r" i get  4.8.0-44-generic. i think it is an issue with the default kernel in grub. when i run sudo update-grub2 it finds all installed versions of 
<Osirus126> the kernel but does not set the newest one to the default. can anyone help?
<Osirus126>  ~$   sudo update-grub2
<Osirus126> Generating grub configuration file ...
<Osirus126> Warning: Setting GRUB_TIMEOUT to a non-zero value when GRUB_HIDDEN_TIMEOUT is set is no longer supported.
<Osirus126> Found linux image: /boot/vmlinuz-4.8.0-44-generic
<Osirus126> Found initrd image: /boot/initrd.img-4.8.0-44-generic
<Osirus126> Found linux image: /boot/vmlinuz-4.8.0-42-generic
<Osirus126> Found initrd image: /boot/initrd.img-4.8.0-42-generic
<Osirus126> Found linux image: /boot/vmlinuz-4.4.0-70-generic
<Osirus126> Found initrd image: /boot/initrd.img-4.4.0-70-generic
<Osirus126> Adding boot menu entry for EFI firmware configuration
<Osirus126> done
<Osirus126> never, mind.. i just had a dull moment there... didnt pay attension to the version numbers and as a result asked a silly question. my mistake. lmao
#ubuntu-kernel 2017-03-29
<LocutusOfBorg> hello apw, strange situation involving kernel
 * apw looks up
<LocutusOfBorg> install inside virtualbox the new zesty iso image
<LocutusOfBorg> apt-get update && dist-upgrade (install proposed)
<LocutusOfBorg> install virtualbox-guest-x11
<LocutusOfBorg> reboot
<LocutusOfBorg> blank screen
<LocutusOfBorg> something can't start the graphic
<apw> hmm
<LocutusOfBorg> now, go in tty1
<LocutusOfBorg> apt-get install virtualbox-guest-dkms
<LocutusOfBorg> reboot, everything is fine, 3d acceleration works correctly
<apw> hmmm so like vbox is just broke/missing in the kernel in -proposed ...
<LocutusOfBorg> ok, the guest-dkms packages inside the kernel are 5.1.16 while the vbox modules are 5.1.18, but modules didn't change
<apw> odder and odder
<apw> sforshee, ^^
<apw> i
<apw> i guess we need to try and reproduce that and see if we cna figure out what is off there
<LocutusOfBorg> strange fact, it isn't missing
<apw> is it loaded ?
 * LocutusOfBorg reboots the machine
<apw> it might just be timing, or something odd
<LocutusOfBorg> but why the dkms one is working?
<LocutusOfBorg> yes, it is loaded
<LocutusOfBorg> vboxsf vboxvideo vboxguest all loaded
<LocutusOfBorg> (lsmod returns them as loaded)
<LocutusOfBorg> now, I can force the vbox-guest-x11 to need virtualbox-guest-dkms, but seems strange
 * LocutusOfBorg blacklists vboxvideo and retries
 * LocutusOfBorg nothing happens
 * LocutusOfBorg install dkms package and compares lsmod outputs
<LocutusOfBorg> nothing strange
<LocutusOfBorg> even removing the dkms kernel modules works
<LocutusOfBorg> now, the dkms is triggering some code that the kernel isn't
<LocutusOfBorg> some postinst maybe
<LocutusOfBorg> oh... udev :/
<LocutusOfBorg> apw, confirmed
<LocutusOfBorg> https://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/tree/debian/virtualbox-dkms.udev
<apw> missing a udev script ?
<LocutusOfBorg> sorry
<apw> oh when did that appear ?
<LocutusOfBorg> https://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/tree/debian/virtualbox-guest-dkms.udev
<LocutusOfBorg> this one
<LocutusOfBorg> KERNEL=="vboxguest", NAME="vboxguest", OWNER="root", MODE="0660"
<LocutusOfBorg> KERNEL=="vboxuser", NAME="vboxuser", OWNER="root", MODE="0666"
<LocutusOfBorg> adding this rule to your kernel works
<LocutusOfBorg> who should add it?
<LocutusOfBorg> yes, a basic kernel without guest-dkms, and that rule added works
<LocutusOfBorg> so, somewhere the kernel should add it? :)
<apw> oh dear, that is as they say difficult, would you file a bug against linux, so i can think about how we handle that
<apw> drop the bug number in here...
<apw> as obviously we can only have one script but have three kernels installed
<LocutusOfBorg> alternatively I can add such hack in virtualbox-guest-x11 instead
<LocutusOfBorg> somewhere without the GL/EGL custom library everything "seems" to work
<LocutusOfBorg> but you don't have 3d acceleration
 * LocutusOfBorg opens a bug
<apw> LocutusOfBorg, drop the bug# here so i can find it; we have a lot fo bugs
<LocutusOfBorg> yep
<LocutusOfBorg> apw, I assigned LP: #1677170 to you
<ubot5> Launchpad bug 1677170 in linux (Ubuntu) "Linux vbox guest modules needs udev rule" [High,Confirmed] https://launchpad.net/bugs/1677170
<LocutusOfBorg> so you don't loose it :p
<LocutusOfBorg> as usual feel free to downgrade reassign or to whatever you prefer
#ubuntu-kernel 2017-03-30
<ivan> could whoever pushes please push to ubuntu/ubuntu-xenial.git, it's missing Ubuntu-4.4.0-71
<hallyn> stupid question.  If I have livepatch enabled, how do I know whether my kernel (a) is in fact being livepatched and (b) is uptodate with the most recent panicy cve-patching kernel release?
<hallyn> does "fully-patched: true" mean that latter?
<hallyn> (as a response to 'sudo canonical-livepatch status')
<stgraber> hallyn: canonical-livepatch status --verbose
<stgraber> hallyn: that should show you the CVE that got patched too
<smb> ivan, xenial tree is updated now
<smb> though only the master branch right now
<ivan> smb: thanks
<ivan> is there anything in 4.4.0-64 -> 4.4.0-69 (proposed, yes) that could have regressed network device renaming? I used to see eth0,eth1 -> em1,em0 renaming but now absolutely no renaming
<ivan> on just one machine. of course.
<ivan> running a tg3 0000:03:00.0 eth0: Tigon3 [partno(N/A) rev 5720000] (PCI Express)
<ivan> oh wow a SIOCSIFNAME ioctl does this so I need to look outside the kernel too
<smb> ivan, I believe the whole renaming game is in some way tied into systemd nowadays (formerly done by udev rules)
<ivan> thanks
<ivan> I need a Really Stable Device Names that just brings up all the network devices and sees which gets which IP over DHCP
<smb> ivan, Maybe "man systemd.link" is helpful for you. Should be working nowadays by creating a *.link file in /etc/systemd/network with a match section for the mac address and a link section with the desired name.
<smb> Then update-initramfs -u (not 100% its needed but should not hurt either)
<ivan> ah thank you
<ivan> it looks like I had an empty (with comments) /etc/udev/rules.d/80-net-setup-link.rules that was inhibiting network device renames
<ivan> but now they're eno1,eno2 instead of em1,em0. whatever, I'll live with it
<ivan> _oh_, em0/1 aren't stable names, that was a dumb thing to assume
<ivan> oh, em = embedded NICs and they're supposed to be stable, I guess the kernel stopped thinking my NICs were embedded NICs (?), whatever
<hallyn> stgraber: hm, it doesn't.  i wonder whether the latest cve was not patchable
<ivan> oh, I see, things changed because I purged biosdevname
<manjo> I need to add a module for ethernet and PHY for arm64 vendor.. it is applicable only to ARM64 and a given vendor .. should I add that to d-i/modules/arm64/nic-modules ? d-i/modules/arm64/modules simply includes generic nic-modules so asking 
<manjo> apw, ^ any thoughts ? 
<manjo> apw, this for di install of that system 
<rtg> manjo, looks right
<manjo> rtg, add it to arm64 specific nic-modules correct ? 
<rtg> manjo, yep
<manjo> awesome thanks
<lostgoat> hey guys, trying to make a ppa with some local kernel changes + 4.11-rc4
<lostgoat> I've got my kernel + debian patches, and a source package I created using "debuild -S -I -i" 
<lostgoat> that uploaded nicely to launchpad, but resulted in error building after 5 hours
<lostgoat> /bin/bash: line 3: /<<BUILDDIR>>/linux-4.11.0-rc4+losgoat/debian/build/udeb-meta-packages: No such file or directory
<lostgoat> I can look for the solution to this, but I was mostly curious if anyone knows any other pitfalls I should be trying to avoid
<lostgoat> don't want to have to wait another 5 hours for a silly mistake
<lostgoat> Or if anyone knows how to perform the same build locally that would be great
 * lostgoat is not super experienced using debuild
<apw> lostgoat, did you clean the package before you built it ?
<apw> lostgoat, the specific error you have implies you have debian installer bits turned on but no d-i config
<apw> lostgoat, if you arn't making old style CDs from your kernel you might want to set disable_d_i=true in your buidl
<lostgoat> apw: yeah I had a local build at some point, but I ran fakeroot debian/rules clean before starting the debuild command. (and also a git clean -fd before that). I might have messed this up somehow though
<lostgoat> I'll look into disable_d_i and turn it off as you suggested. I don't need CDs
<lostgoat> apk: thanks for the tips
<lostgoat> *apw
<lostgoat> apw: I've also read about disabling abi checks. Is that something else I should be doing?
<apw> yes most likely
<apw> skipabi and skipmodule something like that
<lostgoat> thanks, will do
#ubuntu-kernel 2017-04-01
<frbd> Did the ubuntu package linux-image-lowlatency (and its latest dependency actual kernel image) stop supporting AMD 32 bit processers after about Kernel 4.8.0-22-lowlatency?
<frbd> LOGOUT
<frbd> I am running Kernel linux-image-4.8.0-22-lowlatency on my AMD A8-5600K processor. It appears that later kernels no longer support my 32-bit processor, and if I install linux-image-lowlatency, this will install the Kernel 4.8.0-45, which will not work on my system. It appears that since Kernel 4.8.0-22, the ubuntu lowlatency kernels have been compiled for 64-bit processors. Is this correct? What package should I install to run the
<frbd> latest kernel compiled for my 32-bit processor, or will I need to download and compile my own kernels going forward? Thank you!
<frbd> logout
#ubuntu-kernel 2018-03-26
<dijuremo> tseliot: I have not filed a bug report on any of my finding
<dijuremo> FWIW, I am running nvidia 384.111 with 4.4.0-116-generic on Ubuntu 16.04 and it is working OK. I just ran the updates, rebooted and it came up just fine, nvidia drive is running and a simple glxgears shows high fps.
#ubuntu-kernel 2018-03-27
<dijuremo> Alright, so I have another DELL workstation that totally fails to work properly after BIOS update. This is an Ubuntu 16.04 install, was updated to latest packages and installed linux-generic-hwe-16.04 kernel. I used the nvidia-384.111 driver and the latest BIOS A16. The machine randomly hangs. I tried adding nospectre_v2 as a boot option but still seems to work for a bit, but if I log off, which resets the X system, i.e. lightdm seems to r
<dijuremo> This is a DELL T3610. In order to get everything working again, I had to downgrade from BIOS A16 (released march of this year) to BIOS A14, released May 2017. With the old bios and absolutely no additional kernel options, the computer is stable.
<dijuremo> The system has two Quadro K2000 video cards installed.
<tyhicks> dijuremo: I'm curious if you've tried to use the intel-microcode packages from https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa ?
<tyhicks> dijuremo: they contain updated microcode which could be the same version that's delivered in your BIOS update but there could be differences
<tyhicks> dijuremo: you'd need to install the amd64 deb and then reboot
<tyhicks> dijuremo: assuming that you're running xenial, you can find the deb here: https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+build/14453957
#ubuntu-kernel 2018-03-28
<xnox> cking, how silly is this udev rule - https://github.com/ibm-s390-tools/s390-tools/blob/master/etc/udev/rules.d/60-readahead.rules#L10 ? why is read_ahead_kb 128? should the kernel read_ahead_kb be bumped? is there a sysctl to set the default read_ahead_kb in the kernel?
 * xnox is grepping the kernel and getting lost
<xnox> can i bump it to 512 everywhere?
<xnox>  916        q->backing_dev_info->ra_pages =                                                                                                                                                                        
<xnox>  917                        (VM_MAX_READAHEAD * 1024) / PAGE_SIZE;
<xnox> oooh
<cking> 512 is quite large for all systems isn't it?
<xnox> http://paste.ubuntu.com/p/btw3vKkx8X/
<xnox> is my thinking....
<xnox> cking, are you saying 128kb should be enough for everyboy - Bill Gates?
<xnox> cking, are you saying 128kb should be enough for everybody - Bill Gates?
<cking> heh, well, today's drives are getting faster and memory is larger so a larger readahead makes some sense I suppose
<xnox> cking, if that's too large for all systems, i want this exposed as a /all/ sysfs ctl such that I can configure the default at runtime and apply to all.
<xnox> cause at the moment, i can either set it on each device as they appear.... which is racy. Or recompile the kernel.
<xnox> cking, given 4k native drives, bumping the readahead 4 times makes sense to keep the constant readhead number of sectors, no?
<cking> xnox,  the problem is that the default may not be ideal for all use cases. for example, doing lots of random I/O you don't want a really large readahead
<cking> large readahead makes sense when you are streaming data in sequentially
<xnox> on 4k native drives, the cost should be the same as it used to be with 128kb & 512 sector drives.... unless i'm a clueless muppet =)
 * xnox looks at the historgram of all reads an "average" machine does.
 * xnox notes there is no such graph
<cking> well, you still have bus bandwidth limitations, large readahead will impact even with large sectors, so the choice is a good compromise, which is hard to guess
<xnox> i'm wondering if this is true in general, given all of this is hidden inside the layers of bcache / md / filesystems layers, and most of that stuff is very extends happy these days, etc.
<xnox> cking, and ibm is bumping that up, on s390x, because everything is big on big iron?
<cking> xnox, s390x can do I/O *really* fast
 * xnox notes that it looks like that udev rule they commit alongside the bootloader is meant to run everywhere.
<cking> it's one of it's key wins
<xnox> oh, so if I condition this to s390, people will complain? =)
 * xnox about to make s390x bloody fast; and make all the other kids complain
<cking> xnox, whatever is chosen is going to be sub-optimal for somebody
<xnox> however, ibm recommends this and all of us ship that udev rule, so for everybody we go with ibm recommendation on this one.....
<xnox> one can overcommit z/vms too
<cking> very true
<xnox> i really don't like how it is *1024/PAGE_SIZE. Surely a default of a specific number of sectors or pages makes more sense. And systems with larger disk sectors / memory page_size get more caching.
<xnox> btrfs does funky stuff to the device.
<xnox> 2727        sb->s_bdi->ra_pages = VM_MAX_READAHEAD * SZ_1K / PAGE_SIZE;                                                                                                                                            
<xnox> 2728        sb->s_bdi->ra_pages *= btrfs_super_num_devices(disk_super);                                                                                                                                            
<xnox> 2729        sb->s_bdi->ra_pages = max(sb->s_bdi->ra_pages, SZ_4M / PAGE_SIZE); 
<cking> nice, so a device specific setting behaves differently depending on the file system, yat
<cking> *yay
<xnox> btrfs goes to 11
<xnox> cking, well, btrfs does take over the whole device, if the whole device is added to the pool....
<xnox> md layer does stuff with stripe sizes
<xnox> nfs too
 * cking wonders what zfs does
<dijuremo> tyhicks: I was running: ii Â intel-microcode Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 3.20180108.0+really20170707ubuntu16.04.1
<dijuremo> I have installed your package, intel-microcode (3.20180312.0~ubuntu16.04.1)
<dijuremo> And will conduct testing and report back.
<f_g> cking: it sets ra_pages to 0
<f_g> ah no, to 1 actually
<cking> f_g, that's not what I expected for sure
<f_g> courtesy of having its own prefetcher
<cking> ah, that makes sense
<f_g> bc17f1047a83cc8c4065e0ef84333a0d9b9d73aa
<f_g> :)
<dijuremo> tyhicks: My first test was to update the microcode, reboot, and keep the old firmware A14. Machine seemed fine, though it fully hung on my first test. The test was to log in, run glxgears and Matlab: bench(5) then log off. The machine hung up after login off at the login screen where a darker shade appeared over the whole screen. Num Lock would not work on the keyboard. I force restarted the machine, repeated the same process 3 times with 
<dijuremo> tyhicks: My second test was to update to A16, which is the latest firmware for the DELL T3610. I booted up, was able to log in, run glxgears and Matlab, log off and log back in and repeat the test several times (3+) with no problem. The machine was crashing (screen hung) right after entering the password and hitting enter when I was using the outdated microcode. Any idea when the new microcode package is going to be made available in the m
<tyhicks> dijuremo: thanks for testing! I believe that the security team plans to publish the new intel-microcode this week
<tyhicks> dijuremo: could you paste the output of 'iucode-tool --scan-system' when you get a chance?
<dijuremo> tyhicks: oh well, spoke too soon, now that we have added gnome-desktop per user request, the machine is back to crashing either at the login screen or if we log out after starting a graphical session... sigh...
<dijuremo> iucode-tool: system has processor(s) with signature 0x000306e4
<dijuremo> Is there a need to rebuild the nvidia kernel module with the latest Intel Microcode in place?
<tyhicks> dijuremo: no, there shouldn't be
<tyhicks> dijuremo: can you pastebin the output of 'dmesg -t | grep -i microcode'? are you still running firmware A16?
<tyhicks> dijuremo: also, can you elaborate on what you mean by "crashing"?
<dijuremo> The system freezes completely, only hardboot from the power button will reboot it. Numlock stops turining on/off in the ssytem
<dijuremo> microcode: sig=0x306e4, pf=0x1, revision=0x42c 
<dijuremo> microcode: Microcode Update Driver: v2.2.
<dijuremo> Our testing earlier today involved two separate users login in and running the usual Matlab and glxgears for tests. It was all working well up until the point we added gnome-desktop to the machine. It seems the issues are related to GUI/Nvidia, but I cannot be sure.
<tyhicks> that matches the microcode revision in the latest blob from intel:
<tyhicks> 01/126: sig 0x000306e4, pf mask 0xed, 2018-01-25, rev 0x042c, size 15360
<tyhicks> dijuremo: which kernel are you running?
<dijuremo> 4.13.0-37-generic
<dijuremo> BIOS Information 
<dijuremo>  Â Â Â Â Â Â Â Vendor: Dell Inc. 
<dijuremo>  Â Â Â Â Â Â Â Version: A16 
<dijuremo>  Â Â Â Â Â Â Â Release Date: 02/05/2018
<tyhicks> dijuremo: at this point I think we're better off tracking all the failing combinations in a bug report
<tyhicks> dijuremo: could you file one?
<dijuremo> Point me in the right direction, never done one for Ubuntu...
<tyhicks> dijuremo: also, I think it'd be very helpful to confirm one more time that lockups do not happen after removing intel-microcode, downgrading to firmware A14, and then rebooting into 4.13.0-37-generic
<tyhicks> dijuremo: I think you should initially file it against intel-microcode: https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+filebug
<dijuremo> Let me try going to A14 without even removing gnome-desktop and I will report back. The system was stable with BIOS A14 and new microcode.
<tyhicks> dijuremo: please include that info in the bug report
<tyhicks> dijuremo: at this point, it is sounding like a bad BIOS update
<dijuremo> tyhicks: This behaviour is the exact same in several DELL and one Lenovo System. Machines boot up just fine and freeze after attempting to log in. Or if you are loging off, right after log off, I think when lightdm restarts.
<dijuremo> In all cases, we have fixed the issues by downgrading the BIOS.
<tyhicks> dijuremo: including the 'iucode-tool --scan-system' output from all affected systems would be helpful
<dijuremo> But in the other DELL machines I had not tested the latest microcode update
<dijuremo> Neither the Lenovo M93p
<tyhicks> dijuremo: I don't have a machine with 0x000306e4 so I'm unable to reproduce with that particular processor
<tyhicks> dijuremo: big thanks for helping so much to test out all the different combinations
<dijuremo> The Lenovo had an i7, would that be a good test you can check?
<dijuremo> The T series are all Xeons. Seen it on the 5810 which has the E5-1680 and the 5820 with the newer W-2XXX cpus
<tyhicks> no i7s but let me check my xeons
<dijuremo> I am going to see what I can do, I have given these systems to end users, so not so sure they will be happy with me hijacking them for a few hours...
<tyhicks> fwiw, I've been running the updated microcode for weeks now without any issue
<tyhicks> I haven't applied any BIOS updates to those machines, though
<dijuremo> Do you have Nvidia cards?
<tyhicks> no
<tyhicks> all machines are either intel graphics or headless
<dijuremo> So the BIOS is pretty much what breaks them...
<dijuremo> And I think it is highly related as well to the nvidia driver. though we had one set of laptops with the freezing issue which was solved by running the 4.4.0-116 kernel I think.
<dijuremo> It was a couple of weeks ago, so I do not remember much. But bought two laptops, one came with an older firmware and took 4.4.13-036 without issue. The other machine had the newer firmware and would freeze.
<dijuremo> I tried downgrading the BIOS on the laptop that was freezing, but the downgrade was blocked by DELL :(
<dijuremo> At that time I did not know of pti=off or nospectre_v2 or updating microcode, so I have not tried any of those....
<dijuremo> tyhicks: FWIW, the machine is currently up, without login into it. So it seems that the graphical login triggers the freezes, though one time earlier today it fully froze during boot.
<dijuremo> tyhicks:  I am ssh-ing it from another machine and have a shell on it..
<tyhicks> dijuremo: ok, so you have the A14 firmware with intel-microcode uninstalled?
<dijuremo> Nope, I have A16 without having logged in at all in the GUI
<dijuremo> Still A16 microcode .deb from march I got from your PPA
<tyhicks> dijuremo: I think we've established that the A16 BIOS locks up in all cases
<dijuremo> tyhicks: A16 locks up in all cases after login via the GUI. Sometimes as you log in, sometimes when you try to log off and lightdm restarts
<dijuremo> That is with the microcode from March (your PPA deb package).
<tyhicks> dijuremo: I wonder if we'll see any microcode revisions reported by the kernel with A16 but with intel-microcode uninstalled
<dijuremo> Without the microcode, it freezes as soon as lightdm starts
<tyhicks> huh
<tyhicks> that makes me think that the BIOS has the microcode that Intel pulled due to QA issues
<dijuremo> With the older 201801 microcode from the main Ubuntu repo
<tyhicks> Intel briefly released updated microcode and the pulled it because users were experiencing issues
<dijuremo> These BIOS releases are from March, so supposedly vendors had not published the first problematic ones or removed them from their sites.
<dijuremo> But some of the 5820 and 5810 BIOS are very freshly released... 
<tyhicks> I don't know how to tell which microcode revision is provided in a BIOS update
<dijuremo> The T3610 is from this month as well.
<dijuremo> A16 Dell Precision Workstation T3610 System BIOS  BIOS	06 Mar 2018	
<tyhicks> timing doesn't tell us if they are shipping a possibly bad revision
<dijuremo> I do not know how to check for good/bad
<dijuremo> My understanding was they were not releasing the ones with the bad fixes...
<dijuremo> How could one figure out what those are?
<tyhicks> I'm not sure - thinking about that now...
<dijuremo> For the 5820 there is a newer BIOS released yesterday.... Dell Precision 5820 Tower System BIOS BIOS	27 Mar 2018 1.4.0
<tyhicks> dijuremo: you could try uninstalling intel-microcode, rebooting, and then see if the 'dmesg -t | grep -i microcode' command shows anything
<dijuremo> Will do that now
<dijuremo> We do not want the older microcode from 201801, right?
<tyhicks> dijuremo: 'sudo cat /sys/devices/system/cpu/cpu0/microcode/version' would also be interesting
<tyhicks> dijuremo: that's right
<dijuremo> With A16 cat /sys/devices/system/cpu/cpu0/microcode/version 
<dijuremo> 0x42c
<dijuremo> We want this to use the original CPU microcode, right?  ->   apt purge intel-microcode
<tyhicks> dijuremo: right - we want to see what revision is reported when just using the microcode from the A16 BIOS 
<dijuremo> dmesg -t Â | grep micro 
<dijuremo> microcode: sig=0x306e4, pf=0x1, revision=0x42c 
<dijuremo> microcode: Microcode Update Driver: v2.2.
<dijuremo> cat /sys/devices/system/cpu/cpu0/microcode/version Â 
<dijuremo> 0x42c
<dijuremo> root@localhost:~# dpkg -l | grep intel-microcode 
<dijuremo> root@localhost:~# 
<tyhicks> dijuremo: that was after a reboot?
<dijuremo> Yes
<dijuremo> root@localhost:~# uptime 
<dijuremo>  14:14:03 up 2 min, Â 1 user, Â load average: 0.43, 0.53, 0.24
<tyhicks> hmm
<tyhicks> I'm stumped
<dijuremo> Should I downgrade to A14 and repeat?
<dijuremo> We should get a different microcode then, right?
<tyhicks> the intel-microcode deb and the A16 BIOS deliver the same microcode revision yet the lockup only happens with A16
<tyhicks> dijuremo: yes, that's a good test
<tyhicks> dijuremo: downgrade to A14, check what microcode revision is being reported, ensure that you can't trigger the lockup, then install the intel-microcode from the PPA and reboot, then see if you can trigger the lockup
<tyhicks> this is maddening but very helpful since we're trying to determine how widely to push out the new intel-microcode updates
<dijuremo> With the A14 BIOS
<dijuremo> root@localhost:~# cat /sys/devices/system/cpu/cpu0/microcode/version Â 
<dijuremo> 0x428
<tyhicks> ok, so it was downgraded
<dijuremo> dmesg -t Â | grep micro 
<dijuremo> microcode: sig=0x306e4, pf=0x1, revision=0x428 
<dijuremo> microcode: Microcode Update Driver: v2.2.
<dijuremo> I am going to log into GUI and log out a few times and also change desktops from unity to gnome with A14.
<tyhicks> sounds good
<dijuremo> Login works well for Unity and Gnome under my account and I asked someone else to log in to their account to gnome. Ran Matlab and glxgears no issue
<dijuremo> So total of 3 GUI logins and logouts without freezes on A14 BIOS and 4.13.0-37-generic kernel
<dijuremo>  
<dijuremo> Would the next test be to install your PPA intel-microcode package and test again?
<dijuremo> See if we can get it to crash?
<tyhicks> dijuremo: yes, please
<dijuremo> I also do not know that running matlab and glxgears are the best test, but since the freezes happened on a GUI, I thought those would be at least decent apps to run.
<dijuremo> If you can think of any other apps to run, let me know.
<tyhicks> I've heard of one other report that involves starting up a VM
<tyhicks> it seems like you have a fairly reliable reproducer though
<dijuremo> I would have to install virtualbox and a VM... do not have one there at the moment.
<tyhicks> no worries
<dijuremo> Installed intel-microcode from your PPA and now rebooting...
<ricotz> sforshee, hi, are you about to rebase the bionic next branch to 4.15.14?
<dijuremo> After reboot:
<dijuremo> dmesg -t Â | grep micro 
<dijuremo> microcode: microcode updated early to revision 0x42c, date = 2018-01-25 
<dijuremo> microcode: sig=0x306e4, pf=0x1, revision=0x42c 
<dijuremo> microcode: Microcode Update Driver: v2.2.
<dijuremo> cat /sys/devices/system/cpu/cpu0/microcode/version Â 
<dijuremo> 0x42c
<dijuremo> dmidecode | grep -i version | grep 14 
<dijuremo>  Â Â Â Â Â Â Â Version: A14
<dijuremo>  Bios is still A14
 * tyhicks nods
<dijuremo> So far no freezes... A14 BIOS with your Microcode Logged in 3 times user1 both Unity and Gnome, user2 to Gnome, logged out after running matlab bench(5) and glxgears, machine is still OK, no freezes.
<dijuremo> Does that tell us something else in the BIOS not related to the CPU microcode is to blame?
<tyhicks> possibly
<tyhicks> I'd say the only thing left to do is upgrade the BIOS to A16 and try once more
<dijuremo> Will do, that should reproduce the freeze easily...
<sforshee> ricotz: that must have just come it. We'll undoubtedly get to that shortly.
<sforshee> *out
<TJ-> dijuremo: when the BIOS is updated do you reset to factory defaults or leave the existing BIOS config in place?
<ricotz> sforshee, yeah, a couple hours, just notice you were pushing changes, so I was curious about this last release
<TJ-> dijuremo: I've seen instances where a later BIOS changes the layout of the config NVRAM space and inherited values can be read for some other setting (due to different offsets, etc.)
<dijuremo> After BIOS update I have not reset to factory defaults. I can try that. The first GUI login worked well, I ran Matlab and Glxgears, and then after login out, the machine froze. Numlock key is no longer tuning on/off and I cannot ssh into the machine 
<tyhicks> while maybe not definitive, I think it points at the BIOS update as introducing the issue
<tyhicks> TJ- has a good idea
<dijuremo> For a moment I thought it worked, because this time I was able to log in and log out once, but during the second GUI login the machine froze and Numlock key does not respond nor does ssh...
<dijuremo> Not sure if it would matter, but the BIOS is set to EFI mode.
<dijuremo> Has been for all the testing....
<dijuremo> So resetting BIOS defaults with A16 did not really fixed the problem either.
<tyhicks> on one hand I'm glad we were able to narrow it down to the new BIOS but on the other hand, I'm stumped at what the next steps would be
<dijuremo> tyhicks: And this happens with several models and also a Lenovo M93p
<dijuremo> Exact same type of freezing with the later BIOS from manufacturers. Fix is to downgrade the BIOS where possible.
<dijuremo> And in that DELL 7480 laptop with the latest BIOS, the fix was to stick to 4.4.0 kernel because 4.13.0 would freeze the machine.
<dijuremo> I guess we could try downgrading the kernel to 4.4.0 here and test with A16. Would that provide any useful information?
<tyhicks> it would be a good data point
<dijuremo> That may be tomorrow since it will involve clearing and rebuilding the nvidia driver, etc and I am getting close to leave and have to wrap up other things. Will keep you posted.
<tyhicks> that's understandable - thanks for all the debugging you've done so far
<dijuremo> Thanks for all the help!!! I really appreciate it!
<TJ-> tyhicks: can of worms!
<TJ-> tyhicks: one question I've not been able to find answered in the Intel architecture docs is this: when doing a CPU warm reset does the loaded microcode get reset back to CPU-ROM version, or does a loaded microcode persist. Inference says it gets cleared on CPU reset but it isn't documented anywhere I've been able to find.
<tyhicks> TJ-: hmm... I would think it gets cleared but I'm really not sure
<TJ-> Aha.. Intel 64 and IA-32Architecture Software Developers Manual vol 3A; System Programming Guide; Part1 9.11.6.1: "The effects of a loaded update are cleared from the processo
<TJ-> r upon a hard reset. Therefore, each time a hard reset 
<TJ-> is asserted during the BIOS POST, the update must be re
<TJ-> loaded on all processors that observed the reset. The 
<TJ-> effects of a loaded update are, howeve
<TJ-> r, maintained across a processor INIT. 
#ubuntu-kernel 2018-03-29
<dijuremo> Tried to use 4.4.0-116 kernel on the DELL T3610 with A16 BIOS and latest microcode installed and it also hangs on first attempt to log in to GUI
<dijuremo> uname -r 
<dijuremo> 4.4.0-116-generic
<dijuremo> dpkg -l | grep microcode 
<dijuremo> ii Â intel-microcode Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 3.20180312.0~ubuntu16.04.1 
<TJ-> dijuremo: do these various PCs share a common GPU maker?
<TJ-> dijuremo: or, put another way, is this freeze GUI specific or is there a way to reproduce the freeze without the GUI starting, via console or SSH for example?
<dijuremo> TJ: With the laptops, the GPU was the Intel one part of the CPU. The freeze is usually triggered in some occassions after X starts. In some other after login in (during login in itself) or after log out.
<dijuremo> TJ: Most of the workstation machines have either a Geforce or Quadro card.
<dijuremo> TJ: Most of our Geforce series are eVGA branded, no idea who makes the Quadro cards for DELL.
<TJ-> dijuremo: if we could reduce the proof to something simple without GUI it'd be much easier to track down the cause, over SSH would even discount it being console/video related
<dijuremo> TJ: So I do not know how to trigger the freeze from a console. Any suggestions on what to run? We started noticing when running X related things, ie lightdm or sometimes even we can survive a log in, but the machine freezes after loging out when lightdm restarts.
<dijuremo> TJ: We first notice the issues when we applied updates, the machines would boot up and freeze at the lightdm login screen
<dijuremo> # uptime 
<dijuremo>  12:15:41 up 54 min, Â 1 user, Â load average: 0.00, 0.00, 0.00
<dijuremo> So the machine has been up for that long at the login screen without freezing.
<dijuremo> I am logged in to it via SSH
<TJ-> dijuremo: maybe get it do a lot of I/O? "sudo find / >/dev/null" 
<dijuremo> It completed without freezing
<TJ-> dijuremo: trouble is we don't know if that is a reasonable way to provoke the issue or not :s
<dijuremo> Si I am running prime95, started 12:22
<dijuremo> top - 12:23:11 up Â 1:02, Â 2 users, Â load average: 9.58, 3.42, 1.25
<dijuremo> That should use lots of CPU and memory
<TJ-> of those are OK, it's worth trying the same commands from a direct console. If there's an issue with the GPU side  that might trigger it
<dijuremo> I gotta go to a meeting so will let prime95 torture the hardware for 1.5 hours... if it has not crashed, then we can confirm it is related to GPU/GUI
<TJ-> dijuremo: good plan
<dijuremo> For the record, we are currently on 4.4.0-116 kernel
<dijuremo> Still running...
<dijuremo> top - 12:23:11 up Â 1:02, Â 2 users, Â load average: 9.58, 3.42, 1.25
<dijuremo> I guess I should try and get lightdm out of the equation, perhaps log in one of the virtual terminals and run startx and see if that freezes the machine...
<dijuremo> Oh well, machine froze. I had two ssh sessions going into it, one running prime95, the other top. I quit top, exited the ssh session and then the machine froze
<TJ-> dijuremo: with no console activity?
<dijuremo> prime95 was running as I disconnected my ssh session and then it froze
<dijuremo> I had two separate ssh sessions
<dijuremo> I did not get to try login in the console and running startx yet.
<dijuremo> This was as I was going to do that, I disconnected one ssh session, was going to stop prime95 and then go directly to the machine to try login in and running startx.
<dijuremo> Now I rebooted into 4.4.13, sshd in on shell 1, started prime95, then on shell2 I tried to ssh, saw the motd and now frozen.
<dijuremo> So it is more prone to freezing with 4.4.13 than it is with 4.4.0
<TJ-> 4.4.13 or 4.13 ?
<dijuremo> Sorry, typo more prone to crash with 4.13.0- than 4.4.0-x
<TJ-> dijuremo: can you monitor temperatures? I'm wondering if this freeze is actually an overheat
<dijuremo> I usually do that with gkrellm... not so sure how to do it form the command line... will have to look
<dijuremo> Package id 0: Â +69.0Â°C Â (high = +85.0Â°C, crit = +95.0Â°C)
<dijuremo> And it just hung again....
<dijuremo> Package id 0: Â +69.0Â°C Â (high = +85.0Â°C, crit = +95.0Â°C) 
<dijuremo> Core 0: Â Â Â Â Â Â Â +64.0Â°C Â (high = +85.0Â°C, crit = +95.0Â°C) 
<dijuremo> Core 1: Â Â Â Â Â Â Â +67.0Â°C Â (high = +85.0Â°C, crit = +95.0Â°C) 
<dijuremo> Core 2: Â Â Â Â Â Â Â +65.0Â°C Â (high = +85.0Â°C, crit = +95.0Â°C) 
<dijuremo> Core 3: Â Â Â Â Â Â Â +67.0Â°C Â (high = +85.0Â°C, crit = +95.0Â°C) 
<dijuremo> Core 4: Â Â Â Â Â Â Â +69.0Â°C Â (high = +85.0Â°C, crit = +95.0Â°C) 
<dijuremo> Core 5: Â Â Â Â Â Â Â +67.0Â°C Â (high = +85.0Â°C, crit = +95.0Â°C)
<dijuremo> I do not think it is overheating... well. Thiis is it for today, gotta run to a meeting... :)
#ubuntu-kernel 2018-03-30
<s10gopal> can you please fix it ? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1745646
<ubot5> Ubuntu bug 1745646 in linux (Ubuntu) "Battery drains when laptop is off (shutdown)" [Medium,New]
<JanC> that might be a firmware (BIOS/UEFI) configuration thing...
<JanC> or even a bad motherboard design
<s10gopal> JanC, it dont happen when i install ubuntu 14.04 LTS
<s10gopal> please see this too https://bugzilla.kernel.org/show_bug.cgi?id=198665
<ubot5> bugzilla.kernel.org bug 198665 in Power-Off "Battery drains when laptop is off (shutdown) . WOL disabled and no usb device connected." [High,Needinfo]
#ubuntu-kernel 2018-03-31
<nusch> Hello, could anyone prepare bisect kernel for me between 4.10.0-43 and 4.13.0-37 for this https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1760284 ?
<ubot5> Ubuntu bug 1760284 in linux (Ubuntu) "Regression, system unresponsible few seconds after showing gdm3, Sysrq doesn't work" [Undecided,Confirmed]
<nusch> my guess it's something with either of touchscreen, propertary broadcomm wifi or secure boot - I manually sign broadcomm driver with machine owner key
<TJ-> Not sure where to report this. User in #ubuntu has discovered that packages.ubuntu.com, for a package that started in -security and moved to -updates, fails to be able to list files with a 404 error, and it's not clear (to users of the web-site) how to workaround it. The workaround is to look at the same package in -updates. E.g.  https://packages.ubuntu.com/xenial/linux-image-4.13.0-37-generic   vs 
<TJ-> https://packages.ubuntu.com/xenial-updates/linux-image-4.13.0-37-generic
<TJ-> hmmm! meant to be in -hardened not -kernel!
<s10gopal> apw, ring ring
<s10gopal> TJ-, apw this https://bugzilla.kernel.org/show_bug.cgi?id=198665 , the problem exists after kernel 4.9
<ubot5> bugzilla.kernel.org bug 198665 in Power-Off "Battery drains when laptop is off (shutdown) . WOL disabled and no usb device connected." [High,Needinfo]
<s10gopal> anyone online ?
#ubuntu-kernel 2019-03-25
<dsmythies> sforshee: Two things. 1: Recall on the 14th I was aksing if mainline kernel config could be changed to CONFIG_CPU_IDLE_GOV_TEO=y. ( https://irclogs.ubuntu.com/2019/03/14/%23ubuntu-kernel.html )
<dsmythies> I see it didn't make it for -rc2. Might it be expected for -rc3?
<dsmythies> 2: apparmor is broken in 5.1rc series so far. There is some proposed fix, but it seems it didn't make it into -rc2. Basically this kernel config line:
<dsmythies> CONFIG_LSM="yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor"
<dsmythies> needs to become something like this:
<dsmythies> CONFIG_LSM="yama,loadpin,safesetid,integrity,apparmor"
<dsmythies> Myself, I don't care. Just F.Y.I.
<dsmythies> see also: https://lkml.org/lkml/2019/3/16/274
<dsmythies> By the way, I compiled 5.1-rc2 with the above mentioned CONFIG_LSM, and apparmor is working fine.
#ubuntu-kernel 2019-03-26
<sforshee> dsmythies: cascardo is working on the updates for 5.1, I know it didn't get finished last week but I assume we'll have something this week
<sforshee> cascardo: ^ a couple of configs to look at for
<sforshee> *look out for
<cascardo> noted
<kubde> I think I broke the world record for kernel panic. Under a second :D
<apw> heh
<dsmythies> sforshee, cascardo: O.K. thanks for the update.
#ubuntu-kernel 2019-03-28
<puetzk> just poking my head in per the comments I've added today about the root cause of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1820755 (Netboot install fails due to linux-image-4.4.0-143-generic.postinst linux-update-symlinks not found). Is there anything more an outsider can do to help?
<ubot5`> Ubuntu bug 1820755 in linux (Ubuntu Xenial) "Netboot install fails due to linux-image-4.4.0-143-generic.postinst linux-update-symlinks not found" [Undecided,Confirmed]
<puetzk> It seems to be a pretty simple case of inadequate Depends (it just has Depends: linux-base, which is met by the 4.0 the debootstrap xenial has, but it actually needs to be >= 4.1)
<puetzk> Would be trivial to work around if it didn't break the base-installer before you have a chance to interact and upgrade the pacakge
<puetzk> Just found https://bugs.launchpad.net/ubuntu/xenial/+source/linux/+bug/1820419, which seems to be the same root cause but has a update in -proposed, and tested that. Seems to fix the problem.
<ubot5`> Ubuntu bug 1820419 in linux (Ubuntu Xenial) "linux-generic should depend on linux-base >=4.1" [High,In progress]
<puetzk> So one should probably be marked as a dup of the other. I'm not sure what the preference is on that: 1820755  was more findable (had the error message for web searches) and has more discussion, 1820419 has an assignee and progress toward a fix
<puetzk> Looks like the kernel team policy is that only members should mark duplicates, so I'll hold off on doing so. smb: see above comments about 1820419 and 1820755, and thank you so much for helping get this fixed.
<smb> puetzk, I think duplicating is not restricted to kernel-team but bug triagers in general. But thanks for the hint, I will get the duplication done.
<smb> puetzk, My preference at least is to mark 1820755 a duplicate of 1820419 since the latter is referenced in the upload, so it gets updated once that is released.
<puetzk> smb: thanks. https://wiki.ubuntu.com/Kernel/Policies/DuplicateBugs is where I found the policy note that only the kernel-team was to mark duplicates
<smb> puetzk, oh that was almost 9yrs ago... But I guess it was because people tend to make issues the same problem even if the only common thing is that is somewhere in the kernel (exaggerated of course)
<puetzk> heh :-)
<puetzk> I didn't spot the date, you're right
#ubuntu-kernel 2019-03-29
<nacc> hi kernel folks! I was just looking at makedumpfile's changelog on disco and the upstream 1.6.4 changes specifically mention new kernel support (4.17 is mentioned). Should we be updating makedumpfile on bionic for HWE (4.18...) support?
<nacc> I can file a bug if so
<nacc> cascardo: --^ maybe since you, i think TIL?
<nacc> tyhicks: --^ you sponsored it as well, so you may have an opinion
<cascardo> nacc: sure, we just need to get it SRU approved
<cascardo> there is already a version in the queue
<cascardo> but I need to write up an exception document for that
<nacc> cascardo: oh! I didn't realize that, sorry
<cascardo> nacc: no problem, glad there is someone who cares, that might motivate me to get this in more quickly
<nacc> cascardo: yes please, and I think we can test it too
<nacc> cascardo: if you do file a SRU bug, can you subscribe me?
<cascardo> nacc: there are some of them which are being fixed by this upload, not related to supporting 4.18, especifically, though that's what also happens when the upload is accepted
<cascardo> https://launchpad.net/ubuntu/bionic/+upload/20071421/+files/makedumpfile_1.6.5-1ubuntu1~18.04.1_source.changes
<nacc> cascardo: thanks
<cascardo> yw
