#ubuntu-kernel 2005-09-19
<zul> hey
<BenC> yo
<Mithrandir> hi dude
<fabbione> hey
<mxpxpod> zul: ping
<Nafallo> morning all!
<Nafallo> I just recivied a complaint on hoary from jabber :-P. will breezy kernel-panic when the computer has an Adaptec 2110S stuck in?
<Nafallo> the user will try with the breezy preview.
<Nafallo> same problem with breezy
<jbailey> Nafallo: Does it work on any other version of linux, or is it just us that sucks? =)
<Nafallo> jbailey: debian and knoppix kan handle it :-)
<jbailey> Joy. =)
<jbailey> When does it panic?
<Nafallo> jbailey: I have part of the panic at http://paste.ubuntulinux.nl/2184
* Nafallo asks the user
<Nafallo> on boot, it finds the card, starts scanning for discs, panics.
<jbailey> Nafallo: Do you know which kernel module is being used on Debian/ knoppix?
<jbailey> It would be interesting to see if there are two drivers competeing and we're just selecting the wrong one.
<jbailey> I'm assuming that he installs fine?
<Nafallo> dpt_i2o seems to be the same driver on all kernelns he have tried yet.
<Nafallo> knoppix 2.6-kernel, almost vanilla 2.6.11 and 2.6.9 from morphix.
<Nafallo> is i2o patched in our kernel? it seems the problem lays in i2o_core from that partial panicmessage.
<Nafallo> should be an old patch in that case. hoary didn't work either ;-)
<jbailey> Mithrandir is our i2o god. =)
* jbailey hides.
<Nafallo> hehe
<Nafallo> Mithrandir: awake? ;-)
<zul> mxpod: pong
<zul> meh..
<Nafallo> zul: hi! :-)
<Nafallo> zul: what do you feel about adding rt2570 to our kernel?
<Nafallo> (the usb-version of rt2500)
<fabbione> hmmmm
<Nafallo> morning fabbione :-)
<fabbione> scsi seems to be oopsorama...
<fabbione> i get a scsi crash here too
<fabbione> but on another controller
<Nafallo> same error as http://paste.ubuntulinux.nl/2184
<Nafallo> ?
<fabbione> no
<fabbione> it's a different one
<Nafallo> joy :-P
<Nafallo> works on my scsicontroller anyway ;-)
<fabbione> oh it's not a stopper for me
<fabbione> because it's a combo scsi + lan card
<fabbione> and i wanted to use only the LAN (intel)
<fabbione> instead of a crappy 8139 that can't make more than 40Mb/s
<Nafallo> :-)
<zul> Nafallo: probably not in breezy i been told alread
<zul> already
<Nafallo> zul: oki :-)
<fabbione> breezy is basically closed...
<fabbione> consider breezy as bug fixing only
<fabbione> BenC: when do you plan to upload 8.13 ?
<fabbione> we got a lot of good response on the SATA fix
<Nafallo> oki :-). like those scsi-bugs then ;-)
<fabbione> (i had to roll out a test kernel for a few people)
<zul> which sata fix?
* zul has been in a hole the past couple of days
<zul> otherwise known as toronto
<fabbione> zul: the one that BenC applied to 8.13.. libata race foo bar
<zul> ah ok
<zul> i have to update tonight..i been working so much with real work i  havent had a chance for ubuntu stuff recently
<BenC> fabbione: today
<fabbione> BenC: ah cool
<BenC> gonna start trying to do an upload a week
<BenC> maybe two
<BenC> fabbione: did you ever commit the configs you said you were?
<fabbione> configd?
<fabbione> configs??
<BenC> s/configs/abis/
<fabbione> i did commit sparc...
<fabbione> you told me you were going to take care of the others...
<fabbione> but if you need others, just tell me
<fabbione> given this might be the last kernel we upload, we can take a couple of hours more to build
<BenC> I did i386 and I have ppc
<BenC> so I need to get amd64 and ia64
<fabbione> you have access to halley for ia64
<BenC> sparc was the one I remember you saying you would get
<fabbione> yes
<fabbione> what about hppa?
<fabbione> lamont?
<BenC> idle 2.3 hours
<BenC> ocfs is in the repo
<BenC> I need to add a couple of more patches, and then I can start some builds
<fabbione> BenC: ok..
<fabbione> i will collect the ABI from hppa...
<BenC> fabbione: do you know chuck's repo url?
<zul> hey BenC...im back..
<zul> http://zulinux.homelinux.net/arch/zulcss@gmail.com--2005
<zul> BenC: i was in toronto the last couple of days so i have to commit my stuff tonight 
<BenC> was doing an upload today
<BenC> btw, I have the sky2 driver in now, which alleviates the need for a mod'd sk98lin driver
<zul> sweet..
<zul> sorry havent been really active lately..work takes precedence
<BenC> do you have anything important enough to be in today's upload?
<zul> not really..
<BenC> no problem, just want to make sure none of your work goes to waste :)
<zul> heh :)
<BenC> ok, I'll sync up with you for the next upload
<zul> yeah that would suck
<Mithrandir> jbailey: pong
<BenC> ok, I've got builds going
<BenC> lunch time
<fabbione> BenC: sorry i am a bit late.. lost connectivity with the hppa
<zul> did we change that printk about the ide message that jbailey had?
<zul> i know i can be any more vague
<BenC> I didn't know which message he was talking about
<BenC> I did get the audit printk though
<BenC> fabbione: not doing an upload yet, so still time
<zul> uh...ill check..
<fabbione> BenC: i just started the building..
<zul> fuck it...i dont remmeber
<fabbione> BenC: did you actually push all 2.6.12.6 in?
<BenC> 2.6.12.6?
<zul> BenC:  printk(KERN_ERR "%s: ports already in use, skipping probe\n",
<BenC> zul: ok, thanks
<jbailey> Mithrandir: mmm.  Did I hint what I pinged about?
<fabbione> BenC: i have the ABI...
<fabbione> as soon as i can ssh....
<fabbione> damn connection is slow to death today
<fabbione> BenC: they are in my ~ on chinstrap and rookery
<fabbione> md5sum hppa*
<fabbione> 6fdcea618b99a6f7673a9a0a86641d84  hppa32
<fabbione> 83dbecef0e8cf7e97ba0898c7202bceb  hppa32-smp
<fabbione> 417814f19115af3d20202e21b3b5d105  hppa64
<fabbione> 0cbc78b292ef8bc2b6421ee6bd761e16  hppa64-smp
<fabbione> sorry but i still don't have my ws back with all the sources and exports...
<fabbione> it should be up by tomorrow
<fabbione> i finally found the problem
<fabbione> BenC: 2.6.12.6 was released as stable the same day .13 come out
<fabbione> so it was a fast release that disappeared in the shadow
<fabbione> but it has bug fixes
<fabbione> you can get it from git.. i am sure
<Mithrandir> jbailey: i2o
<Mithrandir> jbailey: I'm going to get a shot at debugging all our i2o stuff in a few days to a week, as we're freeing up that machine for testin
<Mithrandir> +g
<Nafallo> Mithrandir: yay! :-) tell me if you need to the person reporting it. I trust you to understand swedish ;-).
<Mithrandir> Nafallo: I've got i2o hw myself, or at least access to it, once in a while.
<Nafallo> Mithrandir: oki, same failure?
<Mithrandir> Nafallo: I'm not sure what failure you're seeing; if you look for i2o in the bugzilla, you'll see a couple of bugs filed by me basically just requesting support for i2o in the installer and grub.
<Nafallo> Mithrandir: http://paste.ubuntulinux.nl/2184 <-- this one?
<Mithrandir> nope, my i2o stuff is working fine.
<Mithrandir> but I'm on amd64 which means no i2o_dpt, just i2o_block
<Nafallo> Mithrandir: I'll forward him to you later then ;-)
<Mithrandir> please do
<jbailey> Mithrandir: Sweet!
<zul> whoa...what the hell
<zul> ah..nm
<zul> night
<BenC> fabbione: ok
<BenC> fabbione: I grabbed the hppa abi's, so you can just get rid of them on your end
<BenC> fabbione: ping
<Mithrandir> BenC: it's almost midnight here; he'll probably be around in five to six hours
<BenC> ok
#ubuntu-kernel 2005-09-20
<fabbione> BenC: pong?
<BenC> ?
<fabbione> BenC fabbione: ping
<fabbione> you did ping me a few hours back..
<fabbione> but i was asleep :)
<BenC> oh, hmm
<BenC> I forgot :)
<fabbione> ehehe ok
<mjg59> Hrm.
<mjg59> Looks like we may have to bump the ACPI code.
<mjg59> http://bugzilla.kernel.org/show_bug.cgi?id=5162
<jbailey> Why are there 'of course' less entires in his /porc/acpi?
<mjg59> Dunno
<mjg59> Oh arrrrrrrrrrrrgh.
<mjg59> It's part of the core ACPICA code, so there's no way to get the individual patch out of it
<mjg59> And they've lindented the entire ACPI tree
<mjg59> Fuckfuckfuck.
<mjg59> This is going to be a nightmare.
<mjg59> This probably means rediffing most of our acpi patches
<Mithrandir> mjg59: diff -w ?
<Mithrandir> or -b
<mjg59> Oh, no, hang on. This may be tractable.
<mjg59> Argh, no.
* mjg59 swears at length
<mjg59> HNNNGH.
<zul> heh...dont worry be happy
<mjg59> Are carriage returns counted as white space?
<BenC> mjg59: should I hold off my upload?
<mjg59> BenC: This may take me a couple of days to sort - if you're going to do another pre-Breezy, I wouldn't bother
<BenC> mjg59: is this a problem that's already in 2.6.12-8.12?
<mjg59> Yes
<BenC> oh, ok
<mjg59> This is being made excrutiatingly painful by the current patch being against 2.6.13
<mjg59> And there having been a pile of acpi diffs since then
* mjg59 wonders if he can get git to give him everything under drivers/acpi that changed between 2.6.12 and 2.6.13
<BenC> "get git"
<BenC> hehe
<zul> the arch for preX,14 is coming out soon right?
<BenC> should be in the next 12-24 hours
<zul> sweet...then i get stuff in again
<mjg59> Ah, no, I might be able to sort this
<mjg59> BenC: Ok, I'll have a patch for you in a minute
<BenC> sweet
<mjg59> BenC: http://www.codon.org.uk/~mjg59/tmp/acpi_noexecute.diff
<mjg59> BenC: I've got some other patches for you, too. Want me to batch them?
<BenC> yeah, get them all together
<mjg59> BenC: With that acpi one?
<BenC> mjg59: what's the noexecute patch for?
<mjg59> BenC: 14652
<BenC> any idea if it changes the abi?
<mjg59> I believe not
<mjg59> BenC: Did you apply my swsusp.diff ?
<BenC> yeah
<mjg59> Cool
<mjg59> Right, patches mailed
<BenC> thanks
<jbailey> BenC: Are you guys planning an ABI change soon?
<BenC> I don't think we ever "plan" an ABI change :)
<BenC> but no, there are none expected
<jbailey> I should integrate update-initramfs this week or early next, I guess.
<jbailey> So that usplash can be updated on its own.
<mjg59> BenC: When are you hoping to do the upload?
<BenC> in a few hours
<mjg59> Cool
<zul> jbailey: gcj cannnot load gnu.java.awt.peer.gtk.Gtktookit means anything to you?
<jbailey> zul: Do you have libgcj6-dev installed?
<jbailey> Or if you're no tdoing dev work, make sure you have libgcj6-awt
<zul> okie dokie.. ill try that thanks
<jbailey> zul: Whacha doin'?
<zul> jbailey: trying to install aqua data studio under breezyu
<jbailey> Ah, so not a packaged thing.
<zul> nah
<BenC> mjg59: the noexecute didn't cause an abi change, so I'll include it in 8.13
<mjg59> BenC: Thanks
<zul> blah
<zul> meh...gave the same hostname on my work pc and my laptop..
<dilinger> fabbione: *poke*
<zul> hey dilinger how is it going?
<dilinger> hey, pretty good
<dilinger> one of the proposals for breezy was to do some benchmarks on the various smp/nonsmp images, and drop the ones where the optimizations didn't help much
<dilinger> anyone know the results of that?
<zul> it didnt happen
<fabbione> dilinger: pong
<dilinger> fabbione: my question about benchmakrs
<fabbione> dilinger: what question?
<fabbione> ah yeah
<fabbione> sorry i am totally trashed in
<fabbione> dilinger: the are no results,  because no real benchmark have been done
<fabbione> from readin the code there is already impact running 686 kernels on k7 due to L1 cache allignement
<fabbione> between snmo/nosnom Herbet told us that locking at networking layer sucks 
<fabbione> so basically you have impact in running smp kernel on UP machines
<fabbione> the last but not the least, some subsystems like USB are utterly bugged in SMP
<BenC> from what I've read the major impact for an SMP kernel on UP is the cache flush when doing locks, not to mention that lock itself, which can (in total) consume 12 cycles
<BenC> but, I do have a nice patch I found that uses a binary patch on kernel startup to turn all lock's into nop's
<BenC> would even work when booting an SMP kernel with nosmp
<BenC> so it would be easier to prove/disprove a bug is related to SMP
<BenC> or related to locking in general
<dilinger> BenC: how does that work?  just loop through the kernel image, replacing locks w/ noops?  is it i386 only?
<BenC> it redefines LOCK so that it places the .lock op in a linker section, so there's a simple lookup table
<BenC> then it goes through that table and replaces the lock's with nop's
<BenC> so it's a precise and quick rewrite
<BenC> not just a broad search and replace
<BenC> and it does it at runtime
<BenC> it can be done on non-i386 aswell
<BenC> I think I'll be testing it when I start a 2.6.13 tree
<BenC> 2.6.12-8.13 uploaded
<chmj> so the bug flood begins 
#ubuntu-kernel 2005-09-21
<mjg59> BenC: Hm. You didn't apply the other patches I sent you.
<dilinger> mjg59: i don't suppose you have any opinions on http://people.redhat.com/mingo/realtime-preempt/patch-2.6.13-rt12 ?
<mjg59> dilinger: Not really I'm afraid, now
<mjg59> Uh, no
<Mithrandir> BenC: any thoughts on 13834 ?
<Mithrandir> apparently, it's turned off, so I should just be able to turn it on.  Does adding modules change the ABI or is that handled automagically?
<zul> hey
<lamont> we should really add a .deb that has the abi info in it (or deliver it with the kernel) - that way we don't have to go scraping it when we need it...
<lamont> of course, launchpad will do that for us.
<zul> mjg59: i have a laptop here that says its running on battery when its plugged into the wall
<mjg59> zul: Breezy?
<zul> yeppers
<zul> new acpi and kernel i think
<mjg59> What hardware?
<mjg59> Can you try with ec_burst=1 ?
<fs> mjg59: btw, using ec_burst=1 with 2.6.13 on my turion64 laptop fixes the AE_TIME blurb on every acpi access, thanks for the hint
<mjg59> Hm. We should probably make that the default (it was in Hoary)
<fs> the acpi patch for 2.6.12 did not need it, but with 2.6.13 it is needed on both vanilla and acpi-patched kernels
<BenC> Mithrandir: is that still true for -8?
<BenC> 13834 that is
<BenC> lamont: I am adding the gzip's abi file into the kernel .deb's next upload
<BenC> gzip'd
<BenC> it's about 57k compressed
<lamont> BenC: WOOT!
<BenC> thanks for pushing ia64 through
<zul> mjg59: hp dv1170ca
<mjg59> zul: Interesting
<zul> very
<zul> im going to get him to do a ec_burst=1 and he will try it later ill let you know
<mjg59> zul: Cool
<zul> aieee...need arch ;)
<mjg59> BenC: Any chance of being able to push out another new kernel in the near future?
<jbailey> mjg59: I need to push one soonish for the update-initramfs changes.
<mjg59> Ok
<mjg59> BenC: I've mailed you a tarball. 
<BenC> mjg59: yeah, hopefully next week
<zul> i wonder how many drivers dont have hotplug support?
<mjg59> BenC: Did you get the patches I sent?
<BenC> yeah, I wasn't able to merge them before doing the upload
<BenC> they will be in the next one for sure
<mjg59> Ok
<zul> BenC: i thought there was hotplug support for buslogic patch?
<mjg59> jbailey: Any estimate on the initramfs-tools upload?
<mjg59> BenC: Ok, the sky2 driver seems to be a bit flaky
<mjg59> BenC: http://www.kernel.org/git/?p=linux/kernel/git/jgarzik/netdev-2.6.git;a=commitdiff;h=793b883ed12a6ae6e2901ddb5e038b77d6f0c0ac;hp=d7f6884ae0ae6e406ec3500fcde16e8f51642460
<mjg59> Supposed to be better, with luck we can get some debug out of it
<zul> mjg59: the ec_burst=1 makes no difference
<BenC> mjg59: how can I get just the diff from that URL?
<jbailey> mjg59: A few hours?  Will that work for you?
<jbailey> mjg59: I was trying to incorporate your bits with the fact that modalias doesn't detect ide-generic.
<jbailey> (for chipsets that don't have specific drivers)
<jbailey> mdz tripped over that last night, and I'm trying to not forcably always load ide-generic, although I might have to even on scsi-only systems.
<BenC> shit
* BenC has lost an important file
<BenC> knew I should have made the wiki page with this on it before I trashed my system
<BenC> mjg59: never mind, I found the "plain" link
<Mithrandir> BenC: yeah, appears to be.
<BenC> Mithrandir: no idea how it got turned off
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | http://www.ubuntulinux.org/wiki/KernelTeam | The kernel is not in, please leave a message after the beep...OOPS, unable to handle kernel paging request | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ playground: kernel-debian--preX,14--2.6.12
<zul> yay
<jbailey> mjg59: Around?
<Diziet> Hello.  I have some questions about what make-kpkg ought to do.
<Diziet> I'm trying to fix 15488, which is to do with the compiler that it chooses and the dependencies in the various packages.
<Diziet> While investigating, I discovered that apparently our make-kpkg doesn't arrange for it to choose the right compiler.
<Diziet> That is to say, unpacking a stock 2.6.13.1 and running make-kpkg kernel-image on breezy tries to use the default gcc, ie gcc-4.0.
<Diziet> Do our kernel source packages have something in our diffs to force the choice of compiler ?
<zul> yes...its forced to use gcc-3.4 afair
<jbailey> I remember Fabio saying that.  Using gcc-4 on the compiler is insane right now, I suspect.
<fabbione> Diziet: make-kpkg is not broken
<fabbione> we force legally the compiler to use
<fabbione> using normal make vars
<fabbione> if they want to build with 4.0, it's their business
* fabbione -> dinner
<fabbione> BenC: ping?
<BenC> yes
<fabbione> the sky2 driver is FTBFS on sparc...
<BenC> odd
<BenC> builds on amd64, ia64, and ppc64
<fabbione> just a sec.. let see if it is only a missing include
<fabbione> did you get the other one liner?
<BenC> yes
<fabbione> ok
<fabbione> that one seems to be required after one of the security patches..
<fabbione> if you don't plan to upload before monday, we can have more time to look at it
<fabbione> drivers/net/sky2.c: In function `sky2_probe':
<fabbione> drivers/net/sky2.c:2476: error: `DMA_64BIT_MASK' undeclared (first use in this function)
<fabbione> drivers/net/sky2.c:2476: error: (Each undeclared identifier is reported only once
<fabbione> drivers/net/sky2.c:2476: error: for each function it appears in.)
<fabbione> drivers/net/sky2.c:2482: error: `DMA_32BIT_MASK' undeclared (first use in this function)
<BenC> is that in asm-sparc64 anywhere?
<fabbione> include/linux/dma-mapping.h only
<fabbione> testing if it is a missing include
<BenC> does it include linux/dma-mapping.h?
<BenC> other arch's may pull it in from their asm includes
<fabbione> not directly
<fabbione> exactly
<BenC> should be ok to include directly
<BenC> in fact, it should be correct
<fabbione> well i am testing it including it directly
<fabbione> yeah that does it
<BenC> I have a patch for sky2, it may have that fixed already
<BenC> I'll check though
<fabbione> Diziet: the upload you did of kernel-package is WRONG
<fabbione> you must not force gcc-3.4 anywhere
<Diziet> fabbione: Yes ?
<Diziet> (Sorry about my temporary departure.)
<Diziet> I'm not forcing it.  I'm defaulting it.
<fabbione> Diziet: you don't default it
<fabbione> the default is the gcc compiler in the system
<fabbione> you are breaking a known behaviour
<fabbione> the bug is on something completely different
<Diziet> The default gcc compiler in the system can't compile any currently available kernels, right ?
<fabbione> the submitter is telling you that "apt-get install linux-source-2.6.12" should Depends on gcc-3.4
<Diziet> And compiling your kernel with 3.4 is unlikely to do any harm ?
<Diziet> fabbione: Yes, I've fixed that too.
<fabbione> and not apt-get source linux-source-2.6.12
<fabbione> Diziet: did you commit the change to the baz repo?
<fabbione> Diziet: wrong.. gcc-4.0 can compile some kernels
<fabbione> it strictly depends on the config and patches you apply to the kernel
<fabbione> also.. changinc compiler changes the ABI of the kernel
<Diziet> I see.  We had this conversation in #ubuntu-devel because that's where people wanted to talk about it and they said otherwise there.  But they could be wrong of course.
<fabbione> that's bad
<fabbione> there is only one authority in regards of the kernel and that's the kernel team
<jbailey> fabbione, BenC: mkrufky is part of upstream for v4l and dvb
<mkrufky> hello
<fabbione> hey mkrufky 
<mkrufky> how's it goin
<mkrufky> bear with me, i'm at work.... 
<Diziet> I came here and I asked and no-one answered.  Well, one person did respond to the question I had asked here but they did so on #ubuntu-devel.  But if you're telling me I've done it wrong I'm happy to talk about it and undo it if necessary.
<mkrufky> anyhow, yes... jbailey mentioned that there isnt anybody on your kernel team that knows whats going on with v4l / dvb stuff
<mkrufky> i'd be willing to help, in this respect
<jbailey> AFAIK, anyway. =)
<Diziet> It seems to me that it is a bug in make-kpkg that you can download a vanilla kernel.org kernel and expect it to do everything for you but in fact it will select the wrong compiler.
<mkrufky> :-)
<Diziet> Where `wrong' = `most probably wrong for what you want to do'.
<fabbione> Diziet: gcc-4.0 is not a wrong compiler
<Diziet> Note that we are being unusual in shipping with gcc-4.0.
<fabbione> no we are not..
<Diziet> So why should kernel-source depend on gcc-3.4 then if gcc-4.0 is fine ?
<fabbione> FC4 is all based on gcc-4.0
<jbailey> Diziet: If people are building their own kernels, they ought to have some thoughts as to what compiler they're running, etc.
<fabbione> kernel-source doesn't exists..
<Diziet> jbailey: I agree with that _more_ if we're talking about kernel-source.deb than if we're talking about using make-kpkg to make an image.
<fabbione> linux-source-2.6.12 as package (and not as source) should Depends: gcc-3.4
<fabbione> because that's our source with our patches
<fabbione> and it in fact needs gcc-3.4
<Diziet> Sorry, I mean linux-source, not kernel-source.  People keep changing the names of these damn things.
<jbailey> Diziet: I'm really hoping that for dapper we make strong statements against people compiling their own kernels..
<fabbione> Diziet: you must revert that change...
<fabbione> kernel-package is not the place where to do that stuff
<fabbione> BenC: you must be sure to be B-D on a correct version of kernel-package once Diziet revert
<Diziet> fabbione: Our source with our patches uses gcc-3.4 by default, right ?
<Diziet> That is, our patches patch the makefile ?
<fabbione> Diziet: yes. that is correct
<fabbione> correct too
<Diziet> So if you say `make-kpkg kernel-source' from one of our kernel sources you get a linux-kernel.deb which needs gcc-3.4 installed or it will fall over during compilation.  Right ?
<fabbione> Diziet: also.. asking on IRC is fine, but give people time to answer
<fabbione> exactly
<fabbione> it's one line change in linux-source-2.6.12 control file
<Diziet> But if you say `make-kpkg kernel-source' from a kernel.org kernel you get a linux-kernel.deb which needs `gcc' installed and for `gcc' to work and doesn't care about gcc-3.4.  Right ?
<fabbione> exactly
<Diziet> Now make-kpkg is making the control file for this linux-kernel.deb.  How is it to know what to put in the Depends ?
<fabbione> Diziet: you are making hell of a lot of confusion
<mkrufky> seriously
<fabbione> Diziet: there is a source called linux-source-2.6.12
<Diziet> fabbione: Do you want to talk on the phone or something ?  I'm not being deliberately confused here.
<fabbione> and a binary package called  linux-source-2.6.12
<fabbione> the latter needs a Depends on gcc-3.4
<mkrufky> Diziet: does this not cover it all?  http://www.us.debian.org/releases/stable/i386/ch08s05.html.en
<fabbione> that's all the submitter is asking
<fabbione> Diziet: no, my wife is waiting for me and it's friday night
<mkrufky> oh, oops i misunderstood the problem
<Diziet> I'll revert my change completely and we can talk on Monday.  Would that suit you ?
<fabbione> Diziet: revert the changes, because changing behaviour of the kernel build system is bad
<fabbione> we can talk again on monday
<fabbione> but the submitter is asking something completely different of what you are thinking.
<Diziet> No, I understand what the submitter is thinking, but I think there is a wider problem and just doing as the submitter asks is at best partial and at worst wrong.
<Diziet> Anyway, the reversion is in ubuntu4 which has just gone out.
<zul> gah?
<fabbione> Diziet: given that you just changed the default behavior for something that is not related to what the submitter is asking, gives me the impression that you don't get the difference
<fabbione> it is perfectly normal to build a kernel with gcc-4.0
<fabbione> that's the default in the system
<fabbione> it's our kernel that is special cased
<fabbione> and therefor our source takes the appropriate actions to build
<Diziet> Why is our kernel special cased ?  Because gcc 4 doesn't build it right, right ?
<fabbione> thanks for reverting the change
<mkrufky> vanilla kernel is gcc-4.0 compatable
<jbailey> Diziet: gcc-4 still sucks in subtle ways.  We use gcc-3.4 for glibc, too.
<fabbione> Diziet: it does build it, but portion of the code is miscompiled
<fabbione> because we do have HEAPS LOAD of external patches required to make our users happy
<Diziet> Indeed.  So if _we_ don't want to compile our kernels with it, why on earth would we make it the default for our users ?
<fabbione> mkrufky: exactly
* zooko smiles.
<Diziet> mkr: OIC.
<zooko> I think Diziet has a good point there.
<zooko> But as I am not a devel, I will not shut up.
* zooko compiled his kernel on Hoary today...
<fabbione> Diziet: gcc-4.0 is NOT the default for our kernel
<Diziet> But ours users who are compiling their own kernels are likely to want patches, right ?
<jbailey> Diziet: What do we care what users do with their own kernels?
<mkrufky> why not just make ubuntu kernel patches gcc-4.0 compatable?
<fabbione> we force gcc-3.4 and the use spotted that it is missing a Depends :)
<Diziet> jbailey: make-kpkg makes a choice about what compiler to use.
<jbailey> Doesn't it just default to gcc?
<fabbione> Diziet: the choise is also made via environment vars
<Diziet> Yes.  Which we've made (in Breezy) be gcc 4.
<BenC> no, the kernel itself defaults to gcc
<BenC> make-kpkg doesn't
<jbailey> Right, it's the system compiler.  
<fabbione> BenC: we did force it to 3.4
<Diziet> env vars> Indeed, which still work just fine with my change.
<BenC> in linux-source
<fabbione> BenC: yes. that
<fabbione> BenC: yes. that's right
<fabbione> f the user get his kernel from kernel.org
<BenC> but make-kpkg by default just uses what the kernel uses by default, correct?
<fabbione> he can compile it with gcc
<fabbione> (whatever gcc is)
<Diziet> benc: That's what I changed and fabbione is disagreeing with.
<BenC> but is that a make-kpkg decision, or a kernel Makefile one?
<fabbione> kernel makefile
<BenC> without user intervention, it lets the kernel source decide, correct?
<BenC> and, IMO, that is right
<Diziet> make-kpkg has code to make the decision but it didn't do anything of any consequence before I changed it.  Right.
<BenC> because some kernel arch's use odd forced CC's
<BenC> like sparc64 used to force sparc64-linux-gcc
<BenC> because it needed egcs64
<Diziet> In the kernel makefile ?
<BenC> you're change could break that
<BenC> yes
<Diziet> Oh.
<Diziet> Right, I see that point now and you are correct.
<Diziet> (That is, fabbione is correct that it shouldn't do that.)
<fabbione> Diziet: happy to see we can agree :)
<Diziet> But, separately, I don't  think I agree with fabbione and the submitter of 15488.  Sorry :-).
* fabbione powers off the sodomotron
* fabbione powers on the sodomotron again
<fabbione> :)
<BenC> Diziet: the correct solution is to provide a kgcc symlink to the right gcc to use
<BenC> and make-kpkg could use that
<Diziet> That is, make-kpkg can be used _both_ to make linux-source.deb's which contain _our_ kernel sources, and ones which contain _stock_ kernel sources.  Right ?
<fabbione> Diziet: i am sure what he is asking because it is confusing.
<BenC> in that way, each arch can provide it's own, correct and suggested, gcc for the kernel
<Diziet> Yes, I know what he's asking but I think it's wrong.
<Diziet> benc: Indeed.
<mkrufky> sodomotron?  sounds like that vehicle that mr garrison created in south park
<fabbione> Diziet: it's not wrong and i can prove it :)
<fabbione> mkrufky: eheh
<Diziet> Just follow my argument for a bit.
<BenC> IIRC, the kernel even supports that, so make-kpkg might not need to do anything
<fabbione> Diziet: we do patch the kernel Markfile
<Diziet> Do you agree with my comment ...both... above ?
<fabbione> to use gcc-3.4
<BenC> fabbione: no, we pass env vars, we do not patch it
<BenC> s/fabbione/Diziet/
<fabbione> therefor OUR linux-source-2.6.12 binary package needs to Depends on gcc-3.4
<BenC> we do?
<fabbione> BenC: did you make it an env var now?
<Diziet> fabbione told me we patch the kernel top-level makefile to make it use gcc-3.4.
<BenC> no, I thought it was
<fabbione> yes we do patch it
<BenC> ok, then I am corrected :)
<fabbione> because passing the env var to make-kpkg did fail miserably on some arches
<BenC> either way, that's our parogative
<BenC> :)
<fabbione> ok
<Diziet> Right.  But make-kpkg, as we ship in kernel-package.deb, is not just used by us to make the linux-source.deb in our archive, is it ?  It can also be used by the user, for example to turn a stock kernel source tree into a linux-source.deb.
<fabbione> BenC: please just make sure now to bump the B-D on the latest kernel-package
<fabbione> Diziet: that's right.. that's why we don't change default behaviour in make-kpkg
<fabbione> Diziet: and we do special case directly into our kernel
<fabbione> make-kpkg is completely netrual
<Diziet> No, wait, but 15488 requests that the linux-source.deb that make-kpkg produces should always have a different Depends.
<fabbione> nope..
<fabbione> he is asking for linux-source-2.6.12 to Depends on gcc-3.4
<fabbione> Shouldn't linux-source depend on gcc-3.4? Not build-depend, but Depend. Since it
<fabbione> needs gcc-3.4 to compile kernel source.
<fabbione> read it again..
<Diziet> Yes.  Where did linux-source-2.6.12.deb come from ?  It was make by make-kpkg.  The request is to change make-kpkg to make it generate a different linux-source.deb ?
<Diziet> s/was make/was made/
<fabbione> we do ship a linux-source-2.6.12 package
<Diziet> Yes, but it all came from make-kpkg.
<BenC> linux-source isn't made by make-kpkg, is it?
<Diziet> That's why make-kpkg is the thing that's supposed to be changed.
<Diziet> mdz says `changing the hardcoded dependency
<Diziet> in kernel-package should suffice'
<fabbione> Package: linux-source-2.6.12
<fabbione> Architecture: all
<fabbione> Section: devel
<fabbione> Priority: optional
<fabbione> Provides: linux-source, linux-source-2.6
<Diziet> But that's wrong.
<fabbione> Depends: binutils, bzip2, coreutils | fileutils (>= 4.0)
<fabbione> Recommends: libc-dev, gcc, make
<fabbione> Suggests: libncurses-dev | ncurses-dev, kernel-package, libqt3-dev
<Diziet> That doesn't look like what make-kpkg produces.
<fabbione> that's in our control file
<Diziet> Oh, no, just a mo, I'm looking at the wrong stanza in kernel/Control.
<Diziet> It came from this, right:
<Diziet> Package: =ST-source-=V
<fabbione> so one line change there
<Diziet> Architecture: all
<Diziet> Section: devel
<Diziet> Priority: optional
<Diziet> Provides: =ST-source, =ST-source-=CV
<Diziet> Depends: binutils, bzip2
<Diziet> Recommends: libc-dev, gcc, make
<fabbione> and bang :)
<fabbione> solved
<Diziet> But if I do that and you run make-kpkg on a stock kernel, it will produce a package with a wrong dependency.
<Diziet> Why don't we talk about this on Monday.
<fabbione> how so? 
<Diziet> Because it will say  Recommends: ... gcc-3.4 ...
<Diziet> But in fact the source in it will just use `gcc'.
<Diziet> You see the Recommends has to depend somehow on which compiler the Makefile is dealing with.
<Diziet> I think it's too late for this conversation :-).
<fabbione> hmmm
<fabbione> i disagree
<fabbione> or at least partially
<fabbione> our linux-source needs gcc-3.4
<fabbione> and that's a state of facts
<Diziet> Look, I want to have some dinner and I think we should talk about this on the phone 'cos we're going round in circles.
<fabbione> other linux-source needs a compiler
<fabbione> Diziet: have a good dinner
<Diziet> You too.  I'll let you go talk to your wife :-).
<fabbione> if we can't figure it out, just send the submitter to hell
<Diziet> :-)
<fabbione> hounestly
<fabbione> you want to compile your own kenrel
<fabbione> you must know what you are doing
<Diziet> True.
<fabbione> hence use the stock kernel
<BenC> yeah, you have to read the file that tells you what compiler is suggested
<Diziet> We could just take the dependency out altogether :-).
<fabbione> i wouldn't even have spend time on that bug
<Diziet> mdz seemed to think it was important.
<BenC> true, you don't need gcc to use linux-source
<BenC> it could just be for reading
<Diziet> Anyway _goodnight_ :-).
<fabbione> mdz, when we are close to release, believes that even libfoobar is important :)
<fabbione> cya
<Diziet> ttfn
<mkrufky> ok well i guess u guys are gone.... i'll try to pop into this room from time to time.... I repeat, I'd be happy to help in whatever way you need as far as dvb/v4l kernel stuff
<fabbione> mkrufky: oh we are spreaded on all TZ
<fabbione> and you are more than welcome here
<fabbione> if you are a bit familiar with bazaar you can just branch off our tree
<fabbione> and we can merge fixes from you
<BenC> mkrufky: hit the bts, and search the linux bugs :)
<BenC> s/bts/bugzilla/
<fabbione> 310523     Asus A7N8X-E Deluxe, nForce2                    1
<fabbione> 310617     Asus A8V Deluxe, K8T800Pro, S939                1
<fabbione> 320931     AMD Athlon64, 3000+, S939, BOX, Venice          1
<fabbione> 330055     Promise ATA133, TX2 Controller, Bulk            1
<fabbione> 350889     Kingston DDR400, 1024 MB, CAS 3                 1
<fabbione> 820137     ThermalTake 680Watt, Dual Fan, ATX2.0           1
<fabbione> YEEEE
<fabbione> my spare parts have been delivered
<zooko> :-)
<zooko> Nice.
<zooko> I was looking at an A8V today.
<mkrufky> ah, walked away for a minute and the irc page scrolled back 2 pages
<mkrufky> i never used bazaar, but i can always learn
<fabbione> BenC: the sparc kernel builds with these 2 fixes
<fabbione> but it claims an abi change
<BenC> cool, they'll be in the next 2.6.12 upload
<BenC> really?!
<BenC> what lines?
<fabbione> plenty
<BenC> are you sure you put the abi files in from 8.12?
<fabbione> that's what i am thinking about..
<fabbione> but yes i did..
<fabbione> hmmm
<BenC> are there a lot of ocfs2 lines?
<BenC> if so, then I don't think you did
<fabbione> nope
<fabbione> they are not ocfs2 related
<fabbione> -vmlinux sbus_unmap_sg 0x7125562d
<fabbione> +vmlinux sbus_unmap_sg 0x70da842c
<fabbione> most of them are sg related
<fabbione> i have the feeling that the sg security fix has a side effect on sparc
<fabbione> that doesn't on other arches
<fabbione> i will need to test the same fix in hoary and see..
<fabbione> but that's sunday work
<fabbione> BenC: do you think you can wait monday to upload?
<fabbione> bah wife is calling
<fabbione> later fellas
<BenC> later
<zul> right im going home
<persia> I'm tracking down an issue with malone bug #379, and believe that the issue is in the kernel rather than gnome-volume-manager.  Specifically, I've seen an error message of the form "Apr 13 10:18:57 localhost kernel:  /dev/scsi/host5/bus0/target0/lun0: p1" when attempting to mount IDE devices.  Could someone suggest activities which would allow me to confirm this for reassignment?
<BenC> nothing really bad about that kernel message
<BenC> is that the entire kernel message?
<BenC> and what exactly is the problem, are the disks not mounting?
<persia> BenC: On my workstation, I am only successsful mounting /boot about 10% of the time: the rest of the time I get an error like the above.  In Malone bug #379, the reporter complains that g-v-m doesn't work because their USB drive doesn't mount: looking at the errors reported, it appears they are encountering the same issue.
<BenC> I don't think they are
<BenC> the above line isn't an error, it's a line showing the partitions for the drive
<BenC> the USB drive not mounting _may_ be a kernel bug, but you'd need more info, like does the kernel see the drive?, can you mount it manually (using the mount command), etc.
<BenC> if it mounts manually, and just g-v-m doesn't mount it, then it's not a kernel bug
<BenC> if it can't be mounted manually, and the drive actually contains a legitimate filesystem, then it may be a kernel bug
<persia> BenC: That's what I thought, but it only appears on my workstation when the mount fails, and never during a USB hotplug mount with g-v-m, so I'M wondering if the reported bug is really with g-v-m, as I've seen the same behaviour external.
<BenC> persia: it's like that some USB drives (and some hotplug drives) do not have partitions
<BenC> so you wont always see that line
<persia> BenC: Also, my workstation has the error on /boot, which never fails to boot, and works fine when it mounts, but as I mentioned before, sometimes I have to run `mount /boot` 10 times.
<BenC> it's definitely not an error message
<BenC> persia: what type of drive is /boot?
<BenC> could just be a bad harddisk
<BenC> and what sort of error does it say when it fails?
<persia> BenC: OK, I can accept it's not an error message, but it's the only mesage reported when I cannot mount.  It's flash on CF, mounted through an IDE interface.
<jbailey> What's the difference between generic.ko and ide-generic.ko?
<BenC> that line is just the IDE rereading the partition table on insert
<persia> BenC: No error is reported, but the partition map is shown in the logs, and reported if I mount from a root login (as opposed to sudu)
<jbailey> mdz has a device that doesn't use  a chipset specific driver and it doesn't seem to have a modalias file pointing it to something useful.
<BenC> jbailey: does hotplug handle "IDE class" devices with ide-generic?
<BenC> might take more than just a modalias entry for that
<jbailey> For SCSI/SATA/IDE, usually it does a pass over the PCI bus, which then opens up /sys/bus/scsi or /proc/ide
<jbailey> Then we can walk those busses and figure out sd/sh/ide-disk, etc.
<jbailey> ide-generic is a bit quirky because you always have to load it with IDE devices, but it *also* will take over those ports if no other ide chipset driver has grabbed it.
<jbailey> So it has to be loaded last.
<jbailey> The problem is that because it's the generic one, it seems like it's just supposed to be used if you had an IDE chipset for which you have no other driver.
<jbailey> So I'm trying to figure out how to detect that. =)
<jbailey> I think the problem here is that because it's a generic catch-all driver, but each group will write their own chipset for it, there's no PCI ID that could be matched against.
<jbailey> Hmm
<jbailey> I wonder if there's some sort of device class I can check against.
* jbailey wanders off to fetch a rental car for Angie.
<mkrufky> ok im goin home.... tty guys later
#ubuntu-kernel 2005-09-22
<persia> I'm trying to track down Malone bug #379.  The reporter indicates that when a USB drive is attached to the system, it fails to mount, and in the error message is the partition map.  I've encountered this with my own /dev/hdc1 (/boot) and suspect a kernel issue rather than an issue with gnome-volume-manager, but wanted to solicit confirmation from someone who understood the kernel better than I.
<fabbione> BenC: ping?
<BenC> pong
<fabbione> BenC: it is indeed a security patch that changes ABI on sparc
<fabbione>     - Add patch stolen-from-head_CAN-2005-2490.dpatch.
<fabbione> this on
<fabbione> e
<fabbione> -extern int cmsghdr_from_user_compat_to_kern(struct msghdr *, unsigned char *,
<fabbione> +extern int cmsghdr_from_user_compat_to_kern(struct msghdr *, struct sock *, unsigned char *,
<fabbione>                 int);
<BenC> that wasn't from me, was it?
<fabbione> no no
<fabbione> it was from upstream to fix a CAN
<BenC> where did it come from?
<fabbione> what i don't understand yet is why it does affect sparc only
<fabbione> BenC: upstream crack via pitti
<fabbione> either the patch is not complete
<fabbione> or i am missing something obvious
<fabbione> iirc amd64 uses CONFIG_COMPAT
<fabbione> that should pull it net/compat.h too
<fabbione> but it doesn't break the abi
<fabbione> it's not a big deal
<fabbione> we can workaround it easily
<fabbione> nobody run sparc except me and a few peoplw
<fabbione> people even
<fabbione> so even if we change the abi without bumping it
<fabbione> it's not a big effect like killing i386
<BenC> plus, it's an unsupported arch, and I don't think there are any external modules for it
<BenC> ok, odd though
<BenC> amd64 and ppc64 should be pulling in compat layer
<fabbione> i am pretty sure they do
<fabbione> but than.. why didn't they get the abi change?
<BenC> not sure, I checked the ppc64 directly
<BenC> did a compile here
<fabbione> arch/sparc64/kernel/sparc64_ksyms.c:#include <net/compat.h>
<fabbione> arch/sparc64/kernel/sys_sunos32.c:#include <net/compat.h>
<fabbione> arch/sparc64/solaris/socket.c:#include <net/compat.h>
<BenC> I did an 8.12 compile for amd64 abi too, so the buildd would have failed with 8.13 auto build
<fabbione> nope
<fabbione> it's only sparc using it
<fabbione> net/compat.c:#include <net/compat.h>
<fabbione> net/core/scm.c:#include <net/compat.h>
<fabbione> net/socket.c:#include <net/compat.h>
<fabbione> that explain...
<fabbione> so for net/compat.h just include net/sock.h
<fabbione> it's a sparc only change that won't hurt anybody
<fabbione> i am going to give you the new ABI files soon
<fabbione> that we will need to put in the 8.13 directory
<fabbione> so that 8.14 will match
<BenC> ok
<fabbione> but i would like to test build 8.14 before you release
<BenC> no problem
<fabbione> you need to tell me when it is ready for that :)
<BenC> should be early next week
<fabbione> ok..  i am checking out so i can add stuff directly if you want me to
<fabbione> in a few hours i should get the new workstations :)
<fabbione> X again!
<fabbione> working on console isn't exactly my favourite when i could have 3 heads :)
<persia> I'm tracking down an issue with Malone bug #379.  This is a report that sometimes usb drives do not mount.  I have experienced this problem on an IDE drive on my workstation with the same error message.  This behavior is new to Breezy: Hoary did not have this issue, and the Hoary livecd does not today.  Would anyone be willing to verify for me whether this is a kernel or userspace bug?
<fabbione> persia: full url to the bug pleasE?
<persia> fabbione: https://launchpad.net/malone/bugs/379.  This does not include my local experience with /dev/hdc1.
<fabbione> userland problem
<fabbione> the dmesg shows clearly that the kernel has recognized the device
<fabbione> Apr 13 10:18:57 localhost scsi.agent[19294] : disk at /devices/pci0000:00/0000:00:0c.0/usb1/1-2/1-2:1.0/host5/target5:0:0/5:0:0:0
<fabbione> this shows that the kernel did inform userland about the new device
<fabbione> after that it's not kernel business anymore
<persia> fabbione: My local experience with mount is that when it works it is silent, and when it fails, the /dev/scsi/host5/bus0/target0/lun0: p1 (or in my case /dev/ide/...) line prints to console.  Is this just userland failing to catch the report?
<fabbione> possibly
<fabbione> it depends from the error
<fabbione> your problem might not be related to 379 at all
<persia> For me, I get no error reported through dmesg: just many repeats of "/dev/ide/host0/bus1/target0/lun0: p1" with timestamps.  It may not be related, but when it was first discussed on ubuntu-bugs, it was suggested I ask here, both about the bug, and about my issue, and whether they were related.
<persia> Just for fun, my latest run of `sudo mount /boot` generated the following in dmesg "[ 9297.537247]   /dev/ide/host0/bus1/target0/lun0: p1".
<fabbione> persia: i need to see the full dmesg
<fabbione> that kind of msg is in dmesg too
<persia>  /join #ubuntu
<persia> sorry: misplaced space...looking for pastebibn...
<fabbione> BenC: i committed the sparc fixes to baz. i still need to hack the abi files
<fabbione> waiting to complete the build
<persia> Full dmesg is available from http://paste.ubuntulinux.nl/2243.  The tun/tap is from a vpnc run earlier.
<fabbione> persia: what device is connected to hdc ?
<persia> It's an IDE->CF converter with a flash card installed.
<persia> The manufacturer claims no drivers are required, regardless of OS.
<fabbione> so you have /boot on the flash?
<fabbione> in theory there is no need of any driver.. that's correct..
<persia> Yep.  /boot is on flash.  Worked perfectly under Hoary.  Problems started around 2.6.12-4-?, but I don't remember exactly.  Hoary livecd works perfectly today.
<fabbione> livecd doesn't use /boot from flash..
<fabbione> but the machine boots fine with that setup, right?
<fabbione> i mean.. you can boot and you can mount /boot ?
<persia> No, but the livecd can mount the drive every time.  With current Breezy I have success about 1 time in 10.
<fabbione> oh i see...
<fabbione> does the boot stop because it cannot mount /boot, right?
<persia> The machine boots fine, and /boot rarely mounts.  I usually go through a cycle of `ls /boot`, `sudo mount ./boot` to get it to mount.
<fabbione> ok
<fabbione> can you try something for me?
<persia> Sure.  What shall I try?
<fabbione> you first need to boot in breezy
<persia> Done.  Shall I reboot?
<fabbione> no
<fabbione> not yet :)
<fabbione> give me a second that i need to search what you need to change exactly.
<fabbione> as root go to /usr/sbin
<fabbione> cp mkinitramfs mkinitramfs.backup
<fabbione> edit mkinitramfs
<fabbione> meh no
<fabbione> sorry.. wrong file :)
<persia> `sudo su -`; `cd /usr/sbin`; `cp mkinitramfs mkinitramfs.backup`.  OK.  deleting the backup...
<fabbione> cd /usr/share/initramfs-tools/scripts
<fabbione> cp functions functions.backup
<fabbione> (just in case :)
<persia> OK.
<fabbione> edit functions
<fabbione> go to line 226
<persia> Error: no "edit" mailcap rules found for type "application/*"
<fabbione> and look for ide_boot_events
<persia> I'm using vi instead.
<fabbione> yeah edit = use your favourite text editor :)
<fabbione> vi is fine ;)
<fabbione> around line 226
<persia> ide_boot_events() { [ -e /proc/ide ]  || return ...
<fabbione> ide_boot_events
<fabbione> second.. i have an old file..
<persia> I'm on line 146 on the current file.
<fabbione> 226 please
<persia> There's also an entry on line 226.
<persia> 226 it is.
<fabbione> the line after ide_boot_events
<fabbione> add sleep 10
<fabbione> so that looks like:
<persia> Done.
<fabbione>         ide_boot_events
<fabbione>         sleep 10
<fabbione>         scsi_boot_events
<persia> I have a space between the sleep line and the scsi_boot_events line.  It shouldn't matter, should it?
<fabbione> no it doesn't matter
<fabbione> than as root:
<persia> dpkg-reconfigure linux-kernel-whatever?
<fabbione> mkinitramfs -o /boot/initrd.img-`uname -r` `uname -r`
<persia> Ah.  Processing in the same root session...
<fabbione> you need to have /boot mounted to do that
<persia> Hold on - it'll take me a little while to get it mounted...
<fabbione> sure
<persia> OK.  Mounted.  Remounted RW, mkinitramfs run.
<fabbione> once it is finished, you should reboot the machine
<fabbione> and see if it can mount /boot
<persia> OK.  It's the machine on which I'm here, so I'll be back in a bit.
<fabbione> basically the sleep 10 will give more time to the device to settle after initizializa
<fabbione> if this work, i will tell you what to do next
<persia> If the device sometimes doesn't settle for over 10000 seconds, I'm not sure 10 will help, but trying anyway...
<fabbione> it will take a few seconds more to boot
<persia> The mount of /boot failed.  BTW, thanks for looking into this now.
<fabbione> persia: one second..
<fabbione> can you give me ls -las /boot ?
<persia> No worries.  I'm not in a hurry.
<fabbione> sleep 10 might not be enough...
<persia> total 2
<persia> 1 drwxr-xr-x   2 root root 1024 2005-08-21 19:08 .
<persia> 1 drwxr-xr-x  23 root root 1024 2005-09-13 19:37 ..
<fabbione> well i need the mounted /boot
<fabbione> not the empty one ;)
<persia> Sometimes it won't mount after a day of settling in, so I'm not sure sleep is the right fix.
<fabbione> hmm in that case no
<persia> OK.  Trying to mount (repeated tries seem to help).
<fabbione> did you ever try such device in windows?
<fabbione> or with another OS?
<persia> The device worked fine with Hoary, and also when I first tried the Breezy repositories (my joystick requires 2.6.13)
<fabbione> i see...
<fabbione> ok last test...
<fabbione> still as root
<fabbione> mkinitrd -o /boot/initrd.img-`uname -r` `uname -r`
<fabbione> of course you still need /boot mounted
<fabbione> after that do another reboot
<persia> `ls -las /boot` output for mounted /boot is in http://paste.ubuntulinux.nl/2245
<persia> Do you want to look at that before I do the mkinitrd?
<fabbione> done.. it's fine
<fabbione> i had to check only the timestamps on a file
<fabbione> please try the mkinitrd
<persia> I don't have mkinitrd installed.  Let me find it in the archive.  Apologies for the delay.
<fabbione> apt-get install mkinitrd-tools should do
<persia> I use aptitude, but yep...
<persia> OK.  initrd created.  Rebooting again.
<fabbione> ok
<persia> With the initrd, /boot mounted.  Does this indicate a clear userspace issue, or have I just gotten lucky this time?
<fabbione> you need to try it a few times :(
<fabbione> if it works it's an issue with initrams
<persia> OK.  I'll be back in a while.
<fabbione> initramfs
<fabbione> ok take your time
<persia> I can repeatedly mount /boot with the initrd.  Does this indicate the kernel is happy and userspace is broken?
<fabbione> yeps
<fabbione> now go to bugzilla.ubuntu.com
<fabbione> file a bug to component initramfs-tools
<fabbione> explain all the setup in details
<fabbione> and you can copy&paste from this IRC session
<fabbione> so that jbailey can look into it asap
<fabbione> severity is major
<persia> Well thanks a lot for helping me understand that.  I'm still chasing Malone #379, so I'll try to find someone to hit both of them as part of Bug Day before I add to the 3000+ entries in bugzilla, but it will get documented sometime soon.
<fabbione> 379 is something else tho
<fabbione> persia: i still suggest you file a bug asap
<fabbione> nobody in #ubuntu-bugs other than jbailey will ever upload initramgs
<fabbione> initramfs
<fabbione> i can tell you that :)
<persia> Are you sure?  It looks like the same "mount is not getting the device issue".  When it was discussed about 10 hours ago, we thought they were the same.  I'll put something in bugzilla now just in case, but I'm still not sure it's not something about mount rather than just initramfs.
<persia> Thanks again :)
<fabbione> persia: i am sure it's not the same :)
<fabbione> because the usb is already with a booted system
<fabbione> the device is recognized byt the kernel
<fabbione> it is not automounted
<fabbione> in your case, it's not mounted even if it should (given the entry in fstab)
<fabbione> so trust me, they are different bugs
<persia> OK.  The issue I have with a fresh boot is different, and being logged to bugzilla.  The issue I had mounting it later appears the same to me, but I'm not worried about it, and am trusting you.
<fabbione> mounting it later is not the same
<fabbione> the 379 is talking about automount
<fabbione> that is different from mounting it later manually
<fabbione> bbl
<fabbione> i need to wake up my wife
<fabbione> persia: thanks a lot for your testing
<fabbione> pretty much appreciated
<persia> fabbione: It's bugzillla bug  15637, for your reference.  Have a good day.
<mjg59> Did we get the ndiswrapper amd64 build fix thing sorted?
<airox> Hi
<airox> I seem to have a kernel panic after updating my SMP kernel on breezy preview yesterday. Known issue ?
<BenC> airox: what does the panic say?
<BenC> damn, missed him
#ubuntu-kernel 2005-09-23
<desrt> benc; ping
<fabbione> mjg59: ping?
<mjg59> fabbione: Hi
<fabbione> mjg59: yo.. sorry i am busy to fix something atm, but i have an interesting problem for you on my new amd64
<fabbione> will you be around in a couple of hours?
<mjg59> fabbione: Ought to be
<fabbione> ok great
<fabbione> mjg59: still around?
<mjg59> fabbione: Hi
<fabbione> yo
<fabbione> so that's the situation...
<fabbione> i just bought an AMD64
<fabbione> with an A8V mobo
<fabbione> if you need links to the references you tell me
<fabbione> basically i have 2 video card there
<fabbione> one AGP and one PCI
<fabbione> both of them nvidia
<fabbione> indipendently if:
<fabbione> a)  i use the free or the binary driver
<fabbione> b) i pass the hell of a command line like acpi=off pci=noacpi pci=routeirq acpi=noirq 
<fabbione> c) indipendently to whatever i set in the BIOS
<fabbione> everytime i start to make load on the PCI card
<fabbione> the machine hangs very very hard
<fabbione> and i know for a fact that the card is good
<fabbione> there are no irq conflicts whatsoever
<mjg59> fabbione: Hm. No idea, I'm afraid.
<fabbione> it happens if i change slot of the card
<mjg59> Does it happen with only the PCI card?
<fabbione> so it's not related to position on the PCI bus
<fabbione> you mean without initizialing the AGP one?
<mjg59> Pulling the AGP one?
<fabbione> hmmmm didn't check...
<fabbione> point
<fabbione> ok let say that it doesn't work...
<mjg59> It could be a PCI controller issue
<mjg59> It'd be interesting to see what happens if you try heavy DMA load over another PCI device
<fabbione> i doubt.. there are other 3 cards there that are working fine
<fabbione> already done
<mjg59> Ah, ok
<fabbione> cat /proc/mdstat 
<fabbione> Personalities : [raid5]  
<fabbione> md0 : active raid5 hde1[0]  hdg1[2]  hdh1[3]  hdf1[1] 
<fabbione>       361871808 blocks level 5, 64k chunk, algorithm 2 [4/4]  [UUUU] 
<mjg59> Could be the PCIGART code doing something wrong on amd64, I guess
<fabbione> these 4 disks have been resyncing a few times during the 40 reboots/crashes
<fabbione> i did try also to run i386
<fabbione> same story
<mjg59> Heh. Ok, so probably not a generic PCI issue.
<mjg59> Have you tried an earlier X?
<mjg59> I'm sorry, I'm running out of possible issues here. It'd be interesting to see if it happens with only the PCI card, which would narrow things down a bit
<fabbione> ok.. i will try in a few minutes
<fabbione> i was just searching ideas on how to isolate the bug
<fabbione> that would make me happy enough for today
<mjg59> Narrowing it down to the PCI or the PCI+AGP cases would probably help
<fabbione> yup
<mjg59> If it happens with just the PCI card, it's probably an X boog
<fabbione> well yeah, but the machine should hang dead hard... but well it's X :)
<fabbione> let see
<fabbione> it seems i did mistype noapic the first time
<fabbione> hey ik5pvx 
<ik5pvx> hello
<fabbione> guys.. meet ik5pvx .. the guy that ported me to linux
<fabbione> ik5pvx: meet the guys
<desrt> hello ik5pvx.  thanks for porting fabbio
<ik5pvx> quit saying that fabio, or people may think I'm actually able to do anything useful here
<ik5pvx> :)
<fabbione> hey desrt 
<desrt> ik5pvx; he has some endianness issues, though, that maybe you could fix up...
<fabbione> ik5pvx: the DVB guy is not online.. but well
<desrt> good 'morning'
<ik5pvx> fabbione ? hes BIG endian. 
<fabbione> ahha
<fabbione> hey i lost 4 kg in the last 2 weeks
* desrt is little endian
* fabbione is on a diet
<fabbione> desrt: no.. your problem is that you are canadian.. and you use ppc
* desrt O-o
<desrt> you're going to ubz, right?
<fabbione> desrt: i have to.. it's no option for me
<fabbione> i will be there almost 3 weeks
<desrt> cool.  i'll get to meet you then :)
<fabbione> ah cool!
<desrt> y'all were nice enough to sponsor me
<fabbione> desrt: remember the G5 you promised me
<desrt> actually, no... i don't remember that at all :)
<fabbione> that's why i am sending you a reminder
<desrt> hah
<fabbione> so you have time to pack it :)
<fabbione> ahha
<fabbione> anyway i am back to mount the XP2100+
<fabbione> hopefully it will work
<desrt> k
<desrt> i'll have to start working on packing it
* desrt starts looking for big boxes
<fabbione> desrt: oh don't forget the 24 ports Gigabit Cisco switch!
* fabbione got a bunch of gigabit cards now
<desrt> i -definitely- don't remember promising that one
<fabbione> ahha
<desrt> k
<desrt> G5 all packed up
<fabbione> eheh
<quartermain> can I ask a questionn about initramfs here?
#ubuntu-kernel 2005-09-24
<zul> hey folks
<jbailey> Should a mobile AMD Athlon(tm) use a k7 kernel?
<zul> i believe so
<jbailey> Cool, tx.
<mkrufky> jbailey: i responded to that bugzilla about the dvb headers... the way i fixed it should solve the problem for all distros
<jbailey> mkrufky: Nice, thanks!
<jbailey> I'll look at the bug in a few minutes to see what the solution is.
<mkrufky> ok... would be nice to hear from the original user if it works 
<mkrufky> (before we close the bug)
<jbailey> mkrufky: Are you still interesting in being involved in dvb/v4l with Ubuntu?
<mkrufky> ya
<jbailey> People often don't answer, it's not usually worth waiting for them to reply if you beleive that it's actually fixed.
<mkrufky> i guess ur right
<mkrufky> but yes, i am interested in being involved in dvb/v4l w/ Ubuntu... 
<jbailey> Cool.  Did you get a chance to talk with BenC about it at all?
<zul> or just close it, some people open bug reports and never get back to you
<mkrufky> he was discussing gcc dependencies for kernel-package that other day... didnt really say much to me
<mkrufky> he did say i was always welcome here... thats basically iy
<mkrufky> it
<zul> gah...simpsons sucks
<mkrufky> zul: ur right... this episode sux
<zul> BenC: shouldnt it be CONFIG_ACPI_BOOT=n for 686-smp?\
<zul> hah hah...ottawa is beating toronto in pre-season nhl
<BenC> zul: I dunno, should it?
<zul> i been reading some people have problems with smp and acpi 
<BenC> will disabling acpi hurt anything?
<zul> not sure...but its gone in 2.6.13
<zul> maybe mjg59 would be the best person to ask :)
<BenC> acpi is gone?
<BenC> or the acpi/smp bug? :)
<zul> for smp i think...gimme a sec...i saw it on bugme
<BenC> yeah, acpi disabled on smp would make sense I guess
<zul> 2745 on bugme.osdl.org
<zul> uh...no thats wrong
<zul> 2495
<zul> night night
<fabbione> morning fellas
<fabbione> mkrufky: ping?
<mkrufky> fabbione: pong
<fabbione> hey mkrufky 
<mkrufky> hello
<fabbione> may i take a few minutes of your time? if you are not busy
<mkrufky> sure
<fabbione> great
<fabbione> there is a friend of mine here on IRC that is building a HTPC
<fabbione> (so am i)
<mkrufky> ok
<fabbione> he is not online now, but i think he would like to talk with you to have some suggestions about what kind of DVB cards to buy
<mkrufky> what country does he live in?
<fabbione> i would be really glad if you could give him some suggestions when he will be around
<fabbione> italy
<fabbione> and i am in denmark
<mkrufky> ok... you should tell him to go into #linuxtv
<fabbione> ok.. on this net?
<mkrufky> yes
<fabbione> ok
<mkrufky> the dvb drivers are discussed in #linuxtv and the analog drivers in #v4l
<fabbione> for me instead i am looking for a TV/FM card only for now...
<fabbione> ok.. so i guess i need to join #v4l
<fabbione> :)
<mkrufky> hehe
<mkrufky> most cards are supported
<fabbione> thanks :)
<mkrufky> if u get an unsupported one, you can help us to add support for it
<fabbione> yeah but i have a very limited selection of hw
<mkrufky> if u tell me what u have access to, i'll let u know which is better supported
<mkrufky> bttv-based cards have the best support, but that is an older chip
<fabbione> like pinnacle, asus (one model), Hauppauge and trust
<mkrufky> cx2388x and saa713x based boards are also very well supported
<fabbione> skipping trust that i don't like
<fabbione> yeah but there is no indication of the chipset :/
<fabbione> that's why i was seeking for help :P
<mkrufky> those pinnacle and hauppauge are mostly supported
<mkrufky> do u know any model #'s
<fabbione> hauppauge claims to be "Win-TV" something....
<fabbione> yeps
<fabbione> i can take you there..
<mkrufky> k
<fabbione> www.shg.dk
<fabbione> sec.. mozilla died.. again
<fabbione> Hardware -> Tv-Kort (3rd col to the bottom)
<mkrufky> i think all 4 of those carfds are supported
<fabbione> click (alle)
<mkrufky> we have a relationship with hauppauge
<fabbione> ah
<fabbione> that sounds good
<mkrufky> if there is an unsupported card, they help us by giving us some info
<fabbione> once you get to that page, if you click on the icon with the pic of the board, you get the specs
<fabbione> but they never mention the chipset
<fabbione> but there are the references to the producer site
<mkrufky> ya i see
<mkrufky> thats aannoying
<fabbione> yeah. but it's a very good hw reseller here in sk
<fabbione> dk
<fabbione> http://www.hauppauge.com/Pages/products/data_pvr500mce.html
<mkrufky> i think wintv pvr500 might not be supported yet
<fabbione> perfect :)
<mkrufky> but we just added support for 550
<fabbione> (it's also too expensive)
<mkrufky> so, you can buy the 500 and help us to test and add new support for it
<mkrufky> the hardware is very similar to 550
<mkrufky> so it would be easy
<fabbione> yeah but i am hounest, i wouldn't be able to allocate time for it
<fabbione> other than doing testing
<fabbione> i am not into v4l code or DVB code at all
<fabbione> and i guess you need such a board locally to be able to work on it
<mkrufky> thats all u'd really need to do... we would need u to read us some #'s off the card and run some tests
<fabbione> mkrufky: can this stuff be done remotly?
<mkrufky> card programming is simple... just a definition of what drivers to call with what options
<mkrufky> yes, it can be done remotely, but it is handy to have someone nearby in case reboot is necessary
<fabbione> yeah of course
<fabbione> i can live with rebooting the box :)
<mkrufky> :-)
<mkrufky> u never know... maybe someone else will add support before you receive it in the mail
<mkrufky> :-P
<fabbione> eheh true
<fabbione> but i can't see the 550 on their product line..
<mkrufky> our cvs has been very active lately
<fabbione> yeah i am sure it is :)
<mkrufky> that pvr 500 looks real nice to me
<fabbione> i like the idea of the 2 tuners
<mkrufky> ya its nice
<fabbione> they use a conexant chipset
<mkrufky> looks like it does not do HDTV tho
<mkrufky> yes, it is supported
<fabbione> we don't have HDTV here anyway :)
<mkrufky> ooh oops... this board... maauro has it
<fabbione> we barely have an antenna ;)
<mkrufky> mauro is v4l maintainer... hauppauge sent him that board for him to add support for it
<fabbione> cool
<mkrufky> cx23416 chipset
<mkrufky> X2
<fabbione> "each with their own hardware MPEG encoder!"
<mkrufky> yes
<fabbione> lovely
<mkrufky> this is great... uses less cpu
<mkrufky> the name of the driver is cx88-blackbird
<fabbione> ah
<fabbione> perfect!
<mkrufky> and i think that board might be supported by ivtv , not sure
<fabbione> oh
<mkrufky> we're working with the ivtv people to merge their stuff into v4l
<fabbione> you convinced me :)
<mkrufky> :-)
<fabbione> yeah i have been asked to merge ivtv once into the ubuntu kernel
<fabbione> but there were too many bits i didn't like
<fabbione> such as conflicting drivers
<mkrufky> it is easier for distro's to do something like that.... vanilla kernel cant quite do that
<mkrufky> yes
<fabbione> but i will have to wait a bit to buy this card.. it's a bit too expensive atm
<mkrufky> they could instead, have an ivtv package in the repository
<mkrufky> and if you did that, you might as well also have a v4l update package in the repository as well
<mkrufky> i think that would have to mask each other out though
<fabbione> it's still an issue to provide kernel drivers in an external package
<mkrufky> why is that?
<fabbione> we have a simple rule..
<fabbione> whatever is GPL and can be merged into the main kernel, we do it
<mkrufky> hmmm... dont merge ivtv then... it DOES conflict with v4l
<fabbione> the issue of having extra kernel drivers packages goes to security
<fabbione> i didn't merge it :)
<fabbione> let me explain in few words
<fabbione> the main tech issue is when we need to provide security updates
<fabbione> let say that we do update the main kernel and this gets to change its ABI
<fabbione> as it is now: we upload 2 packages and everybody is happy
<fabbione> if we start to ship N external packages, all of these need to be rebuild (and possibly fixed) against the new kernel
<fabbione> that takes hell of a lot of time and resources
<fabbione> so it's easier to a certain degree to keep everything in the main kernel
<fabbione> but clearly we need to make a selection of what can go in
<mkrufky> i c
<fabbione> and what has to stay out
<mkrufky> do u ever backport features from newer kernels into your current kernels?
<fabbione> yes
<fabbione> it of course depends what we need to backport
<mkrufky> how conservative about that stuff is ubuntu?
<fabbione> well if you are asking me to backport a new MM layer, i would clearly say no
<fabbione> if we are talking about drivers we are more flexible
<mkrufky> hehe ya of course
<fabbione> it also depends on what development season stuff shows up
<fabbione> right now at 3 weeks from release, it's only heavy bug fixing and security fixes
<fabbione> we still have exceptions but they are more unique than rare
<mkrufky> makes sense
<fabbione> we are flexible to the point that in the beginning of the development season we can include all kind of junk
<fabbione> if it results to be buggy, we kick it out before FeatureFreeze
<fabbione> it means that we have no issue to push crack around to user for testing
<fabbione> but it gets the time in which we make decision.. and sometimes it's though
<mkrufky> well, i guess when it comes time to upgrade your kernel to the next mainline version, i could give you a v4l/dvb update patch against that mainline version
<fabbione> sure
<fabbione> that would be very nice
<mkrufky> i understand that your most likely not going to adopt 2.6.13
<fabbione> not for breezy.. no
<mkrufky> i wouldnt expect that you would want such a patch against 2.6.12 for breezy
<fabbione> i am pretty sure we will got .13 or .14 for dapper (breezy+1)
<desrt> shhhh
<fabbione> mkrufky: it depends how big it is :)
<fabbione> mkrufky: we are at 3 weeks from release
<mkrufky> hmm... does that mean a lot of time or a little time?
<desrt> dapper is ultra-secret codename :)
<fabbione> little
<fabbione> desrt: no it's not :)
<fabbione> it's been announced on ubuntu-devel a while ago ;)
<desrt> pfah.  jeff seems to think it is
<desrt> ah.
<desrt> a dingo is an awful animal
<mkrufky> hmm... maybe tomorrow i'll see what a diffstat of our current stable snapshot looks like against 2.6.12
<desrt> well... the animal isn't bad
<desrt> but i mean... as a name!
<fabbione> mkrufky: ok..
<fabbione> mkrufky: thanks a lot for all your suggestions :)
<mkrufky> fabbione: no problem
<desrt> fabbione; is benc still the man?
<mkrufky> ive got an unrelated question then....
<fabbione> desrt: yeps
<fabbione> mkrufky: sure if i can help
<mkrufky> do u have zaptel in your kernel?
<desrt> hm.  hopefully he is around tomorrow, then
<fabbione> mkrufky: oh hmm.. can't remember
<mkrufky> it is not in mainline, and probably will never be
<fabbione> let me check
<mkrufky> it is device driver for the digium boards
<mkrufky> for asterisk
<fabbione> i am checking..
<mkrufky> k
<fabbione> we added quite a bunch of external drivers
<fabbione> so i don't exactly remember all of them
<mkrufky> zaptel is also quite actively changing in cvs
<fabbione> nope we don't
<mkrufky> ya i didnt think so... 
<mkrufky> so anyone that wants to make a pbx will have to install that kernel driver from cvs, and lose ubuntu support?
<fabbione> mkrufky: well not really...
<fabbione> or better.. it depends
<mkrufky> i was told that installing external modules causes loss of support
<fabbione> let say that the standard kernel works on machine foo
<fabbione> and you add a module
<fabbione> and the kernel starts to oops
<fabbione> than well.. there isn't much i can do there
<fabbione> (like with nVidia binary crap)
<fabbione> but if the kernel oops before and after.. makes no difference
<mkrufky> you could always say, "it must be your externel module... ask #foo for help with that"
<fabbione> now.. if you are talking about commercial support.. i have no idea..
<fabbione> mkrufky: well as i explained above, if the kernel works and only adding that module starts to oops..
<mkrufky> ya i gotcha
<fabbione> it is sort of clear that the module might either be buggy or exploit a bug in the kernel
<fabbione> but if i get an oops that is related only to that driver..
<fabbione> well than i need to forward you to #foo
<mkrufky> ya
<fabbione> but note.. this is true for drivers of which i can read the code..
<fabbione> if i get bugs like "NVidia driver oops"
<fabbione> i don't even bother to check
<fabbione> i send them to nvidia forums
<fabbione> no code.. there is nothing i can do
<mkrufky> ya we do the same in #v4l 
<fabbione> ok :)
<mkrufky> nvidia should just open up their drivers
<mkrufky> oh well
<mkrufky> i use all ati
<mkrufky> :-D
<fabbione> they both should :)
<mkrufky> true
<mkrufky> but there are some good oss ati drivers
<fabbione> yes
<fabbione> they should still open up
<mkrufky> i agree
<fabbione> brb.. i have to wake up my wife
<mkrufky> k
<mkrufky> i'm actually goin to bed soon
<mkrufky> was nice chattin
<fabbione> thanks a lot mkrufky 
<fabbione> good night
<mkrufky> nite
<Mithrandir> BenC: how do you feel about applying http://bugzilla.ubuntu.com/attachment.cgi?id=1985 ?
<Mithrandir> (I know it's late in the release cycle, but I was made aware of it late.)
<mjg59> BenC: When are we looking at a new kernel release?
<BenC> mjg59: this week
<mjg59> BenC: Any idea when?
<BenC> Wed or Thu
<Mithrandir> BenC: what about the p4-clockmod patch?
<BenC> Mithrandir: which bug report is that for?
<mjg59> BenC: Ok. Kernel freeze is the end of next week?
<Mithrandir> BenC: http://bugzilla.ubuntu.com/show_bug.cgi?id=8587
<fabbione> hey BenC 
<fabbione> BenC: i did commit all the sparc stuff to baz
<fabbione> let me know when it's time to prebuild before release
<fabbione> this is the last kernel.. if we fuck it up, we lose sparc for breezy
<mjg59> Uh. We're only doing one more release?
<fabbione> mjg59: yes
<fabbione> and i think we are already pretty late
<fabbione> we should be already in Security only bug fixing iirc
<mjg59> Ok. That presents certain problems.
<fabbione> we are at 3 weeks from release
<fabbione> let me check the schedule
<BenC> if anyone wants patches added to the kernel before this next release, please can you send me a diff with the .dpatch, changelog entry and 00list-8.14 entry added?
<BenC> I have about 3 bug reports that I need to do some hardcore kernel debugging with, before this next release
<BenC> going to be time consuming
<fabbione> kernel freeze is the 24th
<fabbione> so that means friday
<fabbione> sorry
<BenC> Friday is the latest then
<fabbione> 29th
<fabbione> so in 10 days
<Mithrandir> BenC: well, I would like a comment on the bug I mentioned above; I don't know kernel stuff enough to tell whether it's correct or not.
<BenC> Mithrandir: hold a sec
<BenC> Mithrandir: the patch is clean, so I think it can go in
<Mithrandir> BenC: excellent, can you wrap it up or should I commit it to the archive?
<BenC> it might also fix some other bug reports (powernowd causing screwed up mouse, cpufreq messing up the clock speed)
<BenC> If you have the time, please do
<BenC> if not, shoot me an email as a reminder
<Mithrandir> I can just do it.
<Mithrandir> (it's not that I don't have enough to do, but it's trivial enough. :)
<BenC> :)
<zul> hey peeps
<BenC> hey zul
<zul> how is it going ben?
<BenC> not too bad
<BenC> how about you?
<zul> good...after recovering from a flu bug and a cold as well as good be expected
<fabbione> hey zul
<BenC> nasty, I hate the flu more than anything
<fabbione> BenC: so we have only 3 pkgs that are FTBFS on sparc/main/breezy :)
<fabbione> one of which we don't really care
<zul> yeah i had chills and hot flashes...i think i got it from fabbio...
<zul> hey fabbione 
<fabbione> but kernel and klibc yes.. we do :)
<fabbione> zul: i told you not to lick my nose while i am sleeping!
<BenC> fabbione: you said klibc was getting fixed, right?
<fabbione> BenC: jbailey was going to look at it...
<fabbione> kernel is fixed if we don't change the hell in it
<BenC> what's wrong with klibc on sparc?
<zul> better than your nose than your nuts
<fabbione> BenC: it builds in 64bit mode...
<fabbione> and it fails in 32bit
<BenC> zul: yeah, that'd probably be a whole different sickness :)
<fabbione> mimatch = crash at boot
<fabbione> probably busybox-initramfs
<zul> hehe
<fabbione> bah i have 15 minutes.. i can give it a shot
<BenC> fabbione: kernel crash, or crash in klibc?
<fabbione> BenC: same kernel works with initrd
<fabbione> i get an oops
<fabbione> but  it's too early in the boot process to understand what's wrong
<BenC> does klibc run in kernel mode?
<fabbione> no idea
<fabbione> i don't think so
<BenC> is it just a stripped down libc like uclibc?
<fabbione> afaik yes
<BenC> hmm, and 32-bit mode causes a kernel crash...that sounds more like a kernel bug (assuming klibc runs in userspace mode)
<jbailey> BenC: It does.
<fabbione> nope.. i think it's the mistmatch between klibc being built in 64bit and busybox in 32
<fabbione> hey jbailey 
<BenC> if klibc is causing a kernel crash on sparc64, that's really bad
<jbailey> BenC: The kernel crash is almost certainly because there's nothing left to do, so the shell script dies.
<jbailey> As opposed to a real crash.
<BenC> ah
<BenC> so it's like init dieing?
<jbailey> Yup
<BenC> ok, I feel better now :)
<BenC> why is klibc being built as 64-bit?
<fabbione> BenC: the same exact kernel boots perfectly if we use initrd
<fabbione> that's why i pointed the finger at klibc
<BenC> initrd uses installed libc?
<jbailey> BenC: Because it sucks.  I haven't fixed it yet, I ran out of time this weekend.
<fabbione> BenC: eh that's the interesting problem
<fabbione> it's FTBFS on 32bit more
<fabbione> the one in the archive was my mistake building it manually
<jbailey> libgcc is pulling in .umul in 32 bit mode for some reason. 
<BenC> ah, where's the package, I can have a look later tonight maybe
<fabbione> and it did build in 64bit
<jbailey> I don't think it'll be hard to fix.
<fabbione> BenC: klibc
<BenC> easy enough :)
<fabbione> BenC: do you want access to the sparc with the chroots?
<jbailey> It was totally a case of I spent all of Saturday polishing up the initramfs-tools package, and Sunday needed a break.
<BenC> nah, I can just build it here
* jbailey really needs to find a null modem cable to get his U5 running.
<fabbione> jbailey: you polished it so much that somebody did open a critical on it :)
<jbailey> fabbione: Great.  I'll punt it to mjg59.  He sent me the patch that broke it.
<fabbione> ahahha
<jbailey> Apparently USB drivers suck and can'tbe loaded before a resume.
<fabbione> no shit...
<jbailey> So we had to split up the driver passes and do a resume after only the controllers are walked.
<fabbione> i managed today only after 6 months to get my USB webcam to work
<jbailey> But that's before md runs, before lvm runs, before evms runs...
<jbailey> Oh!  Since I have you both here.  I have update-initrfs in the package I just uploaded now.
<jbailey> So I need to do a hack again to use that now instead.
<mjg59> jbailey: Mm?
<jbailey> mjg59: 15775
<BenC> jbailey: can you unload drivers before a resume?
<jbailey> mjg59: It looks like resume isn't working in some case there.
<jbailey> mjg59: Wondering if you've thought of some magic way of making this all Just Work without me rewritting all of the logic in there?
<jbailey> mjg59: Like, I could walk the tree and maybe *unload* the USB drivers or something...
<BenC> err, I mean unload drivers before a suspend and then reload them
<mjg59> BenC: We do
<BenC> jbailey: the e100 and e1000 drivers fail if they are loaded during a suspend, and then are reloaded for the resume
<fabbione> mplayer http://gordian.fabbione.net:8090/fabcam.rm <-
<fabbione> not everybody all together please
<mjg59> BenC: The problem is that the driver gets loaded by initramfs, the old image is read back and then the module is loaded again
<mjg59> jbailey: It's not just USB. It's basically *everything*.
<BenC> if e100 and e1000 can be unloaded prior to the suspend, it may be a workaround that is needed if I can't figure out this 1 year old bug
<mjg59> BenC: They *are* unloaded prior to the suspend
<mjg59> All network and USB drivers are unloaded
<BenC> mjg59: prior to the suspend state being saved to disk?
<mjg59> Yes
<BenC> then this bug report makes even _less_ sense
<mjg59> BenC: Which one?
<mjg59> The problem is:
<zul> fabbione: what is it?
<BenC> upon resuming from S3, e100/e1000 dumps out because the EEPROM is seen as corrupted
<BenC> hold a sec...
<fabbione> zul: my webcam
<mjg59> BenC: If the driver isn't loaded, nothing saves/restores the PCI state
<zul> ooh..scarey
<mjg59> So in an ideal world, we don't unload the driver
<BenC> 14790
<mjg59> Except that most drivers are broken, so we do unload them
<BenC> anyone know the command off hand for getting the eeprom with ethtool?
<mjg59> jbailey: I'm not sure what cleaner ways there could be
<mjg59> BenC: That one is probably the same issue as with USB
<mjg59> BenC: initramfs loads the driver. The hardware is then in an initialised and running state. We resume from disk, and then try to load the module again. The driver doesn't know how to deal with this.
<mjg59> jbailey: Either we unload all the drivers, resume and then reload them
<mjg59> jbailey: Or we resume before we load those drivers
<mjg59> The second of these takes less time. Both would appear to have identical failure modes.
<BenC> mjg59: well, if the driver was unloaded prior to suspend, then there should be no saved state concerning the driver, and it should just do everything from scratch again, as if it was not resumed, right?
<mjg59> BenC: Yes, but the initialisation code expects quiescent hardware
<mjg59> Not running hardware
<mjg59> BenC: That bug report isn't S3, it's S4
<jbailey> mjg59: Right.  The issue I hit is that lvm and md cope poorly with devices missing.
<BenC> right, the reports I read on other sites said S3
<mjg59> jbailey: "Cope poorly" in what way?
<mjg59> BenC: Right. That's probably them failing to unload/load it, or something.
<BenC> mjg59: but if the driver was unloaded prior to suspend, then the hardware should not be running
<BenC> what would make it "running"?
<jbailey> mjg59: They'll activate anyway and then the missing devices require special handling to bring them online again (Like, remirroring, etc)
<mjg59> BenC: Except it is, because initramfs loaded the driver
<mjg59> jbailey: Oh, for christ's sake.
<jbailey> I don't remember what lvm does is a missing device case for multipath
<mjg59> jbailey: Hm. Is there any way that we can tell if there's a USB device in the lvm or md?
<BenC> probably checking /sys/
<jbailey> Not that I know of, but I haven't explored the idea.
<mjg59> jbailey: Well, in that case we lose *anyway*
<jbailey> The whole filesystem/mapper/ide-disk&&sd/block device sandwitch seems to be a bitch.
<jbailey> At each layer nothing cleanly refers to the next.
<mjg59> jbailey: Ok. Can we clearly define the problem?
<mjg59> jbailey: We need to resume *after* the swap partition is available, but *without* USB/network modules loaded
<jbailey> mjg59: "Suspend and resume suck.  We need to make it suck the least possible and piss off the fewest people in the failure cases"
<jbailey> Right.
<mjg59> So currently we should be doing that except in the case that the swap partition is on lvm
<jbailey> Do we just say for now that anyone doing something crazy like multipath on usb or NBD will lose and we're not too fussed?
<mjg59> Nobody's going to be doing md over NBD or USB
<jbailey> Or on md, I realised.
<mjg59> But they *might* be doing LVM on USB (they'd be fucking insane, but still)
<Mithrandir> mjg59: I've actually considered doing md over nbd, but not usb.
<jbailey> mjg59: The installer does this when you do lvm.
<jbailey> Mithrandir: I've done md over USB. =)
<Mithrandir> jbailey: some people will be doing raid over their USB enclosures.
<jbailey> Unplug the USB drive and store it for backup.  Drop in the new drive and remirror over the course of the day.
<jbailey> No waiting for overnight backups.
<mjg59> jbailey: It's fine for us to say that we don't support hibernate in bizarre configurations
<mjg59> jbailey: But we should support hibernate on plain LVM
<mjg59> Since currently we *do* support hibernate on plain LVM
<jbailey> Whats the right things long term?  Should the drivers eventually all work right?
<mjg59> Eventually we don't unload the drivers on suspend and their resume code works
* fabbione -> offline
<fabbione> later guys
<Mithrandir> can't the resume check that the modules are already loaded and not try to reload them?
<Mithrandir> (or is that a totally silly idea, since this is all handled through hotplug which does magic stuff)
<mjg59> Mithrandir: ?
<mjg59> Mithrandir: Ah - no, we're on a different kernel by then
<mjg59> suspend unloads module, saves image. Resume loads module, loads image. Module is now not loaded.
<Mithrandir> uhm, ok.
<mjg59> The resumed image has *no idea* what's happened before it was read off disk
<Mithrandir> is there any way to communicate that to it?
<Mithrandir> whatsoever?
<mjg59> No
<mjg59> But it wouldn't help, because the module code wouldn't be loaded
<jbailey> mjg59: alternatively, it should only attempt to load them if acpi has initialised.
<jbailey> " "
<jbailey> mjg59: Lovely, how do I do that? =)
<jbailey> I didn't think I could detect that from userspace.
<mjg59> Check for /proc/acpi
<jbailey> Ah? Okay.  I thought that was created when the first modules was loaded/.
<mjg59> No, it should be created when the interpreter starts
<jbailey> 'k
<jbailey> Is there any way of detecting which modules it's capable of accepting?
<mjg59> Nope
<Comte0> Hi. Can anyone have a look at bug #10307? I'm on that macintosh right now.
<jbailey> Sure, I can.
<jbailey> I'm also on a Mac G5 atm that's working.
<jbailey> Probably a different superdrive, though.
<BenC> me too
<BenC> I have a CDR/DVDR Superdrive
<BenC> it works (live cd)
<jbailey> I'll let Ben take it, he's more knowledgable that I for this.
<jbailey> (Still watching the screen, but doing marketplace updates in the other window)
<BenC> Comte0: how old is your G5?
<BenC> my superdrive is connected to my ATA according to System Profiler, but my harddrive is connected via sata, and the live-cd recognized it
<BenC> I think it's all the same bus though
<Comte0> BenC: it's quite new, I think it was bought for christmas
<Comte0> it's a "computer in the flat panel"
<Comte0> I suspect people who do not see the bug have a tower
<BenC> ah, mine's a big aluminum tower model :)
<BenC> still, the hardware for your ata/sata bus's are supported by the kernel
<BenC> the pmac-ide module is built into the kernel
<BenC> so it should see the cdrom with no problem
<BenC> can you do "dmesg | grep -i ata"
<BenC> and see if there is anything more specific?
<Comte0> there's no lspci on the install cd. I suspect I can have a look at /proc to see the hardware there ?
<BenC> cat /proc/ide/drivers
<BenC> ls -l /proc/ide/
<BenC> cat /proc/scsi/scsi
<BenC> ls -l /proc/scsi/
<Comte0> well, thanks
<desrt> uh oh.
<desrt> i think the new kernel contains some evil
<desrt> my computer just hard froze (hasn't done that in ages)
<desrt> what changed? :)
<BenC> your computer obviously :)
<BenC> no messages?
<desrt> serious, dude :p
<desrt> *hard* crash
<desrt> mouse stops moving.  music stops playing.  machine stops responding to ping (much less ssh)
<BenC> what type of machine and which kernel image?
<desrt> 686-smp on a MT box
<desrt> serial ata
<desrt> intel p4 3.0ghz with 2gigs of ram... asus p4p800-se mainboard
<BenC> how long was the machine up before it locked?
<desrt> i'll file a bug with all this
<desrt> about a day, i think
<desrt> let me check the syslog
<BenC> 2.6.12-8.13?
<desrt> yes
<BenC> did you find it locked up, or did it happen while you were using it?
<desrt> reboot   system boot  2.6.12-8-686-smp Mon Sep 19 10:23          (00:05)
<desrt> reboot   system boot  2.6.12-8-686-smp Sun Sep 18 01:25         (1+09:03)
<desrt> so a day and 9 hours
<desrt> while i was using it
<BenC> anything special going on when it happened?
<desrt> i was in the middle of surfing bugzillas
<desrt> just stuff i normally do
<desrt> the last time i had lockups like this was when i tried to enable CFQ
<BenC> cpu frequency scaling?
<desrt> no.
<BenC> do you have powernowd installed?
<desrt> yes but it's not running
<BenC> ok
<BenC> there's a p4 errata concerning cpu scaling, just making sure that wasn't it
<Mithrandir> BenC: can you run baz lint in the source tree and see if you get errors about duplicated ids?
<BenC> Mithrandir: no messages from baz lint for me
<Mithrandir> it complains about d-i/amd64/modules/amd64/.arch-ids/=id and d-i/hppa/modules/hppa/.arch-ids/input-modules.id, d-i/amd64/modules/amd64/.arch-ids/pcmcia-storage-modules.id and  d-i/hppa/modules/hppa/.arch-ids/nic-shared-modules.id and last d-i/amd64/modules/amd64/.arch-ids/irda-modules.id d-i/hppa/modules/hppa/.arch-ids/usb-storage-modules.id
<BenC> odd, those haven't been touched in awhile
<Mithrandir> hm, weird
<Mithrandir> I guess it's just baz being an ass
<desrt> ben -- 15799
<Comte0> re
<Comte0> BenC: I haven't found anything :(
<desrt> BenC; i was wondering if you could slip john mccutchan's inotify patch into the next release....
<desrt> BenC; it solves a fairly nasty race condition
<desrt> well... nasty as in impossible-to-work-around.... not as in the-kernel-will-panic
<Comte0> there's a couple of entries in /sys/devices
<BenC> desrt: does it change the kernel ABI?
<desrt> BenC; a bit.
<BenC> Comte0: there's nothing in /proc/ide/drivers or /proc/scsi/scsi?
<desrt> but backwards compatibly (and almost forwards compatibly)
<BenC> also do lsmod | grep sata
<desrt> BenC; there's a one-liner addition to a header file, though... so yes... the API changes
<BenC> desrt: if it changes the abi, it potentially breaks modules built against the kernel (versioned symbols change)
<BenC> oh
<BenC> no, not API, the binary ABI
<Comte0> BenC: bugzilla has just been updated
<desrt> BenC; definitely won't do that
<BenC> ok, then sure, I can include it
<desrt> BenC; no functions change prototypes, no data structures change layout
<desrt> it's just an additional flag to an already-existing function (that's only called from userspace)
<Mithrandir> uhm
<Mithrandir> I think I might just have broken the baz archive
<desrt> http://bugzilla.ubuntu.com/show_bug.cgi?id=14458
<desrt> BenC; this is in the tree that will become linus's 2.6.14
<BenC> Comte0: can you see if lsmod shows that any ata, sata or ide drivers are loaded?
<BenC> also try "modprobe sata_svw"
<Mithrandir> BenC: can you please fix your umask on rookery and chmod +x /home/lamont/public_html/Archives/kernel-team@ubuntu.com--2005/kernel-debian--preX,14--2.6.12 ?
<BenC> my umask should be fine
<Comte0> Sure, but I'd like to know if there's some file you want to see in /sys
<BenC> Mithrandir: $ ls -ld /home/lamont/public_html/Archives/kernel-team@ubuntu.com--2005/kernel-debian--preX,14--2.6.12
<BenC> drwxrwxr-x  8 bcollins warthogs 4096 Sep 19 15:55 /home/lamont/public_html/Archives/kernel-team@ubuntu.com--2005/kernel-debian--preX,14--2.6.12
<BenC> Comte0: /sys doesn't matter at this point, right now we need to see if the module is loaded, if not then we need to try loading it manually to see if that resolves the problem
<Mithrandir> sorry, I'm blind
<BenC> if it is, then we need to see why it isn't working
<Comte0> ok
<lamont-away> Mithrandir: the only stuff in that archive that is owner-writable but not group writable is in kernel-team@ubuntu.com--2005/kernel-debian--mainline-2,6,11,92-1,1--0/base-0/
<lamont-away> which I don't think we care about anymore...
<lamont-away> (since it's 4+ months old now..)
<Mithrandir> lamont-away: I kicked it a bit and the problem went away.
<lamont-away> heh
<lamont-away> speaking of going away - back much later
* zul got new shoesies
<BenC> desrt: can you make that inotify bug P1?
<desrt> k.
<desrt> done.  thanks.
* desrt off to school/work/whatever
<Comte0> BenC: short answer, there is no sata modules
<Comte0> I'll put the long one in the bugzilla
<Comte0> bug #10307 has been updated. Anyone can check the live-cd initrd kernel has sata enabled ?
<Comte0> (the ppc power4 one)
<BenC> Comte0: you're using the power4 cd?
<BenC> I used the powerpc one
<BenC> that's probably your problem
<Comte0> it's the one that works...
<BenC> power4 wouldn't have the mac drivers
<Comte0> erm, there's only one powerpc cd, isn't it ?
<BenC> the powerpc one works for me, and no, the power4 one isn't working for you, else you wouldn't have filed a bug :)
<BenC> well, you said power4
<BenC> I assumed there was one specific to that system
<BenC> are you booting with live64 (or whatever it is)?
<Comte0> Is it the 64 bits kernel?
<BenC> G5 is 64-bits
<BenC> how do you boot the cd, what command do you type at yaboot?
<Comte0> live-power4
<BenC> that's the wrong one
<BenC> live-powerpc64
<Comte0> is hitting enter the good solution?
<BenC> no, for G5, you have to type the live-powerpc64 (I did too)
<BenC> yaboot doesn't auto detect yet
<BenC> Comte0: this would explain a lot
<Comte0> (it also means you have read comment #4 too quickly ;) )
<Comte0> oh, nevermind
<Comte0> re
<BenC> does it work?
<Comte0> BenC: when is the deadline for kernel changes on breezy? I'll try to rip a preview iso before
<BenC> 10 days
<BenC> did the system boot with live-powerpc64?
<Comte0> no, ther's no install/powerpc64 directory on my cd
<BenC> download the latest breezy preview
<BenC> I'm quite sure that it will work, and that the problem has just been that you are booting the wrong kernel
<Comte0> the blank cd was left at home :(
<BenC> ah, ok
<Comte0> $ ls /Volumes/Ubuntu_PowerPC_hoary/install/
<Comte0> boot.msg        power3          powerpc         yaboot.conf
<Comte0> ofboot.b        power4          yaboot
<Comte0> $ ls /Volumes/Ubuntu_PowerPC_hoary/install/
<Comte0> boot.msg        power3          powerpc         yaboot.conf
<Comte0> ofboot.b        power4          yaboot
<Comte0> $ ls /Volumes/Ubuntu_PowerPC_hoary/install/
<Comte0> boot.msg        power3          powerpc         yaboot.conf
<Comte0> ofboot.b        power4          yaboot
<Comte0> $ ls /Volumes/Ubuntu_PowerPC_hoary/install/
<Comte0> boot.msg        power3          powerpc         yaboot.conf
<Comte0> ofboot.b        power4          yaboot
<Comte0> ls /Volumes/Ubuntu_PowerPC_hoary/install/
<Comte0> $ ls /Volumes/Ubuntu_PowerPC_hoary/install/
<Comte0> boot.msg        power3          powerpc         yaboot.conf
<Comte0> ofboot.b        power4          yaboot
<Comte0> $ ls /Volumes/Ubuntu_PowerPC_hoary/install/
<Comte0> boot.msg        power3          powerpc         yaboot.conf
<Comte0> ofboot.b        power4          yaboot
<Comte0> that was why I was so slow to reply: The computer is my father's
<Comte0> ...and I hate MacOs X cut&paste ...
<Comte0> sight
<zul> wth...oh..sorry
<Comte0> well, thank you very much for your help
<Comte0> BenC: I'll try next saturday
<mjg59> Have we fixed the ndiswrapper build on amd64?
<mjg59> Also:
<mjg59> sky2 isn't going to be ready in time for Breezy
<mjg59> zul: Did you get anywhere with the sk98lin stuff?
<zul> mjg59: i have it in my arch, the sk98lin stuff im going to work on tonight
<zul> work had really busy the past couple of days
<mjg59> zul: Ok - it's fairly urgent, so I can do it now if that would be easier
<mjg59> Hmm. Uhm.
<mjg59> Do we actually have sk98 in the kernel already?
<mjg59> Ah, yes
<zul> mjg59: please
<mjg59> zul: Ok, no problem
<mjg59> Waa why must it be a 1 MB patch?
<zul> because its syskonnect and they are bastards
<mjg59> Ok, done.
<mjg59> It seems to build, and the PCI IDs don't overlap with skge
<zul> do you want to forward to me so i can do a build test tonight?
<mjg59> Sure. Email address?
<zul> zulcss@gmail.com
<mjg59> Ok, sent
<zul> cool...ill do it when i get home tonight
<BenC> mjg59: thanks for the patch
<mjg59> BenC: NP
<mjg59> BenC: There's a one character error in the diff I sent you. I'll resend.
<BenC> ok
<mjg59> BenC: Right, done
#ubuntu-kernel 2005-09-25
<jbailey> mjg59: So it seems the patch killed any system without a swap partition, joy.
<jbailey> mjg59: I thnk I have it fixed.
<jbailey> =)
<mjg59> jbailey: Hrm?
<jbailey> The other suspend shell script had a guard to make sure that if the RESUME variable wasn't defined, that it didn't attempt to figure everything out.
<jbailey> This one didn't have the guard.
<jbailey> It turns out that [ -e ${RESUME} ]  returns true when RESUME isn't defined.
<mjg59> Ah
<mjg59> Right
<jbailey> [ -e "${RESUME}" ] , however, returns false.
<mjg59> Hm
<mjg59> But it's still failing to resume, for some reason
<jbailey> mjg59: Cerainly on my laptop resume doesn't seem to be defined.
<jbailey> But hopefully, I can kill all the critical bug reports at least.
<jbailey> *sigh*
<mjg59> jbailey: "defined"?
<jbailey> //sys/power/resume is 0:0
<mjg59> Hm. When is this? After boot?
<mjg59> jbailey: Ok. If I panic immediately before the resume call, I have no disk devices
<mjg59> jbailey: Doing a udevstart gives me devices
<mjg59> jbailey: Argh. Yes, udevstart is run after load_modules has finished
<jbailey> Ahahahaha
<jbailey> Hm
<jbailey> But why didn't the second call catch it?
<mjg59> Dunno
<jbailey> It should at least still be set, since the suspend script is still there?
<jbailey> I think I want to spend another day thinking about how to lay this all out.
<mjg59> I'd prefer that we had something in the archive that worked, to be honest
<jbailey> Most people will have swap on lvm, I think.
<mjg59> Really?
<jbailey> IIRC, the installer does LVM by default now.
<mjg59> Uhm.
<mjg59> Not in my experience.
<mjg59> Unless you tell it to use the whole disk?
<jbailey> Dunno.
<mjg59> Hm.
<jbailey> All of my machines are whole-disk installs.
<jbailey> But I thought that it was doing LVM in general now.
<mjg59> Right. Hrm.
<mjg59> Oh, I'm told that it's easy to check if all the disks in an LVM are present
<mjg59> One of the vg commands will tell you
<mjg59> jbailey: Ok, yeah. A udevstart sorts it.
<jbailey> So in what order should this happen then?  Attempt to walk the PCI bus, find card.  Find ide-disk, sd, and friends.
<jbailey> udevstart
<mjg59> Yeah.
<jbailey> Mm, no, step before.
<jbailey> Start md, lvm, evms.
<jbailey> I'm wrong, those are after udevstart
<mjg59> udevstart needs to be before md and lvm
<mjg59> Yeah
<mjg59> Except we only want to start them if we have all member disks
<jbailey> Right, but that's a good hack to put the in lvm script anyway
<mjg59> Sure
<mjg59> Hurrah. Working hibernate.
<jbailey> Then walk the bus a second time, looking for usb and network drivers.
<mjg59> Yeah
<jbailey> start md, lvm, and evms. =)
<jbailey> Sorry udevstart.
<jbailey> Then start those.
<jbailey> Then attempt hibernate resume again in case the device was on one of those and it happens to work for people.
<mjg59> Yeah
<jbailey> Sick.
<mjg59> Heh
<jbailey> Mind you..
<jbailey> I guess I can shortcut that second pass if I have swap and the root device.
<jbailey> All I need is USB at that point in case they drop to a shell.
<jbailey> I wonder how many people will get screwed if I suddenly don't load their ethernet cards in the initramfs?
<zul_> heylo
<jbailey> mjg59: Are you getting lots of reports of fails to resume?
<jbailey> I have 15775
<mjg59> jbailey: Well, it's broken with current initramfs-tools
<mjg59> As in, there's no way it can work
<jbailey> Right.  I'm wondering if it's urgent enough that I should stay up, or if I can consider my workday over and dive in tomorrow.
<jbailey> I'd sortof like dinner and to see my belle.
<mjg59> Heh
<mjg59> Would it be possible to just add the one-line udevstart to fix some cases?
<mjg59> I'll take a look at the lvm stuff and let you know what I find
* jbailey squirms.
<mjg59> It leaves things no worse than they are right now
<jbailey> Oh, I figured out why the suspend script isn't running.
<jbailey> It needs a chmod +x
<mjg59> Ah. heh.
<jbailey> When I recovered it from bzr, it didn't preserve that.
<jbailey> I'd really prefer to leave it until I can actually do a test run with it.
<mjg59> I've just done a test run with that case
<jbailey> I'm basically going to go offline for the night in a few minutes and don't want to look for more "OMG can't boot" bugs. =)
<mjg59> The one change I made was to add the udevstart
<zul_> heh liar
<jbailey> mjg59: You have main upload privs, don't you? =)
<mjg59> jbailey: Heh. Indeed.
<mjg59> jbailey: Have you uploaded the one with the resume guard quotes?
<jbailey> mjg59: Feel free.  That way they beat on your for touched-it-last priviledges.
<jbailey> mjg59: I have.  If you're using bzr, I've updated that to 0.27
<mjg59> jbailey: Hm. vgscan ought to return an error, I'm told
<mjg59> jbailey: Ok, where's your tree?
<jbailey> http://people.ubuntu.com/~jbailey/bzrtree/initramfs-tools
<mjg59> Thanks
<jbailey> vgscan doesn't take a vg as a parameter, though.
<jbailey> The root vg is the only thing that needs to promise to be present at boot time.
<jbailey> Other arrays and stuff could require fancier setup that requires an otherwise running system.
<mjg59> Hmm. Yes.
<jbailey> I wonder if vgdisplay has it.
<mjg59> There must be a reasonable way to get it out of the metadata.
<jbailey> With lvm, it's not obvious what's reasonable or not.
* jbailey runs off for food.
<BenC> mjg59?
<mjg59> BenC: Hi
<desrt> BenC; poke
<fabbione> morning guys
<fabbione> BenC, jbailey: ping?
<zul> morning
<fabbione> hey zul
<zul> hey fabbione how goes it?
<fabbione> zul: working as usual
<fabbione> you+
<zul> ditto
<Diziet> Ah, hello fabbione.  I just wanted to have a quick word with you about that kernel-package dependency thing.
<Diziet> Do you have a moment ?
<fabbione> Diziet: can you give me 5/10 minutes?
<Diziet> Sure.
<fabbione> Diziet: ok...
<fabbione> i am back
<fabbione> Diziet: ??
<Diziet> Hello.
<fabbione> so remind me where we left the discussion
<Diziet> So this is about 15488.  Can you remember what I was saying on Friday ?
<fabbione> yes
<fabbione> till we agree to stop for the day :)
<Diziet> kernel-package has a hardcoded value `gcc', which it inserts into the Depends of the source .deb's that it causes to be created.
<Diziet> mdz and the submitter seem to think just changing that to gcc-3.4 would be correct.
<fabbione> Diziet: one second that i am digging code and stuff...
<Diziet> Since when you use kernel-package with one of our kernels they end up trying to build against gcc-3.4.
<fabbione> Recommends: libc-dev, gcc, make
<fabbione> ok
<fabbione> gcc is only Recommended
<fabbione> not a Depends:
<fabbione> now we have 2 situations we need to analize
<fabbione> and that's why i didn't agree with your changes
<fabbione> 1) building our linux-source
<Diziet> Yes, I see what you were saying about my change which I agree was wrong.
<fabbione> 2) building a generic vanilla kernel
<fabbione> ok
<fabbione> let's take it again point by point
<Diziet> Right.
<fabbione> so we are sure we don't overlook anything
<fabbione> for the sake of release in 3 weeks :)
<fabbione> our kernel must be built with gcc-3.4
<fabbione> this is hardcoded
<fabbione> so
<fabbione> the Package: linux-source-2.6.12 must Depends on gcc-3.4
<Diziet> Hardcoded in the Makefile you get when you unpack one of our kernel source trees (no matter how you got it).
<fabbione> or Recommends: gcc-3.4
<fabbione> and I agree with BenC that should be a Recommentds
<Diziet> Right.
<fabbione> Diziet: exactly
<fabbione> it's hardcoded in the makefile
<Diziet> When you say `the Package: linux-source-2.6.12' you mean _our_ `linux-source-2.6.12'.
<Diziet> But of course someone could sensibly use make-kpkg to make their own linux-source-2.6.12.
<fabbione> Diziet: we have a source called linux-source-2.6.12 that B-D on gcc-3.4
<Diziet> That's one of the things it's for.
<Diziet> Right.
<fabbione> and a package that ships our source + patches that Recommends: gcc
<fabbione> the latter is wrong
<Diziet> Indeed so.
<fabbione> so we all agree that P: l-s-2.6.12 must either Depends: gcc-3.4 or Recommends: gcc-3.4
<fabbione> because i might download the source only for reading
<Diziet> _Our_ l-s-2.6.12, yes.
<fabbione> yes
<Diziet> Right.
<fabbione> our
<fabbione> i didn't talk about pint 2 at all
<Diziet> OK.
<fabbione> that's why i isolated the cases
<fabbione> i am still on point 1)
<Diziet> Carry on ...
<fabbione> so for 1) that's the only change required
<fabbione> now
<fabbione> 2) is more complex
<fabbione> it is way more complex
<fabbione> why:
<fabbione> a) we don't know what kernel the user is building
<fabbione> b) and we don't know why
<fabbione> so we can't force a gcc to him
<fabbione> he might be as well compiling a kernel with gcc-4.0 for debuggin
<Diziet> Currently, make-kpkg does do that.  That is, if the user uses make-kpkg to make a linux-source.deb, it will say Recommends: gcc.
<fabbione> we have no idea
<Diziet> Right.
<fabbione> so i still believe that Recommends: gcc is the right solution
<fabbione> i see no winner in forcing a gcc
<Diziet> In this second case ?  Certainly there shouldn't be a Depends.
<fabbione> ok..
<Diziet> But yes, it seemed to me that either Recommends: gcc or nothing at all would be best.
<fabbione> and that's how the situation is
<Diziet> Nothing at all is a reasonable option - after all, the user knows what they're doing and we shouldn't trip them up.
<fabbione> also.. who compile its own kernel, needs to know what it is doing
<Diziet> Exactly.
<Diziet> Now, AIUI both of these cases are generated by the same code in make-kpkg.
<fabbione> so for me.. personally.. 15488 is NOTABUG :)
<Diziet> Um, you're saying that _our_ linux-source packages are _not_ made with make-kpkg ?
<fabbione> Diziet: yes it is made with make-kpkg
<Diziet> So surely atm the dependencies are wrong ?
<fabbione> Diziet: yes.
* Diziet goes to check.
<fabbione> but we need to fix it in debian/control in linux-source-2.6.12
<fabbione> and not in kernel-package :)
<fabbione> our l-s-2.6.12 debian/rules is insane
<Diziet> But linux-source-2.6.12, if it is make with make-kpkg, has an autogenerated debian/control made by make-kpkg.
<Diziet> s/is make/is made
<fabbione> iirc it is overwritten
<fabbione> there are scripts that copies parts of debian/control to differnt packages
<Diziet> Scripts where ?
<fabbione> inside debian/
<Diziet> In linux-source-x.y.z's source package ?
<fabbione> it's all contained in one dir (at least!)
<fabbione> yes
<Diziet> But make-kpkg makes up a source package out of whole cloth.
<fabbione> Diziet: be aware that our source doesn't call make-kpkg on itself
<fabbione> the source is copied/mangled/trashed/reconfigured several times
<fabbione> and that happens in debian/build
<fabbione> building our kernel is not only executing make-kpkg
<fabbione> there are plenty of more problems we need to address
* Diziet reads debian/rules build in linux-source 2.6.12's source.  Blimey.
<fabbione> Diziet: you also want to check the scripts that it calls
<Diziet> Yes, so I see.
<Diziet> kernel-wedge gen-control > debian/control
<fabbione> yes.. kernel-wedge is for udebs
<fabbione> control file is generated via control.stub
<fabbione> nothing too fancy
<fabbione> Diziet: line 162
<fabbione> sorry 163
<fabbione>         cp debian/control $(srcdir)/debian
<fabbione> that one copies our control file into debian/build/linux-source-2.6.12/debian/
<Diziet> Right.
<fabbione> the dir that will generate the source afterwards
<Diziet> But even debian/control.stub looks like it should be autogenerated.
<Diziet> It's full of version numbers.
<fabbione> Diziet: ALT
<fabbione> control.stub and control are only for udebs
<Diziet> ALT ?
<fabbione> ALT = STOP :)
<fabbione> sorry...
<fabbione> itaglish
<fabbione> you will learn that my itaglish > pure english :P
<fabbione> don't get confused by control.stub and control
<fabbione> that's not relevant for we need here
<fabbione> just think at them like debian/control
<fabbione> the mangling required for udebs is another story
<fabbione> (brb.. mother nature is calling ;))
<Diziet> So when you update to a new upstream kernel, how to the version numbers get furtled in these control files ?
<Diziet> OK.
<fabbione> (= i need to take a piss )
<Diziet> Yes, that's not itaglish :-).
<fabbione> Diziet: sed -i -e 's/2.6.12/2.6.whatever/g' debian/control.stup
<fabbione> and for a little bunch of more files
<fabbione> it's suboptimal
<fabbione> but I never had the time to rewrite that mess
<fabbione> so we can live with it...
<fabbione> and we should merge our build system with the Debian one
<Diziet> Ah, right.  So the right answer is just to change control and control.stub and leave kernel-package alone.
<fabbione> exactly
<fabbione> control.stub is enough :)
<fabbione> control is regenerated
<Diziet> OK :-).
<Diziet> Do you want me to attempt to do that ?  Is this stuff in arch or something or just normal uploads ?
<fabbione> Diziet: see /topic :)
<fabbione> i can do it.. it's one line change
<Diziet> Hey, I looked at the topic _yesterday_ :-).
<fabbione> yeah...
<fabbione> debian/ is in baz
<Diziet> Right.  Well, I'll leave you to do it I think; probably quicker than me faffing, unless I'm going to turn into an actual kernel bod.
<fabbione> Diziet: that's ok..
<fabbione> Diziet: it is important that we coordinate changes to the kernel build system all together
<fabbione> there are a lot of bits that need to fall down in the right place
<fabbione> otherwise we can wave kthxbye to it
<Yagisan> how much space is needed when compiling linux-source ?
<Yagisan> I've tried to add a driver to my local copy, but it dies in my pbuilder complaining it is out of space.
<fabbione> Yagisan: it depends.. it can be quite a lot
<fabbione> up to 550MB for a build
<fabbione> sorry per flavour
<Yagisan> ah
<Yagisan> so my 11GB tmpfs wasn't enough
<fabbione> Yagisan: they should be plenty...
<fabbione> but well... if it complains about space, you must have done something wrong
<Yagisan> well, all I did this morning was "sudo pbuilder build linux-source-2.6.12_2.6.12-8.13.dsc"
<fabbione> Yagisan: it depends how you did configure pbuilder
<fabbione> by default it uses /var/cache
<fabbione> so if your /var/cache/pbuilder/build is a tmpfs, than yes.. you were building in RAM
<fabbione> otherwise you were writing on fs
<Yagisan> I set BUILDPLACE=/tmp/ in pbuilder and /tmp is tmpfs
<Yagisan> so I think pbuilder is set up ok
<Yagisan> I've never build anything this big in pbuilder though
<fabbione> Yagisan: just be sure it is really using /tmp than
<Yagisan> ok. I've just freshly unpacked linux-source-2.6.12_2.6.12-8.13.dsc and confirmed it is building in /tmp, now to wait and see if it crashes again - this time with logging on.
<mkrufky> fabbione: about v4l/dvb kernel updates (for breezy):  what kernel should I patch against?
<fabbione> mkrufky: if you really want to spend your time on it, against our tree
<fabbione> but we are really too close to release to update an entire subsystem
<fabbione> i think it's more worth to start working from the dapper kernel
<mkrufky> ah, then i wont bother... no big deal... 
<mkrufky> i guess that kernel will be ready in about a month, right?
<fabbione> mkrufky: i think in 10 days we can start working on dapper kernel
<fabbione> we won't be able to upload it
<fabbione> but given that breezy is uber frozen
<fabbione> we can start playing around in a devel branch
<mkrufky> hmmm..... so will i get access to this branch?
<fabbione> mkrufky: if you use baz yes of course
<fabbione> you won't be able to commit directly to it
<fabbione> but you can branch off 
<fabbione> and publish your branch
<fabbione> and we can merge back
<fabbione> no big deal
<fabbione> zul did this for all the hoary release...
<fabbione> it did work pretty well
<mkrufky> thats fine... i guess i have a new tool to learn then.... (never heard of baz, but there's always a good time to learn)
<fabbione> ehhe
<fabbione> apt-get install bazaar
<fabbione> there are plenty of howto's
<mkrufky> got it
<fabbione> for basic stuff i can even help you :)
<mkrufky> i'm downloading it now... will play around a bit
<fabbione> sure
<zul> i did what?
<zul> oh...heh
<zul> heh i wasnt special enough to get direct access ;)
<mkrufky> dont be jealous... im not special enough either :-P
<BenC> mjg59: ping
<mjg59> BenC: Hi
<mjg59> Hm. Are we allowed to break the ABI now?
<BenC> hey, can I close 14790?
<BenC> no :)
<mjg59> Shit. Right.
<mjg59> BenC: Yeah, looks like that can be closed
<mjg59> Argh.
* mjg59 tries to figure out a way of doing this without breaking ABI
<mjg59> I fear it may be impossible
<mjg59> Right. It breaks ABI in the pcmcia socket driver
<mjg59> If we want to support recent TI PCMCIA chipsets properly, they need an extra prod to power up properly by the looks of it
<zul> mjg59: i cleaned up the patch a bit last night so it applies will be doing a test build tonight and will commit it to my archive tonight for BenC 
<mjg59> Maybe I can just drop that hunk.
<mjg59> zul: Which patch?
<fabbione> meh breaking the abi is still possible, but mdz is not going to like it
<mjg59> I'll see if I can do this without it
<fabbione> BenC: i am working on fixing 15488, 14736 and 13506
<fabbione> if you already did any of them, please let me know
<zul> mjg59: sk98lin
<zul> BenC: i have a patch for the buslogic stuff, i need to find a way to test it though
<mjg59> zul: Cool
<BenC> buslogic == vmare fix?
<zul> yep..i added a struct for hotplug it seems the logical thing to do
<zul> based on previous examples
<BenC> fabbione: cool, thanks
<BenC> my vmware install is v5, so I can't test it
<Yagisan> I have vmware 5.5beta
<Yagisan> want a copy ?
<mjg59> Blah.
<zul> sure...just send me a key or something
<mjg59> Suck.
<mjg59> It looks like we need to break ABI if we want these controllers to work
<BenC> Yagisan: bug shows in vmware v4
<mjg59> (Which includes bsaically everything made by HP at the moment)
<mjg59> Sorry, my fault. I should have noticed this earlier.
<zul> meh...i have a key for vmware4
<BenC> mjg59: well, if it's that bug a deal, we will break it
<mjg59> They work if you boot with the card in, but there are no events for insertion/deletion
<BenC> s/bug/big/
<Yagisan> BenC: I have 4.5.2 somewhere too
<BenC> I think supporting cardbus on a large range of laptops qualifies as worthy of abi breakage
<Yagisan> vmware 5 keys work in 5.5beta - that's part of the deal of being a beta tester
<BenC> Yagisan: A copy of that would be nice, if it's not too much trouble
<zul> Yagisan: same here
<zul> lunch time
<mjg59> BenC: Mailed
<BenC> mjg59: the ABI breaker?
<mjg59> Yeah
<mjg59> The break is in cs.c
<BenC> ok, thanks
<BenC> btw, did you resend a second sk98lin patch?
<BenC> I only got one
<BenC> the first one
<mjg59> Hrm. I did.
<mjg59> The only difference was that -Ia/drivers was replaced with -Idrivers in the EXTRA_CFLAGS statement
* mjg59 wonders what's up with his mail
<fabbione> BenC: we need to add an extra package to upload when we break the ABI
<fabbione> BenC: klibc B-D
<Yagisan> heh - I did it again. linux-source-2.6.12_2.6.12-8.13 again failed to build in pbuilder - cites "lack of space"
<fabbione> Yagisan: i blame pbuilder
<Yagisan> fabbione: at least I have a log now
<mjg59> BenC: Did you get the patch I just mailed you?
<Yagisan> I'll point pbuilder at a 600GB RAID array, start it up, and go to bed. If it isn't done by the time I get up - I'll file a bug on pbuilder.
<BenC> mjg59: not yet, I did get the pcmcia patch though
<mjg59> BenC: Yes, that's the one I sent
<mjg59> Should I resend the sk98lin one?
<BenC> nah, I can just add your change manually
<mjg59> Ok
<BenC> I get spurious a's in my stuff too, I can deduce that you use vi :)
<BenC> mjg59: are you sure the change to cs.c breaks the ABI?
<BenC> the change is to socket_setup(), which is a static function
<mjg59> BenC: Sorry, I should have been clearer. It adds a new callback to struct pcmcia_socket (see ss.h)
<mjg59> So that changes the version
<BenC> ah, ok
<BenC> zul: ping
<mkrufky> jbailey: fedora kernel people dont like my tree-merge solution, RE: missing dvb headers.... have you ever heard from the original bug poster?
<mkrufky> jbailey: im hoping to get those moved into /include/linux/dvb .... hopefully for 2.6.15
<BenC> mjg59: does the pcmcia fix apply to bug 15734, or is that bug a dup of the one this fixes?
<zul> BenC: yo
<mjg59> Should be unrelated
<BenC> zul: you have sk98lin in your tree, right? So I don't need to merge this directly?
<BenC> apply directly I mean
<BenC> mjg59: ok
<BenC> what bugs is it
<mjg59> BenC: Don't have the number to hand, but it bites me here
<zul> BenC: it will be going in tonight when i get home, should i remove the other yukon driver patch?
<BenC> zul: yeah, I'm dropping sky2 completely
<mjg59> 15196 looks likely, 15083 certainly is
<BenC> if you pull it from your tree, even better, so I can just merge and take care of both
<zul> BenC: ah so ill add it tonight, im just doing a build now to make sure everything is hunky dory
<BenC> zul: thanks
<BenC> I plan on making tomorrow prep day for upload on Thurs
<BenC> just FYI
<zul> ok..ill commit it tonight then ;)
<mjg59> BenC: One more easy patch for you, possibly a couple of more awkward ones
<mjg59> (won't break ABI)
<BenC> mjg59: ok, I'm going to take those bugs, mark 15196 a dupe of 15083, and mark 15083 PEND
<mjg59> Ok, cool
<zul> whoops
<mjg59> Hurrah!
<mjg59> I may have found the solution.
<BenC> pcmcia?
<mjg59> PCMCIA breaking hibernate
<mjg59> I'm afraid you're stuck with the ABI breakage :)
<BenC> damnit :)
<jbailey> mkrufky: Ah, okay.  I haven't taken a look at the script.
<jbailey> mkrufky: Basically what's in the bug report is all I've got.
<jbailey> mkrufky: Given that it's new files going in, is there no way to get them in for 2.6.14?
<mjg59> I win
* fabbione commits fix for 15488
<fabbione> guys .. one suggestion
<fabbione> i am reading here... kill sky2.. add sk98lin.. blabla
<fabbione> be aware that this might be the last kernel upload
<fabbione> and that somebody will have to support for 18 months
<fabbione> is the archive fucked up???
<fabbione> oh fuck
<fabbione> Mithrandir: you blocked the kernel archive
<fabbione> Mithrandir: you need to set a proper umask on people
<fabbione> Mithrandir: /home/lamont/public_html/Archives/kernel-team@ubuntu.com--2005/kernel-debian--preX,14--2.6.12/
<fabbione> check for patch-5 and fix permissions
<fabbione> i guess i will commit later
<mjg59> fabbione: While it's bad to ship a kernel that's hard to support, it's worse to ship a kernel that doesn't actually work on useful hardware
<mjg59> BenC: I've just sent you pcmcia_hibernate.dpatch
<mjg59> BenC: This fixes hibernation when PCMCIA cards are physically present in the machine at hibernate time
<zul> fuck fuck..
<BenC> mjg59: cool, thanks
<mjg59> BenC: Another patch. Fixes reboot on HP laptops without affecting anyone else (I had one report of a desktop that didn't reboot with the reboot-thru-bios patch - this one should only hit affected machines)
<Mithrandir> : tfheen@rookery ~ > umask
<Mithrandir> 002
<Mithrandir> fabbione: it looks sane to me
<jbailey> BenC: Do you think it's safe to merge 10307 and 9115?
<mkrufky> jbailey: looks like it's safe to move the headers... i just worked it out with the dvb maintainer
<mkrufky> we should probably have them (officially) moved by 2.6.15
<jbailey> mkrufky: Cool.
<jbailey> mkrufky: If you have a list of what headers are moving where, I can take care of it in Breezy.
<fabbione> Mithrandir: well the commit you did locked the archive
<jbailey> mkrufky: No chance of sneaking it in for 2.6.14?  It's less invasive than the other crap that went in to -rc1
<mkrufky> those 5 .h files in /drivers/media/dvb/dvb-core
<jbailey> -rc2, rather
<fabbione> Mithrandir: remember tha scp/sftp needs umask very eary
<fabbione> early even
<mkrufky> jbailey: I dont wanna push Linus' buttons
<mkrufky> and... there are some out-of-tree dvb drivers that still depend on them to be in the current location
<jbailey> mkrufky: 'kay.  Where will they go?
<mkrufky> include/media/dvb
<jbailey> include/media?
<jbailey> A new subdir?
<mkrufky> checking.....
<jbailey> Maybe include/linux/media or somethin
<jbailey> mkrufky: Is there another channel I should join?
<mkrufky> nah, i took care of this over the linux-dvb mailing list
<jbailey> mkrufky: Right now there's stuff in /usr/include/linux/dvb
<mkrufky> but the applicable channel is #linuxtv
<jbailey> Well, I'm not in a rush to add windows 76 on my irssi. =)
<mkrufky> heh
<mkrufky> looks like ur're right... that directory doesnt exist
<mkrufky> i guess johannes wants to create the new directory
<fabbione> Mithrandir: i do set the umask from .bash_profile, because i think sftp doesn't load bashrc
<mkrufky> jbailey: apparantly this has already been the plan, i just kicked it with a little jumpstart, thanks to you
<mkrufky> hang on, i will show you the email thread
<jbailey> mkrufky: Tx.
<jbailey> If they're going under /usr/include/linux/dvb, I can do this no prob.
<jbailey> If he wants to create a new subdir, I need to wait for the flamewar, sadly.
<mkrufky> hmm
<mkrufky> would it cause any harm if u put them in include/linux/dvb ?
<mkrufky> i doubt it.
<jbailey> mkrufky: None at all. =)
<jbailey> mkrufky: 'cept that if nothing is going to look for them there...
<mkrufky> heh true
<jbailey> That's why I'd rather drop them into wherever they're going to wind up eventually.
<mkrufky> well, i wouldnt start up a flame war just yet
<mkrufky> http://linuxtv.org/pipermail/linux-dvb/2005-September/004861.html
<jbailey> But I imagine that there'll probably be some resistance to adding another directory to /usr/include from the kernel folks.
<jbailey> hmm
<mkrufky> ya maybe it makes sense to wait on it for now
<jbailey> Dude, I see the words "are considered half-private i.e. not for userspace"
<mkrufky> and tell your users to use the tree-merging scripts instead, as a temporary workaround
<mkrufky> yes..... thats the same as any other kernel headers
<mkrufky> but u see, those headers are needed for v4l compile , which is kernel space
<jbailey> Is it a kernel module?
<mkrufky> v4l is a set of kernel modules
<jbailey> Hmm.
<mkrufky> and so is dvb
<mkrufky> ivtv is NOT a kernel module
<jbailey> Are those going to just be integrated eventually?
<mkrufky> they are already integrated
<mkrufky> the only difference is:
<mkrufky> users find themselves updating their v4l / dvb drivers to take advantage of support for new hardware
<jbailey> Oh, hmm.
<mkrufky> you see, i just wrote all these drivers for new hardware that came out last year
<mkrufky> unfortunately, due to kernel release cycle, these drivers wont be available in a mainline kernel until 2.6.15
<fabbione> BenC: ping?
* jbailey reaches for his 'no sympathy' stick...
<jbailey> =P
<mkrufky> so many users want to play
<mkrufky> so they get cvs
<mkrufky> now do u see ?
<jbailey> I do.  It sounds very much like problem we can't solve.
<mkrufky> no
<mkrufky> it is easily solved
<mkrufky> the user gets newer drivers from cvs
<mkrufky> simple as that
<jbailey> benc, fabbione: What do we currently do for folks who want to compile their own out-of-tree kernel drivers?
<mkrufky> about the missing headers, until we standardize the final location, the tree-merging scripts will suppice as a temporary workaround
<mkrufky> s/suppice/suffice
<jbailey> Right.  But whatever mechanism we provide for other kernel modules to be built out-of-tree should also be available for these things.
<jbailey> That might provide some hints for an esaier solution than the tree-merging scripts.
<jbailey> The userspace headers that I provide in linux-kernel-headers have all of the #ifdef KERNEL bits ripped out of them.
<jbailey> They can't be used for compiling kernel modules at all.
<mjg59> BenC: Fix for 13382 just emailed to you
<mjg59> Uh, 13882
<fabbione> jbailey: we usually hand them a nice piece of RTFM :)
<mkrufky> heh
<fabbione> mjg59: re 13506...
<fabbione> ahci is a scsi module... 
<fabbione> why should it land in sata?
<mkrufky> the tree-merging scripts do more that just fix this header problem
<mkrufky> there are other (non-critical) dependencies that v4l has in dvb-kernel that is necessary fro hybrid analog/digital capture cards
<mkrufky> oh, wait... it all just clicked... 
<mjg59> fabbione: It's not a SCSI module. It's a sata one.
<mkrufky> jbailey: did you at first think that v4l was userspace?!?
<jbailey> mkrufky: Yes.  If I had known it was a kernel module, I would've asked Fabio the question earlier and not gone any further with it. =)
<mkrufky> aaah
<fabbione> mjg59: ok added.. but i have no way to ensure it's loaded before ata_piix
<mjg59> fabbione: Well, we'll have to work that out later
<mjg59> That can be handled in userspace
<fabbione> mjg59: yup
<fabbione> but there is no much time to do it
<fabbione> so i rather suggest we talk with Kamion
<jbailey> Do I smell more initramfs magic?
<mjg59> jbailey: Sadly so
<jbailey> Greeat.
<mjg59> jbailey: Actually, probably module-init-tools magic. But it'll need to go in initramfs.
<mjg59> jbailey: We just need a modprobe.d that attempts to load ahci before ata_piix
<jbailey> fabbione: Which which FM shall I tell them to read when I smack this bug report with it?
<jbailey> mjg59: 'attempts to'?
<mkrufky> jbailey: so, i take it, that now that you know the true story... that ubuntu will frown upon such cvs module updates?
<mjg59> jbailey: Well, it may fail
<jbailey> mjg59: So anyone with ata_piix will have a stale ahci lying around?
<mjg59> jbailey: It can always attempt to rmmod it afterwards :)
<jbailey> mkrufky: No idea.  It means that I'm not worried about it for the userspace headers. =)
<mjg59> Actually, I dunno if that would work
<mjg59> jbailey: It's better to have a stale ahci module than non-working systems, I think
<jbailey> mkrufky: That's why I'm asking Fabio which manual we send them to when they want to do their own modules?  Between that and the tree merging scripts, hopefully they'll sort it out.
<fabbione> jbailey: it's called README + Makefile + Kbuild
<fabbione> jbailey: seriously... modules that are done properly use kbuild
<fabbione> if they use kbuild users needs only the headers for their running kernel and the correct gcc
<mjg59> jbailey: There are 4 Intel bridges that will work with *one* of ata_piix or ahci
<mjg59> And have identical PCI IDs
<jbailey> fabbione: Which package is kbuild in?
<mjg59> Actually, that's probably not true. ata_piix will probably drive them most of the time
<jbailey> mjg59: 'kay.  Hmm.  Right now I'm just copying modprobe into the initramfs, and not the config files.
<mjg59> jbailey: Yeah. We'll work something out.
<jbailey> mjg59: Do y ou think I should also take all of /etc/modprobe.d ?
<mjg59> jbailey: Not sure. Scripts there may call stuff that you don't have.
<fabbione> jbailey: linux-headers.. it's kernel build system :)
<fabbione> jbailey: but once you install the headers for your specific kernel
<fabbione> you also automatically get the generic and kbuild
<mjg59> BenC: Have we got the Apple touchpad driver?
<mkrufky> jbailey: ah, gotcha
<mkrufky> jbailey: this is exactly why i will backport the newer v4l/dvb code for the dapper kernel... hopefully users wont need to mess with cvs if all the latest support is already included in ubuntu's kernel
<Mithrandir> fabbione: anyway, is it correct now?
<fabbione> Mithrandir: yes.. thanks
<fabbione> at least i could commit
<jbailey> mkrufky: Ah, cool.  I expect that it's quite late for getting an update into breezy with less than a month to ship.
<jbailey> mkrufky: I'll let you sort that out with BenC though.
<jbailey> mkrufky: I see that the kernel-headers-2.6.12-8 package does have an include/media directory
<jbailey> So this all makes sense now. =)
<jbailey> Getting the headers into there for Breezy is probably quite doable to keep everyone happy.  (Again, it needs to go to BenC)
<mkrufky> ah, cool
<mkrufky> it DOES have include/media
<mkrufky> but not include/media/dvb
<mkrufky> (that is where they will end up going)
<BenC> mjg59: don't think so
<mkrufky> fabbione told me that he welcomes updates like i've mentioned, but yes, it probably IS too late for breezy
<mkrufky> although if you guys are in fact interested, I can probably have a patch ready by tomorrow (or the next day)
<fabbione> BenC: i did commit fixes for 14736 and 13506
<fabbione> BenC: the former needs a full test build on ppc
<fabbione> the latter on all arches
<mjg59> BenC: Want me to find the diff for you?
<fabbione> or at least ppc, i386, amd64 and ia64
<BenC> fabbione: thanks
<BenC> mjg59: yes, please
<fabbione> BenC: no problem
<BenC> dpatch is really slow for taking in a lot of small patches
<jbailey> mjg59: Hey, did you ever make it possible for usplash to handle input text? =)
<mjg59> I didn't
<jbailey> I have a wishlist bug with a patch attached for encrypted root. =)
<mjg59> Haha.
<mjg59> Prefix it with usplash_write "QUIT"
<jbailey> Sweet, that'll do nicely. =)
<jbailey> usplash_write "FOAD"
<mjg59> BenC: Just sent you a patch to fix http://bugzilla.kernel.org/show_bug.cgi?id=3927
<mjg59> (Well, "fix")
<mjg59> BenC: I've sent you a patch for #7904 (apple trackpad driver)
#ubuntu-kernel 2006-09-18
<Philip5> fabbione: are you awake?
<desrt> BenC; i wonder if you'd take a totally crack patch to the kernel that no "real user" would ever use but would make developer's lives nicer?
<BenC> desrt: depends on how invasive it is
<desrt> BenC; very minimally
<BenC> I can review it if you email it to me
<desrt> BenC; it adds 5 fields to struct task_struct
<BenC> oooh
<desrt> BenC; and uses them to keep track of how many times poll/select/epoll/itimer/schedule_timeout timeouts fire
<desrt> BenC; then makes the info available in /proc
<neuralis> desrt: for future discussions of this type, just stick the patch up somewhere, http://pastie.caboo.se or something
<BenC> I've heard task_struct is very peculiar about it's size right now
<desrt> oh.  really?
<BenC> and that sort of tracking sounds like it has some overhead unless it's disabled by default
* desrt is running said patch right now and nothing too evil seems to be happening
<desrt> BenC; it's a ++ in the poll syscall
<BenC> desrt: if task_struct gets > PAGE_SIZE it wastes mem, and costs ticks
<desrt> ya.  task_struct is pretty big, too
<desrt> i'll find out.  hold a sec.
<BenC> email me your findings
<desrt> ok.
<BenC> redskins vs. dallas is about to start, and I can't miss that :)
<desrt> :)
<desrt> 1360 bytes with my patch on x86
* desrt emails :)
<neuralis> BenC: ping me when you get back from the game
<infinity> BenC_: Pong?
<pdr> anyone know why saa7146 driver was removed form the edgy kernel?  is there a problem with it?
<`ph8> no daily image yet boys and goyles?
<jbailey> BenC_: ping
<`ph8> idle 8 hours jbailey :)
<jbailey> ph8: That's a full night's sleep, he should wake up soon ;)
<`ph8> He's overslept in fact. He should wire his alarm clock up to the internet for situations like this. Too much sleep can be bad for you
<`ph8> :o)
<BenC_> jbailey: pong
<jbailey> BenC_: Heya.  I'm back in Canada now.  ISTR that there was a git tool to make doing a binary search for a particular change in the git tree easier.
<mjg59> jbailey: git bisect
<jbailey> BenC: 2.6.18 is working fine with sata_foo (I don't remember off hand which one), so I'd like to find the change that fixed and ask for it in edgy.
<jbailey> mjg59: Thanks.
<BenC> yep, that's the one
<BenC> the man page will make it easy to get started
<jbailey> Fabulous. =)
<mjg59> BenC: Any ETA on the edgy upload?
<BenC> this morning, I hope
<mjg59> Cool
<mjg59> Are you merging the stuff I sent, or is that for the next one?
<zul> BenC: do you want me to keep an eye on the dapper-proposed-updates tree?
<neuralis> BenC: what's our policy on updates to the dapper kernel? security-only? apparently all the newer hp servers ship with iLO2, which kills the dapper installer. description and patch here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=384202
<`ph8> BenC: what timezone are you in? ;)
<BenC> zul: if you want to, that'd be great
<BenC> ph8: EST -04
<BenC> neuralis: right now, security only for user visible updates, but patches are going into -proposed, and being migrated with security fixes after testing
<BenC> I wonder if we can get cd's built with the -proposed kernel
<zul> neuralis: ill see if i can get it included
<neuralis> zul: thanks; currently we're not installing on many hp servers, and that's not good
<`ph8> BenC: once the image is up would you mind mentioning it in here/ubuntu+1? If you want to throw in my nick as well that would be *really* useful. Hopefully I can transform my expensive paperweight into a machine with ubuntu on today! :)
<`ph8> i'll come and molest you when the patch doesn't work - sods law dictates it won't work first time
<BenC> $ git-cherry-pick 0d8fc83fd11b85e917269dce896740e0875c685c
<BenC> First trying simple merge strategy to cherry-pick.
<BenC> Finished one cherry-pick.
<BenC> nothing to commit
<BenC> neuralis: seems that patch is already in dapper
<neuralis> BenC: the hcs folks tried this yesterday, and the installation failed. ignore it for now; i'll verify with them.
<desrt> kernel dudes!!!
<desrt> the kernel is like the POPCORN of the movie theatre, really
<desrt> it is EXPENSIVE and if you eat too much you will be MONOLITHIC
<`ph8> i'd say it's more like the floor
<`ph8> or the structural supports for the roof
<desrt> where's the fun in rational metaphor?
<jbailey> Is there a way of mounting a partition more than once?  I thought I read at some point that Linux was growing that ability
<desrt> jbailey; -o bind
<jbailey> desrt: Thanks
<desrt> use the first mountpoint as the 'device'
<`ph8> isn't it a similie desrt ? :)
<jbailey> Oh.  See, the problem is that I've lost the original mount point. =)
<desrt> ph8; similies are metaphors with 'like' or 'as'
<`ph8> lol
<desrt> you might be screwed, then :)
<jbailey> I move mounted something onto /, and forgot to get my HD partition out of it first. =)
<Mithrandir> jbailey: see if you can move-mount / out of the way to get the old one back?
<desrt> Mithrandir; that would involve mounting / inside of itself
<zul> Mithrandir: have you sent me your nvidia stuff yet?
<Mithrandir> zul: no, I'm a slacker.
<zul> ok...good to know that there are more of us out there
<`ph8> heh
<Mithrandir> I need to push some of my local changes to the tree too.
<Mithrandir> zul: for auto-update-initramfs we need to patch kernel-package.
<zul> Mithrandir: thats what i thought ;)
<Mithrandir> it's probably easy enough; make /usr/share/kernel-package/pkg/virtual/xen/postinst a symlink to /usr/share/kernel-package/pkg/image/postinst (and similar for the other pre/post scripts)
<Mithrandir> I haven't tested that, though, so we might want to test it properly first.
<`ph8> ah zul, i meant to ask - with the fix for jmicron chipsets/IDE, were you aware of issues detecting SATA ports as well? Because once i'd got around the IDE problems that's the wall I hit..
<zul> no i wasnt
<`ph8> do you think the fix will cover that as well?
<`ph8> or was it very specifically ide
<zul> probably not in this upload
<`ph8> we'll see :o(
<`ph8> i'm going to have to use fedora if it doesn't work in this upload
<`ph8> that's how horribly horribly twisted the situation has become
<`ph8> zul: did you mean the fix won't be in this upload back then? or just that sata may not be covered?
<Nafallo> BenC: I just noticed the new kernel doesn't close bug #58117, is this an error in the changelog or did you forget it?
<zul> ph8: well have to see
<BenC> Nafallo: just didn't make it into this upload
<Nafallo> oki. but the plan is still to have it in edgy?
<`ph8> latest changelog's out?
<`ph8> oh no, old one
<Nafallo> `ph8: edgy-changes
<`ph8> you can all go about your business :)
<zul> right im off for the ultrasound
<infinity> BenC: *poke*
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel GIT tree info (updated): https://wiki.ubuntu.com/KernelGitGuide | 2.6.17-8.21 uploaded, "These are not the ACPI patches you are looking for...wait, maybe they are
<BenC> crappy xchat topic editor
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel GIT tree info (updated): https://wiki.ubuntu.com/KernelGitGuide | 2.6.17-8.21 uploaded, "These are not the ACPI patches you are looking for...wait, maybe they are | Daily kernel builds (for debug and testing purposes only) http://people.ubuntu.com/~bcollins/kernels-daily/ | Kernel Wiki: https://wiki.ubuntu.com/CategoryKernel
<mjg59> BenC: So this is just the ACPI stuff, not the more recent stuff I sent you?
<BenC> yeah, minus the stuff you sent me in the past day or so
<BenC> fans and "more acpi crack" are not in there, but will be in a few days
<mjg59> BenC: So you didn't add the patch you accidently dropped?
<mjg59> Ah. That has the downside of meaning that fans won't work on HP laptops.
<BenC> I can do another upload real quick
<BenC> there is no lrm or linux-meta yet
<mjg59> The 0003 one that I resent (or was it 0004? Anyway) is the important one, though the other fan ones would also be helpful
<mjg59> Sorry, I should have pointed that out
<infinity> BenC: Can I get you to mangle debian/control in the dapper branch so I don't have to do manual archive overrides on the next ABI bump?
<infinity> BenC: We always send ufs-modules-* to universe in dapper.
<BenC> infinity: -security or -proposed?
<infinity> BenC: Yes? :)  Just in your git branch for the next upload(s).
<infinity> BenC: Just got reminded of this when I did queue/new processing for the latest dapper security update.
<BenC> ufs-modules package stuff is done by kernel-wedge
<mjg59> Is the ti acx firmware in l-r-m?
<infinity> BenC: And that can't easily be mangled?  If not, nevermind.
<BenC> mjg59: yeah
<mjg59> BenC: Ah, ok
<mjg59> BenC: Have we mangled it so a more useful version is the default for PCI chipsets?
<BenC> infinity: I think I can override it. I'll give it a shot
<BenC> mjg59: not yet, let me do that for the edgy lrm upload
<mjg59> (Amusingly, I lost my acx card about a day after getting it. I think it may be under my bed somewhere)
<mjg59> BenC: Ok, cool
<BenC> mjg59: I don't see anything about a missing patch, I have "more acpi crack" tarball, and the fan stuff
<mjg59> BenC: I mentioned on IRC that you'd applied all the patches from the previous tarball except one, and then resent that with the fan stuff
<mjg59> (I believe)
<BenC> can you check current git to see if I got it, because I don't see it in my inbox
<mjg59> BenC: It was called 0003-Fix-fan-control-on-HP-hardware.txt and was originally in the pm-fixes.tar.gz tarball
<BenC> "The fan on/off code is currently a touch flaky. This patch from kernel 
<BenC> bugzilla 7122 improves that.
<BenC> "
<BenC> that it?
<mjg59> No
<mjg59> Hm.
<mjg59> It's possible that I accidently failed to resend it.
<BenC> I probably don't have it then
<mjg59> You applied all the other patches from that tarball
<BenC> weird that I missed it, I used git-applymbox to apply them all
<mjg59> Well, checking the tree it's certainly not there
<BenC> if you can resend it, I'll add it now and reupload
<mjg59> Ok
<BenC> infinity: Oh, that reminds me, I need to ask about my grand scheme to make sure things aren't going to break
<BenC> infinity: If I have 2.6.15-50 in dapper-proposed, and 2.6.15-27 in dapper-security, the next upload to -security (which will likely be -27 still) wont be rejected because it is older than the -50 in -proposed, right?
<mjg59> BenC: I'll send you the stuff I have outstanding now
<BenC> ok
<mjg59> Ok, done
<BenC> mjg59: Weird, I remember that patch
<BenC> applied now
<mjg59> BenC: Thanks
<mjg59> BenC: Just that one, or the others as well?
<BenC> all of them, I had the others already
<mjg59> Ok, cool
<mjg59> Thanks!
<dantolini> hi everybody
<dantolini> sb present?
<dantolini> i'm looking for someone who has experience withe the problem that you get the error message: "access beyond end of device"
<BenC> sounds like your filesystem is reporting that it is bigger than the device that it's one
<BenC> is this on a CD?
<dantolini> exactly
<dantolini> file system
<BenC> or maybe a USB drive?
<dantolini> ext3 partition (root file system, unluckily)
<mjg59> dantolini: What hardware?
<dantolini> i did a little research, but i have no idea where this problem comes from
<BenC> how was the fs created?
<dantolini> it's a hard drive
<dantolini> fs = fstab?
<mjg59> dantolini: On what hardware?
<dantolini> mjg59, you wanna know the producer`of the hard drive?
<mjg59> dantolini: No, I want to know what it's plugged into
<dantolini> well, i don't understand very well.. but i have 2 hard drives on one IDE-cable...
<dantolini> ?
<BenC> ide chipset, scsi chipset, usb, firewire, what?
<dantolini> its IDE
<BenC> lspci | grep -i IDE
<dantolini> what's that for?
<BenC> what do you get from that?
<dantolini> (currently i booted with windows, since it's not possible with ubuntu)
<BenC> run that command so we can see what IDE controller you have
<dantolini> ah, can i get this information in windows as well?
<BenC> dantolini: what version of ubuntu did you install, and how did the install process create the filesystem?
<BenC> probably, but don't ask me how, because I can't remember
<`ph8> BenC: Do you happen to know if the daily is on its way old bean?
<`ph8> (NB: I have no confirmed sources for implying that you are old, or a bean)
<BenC> e.g. did you use automatic filesystem creation where it did everything itself, or did you use existing partitions, or create your own partitions?
<dantolini> first insalled ubuntu 5.0x, then upgraded a few month ago... and a few days ago i got this error message while booting up (in the recovery mode, in normal mode, it just hangs itself)
<BenC> ph8: read topic
<dantolini> upgraded to 6.06
<BenC> I just uploaded edgy kernel
<dantolini> the file system was created automatically..
<`ph8> ah. cool - will that work into an install-cd image release today?
<`ph8> or can i update my install cd somehow?
<dantolini> after i created partitions for it....
<BenC> dantolini: what changed when the problem started occuring? Some security update, nothing?
<dantolini> i have : Standard-IDE-ATA/ATAPI-Controller
<BenC> so when you say "upgraded" you really you freshly installed dapper 6.06?
<BenC> windows isn't descriptive enough
<dantolini> well, i was in holidays for a month, and i had to do a major update (all of august)... but, i don't think that the problem occurred directly whilst the next bootup
<dantolini> no, i made an upgrade from the last version to the actual ubuntu..as described somewhere on ubuntu.com
<BenC> it's very hard to follow what happened
<dantolini> yeah, i think...
<dantolini> so:
<dantolini> installed ubuntu 5.10 with dvd
<dantolini> then upgraded directly to 6.06 lts without cd...internet connection
<BenC> if you made an upgrade, then how did you "create partitions"?
<BenC> upgrades don't involve creating new partitions
<dantolini> then problem, after upgrades of all august
<dantolini> sorry, updates of august
<dantolini> the partitions were already created..
<dantolini> so i guess this "access beyond end of device" problem has not a very specific source...
<BenC> at what point did the problem start occuring?
<dantolini> i did an fsck.ext3 of the partition if the results of that helped..
<dantolini> well, for me it was a little out of the blue.. thats why i am so clueless
<dantolini> i'd say after the update session a few days ago
<BenC> no, what I need to know is two things...1) What IDE chipset you have (get this from the lspci output, boot from the CD if you have to), and 2) What event during your install/upgrade happened right before you started having problems
<dantolini> ok.. that will take a while..
<BenC> do you have an older kernel that you can boot from?
<dantolini> nah, just live dvd
<dantolini> all the kernels have the same problem
<BenC> unless you removed kernels, then grub should have an older kernel in the menu on boot
<dantolini> grub lists me at least 8-10 kernels..., but i'm going to do it with the live cd...
<BenC> then you need to tell me what kernels you have installed (versions listed in grub will work)
<BenC> if all the kernels have the problem, then this isn't something new, it just took awhile for it to appear (maybe something is finally being written to the problem area)
<BenC> dantolini: No, I need to know if any of the older kernels work
<BenC> this is very important
<dantolini> i've already tried
<dantolini> not a single works..
<BenC> no need to try the rescue options, just  the main kernels
<BenC> so they all failed?
<dantolini> yep
<BenC> then this isn't a new problem, it's existed on your machine since it was installed
<BenC> you started off with a 5.0x install?
<dantolini> yep
<dantolini> i think 5.10
<dantolini> yes, exactly 5.10
<BenC> I'd say your best bet is to use the livecd to mount your drive, copy off any data you need, and do a fresh install
<dantolini> but that was more than six months ago
<BenC> I don't know if there's any way to recover (easily) from a filesystem problem like that
<dantolini> mhm, i kinda tought that.. :)
<`ph8> BenC: There doesn't appear to be an entry for today at bcollins/kernels-daily/. Also, would you mind giving me a yes/no as to whether this will make it into a new 'daily' (although there hasn't been one for days) install-cd image?
<BenC> ph8: I uploaded it to edgy, not kernels-daily
<BenC> ph8: I don't handle cd images, so I wouldn' t know
<`ph8> ah.
<dantolini> and in your opinion there is no chance that this could be a BIOS problem?
<`ph8> do you not know how long it usually takes your kernel to get into them or anything?
<BenC> dantolini: what makes you think that?
<BenC> ph8: No idea
<`ph8> :o( cheerse then
<`ph8> i wish i could type :/
<`ph8> i'm going to have to go to fedora at this rate
<BenC> dantolini: is there something you are not telling me about your setup? :)
<dantolini> because, i read about a 1000 different things of people who had this problem... and one said to another that sometimes if the battery gets weak, settings of partitions could be deleted
<BenC> dantolini: you could always redo your BIOS settings to see
<dantolini> BenC, well, i have read a lotta things, but i wanted to know what an "expert" thinks unindependently
<dantolini> if i redo my BIOS settings such parameters would be recovered?
<BenC> ph8: there's more to this kernel than just the JMicron patches, there'a hundreds of other patches that need adding and testing
<dantolini> unluckily i have no idea of bios
<BenC> ph8: Not to mention that the cd builds are dependent on thousands of packages besides the kernel, any of which could hold it back from creating a working image
<BenC> ph8: Have some patience, we are not all here to serve your one patch for your one server
<BenC> dantolini: I can't help you there
<dantolini> ok..
<dantolini> i just also like to know what kink of information you expect from the lspci
<dantolini> i mean, whats to know about the ide?
<BenC> ~$ lspci | grep -i IDE
<BenC> 00:1f.2 IDE interface: Intel Corporation Enterprise Southbridge SATA IDE (rev 09)
<BenC> the exact chipset that you are using
<BenC> different ones use different drivers
<dantolini> Silicon Integrated System
<dantolini> ?
<BenC> narrowing down which driver helps us understand what the problem might be
<BenC> there are at least 2 drivers for SiS, I believe
<BenC> so more info is needed
<dantolini> ok :)
<`ph8> BenC: It's been widely documented for a long while now, there's at least three forum threads like this one -> http://www.ubuntuforums.org/showthread.php?t=258010&page=2 - it's not purely selfish. This is something that's already working on things like redhat, obviously it works with windows because they must have thrown money at it at some point.
<`ph8> I don't think it's especially selfish
<`ph8> I've spoken to quite a few people sitting next to expensive paperweights
<dantolini> so i'll boot from the live dvd now. you'll be here for another 20 mins?
<BenC> Reported on:
<BenC> 2006-08-23 
<BenC> that's not that long
<dantolini> don't underestimate me ! :D
<dantolini> a plus
<BenC> dantolini: ok
<`ph8> considering the fix was already in the kernel.org kernel..?
<`ph8> well, if you say so
<`ph8> i imagine it takes a while to backport things like that
<BenC> ph8: the patch is in the kernel git, and the tarballs are uploaded, it's now a matter of hours before you can use it
<BenC> so lighten up
<`ph8> well if i knew that i wouldn't be bothered
<`ph8> !!
<`ph8> when you say use it?
<`ph8> you mean a cd image will be available?
<BenC> I told you that it was uploaded
<`ph8> or i'll have to do some jiggery pokery replacing my install cd kernel?
<BenC> no, the kernel .deb's
<BenC> I have no idea when the CD's will be ready
<`ph8> can i replace my install cd kernel with your image do you know?
<`ph8> with your kernel do you know even
<BenC> no idea, I've never messed with install cd's
<`ph8> ok
<BenC> other than booting them
<`ph8> If you fancy using your ubuntu team member status toi find the person who makes the install cds...
<`ph8> fancy asking them what happened to dailies? :)
<BenC> ask in #ubuntu-devel
<Mithrandir> we build daily installation CD daily.
<BenC> someone there will know
<Mithrandir> I just forgot to turn the cronjobs on this morning, but they're there now.
<`ph8> lo Mithrandir 
<`ph8> not @ http://cdimage.ubuntu.com/daily/ ?
<Mithrandir> yes
<Mithrandir> that is, there probably aren't any for today built
<Mithrandir> since the cronjobs were off this morning
<`ph8> i see
<`ph8> so there will be one built tomorrow?
<`ph8> (or can you build one for today? ;))
<Mithrandir> they'll be built tomorrow morning; I can build one for today, but if the kernel with the stuff you want haven't hit the archive yet it'll be more or less equivalent with the just-release knot-3
<`ph8> i see, and the archive is what Ben just referred to as what it will reach in a few hours?
<Mithrandir> yes
<`ph8> right, i'll sit and wait for it tomorrow then i guess :o)
<`ph8> will get it installed eventually!
<`ph8> thx
<`ph8> i'll post on the forums so the others know
<dantolini> BenC, 0000:00:02.5 IDE interface: Silicon Integrated Systems [SiS]  5513 [IDE] 
<dantolini> does that help? :)
<dantolini> hullo??
<dantolini> well, BenC if you have an idea, contact me stupid_homer [at]  gmx [dot]  net
<dantolini> thanks anyway
<Mithrandir> zul: is there any reason why you make -amd64-generic rather than just -generic for amd64 too?
* gnomefreak cant find 686 kernel anymore? was it renamed or removed?
<Mithrandir> renamed to -generic
<gnomefreak> ok ty
<Mithrandir> BenC: 2.6.17-8.21 ftbfs
<BenC> yeah, working on it now
<BenC> Mithrandir: it is -generic on amd64
<Mithrandir> that broke all the others too?
<BenC> -amd64-k8 and -amd64-xeon are gone
<BenC> there is only -generic for amd64 now
<BenC> and -server
<fractalmind> Can anyone here help me get Edgy to boot my custom AKPM kernel?  I test Andrew Morton's unstable kernel tree, and since upgrading to Edgy, I find that my custom kernels won't boot.  This seems to be due to Edgy's GRUB support of UUID.  My custom kernel can't open the root device.
<fractalmind> Also, when I try to make an initrd, I am getting an error.  I am running "mkinitrd -o initrd.img 2.6.18-rc6-mm2" and get back "/usr/sbin/mkinitrd: 253:0: Cannot find LVM device."
<fractalmind> I am not using an LVM device or RAID.  
<Mithrandir> you might want to run mkinitramfs instead.
<Mithrandir> zul: you broke the amd64 builds. :-P
<fractalmind> Mithrandir: Would not having an initrd have something to do with root=<UUID> not working?  I have all the requisite drivers built into the monolithic vmlinuz for it to access the boot partition.   
<Mithrandir> fractalmind: you need udev there too, to make the by-uuid symlinks
<fractalmind> Mithrandir: In the kernel?  I already have Edgy's udev installed, and the Ubuntu Edgy kernel boots fine.
<Mithrandir> fractalmind: in the initramfs.
<fractalmind> Mithrandir: Is there an Ubuntu HOWTO that explains putting together the necessary bits in the initramfs?
<fractalmind> Mithrandir: I'll google for it.
<mjg59> fractalmind: mkinitramfs
<mjg59> Seriously. Our boot system heavily depends on doing it that way
<fractalmind> mjg59: I just built one for my custom kernel "mkinitramfs -o initrd.img 2.6.18-rc6-mm2".  
<makx> fractalmind: check out initramfs-tools manpage fore details
<fractalmind> mjg59: I'll copy the resulting initrd.img to initrd.img-2.6.18-rc6-mm2 and make the necessary changes to GRUB's menu.lst.  I'll go read up on whether I need to do more to get the udev stuff in the initrd.img file.
<fractalmind> makx: thx
<mjg59> fractalmind: The udev stuff is copied in automatically
<fractalmind> mjg59: Cool.  Yeah, I am reading the manpage about it now.
<makx> mjg59: latest usplash bar jumps back and forth for me on debian
<mjg59> makx: "jumps back and forth"?
<makx> you call usplash_write from gdm or?
<mjg59> No...
<makx> debian/usplash.init has in the stop target usplash_write "TIMEOUT 15"
<mjg59> The stop target doesn't stop usplash
<mjg59> It's, uh, counterintuitive
<makx> i know they are inverted :)
<mjg59> Anyway, I didn't write that stuff
<makx> but when i shutdown the stop gets invoked
<mjg59> Oh, it's supposed to be launched by gdm
<mjg59> On shutdown
<makx> yes in debian i tried to workaround with "usplash -c &"
<makx> but since latest that doesn't make usplash happy
<mjg59> Scott's probably a better person to ask
<makx> ok
<makx> progressbar makes funny jumps :)
<zul> Mithrandir: ill unbreak it tonight
<Mithrandir> zul: I'll probably beat you to it, since I have something which works locally.
<Mithrandir> (and almost works for lrm)
<zul> sweet...commit it to git and send me the crack :)
<ajmitch> good, zul has users clamouring for packages :)
<mjg59> zul: Looks like i386 is b0rked too
<ajmitch> seent hat bug that xen-ioemu-3.0 is empty?
<zul> i just got back from the ultra sound so no
<zul> grr...ill take a look at it
<mjg59> zul: linux-source-2.6.17, that is (re: my comment)
<mjg59> The asus_acpi code is malformatted in some way
<zul> gah...cant get a break can i?
<zul> im just catching up
<zul> mjg59: i dont see your asus_acpi code comment
<mjg59> zul: The i386 build being broken
<kinema> what meta package should be installed on a 686 smp box (quad ppro) when running edgy?
<kinema> are the linux-generic compiled for SMP?
<Mithrandir> zul: dpkg-deb: Bygger pakken xen-restricted-modules-2.6.16-11.2-generic i ../xen-restricted-modules-2.6.16-11.2-generic_2.6.16-1_amd64.deb.
<zul> mjg59: looks like it fixed it git
<mjg59> Ah, yes
<zul> kinema: generic
<ajmitch> Mithrandir: great, I can drop vmware now :)
<ajmitch> mjg59: do you remember when the last big batch of ACPI updates landed in the ubuntu kernels? was it for dapper?
<ajmitch> I just noticed that I have no decent ACPI info on the 2.6.16 xen kernel
<mjg59> ajmitch: There was a set for dapper, and there's a set for edgy
<mjg59> I have no idea what the interaction between xen and acpi status reporting is
<Mithrandir> making sure something actually ends up in the deb == good
<kinema> zul: I checked and I am running linux-image-2.6.17-7-generic via the linux-generic meta-package but when I look at /proc/cpuinfo I only see a single cpu when i should see four.  are you sure that the generic kernel packages are smp capable?
<kinema> Linux lorax 2.6.17-7-386 #2 Wed Sep 6 17:53:03 UTC 2006 i686 GNU/Linux
<mjg59>  Linux lorax 2.6.17-7-386
<mjg59> No, that's not the generic kernel
<kinema> hmmm...
<kinema> the only image package dpkg is listing as installed is linux-image-2.6.17-7-generic 
* mjg59 shrugs
<crimsun> Linux garnish 2.6.17-7-generic #2 SMP Wed Sep 6 17:56:40 UTC 2006 i686 GNU/Linux
<crimsun> that's what generic reports, and it is SMP-aware
<kinema> maybe not.....
<mjg59> If you were running 2.6.17-7-generic, it'd say 2.6.17-7-generic
<mjg59> So something's gone wrong somewhere
<kinema> linux-image-2.6.17-7-386 is installed as well...  it's been selected for removal but it's currently being used.
<kinema> how do i tell grub to boot the other kernel?  i don't have physical access to the box right now so i can't select it when i reboot.
<Mithrandir> zul: you might want to pull from http://git.err.no/xen-ubuntu-2.6.16-tfheen/ and use that as a basis; I can't be bothered to find my laptop with ssh key on it.
<Mithrandir> zul: as well as http://err.no/tmp/xen-restricted-modules-2.6.16-2.6.16.1.tar.gz which is just where I am.  ETA ~1 hour or so.
<zul> mdz: looking now
<zul> oops...sorry Mithrandir looking now i meant
#ubuntu-kernel 2006-09-19
<eyequeue> is there a quick synopsis (or page) about what -generic -server and -server-bigiron mean in edgy?
<eyequeue> o
<eyequeue> m guessing this will be a faq, so i'd like to have a page to send people to
<eyequeue> (will create a factoid, if not)
<crimsun> https://lists.ubuntu.com/archives/ubuntu-devel/2006-August/019983.html and https://lists.ubuntu.com/archives/ubuntu-devel/2006-August/020807.html
<crimsun> the latter directly addresses your question; the former is nice for context
<eyequeue> crimsun, thanks, i figure i'm not the only one that wonders :)
<gnomefreak> eyequeue: the -i386 is still an edgy kernel
<eyequeue> yes
<gnomefreak> eyequeue: your factoid said they changed to -generic
<eyequeue> perhaps i need to add that, but dpn't have access
<gnomefreak> eyequeue: try to add it and i will add it
<eyequeue> feel free to edit if you do
<zul> hi mdz 
<mdz> hi
<desrt> BenC_; 'sup
<infinity> BenC: About to NEW the new kernels for you, do you have an LRM and -meta lined up?
<BenC> yep, getting them ready now
<infinity> Spiff.
* infinity waits for the i386 build to finish..
<infinity> There, done.
<infinity> BenC: Accepted.  If you get LRM up before :03, you get a prize. :)
<BenC> lrm is uploaded
<BenC> now where's my prize :)
* infinity hands you a direct line to Kamion to process it through queue/new.
<infinity> That'd be your prize. :)
* infinity is heading off to bed now.
<ajmitch> lucky kamion is tied up in a CC meeting :)
<infinity> Actually, I may still be around in the hour or so when all the binaries show up.
<infinity> We'll see.
<zul> ajmitch whats the bug number for the ioemu stuff again?
<ajmitch> bug 61121
<zul> thanks...uploading now
<ajmitch> does it still have -- in the package name?
<ajmitch> just a minor thing :)
<zul> nope...i386 and amd64 packages are the same now
<ajmitch> ok, great
<ajmitch> how'd you go with the headers?
<ajmitch> just starting for the day?
<zul> yeah im just starting fot the day
<mjg59> infinity: Oh, hey, bug appeared about madwifi suddenly supporting less hardware
<zul> BenC: : ping
<zul> is there support for qla2300 hba cards?
<BenC> zul: I think so
<zul> well ill guess ill go find out
<BenC> infinity: l-m uploaded now too
<fabbione> we do have the driver
<zul> ssweet
<infinity> mjg59: Is it wrong of my to admit how deeply I don't care?
<infinity> mjg59: (Is it just missing PCI IDs, or fundamental incompatibilities with the new hal?)
<mjg59> infinity: hal breakage
<infinity> s/my to/me to/
<infinity> hal breakage.  Suck.
<mjg59> It's almost like we're dealing with some sort of incompetence
<infinity> I guess we get to A) whine upstream, and B) tell people to not use hardware with binary-only drivers. :/
<infinity> We could roll a hacked up madwifi-old for the older cards, but that idea makes me cry many moons.
<mjg59> Oh, hang on, it's about dapper
<thom> wouldn't crying a _single_ moon be rather painful?
<mjg59> https://launchpad.net/distros/ubuntu/+source/linux-restricted-modules-2.6.15/+bug/60860
<thom> multiple ones just seems masochastic
<thom> masochistic even
<mjg59> No, wait, that's not the bug I'm thinking of
<infinity> Clearly not.
<mjg59> Nngh.
<infinity> That's just straight up linkage breakage (and I assume, no longer an issue, or we'd have a mess of duplicates)
<mjg59> I'm getting vast numbers of launchpad mail nowadays
<infinity> You can't possibly get as much as I do.
<mjg59> You're paid
<infinity> I've turned ignoring LP mail into an art form.
<ajmitch> you receive every build log & upload?
<infinity> Don't get all the logs yet, but I will when that patch lands.
<infinity> I just happen to also get bug mail for about half the distribution.
* infinity heads to the store for some meat and cheese for a midnight snack.
<mjg59> infinity: https://launchpad.net/bugs/27604
<mjg59> No idea what's going on there
<zul> whoot...new file server is going to be ubuntu
<infinity> mjg59: Fun.  At least that's new hardware, and not "we accidentally dropped support for old hardware", which is what I thought you meant.
<mjg59> infinity: Well, doesn't it claim that it used to work?
<Petaris> ajmitch: I don't suppose yoru awake ATM?
<Petaris> er, your
<infinity> mjg59: Yeah, but it also claims it stopped working without a reboot, which is pretty sketchy.
<doko_> BenC: the names/descriptions for the kernel packages are confusing: -i386 -> "Supports alternate x86 (486 and better)", generic -> "Supports generic processors"
<BenC> doko_: I'll try to clean that up some
<ernstp> is usplash supposed to work on amd64? with edgy?
<HiddenWolf> Hey guys.
<HiddenWolf> BenC: around?
<HiddenWolf> I've got a possible bug wrt acpi/cardbus cards, and I need some help figuring out how to file a good bug.
<BenC> HiddenWolf: yeah
<BenC> is this in edgy?
<HiddenWolf> BenC: yeah
<HiddenWolf> BenC: I recently took an old laptop and put dapper on it. Internet over a cardbus pmcia ethernet card. Worked flawlessly. After a dist-upgrade to dapper this broke.
<HiddenWolf> to edgy
<BenC> try 2.6.17-8 before filing a bug
<BenC> what driver was it using?
<HiddenWolf> On dapper I have no clue. 
<HiddenWolf> on edgy all I get is:
<HiddenWolf>  Sep 19 22:21:12 ubuntu kernel: [  123.452379]  pccard: card ejected from slot 1
<HiddenWolf>  Sep 19 22:21:44 ubuntu kernel: [  156.219006]  pccard: CardBus card inserted into slot 1
<HiddenWolf> BenC: is 2.6.17-8 on a daily, or will I have to wait?
<BenC> should show up in the archive any time now
<gnomefreak> HiddenWolf: it should hit repos shortly
<BenC> already uploaded and built
<gnomefreak> just got the pre packages
<HiddenWolf> ah.
<HiddenWolf> I'll burn tomorrow's daily then. I don't feel like shuttling kernel debs on a usb-stick. ^-^
<Mithrandir> zul: did you get to hack on the amd64 problems yesterday?
<zul> Mithrandir: no i was trying to fix the xen-ioemu bug report, i have access to an amd64 box now so i will do it tonight
<Mithrandir> ok
<HiddenWolf> BenC: same problem with -8
<mjg59> HiddenWolf: Please do lspci before and after inserting the card
<BenC> HiddenWolf: Please file a bug report with lspci (with card inserted), and dmesg, and tag the bug edgy-regression
<BenC> yeah, before and after would be helpful
<HiddenWolf> at least one bug was fixed by -8 tho
<HiddenWolf> I can now force acpi
<gnomefreak> HiddenWolf: you installed -8 from upgrades?
<HiddenWolf> gnomefreak: I put the deb on a usbstick and dpkg -i did the trick
<gnomefreak> ah
<HiddenWolf> BenC: mjg59: https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/61291
<HiddenWolf> if there is anything else you need I'm happy to provide it, else I'll toss in a dapper xubuntu disk and be done with it.
<BenC> I'll check on it when I get that far in my bug list :)
<BenC> I'll let you know, thanks
<Nafallo> BenC: rt61 still broken, just updated the bugreport :-)
<HiddenWolf> BenC: no problem, I'd be happy to help.
<Nafallo> rt61pci even
<BenC> Nafallo: still broken because the package isn't uploaded yet
<BenC> I just put it into git
<mjg59> HiddenWolf: That's a dmesg without having inserted the card, right?
<Nafallo> BenC: oh? There is another coming? :-)
<Nafallo> hehe, I thought it was this one that I just rebooted to :-P
<HiddenWolf> mjg59: seems like it.
<BenC> no, not yet
<Nafallo> BenC: if you have a daily kernel or something I would be happy to try it out.
<BenC> Nafallo: none built right now, but I'll get one up tonight
<Nafallo> BenC: nice. could you add that to the bug-report when it's available?
<Nafallo> (the url)
<HiddenWolf> mjg59: putting up a dmesg with card inserted now
<HiddenWolf> there
<zul> less mmc.c
<BenC> Nafallo: it's in the topic
<mjg59> HiddenWolf: It appears to be identical
<mjg59> Oh, no, sorry
<HiddenWolf> :)
<HiddenWolf> ifconfig shows lo only, pppoeconf offers to run modconf instead of picking it up.
<mjg59> What sort of card is it?
<HiddenWolf> ethernet
<mjg59> Yes, what sort?
<mjg59> Make/model
<HiddenWolf> It's in one of the comments
<HiddenWolf> unex corp MD010C
<mjg59> And it's cardbus rather than pcmcia?
<HiddenWolf> I wouldn't know the difference, honestly.
<HiddenWolf> It says cardbus on it, so yeah
<mjg59> When it's in, what does pccardctl status print?
<HiddenWolf> of course he asks that just after I shut it down. One moment. =)
<HiddenWolf> socket 0; no card, socket 1; no card
<HiddenWolf> ah, wait
<HiddenWolf> after inserting it again, socket 1: 3.3V 32-bit PC Card
<mjg59> And lspci now?
<HiddenWolf> no difference
<mjg59> And nothing else in dmesg?
<HiddenWolf> dmesg: http://paste.ubuntu-nl.org/24024
<HiddenWolf> lscpi: http://paste.ubuntu-nl.org/24025
<HiddenWolf> mjg59: ^^
<HiddenWolf> That's with the card picked up (as per /var/log/kern.log and pccardctl)
<zul> right im heading home..
<BenC> zul: later
<mjg59> BenC: #53910 - it gets taken care of on amd64, it doesn't get taken care of on x86
#ubuntu-kernel 2006-09-20
<infinity> BenC: ABI bumps in linux-meta work a lot better if you remember to edit debian/rules. :P
<BenC> infinity: oops, guess I need to make a damn checklist
<infinity> BenC: No big deal.  Uploaded to fix it already.
<infinity> BenC: I just enjoy a good public shaming. :)
<BenC> infinity: is that listed in your resume under "Extracuricular activity"? :)
<infinity> Should be. :)
<zul> ooh...i get alot of those
<mjg59> BenC: I've just stuck a fix #53910
<BenC> mjg59: done
<BenC> did it in dapper too
<mjg59> Thanks
<BenC> thank you
<Bryce> Anyone around?
<fabbione> BenC: i got all our gfs2 patches upstream modulo the 2 required to run on .17. i will have something to push to you for when you wake up
<infinity> He's awake. :)
<AnAnt> ping BenC
<AnAnt> BenC: does Knot-3 include the TI MMC driver ?
<fabbione> infinity: but i am not ready to push yet :)
<ant1> ping BenC 
<AnAnt> BenC: I just upgraded the kernel
<AnAnt> BenC: my laptop (it has a TI card reader) did detect that something got in the card slot at last
<AnAnt> BenC: but it did not create a suitable device for it in /dev/  (it was an MMC btw)
<tonfa> gug
<tonfa> I was usually using gentoo and testing -mm kernel, now I have ubuntu on my work laptop and I'd like to continue testing -mm
<tonfa> is there a preferred way to do that ?
<tonfa> (and tell if that is offtopic)
<pina> messing with drivers will have one learning how to mess w/ the kernel build system pretty sharpish
<pina> note to self
<AnAnt> ping BenC 
<mjg59> AnAnt: Load tifm_sd
<AnAnt> mjg59: ok 
<pina> suse it's the only one which works with kerberos/ldap out of the box?
<pina> doesnt ubuntu?
<AnAnt> btw, the splash doesn't work here
<AnAnt> it did work from the Knot-3 Live CD
<makx> what are your bootargs cat /proc/cmdline ?
<AnAnt> well, I am using dapper now, shall I read the args from the grub file ?
<AnAnt> makx: kernel          /boot/vmlinuz-2.6.17-8-386 root=/dev/hda5 ro quiet splash vga=0x314
<pina> makx any hints on what i asked
<makx> pina ldap is not on topic here, but it works nicely here (although using Debian)
<pina> weird 
<AnAnt> makx: ?
<AnAnt> makx: ok, I'll reboot in Edgy now
<AnAnt> later
<pina> thanks makx
<pina> makx out of the box right?
<pina> tried with ubuntu does not work quite that well
<pina> oh wel
<pina> always thought only suse had it working out of the box
<AnAnt> makx: root=/dev/hda5 ro quiet splash vga=0x314
<AnAnt> makx: so what you think the problem is ?
<AnAnt> makx: I get an error that there is no theme for 640x480
<infinity> AnAnt: It's a known bug that edgy's usplash doesn't currently work with vga=
<AnAnt> infinity: I tried without vga= too
<AnAnt> infinity: didn't work also
<mjg59> Well, it works, but you won't get any consoles afterwards
<mjg59> The error is due to the artwork not being complete
<AnAnt> I can try again without vga=
<AnAnt> ok, I just unpacked the initrd image
<mjg59> It won't make any difference
<AnAnt> I found this in usplash.conf: 
<AnAnt> xres=640
<AnAnt> yres=480
<AnAnt> can that be the problem ?
<mjg59> 13:39 < mjg59> The error is due to the artwork not being complete
<makx> infinity the debian bts has a patch for the fb handling
<makx> had no time yet to polish and integrate
<makx> -> http://bugs.debian.org/386441
<AnAnt> mjg59: I don't understand, it did work from the Knot-3 live CD
<AnAnt> mjg59: yet it won't work from the installed version
<AnAnt> makx: btw, the MMC worked, thanks
<makx> pina : no idea what you mean by out of the box
<AnAnt> makx: is it a bug that tifm_sd doesn't automatically load
<makx> AnAnt: never heard about tifm_sd and i'm really only a guest here
<AnAnt> huh ?
<AnAnt> who told me about tifm_sd
<AnAnt> mjg59: was it you ?
<mjg59> AnAnt: Yes
<AnAnt> mjg59: is it a bug that tifm_sd doesn't automatically load
<zul> hey mjg59 
<mjg59> AnAnt: Yes
<AnAnt> mjg59: ok, thanks
<AnAnt> mjg59: ok back to the usplash thing
<AnAnt> mjg59: I don't understand why it works from the Knot-3 Live CD, yet not working from the installed Edgy
<mjg59> 13:41 < mjg59> 13:39 < mjg59> The error is due to the artwork not being complete
<AnAnt> mjg59: well I seen that
<mjg59> And that's why it fails
<AnAnt> mjg59: even on the same machine ?
<mjg59> There's no 640x480 artwork. 
<mjg59> Yes.
<AnAnt> mjg59: aha, so are there artwork for different resolution ?
<mjg59> It would look dreadful otherwise
<AnAnt> ok
<AnAnt> thanks
<AnAnt> btw the linux console has a wierd font after I upgraded
<AnAnt> is that kernel related or what ?
<zul> no
<AnAnt> what then ?
<zul> i think its usplash related
<AnAnt> zul: again !
<AnAnt> so usplash will fix the splash & the font ? 
<zul> probably
<AnAnt> k , cool
<zul> ooh when will edgy be 2.6.18 ;)
<makx> zul grab d-kernel, but they are vastly mainline :-P -> http://kernel-archive.buildserver.net/debian-kernel/
<zul> makx: it was a joke
<tonfa> is there a list of patch applied to the ubuntu-kernel somewhere ?
<tonfa> (that are not in mainline)
<zul> yes in git
<tonfa> any git magic to find it ? because i suppose some patch are just backports, other are only in ubuntu's kernel
<zul> what are you looking for?
<tonfa> if running an -mm kernel instead of the ubuntu one is "safe"
<makx> -mm != "safe"
<tonfa> if i will lose some features or not
<tonfa> makx: i know i'm running on them since a few years
<tonfa> and i want to continue that while using ubuntu
<tonfa> you can contribute some patches easily while running -mm
<tonfa> i like that
<BenC> mjg59: ping
<mjg59> BenC: Hi
<BenC> mjg59: Would it make sense to backport 2.6.18 libata+drivers to our kernel?
<BenC> main reason I'm asking is because there's some core2duo ich8 support in 2.6.18 and it's non-trivial backporting this
<mjg59> BenC: Urgh.
<mjg59> I don't see why not, but it's likely you'll have to suck in scsi as well
<BenC> sounds like a cascading effect...ata->scsi->usb+firewire
<BenC> hopefully I'll get my core2duo laptop soon enough to test all this junk
<Nafallo> hehe, will end up pulling the whole 2.6.18 then ;-)
* Nafallo sits and select parts to upgrade his server ;-)
<zul> BenC: uh...kernel-package from unstable you need to create a .config before doing anything
<tonfa> BenC: is that the libata part where you have to change your fstab ?
<tonfa> because ide is seen as sd*
<zul> BenC: the new kernel-package from debian unstable works with 2.6.18 maybe we should consider resyncing one more time
<BenC> tonfa: no
<BenC> zul: I'm not sure I'll have time to look at it, so you may want to look at what bits need to be synced
<zul> sure..
<BenC> mjg59: nm, I think I got all the ich8 bits (hopefully)
* BenC starts up 10 kernel builds, and goes to smoke
<Nafallo> :-P
<desrt> BenC; 'sup
<desrt> BenC; i got some good news and some bad news
<desrt> good news: the ACPI stuff in -8 causes my laptop to successfully wake up again
<desrt> bad news: the ACPI stuff in -8 causes my laptop to go successfully to sleep only occasionally
<desrt> it gets suck at some line about SMP Alternatives: Switching to UP code
<desrt> and gets no farther than that
<svu_tv> BenC, ping
<BenC> svu_tv: pong
<svu_tv> BenC, just a quick question: is there any way I could help debugging the problem with kernel on G5? Are you aware it is not bootable?
* svu_tv means livecd Eft
<BenC> I'm aware yes, and I have a G5 right here I am going to fix it on by Monday
<svu_tv> BenC, thanks a lot, you are just saving my soul
<Goliath23> hi
<Goliath23> is there a known problem with the linux-k7 package and its dependencies concerning the nvidia driver (or linux-restricted-modules in general) linux-k7 depends on the 2.6.15.27 kernel image, but also on the 2.6.15.27 restricted modules package... isn't that a mismatch? because on my system the nvidia module fails to load and modprobe says it can't find it ... insmod works though...
<Goliath23> in other words: what have I done wrong if modprobe fails to find the nvidia module, but the restricted modules package is installed?
<Goliath23> update: when I boot the 2.6.15.26 kernel it works and the module is loaded
<Goliath23> thats --- strange!
<BenC> Goliath23: make sure you have everything updated and in sync
<Goliath23> you mean sudo apt-get update & upgrade?
<Goliath23> yes, everything is in sync
<BenC> Goliath23: and what is out of sync about linux-k7 depending linux-image-2.5.15-27-k7 and linux-restricted-modules-2.6.15-27-k7?
<BenC> you do have both those packages installed?
<Goliath23> for restricted modules its .23!
<BenC> you are probably looking at the meta packages
<BenC> dpkg --get-selections | grep 2.6.15-27
<BenC> show me the output for that
<Goliath23> when i install linux-k7, it instales the *.27 image, but that doesn't boot then
<Goliath23> k
<Goliath23> hold on
<BenC> you are saying something wrong, there is no .27, it's -27
<Goliath23> ups, sorry
<BenC> please make sure you say that right, as it means two different things
<Goliath23> david@sun:~$ dpkg --get-selections | grep 2.6.15-27
<Goliath23> linux-image-2.6.15-27-k7                        install
<BenC> you don't have the lrm package installed
<Goliath23> lrm?
<BenC> sudo apt-get install linux-k7
<BenC> linux-restricted-modules
<Goliath23> I just did that!
<BenC> sudo apt-get install linux-restricted-modules-k7
<Goliath23> david@sun:~$ sudo apt-get install linux-k7
<Goliath23> Paketlisten werden gelesen... Fertig
<Goliath23> Abhngigkeitsbaum wird aufgebaut... Fertig
<Goliath23> linux-k7 ist schon die neueste Version.
<Goliath23> 0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
<Goliath23> david@sun:~$ sudo apt-get install linux-restricted-modules-k7
<Goliath23> Paketlisten werden gelesen... Fertig
<Goliath23> Abhngigkeitsbaum wird aufgebaut... Fertig
<Goliath23> linux-restricted-modules-k7 ist schon die neueste Version.
<Goliath23> same there...
<Goliath23> sorry about my german locales :)
<Goliath23> david@sun:~$ dpkg --get-selections | grep 2.6.15-
<Goliath23> linux-image-2.6.15-23-k7                        purge
<Goliath23> linux-image-2.6.15-26-k7                        install
<Goliath23> linux-image-2.6.15-27-k7                        install
<Goliath23> linux-restricted-modules-2.6.15-23-k7           purge
<Goliath23> david@sun:~$
<Goliath23> I dont know what the purge means !?
<BenC> purge means you uninstalled it
<BenC> something is broken on your system
<Goliath23> how do I repair it? :)
<BenC> not something in the kernel/lrm, but something you did :)
<BenC> sudo dpkg -P linux-restricted-modules-k7
<BenC> sudo dpkg -P linux-k7
<BenC> sudo apt-get install linux-k7 linux-restricted-modules-k7
<BenC> try that
<Goliath23> it says that it removed it and them I reinstalled them. but the output of get-selections is the same..
<Goliath23> damnit
<Goliath23> is there something like an apt-get --fix-all-strange-things ??
<BenC> what packages did apt install?
<Goliath23> Die folgenden NEUEN Pakete werden installiert:
<Goliath23>   linux-k7 linux-restricted-modules-k7
<BenC> dpkg -s linux-restricted-modules-k7
<BenC> paste that in privmsg (not in this channel)
<BenC> Goliath23: grep -v '^#' /etc/apt/sources.list
<BenC> paste that in privmsg too
<Goliath23> BenC: thanks a lot, you made my day! everything is up to normal now... man. those sources.list floating around in the net are dangerous
<BenC> hehe
<ph8`> zul: ping?
<zul> ph8`: whats up?
<tonfa> any doc about how the initrd is created and special changes in the ubuntu-kernel ?
<crimsun> see mkinitramfs(8)
<zul> right im off..
<tonfa> crimsun: thanks
<ph8`> zul: Have you had any feedback about the jmicron patch yet by any chance?
<ph8`> There's one guy reporting it doesn't fix the cd-rom detection issue at the moment, i'm just giving it a go myself
<ph8`> + if it doesn't work is there anything i can do to help you diagnose?
<zul> BenC: ping
<zul> about the jmicron drivers i believe there is patch in 2.6.18-rc4-mm for the jmicron drivers but it creates a drivers/ata directory
<svu_tv> will mac-on-linux  be supported on eft or not?
#ubuntu-kernel 2006-09-21
<mjg59> zul: The stuff in drivers/ata is just stuff that used to be in drivers/scsi
<mjg59> Do we have an lspci for the systems in question?
<mjg59> I suspect we need http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=15e0c694367332d7e7114c7c73044bc5fed9ee48
<zul> ill push a patch tonight
<desrt> BenC; poke.
<BenC> desrt: peek
<desrt> BenC; -8 fixes my laptop's ability to wake from sleep
<desrt> but it also breaks its ability to sleep most of the time
<BenC> anything in dmesg as to why it fails?
<desrt> gets stuck at the 'Switching to UP code' message from smp alternatives
<desrt> nothing past that
<desrt> the system is almost entirely useable at this point, though
<desrt> like, i can still do stuff....
<desrt> it's like it gets stuck at something in the middle of bringing itself down
<desrt> and the echo 3 > /proc/acpi/sleep D-states
<desrt> it works sometimes . doesn't work others.  not sure what it is
<desrt> basically just wondering if you have a guess before i start sticking printk's everywhere
<desrt> also: do you know a way to figure out what address a process in-kernel is currently executing at?
<mjg59> desrt: alt+sysrq+t should still dump kernel threads
<desrt> i figure since the 'echo' is getting wedged in D-state the kernel must handling the shutdown in context of that process.... so wherever that process is executing in the kernel is probably a good guess
<desrt> mjg59; no sysrq key here :)
<desrt> mjg59; and it's not a kernel thread
<mjg59> Oh, I see what you mean
<desrt> kernel executing on behalf of a normal process
<mjg59> Erm. I /think/ alt+sysrq+t will still do what you want
<mjg59> And I think there's somewhere in /proc where you can set the keycode
<desrt> is there any way to key that on a system without sysrq?
<desrt> cool
<desrt> i'd like to avoid the recompile if possible :)
<mjg59> Hm. Maybe not.
<mjg59> You might need the recompile.
<desrt> bah
<desrt> btw... do you know why capslock has stopped working?
<mjg59> Nope
<mjg59> Could be the new keymap stuff
<desrt> without vbestate hitting capslock was the only way to tell the diff between a working-but-invisible system and a crashed one
<desrt> you know
<desrt> i wonder if this is another incorrect-lpj symptom.....
<mjg59> Could be
<mjg59> Worth giving it a go
<desrt> it's not happening anymore
<mjg59> The failure?
<desrt> heh
<desrt> take that back
<desrt> it just happened again
<desrt> k.  the shellscript is in state D+
<mjg59> My suspicion is that it's just stuck in the refrigerator
<mjg59> That'll loop several times before it gives up
<desrt> i wonder if i can mine the data that i need from proc
<desrt> what is the fridge?
<desrt> process-freezer?
<mjg59> Yeah
<desrt> i may just be impatient... but i think it gets stuck here for good
<mjg59> What does dmesg have?
<desrt> gets stuck at the 'Switching to UP code' message from smp alternatives
<desrt> nothing past that
<desrt> before that i have only:
<desrt> Freezing cpus...
<desrt> CPU 1 is now offline
<desrt> so it certainly makes sense that it's proably trying to freeze processes next
<desrt> this is interesting
<desrt> i have two kernel threads called [kstopmachine] 
<desrt> one is sleeping anti-nice
<desrt> the other is an anti-nice zombie
<desrt> (the worst kind of zombie you could encounter, really)
<desrt> so many damned modules
<mjg59> BenC: Have we lost the PCI express stuff for bcm43xx again?
<BenC> mjg59: Nope, I checked it today
<mjg59> BenC: Hm.
<mjg59> We don't have the PCI IDs
<BenC> that's the CORE_NEW stuff, right?
<mjg59> Yeah
<mjg59> "Unsupported 80211 core revision 10"
<mjg59> So bits of it are gone, at least
<BenC> -       { PCI_VENDOR_ID_BROADCOM, 0x4312, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
<BenC> I think that's the one
<BenC> Fixed now
<mjg59> No, it's not just the IDs
<BenC> the COMMON_NEW bits are still there, maybe I missed something else
<BenC> mjg59: I have the PCIE changeset, and am cherry-picking it back into head
<mjg59> BenC: Which PCIE changeset?
<mjg59> I'm just testing the one that's going upstream
<mjg59> Rather than my slightly hacky one
<BenC> commit 8ffedd7b606cc085fbfb11019f2794c8a94bb5e9
<BenC> Author: Matthew Garrett <mjg59@srcf.ucam.org>
<BenC> Date:   Wed Mar 8 09:43:00 2006 +0000
<BenC>     [PATCH]  Broadcom wireless patch, PCIE/Mactel support
<mjg59> Yeah
<mjg59> Drop that one
<mjg59> Hang on a couple of minutes
<desrt> neat fact: a system that fails to sleep won't shutdown anymore
<BenC> mjg59: damnit, I already cherry-picked it :)
<BenC> curse the fast and convenient source control system
<mjg59> Heh
<mjg59> Revert it, then :)
<BenC> done, just email me your patch and I'll get it in tonight for the 1am upload :)
<mjg59> Hm.
<mjg59> So the one I've got doesn't quite seem to work...
* mjg59 looks closer
<zul> 1am upload?
<zul> ick..
<mjg59> Hm. No interrupts
<mjg59> I'm /sure/ I've fixed this before
<desrt> i hate my macbook
<desrt> it's as if inserting the printks fixed the problem
<mjg59> Whereas mine works
<mjg59> Hm
* mjg59 looks more closely
<desrt> your macbook?
<mjg59> I don't have a macbook
<mjg59> Sorry, my bcm patch
<desrt> lucky bastard.
<desrt> whatever
<mjg59> BenC: Oh, bugger it
* desrt jsut runs his instrumented kernel
<mjg59> BenC: Ignore me, merge my patch again, it has the advantage of working :)
<desrt> next time it screws up i'll at least have the debugging there
<mjg59> BenC: But can you add 0x4311 as well as 0x4312?
<BenC> yeah
<mjg59> No idea why this doesn't work, but the upstream one just never gets any interrupts
<mjg59> Mine's incorrect in places, but does work
<BenC> mjg59: all done
<mjg59> BenC: I didn't see the patch from #53910?
<BenC> it's in git
<BenC> should be, I know I grabbed it
<mjg59> Can't see it on gitweb
<BenC> put it in dapper too
<mjg59> Ah
<mjg59> It's under "update configs"
<mjg59> Your commit messages suck :)
<BenC> oh, that's right
<BenC> I did a git-update-index on it, forgetting I had a huge update under debian/*
<BenC> mjg59: I added a patch to bcm43xx that sets signal stats in iwconfig (and NetManager)
<BenC> works on my powerbook
<mjg59> BenC: Cool
<johanbr> BenC: Did you hack that up yourself, or did you backport the patch that was just added to upstream bcm43xx?
<mjg59> johanbr: That's something I wrote a while ago
<mjg59> Oh, you mean the stats stuff?
<johanbr> mjg59: Yep.
<BenC> johanbr: someone emailed it to me from upstream
<zul> BenC: how would i revert the smp-alt stuff it seems to be getting in the way
<BenC> zul: smp-alt is in stock 2.6.17, so it's not a patch I did (except the amd64 support)
<fabbione> hey BenC 
<fabbione> no new kernel yet?
<BenC> working on it
<fabbione> ok :)
<BenC> need to fix a agp build failure
<fabbione> time to get ready to start my hw maintainance
<fabbione> i have to move a few hd arounds and put the rest of the machines under UPS
* fabbione sighs at more cables around
<BenC> #61448: [Edgy]  Kernel 2.6.18 Released
<ajmitch> heh
* BenC didn't know that malone was a opensource announce list
<ajmitch> you know you'll get asked to put in 2.6.19 when it's there
<BenC> 2.6.19 wont be released before edgy, so no worries there :)
* ajmitch has seen such bugs filed within minutes of an upstream release
<BenC> they were even nice enough to put a link to kernel.org, like I wouldn't know where to find the kernel source
<ajmitch> how thoughtful
* Starting logfile irclogs/ubuntu-kernel.log
<zul> someone say my name? it went past the scrollback 
<tonfa> 06:45 < BenC> zul: smp-alt is in stock 2.6.17, so it's not a patch I did (except the amd64 support)
<zul> thanks..
<AnAnt> I'm not sure if that is the proper place to discuss it but here it is anyways: if I am on an amd64 using 32-bit Ubuntu, will I be able to run 64-bit applications ?
<Mithrandir> AnAnt: no, not unless you use a 64 bit kernel, which is an unsupported configuration
<AnAnt> Mithrandir: what does "unsupported configuration" mean ?
<AnAnt> Mithrandir: does it mean that it is impossible to do ? or that Ubuntu would do it ?
<Mithrandir> AnAnt: that if it breaks or you get unexpected problems you might not get your bugs fixed.
<AnAnt> mithrandir: ok, did you mean that it is not supported by Ubuntu, or that it is not supported by the kernel ?
<Mithrandir> unsupported by ubuntu
<AnAnt> Mithrandir: do you know wether they plan to support it in the future ?
<AnAnt> edgy+1 or so ?
<Mithrandir> I'm not sure, but I don't think so
<AnAnt> btw, this is the proper place for my question, right ?
<gnomefreak> mjg59: you around?
<zul> BenC: ping
<BenC> zul: pong
<zul> i saw your note last night about the smp-alt stuff i just checked the stable tree in git for 2.6.17 and there is no reference about it
<Mithrandir> hi zul
<zul> hi Mithrandir 
<BenC> zul: That's funny, because after hearing what fabbione said, I checked current 2.6.18, and smp-alt is in there still
<zul> smp_alternative?
<BenC> rgrep alternatives_smp_switch arch/i386
<zul> ah ok..
<zul> then how the hell im going to to do this (rhetorical question)
<mjg59> BenC: Ha. So while the PCI-E broadcom stuff /works/, I'm getting 20K/sec
* mjg59 decides not to care for now
<BenC> mjg59: nasty, even I get 500-600k/sec and it seems crappy :)
<mjg59> BenC: On a Broadcom?
<BenC> mjg59: Yeah, powerbook
<BenC> it's weird, I get less than half the distance under linux than I do under macosx
<mjg59> BenC: Yeah, it seems to be PCI-E specific
<BenC> the signal strength sucks
<mjg59> Oh, the txpower stuff?
<mjg59> Yes, that's still not properly implemented
<BenC> how can I bump the txpower?
<mjg59> Help complete the specs?
<BenC> heh
<zul> BenC: interesting http://svn.debian.org/wsvn/kernel/?rev=0&sc=1 (based off of 2.6.18)
<zul> BenC: got it without the xen smp-alts crack from 2.6.16
<`ph8> hey BenC
<`ph8> thanks for getting back about that bug so promptly
<BenC> hello
<BenC> hoping that this last changeset I pulled fixes the problem
<ivoks> BenC: will that patch get ported to dapper?
<BenC> ivoks: maybe
<ivoks> ok
<`ph8> will let you know tomorrow hopefully Ben
<`ph8> i'm actually out tomorrow night so it might not be until Saturday :/
<ivoks> i'll try it tomorrow
<`ph8> unless i negotiate a day to work at home *g* - we'll know shortly
<ivoks> i have same problem :/
<zul> heh...i tried..
<BenC> mjg59: You know, it sucks, I used to have a broadcom docsafe account, in which I could have gotten the bcm43xx specs, but the account is no longer active
<ivoks> zul: and?
<zul> ivoks: meh...didnt work
<ivoks> ok :)
<ivoks> well, then i'll prepare 2.6.18 image to solve this problem :)
<mjg59> BenC: I've got the driver for the iSight on the Apples sorted
<`ph8> BenC: do Windows know about all these things because Asus told them years in advance for fear of angering them?
<`ph8> then we linux-ers have to wait until release to sort out compatibility?
<BenC> ph8: no idea
<`ph8> i have a suspicion that's the case. We need to get a couple of lottery winners on board to start a nice investment fund to run Ubuntu off forever more :D
<ivoks> `ph8: vendors provide their own windows drivers
<`ph8> i dont' think it's right that Asus claim this board works with gentoo/bsd/linux on their website then don't provide some clever linux drivers
<`ph8> unless they provided it to the kernel when they shipped the product i suppose
<`ph8> s/kernel/kernel team
<`ph8> muwahaha
<`ph8> tomorrow working from home, i'll be around at about 10am gmt to try it out ben :)
<`ph8> looking forward to it
<`ph8> hopefully this will fix my sata and my ide issues
<`ph8> as if I know anything though, they might even by symptoms of the same problem
<zul> bleah...i feel like shit
<svu_tv> BenC, thanks for fixing G5. Will the fix be in the tomorrow's .ISO images? what was the problem?
<BenC> svu_tv: Hopefully
<BenC> was a bug in libata where it thought that irq==0 was a bad thing, when it isn't
<svu_tv> nice. ok, i will try tomorrow and report
<BenC> cruft from libpata patch
<zul> i dont care about ia64 do i?
* svu_tv really seen some messages from ata driver
<BenC> svu_tv: I know it works, since I had the same problem on my G5, and now it's booting and running edgy fine
<BenC> so look forward to it :)
<svu_tv> sweet, I just cannot believe till I see it myself:)
<BenC> feh, no faith :P
<svu_tv> :)
<zul_> right...later
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel GIT tree info (updated): https://wiki.ubuntu.com/KernelGitGuide | 2.6.17-9.23 uploaded, Ok, I think I'm getting the hang of this kernel thing. | Daily kernel builds (for debug and testing purposes only) http://people.ubuntu.com/~bcollins/kernels-daily/ | Kernel Wiki: https://wiki.ubuntu.com/CategoryKernel
<jbailey> BenC: Still around?  I have an amusing one. =)
#ubuntu-kernel 2006-09-22
<zul> there ported to 2.6.17
<desrt> zul; xen?
<desrt> you sexy beast
<`ph8> anyone tried out the jmicron fix yet?
<ph8> Mithrandir: around per chance? I've noticed the new kernel which should fix all these darn jmicron issues didn't make it into today's daily image as advertised on the bug report, any idea when the new kernel will make it to a daily image?
<Mithrandir> ph8: is the version you need currently built and published?  (As in, is it available if you browse archive.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.17?
<Mithrandir> )
<ph8> struggling to connect to archive. - sec
<ph8> ben implied in the bug report it would be on the install cd today
<mjg59> Mithrandir: launchpad claims that 2.6.17-9 is published
<ph8> ah, kinky
<mjg59> ph8: The timing may not have worked out for that
<ph8> and -8 is in the current isos right?
<mjg59> I've no idea. I assume so.
<ph8> ja
<ph8> so it might mean waiting another day? :(
<ph8> archive.'s not working for me
<Mithrandir> you want alternate or desktop?
<ph8> (can't connect)
<ph8> alternate
<ph8> but there may also be people waiting for desktop
<ph8> there's lots of people watching the report/posting on the forum
<Mithrandir> i386?
<ph8> amd64 :o)
<ph8> just to be mega-difficult
<Mithrandir> running now
<ph8> you legend :o
<ph8> i've got to hop to windows (meant to be working from home today, alledgedly)
<ph8> brb
<ph8> well `ph8 is here, that's on my work machine
<`ph8> back
<Mithrandir> `ph8: hmm, the old binaries doesn't seem to have been expired yet, I need to poke it a bit
<`ph8> use the large pitch fork. :o)
<`ph8> rm -rf ftw
<`ph8> The kernel on today's (2006-9-22) daily iso is version 2.6.17-7.20 from
<`ph8> Sept. 18, not the fixed 2.6.17-9.23, so it's not to be expected to work
<`ph8> what was just posted on the bug report, if it helps
<Mithrandir> seems like linux-meta needs an upload too.
<`ph8> does that mean waiting for ben?
<Mithrandir> nope, but it means waiting a bit for it to be published.
<`ph8> ah
<Mithrandir> actually, I think I'll hold this off and get it coordinated with new LRM.
<`ph8> time enough for me to go and get a haircut without missing my chance to grab a download? ;) or several haircuts?
<`ph8> LRM?
<Mithrandir> linux-restricted-modules.
<Mithrandir> yes, you can go get a haircut.  I need to poke somebody to fix this.
<zul> dont poke me im off to work
<`ph8> lol
<`ph8> cheers for the concern mith
<`ph8> i'll bounce off shortly then
<`ph8> out this evening as well :(
<`ph8> that's a shame
<Mithrandir> oh well, let's hope this works, then
<`ph8> :o)
<zul> neuralis: ping
<neuralis> zul: pong
<neuralis> what's up?
<zul> is it possible can you create an ubuntu-xen-2.6.17 git?
<neuralis> sure
<zul> danka
<neuralis> you can also create a 2.6.17 branch
<zul> i could do that as well
<neuralis> which is probably more natural
<neuralis> it's what upstream does.. but whichever you preer.
<neuralis> prefer, even.
<zul> we have two different gits for dapper and edgy so i would like to do the same
<neuralis> done
<`ph8> Mithrandir: back, any joy?
<zul> neuralis: thanks..
<zul> BenC: close but no cigar on the xen porting
<BenC> suckage
<ivoks> hi
<ivoks> BenC: ping
<ivoks> BenC: latest source doesn't fix the jmicron bug
<ivoks> BenC: but i got it working with little modifications
<ivoks> BenC: still, ich8 doesn't work and i didn't manage to backport fix from 2.6.18
<BenC> can you send me the changes?
<BenC> and is this the 9.23 source?
<ivoks> sure
<ivoks> yes
<BenC> ivoks: According to even JMicron, the patches I pulled into 9.23 should have fixed things
<BenC> Also note that they said a BIOS update may be needed for some things to work
<BenC> like grub booting
<ivoks> heh :)
<zul> hah...so i wasnt going crazy with the jmicron stuff
<ivoks> we'll see :/
<ivoks> i spent whole day today trying to install edgy on a box with r1000, ich8 and jmicron
<BenC> zul: There was another part that was needed that included ide-generic changes and a pci quirk addition
<ivoks> BenC: i'll send you everything tomorrow... is that ok?
<zul> BenC: yeah i saw
<ivoks> i have to check everything; maybe i'm bringing false alarm :/
<BenC> ivoks: Time is important...I have 20 some odd people watching my every move on this bug :)
<ivoks> hehe
<ivoks> BenC: i have a client with non-working machine :)
<ivoks> btw...
<ivoks> i tried with 2.6.18, and it worked (ihc8, jmicron)
<BenC> problem is, I pulled in all the changes for ich8 and jmicron from 2.6.18
<ivoks> but installation failed while detecting hardware, creating partitions...
<ivoks> um...
<zul> hehe..
<ivoks> BenC: you didn't... :/
<ivoks> BenC: this i'm 100% sure
<ivoks> ata_piix.c has big diff
<BenC> can you at least point me to this mysterious commit that I missed?
<BenC> ata_piix has a big diff because of the libata changes
<ivoks> right
<ivoks> but it's missing some parts related to ich8
<Mithrandir> BenC: hope you don't mind that I uploaded a new ubuntu-meta
<ivoks> just a second
<BenC> Mithrandir: not at all, but could you find out about getting l-r-m for i386 out of dep-wait?
<BenC> Mithrandir: and can you make sure that daily CD's are building with the latest kernels? Some people reported that the ones from today are using 7.20 kernel, which isn't even the latest one I uploaded almost a week ago
<Mithrandir> BenC: daily cds use linux-generic.
<ivoks> (maybe i was drunk whole day:/)
<BenC> Mithrandir: linux-generic should have been pointing to 8.22 for the cd build today
<BenC> ivoks: I'm very interested in what changes you needed for the JMicron stuff...if you could just point out a commit from 2.6.18 gitweb, that would be enough
<ivoks> i downloaded whole source and cherrypicked from it :/
<ivoks> BenC: i will tell you everything... now i just have to get ready for wedding :)
<Mithrandir> /pool/main/l/linux-source-2.6.17/linux-image-2.6.17-8-generic_2.6.17-8.22_amd64.deb
<Mithrandir> is the one which went into this morning's amd64 image
<BenC> Mithrandir: hmm
<BenC> some ppl are using the wrong CD images then
<Mithrandir> I need to find out why lrm is in dep-wait, though
<BenC> Mithrandir: I don't suppose there's anyway you can do a half-daily cd build after this new kernel is ready, could you? :)
<BenC> Mithrandir: I think it was because linux-source on i386 didn't build for awhile
<BenC> and l-r-m could build when it was uploaded
<BenC> it just needs to be kicked or something
<Mithrandir> BenC: I could poke one when I get home after dinner and a concert.  Which means aroudn 0000 UTC or so
<BenC> Mithrandir: excellent, thanks
<`ph8> and that one will have the kernel with the jmicron fixes in? ;)
<`ph8> hi ben btw
<BenC> ph8: it should, but ivoks was saying the latest source didn't work for him, didn't clarify, and left
<BenC> jmicron is sending me eval boards, so worst case is I get it all working then
<BenC> will reduce the turn around time on "patch kernel, upload, wait for it to build, wait for CD images, wait for users to test"
<`ph8> that was good of them
<`ph8> what ich8, that affects sata detection?
<`ph8> because from what i've heard it sort of sounds like the new one fixes the satas at the very least and the cdrom drive detection issues can be worked around with a USB disk
<`ph8> which would be fine
<`ph8> s/what/what's
<`ph8> anyone?
<ivoks> hi, again
<ivoks> BenC: find . -name jmicron.c doesn't find anything in kernel source
<ivoks> while in upstream there is jmicron.c
<ivoks>  drivers/ide/pci
<BenC> bcollins@grayson:/org/linux-2.6$ head -3 Makefile 
<BenC> VERSION = 2
<BenC> PATCHLEVEL = 6
<BenC> SUBLEVEL = 18
<BenC> bcollins@grayson:/org/linux-2.6$ find -name jmicron.c
<BenC> bcollins@grayson:/org/linux-2.6$ 
<BenC> I see nothing
<ivoks> huh?
<ivoks> i have -rc7
<BenC> same here
<ivoks> http://www.archlinux.org/~tpowa/2.6.18/PKGBUILD/jmicron-ide.patch
<ivoks> this is what i've added
<ivoks> but i realize that i made a mistake
<ivoks> it should use libata, this patch is for basic IDE support
<BenC> it shouldn't be needed for this to wrok
<BenC> ide-generic should handle it
<BenC> I think your missing something
<BenC> JMicron has two functions on the PCI device
<BenC> a stock IDE function, and the SATA function (handled by ata_piix)
<ivoks> i tought ata_piix is different bug (ich8 related)
<BenC> the reason things are broken for CDROM's is because ata_piix grabs the whole PCI device, and doesn't let ide-generic grab the second function for IDE
<BenC> the quirk fixups are supposed to fix that
<BenC> err, ahci I mean
<BenC> sorry, s/ata_piix/ahci/ for JMicron
<ivoks> ah... ok :)
<BenC> Jmicron has SATA and ATA on the same PCI device, and that's what was causing the problems
<ivoks> ok
<ivoks> so, basicly, new kernel should work
<ivoks> sorry for introducing confusion :(
<`ph8> kernel out on a daly image tomorrow? :)
<`ph8> * daily
<`ph8> it's another tomorrow, but this one sounds like it actually might happen :D
<zul> `ph8: please be patient
<`ph8> nps..
<`ph8> back tomorrow then
<svu_tv> BenC, ping?
<BenC> svu_tv: pong
<svu_tv> BenC, I tried today's live cd (well, the one marked as 2209) - it stil does not boot on g5 ;)
<svu_tv> BenC, are your changes in it?
<BenC> doesn't contain the new kernel
<BenC> one tomorrow will
<BenC> everything is built, but it didn't get done in time for today's cd build
<svu_tv> BenC, ok, I see. sorry for bother, i'll try tomorow
<BenC> np
<Xnix> anyone in here know about the ACPI_DSDT patch in the latest git of ubuntus kernel tree
<BenC> 6 more weeks...just keep telling myself that
<BenC> I wonder how well this sat dish will hold up to a double barrel 12 guage, because that's about what I want to do to it
<crimsun> we will all cheer when you receive better connectivity
#ubuntu-kernel 2006-09-23
<Mithrandir> BenC: do you want a daily build now?
<zul> BenC: you can throw rocks at your satelite dish or cow dung
<BenC> Mithrandir: yeah, definitely
<yarddog> this 2.6.17-9 is giving me a panic on boot
<yarddog> cannot use it
<yarddog> ive reinstalled and still panic, it hangs on the new splash and will not boot
<Mithrandir> BenC: oh well, I didn't see that before going to bed; you'll have images in an hour or so.
<ivoks> bummer :/
<ivoks> BenC: it doesn't work, but it works with 2.6.18-rc7-mm
<ivoks> fwiw
<ivoks> (i know that isn't much of the help)
<ph8> morning all
<ph8> any feedback from the jmicron fix from today's daily yet? I haven't got around to downloading the image yet
<ph8> Just one guy going "oh it's not in the source boo hoo"
<ph8> but according to the .list
<ph8> /pool/main/l/linux-source-2.6.17/linux-image-2.6.17-9-generic_2.6.17-9.23_amd64.deb
<ph8> is included
<ph8> so all should be gravy when i get a chance to d/l it :)
<ivoks> hi BenC 
<ivoks> yay... it almost booted :)
<ph8> hey BenC! Noticed the comments on the jmicron bug report mate? wondering if it's true/applicable and if so if it would then be a waste of my time downloading the image today
<yarddog> anyone have a problem booting with 2.6.17-9 ?
<gnomefreak> yarddog: it hasnt hit my repos yet
<gnomefreak> using uk repos too they are normally one of the first updated
<yarddog> i think mine are the ubuntu archives
<yarddog> archive.ubuntu.com
<yarddog> it boots fine on my laptop
<yarddog> but not on this desktop
<yarddog> i had to revert to 
<yarddog> 2.6.17-8-386
<yarddog> the desktop has kde as well and it uses the kubuntu usplash
<yarddog> i dont know if that makes a difference because it hangs/panics on the kubuntu splash screen
<yarddog> so i cant see if its a panic or not
<gnomefreak> yarddog: they were in my repos but some some strange reason they were not updating i had to install
<yarddog> interesting
<yarddog> what kernel version are you running?
* gnomefreak thinks its not BenC's fault 
<gnomefreak> -8-generic
<yarddog> hrm
<gnomefreak> i had changed to -generic since 386 is installed by default
<yarddog> i tried several times
<yarddog> what does generic have?
<yarddog> this desktop is a prescott and there is no 686 or smp either
<gnomefreak> generic is 686 may  also be 486 and 586
<yarddog> so its forced to run 386
<gnomefreak> 686 was renamed to -generic
<yarddog> so i should be running generic?
<gnomefreak> yarddog: im not sure there is much of a performance difference but im not a kernel guy
<yarddog> ok
<gnomefreak> gonna try brb
<ivoks> hi zul 
<zul> hey
<ivoks> do you have a minute?
<ivoks> :)
<zul> i might
<zul> whats u
<zul> *up even
<ivoks> ich8 doesn't work with latest kernel 9.23
<ivoks> and i was checking diff with vanilla kernel
<ivoks> and it's big
<ivoks> but vanilla kernel doesn't include support for ich8
<ivoks> so, i've looked for a patch and found this:
<ivoks> http://lkml.org/lkml/2006/7/11/493
<zul> gimme a sec
<ivoks> it seems that our ata_piix.c has parts of this patch and parts from somewhere else
<zul> hmmm...you might want to talk to ben when he is around
<ivoks> ok
<zul> does that patch work though?
<ivoks> it builds
<ivoks> but i can't test it right now :/
<zul> ah..
<ivoks> our driver reports that it can't read status of disk
<ivoks> but, i'll talk with ben about it
<ivoks> speeking of... :)
<ivoks> speaking even
<ph8> BenC: Sorry, lost my connection, did you reply?
<ivoks> ph8: did your jmicron worked?
<ph8> not sure
<ph8> downloading now
<ph8> did yours ivoks?
<ivoks> no
<ph8> same error?
<ivoks> well, i have disk on ich8 and cdrom on jmicron
<ivoks> cdrom wasn't detected at all
<ivoks> and ich8 stalled for a long time... :/
<ph8> was ich8 detected in the end though?
<ph8> there's some guy on bug report saying that the installer is using an old kernel which probably only BenC or Mithrandir would know about - presumably though the installer should use the kernel that gets put into the distro..
<ivoks> i said that :)
<ivoks> and it does
<ph8> ah
<ivoks> i've tested it this morning
<ph8> weird
<ph8> does that mean someone's not updated the installer?
<ivoks> it's not that weird
<ph8> or is that how it's meant to work
<ph8> and since we've got a fixed kernel package can't we just overwrite the one on the install cd?
<ivoks> this is automated procedure
<ivoks> i think tomorrow we'll have new kernel in installer
<ph8> :(
<ph8> always another tomorrow
<ph8> pain in the arse
<ivoks> ph8: safe bet is "the release day"
<ph8> unless of course Mithrandir's around and is feeling generous? ;)
<ph8> ivoks: I was hoping to fit this machine on monday/tuesday
<ivoks> ph8: this is expected for a development version
<ph8> indeed
<ph8> do you know if any other distros have it fixed yet?
<ivoks> ph8: i was hoping to make it work yesterday :)
<ph8> distros that have server installations
<ph8> ivoks: Did you say ich8 detection worked?
<ivoks> only those that have 2.6.18 kernel
<ph8> do any have the .18?
<yarddog> that kubuntu splash has something to do with the kernel panic
<yarddog> edgy splash is fine
<ivoks> ph8: there is thousands of linux distribution :)
<ph8> doesn't answer the question though, does it? ;)
<ivoks> i don't know :)
<ivoks> 2.6.18 is fresh
<ph8> do you know an easy way to just copy the kernel on the install cd into the installer?
<ph8> or is that not do-able?
<ivoks> i did that
<ivoks> and i managed to install edgy onto disk
<ph8> and it works?
<ivoks> even boot it
<ivoks> but (big BUT)
<ivoks> udev in edgy isn't compatibile with 2.6.18
<ivoks> so... bummer :)
<ph8> i meant the fixed edgy kernel
<ph8> which presumably is on the install cd as a package
<ph8> just not in the installer
<ivoks> ph8: you can do netboot, as i did
<ph8> don't you have a P5B?
<ph8> the network card isn't supported
<ivoks> i don't know what board it is...
<ph8> you have to download seperate drivers which aren't on the install cd
<ivoks> ph8: realtek?
<ph8> iirc
<ph8> yes
<ivoks> it's supported
<ivoks> r1000 module
<ph8> i can try it but i'm not sure you're right
<ivoks> if you have time, you can do it
<ph8> netboot involves setting up a dhcp server and all that rubbish right?
<ph8> i don't really have the cabling tbh
<ivoks> first, do apt-get source linux-image-2.6.17-9-386
<ph8> it would be a trek
<ivoks> ph8: it's easy... you need 5 minutes for setup and hour and half for waiting kernel to compile
<ph8> this is for netboot?
<ph8> i have a feeling one of us might be lagging
<ivoks> ph8: no one is lagging :)
<ivoks> for netboot, yes
<ivoks> you need dhcp3-server and tftpd-hpa
<ivoks> and apache2 :)
<ivoks> those three packages
<ph8> eww
<ph8> i need to setup software raid as well
<ph8> will netboot use the latest kernel instead of this old one which seems to be all over the place?
<ivoks> ph8: netboot will use kernel which you will create
<ivoks> which would be the same as ubuntu kernel + r1000 module for realtek
<ivoks> it's easy
<ph8> this assumes the ich8 fix works
<ivoks> that one doesn't work
<ph8> then my sata's won't get detected?
<ivoks> but if you are willing to try my patch...
<ph8> hmmm
<ph8> why not submit the patch to these lovely guys?
<ivoks> cause i'm not sure it works :)
<ivoks> and i can't test it
<ph8> well then
<ivoks> :((((((
<ivoks> but if you would test it...
<ph8> i'm going to try today's daily in an hour, i'm not too hopeful from what i've heard already :/ 
<ivoks> then we would know if it works or not
<ivoks> so, you don't want to test this patch? it will take maybe 20 minutes to set everything up (since i allready compiled kernel and modules)
<ph8> maybe
<ph8> give me an hour to try this
<ph8> and then i'll think about it
<ph8> as i said, if i can get this machine installed on tuesday that would be great
<ph8> it's the last day i'll be able too really
<ph8> pressure's on
<ivoks> same here
<ph8> i've pm'ed Mithrandir, if he appears maybe he'll do a new build for us so the new kernel can get into that blasted installer
<ph8> then we'll be on the way \o/
<ivoks> i doubt
<ivoks> since i've allready tried new kernel
<ivoks> and it doesn't work
<ivoks> period
<ph8> pfft
<ph8> sounds like a recurring nightmare
<yarddog_> wiping that install and doing a clean onee
<ivoks> jezzzz
<ivoks> ph8: please, please, are you willing to test this patch?
<ivoks> it might make your computer - work :)
<ph8> it involves a netboot and a rebuild with the r1000?
<ph8> if so, how are you going to get around the ich8 issue?
<ivoks> this get's around ich8 issue
<ivoks> it solves it
<ivoks> it also solves PATA part of jmicron driver
<ph8> and does it involve a netboot or just a patch to the install cd?
<ivoks> fix in edgy kernel includes only fix for SATA part of jmicron
<ivoks> netboot
<ph8> what do i need to do?
<ivoks> it's much easier to do it trough netboot than remastering CD
<ivoks> ph8: install tftpd-hpa dhcp3-server apache2
<ivoks> patch is on http://www.grad.hr/~ivoks/ubuntu/jmicron-ich8.diff
<ivoks> then you need to get source of edgy kernel; apt-get source linux-image-2.6.17-9-386
<ivoks> or, if you trust me, i can provide you prebuild image and modules
<ph8> presumably as soon as edgy dev has fixed this i can update to their kernel?
<ph8> i won't be tied into this patched kernel for a long time?
<ivoks> of course
<ph8> link me to the prebuild then
<ivoks> i have to upload them, just a second
<ivoks> while it's uploading, let's set up everything for netboot, ok?
<ivoks> ph8: ?
<ph8> ok
<ivoks> did you install those packages?
<ph8> yes
<ph8> start of dhcp3 server fails atm though
<ph8> not sure why
<ivoks> that's ok
<ph8> no config you think?
<ph8> ok
<ivoks> now go to /var/lib/tftpboot
<ivoks> and run:
<ivoks> lftp -c "open http://archive.ubuntu.com/ubuntu/dists/edgy/main/installer-i386/current/images; mirror ."
<ivoks> errr
<ivoks> lftp -c "open http://archive.ubuntu.com/ubuntu/dists/edgy/main/installer-i386/current/images/netboot; mirror ."
<ivoks> this will take a while, depending on you connection
<ph8> 5 mins
<ivoks> ok...
<ivoks> while that's downloading, we could set-up dhcp
<ph8> am i going to be able to setup software RAID using this method?
<ivoks> ph8: this is just for kernel, installer is standard
<ph8> k
<ivoks> so... in another term, open (as root) /etc/dhcp3/dhcpd.conf
<ivoks> do you have only one or more network cards on your computer? (on which you are editing dhcpd.conf)
<ph8> wireless and wired eth1/eth0 respectively
<ivoks> great... you are connected to internet trough wifi?
<ph8> no, wired
<ph8> although
<ph8> when doing the netboot
<ph8> i'll be wi-fied
<ph8> i think, assuming it works
<ivoks> ok
<ph8> i've only got one wired connection up here
<zul> bian/build/build-generic-xen0'
<zul> damn it
<zul> /usr/bin/make  EXTRAVERSION=-1-generic  ARCH=i386 \ modules
<ivoks> you need one free wired network card
<ph8> free in what sense?
<ivoks> to which you are going to connect your jmicron computer
<ph8> in the sense the netboot machine connects to a machine that's then connected to the network?
<ph8> i see
<ph8> ok
<ph8> that should be ok
<ivoks> so, if you now have IP 192.168.0.x
<ph8> .1.102
<ivoks> you should set-up 10.0.0.x on your other card
<ivoks> so in that dhcpd.conf enter:
<ivoks> i sent you that on private, so we don't flood channel
<ivoks> now you have to add 10.0.0.1 IP to your network card, which you don't use for internet (ergo; which is free)
<ph8> erm
<ph8> i'll try switching to wifi
<ph8> probably get d/ced
<ivoks> so, if you are connected over eth0, run 'ifconfig eth1 10.0.0.1 up'
<ivoks> ok
<ph8> will wait for that download to finish
<ph8> oh wait
<ph8> i can add 10.0.0.1 to my wireless?
<ph8> i assumed you meant the card the jmicron would connect to
<ivoks> no, not to wifi, but to the wired card
<ph8> will have to wait for that d/l to finish then
<ivoks> ok
<ivoks> what's you connection?
<ivoks> adsl?
<ivoks> (btw; we are mostly following: http://wiki.koeln.ccc.de/index.php/Ubuntu_PXE_Install)
<ph8> ja
<ivoks> still downloading?
<ph8> yes
<ph8> ah no done now
<ph8> brb
<ivoks> ok
<ph8> my wireless is being shit
<ivoks> :)
<ph8> this could be a long process
<ph8> i might have to have one machine downstairs and one up
<ivoks> uh
<ph8> right brb
<marcin_ant> hi guys
<marcin_ant> ph8: hi
<marcin_ant> ph8: do you know what's going on with jmicron issue?
<ivoks> :)
<ivoks> topic of the week
<marcin_ant> ivoks: sure, but do you know if is it really fixed now?
<ivoks> i think SATA part of jmicron is fixed, but not the IDE one
<ivoks> (i'm not kernel developer, just a poor user with same problem)
<ivoks> so i might not be best person to comment this
<marcin_ant> well that's pretty sad.
<marcin_ant> fortunately I finally got running dapper
<marcin_ant> which I installed using instlux
<marcin_ant> but yesterday I tried to run edgy from daily build which I installed on some other machine with SATA controller based on VIA chipset
<marcin_ant> but I just couldn't boot
<marcin_ant> it stopped with some ACPI message related to CPU... 
<ivoks> noacpi might help
<marcin_ant> another thing is - I'm not sure if anyone cares is that on Asus P5B there are 2 NIC's while only one is functional in dapper/edgy...
<marcin_ant> ivoks: I just switched ACPI off in bios... unfortunately no success with it
<ivoks> pass noacpi argument to kernel
<ivoks> f6
<marcin_ant> well now I just installed dapper on this partition
<marcin_ant> I don't have time to fight with it anymore
<marcin_ant> but just wanted to get some info if is this fixed in edgy daily build
<ivoks> none of kernel devs is in here, so no one can give you exact answer
<ivoks> it didn't work for me :/
<ivoks> bbl
<ph8> huzzah
<ph8> finally sorted the wireless
<ph8> and ivoks has left :(
<tidiman07> help
<ph8> can you be more specific?
<tidiman07> i want to install kernel 2.6.18, but two version, how do i do that?
<tidiman07> like one with default settings, and another customized
<gnomefreak> tidiman07: 2.6.18 isnt supported by ubuntu my suggestion would be to read the docs on compiling a kernel and start there
<tidiman07> i can compile it myself, but i dont know if i try to install it again will it tell me its already installed or override
<gnomefreak> https://wiki.ubuntu.com/KernelCustomBuild?highlight=%28kernel%29
<gnomefreak> i would think naming it something differnet add a .1 or something but not positive on that
<tidiman07> you know what, i'll just backup some stuff and start experimenting
<tidiman07> thanx, ,later
<ph8> BenC: lo
<ph8> BenC: Did that kernel patch (for jmicron) bring in this new 'could not read from install cd' when the kernel's loading? My system now actually crashes earlier
<ph8> 'error reading boot cd' is the exact error sorry
<BenC> no idea
<ph8> i see, i'll check my image
<BenC> I'm just pulling in the patches that jmicron pointed me to, I have no way to test it yet
<ph8> it appears your shiny new kernel didn't make it to the installer :(
<ph8> which is a bummer
<BenC> check the kernel version in the initrd (unpack and check /lib/modules)
<ph8> do you know how often the installer's kernel gets updated by any chance?
<ph8> sec
<BenC> yeah, that would suck
<ph8> how do i unpack initrd?
<ph8> in the .tar.gz there's just one fine
<ph8> * file
<BenC> there should be an initrd on the cd image
<ph8> sorry .gz
<ph8> i see initrd.gz
<ph8> not what you mean?
<ph8> wb ben
<ph8> i've got initrd.gz
<ph8> but that seems to be an unopenable file
<ph8> is that not what you meant?
<BenC> zcat initrd.gz | cpio -i
<ph8> 2.6.17-8-generic benc, that mean anything?
<ph8> BenC: 2.6.17-8-generic, that mean anything?
<ph8> grr :p
<crimsun> ph8: it's likely he's away; his Internet connection is quite bad. In a few weeks he'll have a much more stable one.
<crimsun> getting a T1 iirc
<ph8> he was sort of here before :p
<crimsun> it's Saturday evening localtime; he lives on a farm; his Internet connection is awful; ...
<chillywilly> hi, I am running a dist-upgrade form breezy to dapper for amd64 and there's an error in the pre install script for lvm2...can anyone help?
<BenC> ph8: the installer needs to use -9. The -8 kernel didn't contain the changes for jmicron
<chillywilly> says returned error exit status 10
<BenC> chillywilly: #ubuntu
<crimsun> d'oh, I just punted him here
<BenC> heh
<chillywilly> yea...it's like the phone company or some shit
<chillywilly> bouncing me around
<chillywilly> weee
<ivoks> BenC: hi
<ivoks> BenC: i have a patch, if you would like to look at it
<BenC> email it, bcollins@ubuntu.com
<BenC> I'll be gone for about an hour
<ivoks> BenC: http://www.grad.hr/~ivoks/ubuntu/jmicron-ich8.diff
<ivoks> ok
#ubuntu-kernel 2006-09-24
<ph8> ivoks
<ph8> you left 
<ph8> my internet died
<ph8> i'll try the daily tomorrow
<ph8> i really hope the new kernel's made it into the installer then
<ivoks> ph8: ok, but CD won't work
<ivoks> as i said, i tried with latest kernel
<ph8> tomorrow's...
<ph8> i see
<ivoks> anyway, i'm going off and will try tomorrow with this patch i created today
<ivoks> good luck
<xopher> Hi! Any ideas on what I should do if I wish to build a linux-restricted-modules for a specific kernel-version? Ive tried, well everything I can come up with, and it still compiles according to the newest available, instead of the one I want. I cannot use 9-generic because it panics for me. (amd64)
<AnAnt> is the usplash issue fixed ?
<Mithrandir> xopher: poke the values in debian/rules ?
<xopher> Mithrandir, I have poked around quite a bit. Ive replaced _every_ value that indicated to 9-generic with 8-generic
<Mithrandir> xopher: you want to do debian/rules debian/control too
<xopher> well I used grep to search the whole debian dir, so Ive gone through all the files
<xopher> I even tried a different approach, I edited the diff.gz, changing even the @@KVERSION@@ and @@ABIVERSION@@, still looks for 2.6.17-9-generic :/
<xopher> Its not that vital that I get this working, just really want to know how this is done now :) Took me the whole day yesterday trying to get it compiled correctly
<BenC> xopher: there's a page on the wiki explaining how to rebuild the kernel
<xopher> BenC, well Im not trying to rebuild the kernel, Im trying to build linux-restricted-modules for a specific kernel version. I doubt rebuilding 9-generic would make it boot for me ? As it panics for me atm.
<BenC> xopher: edit debian/rules, change abi to 8, and dpkg-buildpackage -b -rfakeroot
<xopher> ok, Ill try once more. Using pbuilder/pdebuild shouldnt affect this right?
<ph8> 5 minutes and i'll has tested today's daily 
<ph8> * have
<xopher> Does today's daily differ from 9-generic? Are there changelogs for dailys?
<ph8> yes
<ph8> erm
<ph8> well
<ph8> you have to check each individual package
<ph8> the packages included are in the .list @ cdimage.ubuntu.com
<ph8> BenC: Do you know if we have to set certain bios settings to fix the sata detection bugs?
<ph8> like ahci instead of ide?
<ph8> and the latest install cd still doesn't find a cdrom drive :/
<ph8> what was that zcat command to check the installer kernel version?
<ph8>  lib/modules/2.6.17-8-generic/kernel/ ... that's the most recent right?
<ph8> the one that should be working?
* ph8 mounts BenC
<xopher> ph8, -9-generic is the most recent one
<xopher> BenC, ok, I believe I got it working now, had to put -d in debbuildopts, or it would fail on a dependency issue for 9-generic. Even there's nothing (I can think of, thats pointing at 9-generic). Thanks for your help.
<svu_tv> BenC, I hate to tell you - but .iso 2309 does not work either :/
<svu_tv> (with PPC G5)
<ph8|2> Mithrandir: Sorry to bother, i was wondering if you could tell me whether the installer has the latest (fixed?) kernel? i'm still having problems.. :/
<Mithrandir> ph8|2: you can check it yourself, you know.
<ph8|2> erm
<ph8|2> well
<ph8|2> i was aware
<ph8> I *think*
<ph8> but do you know if -8 is the latest?
<Mithrandir> look at the publishing history for linux-source-2.6.17 on launchpad
<ph8> if not, is there any way for me to update it? and/or will you know when it makes it into the dailies?
<ph8> i've just noticed the topic actually
<ph8> -9.23 = fixed
<ph8> but zcat initrd.gz | cpio -i shows lots of -8 references
<Mithrandir> hmm, might need a d-i upload then
<ph8> sounds like a plan?
<ph8> ;)
<ph8> wish i could do something to help 
<ph8> do you think it would be possible to get one today? or would it be ready as soon as tomorrow? I've got about two days to get this going before i have to cart it cross-country and back and the cost goes up++
<Mithrandir> I've asked our d-i guru about whether it needs an upload or not
<ph8> ty - is he activeish?
<ph8> test
<ph8> looks like my connection's just holding on :p
<ph8> Mithrandir: If he was to go 'oh yes it does' and do one, would it get into a daily today? or am i looking at a long wait?
<Mithrandir> it'd go into tomorrow's, but I'm not sure I'll see a response today -- he's busy with moving house.
<ph8> :s ok thx, looks like you guys are leading the way with this bug - i can't find another distro it works in
<Mithrandir> zul: so, I get my xen domains starting, but they seem to be unable to connect to xenstored and give me "XENBUS: Timeout connecting to device: device/vbd/2049 (state 3)" when I modprobe xenblk in the initramfs.
<Mithrandir> zul: any ideas?
<ph8> #ubuntu+1 Hoping for some help guys, if I was trying to build my own ubuntu install CD, which requires a copy of the debian installer ubuntu uses as well as the kernel etc, where would i find the installer?
<ph8> erm
<ph8> whoops
<ph8> Hoping for some help guys, if I was trying to build my own ubuntu install CD, which requires a copy of the debian installer ubuntu uses as well as the kernel etc, where would i find the installer?
<ph8> strange
<ph8> Mithrandir: Don't suppose you got a reply from that chap? :s
<Mithrandir> ph8: "apt-get install debian-installer"?
<ph8> lol.
<ph8> cheers :)
<ph8> i was searching for variations of d-i
<ph8> i hope this works or i'm in the proverbial shit :/
<zul> Mithrandir: havent seen that one before
<zul> because i dont modprobe anything in the initramdisk if i can recall
<Mithrandir> zul: hmmkay.  I'll try building a domU with somewhat less shit, then
<ph8> Mithrandir: Did you get a reply from the d-i maintainer bloke?
<zul> you mean dom0 didnt you?
<Mithrandir> ph8: no.
<Mithrandir> zul: no, I thought it was the domUs which didn't need all kinds of drivers compiled in?
<zul> domU is your guest kernel
<zul> dom0 is the one your boot your pc with
<Mithrandir> yes, I know that.
<zul> oh..
<zul> heh maybe i should go back to bed then
<ph8> I've got plenty of use for you if you're bored zul... :)
<ivoks> it looks like sata disk connected to jmicron will boot with -9-386
<ivoks> true, it takes 5 minutes, but it does boot
<ivoks> still, we don't have support for IDE part od jmicron controller
<ivoks> and no, ich8 doesn't work
<ivoks> with my patch, kernel boots normaly
<ivoks> (no IDE jmicron, yet and no ICH8)
<mjg59> ivoks: Can you please put an lspci of your system somewhere?
<ivoks> mjg59: sure, i'm waiting it to boot up :)
<mjg59> ivoks: Cool
<ivoks> it has jmicron sata controller, jmicron ide controller and ich8 sata controller
<ivoks> i'll be back
<ivoks> joy! it works!
<ivoks> mjg59: lspci: http://www.grad.hr/~ivoks/ubuntu/LSPCI
<ivoks> mjg59: lspci -vvv: http://www.grad.hr/~ivoks/ubuntu/LSPCI-vvv
<ivoks> for IDE to work, we need aditional driver in kernel
<ivoks> ahci handles only SATA part of jmicron, for IDE part we need jmicron.c
<ivoks> can be found in 2.6.18-rc7-mm
<ivoks> 2.6.18-rc7-mm also contains fix for ICH8, but inside new libata
<ivoks> :/
<ivoks> i guess it's a known issue that ubuntu-desktop depends on universe packages :)
<BenC> ivoks: Then we have a different bug
<BenC> one in which ide-generic isn't grabbing legacy IDE ports
<BenC> because it should handle JMicron IDE without that jmicron.c
<ivoks> BenC: i'm not kernel expert, so i guess you are right
<ivoks> the fact is that it works with that jmicron.c and is trivial to import it
<ivoks> that driver also states that it's for basic functionality
<BenC> ivoks: Can you see if ide-generic is loaded without the jmicron module on there?
<ivoks> BenC: atm i don't run with kernel with jmicron.c
<BenC> if it isn't, can you "modprobe ide-generic" and see if that works?
<ivoks> but i'll create it today and i'll be able to test it
<BenC> ivoks: No, try it without that module
<BenC> just use our livecd or something
<mjg59> ivoks: lspci -n would be good
<ivoks> BenC: it discovers nothing
<ivoks> mjg59: ok
<ivoks> mjg59: lspci -vvv: http://www.grad.hr/~ivoks/ubuntu/LSPCI-n
<ivoks> beh..
<ivoks> lcpsi -n
<mjg59> It's possible that ide-generic isn't being autoloaded
<BenC> ivoks: I don't care about "nothing", I just care about ide-generic being loaded or not
<BenC> yeah, that's what I'm worried about
<ivoks> BenC: it loads on start
<ivoks> BenC: from initrd
<mjg59> ivoks: How do you know?
<BenC> lsmod | grep generic
<BenC> see if it's loaded
<ivoks> mjg59: Probing IDE interface ide0...
<ivoks> ide_generic             2432  0 
<ivoks> generic                 6148  0 
<mjg59> Oh, hang on, yeah. It should be generic.
<BenC> ivoks: what does it say about the ports on ide0?
<mjg59> Not ide-generic.
<ivoks> BenC: that's only output i get with ide0
<mjg59> ivoks: Can you rmmod generic; modprobe generic and then see what appears in dmesg?
<ivoks> dmesg | grep ide0
<ivoks> mjg59: nothing
<mjg59> ivoks: Nothing? At all?
<ivoks> at all
<ivoks> with ide-generic
<mjg59> No
<mjg59> generic
<ivoks> with generic nothing, with ide-generic i get onli Probing... for ide0 and ide1
<ivoks> hate this keyboard
<mjg59> generic really should claiming it
<mjg59> What do you have connected?
<ivoks> cdrom
<mjg59> Was generic autoloaded?
<ivoks> can't tell for sure...
<mjg59> Well, did you load it first?
<ivoks> no
<mjg59> Then it was presumably autoloaded
<ivoks> there's no other explanation
<ivoks> btw... with default initrd, system boots slowly
<mjg59> We'll worry about that later
<ivoks> problem is in r1000 wich crashes and kills modprobe
<mjg59> BenC: I can't see any obvious reason why generic would fail to bind usefully
<BenC> is this with -9?
<ivoks> BenC: yes
<BenC> because -8 I can understand it doing that
<ivoks> BenC: compiled with -9-generic and netbooted
<BenC> you compiled -9-generic, or you mean you rebuilt the netboot?
<ivoks> i compiled -9-generic and booted installation with it, over netboot
<BenC> ...using the -9-generic in the archive
<BenC> compiled it from where?
<BenC> using git or linux-source-2.6.17 9.23?
<ivoks> apt-get source linux-image-2.6.17-9-386 ; cp /boot/config*-generic .config
<ivoks> make ; make modules_install
<ph8> ivoks: I'd love you forever if you can help me get my system booting..!
<BenC> grep ide0 /proc/ioports
<BenC> tell me what that says
<ivoks> nothing; no output
<BenC> grep ide /proc/ioports; grep ide /proc/iomem
<ivoks> 000a0000-000bffff : Video RAM area
<ivoks> 000c0000-000cebff : Video ROM
<ivoks> that for iomem
<mjg59> BenC: If generic isn't claiming it, there'll be nothing there
<mjg59> And the use count of generic is 0, which isn't a good sign
<BenC> I wonder why it would probe it, but not actually see anything
<BenC> this sounds an aweful lot like the bug that the jmicron patches in -9 were supposed to fix
<BenC> ivoks: dmesg | grep -i jmicron
<mjg59> ivoks: Can you do sudo modinfo -F alias generic and paste the output somewhere?
<ivoks> BenC: no output
<ivoks> mjg59: www.grad.hr/~ivoks/ubuntu/alias
<ivoks> sorry, i'm in console :/
<mjg59> Ok, so generic is being loaded
<ivoks> i'm afraid i have to go now
<mjg59> So possibly the PCI quirk that puts it in dual function mode is broken
<ivoks> but i can ssh to this machine from home
<mjg59> Or possibly it still depends on the jmicron driver being loaded to set that up
<ivoks> so i can give any info that's needed
<mjg59> ivoks: Are you able to provide us with remote access?
<ivoks> mjg59: sure
<ivoks> as soon as i find free IP address :)
<mjg59> Heh
<mjg59> Ok
<BenC> mjg59: jmicron told me that fixup was all that was needed
<ivoks> i'll be back.. IP change
<mjg59> Ok. Well, it's plainly not working right now...
<ph8> perhaps all that was necessary ben?
<ph8> at least sata's appear to work with ahci compatibility set, that means you can install from usb disk
<BenC> I think all you jmicron guys are just going to have to wait till I get my eval board and can actually test this stuff
<ph8> well, if 9 solves it as implied above ^ that's good enough to work with until it gets fixed properly... the kernel just isn't in d-i atm and i'm told that could take days :(
<mjg59> We're in beta freeze
<mjg59> It'll be fixed before release of the final distribution. Other than that, there's no way to provide definite timing information
<mjg59> BenC: Do we not have support for the ICH8 sata?
<BenC> mjg59: We should, but it's something else I have to test, because reports imply it doesn't work
<BenC> I backported a lot of stuff for ich8 into -9
<mjg59> If I can get access to ivoks's machine, I'll do some quick sanity checks
<BenC> mjg59: btw, I have a core duo laptop now, but unfortunately, everything seems to work perfectly so it did me little good :)
<zul> *sigh*
<mjg59> BenC: Ha
<kylem> zul?
<zul> BenC: heh thats ironic
<zul> kylem: heh rt2x00 cards are giving me grief
<kylem> ah.
<mjg59> Hm. The PCI IDE setup code is static.
<mjg59> Wait.
<mjg59> Oh, yeah.
<mjg59> Wait a moment.
<mjg59> Where did pata_jmicron come from?
<ivoks> from me
<ivoks> but i don't use it
<svu_tv> BenC, did you see my msg about failure on G5 (again)? Need any help/info?
<mjg59> ivoks: If I reboot this machine, will it come back up? :)
<ivoks> mjg59: probably not :)
<mjg59> I just tried to unload that, and it oopsed the kernel
<ivoks> mjg59: wait a second
<mjg59> Having pata_jmicron there is likely to confuse things
<ivoks> so, do you want me to boot real -9-generic?
<mjg59> Will that boot?
<mjg59> If so, yeah
<ivoks> i'll try
<mjg59> Ok
<mjg59> Thanks!
<zul> have you guys tried passing ide-generic?
<mjg59> zul: I'm not convinced it's wired up as a legacy controller
<mjg59> We'll get to that
<ivoks> mjg59: booting
<BenC> svu_tv: no
<ivoks> brb
<mjg59> ivoks: Ta
* mjg59 goes to try to find a drink quickly
<zul> back later have to go clean the house
<doko_> fabbione, BenC: debian#389225
<ivoks> hrmph...
<ivoks> mjg59: i tried :( but no-go
<ivoks> mjg59: there is strace of crash in syslog
<ivoks> um...
<svu_tv> BenC, g5 still does not boot (.iso 2309) - still error messages from hda
<ivoks> mjg59: ignore that, there isn't strace of crash
<mjg59> ivoks: Mm?
<mjg59> ivoks: Where does it crash?
<ivoks> it detects disk, loads USB modules
<ivoks> and then crashes
<ivoks> right after usb modules
<mjg59> ivoks: What does the trace look like?
<ivoks> note: in initrd i have only modules related to disk
<ivoks> mjg59: checkout syslog
<mjg59> ivoks: No, that's from when I unloaded pata_jmicron
<ivoks> mjg59: i know, but something like that
<mjg59> ivoks: No, very unlikely to be like that
<ivoks> BUG: Unable to handle kernel paging request at virtual address 00003020
<mjg59> Right
<mjg59> It's the call trace that's important
<ivoks> ok, i can reboot and take a picture
<ivoks> gr... i can't do that :/
<ivoks> but i can write it down
<mjg59> Ok
<ivoks> stay tuned for news... :)
<ivoks> i was writing it down, and then it booted all the way :)
<ivoks> but no network :/
<ivoks> so, it's in syslog
<BenC> svu_tv: Latest ISO's are not using the new kernel
<mjg59> Ok
<mjg59> ivoks: So is it up now?
<BenC> svu_tv: The installer hasn't been rebuilt yet
<ivoks> mjg59: modified kernel, not the default one :/ 
<mjg59> Ok, got it
<ivoks> mjg59: but you have trace of crash in syslog
<ivoks> line 2198
<mjg59> Oh, that's fun
<mjg59> Now, why is it crashing there...
<mjg59> BenC: It's dying during generic_probe_one
<mjg59> BenC: Which might well explain things
<mjg59> BenC: http://pastebin.ca/181214
<mjg59> ivoks: Can you try booting 2.6.17-9-generic with pci=nobios as a boot option and see if it crashes in the same way?
<ivoks> sure
<ivoks> brb
<BenC> or even nosmp might be something to try
<BenC> that is a weird crash
<mjg59> A word is 16 bits, right?
<mjg59> Yeah
<BenC> yeah, dword is 32
<mjg59> And there's no weird context issues...
<mjg59> Oh, god knows what's up there
<mjg59> But anyway, that's why generic isn't working on -9-generic
<mjg59> (In this case, at least)
<mjg59> Anyway, they're throwing us out
* mjg59 goes
<BenC> I wonder if it's special to this case, or if it's in general broken
<BenC> later
<ivoks> 2.6.17-9-generic
<mjg59> ivoks: Mm?
<ivoks> it crashed again, but after loading r1000, so i have network now
<mjg59> ivoks: Same crash?
<ivoks> not the same
<ivoks> check it out 
<mjg59> No, that's the same crash
<mjg59> Except it's going through pci_conf1_read rather than pci_bios_read
<mjg59> So that's irrelevant
<mjg59> Right
<mjg59> Have to leave now
<mjg59> Networking going away
<ivoks> ok
<zul> grrr...
<zul> we have new neighbors next door and we thought they were doing construction but noooo they have a drum kit going full blast 
<kylem> zul, what part of the city are you in?
<zul> kanata
<kylem> ah, isn't there like, bylaws against fun there?
<kylem> :)
<zul> yeah there is, its called i wanna nap in the basement and you are rattling my couch
<zul_> ooh...ringo star has stoped
<svu_tv> BenC, ghm, it is not installer, it was a kernel booting cd live
<svu_tv> BenC, anyway, when could we expect ISOs with new kernel? next week?
<ph8> if i have a built version of -9 (from another edgy system), should i just be able to overwrite the one that my debian installer uses or is it more complicated than that?
<gnomefreak> svu_tv: beta gets release this week should have the -9 kernel
<svu_tv> gnomefreak, cool. looking forward. Actually extremely eager to get it in .iso :)
<ivoks> hi ph8 
<ph8> hi!
<ph8> just updated my lappy to edgy
<ph8> little bumpy, the new intro music is way cooler though
<ivoks> :)
<ph8> i hear you've got a working something-or-other
<ph8> i was *really* hoping you'd consider putting your install cd source online?
<ph8> especially after my connection messed up our netboot attempt last night
<ivoks> there's no source
<ivoks> i did netinstall
<ivoks> CD isn't working, but SATA disk on jmicron port is working
<ph8> did you have a special kernel with the drivers for the network card in though?
<ph8> that would be ideal :)
<ph8> cd was only needed for installing
<ivoks> i wouldn't advise you to go trough install
<ivoks> grub doesn't work for me
<ivoks> i'm booting machine over network :/
<ivoks> but if you want, i can guide you
<ph8> so what doesn't work as expected? not just the cd drive?
<ph8> i'd be wanting to setup two satas in a software RAID array
<ivoks> ich8 doesn't work too, grub doesn't work
<ph8> how are your satas connected to the p5b?
<ivoks> ph8: jmicron has only one internal sata port
<ph8> ah i see
<ph8> so ich8 is still broken?
<ivoks> other 4 ports are from ich8
<ivoks> yes
<ph8> darn
<ph8> that's with -9?
<ivoks> yes
<ph8> k
<ph8> i'll have to expend some cash on the old train in a couple of weeks then!
<ivoks> ph8: one bug at the time :)
<ph8> that's a shame
<ph8> do you know how the fix is progressing? will it be ready in a couple of weeks?
<ivoks> i'm sure it will be fixed for the release
<ivoks> i can't tell you exact date
<ph8> that's end of october though right?
<ivoks> i'm not kernel developer, i'm just interested party
<ph8> just wondered if people knew exactly what was wrong and how to fix it
<ivoks> i know how to make CD work
<ivoks> the thing i need now is ich8
<ivoks> BenC: here?
<ph8> i'll watch avidly i guess now i've resigned myself to the trip back down to london, thanks for all you've done so far
<ivoks> well... i lost whole day working around this
<ivoks> and i have exam tomorrow :)
<ivoks> anyway...
<ivoks> BenC: http://lkml.org/lkml/2006/7/11/493
<zul> BenC: ping
<zul> Mithrandir: ping
<zul> Mithrandir: can you possibly merge changes into the git please? Thanks..
<zul> yippe skippe...xen-image-xen0-2.6.17-1-generic_2.6.17-1_i386.deb
<ivoks> woho!
<ivoks> to late to merge? :)
<zul> no i have til thursday
<ivoks> so... we could have xen by default? :))
<zul> no...this is in universe
<ivoks> eh... :/
<zul> seperate kernel
<zul> brb need to reboot
<ajmitch> ivoks: too much pain & suffering to have it by default
<ivoks> i know...
#ubuntu-kernel 2007-09-17
<kraut> moin
<ogra> BenC, hey, could it be that linuc-ubuntu-modules is a bit out of sync ? seems people using ltsp with unionfs/squashfs/nbd setup are seeing a lot of unionfs noise in the dmesg outputs since the swithc from 2.6.22-10 to -11
<mjg59> ogra: unionfs is currently broken
<ogra> yeah, ltsp users are moaning :)
<ogra> mjg59, thanks for the info 
<soren> AFAIUI the netconsole stuff in the kernel is only one-way. It's only good for spewing kernel output and such to a remote host.. Is there a more full featured mechanism for setting up a "real" networked console (if the hardware doesn't have it built in, obviously)?
<BenC> ogra: everyone is moaning :)
<ogra> heh
<ogra> well, it seems to do any harm on thin clients at least apart from filling the logs with oopses :)
<ogra> s/seems/seems not/
<ogra> but then a thin client doesnt do any more with it but booting :)
<\sh> BenC, btw...are you enabled hugetbl fs by default as module in the next kernel release?
<\sh> s/enabled/enabling/
<BenC> \sh: it's not modular
<\sh> BenC, right ;) so it's enabled by default?
<BenC> no, not on i386
<\sh> BenC, but on amd64...that's whats more important ;)
<BenC> only on sparc and powerpc
<\sh> BenC, I filed a but about it on amd64...this is important for java devs on x86_64 ...
<\sh> BenC, it enabled ibm java etc. to use largepages support
<\sh> s/enabled/enables/
<\sh> BenC, bug 122800 :)
<ubotu> Launchpad bug 122800 in linux-source-2.6.22 "Please consider enabling HugeTBLFS for Gutsy " [Wishlist,Triaged]  https://launchpad.net/bugs/122800
* BenC notes wishlist, and pending beta freeze in 3 days
<BenC> \sh: we'll do our best
<\sh> BenC, it was reported 2007-06-28 :)
<\sh> when I tested feisty with our java backend on amd64
<BenC> \sh: point taken, but it's still 3 days till beta :)
<BenC> beta freeze I mean
<\sh> BenC, using my self made 2.6.22.2 it's working perfectly...and when it's enabled via kernel paramenters (sysctl.conf) it works more perfectly..but it's not needed by default, only when you use this feature
<BenC> rtg: rebooting in a sec to test the new iwlwifi
<rtg> Big fire yesterday afternoon, my mirror isn't up to date. No power until this morning.
<BenC> rtg: fire at your place?
<rtg> No, downwind a few hundred yards.
<rtg> Burnt up some power lines.
<rtg> (and a bunch of houses)
<BenC> rtg: nasty
<ogra> rtg, hey, mn works fine with WEP and the rt73 driver in gutsy (have no WPA networks here so i only can test WEP and unencrypted)
<ogra> s/mn/nm/
<rtg> So, lum and kernel et al are in the archive?
<BenC> rtg: kernel is, I'm giving pkl some time to fix unionfs before we do lum
<rtg> ogra: rt73 works? I'm amazed.
<BenC> so am I
<BenC> ogra: works with n-m too?
<ogra> yep
<mjg59> acx100 seems to have broken again for some reason
<mjg59> I managed to lose my hardware for that, which is a pain
<ogra> on a minimally local install on the classmate ... tested on the weekend 
<rtg> ogra: I have a CMPC. Do you have directions and/or an image somewhere? I can test WPA.
<JanC> aren't all those rt* bugs concurrency issues, so not always reproducable ?   ;)
<ogra> rtg, i dont have any gutsy image yet ... mdz moaned about my decision to take a squashfs image for that thing, i'm waiting on a meeting for a proper decision
<rtg> ogra: np. 
<BenC> rtg: iwlwifi seems to be working ok for me
<BenC> $ lsmod | grep mac
<BenC> iwlwifi_mac80211      174856  1 iwl4965
<BenC> cfg80211                7304  1 iwlwifi_mac80211
<rtg> BenC: have you tried WPA, suspend/resime hibernate, etc.
<BenC> only thing I've done is connect via WEP
<rtg> If it compiles, ship it :)
<rtg> BenC: you won't forget debian/control-scripts/* will you?
<rtg> Seeing activity on the DKMS bug reminded me.
<BenC> rtg: err, I did forget
<BenC> I'll work on that today and get an upload out tomorrow for it
<rtg> Its important.
<BenC> yeah, critical in fact
<zul> how is the dkms revu coming in universe coming?
<rtg> zul: https://bugs.edge.launchpad.net/ubuntu/+bug/121676. He is banging away at it.
<ubotu> Launchpad bug 121676 in ubuntu "add DKMS to Ubuntu" [Wishlist,Incomplete]  
<zul> well if it needs a uvf for universe let me know since im on the uvf team i can get it rammed through
<BenC> rtg: interestingly enough, I seem to be getting 85% signal now instead of ~75% like I was before
<rtg> BenC: The real indicator is 'at what bit rate does it run?' and  'with how many retries?'. Ultimately throughput is the goal. Signal level can be quite misleading.
<BenC> rtg: 2.2M/sec transfer over scp
<rtg> Mbit/sec?
<BenC> Megabytes
<BenC> scp doesn't report mbits :)
<rtg> BenC: Thats not too bad. Is it better then before?
<BenC> connected at 54g
<BenC> rtg: before was about 1.8M/sec
<BenC> rtg: so far, no invalid packets reported in iwconfig
<rtg> BenC: You should set up a loop and run some sustained bulk transfers. Maybe we can close the hiccup bug.
<rtg> BenC: I'll do the same.
<BenC> rtg: and more importantly, my dmesg isn't being flooded with operational messages :)
<rtg> BenC: sounds like 2 steps forward. 
<BenC> rtg: only problem so far is the lack of wifi led
<BenC> I need to see what I can do to make ieee80211_led.c compile in this new mac80211
<BenC> it was expecting some new led interfaces in the kernel I think
<rtg> I think it was a config option. I might not have turned it on.
<BenC> I tried enabling it, but the compile failed
<rtg> BenC: The iwlwifi pile is  backport from 2.6.23-rc*, so it might not compile.
<zul> anyone got an opinon on bug 139881
<ubotu> Launchpad bug 139881 in linux-source-2.6.22 "hdaps_protect patch to enable disk head parking on thinkpads" [Undecided,New]  https://launchpad.net/bugs/139881
<mjg59> It would be nice if someone would actually get it into a state where it'll be accepted upstream
<BenC> zul: Yeah, the patch is useless without userspace to support it
<mjg59> BenC: There's userspace in the archive
<BenC> mjg59: ah, last I heard it wasn't there
<BenC> mjg59: but I also remember that the patch is pretty intrusive
<mjg59> Yes, it's pretty nasty looking
<zul> Ill just leave it then
<afs> hi! I'm trying to compile qemu but it can't find /usr/include/linux/compiler.h. This include file belongs to package linux-headers-2.6.20-16-generic, but ends up in /usr/src/linux-headers-2.6.20-16-generic/include/linux/compiler.h. Is this normal behaviour?
<soren> afs: It's an empty file, IIRC? Could you check that?
<BenC> afs: add -I/usr/src/linux-headers-`uname -r` to your CFLAGS in qemu
<afs> tried that, didn't work (suspect that's a qemu bug)
<afs> /usr/include/linuxcompiler.h is not an empty file on debian
<rtg> BenC: have a look at the changelog for iwlwifi 0.1.16. I'm testing his updates. It might fix an iwl3945 RF kill issue.
<soren> do any of our kernel flavours have HZ=1000? 
<abogani> soren: Rt kernel have it
<soren> abogani: Sure? It's not at 250?
<abogani> soren: yes i'm sure.
<soren> abogani: Ok. Thanks.
<abogani> soren: :-)
<BenC> soren: HZ= doesn't make sens with our stock kernel, because it has dynticks
<JanC> hm, on all architectures?
<mjg59> BenC: My understanding is that it still affects the base timer granularity
<mjg59> HZ=1000 on i386 would make sense
<BenC> we got too many complaints about battery usage when we did that
<BenC> and we have quite a few laptop models that fall into the AMD broken ioapic timer category
<mjg59> Yes, but dynticks avoids that being an issue
<mjg59> When the system is idle, you still get the power savings
<Nafallo> mjg59: my acer died ;-)
<mjg59> And when it's active, it's no worse
<Nafallo> mjg59: just thought you might want to know ;-)
<mjg59> Nafallo: I'm shocked
<Nafallo> hehe
<BenC> mjg59: but the broken ioapic timer's don't get nohz, so they'll suffer
<Nafallo> I've ordered a Dell D630 again :-P
<mjg59> BenC: Uh. That shouldn't be the case.
<mjg59> BenC: Lacking the apic timer isn't a blocker to nohz
<BenC> mjg59: on the amd laptop I have, I had to add nolapic_timer nohz=on to get it to boot
<BenC> I meant lapic timer
<mjg59> Then there's a bug somewhere
<BenC> nohz doesn't like not having lapic timer
<mjg59> BenC: I think limiting functionality in the name of providing a small increase in battery life on broken hardware is less than ideal
<mjg59> But I was also under the impression that the turion issue had been fixed without the need to disable the lapic timer (the issue was that the code was incorrectly thinking that the timer continued in C2, which it didn't)
<BenC> maybe I misunderstood the patch then
<BenC> I can't tell if dynticks is enabled or not...is there a file in sysfs that will show that?
<mjg59> Not sure
<mjg59> You can work it out from /proc/timer_list, I think
<BenC> there's a nohz_mode...guess I can check the expected values for that
<BenC> running on intel now
<verwilst> hi!
<verwilst> oh, they're in universe!
<verwilst> carry on people ;)
<rtg> mjg59: Do you only need the first 2 bytes of a hotkey to map it? For example, the windows media key on an XPS M1330 emits e0 5b e0 db.
<superm1_> is this commit toward unionfs supposed to be resolving the issue on the currently daily builds, or is that coming in a later build? http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-gutsy-lum.git;a=commit;h=2289191572cbb20dc4db387cc079e79f003a3bf2
<rtg> superm1_:  Phillip is still working on it.
<superm1_> rtg, okay cool thanks :)
<mjg59> rtg: e0 means it's an extended scancode, 5b is the mapping, db is the release
<mjg59> We need e05b for the mapping
<rtg> mjg59: thanks.
<mjg59> Does it not already generate a keycode under X?
<rtg> mjg59: It does, I was juts trying to figure out the mapping using 'showkey -s'
<mjg59> Ah, ok
#ubuntu-kernel 2007-09-18
<r3pek> hey!
<r3pek> any dev around?
<IntuitiveNipple> >/dev/null :)
<r3pek> :P
<IntuitiveNipple> sorry... I couldn't resist :)
<S0me1> hi
<S0me1> Can  i ask?
<bdmurray> S0me1: ask what?
<S0me1> why ubuntu developers fix winmodem issue on some laptops such as Dell XPS?
<mjg59> I don't understand the question?
<mjg59> Oh, you mean the hsfmodem drivers?
<mjg59> We don't have permission to distribute those. Dell do.
<S0me1> mjg59: Dell is sleeping :)
* mjg59 shrugs
<mjg59> I suspect that questions about those may have to go to Dell. I'm not sure what the support situation is in that respect.
<S0me1> but that's mean if you have permission you can do it !!
<mjg59> We don't have permission. 
<mjg59> So we can't
<S0me1> :) OK
<S0me1> I am sure ubuntu kernel they can fix this issue , but there is a policy from DELL
<mjg59> No, we can't
<mjg59> The copyright holder (Linuxant, not Dell) have not granted us a license
<S0me1> mjg59: have ubuntu team try get granted license from Linuxant 4 ubuntu users?
<S0me1> why not try ask them ?
<mjg59> I did, a year ago
<S0me1> and what they said?
<mjg59> I never got a reply
<S0me1> sorry for my question ... but this very important for me I tried find-out solution ... this is why i am asking you
<mjg59> But given that they charge money for it, I suspect we'd never be able to distribute it for free
<IntuitiveNipple> S0me1: I found the Linuxant drivers mess up the snd-hda-intel and report a shed-load of unhandled events, so I dropped them
<S0me1> I see ... I think they never want work with you in this issue ... 
<S0me1> anyway guys ... nice chatting with you 
<S0me1> nice to meet you :)
<lamont> 	kernel-wedge copy-modules 2.6.22-11 hppa64 2.6.22-11-hppa64
<lamont> missing module serpent
<lamont> http://launchpadlibrarian.net/9335614/buildlog_ubuntu-gutsy-hppa.linux-source-2.6.22_2.6.22-11.33_FAILEDTOBUILD.txt.gz
<lamont> OTOH, that was a build in the data center...
<lamont> is there going to be another kernel upload this week, I wonder?
<fabbione> isn't there a -12 already ?
<fabbione> oh no
<fabbione> never mind
<defendguin> ubuntu just pushed out an update to the synaptics package and now the side scroll on my touchpad doesn't function 
<defendguin> gutsy of course
<mjg59> defendguin: system/preferences/mouse
<defendguin> ha i didn't even think to look and see if it had been disabled 
<defendguin> sorry mat
<defendguin> wow and tap to click wasnt working either   i certainly hope that isn't supposed to be the default behavior after the update
* Starting logfile irclogs/ubuntu-kernel.log
<john> anyone there
<kraut> moin
<Nafallo> what did I do when I got that irq x: nobody cared again?
<zul> use irqpoll
* Nafallo tries
<Nafallo> thanks zul
<BenC> pkl_, amitk, rtg, kylem: getting ready to do another kernel upload. Any last minute patches you guys know of that need to be in?
<BenC> lamont: did you check on the hppa ftbfs? I noticed it, but didn't look into it
<kylem> BenC, nyetski on my end.
<amitk> mjg59: ping for the usb-autosuspend-disable patch
<amitk> BenC: nada
<BenC> kylem: good morning...any comment on bug #119976?
<ubotu> Launchpad bug 119976 in linux-source-2.6.22 "All the task previous are killed after resumed from S3 on Santa Rosa with Crestline" [High,Confirmed]  https://launchpad.net/bugs/119976
<ogra> amitk, ooohhh is that like "dont unload my usb disk if / is on it during suspend" ?
<kylem> if it only happens on the sdv and not on the production hw, i don't know what we can do
<BenC> kylem: it almost doesn't sound like a kernel bug to me either
<BenC> sounds like xorg crashing
<kylem> yeah.
<amitk> ogra: not really. It is mainly to avoid breaking a _lot_ of usb peripherals (scanners, printers, etc.) that don't deal with USB autosuspend very well.
<kylem> my 965 box suspended and resumed at least 10 times in a row last night running gears, so i really don't see what the probelm is...
<BenC> kylem: ok, can you comment on the bug, and maybe punt it over to xorg?
<amitk> ogra: is it becoming common to have / on a usb disk?
<BenC> amitk: there's a class of system where the built-in driver is a 2g usb flash
<BenC> s/driver/drive/
<ogra> amitk, well, its the case for me on the classmate 
<ogra> and i guess it will become common in the embedded world as well 
<amitk> ogra: how is classmate dealing with it currently?
<ogra> not at all, i had to disable suspend
<ogra> you can suspend/resume fine ... up to the first disk access :)
<amitk> ogra: a proper fix would probably require collating VFS mount information with USB disk information to make suspend decision...
<ogra> well, a kernel option to just suppress the unloading would suffice for a start :)
<ogra> indeed nifty autodetection etc would be cooler :)
<amitk> but that would still leave usb disks with / on them un-suspendable
<ogra> hmm
<lamont> BenC: hppa ftbfs: module "serpent" went *poof*  No clue what that module is, or if I even care if it is there...
<BenC> lamont: I can add a modules.ignore for that
<lamont> BenC: sounds good to me
<amitk> ogra: /sys/module/usbcore/parameters/autosuspend doesn't work? Or something like ./devices/pci0000:00/0000:00:1d.7/usb4/power/autosuspend?
<BenC> lamont: config CRYPTO_SERPENT
<ogra> it didnt in feisty, i didnt try with gutsy yet .... 
<lamont> heh - I was half way guessing that would be a crypto module
<lamont> it was either that or an I/O card
<BenC> ogra: remember feisty didn't have that mod param...maybe it'll work for gutsy with that
<ogra> BenC, i'll try it later today
<BenC> lamont: hmm, the config option doesn't have any deps...no idea why it went missing
<BenC> might be better to re-enable it
<lamont> re-enabled is fine too
<lamont> I got it: let's do both. :)
<lamont> that way if there's another, it'll at least build
<lamont> or does the modules check dump all of them before barfing?  as opposed to just the first one
<amitk> ogra: aahaa.. you tried this on feisty.
<BenC> lamont: it dumps all
<ogra> amitk, yeah, until recently i had no working gutsy image 
<BenC> lamont: plus modules.ignore is a list of modules, not a blanket ignore of failures
<lamont> cool.  IIRC it does hppa32 before hppa64, and abi before modules, so that should be the  only issue in the build
<lamont> oh
<lamont> yeah - renable sounds good.
<lamont> do you have an hppa box to play with?
<BenC> lamont: was enabled in hppa32, re-enabled in hppa64, and updateconfigs leaves it intact
<BenC> so this should be good for hppa to get built today
<lamont> cool
<lamont> atm linux-source-2.6.22 will fall into a pool of ~340 packages at the same pri in queue-mangler
<lamont> hrm.. that reminds me... need to get some stuff pushed from universe
<rtg> BenC: the only thing I might have is sky2 fixes.
<BenC> rtg: ok
<rtg> BenC: still waiting on Stephan. I'll bug him this morning.
<BenC> reminder, we have a kernel team meeting at 1600 UTC
<zul> yippe skippe
* lamont heads to the office
<mjg59> amitk: Ok, will dig that out
<tepsipakki> hey, I've filed a but against the gutsy kernel since it (?) claims that the flashdisk in my camera is corrupt, but the same happens with feisty kernel. Should I reassign it to another package?
<tepsipakki> it works in feisty proper
<tepsipakki> bug 134477 if interested :)
<ubotu> Launchpad bug 134477 in linux-source-2.6.22 "reports corrupt filesystem on flash-media, fine on feisty" [High,Confirmed]  https://launchpad.net/bugs/134477
<soren> tepsipakki: "the same happens in feisty" vs. "fine on feisty"?
<tepsipakki> soren: with feisty kernel on gutsy
<tepsipakki> but a real feisty installation is ok
<soren> tepsipakki: Ah, ok.
<tepsipakki> so I'm wondering if it's a kernel bug at all, but somewhere else
<tepsipakki> my wife is pissed off because I can't get the pictures from it :)
* soren doesn't know
<BenC> tepsipakki: if the difference between working and not working is userspace, then blame userspace :)
<BenC> tepsipakki: where do you see that it is corrupted? dmesg, gnome pop-up?
<tepsipakki> dmesg, it doesn't get mounted
<BenC> tepsipakki: can you mount it and see the files in a terminal?
<tepsipakki> no, not even fdisk works..
<BenC> tepsipakki: what filesystem?
<tepsipakki> fat16
<tepsipakki> I don't have it handy atm
<rtg> tepsipakki: Is it the same media? Perhaps flash is going bad....
<tepsipakki> but in 4h or so..
<BenC> tepsipakki: have you tried formatting it?
<tepsipakki> rtg: same media yes, bought after last Christmas
<tepsipakki> BenC: yes, worked fine on feisty
<rtg> tepsipakki: If the problem can be reproduced with another part, then it might really be a bug. Otherwise I suspect a HW failure.
<Lure> BenC: is it worthwhile to milestone bug 136257? - restart/reboot does not work on some HP laptops
<ubotu> Launchpad bug 136257 in linux-source-2.6.22 "regression: restart system does not work on HP nw8240" [Medium,Triaged]  https://launchpad.net/bugs/136257
<tepsipakki> rtg: hmm, correct. I don't have another microsd-card available, though I could buy one
<rtg> tepsipakki: The reason I say that it might be HW failure is that SD failures do not appear to be widespread. 
<BenC> Lure: yes, please, and see about testing reboot=b reboot=w reboot=h on the machine
<BenC> try each one separately
<Lure> BenC: ok, will do
<BenC> Lure: will need output of "sudo dmidecode > dmidecode.txt" as well
<tepsipakki> rtg: would that cover the fact that it works on feisty?
<soren> tepsipakki: You've seen it work in Feisty after you've seen it fail on Gutsy?
<tepsipakki> soren: yes
<tepsipakki> I've reproduced the problem on three gutsy installations, but on my office workstation (feisty) it keeps working :/
<zul> BenC: about your email what about bugs that are in 2.6.20 that are still in gutsy (ie: pci ids, etc)
<BenC> zul: add a target for 2.6.22 and milestone it for beta
<mjg59> BenC: Hi - did you see my message about msi and mmconfig?
<BenC> mjg59: no, missed that. What's up?
<mjg59> BenC: The patches we applied to feisty to alter the msi and mmconfig defaults seem to be missing
<mjg59> BenC: Was that deliberate?
<BenC> mjg59: I asked kyle about it and I forget what he said
<BenC> kylem: msi patches ^^ ?
<mjg59> BenC: Would it be possible to get the list of patches in feisty that aren't in gutsy?
<BenC> tepsipakki: I/O errors are indicative of bad media
<mjg59> BenC: Or a broken driver, but yeah
<kylem> they should be reapplied.. they weren't in the diff you sent me to bash into gutsy.
<BenC> right, but if it used to work in feisty, and now doesn't work on feisty kernel, then I suspect hw
<tepsipakki> BenC: right, I'll buy a new card (ExtremeIII this time, and bigger) and test with that
<mjg59> tepsipakki: This was SD, or compact flash?
<tepsipakki> mjg59: SD
<mjg59> Ok. No clue, then.
<tepsipakki> BenC: also, it does work on a real feisty install (not just kernel+gutsy)
<BenC> tepsipakki: see, that makes no sense to me
<BenC> feisty with gutsy userspace should not make this sort of things appear
<tepsipakki> BenC: hopefully we'll be a whole lot wiser later today :)
<BenC> tepsipakki: test a feisty and gutsy livecd if you can please
<tepsipakki> BenC: sure will
<BenC> tepsipakki: thanks
<tepsipakki> hmm, dailies are oversized (even dvd)
<mjg59> Grab a CD daily and burn it to a dvd?
<tepsipakki> oh, haven't done that yet :)
<zul> BenC: okie dokie
<BenC> rtg, pkl_, kylem: btw, activity reports were due for this morning :)
<pkl_> BenC: I'm kinda busy at the moment :)
<pkl_> BenC: I'll do a quick activity report
<rtg> BenC: Gusty debian/control-scripts/* ?
<BenC> rtg: working on it now
<amitk> mjg59: were you trying to get the isight camera working on gutsy?
<mjg59> amitk: Yeah, ought to work fine now
<amitk> bug #131222
<ubotu> Launchpad bug 131222 in ubuntu "isight does not work in ubuntu gutsy - Video for Linux 2 (v4l2): Could not get buffers from device '/dev/video0'." [Undecided,New]  https://launchpad.net/bugs/131222
<mjg59> Oh, there's a gstreamer update needed if you want to use gstreamer
<mjg59> I uploaded it but managed to bodge the package somehow. I blame its clean target
<mjg59> I'll redo that at some stage
<amitk> mjg59: so we will have that for gutsy beta then?
<mjg59> amitk: Should do, yes
<Lure> BenC: reboot=b work for bug 136257
<ubotu> Launchpad bug 136257 in linux-source-2.6.22 "regression: restart system does not work on HP nw8240" [Medium,Triaged]  https://launchpad.net/bugs/136257
<BenC> Lure: ok, with dmidecode we can force it for that specific machine
<BenC> machine type
<Lure> BenC: dmidecode is attached to bug
<BenC> Lure: thanks
<Lure> BenC: thank you! ;-)
<mjg59> Wait. We used to have reboot=b for all HPs.
<mjg59> What happened to that?
<mjg59> In fact, we still do
<mjg59> Lure: Your dmi tables are broken
<Lure> mjg59: how can I fix them?
<mjg59> Lure: Try updating your bios
<Lure> oh shit, this requires windows again :-(
<mjg59> Well, the alternative is to just always boot with reboot=b
<mjg59> There's not enough information in your DMI tables to identify your system
<Lure> mjg59: how can dmi table get corrupted, if I do not change bios?
<Lure> mjg59: interesting...
<mjg59> No clue
<bdmurray> BenC: Is there time to look at the cherry-pick tagged bug reports before Beta?
<BenC> bdmurray: should be
<BenC> bdmurray: do you have a quick link?
<bdmurray> https://launchpad.net/ubuntu/+bugs?field.tag=cherry-pick
<bdmurray> It is a short url even. ;)
<BenC> bdmurray: thanks
<bdmurray> There are also some kernel-oops tagged bugs for 2.6.22 - https://launchpad.net/ubuntu/+bugs?field.tag=kernel-oops
<BenC> bdmurray: cherry-pick list done, except one report
<BenC> bdmurray: any chance I could get you to add a list of tags we're using for the kernel to our bug triage page?
<BenC> kylem: pushed all my changes to ubuntu-gutsy, she's all yours...thanks
<BenC> kylem: abi's are all ready, just needs a insertchanges when all the patches are in
<bdmurray> BenC: What is happening with usb autosuspend?
<bdmurray> https://bugs.launchpad.net/ubuntu/+source/sane-backends/+bug/85488/comments/442
<ubotu> Launchpad bug 85488 in sane-backends "some usb_devices fault if usb_suspend enabled" [Medium,Confirmed]  
<BenC> bdmurray: there's a blacklist of devices that disable auto-suspend
<BenC> bdmurray: people are supposed to provide usb ven/dev id's for devices that need them
<bdmurray> BenC: It looks like gregkh just commit a patch to disable autosupsend though
<bdmurray> If I am reading that right.
<BenC> bdmurray: probably misreading it, autosuspend is a config option you can disable already
<bdmurray> http://git.kernel.org/?p=linux/kernel/git/gregkh/usb-2.6.git;a=commit;h=7d2c592609a7da950b458403f1936d382f38ff9c
<BenC> and in gutsy you can add a module option to disable it as well
<BenC> bdmurray: ok, let's toss that one into cherry-pick
<mjg59> BenC: No, the default upstream is to disable autosuspend for everything other than hubs
<zul> we already have that for 2.6.22
<BenC> mjg59: right, just read the commit
<zul> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-gutsy.git;a=commit;h=db90e7a15cb4a160610b4e58576f25539ca216e7
<BenC> zul: doesn't look like we had it
<zul> BenC: ^^ same commit
<BenC> +
<BenC> +       /* By default, disable autosuspend for all non-hubs */
<BenC> +#ifdef CONFIG_USB_SUSPEND
<BenC> +       if (udev->descriptor.bDeviceClass != USB_CLASS_HUB)
<BenC> +               udev->autosuspend_delay = -1;
<BenC> +#endif
<BenC> we were missing that it seems
<zul> ah yeah..
<zul> i see now
<BenC> not the same commit
<kylem> BenC, ok doke
<zul> BenC: same commit message though ;)
<BenC> zul: doesn't look like it to me :)
<zul> maybe i should lay off the crack pipe then
<BenC> as849 vs. as965
<BenC> bdmurray: patch cherry-picked
<bdmurray> So I could comment on 85488 saying that auto-suspend for USB devices will be disabled for everything except hubs.
<maks_> meeting?
<BenC> bdmurray: yes, and fixed-committed for 2.6.22
<BenC> yep
<zul> whoops it looks like xen needs to be added to amd64 lum as well
<dholbach> rtg: I assigned bug 139323 to the kernel team because I thought that you guys would be the most knowledgeable about that package
<ubotu> Launchpad bug 139323 in libieee1284 "please sync from debian libieee1284  (0.2.10-8)" [Undecided,New]  https://launchpad.net/bugs/139323
<dholbach> so I'd just need somebody who'd ACK that sync request if it's ok
<rtg> dholbach: It looks harmless, but its way outside the kernel.
<dholbach> rtg: the people who get those sponsoring bugs assigned are usually not the 'bug contacts' but people who might have a clue
<ogra> are there any known bugs with usb dvb cards ? i had an oops last night with a Hanftek DVB-T card last night (kept dmesg if its not known yet) seems usbcore is stuck sice that happended (havent rebooted yet)
<dholbach> rtg: I simply can't deal with all the sponsoring bugs that come in, so I need to assign them to people
<rtg> dholbach: Well, I don't count as someone who has a clue about this one :)
<dholbach> rtg: I thought that somebody in the kernel team might :)
<dholbach> so all I need from somebody of you guys is a "OK, look good" and I won't pester you with this one any more :)
<rtg> dholbach: OK, I'll update the LP report.
<dholbach> thanks a lot rtg, I'll pass it on to ubuntu-archive then
<ogra> ah, nm, found bug 115284 ... seems to be my issue
<ubotu> Launchpad bug 115284 in linux-source-2.6.22 "USB DVB-T Tuner causes Kernel Oops" [Medium,Triaged]  https://launchpad.net/bugs/115284
<tepsipakki> rtg: with a new SD card I still get errors, so it's not that
<tepsipakki> next I'll test feisty&gutsy live-cd's
<zul> stupid power
<Lure> mjg59: new bios does not fix the reboot problem, I have added new dmidecode to the bug
<BenC> Lure: bug# again?
<Lure> BenC: bug 136257 - it looks like root cause is that "Product Name" is empty in dmidecode...
<ubotu> Launchpad bug 136257 in linux-source-2.6.22 "regression: restart system does not work on HP nw8240" [Medium,Triaged]  https://launchpad.net/bugs/136257
<BenC> Lure: ok
<Lure> BenC: not sure how this can happen to dmi table though...
<BenC> Lure: vendor mistake
<tepsipakki> ok, feisty live-cd is ok, but gutsy is still broken
<Lure> BenC: funny as it is, this laptop was properly reporting product name as seen in old bug 63123
<ubotu> Launchpad bug 63123 in linux-source-2.6.20 "battery info & fans do not work after hibernate (HP nw8240)" [Medium,Incomplete]  https://launchpad.net/bugs/63123
<tepsipakki> hmm, on the other hand.. I don't get anything on the gutsy dmesg, maybe because the desktop is generally unusable on the daily live-cd
<tepsipakki> BenC: so, testing the gutsy live-cd failed, because it can't modprobe anything, they just hang
<tepsipakki> I got the desktop to load eventually
* lamont notes that the topic is out of date wrt kernel version number
* ..[topic/#ubuntu-kernel:xhaker] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.22-10.33 | Latest news: -rt and -xen kernels re-added | New Kernel Team machine: http://kernel.ubuntu.com
<xhaker> woops
<xhaker> bear with me
* ..[topic/#ubuntu-kernel:xhaker] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.22-11.33 | Latest news: -rt and -xen kernels re-added | New Kernel Team machine: http://kernel.ubuntu.com
* Nafallo can't see a difference between those two.
<xhaker> s/10/11
<xhaker> it was s/26/33 before
<xhaker> nitpicking :D
<Nafallo> ooh
<Nafallo> oki ;-)
<xhaker> so who here knows Robert Moore?
<mjg59> At Intel?
<xhaker> yes
<mjg59> He's not very involved in the Linux side of things
<mjg59> More just the core ACPI code
<xhaker> yes
<xhaker> that's why i'm trying to find him
<mjg59> He still occasionally pops up on the linux-acpi list
<xhaker> i've read about the beta kernel milestone and etc
<xhaker> mjg59, you probably don't remember this.. but i was trying to fix an acpi bug, present since 2.6.21, with acpi and batteries
<xhaker> i've made a patch that you looked into.. but it's awesomely small and kindoff hard to document
<xhaker> i've found another bug report upstream about it
<xhaker> http://bugzilla.kernel.org/show_bug.cgi?id=8810
<ubotu> bugzilla.kernel.org bug 8810 in ACPICA-Core "Laptop needs acpi_serialize to works - HP Pavillion dv8230us" [Normal,Reopened]  
<xhaker> could you please look into the last two comments there
<Nafallo> oooh
<Nafallo> ubotu is finally here :-D
<xhaker> i know mjg59 is the laptops guy
<xhaker> but you can look too Nafallo  :)
<Nafallo> xhaker: naah. can't :-P.
<xhaker> mjg59, this other bug seems to be a duplicate http://bugzilla.kernel.org/show_bug.cgi?id=8171
<ubotu> bugzilla.kernel.org bug 8171 in ACPICA-Core "acpi_serialize locks system during boot" [Blocking,Assigned]  
<xhaker> but moore claims to be preparing a patch
<xhaker> i've set this bug to high on launchpad.. this affects thinkpads too i think.
<xhaker> reading robert moore's comments make me think my patch is not that crazy
<mjg59> xhaker: No, returning AE_OK there isn't the right thing to do. The execution failed.
<xhaker> mjg59, yes, you might be right. i'd love to see robert's patch, could he have commit it yet?
<xhaker> i'd set this bug to critical if i was brave enough
<mjg59> xhaker: If it's committed, it'll be in the acpi git tree
* xhaker googles
<mjg59> it's on git.kernel.org
<xhaker> mjg59, no related commit there.. crossing fingers for robert to free the patch
<bdmurray> mjg59: bug 74683 seems to be fix released now is that right?
<ubotu> Launchpad bug 74683 in acpi-support "incorrect dependencies for acpi-support" [Low,Fix committed]  https://launchpad.net/bugs/74683
<mjg59> bdmurray: Yup
<bdmurray> mjg59: Okay, also looking at bug 77212 it looks like it could use a bit more love.
<ubotu> Launchpad bug 77212 in acpi-support "No screen upon resume from suspend to ram (Fujitsu Lifebook S7020)" [Medium,Triaged]  https://launchpad.net/bugs/77212
<elmo> oh, come on, seriously - the order of my sound cards is non-deterministic in feisty :-/
<jwest-> any gdb gurus
<gnomefreak> guru == knows how to use it?
<BenC> elmo: there's some magic with id= for each module you can use to force it
<elmo> BenC: I wish I didn't have to, but then I guess not many people have > 1 soundcard
<BenC> elmo: mostly the media guys
<BenC> wish the alsa/gnome stuff had a better way of configuring it in the UI
<JanC> all peripheral devices should just have a built-in unique ID  ;)
<BenC> ieee1394 does :)
<mjg59> Where did the rtl8180 driver go?
<mjg59> We only have rtl8187, which is the USB model
<BenC> for some reason I was thinking rtl818x was both
<mjg59> I think rtl818x as a project is both, but we only have the 8187 portion
<mjg59> There's no mention of pci in the set we have
#ubuntu-kernel 2007-09-19
<zul> BenC: ping
<BenC> zul: yo
<zul> how am I suppose to build lum again
<bdmurray> BenC: Is there a special bug policy for -rt and -xen?
<zul> yeah xen bugs get forwarded to me i guess
<BenC> bdmurray: for -rt, they are assigned to ubuntu-studio and marked low
<bdmurray> zul: What do you mean by "forwarded"?  How would you prefer to be notified?
<BenC> zul: fakeroot debian/rules binary-modules-generic
<BenC> bdmurray: assign -xen to the xen team
<BenC> which zul is apart of
<zul> sweet 
<zul> -rw-r--r-- root/root     40104 2007-09-18 19:59 ./lib/modules/2.6.22-11-generic/ubuntu/net/atl2/atl2.ko
<zul> off to get squishy
* BenC is off to get slushy
<mjg59> BenC: Yeah, the wireless-dev tree just seems to have 8187. I'm not sure what the status of 8180 is - in the worst case, I guess we'll have to pull it (and possibly its ieee80211...) back in
<BenC> uuuuugly
<BenC> we already had to get a new mac80211 for iwlwifi
<BenC> wonder if we'll ever release with just a stock 80211 stack :)
<zul> BenC: i sent the patch off to the kernel-team mailing list
<RAOF> I'd just like to check that the kernel team is aware of the new nvidia driver release, the release notes of which suggest that it fixes essentially all the compiz+nvidia bugs we have ( http://www.nvidia.com/object/linux_display_ia32_100.14.19.html ).  Is this something worth a l-r-m bug to track?
<BenC> RAOF: yes we are aware of it, and we will be  including it for gutsy
<RAOF> BenC: Thanks.  It's probably worth assuming that you know about such things in future?
<BenC> RAOF: not always
<RAOF> Ok.  In such a case, is a LP bug desirable, or just a ping here?  Might it be worthwhile filing a bug anyway, since I'd imagine that a number of people are going to be asking a similar question?
<BenC> RAOF: ping here is better
<RAOF> Thanks.
<tepsipakki> hey, nvidia released a new blob yesterday (100.14.19), adding support for a couple of quadro chips (as found on my yet-to-be-delivered T61p).. any chance of getting that for gutsy beta?
<RAOF> Yup.  See the replies as of about 4 hours ago :)
<tepsipakki> oh, thanks :)
* tepsipakki should check backlogs first..
<dholbach> can I get feedback from the kernel team on bug 121676?
<ubotu> Launchpad bug 121676 in ubuntu "add DKMS to Ubuntu" [Wishlist,Incomplete]  https://launchpad.net/bugs/121676
<DexterF> hi
<DexterF> I backported the gutsy kernel to feisty, works alright but the modules are ridiculously huge, xfs.ko for example 10MB (!)
<DexterF> I pretty much went with the unmodified kernel src (apart from setting K7 arch) and ran make-kpkg
<DexterF> nvm, forgot to disable debugigng info
<zul_> morning
<zul> hey can someone cherrypick the alt2 driver from my gutsy-lum tree thx
<rtg> zul: working on it...
<pina> seems like intel is back to making the universaal serial bus technology
<pina> data transfer rates more than 10 times as fast by adding fiber-optic links alongside the traditional copper wires
<zul> rtg: thanks
<Nafallo> rt2x00 pcmcia is working fine those days, are they?
<DexterF> running   AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary-debs flavours=amd-k7
<DexterF> I get no build target binary-k7. removed?
<Nafallo> DexterF: long time ago
<Nafallo> edgy IIRC
<DexterF> so... how would I build a K7 kernel?
<DexterF> ok, then that wiki howto is seriuosly outdated
<DexterF> https://wiki.ubuntu.com/KernelCustomBuild
<Nafallo> DexterF: checked the topic yet?
<DexterF> mea to say wrong place?
<Nafallo> hm. doesn't look like it though. that page is linked from the kernel pages.
<DexterF> Nafallo: saw that, too. well I can menuconfig the arch still, tho I'd prefer to do it "properly"...
<Nafallo> DexterF: probably add a new flavour then.
<DexterF> ...and I wouldn't have to go thru this at all if the Feisty kernel did its job properly...
<DexterF> Nafallo: never done that. pointers?
<rtg> zul: what is the URL you used to download the atl2 driver?
<Nafallo> DexterF: never done that either :-). I have not needed a special kernel since I started to run Ubuntu.
<zul> rtg: gimme a sec
<zul> rtg: http://42.pl/u/qMH_Attansic_L2_Linux
<DexterF> ah.. the new target for k7 is generic...
<rtg> zul: The provenance of this driver is curious. The GPL looks right, but I would have expected the driver to come from Atheros or Attansic. Why is a Linux driver in a RAR archive? How does Piotr Kucharski come to be in possession of this driver?
<DexterF> won't work tho yet, src not clean...?
<zul> rtg: its all in the bug report
<rtg> zul: refresh my memory of the bug report please.
<zul> bug #77725
<ubotu> Launchpad bug 77725 in linux-source-2.6.22 "No Driver for Attansic Gigabit Ethernet" [High,In progress]  https://launchpad.net/bugs/77725
<zul> rtg: thanks
<BenC> rtg: Oh, we need to get rtl8180 driver
<rtg> BenC: lemme look into it.
<BenC> I had been thinking that the rtl818x worked for both 8180 and 8187, but as mjg59 pointed out, it only works for 8187
<DexterF> when I run debian/rules updateconfigs my changes to config are checked against other build targets, right? thus I get 4x make oldconfig or whatever looks lik eoldconfig?
<BenC> DexterF: your question isn't making sense to me
<DexterF> BenC: I followed your wiki howto on https://wiki.ubuntu.com/KernelCustomBuild
<dholbach> can I get feedback from the kernel team on bug 121676?
<ubotu> Launchpad bug 121676 in ubuntu "add DKMS to Ubuntu" [Wishlist,Fix committed]  https://launchpad.net/bugs/121676
<BenC> dholbach: we really want it
<DexterF> it says after altering debian/config/arch/config to run updateconfigs
<dholbach> BenC: ok great, can you follow up on that bug report saying that it's all good and I'll make sure to get motu-uvf approving it
<DexterF> I just wanna know what updateconfigs does. merge my alterations to the other configs calling make oldconfig or something with similar function on the other targets?
<dholbach> BenC: I checked it from a packaging point of view, so it'd be nice if somebody of you guys would check it again and say that it's all good on the bug
<BenC> dholbach: done
<dholbach> BenC: rock on
<BenC> dholbach: well, I commented on the need for the package, I haven't checked the packaging itself because I completely respect your ability to do so :)
<BenC> dholbach: I know rtg has given it a once over with mdomsch (who is here and is the packager)
<mdomsch> good day
<BenC> mdomsch: hey
<dholbach> ok great - even better
<rtg> BenC, mjg59; Any idea where the rtl8180 driver lives? The sourceforge driver is ancient and doesn't even compile.
<BenC> rtg: yeah, it's ancient and we'll have to forward port it to make it work
<mdomsch> I misread the guidelines and subscribed  ubuntu-release to it, but they don't need to if it's in Universe.  I can't unsubscribe them, can someone?
<BenC> rtg: it's totally unmaintained
<rtg> BenC: how much fun could that be?
<BenC> rtg: it was working with 2.6.20, so maybe grab it from ubuntu-feisty.git and start with it
<rtg> BenC: Thats probably a better choice.
<BenC> should be under ubuntu/wireless/ in that tree
<rtg> BenC: rtl818x?
<BenC> don't think so
<rtg> BenC: its got a bunch of rtl8180* files.
<rtg> BenC: and they are the same names as the tarball from SF.
<BenC> rtg: yeah, it is rtl818x in that tree
<BenC> I'd rename it to rtl8180 in lum
<rtg> BenC: I'm gonna make the lum directory name rtl8180 so there is no confusion.
<BenC> hehe, cross typing
<rtg> great minds think alike :)
* BenC high fives rtg
<kantor> I have a question related to HDIO_DRIVE_TASKFILE command
<kantor> can I ask ?
<Hobbsee> hiya BenC 
<BenC> Hobbsee: hello
<Hobbsee> BenC: did you want to upload DKMS?  https://bugs.edge.launchpad.net/ubuntu/+bug/121676
<ubotu> Launchpad bug 121676 in dell "add DKMS to Ubuntu" [Low,Fix committed]  
<Hobbsee> BenC: motu uvf has ack'd it.
<mdomsch> Hobbsee, BenC, let me push to revu a 2.0.17.4 that just bumps the version number to not conflict with a previous push
<BenC> mdomsch: ok
<DexterF> http://pastebin.ca/703341 <- can someone please gimme a hand here?
<mdomsch> BenC, see http://linux.dell.com/dkms/permalink/ for all the dkms_2.0.17.4 files for upload
<mdomsch> my upload of this to revu got cut off partway through, and it won't let me dput -f :-(
<mdomsch> ahh, revu just took it, yea!
<Hobbsee> mdomsch: the revu upload appears to be there.
<mdomsch> Hobbsee, it appears I have to wait a few minutes after the failed upload for the queue to clear then it'll let me dput -f
* mdomsch lost network midway through the upload :-)
<Hobbsee> mdomsch: indeed, but i'ts fallen over for some other reason.
<Hobbsee> mdomsch: ah yes, changes file never made it.
<Hobbsee> well, is empty
<mdomsch> ok, give it a few minutes and it'll probably be ok
<mdomsch> it looks like the changs file uploaded fine my second try
* Hobbsee just removed it from the incomming queue
<adnarim> hi
<adnarim> Is any kernel developer of Ubuntu here? I searched the whole net but couldn't find any answers about this. Is the Ubuntu-kernel not supporting the syscall macros? they should be in unistd.h but are not there !?!
<BenC> rtg: what was the bug number for the header postinst hook?
<rtg> BenC: a minute...
<rtg> 125816
<BenC> rtg: thanks
* mdomsch cheers if that makes it in
<rtg> BenC: you know, this rtl8180 crypto is a monumental PITA.
<BenC> rtg: oh, the deprecated crypto calls
<BenC> rtg: that's why I dumped it
<rtg> BenC: It'll work, but I have to touch a lot of crypto stuff.
<BenC> rtg: good luck, I gave up on it very easily :)
<rtg> BenC: a couple more hours...
<BenC> rtg: ok, got the headers-postinst in, getting ready to push
<rtg> BenC: thanks. mdomsch will appreciate you :)
<superm1> Hi guys, is there a plan as to when 2.6.22-11.29 is going to be tagged? Is there a schedule for these sorts of things to watch?
<superm1> (for linux-ubuntu-modules this is)
<rtg> superm1: It should get uploaded in the next day or so.
<superm1> thx rtg 
<DexterF> kernel build failed: http://pastebin.ca/703528
<kraut> moin
<BenC> mdomsch: the next kernel upload will have the headers postinst script. Would you be able to test it with your DKMS usage?
<mdomsch> BenC, absolutely; just say the word
<BenC> mdomsch: great, thanks...It should be uploaded tonight, and built/available by tomorrow
<BenC> mdomsch: actually: http://people.ubuntu.com/~bcollins/linux-headers-2.6.22-11-generic_2.6.22-11.34_i386.deb
<BenC> that's the package I just built if you want to give it a go
<superm1> is the role of providing the new packaged drivers going to fall upon ubuntu kernel team directly?  I can pass off a few comments to the maintainer of the Ubuntu packaging scripts for fglrx to migrate things over to DKMS otherwise
<mdomsch> downloading
<BenC> superm1: we package the new drivers and we don't use the packaging scripts in fglrx to do it
<superm1> right, but i'm saying for post release
<superm1> as newer drivers come out and people end up using them
<BenC> sure, that would be useful, yes
<superm1> will this be changing the way that's handled with more updates within the repositories 
<superm1> okay i'll pass some comments to the beta mailing list
<BenC> third-party drivers can make good use of DKMS
<superm1> mdomsch, do you have some documentation regarding DKMS i can pass off?
<mdomsch> superm1, http://linux.dell.com/dkms has papers and docs
<superm1> great thanks mdomsch 
<rtg> BenC: I have the rtl8180 forward ported as is from Feisty, but I'm reluctant to push it. I really think it ought to use the kernel ieee80211 softmac and crypt stuff. It'll make it easier for Heron.
<mjg59> rtg: If you can port it before freeze, that sounds like an admirable belief :)
<rtg> mjg59: Do you think its worthwhile? How long do we carry this driver?
<mjg59> rtg: I've already got friends bitching at me about the fact that it's missing
<mjg59> They're common cards
<rtg> OK, I'll take a stab at it. 
<rtg> mjg59: First, I think I'll push it as is in case I can't get it done in time.
<mjg59> rtg: Excellent, thanks!
<superm1> BenC, mdomsch DKMS, is it headed to main and installed by default by gutsy?
<mdomsch> BenC, that linux-headers package does not look in /etc/kernel/header_postinst.d/ for scripts to run
<mdomsch> superm1, right now it's targeting Universe; if it's more widely useful I started the wiki page to promote it to main
<mdomsch> but haven't filed that as a request yet
<BenC> mdomsch: I thought that was setup in /etc/kernel-img.conf?
<BenC> the script should only read that file, and it should tell it the command to run (which was a runparts for /etc/kernel/header_postinst.d/)
<mdomsch> BenC, that's the "old" way to do it, but it only allows one thing to hook in; I had proposed a patch that lets it look in /etc/kernel/header_postinst.d/ in addition
<mdomsch> just like linux-image uses
<BenC> hmm...maybe I missed that
<BenC> can you point me to your changes?
* mdomsch digs
<superm1> mdomsch, well the fglrx guys already got back to me, i'll just let them know to depend on it since its not by default
<BenC> I only did the script, plus the s// matching patch
<mdomsch> https://bugs.launchpad.net/dell/+bug/120049
<ubotu> Launchpad bug 120049 in linux-source-2.6.22 "header_postinst_hook should use /etc/kernel/header_postinst.d instead" [Medium,Confirmed]  
<mdomsch> http://launchpadlibrarian.net/9273949/header.patch
<mdomsch> the first hunk you don't need, but the second hunk adds looking in /etc/kernel/header_postinst.d/ and header_postinst.d/$version/ 
<mdomsch> and I don't know if it's needed, but analogous is etc/kernel/src_postinst.d/  is done in that patch too
<mdomsch> superm1, their package should Depend on dkms regardless if they're using dkms :-)
<superm1> well the maintainer for the ubuntu scripts said he may not have the time to investigate it himself directly, so if he doesn't in the near future i'll try to take care of that upstream (he has taken patches from me in the past when he gets busy)
<mdomsch> superm1, looks like mandriva packages ATI drivers using dkms
<superm1> that's a good starting point than, thx
<mdomsch> as does pclinuxos
<rtg> mjg59: I pushed Gutsy lum. If one of your bitching friends is handy, perhaps you could build lum and try out the rtl8180 driver on them.
<mjg59> rtg: Ok, I'll see what I can do
<BenC> mdomsch: thanks, added that hunk
<mdomsch> BenC, danke
<BenC> anyone have anything left for linux-source-2.6.22 before I do this upload?
<kylem> nyetski.
<mdomsch> BenC, thanks, I see the change hit the git tree - looks ok by inspection
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.22-11.34 | Latest news: -Beta freeze upon us | New Kernel Team machine: http://kernel.ubuntu.com
<rtg> mjg59: I think porting rtl8180 to the current ieee80211 softmac is a days long effort.
<BenC> rtg: yeah, probably
<mjg59> rtg: That's what I'd suspect
<rtg> BenC: At best, I might be able to use the crypto from the kernel, but the softmac is really different.
<dieguito> hello dear kernel hackers, may I ask for your attention on lp bug #103780 ? I'm unable to install Ubuntu at home because of that bug
<ubotu> Launchpad bug 103780 in linux-source-2.6.20 "IDE drive hangs boot for ~2 minutes after 2.6.20-13=>2.6.20-14" [Undecided,Confirmed]  https://launchpad.net/bugs/103780
#ubuntu-kernel 2007-09-20
<bdmurray> dieguito: Have you tried using the development release of Ubuntu?
<dieguito> not yet, latest cd I have is 7.04, I tried with other distros and all of them using libata share the problem
<dieguito> worth mentioning among those Arch linux which has kernel 2.6.22
<sirpan> hola tengo problemas con ubuntu 7.04 kernel 2.6.20-16-generic y nvidia.. alguna solucion?
<mjg59> BenC: Hm. TIFM in the core kernel needs to be disabled in order to use the one in l-u-m.
<calc> seems my audio stopped working on gutsy at some point it is intel hda with realtek 888
<johanbr> calc: If it's a kernel problem, it should work if you go back to a previous kernel.
<calc> oh i figured out the issue
<calc> it changed how it works for which audio port to increase volume
<calc> it claims it is the surround port now
<johanbr> Oh, okay. So there have been patches to the hda driver this late in the game?
<calc> not sure when it happened i haven't been using audio on my desktop in a while
<mjg59> BenC: Hm. I suspect that the ACPI oopses on boot on some machines might be my fault
<mjg59> BenC: Looking into that
<mjg59> This is confusing me to an excessive degree
<mjg59> I've made no substantive changes, but it seems to boot now
<sud0> can anyone help with compiling using older kernel headers?
<AnAnt> Hello, I got a question, why is CONFIG_SND_HDA_INTEL option not set anymore ?
<AnAnt> it was enabled in 2.6.22-8
<AnAnt> but in the current version it is disabled
<AnAnt> is there a reason for this ?
<RAOF> AnAnt: Didn't hda_intel get moved to linux-ubuntu-modules for ease of out-of-kernel updates?
<AnAnt> RAOF: dunno
<john_> can any one shed some light on the dmi_string:out of memory error that appears on startup. also have kernal alive error but one problem at a time as i am a NEWBIE
<john_> was ok on 32 bit ubunto but moved over to 64 bit
<john_> running a duo core intel chip
<AnAnt> RAOF: what I know is that hsfmodem doesn't compile the HDA modules because of this option being not set
<kraut> moin
<RAOF> AnAnt: Yup, it's in l-u-m.
<AnAnt> RAOF: what do you mean by "ease of out-of-kernel updates" ?
<RAOF> AnAnt: I'm in no way authorititive, but it seems that hda_intel was taken out of the kernel and put into l-u-m so that l-u-m could track upstream ALSA more closely.
<AnAnt> ok
<RAOF> Rather than waiting for ALSA -> vanilla kernel -> Ubuntu.
<Whoopie> BenC: Hi, could you consider adding the ipw2100/2200 power management fixes? it's bug 136357
<ubotu> Launchpad bug 136357 in linux-source-2.6.22 "ipw2*00: please backport fixes for power management commands" [Wishlist,Triaged]  https://launchpad.net/bugs/136357
<amitk> Whoopie: the patches look sane. I will push in the changes
<Whoopie> amitk: thanks a lot.
<DexterF> hi
<DexterF> are the feisty/gutsy kernels patched in regards to the usb system somehow?
<DexterF> got a cheap usb hub here, works fien in etch, slack, windows, on two other machines, too. only ubuntu screws up when I attach it. usb-dvb-t box stops responding and so does a card reader
<amitk> DexterF: the core usb subsystem is what is in mainline 2.6.22
<amitk> DexterF: filing a bug with details of your devices would help in tracking down the problem
<DexterF> amitk: sure, only wanted to check usb isn't patched beforehand
<StevenK> Hey guys, I worked to get virtualbox-ose into Gutsy, which requires a kernel module to work, and it looks like a candidate for ubuntu-kernel-modules to include for i386/amd64, but virtualbox-ose-source (which is the source of the modules) is in universe, so I'm looking for suggestions.
<zul> StevenK: I think including the virtualbox in feisty caused too many problems last time around so thats why they werent probably not included this time around but ask someone like BenC 
<StevenK> virtualbox wasn't in Feisty - surely that was vmware?
<zul> yeah it was
<zul> im sure of it or I need more caffine
<lamont> BenC: sigh.  -11.34 ftbfs on hppa with missing module sha256... wanna reenable all the crypto modules, or shall I do a test build or 3 and make a known-good patch for -11.35?
<BenC> lamont: test build please
<lamont> BenC: will do
<amitk> BenC: I am going to push 1pw2x00 power management fixes soon. Testing now. When are you uploading?
<amitk> s/1pw/ipw
<zul> BenC: can we get xen amd64 added to lum and meta as well?
<lamont> BenC: where is it deciding that sha256 is missing... it's not in modules.hppa64...
<lamont> ah... sounds like debian/d-i/modules/crypto-modules is to blame, maybe?
<lamont> someone remind me what the updateconfigs target is?
* lamont notes that is face is red.
<amitk> debian/rules updateconfigs?
<amitk> https://wiki.ubuntu.com/KernelMaintenance
<amitk> lamont: updateconfigs is runn for all flavours in all architectures
<rtg> amitk: Do you think your recent commits will have any effect on bug ##139171 ?
<rtg> hello ubuntoid? bug #139171
<ubotu> Launchpad bug 139171 in linux-ubuntu-modules-2.6.22 "ipw2200 regression in gutsy" [Undecided,New]  https://launchpad.net/bugs/139171
<zul> rtg: that one looks more like a network-manager problem
<rtg> zul: Except for 'ipw2200: Firmware error detected.'. amitk's patch mentions causing firmware errors.
<Mithrandir> pkl_: what's the status of the new lum with fixed unionfs?
<pkl_> Mithrandir: the unionfs fixes are in git.  I don't know if BenC has done an upload yet.
<Mithrandir> ok, I'll pester him then.  Thanks a lot for fixing the problem though! :-)
<Mithrandir> BenC: if you could tell me what the status of new lum is, that'd be great.
<amitk> rtg: any effect will be unintentional. I looked at the patch from the point of view of getting  'iwpriv set_power' fixed
<lamont> BenC: test build running now, eta 2 hours or so. :(  patch in git (lamont/hppa-ia64.git that probably fixes things if you happen to be doing -11.35 before the build finishes)
<Whoopie> amitk: btw, do you know why the history function for gitweb doesn't work?
<lamont> Whoopie: one guess would be the rebasing that happens
<Whoopie> lamont: sorry, could you explain more?
<lamont> Whoopie: how does it "doesn't work"?
<Whoopie> lamont: history is empty. e.g. in Linus' tree, I can see the whole history of each file.
<Whoopie> lamont: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-gutsy.git;a=history;h=d0ecf29b6abcd567121e63aa43f06e7c587d89e7;f=drivers/net/wireless/ipw2200.c
<Whoopie> lamont: just an example, it should show the latest patch which amitk commited.
<lamont> good question
<lamont> git log on the file shows the right stuff - so I'd wager it's gitweb having fits
<bdmurray> mjg59: A bit ago we talked about bug 91056 and I thought you mentioned you would have to think about it.  Am I recalling things correctly?
<ubotu> Launchpad bug 91056 in xkeyboard-config "[Feisty]  synaptic keypad lock button launches KDE or Gnome Help Center" [Undecided,Confirmed]  https://launchpad.net/bugs/91056
<mjg59> bdmurray: Yeah
<mjg59> I can reproduce it on my new system, so I'll try to figure it out
<bdmurray> Okay, I thought you said something about it sending a keypress even on release.
<bdmurray> s/even/event/
<mjg59> Yeah, that's what I see
<lamont> BenC: patch committed in lamont/hppa-ia64.git confirmed good.  Please grab it.
<lamont> 5f73606476035c5dfc5166d94f1ca48e42fe13a4
<dieguito> dear kernel hackers, may I once again steal some seconds of your attention so you fix the makefile that is leaving r818x.ko out of kernel packages: lp bug #129407 ?
<ubotu> Launchpad bug 129407 in linux-ubuntu-modules-2.6.22 "r818x.ko missing in  linux-ubuntu-modules-2.6.22-8-generic" [Undecided,New]  https://launchpad.net/bugs/129407
<rtg> dieguito: I put it in Gutsy lum yesterday.
* dieguito hugs rtg
<dieguito> i'll try to update now
<rtg> dieguito: It hasn't hit the archive yet. Maybe by tomorrow.
<dieguito> awww, well i'll keep an eye
<rtg> dieguito: incidentally, its going to be called rtl_8180.ko in order to clearly distinguish it from rtl818x.
<dieguito> which version is the one i'm waiting for?
<rtg> dieguito: it depends on your device. Look in  http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-gutsy-lum.git;a=blob;h=b548f172c049814fd3b11c128eb8c066c27f6825;hb=c1b118eaae96119089a567ff175109f661c6f149;f=ubuntu/wireless/rtl8180/rtl8180/r8180_core.c for rtl8180_pci_id_tbl[]  to see if your device is supported.
<dieguito> I mean the ubuntu package that is including the driver, I already know it works with my card, I was using that before
<dieguito> I even had to compile it's 10 different incarnations when ubuntu lost the module, i ended using ndiswrapper
<rtg> dieguito: I'm not sure what you are asking. rtl8180 will appear in linux-ubuntu-modules, which you will get as part of the normal update process.
<dieguito> i mean, which is the version of the ubuntu package
<dieguito> the version that includes the previously missing driver
<dieguito> linux-ubuntu-modules 2.6.22.what
<rtg> dieguito: It looks like the kernel upload is forcing an ABI bump, so lum will be 2.6.22-12.1
<dieguito> yeah that :)
<dieguito> thank you rtg :)
<bigjools> hey folks, are there any plans to upgrade alsa further in gutsy? (to fix https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/131133)
<ubotu> Launchpad bug 131133 in linux-source-2.6.22 "[gutsy]  no sound on Dell Latitude D630/D830/Precision M4300 pci id 8086:284b" [Medium,Triaged]  
<mjg59> rtg: http://rtl-wifi.sourceforge.net/wiki/Main_Page seems to have a more up-to-date rtl8180
<rtg> mjg59: I'll lok.
<rtg> s/lok/look/
<rtg> mjg59: Did you get a change to test?
<rtg> s/change/chance/
<rtg> can't type today.
<mjg59> Afraid not - I should be able to get a tester once we have images that fit on a CD again
<rtg> mjg59: I've been building Live CD images on USB sticks.
<Mithrandir> DVDs generally also work.
<mjg59> rtg: https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/74672 - I suspect that'll still be an issue with the forward port?
<ubotu> Launchpad bug 74672 in linux-source-2.6.20 "ESSID gets truncated" [Medium,Confirmed]  
<rtg> mjg59: Yep. I'll patch lum, but its already missed the upload.
<mjg59> Ok, no problem
<dieguito_> that rtl-wifi version of the driver works, if that's useful to know
<rtg> dieguito_: Good. That is the first positive confirmation. get that mjg59?
<mjg59> Yup
<dieguito_> well, it works but you *have* to make it work
<dieguito_> and if I recall correctly, it suffers from the hangs ubuntu's version had. I would have to test again.
<Krystof> maybe someone who's better at searching launchpad than I am can find it, but there is at least one extended discussion about the r818x driver where the deadlocks are discussed and a possible patch advanced in one of the bug reports about freezes on network changes or large data rates (with that driver)
<dieguito_> yes it's somewhere around
<dieguito_> lp bug #77152 is also related to 818x hardware
<ubotu> Launchpad bug 77152 in ndiswrapper "Can't upload files" [Undecided,New]  https://launchpad.net/bugs/77152
<dieguito_> (and I'm suffering it right now)
<dieguito_> you may also want to close this lp bug #22689 since it seems to be about the old driver version
<ubotu> Launchpad bug 22689 in linux-source-2.6.17 "Wi-Fi PCMCIA card fails association until CTRL+C is pressed." [Medium,Incomplete]  https://launchpad.net/bugs/22689
<dieguito_> and the freeze bug is lp bug #31857, this one is a dupe of the essid truncate one lp bug #33714 and mark lp bug #45146 as dupe of  #31857
<ubotu> Launchpad bug 31857 in linux-source-2.6.15 "r818x driver freezes randomly" [Medium,Confirmed]  https://launchpad.net/bugs/31857
<ubotu> Launchpad bug 33714 in linux-source-2.6.15 "r818x not working" [Medium,New]  https://launchpad.net/bugs/33714
<ubotu> Launchpad bug 45146 in linux-source-2.6.15 "Hard lockup using realtek wireless since 2.6.15-22 " [Medium,New]  https://launchpad.net/bugs/45146
<dieguito_> https://bugs.launchpad.net/bugs/+bugs?field.searchtext=r818x&orderby=-importance&search=Search&field.status%3Alist=New&field.status%3Alist=Incomplete&field.status%3Alist=Confirmed&field.status%3Alist=Triaged&field.status%3Alist=In+Progress&field.status%3Alist=Fix+Committed&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
<dieguito_> (sorry about all that text)
<Krystof> 31857 is the one I was thinking of
<Krystof> as in, it has some useful discussion
<Krystof> (the patch that I have seen somewhere is to remove the lock_irqsave/unlock_irqrestore in that function; I doubt it's correct, but it probably deals with the immediate symptoms)
<dieguito_> right now, the problems with the r818x thing are: locks when uploading files or doing lot of stuff via wifi, no multicast support, truncated essid names, no accurate signal strength
<Krystof> the locks can be worked around by using a -386 kernel, too
<rtg> mjg59: I'm liking the driver at http://rtl-wifi.sourceforge.net. Maybe I can dump the rtl softmac and encryption hacks in favor of the in-kernel versions.
<rtg> Wish I'd have found this one first before porting the Feisty mess.
<Nafallo> wow.
<Nafallo> nice URL ;-)
<Nafallo> mjg59: hi mate, around?
<mjg59> Nafallo: Hi
<Nafallo> mjg59: if I was sick of dell and consider buying a lenovo. which one would be a good choice if you know of hand?
<mjg59> Nothing in the 3000 range
<Nafallo> mjg59: dell wants one and a half month to deliver a D630, so screw them ;-)
<Nafallo> mjg59: oki, thinkpad it is. more specific or are those all good ones? :-)
<mjg59> Depends what you're looking for
<mjg59> They should all work fairly similarly
<mjg59> Though I've only direct experience of the T61
<Nafallo> basically something to pick with me out on the datacenters if need be, but also sitting home and from time to time compiling stuff.
<Nafallo> basically.
<Nafallo> X is to damn small I think. how is the T-series?
<mjg59> Fine
<mjg59> I think the 42/43 were nicer, but they're still very competent
<Nafallo> kewl. I'll probably end up with that then. thank you so much! :-)
<bullgard4> How can I read out the ECDT?
<mjg59> acpidump
<bullgard4> sudo acpidump outputs DSDT, FACS, FACP, APIC, BOOT, MCFG, SSDT RSDT, RSD, PTR but no ECDT. (http://ubuntuusers.de/paste/15169/)
<bullgard4> /proc/acpi/embedded_controller/EC0/info contains: "gpe: 0x17; ports: 0x66, 0x62; use global lock: no".
<jetsaredim> is it possible/likely to get an updated version of vmware-server-kernel-modules for gutsy in the near future?
<jetsaredim> or - better yet - is there a way for me to be able to build the module for my system?
<kylem> hmm. you raise a good question.
<jetsaredim> which?
<kylem> where did the vmware modules go?
<kylem> they're still in the source package, heh.
<jetsaredim> there is also bug 120332
<ubotu> Launchpad bug 120332 in vmware-player-kernel-2.6.15 "vmware-player-kernel-modules not available for Gutsy kernel 2.6.22 (dup-of: 124775)" [Undecided,New]  https://launchpad.net/bugs/120332
<ubotu> Launchpad bug 124775 in vmware-player-kernel-2.6.15 "No kernel modules for the 2.6.22 kernel" [High,Confirmed]  https://launchpad.net/bugs/124775
<kylem> and feisty.
<jetsaredim> i know its a good question - that's why i asked it :)
* kylem points at BenC
<rtg> kylem: Does bug #141298 make any sense to you? These are Intel graphics platforms.
<ubotu> Launchpad bug 141298 in dell "Intel video card 8086:2a02 blacklisted, can't run compiz" [High,Confirmed]  https://launchpad.net/bugs/141298
<bullgard4> I downloaded the DEB program package pmtools and installed it. But 'apropos acpidisasm' cannot find anything suitable. How to diassemble the DSDT?
<mjg59> rtg: Yes, that's deliberate
<mjg59> 965 doesn't support Xv with composite
<rtg> mjg59: I guess I don't understand enough about compiz and Xv.
<mjg59> XAA + composite = no video on 965
<mjg59> Which is awkward
<rtg> mjg59: This is something Jose used to be able to do. e.g., compiz --replace to fix fubar'd compiz after saving his session.
<mjg59> Right. Compiz will now not run on 965.
<rtg> mjg59: Does that mean no 3D effects?
<mjg59> Yes
<rtg> mjg59: Can you point me to some info or rationale for this? I need to wrap my head around it 'cause Jose is gonna have a cow.
<Keybuk> rtg: i965 doesn't support the necessary pieces for video to work without using EXA
<Keybuk> so you can have whizz-bang 3D effects, but no porn
<mjg59> rtg: The -intel driver doesn't support accelerated video playback when using a composited desktop unless you're using the EXA acceleration architecture, which we aren't
<mjg59> Video playback is more important than desktop effects
<rtg> So, this is really a feature :)
<mjg59> Yes
<JanC> mjg59: I'm sure a computer with a 965 can easily play video with compiz enabled, but without using Xv ?
<mjg59> JanC: In HD? No.
<JanC> well, most porn isn't in HD I guess?  :P
<bdmurray> bug 141082 might need some attention
<ubotu> Launchpad bug 141082 in linux-source-2.6.22 "Only one CPU core recognized in Gutsy after updates" [High,Triaged]  https://launchpad.net/bugs/141082
<JanC> well, at least I can play DVDs on my 1.33 GHz Core Duo laptop with 945 graphics, without using Xv (and while using compiz...)
<jetsaredim> i'm running that kernel on my pentium d and i can see both cores
<mjg59> Anyway, there's no decent way of autodetecting whether to use Xv or not
<rtg> bdmurray: read the followup. He was running the 386 (UP) kernel.
<rtg> bdmurray: never mind. brain damage.
<bdmurray> rtg: That is one out of 4 commentors
<kylem> i suspect he doesn't have an mpbios and as such, without acpi there's no hope of finding the other cpu
<mjg59> Yeah. You're not going to get more than one processor on any modern machine unless booting with acpi
<bdmurray> What is this commentor's issue? https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/141082/comments/5
<ubotu> Launchpad bug 141082 in linux-source-2.6.22 "Only one CPU core recognized in Gutsy after updates" [High,Triaged]  
<kylem> [    5.324000]  CPU #1 not responding - cannot use it.
<mjg59> bdmurray: That's clearly a different bug to the filed one
<bdmurray> hrm, its too bad comments aren't movable then
<mjg59> rtg: I suspect someone's going to have to manage Jose's expectations. Gutsy will not be shipping with compiz on 965.
#ubuntu-kernel 2007-09-21
<rtg> mjg59: Well, I suspect you know who gets to manage those expectations.
<mjg59> Heh
<bdmurray> uvcvideo is blocking my laptop from suspending
<bdmurray> I receive an error message when that kernel module is loaded and I try to suspend with 2.6.22-11.
<bdmurray> Actually, I don't understand why that module is being loaded on my system.
<bdmurray> Whay does this "alias:          usb:v*p*d*dc*dsc*dp*ic0Eisc01ip00*" alias match?
<bdmurray> s/Whay/What/
<kylem> any device that claims to be usb video, subclass video control
<bdmurray> kylem: So uvcvideo will loaded for any unknown webcam?
<kylem> it's a match based on the capability of the usb device, not it's specific vendor/device ids.
<mjg59> bdmurray: If it claims to be a USB video device, which most webcams don't
<bdmurray> okay, but I don't understand why the module would be loaded for devices that are supported by the driver
<bdmurray> maybe webcam was the wrong word, the camera in my laptop then
<kylem> lsusb -v | egrep 'bInterface.*Class'
<mjg59> Your camera presumably claims to implement the USB video class
<bdmurray> Okay, so it might work with uvcvideo then?
<mjg59> bdmurray: It claims that it should do. It might be lying, or uvcvideo might be broken.
<bdmurray> mjg59: Okay, that module is preventing me from suspending though and if it matches a lot of devices it seems like it might be a problem for a lot of people then.
<mjg59> bdmurray: Sounds like we need to fix the module. What are the symptoms?
<bdmurray> When trying to suspend vi "echo -n mem > /sys/power/state" I receive a kernel erro message regarding "uvcvideo 5-4:1.1: suspend error -22"
<mjg59> bdmurray: Uh. Why are you trying to suspend like that?
<bdmurray> line 39 of /etc/acpi/sleep.sh is what was failing and it wasn't very informative
<bdmurray> So I was originally using /etc/acpi/sleep.sh
<mjg59> dmesg should give you the same information
<mjg59> Hm. Interesting. I can't see any obvious reason why that would fail.
<bdmurray> I think it worked before this commit - 616d7243b60bb3eb2abed6cf99fe4d3edfc6a874
<mjg59> to lum or the main kernel?
<bdmurray> lum
<mjg59> Interesting.
<bdmurray> my git knowledge isn't the greatest but I think that was the last commit changing uvcvideo
<mjg59> If you revert that, does it work?
<bdmurray> How could I do that?
<mjg59> git revert 616d7243b60bb3eb2abed6cf99fe4d3edfc6a874
<mjg59> Then try building l-u-m
<mjg59> Are you sure it says "suspend error"?
<mjg59> I can't find that string in the obvious bits of the kernel
<bdmurray> [   83.816850]  usb_endpoint usbdev5.2_ep82: PM: suspend 0->2, parent 5-4:1.0 already 2
<bdmurray> [   83.816863]  uvcvideo 5-4:1.1: suspend error -22
<mjg59> Ah, ok, thanks
<mjg59> Hm. Still not entirely obvious.
<bdmurray> mjg59: 2.6.22-10 suspends if that is any help
<mjg59> Is that before that commit?
<bdmurray> Yeah it looks like
<mjg59> Ah, hm. That diff added a suspend method.
<mjg59> Oh, I see
<mjg59> Right. Can you rmmod uvcvideo, then modprobe uvcvideo trace=255
<mjg59> Then try a suspend and paste the full demsg?
<bdmurray> sure, just a sec
<bdmurray> Did I do something wrong or should have suspending worked?
<lamont> kylem: you around?
<lamont> or BenC?
<mjg59> bdmurray: No, suspending probably shouldn't have worked
* lamont sends mail to kernel-team
<lamont> sigh
<lamont> kylem: -12.36 will ftbfs on hppa without the patch I mailed to kernel-team.  sorry for not mailing it earlier when it was being discussed in channel.
<bdmurray> mjg59: well, here is dmesg, I'll make sure it fails again too
<bdmurray> http://pastebin.osuosl.org/2372
<mjg59> bdmurray: Ah, I think I know what the issue is
<mjg59> bdmurray: It's failing to initialise, but not releasing the device
<mjg59> Hm. No, that /should/ release things correctly
* lamont goes hoem
<bdmurray> Hrm, ocassionally the system becomes nonresponsive when suspending too.
<lamont> bdmurray: mine turns almost completely off when I suspend it. :)
* lamont thinks that the lrm build-dep on gcc-3.4 [hppa]  could change to gcc-4.1.  I'll test that tomorrow
<kraut> moin
<verwilst> hi guys
<verwilst> i was wondering, shouldn't there be a linux-image-xen or something?
<verwilst> i apt-get install'ed linux-image-2.6.22-11-xen
<verwilst> but apparently, when 2.6.22-12-xen is out, it doesn't automatically upgrade
<verwilst> could it be because be installing it like that, it pinned itself to -11 ?
<Chorus> there is a package named "linux-image-xen"
<Chorus> http://packages.ubuntu.com/gutsy/metapackages/linux-image-xen
<verwilst> aaah
<verwilst> but not for amd64
<verwilst> bugreport it?
<zul> verwilst: its coming soon
<verwilst> zul: coolnes :)
<verwilst> just trying out xenman
<verwilst> 0.5 on feisty doesn't seem to let me login to my server
<verwilst> 0.6 doesn't seem to work on feisty, it cant find some modules :)
<verwilst> python modules that is
<zul> because xen-3.1 changed stuff
<zul> try the one on gutsy
<verwilst> yeah, i don't have a gutsy yet
<verwilst> oh! my laptop!
<verwilst> it scans for /usr/lib/xen-*, maybe if i just change the location, it'll work
<verwilst> zul: apparmor seems to be disabled for the xen kernel
<verwilst> any idea why?
<zul> verwilst: because its not, i dont use it for one
<verwilst> its not disabled you mean?
<zul> verwilst: but but in a bug request and ill enable it this weekend
<verwilst> thanks man :)
<verwilst> zul: hm, it seems to be available in linux-ubuntu-modules-xen
<verwilst> E: Couldn't find package linux-ubuntu-modules-2.6.22-12-xen
<verwilst> but my mirror is acting up so it seems :p
<zul> for amd64?
<verwilst> in the changelog entry for ",linux-ubuntu-modules-2.6.22 (2.6.22-12.29)"  it says "Ben Collins: ubuntu: Add amd64 to xen target"
<zul> could be your mirro 
<verwilst> ftp://ftp.ubuntu.com/ubuntu/pool/universe/l/linux-ubuntu-modules-2.6.22
<verwilst> idd
<verwilst> the kernel has been sycned
<verwilst> but the modules aren't yet
<verwilst> xenman looks pretty nice btw
<jetsaredim> did we ever get an answer on the vmware modules question?
<verwilst> zul: hm, do you know of a bug that makes the bridge not being creates?
<verwilst> created*
<verwilst> i have bridge-utils installed
<verwilst> and my xend-config.sxp has the network-bridge thing correct
<verwilst> i have lots of vif's, but no bridge
<zul> nope
<verwilst> had that problem before with -10 i think
<verwilst> booting with 2.6.16-xen worked fine
<verwilst> so must be a kernel issue
<verwilst> 2.6.18-xen sorry, the official one
<zul> you might want to check #xen
<Nafallo> Lenovo ThinkPad R61 (NA01FUK)
<Nafallo> I hope its a good one, cause I have it early next week :-)
<verwilst> zul: read everything on #xen? :)
<zul> uh no
<verwilst> zul: only the last lines are important :)
<bdmurray> BenC: I'm having some issues with suspend and uvcvideo on my laptop.
<BenC> bdmurray: yeah, I've heard the same from others
<mjg59> bdmurray: Did you generate the full trace I asked for?
<BenC> some people have added it to the list of modules to load/unload for suspend
<mjg59> There's a trivial one line workaround
<mjg59> Just change the return -EINVAL to return 0 in uvc_suspend()
<mjg59> It's a sanity check that's failing
<mjg59> I suspect because the driver never bound, so dev->video.streaming->intf never got set
<mjg59> Quite /why/ the driver is still attached to the device when it failed to set up the video interface, I've no idea
<zul> mjg59: http://svn.berlios.de/viewcvs/linux-uvc/linux-uvc/trunk/uvc_driver.c?rev=122&r1=120&r2=122
<mjg59> zul: Yes, that's the code we have
<zul> ah ok
<bdmurray> When the module is initially loaded I do see a message about it failing to initialize the device
<mjg59> bdmurray: The logs from an attempted suspend with the tracing turned on would be helpful
<bdmurray> mjg59: okay, I'll keep trying to get one
<natenewz> submitted bug #129972 this last summer, if somebody wants to take a look, I can test and run commands and things
<ubotu> Launchpad bug 129972 in alsa-driver "no sound on hp dv6500 pavilion laptop" [Undecided,Confirmed]  https://launchpad.net/bugs/129972
<bdmurray> natenewz: is that with gutsy or feisty?
<natenewz> bdmurray: gutsy
<bdmurray> natenewz: installed or a live cd?
<natenewz> bdmurray: installed
<jdong> what architectures are "tickless"?
<jdong> just i386, or i386 and amd64?
<jdong> sorry if I, err, ticked... anyone off by asking that in -devel
<mjg59> Just 9386
<mjg59> i386
<jdong> ah, ok
<jdong> thanks
<bdmurray> Is there a reason PM_TRACE isn't available on amd64?
<mjg59> bdmurray: It shouldn't make any difference in this case?
<bdmurray> mjg59: The architecture shouldn't make any difference?
<mjg59> bdmurray: Oh, sorry, are we not on uvcvideo any more?
<mjg59> I believe rtg added PM_TRACE support to x86_64
<mjg59> Back in Feisty
<bdmurray> Right I see it in 2.6.20 but not 2.6.22
<rtg> mjg59: I don't think we carried that forward.
<mjg59> sigh.
<mjg59> BenC: Please, please, please could you generate a list of patches that weren't carried forward?
<kylem> eh?
<kylem> it's upstream.
<BenC> those got merged upstream
<mjg59> BenC: It's still something of a general problem, though
<rtg> mjg59: PM_TRACE was used to find out which drivers were causing suspend problems. I think most of them have been fixed. The remaining video issues are not solvable using PM_TRACE.
<mjg59> rtg: No, there will still be a large number of drivers causing issues.
<BenC> mjg59: at this point, suspend tracing doesn't much matter, does it?
<BenC> but i was sure all of our patches got merged upstream, including the amd64 one
<mjg59> BenC: We still seem to be missing the MSI and MMCONFIG stuff
<BenC> Now that I was sure was merged at the start of gutsy work
<mjg59> Nope
<mjg59> static int pci_msi_enable = 1;
<mjg59> BenC: This is why I keep asking for a list - nobody seems to have any clue which patches have been dropped by accident :)
<bdmurray> I think there should be some consistency with pm_trace.  Having it available on i386 but not on x86_64 seems odd.  Also the wiki page DebuggingKernelSuspend points people to it.
<mjg59> Yeah. It's in-kernel, it should be switched on.
* BenC was pretty sure tim merged that...let me check
<BenC> yeah, the +6 is still there, so no amd64 support...hmm
<rtg> BenC: Cherry-pick from Feisty?
<BenC> rtg: yeah
<rtg> Feisty c63e3d917a84214a98c81ae497bcd4a72ead62ed
<rtg> I'll get it after kylem sorts out the ABI brokeness.
<Kano> hi, are those vfs changes from 2.6.23?
<Kano> they make that aufs does not compile again
<BenC> Kano: no, they are caused by apparmor needing vfs changes for proper hooks
<BenC> Kano: search for an aufs patch to make it work with latest apparmor
<Kano> BenC: any idea where to find that?
<okaratas> hello
<jetsaredim> did we ever get an answer on the vmware modules question?
#ubuntu-kernel 2007-09-22
<superm1> it looks like unionfs issues are still cropping up for me in the live disk i just built with the newer linux-ubuntu-modules :(
<IntuitiveNipple> superm1: Funny that - I was just remarking that yesterday's desktop i386 image is the first one i've been able to get to load on the Vaio notebooks - they were seeing the unionfs BUG early in the load
<superm1> i'm seeing this after using it for a bit
<superm1> this is the first i can boot too though
<IntuitiveNipple> I started it about 5 minutes ago, it is still chugging... blank screen right now but some CD activity at times
<superm1> i'll fire back up the VM and reproduce it to get it into a bug report
<IntuitiveNipple> If this goes well I'm going to try it on the Acer travelmate tablet
<IntuitiveNipple> Looks like it's still no-go. blank screen still, CD chugs occasionally, but seems like the i810 video isn't working
<superm1> of course i can't reproduce it this time around :).  well i'll keep trying
<IntuitiveNipple> It's failed here, I'm trying the alternate image
<TheMuso> c
<TheMuso> ugh
<lamont> Checking ABI for hppa32...previous or current ABI file missing!
<lamont>    /build/buildd/linux-source-2.6.22-2.6.22/debian/abi/2.6.22-12.37/hppa/hppa32
<lamont>    /build/buildd/linux-source-2.6.22-2.6.22/debian/abi/2.6.22-12.36/hppa/hppa32
<lamont> make: *** [abi-check-hppa32]  Error 1
<lamont> -12.37 (with the -12.38_sources) is gonna fail on hppa
* lamont sleeps
<lamont> I wonder if the real -12.38 will work instead.
* Starting logfile irclogs/ubuntu-kernel.log
* #ubuntu-kernel  [freenode-info]  channel trolls and no channel staff around to help? please check with freenode support: http://freenode.net/faq.shtml#gettinghelp
<jeromeg> hello
<jeromeg> BenC : do you have a second ?
<BenC> jeromeg: yeah
<jeromeg> BenC : I have someone on #ubuntu-bugs telling me that bug 118539 should be of high priority
<ubotu> Launchpad bug 118539 in linux-ubuntu-modules-2.6.22 "[regression]  acx does not load" [Medium,Confirmed]  https://launchpad.net/bugs/118539
<jeromeg> it disables internet access which is quite crucial with ubuntu
<jeromeg> and a patch ( i don't if it's good but it works) is available
<jeromeg> BenC : is it possible to do something for this bug ?
<BenC> it is definitely high
<BenC> jeromeg: I'll take on the bug from here, make sure we get it fixed
<BenC> jeromeg: thanks
<jeromeg> BenC : thank YOU ! i didn't do anything there :)
<BenC> jeromeg: fixed it, I'll get this uploaded for beta
<jeromeg> BenC : waouh ! that was a fast fix !
<jeromeg> BenC: while I'm here I've another bug considering wifi cards, it has been here since edgy, it's the orinoco_pci / hotstap_pci conflict 
<jeromeg> it still seems to be here in gutsy :
<jeromeg> bug 126220
<ubotu> Launchpad bug 126220 in linux-source-2.6.22 "[regression]  wireless card does not work in gutsy, ma311" [Medium,Triaged]  https://launchpad.net/bugs/126220
<jeromeg> same card as mine
<jeromeg> sorry got to go
<jeromeg> bye
<jeromeg> thx BenC 
<asabil> hi all
<asabil> did anyone take a look at bug 102818 ?
<ubotu> Launchpad bug 102818 in ubuntu "macbook volume control doesn't work" [Medium,Confirmed]  https://launchpad.net/bugs/102818
#ubuntu-kernel 2007-09-23
<lamont> kylem: thanks, btw.  -12.38 built
<lamont> (and is blocked by NEW for hppa, but that's OK)
<lamont> does LRM live in git?
<rtg> lamont: nope.
<lamont> ah, ok
<lamont> so the archive is the SCM for that?
<rtg> yes
<lamont> ok
* lamont works on a fix
<lamont> (hppa)
<lamont> 144MB tarball? wow
<lamont> competing with OO.o, I see
<rtg> It full of those binary blobs.
<lamont> yeah
<lamont> they'd be much smaller if we compressed them with AAC, you know. :-D
<rtg> It would be my preference as well, but BenC disagreed. 
<lamont> something to do with wanting to be able to uncompress them later, I suppose.
<rtg> I think LRM should be under git control.
<lamont> booring.
<BenC> we don't recompress them because we leave them as they came from upstream
<lamont> BenC: I was being silly and suggesting lossy compression...
<BenC> lamont: if you want lossy, just use "rm -f *" :)
<lamont> fwiw, at a minimum, I need to change the hppa build-dep on gcc-3.4 to 4.1, and then I'll see what more it needs to compile successfully
<rtg> I don't care about compression so much. I just think that all of the kernel packages ought to be managed in a standard way.
<lamont> BenC: it would be nice to drop lrm into git..
<lamont> largish, but good.
<BenC> we had it in git, but it was a real pita
<BenC> didn't help us at all
<lamont> ah, ok.
<lamont> I can see that with the size and the blobitude
<BenC> most of our lrm uploads are just ABI bumps, so git just adds too much overhead
<lamont> wfm
<lamont> lum and lbm both built, as did the kernel, so I think lrm is the only part left that hppa is lacking
<lamont> d-i even built
<lamont> well, will have in LP once I finish my current pulse and give it back in LP :-)
<lamont> BenC: if we packaged lrm as .orig + .diff.gz, that'd help with uploads at least somewhat...
<lamont> which is what we did/
<lamont> never mind... maybe I should go to bed
<lamont> hrm... if hppa ever supports any modules that require compiling things, we're going to have to deal with the multiple-compiler issue in debian/rules.
<lamont> in the meantime, it's ok
<lamont> BenC: any reason for me to not upload this fix now?
<lamont> debian/control* (drop b-d: gcc-3.4) and debian/rules (don't use gcc-3.4)
<lamont> W: linux-restricted-modules-2.6.22 source: maintainer-script-lacks-debhelper-token debian/linux-restricted-modules-generic.postinst
<lamont> neato
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.22-12.39 | Latest news: -Beta freeze upon us | New Kernel Team machine: http://kernel.ubuntu.com
<BenC> zul: ping
<zul> BenC: you are lucky I just sat down
<BenC> zul: The xen configs don't appear to be based on our stock generic config...any reason for that?
<BenC> e.g. CONFIG_FW_LOADER=m instead of our CONFIG_FW_LOADER=y
<zul> BenC: correct they are based on suse's xen kernels I could go through them today 
<BenC> zul: I was thinking the best bet would be "cat debian/config/i386/config{,.generic} > .config" and make oldconfig to get the xen options
<BenC> otherwise we risk different support in each kernel
<BenC> and the same for amd64
<zul> sure not a problem ill have to recompile then to make sure they still work though
<BenC> ok, I'd appreciate it
<zul> nop
<xhaker> BenC, mjg59 : could you please look into this upstream bug http://bugzilla.kernel.org/show_bug.cgi?id=8171
<ubotu> bugzilla.kernel.org bug 8171 in ACPICA-Core "acpi_serialize locks system during boot" [Blocking,Assigned]  
<xhaker> there is a patch there now! :)
<BenC> xhaker: I think we have that patch integrated in the latest kernel upload
<BenC> maybe not, I'll check though
<BenC> xhaker: is there a launchpad bug for this and confirmed it affects 2.6.22?
<xhaker> BenC, 1 sec
<xhaker> It's related to this one
<xhaker> https://bugs.launchpad.net/linux/+bug/116185
<ubotu> Launchpad bug 116185 in linux-source-2.6.22 "battery state not reported correctly" [High,Confirmed]  
<mjg59> Yes, that patch looks reasonable
<xhaker> and this one upstream
<xhaker> http://bugzilla.kernel.org/show_bug.cgi?id=8810
<ubotu> bugzilla.kernel.org bug 8810 in ACPICA-Core "Laptop needs acpi_serialize to works - HP Pavillion dv8230us" [Normal,Reopened]  
<mjg59> xhaker: So, just to clarify - the first patch just stops acpi_serialize from locking the system?
<xhaker> mjg59, yes.
<mjg59> Right. That should certainly go in.
<xhaker> mjg59, the first bug is about acpi_serialized not working right
<xhaker> mjg59, but the second upstream bug report might be a good read along the end
<mjg59> xhaker: Yes. It's still lacking a fix.
<xhaker> upstream is considering marking _BST always serialized
<mjg59> Yes
<xhaker> mjg59, you seem to have helped with a recent commit too, let me search it
<xhaker> 426ea6c8aadc921e499f490bb457086945b42a0d : Ubuntu: Allocate acpi_devices structure rather than leaving it on the stack.
<mjg59> That fixes a bug that I introduced myself
<xhaker> mjg59, ohh, i was under the impression it was 8171 related
<mjg59> No
<nixternal> toshiba satellite l35 w/ gutsy: kernel 2.6.20* works great, 2.6.22* does not work at all. when it gets to the point where it starts X, it just turns the display off and never comes up...any ideas?
<mjg59> So if you run gutsy with the feisty kernel, it works?
<nixternal> ya
<nixternal> thank god you answered :)  I am at a LUG right now and this laptop just will not work at all with the 2.6.22 kernels
<mjg59> Can you try blacklisting the video module and see if that makes any difference?
<nixternal> I can try that
<nixternal> so in /etc/modprobe.d/blacklist, I should add ati since that is what it is loading?
<mjg59> No
<mjg59> video
<nixternal> derr
<nixternal> no go
<mjg59> Which graphics drivers are you using?
<nixternal> ati
<mjg59> RIght
<mjg59> Try blacklisting radeon, then
<nixternal> k
<nixternal> still not working...this thing is a pain
<mjg59> Are you able to ssh into the machine?
<nixternal> it is sitting right next to me, I have physical access to it
<mjg59> And the console still works after the failure?
<nixternal> I can restart it in single-user mode
<mjg59> No, that's not what I asked
<nixternal> I can't access anything after the failure
<nixternal> I have to push the power button and hard power down
<mjg59> Does caps lock still work?
<nixternal> it is working at the terminal right now yes
<mjg59> After X has failed?
<nixternal> after x has failed, the only thing that seems to work is the power button...you can't tell if the caps lock is working or not as there is no indicator for it
<mjg59> Ok. So, can you ssh into the machine?
<IntuitiveNipple> nixternal: When X fails, can you so Ctrl+Alt+SysRq+K ?
<nixternal> hrmm, I need to install the server and give it a shot
<IntuitiveNipple> s/so/do/
<mjg59> IntuitiveNipple: Please don't confuse things
<nixternal> no doubt
<nixternal> :)
<nixternal> let me install ssh server really quick
<mjg59> Thanks
<nixternal> alrighty, going to let it boot up and crash, then try and ssh into it
<nixternal> mjg59: I can log in via ssh just fine
<mjg59> nixternal: When it's frozen?
<nixternal> yup
<nixternal> so obviously it isn't frozen, just no video
<mjg59> Ok. Can you grab /var/log/Xorg.0.log and put it somewhere?
<nixternal> yup
<mjg59> Right, let me know when you've done that
<nixternal> http://www.nixternal.com/tmp/Xorg.0.log
<mjg59> Ok, the radeon driver is still getting loaded
<mjg59> Try just deleting /lib/modules/`uname -r`/kernel/drivers/char/drm/radeon.ko
<nixternal> that is my fault, I remove the blacklist before I rebooted
<mjg59> No, I suspect the server is triggering the load itself
<nixternal> hey, refresh that log, I just uploaded an updated, while I wait to get root access tot he laptop to delete the module
<nixternal> one sec
<mjg59> It's the same
<nixternal> OK, moved that file out of there, give it a reboot?
<mjg59> Yes
<nixternal> k
<nixternal> holy smokes
<nixternal> it booted up
<mjg59> Right. Please file a bug against xserver-xorg-video-ati and linux-source-2.6.22
<mjg59> There's a bug in either the dri or drm implementation there
<nixternal> roger that, I will work on that
<mjg59> Include the Xorg.0.log
<nixternal> the one on my server right now, or the one that is booted up now?
<mjg59> Both would be good
<nixternal> before and after...roger that
#ubuntu-kernel 2008-09-15
<BigBear> what i/o scedular does ubuntu use by defualt?
<_ruben> hrm .. i want to take an existing kernel version (say: 2.6.24-16.30), and want to roll my own version of it (including 2 small patches) .. currently im rebuilding using the old make-kpkg approach, but im having difficulties mimicing the 'standard' versioning scheme
<alex_joni> _ruben: grab it from git, and make a custom flavour
<_ruben> hmm .. sounds like smth i could investigate indeed
<alex_joni> there is a quide around wiki.ubuntu.com about building kernels from git
<alex_joni> that should get you started
<_ruben> havent checked wiki yet, using https://help.ubuntu.com/community/Kernel/Compile now
<alex_joni> ok, that sounds good
<alex_joni> you need to mess with debian/binary-custom.d/
<alex_joni> add another custom binary flavour, put you patches and config there
<alex_joni> then build using: "AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules custom-binary-FLAVOUR"
<_ruben> git clone in progress
<_ruben> hmm .. the git/flavour approach seems pretty straightforward .. nice job
<_ruben> to get the -server config .. i'd just cat debian/config/$ARCH/config and debian/config/$ARCH/config.server to one file i guess/
<munckfish> BenC: got a sec?
<BenC> munckfish: sure
<munckfish> Over the weekend I sent a pull request for Linux Ports cause I've finally managed to get together a stable build for the PS3
<munckfish> I just wanted to know what the next steps are to get it into the intrepid repos
<munckfish> note that I haven't been able to test build on anything but Cell
<munckfish> so I don't know what the options are for the other arch's
<munckfish> BenC: over
<BenC> munckfish: I'll take a look after I catch up on email (been off for a week)
<munckfish> BenC: sure take your time
<_ruben> how can i get my kernel git tree to 'represent' 2.6.24-19.41 ? .. i just want to apply 2 small patches to a given kernel and not change anything else (code-wise)
 * _ruben lacks proper git skills and background info on the kernel git tree
<munckfish> _ruben: can you not apply them to the current development version of the kernel from the ubuntu-hardy git tree?
<munckfish> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=summary
<munckfish> Or do you specifically just want to add these patches for yourself and do not intent to contribute them?
<_ruben> munckfish: personal (testing) use only .. im interesting in performance differences :)
<munckfish> _ruben: the easiest way is to just checkout the hardy source as is and work with the current development version
<munckfish> _ruben: the less easy way is to create a branch starting on 2.6.24-19.41
<_ruben> munckfish: how "less easy" would that be? :)
<munckfish> it's worth you look at the docs for git branch and git checkout
<_ruben> i browsed the commit log, but couldnt even pinpoint the exact commit to take as reference (19.41 is mentioned multiple times)
<munckfish> you can reference the tag for that version
<munckfish> see "git tag"
<_ruben> ah, nice
<munckfish> Stefan Bader tagged the version you want here: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=0717f584cfe10c9772b1b5daba51485c419fbe18
<munckfish> instead of specify a branch to to branch from
<munckfish> give the tag name instead
<munckfish> Git is a great great system - but it does take a while to get to grips with it
<_ruben> seems reading up on git is smth to add on my (huge) todo list
<munckfish> worth it though imo
<munckfish> Yeah I'd recommend it - have you seen the Ubuntu kernel KnowledgeBase docs?
<munckfish> they're on the wiki
<munckfish> _ruben: you'll need to follow the instructions on the Maintenance guide to make a kernel build which ends up as a deb
<munckfish> that is without building loads of stuff you don't need just to test something
<_ruben> still havent checked the wiki yet .. working with https://help.ubuntu.com/community/Kernel/Compile .. will search the wiki now
<_ruben> actually i had the wiki open as well .. just not a very helpfull page (for me) https://wiki.ubuntu.com/KernelGitGuide
<amitk> _ruben: https://wiki.ubuntu.com/KernelMaintenance
<_ruben> amitk: was just reading that one
<amitk> ..if you are looking to build Ubuntu-based kernsl
<_ruben> tho my current quest is more a git one than a kernel one i'd say :p
<_ruben> as in: "how to gt my git tree to represent 2.6.24-19.41 instead of head"
<_ruben> but kernel.org isnt liking me thusfar (for the git docs)
<amitk> _ruben: any reason you do not want to clone the kernel tree from kernel.ubuntu.com?
<_ruben> amitk: i am using that, mentioned kernel.org wrt documentation of git :)
<_ruben> hmm .. my custom kernel build (based on uptodate git tree) has a linux-headers packages which depends on linux-headers-2.6.24-22 but that one doesnt get build
<_ruben> debian/rules binary-headers seems to do that trick :)
<munckfish> _ruben: unless you really need the headers you should just be able to install the linux-image-* package
<_ruben> munckfish: i needed the headers to recompile a kmod .. but i succeeded at that .. and so far im not seeing any performance difference .. so this little project goes in the fridge for now :)
<munckfish> ok
<_ruben> thanks for the help/pointers tho
#ubuntu-kernel 2008-09-16
<hyperair_> where can i get 2.6.27 kernel images for testing in hardy?
<hyperair_> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/234738/comments/2
<munckfish> BenC: did have a chance to look at my linux-ports pull request yet?
<BenC> munckfish: still settling back in after vacation...got some high priority stuff to handle first
<munckfish> BenC: ok understood - any idea when you may have time to look at it? Quite keen to get it onto a daily build so I can start weeding the install/upgrade process.
<munckfish> Or ... is there someone else who could evaluate it, who's less on-the-critical-path than yourself?
<munckfish> BenC: also, I'm quite concerned to know how best to get the changes regression tested/validated for the other architectures
<munckfish> BenC: is that something you would take care of or should I rally some testers on the kernel team list?
<laga_> BenC: aufs? ;)
<munckfish> BenC: whatever the simplest path to inclusion is, that doesn't burden you time wise
<BenC> laga_: I believe amitk was looking at that
<amitk> laga_: I'll get to aufs ASAP. I've been side-tracked by some bugs.
<amitk> laga_: but we'll accept a patch too :)
<BenC> amitk: laga_ sent one to kernel-team@ not too long ago, IIRC
<amitk> BenC: that version is too old. It still contains deadlock bug in the rename() syscall
<amitk> laga_: ^
<laga_> amitk: well, it was whatever version was in the kernel AFAIK 
<laga_> the version in the kernel probably was not a regular "monday" release but a CVS checkout 
<laga_> i'm afraid i dont have time right now to prepare & test yet another patch. maybe i'll get to it on the weekend
<amitk> laga_: what do you mean by "in the kernel"? aufs isn't upstreamed yet, AFAIK
<laga_> amitk: "in the kernel" -> the version in the intrepid kernel as committed by benc.
#ubuntu-kernel 2008-09-17
<elkan76> Hi!
<elkan76> I 've a doubt, on september 12th an update, drops down my wifi, and i report the bug (#269533), today another update was fixiing the bug (#259816) fix my wifi , but a half hour later it drops down like the first time, i repport this and go tu the second bug tu link them because the work to fix it has effects on my system. I'm using the proposed kernel.
<philsf> where can I get the kernel 2.6.27, that is mentioned in possibly all kernel related bug reports, for hardy?
<nullack> Hi kernel team :) Does the intrepid alpha kernel have any debugging code that would slow it down
<nullack> Im trying to chase down some performance problems
<nullack> philsf Such a configuration would be unsupported and would need to be compiled by you
<nullack> philsf Intrepid has that kernel revision but its Alpha software so it comes with the usual caveats
<philsf> so, the ubiquous message from ogasawara across the bug reports actually calls for intrepid testing, and not just the kernel?
<nullack> yep, no .27 in hardy
<philsf> what about the bugs in hardy, won't they be fixed?
<nullack> They might be as backports
<philsf> I see, thanks for the info, then
<philsf> nullack: as a side question, some bugs I subscribe to are considered "fixed" because they no longer appear in intrepid. Shouldn't hardy deserve the fix as well, being LTS?
<nullack> philsf If the fix works in Intrepid then it might be considered for backporting onto Hardy
<philsf> nullack: what can I do, as a user, to make it happen?
<nullack> https://help.ubuntu.com/community/UbuntuBackports
<philsf> well, duh, I should've known better by now :) thanks again
<wgrant> nullack: No. That's not for backporting fixes.
<wgrant> Important fixes may be SRUed, but Ubuntu Backports are not for fixing bugs.;
<nullack> wgrant : Wouldnt a new version of a package be backport? The difference between SRU and Backports isnt clear to me
<wgrant> SRU is for fixing bugs.
<wgrant> Backports are for new version.
<wgrant> Kernels will not be backported.
<wgrant> Backports will not be granted to fix bugs.
<nullack> wgrant : So an SRU could involve a version upgrade by fixing a bug? Whereas a backport is to get new features offered in new versions?
<wgrant> An SRU will involve only the minimal patch needed to fix the bug.
<wgrant> Unless you are Mozilla.
<nullack> wgrant : right, thanks mate for helping me understand :) Makes sense from a regression point of view
<wgrant> Yes. We do not do crazy things like some other distros.
<philsf> and yet are no so conservative as debian
<philsf> *not
<wgrant> With regard to SRUs we are rather close.
<wgrant> Except that they do them all at once.
<philsf> is the -updates repo only for SRUs, or are there other kind of updates there? It's a rather dynamic repo there
<wgrant> -updates is only for SRU.
<wgrant> +s
<wgrant> Well, security updates are also copied into there now for various reasons, but they're generally even more conservative.
<lukehasnoname> bug #59695
<nullack> Im trying to chase down some performance problems in Intrepid. Can any kernel folk advise me if the Intrepid Alpha has debug code in it slowing it down?
<nullack> i.e. The Alpha kernel
<TheMuso> nullack: I wouldn't think so. I think the debug code for the kernels is in a separate package.
<TheMuso> However, I am not a kernel dev, so don't know for sure.
<nullack> TheMuso : Thanks, btw, Im on your PPA for PA, working well
<TheMuso> nullack: Sounds good, however I think 0.9.10 will be used for intrepid. Too many regressions from other users that need addressing at he alsa level.
<TheMuso> As well as stream switching, and usb card/speakers issues.
<nullack> TheMuso : yep thats why having test coverage as wide as possible is important :)
<TheMuso> nullack: Totally.
<TheMuso> Maybe for jaunty.
<persia> Good day.  I've some questions about kernel packaging, and hoped someone could direct me.
<persia> Firstly, I've noticed that the linux-meta package seems to be arch-dependent, rather than arch: all.  I wondered if this was due to convenience of packaging with the git tree, or was chosen to meet the constraints of "depending on the latest kernel".
<persia> Also, I've noticed that the various ports all seem to have linux-$(architecture) as the name of the package.  Would it be sensible for an arch-dependent metapackage to also provide "linux" that depends on e.g. "linux-powerpc"?
<persia> Lastly, I'm wondering how the -meta packages are tracked.  Is there a script that pulls them out of git, or are they handled as source packages directly?
#ubuntu-kernel 2008-09-18
<persia> I'm planning an upload of linux-lpia and linux-meta-lpia.  If anyone with any experience with packaging kernels is about, and has time to discuss the implementation, I'd be very appreciative.
<zul> BenC: the drbd modules and userland doesnt seem to be in sync we are shipping 8.x userland but the kernel is using modules for 8.2.x should I send a patch?
<BenC> zul: is the kernel module newer?
<zul> BenC: yeah im getting the user to test the newer userland if it works for him Ill probably ask for a FFE then
<BenC> zul: sounds good
<BenC> zul: we need the newer kernel module to work with 2.6.27, so backing it down isn't as easy
<zul> BenC: yeah I realized that yesterday
<kryptonite_> hi all
<kryptonite_> why ubuntu fails in reading vcd
<munckfish> BenC: have you had any time to look at the ports stuff?
<munckfish> BenC: I don't want to become PITA - what's going to be the best way to move forward?
<BenC> munckfish: can you do uploads?
<munckfish> BenC: nope
<munckfish> :(
<munckfish> I'm a bit powerless
<munckfish> BenC: I'd dearly like to have a decent chat with you about ports and it's future. Maybe could it be on the agenda for next weeks kernel meeting (if there is one)?
<munckfish> I want to understand a) who the other interested parties are in the KT, b) what the general feeling about it is c) how can I get to stage where I don't need to bug you d) what the future of the ports kernel is e) how interested you are in it compared with time you have avail to work on it.
<munckfish> those sorts of things
<BenC> munckfish: That sounds like a great topic
<munckfish> BenC: cool
<munckfish> I'm glad you think so
<munckfish> Do you actually have a PS3 or were you just helping out Colin when he got one?
<BenC> I have two :)
<munckfish> Oh nice :)
<munckfish> And I take it you still have a stack of great kit out in your barn :D
#ubuntu-kernel 2008-09-19
<DHR> I *hope* that this counts as developer discussion.  Hardy's kernel has a bug that I reported.  The response was that there was a fix in 2.6.27.  But 2.6.27 doesn't work because there is no v86d, needed for uvesafb.  Is this easy to fix?  Will it be fixed?  See http://kernel.ubuntu.com/pub/next/2.6.27-rc3/{all,hardy}
<DHR> Separate question.  Some BIOSes set up the MTRRs with nested ranges.  Several X video drivers cannot then change their video buffers to Write Combining; they either refuse to run (proprietary ATI driver, for example) or run at reduced efficiency (Intel driver).
<DHR> Solution 1: There is a kernel patch to reorganize MTRRs to solve this.  Solution 2: The better approach is to use PAT, and this will happen eventually.  Solution 3 (maybe): I've written a userland program to reorganize MTRRs.
<DHR> Is anyone here interested in my program for Solution 3?
<DHR> My first question relates to bug 246269
<DHR> My second relates to bug 224404
<CarlFK> DHR: im no dev, but my advice is to post your comments and patches to the bug reports 
<DHR> CarlFK: thanks.  I have done so for the first but gotten no response.  I'm working on responding to the second.
<stephantom> hey there. I've just upgraded a testing machine to intrepid, and the new kernel won't boot. normally there would be something useful in the logs that would tell me what's wrong. but I can't find anything. it just... stops. have a look, please: http://nopaste.biz/51874
<stephantom> any ideas?
<abogani> stephantom: Do you already tried to boot disabling acpi?
<stephantom> nope, will do that
<abogani> stephantom: and also with wlan turned off.
<stephantom> i had a feeling that might be an issue :)
<abogani> :-)
<DBO> is there any realistic way I can look to help Ubuntu support suspend on my thinkpad (intel GPU)
<DBO> where do I ask for help with Suspend in intrepid?  There seems to be very few people with a good working set of knowledge on the subject
<DBO> I have a new Thinkpad T500 and am willing to allow remote access if need be
<DBO> also willing to allow complete system trashing
<DBO> it just got installed
#ubuntu-kernel 2008-09-20
<fta> fyi, i'm having a whole bunch of those with the latest kernel on intrepid: http://paste.ubuntu.com/48442/ Should i file a bug?
<wgrant> fta: There's a bug on that... it's at the top of the 2.6.27 regression list linked to in the 2.6.27 status email sent yesterday, I believe.
<Nafallo> wgrant: you're not online
<wgrant> Nafallo: You are "service unavailable"
<wgrant> I'll check logs in a sec.
<Nafallo> :-/
 * laga waves
<laga> i'll prepare a new aufs patch.
<laga> with a current aufs release, unless someone objects. amitk complained that the patch i posted earlier still has some issues resolved in current aufs versions
<wgrant> laga: Any chance of having CONFIG_AUFS_HINOTIFY enabled?
<laga> wgrant: i'll look into it
<wgrant> laga: Thanks. It's a bit annoying having to maintain a local patch for just that on production servers.
<laga> hum. i think we could just apply the patch that fixes the deadlock issue to my patch. that'd save me some work :)
<laga> how can i use ccache or distcc with the kernel build system? simply export CC?
<alex_joni> yup
 * alex_joni uses ccache usually
<laga> great. i guess i wont need distcc then..
<laga> hum
<laga> aufs was added as a big monolothic patch cobbled together from an upstream checkout and several patches
<laga> this is a huge PITA to work with
#ubuntu-kernel 2008-09-21
<Kano> did somebody see that kernel 2.6.26 and newer only detect 32 gb from the hds which was fully seen with 2.6.24?
<Kano> http://kanotix.com/files/fix/alewe/
<Kano> there i have put some logs
<Kano> looks like it detects HPA with 2.6.27
<Kano> which is unlocked by default with 2.6.24
<Kano> because hpa unlock for 2.6.24 and hpa detected for 2.6.27
<dody> bagaimana cara intalasi gyachi
<dody> ada yang bisa bantu
<Kano> static int ata_ignore_hpa = 1
<Kano> was in 2.6.24 -> drivers/ata/libata-core.c
<Kano> http://www.kroah.com/log/linux/lpc_2008_keynote.html
<Kano> did  you read this *g*
<Kano> * libata: Default to hpa being overridden
<C10uD> hello there
<C10uD> i'm using intrepid, latest updates and i get this error once a while in syslog
<C10uD> error that slows down the system
<C10uD> http://pastebin.com/m5a0a401b
<Kano> i saw those too here, just only the EH compete ones
<Kano> is it nforce2?
<C10uD> nope, it's via
<C10uD> quite an old motherboard though
<C10uD> i've found something on the internet, but not recent stuff due to kernel upgrades
<C10uD> i re-must try previous kernel btw, even if i think it worked flawlessy if the kernel is the problem
<C10uD> seems  2.6.27-2-generic isn't having this problem
<C10uD> i'll try -3 again hoping that was just a temp error
<C10uD> ok, this is definitely a regression (?)
<C10uD> should i file a bug on launchpad?
<laga> sure
<C10uD> what do you think i should include apart from syslog? :p
<laga> a good description of your problem
<laga> the good and the bad kernel versions
<laga> etc
<C10uD> kk
<C10uD> thx
<C10uD> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/272835
<C10uD> just in case someone wants to play with it
<C10uD> switch back to -2 kernel
<C10uD> brb
#ubuntu-kernel 2009-09-14
<dholbach> hiya
<dholbach> can anybody tell me if this looks like a kernel problem or more of a Keybuk-boot problem:
<dholbach>  the last thing when I boot on the other machine is "ACPI: I/O resource nForce2_smbus [0x1c40-0x1c7f] conflicts with ACPI region SM01 ............. Error probing SMB2"
<dholbach>  but I get the feeling that that message has nothing to do with the hang on the machine I'm seeing
<dholbach>  if I boot with bin=/bin/bash the last thing I see is "bash: cannot set terminal process group (-1): Inappropriate iotcl for device" "bash: no job control in this shell"
<dholbach>  this is the latest karmic with the ubuntu-boot ppa enabled
<dholbach>  Keybuk: ^ any idea what I could do?
<jk-> dholbach: you mean init=/bin/bash ?
<dholbach> jk-: oh yeah, that's right
<jk-> looks like bash is starting up OK, just giving you a warning.
<dholbach> ok... so it might actually be something boot-related breaking
<jk-> it may not have correct access to the console device
<dholbach> and not the kernel
<apw> tend to agree, would be suspicious its boot and not the kernel
<dholbach> the ACPI smbus thing seems to be unrelated?
<apw> you may even find it will respond to commands even if it does not look like its prompting
<jk-> yeah, make sure you have /dev/ populated
<apw> which with init as bash you won't without devtmpfs
<dholbach> erm... I think I'm seeing a very very weird thing right now - after booting from a livecd and running fsck and smartctl it works again now (both reported no errors and didn't say anything about fixing something?!)
<dholbach> Keybuk: nevermind
<dholbach> apw, jk-: thanks guys - I have no idea what "fixed it now"
<apw> hrm ... computers ...
<dholbach> might be a good idea to get a replacement disk :-)
<apw> heh ... lets hope not
<dholbach> at least have it ready and do a backup again :-)
<thux> hi, with one hardware my jaunty waits long time 'starting to boot' on screen. acpi=off reduces that time but complaint pnpbios. and if acpi=off and pnpbios=off again 'starting  to boot' show long time. is there a way around  this? 
<smb> thux, Its hard to say something on that. It might be some subsystem that just takes long to initialize. And with the combination that seems to be faster it might not be there at all. I assume you removed the "quiet" from the command line and still there is nothing between the first line and the boot?
<apw> thux one would need to get the dmesg output from the boot and see if there is an obvious time delay in the timestampts there.  may give a clue as to cause
<thux> ok I try first remove quiet and then put dmesg to pastebin
<apw> smb, as a heads up, karmic intel graphics are looking like they have hang issues ...
<smb> apw, I noticed from comments last week. Seems mostly ok on the aa1
<apw> i am suspicious it only triggers after a suspend/resume
<smb> I had, not yet, a complete lockup as you had. There is a strange case of the netbook launcher sometimes ignoring the mouse after a while. But that is rather something else
<smb> apw, What model do you have? 945GME?
<thux> here is my dmesg http://pastebin.com/m5185a0b0
<smb> [    9.224019] pci 0000:00:1d.7: EHCI: BIOS handoff failed (BIOS bug?) 01010001
<thux> yes
<smb> This seems to be the problem
<thux> before that line it waits now
<smb> Is USB working after this for you?
<thux> yes
<smb> If I read this message correctly there is a problem transferring control of usb from the bios to the kernel
<thux> i have many usb devices plugged only hp laser sometimes not detected
<smb> If there are settings in the bios to control usb support, you might play around with them. But often you want early usb support for usb keyboards
<thux> yes i have that
<apw> does the problem occur if you boot without any usb devices attached
<apw> smb, i have both 945GME and GM45E's showing the issue
<smb> apw, Ok, I also try to keep an eye on it. Though I am running mixed stuff, Jaunty userspace with -10.31 kernel and x-org-edgers X
<apw> heh ... franenstein
<smb> :) Ubuntu, Halloween edition ;-)
<apw> actually thats interesting as these hangs can just as easily be a bad gpu usage from mesa as they can be kernel issues ... so ... a different mesa combination should be an interesting control
<apw> i like the sounds of that ... Ubuntu, halloween
<apw> horrific halloween
<apw> shame we have used up HH
<smb> Hehe, and its no animal... 
<smb> I should compare the mesa versions against yours. The edgers should in theory be near Karmic, shouldnt' they?
<apw> halloween hyena
<apw> yeah near, but i'd expect them to be ahead a little
<smb> Mine are all 7.7.0-git20090911.a79eecb9-0ubuntu0tormod-jaunty
<thux> there was a setting in bios for usb hand off and it was disabled, i enabled it and now it boots normally, thanks :)
<thux> wonder why it was default disabled
<smb> you're welcome. good to hear. Meh would not think about it... Maybe works better with the other OS... 
<thux> ah that i see 
<apw> cking, gnarl, did either of you report the sd card not mounting thingy
<cking> nope
<smb> apw, Don't think so... Though not mounting thingy is a bit broad
<cking> it was steve who hit this issue
<apw> oh welll i've filed 5 today, wahts one more
<apw> if only i knew what the heck was meant to handle it
<smb> apw, does it only affect sdhc or all or is the reader not detected?
<smb> normally the reader would issue a udev event for a device getting ready (I think)
<apw> the card is detected and the devices are all made, the partition table is read, and the p1 device is made
<apw> its the next step, the mounting it and popping up boxes to show it that don't occur
<smb> Is /media/bla created?
<smb> Err well likely not
<smb> as you say it does not get mounted
<smb> In theory the partition scanning is also done in udev ... Do you get any error message in dmesg?
<smb> I believe each partition should also do a uevent, then udev call blkid and create the symlinks /dev/disk/by-... The mount step might be device-kit...
<apw> smb, no it doesn't get mounted
<apw> the p1 device does get mounted
<smb> apw, ??? huh
<apw> _made_ sorry
<apw> not mounted
<apw> there are by-id files as well
<smb> The id files at least show the partition got through blkid. I just cannot grep the statement about the p1 device. So nothing gets mounted, correct?
<apw> i meant that it does partition discovery correctly and finds it has a partition and makes mmblk0p1 as well
<apw> nothing is mounted as a result.  manual mount triggers gnome to find piccies etc
<apw> i've filed it on gnome-volume-manager, bug #429257
<ubot3> Malone bug 429257 in gnome-volume-manager "MMC cards no longer auto mount" [Undecided,New] https://launchpad.net/bugs/429257
<apw> i am a bug filing machine ... 4 today alone
<smb> apw, Shame, you should fix them. ;-)
<apw> na, i file them _you_ get to fix them
<apw> most are these intel graphics hangs ... bah
<smb> If its Karmic, I can' see it (yet) :)
<smb> apw, But seriously, I am not completely sure, the automounting thing seemed to be tied to a desktop (so gnome) but (might check up on this later) might have moved to something more generic to work without a running desktop too...
<apw> smb, yeah figured i file with gnome thingy as thats description included automounting, someone else can move it
<cking> apw, I'm seeing a lot of messages: "TKIP: RX tkey->key_idx=2 frame keyidx=1 priv=de21d780" - is this new with the latest kernel?
<apw> cking, hmmm not sure
<apw> [   10.393047] lib80211_crypt: registered algorithm 'TKIP'
<apw> changed your AP setup recently?
<apw> not getting it here, but that is a WPA2 thing iirc ?
<cking> yep, WPA2
<cking> apw, I've rebooted my router today, surely, that's not caused this message?
<apw> whats your driver here, that message appears to be in the rtl8187se driver
<apw> looks to always have been in there
<cking> it's the broadcom wl driver 
<cking> :-(
<apw> yay
<cking> nggg
 * amitk welcomes csurbhi to the kernel team
<smb> Hi csurbhi 
<csurbhi> Hi !
<csurbhi> thanks Amit
 * apw waves to csurbhi 
<csurbhi> hello apw :)
<apw> csurbhi, so hows it going so far
<csurbhi> reading up the docs and setting up accounts.. other than that.. descent
<csurbhi> :)
<smb> Luckily there is help close. :)
<csurbhi> yes.. thats right
<rtg> apw, I wonder why we have CONFIG_LIB80211_DEBUG enabled ?
<rtg> csurbhi, howdy
<csurbhi> okie dokie
<apw> debian.master/config/config.common.ports:# CONFIG_LIB80211_DEBUG is not set
<apw> debian.master/config/config.common.ubuntu:# CONFIG_LIB80211_DEBUG is not set
<apw> rtg ?
<smb> backports?
<rtg> apw: hmm, then what kernel is pgraner running that he would get the 'CCMP: replay detected' message?
<smb> updates/compat-wireless-2.6/config.mk:# CONFIG_LIB80211_DEBUG=y
<apw> rtg ahh we jut hit that with cking, a couple of the WL drivers contain the whole damn 80211 stack in them with mods
<apw> and it may be on there
<rtg> apw: it is indeed enabled in LBM
<smb> rtg, apw, Or he has LBM installed
<cking> I have LBM installed
<apw> i think pete has the cranky wl driver doesn't he?
<rtg> apw, rt73 IIRC
<rtg> apw: actually, rtl8187se
<apw> cking, which rt driver did you have, it was that rtlxxxse one wasn;t it?
<apw> that definatly has the 80211 in it en-toto
<apw> a staging driver horror show and no mistake
<cking> a;w
<cking> apw, I saw this on my wl broadcom driver
<apw> gibber
<apw> its everywhere, and spreading :)
<cking> it's on my HP mini 1000 ;-)
<rtg> apw, how about Keybuk's ext4 patch? 'ext4: Don't update superblock write time when filesystem is read-only'
<apw> i've not heard back from him that i know of on its effacacy
<apw> Keybuk, did you get to test that kernel i did?
<Keybuk> apw: did you ever e-mail it me?
<apw> i pointed you to it on here ... 
<Keybuk> see, that never works :p
 * Keybuk doesn't read IRC scrollback
<apw> ahh ... damn
 * apw finds it
 * Keybuk finds his laptop under things
<apw> http://people.canonical.com/~apw/lp427822-karmic/
<apw> mine is burried in bugs
<ogra> Keybuk, hmm, you only talk abour east of UTC 
<ogra> *about
<ogra> Keybuk, (see #ubuntu-devel, loic-m is surely in france but seems to see a similar thing)
<Keybuk> ogra: france is very much east of UTC
<Keybuk> I realise that, historically speaking, they are very unhappy about that
<Keybuk> and feel that the prime meridian of the world, and thus all timekeeping, should pass through Paris
 * ogra must have gotten his sense of east and west wrong 
<apw> heh
<Keybuk> but that was not the consensus of the rest of the world
<Keybuk> and if they're still clinging to that, we can't help them :p
<rtg> Keybuk, you're poking the hornets nest
<apw> Keybuk, sorry about the email, i'll remember that for next time
<Keybuk> rtg: it's a hobby ;)
 * apw files his 7th bug of the day, sigh
<Keybuk> apw: if I'm actually paying attention to IRC, it's usually ok - also /msg is always good - I save those and read them back
<Keybuk> but things-on-a-channel I don't tend to notice if they go off the top of the screen while I'm not looking
<apw> ahh right, fair enough
<rtg> My use of IRC isn't much different.
<rtg> its a lousy bug tracking mechanism
<Keybuk> ogra: the recovery-while-read-only bug affects everyone from Britain (in Summer time) through Europe, across Eastern Europe, the Middle East, Asia, Indionesia and Australia and (I think) NZ
<apw> all true
<Keybuk> rtg: for me it's a getting-things-done defence
<Keybuk> IRC is a productivity black hole
<rtg> indeed
<Keybuk> if I wake up and start reading through things like e-mail or IRC, then I may as well write off being productive in the morning
<ogra> Keybuk, yeah, i always get the sides wrong here :P
<Keybuk> and I find that people tend to notice when you're back and remind you about things anyway
<Keybuk> ogra: what's nice is that it's the exact opposite of the init scripts bug
<Keybuk> which only affected Merkins
<ogra> heh
<rtg> Keybuk, new topic. anything changed recently that I should investigate that slows the boot time on my SSD laptop? It used tyo be 28 seconds, but has gotten much longer since late last week.
<Keybuk> rtg: I've noticed some slowdown with recent kernels myself
<apw> my main laptop seems to take hours to login these days
<Keybuk> both on SDD and HDD
<apw> specially now as its hidden the feeling of length is even worse
<Keybuk> I figured that the IO elevator of the week wasn't working as well as last weeks'
<rtg> Keybuk, you think its kernel related?
<Keybuk> rtg: I'm not sure what else has changed
<apw> we added xsplash
<apw> osd seems to have lost its mind
<rtg> I'm watching the GDM throbber just sit there and flash at me, no disk activity
<Keybuk> hmm
<Keybuk> odd
<Keybuk> couchdb?
<rtg> dunno what couchdb is
<Keybuk> silly desktop database stuff they added for Ubuntu One
<Keybuk> it's quite heavy
<apw> nnng
<Keybuk> and seems to sit there for a few minutes
<ogra> isnt it erlang too ?
<apw> that reminds me it exploded on my other laptop
<apw> ubuntu one
<rtg> some serious bitching is in order if thats what it is
 * ogra wonders how fast/slow erlang is compared to other langs
<apw> can we tell from a bootchart
<ogra> loading another interpreter during boot is surely not speeding up things
<Keybuk> probably
<apw> Keybuk, are we using sreadahead by default now, could that be contributing to slowness
<apw> in the sense we are upgrading a lot, it will be loading old junk?
<ogra> if you got a new apparmor profile it will definately slow down the next boot after that
<Keybuk> apw: one of the main reasons we switched to sreadahead is that it reprofiles often
<Keybuk> it may be simply that you upgrade before every reboot
<Keybuk> so every boot sreadahead is profiling
<Keybuk> (rather than assisting)
<apw> now that i almost always do do yes
<Keybuk> I've also noticed a strange issue that I think is ext4, but can't place it
<Keybuk> after people upgraded to my PPA, and rebooted
<Keybuk> they have a 4-6s "exe" process that seems to be somewhere around the point the root filesystem was mounted
<Keybuk> it's almost as if, after major upgrades, ext4 has to do lots of work before it can mount the filesystem next time
<Keybuk> that needs investigation
<apw> its called 'exe' in the profiles?
<Keybuk> yes
<Keybuk> that's what confuses me
<apw> how does the name get generated for the profiles, from the executable link?
<apw> interestingly that link is call 'exe', so perhaps its what things get called which are not convertable back to a name
<apw> i wonder if the chrooting madness and rm madness going on at root mount time leaves us with bad /proc/NNNN/exe links and bad names in the profile
<apw> ie. it could be anything
<Keybuk> right, that's what I think
<Keybuk> that it's something run from the initramfs, just before it's cleaned up, so the link never exists
<apw> hmmmmm
 * apw goes for a couple of boots to see if that speeds things up
<apw> Keybuk, i am getting 1m frm bios to X, 1:22 to bios to gdm, 34s gdm to desktop.  now this is a HDD, so i'd expect it to be what 30s total?
<ogra> try a second one :)
<apw> (that was second boot, so i assume sreadahead has done its thing)
<apw> ogra, that was the second one
<ogra> ah
<apw> still seems like an insane length of time
<ogra> i see a few added seconds every time i get an updated apparmor profile for an app
<apw> ouch
<ogra> which i was told is normal now 
<Keybuk> can you get a bootchart of that
<ogra> since apparmor turns the profile textfiles into binary thingies
<Keybuk> use bootchart=nostop on the kernel command line
<Keybuk> then once you're a desktop, run sudo /etc/init.d/stop-bootchart start
<apw> Keybuk, sure
<apw> yay java ... sigh
<ogra> apw, whats wrong with java ? ... as long as you dont have to touch its code it's usually fine :)
<apw> Keybuk, ok got it, seems sreadahead runs for a full 90s, that seems unreasonable to me
<Keybuk> apw: really?
<Keybuk> when you login do "status sreadahead"
<Keybuk> what does it say?
<apw> apw@dm$ status sreadahead
<apw> sreadahead stop/waiting
 * apw pushed up the data to rookery
<apw> if this image is to be believed, then it sustained like 44MB/s for that 90 odd seconds
<apw> which is like 4GB of poop
<apw> http://people.canonical.com/~apw/bootchart/
<apw> does the green line on the bar there show instantaneough thorugh put?  of so its like 100k/s over that time?
 * apw has a nother go
<apw> Keybuk, ok the second boot was a little better, so lets assume the first one was a reconfigure or something
<apw> device discovery takes like 20s alone
<Keybuk> status sreadahead - if that says "stop/waiting" then your boot was assisted by sreadahead 
<Keybuk> if it says "stop/killed" or similar, then your boot was *reprofiled*
<Keybuk> apw: the -2
<Keybuk> that shows the exact same I/O weirdness that I see
<apw> what bit?
<Keybuk> the entire system spends most of its time in I/O wait
<Keybuk> http://people.canonical.com/~apw/bootchart/dm-karmic-20090914-2.png
<Keybuk> the two graphs along the top
<Keybuk> the first graph, blue is CPU usage, red is I/O wait
<Keybuk> the second graph, red is disk utilization, the green lines are throughput
<apw> yep, so that would imply its nailed waiting for disk
<Keybuk> so that's showing
<Keybuk>  1. your system is spending almost all of its time in I/O wait (BAD BAD BAD BAD)
<Keybuk>  2. your disk is continually utilized
<Keybuk>  3. almost no throughput is being achieved, despite the continuous utilization
<Keybuk> I'd also point out where this starts
<apw> so read ahead is sucking?
<Keybuk> deep inside the initramfs
<Keybuk> in fact, last time I debugged this, it started as soon as you loaded the disk controller
<Keybuk> which implies something seriously wrong in the kernel
<rtg> apw, do you still have older kernels installed?
 * apw would have a bunch of them yes
<apw> i'll go back to something older and see
<rtg> apw, IIRC -8 worked well.
<apw> if its the kernel it would imply its more like kernel readahead sucking
<apw> anyhow ... i'll try -8
<Keybuk> apw: could be, though again, it starts in the initramfs
<Keybuk> this is quite important
<Keybuk> it starts *before* we mount the root filesystem
<Keybuk> it starts before we even know which block device is the root filesystem
<apw> could it just be bad stats rather than actual anything
<apw> enough to throw off sreadahead
<Keybuk> sreadahead doesn't look at stats
<Keybuk> but I don't think it is bad stats
<Keybuk> my Dell laptop has exactly this problem
<Keybuk> and has had for a while now
<apw> though my disk light is nailed ... and its rattling like hell
<Keybuk> this is why you hear me whining continuously about I/O performance
<Keybuk> *but* other laptops and hardware I have *do not*
<apw> but there is io perf and io perf
<apw> mine is a dell
<Keybuk> I suspect it's controller related
<apw> a horrible thouught
<apw> -5 is as bad
<Keybuk> apw: I have tested your kernel packages, and they are good
<apw> Keybuk, most excellent
<apw> Keybuk, i am assuming you will be going back to ted, and we'll get a pair of patches from you when thats ready?
<apw> Keybuk, do you know waht this 'utilisation' on the disk actually is, which stat it is
<apw> we don't seem to have any form of actual 'how utilised is the disk' number in the numbers collected by bootchart
<erichammond> jjohansen, pgraner: Is there an EC2 kernel status meeting now?
<pgraner> jjohansen: ^^^^^^^^????
<apw> its at this time in my calender
<apw> (modulo google being pants)
<jjohansen> ah yes
<jjohansen> just a sec
<pgraner> apw: pants, pants, pants... that gcal is
<apw> so very true
<rtg> erichammond, lool has approved the linux-ec2 package for main inclusion, so perhaps I can get it built today.
<smoser> here
<jjohansen> alright lets begin
<jjohansen> This is the EC2 kernel status update meeting
<jjohansen> as far as I am aware the only change since thursday/friday is the state of bug #427288
<ubot3> Malone bug 427288 in eglibc "Karmic i386 EC2 kernel emulating unsupported memory accesses" [High,Fix released] https://launchpad.net/bugs/427288
<jjohansen> which was fixed in glibc
<erichammond> smoser: Can a new AMI be created to test this fix?
<jjohansen> it looks like there is some packaging work to be done as well
<rtg> smoser, have you been able to test this?
<smoser> i have not tested this yet, but will do that today.
<smoser> erichammond, i think publishing a new ami for it doesn't make sense given alpha 6 on thursday
<jjohansen> smoser: so are we then planning on rolling out a new ami with the karmic kernel
<jjohansen> minus this glibc fix
<smoser> i'm planing on alpha6 using the karmic kernel
<smoser> jjohansen, also, i opened bug 428692
<ubot3> Malone bug 428692 in ubuntu "ec2 kernel needs CONFIG_BLK_DEV_LOOP=y and other config changes" [Medium,Confirmed] https://launchpad.net/bugs/428692
<jjohansen> smoser: thanks
<rtg> smoser, why _wouldn't_ you use the new glibc? Isn't that what the alphas are for?
<smoser> i did not intend to say i wouldnt
<smoser> i hope to get 427288 "all the way fixed" for alpha6
<jjohansen> ah, I missed interpreted, no point in rolling out a new ami before alpha6, right?
<erichammond> smoser: My opinion is that if we can test a fix, we should do it sooner rather than later.  Are we saying that the fix won't be in glibc until alpha6?
<smoser> I'll test it. it can easily be tested just by apt-get update && apt-get install libc6-xen and reboot
<erichammond> smoser: nice, thanks.
<smoser> then, i'll make sure that we get libc6-xen into the ami, and that that ami will not get the error. but i dont plan on publishing another ami with all that incorporated prior to alpha6
<erichammond> smoser: When you publish an AMI are you building it from scratch with vmbuilder or are you simply uploading and registering the daily image which is automatically created?
<smoser> i much prefer to use the nightly
<smoser> if that werent' sufficient, then i'd re-spin the nightly in the same way, just at a later date
<erichammond> smoser: Ok.  How often is the code updated which is used to build the nightly?  I thought I saw that you pinged soren to manually update it recently.
<lool> rtg: It was still in NEW when I looked though
<smoser> erichammond, you're correct
<smoser> we do need a long term solution for that.
<lool> rtg: (Thanks for clarifying the doc question BTW)
<rtg> lool, right. how long will it sit there before getting accepted?
<lool> rtg: I'm not archive admin; it's up to them
<rtg> lool, so, just find the Monday guy and hassle him?
<lool> Digging the Ubuntu wiki page
<lool> https://wiki.ubuntu.com/ArchiveAdministration
<lool> #
<lool> Monday: SteveLangasek; JamesWestby 
<lool> rtg: You could I guess
<lool> rtg: slangasek seems like a good target; he knows about the source package and how it's constructed
<lool> rtg: I expect that if the copyright was properly updated for the Xen patches it should be ok
<rtg> lool, uh, I didn't see that mentioned anywhere. 
<lool> rtg: Well it's not MIR related, it's NEW related
<lool> rtg: Source packages have to document their copyright properly before they enter the archive, right?
<lool> My role was just in approving the move of this package from universe to main
<rtg> lool, AFAIK there are no copyright issues.
<lool> Since it's built like the other kernel packages which are in main already and since the kernel team will care for it, I dont have a big issue with another one
<rtg> everything is gplv2
<lool> k
<Keybuk> apw: yes, I've already sent ted a note
<erichammond> (I'm lost, is this still part of the EC2 status?)
<Keybuk> apw: I think it comes from /proc/diskstats
<lool> rtg: debian/copyright usually mentions where stuff was taken from, which license it's under and who owns copyright; that said this last bit probably isn't maintainable in the copyright file so I guess you would refer to the list of AUTHORS or something similar or just omit it
<rtg> erichammond, sorry, lool and I were discussing linux-ec2 acceptance.
<lool> (Is this a meeting?)
<rtg> lool, 'tis
<Keybuk> apw: bootchart logs /proc/stat, /proc/diskstats and /proc/*/stat
<Keybuk> all chart information is derived from that
<rtg> jjohansen, are we done?
<jjohansen> I believe so
<jjohansen> anyone else?
<erichammond> smoser's second bug has not been addressed.
<lool> Ok /me disappears then, sorry for interrupting
<erichammond> bug 428692
<ubot3> Malone bug 428692 in ubuntu "ec2 kernel needs CONFIG_BLK_DEV_LOOP=y and other config changes" [Medium,Confirmed] https://launchpad.net/bugs/428692
<Keybuk> isn't DEV_LOOP=y already?
<rtg> Keybuk, it is for the master branch
<jjohansen> Keybuk: not in EC2 build currently
<smoser> the bug is really "make the ec2 kernel more like -server" 
<rtg> smoser, I see that. I'll see what I can do
<smoser> but explicitly, users have already asked for CONFIG_BLK_DEV_LOOP=y
<jjohansen> smoser: you also wanted KEXEC :)
<apw> Keybuk, from waht i can see the utilisation is a number of ticks that there was an io on the queue... so that means 1 io has the basic same effect on the table as 10
<Keybuk> apw: it doesn't seem to be translated into binary though, it appears as an analogue graph
<smoser> jjohansen, yes, but you dont want to support it. so i wasn't going to explicitly ask :)
<Keybuk> and, most importantly
<Keybuk> I have machines which *don't* have that I/O graph
<Keybuk> and they boot much faster, with identical installs
<jjohansen> smoser: right
<apw> Keybuk, right if the io is very empty then it would be empty, or if the queue is empty any time in the sampling tick the answer will be less than 1.0, but if its got 1 io for all the time then its 1.0 same as if its 100 io for all the time
<apw> ie, its pretty much saying if read ahead worked even badly the block should be 'full' utilisation wise
<jjohansen> all right if there is nothing else, we will call the EC2 kernel meeting adjourned
<apw> seems a bit pointless
<erichammond> This may also be the place and time to discuss bug 429169 as some of the alternatives affect the kernel.
<ubot3> Malone bug 429169 in vm-builder "ec2: Include kernel modules in AMIs" [Undecided,New] https://launchpad.net/bugs/429169
<Keybuk> apw: but the output doesn't support that
<Keybuk> we have graphs which are quite fluid
<Keybuk> suggesting it doesn't behave that way
<apw> suggesting the data doesn't always mean the same perhaps
<Keybuk> http://people.canonical.com/~scott/boot-performance/sam-karmic-20090721-8.png
<Keybuk> for example
<apw> but thats what they are according to the docs
<Keybuk> I tend to disbelieve any documentation of things in /proc
<Keybuk> they're hopelessly out of date
<Keybuk> especially on that graph above
<Keybuk> note how the I/O wait goes *flat*
<apw> well no that graph looks pretty the same, mostly high when read ahead is high
<Keybuk> you don't see that on machines "affected" by this I/O issue
<Keybuk> right
<Keybuk> but the whole point is that on my Dell, the graph goes high when readahead isn't even running
<Keybuk> and remains high after it finished
<apw> yeah i think the graph we have on my machine literlally only says IO isn't going very fast
<ogra> amitk, any chance we see a new imx51 kernel before the freeze ?
<Keybuk> and
<Keybuk> key
<apw> and so the IO wait is high all the time
<Keybuk> *the throughput on the disk is virtually zero*
<Keybuk> that to me suggests that the I/O queue is getting stuck
<Keybuk> that things are waiting for I/O
<Keybuk> and the kernel isn't actually bothering to service them
<Keybuk> since I've seen bugs exactly like this, where the kernel stops doing I/O, I'm inclined to believe that there is a bug here and it's not a charting issue
<erichammond> jjohansen, smoser: Did I not speak in time to keep the meeting going?
<jjohansen> erichammond, smoser: I think it would be appropriate to take that discussion over to #ubuntu-server
<smoser> ok
<Keybuk> (just looking up the bug number)
<Keybuk> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/336652
<ubot3> Malone bug 336652 in linux "Poor system performance under I/O load" [Medium,Triaged] 
 * apw notes that the green line is very low agian even in your one ... odd
<erichammond> jjohansen: Two of the options relate to building things into the kernel and/or ramdisk, but it is quieter over on #ubuntu-server
<jjohansen> erichammond: that is why I suggested it
<Keybuk> apw: on the sam one, the green line is at least trying to lift when there is I/O wait
<Keybuk> what worries me about yours (and my other laptop) is that the green line stays flat even when there is I/O wait
<apw> the green line in mine is the same pattern
<apw> its that there is no gaps in the wait that its not so obvious
<apw> not that that means there isn't an issue, it taking 100years to boot demonstrates that on its own
<Keybuk> no, yours shows a different pattern
<Keybuk> you have red I/O wait almost all the time
<Keybuk> with a flat green line
<apw> what i don't really understand is why sreadahead isn't able to get its shit onto the queues
<Keybuk> that implies waiting for I/O without any disk throughput
<apw> nope it has two distinct lists
<Keybuk> which leans me to I/O queue stall
<apw> lifts one where you first block is, and the second where you 51mb/s is
<Keybuk> yes
<Keybuk> but it's otherwise flat
<Keybuk> even though you have I/O wait
<Keybuk> on http://people.canonical.com/~scott/boot-performance/sam-karmic-20090721-8.png
<Keybuk> there is
<Keybuk>  a) *far* less I/O wait
<apw> yep, that is cause sreadahead is take soooo long to do its thing
<Keybuk> in fact, much of the top of the graph is blue, not red
<apw> its pushing in a dribble of io which accounts for the queue
<Keybuk> and every point there is I/O wait, there is continual lift
<Keybuk> apw: please disregard sreadahead
<apw> the question is why is read ahead not occuring in 2-4 s in mine than yours
<Keybuk> if you like, comment out the "start on" from /etc/init/sreadahead.conf
<Keybuk> and you'll see the same pattern
<Keybuk> right
<apw> Keybuk, i can't as its likely the cuase of constant wait
<Keybuk> sreadahead being unable to push I/O is a symptom of the bug
<apw> likely yes
<Keybuk> not the bug
<apw> indeed ...
<Keybuk> and if you remove sreadahead, you still see the exact same pattern
<Keybuk> which fits
<Keybuk> because
<Keybuk> as I do keep pointing out
<Keybuk> your problems start several seconds before sreadahead is even started ;)
<Keybuk> sreadhead starts at 5s
<apw> well you have to be careful with that statement, as all yo ucan tell is that there is 1 page on the queue during that perios
<Keybuk> but you've already been in large I/O wait for a couple of seconds with no throughput by then
<Keybuk> there shouldn't be any pages on the queue
<apw> we have no idea if thats 1 block or 10000 blocks for a short time
<Keybuk> or there should be disk throughput
<apw> on -2 there is a lift in throughput with the fvery first spike of red
<apw> its small but there
<Keybuk> so why is there I/O wait after the lieft
<apw> there isn't the lift drops as does the wait
<Keybuk> ok
<apw> there is a similar width gap then it starts again, lift + wait
<Keybuk> try something for me
<Keybuk> boot without sreadahead
<apw> yep will do that, seems most logical to confirm your theory
<apw> how did i do that?
<Keybuk> edit /etc/init/sreadhead.conf
<Keybuk> comment out the "start on" line
<apw> (and i do believe it in principle
<apw> just its not proven to me yet) and if its right the debug will be nasty
<Keybuk> I can't find the bug I was looking for though yet
<Keybuk> I had an actual test case where I could stall "dd" on this machine
<apw> launchpad hates us all
<Keybuk> in a way that the kernel had decided that dd was doing no more I/O and could block on read() forever
<apw> that sounds like the sort of thing you see with barriers in the queue
<Keybuk> annoyingly, I have a feeling it was when I was trying to back up my old laptop hard drive
<Keybuk> so I don't even have the logs, because the hard drive has obviously been replaced ;)
<Keybuk> but basically, yes, on this machine I find that any attempt to do large amounts of I/O get extremely slow
<Keybuk> readahead included
<Keybuk> pitti has a similar laptop, and confirmed my results
<Keybuk> but the XPS 1330 for example *does not* have the same problem
<pgraner> Keybuk: anything similar to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/392288
<ubot3> Malone bug 392288 in linux "dd extremely slow writing to usb key without oflag=dsync" [Medium,Triaged] 
<Keybuk> pgraner: I don't think so, on the basis that I was having these problems on jaunty
<Keybuk> (it was during Berlin that I had the dd-stall issue)
<pgraner> Keybuk: ack
<Keybuk> (I've had the abysmal I/O performance on this laptop for several releases now, it's not a "new" bug
<Keybuk>  if I were to guess, I'd say it was edgy or feisty that it started)
<apw> Keybuk, ok ... the readahead less case is faster booting
<apw> there is wait along the way as predicted, though depending how the driver calcs that stat we might expect that
<apw> its a poor metric at best
<apw> of course readahead getting behind would account for the worse with readahead mode too
<apw> so all pointing to poor io performance full stpo
<apw> stop
<Keybuk> yeah
<Keybuk> don't suppose you could time how long sreadahead takes?
<Keybuk> time sreadahead --debug --no-fork
<apw> on my machine it was 90s
<apw> if i run it once booted it takes like 0
<Keybuk> ok
<Keybuk> boot with init=/bin/bash
<Keybuk> then run it (with those args)
 * apw tries your incantation
 * apw notes it running for some time, no IO obvious
<apw> 15s
<Keybuk> weird
<Keybuk> so that took 15s to do nothing?
<apw> and also notes it complains about not being oable to open things
<apw> sda/queue/read_ahead_kb for one
<apw> which sounds bad to me
<apw> Keybuk, that does seem about how it felt yes
<apw> Keybuk, does your machine (thats slow) have its root in an extended partition?
<Keybuk> no
<Keybuk> /dev/sda1
<apw> Keybuk, i can't get it to do any actual readahead calls in debug mode
<Keybuk> you need both arguments
<apw> Keybuk, have both as in --debug --no-fork
<Keybuk> yes
<apw> Keybuk, i am worried by mdz's bug #429001 ... that warn on there is triggered by what appears to be ftrace on opens, and if i am reading sreadahead right it turns that on... could it be its failing to turn it off again ... as he had it on still when he suspend/resumed much later
<ubot3> Malone bug 429001 in linux "WARNING: at /build/buildd/linux-2.6.31/kernel/trace/ring_buffer.c:1393 rb_add_time_stamp+0x79/0x200()" [Low,Incomplete] https://launchpad.net/bugs/429001
<Keybuk> I don't think it should fail to turn it off
<Keybuk> unless he killed it;)
<apw> he is running your boot ppa's so anything possible :)
<Keybuk> mdz's laptop is a strange beast
<Keybuk> also sreadahead only turns on ftrace when profiling
<Keybuk> not in "normal operation"
<apw> bah it just fooked its own db
<apw> Keybuk, ok i am finding that running the read ahead on my laptop after dropping caches takes 30s, if i make it single thread not 4 threads it takes 15s
<Keybuk> right, you have a HDD
<Keybuk> but I don't see what about HDDs makes that need to happen, when on SDD you have the exact opposite behaviour
<apw> the threads can out of order the requests badly and make the disk thrash i guess
<apw> i guess we can actually tell now, there is a rotational flag in the device so we could use that to check
<apw> Keybuk, /sys/block/sda/queue/rotational seems to tell us
<apw> as sreadahead is in there already it could check and change behavior
<Keybuk> that's handy
<apw> one assumes its cause seek latency is essentially 0 on ssd
<Keybuk> I actually already have the sreadahead patches to use a single thread ;)
<Keybuk> but I also found in testing that you then need sreadhead to *block* the boot
<Keybuk> ie. single thread and other stuff in background = bad
<Keybuk> (which fits with readahead-list)
<Keybuk> but then I noticed slow down unless the readahead pack was not sorted ideally for HDD
<apw> hmmm, thats not hot either is it
<Keybuk> and I hadn't done the "ideal sort" bit yet
<apw> this is all a bit of a nightmare
<apw> just trying a single thread one on my machine
<apw> but still in parallell
<Keybuk> I wrote a very long mail about this
<apw> i know ... i remember reading it
<apw> i wonder if letting it run single in parallel but skipping the first few files deliberatly would work
<apw> as that would hold the boot in the sense those required io's would get the boot behind readahead
<Keybuk> I don't follow
<Keybuk> still don't follow
<apw> the risk is if the boot ever gets ahead of where the read ahead is we can make things much worse
<apw> as its reading stuff we no longer need and already ready
<Keybuk> still don't follow
<Keybuk> we never do that
<Keybuk> sreadahead is the first thing started
<Keybuk> the problem on HDD isn't that the boot gets ahead
<Keybuk> it's that we're inherently seeking the disk all over the place
<Keybuk> back after dinner
<Keybuk> will try to use that rotational flag and merge my other sreadahead updates to do the foreground stuff
<Keybuk> see if it makes a difference
<apw> yeah ... tricky
<apw> ok from 15 -> 10s if i stop it using low IO priority
<amitk> ogra: yes, I am hoping for a imx51 upload tomorrow.
<ogra> amitk, oh, ok 
<amitk> had already discussed it with rtg
<ogra> yeah i saw that last week but couldnt remember the outcome
<amitk> ogra: http://people.canonical.com/~amitk/mx51/linux-image-2.6.31-100-imx51_2.6.31-101.8_armel.deb is a preview if you want to play
<Keybuk> apw: interesting on the scheduler
<Keybuk> is that changeable per-device or ?
<apw> Keybuk, yep per device on the fly, look for queue/scheduler in the device
<Keybuk> if we stayed in the foreground, and blasted the readahead list for an HDD before letting the boot continue
<Keybuk> whilst setting the io priority to realtime, and the scheduler to deadline
<Keybuk> that might work better?
#ubuntu-kernel 2009-09-15
<amitk> csurbhi: how goes your quest to get everything configured?
<csurbhi> still cannot access the wiki
<smb> hm, lets check on your page...
 * smb thinks we must fix your memberships
<csurbhi> ok
 * apw is getting bored of the i915 hangs already
 * smb slaps himself in advance for thinking evil replies
 * apw thinks you should run karmic for a bit just to feel my pain
<smb> Well I run it on machines with ati and nvidia graphics. Which were supposed to be the more painfull...
<apw> heh ... how is your ati.  with compiz mine is unusable
<smb> I am not sure I enabled it fully but I can't remember any particular pain. I will have a go at the latest packages of the day later
<kervel> hi, i want to make a custom version of linux-backports-modules-karmic in a PPA. i'm now using "dch -i 'rebuilt without rfkill'"  as part of my script .. but that doesn't result in the right version number
<kervel> is there any recommendation on what to use for a PPA
<smb> kervel, If you mean that adding ubuntu1 is not the right thing, probably the simplest thing is to sed it to what extension you want. But you would not want to increment the upload number
<kervel> smb i don't really know how version numbers work in ubuntu.. but i guess i need something like blabla-ubuntu1-custom1 or so
<kervel> now it changes ubuntu1 to ubuntu2 and so on
<kervel> which is - i guess - not fine as it will conflict with a real version
<kervel> maybe
<smb> In the case of this package, no official version will have ubuntux in it, as it is not based on a debian package
<smb> But to make it clear where it comes from, you could replace the ubuntu by your nick, initials or whatever
<kervel> ok let me try ...
<rtg> apw, did you make any headway on the disk performance issue you were seeing yesterday?
<apw> rtg not as to root cause no, i am not 100% convinced there is a speciific issue in my case
<rtg> apw, there is something going on with one of mine late in the process. the throbber just sits there for 15 seconds with no disk activity
<apw> its entirly possible its showing that a rotating media does not like to be rattled
<apw> rtg, that sounds different, mine is rattling its ass off for the whole time
<apw> though i think the same technique could help us
<apw> if you install bootchart, then boot with bootchart=nostop
<apw> then boot, login, and run sudo /etc/init.d/stop-bootchart start
<apw> it will give you a nice piccy to look at, which should show you what it hotught it was doing in that period
<rtg> apw, ok, I'll bring it downstairs in a bit and give it a try
<apw> i found i was taking a 7s hit every boot for schroot, changed recover to end in its config and i got 7s back
<apw> spent most of my time looking at this i915 hang, have the upstream activly engaged as i seem to be able to reproduce almost at will right now
<rtg> apw, thats either good, or a real pain the ass :)
<apw> mostly the latter for me unfortunatly ... fortuanatly it seems to be pretty stable before the first suspend, and gets much more likley after
<gnarl> rtg, good for us but pita for apw 
<apw> so as long as i never sleep things are fine
<rtg> apw, you'r eye'll get kind of red if you never sleep
 * apw watches a bunch of startup stuff get uploaded ... bumpy waters ahead
<apw> rtg heheh
<amitk> bug 427289
<ubot3> Malone bug 427289 in linux-fsl-imx51 "hardware clock not saved if board power is removed on babbage 2.5" [High,New] https://launchpad.net/bugs/427289
<kervel> hi, no luck setting up my PPA (http://launchpadlibrarian.net/31842410/buildlog_ubuntu-karmic-i386.linux-backports-modules-2.6.31_2.6.31-10.12kervel2_CHROOTWAIT.txt.gz)
<kervel> when i build the packages using pbuilder i didn't get this problem
<smb> kervel, Looks a bit more like a ppa setup problem in general. If I read this right the pulled sysv-rc needs an initscripts package greater or equal 2.86.ds1-63 but only finds an older version...
<kervel> hmm
<kervel> so that means i need to wait and retry
<smb> kervel, Hm, not sure where this old version comes from. rmadision for initscripts shows 2.87dsf-4ubuntu2 for karmic...
<kervel> thing is, it seems these packages were just uploaded
<smb> kervel, Might it be that you accidentally have jaunty in the first line of the debian/changelog
<kervel> ow let me check
<kervel> but then pbuilder would also fail
<kervel> it says karmic, so that won't be it
<smb> Ok. Actually it seems to pull from karmic. Just the version number seemed close to the one in jaunty
<kervel> on my local system the initscripts upgrade is held
<kervel> so i guess its a general problem with karmic
<rtg> Keybuk, help! https://launchpad.net/ubuntu/+source/linux/2.6.31-10.33/+build/1244811/+files/buildlog_ubuntu-karmic-i386.linux_2.6.31-10.33_CHROOTWAIT.txt.gz
<rtg> something new.
<kervel> rtg looks like my problem
<Keybuk> yes
<Keybuk> it'll cure itself after the next publisher run
<rtg> yeah, 'cause there ain't no sysv-rc dependency
<rtg> Keybuk, so, since its in a CHROOTWAIT state, will it automagically restart?
<Keybuk> no, it'll need an admin to give back
<Keybuk> colin just said he'd do that
<smb> rtg, Somewhat interesting, as rmadison already shows the new version and I also had pulled it to a test system
<rtg> smb, what did you pull? it hasn't built yet
<smb> rtg, dpkg -l on karmic64 shows it installed...
<rtg> smb, -10.33 ?
<smb> no the initscripts
<rtg> smb, have you ever noticed that were are often on totally different tracks?
<rtg> s/were/we/
<smb> The following packages have unmet dependencies:
<smb>   sysv-rc: Breaks: initscripts (< 2.86.ds1-63) but 2.86.ds1-61ubuntu16 is to be installed
<smb> I guess that was your problem as well
<smb> as that of kervel 
<rtg> yep
<smb>  +++-==============-==============-============================================
<smb> ii  initscripts    2.87dsf-4ubunt scripts for initializing and shutting down t
<smb> Just found it interesting that it seems to be installable but not available for the ppa's or buildd's
<kervel> initscripts is not installable on my karmic box
<kervel> or it comes with a warning ... (you are about to do something potentially harmful)
<smb> kervel, mine is a 64bit system and likely I ignored the warnings... Its a test system anyway
<smb> rtg, But yes, I guess my jump in thoughts was a bit steep
<NakidGirl_With_I> hi . how can I look at the filename in http://packages.debian.org/unstable/kernel/ , detemine that its a dom0 kernel
<NakidGirl_With_I> I want to install dom0 kernel on Jaunty 9.04
<NakidGirl_With_I> anybody ?
<NakidGirl_With_I> I want to install dom0 kernel on Jaunty 9.04 , can any body help
<arvind_khadri> NakidGirl_With_I, did you google?
<NakidGirl_With_I> hello <arvind_khadri> , since I am from elX distro person , I am finding it difficult to compile one for Jaunty
<NakidGirl_With_I> I googled
<NakidGirl_With_I> I was looking for some latest prebuild images which I could use, and Thanks
<NakidGirl_With_I> I can do that on centos , but jaunty is failing
<rtg> IIRC Hardy is the last dom0 kernel. zul?
<zul> yep
<NakidGirl_With_I> rtg> can you please give the link for that download
<NakidGirl_With_I> ??
<rtg> http://www.ubuntu.com/getubuntu/download
<NakidGirl_With_I> <rtg>  thats for ubuntu ,. I am asking for dom0 image
<NakidGirl_With_I> <rtg> if you are unable to assist , dont fake it
<rtg> NakidGirl_With_I, you are suddenly the source of some amusement. zul - is the Hardy xen flavour packaged? Or is he gonna have to build it?
<zul> its package just get it from the archive
<rtg> its not on the dvd?
<zul> ummm...not sure I dont have a dvd to check ;)
<NakidGirl_With_I> <rtg> amusemnest ? Jeez thats something. Hope you had your fill , but then is there some lead or not
<rtg> nor do I, takes to dang long to download.
<NakidGirl_With_I> Thanks guyzz.. thats why I told that morron that even centos is better ..ciao 
<apw> yeah right ... go for it NG
<rtg> gosh, I was just about to paste a link :)
<apw> rtg, major positive progress on the i915 hanging bugs ... it looks to be a mesa bug ... and we have what appears to be the fix.  proved it was the issue using a kernel  patch which added more validation.
<rtg> apw, cool. worth an upload?
<apw> the fix itself is mesa, so i don't think we need to panic on the kerenl
<apw> i'm just trying to persuade ickle to push the kernel patch to stable
<apw> as that does protect us and makes any bug obvious as your screen is poop
<apw> i suspect is worth us applying it to our tree so its in the next upload whenever that occurs tho.
<apw> right now without mesa fixed it will trash everyones screen :)
<rtg> apw, wfm
<apw> has the kernel with the ext4 fix already gone up?
<rtg> apw, yep
<apw> good stuff
<ogasawara> ** Just a reminder . . . Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<apw> ogasawara, ack, now + 50 mins
<erichammond> pgraner: Is the daily EC2 kernel meeting going to happen now? http://kernelcalendar.notlong.com/
<rtg> jjohansen1, ^^
<jjohansen1> rtg: thanks
<jjohansen1> EC2 kernel meeting
<jjohansen1> will begin in just a minute I am going to see if I can't get smoser
<erichammond> jjohansen1: There's a server team meeting still happening in #ubuntu-meeting
<jjohansen1> erichammond: ah
<jjohansen1> rtg: did you do any config updates for the EC2 kernel?
<rtg> jjohansen1, I have not uploaded the source package, but he configs should be closer to server
<smoser> i thought we said to do these in -server. oh well
<rtg> smthe meeting?
<rtg> smoser, ^^
<smoser> y
<rtg> we can certainly move there. all opposed?
<smoser> i dont care
<smoser> just i wasn't here, thinking it was there. anyway. this is fine.
<smoser> i'll go first if you dont mind
<rtg> lets do it in -server since there are folks interested in that channel
<smoser> i'm planning on later today publishing the karmic kernels to eu-west-1, and getting ec2-version-query updated 
<smoser> ok. moving there.
<rtg> apw, patch from Ted in https://bugs.edge.launchpad.net/ubuntu/+source/e2fsprogs/+bug/427822
<ubot3> Malone bug 427822 in linux "fsck says last write time in future" [Critical,Fix released] 
<apw> rtg his timing stinks!  38 mins ago
<rtg> apw, its not too late
<apw> is it worth spinning yet another kernel for?
<rtg> apw, probably not as long as thefix is in the pipeline.
<apw> and its untested, though it looks identcle to the other, it'd be a worry
<apw> we kittened ourselves last time rushing something
<rtg> indeed
<apw> i'll get it tested and committed tho.  my machine has ext3 it seems
<apw> bah its gone manic out here all of a sudden!
<bjf> -afk
<Keybuk> rtg: did you see that Ted posted an ext3 patch for you?
<Keybuk> it would be REALLY NICE to have that in Î±6 as well
<rtg> Keybuk, i bugged apw about it. we can upload if you think it necessary.
<apw> Keybuk, i applied the patch to a test kernel, its pushing to rookery as we speak
<apw> http://people.canonical.com/~apw/lp427822-karmic/ ... they will be there in 10 mins or so
<rtg> apw, what was the chart profiling magic on the kernel command line? My laptop gets slower with each update
<apw> bootchart=nostop
<apw> then sudo /etc/init.d/stop-bootchart start
<apw> rtg just rember to boot twice, the first one after an update is always an sreadahead watch mode
<rtg> apw, boot twice after an update, right?
<apw> yeah the first one is always slow cause of sreadahead watching and learning
<apw> so profile the second one
<rtg> apw, should that be /etc/init.d/stop-readahead start ?
<rtg> apw, never mind. needed to install bootchart.
<kervel> is there any idea yet when the building problems (related to initscripts , sysv-rc) will be fixed ? i'm still unable to do anything useful
<Keybuk> kervel: later
<pgraner> Keybuk: my netbook is hanging on mounting after updates, any idea?
<pgraner> Keybuk: Right after "Running /scripts/init-bottom"
<smb> pgraner, Welcome in the club
<smb> pgraner, See topic over in #distro
<pgraner> smb: in that case I'll shutup
#ubuntu-kernel 2009-09-16
<LLStarks> hi
<LLStarks> i'm having a problem with b44 loading in 2.6.31-10
<LLStarks> can someone help me?
<Q-FUNK> howdy!  would anyone know what broke KMS yesterday and how to fix it?
<smb> Q-FUNK, There had been disturbances in the (buildd) force which broke things in general. I am currently checking whether it is better now
<Q-FUNK> smb: buildd and upstart, yes.
<Q-FUNK> this transition to event-based eveything is extremely ill-timed, to say the least.  it really should have been pushed to karmic+1.
<smb> I agree, the timing was not ideal. It seems if you can do an upgrade using a chroot now, it seems to be at least in a usable state
<smb> I saw some errors flying by but at least a gui comes up with a usable mouse
<smb> and bash
<Unggnu> hi all
<Unggnu> I just wanted to ask if someone can take a look at this bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/421662
<ubot3> Malone bug 421662 in linux "Dell Inspiron 1525 WLAN (Intel 3945) doesn't work with Ubuntu Kernel in Karmic [regression]" [Undecided,New] 
<Unggnu> Karmic release isn't far away so I am worried :)
<Unggnu> It seems that the Ubuntu kernel thinks that WLAN is disabled while it is not. At least the mainline kernel and the old ones don't have this problem
<JanC> hm, I have a laptop with a 3945ABG wlan, but it's not a Dell
<Unggnu> JanC, yes, someone else confirmed that it worked with his 3945
<Unggnu> I also need the backport modules in Hardy so I guess it is a special card :)
<JanC> Unggnu: maybe different radio chip ?
<Unggnu> It was the standard model. You couldn't change it when you were ordering the Ubuntu Dell Notebook.
<Unggnu> I would have prefered the 4945 or how it is called but it was not possible from Dell
<JanC> hm, main pci-id is the same, but yours is subsystem 8086:1021, mine is subsystem 8086:1001
<Unggnu> I guess we need another one with a Dell Inspiron 1525 and the same radio chip :)
<apw> cjwatson, is ia64 ok for builds?  that one failed to build for chroot issues for .34, are we expecting admins to resubmit those or at this stage is it do your own?
<cjwatson> ia64 is hosed
<cjwatson> package maintainers don't need to worry about it
<apw> ok thanks
<cjwatson> basically, ignore ia64 for the time being, until somebody gets dbus ported
<cjwatson> http://launchpadlibrarian.net/29635553/buildlog_ubuntu-karmic-ia64.dbus_1.2.16-0ubuntu2_FAILEDTOBUILD.txt.gz
<cjwatson> also, in general, you can ignore "chroot problem" as a failure - buildd admins will take care of that
<apw> cjwatson, thanks for the info
<rtg> apw, have you noticed if ccache is still working for you?
<apw> can't say i have noticed ...
<rtg> on karmic, tha is
 * apw looks at his stats
<apw> smb, do you have karmic available for testing on your aspire one?
<apw> wondering if the rfkill works ok on there
<smb> apw, Yep, got a card with it. Should I upgrade it or not for the test?
<apw> wouldn't need upgrading i don't think if its pretty recent
<smb> lets see
 * smb is booting
<smb> Looks a bit old -9 kernel only
<smb> apw, At least with that kernel I got wireless
<apw> does rfkill work do you know
<smb> The physical switch or the command?
<smb> If I pull the wireless switch I loose connection but it is something hardware internal as it is not reflected in hard blocked state
<apw> so the wireless disable switch works ok on yours ... with the default kernel
<apw> and it comes back ok when you toggle it again?
 * smb just says goodbye to his card games adn updates
<smb> apw, Right
<apw> strange, we have a patch to fix your machine which is not in karmic, and seems to apply
<smb> It acts a bit weird as the software is not notified (nm tries to reconnect like mad)
<apw> yet you are ok without it, i guess i'll drop it then
<smb> if you mean the patch to not do soft rfill in acer-wmi
<apw> yeah that one
<smb> upstream acer-wmi completely blacklists the aa1
<apw> ahh ok, then its got fixed that way, nice
<smb> seems the whole wmi interface there is buggered
<apw> so i can sensibly drop it
<smb> ack
<apw> good enough
<rtg> *sigh* it doesn't pay to update some days. my raid0 server has stopped booting after running /scripts/init-bottom
<ogra> rtg, it really helps to read the topic in #ubuntu-devel where such breakage gets pre-announced 
<ogra> (or at least announced on discovery)
<rtg> ogra, too many channels...
<ogra> pfft
<ogra> but i agree we should kill things like -kernel, -arm, -mobile -desktop and go back to just use #ubuntu-devel again
<ogra> all that annoying fragmentation only came up over the last years
<rtg> ogra, maybe I'll just install Hardy 'cause its my build box.
<gaspa> ogra: +1
<ogra> gaspa, sadly its way harder to close channels than to open them :)
<gaspa> I know.
<gaspa> but for me it's quite a problem, I'm interested in lots of different areas... and I just can't have so much opened tabs ...
<ogra> i only have 26 open atm
<gaspa> O_o you won.
<ogra> on bad days its 40 :)
<gaspa> usually over the 15th I start to kill them.
<gaspa> :P
<apw> pgraner, do you now have a PC Beep channel in your alsa mixers?  wondering if you are affected by bug #331589 on karmic or not
<ubot3> Malone bug 331589 in linux "Extremely loud and intrusive system beep with (some?) HD Audio devices" [Medium,Fix committed] https://launchpad.net/bugs/331589
<pgraner> apw: on which box (or all of them?)
<apw> i am unsure which one you were seeing it on, i think you are listed as affected, but likely your 1330
<pgraner> apw: that one no longer has karmic on it :-(
<apw> manjo has one, i'll ask him
<pgraner> apw: I'll have to boot a usb stick and test. I have yesterday's daily on usb, I'll try as soon as I can get access to it
<pgraner> apw: manjo is onsite today
<apw> he likely has the kit with him then, and running karmic :)
<pgraner> apw: right now I can get to the 1330 due to -EWIFE
<apw> i suspect touching that machine before the weekend is a bad plan for you full stop
<apw> it can wait for manjo and i've sent email to TheMuso as the bug i am wondering about was from him
 * rtg has his server running in recovery mode. 
<apw> rtg, deliberate action or a disaster recovery?
<rtg> apw, total borkage after this last update
<apw> rtg ahh i was lucky to miss that, left just in time
<apw> rtg in jaunty we enabled GADGET_DUMMY_HCD and that had some fallout for the ABI and you worked round it with:
<apw> index e69de29..b711024 100644
<apw> --- a/debian/abi/perm-blacklist
<apw> +++ b/debian/abi/perm-blacklist
<apw> @@ -0,0 +1,3 @@
<apw> +net2280_set_fifo_mode
<apw> +usb_gadget_register_driver
<apw> +usb_gadget_unregister_driver
<apw> would it be more reasonable to just bump the abi in karmic, or should i follow that?
<rtg> apw, just bump the ABI
<apw> will do
<Q-FUNK> re
<Q-FUNK> has anyone found the reason why KMS no longer works in Karmic?
<cdE|Woozy> Q-FUNK, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/430694 ?
<ubot3> Malone bug 430694 in linux "agpgart-intel not loaded before drm sometimes, causes KMS to fail" [Undecided,New] 
<Q-FUNK> cdE|Woozy: could be it. any known cure?
<cdE|Woozy> I "solved" it by rebooting until it loads in the correct order :)
<cdE|Woozy> I don't know how the order in which those modules are loaded is determined
<apw> normally load order is determined by udev
<apw> the new parallel probe for pci in the kernel might trigger some instability in order
<apw> rtg there seem to be 6 patches applied to jaunty that didn't get upstream or into karmic, since we forked off karmic.  do you want me to mail them to the list for review or you happy for me to apply them
<rtg> apw, lets run 'em through the list first
<apw> rtg ack
<apw> rtg ok ... the analysis in all its gory details is up, as is a separate thread with the patches i want in
<apw> smb, jaunty sru review is out on email
<smb> apw, ok, I have a look
<rtg> apw, reading...
<devinheitmueller> Hello all.  I filed bug #403642 almost two months ago and it's supposedly milestoned for Karmic Alpha 6.  Is there any chance this is going to happen?  It's just a PULL request - no actual code changes required.
<ubot3> Malone bug 403642 in linux-firmware "Include xc5000 firmware in Karmic (now properly licensed)" [Medium,In progress] https://launchpad.net/bugs/403642
<rtg> devinheitmueller, its on my todo list, but its likely too late for A6
<devinheitmueller> :-/
<devinheitmueller> I'm obviously pretty disappointed to hear that, especially since the linux-firmware module got three updates since the ticket was filed, and it's just a pull request (it's not like I'm demanding that somebody investigate and fix a bug).
<devinheitmueller> rtg: Is there anything I could have done differently that would have effected the outcome here?
<rtg> devinheitmueller, actually, I din't even notice the bug until a couple of days ago when I was working on something else. You could always send a git pull request to the u-k-t list, which would have gotten my attention.
<devinheitmueller> But weren't you were the one that set the milestone to A6?
<rtg> devinheitmueller, uh, maybe. I can't remember.
<devinheitmueller> (yes, you were)
<devinheitmueller> If I had any reason to believe that sending pull requests to the ml would have helped, I would have been doing that weekly.  Instead I sat by and waited patiently after being told it was "in progress".  I guess lesson learned for next time.
<devinheitmueller> rtg: Thank you very much!
<rtg> np
<Wicked> is there any legit reason why ipv6 was hard coded into the kernel...and not as a module....so the only way one can truely disable ipv6 is to compile there own kernel?
<Wicked> it seems like a big mistake to me....and to think its such a small fix...that with all the kernel updates it has not been fixed...
<Wicked> which makes me think there may be something else im not seeing.......as to make sense of why its not fixed.
#ubuntu-kernel 2009-09-17
<norkakn> Hello good people, is there a way that I can get atl1c on 9.04 with 2.6.30?
<apw> 2.6.30?
<norkakn> Yeah, I have an acer timeline 3810t, and 2.6.30 fixes a lot of problems with it.  I installed it from the deb on kernel.ubuntu.com
<apw> norkakn, is that supported in the karmic kernel?  might be worth trying the karmic kernel on there
<apw> my expectation is that the karmic kernel would work ok on jaunty, no guarentees of course
<norkakn> I think it is, how do I procure the karmic kernel?
<smb> My best experience was somehow apw's ppa
<smb> https://launchpad.net/~apw/+archive/daily
<smb> apw, reminds me, if you got time, you could upload the latest and greatest up to now. ;-)
<apw> smb, thats a good idea, its a bumper so it needs testing
<norkakn> awe, well, it does the same thing that 2.6.31 from the mainline repo does, which is give me a big blank, black screen of nothingness
<apw> norkakn, oh yeah you need to tell it not to use KMS
<apw> i915.modeset=0 on the boot command line
<norkakn> apw: thanks, trying now
<norkakn> YES!
<apw> norkakn, yay
<norkakn> I'd tried the 31s before, but I didn't know about the KMS magic, thank you very much
<apw> norkakn, np, its not at all obvious
<norkakn> apw, I love this little machine, but nothing about it ever seems obvious.  If my computers begin to be able to sleep, my life will be complete
<apw> suspedn not working then?
<apw> worth trying with karmic, works pretty damn well today for me
<norkakn> No, it is a known bug with the 3810T, no one seems sure if it is a BIOS bug or a Linux bug.
<norkakn> I'll try it out on my desktop though
<Notch-1> forgive me guys but i have this problem and i need to ask you: i have 2.6.28-15-generic on jaunty, now i need to recompile to change one small option, and i get 2.6.28.10-generic.. this way i can't use the backports and restricted modules so how can i recompile those packege too OR change the kernel version to exactly match the official one?
<Notch-1> there are a lot of tutorials, but i can't found a sigle one that solve this problem...
<apw> Notch-1, if you are getting 2.6.28-10-generic you are using the wrong version of the source for the kernel
<mjg59> apw: 2.6.28*.*10
<Notch-1> i did apt-get install linux-source-2.6.28 ...
<mjg59> apw: It's just a wrong EXTRAERSION
<Notch-1> mjg59: yes, but i can't change it, look at man make-kpkg
<Notch-1> i can only change revision and --append-to-version ...
<apw> mjg59, oh yeah a . ... hrm
<Notch-1> and the local version inside menuconfig, but i don't know this one
<apw> Notch-1, that implies you used the wrong tools to build it
<mjg59> apw: .10 will be the upstream stable point release EXTRAVERSION
<apw> if you use debuild it ought to get it right for you
<Notch-1> somebody told me that -15-generic it's ubuntu notation while .10 is standard notation...
<apw> mjg59, yeah just didn't see it, saw what i thought it said not what it actually says
<apw> Notch-1, yep thats true
 * apw idly wonder what option you need to change and why
<Notch-1> apw: what's debuild?
<apw> its the tool for turning a source tree into a real binary .deb for installation
<apw> and basically is how packages get made in ubuntu
<Notch-1> ah fine
<Notch-1> i can use it to change this extraversion?
<Notch-1> anyway it seems that the package linux.source and the kernel i'm running are very different, how can i compile a kernel like the original one? what options/files are missing?
<Notch-1> so i can install backports and restricted....
<apw> the problem is if you change an option and that changes the ABI then you can't install backports and restricted safely even if it lets you do it
<apw> hense my question as to the option you are changing
<Notch-1> ah nice :D
<Notch-1> it's the loop module
<apw> those other packages are built agianst that specific kernel
<apw> what you doing to it
<Notch-1> recently it became included in the kernel, but for some reason me and other people need it at least as module...
<apw> that would probabally just about be safe ABI wise
<Notch-1> the are a lot of posts on the net, everybody bothered recompiling the kernel to get the system back to work... but i don't think it's a complete solution, without the ability lo use backports and restricted modules....
<apw> i would get the source either from 'apt-get source linux' or from our git tree, checking out the tag for the version you need
<apw> and then i'd change the config, and personally upload it to a PPA for building
 * apw wonders if this is this aes loop thing that the maintainer won't simply change the name of to aesloop so that it can coexist with the normal loop module
<apw> nor will they work with upstream to get it into the kernel
<Notch-1> apw: i don't think it's just a name problem...
<apw> as i recall its a philosphy issue, making life hard for everyone else problem
<Notch-1> yes, but seems that noone need it upstrem so...
<Notch-1> anyway, what if i just do make and replace the executable by hand?
<Notch-1> no noone notice the new kernel... and i can install whatever i need... what do you think about that solution?
<apw> as in the module?
<apw> you should be able to build the module externally and just replace the loop one in the lib/modules
<Notch-1> nono
<apw> bah ignroe that
<Notch-1> i mean the kernel
<apw> i am losing my mind
<Notch-1> :D
<apw> you could do that, but it wouldn't be very pretty
<apw> i would build your own version of the whole thing, with that module replaced
<Notch-1> sure? :D
<Notch-1> but i will still have the backport issue...
<Notch-1> now i'm doing apt-get source linux-image-2.6.28-15-generic to see if this source are more similar to the original kernel... but i'm afraid :D
<apw> as we know the abi change (and there will be one) is benign mostly, you should be able to make a like 2.6.28-15.NNaesloop1 kernel in a PPA which can then be installed and the backports etc still work with it
<Notch-1> excuse me, what's a ppa? :P
<apw> ppa is a personal package archive, which is like having your own ubuntu archive on the net
<Notch-1> ah right, launchpad :D
<Notch-1> have this features, now i remember thanks
<apw> yeah launchpaddy thing
<apw> Keybuk, are we expecting usplash to be absent with karmic tip?
<Keybuk> yes
<rtg> apw, did 'quiet' disappear from the grub line?
<apw> rtg nope they are still there
<apw> Keybuk, i assume there is a plan for the mess i the gap?
<Keybuk> right
<Keybuk> in fact, not having usplash is partially so we can see the mess we need to clean up
<rtg> Keybuk, I've a server that won't mount a /dev/md0p1 partition at boot time. in fact, it borks the boot altogether if /home is mounted on this partition. what title should I use for the bug report that will catch your eye?
<Keybuk> you're not the first person to say that
<Keybuk> it breaks inside the initramfs, or breaks during normal boot?
<rtg> Keybuk, can't tell. its got a bunch of udev messages
<rtg> I think it must be during normal boot
<Keybuk> ok great
<Keybuk> you have it in front of you now?
<rtg> Keybuk, that noisy hoover? of course not. its inconveniently off in another room
<Keybuk> if you could boot it and try a few things, I'd appreciate it
<Keybuk> boot with init=/bin/bash
<Keybuk> and get the output of "blkid"
<Keybuk> (just on its own)
<rtg> Keybuk, can do. what would you like
<rtg> ?
<rtg> Keybuk, ok, back in a sec
<rtg> Keybuk, ok, blkid shows /dev/md0p1 with a UUID and file system type of ext4 (but its not mounted even though its in /etc/fstab)
<Keybuk> right
<Keybuk> but, does it also show the same UUID for the underlying filesystem?
<rtg> Keybuk, I'm not sure what you mean. it only shows 1 UUID
<Keybuk> blkid only outputs one thing?
<rtg> for that partition, yes
<Keybuk> I don't understand
<Keybuk> blkid should output lots of lines
<rtg> and it does
<Keybuk> ok, can you take a picture of them or something?
<rtg> Keybuk, yep, gimme a bit
<Keybuk> also mdadm -D /dev/md0 would be helpful
<rtg> Keybuk, http://kernel.ubuntu.com/~rtg/md0
<Keybuk> rtg: great, and what's in /etc/fstab and /proc/self/mountinfo ?
<rtg> on sec
<rtg> Keybuk, http://kernel.ubuntu.com/~rtg/md0/imgp0763.jpg
<Keybuk> thanks
<Keybuk> that's very useful
<Keybuk> so, I know what's happening but not how to fix it yet
<Keybuk> for some reason, it's showing the UUID and filesystem type, etc. for sdb1 as it is for md0p1
<rtg> is it because mdadm isn't getting run?
<Keybuk> and sdb1 is winning
<Keybuk> so it tries to mount that, but fails
<Keybuk> mdadm must be being run, your array is visible, up and enabled
<rtg> I guess for now I can just mount it later in the process.
<Keybuk> yeah
<Keybuk> I need to debug this a bit more really
<Keybuk> I've not seen these md0p1 things before
<Keybuk> I didn't even know you *could* partition raid arrays
<Keybuk> usually I see /dev/md0 ;)
<Keybuk> I think this is a udev bug
<Keybuk> but it may also be a blkid bug, since blkid shouldn't be reporting raid members as filesystems
<rtg> Keybuk, its been awhile since i set this up, but I beleive partitioning was part of the setup documentation
<Keybuk> right
<Keybuk> if you fancy an experiment
<Keybuk> try downgrading udev back to 146
<rtg> can do.
<Keybuk> but don't just replace the package
<Keybuk> because that won't work so well
<Keybuk> instead grab the deb, and get the udevd and udevadm binaries out of it
<Keybuk> and put those in place
<Keybuk> (back up the 147 ones)
<Keybuk> and see if that makes a difference
<rtg> k, first I have go unwire this thing to get it to boot normally. how does one stop grub2 these days?
<Keybuk> hold down shift
<rtg> wasn't it the shift key?
<rtg> hmm, no joy there
<Keybuk> you couldn't get grub2?
<Keybuk> or udev didn't help?
<rtg> Keybuk, I can't get grub2 to stop during the boot process so that I could modify the kernel command line, so I edited /boot/grub/grub.cfg and rebooted. now I'm kind of stuck 'cause / is mounted readonly.
<Keybuk> mount -o rw,remount /
<rtg> Keybuk, yeah, I just came back in here to read the man page :)
<Keybuk> (just be sure to mount -o ro,remount / or SysRq-U before rebooting :p)
<rtg> Keybuk, udev 146 has already been obsoleted from the archive. do you have an amd64 copy lying around?
<Keybuk> #  The default value of the child_runs_first scheduler sysctl knob has been changed to "false." This causes the parent process to continue running after a fork() rather than yielding immediately to the child process. See this article for more information on 2.6.32 scheduler changes.
<Keybuk> oh
<Keybuk> sigh
<Keybuk> happy days
<Keybuk> now we see all the race conditions that people think they fixed, suddenly break again
<Keybuk> admittedly, their fault for not actually fixing it, but hey :p
<rtg> Keybuk, is that the root of the udev issue?
<Keybuk> huh, no
<Keybuk> sorry, was just musing on the 2.6.32 merge window
<Keybuk> rtg: you can get udev 146 from LP still
<Keybuk> https://launchpad.net/ubuntu/karmic/+source/udev/146-1
<Keybuk> there should be a "karmic amd64" link there
<rtg> Keybuk, http://launchpadlibrarian.net/30822986/udev_146-1_amd64.deb
<Keybuk> there you go :)
<rtg> Keybuk, replace both udevadm and udevd ?
<Keybuk> yes
<Keybuk> yay
<Keybuk> https://edge.launchpad.net/ubuntu/karmic/+source/udev/146-1
<Keybuk> err
<Keybuk> proc-connector-add-event-for-process-becoming-session-leader.patch
<Keybuk> is in akpm's big list of patches
<rtg> Keybuk, no difference in nehavior. /home.md0p1 is still not auto-mounted from the fstab. uit works if I put 'mount -a' in /etc/rc.local
<rtg> with -146 (that is)
<Keybuk> ok
<Keybuk> that's good to know
<Keybuk> rtg: can you check something for me
<Keybuk> ls /sys/block/sdb
<Keybuk> do you have sdb1 in there?
<Keybuk> if so
<Keybuk> fdisk -l /dev/sdb
<rtg> root@tyler-b:~# ls /sys/block/sdb
<rtg> alignment_offset  capability  device     holders  queue  removable  sdb1  slaves  subsystem  uevent
<rtg> bdi               dev         ext_range  power    range  ro         size  stat    trace
<rtg> root@tyler-b:~# fdisk -l /dev/sdb
<rtg> Disk /dev/sdb: 500.1 GB, 500107862016 bytes
<rtg> 2 heads, 4 sectors/track, 122096646 cylinders
<rtg> Units = cylinders of 8 * 512 = 4096 bytes
<rtg> Disk identifier: 0xe3da5fd4
<rtg>    Device Boot      Start         End      Blocks   Id  System
<rtg> /dev/sdb1               1   488386496  1953545982   83  Linux
<Keybuk> aha!
<Keybuk> *but* your mdadm says that "/dev/sdb" is the RAID member
<Keybuk> not /dev/sdb1
<rtg> right
<Keybuk> what does blkid -p /dev/sdb say?
<rtg> root@tyler-b:~# blkid -p /dev/sdb
<rtg> /dev/sdb: VERSION="0.90.0" UUID="8d408524-0506-f40d-4659-8b40d611b84e" TYPE="linux_raid_member" USAGE="raid"
<Keybuk> AHA!
<rtg> doesn't mdadm put some crap in fron of the partition table?
<Keybuk> apparently not
<Keybuk> maybe mdadm is putting its metadata in the MBR?
<Keybuk> (is bcmwl a bit busted in Î±6 btw?)
<rtg> dunno about bcmwl. it should be under jockey control
<rtg> is there room in the MBR? it doesn't sound like a reasonable place for it
<Keybuk> no, no idea
<Keybuk> udevinfo -q all -n sdb
<Keybuk> udevinfo -q all -n sdb1
<Keybuk> udevinfo -q all -n md0
<Keybuk> udevinfo -q all -n md0p1
<Keybuk> would be handy
<rtg> Keybuk, is that from a dev package?
<Keybuk> sorry
<Keybuk> udevadm info
<Keybuk> fingers still haven't learned ;)
<rtg> hmm, spewage. I'll collect this in a file
<Keybuk> this is a RAID 0 isn't it
<rtg> Keybuk, yes, 4 spindles
<Keybuk> I have a hypothesis
<rtg> Keybuk, http://kernel.ubuntu.com/~rtg/md0/udev-info.txt
<Keybuk> thanks
<Keybuk> ok
<Keybuk> well there's a couple of interesting bits there
<Keybuk> where did you read this documentation about partitioning your RAID like that?
<rtg> Keybuk, hmm, probably wikipedia. lemme look
<Keybuk> ok
<Keybuk> that's all I need for now
<Keybuk> bbl
<rtg> Keybuk, k, I'm travelling to PDX starting in a couple hours
#ubuntu-kernel 2009-09-18
<ne0futur> hi all, I need to install sudo apt-get install linux-restricted-modules-`uname -r`
<ne0futur> and I dont understand why it needs to install a nvidia kernel
<ne0futur> no way to have madwifi without the nvidia stuff ?
<spstarr> Where can I find nightly builds of the kernel?
<ne0futur> http://kernel.org/
<spstarr> so you don't have a snapshot build like the fedora folks with git snapshots?
<ne0futur> spstarr: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=summary
<spstarr> looks 'old'
<spstarr> .27?
<spstarr> in intrepid
 * spstarr looks for karmic kernel
<ne0futur> https://wiki.ubuntu.com/KernelTeam/FAQ
<ne0futur> ubuntu is debian based
<spstarr> yeah i know
<ne0futur> if you want cutting edge kernel and apps . . . I d recommend something like mandriva
<ne0futur> but its less stable most of the time
<spstarr> well once .32 comes out i wont need cutting kernel
<spstarr> its only the r6xx stuff i want to use
<ne0futur> you can also build your own kernel its not _so_ hard
<spstarr> sure, and have, taking ubuntu's .config
<spstarr> .32 will be out sooner than later 
<cobradevil> Hello all
<cobradevil> I'm testing ubuntu karmic and wanted to ttry fs-cache
<cobradevil> the read speedup for nfs is the thing i'm interested in because of a terminalserver configuration 
<cobradevil> i was looking at the kernel config and saw that the config option for CONFIG_NFS_FSCACHE is not set
<cobradevil> is there a specific reason why it hasn't been enabled?
<hifi> latest 2.6.31 has no fbcon
<hifi> oh, sorry, no, it's just not loaded automagically anymore
<hifi> which kills video signal if used with radeon kms
<hifi> uh, that wasn't so clear, if radeon module is loaded with kms and no fbcon is loaded you get no signal for virtual terminals
<ne0futur> hi all, for madwifi  I need to install sudo apt-get install linux-restricted-modules-`uname -r`
<ne0futur> and I dont understand why it needs to install a nvidia kernel, no way to have madwifi without the nvidia stuff ?
<ne0futur> furtermore trying to install it fails :
<hifi> linux-restricted-modules is a metapackage probably
<ne0futur> i couldnt find another way to get madwifi
<ne0futur> is itpossible to find a kernel with the ath_pci module on ubuntu
<ne0futur> seems it ned a more recent kernel  than those in ubuntu
<amitk_> ne0futur: have you tried the karmic kernel?
<ne0futur> amitk_: i need to upgrade all my distro to get the recent kernel ?
<maxb> ne0futur: You're looking in the wrong direction, ath_pci is old and removed
<amitk_> ne0futur: no, not upgrade the distro. But you can get just the karmic kernel and see if that helps. It has the new ath5k drivers.
<maxb> karmic kernel won't give madwifi, though it will give an up-to-date ath5k which might be a suitable replacement
<maxb> Though that seems to be an inadvisable course of action without first trying linux-backports-modules
<ne0futur> hum ill try to see how i can try this kernel
<ne0futur> apt-cache search karmic gives nothing
<amitk_> ne0futur: what release are you running currently?
<amitk_> maxb makes a good point. Try linux-backports-modules for that release and see if that solves your problem.
<amitk_> ne0futur: If not, you can simply download the karmic kernel .deb from http://packages.ubuntu.com/karmic/linux-image-2.6.31-10-generic (depending on whether you run 32-bit or 64-bit) and try that.
<ne0futur> /etc/debian_version says lenny/sid
<ne0futur> i cant find a /etc/ubuntu-release
<ne0futur> but i instsalled a ubuntu ;)
<ne0futur> I dont want to upgrade distro cause i dont want kde4, kde3 is perfect for me
<ne0futur> ah I found /etc/lsb-release 
<amitk_> ne0futur: what does /proc/version_signature and /etc/lsb_release say?
<ne0futur> says DISTRIB_ID=Ubuntu DISTRIB_RELEASE=8.04 DISTRIB_CODENAME=hardy
<ne0futur> 2.6.24-24.60-generic
<amitk_> ne0futur: in that case best try the linux-backports-modules packages
<ne0futur> ( downloading the .deb from http://packages.ubuntu.com/karmic/linux-image-2.6.31-10-generic is not ok with this ubuntu release ?)
<amitk_> ne0futur: that release is very old. I don't think anybody has tested such a new kernel with Hardy.
<ne0futur> (another question is there a best kernel for a thinkpad laptop than the -generic kernel ? )
<ne0futur> hum ok
<ne0futur> if I upgrade my ubuntu will I be forced to migrate to kde4 or is it possible to stay on kde3 ?
<amitk_> ne0futur: that is a question for #ubuntu. I think the default might be KDE4 but it might be possible to get KDE3 back.
<ne0futur> ok thanks
<ne0futur> i ll try the .deb first and then think on upgrading or using backports
<amitk_> ne0futur: I'd try backports first, the .deb next and then think of upgrading :)
<ne0futur> my other problem is that I nmeed an old xorg to have my intel graphics card working well with flash/3d
<ne0futur> I switched fron mandriva to ubuntu for this reason :
<ne0futur> https://qa.mandriva.com/show_bug.cgi?id=53468
<amitk_> apw: I've got a new branch,  fsl-imx51-next, in my local tree. Should I overwrite the fsl-imx51 in the karmic git tree or just create a new temp branch for you to review?
<ubot3> qa.mandriva.com bug 53468 in Hardware "very slow flash and graphics when using intel 945GM video card" [Major,New] 
<amitk_> ne0futur: you can try out new Ubuntu releases using the livecds/liveusb. So you can check it out without reinstalling your OS.
<ne0futur> yup i ll try this 
<amitk_> apw: I want to get this uploaded today if possible
<ne0futur> thanks
<apw> amitk_, hiya
<apw> let me just check the current branch
<apw> amitk_, we seem to have one commit since the last tag, so assuming you have that, then you can push to the main branch
 * amitk_ checks
<amitk_> apw: yes, I got the one from Tim removing ABI/version from vmlinuz name
<apw> then i can't see any issue pushing it it, is it a rebase?
<apw> i assume so, as the old one is -6.25 based
<amitk_> apw: rebased onto 878e32db158b972b443c5cd8370b2d52068bcaaf (master). Though I see 22 commits since then.
<apw> probabally rebase pretty simply onto the latest tag i'd assume as there aren't any rebases since then
<apw> but if you've tested that one, that seems like a major improvement
<apw> over -rc6
<amitk_> apw: I don't see the -10 tags
<apw> sometimes i find you need to git fetch --tags origin to get them all
<apw> i don't know why sometimes it doesn't get them
<amitk_> git fetch -t still doesn't get me a Ubuntu-2.6.31-10*
<apw> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=summary
<amitk_> nevermind, I am blind
<apw> yet they really are there, gitkweb shows them
<amitk_> I'll rebase onto -10.34
<apw> these arm kernels really are a lot of work
<amitk_> apw: you should see the tree I'm about to push :)
<apw> am i going to barf?
<apw> heheh ...
<apw> amitk_, hopefully the rebase will be unremarkable to that tag
<amitk_> yeah, unremarkable. No config changes too. I'll just push the changelog, skip abi and module checks and push the branch
<amitk_> apw: I'm a bit confused. Should debian/abi be touched or debian.fsl-imx51/abi ?
<apw> abis are in the per branch space, so .fsl-imx51
<apw> getabis is still broken
<amitk_> apw: then why are debian/changelog debian/control, etc. created?
<apw> those have to be in those places as they are used by build system
<apw> built stuff is mostly still in debian as a result
<amitk_> apw: test building once before pushing
<apw> cool
<ogra> amitk, do you know if the imx51 package uses the very same postinst -generic uses ? 
<ogra> i dont get any link in / which makes alternate and netboot installs fail miserably since flash-kernel urgently needs these links
<ogra> apw, ^^^ ?
<ogra> http://paste.ubuntu.com/273349/ ...
<apw> ogra, as far as i know its a direct copy
<ogra> ~ # grep symlink target/etc/kernel-img.conf 
<ogra> do_symlinks = yes
<ogra> but according to the log (and my inspections) the symlink isnt created
<apw> ogra, do they get made on on the dove images?
<ogra> no idea
<ogra> NCommander, did you try out alternate installs on dove yet ? 
<apw> ogra, isn't the install of the kernel failing anyhow
<ogra> update-initrmafs is failing because it calls readlink
<ogra> looking for /vmlinz and /initrd.img
<amitk_> apw: ogra: I see a slight diff
<apw> is that the three new postrm's ?
<amitk_> http://pastebin.ubuntu.com/273351/
<ogra> amitk, thats only error messages if i reasd it right
<amitk_> yeah, seems to be just messages
<ogra> Sep 17 17:59:47 in-target: Setting up linux-image-2.6.31-100-imx51 (2.6.31-100.7) ...
<ogra> after that the symlinks should exist
<apw> Sep 17 17:59:48 in-target: Failed to create initrd image.
<apw> Sep 17 17:59:48 in-target: dpkg: error processing linux-image-2.6.31-100-imx51 (--configure):
<apw> Sep 17 17:59:48 in-target:  subprocess installed post-installation script returned error exit status 2
<apw> Sep 17 17:59:49 in-target:   Package linux-image-2.6.31-100-imx51 is not configured yet.
<ogra> apw, yup, thats the fallout of the missing links
<apw> it seems to have failed in such a way that its not configured
<ogra> Sep 17 17:59:48 in-target: readlink: missing operand
<ogra> thats the actual error
<ogra> update-initramfs looks for /vmlinuz 
<ogra> which the postinst of linux-image-2.6.31-100-imx51 should have created before running update-initramfs
<amitk_> ogra: and it works in the desktop install images?
<ogra> yes
<ogra> but desktop doesnt need flash-kernel ... even if it would have gone through update-initramfs, it would have failed in flash-kernel, the links in / are essential on armel
<apw> ogra, are tehy on the desktop images?
<apw> that log there, how was it generated, is there a command line to do that or something?
<ogra> thats the output of d-i 
<ogra> the desktop images dont use d-i 
<apw> but does the kernel installed there have it
<apw> also when you install kernels manually do they normally maintain the links
<apw> obviously they do in the main kernel, and the script is identicle
<ogra> yes, the desktop images have /vmlinuz and /initrd.img
<ogra> else they wouldnt be installable :)
<apw> so generally the install is making them then
<ogra> (flash-kernel, as i said above )
<ogra> right
<ogra> the linux-image postinst reads /etc/kernel-img.conf and creates them
<ogra> in d-i installs /etc/kernel-img.conf is created by base-installer right before linux-image* is installed
<ogra> in live setups /etc/kernel-img.conf is created by livecd-rootfs right before the linux-image-* package gets installed in the chroot 
<ogra> same procedure two different environments and outcomes
<apw> have you looked at an x86 alternate installer image?
<apw> perhaps they are all broken
<ogra> heh
<ogra> someone would have noticed that ... the log is from A6 testing :)
<ogra> i produced it yesterday with the A6 candidate image 
<apw> not necessarily perhaps its not important on the alternate if you don't have flash-kernel
<ogra> given that i386 all passed i doubt they have that issue
<ogra> flash-kernel is run a lot later
<apw> fair
<ogra> though i'm not sure why the readlink error shows up
<ogra>         if [ -L /initrd.img -a -e /initrd.img ]; then
<ogra>                 linktarget="$(basename "$(readlink /initrd.img)")"
<ogra>         fi
<ogra>         if [ -L /boot/initrd.img -a -e /boot/initrd.img ]; then
<ogra>                 linktarget="$(basename "$(readlink /boot/initrd.img)")"
<ogra>         fi
<ogra> neither of the files exist yet, so the if statement isnt fulfilled
<ogra> (thats from update-initramfs)
<ogra> so it shouldnt call readlink at all
<apw> so i'd say it can't be that readlink which failed
<ogra> there is no other readlink involved i think
<ogra> Sep 17 17:59:48 in-target: update-initramfs: Generating /boot/initrd.img-2.6.31-100-imx51
<ogra> Sep 17 17:59:48 in-target: readlink: missing operand
<ogra> Sep 17 17:59:48 in-target: Try `readlink --help' for more information.
<ogra> Sep 17 17:59:48 in-target: mkinitramfs: missing  root  /sys entry
<ogra> Sep 17 17:59:48 in-target: mkinitramfs: workaround is MODULES=most
<ogra> ogra@osiris:~/Devel/packages/base-installer-1.101ubuntu4$ grep readlink /usr/sbin/update-initramfs 
<ogra> 		linktarget="$(basename "$(readlink /initrd.img)")"
<ogra> 		linktarget="$(basename "$(readlink /boot/initrd.img)")"
<apw> ogra, but thats not all of it
<ogra> all of what ?
<apw> Sep 17 17:59:48 in-target: readlink: missing operand
<apw> Sep 17 17:59:48 in-target: Try `readlink --help' for more information.
<apw> Sep 17 17:59:48 in-target: mkinitramfs: missing  root  /sys entry
<apw> Sep 17 17:59:48 in-target: mkinitramfs: workaround is MODULES=most
<apw> Sep 17 17:59:48 in-target: mkinitramfs: Error please report the bug
<ogra> Sep 17 17:59:48 in-target: readlink: missing operand
<ogra> thats the error
<apw> that comes from hook-functions in initramfs
<apw> yes but there are more readlinnks in that file
<apw> which is run by innitramfs
<apw> mkinitramfs
<ogra> outfile="$(readlink -f "$outfile")"
<ogra> oh you are right
<apw> thats like /sys is broke
<ogra> i see the error msg, buit i dont get why sys would be involved at all
<apw> there are errors about things in sys not being there
<apw> which are surly not right
<apw> and led to it exiting 1
<apw> which led to the kernel install failing
<apw>         if [ -z "${block}" ] || [ ! -e /sys/block/${block} ]; then
<apw>                 echo "mkinitramfs: missing ${block} root ${root} /sys entry"
<apw>                 echo "mkinitramfs: workaround is MODULES=most"
<apw>                 echo "mkinitramfs: Error please report the bug"
<apw>                 exit 1
<apw> that was what it didn't cope with, not syaing the readlink is irrelevant, but its not what triggered the failure of kernel install directly
<ogra> apw, yeah, just found that too 
<apw> so i think that means the kernel links likely would have gotten made 'shortly' but initramfs blew chunks so it stopped
<ogra> yup
<ogra> so its an installer issue, sorry for bothering you guys ... i'll try to find out why base-installer didnt mount /sys
<apw> ogra, not sure if it was mounted or not hard to tell from the error
<apw> there may yet be an issue that /sys/block was missing for some kerenl reason, but see if you can find out if it was mounted
<ogra> well, i see that it isnt mounted atm,
<apw> ahh
<ogra> ~ # mount
<ogra> rootfs on / type rootfs (rw)
<ogra> none on /proc type proc (rw,relatime)
<ogra> none on /sys type sysfs (rw,relatime)
<ogra> tmpfs on /dev type tmpfs (rw,relatime)
<ogra> devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
<ogra> /dev/sda1 on /target type ext4 (rw,relatime,errors=remount-ro,barrier=1,data=ordered)
<ogra> /dev/sda1 on /dev/.static/dev type ext4 (rw,relatime,errors=remount-ro,barrier=1,data=ordered)
<ogra> tmpfs on /target/dev type tmpfs (rw,relatime)
<ogra> neither /proc nor /sys are mounted under /target atm
<apw> if thats 'mid install' then that seems broke
<apw> amitk_, is this an abi-bumper, i assume it is with this huge pile of patches
<amitk_> apw: yes, and adds a module or two. So you could ignore abi and module checks
<apw> ok
<apw> i'll do that
<amitk_> thanks
 * amitk_ steps out for a while
<ogra> amitk, how are the chances of seein the imx51 upload today ? (/me si assembling the release team report and would love to strike the rtc issue from the buglist)
<apw> ogra, i have the tree and it should be uploading imminently
 * ogra hugs apw 
<apw> i've build tested it, and i assume amitk has boot tested the basic tree
<apw> its an abi bumper so it'll be a while churning through the works
<apw> ogra, do you have the agenda for todays meeting yet?
<ogra> yep, lool forwarded it to me, i think robbie doesnt know about the replacement people 
<lool> apw: bounced
<apw> lool, thanks
<Laibsch> Hi
<Laibsch> Why do the mainline kernel builds have only source and header packages lately?
<Laibsch> http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/
#ubuntu-kernel 2009-09-19
<cobradevil> hello all
<cobradevil> is there someone around which is responsible for the kernel config options?
<cobradevil> i have a question about the kernel config cachefs which is enabled but not for nfs and afs
<hyperair> apw: ^^
<cobradevil> i thought cachefs was primarily designed for the network filesystems (at least that was the big hype)
<cobradevil> hyperair: i'm not an irc guru ;) was that apw ^^ for my question?
<hyperair> cobradevil: apw's probably the guy you should be asking. i was just pinging him
<cobradevil> hyperair: ah okay thanx!
<GobiTheGoblin> hi there. Are you guys involved with karmic dev?
<GobiTheGoblin> k, seen the topic now =) The question is this: If I have understood correctly this should be somewhat correct dir/file structure of 2.6.31 http://kernel.ubuntu.com/git-repos/ubuntu/linux-2.6/drivers/hid/
<GobiTheGoblin> Still, when i install sources from repos, those files are not there
<rquarles> Pete, I want to get involved in the kernel, I am sitting in your talk at Atlanta Linux Fest
<rquarles> 1
<rquarles> !
<rquarles> 1
<rquarles> please disregard above lines, laggy wireless 
#ubuntu-kernel 2009-09-20
<penguin42> given an apt-get source'd kernel tree that I've hand patched what is the right way to rebuild a set of packages from it changing the package version number?
<luis_> posible error en 9.04 cuendo me conecto remotamente a un equipo con gnome-rdp no puedo utilizar la mayuscula se activa en el teclado pero no escribe en mayuscula, si tengo precionado la tecla de mayuscula shitf si funciona, creo que es un problema en 9.04, lo prove en 8.10 y funciona bien
<pm124493> Good Morning. I know it is early. I was at the Atlanta Linux Fest yesterday and Pete Graner said Ubuntu Kernel team needs help. I am not a programmer, but I have been in IT for 25 years. How can I help? THX
<|Dreams|> ok so i have installed kernel 2.6.31-020631-generic but now i cant install restricted driver for my ati card when i tried earlier ubuntu rebooted and it came to the log in screen i just seen loads of garbage so had to reinstall -- help lol
<|Dreams|> i read a fw threads with poeple saying that installing the latest nvidia driver solves the problem, i was a bit confused as i use ati radeon? or do they use the same packages
<|Dreams|> i noticed as well you cant update the kernel after u have already installed restricted drivers as dkms fails
<Hans_Henrik> is there a significant difference between the "linux kernel" and ubuntu's kernel?
<domas> hiii! will systemtap uprobes hit some ubuntu kernel? (like, in next LTS? :)
<domas> I must be blind, where did debug info packages go?
<domas> (can't find them in jaunty repos)
<tormod> domas, for kernels?
<domas> tormod: yea
<domas> tormod: I remember there was a package in earlier releases, but now I don't see any in jaunty, so either it is in another repo
<domas> or... I'm blind
<Hans_Henrik> domas: how many fingers am i holding up?
<Hans_Henrik> (hmm maybe this is the wrong channel for jokes)
<domas> =)
<domas> eh, ddebs, right, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/289087
<ubot3> Malone bug 289087 in linux "Missing linux-image-debug packages and metapackages since Intrepid" [Undecided,Confirmed] 
<domas> (just no linux-iamge-debug there either :)
<domas> so, for now they are available just for karmic and hardy, and karmic ones will be gone soon
<domas> on the other hand, hardy wants to install it to /boot, which is of course too small
<mnemoc> hi, are "[ 3099.024303] longhaul: Warning: Timeout while waiting for idle PCI bus.", and a multiple-panic in [<c05001f8>] _spin_lock+0x8/0x10 right after "BUG: soft lockup - CPU#0 stuck for 61s!" related?  (jaunty server or cle266)
<mnemoc> or they are two different things?
<mnemoc> on cle266*
#ubuntu-kernel 2010-09-20
<Kano> hi, the .35 ubuntu kernel has got patches from .36 it seems so that fglrx does not compile
<melkor> fglrx compiles with the .35 kernel?
<Kano> with mainline it does
<melkor> I forgot, the reason I can't use the new fglrx is because my card isn't supported any more hd3650.
<Kano> it is supported
<Kano> just 10-9 is not for xserver 1.9, but you could try lucid with 2.6.35 mainline and it will work
<Kano> just not with the maverick kernel
<melkor> Last I checked (months ago) it was supported with the 9.xx drivers, but not the 10.x.
<Kano> thats incorrect
<Kano> hd2+ is supported
<melkor> But I'd need to install the mainline kernel and not the backports maverick?
<Kano> mainline works
<Kano> 100%
<melkor> Is there a repo with mainline?
<Kano> not directly a repository
<Kano> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.35.4-maverick/
<melkor> Kano: isn't that a maverick kernel?
<Kano> maybe it was compiled with maverick
<Kano> but the libc6 is compatible with lucid
<Kano> so headers work
<Kano> its even compatible with squeeze ;)
<bjf[afk]> melkor: the -maverick indicates it was build with the maverick configuration settings
<bjf[afk]> s/build/built/
<melkor> So after I install this I should be able to reboot to that kernel and install fglrx.  Sometimes I have trouble with fglrx trying to install on the wrong kernel.
<Kano> my script is able to install it
<Kano> rm -f /etc/X11/xorg.conf*
<Kano> http://kanotix.com/files/install-fglrx-debian.sh
<Kano> use my script with -z optoin and reboot then
<Kano> well use a supported kernel... dont forget to install both header debs
<melkor> That is one hell of a script.
<melkor> How do I check my x server version?
<Kano> X -version
<melkor> 1.8.2
<Kano> no problem then
<Kano> .35 kernel is supported, just not the u patched variant
<melkor> what about using the x-swat fglrx package?
<Kano> will not be much different
<melkor> I'm gonna give that a shot it seems easier to undo.
<Kano> i update the script in the minutes after a new fglrx when i know about it. it is even prepared for maverick
<Kano> as soon you can dl the file
<Kano> but not with maverick kernel ;)
<melkor> alright I'm gonna give it a shot.
<smb> RAOF, Are you still around?
<erez_> helo
<erez_> hello
<erez_> I have a kernel oops. i want to report it, but I can't find where to attach the dmesg
<erez_> who should i report it o ?
<smb> erez_, Report it against the linux package (ubuntu-bug linux). If you can write the dmesg to a file to add it to the generated bug report.
<erez_> it doesn't let me add the dmesg log
<smb> erez_, Isn't there a little item to the bottom that says attach file?
<smb> Actually it says "Add attachment or patch" in the bug report
<erez_> not that i saw. i'll try again...
<smb> If you open the bug report in the browser its very much to the bottom of the page. Above "What next"
<erez_> no, it doesn't
<smb> Hm, are you logged into launchpad?
<erez_> no, i used ubuntu-bug linux command
<smb> That should have opened a bug report or at least given you the bug number 
<erez_> i didn't proceed when it said "send report" as the report wasn't finished
<erez_> it also asks strange questions, i have to choose if this is a regression or not, but there is no "i don't know" option
<smb> erez_, Ah, ok. I cannot say from my memory how this exactly looks like. But it should not matter. Just finish it off and then the report can be completed 
<erez_> ok, trying right now
<smb> erez_, Did it work before (with and older release or the same release)?
<erez_> is an OOPS is a "Kernel Config" or "Other" or "I Don't know"
<erez_> I know what a "regression is", i just didn't test this with a previous ubuntu 
<smb> Was that still the question about regression or another one (the one with kernel config ....) Ok, in that case I would rather say no to regression
<smb> It also can be changed later, when more is known
<smb> Otherwise an oops is rather unlikely a kernel config. So I'd say either other or don't know 
<smb> erez_, One note, if you are using the system which had the oops for the generation of the bug report, then ubuntu-bug adds the dmesg output automatically
<erez_> ok, thanks
<erez_> after i finished the bug report, it opened lunchpad on my browser. i can login, however - it doesn't seem to associate that to the ubuntu-bug i just used 
<smb> Hm, it has been a little while when I used it. I thought it would redirect you to the bug report after login. Was there any printing of the generated bug number somewhere?
<erez_> no
<erez_> i will just have to fill it manually
<erez_> ok, thanks smb, bug commited
<erez_> bye
<tseliot> apw, smb: there's no gpl code in fglrx hence I can't use that workaround that you suggested. Furthermore it seems that things broke in Lucid too
<tseliot> as shown in make.log here: https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/573748/comments/28
<ubot2> Ubuntu bug 573748 in fglrx-installer (Ubuntu) "[MASTER] fglrx does not build on 2.6.33 kernel and higher (affects: 103) (dups: 33) (heat: 618)" [Medium,Triaged]
<tseliot> apw, smb-afk: the problem is that even if I patch the driver to call arch_compat_alloc_user_space instead of compat_alloc_user_space when dealing with 2.6.32 and 2.6.35 I can't check the ABI and the patch may or may not break the module compilation
 * tseliot repeats things for smb-afk
<tseliot> smb: there's no gpl code in fglrx hence I can't use that workaround that you suggested. Furthermore it seems that things broke in Lucid too, as shown in make.log here: https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/573748/comments/28
<ubot2> Ubuntu bug 573748 in fglrx-installer (Ubuntu) "[MASTER] fglrx does not build on 2.6.33 kernel and higher (affects: 103) (dups: 33) (heat: 618)" [Medium,Triaged]
<smb> tseliot, That is bad. In hindsight it might have been better to modify the security patches to export normally
<tseliot> smb: yep. What do you suggest that we do now?
<tseliot> patch the kernel and undo the breakage?
<smb> tseliot, I'll have to talk to the security team. Problem atm likely is that no binary gfx driver works (or is this restricted to fglrx only
<smb> ?)
<smb> The question would be whether to revert it as a single upload or have it packaged into the next security release
<tseliot> smb: nvidia doesn't seem to use that function so hopefully it's just fglrx
<smb> tseliot, Ok, at least something but I agree that it should be reverted. I just hope that changing the type of export does not cause an abi bump. But on the other hand it did not when the function was made gpl only.
<tseliot> smb: ok. Are you referring only to Lucid's kernel or also to Maverick's?
<smb> That would be only Lucid and before, though. Long term (and that would inlcude Maverick) the fglrx driver likely needs somehow to cope
<smb> This change is upstream that way and I don't think it will change there
<tseliot> smb: I suspected that. In Maverick I'll have no way to check the availability of that function at compilation time so my patch won't work on kernels with older ABIs
<tseliot> :/
<smb> tseliot, But to as back about the workaround: what was the problem that may break older things?
<tseliot> smb: I would call arch_compat_alloc_user_space instead of compat_alloc_user_space
<smb> tseliot, When you posted that I was trying to get an irc proxy working, so I might have missed details
<tseliot> ^
<smb> ok, there was no place for the wrapper? calling arch would not be very good. 
<smb> Neither in old code which does not have it nor in new where it is not doing any checking
<tseliot> smb: the wrapper that you suggested would work well only if there were GPL files in the fglrx driver
<tseliot> Amd told me that there isn't any
<smb> tseliot, Would it not be possible to add a file and make that gpl?
<smb> Somehow I thought they had some issues with other functions that became gpl exported only before
<tseliot> smb: I'm not sure. I guess that would be a problem too
<tseliot> smb: the problem is that they moved compat_alloc_user_space from asm/compat.h to kernel/compat.c and did EXPORT_SYMBOL_GPL(compat_alloc_user_space)
<smb> tseliot, Hm, I guess I need to think about that. I need to leave for lunch, too. Let me think and I'll get back to you.
<tseliot> smb: ok, thanks
<smb> tseliot, remind me of the source package name for fglrx
<tseliot> smb: fglrx-installer
<smb> ok, ta
<tseliot> smb: this is the correct bug report: https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/642518
<ubot2> Ubuntu bug 642518 in fglrx-installer (Ubuntu Lucid) (and 1 other project) "[MASTER] package fglrx 2:8.723.1-0ubuntu4 failed to install/upgrade: Kernel fix for CVE-2010-3081 breaks fglrx (affects: 176) (dups: 165) (heat: 1408)" [High,Triaged]
<smb> tseliot, Ok, I just sent out an email. I believe this could work.
<tseliot> smb: did you CC me?
<smb> tseliot, no, I To'ed you
<tseliot> ah, even better
<smb> In essence you may be able to decide whether to use arch_compat_... or compat_... based on whether compat_alloc_user_space is an exported symbol in kallsyms
<smb> tseliot, I have not tested against old kernels yet, but I believe the principle should work
 * tseliot reads the email
<smb> Darn, most of my systems have ATI cards that are no longer supported by fglrx
<tseliot> smb: now, that's clever :)
<smb> tseliot, Clever of ATI :-P They used to be previously but them removed support apparently
<tseliot> smb: yes, I was referring to your patch ;) I'm more than fine with the open driver even with cards that are supported by fglrx
<tseliot> ~$ grep "T compat_alloc_user_space" /proc/kallsyms
<tseliot> ffffffff810a5630 T compat_alloc_user_space
<tseliot> this is with 2.6.35-22-generic
<smb> Ah I thought you referred to the cards no longer being supported. :) I just checked on an older Lucid kernel, there is no such entry in kallsyms
<smb> Seems I found a system that has a more recent card
<tseliot> good
<smb> *argh* that is a 32bit installation...
<tseliot> hey at least we can use the workaround in Maverick
<tseliot> I can try a Lucid livecd
<smb> We could potentially use the workaround on Lucid, too. Somehow I suspect we get the fglrx package updated faster than the kernel
<smb> (not to forget that I know how much pain it will be to do from the amount of work)
<smb> tseliot, Oh, so actually the breakage is limited to 64bit as well...
<smb> given that this 32bit install is happy with the most recent kernel. OK, should have known by the fact that this is in compat_...
<tseliot> smb: yes, sorry, I should have pointed that out before
<smb> tseliot, As I said I should have known from the code. :)
<tseliot> hehe ok
<smb> tseliot, How much effort would it be for you to update fglrx for the older releases as well? I am winching about making a kernel update as that not only means new kernel packages for all the releases but also merging things around and creating new proposed uploads for Karmic and Lucid... again...
<tseliot> smb: if your workaround works as expected on Lucid, I think I can safely do that. Oh does it also affect Karmic?
<smb> tseliot, Unfortunately that change went in back to Dapper, so it would affect all that have som fglrx support. (I think Hardy its envy)
<tseliot> smb: ouch
<smb> Yeah. :( 
<tseliot> ok, it looks like I'll have some additional work to do
<smb> tseliot, Hm I am not even sure just changing EXPORT_SYMBOL_GPL to EXPORT_SYMBOL would be enough as the function declaration is in linux/compat.h and I think you mentioned that the fglrx driver only includes asm/compat.h. *urgh*
<tseliot> smb: yes, it can't include linux/compat.h
 * smb offers to by tseliot beers in Orlando (though I was told you might not enjoy that)
<tseliot> smb: hehe, right, I don't drink. Let's put it this way, you can offer me a coke and I'll buy you a beer for your patch ;)
<smb> tseliot, Ah ok. NP with that. (though I was actually referring to the beer quality) :)
<tseliot> smb: I wouldn't have noticed anyway ;)
<smb> I see that know. :)
<tseliot> hehe
<smb> tseliot, Should I update the bug report with those facts we have discussed here?
<tseliot> smb: yes, sure that would be welcome
<smb> ok, will do
<tseliot> smb: your patch works well in Maverick. I'll test it in Lucid soon
<smb> tseliot, OK, cool. :)
<aquarius> after upgrading to maverick, when I tell my machine (dell m1330) to restart, it jumps to the "ubuntu" shutdown screen with the 5 dots, and the 5 dots continue to tick over forever, but the machine never shuts down/restarts. It worked under lucid, so this is a regression somewhere. Which information do I need to provide to help you chaps fix it?
<aquarius> is "ubuntu-bug -p linux" sufficient?
<jjohansen> aquarius: its a start, along with a description of what is going on
<jjohansen> aquarius: if you still have the Lucid kernel installed it is worth booting with it too
<aquarius> jjohansen, ok, I'll do that
<jjohansen> that would help isolate whether its actually the kernel or maybe upstart/plymouth
<aquarius> er. Warning: The options -p/-P are deprecated, please do not use them. :)
<aquarius> will try rebooting with the lucid  kernel next time I reboot before fiiling a bug
<ogasawara> smb: your misc blueprint work item to pull back the Lucid version of fsl-imx51 to karmic-fsl-imx51... didn't you mention we won't do that?  ie I can mark that one off the list?
<smb> ogasawara, Oh, I think I should make that announcement I wanted to but forgot with oall the other stuff going on
<ogasawara> smb: also, I thought that you, sconklin, and bjf[afk] have been documenting the stable team processes.  Anything left to document there?  or can I mark that work item as done also.
<bjf> ogasawara: please mark it done though with all kernel wiki documentation its really never ending
<ogasawara> bjf: ack
<smb> ogasawara, I have the feeling that there might still be something. But as bjf says
<sconklin> ogasawara: I think that we have enough documentation for Brad and I to consult, but not of a quality to be generally useful. We've done a lot. Maybe it's appropriate to close it and open a new task for next cycle.
<smb> ogra, Is there a specific mailing list for arm or is this ubuntu-mobile?
<fta> could someone please have look at bug 638024? looks like a kernel panic (with a patch in the upstream bug)
<ubot2> Launchpad bug 638024 in chromium-browser (Ubuntu) "Crashes ubuntu on application exit (affects: 3) (heat: 18)" [Undecided,New] https://launchpad.net/bugs/638024
<jjohansen> fta: I'll take a look in a bit
<ogasawara> fta: comment #32 - http://code.google.com/p/chromium/issues/detail?id=54617#c32 notes this doesn't seem to be an issue with the 2.6.35 kernel
<ogasawara> fta: so I assume this shouldn't be an issue for Maverick
<fta> the OP seems to be using lucid
<ogasawara> fta: indeed, so it seems they should confirm if the issue still exists in Maverick before any further work is done trying to backport anything to Lucid.
<jjohansen> -> lunch
 * ogasawara lunch
<Keybuk> mjg59: here's a random one for you, when you're up
<Keybuk> the current MBPs have both an Intel GMA HD and an nVidia card in them, right?
<Keybuk> Linux only sees the NV
#ubuntu-kernel 2010-09-21
<MTecknology> jjohansen: Hey- you weren't around when I wanted to give you a big gargantuan hug. Thanks for the help. :)
<jjohansen> MTecknology: glad to here it worked for you
<smb> morning
<abogani> smb: Good morning to you.
<eugenesan> Hi all, I am experiencing frequent OOM kills with -25 from proposed. I am I alone?
<jjohansen> eugenesan: hrmm, I haven't heard any complaints of OOM kills, do you have a bug with some logs attached?
<jk-> hey cking 
<smb> I have not seen any OOM kills either
<cking> jk-, hiya
 * cking forgot to start irc, doh
<eugenesan> jjohansen: Nope, I wanted to consult here first. I am seeing it on 2 different machines, without a reason with plenty free pages...
<smb> cking, what a wonderful world this seemed to be ;-)
<cking> smb, indeedy
<jjohansen> eugenesan: open a bug using ubuntu-bug linux
<eugenesan> I need suggestion for correct bug title, to be self explaining for non technical users?
<eugenesan> From my expirience OOM causes long hangs and applications termination.
<jjohansen> eugenesan: hrmm, I'm not sure the non technical users will understand that the oom killer is what causing their apps to die
<eugenesan> Just been hit by OOM with 2.6.32-24-generic-pae... very odd
<eugenesan> Please take a look at http://paste.ubuntu.com/497587/
<tseliot> smb: I guess I'll have to update fglrx in Jaunty and Hardy too in addition to Lucid and Karmic
<tseliot> :/
<Kano> hi, when will 2.6.35.5 mainline ready
<Kano> 36rc5 would be good too
<apw> Kano, .5 is second in the queue so i'd say now+4hrs, -rc5 is after that say +6hrs
<Kano> ok
<tseliot> apw, smb: I guess you'll have to apply the patch to fglrx in the linux-restricted-modules in Hardy (I should do the same with envyng, I guess)
<smb> tseliot, Yes thats true. Will see about lrm
<tseliot> ok
<mjg59> Keybuk: No, there's two nvidias, no Intel
<Keybuk> mjg59: the spec says it's an Intel GMA HD and an NVIDIA GT330M
<mjg59> Keybuk: Which mbp?
<Keybuk> 6,2 - the 15" 2.66Ghz i7
<mjg59> Oh, of course, it's an arrandale. Ok.
<mjg59> Apple seem to have their own magic video muxing device. I'm not clear on how they handle the PCI devices, though.
<mjg59> In their nvidia setups both are visible.
<Keybuk> yeah only the NV is visible in lspci
<hallyn> jj-afk: at k by chance?
<ogasawara> smb: from the ml thread, it seems everyone is fine to drop support for fsl-imx51 in karmic.  so I'm just going to delete the work item from the blueprint.
<smb> ogasawara, ack. I'll mothball the branch soonish
 * smb likes a work-item being completed without doing work
<jjohansen> hallyn: pong
<hallyn> jjohansen: i was going to ask if you had any hints on how to specify your debug kernel to be used (bc it wasn't being used by default despite being the highest version #) but think i've got it, thanks
<bjf> ogasawara: is there a wiki page which explains what the conditions are to change a bug status from "New" to "Triaged"? (or any other state for that matter)
<popey> hullo linux kernel people!
<ogasawara> bjf: I know there is, I just have to remember now where it is in our black hole of wiki pages
<popey> if someone has a moment, could they look at bug 642792 which appears to be a regression, breaking ALT+PrintScreen functionality in GNOME
<ubot2> Launchpad bug 642792 in linux (Ubuntu) "ALT+PrtSc not recognised (affects: 3) (heat: 3390)" [Undecided,Confirmed] https://launchpad.net/bugs/642792
<bjf> ogasawara: the other thing is we seem to be generating logs of bugs due to various kernel "WARNING" messages
<ogasawara> bjf: I think those will go away when they turn off kerneloops after release
<ogasawara> bjf: and I believe there's been a lingering work item to fix that up
<ogasawara> bjf: https://wiki.ubuntu.com/Kernel/BugTriage/BugStates
<bjf> ogasawara: thanks
<jjohansen> -> lunch
 * ogasawara lunch
<MTecknology> pgraner: Ya know... I remember all of a sudden getting a crap ton less email... I didn't even notice I dropped myself from the team. I think I meant to drop from another one I was in..
<Keybuk> Sep 21 22:10:45 deathspank kernel: [   16.122012] intel ips 0000:00:1f.6: Warning: CPU TDP doesn't match expected value (found 26, expected 35)
<Keybuk> Sep 21 22:10:45 deathspank kernel: [   16.122178] intel ips 0000:00:1f.6: failed to get i915 symbols, graphics turbo disabled
<Keybuk> Sep 21 22:10:45 deathspank kernel: [   16.122260] intel ips 0000:00:1f.6: request irq failed, aborting
<Keybuk> Sep 21 22:10:45 deathspank kernel: [   16.122338] intel ips: probe of 0000:00:1f.6 failed with error -16
<Keybuk> mjg59: ^ of possible relevance, perhaps
<mjg59> Keybuk: That's just the ips driver complaining that it can't get at the i915 symbols, presumably because i915 never loaded
<mjg59> Because the PCI device isn't there
<Keybuk> ah right
<Keybuk> IPS being the power stuff?
<mjg59> Yeah
#ubuntu-kernel 2010-09-22
<TheMuso> bjf[afk]: I think we have a problem with alsa daily snapshots and missing/unknown symbols for both lucid and maverick. Had some users report bugs where they are using daily build packages, and no sound devices are found. Dmesg shows symbols not being found. I'm going to see what I can find out.
<TheMuso> bjf[afk]: I can reproduce on maverick, and about to do a lucid install on some hardware to attempt to reproduce there to be 100% sure.
<TheMuso> bjf[afk]: Seems that some symbols are undefined at link time for some modules. I'll try and track this down some more tomorrow, not in a mental state atm to work out where to go from here, and dig hrough more autotools foo for alsa-driver...
<avinashhm> hi, any one familiar with this ??? "fs_initcall(inet_init);" .. i commented this and my linux isn't booting ... its running on an SOC ..
<smb> avinashhm, It adds inet_init to the functions called when the system boots. There are various stages of this and fs_initcall ususally initializes filesystem related modules.
<avinashhm> smb, i dont need inet_init ... its something related to network .... So thought of remvonig it ... Is it very necessary for the system to run or we can remove ???
<avinashhm> It does something before last login time ... 
<avinashhm> init: ureadahead main process (524) terminated with status 5
<avinashhm> -->
<avinashhm> Last login: Sun Jan  2 04:34:55 CET 2000 on tty1
<smb> Are you really sure you don't need it if you cannot boot after you remove it? Don't know where this is and whether maybe other people would not be happy about removing it. Also keep in mind that loopback is network, too and it is neaded.
<avinashhm> So after removing the initcall, it hangs at the arrow marked point ... 
<avinashhm> I am testing it on an SOC ... We observe once in about 2 hours, it crashes in a fucntion rt_worker_func ...
<avinashhm> This function is in route.c ...So we thought we ll remove network related and removed the initcall ...
<avinashhm> smb, Whats loopback ?? 
<smb> lo0 the network device that represents the localhost
<smb> and a lot of things use it
<smb> I cannot really help with details but I think removing that initcall sounds like a bad idea
<avinashhm> oh .. .:-( .... seems like i can't get rid of it ...
<RAOF> smb: Sorry for not getting back to you re: those radeon patches; I've replied now.
<avinashhm> smb, thanks .. for the replies ... I ll try to have initcall and look what else i can do ... thanks again
<smb> RAOF, He is alive! ;) Ok, thanks, I'll have a look
<RAOF> smb: Sorry; traveling from Toulouse to Hobart takes me through any number of un-wifi'd airport terminals.
<smb> avinashhm, no problem and good luck
<RAOF> And leaves me ~110% asleep.
<RAOF> :)
<smb> RAOF, Why do you need to live on the other half of the world. :)
<RAOF> Because I'm much cooler than you.  I live in the future, damnit!
<RAOF> Spending 36 hours to travel anywhere is surely a small price to pay to live in the future :P
<smb> RAOF, d-; ËÉÉ¹nÊnÉ ÊÉ¯ sÉ sÄ±É¥Ê ÆuÄ±ÊdÉÉÉÉ É¯oÉ¹É ÊuÉsÉÉ¹ Ä±
<RAOF> :)
<smb> RAOF, Though I must admit its a good pickup line: "I come from the future and must warn you..." :)
<RAOF> Heh.
<smb> So the answer seems to be we can take the patches or not. Whatever we want. So I guess if its ok well try with them
<RAOF> They seem to make sense, yes.
<smb> Ok, thanks a lot. Then we can go on to have them included in your world (the future, usually even more into it than you could ever live)
<avinashhm> smb, how did you do that .. pasted invert :-) ...nice
<smb> avinashhm, Used an upside down generator on the web and pasted the result. :)
<avinashhm> smb, )-: Éuo ÉÉÄ±u ÊÉÉ¥
<bjf> tgardner: fly to the other side of the world to have a public holiday? :-) (how are things going?)
<tgardner> bjf, s'okay. its hot here though.
<tgardner> really hot.
<jjohansen> ogasawara: how soon do you want the AA patches?  I have them but I am still working on updating regression testing
<ogasawara> jjohansen: definitely no hurry as they likely won't get uploaded until after the 10.10 official release.  So maybe just get them to the list by beginning-mid next week or earlier if you want.
<jjohansen> ogasawara: earlier, I just want to make sure they are thoroughly tested
<ogasawara> jjohansen: ack
<vanhoof> hello friends :)
<vanhoof> im willing to buy someone a beer if they can build me a kernel on a machine with actual power :)
<ogasawara> vanhoof: I can kick a build off for you
<ogasawara> vanhoof: what's the patch you need and what arch?
<vanhoof> ogasawara: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e259befd9013e212648c3bd4f6f1fbf92d0dd51d
<vanhoof> ogasawara: amd64
<vanhoof> ogasawara: on top of the latest mav kernel
<ogasawara> vanhoof: ack, gimme a few minutes and I'll get it going
<vanhoof> ogasawara: \o/ thank you
<vanhoof> last time it took me 4 hours to build :D
<ogasawara> yuck
<bjf> vanhoof: you need tgardner to give you access to tangerine
 * vanhoof is down for that
<vanhoof> I don't need to build often, but when i do i cringe
<ogasawara> smb, sconklin, bjf: EtienneG is inquiring about bug 554569
<ubot2> Launchpad bug 554569 in gentoo (and 6 other projects) "[lucid] Blank screen with KMS on Thinkpad X201 with Arrandale (i915) (affects: 43) (dups: 1) (heat: 300)" [Unknown,Fix released] https://launchpad.net/bugs/554569
<ogasawara> [10:00:37] <ogasawara> EtienneG: no worries, anything you need me to ping them about?
<ogasawara> [10:01:02] <EtienneG> ogasawara, yes, status of bug #554569 in lucid
<ogasawara> [10:01:18] <EtienneG> it is marked fix Commited, and milestoned for 10.04.2
<ogasawara> [10:01:38] <EtienneG> i was wondering if the patch will appear in an SRU earlier than 10.04.2
<ogasawara> [10:01:53] <EtienneG> and if yes, approx ETA for that
<vanhoof> heh
<vanhoof> its sitting in -proposed
<vanhoof> its been bumped twice by security
<ogasawara> I always love the ETA questions
<smb> yeah
<smb> eta somewhen
<ogasawara> heh
<vanhoof> that bug has a special place in my heart
<bjf> vanhoof: it really hasn't been bumped by security, the clock has not been reset on it really
<bjf> vanhoof: it's just that that patchset was so large the sru team wanted to let it bake a while
<smb> on the status page yes, but that should not matter that much. it also suffered from not really many people doing verification on their bugs
<vanhoof> bjf: well it has been once at least
<vanhoof> bjf: how has the clock not been reset?  it went from ~18 to 3 last i checked?
<smb> vanhoof, Yes but that probably can be argued with the sru team
<vanhoof> do you say that since the bugs that has been verified stayed verified?
<smb> we know it has been out longer
<smb> Yes, the verification tags do not get reset
<vanhoof> ah ok
<lamont> why does the maverick kernel have a 25GB footprint on the build machine?
<kees> lamont: lots of flavor?
<lamont> 23GB in lucid, 14GB in karmic
<lamont> kees: and a build process that doesn't believe in /bin/rm
<smb> and each compiled with debug info which is only stripped on packaging
<lamont> well, lucid fails to build on most of our ppa builders, and maverick will only be worse
<smb> Hm, I was not aware that there are problems with it
<ogasawara> vanhoof: I'm seeing build failures with that patch, gimme a sec to see if I can get it fixed up
<lamont> it helps even less that when it fails, it sometimes decides to just loop
<lamont> and what I'll assert is likely the second largest package in the archvie (openoffice.org) has a build footprint of a "mere" 6.5GB
<vanhoof> ogasawara: cool, i hope its not too much trouble
<lamont> smb: sounds like time for me to file a bug, I guess
<smb> lamont, most if that footprint really is that the compile stage is done with full debug symbols. Maybe it would be possible to clean between flavour builds, but I am not sure. Yes, if that needs to change I guess a bug will remind us to...
<lamont> ta
<vanhoof> wow, my tv viewing just got screwed up pretty bad for the next few months :\
<vanhoof> "For Thu: Ghost Whisperer: Season 1: Disc 1"
<vanhoof> ... I sure didnt put that in queue, I bet I know what's coming after that
<ogasawara> vanhoof: are you testing this kernel yourself or giving to someone else to test?
<vanhoof> ogasawara: myself
<vanhoof> ogasawara: and Sarvatt 
<ogasawara> vanhoof: so I forgot to tweak the version, but I can change that and rebuild, will be about 10 more min
<vanhoof> ogasawara: cool, thank you very much!
<ogasawara> vanhoof: http://people.canonical.com/~ogasawara/test-build/vanhoof/
<Sarvatt> vanhoof: it may not be just that patch :( 20100921 resumes with a garbled display, 20100922 is fine
<Sarvatt> thanks ogasawara! testing now
<vanhoof> was on the phone
 * vanhoof grabs kernel
<vanhoof> Sarvatt: i tried 22, and did not resume at all
<vanhoof> i guess we'll know here in a second :D
<Sarvatt> yeah, 0921 comes up at least but its garbled and 0922 with it works right and it doesn't come up at all on maverick
<vanhoof> Sarvatt: https://bugs.freedesktop.org/show_bug.cgi?id=29631
<ubot2> Freedesktop bug 29631 in DRM/Intel "[Huron River] Resume does not work on HR CRB (resume screen corruption issue)." [Normal,Resolved: fixed]
<vanhoof> which i found from https://bugs.freedesktop.org/show_bug.cgi?id=30199
<ubot2> Freedesktop bug 30199 in DRM/Intel "[Huron River] render corruption after S3 resume (with tiling)" [Major,Resolved: fixed]
<Lollipop56> hi there
<Lollipop56> I was wondering why Ubuntu doesn't allow software to auto-update itself instead of working with PPAs, Ubuntu uses the Linux kernel whereas OSX uses the Darwin kernel. Now, both are stable, if not Linux is even more stable, so why??
<scrllock2> anyone know if this kernel: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.36-rc5-maverick/  has been patched for the recent root exploit? (http://www.ubuntu.com/usn/usn-988-1)
<ogasawara> scrllock2: all the patches for CVE-2010-3081 and CVE-1020-3301 should be upstream as of 2.6.36-rc5
<ubot2> ogasawara: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3081)
<scrllock2> ogasawara: thank you very much.
<jjohansen> -> Lunch
<rsalveti> argh, sometimes I'm getting a weird issue with my radeon card at my thinkpad t400
<rsalveti> my monitor suspends after a while, and when I try to wake him up sometimes the display just goes blank
<rsalveti> X turns dead, but I still get console
<rsalveti> and at my kernel log: [90595.959747] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
<rsalveti> doesn't happen all the time
<rsalveti> with current maverick
<lfaraone> ogasawara: btw, what was changed in linux-meta 2.6.35.22.23 that casued the ABI bump? the changelog gives me no hints.
<ogasawara> lfaraone: nothing in the linux-meta package changed, but the linux package required an ABI bump which resulted in the ABI bump for linux-meta
<lfaraone> oops, I should have looked at "linux".
<lfaraone> background: after upgrading today, resume-from-suspend stopped working, and disabling nvidia drivers didn't help. I'm thinking of rolling back to 21 to see if that was the cause.
#ubuntu-kernel 2010-09-23
<lamont> smb`: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/645653
<ubot2> Ubuntu bug 645653 in linux (Ubuntu) "kernel is unbuildably large (affects: 1) (heat: 6)" [High,Confirmed]
<kees> hah
<lamont> kees: you say that now...
<jjohansen> lamont: don't worry openoffice will catch up in size
<lamont> jjohansen: I'm seriously considering quotas at around 15GB when natty opens
<lamont> karmic was a mere 14GB
<jjohansen> lamont: the kernel build is a pig, I am not sure what we can do about it
<lamont> jjohansen: removing .o files after the link stage comes to mind as a likely option
<jjohansen> lamont: that has to be done incrementally however, and then it interferes with the ability to incremental builds
<lamont> building the .deb files one at a time (skipping dh_builddeb) would be a much less sane but doable option
<lamont> still,  not being able to build packages in a ppa that we build in the distro is just plain bad
<jjohansen> agreed
<jjohansen> and we need kernel ppas
<lamont> anyway, afk for me.
 * vanhoof waits and keeps his fingers crossed that https://edge.launchpad.net/~leannogasawara/+archive/kernel-ppa holds all the fixes he needs :D
<lag> cnd: ping
<ogasawara> smb, bjf, sconklin, kees: fyi bug 643971
<ubot2> Launchpad bug 643971 in linux (Ubuntu) "security updates issued Sept. 18, 2010 causes system to repeatedly boot into initramfs (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/643971
<kees> ogasawara: weird; doesn't really sound kernel related.
<smb> ogasawara, thanks for the pointer. looking...
<smb> kees, Yeah
<smb> Feels a bit like maybe a udev race but probably need to read more closely
<ogasawara> kees: yah, the bug seems to need further investigation
<smb> ogasawara, kees Hm, nothing really obvious in the dmesg there. Likely the files were taken from the good boot anyway
<kees> smb: your quick handling of the root-escalation vulns has been noticed: http://lwn.net/Articles/405662/ :)
<smb> kees, Gosh I wanna see. if I would remember the subscription details... :/
<jjohansen> smb: you have to set up an lwn account then send the account details to someone in canonical /me hasn't done it yet either
<smb> jjohansen, Yeah, I have part 1 but try to remember the someone for part 2 
<jjohansen> smb: Email maria.randazzo@canonical.com with your lwn username which will be generated once 
<jjohansen>           you have created an account
<smb> jjohansen, Ah thanks, should do that
<Edgan> When is 2.6.32-25 going to get released as an official update to Lucid?
<bjf> Edgan: can't give a specific date for that, it's working it's way through our process
<Edgan> bjf: I keep running into an issue with kernels going into limbo with a message in dmesg about 120 seconds. It is getting old.
<bjf> Edgan: do you have a bug number we can look at?
<bjf> Edgan: have you tried the 2.6.32-25 kernel and does it fix this problem for you?
<Edgan> bjf: I am pretty sure it is fixed in -25. The one that just did it was a pre-25. Give me a minute and I will dig up at least one bug number.
<Edgan> bjf: pre-25, as in pre-release of 25.
<bjf> Edgan: interestingly enough if it fixes more bugs it could help us get it to updates quicker (my thinking anyway)
<Edgan> bjf: Here is at least a similar bug, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/588046
<ubot2> Ubuntu bug 588046 in linux (Ubuntu) ""task blocked for more than 120 seconds" freezes system in Lucid: xfs (affects: 3) (heat: 39)" [Medium,Triaged]
<Edgan> bjf: https://bugs.launchpad.net/linux/+bug/543617  is another
<ubot2> Ubuntu bug 543617 in linux (Fedora) (and 3 other projects) "Unmount of an fs with dirty cache buffers causes pathological slowdown (affects: 14) (dups: 2) (heat: 132)" [Unknown,Unknown]
<bjf> Edgan: can you confirm that the -25 proposed kernel fixes the issue for you?
<Edgan> bjf: https://bugs.launchpad.net/ubuntu/lucid/+source/linux/+bug/585092  here is the main one I was following
<ubot2> Ubuntu bug 585092 in linux (Ubuntu Maverick) (and 2 other projects) "giant IO delays on unmount (affects: 2) (heat: 40)" [Medium,Fix released]
<bjf> Edgan: thanks, looking at all 3
<Edgan> bjf: I can confirm it fixed an issue with one of my servers that the symptom was a 120 second message. Which exact bug, not 100% sure on, but I think it is the last
<vanhoof> ogasawara: do you have https://edge.launchpad.net/~leannogasawara/+archive/kernel-ppa/+build/1971068 built anywhere atm?
<Edgan> bjf: Actually more than one. I have four build machines, and one had the issue. All the same hardware and workload. So I loaded -25 on them. Then I had someone doing mpi work on another machine, and -25 seems to have fixed it too.
<vanhoof> ogasawara: looks like the build failed due to low disk space
<Edgan> bjf: I suspect it will also fix my backup server, that I just ran into it on.
<bjf> Edgan: two of those bugs have been marked "verification-done" which indicates the proposed fixed the issue for the tester
<Edgan> bjf: ok
<pmatulis> what do H71 or H74 kernels refer to?
<ogasawara> vanhoof: that's a bug we just found out about
<ogasawara> vanhoof: I can kick off a build for amd64 on tangerine and post it
<ogasawara> vanhoof: i386 built fine
 * ogasawara lunch
 * jjohansen -> lunch
#ubuntu-kernel 2010-09-24
<jj-afk> bjf[afk]: around?
<bjf[afk]> yup
<jj-afk> I have a ppa abi question
<bjf[afk]> ok
<jj-afk> I have a ppa that is failing on the abi check
<jj-afk> however it worked the first build and I haven't bumped abi since
<bjf[afk]> wow, that's weird
<jj-afk> yeah, I am sure I have done something wrong but, the whole abi bump, upload part is uhmm poorly documented
<jj-afk> do you have some docs you follow when working through the bump?
<jj-afk> I noticed certain steps in the maintanence guide don't seem to work anymore
<bjf[afk]> trying to find my notes
<bjf[afk]> mostly we use the maint-starnewrelease script, it advances the build number however i'm not sure how it knows to bump the abi
<jj-afk> it doesn't
<bjf[afk]> one thing you can do is "git mv <old-abi-directory> <new-abi-directory>"
<jj-afk> won't that cause a failure if the abi has change though
<bjf[afk]> let me send you my notes and see if they make any sense to you, they don't to me right now
<jj-afk> okay, and I will give moving the abi file a try
<bjf[afk]> i've only had to go through this once
<bjf[afk]> email sent
<jj-afk> ah, okay.  I've only bumbled through it on my ppa once and fluked out on getting it to work, and now it won't :)
<jj-afk> thanks
<bjf[afk]> now that my notes don't make sense to me i'm going to have to go through them again tomorrow and fix them up
<ogra> apw, ouch ...
<ogra> apw, we have another package description pointing wrongly to versatile ...
<ogra> apw, omap4 meta seems to still have it
<doko> apw: who can tell me about binary demotions of kernel packages? see http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<doko> or ogasawara ? ^^^
<tseliot> smb: do you know if all of the releases of 2.6.36 have the security fix with arch_compat_alloc_user_space?
<smb> tseliot, Some of the early -rc's may not but the change is in upstream now
<smb> tseliot, commit was between -rc4 and -rc5
<tseliot> smb: ok, as I'm facing a weird issue with fglrx (from maverick) and (mainline) 2.6.36 where the workaround doesn't work (i.e. the compilation flag seems to be ignored. Therefore I was wondering if I should just replace compat_alloc_user_space with arch_compat_alloc_user_space when dealing with 2.6.36 kernels (I can do this with DKMS)
<tseliot> smb: make.sh.log: http://pastebin.ubuntu.com/499734/
<smb> tseliot, That seems to use a slightly different approach. Is the code in fglrx expecting COMPAT_ALLOC_USER_SPACE being a macro?
<tseliot> smb: make.sh sets COMPAT_ALLOC_USER_SPACE to either of the compat_alloc_ functions and then passes it as a flag (MODFLAGS). Then the C file calls COMPAT_ALLOC_USER_SPACE(size)
<smb> tseliot, I would be a bit careful with the wholesale replacement. You never know against which 2.6.36 you may be compiling against and -rc4 and earlier are different. 
<tseliot> yes, that's why I asked
<smb> The error sounds like something generally goes wrong with the definition
<smb> and COMPAT_ALLOC_USER_SPACE is not replaced at all
<tseliot> smb: make.sh http://pastebin.ubuntu.com/499736/
 * tseliot nods
<tseliot> smb: the weird thing is that the same fix works with 2.6.35
<smb> tseliot, This is quite odd. I'd probably try to modify the Makefile in the subdir to pass V=1, to see what gets passed in
<tseliot> ok, thanks
<smb> It feels like the flag might not get repeatedly get set in there
<tseliot> smb: I definitely don't see it there: http://pastebin.ubuntu.com/499750/
<smb> No if it had been correctly passed on it would be somewhere around PAGE_ATTR_FIX
<smb> Have you checked the module Makefile? At least thea PAGE_ATTR_FIX was set again there for the kernel compile
<tseliot> smb: wait a second, PAGE_ATTR_FIX is being passed while COMPAT_ALLOC_USER_SPACE is not: http://pastebin.ubuntu.com/499752/
<tseliot> but why does this work with 2.6.35???
<smb> tseliot, i bet if you add something there it works. I am as puzzled as you may be.
<smb> It should not work there either
<tseliot> smb: yes, that's what I'm trying now
<ogasawara> doko: I'll send email to the team asking about the binary demotions of kernel packages.  most of the guys are in taipei at the moment.
<doko> ogasawara: thanks!
<tseliot> smb: something's definitely wrong. I doesn't fail now but COMPAT_ALLOC_USER_SPACE is set to nothing http://pastebin.ubuntu.com/499762/
<tseliot> smb: and I added a -DCOMPAT_ALLOC_USER_SPACE=$(COMPAT_ALLOC_USER_SPACE) in the makefile
<tseliot> O_o
<smb> I am not sure, but make.sh currently adds it to MODULE_FLAGS which I am not sure about how this gets passed on
<smb> I think in the code i saw it was passed on differently
<tseliot> yes, I really should ask AMD how they pass MODULE_FLAGS
<smb> tseliot, Maybe its something that used to be in older kernels... let me check something
<tseliot> oh
<tseliot> that would explain it
<smb> tseliot, Seems AMD got hit by progress again "kbuild: allow assignment to {A,C,LD}FLAGS_MODULE on the command line" in 2.6.36-rc1 replaced MODFLAGS with something new
<smb> "Note2: MODFLAGS was not documented and is dropped
<smb>     without any notice. I do not expect much/any breakage
<smb>     from this."
<tseliot> smb: d'oh
<tseliot> smb: do you have a link to the commit?
<smb> tseliot, 6588169d516560f68672e2928680b71c647b7806 (a second I try to give you a link)
<smb> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6588169d516560f68672e2928680b71c647b7806
<tseliot> thanks
<tseliot> I guess a new workaround will be required for 2.6.36. The one we adopted in lucid and in other releases should work
<smb> Yeah, generally EXTRA_CFLAGS is probably longer supported. Even if not as specific as CFLAGS_MODULE now. But its an out of tree module anyway
<tseliot> smb: ok, so I guess that any other flag that relied on MODFLAGS will have to be passed in a different way (not only the one we need)
<smb> right
<scottie> #freeipmi
<tseliot> smb: thanks for your help
<smb> tseliot, np. At least the riddle is solved and we can sleep over the weekend. :)
<tseliot> smb: hehe
<tseliot> smb: replacing MODFLAGS with CFLAGS_MODULE did it. Now I can sleep at night :D
<smb> :D
<mpoirier> ogasawara: mumble ?
<ogasawara> mpoirier: sure, just a sec
<david506> Once an LTS is released, will changes by made to the kernel that would require me to recompile drivers ( modules ) that were compiled against an earlier kernel in the same LTS version ?
<smb> david506, yes, there can be changes that require to re-compile (everytime the abi number changes)
<david506> Why would the ABI number change ?
<david506> ok, so if the ABI number changes, can I recompile that same source with no modifications ?
<ogasawara> jjohansen: just curious if you have the AppArmor patches pushed to a branch that I can look at.  I just need to write up a proposal for the 0-day kernel upload and wanted to get the specific details for your patches.
<jjohansen> ogasawara: not pushed to a branch but I can send you them
<jjohansen> both are 1 line
<jjohansen> only one is needed 0 day
<ogasawara> jjohansen: ok cool, just send me the one we need for 0 day
<jjohansen> okay
<smb> david506, because some functions or structure have changed. Usually yes. There can be rare changes that make the compile fail. But this should be really rare. The only reason it happened now once was for non-gpl modules
<ogasawara> jjohansen: you can even just pastebin it if you want
<smb> david506, So I would rather say, there should be no need to change the source of the module in 99.9% of the cases
<david506> but a severe security issue might warrant that .1% ?
<erUSUL> FWIW this was david506 original question in #ubuntu 18:11 < david506> I have a hardware provider who might agree to run a repository for their specialized software or have  their software included in the LTS versions, but I need to know what changes normally happen in the  kernel in LTS versions.
<erUSUL> david506: hope you do not mind
<smb> david506, correct
<david506> :)
<david506> I was trying to make the question more clear :d
<david506> If you could give me links to any relevant web pages to my questions, I would be most happy to read them
<smb> I would not know of a page where this written down in detail. Not that you probably could. It also depends on what you modules rely on. If it is only using more general kernel interfaces change will less likely happen than if someone tries to hook to a very specific module
<bjf> jjohansen, when you have some time, i have a question (no hurry)
<jjohansen> bjf: shoot
<bjf> jjohansen, i'm rebasing Lucid ec2 and ran into a conflict
<jjohansen> bjf: big surprise
<bjf> jjohansen, actually, it went pretty smooth, just a couple of minor conflicts and only one that i have a question about
<jjohansen> okay
<bjf> jjohansen, sorry wife interrupt
<jjohansen> np
<jjohansen> I have server team interrupts
<bjf> jjohansen, can you look at the diff of kernel/irq/manage.c between the master branch and the ec2 branch?
<bjf> jjohansen, to resolve the conflict, i went with the ec2 version
<jjohansen> bjf sure where is it
<bjf> jjohansen, my public ubuntu-lucid has it
<bjf> jjohansen, actually, let me just pastebin it
<bjf> jjohansen, http://pastebin.ubuntu.com/499829/
<bjf> jjohansen, i went with this patch
<jjohansen> bjf what did the upstream patch look like
 * jjohansen is stunned the conflict was this small
<jjohansen> bjf: so I redid the abi check following your guide, it worked fine when I built on tangerine but failed again when I pushed to the ppa
<jjohansen> ogasawara: how much do you know of kernel ppa builds, and abi checks?
<ogasawara> jjohansen: I know a bit about the abi checks, the kernel ppa builds though might suffer from bug 645653
<ubot2> Launchpad bug 645653 in linux (Ubuntu) "kernel is unbuildably large (affects: 1) (heat: 8)" [High,Confirmed] https://launchpad.net/bugs/645653
<jjohansen> hrmm, I suspect it is different as the abi check comes after the build and the failure log clearly shows its failing in the abi check
<ogasawara> jjohansen: have a pointer to the build log
<ogasawara> ?
<jjohansen> this is on a lucid kernel btw
<jjohansen> http://launchpadlibrarian.net/56380500/buildlog_ubuntu-lucid-amd64.linux_2.6.32-27.47~debugmpath_FAILEDTOBUILD.txt.gz
<ogasawara> jjohansen: this looks a little weird... you're buildling version 2.6.32-27.47~debugmpath but it's looking for ABI 2.6.32-26.45?  I'd think it'd look for 2.6.32-26.46
<ogasawara> jjohansen: does debian.master/abi/2.6.32-26.45/amd64/server actually exist in your tree?
<ogasawara> jjohansen: and did it get committed?
<jjohansen> ogasawara: no, it got moved to 2.6.32-27.47
<jjohansen> ogasawara: basically I skipped up a couple abi drivers for testing the mptsas and skipped .26 entirely
<ogasawara> jjohansen: ah, so you really need the previous ABI directory to exist for the current build to check against
<smb> -26 ... -27 how far in the future is htis?
<jjohansen> smb: its not, its something that will die
<jjohansen> smb: its for testing only
<ogasawara> jjohansen: but you mentioned it built ok on tangerine?
<ogasawara> jjohansen: which is odd
<jjohansen> yes, that is what puzzels me
<smb> jjohansen, Not sure you are aware but as long as you would make your tree so the previous version remains what it was you only need to bump the abi once
<jjohansen> smb: right, I recognize that it only needs to be bumped once
<smb> jjohansen, Did you clean completely between the builds?
<ogasawara> jjohansen: mind if I look at your tree on tangerine?
<smb> on tangerine
<jjohansen> but I noticed a stable update bump the abi during testing and figured I would get ahead of that one a wee bit
<jjohansen> ogasawara: hrmm, you could but its changed since then
<jjohansen> basically, it worked and I pushed and moved on to the next thing I wanted to test
<jjohansen> smb: I did an fdr clean
<jjohansen> I followed the abi doc as close as I could
<jjohansen> I had a couple of odd things happen like
<smb> jjohansen, So if you look at you tree and do a fdr printenv, it would tell you what it considers as the previous release. Then the tree needs an abi dir for that
<jjohansen> fakeroot debian/rules insertchanges doesn't insert changes for me
<smb> Hm, an fdr clean would remove any generated abi i believe
<ogasawara> jjohansen: ah, so on tangerine ubuntu-lucid/debian.master/abi/2.6.32-26.45 exists (but is not committed)
<jjohansen> smb: okay, so that may be it, if it is looking for a previous abi and I skipped 2 would it be smart enough to figure that out
<smb> insertchanges relies on the previous version being commited with a message that is formatted "UBUNTU: Ubuntu-..."
<ogasawara> jjohansen: explains why it passes on tangerine
<jjohansen> ogasawara: really?  weird okay that explains it then
<jjohansen> alright I take another stab at this.  /me wonders why that one exists
<ogasawara> jjohansen: well according to git status it's not committed in that tree on tangerine
<smb> jjohansen, It gets created on compile. Though I had been thinking clean would remove it
<ogasawara> jjohansen: not sure if you used that tree or another to build the package to upload
<smb> but maybe that is not ture
<jjohansen> ogasawara: yeah no, it wouldn't be.  I git am'd the patches from my local tree
<jjohansen> so, it doesn't exist locally, on tangerine I built the latest pull, then branched to an earlier state and applied my patches as I didn't want any extra changes in while testing.
 * jjohansen doesn't get why an fdr clean didn't clean up abi cruft is all
<jjohansen> thanks guys, at least it makes sense now
<ogasawara> jjohansen: yah, I usually just to a git clean -f -d since fdr clean doesn't remove everything (and actually generates some files)
<jjohansen> yeah
<smb> or even git clean -d -f -x
<ogasawara> smb: heh, I like that you pass your flags alphabetically
<smb> ogasawara, And I did not even try to. :)
<ogasawara> haha
<smb> Well, before I order all letters I type alphabetically... Its Friday and past 7pm, I think I be gone
<ogasawara> smb: yes, it's well past beer:30 for you
<bjf> smb, which patches did you want on ti-omap?
<sconklin>  so, kamal taught something great yesterday - meld understands git repos. If you didn't know this, check it out. "meld ./" works in a git repo and shows your changed files.
<jjohansen> sweet
<achiang> what is meld?
<kamal> sweet GUI diff utility...   apt-get install meld   (you'll like it :-)
<bjf> achiang, it's like taking a flame-thrower to your code :-)
<achiang> kamal: are you saying that the output of diff -Nurp is insufficient? ;)
<achiang> j/k, the tool looks pretty cool
<kamal> achiang: far be it from me to ever cast aspersions upon the glory of diff -- just another tool^Wflamethrower for the toolbox :-)
<achiang> fwiw, when i need to see visual differences, i use gvimdiff
<achiang> but maybe i'll try meld next time
 * ogasawara lunch
 * jjohansen lunch
<th1> hi
<th1> I'm building a custom kernel with patches to support pv-hvm for better performance under XenClient. how do I go about creating a new flavour like there is the -pae one currently?
<th1> I followed the instructions on https://help.ubuntu.com/community/Kernel/Compile for how to get the sources and patched them from there
<th1> sorry after reading http://blog.avirtualhome.com/2010/05/05/how-to-compile-a-ubuntu-lucid-kernel/ I'm unstuck..
#ubuntu-kernel 2010-09-25
<u456503> hi all,
<u456503> where can I ask about: dpkg-gencontrol: error: package linux-image-2.6.36-rc5-custom+ not in control info
<u456503_> hi all, anybody here ?
<u456503_> just test this: https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
<u456503_> where can I ask about: dpkg-gencontrol: error: package linux-image-2.6.36-rc5-custom+ not in control info
#ubuntu-kernel 2010-09-26
<yofel> are there any checksums available for http://kernel.ubuntu.com/~kernel-ppa/testing/ ? (or zsync, rsync, whatever...)
<AbhiJit> hello
<AbhiJit> how to know the latest kernel version in lucid?
<AbhiJit> 'how to'?
<AbhiJit> hello?
<yofel> a) patience please b) linux-image-generic in lucid-updates is 2.6.32.24.25 so it should be 2.6.32-24 -proposed has 32-25
<AbhiJit> anyone alive here?
#ubuntu-kernel 2011-09-19
<bullgard4> How is the 'machine hardware name' defined that the command '~$ uname -m' outputs? '~$ info coreutils 'uname invocation' returns the additional information: "sometimes called the hardware class or hardware type" and does not give a definition either.
<jk-> bullgard4: it's defined when the kernel is built
<bullgard4> jk-: Right. And what is the definiton for 'machine hardware name' in this situation?
<bullgard4> jk-: Right. And what is the definiton for the term 'machine hardware name' in this situation?
<jk-> bullgard4: it's a string describing the system architecture
<jk-> x86_64 / ix86 / powerpc / arm / etc
<bullgard4> jk-: Where does '~$ uname -m' take this "string describing the system architecture" information from?
<jk-> bullgard4: from the kernel, through the 'uname' syscall.
<bullgard4> jk-: Thank you very much for your help.
<diwic> good morning
<diwic> since I upgraded to oneiric on my development machine, I'm occasionally having network troubles. (i e, this machine can successfully connect anywhere, whereas the other one gets things as "interrupted connection" or "connection timed out" errors, even though they are connected to the same router). It's happening right now, should I attempt some kind of debugging before trying to resolve the problem?
<diwic> timeout - I shutdown/rebooted the faulty computer which resolved the problem
 * smb regretfully stomps in
<ppisati> morning *
 * ppisati go get a lot of coffee...
 * smb already trying that for a while now...
 * smb watches apw's cve frobber produce incoming mail
<ppisati> smb: ah, welcome back Stefan! :)
<smb> ppisati, Thanks, though it probably needs a bit till I am really back (iow not half asleep)
 * apw giggles ...
<jk-> hey apw, ppisati, smb 
<apw> jk-, moin ... how you doing
<jk-> apw: yeah, not too bad. yourself?
<apw> jk-, tired as heck still :/  i hate travel
<apw> smb, http://people.canonical.com/~ubuntu-security/cve/2011/CVE-2011-1747.html
<ubot2> apw: The agp subsystem in the Linux kernel 2.6.38.5 and earlier does not properly restrict memory allocation by the (1) AGPIOC_RESERVE and (2) AGPIOC_ALLOCATE ioctls, which allows local users to cause a denial of service (memory consumption) by making many calls to these ioctls. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1747)
<apw> http://people.canonical.com/~ubuntu-security/cve/2011/CVE-2011-1576.html
<ubot2> apw: Red Hat Enterprise Virtualization (RHEV) Hypervisor allows remote attackers to cause a denial of service via unspecified vectors that cause the napi_reuse_skb function to be used on VLAN packets, which triggers (1) a memory leak or (2) memory corruption, a different vulnerability than CVE-2011-1478. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1576)
<jk-> apw: still? argh. I seemed to reset okay this time.
<apw> thats the one
<apw> jk-, yeah feels like that
<apw> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/852653/comments/2
<ubot2> Ubuntu bug 852653 in linux "BUG: unable to handle kernel NULL pointer dereference at (null)" [Undecided,Confirmed]
<diwic> apw, have you heard anything about the downtime of kernel.org, as of when they expect to be back online?
<apw> diwic, not a damn thing.  it has been a long time now
<diwic> ok
<ppisati> lamont: how did the builder reacted to the new kernel?
<apw> smb, the virtual-extra stuff got approved and applied, so you might want to review your blocked WI and see if it can be closed or not
<lamont> ppisati: the new kernel did nothing for the build issue, which was root-caused to binfmt-support being a build-dep. Other than not fixing the unrelated problem (which _would_ be worrisome), the machine is doing just fine with the new kernel.  I support this kernel for SRUdom
<ppisati> lamont: cool, thanks
<ppisati> lamont: uhm
<ppisati> lamont: nothing, nevermind
<ppisati> i filled a bug against linux-omap, but LP keeps saying it's against linux-meta
<ppisati> bug 853783
<ubot2> Launchpad bug 853783 in linux-meta "vfat support=m: chicken egg situation while removing the running kernel" [Undecided,New] https://launchpad.net/bugs/853783
<lamont> maybe it needs an "also affects" and then a close of the linux-meta one... that's what you get for splitting the metapackage out into realness. :-p
<ppisati> because it was linux-ti-omap...
<ppisati> damn...
<smb> apw, Yes I was just thinking the same this morning. I would say I can close it as the extra package removes the need for better selection of what is included in the main one.
<lamont> ppisati: in fact, if you want to hand me a source package with a ~ version number so that the natty SRU wins, I might be highly interested in that
<apw> smb, yeah just make a note in the Results section of the spec and move it Done i say
<smb> apw, Ok, may have made the note in the wrong place then (in the blueprint) but otherwise its done.
<smb> apw, Hm, maybe not. Since that was only a collection of open ends, I think there was no specific spec for that. So I hope the whiteboard is enough
<apw> will have to be indeed smb
 * ogasawara back in 20
<ppisati> lamont: a dpkg -b <natty kernel dir> has created a .dsc and a huge .tar.gz (~760MB)
<ppisati> doh!
<smb> ppisati, Could it be you are missing the appropriate orig.tar.gz?
<lamont> ppisati: and here I was hoping you had a better handle on the whole packaging process than I did.... I suspect that it wants a tar.orig.gz from the archive or so
<ppisati> dunno
<ppisati> actually i did a dpkg-source -b <dir>
<ppisati> to get the src pkg
<ppisati> lamont: what if i create a branch on zinc, tag it and you get from there the src?
<lamont> sure
<ppisati> perfect
<smb> ppisati, Oh right should be a binary package which has nothing to do with orig.tar.gz... Hm, that sounds then a bit like packing up the unstripped versions... 
 * smb wonders how big the packages in the archive are...
<ppisati> lamont: git://kernel.ubuntu.com/ppisati/ubuntu-natty.git omap4_natty_ehci
<lamont> ta
<ppisati> lamont: so, in the end the problem was in userland, right?
<ppisati> lamont: did you retry with the oneiric kernel?
<lamont> ppisati: the problem was isolated to trying to umount /proc before umounting /proc/foo
<lamont> which is 100% userland
<ppisati> ah ok
<ppisati> got it
<cr3> is it true to assume that unless a child device path under sysfs specifies a driver explicitly then it necessarily uses the driver from a parent device path? ie, /sys//devices/pci0000:00/0000:00:1c.1/0000:03:00.0/ieee80211/phy0/rfkill0 probably uses the same driver as /sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0
<cr3> ... where driver information is retrieved from the DRIVER entry in udev
<tgardner> dmesg
<tgardner> -EWRONGWINDOW
<smb> herton, Heck if I could remember. When I think the changes of a rebase have no effect on a topic branch, I set the workflow task to invalid, is that right?
<herton> smb: yep, that's ok
<smb> herton, Ok, thanks. 
<herton> smb: you can use check-release-tracking-bugs --invalidate --bug=<number> for that
<smb> herton, Ah, ok there was something more to it then. I remember now. That also changes something else to please ignore...
<herton> yes, the bug title, the cmd line tools does in one go everything so it's easier
<herton> *tool
<smb> herton, right. done now. and hopefully one day I *will* remember the tool...
 * herton -> lunch
<tgardner> ogasawara, 'UBUNTU: SAUCE: Unregister input device only if it is registered' has the wrong bug number in the commit log
<ogasawara> tgardner: bah, really? 
<tgardner> ogasawara, would I lie to you ? :)
<ogasawara> bug 839238
<ubot2> Launchpad bug 839238 in linux "[Dell Vostro 1450] System halted when unit is idle for a while." [Medium,In progress] https://launchpad.net/bugs/839238
<tgardner> ogasawara, I didn't look too close, but that doesn't seem related.
<cking> again?
<cking> oops, wrong window
<smb> There seems to be a united pattern somewehere
<bdmurray> ogasawara: I'll prepare the kerneloops upload disabling today right?
<cking> just losing focus
<ogasawara> bdmurray: yep, that'd be great.  thanks.
 * tgardner --> lunch
<bdmurray> bjf: what log files is bug 728034 missing?
<ubot2> Launchpad bug 728034 in linux "[Dell DXP051, SigmaTel STAC9221 A1, Green Headphone Out, Front] Playback problem" [Undecided,Incomplete] https://launchpad.net/bugs/728034
<bjf> bdmurray, looking
<bjf> bdmurray, lspci is missing
<bjf> bdmurray, not saying it's right, but that's what caused the spam
<bdmurray> bjf: okay I reported it using the audio symptom so either that or the criteria should change
<bjf> bdmurray, i did think that we got lspci for everything though
<cking> curses pulse audio
<bjf> apw, that system just arrived
<apw> bjf, awsome, two boxes yes
<bjf> apw, ack
<apw> bjf, alledgedly the small one is the upgrade for the large one, have fun :)
<bjf> apw, it seems pretty heavy for an upgrade, will have to see
<bjf> apw, no wonder, the "upgrade kit" is a new mainboard, a 1200 watt power supply and a new heatsink
<apw> bjf, yeah a 1.2kw powersupply
 * apw thinks he has had enough for one day ... see you tommorrow
<komputes> Does anyone know where I can find an updated list of kernel parameters like this: http://www.cyberciti.biz/howto/question/static/linux-kernel-parameters.php
<mjg59> Documents/kernel-parameters.txt in the kernel source
<komputes> mjg59: is there a way to see that using a web browser (a URL I can use to always see the latest)?
<Sarvatt> https://github.com/torvalds/linux/blob/master/Documentation/kernel-parameters.txt
<komputes> http://www.kernel.org/doc/Documentation/kernel-parameters.txt :(
<komputes> thanks Sarvatt 
<komputes> when using the 'debug' kernel parameter is it used in this manner 'debug=1' (debugging on) 'debug=0' (debugging off) OR doe it use log levels 'debug=[1-7]'. Secondly, where are these (verbose) debug logs to be found?
<komputes> I'm having a hard time understanding what "iommu=off" actually does.
 * jjohansen -> lunch
<dupondje> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/703180 any chance this could be fixed before final?
<ubot2> Ubuntu bug 703180 in linux "SD card reader inaccessible without pci bus rescan" [Undecided,Confirmed]
<jjohansen> dupondje: before release?  possible but unlikely.  The oneiric kernel is now in kernel freeze so all patches have to go through the SRU process.
#ubuntu-kernel 2011-09-20
<smb> Morning .*
 * apw groans
 * smb prepares coffee infusions
<hrw> hi
<hrw> is ubuntu kernel tree git bisectable?
<hrw> cause with 3.0.0-10 my router fans are on 4500rpm instead of <2000rpm like it was on 3.0-1
<diwic> hrw, https://wiki.ubuntu.com/Kernel/KernelBisection - or flirt with apw to make test kernels for you ;-)
<jjohansen> hrw: yes and no
<hrw> will read
<jjohansen> hrw: it is bisectable from the import point forward, otherwise you need to bisect against upstream with the ubuntu patches thrown on top
<hrw> jjohansen: in other words: ubuntu kernel tree is rebased often?
<smb> During development: yes
<jjohansen> hrw: yes its rebased up until the kernel freeze (5 days ago)
<hrw> ok, will stay then with 3.1.0-rc6 self built instead probably
<hrw> or will bisect upstream clean kernel
<smb> Not, sure, are there probably 3.0.x mainline builds as well to compare against?
<hrw> I am fine with bisecting on my own
<smb> Sure, I find them still useful for narrowing the range for bisection quickly
<hrw> right - http://kernel.ubuntu.com/~kernel-ppa/mainline/ exists ;D
<hrw> will have to connect monitor/keyboard to machine for grub selection 
<hrw> hi again
<hrw> 3.0.4 mainline == 1917rpm fan. 3.0.4 ubuntu = 4500 rpm
<apw> hrw, an interesting result indeed
<hrw> d510mo board (atom d510)
<apw> hrw and is there any cpu load when running ubuntu kernel?
<hrw> apw: load <1.0
<apw> comparible to mainline ?
<hrw> apw: same load - routing packets + irssi session
<apw> and the reported load is comparible
<hrw> yes
<apw> clearly the machine is doing more, else it wouldn't be so very hot
<hrw> it had 4500rpm 23Â°C
<apw> as we can assume the environmental load is the same
<hrw> now it has 2000rpm 46Â°C which is also fine
<apw> i'd be interested in comparing powertop output on both
<apw> looking at wakeups and also looking at c-state residency and frequency state residency
<hrw> 1.13/oneiric will be fine?
<apw> if there is nothing obvious then a bisect through the the ubuntu delta will be the next logical step
<apw> 1.13 has most of what you want yes
<smb> D510 has no power management afaik but the wakeups per second might be interesting
<hrw> Wakeups-from-idle per second : 191,1    interval: 15,0s
<hrw> Top causes for wakeups: 31,0% (204,1)   [ath9k] <interrupt>
<hrw> this is router/accesspoint
<apw> its is the comparison from one to the other that is interesting so collect them all on both
<smb> hows that comparing between mainline and the ubuntu kernel
<hrw> I will reboot to ubuntu and collect 'powertop -d' output
<hrw> brb
<hrw> hi
<hrw> 3.0.0-11-server and also 1757rpm 49Â°C
<hrw> http://krzys.juszkiewicz.com.pl/~hrw/powertop/ has powertop dumps
<apw> hrw, so which kernel was bad ?
<hrw> 3.0.0-8 probably
<hrw> if you have it somewhere (amd64 -server) then I can check
<apw> hrw if its working fine and in line with mainline in the -11 kernel then i think we are all happy
<apw> hrw, though 3.0.0-8.11 was based on 3.0.1 mainline not 3.0.4 ?
<apw> https://launchpad.net/ubuntu/oneiric/+source/linux/3.0.0-8.11
<apw> hrw, you can get old binaries from the launchpad librarian for example as above
<hrw> I am fine with just leaving it as it is ;)
 * ogasawara back in 20
<apw> smb, do any of your machines have real serial ports on them ?
<smb> apw, sure
<apw> smb, that you use as consoles ?
<smb> apw, not directly. I may do. but normally use sol
<apw> smb, sol appears as a serial console to the kernel anyhow doesn't it ?
<smb> apw, correct. on the server its just a serial port
<smb> to linux
<smb> apw, So as long as it is not the real hw part of the cable connection my server is already using the serial console for boot
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<tgardner> apw, kernel.org is resolving again. maybe some of the git repos will begin to reappear
<apw> tgardner, looks the same to me, all 'down for maint' and git.k.o is non-existant
<tgardner> apw, uh, yep. was just coming to the same conclusion
<BenC> tgardner: Does oneiric's udev require a minimum kernel level?
<tgardner> BenC, not to my knowledge, though I've been more concerned with backporting recent kernels to Lucid.
<BenC> udevd[1162]: unable to receive ctrl connection: Function not implemented
<BenC> I get flooded with that if I run oneiric's udev on a 2.6.34 kernel, but backing udev down to natty's version makes it all happy
<tgardner> BenC, hmm, I haven't the faintest idea. 
<BenC> Ok, thanks
<BenC> tgardner:   - Some architectures might need a later kernel, that supports accept4(), or need to backport the accept4() syscall wiring in the kernel.
<BenC> tgardner: usage of accept4() is the cause
<BenC> just in case you ever hear about it again
<tgardner> BenC, ok. the only arches that I care about for LTS backports (so far) are x86'en
<BenC> I wasn't suggesting you backport anything, just trying to track it down :)
<tgardner> BenC, understood.
<bjf> ##
<bjf> ## Kernel team meeting in one hour
<bjf> ##
<smb> bjf, You may already know (I wasn't around last week) but the meeting-bot now seems to want the name of the meeting as an argument to startmeeting
<bjf> smb, the bot can screw itself
<smb> bjf, Won't mind. Just thought I relate to you how the other meeting succeded in convincing it to do something
<bjf> ##
<bjf> ## Meeting starting now
<bjf> ##
<smb> Hm, seems to work as good without. Only difference is that the topic is screwed more or less. *shrug*
<herton> ppisati: can you rebase git://kernel.ubuntu.com/ppisati/ubuntu-maverick.git ti-omap4? it got two more patches today, doesn't pull clean
<ppisati> herton: ok, i'll do
<tgardner> apw, we're using overlayfs for oneiric live CDs now, right ?
<ppisati> herton: don
<ppisati> e
<apw> tgardner, yes
 * tgardner --> lunch
<gnomefreak> since *xorg.conf no longer exists how to i drop back to default ati drivers? removeing fglrx doesnt help
<gnomefreak> i was told kernel takes over and sets drivers since that file no longer exists
<apw> gnomefreak, that is normally the plan, check for radeon being blacklisted in /etc/modprobe.d
<apw> though are you sure there isn't an xorg.conf selecting fgrlx when installed, i thought there was
<gnomefreak> apw: i cant find it in /etc/X11
<apw> gnomefreak, worth asking on #ubuntu-x, they should know
<gnomefreak> there is a fglrx.conf in /etc/modeprobe.d
<chrisccoulson> is it normal for modprobe to take this long on startup - https://launchpadlibrarian.net/80443468/farnsworth-oneiric-20110920-9.png?
<chrisccoulson> seb128 doesn't see the same issue on his laptop, and we have quite similar hardware - http://people.canonical.com/~seb128/seb-e6410-oneiric-20110920-9.png
<gnomefreak> apw: thanks ill ask them when i get back. thanks you for the help
 * jjohansen -> lunch
<Kano> hi apw 
#ubuntu-kernel 2011-09-21
<apw> mornin
<ppisati> morning *
<jk-> hey ppisati 
<smb> morning .+
<jk-> ooh, it's a fnmatch vs. regex competition
<smb> not competition really... :-P
<mooky68> Sorry for asking again but I have observed a memory leak issue with the 2.6.31-rt kernel on Lucid: /proc/slabinfo shows a growing count of mm_struct after a resume from hibernate (I didn't reproduced the issue with the corresponding 2.6.32 generic kernel or with a vanilla RT kernel). Is this a known issue ? Should I open a bug report on launchpad ? Thank you
<Kano> apw: how about adding the 3 commints for dvb which should be in the stable kernel as bugfix anyway?
<apw> which are those then?
<Kano> its even in launchpad, a bit hidden by a bugs.debian link
<smb> telling a bug number _may_ help
<Kano> #838130
<apw> bug #838130
<ubot2> Launchpad bug 838130 in linux "Kernel 3.0 breaks DVB-T (ISDB-Tb) in DiBcom 8000" [Undecided,Confirmed] https://launchpad.net/bugs/838130
<Kano> http://git.linuxtv.org/pb/media_tree.git/shortlog/refs/heads/for_v3.0
<Kano> 3 patches basically, i only knew of 2 first, added am and they worked. but most likely it would be best to add all 3
<Kano> they are in another position too
<Kano> i fetched it from
<Kano> http://git.linuxtv.org/media_tree.git/patch/79fcce3230b140f7675f8529ee53fe2f9644f902
<Kano> http://git.linuxtv.org/media_tree.git/patch/bff469f4167fdabfe15294f375577d7eadbaa1bb
<Kano> but the position should not matter
<Kano> otherwise same dvb-t devices do not work
<Kano> did somebody try btrfs with -11.18 kernel, somehow it seems to be very slow
<tjaalton> oh, I just bought the same dvb tuner
<tjaalton> well, the used module is the same, hauppauge nova-td
<Kano> and it worked with 3.0?
<tjaalton> bought it yesterday, haven't really tested it yet
<Kano> good idea to test, .38 should do
<Kano> 3.0 without patch most likely not
<tjaalton> but apparently vlc supports dvb?
<Kano> never used vlc for that
<Kano> only kaffeine, vlc, tvheadend
<Kano> err vdr not vlc
<tjaalton> trying to forward the device to a kvm vdr instance, but it doesn't see the device
<Kano> not my problem
<tjaalton> was i suggesting that?
<jwi> tgardner: for the ENERGY_PERF_BIAS patch, you might want to consider picking 17edf2d79f1ea6dfdb4c444801d928953b9f98d6 as well
<tgardner> jwi, good catch.
<jwi> maverick too, when 2.6.35.14 lands there
<tgardner> jwi, I'll work on Maverick once its determined that these patches really have an impact.
<smb> tgardner, Hm, was that the right thread to re: on?
<tgardner> smb, shit
<tgardner> smb, since the original PERF BIAS patch has already been acked, I'm just gonna apply the correction.
<smb> tgardner, It looks safe enough to be ok even if it wouldn't... You could add my ack there...
<tgardner> smb, done
 * apw might have found .3s to shave off the kernel boot time
<smb> apw, serial init?
<apw> heh oddly not, acpi_init, over halving it in my rather unscientific testing
<smb> uhm... acpi not very scientific, just this uneasy feeling of speeding that up...
<apw> getting my test platform back to around the 0.98s to userspace
<apw> smb, heh the speedup is all in kernel map handling
<smb> ok, that sounds less worrying
<apw> yeah its poor-mans RCU handling which is fine unless you are racing with a cpu hog, like unpacking the initramfs
<bjf> apw, have you looked at the boot-speed reports i've generated ?
<bjf> apw, if so, are they useful ?
<jwi> tgardner: what i was trying to say is: 2.6.35.14 has the initial PERF_BIAS patch you just added, but it's missing the print fix. so when 2.6.35.14 lands in maverick, it will need the same fix up.
<tgardner> jwi, 2.6.35.14 hasn't been pushed yet, has it? if not, then I ought to bug Andi to add the second patch.
<jwi> tgardner: http://lkml.org/lkml/2011/8/1/324 - pushed about 50 days ago :)
<tgardner> jwi, looks like the last stable update we pulled was .13
<tgardner> q
 * ogasawara back in 20
<cr3> in the output of dmidecode, under the Processor section, is the ID attribute expected to be unique across processors?
<CluelessPerson> hi everyone
<CluelessPerson> Hi
<CluelessPerson> I get an error sometimes when I reboot my server
<CluelessPerson> init: ureadahead-other main process (712) terminated with status 4
<CluelessPerson> [   103.509461] [drm:pch_irq_handler] *ERROR* PCH poison interrupt
<CluelessPerson> after doing some sort of check disk or whatever
<CluelessPerson> it prevents my server from booting, and so is problematic
<CluelessPerson> hello?
<tgardner> apw, have you noticed that the changelog version numbers for the daily builds of LBM and linux-meta in pre-proposed are not correct? I think there should be tilde in it.
<apw> tgardner, actually i think they are as intended, the linux-meta packages are alway built off of the closed tip, but they actually have just the abi incremented
<apw> tgardner, thus they are always less than any official bump would be, whether ~ or not
<jbicha> the Oneiric kernel is actually 3.0.4, right? just wondering if our version number should reflect that
<apw> jbicha, it doesn't do that in order to prevent abui bumps unecesarily
<apw> jbicha, typically our version numbers there have not reflected the stable number, they are always 2.6.38-x
<apw> jbicha, and these would have been just 3.0-x if userspace wasn't so utterly broken in soooo many ways
<jbicha> oh ok, it's the Linux 3.0 problem, thanks!
<apw> CluelessPerson, it sounds like that error implies the graphics h/w got all upset about something, an error indication of some sort.  what though is not specified.  only ever seen it on resume in the past
<CluelessPerson> apw,  only happens during check disk or checking the file systems mounts
<CluelessPerson> apw, appeared immediately after adding automounts to fstab
<apw> CluelessPerson, that is odd indeed as the interrupt definatly comes from the display adapter
<apw> CluelessPerson, and the other error should just indicate ureadahead is not helping but should not trigger machine death
<apw> bjf, have you noticed the Launchpad Janitor has taken it upon itself to mark our bugs Confirmed, when they ahve more than one person affected
<apw> we may need to use Triaged instead when we have sufficient logs
 * apw calls it a day, i am not right
 * tgardner --> lunch
 * CluelessPerson is proud of himself.  He is learning. :D
<CluelessPerson> hrm, for some reason it won't start, but everything else functions correctly.
<CluelessPerson> AH, lol. no wonder.
<jbicha> x`/wc
<CluelessPerson> lol
<CluelessPerson> my changes are  being stupid
<CluelessPerson> hrm..
<CluelessPerson> For some reason the script isn't detecting the lock file in ramdisk.
<CluelessPerson> and so the server is starting, and the script isn't detecting it.
 * jjohansen -> lunch
<esoergel> I have a possible kernel regression (I'm told).  I'm running a clean install of Ubuntu 11.04 on a Thinkpad R400 purchased new in 2009.  The display freezes at random; I can't switch to console mode, I can't move the mouse, and any on-screen animations freeze.  This problem doesn't occur if I have Ubuntu 10.04 installed.  How should I file this bug? 
<sforshee> esoergel, start by running 'ubuntu-bug linux' in a terminal, that will take you through the process of filing the bug and attach some information about your hardware to the bug report
<esoergel> sforshee: thank you, can you think of any other tests or anything I should run to add to it?
<sforshee> esoergel, if you can manage to trigger the bug in console mode you might get some information printed to the screen that you could photograph and attach to the bug
<sforshee> otherwise you should get some guidance on what to do next after you file the bug
<esoergel> sforshee: okay, thanks, I'll file it
<bryceh> apw, lp #850772 is weird.  an intel gpu lockup on a system with i915 loaded but no Intel graphics card in sight.
<ubot2> Launchpad bug 850772 in xserver-xorg-video-intel "False GPU lockup EIR: 0x00000010 PGTBL_ER: 0x00000012" [Undecided,Incomplete] https://launchpad.net/bugs/850772
#ubuntu-kernel 2011-09-22
<kit_D> add #gst_ti
<mthaddon> howdy folks, I'm seeing some issues on a Thinkpad X220 (64 bit) with oneiric - occasional hangs and seeing "general protection fault" in dmesg as well as what looks like stack traces. I *think* I have a sandybridge processor, but not sure how I confirm, and what my options are if that's the case
<jjohansen> mthaddon: file a bug, using ubuntu-bug linux
<jjohansen> it will collect you information
<mthaddon> ok, thx
<mthaddon> filed bug#856257
<cking> apw, for bug 851141 you enabled the MTRR sanitizer by default - have we seen any negative issues from enabling this?  If not, should we consider enabling it for earlier releases as a SRU at some point?
<apw> bug #851141
<cking> somebody poke the bot
<apw> ubot2, OI
<ubot2> Factoid 'OI' not found
<apw> ubot2, bug #851141
<cking> its gone bug unaware
<apw> cking, no your bug is private
<apw> 2. install all updates (sudo apt-get update && sudo apt-get upgrade)
<apw> cking, this here really should be a dist-upgrade else you don't get the new packages you need installed
 * smb disonnects 
<smb> Luckily internet _still_ works... :-P
<apw> tgardner, you pulled wireless-crda into ubuntu didn't you ?  there seems to be two packages for it now, see discussion on #ubuntu-devel
<tgardner> apwsynced from upstream ?
<tgardner> apw ^
<tgardner> or debian
<apw> tgardner, i'd guess debian, package is call crda and we have wireless-crda as well
<tgardner> apw, lemme check it out. maybe we can drop wireless-crda
<apw> tgardner, version numbers wise we seem to have a much never version -- maybe
<tgardner> apw, it hasn't been updated since April
<apw> tgardner, ours of theirs
<tgardner> apw, theirs
<apw> i'd guess teh DB needs updating more often than that
<apw> though of course it just may not have been sync'd
<apw> tgardner, seems that version is the latest in debian, so they are not very active with it
<apw> tgardner, we didn't need it until lucid or later right ?  so perhaps they arn't really using it yet
<tgardner> apw, I'm wondering why we synced it without an explicit request.
<apw> tgardner, ahh it seems the regdb is in a separate package, which is in sync
<tgardner> apw, yes
<apw> so the combination may be as good as what we have
<apw> tgardner, yeah i suspect we autosync all of universe without intervention
<tgardner> apw, the issue when I packaged it for Lucid was that many of the build tools were not in main
<apw> the suggestion is that our package only varies slightly from the combination of those two.  something to consider merging i suspect
<tgardner> apw, functionally there should be no difference.
<apw> so perhaps we literally just want to flip the dependancy over
 * apw leaves it with tgardner :)
<realubot> I want to install kernel 2.6.39 in Ubuntu 11.04 but the kernel doesn't seem to be in the kernel PPA?
<realubot> How do I install the kernel without having to install it from a deb file?
<realubot> Kernel 2.6.39 is "missing" in this PPA: https://launchpad.net/~kernel-ppa/+archive/ppa
<realubot> Why?
<apw> that PPA never was the vehicle for those kinds of builds ?
<apw> that PPA is a staging ground for test builds and experiemental packages
<realubot> Ok.
<apw> why do you want 2.6.39 in the first place?  thats an odd version to want
<realubot> apw: Well. There is a bug in the 2.6.38 version sÃ¥ I thought it would be a great idea to upgrade just one step where I have red the bug shall be solved.
<realubot> *so
<tgardner> apw, bug #856421 deferred until P series
<ubot2> Launchpad bug 856421 in wireless-crda "wireless-crda duplicates functionality found in crda+wireless-regdb from Debian" [Undecided,In progress] https://launchpad.net/bugs/856421
<realubot> apw: This bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/734865
<ubot2> Ubuntu bug 734865 in linux "[STAGING] RT2860 Wireless will not authenticate and connect when on battery power." [Undecided,Incomplete]
<realubot> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/734865/comments/5
<realubot> "Thanks for confirming that kernel 2.6.39 fixes the issue."
<tgardner> realubot, use compat-wireless from linux-backports-modules
<apw> what he said
<apw> realubot, you are on natty right ... so to get the 2.6.39 wireless you'd want linux-backports-modules-cw-2.6.39-natty-generic
 * ogasawara back in 20
<realubot> apw: So the bug I linked will be solved using the linux-backports-modules-cw-2.6.39-natty-generic
<apw> realubot, it is highly likely that if a .39 kernel would solve your issue, and it is a wireless issue, then the backports there are likely to carry the same fix.  testing those before moving to unsupported packages is a good idea
<realubot> apw: Ok, thank you for all help. I'll try it out and see if that solves my wifi problem. Thanks!
 * tgardner -> lunch
 * jjohansen -> lunch
 * ogasawara lunch
<tgardner> :q
<philipballew>  whats a good way to blacklist a wifi driver from the kernel
<bryceh> philipballew, /etc/modprobe.d/blacklist.conf
<philipballew> bryceh, thanks!
#ubuntu-kernel 2011-09-23
<smb> Morning +*
<diwic> morning pqr s/p/s s/q/m /s/r/b
<diwic> hmm, that will actually replace the r in morning as well
<diwic> smb, anyway, I'm tracing down a 3.0 regression for a few HDAs and I believe I found the upstream commit that resolves the problem, but that patch is quite large. 
<diwic> smb, would you prefer a large upstream patch or something smaller that I crafted myself?
<smb> diwic, From the point of view of a stable maintainer probably rather something crafted with the note why that was done. 
<smb> It is just better to decide what something does that way. It is a bit of a gap between rather preferring upstream vs. I can understand it...
<diwic> smb, in this case I tend to agree
<diwic> smb, you can search for commit 3af9ee6b83 for reference
<diwic> should be in 3.1
<smb> diwic, Hm, yeah. Most of it looks not too bad actually. But the whole block in alc662_auto_fill_dac_nids looks a bit scary at least on the first glance
<diwic> smb, yeah, it's mainly the stuff in alc_auto_look_for_dac I need here
<diwic> smb, hmm, and actually that stuff is yet again rewritten in a later commit
<diwic> smb, better craft something then probably
<smb> diwic, It is always some tough decision. There have been bigger changes accepted in the past. Just then be prepared to get asked how well this was tested. It may make sense if you can say, there was just no other way to get this done and I did test it at least on the variety of hw I got that is affected.
<smb> Unfortunately when larger changes were done, they usually _had_ some hidden pitfalls in certain cases in them as well. Which tends to lower the acceptance of big chances again.
<diwic> smb, yeah, and tbh I'm a little afraid that would happen if we applied 3af9ee as is
<smb> diwic, If even you are afraid, that is a bad sign. :)
<jjohansen> gah! so I bisected my video problem, found the patch that broke it but, reverting it in newer kernels doesn't restore my display :(
<jjohansen> just my luck
<smb> Sounds like one of those days
<jjohansen> yeah
<smb> jjohansen, Still around?
<jjohansen> yep
<jjohansen> smb: ?
<smb> jjohansen, I wonder whether you could have a peek at that sru Tim sent around (about igb). I have that is-the-stove-really-out nagging feeling about spinlock without any diabling
<smb> If someone else would review and say it looks okish I just would ack it as well
<jjohansen> smb: sure
<jjohansen> urg, this is when I wish for my big monitor so I can run two instances of meld side by side
<jjohansen> smb: your right about the is-the-stove-really-out nagging feeling, I have it too.  I have the original up and this and am doing a full on proper comparison
<jjohansen> and eval
<smb> jjohansen, Ah ok. Yeah, somehow it feels to me that at least a spinlock_bh variant may be required
<jjohansen> hrmmm, that is a frightening thought :)
<smb> But its just that uneasy feeling I usually have about not turning off anything. Somehow I converted to use spinlock alone only if I had nesting... But that is maybe just overcautious
 * jjohansen wishes the original patch hadn't crammed 4 or 5 different things into it
<jjohansen> of course but being overcautious is safe
<smb> Exactly. Rather be safe than sorry and in the bug report I think was a version with irqsave and restore which has been dropped because the original patch did not use it. Though the original patch completely changed things...
<jjohansen> well I am not so worried about what is done in the original patch as patches around it
<jjohansen> the original didn't change things enough in the locking sense for that worry
<smb> In that case I did not look that much on what was done upstream (taking the statement about it being complicated and not all needed to get the gist of what is needed). Mostly what is done looks ok (make the update happen all the time and lock on the callers). And also most callers seem to be things that are triggered from userspace only. Just the watchdog function I am not sure. And whether it may interrupt a caller from user-space in an unfor
<smb> tunate way
<smb> Still I did not want to get that patch forgotten just because I am a code worrier... :-P
<jjohansen> smb: heh no worries, we will get it taken care of
<jjohansen> smb: so this I am less than thrilled with the patch
<smb> jjohansen, Oh, ok. So what are your worries there?
<smb> (actually if you could just reply in the thread, then you'd have to type it only once..)
<jjohansen> smb: in the context of locking _bh, or irq I think it is okay, but I am not entirely convinced the locking is doing much good
<jjohansen> smb: basically, it does prevent similtaneous writers, but it does nothing for readers
<smb> jjohansen, Ah, ok... Hm, missed that aspect then
<jjohansen> smb: look at igb_get_stats in igb_main.c
<smb> jjohansen, Probably did not look into all accesses. At least the hunks seemed to change read (in those cases) into a write (update)
<jjohansen> in the original patch a copy is made after the update and the copy is what is returned to the readers
<jjohansen> so they have a private copy
<jjohansen> a snapshot
<jjohansen> here we are returning the live structure
<jjohansen> now the question is do we care?
<jjohansen> the locking seems to have been mostly added for 64bit accesses on 32bit machines
<smb> Hm, doing the snapshot ensures that the stats are coherent. I guess updates just happening more often would not be completely what is desired...
<jjohansen> so right now I am trying to figure out if we care
<jjohansen> if its only for consistency across 64 bit stats then we may not care
<jjohansen> if its for snapshot consistency we do
<smb> Well otoh locking sounds reasonable just because now there may be two readers causing parallel updates, won't they?
<jjohansen> possibly, the writers certainly need locking of some form
<jjohansen> but I am not familiar enough with the code to say if multiple writers can occur at that point
<jjohansen> but the locking won't hurt
<smb> iirc it was changing the code so reading the stats for example with ethtool woul update them at that time
<smb> And I guess at least in theory that could happen in parallel
<jjohansen> it really comes down to the readers
<jjohansen> right
<jjohansen> I think the writers can be parallel, I am just not positive
<jjohansen> so, I good with the locking on the writer side
<jjohansen> its the readers I am trying to figure
 * jjohansen really wishes the original patch had been split up
<smb> Ok, let me have a look at this again in meld...
<smb> wtf
<smb> I am not sure why I care... There was a code warrior putting that into master-next already it seems...
<jjohansen> o_O
<smb> jjohansen, Just questioning my sanity: do you see it too?
<jjohansen> hrmm, let me pull and see
<jjohansen> ah gah my linux-next tree hasn't been updated to git hub
<smb> oops
 * smb -> lunch
<jjohansen> smb: so I don't believe we care.  We aren't updating 64 bit values, and I don't see a reason for rx and tx stats to be a snapshot, that is if rx gets incremented while read tx it doesn't really matter
<smb> jjohansen, Ah ok, so basically the net stats are not really verifyable the first place. If its only rx / tx then surely they are ok as long as the value itself is consistent
<smb> Would be different when there was something like irqs as well which would or would not be consistent with rx or tx
<jjohansen> well its a little more than rx or tx look in include/linux/netdevice.h for net_device_stats
<jjohansen> eg you could get rx_bytes and rx_packets to be from different snapshots
<jjohansen> but the lack of consistency there is a very minor problem
<smb> Yeah, and probably was there before...
<jjohansen> yep
<mterry> ogasawara, hello!  I'm just pinging you to make bug 849564 more visible.  :)  Very reproducable and pretty annoying regression.  I'd be glad to help test kernels
<ubot2> Launchpad bug 849564 in linux "System76 Lemur: Does not suspend on second attempt" [Undecided,Confirmed] https://launchpad.net/bugs/849564
<apw> jjohansen, tyler hicks is the ecryptsfs man right ?
<jjohansen> yep
<jjohansen> I keep meaning to sit down with him but haven't yet
<apw> jjohansen, heard any reports about encrypted swap corrupting stuff ?
 * smb <- back
<apw> https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/745836
<ubot2> Ubuntu bug 745836 in ecryptfs-utils "ecryptfs encrypted swap corrupts application stack/heap [was: soffice.bin SIGSEGV cppu::throwException()]" [Critical,Confirmed]
<apw> smb, ^^ you may be interested in the bottom of this
<apw> i assume swap actually is actually dmcrypt
<kirkland> wow
<jjohansen> apw: no
<kirkland> apw: so swap is not encrypted using ecryptfs
<kirkland> apw: it's just dmcrypt
<smb> apw, Thought you were the bottom man... :-P
 * smb looking
<apw> right ... i assume the users are confused
<kirkland> apw: ecryptfs-setup-swap sets it up
<kirkland> apw: you assume correctly, I think :-)
<apw> smb, would you have time to poke this nest of worms ?
<smb> apw, Not sure I really want to...
<apw> jjohansen, if you do talk to tyler, tell him that people are reporting that the 'crap at the end of ecryptsfs files' bug is being reported not fixed even where the fixes are applied
<apw> smb, heh now that i can understand :/
<apw> smb, i could swap you for working out why we have power problems if you like
<jjohansen> apw: yeah, that is weird
<smb> apw, I probably take the other land-mine then I guess
<smb> apw, At least things exploding is more realistic 
<apw> smb, it sounds like they have a reproduce by in a vm if you scroll back a few comments
<smb> Yeah. Will try the receipe and see what I get
<Sweetshark> apw, smb: Hi there.
<smb> Sweetshark, Hi, just reading through that bug
 * Sweetshark is Bjoern Michaelsen. And yes, it seemed to be quite reproducable in the end.
 * smb Realized
<smb> Sweetshark, How small was the smal RAM?
<smb> 512M?
 * apw is suprised LO would start at all in that
<Sweetshark> smb: 512MB was enough here.
<apw> Sweetshark, was it reproducible on oneiric ?
<Sweetshark> and then open Firefox, imagesearch for large images and open 20 in tabs to make him swap. (Unless you kernelguys have something less pragmatic).
<Sweetshark> apw: Havent tried yet. I just got it reproducable today.
 * jjohansen -> waves good night
<smb> jjohansen, night
<apw> Sweetshark, heh i think i'd probabally just boot the VM with less ram :)
<apw> jjohansen, no bed bugs ....
<smb> Also got some program done by someone to eat memory... Would try that too
<Sweetshark> as for this affecting oneiric: it is highly likely as there are stacktraces for it: bug 854197 for example
<ubot2> Launchpad bug 854197 in libreoffice "soffice.bin crashed with SIGSEGV in QPaintEngine::drawImage() (dup-of: 745836)" [Undecided,Incomplete] https://launchpad.net/bugs/854197
<ubot2> Launchpad bug 745836 in ecryptfs-utils "encrypted swap corrupts application stack/heap [was: soffice.bin SIGSEGV cppu::throwException()]" [Critical,Confirmed] https://launchpad.net/bugs/745836
<Sweetshark> or bug 801592 (which is closer to the original "cppu::throwException" stacktrace.)
<Sweetshark> arggh, pasted the wrong bugs.
 * Sweetshark better tries himself.
<smb> Sweetshark, I think at least the initial report of that was 32bit. Since you already spent quite a time with those, were there 64bit cases as well?
<Sweetshark> smb: yes.
<Sweetshark> smb: Actually I personally reproduced on natty 64-Bit.
<smb> Ah good. So that does not matter
 * ogasawara back in 20
<tyhicks> apw, kirkland, Sweetshark: I looked into bug 745836 last night and have a gut feeling that it is an inode race condition that I fixed recently. I haven't had a chance to update the bug with my findings yet.
<ubot2> Launchpad bug 745836 in ecryptfs-utils "encrypted swap corrupts application stack/heap [was: soffice.bin SIGSEGV cppu::throwException()]" [Critical,Confirmed] https://launchpad.net/bugs/745836
<tyhicks> I started to backport the patches last night but ran out of steam
<tyhicks> I think I've just got one left to do
<smb> tyhicks, Just wondering, if it is encrypted home/swap it is dm-crypt no ecryptfs...
<apw> tyhicks, though they claim near the bottom that removing ecryptfs from the equasion and the problem is still there
 * tyhicks missed that
<apw> tyhicks, Sweetshark it was you who claimed to have tested with just dmcrypt swap and normal home right ?
<tyhicks> I can reproduce this easily in my vm... let me give it a shot on an unencrypted home
<apw> tyhicks, thanks
<smb> tyhicks, or just replace the swap by an unencrypted one
<tyhicks> apw smb: I couldn't reproduce it with encrypted swap and unencrypted home
<tyhicks> smb: you wanted me to test unencrypted home with unencrypted swap?
<smb> tyhicks, Interesting, in the bug report it is claimed with encrypted home and without encrypted swap it cannot be reproduced either...
<smb> tyhicks, I am still installing a vm, so if you want to go for a try, sure
<tyhicks> smb: I'm thinking that this is the eCryptfs inode race condition that I fixed upstream recently
<tyhicks> smb: encrypted swap could add just enough latency into everything that the race condition exposes itself more often
<smb> Ah, that may well be
<smb> tyhicks, So since you were already quite close to have the patches ready (and probably a test kernel too), I think the best approch would be to give those a try first
<tyhicks> smb: Ah, I just noticed that the fixes I had started backporting are already in oneiric
<tyhicks> smb: Sweetshark says that it is highly likely that oneiric is affected, too, but I'm not seeing any reports against oneiric
<smb> tyhicks, Sweetshark thought there were bug reports for oneiric too. But then said something about wrong ones and I am not sure with what kernel version those would have been opened anyway
<Sweetshark> smb: I just got a vanilla oneiric beta2 vm ready. Trying to reproduce.
<tyhicks> Sweetshark: great - that would give me a good idea about whether or not this patchset I'm backporting is going to fix it
<smb> Sweetshark, tyhicks Can I let the two of you check into this. It feels like tyhicks has the best lead for the fix anyways
<tyhicks> smb: works for me
<tyhicks> smb: if I determine that eCryptfs is not at fault, I'll let you nkow
<smb> Thanks a bunch. Yes, sounds good
 * apw idly notes that 'thanks a bunch' is normally negative
<smb> oops
 * smb meant it the positive way
<apw> thanks a lot! is normally possiblem t
<apw> possible, thanks a lot.  is often not :)
<apw> isn't english great
 * smb probably has to live with every second word he says is an insult, about drinking or sex without knowing
<Sweetshark> tyhicks: NOT reporoducable in oneiric beta2 with encrypted home and swap (or at least not easily reproducable).
<tyhicks> Sweetshark: woohoo... I think I might be on the right rack
<tyhicks> s/rack/track/
<tyhicks> Sweetshark: thank you!
<Sweetshark> of course tests cant prove the absense of bugs ;)
<tyhicks> Oh, I should probably get some quick confirmation on the natty kernel source that I'm using (I've never worked directly on an ubuntu kernel before now)
<tyhicks> Is the master branch of git://kernel.ubuntu.com/ubuntu/ubuntu-natty.git what I should be backporting against?
<tgardner> tyhicks, either master or master-next
<tgardner> master-next is the branch we'll actually apply the SRU patch agains
<Sweetshark> tyhicks: what are the chances that Libreoffice itself is at fault here? I assumed pretty slim and closed as invalid. Since you have a idea what the root cause it do you agree that this is valid to assume?
<tyhicks> Sweetshark: Tough to say just yet
<Sweetshark> tyhicks: k
<Sweetshark> well, if you find anything fishy from LO on this please reopen on libreoffice.
<tyhicks> Sweetshark: at first glance, my reaction was "Oh, eCryptfs is doing something non-POSIX-like and libreoffice should maybe handle that better" but then as I looked into it more, I got the feeling that eCryptfs is at fault
<Sweetshark> tyhicks: k thx
<apw> ogasawara, the binary package is: linux-image-extra-3.0.0-9-virtual
<apw> as an example from my test builds
<ogasawara> apw: cool, was just about to check
<ogasawara> apw: so we're fine there
<apw> the theory behind the packaging changes is that you could pick any subset as a separate package
<apw> so you could pull out staging for example
<apw> though we don't do it
<apw> bug #818177
<ubot2> Launchpad bug 818177 in udev "HP DL380G5 root disk mounted read-only on boot and boot fails" [High,Confirmed] https://launchpad.net/bugs/818177
 * smb drops off
<sforshee> mjg59, do you know of any way to get a trace of the AML method calls being made by a driver under Windows?
<mjg59> sforshee: Nope
<sforshee> rats
<cking> sforshee, ask alexhung
<cking> mjg59, nice response to microsoft's fluff
<mjg59> cking: Thanks!
<sforshee> cking, already have, but I'm exploring a couple of alternate avenues
<cking> I'm glad it's getting a whole load of attention
<cking> sforshee, pity you can't slap in systemtap eh?
<sforshee> cking, I found some kind of sample for tracing ioctls (which is how AML methods appear to be invoked on windows)
<sforshee> heh
<sforshee> cking, windows also seems to have support for something called filter drivers, which I think can be placed transparently between a driver and the hardware
<cking> sforshee, that's interesting to know, so is the windbg approach a dead end?
<sforshee> cking, it looked like it required some special hardware, so I'm looking at software-only solutions first
<cking> sforshee, you could hack out the DSTD, put in some extra AML to do port 0x80 writes and then boot the machine with BITS to pre-load the tables into memory - and then chain boot Windows.
<cking> you need a port 0x80 debug card ;-) and patience
<cking> oh, SIGCHILD, gotta to attend my kids..
<sforshee> cking, that's an interesting idea, but these are netbooks so installing a port 0x80 debug card is going to be problematic :)
<cking> sforshee, yep, I've always found they don't work well
<cking> the mini PCI-e one's have never worked for me
<mjg59> sforshee: Alternative is to figure out where ACPI debug statements go on Windows and fill the AML with a pile of them
<sforshee> mjg59, thanks, I'll look into that as well
 * sforshee -> dr appt
 * tgardner -> lunch
 * apw calls it beer time, laters
<cjwatson> Hmm.  Is there a reason why xenbus_probe_frontend is modular in several of our configs?
<cjwatson> It means that other Xen drivers (e.g. xen-netfront) don't get autoloaded
<cking> sforshee, be sure to write up your findings once you've figured out a workable methodology ;-)
<tgardner> cjwatson, I think the backends are built-in for DomU clients. Aren't the front-end drivers for Dom0 ? or do I have it backwards.
 * ogasawara lunch
<cjwatson> tgardner: I think you have it backwards
<cjwatson> tgardner: I'm on a domU client at the moment - loading xenbus_probe_frontend is enough for it to find its network interface
<cjwatson> and without that, the installer fails due to having no network interfaces; I could work around this in the installer, but it seems more correct to build this in unless there's a reason not to
<cjwatson> tgardner: I've filed bug 857662 with a more complete rationale
<ubot2> Launchpad bug 857662 in linux "Should xenbus_probe_frontend be built-in?" [Undecided,New] https://launchpad.net/bugs/857662
<tgardner> cjwatson, ack
<tgardner> cjwatson, are you using the server or virtual ?
<cjwatson> explained in the bug
<cjwatson> ... and corrected the description to match reality
<tgardner> cjwatson, so you think CONFIG_XEN_XENBUS_FRONTEND=y will solve all your problems ? -virtual works as desired ?
<cjwatson> I have no remotely straightforward way of trying -virtual - I don't control the host
<cjwatson> I have tested that 'modprobe xenbus_probe_frontend' makes everything work
<tgardner> cjwatson, ok
<cjwatson> and I guess I sort of feel that -generic should be a superset of -virtual, normally?  at least for "does it work"-ness
<cjwatson> ISTR -virtual originally being just a make-it-smaller flavour
<tgardner> cjwatson, actually, -server and -virtual are much more closely related (in amd64)
<cjwatson> oh, is the -virtual config generated somehow?
<cjwatson> I noticed
<cjwatson> debian.master/config/amd64/config.flavour.generic:21:CONFIG_XEN_XENBUS_FRONTEND=m
<cjwatson> debian.master/config/amd64/config.flavour.virtual:21:CONFIG_XEN_XENBUS_FRONTEND=y
<cjwatson> and inferred that it wasn't a simple subset any more
<tgardner> cjwatson, it was originally based on -server
 * jjohansen -> lunch
<cjwatson> oh, I see, well, -server has CONFIG_XEN_XENBUS_FRONTEND=m too
<cjwatson> I wouldn't object to switching the xen images over to -virtual in P if it's the kernel team's opinion that that would work better
<cjwatson> and if you think CONFIG_XEN_XENBUS_FRONTEND=y across the board is too risky for Oneiric then I can add workarounds
<tgardner> cjwatson, we tailored -virtual for use in xen environments
<cjwatson> but I thought it made sense to ask first
<tgardner> I'm still evaluating  CONFIG_XEN_XENBUS_FRONTEND=y across the board
<tgardner> its likely OK
<tgardner> cjwatson, it _looks_ ok, but I think I've gotta test it on some bare metal first.
<ogasawara> tgardner: lemme know how the tests go.  I'll hold off on the upload for a bit so we can add the config change.
<tgardner> ogasawara, it'll take 30 mins or so
<ogasawara> tgardner: ack
<tgardner> cjwatson, ogasawara: the only way to build in XEN_XENBUS_FRONTEND is by enabling one of the front end device drivers, e.g., CONFIG_XEN_BLKDEV_FRONTEND=y or CONFIG_XEN_NETDEV_FRONTEND=y. This is the reason we only enabled those drivers for -virtual.
<tgardner> I'll add my rationale to the bug
<cjwatson> tgardner: oh, drat
<cjwatson> that seems like a bug in the upstream config system
<cjwatson> since you can never get autoloading that way
<tgardner> cjwatson, Im not saying it _won't_ work, I'm just a little reluctant at this late stage.
<cjwatson> yeah, understood
<cjwatson> switching to -virtual will be fine for P, and I'll work around it in the installer for Natty/Oneiric
<tgardner> cjwatson, cool, much appreciated.
<cjwatson> solutions that don't involve kernel changes are fine, I just have a little Keybuk voice in the back of my head going "we should just change the kernel" sometimes ;-)
<tgardner> I guess I'm the anti-keybuk
<tgardner> ogasawara, fire away
<ogasawara> tgardner: I'm firing up test boots and will then pull the trigger
 * tgardner -> EOW
<bryceh> ogasawara, heya
<ogasawara> bryceh: hi what's up
<bryceh> ogasawara, I want to build a kernel for a bug reporter to test, with an upstream patch applied
<ogasawara> bryceh: want me to build it for ya?
<bryceh> ogasawara, oh that'd be great
<ogasawara> bryceh: sure, just point me to the patch.
<bryceh> it's comment #7 on https://bugs.freedesktop.org/show_bug.cgi?id=41059
<ogasawara> bryceh: I assume oneiric kernel?  and do they need amd64 or i386?
<ubot2> Freedesktop bug 41059 in Driver/intel "XRANDR operations very slow unless (phantom) HDMI1 disabled" [Major,New]
<bryceh> ogasawara, amd64
<ogasawara> bryceh: once I've got it, you want me to just post the url to the test kernel in that bug?
<bryceh> ogasawara, yep that'd be perfect
<ogasawara> bryceh: ack, will do
<bryceh> thanks ogasawara!
<htorque> bryceh: hi! what do you say - are 120 ms per DP port probe ok? HDMI2 and HDMI3 in comparison are much faster.
<bryceh> htorque, keith packard's been reworking the DP probing code lately
<bryceh> we've seen some horrible times, particularly eDP, of 500-1000ms in some cases
<bryceh> so compared with that 120 ms doesn't seem too bad
<bryceh> however my expectation would be that it should be much lower than that
<htorque> bryceh: okay, thanks for your answer! :)
<bryceh> Given the recent trend of hardware with lots of different ports, what concerns me is the sum of doing these probes in serial.  I wonder why they're not done in parallel; is that even possible?
<bryceh> htorque, keithp has a code branch with reworked DP probing that we had a couple people test and they found it significantly imprved boot speed
<bryceh> I've communicated this to Intel, which they were glad to  hear and hopefully they'll have that new code finished, QA'd, and available in time for LTS
<bryceh> I am not confident it's something we'd want to risk SRUing for oneiric but guess we can decide at some point when the code is ready
<htorque> bryceh: the 1.6 sec. from HDMI1 are definitely worse - especially if you don't have HDMI ports :P
<htorque> do you have a link to that branch?
<bryceh> no but I can dig it up, one sec
<htorque> bryceh: found this: http://kernel.ubuntu.com/~sarvatt/macbook-air/
<bryceh> aha yeah that's it
<htorque> bryceh: from 120 ms per port to 50 ms per port. nice! :)
<bryceh> htorque, most excellent :-)
#ubuntu-kernel 2011-09-24
<jonpry> oh please oh please fix https://bugzilla.redhat.com/show_bug.cgi?id=699156 it's been like 11 months of 83C idle. don't think she can handle much more
<ubot2> bugzilla.redhat.com bug 699156 in kernel "Large amount of acpi interrupts on lenovo y560p with 2.6.38+" [Unspecified,New]
<htorque> hello everyone! where can i get the apparmor compatibility patches as http://www.kernel.org/pub/linux/security/apparmor/ is down?
<jjohansen> htorque: they are also available from the bzr tree, or release tarballs on launchpad in the kernel_patches director.
<jjohansen> https://launchpad.net/apparmor
<htorque> jjohansen: oh, didn't know that. thanks!
#ubuntu-kernel 2012-09-17
<infinity> hggdh: Good news (potentially), I might be able to fix that missing kernel binary.  I'll let you know tomorrow.
<hggdh> infinity: cool. Meanwhile, I failed the SRU, and we will look at it tomorrow
<hggdh> infinity: add Natty LTS HWE to the mix, also missing the kernel headers
<hggdh> infinity: do NOT promote to -updates bug 1047350
<ubot2> Launchpad bug 1047350 in linux-lts-backport-natty "linux-lts-backport-natty: 2.6.38-16.67~lucid1 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1047350
<orated_> Hello! I'm using BeagleBoard XM C1 running Canonical Ubuntu 12.04 image. I'm facing sound issues and even after following https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1019321 comment 24 - sudo modprobe snd-soc-omap, sudo modprobe snd-soc-omap-mcbsp, sudo modprobe snd-soc-omap3beagle - by ppisati, the problem remains the same. How can I fix the sound issue please?
<ubot2> Launchpad bug 1019321 in linux "USB sound card not detected on beagleboard xM" [Medium,Fix released]
<ppisati> moin
<orated_> Hi ppisati
<orated_> I followed bug reported in launchpad - 1019321 which was later fixed by you. Could you guide me how I can fetch the update with released fix? sudo modprobe snd-soc-omap, sudo modprobe snd-soc-omap-mcbsp, sudo modprobe snd-soc-omap3beagle manually is not fixing the problem
<orated_> ppisati: ^
<ppisati> orated: latest kernel have have the fix, upgrade
<orated> Hello ppisati
<ppisati> orated: latest kernel have have the fix, upgrade
<orated> Sorry, my connection dropped before
<orated> ah, well
<orated> Currently it is 3.2.0-23-omap
<orated> ppisati: Could you specify the kernel version on which it is fixed?
<orated> Running dist-upgrade or upgrade doesn't show kernel upgrades so I guess I have to upgrade from binaries?
<ppisati> orated: didn't you mention a bug report earlier? it should contain when it was fixed
<orated> ppisati: I've gone through the bug report and comments multiple times. I can see in the comment mention of linaro kernel then in your comment for http://people.canonical.com/~ppisati/linux-image-3.2.0-27-omap_3.2.0-27.42~socomapy_armhf.deb and then second last comment for linux (3.2.0-29.46) precise-proposed. If I would have understood the process and solution I wouldn't have asked multiple times in this channel or other multiple times in first 
<orated> place. I've not performed kernel upgrades manually which is why I'm requesting you to guide me on it.
<ppisati> bug 1019321
<ubot2> Launchpad bug 1019321 in linux "USB sound card not detected on beagleboard xM" [Medium,Fix released] https://launchpad.net/bugs/1019321
<ppisati> orated: from the bug report - "This bug was fixed in the package linux - 3.2.0-29.46"
<ppisati> orated: which kernel are you running?
<orated> Yes, I mentioned that I read linux (3.2.0-29.46) precise-proposed above
<orated> I'm running 3.2.0-23-omap
<orated> I can see I have to upgrade but I'm not sure how, sorry
<ppisati> orated: sudo apt-get update
<ppisati> orated: and then
<ppisati> orated: sudo apt-get upgrade
<ppisati> orated: are you running precise, right?
<orated> Yes, as I said doing sudo apt-get update && sudo apt-get upgrade && sudo apt-get dist-upgrade is not showing kernel upgrades
<orated> And, the image is Canonical Ubuntu 12.04 Precise
<ppisati> orated: what does /etc/apt/sources.list contains?
<ppisati> orated: paste it in http://paste.ubuntu.com/
<orated> I ran update process again that its taking time to read package lists, hold on please
<orated> http://paste.ubuntu.com/1210483/
<ppisati> orated: and when you do a "sudo apt-get upgrade" whats dows it show?
<orated> http://paste.ubuntu.com/1210486/
<ppisati> orated: upgrade not update
<ppisati> orated: ah
<ppisati> orated: just noticed the first line
<ppisati> orated: dpkg -l | grep image
<orated> http://paste.ubuntu.com/1210490/
<orated> If I understand right, ii  linux-image-3.2.0-30-omap              3.2.0-30.48  on line 22
<ppisati> orated: so you have the latest kernel
<ppisati> orated: sudo flash-kernel 3.2.0-30-omap
<ppisati> orated: and then reboot
<orated> um
<orated> flash-kernel
<orated> Ah, yes I missed that!
<orated> I'll try that. Thanks a lot for your time and inputs :)
<orated> ppisati: But I'm curious as to why the last command said - 64 bit x86 systems for 3.2.0-23.36
<orated> 64 bit x86
<ppisati> orated: probably a broken description
<orated> Ok, I've rebooted and hopefully sound will work
<orated> after flashing*
<orated> $ aplay -l
<orated> aplay: device_list:252: no soundcards found...
<ppisati> uname -a
<orated> 3.2.0-30-omap
<ppisati> cat /proc/asoud/cards
<orated> I have restarted now, one moment
<ppisati> *asound
<orated> ah-ok
<orated> omap3beagel
<orated>  0 [omap3beagle    ]: omap3beagle - omap3beagle
<orated>                       omap3beagle
<orated> I'm trying to play a test track using mplayer now
<ppisati> kernel-wise is ok, dunno what's wrong with your userland
<orated> alsamixer command is giving cannot open mixer: No such file or directory
<orated> I've snd-soc-omap snd-soc-omap-mcbsp snd-soc-omap3beagle in /etc/modules.. I should be removing them
<ppisati> you shouldn't even have these modules since theyt are compiled-in now
<orated> Yes, I had them with old kernel when I thought it was reverting back
<orated> No other change was made 
<orated> I removed it, restarted and again there is $ alsamixer cannot open mixer: No such file or directory
<ppisati> orated: if /proc/asound/cards list the sound card, then the kernel is good
<orated> Yes, it does but
<orated> I have not performed any major changes that its not working
<orated> Kernel is, I mean with reference to "what's wrong with your userland"
<orated> Thank you
 * ppisati -> reboot
<ppisati> dual core arm imx6, 1GB ram, sata: 89$
<ppisati> http://www.wandboard.org/
<orated> ppisati: I just now completed fresh install of Canonical Ubuntu 12.04 with latest omap kernel on BeagleBoard XM. I checked for sound cards its omap3beagle and then tested a track with mplayer. No sound output
 * rtg_ works on 3.5.y quantal update
<ogra_> including omap4 ?
<rtg> ogra_, no right away. usually ppisati sends a pull request after omap4 has been rebased against master
<ogra_> ah, k , i thought he did already
<doko> rtg, ignore the readelf return value, ftbfs on arm
<rtg> ogra_, I'm right now rebasing against v3.5.4. ppisati pull request on the k-team mailing list is going to be obsolete quite soon.
<ogra_> ah, ok
<rtg> doko, I reuploaded after that FTBS so that readelf is only run for x86'en
<ogra_> well, it would be really good to have the graphics patch before beta
<ogra_> but ppisati knows that :)
<rtg> ogra_, is that in 3.5.4, or a patch on the list ? (I'm still catching up)
<doko> rtg: using gcc-4.7 4.7.1-9ubuntu1 on all archs?
 * henrix -> (late) lunch
<ogra_> rtg, 
<ogra_> * important video fixes from TI (eliminate video flickering with Unity)
<ogra_> * kernel rebased on Ubuntu-3.5.0-14.16
<rtg> doko, we'll get an upload later today once -9ubuntu1 is finished building
<doko> ok
<ogra_> its the ifrst item on the most recent mail from him
<rtg> ogra_, ack
<ppisati> rtg: i didn't rebase on origin/master this morning since there was nothing arm-related there (an intel xhci fix and then the x86-only readelf stuff)
<rtg> ppisati, yeah, you're fine. I get omap4 uploaded this morning.
<rtg> I'll*
<ppisati> rtg: ack
<ppisati> since i updated my box this morning, skype keeps popping up and stealing focus
<ppisati> *CRAP*
<rtg> ogasawara, pushed Quantal v3.5.4 rebase w/forced ABI bump. note that we should wait to upload until after gcc-4.7 4.7.1-9ubuntu1 is built.
<ogasawara> rtg: ack
 * ppisati -> reboot
<ppisati> tseliot: sudo apt-get install fglrx-updates
<ppisati> tseliot: Error! Application of patch fix-build-issue-on-i386-where-TS_USEDFPU-is-no-longe.patch failed.
<ppisati> tseliot: is there a way to rekick the build without that patch?
<ogra_> rekick -> dpkg-reconfigure fglrx-updates
<ogra_> no idea how you fix out the patch manually before though
<ogra_> s/fix/fish/
<ppisati> ogra_: dpkg-reconfigure restarts the build, so it unpacks again all the stuff etcetc
<ogra_> but probably there are hints in the /usr/src dir
<ppisati> ogra_: thus it tries to reapply the patch
<ogra_> it shouldnt unpack again 
<ppisati> ogra_: right
<ppisati> ogra_: it actually complains
<ppisati> ogra_: "fglrx-updates is broken or not fully installed"
<ogra_> wow, thats bad, it should just trigger dkms again 
<ppisati> i want to die...
<ogra_> thats a bit of an overrecation, no ?
<ogra_> :)
<ogra_> "killed by an fglrx update"
<ppisati> :)
<tseliot> ppisati: what version of ubuntu are you using?
<ppisati> tseliot: P/amd64]
<tseliot> ppisati: I think there's a package in precise-proposed that could solve your problem
<tseliot> ppisati: still fglrx-updates
<ppisati> tseliot: i'll give it a sping, thanks
<ppisati> sping
<ppisati> ARGH
<ppisati> spin
<tseliot> :)
<ppisati> tseliot: nope
<ppisati> tseliot: sudo apt-get install fglrx-updates/precise-proposed
<tseliot> ppisati: same error? With what kernel?
<ppisati> tseliot: ii  fglrx-updates                          2:8.982-0ubuntu0.1
<ppisati> tseliot: Error! Application of patch fix-build-issue-on-i386-where-TS_USEDFPU-is-no-longe.patch failed.
<ppisati> tseliot: 3.2.0-31-generic #50-Ubuntu
<tseliot> ppisati: weird, let me try it here
<tseliot> ppisati: also, is it on i386?
<ppisati> tseliot: amd64
<tseliot> ppisati: ok
<ppisati> brb
<siretart> ogasawara: would you mind reconsidering the 'importance' field of bug #908784 (my rationale is in comment #3) - thanks in advance!
<ubot2> Launchpad bug 908784 in linux "Please reconsider keeping aufs module in linux-image-3.5.0" [Undecided,Confirmed] https://launchpad.net/bugs/908784
<ogasawara> siretart: re-enabling aufs is on our radar.  I wanted to discuss with apw (when he returns from vacation) later this week.
<siretart> ogasawara: thanks a lot!
<orated> Hello! I'm using Beagleboard XM running Canonical Ubuntu 12.04 3.2.0-30-omap. Even with the latest kernel where sound issue is fixed, I'm not able to get audio output. $ cat /proc/asound/cards lists 0 [omap3beagle ]. I even tried the steps on a fresh install, there is still no sound output. Can anyone help me find the cause?
<rtg> ppisati, ^^ 
<ppisati> if /proc/asound/cards shows the audiocard, kernel is good
<orated> rtg: I had some progress with ppisati help
 * ogra_ doesnt think anyone tested or touched ubuntu-desktop on omap in ages 
<orated> ppisati: Yes, but even the fresh install is with same behaviour
<ogra_> essentially someone needs to supply a proper UCM config for it 
<ogra_> ppisati, no worries, the kernel is good, its just that bnobody sent a patch for alsa-libs with a proper usc config yet 
<orated> I used ubuntu-12.04-preinstalled-desktop-armhf+omap.img image
<orated> Is sound common issue on all arm platform running canonical image?
<ogra_> canonical image ?
<orated> canonical ubuntu image
<ogra_> what has canonical to do with that ?
<orated> just to differentiate it from custom
<ogra_> custom ?
<orated> like rcn-ee
<ogra_> seriously, there is only one ubuntu image 
<ogra_> and with issues with non-ubuntu images you shouldnt come here but go to the creator
<orated> ogra_: When did I say I'm running non-ubuntu image?
<ogra_> you call it "canonical ubuntu image" all the time
<ogra_> there is no such thing
<ogra_> its the ubuntu image
<orated> Well, I've been asked before which image.. canonical or rcn-ee
<orated> Okay, I take that back. Thanks for the correction
<orated> Is sound common issue on all arm platform running Ubuntu?
<ogra_> sound works fine on the pandaboard and the ac100 images
<ogra_> where people have supplied proper ucm configurations for alsa
<alexbligh> Not sure whether this is a kernel question or not. We are seeing:  /bin/mount -t nfs4 10.157.208.2:/volumes/rpool0/qa2-nfs /test not call modprobe on the nfs module, but with '-t nfs' (not -t nfs4) not fail because of the modprobe (but not work, as not nfs4). Apparently this is a known issue https://help.ubuntu.com/community/SettingUpNFSHowTo - my question is *why* isn't mount doing a modprobe?
<alexbligh> (precise & lucid, FWIW)
<rtg> alexbligh: prolly 'cause the super block code advertises the name 'nfs' instead of 'nfs4'. See fs/nfs/super.c 'static struct file_system_type nfs_fs_type'.
<tseliot> ppisati: ok, I can reproduce the issue (something must have changed in the kernel). I'll make sure it builds again
 * ogasawara back in 20
 * ogra_ hugs rtg 
<hggdh_> infinity: good morning
<henrix> hggdh_: hi! i'm still waiting for infinity as well, probably for the same reason as you :)
<hggdh_> henrix: hi, yes, I think we are on the same page
<ppisati> tseliot: thanks
 * ppisati -> gym
<alexbligh> rtg, thanks
<rtg> alexbligh: no problem
<rtg> CVE-2012-3520
<ubot2> rtg: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3520)
<infinity> hggdh, henrix: Hey, I'm around.  Post-birthday hangover.  Going to get to trying to work voodoo to recover those missing binaries in a sec.
<hggdh> infinity: thank you
<henrix> infinity: thanks! (and happy birthday...? :) )
<rtg> jjohansen, is CVE-2012-3520 on your radar ? Just noticed a stable patch for it.
<ubot2> rtg: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3520)
<henrix> infinity: it looks like the missing files are still on the kernel ppa (at least, the linux-headers-*)
<henrix> infinity: not sure if that helps
<jjohansen> rtg: hrmmm no not yet, I'll poke
<rtg> jjohansen, ack
<infinity> henrix: Shouldn't matter if they are or aren't in the PPA still... I think.  I need to sort out what wgrant was trying to tell me yesterday when I was drunk, and see if it works. :P
<henrix> infinity: heh, right. thanks
 * rtg -> lunch
<jjohansen> rtg: okay its being tracked now https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1052097
<ubot2> Launchpad bug 1052097 in linux-mvl-dove "CVE-2012-3520" [High,Invalid]
<rtg> jjohansen, ack. 
 * cking -> EOD
<rtg> ogasawara, gcc-4.7 is done building. are you thinking about an upload this afternoon ?
<ogasawara> rtg: I am.  I had one additional set of amd patches I wanted to squeeze in.
<rtg> ogasawara, I've got 2 AMD systems if you'd like some testing
<ogasawara> rtg: oh cool, lemme build you a quick test kernel.
<ogasawara> rtg: test kernel on gomeisa in my quantal-amd64 dir.  not sure if you have the right combo of actual hw, but at least confirming no regressions would be great.
<rtg> ogasawara, post the patch set ?
<ogasawara> rtg: I'll send a pull request to the list
<rtg> ogasawara, both systems seem to be working OK (desktop and server)
<ogasawara> rtg: thanks.  just sent email to the ml and CC'd you
<rtg> ogasawara, I think we should delay application of patches in bug #1032228 until we can get some hard data. One of those patches is pretty intrusive. I'm not sure its worth the power savings given the maintenance hassles this might create.
<ogasawara> rtg: ack, I'm fine holding off on them till we get more data
<rtg> ogasawara, pull the trigger on the rest ?
<ogasawara> rtg: yep, am kicking off test builds right now and then will upload
<rtg> ogasawara, you picked up 'UBUNTU: SAUCE: CONFIG_HID_BATTERY_STRENGTH=y' ?
<ogasawara> rtg: I didn't flip it on, just posted a comment to the bug
<ogasawara> rtg: or did you push it?
<rtg> ogasawara, I pushed a patch on master-next
<ogasawara> rtg: ah, I hadn't picked it up, will do so now
 * rtg -> EOD
#ubuntu-kernel 2012-09-18
<infinity> hggdh: Around?
<hggdh> infinity: indeed :-)
<infinity> hggdh: In about 15m, all those missing package issues should be fixed, if you'd like to retest and alter the bugs accordingly.
<hggdh> infinity: cool! Will do, but the bugs will have to be changed by the KT, I do not have permission to change them
<hggdh> infinity: thank you very much
<infinity> hggdh: I assume you can remove the tags?  And then maybe the bot will DTRT.
<hggdh> infinity: will do
<infinity> hggdh: If it doesn't, we can revisit it tomorrow.
<hggdh> infinity: ack
<hggdh> this will be tested tomorrow -- I am running another set of tests now
<hggdh> and I am at EOD
<infinity> hggdh: Cool.  Let me know.
<hggdh> infinity: bug 1046423 and bug 1047350 have been untagged -failed, but I cannot change the status of my task. I will let you know tomorrow how it goes
<ubot2> Launchpad bug 1046423 in linux-lts-backport-oneiric "linux-lts-backport-oneiric: 3.0.0-26.42~lucid1 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1046423
<ubot2> Launchpad bug 1047350 in linux-lts-backport-natty "linux-lts-backport-natty: 2.6.38-16.67~lucid1 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1047350
<herton> hggdh, I reseted the tasks, feel free to set regression-testing to fix released when you finish
<hggdh> herton: thank you sir
 * smb shuffles in
<xnox> where was the ppa / archive / package name for the quantal's kernel for 12.04?
<siretart> xnox: I suppose it might be https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport
 * henrix -> lunch
<antonioo> ciao
<antonioo> @find heroes
<ubot2> antonioo: Found: heroes-common, heroes-data, heroes-ggi, heroes-sdl, heroes-sound-effects (and 1 others)
<antonioo> @download heroes
<ogasawara> jjohansen: 2 part question...you'd mentioned something about investigating CONFIG_IMA a few weeks ago and possibly flipping it on.  Did your testing provide enough evidence that enabling it won't cause any issues?  If so, do we need this to land in Beta-2 for more widespread testing?
<marrusl> rtg, if you are around... do you think the fix for LP: 1041397 will hit precise-proposed soon?
<rtg> bug #1041397
<ubot2> Launchpad bug 1041397 in linux "smsc75xx driver is missing from the ubuntu-installer initrd" [Undecided,Fix committed] https://launchpad.net/bugs/1041397
<rtg> marrusl, you'd have to ask herton or henrix where Precise is in the release cycle
<hallyn> so are we expecting to stick with 3.5 for q?
<marrusl> ah right.  makes sense.  thanks rtg.
<rtg> marrusl, actually, it should already be in proposed. see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1041397/comments/4
<ubot2> Launchpad bug 1041397 in linux "smsc75xx driver is missing from the ubuntu-installer initrd" [Undecided,Fix committed]
<rtg> hallyn, yep, 3.5
<marrusl> rtg, ugh.  yes.  thanks.  reading comp++
<henrix> marrusl: the fix is already in the P kernel in the -proposed pocket
<hallyn> rtg: thanks.  
<henrix> marrusl: it should be released later this week
<marrusl> henrix, ah, very good.  thanks for the info.
<henrix> marrusl: np
<cking> brendand, any movement on bug 1025663 ?
<ubot2> Launchpad bug 1025663 in linux "DMIStringIndexOutOfRange on HP Proliant ML110 G5" [Medium,Incomplete] https://launchpad.net/bugs/1025663
<ppisati> brb
<jjohansen> ogasawara: I haven't finished with IMA yet, we don't need to land it in beta2 though as we are going to go with it disabled by default, and users will have to add a kernel boot parameter to turn it on
<ogasawara> jjohansen: ack
<jjohansen> bjf: I am going to need access to a lab machine with that apparmor regression happening, I haven't replicated locally
<bjf> jjohansen: can do
<bjf> jjohansen: request sent (you should have email)
<jjohansen> bjf: thanks
<brendand> cking - the system got a new bios, but since it was moved from london to surrey, we can't access it yet
<cking> brendand, ack
<smb> bjf, Btw, I would say there might be a broader interest in having updated (with that vpn setup) instructions (+ip-addresses) how to access lab machines. So maybe there could be at least an email to c-k-t? Please? :)
 * cking begs too
 * rtg wonders why LP sucks so much today
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<smb> Today?
<jsalisbury> correct
<smb> jsalisbury, Sorry was a comment to rtg (a late one ok)
 * rtg would sure like to view https://launchpad.net/ubuntu/+source/linux/+publishinghistory
<jsalisbury> smb, :-)
<smb> That only works randomly for me
<cking> let's all look at that link to make LP really slow
<jsalisbury> cking, Timeout error ;-)
<cking> me too
<cking> I love the message "Trying again in a couple of minutes might work."  - always so hopeful that things will improve
<jsalisbury> heh
<smb> cking, Thats the same principle as rebooting your machine... sometimes it *does* work. :)
<cking> smb, just like the principle of getting a BIOS upgrade; it may just fix things
<jsalisbury> cking, just put a curl request in a for loop and keep hitting it till it works ;-)
<smb> cking, Of course it says so in the changelog "* Fix issues"...
<cking> watch LP catch fire
<rtg> jsalisbury, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1041883/comments/34
<ubot2> Launchpad bug 1041883 in linux "Recent patch to asus-wmi module makes system unbootable" [High,In progress]
 * cking grabs a bite to eat
<jsalisbury> rtg, ack, I'll help him out
<rtg> ogasawara, I did a pretty thorough review of the SATA sleep patches, see https://bugs.launchpad.net/amd/+bug/1032228/comments/3
<ubot2> rtg: Error: <Bugtracker.plugin.Launchpad instance at 0x9212c2c> bug 1032228 not found
 * ogasawara reads
<rtg> jsalisbury, I'm thinking asus-wmi is a red herring. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1041883/comments/39
<ubot2> Launchpad bug 1041883 in linux "Recent patch to asus-wmi module makes system unbootable" [High,In progress]
<jsalisbury> rtg, ok, thanks
<orated> ppisati: ogra_: Small update if its relevant with refernce to my previous sound queries. I connected USB sound device to BeagleBoard XM and it worked out of the box, good alternative to on-board device for a while.
 * rtg -> lunch
 * henrix will out for a bit
<adam_g> jsalisbury: ping
<jsalisbury> adam_g, hi
<adam_g> jsalisbury: hey, ive been blocked on an unrelated bug thats prevented me from testing your bisected kernels on bug #1035172. thats been resolved now. i was wondering if you would be able to show me which git repo and bisect starts/ends i would use to continue bisecting where you left off, so i can try to get it complete sooner than going back and forth in the bug.
<ubot2> Launchpad bug 1035172 in linux "DHCP broken for Openstack Nova instances since kernel v3.3" [High,In progress] https://launchpad.net/bugs/1035172
<jsalisbury> adam_g, sure.  I can post the info in the bug, so you have it to reference
<adam_g> jsalisbury: thank you. i'm set up to do the builds/bisect/auto test i was just running into issues before with what branches to use and where to start/end
<jsalisbury> adam_g, cool.  I'll post the info.
<jsalisbury> adam_g, would you rather I send the info via email or post it in the bug?
<adam_g> jsalisbury: bug is fine
<jsalisbury> adam_g, ok, putting it together now.  Will post in a few minutes.
<jsalisbury> adam_g, I posted the info.  Just let me know if you have any questions or issues.
<adam_g> jsalisbury: thank you, sir
<jsalisbury> adam_g, np
 * cking --> EOD
 * smb --> ditto
<jsalisbury> rtg, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1041883/comments/39  Can I just have him test the kernel already built at: https://launchpad.net/ubuntu/+source/linux/3.5.0-10.10
<ubot2> Launchpad bug 1041883 in linux "Recent patch to asus-wmi module makes system unbootable" [High,In progress]
<jsalisbury> rtg, or do I need to actually reset to f0d8bd and build a kernel?
<rtg> jsalisbury, he's already done that. the _real_ 3.5.0-10.10 doesn't have 3.5.2 in it.
<jsalisbury> rtg, that was my next question
<rtg> jsalisbury, remember that its a rebase, so the commit log is a bit disingenuous
<jsalisbury> rtg, running git log after resetting to f0d8bd83 shows 3.5.1 as the latest rebase.
<jsalisbury> commit b866834d005a1498c56fa912ece5dd9af06dd088
<jsalisbury> Author: Andy Whitcroft <apw@canonical.com>
<jsalisbury> Date:   Fri Aug 10 11:08:23 2012 +0100
<jsalisbury>     UBUNTU: rebase to v3.5.1
<jsalisbury>     
<rtg> why are you resetting to f0d8bd83 ? you should be resetting to Ubuntu-3.5.0-11.11
<jsalisbury> rtg, ok.  I was a little confused by 'I would start by resetting to f0d8bd83c3d4db8ae76df8a894eac04d441e887d which is Ubuntu-3.5.0-10.10 on the Ubuntu-3.5.0-11.11 branch (which also includes 3.5.2).'
<jsalisbury> rtg, I'll follow your examples
<jsalisbury> rtg, so I should reset to Ubuntu-3.5.0-11.11 and have him test that.  If it's bad, then start the bisect.
<rtg> jsalisbury, no, reset to f0d8bd83 and have him test that first. that verifies that the issue is really something between f0d8bd83 and -11.11
<rtg> we already know that -10.10 is OK, and that mainline 3.5.2 is OK. therefore it seems likely it has to be something between -10.10 and -11.11 _after_ the 3.5.2 rebase
<jsalisbury> rtg, Ok, I understand now.  I was just confused by what git log reported after resetting to f0d8bd83
<rtg> jsalisbury, you can't bisect between the tags Ubuntu-3.5.0-10.10 and Ubuntu-3.5.0-11.11 because there is a rebase in the middle
<jsalisbury> rtg, ahh right.  thanks for clarifying
<rtg> ogasawara, http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-precise.git;a=commit;h=899d6a0e07c23f99fee0d3990aaaf0cca753b818
<rtg> I also updated aufs for Quantal but left the build disabled.
<ogasawara> rtg: ack
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues September 25th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
 * rtg -> EOD
<johanbr> vgaswitcheroo stopped working for me in kernel 3.5.0-15-generic. In previous kernels, I get the log fragment   Sep 18 18:01:57 mars kernel: [    2.978314] [drm] radeon defaulting to kernel modesetting.
<johanbr> Sep 18 18:01:57 mars kernel: [    2.978319] [drm] radeon kernel modesetting enabled.
<johanbr> Sep 18 18:01:57 mars kernel: [    2.978344] VGA switcheroo: detected switching method \_SB_.PCI0.AGP_.VGA_.ATPX handle
<johanbr> In 3.5.0-15-generic, those three log lines are absent. Is this a known problem?
#ubuntu-kernel 2012-09-19
 * ppisati is starting to wonder if every mutt + IMAP user use it with offlineimap
<dannf> ppisati: i go back & forth
<dannf> online imap isn't *too* bad w/ header cache
<ppisati> dannf: i've 2 problems with mutt's imap implemenatation: 1) with gmail, from time to time, it boots you out of your mailbox (timeout - http://marc.info/?l=mutt-users&m=134790617031830&w=2)
<ppisati> dannf: and 2) mutt + imap + gnutls if i enable caching, i get constat freezes in recv() (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=292663)
<ubot2> Debian bug 292663 in mutt "mutt blocks at recv after gnutls handshake" [Normal,Open]
<ppisati> it seems i can workaround the gmail timeout changing the idle timeout to 5mins
<ppisati> but the freezes are really a show stopper for me
<ppisati> *CRAP*
 * apw looks out blearily on the world
 * cking offers a coffee to apw
<apw> a fine plan indeed, thanks
<RAOF> The world looks through the bleary interface offered by apw
<apw> at least that way you cannot see my face, sound
<apw> bah half an hours worth of updates, sigh
 * apw bounces
<cking> bah, gnome terminal just segfaulted
 * cking grabs some food
<profiler1982> am having problem with 3.0.0.26 on 11.10. after grub meny can not load lightdm.  version 3.0.0.25 work perfect
<profiler1982> sometime it's load but most- time is not (my eng is not perfect
 * henrix -> lunch
 * ogasawara back in 20
<apw> bc6697d8a506dedf09e8e9974ffa3a316183e608
<apw> arges, rtg, ^^
<arges> apw, thanks
<rtg> apw, ogasawara, we need to run this aufs question to ground today so we can get a little time on it if we decide to re-enable.
<ogasawara> rtg: indeed, if we flip it on, we should try and shove it up in time for Beta-2
<rtg> ogasawara, I'm thinking today since its not an ABI bump
<ogasawara> rtg: that should at least build in time before Beta-2 freeze tomorrow
 * ogasawara mutes call and jump on mumble
<apw> ogasawara, i think it is pretty safe to turn on as it is not used by default
<ogasawara> bug 908784
<ubot2> Launchpad bug 908784 in linux "Please reconsider keeping aufs module in linux-image-3.5.0" [High,Triaged] https://launchpad.net/bugs/908784
<ogasawara> rtg: ^^
<siretart> thanks for keeping aufs for now!
<rtg> siretart, I also enabled it for the LTS kernel in Precise
<siretart> rtg: :-)
 * smb -> EOD
 * rtg -> lunch
 * henrix -> EOD
 * cking --> EOD too
<jwi> rtg: for the i915 backlight patches in quantal, you probably want 4b4147c3 and a4f32fc3 as well
<rtg> kamal, ^^
<kamal> looking
<kamal> rtg, jwi: agreed.   rtg, do we feel lucky?  :-)
<kamal> I haven't tested either of those at all, of course
<rtg> kamal, 4b4147c3 is clearly a regression
<kamal> rtg: yes, they both look fine to me
<kamal> rtg: I could give them a quick spin first, I suppose
<rtg> kamal, please do
<kamal> rtg: will do.   jwi, thanks!!
<kamal> rtg: those patches at least don't appear to break anything here :-)   I've submitted a pull request.
<rtg> kamal, ack
<rtg> kamal, just those 2 patches, right ? I've already got a kernel packaged and test built, ready to upload.
<kamal> rtg: yes, just those two
<kamal> rtg: I just cherry picked them directly, no additional changes.
<bryceh> jsalisbury, ogasawara happen to know when the SRU for #1037293 will be live?
<ogasawara> bug 1037293
<ubot2> Launchpad bug 1037293 in linux "Intel gen7 graphics OpenGL 3.0 support on 12.04" [Medium,Fix committed] https://launchpad.net/bugs/1037293
<ogasawara> bryceh: lemme check
<bryceh> ogasawara, thanks
<rtg> kamal, Uploading linux_3.5.0-15.22_source.changes: done.
<kamal> rtg: I'll have another one for ya tomorrow ;-)   (tiny Cypress trackpad fix)
<rtg> kamal, I wait in breathless anticipation :)
<ogasawara> bryceh: looks like we're in our 3rd week of the cadence so I'd say EOW
<ogasawara> bjf: ^^ care to double check me on that
<bryceh> ogasawara, awesome, thanks.
<tacotaco> hi, does anyone have time to assist me with completing updating an EC2 instance to 1000hz timer ? I am a beginner but completed 95% of the process just stuck editing menu.lst 
<tacotaco> been following this guide http://wiki.freeswitch.org/wiki/Amazon_EC2#Updating_Kernel_Timer_to_1000HZ
 * rtg -> EOD
<bjf> ogasawara, bryceh, indeed - that precise kernel is in -proposed and should hit -updates by friday
<bryceh> bjf, perfect thanks
#ubuntu-kernel 2012-09-20
 * apw does not like the new colder world
<smb> apw, Mabe prepares you for the next ice age to come
<apw> maybe, cirtainly i need more clothes today
<smb> Or turn on more hardware
<apw> oh good idea, i could build some kernels
<metaphysician> I want to try out Linux 3.5 on precise. How can I install it?
 * cking wonders why iso.qa.ubuntu.com is so slooooow
<siretart> ogasawara: I can confirm that aufs in the kernel upload from yesterdays works. at least I was finally able to deploy the first quantal machine today with fai and live-boot :-)
<doko> apw, rtg, ogasawara: gcc 4.7.2 is there. no kernel related changes (a C++ fix, a LTO fix, a documentation fix). the only visible change for you is the version bump
<apw> doko, thanks for the heads up
<rtg> doko, we'll have one more upload before Beta 2 I think
<doko> so it should be fine to upload now, if you update it again for the beta?
<rtg> doko, yes
<doko> ok
 * henrix -> lunch
<rtg> ogasawara, https://wiki.ubuntu.com/Kernel/Dev/Meta-Pkgs is a whiz bang page :)
<ogasawara> rtg: they teach you how to make pretty picture in management 101
<rtg> :)
<apw> ogasawara, what do you use for those flwo diagrams ?
<ogasawara> apw: the google docs drawing
<apw> ahh
<cking> another ppoke in the eye for libreoffice
<pstolowski> hello, is there any chance to get https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1042213 into beta 2 or into Q final? I think the issue has been spotted and respective fix is identified in newer kernel, and it should be a matter of cherry picking it. I can test a candidate kernel if that helps.
<ubot2> Launchpad bug 1042213 in linux "[quantal] Kernel oops with NFS mount" [Medium,Confirmed]
<ppisati> apw: do you use imap with mutt? and do you connect directly with the imap server? or do you use offlineimap?
<apw> ppisati, yes i do, i use offlineimap as you say
<ppisati> apw: mutt
<ppisati> apw: 's imap implementation is quite crappy
<ppisati> apw: it took me a bit to fine tune it
<ppisati> apw: now it doesn't hang and gmail doesn't boot me out anymore
<ppisati> apw: but still, browsing a mailbox could be a bit frustating still
<ppisati> i'll give offlineimap a try
<apw> ppisati, yeah i concur, i just use offlineimap it does a nice job
<bjf> brendand, are you going to get precise testing wrapped up today?
<brendand> bjf - most likely. or early tomorrow
<bjf> brendand, today would be nice. we don't promote kernels to -updates on Fridays
<brendand> bjf - ok, i'll put the gas on then
<brendand> bjf - we are sprinting this week so bandwidth has been a bit lower, but it's mostly done
<cking> apw, arges how about e08733446e72b983fed850fc5d8bd21b386feb29
<arges> cking, this is interesting
<arges> cking, this is already in natty i believe
<cking> arges, yep, my mistake
<arges> yes
<arges> np. looked good
<rtg> cking, have you watched http://linuxplumbers.ubicast.tv/videos/acpi-component-architecture-acpica/ yet ?
<cking> funnily enough, I'm working through these, and this was on my list to watch this week
<rtg> cking, so am I :)
<cking> rtg, I was working through the slides on this 2 days ago, made me update fwts a bit 
<MestreLion> guys, I need help. I'm trying to use a program to re-write the EDID data on my plasma 42" hdtv,  but i'm unable to access my I2C/SMBus programatically. There's no /dev/i2c* , no listing in i2cdetect, etc... any directions on how to troubleshoot it?
<MestreLion> Some relevant info: motherboard Asus M4A89GTD (AMD 890 chipset), modprobe i2c-dev shows no output or errors, and I'm able to read the EDID fine using get-edid. What can I do? Any relevant log to look at?
<sforshee> apw, 9ca8f72a9297f2052d806bd1111e176533aa69bd
<ppisati> brb
<rtg> ppisati, are you thinking about a rebase against more recent Quantal master ? there are some ecryptfs fixes (though I dunno if armhf uses it), plus at least one CVE patch. aufs is also enabled.
<apw> MestreLion, i am not sure we offer any way to write to the EDID, there is some stuff in P onwards to allow you to replace the kernel idea of the EDID for KMS drivers though
<apw> MestreLion, i don't exactly recall how to use it, the X guys should remember as they asked for it :)
<apw> (#ubuntu-x)
<MestreLion> apw: I already found a software that does that using python-smbus
<MestreLion> the problem is neither python-smbus nor i2c-detect -l lists *any* i2c bus
<MestreLion> and i don't have any /dev/i2c-*  file
<apw> i don't think i am expecting to see the i2c interfaces on VGA ports exposed under KMS anyhow
<apw> writing to your EDID sounds like a recipe for disaster though, do you need to change it
<apw> or only to make you linux box think it says something different
<MestreLion> apw: my plasma 42 hdtv keeps saying 50HZ is its preferred mode in all resolutions
<apw> then you might 
<apw> just be able to override its EDID rather than replace it on the device
<MestreLion> so any fullscreen game, or app, or switching monitors in my dual-view makes the TV go back to 50Hz
<MestreLion> yes, if I could spoof the EDID, that would be fine too... any directions?
<apw> MestreLion, there is a place you can put overrides i believe, i forget how it works though.  i would ask on #ubuntu-x they should know as it was something they requested and presumably use
<MestreLion> i'll give it a try, thanks!
<MestreLion> but, still... isn't it odd not to have any i2c in /dev? is this normal?
<ppisati> rtg: i'll do tomorrow
<rtg> ppisati, ack
 * rtg -> lunch
 * henrix -> EOD
 * smb -> EOD
<rtg> apw, just posted on LKML this morning: [RFC] Second attempt at kernel secure boot support
<rtg> apw, [PATCH 00/13] overlay filesystem: request for inclusion (v15)
<apw> rtg thanks
 * ogasawara lunch
<kamal> rtg: do you have an ETA for the next quantal master version?
<rtg> kamal, I think we'll have one final upload before B2
<rtg> Tuesday at the latest
<kamal> rtg: ok many days off yet -- I won't wait for it.  thanks
 * rtg -> EOD
#ubuntu-kernel 2012-09-21
<cking> apw, https://wiki.ubuntu.com/Kernel/Debugging/USBearlyprintk
<apw> cking, god that is a disaster till you have figured out the physical port, the port N you need to use, and the orientation of the unkeyed device
<cking> apw, yep,  makes debugging so much fun fun fun
<apw> cking, we should have a wiki for which holes and which numbers to use you know
<cking> apw, what? for all models?
<apw> for models where someone figures it out, perhaps
<cking> I suppose that makes sense - as long as they don't get moved around on different revisions
<apw> nnng, please no
 * cking has a motto: "if they can change it, they *will* change it"
<apw> you missed *randomly*
<cking> they do it in a  systematically randomized way just to keep us on our toes
 * henrix -> (early) lunch
 * cking -> late lunch
<rtg> jsalisbury, re: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1041883/comments/66, keep a lazer like focus on the original reporter as long as you can hold his attention. The other dudes need to file separate bugs.
<ubot2> Launchpad bug 1041883 in linux "Recent patch to asus-wmi module makes system unbootable" [High,In progress]
<jsalisbury> rtg, ack.  Allot of noise in that bug, but I'll focus on the original bug reporter
<rtg> jsalisbury, yeah, I think the other noise _is_ likely about asus-wmi, but I think the original reportwer is going to have a different problem. I'm betting its gonna bisect to CONFIG_X86_X32.
<jsalisbury> rtg, (quantal-amd64)jsalisbury@tangerine:~/bugs/lp1041883/ubuntu-quantal$ git bisect visualize | grep commit
<jsalisbury> commit d3a67dbe37d32ba10da0de2f14151d606856e5d2
<jsalisbury> commit 41d572a1eb382b033a93f80e01450425d641dc05
<jsalisbury> commit 2d3e1c176760c110a6237be229a19f61bcc2156d
<jsalisbury> commit c7f240a0b0ea5c489aabf65b3399f192a6f6fc53
<jsalisbury> commit 9e907a96efa9a7f497f1943590e18c5c39d61750
<jsalisbury> rtg, yup, that is 9e907a96 :-)
<jsalisbury> rtg, we should know today
<rtg> jsalisbury, cool
<rtg> jsalisbury, you can blame apw for CONFIG_X86_X32
<jsalisbury> rtg, heh
<smb> sforshee, Errm, was it you playing with (beside other things) dualgfx (optimus)?
<sforshee> smb, not recently. A while back I think I backported something to allow us to turn off the discrete GPU since we can't use it anyway, that's about it.
<sforshee> smb, I've been messing with hybrid graphics on Macbooks recently tho
<apw> rtg, thanks :)
<smb> sforshee, Hm ok. Asking cause someone came up with a black screen bug on #ubuntu-devel and I guess cjwatson and I struggle not to be responsible... :-P bug 1053269
<ubot2> Launchpad bug 1053269 in grub2 "black boot" [Undecided,Confirmed] https://launchpad.net/bugs/1053269
<rtg> apw, anytime.
<sforshee> smb, just read through the backscroll. Usually on optimus the integrated GPU always drivers displays and discrete is just intended to be used for processing power, so it seems right that i915 is the primary device. Although sometimes dGPU is used for some outputs.
<sforshee> smb, not really sure about using nvidia binary module with optimus, I never tried it
<smb> sforshee, Hm, yes. I guess I am confused as to how vt_handoff (or its removal) changes things... And something seems to cause the discrete card to get activated...
 * apw pops out for a couple
<sforshee> smb, the discrete card is probably turned on at boot and will show up on the PCI bus, so it's not surprising that the nvidia module gets loaded. That's fine as long as whatever is trying to display stuff uses the integrated card.
<sforshee> smb, assuming that nvidia binary driver behaves well in dual-graphics setups, which I'm unsure about. But it likely won't detect any attached displays.
<smb> sforshee, There is that bbswitch command fiddling around with things. Whatever that does
<sforshee> smb, I think it's trying to turn off the discrete card
<smb> sforshee, off and on
<smb> [   18.060525] bbswitch: Succesfully loaded. Discrete card 0000:01:00.0 is on
<smb> [   18.062519] bbswitch: disabling discrete graphics
<smb> [   18.062773] bbswitch: Result of Optimus _DSM call: 11000059
<smb> [ 1437.177242] bbswitch: enabling discrete graphics
<sforshee> smb, so it does
<smb> (ok much later...)
<sforshee> smb, bah and it changes the vga decodes
<smb> sforshee, Though I realized that there is a long time in between...
<sforshee> smb, yeah seems that's probably too late to be causing the problem as described
<smb> Right
<deffrag> Hi! I have a code prepared and compiled on x86_64 architecture which I moved to and compiled on ARM(Beagleboard XM). And, it worked without errors exactly as it would on x86_64. Same commands were executed to compile and run, natively compiled. I'm curious to know what is the difference? What changes in gcc in arm (?) made it possible?
<sforshee> smb, although it seems vga decodes are switch to the discrete GPU about 1.7 seconds in
<smb> sforshee, *sigh* You could as well have told me about nomudflap as I have as much idea what this is/does as I had with the other before looking into the man page. :)
<smb> kamal, I hear you may be "interested" to have a look at bug 1053269
<ubot2> Launchpad bug 1053269 in linux "black boot" [Medium,Confirmed] https://launchpad.net/bugs/1053269
<vanhoof> jsalisbury: yo
<vanhoof> jsalisbury: weren't you bisecting some odd Intel wifi bug a month or so back, random drops/hangs?
<herton> jjohansen, would you need a respinned ti-omap4 kernel with the changelog fixed? (re: bug 1047347)
<ubot2> Launchpad bug 1047347 in kernel-sru-workflow/security-signoff "linux-ti-omap4: 2.6.38-1209.26 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/1047347
<herton> ppisati, ^
<vanhoof> jsalisbury: I seem to remember seeing that on a bug list, or maybe it just flew by me in bug mail
<ppisati> herton: that's what the commit says
<ppisati> herton: and it says it's a cherry-pick
<ppisati> (cherry picked from commit 06b6a1cf6e776426766298d055bb3991957d90a7)
<ppisati> i wonder if the original commit is wrong too at this point
<ppisati> jjohansen: ^
<herton> ppisati, natty master is ok, I think the mistake came when it was applied on ti-omap4
<ppisati> yes
<ppisati> no
<ppisati> wait a sec
<ppisati> http://kernel.ubuntu.com/git?p=ppisati/ubuntu-natty.git;a=commit;h=e172e91df99f8841287b02d27b43d85801bc2f4d
<ppisati> it's wrong in natty master too
<ppisati> CVE-2012-3340
<ubot2> ppisati: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3340)
<ppisati> while jj says:
<ppisati> "CVE-2012-3340 is incorrect, it should be CVE-2012-3430"
<ubot2> ppisati: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3340)
<ubot2> ppisati: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3430)
<jsalisbury> vanhoof, Let me double check 
<jsalisbury> vanhoof, here's a list of the bugs I'm bisecting: https://bugs.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=performing-bisect
<jsalisbury> vanhoof, could you be thinking of bug 1050573 ?
<ubot2> Launchpad bug 1050573 in linux "No WIFI network activity after resume" [Medium,Incomplete] https://launchpad.net/bugs/1050573
<henrix> ppisati: i can't see that problem in ubuntu-natty/master...
<herton> ppisati, http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=commit;h=b449827c669916b39ee91b55d26f74ca55cd5fa5 (origin/master)
<vanhoof> jsalisbury: might be, let me take a peek
<vanhoof> jsalisbury: thanks man
<ppisati> bah
<ppisati> they probably flipped the numbers during the cherrypick
<kamal> smb: thanks for the heads-up about bug 1053269.   *sigh*
<ubot2> Launchpad bug 1053269 in linux "black boot" [Medium,Confirmed] https://launchpad.net/bugs/1053269
<smb> kamal, Always glad to get rid of... err be of service. :)
<kamal> smb: grrrr!  ;-)
<ppisati> herton: http://kernel.ubuntu.com/git?p=ppisati/ubuntu-natty.git;a=shortlog;h=refs/heads/ti-omap4
<ppisati> herton: done
<rtg> smb, since you've got the reproducer, any chance you can bisect ?
<smb> rtg, for what?
<rtg> bug #1053269 ?
<ubot2> Launchpad bug 1053269 in linux "black boot" [Medium,Confirmed] https://launchpad.net/bugs/1053269
<smb> rtg, no optimus machine in my home
<rtg> smb, oh, I guess I thought you'd run into this one yourself
<smb> No, that someone who came to #ubuntu-devel and I just happened to be on cjwatsons radar because I was inquiring about bug 1038055
<ubot2> Launchpad bug 1038055 in linux "graphics fail to initialise correctly, in kvm with cirrus graphics (after LUKS install)" [High,Confirmed] https://launchpad.net/bugs/1038055
<rtg> smb, ah, wrong place at the wrong time
<smb> rtg, Yeah, and no deed goes unpunished. :)
<herton> ppisati, we will need an upload number bump to fix this one. But lets wait if jjohansen needs the respin
<rtg> smb, no _good_ deed
<ppisati> herton: ack
<smb> rtg, I would not dare to call the patch I came up with for that bug "good"
 * ppisati rush out -> gym, sushi and Talisker (it's friday night)
 * smb already went to cider
<ogra_> gah, i missed him
<henrix> ppisati: hmm... talisker
 * henrix assumes he's talking about the scotch
<ogra_> is there any other talisker ? 
<henrix> ogra_: not that i'm aware of :)
<smb> Well probably only Talisker, the settlement... :-P
<henrix> heh
<cking> 316 packages can be updated. - turn your back a few days and that's what happens on your dev boxes
<skaet> rtg,  is there any chance that we can get fixes for: https://launchpad.net/bugs/1050855 and https://launchpad.net/bugs/1049088 for Beta 2?
<ubot2> Launchpad bug 1050855 in linux "External USB keyboard stops working when d-i starts on mac mini" [High,Confirmed]
<rtg> skaet, I doubt we'll find a fix for bug 1050855 in time. I also don't think bug 1049088 is a kernel problem given Marc's comment #8.
<ubot2> Launchpad bug 1050855 in linux "External USB keyboard stops working when d-i starts on mac mini" [High,Confirmed] https://launchpad.net/bugs/1050855
<ubot2> Launchpad bug 1049088 in linux "Unity crashes at login with nouveau driver" [Medium,Confirmed] https://launchpad.net/bugs/1049088
<deffrag> Why in the image used - http://cdimage.ubuntu.com/releases/12.04/release/ubuntu-12.04-preinstalled-server-armhf+omap.img.gz - for Beagleboard xm, it is not possible to have DSP working? Why 12.04 has no dsp bridge?
<infinity> deffrag: People in #ubuntu-arm are probably more likely to have interesting answers to that.
<deffrag> Ok
<kamal> rtg: I'm looking at bug 1053269 now -- its clearly the fault of one of the two additional backlight patches we crammed in for 15.22 (the reporter says that 15.21 -- my original set of backlight patches -- works okay for him)
<ubot2> Launchpad bug 1053269 in linux "black boot" [Critical,Confirmed] https://launchpad.net/bugs/1053269
<rtg> kamal, ok, thats good to know
<rtg> kamal, the bisect ought to be easy :)
<kamal> rtg: :-)
<kamal> is it "A", or is it "B"?
<cking> or both?
 * cking --> EOW
<henrix> rtg: re the patch you just sent for CVE-2012-3412
<ubot2> henrix: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3412)
<henrix> rtg: i guess you also want to revert the previous 5 commits, right?
<rtg> henrix, which 5 ? I thought we gave up on the core networking patches ?
<henrix> rtg: no, they have been applied (and released)
 * henrix goes double-check
<rtg> henrix, oh, shit. I guess we didn't.
<henrix> rtg: yep, they've been released this cycle
<henrix> rtg: so, we;ll need to revert them first
<rtg> henrix, lemme think about it for a bit. I'll resend.
<rtg> too damn many kernels....
<henrix> rtg: ack. in the mean time, i'll try to have the bug reporter testing ben's patch with the previous 5 commits reverted
<rtg> henrix, has the USN been published ?
<rtg> henrix, we didn't actually have a reproducer for that one, did we ?
<henrix> rtg: not sure. maybe jjohansen...?
<henrix> rtg: i'm just looking at this because of a regression (bug #1052861)
<ubot2> Launchpad bug 1052861 in linux "After upgrade to new kernel version, machine crashes after a few hours of uptime" [High,Confirmed] https://launchpad.net/bugs/1052861
<rtg> henrix, well, as Ben pointed out, the core net patches likely weren't suitable for a stable update. In retrospect I agree. herton and I must have been on drugs that day.
<henrix> heh :)
<herton> rtg, ack sent
<herton> and yes, needs the reverts, as being released already
 * smb -> EOW
<herton> rtg, I think in retrospect we are just making sure to have things fixed, we are not sure always if we will get flamed/ignored when asking upstream about backporting :P
<rtg> herton, pull request in a few minutes....
<hggdh> ogra_: there still?
<jjohansen> rtg, henrix: yep USNs have been published for CVE-2012-3412 in lucid, natty and oneiric
<ubot2> jjohansen: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3412)
<rtg> jjohansen, do you have a procedure to re-issue a USN ?
<infinity> jjohansen: Oh hey, you're around.
<rtg> jjohansen, we're only re-working Lucid.
<jjohansen> rtg: yes we can edit USNs
<infinity> jjohansen: Respinning for the typo in https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/1047347 seems unlikely.  Are you happy to update bug tasks and let it be released despite the typo?
<ubot2> Launchpad bug 1047347 in kernel-sru-workflow/security-signoff "linux-ti-omap4: 2.6.38-1209.26 -proposed tracker" [Undecided,In progress]
<jjohansen> infinity: hrmmm, that one is problematic as it breaks the tooling give me a few minutes to figure out whether we can/should get around it
<infinity> jjohansen: Mmkay.
<jjohansen> infinity: okay, I'll clear it through and fix it up manually on our side
<infinity> jjohansen: Alright, cool.  Thanks.
<deffrag> infinity: Seems like engaging DSP on arm platforms is rare topic. I asked in #beagle then, as you suggested,  in #ubuntu-arm
<deffrag> or maybe I'm not asking it right.
 * rtg -> lunch
 * henrix -> EOW
 * ogasawara lunch
 * pedrinho home
<jjohansen> bjf, sconklin: err what happened to the shank bot not working to get uploads promoted on friday
<infinity> jjohansen: Friday morning was considered vaguely Thursday night.  Or something.
<jjohansen> infinity: hrmmm okay /me needs to go back and look at what was agreed on
<herton> jjohansen, it was agreed until 18:00 UTC on Friday
<jjohansen> herton: hrmm okay thanks, I think we may need to revisit that at UDS, but for now I'll stop whining
<infinity> I think as long as we still have people around in some timezone who can fix things (so, the Americas, in this case), we're probably okay.
<infinity> But Friday afternoon in the US is right out, since we won't see problems until everyone goes home.
<infinity> But it's all a bit wishy-washy and hand-wavy, as we can't reliably predict when the world will explode from a bad update, we can only assume it's "probably an hour or two after it's released".
<bjf> jjohansen, i'd could live with not doing any on friday but we need to light a fire under regression testing, specifically cert. testing.
<bjf> jjohansen, they consistently wait too long to get started. the other "option" is to not wait for cert. testing.
<jjohansen> bjf: yeah I remember that being an issue, we can live with it now and re-eval how it is going at UDS
 * rtg bugs out for the week
<infinity> Things seem to be going vaguely smoothly right now, except for the occasional hiccup.
<infinity> But always making sure things are ready by Thursday afternoon would be swell.
<jjohansen> infinity: yep
<infinity> Or just changing the initial cadence, so we start the whole process a day earlier.
 * jjohansen recalls that had problems too
<infinity> If you shift the PPA upload earlier, then the release might land in the middle of the week, profit?
<bjf> infinity, we do the ppa upload as soon as we have the kernels ready
<infinity> (Assuming it really does take an exact number of days to go through all the steps)
 * jjohansen thinks pokes the staffing for the weekend beast :)
<bjf> infinity, people understand monday-friday. running thursday to thursday was confusing for everyone
<infinity> bjf: Yeah, that's a fair point.
<infinity> bjf: It's why I tend to find things like progress meetings mid-week disjointing too.
<bjf> ack
<infinity> "Wait, I had  half a week before, and half a week after, the previous half week doesn't register as a thing".
<jjohansen> infinity: but then you have the whole weekend to work on things and make progress :)
<infinity> Anyhow, the current process seems to be running mostly smoothly.  It may be worth hallway conversations to see if we can tweak it, I'm not sure it's worth a bikeshedding session.
 * bjf is going to driver over and smack jjohansen
<jjohansen> infinity: oh no, didn't mean a session, just a quick out out of band hallway conversation
<jjohansen> hehe
<infinity> Yeahp, totally down for that.  Grab me in CPH. ;)
#ubuntu-kernel 2012-09-23
<zenx> Hi, are the default configs supposed to compile? I am asking because I don't know if I should submit a bug on launchpad
<zenx> the answer seems to be no
<zenx> maybe for a stable version
<TazzNZ> Hey All
<TazzNZ> Can someone please point me in a general direction for debugging the e1000 driver in 12.04. We have an issue where by it stops passing traffic after 1000's of little connections
<TazzNZ> this is in an ESXi 5.1 host. Swapping to vmnet3 "solves" the issue, but this has other problems :)
<TazzNZ> thx
#ubuntu-kernel 2013-09-16
<macsplean> hello
<macsplean> i am currently running 3.2.0.25 ... should i upgrade?
<ppisati> moin
<smb> morning
 * apw complains about the cold :)
<infinity> apw: Nice change from complaining about the heat.
<apw> infinity, i don't discriminate
<smb> infinity, Looks like we may get 30Â°C and a few thunderstorms
<apw> smb, 30, we have more like 9
<smb> infinity, And my condolences again ;-P
<smb> apw, Right now its 14 but over there
<apw> oh heh
<smb> If I ever make it
<ppisati> brb
<apw> smb, at least youi don't need to pack any clothes if it is that hot
<smb> apw, Given the US Americans liking for AC I have to
 * apw notes that typing with a wacking great cut across ones index finger is sub-optimal
<smb> apw, Maybe you are more careful with your keys next time. :-P
<apw> smb, not a chance of me being more careful, i am too dumb
<smb> apw, Isn't impatient a more fitting description. :)
<apw> smb, both i suspect
 * henrix -> lunch
<mck182> hi, I just noticed I've been hit by this bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/823106 - using 13.04, standard kernel etc., so I've tried to update to kernel 3.9.0 from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.9-raring/ but after installation, all of the dkms cannot be built - here's nvidia dkms build log http://paste.kde.org/p99289c62/
<ubot2`> Launchpad bug 823106 in linux (Ubuntu) "Kernel panic - not syncing: smp_callin: CPU1 started up but did not get a callout on macbook running oneiric" [Undecided,Confirmed]
<mck182> any ideas about either the bug or the failing dkms?
<apw> mck182, well the 3.9 kernel is an unsupported mainline build, and more importantly is a newer version than that in 13.04, which was v3.8 so it is entirly likely the dkms packages are not compati
<apw> compatible with v3.9
<apw> you may have better luck with the versions of the dkms packages in devel as they have been built agianst all of the main releases in between
<mck182> ah, I may try that
<bjf> ppisati, got a precise ti-omap4 kernel for me :-)
<ppisati> bjf: ah, i forgot
<ppisati> bjf: but i'll do it now
<bjf> ppisati, thanks
<ppisati> bjf: what's the tracking bug?
<bjf> ppisati, bug 1223607
<ubot2`> Launchpad bug 1223607 in Kernel SRU Workflow promote-to-proposed "linux-ti-omap4: 3.2.0-1437.56 -proposed tracker" [Medium,Confirmed] https://launchpad.net/bugs/1223607
<ppisati> bjf: but that's marked as 'fix released'
<bjf> ppisati, that's because you put the version for one that had been released. just go ahead and fix up the title and description and I'll "fix" the rest.
<ppisati> bjf: ok
<rtg> apw, uploaded goldfish with the tools package name changes
<rtg> (and other stuff)
<rtg> xnox, ^^ plus you config changes
<xnox> rtg: \o/ thanks =) meta upload as well? (as there is no i386 meta yet)
<rtg> xnox, yead, was waiting on that until apw and I sorted the tools package names
<rtg> I'll git 'er done soon
<xnox> rtg: alright, cool ;-)
<FernandoMiguel> ah got in
<FernandoMiguel> my network card isn't working with the latest kernel
<FernandoMiguel> 3.11.0-7
<FernandoMiguel> on ubuntu +1
<FernandoMiguel> and ubuntu-bug linux is not helping ....
<FernandoMiguel> The problem cannot be reported:  This is not an official Ubuntu package. Please remove any third party package and try again.
<ppisati> bjf: ok, i pushed a new kernel
<ppisati> bjf: http://kernel.ubuntu.com/git?p=ppisati/ubuntu-precise.git;a=shortlog;h=refs/heads/ti-omap4
<bjf> ppisati, cool, thanks
<ppisati> bjf: and updated the tracking bug
<rostam> HI is there a way to o monitor changes to some memory map area in user land? thx
 * rtg -> EOD
#ubuntu-kernel 2013-09-17
<ppisati> moin
 * ppisati -> reboot
 * apw yawns
<ppisati> bug 1223261
<ubot2`> Launchpad bug 1223261 in flash-kernel (Ubuntu) "dtb concatenation support" [Undecided,New] https://launchpad.net/bugs/1223261
<ppisati> lool: i simplified the flash-kernel dtb concatenation patch, can you give it a look? thanks
<ppisati> lool: ^
<ppisati> apw: aren't you suppoed to be in NO by now?
<apw> ppisati, not me
 * ppisati is officially unable to correctly read and understand emails
 * ppisati ponders about going early to the gym...
<apw> ppisati, when the mind ain't willing it is time for the gym
<infinity> ppisati: Want to bug me about that patch when I'm in New Orleans?
<infinity> ppisati: (The f-k one)
<ppisati> pain is what happens to you while you are busy working out...
<zequence> apw: Sorry to answer you so late :). Where are you currently hosting -lowlatency for saucy?
<ppisati> infinity: i'll do
<apw> zequence, in a personal tree, if you can make the saucy tree i'll push it in from there
<zequence> apw: git@github.com:ubuntustudio-kernel/ubuntu-saucy-lowlatency.git
<apw> zequence, thanks
<zequence> apw: I have problems doing the first push sometimes. Gets stuck in the middle.
<apw> zequence, i don't seem to be able to push at all, see /query
 * apw goes for an emergency reboot
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<apw> zequence, ok i have pushed up what i have in my repo so in theory you can check it out as you would for any other release and rebase it
<apw> zequence, i am guessing you could shove it into the same PPA and i can review it there and copy it over
<apw> and ... you know the rest of the plan
<zequence> apw: Thanks :)
<guzzles> I am experiencing a lockup with no useful error messages (no panic). I have tried netconsole, and I get no information there either. What further steps should I take to get useful information?
<guzzles> ubuntu 12.04 kernel 3.2.0-23, 32-bit PAE
<bjf> guzzles, when it comes back up "ubuntu-bug linux" in a console window
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
<guzzles> bjf: the system was installed command-line-only, so I'm going to need to install the apport stuff. I'll play with it and try that out. Thanks
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues September 24th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
#ubuntu-kernel 2013-09-18
<ppisati> moin
<apw> ppisati, moin
<ppisati> apw: moin
<apw> man that was an early one too
<ppisati> apw: neh, i usually wake up way earlier than that
<apw> wierd gym lover :)
<zequence> Anyone available for a fairly simple upload (artwork update)? lp:ubuntustudio-menu
<zequence> Ah, sorry. Wrong channel :)
<apw> zequence, i might be able to help if it is truly trivial :)
<apw> oh i so did not want to know anything about autopkgtest environments
<lerra> Hey guys, im having a couple of machines running different versions of the kernel 2.6.32-*-server (mostly 40 and 42), I have a vmcore file that I am trying to analyse but I cant find a debug kernel for that but I manage to analyse the binary with strings and manage to get the following content from http://pastebin.com/hCW6W8p9 
<lerra> Anybody seen this ? Its basically a postgres hammering (300-600mb/s) the system (on a mounted xfs partition)
<apw> lerra, not seen that befoer indeed.  the oops says that the thread overran the stack, which if accurate is very bad
<apw> lerra, have you looked on ddebs.ubuntu.com for the ddebs ?
<apw> lerra, and those seem anchient kernels
<apw> lerra, ok i can see -40 on ddebs.u.c, but -42 seems to be awol, but the latest is -51 so we are a heap of pain away from soemthing current here
<apw> lerra, i would if you can see if you can get something a bit more recent in there
<lerra> in ddebs ? I did check it and noticed the same as you :)
<zequence> apw: Thanks. I had forgotten there's a procedure for this, i.e. file a bug and subscribe ubuntu-sponsors. Seems we already got it uploaded :)
<lerra> Where did you find the -40 kernel ? and what do you mean with awol ?
<lerra> found http://ddebs.ubuntu.com/pool/main/l/linux/linux-image-2.6.32-40-server-dbgsym_2.6.32-40.87_amd64.ddeb
<apw> zequence, ok good
<apw> lerra, yeah -40 seems to be where you just indicated, the -42 is missing, but that is so old now i suspect there is no hope of recovery
<lerra> I only got a vmcore from a -42 but I will try and see how far I can go with that
<apw> well that stack you indicated clearly shows a very very deep xfs stack
<apw> and deep stacks are illegal, so if it is real, and it looks believeable at least
<apw> then xfs is probabally at fault.  there may be fixes for that in later kernls and you are some 10 abi's behine
<apw> behind
<apw> (awol == absent with out leave, ie missing)
<lerra> oki, will see if I can dist upgrade it to 12.04 from 10.04
<lerra> or maybe a backported kernel
<apw> lerra, i was more thinking the latest kernel on the release
<apw> lerra, at least there if it reporoduces you know you are on the latest and we have debug symbols
<lerra> basically to the -51 version, right ?
<lerra> even 49, I will see how I can proceed
<apw> lerra, i would say the one in -updates if you are going anywhere
<lerra> thanks apw, very helpfull, not to mutch documentation on this out there
<apw> lerra, np latest is:      linux | 2.6.32-51.113 | lucid-updates | source
<jafeha> hi, i'm looking for someone with insights into intel lynnfield cpus on ubuntu 12.04 lts (enablement stack / kernel 3.8.0-30-generic). can anyone help me?
<jafeha> my question is: i'm running my ubuntu 12.04 with an lynnfield i5 760, which officially has no hyperthreading support. if i check /proc/cpuinfo i get the cpuflag "ht" which should indicate hyperthreading. ht is not activated on the host as far as i can see: lscpu tells me that i've got only one thread per core. so could i actually turn on the hyperthreading bootflag and acutally get more threads per core? or is th
<cking> jafeha, i was under the impression that the i5 760 has 4 cores and not hyperthreads
<apw> i have the feeling that the ht flag is a lie in some cases, "else windows does not see all teh CPUs" or something
<jafeha> ok thank you cking and apw thats what i already thought. i just wanted to be sure. there were some discussions on the i5 760 enabling ht, but it did not make it into the specs. so how much can i actually trust those flags being shown in cpuinfo?
<cking> jafeha, the cpuinfo flags come from what cpuid is reporting on the CPU, so one has to trust the CPU not to be lying I guess
<jafeha> hum, what a mess. :D
<jafeha> what would actually happen if i tried turning it on in the bootflags?
<apw> jafeha, i would say that the key is how many siblings are reported, as the kernel will use all the ones it finds it does not use the HT flag to determin which cpus to enable
<jafeha> last thing i found out about that was that the generic kernel won't activate ht without using ht=on as a boot parameter. thats why i'm asking.
<arges> hey guys, is there a tool that automagically pulls in patch deps (based on context) when cherry-picking? doing it manually with git blame / log is fun and all
<apw> arges, not that i know of
<arges> i'll put that on my list of 'projects to work on when you have the time', if i ever have the time
<apw> jefferai, are you sure, where have you seen that documented
<apw> arges, i generally use selective log to see what all else changes the same files
<arges> yea git log -S'blah' /path
<apw> jafeha, are you sure, where have you seen that documented
<apw> jafeha, i can find no documentation for that and it doesn't fit my experience either
<apw> jafeha, i have tended to get the CPU name out of cpuinfo and look that up on intel (or whoevers) website to be sure
<xnox> sforshee: hello, stgraber says you are good with backlit brightness. I can echo values between 100 -> 4882 into /sys/class/backlight/intel_backlight/brightness but the keyboard buttons / brigtness settings in the gnome control centre.
<xnox> sforshee: any idea what I can tweak to make the buttons work? =)
<sforshee> xnox: are there other devices under /sys/class/backlight?
<xnox> sforshee: yes, acpi_video0
<sforshee> xnox: userspace is going to try to use that ahead of intel_backlight
<sforshee> does writing values to its brightness file work?
<xnox> sforshee: nope, no effect.
<sforshee> xnox: a workaround is to pass acpi_backlight=vendor to the kernel
<sforshee> but you should probably file a bug
<xnox> sforshee: i had that, didn't work. (had that in grub cmd line)
<stgraber> xnox: that's not the line I gave you, did you try that specific one before?
<xnox> stgraber: yeah, i had acpi_backlight=vendor before trying yours. (found it somewhere online)
<stgraber> k
<sforshee> xnox: do you have the acpi_video0 backlight when you boot with it?
<xnox> Hm: https://bugzilla.kernel.org/show_bug.cgi?id=50551
<ubot2`> bugzilla.kernel.org bug 50551 in Power-Video "ACPI uses acpi_video0 instead of intel_backlight for Intel GMA 4500M" [Normal,Closed: will_not_fix]
<sforshee> xnox: that's not a bug per se, the rules are that firmware interfaces should be preferred over raw interfaces (which is what a backlight from a graphics driver would be)
<sforshee> the bug is that acpi_video backlight doesn't work
<sforshee> but it's probably a firmware problem
<xnox> sforshee: stgraber: right so with acpi_backlight=vendor I get under /sys/class/backlight ideapad and intel_backlight
<xnox> intel_backlight works, ideapad doesn't.
<sforshee> xnox: bah. Yeah, and ideapad will be preferred over intel.
<sforshee> xnox: ikepanhc might be able to help you with the ideapad backlight
<sforshee> xnox: for the acpi one, file a bug and point me at it so I can look at your acpi tables
<xnox> sforshee: right. Well in the end I added xorg.conf.d snippet bug 1158934
<xnox> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1158934/comments/4
<xnox> I guess idepad should also be blacklisted just like the HP video.
<xnox> sforshee: is bug 1227188 ok?
<xnox> bug #1227188
<xnox> ubot2`: awake?
<ubot2`> Factoid 'awake?' not found
<xnox> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1227188
<sforshee> xnox, got it
<sforshee> xnox: can you also attach acpi tables? acpidump > acpi_tables.txt
<xnox> sforshee: attached: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1158934/+attachment/3827417/+files/acpi_tables.txt.gz
<sforshee> xnox: ta
<phillw> Hi folks, we seem to have narrowed down an issue with freezing to being a version of zram that doesn't work correctly in kernel 3.11.x How should this be reported?
<jsalisbury> phillw, A launchpad bug is best
<phillw> against kernel?
<sforshee> xnox: there's nothing obvious in the acpi tables to explain why the acpi_video0 backlight doesn't work. I wonder if the backlight iplementation there just doesn't work.
<jsalisbury> phillw, yes.  You can use the linux package.  For example, from a terminal run: ubuntu-bug linux
<phillw> thanks, will do and will add in all the we have found (the last part of the jig saw arrived about an hour ago)
<xnox> sforshee: i believe it just plain doesn't work, and the other one does =)
<sforshee> xnox: well some lenovos have another workaround which works, but not yours
<sforshee> it seems like lenovo doesn't test the acpi backlight implementation in their firmware on machines shipping with win8
<xnox> =/ i did have windows 8 pre-installed on it but no obvious "Certified for Windows 8" logos or some such.
<xnox> like I don't have "Windows 8 compatible sticker" only windows 8 sticker on the back.
<phillw> jsalisbury: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1227202 I've just asked those also affected to mark themselves as such.
<jsalisbury> phillw, great, thanks
<ppisati> infinity: you there?
<kdub> how would one compile a kernel for ubuntu touch?
<phillw> jsalisbury: I'd need some instructions as to how get the kernel into my machine and then see if the Error: /dev/zram0: unrecognised disk label  and Error: /dev/zram1: unrecognised disk label  disappear (that is assuming this fix will also solve that issue).
<jsalisbury> phillw, From a terminal, you can run:  sudo dpkg -i PACKAGE_NAME to install the two kernel .deb packages.
<jsalisbury> phillw, It would be the linux-image and linux-image-extra .deb packages
<jsalisbury> phillw, A reboot is then needed
<phillw> so, a wget into what directory ?
<phillw> is my home directory okay?
<jsalisbury> phillw, sure, any directory should work
<phillw> downloading (sorry for being a n00b to this!)
<jsalisbury> phillw, You can go to that link and click the two package names to download them: linux-image-3.11.0-7-generic_3.11.0-7.14~lp1227202v1_amd64.deb and linux-image-extra-3.11.0-7-generic_3.11.0-7.14~lp1227202v1_amd64.deb	
<phillw> wget'ing them into my ~/phillw directory now.
<phillw> jsalisbury: will it be 
<phillw> sudo dpkg -i linux-image-extra-3.11.0-7-generic_3.11.0-7.14
<phillw> to install them?
<jsalisbury> phillw, use the full file name, so: sudo dpkg -i linux-image-3.11.0-7-generic_3.11.0-7.14~lp1227202v1_amd64.deb
<jsalisbury> and sudo dpkg -i linux-image-extra-3.11.0-7-generic_3.11.0-7.14~lp1227202v1_amd64.deb
<phillw> okies, thanks!
<jsalisbury> phillw, install linux-image first then linux-image-extra
<phillw> will do, no hardware update bit, I take.
<phillw> see you shortly!
<phillw> jsalisbury: sudo parted -l still has the Error: /dev/zram0: unrecognised disk label  and Error: /dev/zram1: unrecognised disk label 
<phillw> To test against an ISO it would need injecting into one. And that is way, way beyond anything I even begin to understand!
<jsalisbury> phillw, thanks for testing.  Does the test kernel resolve bug 1227202, which is the freeze when using zram?
<jsalisbury> phillw, the other issue may need to be a seperate bug
<phillw> jsalisbury: that only appears when installing from an ISO. that kernel would have to be on the kernel of the ISO?
<jsalisbury> phillw, ahh, ok.  
<jsalisbury> phillw, yeah, creating a custom iso isn't very easy
<phillw> jsalisbury: the only other way would be to add it to the build list of lubuntu desktop amd64 daily and my set the system to do a rebuild of just that one ISO ?
<phillw> but, again, that is well beyond my limited abilities - possibly someone on the release team could help? We (lubuntu testers) would be more than happy to test it for you.
<jsalisbury> phillw, ack, I've been looking into doing that for another bug
<phillw> if you add it to that ISO, just give me a ping and we'll happily descend on it like a pack of vultures :)
<phillw> 2 days before freeze for next beta, so we do still have (a little) time.
<phillw> having said that, a poorly kernel is not really a candidate for beta testing.... But, not my call :)
<kdub> where does the nexus 4 kernel come from? I heard its stock CM kernel with some patches and config file changes...
<apw> kdub, that is a pretty accurate description
<kdub> apw, so... just the changes in the 'porting guide' is what's needed?
<apw> kdub, not sure what the porting guides says, but the end of the kernel log will show you what we did to it
<zequence-work> apw: orig file for linux-lowlatency saucy?
<infinity> apw: Did you want to do tools things to lowlatency too?
#ubuntu-kernel 2013-09-19
<ppisati> Hello world! :)
 * apw yawns at the world
<ppisati> apw: goodmorning sweetheart :)
<apw> ppisati, morning my lovely
<ppisati> :)
<ppisati> weren't dtb supposed to be treated like a stable ABI? weren't old dtb supposed to be supported by newer kernels?!?!?
<ppisati> bah, it boots at least...
<apw> ppisati, heh ... yeah right
<ppisati> apw: besides, the answer is no: http://lwn.net/Articles/560523/
<apw> ppisati, so the answer is yes they should, but not they don't cause we are crap at it
<ppisati> apw: right, so to be on the safe side, always update kernel and dtb together, else your board could stop booting
<apw> as the dts comes with the kernle in the main, that isn't so difficult, but it really really shouldn't
<ppisati> apw: well, problem is that on some platform the dtb is buried in the firmware so, everytime you install a new kernel, you *should* reflash the firmware
<ppisati> apw: but this time around, i just lost one day on my new bone, because the dtb that came with a 3.8 kernel
<apw> ppisati, sign
<apw> ppisati, sigh
<ppisati> apw: hanged 3.11 and i spent the entire yesterday debugging it 
<apw> what a royal pain in the ass, and something we need to socialise that there are real risks in upgrading
<ppisati> apw: and when i woke this morning i thought "well, what if it's the dtb?!?!?"
<apw> ppisati, that is the "shower brain" in action
<ppisati> apw: and that's it, now it kind of boot
<ppisati> right
<ppisati> it took me, one day to learn that the serial cable (a usb with an embedded ftdi chip) doesn't work if connected to a usb cable extension
<ppisati> another one to find out that the board provided dtb doesn't work with recent kernel
<ppisati> and now let's see...
<apw> ppisati, a struggle indeed
<ppisati> apw: well, not really, it's just that i loose way too much time on stupid details...
<ppisati> apw: anyhow, it's gym time! :)
<ppisati> see u later
<elmo> Sep 17 22:47:01 juju-prodstack-pes-r2-instance-1 kernel: [17844307.966142] INFO: rcu_sched detected stall on CPU 3 (t=1078390 jiffies)
<elmo> Sep 17 22:47:01 juju-prodstack-pes-r2-instance-1 kernel: [17844307.967042] sending NMI to all CPUs:
<elmo> ^-- does that interrupt userland 
<elmo> err
<elmo> ^-- does that interrupt system calls at all?  e.g. could it interrupt an fsync()?
<apw> elmo, i would not expect that to affect userland at all indeed, i would expect that to make all CPUs to service the NMI and continue where they left off
<elmo> apw: cool, thanks
<ChickenCutlass> apw, hi there,  I want to build a custom kernel in my PPA.  But everytime I bump the changelog and build a source pakcage, it blows away my changelog entry.
<ChickenCutlass> apw, what is the correct way to do this?
<apw> ChickenCutlass, you need to change the changelog in debian.<branch>/changelog not debian/changelog
<ChickenCutlass> apw, ah
<ChickenCutlass> apw, one more question.
<ChickenCutlass> apw, I have a new MacBook Air 6,2.  The haswell one
<ChickenCutlass> apw, and after applying 2 patches -- acpi and sound work
<ChickenCutlass> apw, can we get those into saucy?
<ChickenCutlass> what is the policy there
<apw> ChickenCutlass, its cirtainly possible, if they fix a bug, get them up on kernel-team@ with why they are needed
<ChickenCutlass> apw, ack
<cking> and the provenance 
<ChickenCutlass> cking, right.
<ppisati> infinity: ping
<infinity> ppisati: To be fair, the dtb/kernel dependencies are something that we're desperately trying to socialize as unnecessary and fix.  So, for the short term, we might want to upgrade in lockstep, but I disagree that we want to pass that knowledge on to end users, as it will become cargo-cult misinformation.
<ppisati> infinity: well, the problem is not that we want or not, if the kernel requires a new dtb, you better deliver it or be ready to debug your boot
<ppisati> infinity: anyhow, i pinged you about the flash-kernel patch
<ppisati> infinity: can you give it a look?
<infinity> ppisati: Right, but if the kernel requires a new DTB, it's because the previous one was broken.  Ultimately, they should be (and will be) decoupled.
<infinity> ppisati: I'll give the patch a look this morning.
<ppisati> infinity: that was the promise, but it doesn't work like that
<infinity> ppisati: No, no.  I know it doesn't work like that today, I'm talking about what the future is meant to look like, however.  And socializing "you'll need to pay attention or fix this" to end users sets up a bad expectation.  We should JFDI silently where we can, and in cases where vendors actually SHIP a firmware dtb that breaks with their newer kernels honestly, that's their fault.
<ppisati> infinity: agreed
<apw> ppisati, infinity, it is not obvious one can even change the thing when it is in the firmware
<apw> they should so contain a version number
<infinity> ppisati: Your awk magic for kvers comparisons is somewhat suspect.
<infinity> ppisati: I'm not so good with arithmetic, but I'm pretty sure that 2638 >> 311 >> 40, for instance.
<ppisati> infinity: hold on
<ppisati> infinity: i use just the first 2 number
<ppisati> infinity: 26 < 311 < 40
<infinity> Well, your first half is true. :P
<ppisati> infinity: ah right :)
<ppisati> infinity: well, when 4.0 is out we'll think about it :)
<infinity> Or we can just do it right now.
<infinity> I think I have some shell hackery in glibc to get this right.
<ppisati> infinity: nice
<infinity> Or you could just use dpkg --compare-versions, since having f-k without dpkg seems like an unlikely scenario.
<ppisati> infinity: but then i need to know against which pkg i'm installing/overwriting
<infinity> Eh?
<infinity> No, dpkg --compare-versions just takes version arguments.
<infinity> Or, there's this, from my glibc preinst:
<infinity> linux_compare_versions () {
<infinity>     verA=$(($(echo "$1" | sed 's/^\([0-9]*\.[0-9]*\)\([^.0-9]\|$\)/\1.0\2/; s/\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\).*/\1 \* 10000 + \2 \* 100 + \3/')))
<infinity>     verB=$(($(echo "$3" | sed 's/^\([0-9]*\.[0-9]*\)\([^.0-9]\|$\)/\1.0\2/; s/\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\).*/\1 \* 10000 + \2 \* 100 + \3/')))
<infinity>     test $verA -$2 $verB
<infinity> }
<infinity> CAUSE THAT'S SUPER READABLE.
<ppisati> OH MY GOD!!!
<infinity> I think I'll just use compare-versions.  I do that in initramfs-tools too.  It comes close enough to doing the right thing.
<infinity> ppisati: http://paste.ubuntu.com/6128952/
<ppisati> infinity: way better, ack
<infinity> I have no way to test that this actually works, but it looks sane enough to me.
<ppisati> infinity: hold on
<infinity> (I mean the overall patch, not my change)
<ppisati> infinity: i tested the overll patch going from 2.6.35 to 3.11 (and back)
<infinity> ppisati: It will fail if $kernel already points to $tmpdir/kernel before your code triggers.
<infinity> ppisati: Which would happen in the machine_id case.
<infinity> ppisati: (Since you can't do "cat $foo > $foo")
<ppisati> infinity: you mean the "append_dtb "$kernel" "$dtb" "$tmpdir/kernel""
<infinity> ppisati: Yeah, cause the previous block could have set $kernel to $tmpdir/kernel
<ppisati> infinity: right
<infinity>                                 append_dtb "$kernel" "$dtb" "$tmpdir/kernel.dtb"
<infinity>                                 mv "$tmpdir/kernel.dtb" "$tmpdir/kernel"
<infinity> That seems like it would solve the issue.
<infinity> Though maybe append_dtb itself should be more robust, so it doesn't let you do this.
<ppisati> infinity: debian has the same problem
<ppisati> http://anonscm.debian.org/gitweb/?p=d-i/flash-kernel.git;a=blob;f=functions;h=febf0d4af61dd59bb543798663f3f324d3c4fe68;hb=HEAD
<ppisati> line 502
<infinity> Indeed.
<infinity> Well, I'll fix it here for now. :P
<Notch-1> hi, i'm having throuble using the full power of a bulldozer cpu: with sensors i see that when fam15h_power-pci-00c4 power1 reaches the crit value (125w) the cpu is slowed down and i get a serius performance drop. it's a kernel configuration thing?
<ppisati> infinity: going out for dinner, see you later/tomorrow
<apw> Notch-1, those thresholds normally come out of the cpu ... reaching crit thresholds normally are a very serious boundary and we would expect throttling
<Notch-1> apw: any way around that? 
<Notch-1> apw: anyway it's odd: with another cpu with half the cores i have almost the same performance... and with this one the core/performance ratio it's stable until i use 5 core or more (out of 8). in other words i don't tink i'm getting the full power...
<apw> Notch-1, or the pysical envelope isn't able to disipate the heat that device can produce efficiently enough
<apw> ie 6 cores can outstrip the cooling ...
<Notch-1> apw: not a cooling issue, the heatpipe keeps the temperature below 60Â°...
#ubuntu-kernel 2013-09-20
 * apw yawns
<apw> rtg
<apw> heh, that makes so much sense
<Marex> Hi
<Marex> I'm hitting this issue here http://www.spinics.net/lists/git/msg217736.html when I try to clone from kernel.ubuntu.com GIT repositories
<Marex> would it be possible to contact the admins somehow ?
<Marex> The patch for the issue has to be applied server-side and is already in upstream GIT repository, see http://www.spinics.net/lists/git/msg217744.html
<apw> Marex, is that after a very long wait ?
<apw> Marex, and ... does dropping the -q help
<apw> was that you who said that ?
<Marex> apw: dropping -q fixes it, yes
<Marex> apw: it was me who posted to the git@vger ML, yes
<apw> so you have a work around at least
<Marex> apw: I'm invoking the git from Yocto build and as yocto adds the -q option to the git command line, the workaround is not much of an option
<Marex> apw: would it be possible to get a proper fix applied ?
<apw> Marex, well yokto isn't being very helpful now is it
<apw> Marex, everything is possible, though that machine is on lucid, ick
<apw> Marex, so i wouldn't bet my house on it
<Marex> can the patch not be backported on that version of git? the patch doesn't seem too big
<Marex> apw: the patches are here http://www.spinics.net/lists/git/msg217019.html http://www.spinics.net/lists/git/msg217020.html btw
<apw> Marex, in the unlikely event that a patch against tip still applied it might well be possible, though it would have to go thorugh the SRU process so its not going to be less than weeks
<apw> Marex, you would need to file a bug against git in the first instance 
<apw> Marex, though can you not work round this by cloning the tree locally and then just doing the yocto commands against a local mirror?
<Marex> apw: it's a server side bug, why would I work around it instead of fixing the server ?
<apw> Marex, presumably because you arn't running the command for fun but to get somethign donw
<Marex> apw: certainly, but it's not only me running into these issues
<Marex> apw: I just so happened to be too annoyed by it to push for a fix
<apw> Marex, the backport looks to be non-trivial, so its not going to happen right now
<apw> Marex, can you file a bug against git with the relevant info above in the description please, 'ubuntu-bug git' and give me the number, so i can thnk about it
<Marex> I dont even have a lunchpad account, would it be too much to ask to leave this in your hands ?
<apw> well normally one gets the reporter to test etc
<Marex> apw: let me see
<Marex> ugh
<Marex> apw: where do I need to navigate to file a bugreport for ubuntu kernel git ?
<apw> file it against the package git, as that is the issue
<Marex> it's rather git-core , no ?
<apw> https://bugs.launchpad.net/ubuntu/+source/git/+filebug
<apw> old 'git' went away somewhen in the last 2 years, and git-core -> git
<Marex> apw: is this the correct bug report https://bugs.launchpad.net/ubuntu/+source/git/+bug/1228148 ?
<apw> Marex, yep that lookfs goo thanks
<Marex> apw: thanks, I will also update the redhat bugzilla, where this was initially reported and the git mailing list
<apw> jsalisbury, yo ... we discussed using aliases for git bisect good/bad to allow reverse bisects to not blowup ones head ...
<apw> jsalisbury, if you ended up codifying that, i wonder if it would make sense to update https://wiki.ubuntu.com/Kernel/KernelBisection with that knowledge
<jsalisbury> apw, never put anything into code, just been keeping track in my head when I do them
<apw> jsalisbury, ok ... 
<apw> jodh, yo ... i have a couple of boxes which 'recently' are rebooting when i ask for power off ... ie when i say sudo poweroff it doesn't
 * apw wanders to another location where there are beverages
 * bjf thinks that's a fine idea
#ubuntu-kernel 2013-09-21
<phillw> Hi folks, it seems that the patch to bug 1227202 does not resolve the 'unexpected freeze' issue. Has anyone got any ideas as to how to progress this apart from disabling zram?
<apw> phillw, put that in the bug for sure, that one might have been reverted or something
<phillw> apw: the guy who pointed it out to me on email has updated bug 127202 As the zram issue affects all of *buntu and *nix, I'm struggling as to how high to flag this for kernel 3.11
#ubuntu-kernel 2014-09-15
<axoin_> Hello! is there any specific reason why you removed (or don't build) the module iptable_nat into 3.17-rc5? you built it into 3.17-rc4 and there it was /lib/modules/3.17.0-031700rc4-generic/kernel/net/ipv4/netfilter/iptable_nat.ko but nowadays, it breaks the libvirt...
<axoin> (sorry for repeating, webchat kicked me) Hello! is there any specific reason why you removed (or don't  build) the module iptable_nat into 3.17-rc5? you built it into 3.17-rc4  and there it was  /lib/modules/3.17.0-031700rc4-generic/kernel/net/ipv4/netfilter/iptable_nat.ko  but nowadays, it breaks the libvirt...
<bjf> jsalisbury, i have an Intel nuc and i've installed & booted both trust & utopic several times without issue
<bjf> kirkland, ^
<jsalisbury> bjf, hmm, interesting
<kirkland> bjf: with external USB devices attached?
<kirkland> bjf: usb keyboard, usb3 hard drive?
<bjf> kirkland, yup, all the ones you told me to purchase
<kirkland> bjf: you installed trusty ga, and then upgraded?
<kirkland> (I see a new kernel update is available for me today)
<bjf> kirkland, no, installed utopic daily
<bjf> kirkland, or whatever MAAS picked up
<bjf> kirkland, just re-installed and rebooted with both 3.13.0-27-generic #50  and  3.16.0-14-generic #20
<bjf> kirkland, have both usb drive and usb kbd plugged in
<rtg> apw_, unstable seems to be working well on the couple of bits of kit that I've tried
<apw_> rtg, nice i'll give it a bash
<jsalisbury> apw, rtg, is this due to something we changed in the mainline builds: bug 1369486  And should we be concerned since it's the mainline testing builds and not the Ubuntu kernels?
<ubot5> bug 1369486 in linux (Ubuntu) "module iptable_nat is not built into 3.17-rc5" [Medium,Confirmed] https://launchpad.net/bugs/1369486
<rtg> jsalisbury, I think its already been fixed. apw re-ran the mainline build
<jsalisbury> rtg, cool, thanks.  I'll ask to re-test
<apw_> jsalisbury, thanks for doing that, i clearly forgot
<jsalisbury> apw_, np
#ubuntu-kernel 2014-09-16
<infinity> zequence: You're in -proposed, BTW, if you want to do some smoketesting.
<zequence> infinity: thanks
<sr105> why is it that when I "apt-get source linux-image-3.13.0-34" and then look at the Makefile, it says 3.13.11? Same for git: "git show Ubuntu-3.13.0-34.60:Makefile"
<sr105> but "strings vmlinuz-3.13.0-34-generic | grep 3.13" yields "3.13.0-34-generic (buildd@panlong) #60-Ubuntu..."
<henrix> sr105: may i ask you what were you expecting to see in the Makefile?
<sr105> 3.13.0
<sr105> I'm just trying to patch a driver in the kernel.
<sr105> for a running system
<sr105> module, actually
<henrix> sr105: the makefile simply contains the version of the last stable kernel it was applied to the kernel source.  currently, 3.13.11.6
<henrix> sr105: 3.13.0-34.60 is just the ubuntu package version number
<sr105> henrix: but if I build that, uname -r will report 3.13.11.6. 
<sr105> henrix: does ubuntu change the kernel version to match the package version before building?
<henrix> sr105: that's because you're probably just running make && make install
<sr105> yes
<henrix> sr105: take a look at the kernel wiki, it will show you how the kernel packages are actually built
<henrix> sr105: you can start with https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<sr105> well, I definitley have a secondary goal of learning how ubuntu builds their kernels.
<sr105> my primary goal is to build a modified module that I can modprobe on an existing system
<ogra_> since you want to build an ubuntu kernel, shouldn't that be a primary goal ? 
<sr105> ogra_: If I can't solve my vermagic issue, then yes building an ubuntu kernel will become my primary goal. 
<sr105> henrix: thanks for the link. I was looking at 3 other, different build an ubuntu kernel links all on ubuntu.com 
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<wedgwood> Can anyone tell me whether the choice of the deadline scheduler for the Trusty AWS cloud-image was deliberate, or simply a holdover from the server default? Also asked in #ubuntu-server but it was suggested I ask here.
<smb> wedgwood, more or less because it server and aws just use the same kernel (actually the same as desktop) and deadline had been overall better than cfq 
<wedgwood> smb: OK thanks. Just wanted to know before we try to outsmart you guys by using noop (as seems to be best for the environment)
<smb> wedgwood, yeah the default more or less tries not to be bad for a wide range of cases. Same with the cloud-images which could override the default on the kernel command-line
<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 September 23rd, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!  If the question is should I file a bug for something, likely you can assume yes.
<bicepjai> : trying to load a usb driver when a particular device is hotplugged, trying to figure out what to do with rules for udev, i cannot find resources online and cannot figure it out, any help ?
<tyhicks> rtg: hello! who should I talk to about getting a utopic-armhf chroot on tangerine? saucy-armhf is the newest armhf chroot available.
<rtg> tyhicks, I've stopped supporting armhf chroots in favor of using the cross compiler
<tyhicks> oh, even better
<slangasek> apw_: your new linux-cloud-tools package is doing a number on our cross-toolchain builds
<tyhicks> rtg: can you point me at docs on how cross compile build our kernels?
<slangasek> apw_: this cloud package should not be getting built when DEB_STAGE=stage1 / DEB_BUILD_PROFILE=bootstrap is set
<rtg> tyhicks, from within the appropriate chroot you can build a kernel using 'dpkg-buidlpackage -d -aarmhf -B' (for example)
<tyhicks> rtg: thanks!
<rtg> of course while also spelling it correcftly
<tyhicks> :)
<rtg> slangasek, start a bug report please, then assign apw or me to it.
<slangasek> rtg: ack
<slangasek> lquecy
<slangasek> mmhmm
<slangasek> rtg: bug #1370211 opened / assigned
<ubot5> bug 1370211 in linux (Ubuntu) "cloud package should not be built when DEB_STAGE=stage1 / DEB_BUILD_PROFILE=bootstrap is set" [Undecided,Triaged] https://launchpad.net/bugs/1370211
<rtg> slangasek, ack
<rtg> apw_, please have a look at http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-utopic.git;a=commit;h=4cdb245bfd0b79b2006cbfa5f29cc26a3b20481d to see if I have the right of it.
<apw_> slangasek, will check out rtg's thing in the am
#ubuntu-kernel 2014-09-17
<bicepjai> trying to do complete task05 in http://eudyptula-challenge.org/, got stuck and any help would be appreciated ! my razor keyboard creates 3 devices hiddraw[1-3], i want my hello module to load on my keyboard hotplug; i have tried changing usbhid quirks, udev rules to load my hello module on my keyboard vendor:product id; none of them works ! any thoughts ?
<apw_> bicepjai, well you want to look at the udev events using udevadm monitor, and make sure your modalias matches that device
<apw_> modinfo on your module should show you
<apw_> rtg, ok pushed a couple of fixes for that tools thing to utopic, looks to work in my test env at least
<rtg> apw_, ack
<rtg> apw_, so, prolly need an upload today ?
<apw_> we should jsut remember to check all the "other arches" tools pacakges the next itme we build it properly, as cross does not contain anything in those packages :)
<apw_> rtg, it wasn't clear to me how urgent the issue is in the bootstrap archiev
<rtg> dunno, slangasek ? ^^
<apw_> if it isn't uber urgent i could upload it to the bootstrap PPA and confirm the binaries there
<rtg> apw_, we can get also by without an ABI bump this time (if that'll grease the skids)
<apw_> rtg, i am waiting on another test, when that is done, i'll be happy to suffer an upload, if its not an abi bumper we might fancy doing it sooner
<rtg> apw_, lemme do the bow tying and a quick build test
<rtg> apw_, amd64 test build on Utopic master-next looks good, so you can go ahead and drop this into your bootstrap PPA
<apw_> rtg, ack will do
<rtg> apw_, havebn't tagged it yet
<sr105> henrix: Thanks for your help yesterday. It solved my issue.
<sr105> ogra_: ^ smae
<sr105> same
<ogra_> :)
<slangasek> rtg, apw_: I care about the tools issue for making the cross-toolchain packages in utopic buildable again; dunno what the bootstrap archive is that you're referring to, I think that's not relevant to me?
<rtg> slangasek, its a way of testing those build stages in the linux package, i.e., stage1
<rtg> which is, I think, the problem you ran into (stage1 was erroneously building some tools)
<slangasek> ok, so I suppose you want to test that, but those tests don't address my use case
<slangasek> because when you're testing you're using the full build-depends
<rtg> slangasek, prolly not directly. 
<henrix> sr105: awesome, i'm glad it help!
<rtg> slangasek, I'll get an upload going later today if apw's tests work. then you can retry your cross builds
<apw_> slangasek, right my archive isn't relevant for you, it is for regressions testing on normal cases only
<apw_> slangasek, to test yours i uninstalled dh-systemd in my build chroot after a build and re-ran it with -Pbootstrap to simulate what you are doing
 * slangasek nods
<slangasek> (-P!  Why did we need a commandline argument for this, when we already had the env var setting...)
<apw> i have also fixed the thing to handle the new pluralised -P env variable
<apw> perhaps for tools integration with things like sbuild
<apw> slangasek, spoke with cjw about the build-deps but it seems we don't have buildd support for the control <> thing yet
<slangasek> correct
<apw> slangasek, does your bootstrap env just suck up new sources, or can we slip a special in to check this works for you
<slangasek> apw: the *-cross-toolchain-base packages build-depend on linux-source
<apw> slangasek, hmmm i think we must be talking at cross purposes, as bootstrap stage only produces linux-libc-dev
<slangasek> apw: yes, and when used in a cross environment, we use it for generating a cross linux-libc-dev
<slangasek> (because we can't build-depend on a foreign-arch linux-libc-dev)
<apw> slangasek, oh i see, gah :)
<rtg> apw, my test build looks fine, so I guess I'll upload. you ready for that ?
<apw> rtg, any test builds in bootstrap will be "some time" ... so ...
<rtg> apw, ok, I'm just gonna assume they are OK, cause any failures there won't affect the main build process
<apw> rtg, ack
<apw> rtg, if you haven't already, this isn't right, for cloud tools
<rtg> apw, gak! what ?
<apw> there is a sublty here, due to all being done in i386, asses
 * apw pokes
<apw> and that is the bit which breaks them, crapola
<rtg> apw, guess I'll go delete the tag
<apw> i hate indep
<rtg> apw, feel free to 
<rtg> squash your fix
<apw> will do
<apw> rtg, ok fix squashed and pushed, but i am betting abi failurs ?
<rtg> apw, I'll rebuild then
<rtg> apw, why would anything you've done cause an ABI change ? it all looks like packaging to me.
<apw> rtg, right, that, which is why i mentioned it
<rtg> apw, still confused about why your change might impact ABI, but whatever....
<apw> rtg, it oughtn't which is confusing
<apw> perhaps i screwed some pooch, i am rerunning my test build before i declare it wrong
<apw> rtg, perhaps you should test build it again as it is, and then call me stupid otherwise
<rtg> apw, in progress
<apw> rtg, ok i got another abi failure, but that makes no sense as the diff to your master-next shows only changes in -tools, which isn't even part of the abi check
<rtg> huh, well gloin will be done in 50 minutes or so
 * apw looks baffled
<apw> rtg, where did you get the abi info from, as the previous version is still in (new)
<rtg> apw, git mv I think.
<rtg> apw, and all of my builds failed for abi-check. dang. I'll fix it up.
<apw> rtg, the previous abi was -14 though, this is -15
<apw> ok so at least that makes sense ... i was getting very confused
<rtg> apw, dunno, otp. I''ll get to it in a bit
<marvin24> mlankhorst: xserver (1.15.1-0ubuntu2.1) got broken on lts for non pci platforms like arm
<marvin24> the change log points to some revived patch for hw detection
<marvin24> server just segfaults
<marvin24> https://bugs.launchpad.net/ubuntu/+source/xorg-server-lts-saucy/+bug/1322212
<ubot5> Launchpad bug 1322212 in OEM Priority Project "Switching to the Guest session results in a black screen" [High,In progress]
<mlankhorst> marvin24: yeah !arm is less supported, what are you running?
<mlankhorst> erm !x86
<mlankhorst> pci-less is slightly broken, but as long as they don't use the platform description it will work correctly, afaict omap works, which is the only driver that used the string description
<marvin24> mlankhorst: this is on tegra
<marvin24> I think 1.16 fixes it
<marvin24> (not tested)
<marvin24> driver is opentegra (or modesetting)
<marvin24> I know it is not supported, but it would be sad if it stays broken
<mlankhorst> marvin24: fix opentegra then :P
<mlankhorst> I think modesetting works
<kirkland> bjf: around?
#ubuntu-kernel 2014-09-18
<DynamiteReed> I've got hardware that isn't supported until kernel v3.15.  Is there a time frame for kernel 3.15.x's release in Ubuntu 14.04?  Is it planned?
<DynamiteReed> Or is Ubuntu 14.04 kernel version locked at 3.13 for some reason?
<RAOF> DynamiteReed: As a stable release, 14.04 isn't going to get a new version of the kernel.
<RAOF> DynamiteReed: That said, after 14.10 is released, it'll get backports for hardware enablement.
<RAOF> DynamiteReed: The same sort of thing as with 12.04, documented here: https://wiki.ubuntu.com/Kernel/LTSEnablementStack
<DynamiteReed> Splendid. That's what I wanted to know.  Kernel 3.15+ has much better support for sony dualshock 4 controllers.  I'd like to stay at 14.04 a while and get those updates.  Sounds like that'll probably get backported.
<DynamiteReed> According to that page, though, it looks like the next kernel backport to 14.04 isn't until February of 2015.  Yikes.
<DynamiteReed> I take that back.  It looks like it will be available via trusty-updates about the same time as the 14.10 release, which is late next month.  That's not too bad.
<DynamiteReed> I can wait a month.  :)
<RAOF> Yeah, the ISOs with the new stack will be 14.04.1, which would be Feb or so.
<DynamiteReed> Good to know.  Thanks for the help.
<marvin24> mlankhorst: modesetting also fails, it crashes before loading the driver
<mlankhorst> marvin24: weird, log?
<marvin24> mlankhorst: I don't have the machine here now
<marvin24> I'll create a new bug and attach the log
<mlankhorst> ok
<mlankhorst> make sure to apport-collect on it too :)
<mlankhorst> file against xorg
<marvin24> oh
<marvin24> isn't a gdb backtrace sufficient
<marvin24> this is a low mem machine ....
<marvin24> will see how long it takes
<mlankhorst> it collects the full xorg log etc, it's not that intensive :)
<marvin24> ok
<infinity> zequence: <gentle lowlatency smoketest poke>
<cmagina> is there a branch or tag that points to the head of the trusty-proposed kernel?
<bjf> cmagina, trusty master branch is trusty-proposed
<cmagina> bjf, thanks
<bjf> cmagina, you verifying bugs?
<cmagina> bjf, i have been, but this is to provide someone the kernel tree to build a module against, just want them on the right version
<bjf> kirkland, still looking for me?
#ubuntu-kernel 2014-09-19
<rtg> apw, anything in the pipeline before I upload Utopic today ?
<apw> rtg, nope, pound it in at your convienience
<zequence> infinity: Sorry, will do right now.
 * zequence been busy teaching Linux to the umeployed for a whole week.
<zequence> infinity: Ok. Testing done.
#ubuntu-kernel 2014-09-21
<ramsudharsan> Anyone here?
<ramsudharsan> I am looking for an answer
<columbusgate1492> hello, i'm looking to write a driver for a usb device on xubuntu. am i in the right place?
#ubuntu-kernel 2015-09-14
<rtg> apw, I assume this is a duplicate: https://bugs.launchpad.net/bugs/1494562
<ubot5> Ubuntu bug 1494562 in linux (Ubuntu) "[4.2.0.10] kernel: Request for unknown module key 'Build time autogenerated kernel key: .....' err -11" [Undecided,Confirmed]
<apw> rtg, yes, will dup
<apw> rtg, and done
<rtg> apw, ack
<apw> rtg, i have sent a proposed fix upstream, and having confirmed it is a 1/256 chance of recurring i have just done a no-change rebuild
<apw> until we get confirmation of the approach in my fix
<rtg> apw, yup, I kind of figured that out, though I have not seen the patch. Perhaps you could attach it to the bug ?
<apw> rtg, attached
<apw> rtg, introduced in 3.19 i think so we may see this issue back there also
<rtg> apw, gawd, how did you figure this patch out ? it makes my head hurt.
<apw> rtg, reading a lot of the history for that file change
<rtg> no dobt
<rtg> doubt*
<apw> rtg, one reason i have not yet applied it, as they may have reasons for that strip and then the fix is to strip it in the signer
<apw> not that i can imagine why one would do that, but hey
<rtg> hence the no change rebuild
<apw> exactly, as there is only a very low change of it recurring on such a build
<rtg> apw, do you suppose we can get -10.11 promoted this morning ?
<rtg> -7.7 has a weird crash that I'd like to see if it just goes away
<apw> rtg, the testig i looked at looked good, bjf do you concur
<apw> rtg, and we were waiting on a last few tests to finish
<apw> which have been delayed because lcy01 got eaten by juju over night
<rtg> again ?
<apw> lcy01 is normally broken, but today it is _gone_ same issue as ps4
<rtg> I noticed a bunch of test failures on an i386 box, but haven't drilled in to figure it out. everything else looked pretty good.
<apw> we have a couple of failures on xfs which seem to be output format changes, which cking is looking at
<rtg> there are also a bunch of skylake changes I'd like to get into the wild
<apw> otherwise it looked generally sany
<apw> yeah i agree we want it out
<apw> i think the testing on the previous version was ok, so its not clear it could be any worse
<apw> so as soon as the adt tests finish i think it will be migratable
<apw> the problematic ones have made happily green
<rtg> apw, guess I'll go work un unstable for a bit. 4.3-rc1 is out
<apw> ok
<bjf> rtg, apw, testing for 4.2.0-10.11 looks good to me 
<rtg> bjf, ack. do I just remove the tag for auto-promotion ?
<bjf> apw, ^ ?
<apw> bjf, if we set the test to good will shanky do that for us now ?
<bjf> apw, lets try ...
<apw> when it sees all the ADT tests done, which they are not all yet
 * apw whips the camels
<cking> poor camelids
<apw> bjf, ok i am wacking some failed dkms tests
<apw> but i think it would be good to see this do the right thing itself
<bjf> apw, what exactly did you do? "automated-testing" is already "Fix Released" on the tracking bug
<apw> i exactly did nothing, i cirtainly did not move that task
<apw> oh are you looking at 10.10 or 10.11
<bjf> apw, 10.11
<apw> oh and ... of course it would have gotten confused in the old stuff because we only have the 
<apw> abi number, so this test of the shanky changes is a bust
<bjf> :-)
<apw> that is all fixed with the new adt based regression bits
<apw> so ... rip the tag and we'll see it migrate when adt passes
<henrix> apw: note that shank looks for the test results here: https://people.canonical.com/~kernel/status/dashboard-helper/proposed-migration/regressions.txt
<apw> henrix, no you shouldn't be using the adt-matrix that is a human jobbie, proposed-migration is good
<apw> now ... why on earth do i not have all the matching results ... in adt-matrix ... grr
<apw> henrix, what y9ou have done is right
<henrix> apw: right, but i still see regressions in that regressions.txt for which i don't know what to do :)
<henrix> apw: there are 3 tracking bugs halted because of these regressions
<apw> henrix, give me a minute
<henrix> apw: ack, thanks
<apw> and i'll have a look and hsow you how i have a look
<popey> cking: further to my moan that 4.2 causes slowdown during IO, I'm also finding my laptop is painful when running any kind of hangout / webrtc chat thing - even with nobody else joined, and my webcam off! Very odd.
<popey> (may not be a 4.2 thing, but it certainly got very worse recently) (load avg 13 during a hangout, and completely unresponsive desktop)
<ogra_> does it grow spikes on the keyboard and stuff ? 
<ogra_> or what do you mean by painful ? :)
<popey> back under your bridge!
<cking> popey, well, I've got 2+ more days of intensive fs testing to complete then I can do a full apples vs pears comparison
<popey> heh
<apw> bjf, ok leave that tag on there a sec, there is some issue with britney i'd like to get debugged
<cking> meanwhile, I'll send you an email with some things to try to get some more hard facts so I can ponder on what's going on
<popey> cking: thanks
<TJ-> Using 'ecryptfs-recover-private' with 4.2.0-10-lowlatency, getting "Could not find valid key in user session keyring ...", but 'keyctl list @u' shows the keys are present. I've been using this daily for weeks to mount external disk file-systems but today it fails, mount reporting "mount: mount(2) failed: No such file or directory" but both source and mountpoint exist. Any ideas?
<cking> tyhicks, ^^
<tyhicks> TJ-, cking: I can help in ~15 min
<TJ-> tyhicks: no rush... I'm digging into it but drawing blanks so far
<om26er> Hi! it seems kernel 4.3 rc1 build failed or something, is that a known issue? if so how long is the build fix expected ?
<om26er> http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.3-rc1-unstable/
<tyhicks> TJ-: are you logged into the machine over ssh?
<TJ-> tyhicks: No, regular boot session with KDE. The problem FS is an external drive 
<TJ-> tyhicks: Can I private you a link URL to a log of the attempt?
<tyhicks> TJ-: Sure
<smoser> hey
<smoser> what is the right way to do what i would have thought this would do:
<smoser>  git://kernel.ubuntu.com/ubuntu/ubuntu-wily
<smoser> my expectation based on https://wiki.ubuntu.com/KernelTeam/GitKernelBuild 
<smoser> showing git clone git://kernel.ubuntu.com/ubuntu/ubuntu-lucid.git
<smoser> i'm guessing its 'unstable' 
<smoser> based on http://kernel.ubuntu.com/git/ubuntu/unstable.git/
<smoser> is that right ?
<rtg> smwe've moved wily and unstable to LP, so they've got new paths.
<rtg> smoser, ^
<rtg> git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/wily
<smoser> thanks
<rtg> git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/unstable
<smoser> seems someone is maintaining the unstable though at the old location still
<rtg> smoser, both should be mirrored to kernel.ubuntu.com in the usual places
<smoser> i dont see a wily at kernel.ubuntu.com
<smoser> and get:
<smoser> â« git clone git://kernel.ubuntu.com/ubuntu/ubuntu-wily.git
<smoser> Cloning into 'ubuntu-wily'...
<smoser> fatal: remote error: access denied or repository not exported: /ubuntu/ubuntu-wily.git
<rtg> smoser, apw did it. looks like he put wily in kernel-ppa/mirror
<smoser> rtg, are you able to easily confirm or deny a suspicion i have that COMMAND_LINE_SIZE changed in the generic arm64 kernel between vivid and wily ?
<rtg> smoser, that sounds familiar
<apw> smoser, its master in LP
<smoser> well, it seems to have shortened.
<rtg> smoser, '#define COMMAND_LINE_SIZE 1024' in both kernels
<apw> rtg, we can symlink that kernel-ppa/mirror/ubuntu-wily.git over to ubuntu, i have tested it, you wen't keen
<rtg> apw, I'm fine the way it is. 
<apw> ok
<rtg> apw, at some point we should host all of our git repo on LP and just mirror them to wani
<apw> rtg, right that is the plan ... 
<rtg> apw, perhaps when we are all in the same room ?
<smoser> well, whatever is correct, please update doc ?
<rtg> smoser, URL ? (I can't remember it)
<smoser> you can't remember from above, where i typed it :)
<smoser> https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
<smoser> thats where i saw it
<rtg> ah, smart alek.
<rtg> you just think I read for content
<smoser> also mentioned here https://wiki.ubuntu.com/Kernel/Dev/KernelGitGuide
<rtg> apw, so maybe we _should_ just link wily. that way I don't have to edit wiki pages.
<apw> rtg, ok ... i'll sort it
<apw> rtg, and done
<rtg> smoser, does it work for you now ?
<smoser> does what work ?
<apw> the old name
<rtg> smoser,  git clone git://kernel.ubuntu.com/ubuntu/ubuntu-wily.git
<smoser> ah.it does 
#ubuntu-kernel 2015-09-15
<mIKEjONE1> hey guys
<mIKEjONE1> is there a way to build the kernel without having to build the whole thing from scratch everytime I make a change?
<mIKEjONE1> I'm using fakeroot with debian/rules
<mIKEjONE1> I'd like to have something that's able to only compile things that changed (i.e. the way Linux's Makefile works)
<mIKEjONE1> it's getting kind of ridiculous, so any help would be greatly appreciated
<apw> mIKEjONE1, yes after build if you want to change a few files and rebuild you can remove debian/stamp/stamp-build-<flavour> and then re-run fakeroot debian/rules binary-generic
<rtg> henrix, kamal: I just sent a patch to the k-team list in reference to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1397976/comments/4 - that commit looks good for stable.
<ubot5> Ubuntu bug 1397976 in linux-lts-trusty (Ubuntu Trusty) "tty hangup regression in 3.13 kernel (trusty LTS)" [Undecided,In progress]
<henrix> rtg: yep, looks like it could be applied to 3.13 kernel (all others seem to have it already)
<rtg> henrix, clean cherry-pick
<henrix> rtg: cool, thanks.  kamal, i guess you can pick it ;-)
<rtg> henrix, it might be a bit early for California slackers :)
<henrix> heh, indeed
<apw> henrix, so did we have that in P and fail to apply it to T somehow ?
<henrix> apw: no, i we don't have it P but i believe it is not applicable to such an old kernel...
 * henrix goes check
<apw> henrix, ahh ok, it was the regression word that confused me
<henrix> apw: right, so the issue was introduced by commit eafbe67f8476 ("n_tty: Refactor input_available_p() by call site"), which was cherry-picked into trusty.  so it *may* not even be applicable to stable 3.13, depending on whether or not it contains this commit
<henrix> kamal: ^
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<kamal> rtg, apw, henrix: fyi, 3.13-stable does not contain eafbe67 "n_tty: Refactor input_available_p() by call site", so I'll take no action on that topic, barring further discussion.
<henrix> kamal: ack
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
<bkero> Can I ask that someone install libssl-dev to the kernel build hosts so that we can actually generate kernel packages? http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.3-rc1-unstable/
<bkero> Is that off-topic for the meeting?
<hallyn> what is all this:
<hallyn> root     22390     2  0 15:23 ?        00:00:00 [kworker/u16:88]
<bkero> a kernel worker process
<hallyn> why so many of them?
<hallyn> (this is appears to be new)
<hallyn> oh, actually they've died down
<hallyn> perhaps a side-effect of resume.  interesting
<bkero> It's a kernel thing
<bkero> check out the kernel docs
<rharper> is there any place to get previously published but superceeded kernels?  I've got an issue on the latest vivid kernel but works fine on the vivid released kernel;  would like to bisect but without building all of those kernels 
<sforshee> hallyn: entirely possible it was a result of resume, if that generated a lot of workqueue items. I think the kernel scales the number of worker threads.
<sforshee> rharper: aren't they all still in the archive?
<rharper> did a apt-cache policy linux-image-generic and only showed the latest; so I probably need some apt-fu to find it
<sforshee> linux-image-generic is a meta package. Every new kernel version is its own package so that multiple kernels can be installed at the same time.
<rharper> ah, ok
<rharper> cool; I think I can get them now
<rharper> sforshee: thanks
<sforshee> np
#ubuntu-kernel 2015-09-16
<caribou> This may interest some : Wily fails to complete a crashdump with crashkernel=128 these days
<caribou> OOM kicks in before rootfs is mounted. It needs at least 145M to work
<caribou> https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1496317 follows that problem
<ubot5> Ubuntu bug 1496317 in kexec-tools (Ubuntu) "kexec fails with OOM killer with the current crashkernel=128 value" [High,Confirmed]
<apw> caribou, ugg, hrm
<caribou> apw: initramfs went from 22M in 3.x kernels to 29M with 4.x
<apw> caribou, what the heck
<apw> we _so_ need to make a =dep initramfs for the machine for use with kdump
<apw> as i am sure that is all turd we don't need in reality
<apw> we have been talking for a while how it would be nice to have a thin initrd and a fat one, this would be a perfect use case
<caribou> yeah, indeed
<caribou> though I'm not too enthusiastic about a separate boot file for dumping
<caribou> too many horror stories in the early days
<apw> welll in a perfect world we would use the thin one for booting and dumping, and only "i am broken" boots would use fat
<apw> caribou, if you have a list of what got added for 4.x i would be interested to know, as we have a much newer merge of initramfs-tools in wily
<apw> and it may be related to that as much as anything
<caribou> apw: I'll diff them & let you know
<caribou> apw: 24M more in ./lib for 4.2
<caribou> apw: changing MODULES=most to MODULES=dep in initramfs.conf brings the initrd from 29M to 12M & works around the issue
<ogra_> changing to =none brings it to 2MB ;) 
<caribou> ogra_: yes, but mine still boots :)
<ogra_> mine too :) 
 * ogra_ would simply move the modules to an img file living in /boot ... that could be loop mounted by the initrd and later move mounted to /lib/modules ... that way you wouldnt waste twice the space for modules on disk 
<apw> ogra_, though if you can mount root you don't need any of them, if you can't you need them in the initramfs
<ogra_> apw, well, the only think i need modules for is netboot or encrypted root 
<ogra_> *thing 
<ogra_> and both can have a standalone /boot 
<apw> right but you are above averagely lucky i assume
<ogra_> because i dont use a zfs root ? 
<ogra_> :P
<ogra_> extX is compiled in ... vfat should be too (IMHO) .... if i do a pretty standard install with a standard fs i usually dont need any modules 
<apw> because you don't use a disk controller which is a module
<apw> which makes you lucky
<apw> in theory =dep shold be empty for your use case though
<ogra_> true ... but even with a disk controller like that your /boot needs to be accessible for grub ... 
<ogra_> which means you most likely dont have it on the disk needing this controller
<rtg> tjaalton, I'm starting to see complaints about i915 in Wily with the 4.2 kernel. bug #1496433 for example. I've pulled a lot of 4.3 i915 cruft and am wondering if it is causing issues.
<ubot5> bug 1496433 in linux (Ubuntu) "Error in i915 driver" [Undecided,New] https://launchpad.net/bugs/1496433
<tjaalton> rtg: -7.7 didn't have the latest pull request
<tjaalton> so it's a genuine 4.2 bug :)
<rtg> tjaalton, ok, -10.12 will get published today. I'll keep an eye on progress
<tjaalton> seems to be upstream https://bugs.freedesktop.org/show_bug.cgi?id=91511
<ubot5> Freedesktop bug 91511 in DRM/Intel "[drm:check_crtc_state] *ERROR* mismatch in ips_enabled (expected 1, found 0)" [Normal,Needinfo]
<rtg> tjaalton, can you watch for a resolution on that bug ?
<tjaalton> yep
<rtg> tjaalton, isn't there a way to attach a watch on the LP bug ?
<tjaalton> I'll add the bugwatch and cc myself upstream
<rtg> cool
<tjaalton> "also affects project", then paste the buglink. done that
<old_benz> Hi guys, can anyone point me to the source for the Nexus 7 2013 kernel
<old_benz> "flo"?
<rtg> old_benz, 14.04 was the first release with a "flo" kernel. See 'git://kernel.ubuntu.com/ubuntu/ubuntu-trusty.git flo'
<old_benz> rtg: thank you very much
<hallyn> apw: oy ve.  are you sick of overlayfs yet?  cause there's a new problem with whiteouts for unprivileged containers:
<hallyn> whiteouts are apparently created as character devices.  This means there is no way in a userns to rsync them
<hallyn> (which is required for cloning such a container)
<hallyn> issue was raised at https://github.com/lxc/lxc/issues/655
<hallyn> stgraber: ^ :(
<stgraber> oh, fun
<apw> hallyn, hrm, that _is_ the format in there.  There is prolly a way to work round it in userspace, but hrmph
<hallyn> apw: only way i know to work around it is either with a privileged helper or with bind mounts - neither will stop rsync complaining, and bind mounts won't persist.  sigh.
<apw> you could copy in junk to the whiteouts, and then mount the overlay, and rm them
<apw> hallyn, or actually as you know there is a white out, you could just rsync and let them get lost, then mount the overlay and rm any whiteout in the upperlayer making a new one
<apw> (vile i know)
<apw> it is possible you should be allowed to make whiteout chardevs as a normal user, maybe, god don't make me think of the security consequences though
<hallyn> problem is rsync will fail, so how does a calling program know whether the only failures were expected whiteout failures?
<hallyn> if we can detect that, then what you propose sounds...  well, like a decent workaround
<apw> find -<chardev0> and use that list as an exclude, rsync, mount, rm the original list perhaps
<hallyn> or maybe what we should be doing is simply mounting the two overlays and rsync from the one mount to the other
<apw> that would make _much_ more sense
<apw> doh
<hallyn> feels like ther e must be something wrong with it, but i can't see waht right now
 * hallyn goes for a cup of coffee, biam
<hallyn> apw: yeah, that works.
#ubuntu-kernel 2015-09-17
<tjaalton> which initramfs hook installs the firmware?
<tjaalton> i915/* is missing
<smb> tjaalton, i915 needs firmware therese days?
<tjaalton> skylake does
<tjaalton> and broxton next year
<tjaalton> well, it works without but complains
<tjaalton> bug 1496163
<ubot5> bug 1496163 in linux (Ubuntu) "Wily: firmware load for i915/skl_dmc_ver1.bin failed with error -2" [Medium,Triaged] https://launchpad.net/bugs/1496163
<smb> now that I call a step backwards... errm. 
<smb> Not sure here but probably depends were the binary comes from... would that not be the linux-firmware package
<tjaalton> it doesn't install any hooks at least
<TJ-> The hook is via /usr/share/initramfs-tools/hook-functions::manual_add_modules() 
<tjaalton> I guess it's udev
<smb> tjaalton, ok, so the file of that name (or better link to skl_dmc_ver1_19.bin) is in the linux-firmware package
<tjaalton> yes, checking with -v
<tjaalton> smb: yep
<smb> the loading would be triggered by the driver
<tjaalton> Adding firmware /lib/firmware/i915/skl_dmc_ver1.bin
<tjaalton> huh
<tjaalton> lib/firmware/i915/ is still empty
<tjaalton> maybe because skl_dmc_ver1.bin is a symlink
<smb> tjaalton, have you unpacked the produced initrd to sanity check whether or what might be missing?
<tjaalton> yes
<smb> ok so you say that is completely empty
<tjaalton> yes the dir is empty
<TJ-> I wonder if it's a hanging symlink? That 'file' is a sylink in /lib/firmware/i915/
<tjaalton> no, it points to a real file
<smb> TJ-, maybe though at least for the source of the package its there
<smb> tjaalton, can you look whether the W system has the right link
<smb> to the ver1_19?
<TJ-> Yes, that's what I mean. The source is there, but in the initrd image is it a dangling symlink
<tjaalton> should use cp -aL
<smb> TJ-, as I understand tjaalton there is nothing there
<smb> not even the link
<tjaalton> lib/firmware/i915 is empty in initrd
<smb> tjaalton, let me finish that coffee and bring up a system actually running W...
<TJ-> I see:
<TJ-> Adding module /lib/modules/4.2.0-10-lowlatency/kernel/drivers/gpu/drm/i915/i915.ko
<TJ-> Adding firmware /lib/firmware/i915/skl_dmc_ver1.bin
<tjaalton> yep, modifying the copy command to use 'cp -aL' fixed it
<tjaalton> so adding the L
<TJ-> Yes, confirmed here too. Empty initrd
<smb> tjaalton, is that -aL getting you a softlink in initrd or a file
<tjaalton> smb: a file
<smb> tjaalton, hm, which might not be exactly what we want but of course better than nothing
<tjaalton> well, in this case it's the best there is
<tjaalton> no need to add several versions of the fw in initrd
<smb> normally I'd expect -a to preserve things and get everything... a bit odd
<tjaalton> doesn't follow links
<tjaalton> but odd that it doesn't even copy the link
<caribou> apw: remember Bug 1496317 from yesterday ?
<ubot5> bug 1496317 in kexec-tools (Ubuntu) "kexec fails with OOM killer with the current crashkernel=128 value" [High,Confirmed] https://launchpad.net/bugs/1496317
<tjaalton> maybe it's cleaned afterwards
<smb> tjaalton, Oh I understand only used on a specific path
<smb> caribou, he may as soon as he becomes concious
<caribou> smb: :)
<apw> tjaalton, does cpio represent those i wonder
<apw> caribou, yep
<smb> apw, I thought it should 
<smb> apw, but I try to look there in a min
<caribou> apw: so using MODULES=dep in initramfs.conf brings down the size of the initrd to 12M and it fixes the problem
<apw> caribou, that does sound like a good option for such a resource constrained space ... but we'd need to actually have one
<caribou> "have one" ?
<caribou> I'm a bit concerned to change the initrd for such a corner case.
<caribou> apw: the other option is to raise the value of crashkernel again. 
<caribou> apw: but at the moment, we're shipping wily with a broken crash dump mechanism
<apw> tjaalton, there is a changelog entry saying broken symlinks will be removed
<apw>   * mkinitramfs: Filter out looping or broken symlinks from the
<apw>     initramfs. (closes: #575157)
<apw> tjaalton, so i would say either -L is appropriate, or we need to detect and add the file it points to as well
<smb> Oh, yeah sounds plausible
<tjaalton> yeah
<apw> tjaalton, do you want to file a bug against initramfs-tools for this
<tjaalton> apw: I reused the bug above
<tjaalton> https://launchpad.net/bugs/1496163
<ubot5> Ubuntu bug 1496163 in initramfs-tools (Ubuntu Wily) "Wily: firmware load for i915/skl_dmc_ver1.bin failed with error -2" [Medium,Triaged]
<apw> bug 149616
<ubot5> bug 149616 in ruby1.9 (Ubuntu Hardy) "Net::HTTPS Vulnerability" [Undecided,Fix released] https://launchpad.net/bugs/149616
<apw> bug 1496163  
 * apw slaps ubot5
<apw> tjaalton, thanks
<apw> tjaalton, i assume i have this firmware on my wily boxes already, right?
<tjaalton> yep
<tjaalton> and vivid/trusty
<UNIm95> Hi 2 all. I think kernel 3.13-64-generic has bug. I'm getting kernel panic with this kernel on 2 different PC's.
<UNIm95> One Desktop with Athlon x2 4800+, other toshiba tecra laptop.
<UNIm95> This all comes randomly.
<UNIm95> The strangest thing is that desktop has 32 bit kernel and laptop 64 bit.
<UNIm95> The only same thing is that begin to happen after 3.13-63 to 3.13-64 update.
<apw> UNIm95, ok if it was introduced by an update like that and its detectible then it should be findable
<apw> UNIm95, can you file a bug against the kernle "ubuntu-bug linux" for us, and put that info in it
<apw> UNIm95, if you have a picture or something of the kernel panic can you put that in
<apw> UNIm95, we might know what it is from that
<UNIm95> apw:  with next panic i will make screen photo of panic. 
<UNIm95> But every time i get different messages. The most strange message i saw was Kernel tried to execute NX-protocol page - exploit attempt?
<UNIm95> It is strange cause i saw it on CPU Athlon x2 64 4800+ than was produced in 2006
<apw> UNIm95, it may be somewhat random you never know
<UNIm95> apw: Ok. I will wait for another panic.
<manjo> bjf, wily will be released with 4.2 correct ? 
<bjf> manjo, correct
<manjo> thanks
<manjo> bjf, and 16.04 will be based on 4.5 ? any idea ?
<bjf> manjo, you can probably assume 4.4 ... don't know about 4.5. it's possible
<manjo> ok yep thanks a ton for that info
#ubuntu-kernel 2015-09-18
<UNIm95> apw: Hi. I got kernel panic again. Where should i paste photos?
<apw> UNIm95, file a bug, and add them to that bug: use 'ubuntu-bug linux' to make the bug
<UNIm95> apw: what is ubuntu-bug linux? Console program? Website?
<apw> something to run in a terminal yes
<UNIm95> apw: Damn. I got Launchpad error =)
<UNIm95> apw: I have submitted this. What should i do next? Wait?
<apw> UNIm95, let us know the LP# here for one
<UNIm95> apw: What do you mean with LP#?  if you mean bug number under launchpad it is #1497184. Link here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1497184
<ubot5> Ubuntu bug 1497184 in linux (Ubuntu) "Kernel-panic with 3.13-64 generic kernel" [Undecided,Confirmed]
<apw> yep that
<apw> henrix, ^ looks like a regression in trusty-proposed kernel ...
<apw> UNIm95, does that trace seem consistent in your failures ?
<apw> UNIm95, particuarly is that "BUG: ..../skbuff.c:1290" part appear in other ones
<UNIm95> apw: Not sure. Now I'm still using *-64- kernel and wait for another panic. When it happens i post more photos.
<apw> UNIm95, thanks that is exactly what we need, you are not the only person "feeling" there is an issue in here
<apw> UNIm95, and thanks for 1) testing -proposed and 2) reporting the issues to us
<UNIm95> apw: Please. I is not a problem for me. I have backups =)
<apw> heh, thanks
 * smb feels a disturbance in the coffee namespace
<henrix> smb: ok, i *may* have found something related with this bug.  if your bored, here's what i found:
<henrix> smb: trysty -64 kernel includes commit 738ac1ebb96d ("net: Clone skb before setting peeked flag")
<apw> that sounds suspicious indeed
<henrix> smb: however, there's an upstream commit (not included in trusty yet): a0a2a6602496 ("net: Fix skb_set_peeked use-after-free bug")
<henrix> which fixes the other one
<apw> nnng
<smb> henrix, yeah. I am currently trying to cause it to crash with -64 in a VM. If that succeeds I can have a look with that added
<henrix> smb: cool, thanks
<smb> henrix, but use-after-free sounds a lot like what may happen
<henrix> smb: yeah, the only thing is that none of these functions actually show up in the kernel trace.  but since the kernel is tainted, it could have happen before
<henrix> *don't show
<smb> henrix, absolutely. the pain with use-after-free
<henrix> smb: btw, if the issue you're hitting is really due to this commit, it seems to be related with broadcast/multicast ;-)
<henrix> (according to the commit msg)
<smb> henrix, hmmm... so the method to trigger it is actually the dhcp client running... likely...
<henrix> smb: build on-going in gloin:/tmp/kernel-henrix-RVtd9xTj
<henrix> UNIm95: i've commented on the bug with a link to a test kernel
<henrix> UNIm95: The comment points to the possible issue (and the fix)
<UNIm95> henrix: ok.
<apw> UNIm95, how long did it take to reproduce in general ?
<henrix> apw: smb: btw, looks like this also impacs vivid
<UNIm95> apw: At home laptop worked for 4 hours, than sleep for 8 hours and, finally, after 2 hours word panic.
<UNIm95> work*
<UNIm95> apw: one time a got this after ~30min uptime
<apw> henrix, gah
<UNIm95> henrix: i will try this kernel a later. I need to do my work
<apw> henrix, i've nom'd it to those two for now
<UNIm95> henrix: i have downloaded this kernel
<apw> UNIm95, let us know how you get on
<UNIm95> Sure
<henrix> UNIm95: ack, thanks!
<apw> but i am suspicious this is the issue and fix
<UNIm95> henrix: the only question: "and introduces a use-after-free bug, fixed with upstream commit"
<UNIm95> It means than this bug appers with high memory load?
<henrix> UNIm95: from these commits description it should occur in the broadcast and multicast packages receive paths, so not really a memory stress issue
<henrix> s/packages/packets 
<UNIm95> henrix: network packets?
<henrix> UNIm95: yep
<UNIm95> should i emulate DDOS?
<UNIm95> on my own laptop?
<UNIm95> Or is possible to make some thing like this.
<apw> UNIm95, it is predicted taht dhcpclient would tickle the bug
<apw> UNIm95, so setting your dhcp refresh time on your router to 5m might make it a lot more likley to occur
<apw> lots of packets not so likley to trigger it, as tehy are normally unicast
<UNIm95> apw: and doesn't matter Wlan or ethernet?
<apw> i don't believe so from the description
<apw> henrix, ^
<henrix> apw: i... don't think so either, it's in the core network code.  anyway, looking at UNIm95 photos, it seems to have occurred while using ethernet (e1000e)
<apw> good point
<henrix> but again, i believe that's irrelevant -- if this is the issue, it's in the core code, so it doesn't matter
<UNIm95> henrix: apw yesterday at home i used wlan and got only kernel oops that was catched with apport-gtk.
<UNIm95> do you have access to ubuntu's apport infrastructure?  
<apw> UNIm95, the symptoms of this would be pretty random, as it is a use after free which could literally break anything
<apw> UNIm95, we may be able to find it yes
<UNIm95> look for toshiba tecra laptop a11
<UNIm95> It was at evening. 20:00<x<22:00 Berlin time
<smb> apw, henrix, so far not been able to hit it in a more artificial environment but I guess its random by nature
<apw> tjaalton, hey are you fixing this initramfs-tools thing for the firmware ... i was about to, but i see you ahve it assigned
<tjaalton> apw: that's when it was a kernel bug, you can have it :)
<apw> tjaalton, ack
<tjaalton> thanks
<psivaa> cking_: hello, it's me again :) 
<psivaa> Just was going to disable the memory threshold for NM health check but noticed that it's been passing for a few days. 
<psivaa> *memory threshold tests
<psivaa> https://jenkins.qa.ubuntu.com/view/Trusty/view/Smoke%20Testing/job/trusty-desktop-i386-smoke-health-check/
<psivaa> so i'm wondering if that's OK to let that run for a few more days to see if this has really settled
<cking_> psivaa, ok, lets see how it runs over the next few days
<psivaa> cking_: ack, thanks
<t3hSteve> hey all, is anyone around that could help me with a cpuacct cgroup question/issue/bug?
<apw> t3hSteve, it is eod for me, but it is just best to ask the question and see who responds
<t3hSteve> ok, so basically I notice that on (at least up to) 3.13.0-64, the cpu usage reported in cpuacct.stat is significantly lower than the actual CPU usage as reported by say, top or /proc/<pid>/stat
<t3hSteve> this is on ubuntu 12.04, I seem to recall on 14.04 it was correct, but oddly enough I think it was on the same kernel version
<apw> t3hSteve, hrm, that sounds odd if the kernle version is the same
<t3hSteve> yeah, its very odd =/
<t3hSteve> looking around bug trackers I cant see any reference to anything like this
<t3hSteve> but its a significant under-reporting from the cgroup
<apw> t3hSteve, sounds like some repeatable test is required, if you could file a bug against the kernel "ubuntu-bug linux", and could detail the two platforms that produce different numbers, and how to get the numbers
<t3hSteve> ex top reports 120% and the cgroup reports .9
<apw> t3hSteve, then someone might be able to repro it
<t3hSteve> I can do that
<t3hSteve> althought we'll see how easy it is to reproduce :P
<apw> t3hSteve, heh .. i know ... things like this normaly go away when you try and make them reproducible
<t3hSteve> :P
<t3hSteve> the full context is we're running mesos in AWS
<apw> t3hSteve, drop the LP#number in here when you have done so, so we can find it
<t3hSteve> and the numbers I get out of mesos (which just reads the cgroup) are way different from what I see on the machine itself (top, /proc, etc)
<UNIm95> henrix: apw damn. without kernel change i have 10 hours uptime without panic.
<t3hSteve> so re: my cgroup issue, it looks like the more threads a process has the more the cpuacct.stats numbers diverge
<t3hSteve> apw: https://bugs.launchpad.net/ubuntu/+source/linux-lts-raring/+bug/1497447
<ubot5> Ubuntu bug 1497447 in linux-lts-raring (Ubuntu) "cgroup cpuacct.stats underreports cpu usage" [Undecided,New]
<t3hSteve> I'm not sure if I filed it against the right package?
<old_benz> Hi all, I think the "flo" branch needs to be patched to support newer Nexus 7 devices with an updated eMMC controller, I need to compile a new kernel and patch my boot.img and recovery.img in order to get Ubuntu Touch to install on my Nexus 7
<old_benz> details are here: https://github.com/ddagunts/UTCWM_N7_patch
<apw> old_benz, if you could file a bug against linux-flo with that information and drop the bug # in here ...
<old_benz> apw: will do, need to make an account
#ubuntu-kernel 2015-09-19
<hallyn> thinkpad t440s  4.2.0-10-generic #12-Ubuntu  - my pointing stick stopped working :(
<hallyn> hm, reboot fixed it.  (previous was a boot from shutdown)
<jtaylor> hi, the vivid proposed kernel is randomly crashing with null pointer dereferences
<jtaylor> whats the place to report that? a new bug or the tracking bug 1493902?
<ubot5> bug 1493902 in Kernel SRU Workflow verification-testing "linux: 3.19.0-29.31 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1493902
<jtaylor> its quite rare, only every couple hours
#ubuntu-kernel 2015-09-20
<trippeh> I'm having some crashes with vanilla 4.2(.1-rc) as well, but havent taken the time to capture any eventual kernel output
<apw> jtaylor, a new bug ... with the crashes if you can get them ... we have one patch we are tracking which might cause network related crashes
<trippeh> apw: got a link? my crashing machine is a router.
<trippeh> looked briefly in netdev but didnt find anything
<apw> trippeh, this issue wouldn't affect 4.2 as far as i know ...
<apw> jtaylor, LP #1497184
<ubot5> Launchpad bug 1497184 in linux (Ubuntu Vivid) "Kernel-panic with 3.13.0-64.104 generic kernel (BUG at net/core/skbuff:1290)" [High,Confirmed] https://launchpad.net/bugs/1497184
<trippeh> oh, ok
<trippeh> I dont even have kernel output yet so who knows ;)
<apw> trippeh, it was in 4.1* but is in 4.2-rc7 and later
<apw> (thats not at all clear, the fix was in 4.2-rc7 and later, before that 4.1 etc was affected)
<trippeh> yeah probably not related then
<apw> trippeh, get a stack if you can and get it reported in a bug
<trippeh> was just a shot in the dark :) have to dig up some hw for a serial console methinks
<UNIm95> apw: henrix I got panic again. As predicted it was while router updated my IP address. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1497184/comments/5
<ubot5> Ubuntu bug 1497184 in linux (Ubuntu Vivid) "Kernel-panic with 3.13.0-64.104 generic kernel (BUG at net/core/skbuff:1290)" [High,Confirmed]
<apw> UNIm95, was that with the original kernel or with the test kernel from henrix ?
<UNIm95> apw it was with original kernel
<apw> UNIm95, ok great, i assume you will switch over to the test kernel now
<apw> ?
<apw> (and can you indicate that that comment relates to the old kernel in the bug, esle its position with the request to test feels like the fix was tested)
<UNIm95> apw yes. I waited till some one you, or henrix came here
<UNIm95> apw:  but i haven't build test network with dhcp renewal of some minutes. 
<UNIm951> apw:  Damn.  My router has minimum lease time 60 min =(
<UNIm951> apw: do you know how we can simulate short lease time?
<TJ-> UNIm95: via dhclient config
<UNIm95> TJ-: can network-manger do this? i dont want to kill nm.
<UNIm95> and then restore it
<TJ-> UNIm95: NM runs a 'private' instance of dhclient. It might be possible to configure a predefined/override for te lease 'expire'
<UNIm95> TJ-: Ok. i hope changes that i made are right. 
<UNIm95> apw Now I going to install  henrix kernel and test it
<jtaylor> apw: looks like my issue, I get stacktraces from skb stuff
<UNIm95> apw:  henrix Now i with henrix kernel. 
<UNIm95> henrix:  Is it ok that internet now works very slov?
<UNIm95> slow*
<UNIm95> henrix:  with your suggested kernel?
<UNIm95> apw: First dhcp renewal. All works
<apw> UNIm95, that is encouraging, we have others testing this kernle too
<UNIm95> apw all ok. router has mistake in config. internet works ok
<apw> UNIm95, thanks for the update
<UNIm95> apw Pls. Uptime 9:47. No bugs.
<apw> UNIm95, nice ... let us know tommorow where you are at, if no issues i think we have things identified
<UNIm95> apw: Ok. But from  Friday till Saturday  a had only one pamic
<UNIm95> So i think we must wait
<apw> UNIm95, yep, we hope but not cirtainty indeed
<UNIm95> apw this patch will came with *-64-105 or *-65?
<apw> UNIm95, though it is not my direct decision, I would expect us to respin to just add that single patch
<UNIm95> apw:  Thanks.
#ubuntu-kernel 2016-09-19
<mowthegrass> Hi Has anyone faced boot problems with boot screen just hanging with the messaged "random: lvm urandom read with 25 bits of entropy available"
<mowthegrass> Just installed a new kernel apt-get install -y linux-headers-4.4.0-34-generic && apt-get install -y linux-image-4.4.0-34-generic && apt-get install -y linux-image-extra-4.4.0-34-generic 
<mowthegrass> post which system just doesnt boot, Recovery mode doesnt help too 
<mowthegrass> I get the below error in Recovery mode 
<mowthegrass> Gave up waiting for root device. Common problems:
<mowthegrass> Boot args (cat/proc/cmdline)
<mowthegrass> check rootdelay = (did the system wait long enough?)
<mowthegrass> Check root = (did the system wait for the right device?)
<mowthegrass> Missing modules (cat /proc/modules; ls / dev)
<mowthegrass> ALERT! /dev/mapper/ubuntu-root does not exist. Dropping to a shell!
<mowthegrass> However i am able to fall back to the old kernel which was installed prior to 4.4.0.34
<apw> mowthegrass, that has not been reportred ... lackof entropy can trigger stalls waiting for new entropy, which could be difficult in early boot
<apw> if you oculd file a bug against the kernel and indicate the last working version/first broken version you are aware of ... "ubuntu-bug linux"
<mowthegrass> apw, This doesnt seem to be a BUG whenever we do a new kernel install it throws up with this error , we observed the same while we did 3.19 from 3.16 
<mowthegrass> not really able to figure this out to be a BUG or something going fishy with the H/W 
<apw> well unless installing hte kernel flushes the saved entropy somehow, i am a little confused
<apw> have you tried exiting after a few minuted from the initramfs shell to see if by then it is moutnable ?
<mowthegrass> no no keystrokes are accepted on the console 
<mowthegrass> its just dead with the screen 
<apw> you ought to be able to interact with the initramfs shell so that sounds like a console configuration problem on the kernel command line
<mowthegrass> I am trying to install linux-image-extra-4.4.0-34-generic to see if anything went missing 
<apw> mowthegrass, is this a virtual machine ?
<mowthegrass> No 
<mowthegrass> its a DELL R720
<apw> you would want -extra installed then, was it not ?
<mowthegrass> yeah it wasnt installed 
<mowthegrass> just did it now 
<mowthegrass> fingerscrossed
<mowthegrass>  it helped 
<mowthegrass> apw, Thanks for your time 
<mowthegrass> apprecicate it 
<apw> mowthegrass, if you have the right meta package installed it should dpeend on that kernel -extras package
<apw> to make sure this does not occur again
<mowthegrass> yep got it 
<manjo> apw, looks like some apparmor stuff landed in unstable .. are you still waiting on more ?or is that the complete list?
<manjo> jjohansen, ^ 
<apw> manjo, 4.8 in theory is complete
<manjo> apw, cool thanks 
<manjo> rtg, I see that you guys are active on the Ubuntu-4.8.0-12.13 tag for Y .. if I were to check out a 4.8 tag what would you recommend ?
<rtg> Ubuntu-4.8.0-12.13
<manjo> rtg, thanks
<manjo> rtg, would you be open to pulling some ACPI related patches from 4.9 next if I made an SRU req ? 
<manjo> rtg, for arm64 
<rtg> manjo, mail 'em on the k-team list
<manjo> rtg, yep will do once it is backported and tested 
<rtg> note that 4.9 merge window is still at least 2 weeks away
<manjo> rtg, are you planning on merging from 4.9 onto Y ? 
<rtg> manjo, nope, 4.8 is the 16.10 kernel
<manjo> got it 
<manjo> rtg, yeah few critical ACPI patches for arm64 did not make 4.8 and are sitting in 4.9 next.. so will email ukml once it is ready .. you still need an SRU correct ? 
<rtg> manjo, if it is post kernel freeze, which those most assuredly will be
<manjo> yes that was my feeling for timing as well .. ok thanks a ton 
<_ami_>  is there any document on explanation of hid driver in linux kernel? 
<_ami_> why few drivers overrides report? e.g. .report_fixup = _override_report;
<_ami_> is it because of firmware bugs?
#ubuntu-kernel 2016-09-20
<xnox> Ubuntu-4.8.0-11.12 tag does not appear to be in the yakkety repository
<apw> xnox, i have it here, and it was a leann one so i must have gotten it from the cental repository
<apw> xnox, it might not be in linear history, so you would need to git fetch --tags origin
<xnox> oooh, let me try that.
<xnox> i already see Ubuntu-4.8.0-12.13, so yeah i must be post-rebase.
<xnox> $ git fetch yakkety Ubuntu-4.8.0-11.12 -> was quicker
<xnox> apw, thanks! i had no idea that git does not fetch unreachable tags by default.
<elmo> rtg: hey - so 4.8 is much worse for me
<elmo> [25358.449193] CPU0: Core temperature above threshold, cpu clock throttled (total events = 42960)
<elmo> rtg: and my laptop hard locked over night and when I found it in the morning, every possible fan was at full speed and it was very hot
<rtg> elmo, thermald is installed I presume ? this could be something cking might wanna look at (when he's not totally buried)
<elmo> rtg: it's installed, but broken
<elmo> on 4.8 - it worked on Xenial
<elmo> rtg: http://paste.ubuntu.com/23207813/
<cking> elmo, can you file a bug, I'll try and get onto this ASAP
<elmo> cking: will do
<cking> elmo, can you boot with the previous 4.4 kernel just to double check it's the new 4.8 kernel
<elmo> OK
<elmo> cking: back on 4.4 - seems better; less thermald spew, but it's a bit early to tell
<cking> elmo, OK, well lets keep it monitored. my laptop suddenly got hotter when I moved to 4.7 - but I tracked that down to the thermal paste giving up on me and not the kernel
<elmo> cking: bug against thermald or the kernel?
<cking> thermald please
<elmo> cking: this is a weeks old laptop; I'll be grumpy with Lenovo if it's failed paste :)
<cking> elmo, ok, that's less likely to be a paste issue then :-/
<slangasek> apw: so if ioctl(fd, KDGKBMODE, &addr) takes an unsigned long * but only fills the bottom 32 bits of it, whose bug is that?
<apw> slangasek, it would depend how the thing is documented
<apw> it might be a kernel bug in compatibility mode of course
<slangasek> and where in the world would I find the documentation? :)
<apw> slangasek, or you might be passing the wrong size thing to it ?
<apw> normally there is a manual page for the device the ioctl is on, ifyou are lucky
<slangasek> apw: ok, so ioctl_list(2) claims it should be int *, not long *
<slangasek> interesting
<apw> so then it filling in 32 bits is fine, on a BE it would fill in the top half :)
<slangasek> yeah, context is LP: #1621824
<ubot5`> Error: Could not gather data from Launchpad for bug #1621824 (https://launchpad.net/bugs/1621824). The error has been logged
<apw> slangasek, if the docs say 32 bits, then it is a caller bug i recon
<slangasek> apw: is that manpage the "right" docs?
<apw> phththt now that is a difficult question
<apw>                 ret = put_user(uival, (int __user *)arg);
<apw> it is cirtainly sending you and int
<slangasek> apw: well, turns out that every other call to KDGKBMODE in kbd source uses an int, but cjwatson's patch uses a long, whoops :)
<apw> slangasek, then yes, lets suggest an _unknown_ actor has gotten their size wrong :)
<slangasek> heh
<gpiccoli> Hi, sorry to bother. Just wanna know if there are some really easy way to build a kernel debian package from a kernel tree
<gpiccoli> https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel <= is this updated enough?
<gpiccoli> Never done this before, sorry if this is a silly question
#ubuntu-kernel 2016-09-21
<pekkari> Hi, any easy way to get the kernel config file used for linux-image packages of different series?
<apw> pekkari, they are installed with the kernels in /boot, and are collected here
<pekkari> apw: fine thanks!
<apw> ppisati, http://kernel.ubuntu.com/~kernel-ppa/config/
<apw> sorry got distracted getting the url
<apw> pekkari, http://kernel.ubuntu.com/~kernel-ppa/config/
<apw> even
<apw> xnox, hey ... there is a kernel rebuild in ppa:canonical-kernel-team/ubuntu/unstable which looks to have the right bits in s390x .udebs are you able to confirm
<xnox> apw, that looks good. However, I am wonder if performance will be degraded on x86_64 because:
<xnox> x86 optimised .ko modules do not appear to be in the udeb.
<xnox> ./lib/modules/4.8.0-13-generic/kernel/arch/x86/crypto/crc32-pclmul.ko
<xnox> ./lib/modules/4.8.0-13-generic/kernel/arch/x86/crypto/crc32c-intel.ko
<xnox> hopefully things fallback to generic crc32[c] modules instead.
<xnox> looks good. obviously i'll need d-i to verify, but hopefully things are fine.
<alkisg> Is it possible to install a 4.x kernel in ubuntu 12.04? I tried e.g. with the xenial kernel, but the "kmod" dependency isn't satisfied...
<apw> xnox, yep, that we can fix
<apw> (after beta) 
<apw> alkisg, the newest kernel we offer there is lts-trusty 3.13
<alkisg> apw, thanks, a user reports that he has sound in 16.04 but not in 12.04, even with the -trusty kernel there
<alkisg> (12.04 is his normal installation, 16.04 a live cd)
<alkisg> So I was trying to see if an even newer kernel in 12.04 would solve the issue
<apw> i would guess that the modutils/kmod change is more about the transitional package for the old name going away
<apw> so you might find forcing that on works just fine
<alkisg> Thanks, trying even with broken dependencies...
<alkisg> Nah the user said that the 4.x kernel didn't even boot
<smoser> hey...  i just marked https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1626158 as kernel related.
<ubot5`> Ubuntu bug 1626158 in linux (Ubuntu) "image won't boot after upgrading to yakkety's 4.8 kernel because efi" [Critical,Confirmed]
<chalbersma> Is this Ask Ubuntu Accurate (http://askubuntu.com/questions/804111/is-no-reboot-kernel-patching-enabled-in-16-04)? Is there now live kernel patching in Ubuntu 16.04? I asked on #ubuntu and they said they didn't think so but I should check with you guys.
<dsmythies> Ever since mainline kernel 4.7-rc5, I have been observing sometimes extreme load averages and over 2000 kworker processes (8 CPUs and up to 258 threads per cpu, maybe more).
<dsmythies> Particularly immediately after boot.
<dsmythies> Eventually (5 minutes +- a few seconds) the kworker threads go away, but might return depending on what root activity is going on (it doesn't happen for user activities).
<dsmythies> The issue is somehow related to the massive kernel configuration changes between 4.7-rc4 and 4.7-rc5, and if I compile say 4.8-rc7 using the old kernel configuration, the issue does not occur.
<dsmythies> If I do "scripts/diffconfig .config-4.7.0-040700rc4-generic .config-4.7.0-040700rc5-generic" there are 2249 lines of changes.
<dsmythies> I have compiled several kernels with my best guess at some configuration reversions, but so far have not been able to isolate the exact change that introduced the issue.
<dsmythies> This work has all been on my main test computer, which is 16.04 server based. However today the same thing was observed on a 16.10 based Laptop test computer, after it upgraded to 4.8.0-11-generic.
<dsmythies> It has two CPUs and I observe up to 516 koworker threads, when the issue occurs (used to be about 11 max).
<dsmythies> Does anyone know which kernel configuration change is responsible? And if this is behaviour is actually O.K.?
<dsmythies> To be clear the kworker processes are mostly idle, and the load average seems to be high only because the queue happened to be huge on a sample boundary. This is NOT a hogging the CPU issue.
<rtg> dsmythies, try reducing CONFIG_NR_CPUS=8192 to 256 or something low like that.
<dsmythies> rtg: O.K. that was a change between 4.7-rc4 and 4.7-rc5: "NR_CPUS 8192 -> 512", and it is one that I have not yet tried reverting.
<rtg> dsmythies, it just seems like that is a lot of worker threads. What file system do you use ?
<dsmythies> rtg: my main disk is ext4, on both computers.
<rtg> huh, I've not observed that many threads, though I haven't looked recently
<rtg> one of my 4-way servers does have 589 kworker threads
<rtg> dsmythies, if that does turn out to have an impact, please start a bug and assign me to it (timg-tpi). I'm EOD for now
<dsmythies> rtg: on my server, it occurs every half hour, when CRON runs the php clean up. i.e. /usr/lib/php/sessionclean. I also have now created a way to do it simply myself.
<dsmythies> rtg: O.K.
<dsmythies> does anyone know what rtg meant by "(timg-tpi)"? (3 lines above).
<dsmythies> reverting CONFIG_NR_CPUS made no difference.
<apw> dsmythies, that is his launchpad id
<dsmythies> apw, aghh thanks.
#ubuntu-kernel 2016-09-22
<dsmythies> Additionally: If I look at linux/Documentation/workqueue.txt and do "echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event" and "cat /sys/kernel/debug/tracing/trace_pipe > out.txt"
<dsmythies> with the issue, I get somwhere between 10,000 and 20,000 occurances of memcg_kmem_cache_create_func in the file.
<dsmythies> without the issue, I get 21, and an overall file size about 50 times smaller, for otherwise similar conditions.
<dsmythies> Using a simplified method to create the issue that I made.
<caribou> Hello, just an FYI : makedumpfile is failing on 4.8 kernels (i.e. Yakkety). I'm on the issue and should fix it today
<apw> caribou, thanks, if you have a bug for that could you tag it kernel-4.8 so we see it too
<caribou> apw: sure : LP: #1626269
<ubot5`> Error: Could not gather data from Launchpad for bug #1626269 (https://launchpad.net/bugs/1626269). The error has been logged
<apw> ubot you are just a waste of electrons
<smb> apw, caribou I added the tag
<caribou> smb: thanks!
 * xnox hates EFI
<xnox> so much respins, so much to test =)
<davmor2> xnox: they'll be more yet
<rtg> dsmythies, any luck on changing CONFIG_NR_CPUS to something less then 8192 ?
<apw> rtg, that was not succesful, cking is debugging
<rtg> dsmythies, I've been informed that http://bugs.launchpad.net/bugs/1626564 is likely the root of your kworker issue
<ubot5`> Ubuntu bug 1626564 in linux (Ubuntu Yakkety) "4.8 regression: SLAB is being used instead of SLUB" [High,In progress]
<dsmythies> rtg: Indeed, SLUB is a difference between 4.7-rc4 and 4.7-rc5, and not something that I had tried reverting. I have an inredibly simple way to demonstrate this issue. I'll add to the bug report.
<rtg> dsmythies, I credit apw and cking for finding root cause
<apw> cking, did all the heavy lifting ...
<mterry> I'm experiencing system "slowdown" in yakkety -- that's a known issue?
<apw> mterry, particularly in early boot yes
<mterry> Ah.  Maybe different then.  I'm experiencing system unresponsiveness if anything is happening (like compiling, browsers using cpu)
<mterry> Desktop experience gets quite bad, can't barely type
<apw> rtg, perhaps we should have a dirty build with the curent fixes so we can see if things like this is the same or a new issue
<JanC> mterry also mentioned seeing âcrazy high occasional loadsâ
<mterry> Yeah.  Browsers and such tend to go mental in top, which helps trigger the unresponsiveness.  But I don't know if they are going mental because of initial unresponsiveness problem that spirals out of control?
<mterry> Yeah.  Browsers and such tend to go mental in top, which helps trigger the unresponsiveness.  But I don't know if they are going mental because of initial unresponsiveness problem that spirals out of control?
<dannf> rtg: do you want SRU bugs opened for pull requests for yakkety at this point - if not, when does that change?
<bjf> dannf, yes .. bugs, please
<dannf> bjf: ack
<rtg> dannf, please do
<dsmythies> Confirmed: reverting SLAB /SLUB kernel configuration changes solves the over 2000 kworker threads issue. As a side effect, and as expected, it also solves rediculous load average values after boot. i.e. "load average: 430.90, 99.40, 32.78"
<chalbersma> Is this Ask Ubuntu Accurate (http://askubuntu.com/questions/804111/is-no-reboot-kernel-patching-enabled-in-16-04)? Is there now live kernel patching in Ubuntu 16.04? I asked on #ubuntu and they said they didn't think so but I should check with you guys.
<apw> chalbersma, the statements in there are accurate in that the facility to _do_ live kernel patching is included, there is no stream of such patches though
<chalbersma> Has there been any live patches released?
<apw> not to my knowledge no
 * ogra_ notes that hot-patching does not necessarily mean no reboots ... if you patch changes something that lives in the initrd you most likely want to re-generate it and actually also ask for rebooting
<ogra_> (and there are surely other cases where a hot patch will still cause reboots)
<chalbersma> Thanks guys just wanted to clear that up. 
<apw> .b 6
<_ami_> which driver is responsible for serial over ip in linux?
<apw> that is normally called sol in the kernel side if it is coming via a bmc, though in my experience sol is handled by the device and faked to the machine as a real serial port
<_ami_> apw: ok, thanks
<om26er> Hello! It seems the 4.8 Update on Yakkety have brought in some troubles. 1. My system becomes sluggish during load. 2. There is a lag in screen brightness keystrokes actually taking effect.
<apw> om26er, yes indeed, the first one we know the fix, the second we are investigating
<tdaitx> apw, hi there! we have some sort of mismatching headers between powerpc/ppc64el and the other archs that is causing a few packages to FTBFS on powerpc/ppc64el, I stumbled upon freevo's FTBFS and slangasek said he saw other packages failing due to a similar reason... he said you might be able to help me on that, the current bug is LP: #1619446
<ubot5`> Launchpad bug 1619446 in linux (Ubuntu) "mismatching headers between powerpc/ppc64el and other archs" [Medium,Triaged] https://launchpad.net/bugs/1619446
<tdaitx> please let me know when it is a good time to talk about that
<apw> tdaitx, there should be a new linux-libc-dev hitting the archive about now ... could you confirm it is the same there and add that to the bug
<tdaitx> apw, sure, I will check that, thanks for the info
<rtg> dannf, I've pulled your changes. Please build yourself a test kernel to check if I've broken any arm64 config settings. I've been syncing with Xenial after modularizing everything.
<dannf> rtg: sure and thx
<tdaitx> apw, did you refer to version linux-libc-dev 4.8.0-15.16? it still FTBFS with that one
#ubuntu-kernel 2016-09-23
<shalq> hello
<shalq> is there anyone compiled ubuntu xenial kernel on ubuntu trusty ?
<shalq> It seems it requires linux-libc-dev_4.4.0-36.55_amd64.deb installed on ubuntu trusty
<shalq> I am talking about https://bugs.launchpad.net/bugs/1626838, can any one can help ?
<ubot5`> Ubuntu bug 1626838 in linux (Ubuntu) "yakkety compiling failed on ubuntu trusty" [Undecided,Confirmed]
<JanC> shalq: the missing modules all seem related to ZFS ?
<JanC> also, there are xenial kernels in the trusty-updates repositories, but they don't include ZFS support
<rtg> JanC, ZFS was not supported until Wily (which is EOL)
<JanC> yeah, I know, but in theory ZFS modules/utilities/libraries/etc. could have been added together with the xenial kernels in trusty
<rtg> JanC, until there is user space support, it doesn't make much sense to turn on ZFS modules in the kernel.
<JanC> oh sure (I don't know exactly what would need support even)
<JanC> I guess it would all have to go in -backports
<JanC> actually, I have a bug with ZFS in nautilus that I should file  :)
<rtg> I think there is a plan to backport user space
<JanC> probably a bug in gvfs
<shalq> JanC: so if the ZFS is backport, then the issue should be gone , right ?
<JanC> I don't know
<shalq> I run the compile inside a xenial docker, the compile has no any issue.
<JanC> I'm not even sure what causes your problem, just saw that the "missing modules" are all ZFS-related
<JanC> and if it works otherwise, then the missing modules is probably harmless
<JanC> maybe you could build the yakkety kernel without ZFS & its related modules
<shalq> you mean remove those missing modules from generic flavor ?
<shalq> I am not farmilar with ZFS,  not sure what impact if remove them, so I don't want to remove modules if I really know it well and don't want it .
<JanC> ZFS is a file system; if you don't use it then you don't need any of those modules...
<JanC> and like I said before: the xenial kerel in trusty has ZFS-support removed too
<shalq> just wonder different build result between  trusty and xenial.    If I want to build a xenial kernel,  which build server version should I use , trusty or xenial ? I suppose both have the same result, not sure
<shalq> it is interesting topic, I don't find any doc for suggestion .
<shalq> I think it is better to build xenial kernel on xenial server, it then has no dependency, so if I only have trusty, I can start a docker container with xenial, and run compile in the xenial container, and then get the kernel pkg
<shalq> is there any concern if I build ubuntu kernel inside a docker container ?  from my testing, it works very well, no any depencency issue.
<om26er> apw, Hi! My system comes to a crawl while compiling code. This was definitely not happening with the 4.4 kernel. Is that something of a known issue ?
<om26er> Its a thinkpad X1Carbon.
<apw> om26er, not known i don't think no, which kernel, there is a new -16 (yep, yet another kernel) as of today
<om26er> apw, yes, updated that as well. Same results.
<apw> om26er, ok cna you file a bug please
<om26er> apw, will do that. Also now there is a lag in screen brightness key press and the brightness actually changing.
<om26er> like 2seconds
<apw> om26er, yes _that_ one we know, that is related to a ubuntu-settings-daemon change whihc is triggering a whole login to set the brightness
<apw> _that_ one is not kernel, most every other problem is, but not that one
<om26er> apw, ok, thanks. Reporting the system slowness now.
<apw> om26er, drop the bug number in here please
<om26er> bug 1627108
<ubot5`> bug 1627108 in linux (Ubuntu) "X1Carbon comes to a crawl during high CPU usage tasks" [Undecided,New] https://launchpad.net/bugs/1627108
<apw> om26er, hey htat is reporting that you have -15 running
<om26er> apw, it came in today in updates
<apw> and there is a -16 since then, its moving like a train
<om26er> apw, ah, -16 is in -proposed
<om26er> will update to that first.
<apw> ahh yes, i thought it had made it further
<zyga> jdstrand: offtopic, this branch was there to test if the unexpected unmount of the core snap is caused by the test that was fiddling with cgroups: https://github.com/snapcore/snap-confine/pull/152
#ubuntu-kernel 2016-09-24
<ejat> hi .. with the recent update in yakkety ... my dualboot windows 10 disk become read-only
<ejat> anyone can assist or give suggestion ?
<apw> ejat, what format is that disk
 * apw bets it is NTFS
<ivan> ejat: look in dmesg
<ivan> (or journalctl) - for any explanation of why it was mounted read-only
<lorddoskias> hello, i'd like to ask what is the status of this particular bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1605843
<ubot5`> Ubuntu bug 1605843 in linux (Ubuntu) "Kernel crashes from time to time when using ftrace " [Medium,Confirmed]
<ejat> apw: yeah ntfs ... 
<apw> that tracks with some config issues we are having
<ejat> apw: means ? in the latest kernel ?
<apw> yes in the 4.8 series, we are working on them
<ejat> apw_: any bugs that i can subscribe to follow up on this ntfs issue
<apw_> ejat, sorry no, there is nothing specific to that option filed, that i know of
<ejat> apw_: any ETA / milestone for the fixes to come out soon ?
#ubuntu-kernel 2016-09-25
<ejat> apw: any milestone on which kernel update will fix the RW ntfs partition?
<apw> ejat, i would hope the next one ...
<apw> ejat, what was your bug number
<apw> ejat, actually when did your filesystem work, as it does not appear that that was enabled in 16.04 
<JanC> I thought ntfs-3g is the recommended way to do RW NTFS?
<shalq> Hi, is there is easy way to verify the overall state of a kernel source ?  I run make kselftest on the clean kernel source,  I found there are some FAIL,  not sure if I can determin it by its return code of kselftest
#ubuntu-kernel 2017-09-18
<Laney> can I use lttng to find out which process calls a particular ioctl?
<Laney> I know what userspace thinks the ioctl name and argument are, and I probably know the device
<Laney> just want to find out who on earth is calling it :(
<Laney> basically I want to track down who is putting the tty into unicode mode when you call udevadm trigger
<Laney> it might be systemd but i can't make it admit that
<TJ-> Laney: could you do it via dynamic_debug?
<Laney> TJ-: ah, I just found it by old school detective work
<Laney> "grep"
<Laney> but thanks for the hint, nfi about dynamic_debug
#ubuntu-kernel 2017-09-20
<xnox> sforshee, is 4.13 ready to go into artful release? just needs a d-i rebuild + remove "block-proposed" tag, no?
<xnox> or are we waiting on something else too.
<apw> xnox, it is close
<apw> xnox, i am just looking at some adt bits to confirm they are falsies
<apw> xnox, did you have a particular reason to care
<xnox> ah, ok. I will be rebuilding d-i today for netcfg fixes, and i was wondering if i should bump the kernel d-i build uses.
<xnox> otherwise a separate d-i build with kernel bump will need to be uploaded later
<apw> xnox, difficult call, you likely wnat that to migrate today regardless
<apw> xnox, so i would be inclined to waste buildds and do two
<xnox> ack
#ubuntu-kernel 2017-09-21
<oSoMoN> hey, in case this hasn't been reported yet, my artful VM (vbox) fails to display anything with wayland after upgrading from kernel 4.12.0-12.13 to 4.13.0-11.12
<oSoMoN> if I change gdm3âs config to use X instead of wayland, everything works
<apw> sforshee, ^
<sforshee> oSoMoN: will take a look. Could you file a bug if you haven't already?
<oSoMoN> sforshee, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1718679
<ubot5> Ubuntu bug 1718679 in linux (Ubuntu) "Upgrade to 4.13.0-11.12 in artful amd64 VM breaks display on wayland" [Undecided,New]
<oSoMoN> (sorry for the delay, your message got lost on my end)
<jjohansen1> sforshee: I have a revised LSM stacking patchset, I want to do a little more testing, then I'll point you at it
<jjohansen1> we aren't going to take Casey's full patchset, the secid bit is still questionable and the patches after it to provide stacking of smack/selinux
<jjohansen1> but we will have enough to stack selinux/smack with current 17.10 apparmor
#ubuntu-kernel 2017-09-22
<jibel> hi, could someone have a look at bug 1711358, it started with kernel 4.12. It's pretty annoying for testing because qxl is the only driver that somewhat works with wayland.
<ubot5> bug 1711358 in ubiquity (Ubuntu) "20170817 - ISO hangs on boot on qemu with splash screen enabled and qxl graphics driver" [High,Confirmed] https://launchpad.net/bugs/1711358
<smb> jibel, if then rather next week if you remind us. not obvious from the report as it is right now: is this still happening with a 4.13 kernel? 
<jibel> smb, yes, still hanging
<smb> jibel, could you add that to the bug report, please. not sure what can be done today and better keep info not as volatile as irc
<jibel> smb, sure, I added a summary in the description
<smb> thanks
<smb> jibel, ok, I managed to extract some data but it would be good if you could do the same for the 4.13 kernel case. Then track us down next week
<smb> info in the bug report
<jibel> smb, ah great, I've been trying to extract data without much success and this bug happening only on the iso makes it rather difficult.
<jibel> I'll do the same with 4.13
<smb> jibel, cool. thanks
<jibel> smb, the trace is the same with 4.13
<cpaelzer> are we on this bug at assuming a kernel issue?
<cpaelzer> last time we assumed plymouth (or related) code
<cpaelzer> need to re-read updates in there
<smb> cpaelzer, unfortunately (for me) kernel bug in qxl sounds rather kernel
<smb> jibel, ok, so we have at least something to start on
<cpaelzer> yeah I see the call trace now
<cpaelzer> I came from a dup to this where that wasn't known yet
<cpaelzer> subscribed to the dup now
<cpaelzer> ok read now
<cpaelzer> while a bug that is much better than "no idea somewhere in plymouth"
<maxb> Is anyone aware of bluetooth changes in the 4.13 that recently landed in artful? My bluetooth audio was working wonderfully in artful/4.12 but is now extremely unhappy - spontaneous bluetooth disconnects after playing a few seconds of audio, and unable to redo pairing
#ubuntu-kernel 2017-09-23
<antgel> Hi there. Going through a bit of a weird one with my Thinkpad T470. I think I'm suffering from the known CPU frequency breakage when resuming from suspend. It's been a while since I got into this stuff, and intel_pstate wasn't a thing then, I used to use cpufreqd. My question...
<antgel> Is a correct way to determine CPU speed lscpu | grep 'MHz'? Because mine is *always* on 2900 MHz, power adaptor in or out. Using 4.13.2 from your PPA. I just want to be sure I understand what's (not) going on before I jump to conclusions. (NB I have updated the BIOS to the latest as recommended in several threads.)
<antgel> Okay, I found it myself, something like watch -n 0.3 cat /sys/devices/system/cpu/cpu{0..3}/
<antgel> cpufreq/scaling_cur_freq
<antgel> is much more useful (sorry for the accidental line breaks)
#ubuntu-kernel 2017-09-24
<skrech> hey guys, I bought a new mixer that is also supposed to be class-compliant audio device, but doesn't work right now.
<skrech> I found an ALSA quirk patch from zamaudio (a guy making audio effects for Ardour)
<skrech> I want to apply this patch but I'm wondering is there a way to not recompile the whole kernel?
<tomreyn> skrech: unless its a patch to a kernel module, you'll need to rebuild the kernel. on ubuntu kernels, alsa is an integral part of the kernel, so not a module. hardware specific drivers as well as codecs, however, are usually modules.
<skrech> I have to change this file
<skrech> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/sound/usb/quirks-table.h?h=v4.4.88
<skrech> which appears to be part of the kernel? so I must rebuild the kernel if I change it?
<tomreyn> i think so, but don't rely on me too much.
<tomreyn> you could also ask this in #linux in case you won't get a better answer here
<tomreyn> ##linux actually
<skrech> tomreyn: do you know a good tutorial on kernel recompile?
<skrech> ##linux channel is a mess
<skrech> also, do you have an idea what is https://launchpad.net/alsa-driver, there is no such package in apt-get but there is this launchpad saying that in Xenial I should have this package at version 1.0.25, strange
<JanC> skrech: seems like that's packaged as alsa-base, linux-sound-base & alsa-source
<skrech> JanC: ok, so that's not what I need, i guess?
<skrech> :)
<JanC> and probably also included as part of the kernel
<JanC> skrech: alsa-source might be, if you need to patch it
<JanC> seems like ALSA is a module
<JanC> kernel/sound/core/snd.ko
<JanC> so should be no need to compile the whole kernel  :)
<tomreyn> oh right, lsmod on a desktop lists 'snd', modinfo says "description:    Advanced Linux Sound Architecture driver for soundcards." (so A.L.S.A.)
<skrech> thx, guys!
<skrech> and what would happen when I update my kernel from packaging system
<skrech> as you can see, i'm quite a newbie with this things
<skrech> these*
<skrech> packaging system, i mean package manager, apt-get
<tomreyn> skrech: kernel modules are specific to the kernel. if you have a new kernel you'll need to build your custom kernel modules for this kernel. dkms can automate this process.
<skrech> tomreyn: yes, i understand this. So, to be sure: When new kernel package is installed it will create new dir in /lib/modules with the name of the new kernel version. Under this dir it will place the new version of the alsa driver and autoload it on reboot. So i'd have to rebuild my patched alsa for the new kernel and replace the .ko file in the aforementioned dir?
<tomreyn> skrech: right, or have dkms do it for you
<JanC> when you test that patch and it works, it might be useful to report that and ask the kernel engineers to include it so that you don't have to recompile it  :)
<JanC> assuming that it's likely not going to break other soundcards or the like
<skrech> thank you very much guys, you were reaaally helpful!
<skrech> and yea, definitely I'll opt for this patch to be integrated upstream, but since it's a "quirk" and I'm not that knowledgeable yet, It will be turned down I guess :D
<tomreyn> no no, it's a record in the quirk table
<tomreyn> if it helps seperating badly behaving from properly behaving hardware then it will get merged
<tomreyn> (assuming code quality is fine, and it doesn't break other things)
<skrech> yea, but to be honest I don't know what exactly is this entry doing
<skrech> it's this one
<skrech> http://pastebin.com/raw/mpLUK01g
<skrech> from: https://community.ardour.org/node/13646
<skrech> I'm wondering what is this quirk addressing that the standard driver is not
<skrech> :D
<skrech> dmesg says
<skrech> [69121.804282] usb 6-1: parse_audio_format_rates_v2(): unable to find clock source (clock -32)
<skrech> [69121.805287] usb 6-1: 1:1: cannot set enable PITCH (v2)
<skrech> [69121.806625] usb 6-1: parse_audio_format_rates_v2(): unable to find clock source (clock -32)
<skrech> [69121.807635] usb 6-1: 2:1: cannot set enable PITCH (v2)
<skrech> hey guys, now i've read INSTALL file and try to build the ALSA drivers
<skrech> however on ./configure
<skrech> i get this
<skrech> checking for kernel linux/version.h ... no
<skrech> The file /lib/modules/4.4.0-96-generic/build/include/INCLUDE_VERSION_H does not exist.
<skrech> Please install the package with full kernel sources for your distribution
<skrech> or use --with-kernel=dir option to specify another directory with kernel
<skrech> sources (default is /lib/modules/4.4.0-96-generic/build).
<skrech> i think that I don't need the full kernel soruces?
<skrech> and the package is dependent only on linux-headers
<skrech> yea, I fixed it
<skrech> hm, guys, I think that this package alsa-source is WAY too old
<skrech> alsa 1.0.25 is from 2002 year
<skrech> :/
<skrech> it's soo confusing everything concerning ALSA
<skrech> no  documentation at all, google doesn't find anything
<skrech> do you know where I should ask for guidelines of building the version of ALSA that comes with my distro (xenial lts)
<skrech> ?
<skrech> but just patched by me :D
<ddnh> hi all, removed ubuntu lowlatency kernel and now I am without network
<ddnh> how can I recover connectivity
<tomreyn> ddnh: that's most likely not directly connected and not a kernel issue.
<tomreyn> ddnh: i suggest you ask in #ubuntu
<trippeh> interesting that ubuntu is still shipping alsa-source/alsa-driver, mistake?
<trippeh> that thing has been dead forever
<trippeh> skrech: all the alsa drivers have been shipped in the kernel for a decade+, I dont think this package is actually supposed to exist.
<skrech> yea, my point exactly, trippeh
<skrech> and it's still being built for the new versions of Ubuntu
<skrech> quite strange...
<skrech> btw, I built the snd-usb-audio successfully
<skrech> however, my device is still not working... shit
<skrech> at least it's not giving error message in dmesg
<trippeh> ok - seems alsa-source/drivers carried non-upstreamed things up to 2012. so not quite decade but still long time dead.
<trippeh> are you building it from alsa sources or kernel? if alsa it is probably severely out of date.
<trippeh> you may have better luck just running a newer kernel. say a HWE (hardware enablement) kernel for your xenial
<trippeh> linux-generic-hwe-16.04 or linux-generic-hwe-16.04-edge
<skrech> no i've used apt-get source and downloaded my current kernel version and from there I just built the snd-usb-audio
<skrech> i'm sure that the new kernels don't support my device
<trippeh> right, so you've added some hardware support to the driver?
<JanC> trippeh: I think it's needed for some userspace & documentation stuff (although building the alsa-source binary package isn't really needed for that)
<JanC> specifically the scripts & configs in 'linux-sound-base' & 'alsa-base'
<trippeh> hm yes, seems to provide some driver docs and the like. probably outdated :)
<trippeh> and driver lists
<trippeh> I wonder how much of that stuff is still in use by something
<trippeh> like the blacklisting of alsa drivers if you want to use OSS :)
