#ubuntu-kernel 2005-08-22
<BenC> that's funny
<BenC> that "frenzy" happened about 30 minutes from where I live
<BenC> crazy rednecks
<dilinger> haha
<fabbione> morning
<desrt> :D
<desrt> welcome back, dude
<fabbione> desrt: I HATE YOU ALL! I WANT TO GO BACK IN HOLIDAYS!
<desrt> woh
<fabbione> ;)
<desrt> sounds like you could really use another week or two :P
<fabbione> easily...
<desrt> anyway.. i was hacking yaboot on the weekend
<desrt> as it is, breezy won't boot on an xserve unless it has a videocard
<fabbione> hmmm
<desrt> i have a fix
<desrt> but......
<fabbione> but?
<desrt> it disables the stage 1 yaboot menu
<desrt> ie: it just loads stage 2 directly
<desrt> (stage1 is the part that has a problem)
<fabbione> i don't think that's a solution
<desrt> well, it is for me :)
<fabbione> yeah for you...
<desrt> it's only a problem if you have multiple OSes installed (macos dualboot)
<desrt> i'm working on generalising the code
<desrt> but work has been a bit hectic the past week
<desrt> + i don't know forth :)
<fabbione> BenC: still awake?
<infinity> Gar, is there something mind-numblingly obvious I'm missing, or is the kernel bridging interface really such utter shit?
<infinity> When I unplug a cable from one of the bridged interfaces, the whole bridge goes down.  YAY.
<infinity> (Or power cycle the system it's plugged into, or whatever)
<fabbione> eth brinding?
<fabbione> that shouldn't happen
<infinity> ethernet, yes.  When one interface loses linkbeat, the bridge dies.
<fabbione> are you sure you have no userland tools checking via mii that the iface is connected to a cable?
<infinity> (Doesn't actually down the interface, just stops relaying packets, even after the linkbeat comes back)
<infinity> Oh, it's possible.  THe bridge is on a breezy desktop, so there might be some irritating magic going on.
<fabbione> becasue i use brindging on 2.4 on a dead iface to talk to xen domains
<infinity> Though I can't think of what (no, network-manager isn't installed)
<fabbione> infinity: try to do it in single user mode to see if it is userland?
<desrt> this is completely and totally awesome
<fabbione> desrt: what?
<desrt> excuse the paste
<desrt> 0 > boot hd:2,\\yaboot load-size=24830 adler32=ad6b4eba
<desrt> Loading ELF
<desrt> Config file read, 678 bytes
<desrt> Welcome to yaboot version 1.3.13
<desrt> Enter "help" to get some basic usage information
<desrt> boot:
<desrt>   Linux                      old
<desrt> boot: Linux
<desrt> Please wait, loading kernel...
<desrt>    Elf32 kernel loaded...
<desrt> Loading ramdisk...
<desrt> i can interact with openfirmware (and yaboot) using a whole bunch of methods
<desrt> including -telnet-
<fabbione> yeah i knew that OF has telnetd
<desrt> that's awesome!
<desrt> like, crikey!
* infinity wishes he had a new enough Mac to have an OF that didn't suck.
<fabbione> infinity: ask svenl for upgrades :)
<infinity> You think he'll swing me a dual G5 to replace my G3? :)
<fabbione> i meant software..
<fabbione> and join the queue for g5's ;)
<infinity> Software's a no-go.  You can't update the firmware on the Beige G3 past version 2.4 (which I have)
<infinity> OF didn't start sucking less until 3.0 (NewWorld), though.
<fabbione> i need to hook me up with a nice toy
<fabbione> probably i will soon get money for a new machine
<fabbione> and i don't want it to be i386
<fabbione> either ppc or amd64
<fabbione> not sure yet
<infinity> I like my amd64.
<infinity> And my ppc, for that matter.
<fabbione> or replace my server with a couple of sparcs
<fabbione> OR
<fabbione> make my workstation a new server
<fabbione> and buy a new workstation
<Mithrandir> amd64 is teh love.
<fabbione> yeah i know..
<Mithrandir> and hi and good morning and stuff
<fabbione> hmmm
<fabbione> what's a good brand of ATA harddisks by now?
<fabbione> i have the following options: Maxtor, Seagate, WD 
<calc> seagate seems good and iirc has 5 year warranty
<calc> i want my next system to be an amd64 mac mini
<fabbione> calc: i am looking for 4x300GB harddisk to replace my server
<fabbione> instead of the 8x120GB that i have now
<calc> maxtor/wd have shorter warranties iirc so seagate is likely the most reliable as well
<fabbione> Maxtor has 16MB of cache compared to the 8Mb of the others..
<calc> and the seagate 7200.8 series goes up to 500gb
<fabbione> WD has 320GB instead of 300 of the others...
<fabbione> calc: i am looking at what's available around :)
<fabbione> at least on local hw shops
<calc> oh
<calc> seagate 400gb seems to be generally available so they may have that also
<fabbione> OH right
<fabbione> they are 2 lines below
<fabbione> they are double as expensive as the 300GB
<calc> i see 7200.8 400gb for sale via pricewatch already not sure if regular stores will have that yet
<calc> heh
<calc> yea i see 300gb seagate for $152 and 400gb for $230 on pricewatch which is still a bit expensive
<calc> oh yea the seagate sata drives do ncq as well, not sure about maxtor/wd
<fabbione> IMPRESSIVE
<fabbione> they are selling Apple.. they didn't use to
* calc bbl, bed
<fabbione> Mithrandir: what's a good SATA controller?
<fabbione> given the minimum differnce in price for the hd, it might be worth making the array SATA
<Mithrandir> fabbione: I've actually good experiences with the sii3114
<Mithrandir> fabbione: do you have a kernel for me?
<fabbione> Mithrandir: Herbert is working on it
<Mithrandir> ok, cheers
<fabbione> jbailey: i managed to fix klibc on sparc64.. 
<fabbione> Mithrandir: is the sii from 3ware?
<Mithrandir> no, silicon image
<fabbione> ok
<fabbione> of course my hw pusher doesn't have it
<Mithrandir> it's often onboard.
<fabbione> ah ok..
<Mithrandir> and it's the chip name
<Mithrandir> http://www.hwb.no/artikkel/15307
<Mithrandir> has a test of different controllers.
<fabbione> i am looking for a PCI card
<fabbione> the 3ware they have is the same as in that pic :)
<Mithrandir> well, read the article.  It's fairly decent.
<fabbione> Kjernen benyttet under testingen var 2.6.8.1-5-amd64-k8-smp. Det ble brukt x86_64-versjonen av Warty.
<Mithrandir> you can read norwegian well enough, can't you?
<fabbione> yeah i think so :)
<fabbione> well it's a lot of benchmarks
<fabbione> but tbh i am not too interested into speed...
<fabbione> more about: "It works in Linux,, it doesn't work"
<Mithrandir> all of the controllers there work in Linux, obviously. :-P
<fabbione> yeah clearly :)
<fabbione> looking at the graphs, it makes me wish to buy SCSI :)
<Mithrandir> there's a SCSI controller in there as well
<fabbione> yeah.. that's why :)
<doko> fabbione: the 3ware's are fine controllers, but spend the extra money for the 9500
<fabbione> doko: yeah.. it also costs a fortune :)
<infinity> Adaptec's 2410 isn't so bad. (or 2810 if you need 8 ports)
<infinity> I'd push the 3ware stuff if money was no object, but they are very pricey.
<fabbione> yeah
<fabbione> but given that it's one time expense.. i guess i can look into 3ware too
<mjg59> fabbione: I have ACPI fixup patches for you. Shall I just email a tarball with justification?
<fabbione> mjg59: that would do
<mjg59> fabbione: Ok, cool
<fabbione> mjg59: from now on, please start to CC BenC 
<fabbione> he will take over the kernel soon..
<mjg59> fabbione: Will do
<mjg59> fabbione: benc@canonical.com?
<fabbione> mjg59: meh.. hold on..
<fabbione> ben.collins@ubuntu.com
<mjg59> Ok
<mjg59> fabbione: Mailed
<fabbione> mjg59: ok
<fabbione> you gotta be kidding...
<fabbione> 300KB of tar.gz?????
<mjg59> fabbione: Most of that's a replacement for the existing acpi update patch
<fabbione> ok
<fabbione> mjg59: want to take a look at bugzilla and start marking bugs as pending upload?
<mjg59> fabbione: Sure, will do
<fabbione> jbailey: ping?
<jbailey> fabbione: pong
<fabbione> jbailey: did you like the klibc upload?
<jbailey> I saw that it had been done, but it's just coming down now. =)
<fabbione> nothing too fancy..
<fabbione> change the B-D for new kernel headers
<fabbione> added a specific sparc64 patch to fix FTBFS
<fabbione> that doesn't touch any of the other code
<fabbione> so pretty safe
<mjg59> fabbione: The patch in 11813 ought to be applied
* fabbione checks
<fabbione> OH DAMN SHIT
<fabbione> there is no connectivity with uk toady
<fabbione> like yesterday
<fabbione> ok.. it's taking ages...
<fabbione> mjg59: i need to take my wife to the doc and i will be back in about 2 hours or so
<fabbione> probably more...
<fabbione> just create a list and mail it..
<fabbione> or whatever you prefer..
<fabbione> just don't leave the list here on IRC :)
<mjg59> fabbione: No problem
<fabbione> thanks
<jbailey> fabbione: Looks good, thanks.
<fabbione> i think nobody noticed before, because klibc was probably built on sparc32 or so
<fabbione> that's what come up to mind now..
<fabbione> but we don't care to build in 32 bit
<fabbione> given that: A) we don't support 32bit b) it's all used once at boot and trashed away
<fabbione> anyway.. time to go
<fabbione> bbl
<fabbione> re
<fabbione> BenC: ping?
<fabbione> mjg59: i got the patches..
<mjg59> fabbione: Rock
<fabbione> mjg59: are all the patches done to be applied at the end of 00list?
<fabbione> with the order you gave.. or somewhere else?
<mjg59> fabbione: Which ones? The first batch or the second batch?
<fabbione> both...
<mjg59> The second batch should all go after the first batch, but the order doesn't matter
<mjg59> The first batch should have the big patch first, followed by acpi-revert-pci-interrupt-resume
<fabbione> ok
<fabbione> than all the others in no special order...
<mjg59> Yeah
<fabbione> ok
<mjg59> The others all depend on the first two, but other than that are order independent
<fabbione> ok
<fabbione> on which arches did you test them?
<fabbione> do they build on ia64?
<mjg59> Tested on x86
<fabbione> what about amd64?
<mjg59> I don't have access to any ia64
<mjg59> I'll check amd64 now
<fabbione> ok.. do you don't know if they build on amd64/ia64...
<fabbione> try to be around tomorrow than
<fabbione> if you can
<fabbione> i will start merging now
<fabbione> but i will build tomorrow probably...
<mjg59> Sure, no problem
<mjg59> fabbione: Oh, one thing I forgot to mention - the acpi-i2c one adds a new config option
<fabbione> i saw that
<mjg59> Ok
<fabbione> i guess M is fine...
<mjg59> Yup
<fabbione> perfect
<fabbione> hmmm agp-pm...
<fabbione> didn't we include that one already?
<mjg59> I don't think so
<fabbione>   * Add PCI-E suspend/resume support:
<fabbione>     - Add patch drivers-pci-pcie_resume-pcie.dpatch.
<fabbione> no
<fabbione> it was the PCI-E
<mjg59> Yeah
<fabbione> mjg59: where all these patches are coming from?
<fabbione> just to annotate them properly...
<mjg59> fabbione: The acpi ones are all from acpi upstream, except for the ones that we were already carrying
<mjg59> toshiba-acpi-dev is from John Belmonte's website
<mjg59> agp-pm is from the suspend2 tarball (which contains no indication of who wrote it)
<mjg59> acpi-i2c is from Bruno Ducrot's website
<mjg59> The reboot patch is me
<fabbione> ok
<fabbione> mjg59: only 4 left to apply :)
<mjg59> fabbione: Woo!
<mjg59> fabbione: I've got another couple for you...
<mjg59> (But then that's it for the day)
<jbailey> mjg59: At some point when you have t ime, can I get you to look over the DSDT patch that I've got to see why the classic initrd case fails?
<mjg59> jbailey: I can have a go, yeah
<fabbione> mjg59: send me...
<jbailey> mjg59: Either that or do you think I can get rid of that case an only handle having a DSDT.aml file in the initramfs?
<jbailey> the initramfs case works.
<mjg59> Breezy is going with initramfs?
<fabbione> mjg59: we already switched
<jbailey> mjg59: Yes, it's default already. =)
<mjg59> Yeah. I'd drop the initrd support, then.
<jbailey> mjg59: Nice, saves much trouble. =)
<jbailey> That's the part of the patch I'm having trouble with.
<fabbione> applying patch external-drivers-acpi-hardware-hwsleep_gpe-specs to ./ ... failed.
* fabbione GRRRS
<mjg59> Oops
<mjg59> That's odd
<mjg59> Oh, shit
<mjg59> Sorry, I accidently diffed it from the wrong directory level
<mjg59> Looked like drivers-acpi-sleep-main_make-system-ready-to-resume.dpatch has the same problem
<mjg59> fabbione: Ok, that's it for now
<fabbione> mjg59: ok.. everything applies perfectly
<fabbione> mjg59: got the last mail
<mjg59> Rock
<fabbione> mjg59, BenC: i am going to commit the all ACPI stuff untested
<fabbione> i only know it applies clean
<mjg59> Ok
<fabbione> it will need a proper changelog entry
<fabbione> test build
<fabbione> and overall configs update
<fabbione> on all arches..
<mjg59> The ACPI stuff is all from upstream, and I haven't /seen/ any complaints on other architectures
<fabbione> mjg59: well.. i would like to see it at least builded everywhere
<mjg59> Sure
<fabbione> BenC: you might have to ask elmo to upgrade some of the chroots.. iirc i did bump a B-D recently
<BenC> so you have to build it on all architectures first, then update the debian/abi/* and then do the source upload?
<BenC> oops
<fabbione> * committed kernel-team@ubuntu.com--2005/kernel-debian--preX,11--2.6.12--patch-18
<fabbione> ok this is the commit with all the ACPI crack
<fabbione> https://bugzilla.ubuntu.com/show_bug.cgi?id=11813
<fabbione> we forgot the patch in here
<mjg59> Oops
<mjg59> Sorry, meant to send that to you
<fabbione> mjg59: is that patch still needed?
<mjg59> Yeah
<fabbione> oh my mother just bored me enough on the phone to push me to look at bugzilla for fun
<mjg59> Haha
<fabbione> i need to go and start to cook dinner
<fabbione> BenC: do you want to take care of it?
<fabbione> just add it at the end of the list
<fabbione> we also need that PATA patch.. and i think we are done for 7.11
<fabbione> there is enough crack for the rest of week
<fabbione> EHHHH??!?!?!?!???
<fabbione> ld  -o tests/nfs_no_rpc crt0.o tests/nfs_no_rpc.o libc.a /usr/lib/gcc/sparc-linux-gnu/4.0.2/libgcc.a
<fabbione>  /usr/lib/gcc/sparc-linux-gnu/4.0.2/libgcc.a(_muldi3.o): In function `__muldi3':
<fabbione>  : undefined reference to `.umul'
<fabbione> I DID FUCKING TEST BUILDED IT BEFORE UPLOAD ON EXACTLY THE SAME CHROOT
<fabbione> ah no..
<fabbione> different binutils..
<fabbione> Grrrrr
<BenC> sure
<fabbione> BenC: cool
<fabbione> BenC: if you feel lucky today, there is libaio that is not ported to sparc ;)
<fabbione> it's missing an include file with some asm to generate direct syscalls to the kernel bypassing libc
<fabbione> ;)
<jbailey> fabbione: Why?
<fabbione> async i/O
<fabbione> it's faster for certain apps like DB
<fabbione> (that's the answer i got from upstream at least)
<fabbione> anyway... i need to go now
<fabbione> i might pass by later
<BenC> later
<BenC> I'll check into libaio after I do a kernel build
<BenC> or better, while the kernel is building
<fabbione> BenC: that one is off line and just for fun :)
<fabbione> it's not important for sparc anyway
<BenC> ok
<michele> hello
<michele> I'd like to know if this patch (or something to that effect) is going to make into breezy: http://marc.theaimsgroup.com/?l=linux-kernel&m=111504542402455&w=2
<fabbione> no
<fabbione> that patch is broken
<fabbione> and breaks SCSI
<fabbione> + other stuff
<michele>  oh nice...
<michele> does something else exists to have power mgmt in SATA systems?
<fabbione> not yet
<michele> so I guess that patch isn't even recommended to apply by myself right?
<fabbione> 9/10K
<michele> uh?
<fabbione> nope
<fabbione> don't apply it
<michele> ok... sigh
<mjg59> fabbione: I still don't see any way it can break SCSI
<mjg59> The only way it touches the SCSI layer is to add hooks for suspend/resume
<mjg59> On the other hand, it doesn't /work/ for SCSI
<fabbione> mjg59: ask greg or jeff.. i really don't know and i don't want to experiment it at 2 weeks from preview
<mjg59> fabbione: I spoke to alan about it last week
<fabbione> alan C?
<mjg59> greg and jeff haven't replied to my mails about it
<mjg59> Yeah
<fabbione> what did he say?
<mjg59> He said he couldn't see any problems with it
<mjg59> The only code that touches the SCSI subsystem is scsi_bus_suspend and resume
<mjg59> As far as I can tell, the objection is that it doesn't successfully suspend/resume SCSI (but then, that doesn't work /anyway/)
<mjg59> The rest of it's all safely contained in the sata layer
<fabbione> i think the issue was not SCSI as drivers, but as transport layer
<mjg59> It doesn't touch that part of the kernel
<mjg59> It's all libata stuff except for scsi_bus_suspend and scsi_bus_resume
<fabbione> i know.. but that's what they were talking about
<michele> fabbione, I can offer to test it in my thinkpad in case you decide to build a package. I have a spare 5GB.
<mjg59> There's absolutely no way that that code can touch it
<fabbione> michele: one test is not enough over 2309208 millions different combination of hw
<michele> fabbione, I know... just in case you needed it. Not trying to push you.
<mjg59> The only thing it will do on a SCSI setup is check whether the driver has a suspend method, and if so call it
<fabbione> let me ask again...
* lamont wonders if we have a newer-and-better acpi patch.  And if mjg59 has an ia64 box at home
<fabbione> lamont: build or try to from baz..
<mjg59> fabbione: I'm prepared to believe that it's a patch that won't always work, but I can't see any way that it can make things worse than they currently are
<mjg59> lamont: Newer acpi crack is in, I have no ia64
<fabbione> i committed all the acpi crack 2/3 hours ago
<lamont> mjg59: coolness
<mjg59> lamont: If you want to send me an ia64 laptop...
<lamont> mjg59: I don't think they exist, but a zx2000 might be able to land on your doorstep
<lamont> it's kinda like a laptop :-)
<lamont> in that it'll fill your lap.
<mjg59> lamont: Hmm. Unconvinced.
<mjg59> Oh, it's on of /those/
<mjg59> Did Microsoft ever ship Windows for Itanium?
* lamont _thinks_ so.
* lamont checks
<fabbione> lamont: i am still waiting for my ia64 and hppa :)
<lamont> mjg59: HP certainly shipped it.  I expect that MS is at least supporting it in some manner....
<fabbione> mjg59: Jeff says 2 things about that patch that he wrote
<fabbione> a) it's experimental and not ready for upstream
<fabbione> b) it needs a lot of SCSI love to work properly
<mjg59> fabbione: Right. But it /does/ work on some systems.
<fabbione> yes.. but it might as well breaks other
<fabbione> or make them worst than they are
<mjg59> fabbione: Uh. At the moment, suspend/resume is broken on *all* SATA machines.
<mjg59> There's no way to make them worse.
<fabbione> dude.. that's what he said right now
<mjg59> I entirely understand why it's not ready for upstream. He wants it to work properly.
<mjg59> But failing to work in some cases is still better than failing to work in all cases.
<lamont> mjg59: there's an HP org that supports ia64/windoze
<mjg59> lamont: Wow
<lamont> not sure how much of that is just front-ending M$, though
<fabbione> actually....
<fabbione> mjg59: the patch can be splitted in 2 i think
<fabbione> mjg59: scsi and sata
<mjg59> fabbione: Mm?
<fabbione> they look sort of indipendet one from each other..
<mjg59> fabbione: No - the SCSI part is needed to call the SATA suspend/resume methods
<fabbione> it doesn't look like...
<mjg59> Check the scsi_bus_suspend routine. It stops the SCSI queue, checks whether the driver has a suspend method and then calls it
<mjg59> +	if (sht->suspend)
<mjg59> +		err = sht->suspend(sdev);
<fabbione> ah ok..
<mjg59> On SATA devices, that'll call ata_scsi_device_suspend
<mjg59> On SCSI devices, it's a noop
<mjg59> Until someone writes the support for them
* fabbione ponders...
<mjg59> So the only thing it does on SCSI systems is to call scsi_device_quiesce(sdev) and scsi_device_resume(sdev);
<mjg59> Which is safe
* fabbione ponders again
<fabbione> BenC: what do you think?
<fabbione> i am going to sleep on it..
<fabbione> BenC: if you think the patch is reasonable.. go ahead and commit it..
<fabbione> leave a note in an email on what you will manage to finish, so i don't need to spend time tomorrow digging around...
<fabbione> good night ladies
<mjg59> Night
<fs> mjg59: are the acpi patches for the ubuntu kernel somewhere public?
<mjg59> fs: They're in the baz archive
<fs> is it more than acpi-20050729-2.6.12.patch.bz2?
<fs> or git-latest acpi stuff in -mm?
<mjg59> It's acpi-20050729 plus most of the to-linus from git
<mjg59> So it ought to be pretty close to 2.6.13 mainline
<fs> I see
<fs> the acpi patch made battery and thermal working on my turion64 box, a 2.6.13-rc git snapshot from a couple of days ago did not
<mjg59> You might want to try the ec_burst_mode parameter
<mjg59> Or something like that
<fs> where? 
<mjg59> On the kernel command line
<mjg59> Hang on a sec
<mjg59> Depending on your kernel version, there'll either be an ec_polling parameter or an ec_burst= parameter
<mjg59> ec_polling will force a kernel that uses burst mode to use polling mode. ec_burst=1 will force a kernel that uses polling mode to use burst mode
<fs> I have 2.6.12.5+acpi now, and that looks like it has ec_polling
<BenC> anyone been able to verify if the acpi patch fixes any of the reported bugs?
<mjg59> BenC: It ought to fix the various delayed ACPI event bugs, the ones where resuming causes "scheduling while atomic" errors and the fact that the screen doesn't lock when the lid is closed
<mjg59> But I wasn't bitten by any of those, so it's a bit hard to tell for certain...
<BenC> build fails on ppc
<BenC> kernel/power/main.c: In function `suspend_finish':
<BenC> kernel/power/main.c:126: error: structure has no member named `leave'
<BenC> kernel/power/main.c:127: error: structure has no member named `leave'
<BenC> debian/patches/drivers-acpi-sleep-main_make-system-ready-to-resume.dpatch is the culprit that adds those lines
<mjg59> BenC: Argh. A patch hunk has gone missing, somehow.
<BenC> yeah, it's in the patch
<BenC> but include/linux/pm.h doesn't seem to contain the patch for the leave member
<BenC> wtf
<mjg59> BenC: Ok, got a fixed one for you
<mjg59> I'll mail it now
<mjg59> BenC: Ok, mailed
<BenC> duhthe patch isn't getting applied
<mjg59> BenC: Uhm. If the patch isn't getting applied, how does it cause the build to fail?
<BenC> let me check something
<mjg59> But yeah, there was certainly a hunk missing from that patch
<BenC> ok
<BenC> the patch I was looking at wasn't getting applied
<BenC> must be an old one
<BenC> the patch that is getting applied didn't have the pm.h hunk
<BenC> thanks, got the updated one
<BenC> starting the build over
<mjg59> BenC: Cool. Sorry about that.
<BenC> no problem
<BenC> mjg59: drivers-acpi-sleep-main_make-system-ready-to-resume.dpatch was not listed in 00list-7.11, is there any order that it should be in regards to the other acpi patches?
<mjg59> BenC: After the global patch. Other than that, I don't think it matters.
<BenC> hmm
<BenC> I don't think fab added all the patches in 00list-7.11
<BenC> I'll get it squared away
#ubuntu-kernel 2005-08-23
<lamont> fabbione: util-linux built, just need to do some more testing, and then upload/merge/upload
<BenC> lamont: how invasive are the hppa patches for other architectures?
<BenC> I noticed most of the changes outside of hppa are related to types, do these really affect non-hppa, or is it just mostly non-changes when compiled on something other than hppa?
<lamont> BenC: it was "scary" - so we left them separate.
<lamont> I know that people have built i386 kernels from the hppa tree with no ill effects
<lamont> dunno how recently, thouhg
* lamont must really run
<lamont> back on in about 4.5 hours.
<fabbione> BenC: i did rename some of the patches to match our name convetion. they are all at the end of the 00list-7.11 in the same order as mjg59 did push them to us
<fabbione> so they are pretty simple to identify
<fabbione> i didn't remove the old patches yet.. i tend to keep such big changes around easily reversible for at least one release
<BenC> hey
<fabbione> hey Ben
<BenC> the acpi doesn't compile, so I am figuring out why
<fabbione> yes i am looking at it too
<BenC> got access to concordia, so I am doing builds there
<fabbione> the toshiba acpi is one of them
<BenC> the one place I found is the toshiba
<fabbione> eheh so am i :)
<fabbione> # CONFIG_INPUT_ACERHK is not set
<fabbione> this needs to be N on amd64...
<fabbione> klibc_1.0.14-1ubuntu1_sparc.changes ACCEPTED
<fabbione> finally!
<fabbione> we can install kernels on sparc again
<fabbione> ok.. removing toshiba and setting ACER=n on amd64, it builds...
<fabbione> BenC: did you get access to davis and halley too?
<BenC> no
<BenC> btw, I am doing i386 build
<BenC> does the toshiba need to be working on i386?
<lamont> fabbione: wanna test a util-linux for me?
<fabbione> BenC: it doesn't build on amd64.. and it should on i386 at least
<fabbione> lamont: sure..
<lamont> deb http://people.debian.org/~lamont/util-linux /
<lamont> it's the debian version of hwclock*.sh, I need to go make the ubuntu changes again
<fabbione> i guess that requires a reboot to verify that it works.. but it's ok..
<fabbione> i can do it
<lamont> if it's happy, I'll bump it to -6 and upload
<fabbione> lamont: happy to what degree?
<fabbione> that it doesn't hang at boot?
<fabbione> or that it works?
<lamont> pretty much - It'd be nice to know that hwclock*.sh are spitting things out in some semblance of good format
<fabbione> ok...
<lamont> and that ocfs2 works
<fabbione> lamont: ocfs2 will have to wait that i upload the next kernel
<fabbione> and upgrade the laptop
<fabbione> it's in a special setup that initrd doesn't handle and that initramfs should...
<fabbione> but the guy that did push the patch is good..
<jbailey> fabbione: Eh?
<fabbione> jbailey: it's that setup in which i have /boot on IDE and / on usb..
<fabbione> remember i was talking about sleep N in initrd?
<fabbione> because scsi over usb takes time to init..
<jbailey> Hmm.
<jbailey> I have a sleep 2 after the PCI bus for the USB bus  to populate.
<jbailey> Is that not enough for this?
<fabbione> + if / is on subsystem foo, and /boot on bar, bar doesn't get included in the initrd 
<fabbione> jbailey: in the initrd there is no sleep
<fabbione> i didn't check initramfs yet
<jbailey> initramfs has a sleep2
<jbailey> Otherwisie it goes by way too fast.
<fabbione> and as i said i need to upgrade it when i have time to recover in case of mess
<fabbione> right now i am just too busy
<desrt> jbailey; since switching to initramfs i'm getting a lot of warnings during startup
<desrt> jbailey; you probably know about these?
<jbailey> desrt: Depends on the warning. =)
<fabbione> lamont: is util-linux enough for the clock thingy?
<desrt> lvm
<fabbione> or do i need to upgrade all of them
<jbailey> desrt: AFAIK there should be no lvm warnings.
<desrt> i don't remember exactly... but it's something about can't initialise volume group sda1
<fabbione> desrt: LVM tends to spit out gratuitous warnings
<desrt> nod.  it certainly has no effect on my system successfully booting
<fabbione> nope.. that's probably lvscan or something
<fabbione> that hits automatically all the devices
<lamont> util-linux is enough for the clock
<lamont> mount is enough for ocfs2
<fabbione> lamont: ok.. i will be able to test ocfs2 probably tomorrow
<fabbione> and mount immediatly.. for regressions
<fabbione> if there are no regressions, can you upload and i will test after?
<lamont> fabbione: yes
<lamont> the best part is that the diff between debian/ubuntu is now minimized
<fabbione> lamont: ehehe
<fabbione> Setting up util-linux (2.12p-5.1) ...
<fabbione> Installing new version of config file /etc/init.d/hwclock.sh ...
<fabbione> Installing new version of config file /etc/init.d/hwclockfirst.sh ...
<fabbione> BenC: i will start test builds on ppc and ia64...
<jbailey> fabbione: When is your next kernel upload?
<fabbione> sparc can wait a bit given that there is no ACPI :)
<fabbione> jbailey: soon..
<fabbione> jbailey: and it will be my last kernel upload :)
<jbailey> I need one with the DSDT patch in it.
<fabbione> jbailey: than you have more or less today to give me the patch
<fabbione> brb
<jbailey> Lovely.  That's sometime in the next 24 hours, right? =)
<lamont> fabbione: 69 lines of diff -u atm, the first 39 of which are changelog
<lamont> hrm... oops.
* lamont grumbles at the 2 hour glibc build time
<lamont> fabbione: I'm going to sleep now, but when I wake up, I'll see about uploading
<lamont> or will you be done playing with ocfs2 then?
<jbailey> Yup, bedtime here too.
<jbailey> fabbione: When I get up in the morning I'll do a test build of the kernel.  I think I have a patch that will work (It's one I tested before, but I want to do another round of testing)
<jbailey> fabbione: I need to know how you do your massive ccache speedups, though, if possible.  The build time on the kernel is bloody forever.
* jbailey -> sleep
<fabbione> re
<fabbione> lamont-away: i hope i will be able to test ocfs2 before you wake up
<fabbione> jbailey: i just use ccache in the normal way
<fabbione> the speed up is done by export CONCURRENCY_LEVEL in your env
<fabbione> that's like passing make -j$VALUE
<fabbione> if your ccache is populated, you will switch to disk I/O
<fabbione> that's up to your disk at that point
<fabbione> and yes.. within the next my 24hours
<fabbione> that means when i will wake up tomorrow there must be a patch
<fabbione> RIDE THE SPLIT! GO FEENODE!
<fabbione> mjg59: up till now the only failure i get is the toshiba ACPI on amd64
<fabbione> it builds on i386 tho
<fabbione> i still need to hit ppc64
<fabbione> ia64 looks good
<fabbione> hmmm
<fabbione> i386 just farted
<fabbione> the toshiba patch is borked
<fabbione> drivers/acpi/toshiba_acpi.c: In function `toshiba_acpi_init':
<fabbione> drivers/acpi/toshiba_acpi.c:878: error: `status2' undeclared (first use in this function)
<fabbione> drivers/acpi/toshiba_acpi.c:878: error: (Each undeclared identifier is reported only once
<fabbione> drivers/acpi/toshiba_acpi.c:878: error: for each function it appears in.)
<fabbione> lamont-away: it seems that hwclock did work fine here.
<fabbione> lamont-away: OCFS2 test passed
<fabbione> you are good to go
<doko> fabbione: 12708, our linux-source builds are fine building XFS modules?
<fabbione> doko: our kernel builds with 3.4
<fabbione> and we build XFS
<fabbione> i have no idea with 4.0
<fabbione> last build i did was a long while back
<doko> fabbione: hmm, where do I set the compiler version for the debian build?
<fabbione> doko: to do what?
<fabbione> right now if you want to use the default compiler just stop applying the patch that forces gcc-3.4
<doko> ok
<fabbione> mjg59: wake up dude...
<doko> bah, doesn't get to the modules ...
<fabbione> told you...
<fabbione> we don't support kernel compilation with 4.0
<fabbione> that's it..
<fabbione> he needs to get over it
<doko> hmm, close the report?
<fabbione> doko: NOTABUG
<fabbione> it's not a supported combination
<doko> done
<fabbione> *** Warning: "acpi_ec_read" [drivers/acpi/i2c-acpi-ec.ko]  undefined!
<fabbione> this is on amd64
<fabbione> mjg59: WAKE UP DUDE?
<fabbione> AHHHHHHHH
<fabbione> dpatch sucks
<fabbione> the toshiba thing doesn't work, because the patch doesn't apply, and there is no error reported
<mjg59> fabbione: Ho
<fabbione> 2 dpatches generate .rej
<fabbione> and dpatch doesn't catch them
<fabbione> i noticed by mistake
<mjg59> Oh. Fun. Which ones?
<fabbione> one is the toshiba..
<fabbione> i am trying to find the other..
<fabbione> in fact the reject bit was int status2;
<fabbione> that's exactly why we were getting the above failures
<mjg59> That is weird. It applied fine here.
<mjg59> Bah.
<fabbione> yeah it applies fine here too
<fabbione> expect that there is a .rej
<fabbione> now it did build perfectly..
<mjg59> Weird
<fabbione> now it builds fine :)
<mjg59> Hurrahj
<Mithrandir> jbailey: is suspend to disk supposed to work with initramfs?  It seems extraordinarily unstable for me.
<fabbione> MUHA MUHA MUHA
<jbailey> Mithrandir: works on my laptop.  What problem are you having?
<fabbione> the last rej hunk is the missing exported symbol that was causing the above
<Mithrandir> jbailey: spits out "a" six times then sits around for a while doing nothing.
<jbailey> Mithrandir: At what point?
<Mithrandir> jbailey: just after loading the kernel.  Checking if I can reproduce it now
<jbailey> Mithrandir: Basically, all suspend to disk does is pokes the major:minor into /sys/power/resume or something like that.
<mjg59> Mithrandir: "a"s are from usplash
<mjg59> Mithrandir: Try without quiet/splash
<jbailey> Mithrandir: So from a running system, check to make sure it's set to where your swap is.
<jbailey> Mithrandir: If it is, all further problems are not initramfs.
<fabbione> jbailey: initramfs is still too fast for / over scsi over USB
<Mithrandir> well, now it resumed (As in, got the state off disk), then gave me a screen reverse-video screen with the cursor blinking on it.
<jbailey> Mithrandir: Can you ssh to it?  It would be worth knowing whether that's a video refresh issue or a fucked-machine issue.
<jbailey> fabbione: Can you take a look and tell me where you need pauses added?  Since I don't have that setup, all I'd be doing is guessing.
<Mithrandir> jbailey: no ping, caps lock doesn't work.
<mjg59> jbailey: There's no way of knowing for sure how long USB will take to populate
<fabbione> jbailey: scripts/functions.. i added a sleep 5 before and after calling scsi-$something..
<jbailey> mjg59: What's the right solution?
<mjg59> Mithrandir: 2.6.12?
<fabbione> at the end of functions
<Mithrandir> mjg59: yes.
<fabbione> jbailey: just a sec and i will be more precise
<mjg59> Mithrandir: PM is generally broken on our 2.6.12. Wait for the one fabbione is currently building.
<Mithrandir> mjg59: ok
<mjg59> jbailey: If the root device hasn't appeared and looks like it might be USB, spend a while spinning?
<jbailey> fabbione: If you look in /usr/share/initramfs-tools/scripts/functions
<fabbione> jbailey: yes.. it's in there.. but just one sec. i am powering it on
<jbailey> fabbione: TThe load_modules function is the one you want.  Currently I have:
<jbailey>         # Give the USB bus a moment to catch up
<jbailey>         sleep 2
<fabbione> jbailey: it's a bit after that
<fabbione> if you can wait a minute that's booting..
<jbailey> Sure. =)
<fabbione>         done
<fabbione>         ide_boot_events
<fabbione>         scsi_boot_events
<fabbione> }
<fabbione> i did add sleep 5 before scsi_boot_events 
<fabbione> and for sake 5 after
<jbailey> And that still wasn't enough?
<fabbione> that gives enough time for the disk to appear in /sys
<jbailey> Oh ouch. =(
<fabbione> i did only one test adding 5 at the same time
<fabbione> otherwise scsi and usb-storage are probed
<fabbione> but not sd_mod
<jbailey> So you shouldn't need the 5 after, I think.
<fabbione> mostlikely not..
<jbailey> Is there no way to tell that the bus is still scanning?
<fabbione> but since i didn't read all the code
<fabbione> dunno..
<fabbione> i will need to investigate that
<fabbione> but that's not todays stuff
<jbailey> Ayup
<jbailey> Erp, the concordia i386 chroot doesn't have kernel-wedge and stuff installed?
<fabbione> yes it does
<fabbione> linux32 dchroot -c breezy-i386
<jbailey> Doh.
<jbailey> I'm in hoary-i386
<jbailey> my bad
<fabbione> jbailey: if you can give me a few more minutes.. i have almost done with concordia
<fabbione> and i can hand over to you a kernel source
<jbailey> Cool.  I'm just going to make sure the patch applies cleanly to what I've got right now.
<fabbione> jbailey: wait.. what you got there is ages behind
<fabbione> you are really going to waste your time
<fabbione> i so much have the feeling that i am going to regret the next patch i will apply...
<fabbione> mjg59: do you have the SATA GO FUCK YOUR SELF SLEEP AND RESUME patch for 2.6.12?
<fabbione> because the one i got yesterday doesn't apply
<fabbione> and i don't plan to rediff all that stuff
<fabbione> i know.. i know i am going to regret to add this patch...
<fabbione> jbailey: i am doing the last test build for today.. and i can give you the source.
<fabbione> it's tested only ONE flavour on amd64
<mjg59> fabbione: Nope. I'll generate you one now.
<fabbione> it means that it might not build on other arches
<jbailey> fabbione: Lovely.
<jbailey> Where do I find it?
<fabbione> jbailey: as soon as i am done i will tell you and it will be on concordia
<jbailey> fabbione: Do you know about how long?
<fabbione> jbailey: 10 minutes?
<jbailey> Cool.
<mjg59> fabbione: Mailed
<fabbione> mjg59: building...
<mjg59> fabbione: Cool
<fabbione>   * Add experimental sata suspend remove support (it clearly cannot be worst 
<fabbione>     than it is now):
<fabbione>     - Add patch external-experimental-sata_suspend-resume.dpatch.
<fabbione> michele: you got your patch.. now.. next time i pass by italy, you will offer me a beer
<michele> fabbione, let's make them two :)
<fabbione> michele: where do you live in italy?
<zul> heylo
<michele> fabbione, treviso
<michele> where are you from?
<fabbione> ah
<fabbione> michele: i am from Rome, but i have relatices in Venice..
<fabbione> hey zul
<fabbione> relatvies even
<fabbione> i pass by that area quite often
<michele> ok, let me know next time :) (micampe@micampe.it)
<michele> and well'have a beer or something
<fabbione> michele: yeah.. it won't be before Xmas
<michele> ok, let's hope I'm not in france by then :)
<fabbione> what?? NO BEERS?
* fabbione removes the sata patch...
<fabbione> jbailey: building the latest diff.gz for you right now...
<michele> ahah
<michele> fabbione, I'll make sure you'll have your beers before leaving
<fabbione> eheh
<michele> anyway... when will that kernel be packaged and distributed?
<fabbione> no later than monday
<michele> ok. colony 3 looks decent, I might try to install it
<zul> fabbione: sata patch sucked?
<fabbione> zul: yeah..
<fabbione> i know i will regret it for the rest of my life
<zul> figured
<fabbione> but this is my last kernel upload.. or at least i hope so
<fabbione> so BenC will hunt me down to death at the next Ubuntu conference
<chmj> I'll help him 
<fabbione> jbailey: uploading now to concordia
<fabbione> nah i will still be around till breezy release
<fabbione> and probably after for the cluster stuff
* jbailey blinks
<jbailey> fabbione: You off kernel stuff completely?
<fabbione> jbailey: almost :)
<chmj> fabbione: you leaving kernel for userspace ?
<fabbione> it's not my decision, but i agree with who made it..
<fabbione> the insanometer is out of scale here
<michele> fabbione, will you regret even after my delightful beers?
<michele> home-brewed just for you!
<fabbione> michele: the dark side of the force phear you must
* fabbione takes a long break
<zul> fabbione: so ill tell benc to where to get my stuff whee..
<fabbione> zul: sure.. 
<fabbione> i did merge your last stuff yesterday...
<fabbione> it's in for the next upload
<fabbione> but i remember you did a lot of patches while i was in holidays
<fabbione> you didn't port them to 7.11, did you?
<zul> fabbione: no they were changes to the ide subsystem 
<fabbione> hm ok...
<zul> they were backported from .13 so im not sure if we want them there or not
<fabbione> hmmm
<fabbione> i would have to see them again...
<fabbione> probably it's not a good idea to merge too much from head
<zul> yeah i was thinking that
<zul> ill send you them tonight..it was just two patches though
<zul> both from fedora that got merged into head
<zul> both from alan cox
<fabbione> ok
<fabbione> i will look at them tomorrow morning
<fabbione> i have Danish class later
<zul> okie dokie
<BenC> how do I revert a changed file in baz?
<fabbione> BenC: hey..
<fabbione> did you already commit the file?
<BenC> hey
<BenC> no
<BenC> need to revert to get your changes
<fabbione> are there more changes or only that one?
<BenC> just that one
<fabbione> baz undo
<BenC> ok
<fabbione> note that it will create a ,,LONGDIRECTORYNAME that you can safely remove
<fabbione> BenC: i did fix all the ACPI stuff
<fabbione> it builds everywhere.. 
<fabbione> we need to re-test build, save the ABI files and we are ready to upload..
<fabbione> what time is it now where you live?
<BenC> 10am
<fabbione> do you think you can come tomorrow at 8am?
<BenC> yeah
<fabbione> so we can do the upload stuff together
<BenC> 10:20am I mean
<fabbione> and i will drive your trough the baz dance
<fabbione> yeah.. 
<BenC> sure thing
<fabbione> and how to start the new release
<fabbione> so after that you can take over..
<fabbione> or almost :)
<fabbione> we are waiting for a patch from jbailey 
<fabbione> to attach DSTS to initramfs
<fabbione> that's the latest missing code for 7.11 in what was my list
<fabbione> if you have more, go ahead and add it today
<fabbione> tomorrow i will do the build orgy  everywhere
<lamont-away> fabbione: woot!
<fabbione> if you have time to test the kernel, that would be very good too...
<fabbione> lamont-away: http://people.ubuntu.com/~fabbione/OCFS2-1.1.0.png
<fabbione> now gimme the util-linux crack :)
<fabbione> anyway i am off for the next 4 hours and 30.. probably more
<fabbione> danish class will start soon :)
<fabbione> and i will pass by again
<fabbione> lamont-away: in case, can you help BenC with baz while i am not around?
* fabbione goes off line
<fabbione> later guys
<fabbione> lamont-away: you also want to check that hppa still applies properly to 7.11
<fabbione> i had no time to look at it
<lamont-away> fabbione: uploading util-linux, then I have a task to do here, and off to the office.
<lamont-away> will do my best to help BenC if I'm here.
<BenC> lamont-away: maybe you can help me get my hppa installed :)
<lamont-away> that's easier.
<lamont-away> http://people.ubuntu.com/~lamont/ubuntu-hppa/tree is a hoary archive for hppa
<lamont-away> alternatively, you start with a sarge install, and then dist-upgrade it to breezy with a few well placed --reinstall's as needed.
<lamont-away> still no d-i for hppa/ubuntu
<BenC> I have woody on my hppa, so maybe that wil work
<lamont-away> should - dist-upgrade to hoary, then dist-upgrade to breezy (dunno if you can skip...)
<BenC> can someone else look at bug 3117 and tell me if that looks like an acpi problem, perhaps something with cpu frequency changes for power saving?
<mjg59> That's an unusual one.
<infinity> Hrm, I have a machine that does on-demand frequency scaling, and I've never seen the clock skew like that.
<mjg59> Normally excessive work results in missed timer interrupts and a slower clock
<infinity> In fact, most of us do.
<infinity> I'm willing to bet mjg59 has a few dozen. :)
<mjg59> "I'm seeing this behavior on a brand new Dell so I don't think it's due to crappy
<mjg59> hardware." ha ha ha
<mjg59> Oh - if it's related to spread spectrum stuff, then it probably is broken hardware
<mjg59> The idea there is to change all the clocks slightly to reduce RF interference
<mjg59> Which tends to break stuff
<infinity> Spread spectrum is such utter crack.
<infinity> When my phone rings, all the monitors in the house shake, but clearly I should be concerned about the tiny amount of RF interference from my RAM.
<BenC> mjg59: so is there a workaround other than telling people to disable spread spectrum?
<mjg59> BenC: Not that I know of. It's not something that's ever hit me.
<BenC> damn
<BenC> even google searching just says "disable spread spectrum"
<BenC> even the NTP site says to do it
<jbailey> BenC: ping?
<jbailey> mjg59: Hey, something that might interest you...
<mjg59> jbailey: Mm?
<jbailey> mjg59: The way I'm doing the DSDT replacement, I suspect that it's happening early enough to repalce other tables if you need.
<mjg59> jbailey: Ah
<mjg59> Hmm. In principle that's useful, but there's very few cases where people have broken other tables
<jbailey> 'k, no worries.
<mjg59> jbailey: You've seen the problems some people seem to be having with booting on Colony 3?
<jbailey> If it comes up during LaptopTesting, though, I suspect it's an option.
<mjg59> Excellent
<jbailey> mjg59: Blank consoles and whatnot?
<mjg59> jbailey: Failing to mount the root filesystem and dropping to a shell
<jbailey> Hmm, generally on ubuntu-devel@ or in the channel?
<jbailey> I've been tring to follow the list and haven't seen much there.
<mjg59> The list
<jbailey> Ah, small pile of messages from this morning.
<jbailey> I'll read them
<jbailey> The lilo issue I know about and think I have a fix for.
<jbailey> Dunno about the people specifying a device and it not being there.  Probably just a missing driver.
<jbailey> Anyone here use VmWare?
<mjg59> jbailey: Oh, yes. I had an issue with a missing driver
<mjg59> It didn't pull in my IDE module
<mjg59> I suspect that the logic for grabbing device drivers is faulty
<jbailey> mjg59: The list that's included is a flat list right now.
<mjg59> jbailey: Ah!
<jbailey> I'm going to play with autogenerating it.
<mjg59> jbailey: Well, it's incomplete :)
<jbailey> Which module are you missing, though, in the meantime?
<mjg59> atiixp
<mjg59> Looks like various SATA and SCSI ones may be missing
<jbailey> Quite possibly.
<jbailey> BenC: Whenever you're back, the initramfs DSDT patch is in my homedir on concordia and is called drivers-acpi-osl_attach-dsdt-to-initrd.dpatch
<jbailey> BenC: It just replaces the current version of that patch.
<jbailey> BenC: I have tested it booting with and without it replacing the DSDT from the DSDT.aml file in the initramfs
<fabbione> ah finally good news
<zul> hmmm?
<fabbione> the patch from jb
<zul> ah
<zul> well im heading home
<zul> c ya later
<fabbione> later
<lamont> fabbione: as you may note, new util-linux for you
<lamont> rather, -6ubuntu1 is in the archvie
<fabbione> lamont: thanks...
<fabbione> i saw that..
<lamont> fabbione: I haven't had time to play wiht 7.11 on hppa
<fabbione> i will try a test build tomorrow
<lamont> thansk
<BenC> jbailey: cool, thanks
<jbailey> BenC: Do you know when you're targetting an upload of it?
<BenC> fab wants to get the current 7.11 uploaded, and then turn thngs over to me tomorrow, so I suspect soon after that
<jbailey> Cool, so I don't need to stay up all night tonight watching for people complaining of things breaking. =)
<BenC> nope :)
<BenC> got the patch
<BenC> any certain order that this has to be applied in relation to the other acpi patches?
#ubuntu-kernel 2005-08-24
<jbailey> It's replacing an existing patch already that has the same name.
<jbailey> So the load order should be already determined.
<jbailey> (And I didn't play with it outside of that environment...  I'd be hard pressed to remember how to build a kernel other than 'debuild' *g*)
<BenC> ok :)
<BenC> jbailey: is there a bug that this patch fixes?
<jbailey> If bugzilla ever comes up, I'll let you know.../
<jbailey> *sigh*
<jbailey> BenC: 13535
<jbailey> It occured to me that I could just search my email. =)
<fabbione> morning
<fabbione> BenC: did you commit the patch?
<fabbione> or do i need to?
<fabbione> argh
<fabbione> he is not online
<fabbione> jbailey: where is your patch?
<jbailey> fabbione: My homedir on concordia
<fabbione> ok
<fabbione> thanks
<jbailey> <jbailey> BenC: Whenever you're back, the initramfs DSDT patch is in my homedir on concordia and is called drivers-acpi-osl_attach-dsdt-to-initrd.dpatch
<fabbione> drivers-acpi-osl_attach-dsdt-to-initrd.dpatch ?
<fabbione> ehhe
<jbailey> Right.  Replaces the current version.
<jbailey> After 3 attempts to figure out how to call it something else, I gave up and gave it the same  name. =)
<fabbione> ahaha
<jbailey> (I think you generate your patch lists somehow, but the kernel packaging makes gcc's look simple)
<fabbione> yes we do..
<fabbione> from 00list-$version to 00list
<fabbione> because we support patching per arch and per flavour
<fabbione> so we need to generate it dynamically
<fabbione> dpatch isn't exactly working
<fabbione> what do i need to add in the changelog?
<fabbione> jb??
<fabbione> what do i need to add in the changelog? <-
<fabbione> ok nevermind.. i wrote something you lazy canadian :P
<jbailey> Eh, I  don't have a nick highlight on 'jb'
<jbailey> =)
<jbailey> *sleepy* Canadian.
<fabbione> yeah right :)
<fabbione> lazy lazy...
<fabbione> :P
<jbailey> Right.
<jbailey> If I were less lazy, I'd have gotten up and gone to bed already.
<fabbione> ahaha
<jbailey> Sleep now
<fabbione> night jeff!
<fabbione> lamont: ping?
<lamont> eep!
<fabbione> lamont: i am on f11.. do we have enough pkgs to build the kernel in the breezy chroot?
<fabbione> or do i still need to use hoary?
<lamont> I think you can use breezy
<lamont> ouch.
<fabbione> heck i can't remember my passwd on f11
<fabbione> grrr...
<lamont> need to have gcc-3.4-hppa64 (still universe) installed in the chroot.
<fabbione> lamont: can you reset it for me please?
<lamont> hppa-hacks/expect-tcl8.3-dev_5.43.0-2_hppa.deb
<lamont> hppa-hacks/expect-tcl8.3_5.43.0-2_hppa.deb
<lamont> hppa-hacks/expectk-tk8.3_5.43.0-2_hppa.deb
<lamont> hppa-hacks/gcc-3.4-hppa64_3.4.4-5ubuntu1_hppa.deb
<lamont> hppa-hacks/palo_1.9_hppa.deb
<lamont> that's all the universe-should-be-main packages that I have hacked in right now.
<fabbione> otherwise i will just use hoary...
<lamont> fabbione: sure
<fabbione> just put a temp one that i can change on the fly
<fabbione> i am already logged in
<lamont> yeah, ISTR that sshkeys are the only way to actually login...
<fabbione> yeah but i need the passwd for sudo :)
<fabbione> so i can install the B-D
<fabbione> or you can install them for me..
<fabbione> i really don't care tbh 100%
<fabbione> lamont: is the chroot reasonably updated?
<fabbione> or do i need to upgrade it first?
<lamont> hasn't been touched by me in forever
<fabbione> ok
<lamont> I'll let you fly it
<fabbione> deb http://people.ubuntu.com/~lamont/ubuntu-hppa/tree hoary main restricted universe
<fabbione> i guess this is not needed anymore..
<fabbione> lamont: that's fine :)
<lamont> and should not be present if breezy is
<lamont> (it has .debs with diff md5sums, but the same name)
<fabbione> i think you did create that chroot during the rebuild of breezy
* fabbione kills
* lamont isn't sure if breezy is actually debootstrappable yet...
<lamont> so you may have to clone the hoary chroot, nuke /var/cache/apt/archives/*, fix /etc/apt/sources.list, and dist-upgrade
<fabbione> for what i need, a dist-upgrade will do
<lamont> maybe
<fabbione> it's old enough that it's upgrading almost everything :)
<lamont> if you get any bitching about md5sums on debs being wrong, remove the afflicted .deb :-)
<fabbione> eheh yeah.. have been there before
<fabbione> chroot breezy/ apt-get build-dep linux-source-2.6.12
<fabbione> Reading package lists... Done
<fabbione> Building dependency tree... Done
<fabbione> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
<fabbione> i guess that's it :)
<fabbione> ok. sparc and hppa building
<fabbione> nice.. the latest OCFS2 will compile on sparc and hppa as well..
<fabbione> and the others too now...
<fabbione> hey Ben
<Mithrandir> fabbione: what's the hold-up with 9157?
<fabbione> Mithrandir: that the fix we did try, didn't work?
<Mithrandir> I can't remember, it's been a whlie.
<fabbione> yeah i do remember...
<fabbione> that's why.. the patch doesn't help at all...
<fabbione> but i don't know why
<fabbione> we can ask BenC when he is awake...
<Mithrandir> apparently, it should load i2o_core, but not i2o_block.
<Mithrandir> what's responsible for loading sd_mod for instance?  I think the same mechanism should be used to load i2o_block
<fabbione> hotplug in theory
<fabbione> but the point is that it loads correctly the driver for the card, but not the possible associated device manages
<fabbione> managers
<fabbione> if you load a scsi driver for card foo
<fabbione> you don't know what's connected to it
<fabbione> it could be a disk or a cdrom
<Mithrandir> yeah
<Mithrandir> ok, so hotplug should then traverse the device tree and look at what's connected and then load modules as appropriate?
<fabbione> that's why initramfs parses /sys after to identify what needs to be loaded
<fabbione> yup
<Mithrandir> hm, I guess I should see if I can test that machine sometime in the future, then
<fabbione> Mithrandir: initramfs atm doesn't check for i2o
<fabbione> but it's trivial to implement
<fabbione> that would solve your problem i think
<fabbione> check in initramfs scripts/functions
<fabbione> there is a call to scsi_init_something
<fabbione> that's a little bash function that parses /sys in seek of scsi devices and modprobe
<fabbione> the same can be done for i2o without any problem...
<fabbione> ok ladies
<fabbione> 7.11 is ready
<Mithrandir> I think I have a fix for i2o, now I just need to get access to the box scheduled..
<Mithrandir> fabbione: any idea where Xu's test kernel is?
<fabbione> Mithrandir: he did upload already.. it's building mostlikely, waiting for pitti to bless the USN
<Mithrandir> ok
<fabbione> but i don't have the changelog
<fabbione> so i don't know if he added the patch or not
<fabbione> it's mostlikely in the archive already
<fabbione> because sparc picked it up for building
<Mithrandir>   * Fixed sync_page_io bio leak in drivers/md/md.c (Neil Brown).
<Mithrandir> yup
<fabbione> cool
<fabbione> food time
<fabbione> hey BenC
<fabbione> already awake?
<Mithrandir> jbailey: does my i2o patch for initramfs look remotely sane?
<jbailey> Mithrandir: I just got here, lemme look. =)
<Mithrandir> ok
<jbailey> Mithrandir: Where did you send it?
<Mithrandir> jbailey: new bug
<Mithrandir> 13806
<jbailey> Yes, this looks right.
<jbailey> Assuming that's where things are in /sys and such.  I don't have i2o systems here.
<Mithrandir> well, it's the only thing I saw which resembled a block device.
<jbailey> Cool.  Will you have a chance to test it, or should I just apply it?
<Mithrandir> I can test it, but not for a while, that box is responsible for all the ads we're sending out here (which means it'll cost about 3000 EUR/day just in lost revenue if we take it down unplanned)
<jbailey> Yup, fair enough.
<jbailey> I'll just apply it for now then.  It can't be worse than it is now.
<Mithrandir> true
<jbailey> And I don't see anything harmful in there.
<jbailey> I won't upload just for this,  though.  I'll probably pull in the LVM fix first.
<fabbione> what time is it in BenC land?
<zul> heylo
<fabbione> hey zul
<fabbione> ok time to start uploading the kernel
<fabbione> i can't wait forever
<zul> you can do it!
<mjg59> Woo kernel
<fabbione> eheh
<fabbione> accepted
<fabbione> this time sparc will be the fastest arch to upload :)
<zul> because there are only a couple of users? ;)
<jbailey> zul: He'
<jbailey> s probably primed the ccache. =)
<zul> im evil
<jbailey> doko: Quick!  Upload gcc!
<mjg59> fabbione: That's -7.11?
<fabbione> yes
<fabbione> jbailey: no.. even better.. i did a full sbuild while waiting.. the kernel was ready for upload this morning
<jbailey> Ahahahah
<fabbione> but i was waiting Ben for the baz dance and stuff
<fabbione> so in the meanwhile i can start
<fabbione> it always takes a few hours before it's builded on all 4 arches
<TheMuso> c
* TheMuso curses speakup.
<zul> hey ben
* TheMuso doesn't remember being called ben unless zul is referring to someone else.
<fabbione> hey BenC
<fabbione> TheMuso: you are not the only one in this chan :)
<TheMuso> Just realised that. :S
<BenC> weird
<BenC> not sure why I keep getting disconnected
<BenC> fabbione: ready to do this kernel?
<fabbione> BenC: yes..
<fabbione> i did upload the kernel in the meanwhile
<fabbione> all the rest needs to be done
<fabbione> as it stands now, preX,11 branch is finished
<fabbione> so it's like you completed your devel cycle
<fabbione> i usually wait for katie to get the ACCEPT message and only after tag/prepare the new devel branch
<fabbione> so when you are ready we can start the baz dance
<BenC> let's do it
<fabbione> ok..
* BenC hears the bas line to Funky Cold Madina as he says that
<fabbione> the first thing to do is to get mainline...
<BenC> bass line
<fabbione> ahah
<fabbione> kernel-team@ubuntu.com--2005/kernel-debian--mainline--2.6.12
<fabbione> since it's the first time:
<fabbione> baz get kernel-team@ubuntu.com--2005/kernel-debian--mainline--2.6.12 debian-mainline
<fabbione> store it whenever you want..
<fabbione> it doesn't need to be in the kernel source
<BenC> ok
<fabbione> tell me when you have done that..
<BenC> it's done
<fabbione> ok
<fabbione> now we merge from the pre branch
<fabbione> baz merge kernel-team@ubuntu.com--2005/kernel-debian--preX,11--2.6.12
<fabbione> you do that inside the debian-mainline dir you just got
<fabbione> this will take some time...
<fabbione> it's a quite slow operation
<BenC> ok...
<fabbione> in the meantime i suggest you check your enviroment on people.u.c to be sure 100% that your umask is set to 002
<fabbione> for sftp operation
<BenC> before or after I do this?
<fabbione> during...
<BenC> ok, did that
<fabbione> it's important the umask is set before you commit
<BenC> and the merge is done
<fabbione> for reading it's no problem
<fabbione> ok
<fabbione> did you get any conflict?
<BenC> nope
<fabbione> ok.. now you can commit...
<fabbione> baz commit -s'2.6.12-7.11'
<fabbione> -s is the comment...
<fabbione> or commit log or whatever
<fabbione> baz doesn't spawn a nice editor to make commit logs
<fabbione> it's sort of retarded that way
<BenC> ok, that finished, but the last line was
<BenC> arch: no arch user id set
<BenC> that a warning?
<fabbione> hmmmm
<BenC> or did it fail
<fabbione> what's the output of baz my-id ?
<BenC> arch: no arch user id set
<fabbione> ok
<fabbione> baz my-id Fabio M. Di Nitto <fabbione@canonical.com>
<BenC> some env I need to set?
<fabbione> or whatever fits better to you
<fabbione> the commit did fail...
<fabbione> or it didn't go trough
<fabbione> also remmeber your gpg private key
<fabbione> you need to sign the commit
<fabbione> otherwise it fails even worst
<BenC> * committed kernel-team@ubuntu.com--2005/kernel-debian--mainline--2.6.12--patch-10
<fabbione> what's your keyid?
<BenC> "Ben Collins <ben.collins@ubuntu.com>"
<BenC> 60E80B5B
<fabbione> sorry... i mean the 0x..
<fabbione> yeah
* fabbione updates locally...
<BenC> so the "--patch-10" is something that baz adds? is that like a revision level?
<fabbione> it's like the amount of commits on that branch
<fabbione> sort of -rXXXX in svn
<BenC> right
<fabbione> it's added automatically normaly
<fabbione> but you can use it to retrive specific revisions
<fabbione> and stuff like that
<fabbione> ok.. now
<fabbione> we need to tag and prepare the next devel branch
<fabbione> do a baz abrowse
<fabbione> very useful command to see all the branches in that repo
<fabbione> now.. baz as tla sucks hard on how you can name branches..
<fabbione> specially when it goes to . - and stuff like that
<BenC> lots of them
<fabbione> yup
<BenC> ok, ready to create a branch
<fabbione> baz branch kernel-team@ubuntu.com--2005/kernel-debian--mainline--2.6.12 kernel-team@ubuntu.com--2005/kernel-debian--mainline-2,6,12-7,11-00
<fabbione> yes sorry.. connection to uk is slow from here..
<fabbione> it was still abrowsing
<fabbione> this will create the tag
<fabbione> no!
<fabbione> there is an weeoe
<fabbione> error
<BenC> ok
<fabbione> baz branch kernel-team@ubuntu.com--2005/kernel-debian--mainline--2.6.12 kernel-team@ubuntu.com--2005/kernel-debian--mainline-2,6,12-7,11--0
<fabbione> there
<fabbione> note how . - and , change
<BenC> that's the tag for the last release, right?
<fabbione> yes, that's correct
<BenC> done
<fabbione> ok
<fabbione> now let's create the branch for the new devel
<fabbione> baz branch kernel-team@ubuntu.com--2005/kernel-debian--mainline--2.6.12 kernel-team@ubuntu.com--2005/kernel-debian--preX,12--2.6.12
<BenC> done
<fabbione> perfect
<fabbione> now.. go in you kernel source debian/
<fabbione> (that i guess you manage with baz)...
<fabbione> baz switch kernel-team@ubuntu.com--2005/kernel-debian--preX,12--2.6.12
<fabbione> brb.. wife is calling...
<fabbione> re
<fabbione> tell me when you are done...
<BenC> done
<fabbione> ok  just one second that i will fix one small thing in the rules file
<fabbione> it will make your life simpler :)
<fabbione> if you notice at the end of the rules file there are some "I am lazy BOFH" targets to help you do some boring tasks
<fabbione> one of them is startnewrelease
<fabbione> (that i am fixing now)
<fabbione> that's the first command you run on a new devl branch...
<fabbione> arch_commit: unable to acquire revision lock (internal error in archive-pfs.c(pfs_lock_revision))
<fabbione> GRRRr
* fabbione bets on wrong umask
* BenC set his umask correctly
<BenC> unless .bash_profile isn't getting loaded
<fabbione> BenC did you set it at the top or the bottom?
<BenC> top
<BenC> I just changed what was already there
<fabbione> 4 drwxr-xr-x    3 bcollins warthogs 4096 Aug 19 14:14 kernel-debian--preX,12--2.6.12
<fabbione> yeah.. it didn't load..
<fabbione> let me check where i do it...
<fabbione> i do it in .bashrc
<fabbione> that's because sftp doesn't load .bash_profile
<fabbione> so i need you to do some chmod on people :)
<fabbione> cd /home/lamont/public_html/Archives/kernel-team@ubuntu.com--2005
<BenC> yeah, doing it now
<fabbione> yeah
<fabbione> we need it in all the branches/commit you do
<BenC> done
* fabbione commits
<BenC> $ find . -user bcollins | xargs chmod g+w
<BenC> should get everything
<fabbione> it did
<fabbione> ok get the change i did to rules and run that makenewrelease as user
<fabbione> no need of fakeroot
<BenC> added umask to my bashrc too
<fabbione> perfect :)
<fabbione> it should basically: create the new changelog entry, add debian/patches/00list-* stuff
<fabbione> you might want to correct the info in the changelog for the name
<fabbione> they depend on your passwd file..
<fabbione> but clearly, modify them as you wish
<fabbione> these were ok for me.. they might be useless or not enough for you
<BenC> startnewrelease?
<fabbione> yeah
<fabbione> make -f debian/rules startnewrelease
<BenC> done
<fabbione> ok.. now..
<fabbione> baz lint 
<fabbione> it will tell you if there are files in the archive that are not in rcs
<BenC> no output
<fabbione> ok
<fabbione> baz diff
<fabbione> so you can see what has been done
<BenC> changes related startnewrelease
<fabbione> perfect
<fabbione> now.. we did bump the abi
<BenC> already been using that command :)
<fabbione> so there is a manual step to do
<fabbione> ehe ok.. since i don't know how much you know about baz.. i go step by step..
<fabbione> go in debian/abi
<BenC> ok
<fabbione> baz mv 2.6.12-6.10 2.6.12-7.11
<fabbione> once you have done that, commit
<BenC> the whole tree?
<fabbione> ?
<BenC> not just the abi change, right?
<fabbione> no no.. the whole tree
<fabbione> this is to start a new release after an abi change..
<fabbione> the most complex case basically
<fabbione> so once you get this one right.. the others will be a breeze..
<fabbione> tell me when you are done with the commits...
<fabbione> so i can add the new abi files
<BenC> done
<fabbione> ok gimme a couple of minutes now...
<fabbione> in future, when we have abi changes, you will have to take care of i386/amd64/ppc/ia64..
<fabbione> that's what you are mandate to :)
<fabbione> i will take care of hppa/sparc
<fabbione> since it's non-paied porting job
<fabbione> but clearly..
<fabbione> if you take care of them too.. you will become a Kernel Hero :)
<BenC> well, I have both systems here, so I can probably squeeze them out once I settle in to the "have to do" stuff :)
<fabbione> well it's simple
<fabbione> we officially support only 3 arches
<fabbione> i386/amd64/ppc
<fabbione> so the rest is work that should come from the community
<fabbione> given that i will get pobably ia64 and hppa, and that i love sparc...
<fabbione> i took care of them as well
<fabbione> it's not high cost to run a build in parallel
<fabbione> ia64 is at the DC
<fabbione> hppa ping me or lamont
<fabbione> sparc we can both do i guess
<BenC> amd64 is the only thing I am missing locally
<fabbione> BenC: tough.. i only have i386 and sparc :)
<fabbione> you build it at the DC
<fabbione> somebody will test for you
<fabbione> and for what i suggest.. build and work as much as you can on the DC machines
<fabbione> they are fast :)
* fabbione waits for baz to do a diff....
<fabbione> ok done
<fabbione> BenC: update.. and you are good to go with the next kernel
<fabbione> now we need to look at all the surronding of an abi change...
<fabbione> BenC: ssh to chinstrap and go to fabbione@chinstrap:~/benc
<fabbione> i did prepare all the pkgs for you already signed
<fabbione> since i didn't know if you already have upload privileges
<fabbione> when changing the abi the sequence to do is:
<fabbione> kernel
<fabbione> linux-restricted-modules
<fabbione> and in no preferred order linux-meta and debian-installer
<BenC> ok
<fabbione> now.. as soon as the kernel is built on all arches
<BenC> what exactly is changed in each of those?
<fabbione> http://people.ubuntu.com/~lamont/buildLogs/l/linux-source-2.6.12/ <-
<fabbione> linux-restricted-modules is a pain package
<fabbione> you need to modify changelog/control.stub/control/rules
<fabbione> control and control.stub you need to updated the B-D
<fabbione> sed -i -e 's/2.6.12-6/2.6.12-7/g' control.stub
<fabbione> will do
<fabbione> the REAL pain is rules
<fabbione> you need to look at the beginning where there are a bunch of _MINORS=
<fabbione> you need to bump these one manually
<fabbione> there are 3 or 4 iirc
<fabbione> than you just sign and upload
<zul>  (NOTE from Fabio: this cool guy did push me something that updates
<zul>      drivers-acpi-osl_attach-dsdt-to-initrd.dpatch, but i guess he falled
<zul>      over his keyboard before giving me the data for this entry... duh!)
<zul> shouldnt that be fell?
<zul> :)
<fabbione> linux-meta needs a one char change in debian/rules i think
<fabbione> it's documented and there is only one place where the abi num is reflected
<fabbione> for d-i i usually ping Kamion
<fabbione> i don't upload d-i myself.. but he is in holidays now and he gave me the list of things to do
<fabbione> in general it's always a grep/sed for the previous ABI
<fabbione> now.. the other pain are the seeds
* BenC copies and pastes this IRC session
<fabbione> the seeds are lists of binary pkgs that are used to move pkgs from universe to main
<fabbione> BenC: yeah that's the best :)
<fabbione> BenC: we are not allowed (usually) to make arbitrary changes in there
<fabbione> that's mdz and Kamion business
<fabbione> but..
<fabbione> there are a few entries that are names Kernel-Version that are there only for us :)
<fabbione> BenC: register the archive i did paste to you
<fabbione> that's where the seeds live
<fabbione> and get this branch seeds--breezy--0
<fabbione> baz get ubuntu-devel@lists.ubuntu.com/seeds--breezy--0 seeds
<fabbione> i already updated them for -7 so if you grep for 2.6.12-7 you will see what needs to be changed where
<fabbione> so that's basically it
<BenC> cool
<fabbione> and when you do normal uploads without ABI changes.. you just upload..
<fabbione> now one important trick
<fabbione> let's make them 2/3 :)
<fabbione> when you need to change ABI, bitch always elmo/mdz in advance
<fabbione> they need to NEW all the pkgs
<fabbione> get them all ready in advance.. the kernel takes hours to build.. even on the buildd...
<fabbione> learn the way of baz cacherev :)
<BenC> what is that?
<fabbione> each time you do 5/6 commits.. run a baz cacherev
<BenC> ah, speeds things up?
<fabbione> it will create a cached revision both locally and in the archive..
<fabbione> yeps..
<fabbione> i usually do it every 5/6 commits
<fabbione> and at the beginning of each branch
<fabbione> on mainline every 2/3 releases...
<fabbione> BenC: i would like to stop for an hour or so now and take a nap
<BenC> sure
<BenC> I've got plenty to do
<fabbione> i would like you to keep an eye on the buildd's
<BenC> thanks
<fabbione> ping elmo to get the kernel newed
<BenC> where can I find progress for the buildd's?
<fabbione> and if they get in the archive before i wake up.. to upload linux-restricted-.modules from chinstrap
<fabbione> you need to use jackass to upload
<fabbione> lftp jackass
<fabbione> mput linux-restricted*
<fabbione> and that's it
<BenC> ok
<fabbione> there is no progress yet
<fabbione> you just keep an eye on the build logs
<fabbione> as soon as the 3 main arches are done, you upload l-r-m
<BenC> ok
<fabbione> there are no l-r-m for ia64/sparc/hppa..
<fabbione> so it's pointless to wait :)
<fabbione> i am off for a bit..
<zul> BenC: in the past i push various bug fixes to fabbione, do you mind registering my archive as well?
<zul> http://zulinux.homelinux.net/arch/zulcss@gmail.com--2005
<zul> thanks
<BenC> sure thing
<zul> oh its the quebecker :)
* jbailey_ sharpens the stick
<jbailey_> ... and promptly uses it to eat vegan poutine.
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | http://www.ubuntulinux.org/wiki/KernelTeam | There are no kernel bugs.. only broken hardware | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ playground: kernel-debian--preX,12--2.6.12
<zul> yummmy...vegan putone...not..
<jbailey_> Vegan gravy can be okay.
<jbailey_> Vegan cheese is generally.... not.
<BenC> jbailey: do you still have that patch?
<jbailey_> BenC: The kernel one?
<jbailey_> It's still in my homedir on concordia
<BenC> ok
<fabbione> re
<fabbione> jb, BenC: i did apply that patch already in 7.11
<fabbione> how do we look otherwise?
<fabbione> missing ppc
<fabbione> that would have been jbailey
<fabbione> NICKHIGHLIGHT
<jbailey_> fabbione: Eh?
<jbailey_> fabbione: I'm not sure what respone you're looking for. =)
<jbailey_> "Cool, thanks" =)
<fabbione> jbailey: your initramfs patch is already part of 7.11
<fabbione> you won the last entry in the changelog...
<fabbione> or almost ;)
<jbailey_> As in, I got in by the skin of my teeth? =)
<fabbione> as in "you didn't answer to me this morning for a changelong entry"
<jbailey_> Oh, whups. =)
<fabbione> but the patch made 7.11
<fabbione> oh speaking of bugs..
<fabbione> who wants to close them in bugzilla
<fabbione> ?
<fabbione> zul: i know you love that ;)
<jbailey_> "Make initramfs and dsdt not suck.  Side effect:  initrd and dsdt will suck, but mjg59 said that it's okay"
<fabbione> too late :)
<fabbione> the kernel is up already
<fabbione>   Changes by Jeff Bailey:
<fabbione>   * (NOTE from Fabio: this cool guy did push me something that updates
<fabbione>     drivers-acpi-osl_attach-dsdt-to-initrd.dpatch, but i guess he falled
<fabbione>     over his keyboard before giving me the data for this entry... duh!)
<fabbione>   (Closes: #13535)
<fabbione> you won this entry...
<jbailey_> Cool.  My next glibc upload should have The "Hey Fabio, It's fell, not falled" release. on it. =)
<zul> lol!!
<fabbione> ahha
<fabbione> yeah.. sure!
<fabbione> i like changelog "war" ;)
<mjg59> fabbione: x86 seems to have made the archive. Thanks!
<fabbione> mjg59: so does amd64
<jbailey_> Yeah, but ever since mailirat, everthing is is just small skirmishes. =)
<fabbione> only ppc/ia64/hppa are still building
<fabbione> marillat is french.. that says it all
<jbailey_> What, that he's really just a gtk bug? =)
<fabbione> worst.... ;)
<mjg59> fabbione: Excellent
<jbailey> mjg59: Does the -7 contain the acpi hacking that might fix STR that used to work?  You had said you didn't think you had time for it, so suspected no.
<mjg59> jbailey: It should do
<mjg59> But acpi-support needs to be updated as well
<mjg59> Hmm. Interesting.
<mjg59> Something's changed and breaks bootup on this Toshiba now
<mjg59> It probes ide0 and then hangs
<mjg59> Oh, no, it just takes FOREVER
<mjg59> So it's the same problem it had before. Never mind
<jbailey> Joy.  At least it's not another initramfs bug. =)
<zul> i didnt do it
<fabbione> me neither
<zul> i blame foo
<fabbione> BenC: are you back online? 
<zul> i guess not
<zul> holy lag batman
<fabbione> BenC: dude???
<BenC> damn this connection sucks
<BenC> I keep typing and no one is responding
<fabbione> yeah we noticed..
<BenC> then it finally cycles
<fabbione> specially my wife that would like to have a word or 2 with you disappearing :)
<fabbione> we were supposed to be at a concert now...
<fabbione> forced here by the ABI bump :)
<fabbione> not that i mind.. it was a danish crappy group
<fabbione> but she did :)
<zul> abba?
<fabbione> BenC: anyway.. everything went into place..
<fabbione> zul: no.. i can't recall the name.. some solo retarded singer..
<fabbione> female kind of singers...
<BenC> hehe, sorry
<zul> heh scandanavians have crappy pop bands
<zul> abba, aqua...all crap
<fabbione> zul: SafriDuo..
<fabbione> should we talk about them???
<fabbione> so i guess Benc did fall from the net again
<zul> never heard of them thankfully
<fabbione> i am pretty sure you did
<fabbione> i am ready to bet...
<zul> nope..
<zul> i wouldnt listen to crap
<fabbione> http://www.safriduo.dk/
<zul> oh darn i need flash...i dont have flash at work ;)
<fabbione> night guys
<fabbione> i am crashing
<fabbione> cya monday
<zul> c ta
<zul> i off as well c ya
<mdz> where is BenC?
<crimsun> his client timed out.
<mdz> 2.6.12-7 has broken unionfs
<mdz> I am going to need to roll back the whole thing unless someone can give me a hint where it went wrong
<BenC> fabbione: any ideas on the unionfs regression between 6.10 and 7.11?
<mdz> fabbione collapsed in a heap
<BenC> not surprising, he's been pulling some late hours
<mdz> I see nothing in the changelog or a naive diff which looks related
<mdz> but then, I have no way to even see which files changed from one rev to another
<mdz> do you guys have any better tools for that?
<mdz> the naive diff is 400k lines
<BenC> can you diff between branches?
<mdz> yes
<BenC> run it through diffstat
<mdz> but that's only going to show you which dpatches changed
<mdz> not which files in the kernel tree
<mdz> I can tell that from the changelog
<BenC> true
<mdz> the other possibility is a gcc issue, since doko just updated that
<BenC> yeah, I think gcc is at fault for atleast one other bug (k7 optimized, crash in inotify)
<mdz> 3.4.4-6ubuntu4 is the version used for the build
<mdz> that's the old one
<mdz> so it isn't that
<BenC> only thing I see related to unionfs in the changelog is
<BenC>   * Add unionfs-modules udeb:
<mdz> yes, which is a packaging change, and doesn't affect the linux-image .deb
<BenC> right
<mdz> if we're going to track 2.6.12.x, at the very least we need to release a new Ubuntu version for each upstream version
<mdz> including this high volume of changes in each upload makes regressions difficult to isolate
<BenC> yeah
<BenC> is there an updated unionfs?
<BenC> not even sure where the patches came from
<mdz> no, there isn't
<mdz> they come from ftp://ftp.fsl.cs.sunysb.edu/pub/unionfs/
<mdz> as should be documented in external-drivers
<doko> mdz: no code changes in today's gcc-3.4 upload, and the added include dirs are still empty
<BenC> ah, good file
<mdz> doko: what about in ubuntu3?
<mdz> 2.6.12-6.10 was built with _3.4.4-6ubuntu2
<mdz> 2.6.12-7.11 was built with 3.4.4-6ubuntu4
<mdz> today's upload was ubuntu5
<mdz> so definitely today's upload is unrelated
<mdz> hmm, there is no ubuntu3 in the changelog
<doko> no, ubuntu3 was something internal preparing the biarch uploads. never hit the archives
<lamont> GSI 42 (level, low) -> CPU 0 (0x0000) vector 52
<lamont> ACPI: PCI Interrupt 0000:a0:03.0[A]  -> GSI 42 (level, low) -> IRQ 52
<lamont> hrm... something tells me there should be more output after that...  :-(
<doko> mdz: do we keep the uploads somewhere? I'm currently handicaped with a defect computer in repair
<mdz> doko: what uploads?
<doko> source uploads to breezy
<mdz> morgue
<BenC> no compiler warnings from unionfs compile
<mdz> I'm testing with the latest unionfs snapshot just for kicks
<mdz> they do a snapshot after every commit
<BenC> where did the externa-fs-unionfs-fixups.dpatch come from?
<BenC> those pulled from unionfs CVS?
<mdz> no change
<mdz> BenC: yes
<mdz> in order to fix a regression
<BenC>  and it's odd that it is still needed after so many updates to the main unionfs
<mdz> unionfs is not exactly solid at present
<BenC> it was pulled in 2.6.11.91-1.1
<mdz> but they are building a pretty good regression test suite as the ygo
<mdz> they go
<BenC> pulled in
<mdz> BenC: where do we go from here to debug this?
<BenC> why haven't the tracing the kernel
<BenC> oops
<BenC> tracing the kernel
<doko> argh, I pulled the Debian cvs update in 3.4.4-6ubuntu4. there are three fixes, which touch code generation (fixing regressions). does it help you to make a build with these reverted?
<BenC> I have it reproducing in my vmware install
<BenC> hmm
<BenC> yeah, do you have the ubuntu2 packages still?
<doko> no, my computer is in repair, I don't know, if I do have them. I cannot find them on morgue.u.c
<mdz> 2005-08-12/gcc-3.4_3.4.4-6ubuntu2_i386.deb
<mdz> BenC: http://people.ubuntu.com/~mdz/gcc-3.4/
<doko> mdz: where did you get these? locate couldn't find that on morgue
<mdz> doko: see #-devel
<mdz> <elmo> I stopped morgue syncing because it would run rookery out of sapce
<BenC> mdz: I'll have this figured out by tomorrow
<BenC> I'll try the older gcc first, if that isn't it, I'll start tracing the driver
<mdz> ok, I'm going to work on getting a fallback bind-mount solution in place for ltsp
#ubuntu-kernel 2005-08-25
<lamont>   initramfs-tools: Depends: lvm2 (>= 2.01.04-5) but 2.00.32-1 is to be installed
* lamont glares at jbailey
<lamont> hrm.. my bad
<jbailey> lamont: If you can find an earlier version that's sure to work, I'll relax the dependancy. 
<lamont> nah - I just forgot that I have hoary pinned high and breezy pinned low in the real root on that machine
<jbailey> *lol*
* lamont crosses digits, praying that the ACPI code in -7.11 is love
<lamont> RAMDISK: Compressed image found at block 0
<lamont> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
<lamont> hrm... that's not love
<lamont> ACPI: Looking for DSDT in initrd... not found!
<lamont>  not found!
<lamont> wonder if that matters
<lamont> sigh.  serious kernel hacking is going to be required to figure this one out, I fear
<jbailey> lamont: Are you using mkinitrd or mkinitramfs ?
<lamont> jbailey: dpkg -i
<lamont> note also that -6.10 doesn't boot either
<jbailey> 'kay, so it's not the new dsdt patch, good. =)
<lamont> jbailey: well, -6.10 didn't boot because interrupts don't happen (damn acpi patch..)
<fabbione> mdz: there was no code change in unionfs since your fix
<fabbione> what regression do you have?
<fabbione> bah no changes have been done to VFS layer or unionfs
<fabbione> and i did tell you in /msg once that unionfs is oopsorama
<fabbione> BenC: you here?
<fabbione> i think i know what's wrong.. but that's unionfs error
<infinity> Wow, who do I have to blame for Hibernate working even worse than it did before?
<mjg59> infinity: Comparing what with what?
<infinity> Well, before it used to boot, do the whole "reading state form swap (progress bar)" thing, then hang.  I just tested with the new kernel, and it doesn't even seem to bother trying.
<infinity> It just booted normally and fscked my dirty partitions, no attempt reo resume.
<infinity> s/reo/to/
* infinity stares at his fingers.
<infinity> So, it's not like things got "worse", per se, since I couldn't suspend (either to disk or ram) before, it just seems to try less hard now. :)
* infinity decides to try suspend to ram instead, to see how bad that is.
<mjg59> infinity: Uhm. What kernel version worked?
<mjg59> Or, at least, what kernel version tried harder?
<mjg59> My suspicion would be that it's the initrd/initramfs issue that's biting you
<mjg59> s/issue/transition/
<jbailey> mjg59: How so?
<mjg59> jbailey: If there are no messages at all, then the kernel isn't being told to resume
<jbailey> infinity: Is RESUME= set in your /etc/mkinitramfs/initramfs.conf ?
* infinity 's head explodes.
<infinity> Dude, suspend to RAM now works.
<jbailey> infinity: And also please look at what $(cat /sys/power/resume) gives you
<mjg59> infinity: Rock. What hardware?
<infinity> mjg59 : Brand new SATA T43.
<mjg59> infinity: Hurrah
<infinity> jbailey : RSUME= is commented out.
<mjg59> infinity: That'll be your problem, then
<jbailey> Yup
<mjg59> infinity: (New kernel has extreme amounts of love)
<infinity> Hrm, but that's a regression, mkinitrd didn't need manual love to find the resume partition.
<mjg59> Indeed
<mjg59> infinity: Is this an upgrade or a clean install?
<jbailey> infinity: It's a long-fixed regression.
<infinity> Upgrade from older mkinitramfs versions.
<infinity> But I've not touched that conffile, so it should have been updated if it's changed.
<jbailey> It populates it at first install.
<infinity> And the initrd itself has been regenerated with 0.22
<jbailey> It can't change it after that.
<infinity> Oh, it's not a conffile?... Feh.
<jbailey> is.
<jbailey> (lagging phone)
* infinity purges and reinstalls.
<Mithrandir> jbailey: perhaps use ucf and then upgrade if you can?
<infinity> Right, can't purge, kernels want it there.
<jbailey> Mithrandir: I don't know ucf at all.
<jbailey> infinity: --force-depends
* infinity goes to manually rerun the postinst.
<jbailey> Then reinstall it.
<jbailey> Or manually rerun, that'll do too.
<mjg59> I'm sure there's something broken with acpipnp
* mjg59 digs further
<infinity> I assume I'll need to regenrate my initrd after I reinstall this? :)
<jbailey> infinity: Yes. =)
<infinity> jbailey : Hrm, now it's not commented out, but it's still an empty string.  Was the postinst supposed to put my swap partition in there?
<jbailey> Yes.
<jbailey> It works for all the cases I've tried, do you mind troubleshooting it?
<infinity> It didn't.
<infinity> Oh, that's cause I don't HAVE  aswap partition anymore, cause it still has the bloody suspend magic.
* infinity reruns mkswap and swapon, THEN tries the postinst.
<infinity> <grumble>
<infinity> That worked better.
<jbailey> Oh good. =)
<infinity> Still, that seems a bit unintuitive.  What happens if I reparition and my swap moves around?
<infinity> Isn't there a way for us to figure this stuff out on the fly in a reasonably sane fashion?
<mjg59> infinity: We can't mount the root filesystem on resume
<infinity> Not even readonly?
<mjg59> Arguably what we /could/ do would be to rewrite the grub config on the fly on suspend
<mjg59> No - it'll still replay the journal
<infinity> Ahh, hrm.
<infinity> Yes, rewriting the grub config would work too.
<Mithrandir> that's fairly evil.
<jbailey> Or have grub probe the swap partitions to detect which ones.
<jbailey> +have sigs in them.
<infinity> So is hardcoding the partition we think you resume from.
<jbailey> infinity: Wlel, we hardcode the partition you're resuming *to* as well, right? =)
<infinity> jbailey : That's the elegant solution, but suffers from the inability to have two different supended OSs at once.
<Mithrandir> jbailey: less evil, I'd say.
<jbailey> If you move shit around during a suspend, your system will break, no sympathy.
<Mithrandir> infinity: do we care about that use case?  You'll have to be careful not to have any overlapping mounts, for instance.
<infinity> jbailey : Erm, but does anything actually read the initramfs config on suspend and pick the "right" partition?... When I had nothing in there, the kernel still happily suspended to my swap partition.
<jbailey> Right, that's the default it falls back to.
<jbailey> I wish it wouldn't.
<infinity> Mithrandir : Well, I don't know how many people have multiple Linuxes installed at once, but I dual-boot between Win32 and Ubuntu using suspend-to-disk for both, cause it's much faster than full reboots.
<jbailey> I guess I could detect an image if it's not set.
<jbailey> phear
<infinity> So, for a Linux hacker with Fedora, SuSE and Ubuntu installed, I suppose it's a valid use-case to do OS-swapping using suspend-to-disk and three swap partitions.
<infinity> jbailey : Well, since the kernel plays russian roulette on suspend if that value isn't set, there's no reason you can't do the same on reboot.
<infinity> jbailey : And the multi-OS thing is probably enough of a corner case that you could just disable the autoprobing feature through a config option, for the power user.
* infinity goes to retry suspend-to-disk with his new initrd.
<jbailey> So if resume isn't set, i should check every partition on the system for an image?
<infinity> Oh well, one out of 2 ain't bad.
<infinity> With initramfs properly configured, it attemps to resume and fails.
<infinity> Reading image (progress ... done) ... ACPI: PCI interrupt for XX:XX disabled (repeat several times) ... system hangs.
<infinity> mjg59 ^
<mjg59> infinity: Ok
<mjg59> infinity: I'll be uploading a new acpi-support soon. We'll see if that helps
<infinity> jbailey : Maybe.  Or maybe just not care, I dunno.  I'm undecided, now that I know mine still doesn't work anyway. :)
<infinity> mjg59 : Mmkay.  At least suspend-to-ram works for me for the first time.  Shame about hibernate being broken.  Also odd, since I figured hinbernate kinda worked everywhere. :)
<jbailey> mjg59: Is it possible for now to just tell the kernel not to attempt to guess if the resume partition hasn't been set?
<jbailey> mjg59: All it will result in is a clobbered swap file.
<mjg59> jbailey: Not without removing that code from the kernel
<mjg59> (Which would be easy enough)
<jbailey> Right, I'm thinking the gratuitous application of #if 0 #endif to a section.\
<infinity> That's certainly the safest approach.
<infinity> Will it just refuse to suspend at all in that case?
<infinity> Cause that would be fine by me.
<mjg59> Yeah
<mjg59> Well, it can be made to
<infinity> "Can't suspend, no partition selected as suspend target."
<infinity> That's by far the safest way around this whole issue.
<jbailey> Hey STR work on my laptop with the new kernel
<jbailey> Sweet.
<jbailey> HAvn't had that since 2.6.10 =)
<infinity> Join my l33t STR club, yo.
<infinity> Though it's never worked on this laptop until today.
<infinity> Now I just need to get the Xorg ATi X300 driver to a) support PCIe, and b) STOP FUCKING CRASHING EVERY COUPLE OF HOURS, and I may like my new computer.
<mjg59> infinity: Yeah, I have the same issue on an X300
<mjg59> Daniel's supposed to be pulling CVS radeon soon
<infinity> I suspect A) and B) are closely related.
<infinity> Though, while CVS may help B), it won't help A).
<infinity> PCIe isn't going to make breezy unless someone offers some hacker big bags of cash to make it happen.
<infinity> mjg59 : If you tell me your crashing X300 is AGP, that will put my mind at ease that I may see a fix for the crashes before I see PCIe support.
<infinity> Cause the latter won't be soon.
<mjg59> infinity: It's PCIe
<infinity> Damn you.
<infinity> You could have just lied to make me feel better.
<lamont-away> Setting up udev (0.060-1ubuntu6) ...
<lamont-away> udev requires a mounted sysfs, not started.
<lamont-away> interesting...
<infinity> Interesting that you don't have a mounted sysfs, or that you do and udev's too dumb to notice? :)
<lamont-away> iz in a chroot
<lamont-away> and with a 2.6.12-1-hppa64 kernel
<lamont-away> I should really upgrade to 2.6.12-7.11
#ubuntu-kernel 2005-08-26
<Mithrandir> fabbione: seems like the kernel is happy now:
<Mithrandir> : tfheen@vawad ~ > grep -E '(bio|biovec-1)\>' /proc/slabinfo
<Mithrandir> biovec-1             371    450     16  225    1 : tunables  120   60    0 : slabdata      2      2      0
<Mithrandir> bio                  343    403    128   31    1 : tunables  120   60    0 : slabdata     13     13      0
<fabbione> Mithrandir: cool
<fabbione> i am back to lay the floor.. missing only 2 sq meter
#ubuntu-kernel 2005-08-27
<caldwell_> in both breezy linux kernel-amd64 image packages, my amd64 system won't boot because the initrd img doesn't have libc.so.6 in the correct directory
<caldwell_> is this a known issue?
<caldwell_> it happens in both 2.6.11 and 2.6.12 breezy packages
<fabbione> morning
<doko> fabbione: can the amd64 kernels handle >= 4GB machines?
<fabbione> doko: no
<fabbione> none of our kernels are compiled with > 4GB support
<doko> would it be penalty for machines with <4GB?
<fabbione> yes
<fabbione> it introduces an extra layer in the mm
<doko> and with 4GB, you can only use 3,7GB or something like that. You don't have plans for >4GB support, don't you?
<fabbione> dunno.. never used linux with more than 2GB
<Mithrandir> well, with 4GB, it's faster to use the <4GB model than the >4GB model in most cases.
<Mithrandir> since PAE is stinking shit.
<doko> ok
<zul> heylo
<fabbione> hey zul
<zul> hey fabbione good weekend?
<fabbione> zul: yeaish.. you?
<zul> yeah went to see the 40 year old virgin
<zul> pretty funny
<fabbione> what's that?
<zul> its a movie that just opened up
<fabbione> ah ok
<zul> mainly bigoraphical with some people i use to work with :)
<zul> thats a bad joke..
<fabbione> was it a joke?
* fabbione didn't realize
<zul> meh...too early 
<fabbione> zul: https://wiki.ubuntu.com/UbuntuBelowZero <-
<zul> sweet!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
<fabbione> you live in montreal, don't you?
<zul> no im about 2 hours away
<zul> happy happy joy joy
<fabbione> hey BenC_ 
<zul> its not that cold in canada in november anyways
<fabbione> zul: like if we need to care :)
<fabbione> we will be so busy that we won't get a chance to go out anyway
<zul> true
<chmj> we have one sunday off 
<fabbione> chmj: not distro
<fabbione> only LP
<fabbione> distro will be flying back on sunday
<chmj> bah! 
<chmj> heh, true 
<Mithrandir> fabbione: it doesn't say that on the plan, it just says "day off" and I at least intend to take that in .ca.
<fabbione> Mithrandir: i am sure you will have to pay for the hotel if you want to stay longer
<chmj> fabbione: quick question 
<fabbione> chmj: just ask...
<chmj> fabbione: issin't $ getconf LFS_CFLAGS suppose to return "-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64" instead of "-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64"
<fabbione> chmj: no idea
<chmj> fabbione: becouse the second one still doesn't enable LFS support, first one does 
<chmj> doko: ping ? 
<doko> chmj: pong
<chmj> doko: --------^ any idea 
<doko> ENOCLUE
<chmj> ok 
<chmj> doko: I figured `getconf LFS_CFLAGS` should return ... 
<chmj> #define _LARGEFILE64_SOURCE
<chmj> #define _FILE_OFFSET_BITS 64
<Mithrandir> fabbione: I won. :-)
<fabbione> Mithrandir: better you than me this time :)
<Mithrandir> yup
<fabbione> hey Ben
<BenC> hey
<fabbione> did you have a nice weekend?
<BenC> normally I'd say yes, but no :)
<fabbione> you need to get a better inet connection :)
<BenC> my connection seems to be fine
<BenC> my ssh sessions don't timeout
<BenC> just IRC
<fabbione> you keep pinging out
<fabbione> ah ok
<fabbione> BenC: can i reassing all the kernel bugs to you?
<BenC> yeah, let me have it
* BenC prepares his inbox
<fabbione> BenC: eheh i will do it tomorrow :)
<fabbione> there is no rush ;)
<fabbione> i remember there is a trick to do that in crapzilla...
<BenC> fabbione: is there really a mac_hid module that is needed for ppc users to use apple mice?
<BenC> I thought normal hid would work
<fabbione> BenC: i guess you are talking about James bug, aren't you?
<BenC> 13787
<fabbione> that module is available on ppc32 only
<fabbione> it's not even in the PPC64 Kconfig tree
* BenC isn't using it on his g4
<BenC> what types of apple mice need that module?
<fabbione> no clue.. i don't have a ppc at all
<fabbione> anyway 13787 is sort of duplicate of 13826
<BenC> it's not a driver at all
<BenC> it's a 2+3 mouse button emulator for apple mice
<BenC> well, not a driver in the sense that it is needed to use the mouse
<fabbione> get ready for a 270 mails of spam from crapzilla
<fabbione> should be done :)
<fabbione> hmm nobody did close the bugs from 7.11???
<ivoks> hi
<zul> spaam spam spam
<ivoks> :>
<zul> hey...you changed some of my bugs as well..
<ivoks> who?
<fabbione> zul: i did it in a batch...
<fabbione> sorry.. take them back and coordinate with BenC
<zul> ok..
<BenC> fabbione: I closed 13787, can 13826 be closed you think? I can't see how he enabled ADB in the PPC64 config anyway, since it seems it shouldn't be able to do so
<BenC> maybe he used a PPC .config or something
<fabbione> BenC: i am not sure how he managed to get there...
<fabbione> but elmo definetely has CONFIG_PPC64
<fabbione> no idea if he forced it there
<BenC> oh, that's J Troup's bug?
<BenC> should be closed by default then :)
<fabbione> ahhaha
<fabbione> PEBAK KTHXBYE
<fabbione> :P
<BenC> fabbione: weird, if I do "make menuconfig ARCH=ppc64" it let's me choose ADB and ADBHID options
<fabbione> yeah.. but the mac stuff in that dir is not for ppc64 afaik
<fabbione> it doesn't build at all
<fabbione> nothing in that dir does
<BenC> there are a couple of G5 things in there
<BenC> SMU and         tristate "Support for thermal management on PowerMac G5"
<fabbione> hmm we do build SMU
<BenC> mostly it's ADB stuff
<fabbione> it's mandatory for ppc64
<BenC> yeah, IMO it should be "default y" and depend PPC_PMAC64
<fabbione> possibly.. my ppc64 knowledge is quite limited to what benh tells me
<BenC> looks like the email flood stopped
<fabbione> yeah
<fabbione> we need to check other pkgs/status too
<fabbione> like PENDINGUPLOAD
<fabbione> i don't think the search i did got them
<fabbione> oh teh one assigned to kernel-package
<fabbione> I HATE CRAPZILLA
<fabbione> little more spam.. 10 mails.. no more
<fabbione> hey jammcq 
<jammcq> fabbione: just got the bugzilla email
<jammcq> thanks for adding FUSE to the kernel
<fabbione> oh that was done a long ago...
<jammcq> will make LOTS of ltsp folks happy
<fabbione> i noticed only now because the bug was against kernel-package
<fabbione> whilst it should have been linux :)
<fabbione> but it has been in the kernel for while
<jammcq> oh
<jammcq> cool
<fabbione> i think it was done the kernel immediatly after you asked for it in irc..
<jammcq> that's what I like... I ask for things, and they happen :)
<fabbione> jammcq: i am glad it will be helpful :)
<fabbione> jammcq: don't ask for money or sex.. i am running out myself ;)
<jammcq> damn
<BenC> jammcq: you work with ltsp?
<fabbione> jammcq: of course fuse will cost you a beer ;:P
<jammcq> ok, i'll think of something else
<jammcq> BenC: yeah, it's my project
<fabbione> BenC meet jammcq, jammcq meet BenC
<jammcq> hello benc
<fabbione> jammcq: BenC is the new kernel maintainer as of today .)
<jammcq> ah, cool
<BenC> jammcq: do you know if matt's changes to use bindfs overcame the problems with unionfs being broken in the latest kernel?
<jammcq> fabbione: where are you going?
<zul> im still a flunky
<fabbione> BenC: yes. he doesn't use unionfs anymore.. hence my proposal to kill it from the kernel
<fabbione> jammcq: back to userland...
<BenC> fabbione: gladly
<jammcq> BenC: hmm, dunno.  matt's methods are different from standard LTSP.  But, once the bugz are worked out, we'll prolly adopts the ubuntu way
<jammcq> fabbione: Ubuntu-userland?
<fabbione> jammcq: yup :)
<jammcq> cool. I look forward to see all you guys at the next ubuntu mtg.  Looks like we'll have a bunch of ltsp guys there this time
<fabbione> jammcq: https://wiki.ubuntu.com/UbuntuBelowZero <-
<desrt> woh.  score
<desrt> that's a long conf.
* BenC notices how long his buglist has become
<desrt> BenC; blame fabbio :)
<fabbione> i bleam GTK
<fabbione> blame
<desrt> you always blame GTK
<desrt> you need something new
<fabbione> i blame desrt and all the stupid lusers that buy broken hw
<desrt> i did a build-dep for the restricted modules source the other day and it installed qt.... i think you should blame qt
<desrt> *glare*
<chmj> rather blame glibc  
<desrt> mm.  glibc is a nice easy target
<jammcq> fabbione: ah, nice to see a webpage for UBZ. I guess that means its official. Montreal is easy for us to get to.
<fabbione> jammcq: it will be official soon
<fabbione> don't rely on that info 100% yet
<jammcq> k
<fabbione> iirc the announcment will be done today or tomorrow...
* chmj wonders if he should buy some warm clothing 
<zul> its not that cold in noevember
<zul> just buy some long underwear
<zul> but it is a culture shock coming from south africa to canada in winter
<zul> been there...done that
<jammcq> jbailey: hey, just the guy I need to talk to
<jbailey> jammcq: I'm lagging a bit, I'm just on the phone.
<jammcq> ok, when you get a chance, I've got some questions about the initramfs image for the ubuntu/ltsp kernels.  Like... is it using busybox?
<jbailey> It is.
<jbailey> Feel free to /msg me a series of questions and I'll get them as I have brain space in this call.
<jammcq> k
<zul> BenC: do you want to divy up the x86 bugs?
<zul> hey jeff
<BenC> zul: you can feel free to attack whatever bugs you feel you can
<BenC> it'll be awhile before I can even go through them all and see which are still valid
<zul> ok cool...
<BenC> mjg59: ping
<mjg59> BenC: Hi
<BenC> mjg59: hey, have you seen bug 13786 yet?
<BenC> I'm inclined to assign it to you and usplash
<mjg59> Yeah
<mjg59> Uh
<mjg59> It's not a usplash issue
<mjg59> The framebuffer doesn't work in the installer, either
<BenC> thing is, vga16fb is known not to work on all hardware, especially laptop/lcd situations
<BenC> well, true
<mjg59> The issue is that the installer doesn't communicate that to the installed system
<BenC> problem is that he removed splash and added vga=normal to the grub conf, and it still loaded vga16fb
<BenC> atleast that's what the reporter claims
<mjg59> Yes, that's initramfs
<mjg59> if you include modules, they get autoloaded
<mjg59> I need to check if jeff's fixed that yet
<jbailey> mjg59: Hmm?
<jbailey> It depends on how you include them.
<jbailey> Anything in modules.d gets auto loaded.
<mjg59> jbailey: Ah. I don't think I've had a chance to look at it since you provided an alternative mechanism
<jbailey> You can do things conditionally with hook scripts now at build time.
<mjg59> Ok
<jbailey> Take a look at /usr/share/initramfs-tools/hooks/
<mjg59> So yeah, there's a multitude of bugs here:
<BenC> so remove modules.d/usplash
<mjg59> 1) vga16fb is broken on some hardware and probably shouldn't be
<jbailey> The two interesting functions are "manual_add_modules" which adds the module to the initramfs but doesn't load it.
<mjg59> 2) the installer doesn't usefully tell the system that the framebuffer is broken
<jbailey> and force_load which adds the modules to the initramfs and does load it.
<mjg59> 3) usplash is including modules the wrong way
<BenC> how can the installer know that the framebuffer is broken?
<BenC> if they disable it from the command line?
<mjg59> Yes
<BenC> what's the name of the installer package?
<mjg59> debian-installer
<BenC> how does "splash" get added to grub.conf?
<jbailey> It seems to have been there for ages.
<mjg59> It's put there by default
<BenC> ok
<mjg59> Either d-i or grub, I guess
<jbailey> Yeah, it's there even in Hoary.
<BenC> ok, filed a bug for debian-installer
<BenC> even if it's a grub default, the installer should be responsible for overriding it, IMO
<BenC> mjg59: you have a bug for the module loading problem?
<BenC> in usplash
<mjg59> BenC: Not filed
<BenC> want me to file one?
<mjg59> Plesae
<BenC> filed as 13980
<zul> #7948 is more of a alsa/gnome problem me thinks
<zul> hey BenC gotta a question for you
<zul> #7948 is more of a user space problem rather than a kernel problem isnt it?
#ubuntu-kernel 2005-08-28
<caldwell_> when i boot my amd64 box with the breezy 2.6.12 kernel i get a 'can't find libc.so.6' error.  in order to fix it, i have to mount the initrd.img, cp -a the contents, mv the libs from lib64 to lib, and mkcramfs a new initrd.  Is this a known issue?
<mxpxpod> lamont: ping
<lamont> mxpxpod: si?
<mxpxpod> lamont: if you grab svn of linux-wlan-ng, they're at final
<lamont> uh, ok.
* lamont hasn't been working that angle of things much
<Mez> erm... It may just be me... but ...
<Mez> the bt878 kernel module is broke
<lamont> mdz: what's the policy on arch-specific-for-SCC packages required main packages (but only for SCC)?  (e.g. gcc-hppa64)
<lamont> er, gcc-3.4-hppa64
<lamont> palo
<lamont> libgcc2
<fabbione> morning
<mdz> lamont: parse error?
<lamont> mdz: e.g., linux-source-2.6.12 build-depends: ..., gcc-3.4-hppa64 [hppa] , ...
<lamont> should gcc-3.4-hppa be promoted to main, or does it suck to be SCC architecture?
<lamont> there are other packages which should probably be main as well.
<mdz> lamont: just looking at the string "gcc-3.4-hppa" makes me CRINGE
<lamont> it's a cross-compiler
<lamont> generates 64-bit hppa code (so that you can have a 64-bit kernel for those machines that support and/or require it.
<lamont> to date, that binary is only built on hppa (32-bit user space)
<lamont> problem is that germinate doesn't look at non-FCC architecture build-deps, or some such
<lamont> mdz: I have my preference on that, of course.. but whatever makes sense is fine.  on that note, very much bedtime
<mdz> germinate does look at ia64
<mdz> though elmo and I were discussing today and that should probably change
<mdz> but we need a better way to handle this sort of thing
<fabbione> mdz: i am updating ocfs2 to 1.1.1
<mdz> fabbione: no changes to common code, I assume?
<fabbione> the code was release 4 days ago.. but they forgot to published it on oss
<fabbione> mdz: ocfs2 is extremely contained in 2 dirs fs/configfs and fs/ocfs2
<fabbione> no common code change
<mdz> ok
<fabbione> but i need to verify the ABI again
<fabbione> that's something i will be able to see in an hour or so
<chmj> morning 
<Mithrandir> hi chmj
<fabbione> hi chmj 
<fabbione> hi Mithrandir 
<fabbione> BenC: you around?
<zul> heylo
<zul> hey jeff
<Mithrandir> we should integrate the hdaps driver, so I can use my x40 as an input device.
<fabbione> Mithrandir: what's that?
<Mithrandir> http://rlove.org/log/2005082203 and http://rlove.org/log/2005082202
<jbailey_> Why does an "x40" make me think of heavy artillery?
<Mithrandir> it _is_ approximately 210mm in one direction, which is fairly heavy arty.
<Mithrandir> I think it's essential to ensure enterprise adoption of ubuntu.
<jbailey_> accelorometer?
<Mithrandir> yup
<mjg59> Turns out it's not an accelorometer
<mjg59> And it's also trivial to do in userspace, but still
<jbailey_> Actually, the sad part is gadgets and such is probably what's needed.  We need everything given away at comdex or wherever in a given year to work better on Linux than on Windows.
<jbailey_> Then all the CEOs in the world will demand Ubuntu on their systems.
<fabbione> BenC: you awake?
<zul> hey fabbione 
<jbailey> mjg59: I'm probably doing another initramfs-tools upload later today.  Is there anything you need tweaked for your usplash stuff?
<mjg59> jbailey: Do we have support for /dv moving yet?
<jbailey> mjg59: Nope, how 'bout I do that. =)
<mjg59> Sounds good :)
<fabbione> BenC: ?????
<fabbione> never mind..
<fabbione> ttyl
<BenC> let's see if this system stays connected any better
<mdz_> BenC: what's up with your network?
<BenC> not really the network
<BenC> just IRC
<BenC> my ssh sessions aren't affected
<BenC> mdz: can you look at 4081 and tell me if it's still relevant?
<mdz_> BenC: it's fixed in current images, but the nature of the bug is such that the buggy postrm is lurking on installed systems, to bite the user when they upgrade
<BenC> were the "broken" images ever in a stable release, or are they just dev cycle images?
<mdz_> BenC: if we can verify that the warty and hoary kernels don't have the bug, we're OK
<mdz_> that's the question
<BenC> ok
<BenC> the bug says that warty is unaffected
<BenC> I'll check hoary
<BenC> my 2.6.10-5 breezy image contains the correct bits in postrm
<BenC> err, not breezy
<BenC> hoary
<mdz_> sounds like there's no need to keep it open then
<zul> BenC: i have a patch in my arch that fixes a bug
<zul> so if you want to pull it that would be great thanks..
<BenC> what's your repo url again?
<zul> http://zulinux.homelinux.net/arch/zulcss@gmail.com--2005
<BenC> how do you do a merge command?
* BenC is still new to baz
<Mithrandir> baz merge zulcss@gmail.com--2005/$component--$branch--$version
<zul> sorry was on a conference call
<BenC> thanks
<mdz_> BenC: you're on the tech board meeting agenda, and the meeting has begun
<jbailey> BenC: Around?
<BenC> yeah
#ubuntu-kernel 2006-08-21
<zul> BenC: kernel-package barfs with 2.6.18-rc4
<zul> hey
<kriebly> is a hassle to rehearse for it
#ubuntu-kernel 2006-08-22
<sn9> are there any known issues with i915/i830 drm in dapper?
<crimsun> apologies for the duplicate posts (shell's mail queue was fubar)
<sn9> finally, someone's alive...
<crimsun> I haven't experienced any odd issues with drm on this i915GM
<crimsun> (doesn't by any means imply nonexistence; YMMV)
<sn9> well, i'm trying to help someone who has the i830 chip
<sn9> i don't know whether the problem is in the kernel (drm) layer, the xorg layer, or the dri (userspace) layer
<sn9> or some combination
<crimsun> dmesg and /var/log/Xorg.0.log would offer some clues
<sn9> the basic symptom is that when dri is working (sort of), the bottom of the Google Earth window appears at the top, and the rest is blank
<sn9> dmesg and Xorg.0.log show everything normal
<sn9> so does glxinfo
<wizard> any one here ?
<high> can someone help me locate 2.6.15-20 flight kernel or the disc itself.  i cant seem to find an old ubuntu archive
#ubuntu-kernel 2006-08-23
<kriebly> does anyone know if the sctp_make_abort_user bug fixed in 2.6.17.10 is a serious root exploit? is it local or remote? it isn't documented in the cve web site, and i can't find its mention in lkml
<infinity> kriebly: It's a local root exploit.
<infinity> (Not that I have no proof of concept for the privilege escalation, only for a local DoS, but the overflow looks exploitable)
<Mithrandir> BenC: does edgy support broadcom 5708 NICs?
<BenC> Mithrandir: seems it does as the bnx2 driver
<Mithrandir> thanks.
* Starting logfile irclogs/ubuntu-kernel.log
<gnomefreak> on 2.6.17-6-386 edgy im getting an error here we go. /lib/modules/2.6.17-6-386/volatile/nvidia.ko   no such device. yet i cat that path and i get a bunch of encrypted output. is this normal?
<gnomefreak> bothers me that cat /lib/.... works but yet X cant load it
#ubuntu-kernel 2006-08-24
<macogw> Would this list be the one where I ask that wpa handling please please please be added?
<sn9> hasn't it already been?
<macogw> According to my laptop, no
<macogw> It'll only take WEP keys
<crimsun> which wifi chipset?
<macogw> I'm not sure.  Is there something I can type into the terminal to find out?
<fatal__> lspci
<sn9> assuming it's a pci card
<macogw> Intel
<macogw> that's showing up a lot....
<sn9> is it showing up for the wifi?
<sn9> is the wifi built-in, or an add-on?
<macogw> Built-in
<sn9> then it will be in lspci
<sn9> do you have a line that says Intel Pro Wireless?
<sn9> if not, it's not intel
<nigel_c> wpa_supplicant is probably what macogwis after.
<sn9> but that's installed by default
<sn9> for all we know, he might have orinoco
<macogw> I already tried following that 7-step thing
<nigel_c> Yeah.
* macogw is a girl
<sn9> sorry
<macogw> orinoco is definitely not in the list of what came up
<crimsun> macogw: grep -i wireless /var/log/dmesg
<nigel_c> What's a girl? :)
<macogw> mark of a true geek ^
<nigel_c> Or someone just being silly :)
<macogw> intel pro wireless 3945
* nigel_c decides to go quiet again and let sn9 get on with it :>
<crimsun> macogw: that definitely supports WPA{,-2}
<sn9> ah, then it is intel after all
<crimsun> and nigel_c's right on the ball; you need to configure network-manager or wpa_supplicant
<sn9> wpa worked on that in breezy, and still works (albeit differently) in dapper
<crimsun> I'm not a fan of n-m, so I tend to muck with the wpa_supplicant.conf
<macogw> well i can tell you that network tools will only take wep codes
<macogw> at least the gui
<sn9> macogw: is yours ubuntu or kubuntu?
<macogw> ubuntu
<sn9> 6.06?
<macogw> [17179598.124000]  ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection
<macogw> mack@mack-laptop:~$
<macogw> yes
<crimsun> not much n-m (gui) experience here
<macogw> ah wtf did i highlight
<nigel_c> And dapper or edgy? The edgy version has some config method changes.
<macogw> dapper
<crimsun> I can definitely say it's not kernel-related, however, and is probably better addressed in #ubuntu :)
<nigel_c> Oops. So much for staying quiet :)
<macogw> i dont have the spare box put together yet....that could have edgy on it...
<macogw> ok
<sn9> macogw: install a pkg called network-manager-gnome
<sn9> that will have gui for wpa
<sn9> in order for it to work, the wifi must be set to start on boot, and use dhcp
<sn9> and NOTHING ELSE
<nigel_c> Ah.. I give up on staying quiet... macogw, did you want to use a preshared key?
<nigel_c> I don't know what your experience is like sn9, but I found the guis were all useless for psk.
<macogw> ok well then something that maybe does have to do with kernel: http://support.dlink.com/products/view.asp?productid=DFE%2D530TX# that pci ethernet card works with fedora and red hat.  according to the posts on the ubuntu forum, it doesnt work on ubuntu, and ive heard that drivers go with kernel so...
<sn9> i used the config file myself, but the gui is what is being asked about
<sn9> macogw: are you asking about ethernet now? i thought your question was about wifi
<macogw> now ethernet, yes...since i was told "hey thats not kernel" and i do happen to be having a problem with "oh crap i cant make this computer be a linux server because that ethernet card doesnt work with ubuntu and im not paying for red hat"
<macogw> and that seems like a kernel-ish thing cuz its a driver dealy
<sn9> i don't think i've ever seen any kind of ethernet fail to work on ubuntu. fedora and red hat, yes, but not ubuntu
<macogw> http://www.ubuntuforums.org/showthread.php?t=240514&highlight=dfe
<macogw> http://www.ubuntuforums.org/showthread.php?t=232976&highlight=dfe
<macogw> two people seem to be having trouble with d-line ethernet cards
<sn9> the 530 uses the via rhine driver
<gnomefreak> what is the purpose of wacom?
<sn9> the company?
<gnomefreak> the driver
<sn9> to drive wacom hardware
<infinity> (tablets)
<infinity> ie: atrists's drawing tablets, some CAD/CAM tablets, and the touch-screens on tablet PCs and some POS systems.
<gnomefreak> would that cause a file in restricted-modules to not load
<sn9> no
<gnomefreak> :(
<sn9> are you having nvidia problems?
<gnomefreak> lol
<gnomefreak> yes
<gnomefreak> a .ko file will not load
<gnomefreak> adn i can get ouptu with cat
<gnomefreak> output even
<sn9> there are all sorts of things that can cause nvidia problems
<gnomefreak> iirc its the volatile/nvidia.ko file thats not loading. from error it says its not a device
<sn9> first of all, are you sure you need the regular nvidia modules and not the legacy ones or the free ones?
<infinity> "no such device"?
<gnomefreak> sn9: yes its a gforce4 mx4000
<infinity> gnomefreak: Which nvidia card do you have?
<gnomefreak> infinity: yep
<gnomefreak> accourding to the site its still supported with the reg drivers
<infinity> Hrm, pretty sure they haven't yet cut support for the GF4MX.
<gnomefreak> im going on the assumption that the file it says no such device is in the restricted-modules package not nvidia package
<sn9> it's just not seeing the card for some reason
<gnomefreak> everything else sees it
<gnomefreak> i get the abi warning than that error. alot of wacom errors that end in success
<sn9> can you boot into recovery mode and manually probe the module?
<sn9> oh, wait. abi warnings?
<gnomefreak> will try as soon as im done on dapper
<gnomefreak> yes
<sn9> is this an upgrade from breezy to dapper?
<gnomefreak> the box in question is edgy. but other edgy users got thier accell working
<sn9> edgy is a moving target
<gnomefreak> i know
<sn9> every now and then, things don't work for a while
<gnomefreak> is it possible that the mx 4000 is not supported anymore by the glx drivers, maybe the wiki hasnt been updated?
<sn9> i doubt that
<sn9> more likely, it's temporary edgy breakage
<gnomefreak> ok cool ty
<BenC> mjg59: ping
<BenC> gnomefreak: does Xorg.0.log show that it found the card in the PCI scan?
<gnomefreak> BenC: its showing my changes i made to vesa so i can use it
<BenC> not sure if that relates to my question :)
<mjg59> BenC: Hi
<BenC> look in Xorg.0.log for the PCI scanning and see if it even shows that it sees the device
<BenC> mjg59: Can you give me some background on that pm_{prepare,restore}_console patch?
<mjg59> BenC: VT switching is magic
<gnomefreak> ok give me a few minutes im gonna go boot it up and check
<mjg59> BenC: Ok. More usefully :)
<BenC> and usplash is anti-magic? :)
<mjg59> BenC: The kernel does the console changing in order to work around broken video drivers
<mjg59> We do it explicitly ourselves, so there's no need for it
<mjg59> That's the first argument
<mjg59> When the kernel changes vt, any app bound to the current vt gets a signal
<BenC> by console switching you mean switching to a VT out of X when we suspend?
<mjg59> It needs to respond to that signal in order for the vt switch to be allowed to go ahead
<mjg59> Yeah
<mjg59> Now that seems to interact really badly with suspend, where userspace tasks are frozen immediately after the vt switch
<mjg59> I'm guessing that the signal handling isn't complete before the processes are frozen
<mjg59> The kernel then seems to deadlock
<BenC> ok, that makes sense
<mjg59> We could probably fix this in a complicated way, or we could just strip the unnecessary calls
<BenC> so why do we vt switch, if the kernel does it itself?
<BenC> because of the same problem?
<mjg59> So that we can run vbetool before it switches back to X
<mjg59> Otherwise the kernel switches back to X, we run vbetool, X explodes
<BenC> ok, I am going to try to summarize this in the commit
<BenC> ok, so this went missing in edgy
<BenC> dapper still has the patch
<gnomefreak> ok looking through log
<gnomefreak> (**) |   |-->Device "NVIDIA Corporation NV18 [GeForce4 MX 4000 AGP 8x] "
<gnomefreak> im getting that only its a pci not agp :(
<BenC> gnomefreak: Look for the line that starts:
<BenC> (II) PCI: PCI scan (all values are in hex)
<BenC> check in that list to see if it finds the PCI device
<gnomefreak> k
<gnomefreak> (II) PCI: 00:0f:0: chip 10de,0185 card 0000,0000 rev c1 class 03,00,00 hdr 00   the 00:0f:0 is the hex for the card
<gnomefreak> assumming 00:0f:0 is still 00:15:0
<gnomefreak> BenC: it also lists the card under PCI-to-ISA bridge:
<BenC> gnomefreak: ok, then it sees the card, so that alleviates the issue I was looking at
<BenC> gnomefreak: grep EE /var/log/Xorg.0.log
<gnomefreak> BenC: sorry i froze what was the grep command again?
<lloydinho> <BenC> gnomefreak: grep EE /var/log/Xorg.0.log
<gnomefreak> i got it
<gnomefreak> it doesnt look good :(
<gnomefreak> BenC: http://pastebin.com/774708
<zul_> BenC: the kernel-package from sid behaves the same way
<BenC> gnomefreak: dmesg | grep -i nvidia
<gnomefreak> k
<BenC> gnomefreak: actually, what kernel do you have installed?
<BenC> -386, -686, ...?
<gnomefreak> 2.6.17-6-386
<gnomefreak> and i dont like the output of that command :(
<gnomefreak> http://pastebin.com/774736
<BenC> gnomefreak: I'd take this up with nvidia then
<gnomefreak> is it the card or the drivers in your best guess?
<BenC> hard to tell
<infinity> Or the BIOS, or an ACPI bug..
<BenC> yeah, I'm thinking BIOS
<infinity> If it really is telling the truth, and can't route an IRQ to the card.
<BenC> well, there's no error from PCI about not being able to enable the IRQ
<BenC> it's mainly that it doesn't see it has one
<BenC> I'd check the BIOS settings and make sure the controller has an IRQ for it
<infinity> BenC: How do you know?  There's no full dmesg there. :)
<BenC> infinity: oh, good point :)
<BenC> gnomefreak: put all of dmesg in there please
<gnomefreak> that was all of it
<BenC> no, it isn't
<infinity> gnomefreak: Without the grep.
<gnomefreak> oh
<BenC> dmesg > dmesg.txt
<BenC> lspci -vv >> lspci.txt
<BenC> get both of those
<gnomefreak> http://pastebin.com/774739
<gnomefreak> :(
<gnomefreak> heres lspci -vv http://pastebin.com/774741
<mjg59> [   61.124183]  PCI: No IRQ known for interrupt pin A of device 0000:00:0f.0. Please try using pci=biosirq.
<gnomefreak> other command doesnt output anything and #nvidia just said i need legacy drivers :(
<BenC> yeah, that's BIOS/ACPI
<infinity> gnomefreak: #nvidia lied.
<gnomefreak> k
<gnomefreak> good
<gnomefreak> i have acpi turned off
<mjg59> gnomefreak: Why?
<BenC> gnomefreak: Try booting with "pci=biosirq"
<gnomefreak> i dont remember
<BenC> that's probably the cause there
<mjg59> Oh, because it's a 1999 bios
<mjg59> gnomefreak: Try booting with acpi=force before pci=biosirq
<gnomefreak> add it to /boot/grub/menu.lst?
<mjg59> es
<BenC> gnomefreak: Or add it to the grub menu by hand, either way
<gnomefreak> after the word splash i take it?
<BenC> yeah
<gnomefreak> ok brb
<infinity> gnomefreak: In the "# kopt" section, ideally.
<infinity> gnomefreak: So it gets applied to all boot options when update-grub is run.
<gnomefreak> ok i played in bios changed irq to auto dmesg nvidia shows this line PCI: Using ACPI for IRQ routing   is that good?
<gnomefreak> and anyway to test this before changing xorg?
<gnomefreak> thats with the line i put in grub menu
<mjg59> gnomefreak: Does it complain about a missing IRQ?
<gnomefreak> no it just says if the device doesnt work use lapic
<gnomefreak> i think i like this :)  Boot video device is 0000:00:0f.0
<gnomefreak> thats teh hex for the pci slot
<gnomefreak> that its on
<gnomefreak> brb gonna try this
<gnomefreak> it works ty guys now i just have an issue i have to work on text isnt being displayed
<BenC> that's a known nvidia driver bug
<gnomefreak> ok cool
<BenC> started occuring in edgy, some kind of xorg/drm interaction
<BenC> there's a work around I think, look around for it
<gnomefreak> ill try to
<BenC> yay for shitty internet access
<kylem> that bad, eh?
<fabbione> yeah
<kylem> eep.
<kylem> heh. :/
<zul> dentists are so much fun1
<zul> ! even
<sander_m> Hello. I have a problem with a kernel transplantation. Could someone here help me, or should I go ask on another channel?
<sn9> doctor, it's alive!
<sander_m> eh?
<sn9> kernel transplant
<sander_m> hehe :-)
<sander_m> I am running Ubuntu i386 on an AMD64. Now I want to replace the kernel (only!) with an amd64-k8 kernel. I got linux-image-amd64-k8 installed, but trying to install linux-restricted-modules-amd64 throws up errors like : ath_hal/ah_osdep.o: file not recognized: File format not recognized
<sn9> you can't do it that way
<sander_m> Rationale: I want to be able to create an amd64 pbuiler enviroment on mu i386 Ubuntu installation
<sn9> if you have a 64-bit kernel, you need 64-bit libs
<sander_m> I am running the kernel now :-)
<sander_m> It's the modules that give me headaches at the moment.
<sn9> doesn't this kind of thing just scream "xen" to you?
<sander_m> Probabely, but that would mean a full re-install right? A bit of overkill just to be able to build gnome-hearts for amd64 dapper
<sn9> no, the beauty is that you would not need to reinstall a thing, AIUI
<mjg59> sander_m: Do you need the restricted modules?
<mjg59> They're amd64 objects and they're run through ld, so you'd need a bi-arch binutils
<mjg59> Which is probably going to be more pain than you want
<sander_m> mjg59 they're not 100% nessecary. I'm running the full system now without them, but I'd like XGL back so I'd need the nviaia kernel modules
<mjg59> sander_m: Well, you'll somehow need to deal with binutils in that case, I'm afraid
<sander_m> s/nviaia/nvidia
<sander_m> and what about regular cross compiling? I can only find info for building i386 beds on amd64 systems, not the other way around
<sander_m> s/beds/debs
<mjg59> We don't ship the necessary stuff to do that
<sander_m> Hmmm... maybe it would be the easiest to simply install a minimal dapper on a spare partition and pbuild my amd64 debs in there
#ubuntu-kernel 2006-08-25
<sander_m> Thanks for your help guys. I have to reboot now
<alex_> hello
<alex_> kernel is web cam
<alex_> anubis tipphon(lidl silvercrest)
<BenC> zul_: ping?
<zul_> BenC: pong
<BenC> zul_: when a bug is fixed in edgy, and filed against dapper, just add a new dist target for linux-source-2.6.17, and mark that closed, rather than closing the 2.6.15 target
<zul_> ok
<BenC> thanks
<zul_> sorry about that
<BenC> no biggy
<Keybuk> ~.
<Keybuk> err
<BenC> just makes it easier to track
<zul_> way too early in the morning
<fritsch> hi, i try to load it821x during boot up, because my root filesystem etc. everything is attached on disks to this controller
<fritsch> added it in /etc/mkinitrd/modules and recreated the initrd, but does not come up and in the grub shell module is not added
<fritsch> anyone?
<gnomefreak> the new nvidia drivers are out as of yesterday but before edgy can use them it look like the kernel modules have to be changed
<fabbione> changed?
<fabbione> what do you mean?
<zul> oh hey fabbione 
<fabbione> hey zul
<gnomefreak> fabbione: i wish i knew but the kernel modules are mismatch thats all it gives me
<fabbione> gnomefreak: ok. you didn't install them properly
<fabbione> that's all
<gnomefreak> the .sh installer tries to correct them and says it does it but with stock modules or the ones the .sh gives you dont work
<fabbione> nvidia requires update of both kernel modules and userland
<gnomefreak> fabbione: i installed them as normal (without sudo nvidia-glx-config enable) since it doesnt have that file
<fabbione> you need to de-install our packages if you want to use their .sh
<fabbione> and you are messing up stuff this way
<gnomefreak> de install the nvidia-glx package 
<fabbione> because their .sh doesn't know that X11R6 doesn't exists anymore
<gnomefreak> did that before downloading from nvidia
<fabbione> also linux-restricted modules
<gnomefreak> oh ok
<gnomefreak> i will try it see what happens ty
<zul> later
#ubuntu-kernel 2006-08-26
<zul> mjg59: you got a lot of responses in your blog :)
<mjg59> zul: Yeah, I noticed
<mjg59> Surprisingly positive :)
<zul> heh
<zul> osnews is so much fun
#ubuntu-kernel 2007-08-20
* Starting logfile irclogs/ubuntu-kernel.log
<kraut> moin
<hxu> In include/linux/mqueue.h, the space limit of per-uid mqueue is set 819200 bytes, but you always get -1(which means infinity) for both soft and hard limit of mqueue by getrlimit(2) in ubuntu 2.6.20-16.29, any idea?
<hxu> In include/linux/mqueue.h, the space limit of per-uid mqueue is set 819200 bytes, but you always get -1(which means infinity) for both soft and hard limit of mqueue by getrlimit(2) in ubuntu 2.6.20-16.29, any idea?
<infinity> hxu: Good thing you asked that twice in 20 minutes, otherwise someone might not have noticed.
<hxu> In include/linux/mqueue.h, the space limit of per-uid mqueue is set 819200 bytes, but you always get -1(which means infinity) for both soft and hard limit of mqueue by getrlimit(2) in ubuntu 2.6.20-16.29, any idea?
<TheMuso> i/c
<TheMuso> argh
* lamont` ponders the best way to not build ov511 in lum on hppa
* lamont` tries the other option first
<dieguito> hello happy hackers, just dropping to ask -at the risk of annoying you- if there's a simple way to disable libata via the kernel parameters given at boot time
<Mithrandir> dieguito: you can blacklist drivers, but I don't think you can disable libata as such, no.
<dieguito> hmmm
<dieguito> which ones should i blacklist in that case?
<infinity> What's the end goal here?
<dieguito> my stone age pc boots in no less than 5 minutes with newer kernels using libata
<dieguito> (yes, it can boot faster than 5 minutes on non-libata kernels)
<Mithrandir> why not rather find out what the problem is and fix that?
<dieguito> Mithrandir: if you want me to debug it just tell me how and i'll try
<Mithrandir> it works using older libata kernels?
<Mithrandir> if so, that sounds like a use case for git bisect.
<dieguito> nope, it works using good old /dev/hd* kernels
<dieguito> now that everything is /dev/sd* it takes ages to boot
<Mithrandir> paste a dmesg from a slow boot somewhere, then?
<dieguito> let me turn on that machine...
<dieguito> from a google search the other day I have this line: exception emask 0x0 sact 0x0 serr 0x0 action 0x2 frozen emask 0x4 time out
<dieguito> i'll give you the full log in a second
<dieguito> well in 5*60 seconds
<dieguito> oh great now it doesn't boot
<dieguito> i can't boot it
<dieguito> :/, sorry but closest thing is that line above
<dieguito> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/106512/comments/3 is a close match to my usual output
<BenC> kylem: are you working on an nvidia refresh for next tribe? If no, I'll get it ready for upload later this week with your kernel upload
<kylem> BenC, nope, i haven't done anything about nvidia yet.
<kylem> (what's the problem, is there new hw support?)
<BenC> yeah, we need the 100 series for -new, and there's new versions of legacy and legacy-new as well
<kylem> ok, cool.
<BenC> I've got tons of nvidia hw, so I can test it pretty well
<infinity> We've always had a pretty open "if it seems to work on a few cards, ship it" attitude to LRM updates all the way up to rc/beta anyway, since there's nothing we can really do about upstream breaking it.
<infinity> As long as it kinda works somewhere, we win.  Ish.
<Riddell> BenC: later this week?  freeze is tomorrow morning
<BenC> Riddell: well I can upload it tomorrow, but then it will get uploaded/built again at the end of the week for the kernel ABI bump
<BenC> Oh, wait, tribe freeze is tomorrow?
<BenC> hmm
<BenC> kylem: did we get a kernel upload in?
<Riddell> yes, if you want new linux stuff in you need to upload before I wake up tomorrow
<BenC> I've been on vacation, got a little time skew
<BenC> Riddell: very little chance of us getting an upload done today because of the NEW processing and dep-wait for lrm/lum and such
<kylem> BenC, no, i have all the src packages built but i'm waiting for a fix for unionfs. if i don't get one by the end of my work day, i upload a second set which have the apparmor things reverted for now.
<kylem> not having the apparmor fix blocks mathiaz, so it's kind of important as well, but if it has to be reverted, we're kind of caught by the short & curlies.
<BenC> kylem: ok...for future ref, I promised Mith and others we'd get kernels uploaded Fri before freeze to avoid cutting things so close
<kylem> BenC, ok. yeah, sorry, this was kind of an exceptional case as i'd not noticed lum ftbfs due to stupidity on my pat.
<kylem> part
<BenC> so you might want to clue #ubuntu-release in on the this
<BenC> np
* kylem nods.
<kylem> i wonder which tab that is.
<kylem> if someone tells me what knob to press, i probably have magic build pinning abilities.
<infinity> You don't.
<kylem> loss.
<kylem> i should.
<kylem> ;-)
<infinity> Shouldn't matter anyway, unless the queue is backed up.
<infinity> Making the only build in the queue a higher priority still makes it... The only build in the queue. :P
<kylem> lpia is backlogged, no?
<Mithrandir> slightly
<infinity> Who cares?
<infinity> lpia isn't releasing tribes.
<kylem> true.
<infinity> The only arches you need to see build your kernel are i386/amd64/powerpc.
<Mithrandir> it's only about 7700 builds behind, it'll catch up quickly enough
<Mithrandir> actually, I want kernels on lpia quickly too
<infinity> Down to 7700 from close to 9000.
<Mithrandir> so please tell me ifwhen you have stuff to be bumped
<infinity> It's doing well.
<kylem> infinity, we release powerpc tribes?
<infinity> Anyhow, lpia builds the kernel quickly (fast machines, only one flavour), so if it doesn't get built ASAP, it's not the end of the world.
<infinity> Compared to i386, which takes a week.
<infinity> kylem: I'm not sure about "release" anymore, but we still build 'em.
<BenC> I wonder if I can get nvidia done today
<BenC> we're already past UVF, and I don't want to put it off any longer
<BenC> kylem: we are on an ABI bump, right?
<kylem> BenC, yup.
<kylem> sorry, was on a call.
<BenC> kylem: ok, I'll work on getting that done
<kylem> do you want the .orig.tar.gz with the abibump done?
<kylem> then you can just blat the new nvidia stuff and not worry about it
<BenC> I've got to make a new .orig.tar.gz for lrm
<BenC> kylem: do you have changed to lrm other than the abi bump?
<BenC> *changes
<kylem> nope
<BenC> ok, I'll just apt-get source and go from there
<infinity> BenC: Does LRM still have my 3 levels of autogenerated control files?
<infinity> (For which I profusely apologise but, hey, it worked)
<BenC> infinity: yeah, but then, so does most everything else related to the kernel :)
<kylem> Changes: 
<kylem>  linux-restricted-modules-2.6.22 (2.6.22.2-10.9) gutsy; urgency=low
<kylem>  .
<kylem>    * ABI bump to -10.
<kylem> yeah, that's it
<BenC> rtg_: last time I updated rt2x00 I used the wireless-dev version for lum, but had to munge things because of api changes in current wireless-dev
<BenC> rtg_: if the API has changed too much, then just stick with 2.0.4 that we have now
<rtg_> BenC: right. 
<rtg_> BenC: The only prism54 I see in wireless-dev is drivers/net/wireless/prism54. Is there some other name?
<BenC> kylem: I have lrm with all the nvidia updates, passed built and basic boot test...I'm going to drop it on kernel.ubuntu.com, so you can just upload it from there when you're ready if you want, or ping me and I can
<BenC> rtg_: check for p54
<kylem> sure.
<mjg59> prism54 is hardmac, p54 is softmac
<mjg59> s/hardmac/fullmac/
<mjg59> Any modern p54 hardware is softmac
<rtg_> mjg59: I just spotted it.
<BenC> unfortunately, p54 and prism54 both claim the same PCI ids :/
<mjg59> Thanks, Intersil
<mjg59> The fullmac cards can be run with the softmac firmware and driver
<BenC> ah, good, so just get p54
<rtg_> mjg59: There has been a lot of churn in wireless-dev of late. Will the Gutsy version of softmac be sufficient for p54?
<mjg59> But prism54 works, whereas I have no idea if p54 does
<mjg59> rtg_: When I say softmac, I mean the card doesn't have a hardware mac. I've no idea if the driver uses softmac or mac80211
<BenC> rtg_: do you have any prism54 hw?
<rtg_> BenC: not that I know of.
<BenC> rtg_: you may have to munge things in p54 a bit to compile against 2.6.22, like I did for rt2x00
<BenC> mjg59: do you have any p54 hw?
<rtg_> BenC: so, do you want both prism54 and p54?
<mjg59> Nope
<BenC> rtg_: For tribe-5, let's just enable prism54 in linux-source...after that, disable prism54 and get p54 into lum for testing
<BenC> probably easiest to get the people in the bug report to test p54 for you
<rtg_> BenC: will do.
<rtg_> BenC: We might want to let rt2x00 settle for a bit. Ivo submitted 30 patches yesterday.
<BenC> rtg_: ok
<maks> 78
<maks> -ETERMINAL #soory
* lamont` fights with lum/hppa
<kylem> hmm, it just occured to me, if i bounce apparmor back to the old version for tribe5, we'll have another abi event when we readd it.
* lamont` ponders _why_ squashfs/inode.c winds up dying with TASK_UNINTERRUPTIBLE undefined on hppa64 (only), and why #include <linux/sched.h> is needed there to fix it.
<kylem> lamont`, headers in general are a mess.
<lamont`> will you forgive a stray #include <linux/sched.h> in squashfs/inode.c?
<kylem> i have no idea which include is guarded by __lp64__ or something, i'm kind of confused.
<lamont`> i'll even testbuild on i386
<BenC> kylem: best to ask pkl, it's his code :)
<BenC> lamont: ^^
<kylem> BenC, it's not a squashfs problem persey.
<kylem> granted, explictly including sched.h is probably best
<kylem> i'm curious why it only breaks on 64-bit.
<BenC> doesn't sound like 64-bit, since x86_64, sparc64 and powerpc64 seem to build fine
<kylem> BenC, it's a problem in one of the <asm-*> on parisc, hence my interest
<kylem> being them maintainer and all
<lamont`> hppa64 is CONFIG_SMP=n for now
<kylem> oh.
<lamont`> dunno if that's a factor
<kylem> that might do it.
<BenC> kylem: ah, you meant only breaks on 64-bit hppa, as opposed to 32-bit hppa
<BenC> misunderstood
<kylem> ah, i bet i see how.
<lamont`> kylem: if you have a pointer, I've no objection to testing it
<kylem> lamont`, are you building SMP=n hppa32?
<BenC> kylem: zinc:~bcollins/ has lrm ready
<kylem> BenC, groovy, thanks.
<lamont`> kylem: no.
<BenC> back to my inbox
<kylem> ok.
<lamont`> basically, hppa32 is happy and has what I believe to be final-.config
<kylem> <asm-parisc/smp.h> -> <linux/cpumask.h> -> <linux/kernel.h> -> $lots
<lamont`> hppa64 was failing to boot, so I went for a "give me somethign that boots, thanks"
<lamont`> something was trashing life with SMP
<lamont`> and I grew tired of looking
<lamont`> there's another hppa64-pseudo-ABI event coming
<kylem> lamont`, if squashfs is using something from that header, the safest thing to do is include it.
<kylem> and not rely on it being included acciently.
<lamont`> squashfs calls wait_event, which expands to use TASK_UNINTERRUPTIBLE
<lamont`> but wait_event is defined outside of squashfs, so I think it's still a kernel-header issue, no?
<lamont`> wait.h, to be specific
<lamont`> so I kinda think wait.h should be including sched.h.  Thoughts?
<kylem> yes, probably.
<Nafallo> hmm
<kylem> unless there's some kind of perverse recursion and instead is relying on include ordering.
<Nafallo> is there still daily test kernels? ;-)
<kylem> which, given it's linux, is entirely likely.
<lamont`> kylem: it shows up as undef, so it never got included....
<lamont`> so the question is, do I want to do a lum patch for that, or a kernel patch?
<kylem> Nafallo, i was working on something a few weeks ago that was as much of ubuntu patches + daily git, but never got around to wiring up automation.
<Nafallo> kylem: and http://people.ubuntu.com/~bcollins/kernels-daily/ is empty, so I guess no ;-)
* Nafallo wants working tickless :-P
<kylem> oh right.
<kylem> i don't think you can have tickless, but at least you won't hang on bootup.
<Nafallo> :-/
<Nafallo> I already don't. got some commandline stuff from BenC before :-P
<kylem> yeah.
<BenC> Nafallo: does "nolapic_timer nohz=off" work for you?
<lamont`> kylem: on the subject of dead horses...  do you want me to commit this as a squashfs/inode.c change, or a linux/wait.h change?
<Nafallo> BenC: yes
<BenC> that'll give you the same thing as the patched kernel
<kylem> lamont`, the former for now.
<lamont`> ok.
<kylem> wait.
<kylem> er, sec.
<Nafallo> BenC: at least until the problem is fixed so I can have tickless ;-)
<kylem> kind of hard to fix broken hardware.
<lamont`> I have a kernel commit and a lum commit so far (config, and debian/control*, respectively)
<kylem> possibly a bios update might help you.
<Nafallo> oh. so I will /never/ have tickless then?
<Nafallo> hmm. oki-
<Nafallo> worth trying I guess.
<kylem> iirc what i saw from amd was that it was an smm problem.
<kylem> that could be fixed by a bios update.
<Nafallo> I just wish it was as easy as putting the firmware on USB :-P
<kylem> lamont`, so the problem is TASK_foo being undefined?
<lamont`> correct
<kylem> and that's the only problem?
<lamont`> seems to be
<kylem> hrm.
<lamont`> inode.c failed with lots of TASK_UNINTERRUPTIBLE undefined errors.  including sched.h in inode.c eliminates all the compile errors
<kylem> well, it's a kernel problem. i'll try to track down where i can fix it in <asm-parisc>
<lamont`> the other issue (orthogonal) is that the control file still says gcc-3.4 
<lamont`> ok.  fact remains that linux/wait.h assumes that it'll be included, rather than explicitly including it....
<lamont`> kylem: and then if you grab my committed tweaks from lamont/hppa-ia64{,-lum}.git, we'll get a kernel and lum.
<lamont`> want email?
<kylem> include/linux/smp_lock.h:#include <linux/sched.h>
<kylem> heh, that might have done it.
<kylem> sure.
<lamont`> heh
* lamont` composes
<lamont`> kylem: sent
<lamont`> and pushing git repos. :-)
<kylem> does gcc-4.1 build ocfs2/gfs now?
<lamont`> we made it through the build completely.....
<kylem> already saw it.
<kylem> ;-)
<kylem> so why doesn't it boot?
<lamont`> last I left it, it would hang in the midst of releasing processors.
<lamont`> for my next round of fun, I plan to start with defconfig+SMP, and keep adding stuff back in until it breaks.
<zul> i just love it when /proc/mounts and the output of mount says 2 different things
<lamont`> zul: but that
<lamont`> s always the case, since mount drops stuff
<zul> if its reporting 8k and 32k?
<xhaker> Hey, I'm having some problems with an ich4-m ide controller
<xhaker> I'm running with udma2 for some time now
<xhaker> since the change to ata_piix
<xhaker> It claims my cable is 40pin only
<xhaker> blacklisting ata_piix and running with ide_generic i can have udma5
<xhaker> so what do you say? any boot options to help me get this sorted?
<BenC> xhaker: try booting with "all_generic_ide"
<xhaker> BenC, that would bring it to use ide_generic?
<mjg59> xhaker: lspci -vn
<xhaker> mjg59, http://pastebin.com/meb1bb40
<mjg59> With ide_generic? That sounds unlikely
<mjg59> Are you sure you don't mean generic?
<xhaker> thanks for looking into this, i've been ignoring the problem, until yesterday when i was building a new package for eclipse, and the disk poor performance was noticeable
<xhaker> mjg59, I'm running with ata_piix/udma5 now
<mjg59> xhaker: Erm. I thought you just said you weren't?
<xhaker> mjg59, ata_piix/udma2
<xhaker> ide_generic/udma5
<mjg59> xhaker: ide-generic has no DMA support. Are you really sure you don't mean generic?
<xhaker> hmm, that's why the performance is better with ata_piix
<mjg59> xhaker: I'm sorry, you're not making a lot of sense here.
<xhaker> mjg59, I'll try to summarize. I know this laptop can do udma5. By default the kernel loads ata_piix and claims my cables are 40pin so udma2.
<mjg59> Yes, that bit is fairly clear
<xhaker> mjg59, /dev/sda:
<xhaker>  Timing cached reads:   876 MB in  2.00 seconds = 437.46 MB/sec
<xhaker>  Timing buffered disk reads:   24 MB in  3.11 seconds =   7.71 MB/sec
<xhaker> is what i get now
<xhaker> moving on.. in my quest to enable udma6, i've tried every boot option i could find.. ide0=ata66 idebus=66
<mjg59> Try http://www.codon.org.uk/~mjg59/tmp/xhaker.diff
<mjg59> There's no way ide-generic can give you any DMA, so I don't understand the bit where you say it gives you udma5
<xhaker> mjg59, explaining the rest.. I've then proceeded to backlist ata_piix, rootdelay=3
<xhaker> mjg59, when the shell came up type in modprobe ide_generic
<mjg59> Yes, that'll give you pio
<xhaker> hdparm claimed udma5, even though the performance was tested lower.. 3 MB/sec
<mjg59> hdparm was lying for some reason
<mjg59> Can you try that patch, and if it works send it to Ben?
<mkrufky> hey, guys... is it safe to assume that if I get a patch into 2.6.22.y, that it will make its way into the Gutsy kernel, or do I have to file a bug report and ask for it?
<mjg59> mkrufky: It should do
<xhaker> mjg59, will try :)
<mkrufky> mjg59: ok, cool.. .thanks
<mkrufky> i searched launchpad and nobody filed yet ... probably just luck :-)
<kylem> mkrufky, i think in general we will be pulling 2.6.22.y until freeze, barring any special cases
<mkrufky> ok.. thanks kylem ...  i'll be sending this regression-fix to -stable tonight, when i get home... (cant send inline from here)
<mkrufky> its a regression causing certain DVB hardware to not be able to tune... easily fixed
<kylem> ok, cool
<kylem> bugfixes definitelyw elcome.
<mkrufky> kylem: here's a random question ...  it's almost impossible to google this one, but i tried and landed on your name.....  im under the impression that __u64 is for userspace and u64 is for internal kernelspace ...  what is the difference, really?
<mkrufky> (landed on your name cuz it found you ack a patch of somebody doing a conversion from u64 to __u64)
<kylem> there's no fundamental difference
<kylem> __x is used instead of x for namespace reasons.
<kylem> (only, eg: __u32 is exported, not the u32 typedef)
<mkrufky> ah, ok ...  so, if something comes in from userspace as __u32 is can be assigned to a u32 var in kernelspace, no problem ?
<kylem> indeed.
<mkrufky> i ask, because v4l2_std_id is typedef'd as __u64 , and I'm doing a large refactoring on the v4l / dvb internal tuner api 
<mkrufky> ok, well that makes this easy .. .thanks
<kylem> np.
<mkrufky> ok, goin home... ttyl
#ubuntu-kernel 2007-08-21
<hxu> Hi! In include/linux/mqueue.h, per-uid limit of kernel memory used by mqueue is set to 819200, but why do I always get -1(infinity) by getrlimit(2)  for both soft and hard limit of mqueue?
* Starting logfile irclogs/ubuntu-kernel.log
(kraut/#ubuntu-kernel) moin
<dholbach> can somebody look at bug 82343? I'm not sure who to assign it to or if it makes sense at all
<IntuitiveNipple> dholbach: I guess it's mostly hal since it is hal scripts that are run by gnome-mount to run cryptsetup, but after that it is gnome-volume-manager (which starts gnome-mount)
<dholbach> also bug 57755
<IntuitiveNipple> I'm not sure on that one, but it *looks* like udev from those patches
<dholbach> I don't have a clue about either of them, so it'd be nice if somebody of the kernel team reviewed and sponsored them
<IntuitiveNipple> I did some hacking with hal and gnome-mount for cryptsetup over the weekend, so I'm sure about that one
<dholbach> if you comment on the bug it will make it easier for somebody who sponsors the patch to review it
<dholbach> I'm happier if I don't touch those parts :-)
<IntuitiveNipple> which one, 82343 ?
<dholbach> both :)
<IntuitiveNipple> *sniggers
<dholbach> can somebody also check out bug 129828?
<lamont> head->wall
* lamont prepares a diff to go into .27
<lamont> waiting for builds is such a pain
<Riddell> anyone want to fix linux-source-2.6.22-10.26?
<Riddell> "make: *** [/build/buildd/linux-source-2.6.22-2.6.22/debian/stamps/stamp-custom-prepare-xen]  Error 2"
* lamont notes that running updateconfigs migrated some stuff to i386/config from the individual ones
<lamont> Riddell: i386, I expect?
<Riddell> lamont: yes
<lamont> ah, it wasn't just hppa then
<laga> hello. dev/rtc/max-user-freq is currently set to the default value of 64 which is rather low for multimedia applications. would it be possible for you kernel guys to increase the default value to 1024 as recommended by mplayer/mythtv documentation or would i have negative side effects?
<xhaker> mjg59, thanks for the patch, i have udma5 now :)
<xhaker> BenC, could you please apply http://www.leetcorp.net/xhaker.diff
<abogani> laga: Why someone want use RTC when kernel offer High Resolution Timers at no cost? :-|
<laga> abogani: um, might be a legacy item. i still wonder if there are negative side effects.. if not, we can just enable it ourselves in mythbuntu
<lamont> Riddell: test i386 build running now
<lamont> fix is committed in lamont/hppa-ia64 (xen kernels and hppa were missing CONFIG_MSS)
<Riddell> thanks
<xhaker> bummer, the kernel was uploaded already! :D
<zul> xhaker: send me the patch and ill get it in for the next one
<xhaker> zul, here http://www.leetcorp.net/xhaker.diff
<zul> got it thanks
<xhaker> zul, mjg59 sent me that yesterday. I added the description in front
<zul> is there still a meeting today?
<lamont> Riddell: I think it'll build.. :-)
<Riddell> exciting
<lamont> uploaded
<lamont> s/ed$/ing/
<Riddell> so when you say think, hopefully you're understating?
<lamont> yeah.
<lamont> it was past the scary part on a previously-afflicted architecture
<Riddell> accepted, many thanks lamont 
<lamont> yep.  built. :-)
<xhaker> hmm, i386 failed to build?
<xhaker> the last kernel upload, that is
<lamont> -10.27 can't have failed yet
<xhaker> zul, will -10.27 have that patch i sent you earlier? maybe i got lucky
<zul> xhaker: uh no
<lamont> .27 is nothing but the ftbfs
<xhaker> lamont, ok.
* infinity kills the -10.26 build on artigas...
<infinity> Oh, nevermind, it just finishd.
<dholbach> I also subscribed the kernel team to bug 125834
<dholbach> seems that the team is not bug contact for linux-ubuntu-modules
<dholbach> linux-ubuntu-modules-2.6.22
<dholbach> also bug 114793
<dholbach> and bug 124855
<infinity> They're the contact now.
<dholbach> rock and roll
<dholbach> gracias, monsieur conrad
<infinity> You're mixing languages.
<zul> atheros is lum isnt it?
<rtg_> zul: lrm
<lamont> BenC: you around?
<bdmurray> rtg_: what package is iwl4965?
<rtg_> Gutsy l-u-m
<rtg_> bdmurray: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-gutsy-lum.git;a=summary
<BenC> lamont: yeah
<bdmurray> great, thanks
<lamont> BenC: so since I suck at unbreaking things... is it preferable to have changelog claim that 10.28 immediately follows 9.25, or to renumber 10.{26,27} to 9.{26,27}?
<BenC> lamont: that's what kyle was working on
<kylem> so. really shouldn't have uploaded that.
<lamont> kylem: sorry.
<kylem> and everyone else is kind of stupid for approving it.
<lamont> and while you're fixing zen, please fix debian/hppa/config too
<lamont> s/zen/xen/
<kylem> especially given i was sleeping on the couch about 10 feet away
<kylem> with my mobile phone
<lamont> I think we were trying to let you sleep
<kylem> well, i wasn't at the time it ftbfs.
<kylem> anyway. wha tbroke now?
<lamont> same bug as xen
<lamont> -10.27 is top of my hppa-ia64.git tree
<lamont> and dies in abicheck, because I suck
<kylem> eh?
<kylem> oh.
<kylem> right.
<kylem> ok, i'll just bump to 10.28 and upload.
<lamont> i386 was ftbfs because of CONFIG_MSS.  ditto hppa
<kylem> yes.
<kylem> i know, i got the email...
<lamont> and I screwed up things for abicheck when I did -10.27
<kylem> yeah, it's fine.
<kylem> i'd have made the same mistake probably.
<lamont> but if you want the history, it's in my tree... :(
<kylem> ok, i pulled the patch from your tree
<lamont> and I had a -10.28 prepared, but hadn't committed it or uploaded yet...  and now it's your baton.
<kylem> lamont, there's nothing wrong with the commit though, right? it will succeed now?
<lamont> right
<kylem> ok, thanks.
<lamont> what I changed but did not commit was: changelog (rename .26,27 to -9), and rename debian/abi/2.6.22-9.25 -> 27
<kylem> the odds are astronomically high that i'm goign to fuck this up.
<lamont> want me to just upload a .28?
<kylem> no, it's fine
<kylem> why would you rename the abi?
<kylem> there is no abi to compare it to
<lamont> ah, good point.
<lamont> as long as it's -9.27 for the previous in changelog.  got it.
<lamont> EOVERKILL
<kylem> yeah, sorry, i should have nuked it when i was preparing it in the first place.
<lamont> anyway, sorry for screwing up .27 and making more work.
<lamont> and feel free to make that .27 guy lamont@u.c, or not. :-)
<kylem> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-gutsy.git;a=commitdiff;h=a5691db7134fd4566504a38c3a3d812658452665
<kylem> hopefully it doesn't fail because i capitalize urgent or something
<infinity> Processing..
<infinity> kylem: Processed and approved.
<lamont> kylem: as an FYI, debian/rules updateconfigs changes config/i386/*
<kylem> yeah
<kylem> i expect that
<lamont> I expected that you did
<lamont> I also noticed that at least one of those config vars was =y and =m in diff config.* files, and merged into =y... 
<kylem> hand editing them generally a bad idea
<lamont> uh.... that's what I do.  and then I run updateconfigs so that amitk doesn't yell at me.
<ogra> BenC, ping
<BenC> ogra: ?
<ogra> BenC, about bug 130330
<ogra> meh, no ubotu :P
<ogra> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/130330
<ogra> i was told you have concerns with that ?
<BenC> ogra: ...
<mjg59> ogra: Which hardware?
<kylem> i'm working on fixing up alsa on them.
<kylem> slowly.
<elmo> oh, right, I need to report my feisty-hates-usb bug
<ogra> mjg59, kaluha specifically and there is a driver for sis7019 that we dont have but thats available as unlicensed source that needs various bits of the oss stack thats missing as well
<mjg59> ogra: Yeah, I think the "unlicensed source" bit is probably more of a problem
<ogra> right
<mjg59> We shouldn't be distributing kernel options for the sole reason of letting someone breach copyright
<ogra> i have it building fine here, but cant use it, its a shame
<ogra> well, i think its up to the user and i want to enable them at least to make their HW work
<amitk_> ogra: we have worse - a GPL driver that we can't include becase of crazy firmware licensing: http://www.marvell.com/drivers/driverDisplay.do?dId=178&pId=38
<BenC> ogra: ah, right...we'll end up re-enabling oss where needed
<ogra> amitk_, well, i dont care about inclusion since i wont be able to, but i care that the user can solve it himself ....
<amitk_> ogra: point taken
<mjg59> amitk_: 2.2(ii) seems to grant permission to redistribute the firmware?
<elmo> mjg59: but not sell it, and check out the export/nuclear crack clause towards the end
<ogra> BenC, i'll get a list and attach it to the bug .... for now kahlua is the most important one i know of, but i'm sure there are more, these embedded chipsets suck in that regard
<mjg59> elmo: It says that we can't sell the firmware, not that we can't sell the product it's incorporated into?
<mjg59> elmo: I suspect that the export stuff is a matter of law anyway. I'd go slightly further and suggest that we've never made any real guarantees about anyone's right to use anything in l-r-m
<elmo> mjg59: if we sell an Ubuntu DVD with this on it, how is that not selling the firmware?  where does the license make the distinction between the firmware and the product it's integrated into
<elmo> mjg59: that export stuff is not a matter of law
<elmo> "any party engaged in nuclear, chemical/biological weapons or missile proliferation activities "
<elmo> " may not, in the absence of authorization by U.S. and local law and regulations, as required, be used by or exported or reexported"
<elmo> is something I can't even parse, but under at least one reading seems to say 'in soviet russia, US law applies YOU'
<mjg59> elmo: That section starts "are subject to US export control laws"
<mjg59> If authorization by US and local law and regulations /isn't/ required, it sounds fine
<elmo> I really don't see how you're reading it that way
<elmo> '  In addition to the above' <- above being are subject to US export control laws
<elmo> ' may not, in the absence of authorization by U.S. and local law and regulations, as required, [... a whole bunch of prohibitive restrictions] '
<BenC> ogra: ok
<mjg59> I read that as "You may not do these things without the authorization of US and local law (as required)"
<mjg59> Where there's no requirement, you may do them
<mjg59> elmo: The "You may not sell this" bit also claims "You may not distribute it", which is clearly at odds with 2.2 - the only way for that to make sense is for it to be fine to distribute or sell it as part of the licensee's product, but not on its own
<mjg59> Which is a restriction that we've had on other things in the past
<elmo> err, like what?
<elmo> oh, you mean selling in aggregrate
<elmo> sure we've had that before
<mjg59> Yeah
<elmo> but I don't buy the whole 'this is the whole sane reading of the license -> we'll use that' argument at all
<elmo> we've been bitten by that before with e.g. pine
<mjg59> 2.2(ii) makes it clear that you can distribute as part of licensee's product, whereas 2.3(ii) states that you can't distribute the proprietary deliverables
<elmo> and we've certainly got a history of rejecting internally inconsistent licenses
<mjg59> Heh. Have you guys asked for clarification?
<elmo> I dunno - I haven't been dealing with them/don't know who is.  amit?
<elmo> 'All Derivatives of the Open Source Deliverables shall be licensed back to Marvell' is another interesting one
<infinity> kylem: Old builds killed, new builds on the way.
<kylem> thanks hot stuff.
<mjg59> elmo: Surely that's an inevitable consequence of them being GPLed?
<elmo> not if I don't  distribute it to them, it's not
<mjg59> Hm. Yes, I can see that being an issue.
<amitk_> elmo: mjg59: I haven't dealt with Marvell directly. I got a request from Pepper to include this driver. And since the license was too much for my comprehension of law, I asked around (mdz, elmo, rtg_)
<amitk_> but if you know who has done these sorts of negotiations before, we could take this forward
<amitk_> actually it was Mithrandir instead of rtg_
<zul> BenC: maybe there should be a wiki page on patches from the community (ie what is needed, etc)
<BenC> zul: basically it's the same as upstream kernel
<IntuitiveNipple> Anyone familiar with the TCP keepalive code? I'm trying to confirm that code I'm looking at in net/ipv4/tcp_minisocks.c in tcp_check_req() is the bit responsible for sending the keepalive ACK - around line 585 "req->rsk_ops->send_ack(skb, req);"
<xhaker_> zul, that bit about patches from the community was related to the patch i linked you earlier? It was mjg59 who did that patch, not me, i just added the /**/ comment
<zul> xhaker_: can you update it then
<xhaker_> i've added it to my own branch
<xhaker_> what info do you need? the commit message?
<zul> signed off description etc
<xhaker_> can i export my diff with that info attached?
<xhaker_> git-*
<zul> sure email me it ill try to get it upstream as well
<zul> zulcss@ubuntu.com
<zul> or even better yet send it to the kernel-team ml
<xhaker_> I will do that.. after a reboot
<zul> later
#ubuntu-kernel 2007-08-22
<BenC> zul: ping
<zul> BenC: pong
<BenC> zul: was the amd SB600/SB700/SB800 patch in your patch set?
<zul> the ide stuff?
<zul> BenC: would it be ok to email the kernel-team list to say where I got thoee patches from?
<kylem> tell people to get it into -stable...
<zul> well the sdhci crack is already in linus-tree for one
<BenC> zul: that doesn't get it into our git tree, so 6 months from now, we'd forget where that commit originated
<zul> BenC: yeah realized it going through it
<zul> BenC: http://paste.ubuntu-nl.org/34608/
<zul> any information else do you need
<zul> if its ok ill rediff my stuff tomorrow morning
<xhaker> can somebody help me mail a patch to linux-ide?
<kraut> moin
<dholbach> did somebody mention that sound did not work with -10? /dev/sndstat does not exist and so on
<dholbach> also I assigned a few reviewing/sponsoring bugs to ubuntu-kernel-team - you can also see them here: http://daniel.holba.ch/sponsoring/ - it'd be nice if somebody picked them up
<Mithrandir> dholbach: missing lum, maybe.
<dholbach> Mithrandir: ok... I'll wait for them and see what happens
<JanC> maybe someone from the kernel team can have a look at this bluetooth bug: https://bugs.launchpad.net/ubuntu/+source/bluez-utils/+bug/32415 ?
<JanC> recent activity indicates that there might be a missing/incorrect patch or something like that...
<zul> https://bugs.launchpad.net/bugs/134043 <-- i so hope is a typo (2.6.10)
<lamont> zul: maybe it's the Ubuntu 6.10 kernel.
<lamont> although that doesn't make much sense either. :-)
<xhaker> Hi, lamont how do you send kernel patches upstream. I got a mbox file generated with git-format-patch, what do i do with it?
<lamont> xhaker: to date, I've sent my kernel patches to kernel-team@lists.u.c and let this gang deal with forwarding them upstream
<lamont> generally speaking, you send it to the upstream mailing list where the source is coordinated
<xhaker> lamont, i'm having trouble trying to send the mail correctly, is there any mail program i can use to send the mbox file? git-sendmail?
<lamont> uh... I use mutt
<lamont> but then, most people have decided that email == web these days, heathens.
<lamont> :-)
<lamont> you could just save it one message per file, and then send them as attachments to your mail
<lamont> I've seen that done, too
<zul> you can do git-format-patch -o ../patches origin
<lamont> alterntatively:  sed '1,1s/^From/Return-Path:/' $PATCH | sendmail $UPSTREAM
<lamont> zul: yeah - that's what I meant, but didn't feel like looking up syntax for it...
<zul> heh i used it all the time until recently
<lamont> zul: and now you use?
<xhaker> lamont, he commits! joke. zul?
<zul> eh?
<xhaker> zul, what do you use now?
<zul> a regular email client
* xhaker sends patchernel-team@l.u.c
<GM_Alex> hi
<GM_Alex> i have make my own kernel but my ati card doesn't work but the radeon module is in the config file
<GM_Alex> has anybody an idea?
<doko> BenC: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/74691 did you see the  patches.arch/i386-compat-vdso patch mentioned https://bugzilla.novell.com/show_bug.cgi?id=258433? (allow debuggers to access the vsyscall page with  compat vDSO.)
<BenC> doko: no, I hadn't seen that
<doko> BenC: hmm, can't see if it's a kernel or gdb patch
<carbonfreeze> anyone having an issue passing vga= options to tribe4+ kernel? After doing dist-upgrade from 7.04 to 7.10, newer kernel just shows blank screen upon boot instead of verbose output. I have to remove vga= options to get a 640x480 fb.
<IntuitiveNipple> Anyone know what the RFC or specification document is for TCP_DEFER_ACCEPT aka SO_ACCEPTFILTER for delayed/deferred ACK on TCP handshakes?
#ubuntu-kernel 2007-08-23
<defendguin> i just upgraded gutsy to the newest kernel and now my sound is gone
<BenC> defendguin: hda?
<BenC> defendguin: do you have linux-ubuntu-modules-2.6.22-10-generic installed?
<defendguin> through the ear phones works fine
<defendguin> one sec
<defendguin> yes its installed
<BenC> headphones work but speakers don't?
<defendguin> correct
<defendguin> maybe the sound is in audible 
<defendguin> i tried adjusting volume and running the tests but nothing
<defendguin> under preferences the Sound option i tried running those audio tests with nothing 
<defendguin> BenC: any idea?
<BenC> defendguin: yeah, the new snd-hda-intel driver is broke for you, will get fixed in next upload
<defendguin> BenC: ok i'll live with it
<defendguin> BenC: how did it get broken?
<BenC> defendguin: the newer version fixed some things, but I expected it would break others. We didn't have a chance to back it out before this upload
<defendguin> what did it fix?
<BenC> IBM t60/t61, Dell 1420/1521
<defendguin> hmmm
<defendguin> i have to add the i8042.nomux  kernel option for my laptop or else the touchpad is broken when i come back from suspend is there any way i can get that fixed?
<defendguin> https://bugs.launchpad.net/bugs/86820
<defendguin> its annoying as hell
<BenC> defendguin: dmi entry for your laptop
<defendguin> ?
<defendguin> sorry,   what is a dmi entry?
<BenC> sudo dmidecode > dmi.txt
<BenC> that file can be used to add an entry specific to your model/bios-version of laptop
<defendguin> so if i upgrade my bios is might mess up that?
<defendguin> would you like me to attach that txt file?
<BenC> yeah, attach the file
<BenC> upgrade your bios first, and if it doesn't fix it, we can add the exclusion
<defendguin> the bios is the newest available version 
<defendguin> just ask in the ticket to have an exclusion added for my laptop and add the file?
<BenC> yeah
<defendguin> ok done
<BenC> thanks
<defendguin> let me done some testing and i'll add that info in a few
<defendguin> suspend is very flaky for me sometimes things work sometimes they don't
<defendguin> it's hard to say what breaks what
<defendguin> hmm that seems to work well
<defendguin> BenC: you said it was called an exception?
<BenC> defendguin: depending, it's probably called a blacklist
<defendguin> well i want to make the right request in the ticket
<BenC> defendguin: it will be understood
<defendguin> thanks
<sparr> is there a [k] ubuntu packaged kernel with CONFIGURE_TIMER_STATS enabled?
<sparr> for powertop
<kylem> uhm. yes. all of them.
<sparr> ok, ill upgrade then, thanks
<kraut> moin
<Company> morning
<Company> i'm on a macbook with recent gutsy, and gnome-power-manager doesn't show battery status info
<Company> what to do?
<Company> it didn't work with the last kernel either, the ones before worked fine
<Company> #129388
<abogani> BenC, amitk_: Could you tell me why nvidia and fglrx are not present in l-r-m 2.6.22-10-rt, please ?
<_MMA_> abogani: I was about to. PM. :)
<amitk_> abogani: because nobody tweaked the config perhaps?
<abogani> amitk_: What config ?
<amitk_> kernel config? Or is the source missing?
<abogani> amitk_: AFAIK Nothing missing.
<abogani>  I resolved all tech and legal issues. I don't understand why, if exist a problem with a -rt, no person tell me....
<_MMA_> abogani: I PM'ed you with my chat with Ben.
<_MMA_> It has the info there.
<amitk_> abogani: I don't run -rt. BenC might know.
<BenC> abogani: after tribe-5, I'll be uploading an lrm that to work with -rt and -xen
<zul> yay
<_MMA_> w00t! Morning Ben.
<verwilst> isn't the latest kernel upload -10.30? :
<verwilst> :)
<amitk_> verwilst: yes
<verwilst> i'm wondering, when will the new xen kernels be compiled for 64bit?
<amitk_> zul should know :)
* verwilst looks at zul :)
<verwilst> i would really like to know, since i installed my new colocation server with the i386 -10-xen kernel now
<verwilst> but i would prefer to do everything in 64bit instead
<isidoro> hi guys someone is on line?
<ScottK> Yes
<isidoro> hi scottk
<isidoro> are you expert with hal demon?
<ScottK> No.
<ScottK> If you have a question, just ask it.
<isidoro> i have a stupid but annoing problem....  a usb pen stik is mount with ipod icon than yellow usb esternal disk icon
<isidoro> in feisty
<isidoro> hal says block.is_volume = true  (bool) but is wrong that's a storage not a volume
<isidoro> another usb pen stik hal says block.is_volume = false  (bool) and shows many more options for storage
<isidoro> that one has ipod icon hal shows many more option for volume
<isidoro> I am not able how to teach to hal that particular pen is hard disk not a ipod 
<isidoro> no one has ideas???
<isidoro> :-(
<ScottK> isidoro: Of the top of my head, I'm not sure why you chose #ubuntu-kernel to ask that question.  HAL isn't part of the kernel.
<isidoro> ScottK: ok where can i discuss about it?? on which room?
<ScottK> #ubuntu since it's a support question, not a development question.
<zul> amitk_: hmm?
<zul> amitk_: oh yeah there is a patch i havent submitted yet
<verwilst> zul: for 64biT?
<zul> verwilst: yep
<verwilst> so next version of the kernel will be amd64 too?
<zul> hopefully
<verwilst> if so, i'm not bringing my colo server to the datacenter yet :)
<verwilst> but i'll reinstall it so it's all 64bit ;)
<verwilst> zul: that xen kernel is heaven :)
<verwilst> you still have to use ethtool tx off, but hey
<verwilst> it's certainly better ( read: easier ) than compiling my own kernel or using the 2.6.18 from xensource :)
<zul> verwilst: thanks
<verwilst> zul: if you can provide me with a build of your new kernel, i'll be more than happy to test it out
<zul> verwilst: i can put up the patch somewhere for you to test
<zul> send an email to remind me
<verwilst> zul: will do
<zul> zulcss@gmail.com
<verwilst> zul: you have an estimate when the new kernel could appear?
<verwilst> ( i wanted to have my colo live starting from sept :)
<zul> verwilst: no idea
<verwilst> zul: and what exactly does the patch do?
<verwilst> zul: so i can add amd64 in debian/control, debuild, and use it all 64bity? ;)
<verwilst> ( or was it debian/rules )
<verwilst> zul: it it a dpatch file?
<verwilst> is*
<zul> verwilst: nope its a diff
<verwilst> oh
<zul> verwilst: grab the latest tree from git and do a fakeroot debian/rules custom-binary-xen, it will generat the deb and headers for you
<verwilst> uh
<verwilst> ubuntu-git?
<verwilst> i'm really at home at ubuntu kernel compilation stuffs :)
<verwilst> i usually do apt-get source linux-source-xxx and a debuild :D
<zul> nope you need the git tree from kernel.ubuntu.com
<verwilst> zul/ubuntu-gutsy-xen-3.1.git probably
<verwilst> never used git either :d
<verwilst> so i can learn it ;)
<zul> nope ubuntu/ubuntu-gutsy.git and then apply the patch once you send me an email (zulcss@gmail.com) and ill send it tonight when i get home
<verwilst> oh
<verwilst> so just checkout, patch manually, get in the root, and do "fakeroot debian/rules custom-binary-xen"
<verwilst>  voila
<verwilst> ?
<zul> yep
<verwilst> will that compile 99 kernels like my debuild did? :)
<verwilst> -rt, -server, -generic, ... :)
<zul> nope just the one
<verwilst> what's the patch for?
<verwilst> amd64 compilation fixes or something?
<zul> yep
<mhb> hello folks, restricted-manager is getting a lot of bugreports for the lirc_gpio marked as a restricted module, but I've been told that it's a kernel bug and it's being worked on. Is there a central bugreport I can link duplicates to?
<verwilst> zul: fetching git tree ;)
<verwilst> zul: kernel ready and waiting for patch ;)
<zul> verwilst: well you are going to have to wait a bit longer since im not home from work yet
<verwilst> yeah sure no prob
<verwilst> you told me already :)
<zul> ill send it tongith
<verwilst> you in USA?
<zul> canada
<verwilst> ( btw you're in private chat too :) )
<verwilst> oh
<verwilst> that's like gmt-7 or something?
<zul> dont know
<verwilst> well, no hurry :)
<verwilst> zul: i guess that's one of the errors your patch fixes: http://pastebin.ca/668137
<zul> verwilst: one of them
<BlueDevil> hello, can someone help me build the NVIDIA driver 100.14.11 as a package please?
<BlueDevil> i'm using feisty
<bdmurray> kylem: with the new kernel my volume keys are affecting headphone volume instead of speaker volume.  What would be needed for that bug report?
<kylem> amixer output
<kylem> i know things are kind of wonky with alsa right now, i'm working to fix it in the next upload
<bdmurray> okay, I won't bother then
<kylem> can you put the amixer output on rookery:public_html or something for me though?
<kylem> also cat /proc/asound/cards (iirc that's the path)
<soysamurai> I know that this isn't the right place for this question technically, but maybe someone can point me to the right place ;) I'm working on an ebtables module and I was looking for someone who has more experience with the bridging code (and network internals) than I.. 
<soysamurai> The #kernel channel is deathly silent and #ebtables is dead 
<bdmurray> kylem: http://people.ubuntu.com/~brian/bdmurray-laptop-sound.txt
<kylem> thanks.
<bdmurray> Is there a workaround I can use in the meantime?
<kylem> soysamurai, try #kernelnewbies on oftc? (sorry, i don't know too much about the network stack)
<kylem> bdmurray, tbqh, i'm not sure what's going on there yet.
<kylem> i think the controls got reordered or something
<bdmurray> kylem: I could boot the old kernel then
<soysamurai> kylem: thanks, I just figured someone in here might have an inkling of where to look I'll see if it's more lively over there 
<kylem> bdmurray, oh, that would be useful
<bdmurray> kylem: the amixer output was quite different I updated the file on rookery
<kylem> thanks, i think i knew what's wrong now
<kylem> or rather, i think i know what broke
<bdmurray> cool
<bdmurray> zul: ping
<zul> bdmurray: pong
<zul> bdmurray: whats up?
<bdmurray> zul: At one point in time you were working on bug 84965.  What is the current status of it?  Has the patch made it into Gutsy?
<zul> remind me again which one is that/
<bdmurray> Microsoft Ergonomic Keyboard support
<zul> ah no it hasnt, i can get it again this weekend hopefully
<bdmurray> That'd be cool - it seems like a nice to have
<verwilst> hmm gutsy will be sweet :)
<mhb> whom can I talk with about linux-restricted-modules?
<mhb> err, bad sentence :o)
<doko> devel/linux-libc-dev is missing usr/include/linux/awe_voice.h - is this intended?
<mhb> is there a developer of linux-restricted-modules in this channel?
<kylem> mhb, yes, several, just ask your question
<mhb> okay. It seems modules.alias.override/ath_hal won't list an Apple MacBook (black non-pro) wireless card. Do you prefer to have a bug about it or is there a faster procedure (I guess adding a line there is not really hard) ?
<Mithrandir> please file bugs.
<doko> ../include/check_data.h:38:27: error: linux/ip_masq.h: No such file or directory
<doko> ../include/check_data.h:39:25: error: net/ip_masq.h: No such file or directory
<doko> BenC, kylem: linux-libc-dev doesn't look too well ...
<doko> plus linux/awe_voice.h
<mhb> Mithrandir: yeah, I was afraid you'd say that :o) my last easy-to-fix bug related to the kernel has been unnoticed for over a year now, so I had to ask
<BenC> doko: linux-libc-dev only installs headers required for libc
<BenC> can't see awe_voice.h being needed for that :)
<doko> BenC: apparently these were inclued earlier? at least this breaks sdl-mixer1.2 and keepalived. that change was done in the past three weeks?
<BenC> doko: then those things need real linux headers, either from linux-headers-2.6.22-10, or included locally
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.22-10.26 | Latest news: -rt and -xen kernels re-added | New Kernel Team machine: http://kernel.ubuntu.com/
<doko> BenC: jsut don't understand why we break somtething like this just before feature freeze ;-P
<BenC> doko: I can't see that being the case...we (kernel team) don't remove headers from there, the linux upstream build decides what goes and what doesn't
<BenC> and 2.6.22 has been final for longer than 3 weeks, so there's almost zero chance something changed recently
<doko> ok, filing bug reports for those packages
<bdmurray> kylem: there seem to be a fair bit of bugs about sound with 22-10 is there some way to consolidate them?
#ubuntu-kernel 2007-08-24
<lamont`> BenC: it still says find: /lib/firmware/2.6.22-10-hppa64: No such file or directory with -10.30, just fyi. :)
<doko> kylem, BenC: please could you add lpia support to: linux-backports-modules-2.6.22 linux-meta linux-source-2.6.22 linux-ubuntu-modules-2.6.22
<kraut> moin
<verwilst> morning
<tseliot> BenC: can I steal a minute of your time?
<paran> could someone look at bug 92553? I have sent two mails about it to the kernel-team list, the last one with a patch attached, but both have been ignored.
<paran> if there is something wrong with my solution i'd really like to know so that I can fix it.
<jwendell> Hi, BenC. I'm seeing on changelog you dropped snd-hda-intel on version 10.30. Now i have no sound on my laptop
<jwendell> BenC, what should i do in order to have my sound back?
<zul> hah someone wants cfs
<verwilst> hi zul
<verwilst> zul: you have mail
<verwilst> zul: already gets a lot further than without the patch :)
<zul> ill send you a patch
<verwilst> okido
<verwilst> go ahead, i'll test it right away
<verwilst> an updated "diff" ?
<zul> yeah it'll have to be later though since I just got into work
<verwilst> ah ok :) after work you mean?
<zul> probably
<verwilst> ok! enjoy your work then :)
<ogra> zul, https://lists.ubuntu.com/archives/ubuntu-users/2007-August/121818.html is that known ?
<zul> ogra: not that i know of
<zul> ogra: http://lists.xensource.com/archives/html/xen-users/2006-10/msg00103.html
<ogra> i'll point him to that, thanks
<zul> no probs
<verwilst> zul: found the problem i think
<zul> oh?
<verwilst> you set LOCALVERSION to "-xen"
<verwilst> but you have an EXTRAVERSION in make, that's -10-xen
<verwilst> making it -10-xen-xen
<zul> ok
<verwilst> setting the localversion in config.amd64 to "" should fix it
<verwilst> trying now
<verwilst> zul: the kernel itself compiles fine though
<paran> ignored once again. am I the only one actually using the linux-image-debug-packages? :-)
<verwilst> zul: linux-headers-2.6.22-10-xen_2.6.22-10.30_amd64.deb and linux-image-2.6.22-10-xen_2.6.22-10.30_amd64.deb are present! ;)
<verwilst> so it works
<verwilst> i'll go home in 30 mins and try booting with it
<zul> ok
<verwilst> ( had to add amd64 in control first :)
<verwilst> and the small fix to config.amd64
<verwilst> zul: Signed-off-by: Bart Verwilst <bart@verwilst.be>
<verwilst> hehehe
<Kano> hi
<Kano> config-2.6.22-10-generic:# CONFIG_SND_HDA_INTEL is not set
<Kano> is that by purpose?
<rtg> Kano: CONFIG_SND_HDA_INTEL is fubar'd. It being worked on.
<mjg59> Kano: Check Launchpad. It's a known issue.
<tseliot>  hi, does anybody know why my patches (for Feisty and Gutsy) haven't been approved yet? https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.20/+bug/98641/comments/66 https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.20/+bug/98641/comments/67
<Kano> hmm system lock with that kernel...
<BenC> tseliot: I thought that were in there...I'll check them in a few
<Kano> why was hda-intel not active??
<tseliot> BenC: thanks
<mjg59> Kano: Because it was in linux-ubuntu-modules instead
<Kano> any specific reason why it was not patched directly
<mjg59> Because of a desire tokeep the Linux source as close to upstream as possible
<Kano> why have been most of my kernel patches ignored
<Kano> only the one from mm was integrated
<mjg59> What makes you think they've been ignored?
<Kano> they did not have been applied
<Kano> and i added a bug one month ago for each of em
<Kano> how do you compile linux-ubuntu-modules for one flavour only
<zul> *sigh* here we go again
<mjg59> Kano: linux-restricted-modules is generally handled at a lowerpriority than the core kernel. I'll be done before the release.
<Kano> patches that only change 1 or 2 lines...
<Kano> but the 2 others
<Kano> about hostap_cs and the via southbridge on intel
<Kano> currently i even patch the a new siemens id
<Kano> these 2 where against 2.6.22 directly
<BenC> Kano: fakeroot debian/rules binary-modules-generic
<Kano> BenC: thanx. and for restricted too?
<BenC> for lrm, you're just going to have to build the whole thing
<BenC> no one has switched it over to the new build system yet, because it's ugly and hairy
<Kano> not good...
<mjg59> Kano: Working patches welcomed
<Kano> they work
<Kano> but still ignored
<mjg59> There's no real incentive to change it - lrm builds correctly, and for the purposes of Ubuntu development there's no real incentive to build it for a single flavour
<lamont> it's not like the build takes a long time
<verwilst> zul: just to let you know, the kernel boots fine
<lamont> 13 minutes is quick
<verwilst> xend starts, xm list works, ...
<Kano> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/128289
<Kano> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/132466
<Kano> patches working, not included
<mjg59> Kano: Thank you. We can list your bugs.
<mjg59> Kano: They're patches of low importance and low risk, so they're not high priority righ tnow
<mjg59> We're part-way through a development cycle. If they're not there by beta, then please feel free to remind us.
<Kano> well risk is really low, just apply em
<Kano> i know that they are correct. otherwise pure ubuntu kernels are absolutely useless for me
<mjg59> But there's no point whatsoever in doing so until then. It won't make things happen any faster.
<BenC> Kano: it's true, we could "just apply them", but the reality is, those are not the only two bugs we have to look at...we have to prioritize, else we'll never get the big problems taken care of
<BenC> Kano: but your fixes will get in
<Kano> there is a new one i currently patch. the one who found it reported it here:
<Kano> http://bugzilla.kernel.org/show_bug.cgi?id=8932
<Kano> also only id changes
<Kano> 2 lines
<mjg59> Kano: Please file a bug and link to the upstream bug
<nixternal> quick question...with gutsy, my realtek 8139 lappy eth connection craps out on the wan, works fine on the lan...happens after a while of use, and then comes back...would this be kernel related at all? I just started noticing this yesterday (24+ hours ago)
* lamont bets he meant wlan
<BenC> Kano: if you want things faster, apply for a kernel.ubuntu.com account, clone our tree, commit the patches and send a pull request
<nixternal> not wireless
<nixternal> I can hit my gateway fine, but anything outside of my network I can't...and it is only this laptop, it doesn't happen with any other gutsy machine here
<lamont> ah, ok
<BenC> nixternal: doesn't sound like kernel
<lamont> that sounds more like a router issue
<nixternal> why only this laptop and not my other machines?
* lamont was trying to picture plugging a laptop into a WAN
<nixternal> hehe
<nixternal> you know, I wouldn't 100% put it past the router either after our storms and issues last night, but it is just odd that it only happens to one machine
<BenC> nixternal: could be something whacky with network-manager :)
<nixternal> BenC: network-mangler you mean :)
<BenC> for example, if it dropped the default route
<mjg59> nixternal: Are the other machines running Linux?
<nixternal> mjg59: yessir
<mjg59> Hm. Ok.
<mjg59> If the card is able to talk to your local network, it's highly unlikely that it's a kernel issue
<mjg59> Unless your upstream is *very* odd
<nixternal> ie. I am connected to my server which is running gutsy, that is how I am able to stay on IRC
<BenC> nixternal: next time it happens, check "route" output to see if it's sane
<nixternal> BenC: will do
<mjg59> Best you could do would be to get a tcpdump of the the traffic when it's affected
<Kano> ubuntu is really fast... just as fast as the ntfs-3g development. there is 1.8 out and 1.7 in repository...
<nixternal> looks sane
<nixternal> it is affected right now...let me try tcpdump
<Kano> do i really have to report every bug...
<zul> yes
<zul> then it would never get fixed
<BenC> Kano: when we hit kernel freeze, we only take fixes that have bug reports associated with them
<Kano> is nobody tracking upstream on major packages, and ntfs-3g is major
<Kano> it writes on ntfs
<mjg59> Kano: We're past upstream version freeze.
<BenC> Kano: pkl is taking care of our ntfs-write support
<mjg59> No new upstream versions will be accepted unless somebody explicitly requests them.
<Kano> i use it since 14 days without problems
<zul> BenC: what should i do with the cfs wishlist bug report?
<BenC> zul: bug#?
<nixternal> heh, as soon as I run tcpdump the connection comes back
<zul> 134491
<rtg> zul: revert it to wishlist from confirmed.
<zul> its already wishlist
<rtg> zul: never mind. I confused status with importance.
<zul> BenC: i say tell them to wait til gutsy+1 
<BenC> zul: mark as wont fix in 2.6.22 with a comment about being too late, and tag it gutsy-plus-one
<BenC> zul: actually, better tag may be deferred
<zul> BenC: done
<BenC> zul: gracias
<zul> no probs
<tseliot> BenC: if you have any questions on my patches I'll be glad to answer
<Kano> why do you compile ipw3945 and iwlwifi?
<mjg59> Kano: Because iwlwifi is currently not stable on 3945
<Kano> and why is it compiled then
<Kano> you would need to blacklist it
<mjg59> The 3945 IDs have been removed
<mjg59> It's used for 4965
<Kano> hmm
<Kano> thats older lirc or
<BenC> tseliot: sure thing
<BlueDevil> BenC: can you share how you built the packages for nvidia 100.14.11 driver and l-r-m please?
<BlueDevil> i'd like to build the same packages for my system. thanks
<BenC> BlueDevil: I'm not sure what you mean
<Kano> hmm lirc is new
<Kano> but why is ttusbir not there
<BenC> BlueDevil: install the latest nvidia-glx-new and you have that
<BlueDevil> BenC: i'm running a custom kernel (because the stock kernel does not support more than 4G of ram) so i need to build l-r-m myself, right?
<Kano> any specific reason to skip that module?
<BenC> BlueDevil: you're better off just downloading the nvidia installer and running that for your kernel
<BenC> Kano: lirc support came from a community member, we didn't decide what to put in there, we too what the guy gave us
<BlueDevil> BenC: would i be able to deinstall what the installer installed if I ever wanted to?
<BenC> took
<BenC> BlueDevil: yes
<BlueDevil> how?
<tseliot> BlueDevil: you can install nvidia-glx-new nvidia-glx-new-kernel-source (or whatever it is called) and build the kernel module with module-assistant
<Kano> BenC: i think he missed that the new lirc has a new module
<BenC> BlueDevil: the installer will uninstall too
<BlueDevil> tseliot: i'm not sure how to build that
<BenC> Kano: I wasn't very keen on lirc being included in lum anyway, but the ubuntu-media folks needed it to support hw out of the box
<Kano> yes it is needed just like the new module 
<BlueDevil> are there any chances that the kernel in gutsy will support more than 4G ram by default?
<BenC> Kano: then by all means include it
<tseliot> BlueDevil: you can uninstall it by typing sudo sh nameoftheinstaller --uninstall
<Kano> i think only the CONFIG_LIRC line is missing
<Kano> the source is there
<BenC> BlueDevil: Not likely to happen in our default 32-bit kernel...why not run 64-bit?
<Kano> will check it
<tseliot> BlueDevil: this is something we can discuss elsewhere. I can show you how to do that in just few mouse clicks
<BlueDevil> BenC: because i'm in the online video business and 64bit is nothing but trouble in that respect (flash + w32codecs) :(
<BlueDevil> tseliot: can I pm you?
<tseliot> BlueDevil: sure
<BlueDevil> thx
<BenC> BlueDevil: Maybe you should run the -server kernel?
<BlueDevil> BenC: i tried the -bigiron but nvidia wouldn't work, would i have better success with -server?
<BenC> BlueDevil: it's worth a shot
<Kano> it seems you manually added those, well should be no problem...
<Kano> well the makefile mod is simple, whats with that 0list?
<Kano> or should it be in every arch
<BenC> 0list is a template
<Kano> CONFIG_LIRC_TTUSBIR=m
<Kano> should i add it everywhere?
<BenC> each arch needs the CONFIG_* line in it
<BenC> yeah, including the 0list file
<Kano> well you have to check if it compiles..
<BenC> I'm not going to include a patch that I know I have to test
<Kano> i can not compile sparc and such things
<Kano> that is no real patch, i just added the line in the makefile
<BenC> you don't have to test it everywhere
<BenC> just binary-modules-generic will make me happy
<BenC> Kano: does it apply with the patch command?
<Kano> tested that on i386
<Kano> wait one second
<Kano> should i dcc you the patch
<Kano> or upload
<cjwatson> people still use dcc?
<Kano> a very simple one
* cjwatson checks the century indicator on his clock
<BenC> hehe
<BenC> I haven't used dcc since the efnet days
<Kano> http://kanotix.com/files/kernel/linux-ubuntu-modules-2.6.22-2.6.22-lirc-ttusbir.patch
<BenC> Kano: email to kernel-team is preferred
<BenC> kernel-team@lists.ubuntu.com
<verwilst> zul: could i recommend 1 more patch?
<verwilst> http://overlays.gentoo.org/proj/xen/browser/patches/tags/2.6.20/fedora-xen-patches-2.6.20-2925.13.fc7/1665-linux-2.6-disable-netback-checksum.patch?rev=10
<verwilst> it's a one-liner
<verwilst> but it makes sure you don't need to do ethtool -K ethX tx off
<Kano> why is ndiswrapper 1.45 not 1.47?
<BenC> Kano: UPSTREAM-VERSION-FREEZE
<Kano> do you really know how long 1.47 was avalable
<BenC> unless we have a compelling reason to do so, it wont get upgraded
<Kano> bugfixes
<BenC> Kano: can you list the bugs?
<BenC> Kano: can you tell me how severe they are?
<Kano> 1.47 is out since 27. 04.
<Kano> 4 months
<BenC> if we go by bug-fix alone, we'll be upgrading till release day
<Hobbsee> BenC: Kano seems to be out to troll, so probably wont answer that
<Kano> Hobbsee: should i add all changelogs since 1.46 to the bugreport?!
<Hobbsee> BenC: that being said though, upgrades of ndiswrapper are usually a good idea, for the hellish cards that require them.
<Hobbsee> Kano: list the bug fixes.  not changes.  
<mjg59> Kano: If you can point us to people who are having bugs in Ubuntu, that's significantly more compelling
<Kano> Version 1.46 has been released. Short summary of changes since 1.45:
<Kano>     * Fixed crash with large transfers (bug in version 1.45)
<Kano> Version 1.47 has been released. Short summary of changes since 1.46:
<Kano>     * Fixed random (occassional) crash issues with 64-bit drivers (observed with Broadcom driver)
<Kano>     * Fixed compilation issues with version 1.46
<Kano> so you see 64 bit fixes
<verwilst> zul: mail sent
<verwilst> bye!
<BenC> Kano: 64-bit doesn't concern me too much
<BenC> people have way too many excuses already to use 32-bit even on x86_64 hw
<Hobbsee> ndiswrapper seems to have a disobliging habit of *breaking* some cards, the further up they go.
<Hobbsee> version-wise
<Kano> Hobbsee: i really prefer to use latest code
<BenC> yeah, hence, fixing things may not be worth breaking other things
<Hobbsee> Kano: i prefer to use code that *works*.
<Hobbsee> Kano: tell that to my old wifi card, which broke with later versions of ndiswrapper.
<Kano> Hobbsee: then you are not able to go to #ndiswrapper and speak to giri
<Kano> i did serveral times, even donated to him
<Hobbsee> Kano: you assume, wrongly, that i did not.
<Kano> and it still does not work with 1.47?
<Hobbsee> see the part about "old"
* Hobbsee changed machines since then.
<Hobbsee> it broke in 1.17, iirc.  i no longer have that card.
<Kano> what i absolutely know is that the feisty ndiswrapper was unusable at all for my card
<Kano> so i skipped feisty not because of that, but due to other problems
<Kano> hmm even 1.48rc1 there...
<mjg59> We're not shipping a release candidate
<Kano> then use 1.47
<mjg59> Kano: As I said, if you can point us to bugs filed against Ubuntu that show people having problems, it's much easier to convince the release team that we should do that
<mjg59> But if we have no evidence of people having problems, we're not going to take the risk of introducing new and unknown bugs
<Kano> the only reason that i see is that your current ubuntu users are not heavy ndiswrapper users. but kanotix users are
<Kano> and when i want use ubuntu as base then i dont want to have worse hw support than before
<mjg59> Kano: Perhaps the needs of your users do not align well with the Ubuntu release methods?
<BenC> Kano: any time you use a release distribution, you are going to have slightly out-dated software
<BenC> there's no way to get a stable dist with latest software all around
<Kano> BenC:  sure, but not the main drivers
<BenC> Kano: I'd hardly call ndiswrapper a main driver
<Kano> ntfs-3g, ndiswrapper are thing that i monitor
<mjg59> Kano: We don't accept new upstream versions after the 16th of August unless there are important bugs that we know they will fix
<BenC> Kano: important to you doesn't mean important to all of our users
<mjg59> Kano: If that's unacceptable to you, then I suggest that you either changethe process (you'll want to contact the technical board) or find a new source of kernels
* BenC notes that mjg59 is on the technical board
<doko> kylem, BenC: please could you add lpia support to: linux-backports-modules-2.6.22 linux-meta linux-source-2.6.22 linux-ubuntu-modules-2.6.22
<BenC> doko: I'm pretty sure it's in linux-source, linux-meta and linux-ubuntu-modules
<doko> lookking
<BenC> doko: just needed for lbm and lrm
<doko> BenC: linux-meta doesn't build linux-headers-generic and linux-image-generic . correct?
<BenC> doko: yeah, it does
<doko> BenC: and linux-ubuntu-modules and linux-backports-modules-2.6.22 is not needed for the live CD, apparently
<BenC> doko: linux-ubuntu-modules is
<doko> BenC: ok, was confused that lpia doesn't have a -generic, but just a -lpia kernel. but as long as that's roughly the same config as i386 that will let us boot from the liveCD
<BenC> doko: well, linux-ubuntu-modules-2.6.22-abi-generic is, not sure about the meta package
<BenC> doko: lpia flavour is pretty much the same as ume
<doko> apt-cache -n search linux-ubuntu doesn't show anything
<tseliot> doko: linux-restricted-modules
<doko> yes, missing as well
<tseliot> doko: instead of linux-ubuntu-modules
<zul> doko: i was wondering why you added ipia to xen-3.1?
<tseliot> doko: doesn't this command return anything??? apt-cache -n search linux-restricted-modules 
<doko> tseliot: it does on amd64, not on lpia
<doko> zul: looking if it builds and works with gcc-4.2
<zul> ah ok
<tseliot> doko: sorry, I didn't read ipia flavour...
<BlueDevil> what is the downside of compiling a kernel with HIGHMEM64G=y vs HIGHMEM4G=y?
<BenC> BlueDevil: more overhead
<BenC> you really only want 64G enabled if you have > 4G of memory
<BlueDevil> do you know if any benchmarks have been done?
<BenC> otherwise it hurts you performance wise and takes up more memory just for memory management
<BenC> BlueDevil: I can't point you to any, but I'm pretty sure it's been done
<BenC> I think most people assume that you'll be running a 64-bit kernel on such machines
<BenC> there are ways to run 32-bit stuff decently on 64-bit
<BenC> ia32-libs and friends help a lot
<BlueDevil> the last time i ran flash in a 32bit chroot it took away part of my filesystem when it crashed; i didn't even think that was possible
<BenC> were you running it as root?
<BlueDevil> no
<BenC> I don't see how it can corrupt your fs if it isn't run as root
<BenC> that would be a major bug :)
<BlueDevil> i didnt investigate much the machine being a production one; i just reinstalled 32bit
<BlueDevil> AFAIK it didn't do anything outside of the chroot but i wasn't going to risk it
<BenC> BlueDevil: why not ditch the chroot and use ia32-libs and the 32-bit firefox plug-in wrapper?
<BlueDevil> BenC: i don't think those were available at that time
<BlueDevil> i was on dapper-1
<BlueDevil> or -2
<BlueDevil> everybody was recommending 32-bit chroot to run flash
<BlueDevil> looking now at ia32libs
<BlueDevil> what are my options for w32codecs?
<JanC> w32codecs are illegal, so...  ;)
<tseliot> BlueDevil: have a look at this sticky in the forum: http://ubuntuforums.org/showthread.php?t=191205
<BlueDevil> JanC: why are w32codecs illegal?
<BlueDevil> i own a windows xp oem copy for the machine
<pmjdebruijn> BlueDevil, because MS' license probably says you may only use the codecs in conjunction with WinXP
<JanC> that license says that, but that part might be illegal in itself in some countries
<JanC> OTOH, there is no license that allows redistribution of those codecs in the way w32codecs does
<JanC> so if you use the codecs on your WinXP partition, that might be okay, but w32codecs certainly isn't
<verwilst> http://pastebin.ca/669541 <- anybody knows about this?
<verwilst> had to modprobe dm-mod manually
* ..[topic/#ubuntu-kernel:BlueDevil] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.22-10.26 | Latest news: -rt and -xen kernels re-added | New Kernel Team machine: http://kernel.ubuntu.com
#ubuntu-kernel 2007-08-25
<calc> does linux support exFAT yet?
<calc> perhaps it will be a useful replacement for aging and crappy FAT32 for OS data sharing partition
<mjg59> calc: No, there are no specs
<calc> mjg59: oh :\
<arno> hi all I did 'apt-get install kernel-source-2.6.20' and got a bz2 in /usr/src. Moved it to a new subdir of my ~/. Unzipped and did make xconfig, set the processor type and then make, and used make-kpkg to create a linux-image_xxxx. Installed it and it created a ramdisk and all. BUT: boot stops after having displayed the splash screen. CtrlAltF1 tells me "kernel does not support inotify" etc. But I DID compile with CONFIG_INOTIFY=y. (Doub
<arno> le checked). Any suggestions?
<BlueDevil> get the kernel source from git and compile that
<maks> BenC: can you please nack #124855, this guy has zero idea, he ignores simplification like MODPROBE_OPTIONS to add everywhere *again* the -Qb args
<maks> also 0.89 is a bad base to merge with, the first sys walk MODULES=dep didn't account fancy root bootargs
<BenC> maks: ok, thanks
<BenC> and done
<maks> BenC: thanks
<hambobo> is this to help making an os be defult
<hambobo> omggg no one here
#ubuntu-kernel 2007-08-26
<damntech> Hello I am unsure if this is the right channel but (Sys Admin here) has anyone here worked with KVM from a real implementation perspective?
<rautela> git-cloning ubuntu' s xen3.1 git repo stalls after sometime, any idea why?
<ion> anyone know of a howto to compile a kernel with cfs scheduler patch?
<arno-t> Hi I'm a newbie on kernel compiling - Can I use a .config file from an earlier compilation (earlier kernel source) to compile a new? Will there be any problems with new or deprecated options between versions? Is the .config the only file I need?
<defendguin> who do i speak to about getting a driver updated?
<Chorus> anyone succeded in compiling 2.6.22-*-xen for amd64?
<`23meg> Is there the slimmest chance that we jump to .23 for Gutsy? There's a lot of demand from users, as usual, mostly due to CFS and I/O problems in .21 and .22 that have been fixed
<defendguin> `23meg: how are you calculating user demand?
<`23meg> extrapolating from number of forum posts :)
#ubuntu-kernel 2008-08-18
<_gAri-> hi there, can please someone help me how can I get the kernel patches of ubuntu individually, not a whole big patch? I just cloned the git repository
<mjg59> _gAri-: git log will show you the logs. git show hashvalue will then give you the individual patch associted with that commmit.
<_gAri-> hm I do not need a patch associated with one commit, I need a patch that consists of apparmor for example
<smb_tp> _gAri-, And git-format-patch -o <dir> "<from id>..<to id>" will write individual patches to the dir you give. E.g. "git-format-patch -o .. Ubuntu-2.6.24-21.40..HEAD" will write all patches since the commit tagged as that release...
<_gAri-> any way to achieve that?
<mjg59> _gAri-: No
<mjg59> There isn't "an apparmor patch". There's a series of commits that result in apparmor in the Ubuntu kernel being in its current form.
<smb_tp> _gAri-, No, mjg59 is right. You will have to search for "apparmor" in the commit msgs and gather yourself
<pwnguin> a simple grep of git log should do the trick
<maks> apparmor is not of much use anyway
<hyperair> hello there. does anybody notice that the 2.6.24-21 kernel for hardy doesn't seem to work with bluetooth?
<hyperair> i'm using a lenovo y410 with integrated broadcom bluetooth
<hyperair> lsusb doesn't show anything when press the bluetooth button
<hyperair> Fn+F6
<adamwood> hyperair: is this new with the -21 kernel?
<hyperair> yeah
<hyperair> with the -20 kernel it works
<hyperair> adamwood, ^
<adamwood> hyperair: is it similar to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/90955 
<hyperair> nope
<hyperair> nothing appears in the acpid log
<adamwood> hyperair: I'll have to get my bluetooth adapter out and see if it still works. Can you file a new bug in launchpad for this and attach your logs?
<hyperair> what logs?
<hyperair> my logs don't show _anything_ related
<hyperair> nothing changes
<hyperair> there's just no response
<hyperair> and lsusb doesn't show anything
<hyperair> what kernel modules are involved?
<adamwood> hyperair: There is a list of logs that are useful for bug reports here - https://wiki.ubuntu.com/KernelTeamBugPolicies
<adamwood> hyperair: typing lsmod will tell you which modules you are using
<hyperair> yeah but which are the bluetooth modules
<hyperair> adamwood, ^
<hyperair> need i do lspci in this case?
<hyperair> bluetooth stuff goes in usb don't they?
<adamwood> hyperair: they can also be pcmcia I think.
<hyperair> oh
<hyperair> well mine appears in lsusb when in -20
<hyperair> as if it is suddenly plugged into a usb slot
<adamwood> hyperair: for usb I think the hci_usb.ko module is a core module
<hyperair> socket*
<hyperair> adamwood, is there anything in the kernel that controls the Fn keys?
<hyperair> there isn't any dmesg log entries when pressing the button
<hyperair> and lsusb doesn't work either
<adamwood> hyperair: as far as I know they act like most other keys but maybe some laptops work differently. I'm pretty sure there isn't an "event" that tells the kernel to load the modules that can be caused by pressing the keys
<hyperair> the so-called "event" is the same event as plugging in an external bluetooth module
<hyperair> you get the whole lot of dmesg initialization messaegs
<hyperair> *messages
<adamwood> hyperair: Some laptop FN keys can start and stop power getting to a device which makes it look to the kernel like it's being plugged in or out
<hyperair> yeah that's probably how it's done
<adamwood> hyperair: yeah, are you seeing anything in dmesg?
<hyperair> nope
<hyperair> not at all
<hyperair> [  577.021928] usb 7-4: new high speed USB device using ehci_hcd and address 4
<hyperair> [  577.053077] usb 7-4: configuration #1 chosen from 1 choice
<hyperair> [  577.053458] uvcvideo: Found UVC 1.00 device USB 2.0 Camera (04f2:b008)
<hyperair> this is what happens when i do the Fn+Esc (turn on/off webcam)
<hyperair> [  584.033429] usb 7-4: USB disconnect, address 4 <-- this s what happens when it's turned off
<hyperair> similar stuff happens with bluetooth in -20
<adamwood> hyperair: can you boot a -20 kernel and check which module is being loaded?
<hyperair> mm
<hyperair> oka
<hyperair> i'll take al ook
<hyperair> okay i'm back
<hyperair> this time in -20
<adamwood> welcome back
<hyperair> [  162.144186] usb 1-2: new full speed USB device using uhci_hcd and address 2
<hyperair> [  162.160429] usb 1-2: configuration #1 chosen from 1 choice
<hyperair> [  162.293854] Bluetooth: HCI USB driver ver 2.9
<hyperair> [  162.295278] usbcore: registered new interface driver hci_usb
<hyperair> bluetooth              61156  7 hci_usb,rfcomm,l2cap
<hyperair> lsmod said that
<hyperair> lsmod | grep blue
<adamwood> hyperair: try lsmod | grep bcm
<hyperair> nothing
<adamwood> my broadcom bluetooth device uses bcm203x module
<hyperair> is it?
<hyperair> ah well
<hyperair> can you modinfo hci_usb?
<adamwood> hyperair: yours could be different
<hyperair> it seems mine is 2.9
<adamwood> hyperair: I think you need to file a launchpad bug with all the information because I don't think we can fix this quickly
<hyperair> okay
<hyperair> file against what package?
<hyperair> adamwood, could you try running modinfo hci_usb and see if what that tells you?
<hyperair> s/if//
<adamwood> hyperair: version 2.9 - but that doesn't mean much
<adamwood> hyperair: as for the package file it against Linux (ubuntu hardy). I think....
<hyperair> okay
<hyperair> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/259151
<hyperair> oh damn he went
<sander_m> Hi all. Does the 8.04 Live CD kernel have support for LVM? I'm trying to acess the LVM volumes on my hard drives using the Live CD but I can't make it go. It doesn't find the device maper kernel module
<smb_tp> sander_m, I cannot really speak about the CD. If "sudo modprobe dm-mod " fails it might have been thrown away to save space...
<sander_m> It fails....
<sander_m> :-(
<smb_tp> sander_m, This is normally part of the linux-image package. I wonder if you can apt-get that on the live system...
<sander_m> Yeah, i works :-)
<smb_tp> sander_m, Then you only have to apt-get lvm2 and might be happy. :)
<sander_m> Did that already and found out that the mapper was missing. I can access my LVM now :-)
<chris_goe> _ruben: re: CONFIG_MD_RAID10, a bit late, but: thanks, I shall use a different kernel then
<chris_goe> I think I've installed jeos, and CONFIG_MD_RAID10 was not enabled.
<sander_m> Do you guys also happen to know about making mdadm find existing devices on a Live CD? I have a working mdadm.conf but mdadm says it can't find any devices
#ubuntu-kernel 2008-08-19
<VampyreDragon> Good Evening
<amitk> morning pgraner 
<pgraner> amitk: good morning. I see you made it back ok
<amitk> pgraner: yeah... wasn't too bad on the way back
<pgraner> amitk: cool. 
* BenC changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.26-5.14 (based on 2.6.26 final) |  Latest news: Please test last-good-boot, now in intrepid (grub/module-init-tools) | Next meeting: Aug 19, 16:00 UTC | Kernel Team machine: http://kernel.ubuntu.com
<nir> join #ubuntu-helpteam
<nir> hi
<BenC> amitk, smb_tp, cking, rtg: ping a ling
<smb_tp> BenC, There I am
<cking> BenC, me too
<rtg> BenC: dude
 * zul lurks
<BenC> sweet
<amitk> BenC: ping
<cr3> hey dudes, I'll be joining today
<BenC> ogasawara, slangasek: alive?
<slangasek> hi
 * ogasawara waves
<smb_tp> cr3, hey dude :)
<BenC> The gangs all here
<zul> hi cr3
<BenC> Call the meeting to order then
<BenC> Primary agenda for today, which we will dive right into, is whether we should start the move to 2.6.27 for intrepid
<cr3> smb_tp: yo mama!
<BenC> If we do it, it has to start now
<zul> BenC: that would be nice 
<BenC> Luckily, I've been maintaining a synced 2.6.27 tree that is pretty much a drop in replacement for 2.6.26
<BenC> so the "doing it" part is pretty much "done"
<smb_tp> As you said the volume of new stuff went down, so the main window might be over
<BenC> Other than the upload
<cking> I think the benefits (additional drivers, etc) outweigh the risks.
<BenC> The drawbacks we face, and have to decide whether it is worth the effort are:
<BenC> 1) 2.6.27 timeline may leave us with a pre-released kernel at intrepid release time
<BenC> 2) The possibility that the kernel will be less stable due to it being so fresh (even if it is final 2.6.27 at intrepid release)
<amitk> BenC: bugs(2.6.26 + backport of alsa+wireless) > bugs(2.6.27-rcX)
<BenC> As cking and amitk have pointed out, we are already considering moving to a newer wireless and alsa stack in 2.6.26, which we would get for free moving to 2.6.27
<rtg> amitk: I'm beginning to become convinced that backporting the wireless pile is not feasible.
<BenC> One of the main reasons for alsa and wireless is newer device support that isn't easy to backport in bits
<slangasek> and if the timeline leaves us with a pre-release at intrepid release, is the intent that it be updated to 2.6.27 release in SRU?
<BenC> slangasek: yes
<BenC> slangasek: if we are left with -rc at release, the amount of delta to final wont be much
<BenC> slangasek: so we should be able to evaluate every commit that will be there
<rtg> slangasek: I also think we (the kernel team) should follow the stable tree updates until upstream stops maintaining it.
<slangasek> that's not an answer I like very much, just because SRUs take time away from working on the next dev release
<BenC> slangasek: hardy SRU's are already taking up time, and we didn't do this for hardy
<slangasek> for an LTS it's understandable that there are going to be SRUs
<slangasek> for intrepid, which isn't an SRU, I think that's spreading ourselves rather thin
<BenC> slangasek: I don't think it will incur a long period of overhead...just a one shot deal
<slangasek> er, isn't an LTS
<BenC> slangasek: and because we are on a continuous move, we'll be able to get started on intrepid+1 kernel pretty quickly
<slangasek> no SRU is a "one-shot deal" for the SRU team :)
<BenC> slangasek: IOW, we wont have the huge burden of forward porting all of our patches across two versions of the kernel before starting...we'll have a kernel ready on day zero of intrepid+1 opening
<BenC> our work on intrepid+1 wont really start until after UDS, so we have that time frame
<BenC> slangasek: we usually have a month or so of SRU's for the kernel, even on non-LTS...do you think this one would incur more overhead than usual?
<BenC> (and note, most of those SRU's are lum/lbm work for supporting newer drivers, which will be moot because of the move to 2.6.27)
<slangasek> well, my work on intrepid+1 has to start significantly earlier than UDS in order to get the archive opened, so having to spend additional time on SRUs would be resource contention :)
<BenC> slangasek: plus we have to consider how much work it will be for us if we stick to 2.6.26
<slangasek> right, that's fair
<smb_tp> It also depends on the policy. If it is agreed to follow the stable kernel updates it is less overhad to process...
<amitk> it would also help to move kerneloops package to default install if we decide to go with 2.6.27 to help upstream bug identification
<BenC> amitk: sounds like a volunteer has stepped in to do that ;)
<slangasek> OTOH, it also seems to imply that the kernel is going to be undergoing significant changes well past FeatureFreeze?
<amitk> BenC: ack
<slangasek> which can have a destabilizing effect on bits of userspace, as things are deprecated etc
<zul> I guess from the server team perspective there is additonal features that we want for the virtualization stuff that we do (xen64 and more kvm features)
<BenC> slangasek: well, the kernel updates past feature freeze will be limited to bug fixing by upstream's process
<slangasek> ok
 * soren agrees with zul and drools over mmu notifiers
<BenC> zul: xen64 is in .27?
<slangasek> you seem to have addressed all the objections I can think of, then
<amitk> slangasek: things don't really get deprecated in -rc6/rc7, it is only bug fixing
<zul> BenC: yep
<BenC> another reason to add to the list, thanks
<BenC> slangasek: I've been watching .27 tree since it opened, and the churn has already dropped to bug fixing only
<zul> also so we dont have to carry a different flavour for redhat's xen64 patchset
<slangasek> I'd appreciate it if this plan can be floated by more people than just me (i.e., cjwatson/Keybuk) before we're committed to it
<BenC> slangasek: I'll post the summary of this discussion and our reasoning to -devel to get feedback
<BenC> slangasek: If we do it, I'd like to hit next Alpha
<slangasek> given that next alpha is after FF, I agree :)
<BenC> when is next alpha?
<BenC> two weeks from thu?
<slangasek> Sep 
<slangasek> so, yes
<BenC> If we can commit to this by next week, same time, we should be good then
<BenC> Ok, so action: Me: post summary for discussion on ubuntu-devel list
<BenC> Will do that today
<BenC> That's the only topic I had formally set for this
<BenC> slangasek, zul, soren: Thanks for input
<zul> np
<smb_tp> Ok, then we might discuss quickly about the -security fixes
<BenC> Anyone have anything they want to bring up now?
<BenC> smb_tp: Ok, podium's yours then :)
<smb_tp> It seems quity urgent for at least Gutsy to have something out
<cr3> BenC: I would like to mention that all daily iso images for ubuntu (alternate), kubuntu, mythbuntu, xubuntu, ubuntu-server are being tested
<smb_tp> I checked those asn fixes upstream and they disagree how to fix
<smb_tp> One is fixed by ULONG to UINT
<slangasek> BenC: n/p, thanks for the invite :)
<cr3> BenC: this is all done automatically, so I would like to take this opportunity to ask whether the kernel team might have special requests for tests to run. I'll be integrating ltp and autotest, but I'm wondering what might be your priorities
<smb_tp> the other (better as I guess) by making size to be size_t
<BenC> cr3: excellent!
<BenC> cr3: let's let smb finish this topic, and we'll open to that discussion
<BenC> smb_tp: Ok...is it easy to cherry pick the upstream fixes?
<smb_tp> Ok, quite simple, yes. And if upstream is happy with that.
<BenC> smb_tp: Ok, can you resubmit the upstream versions to kernel-team for ACK?
<smb_tp> ASAP
<BenC> I don't see a problem with ACK'ing them, but just to keep the process rolling...
<BenC> smb_tp: thanks
<BenC> cr3: Ok, on to your topic
<BenC> cr3: what are you currently running as testing right now?
<cr3> BenC: so, I would like to know what the kernel team would find most urgen, preferably in order of priority, to test in my automated suite
<cr3> BenC: it's rather pathetic right now, I'm simply making sure that the image installs and then making sure that a few processes relating to specific packages are running
<ogasawara> cr3: can you refresh my memory what specific kernel tests autotest provides?
<rtg> cr3: device support, virtualization issues, tests that focus on kernel stuff.
<cr3> ogasawara: I don't recall, sorry
<cr3> rtg: for device support, I have hardware to help me automate audio testing but it still requires a bit of work, I have also thought of a way to automate webcam testing and I need to perform some exploration for modem testing.
<cking> cr3: autotest covers ~
<cr3> rtg: for those devices and potentially other devices, what might be your priorities?
<cking> cr3: try again..  ltp covers 3000+ tests, fs, memory, scheduler, disk I/O, networks, syscalls 
<rtg> cr3: disk, wireless, video
<BenC> cr3: a check for /proc/asound/card0 existing
<cr3> BenC: noted
<BenC> cr3: checking that there is an interface for every PCI device that is of network class
<amitk> cr3: how many machines and what kinds do you test on?
<cking> cr3: maybe consider dbench, aio-stress, aio-cp, hackbench, vmmstress, kernbench
<BenC> cking: one thing we have to remember is "daily testing" and the time it takes to run tests :)
<rtg> cr3: are you doing anything with lvm and/or RAID stuff?
<BenC> cr3: is this geared at testing the dist, or specific hardware?
<cking> BenC: true.. 
<cr3> amitk: I have about 100 machines ranging from laptops, desktops, servers and a few thin clients I'm not testing very well
<cking> cr3: How much time does the current testing take?
<cr3> amitk: the automated tests right now are very poor, the most relevant being simply testing the installation. however, I'm now in a position to add more tests since the whole process is completely automated so I get test results when I come in the office in the morning :)
<rtg> cr3: wow, you just about need a test profile for each machine 'cause some of the tests aren't relevant.
<cking> cr3: I will send you some info from OLS on testing that I may be useful. 
<cr3> cking: I'm reluctant to test the hardware with benchmark tools rather than the compatibility of ubuntu with the hardware. what do you think is the particular relevance of benchmark tools?
<amitk> cr3: if you can simultaneously test on all of them, then I'd like to know if every PCI and USB device has a driver associate with it.
<cr3> rtg: nothing with lvm or raid right now, but noted
<smb_tp> cr3, benchmarks usually are doing some stress test
<rtg> cr3: per amitk's suggestion, you should definitely note unsupported devices.
<cr3> BenC: now that certification is under QA, the tests are geared towards both hardware and software. basically, everything :)
<smb_tp> cr3, and some problems show up on procesing high volumes of traffic network or storage
<BenC> cr3: Ok...just wanted to make sure the comments I was making fell under the scope you were working toward :)
<cr3> cking: current testing takes about the time of installation, so about 20 minutes. So, I get test results between 20 and 1h20 minutes after a new ISO images is made available on cdimage.ubuntu.com
<cr3> rtg: the relevance of some tests is currently detected on the machine itself. so, if hal detects that there's an audio controller, then the audio tests are run
<rtg> cr3: makes sense
<cr3> rtg: however, this doesn't always work. for example, there might be two network controllers in a machine but only one is detected
<cr3> rtg: so, I will be introducing the concept of profiles but I have no timeline for this
<cking> cr3: It would be interesting to see how much coverage these tests actually do on the entire kernel - I believe that LTP only covers a few percent of the kernel
<cr3> smb_tp: true, but there's a difference between running a cpuburn and compiling the kernel with num_processors + 1 processes. I think the former is irrelevant because it only tests the hardware whereas the latter is relevant because it tests smp
<BenC> Ok. I say we take this up more in depth over email...sounds like we have some good ideas, and cr3 is probably going to get swamped :)
<cr3> cking: I think ltp in combination with autotest and lsb might cover a good portion of the kernel
<smb_tp> cr3, I would rather think of iobench or netbench or how they are named
<cr3> smb_tp: noted, I actually used to have those as part of my suite, but I removed them eventually because I figured the provided little bang for the buck: some of these benchmarks take a long time to run which delays test results
<cr3> smb_tp: one solution might be to dispatch test results incrementally, instead of in a batch, but there are no real plans for this yet
<BenC> cr3: Are these results going to be made available for others?
<cr3> ok, I think I have plenty to work on until the meeting next week. I will try to keep you guys posted
<cr3> BenC: yes. this is currently done under the certification framework which is gradually being opened to the community since the department is now under QA
<BenC> cr3: great, thanks
<BenC> If no one else has anything to discuss....
 * BenC pauses for slow typers
<amitk> cr3: what's your annual HW upgrade budget to keep with the current fashion? ;-p
<BenC> amitk: we don't stock Mac's, so we're not into fashion ;)
<amitk> hehe
<cr3> amitk: I have no budget, this is all hardware sent to us by hardware vendors
<amitk> good to know
<cr3> amitk: if you think we should have specific devices, let me know and I could raise this issue with heno
 * BenC calls the meeting adjourned
<cr3> personally, I would rather invest my budget in testing infrastructure such as some telephone switch for testing modems
<BenC> Thanks everyone. See you next week
<cr3> thanks for all the suggestions folks, much appreciated!
<zul> BenC: where are the 2.6.27 kernels again?
<BenC> zul: http://kernel.ubuntu.com/pub/next/
<zul> thanks
<rtg> soren: bug #257569, can you think of a use case for IP filter and connection tracking in the virtual kernel?
<elmo> rtg: kernels without those options are useless to me, FWIW
<rtg> elmo, yeah, but a virtual kernel?
<elmo> rtg: well, I use the -xen kernel, but yes ;-)
<_ruben> virtualized routers arent that uncommon
<_ruben> especially for testing purposes, but also live environments
<soren> rtg: Yes. I use it all the time.
<soren> rtg: My vpn endpoint is a virtual machine.
<rtg> soren: I'm talking about the virtual flavour.
<soren> rtg: Yes...
<soren> rtg: I thought I was too.
<soren> rtg: My vpn server is a virtual machine, which would be running the virtual kernel if there were an amd64 version of it.
<rtg> soren: config.virtual:# CONFIG_NF_CT_NETLINK is not set
<soren> rtg: The only difference between the server kernel and the virtual kernel really should be device drivers.
<rtg> soren: ok, I'll enable it for -virtual.
<soren> rtg: In Intrepid?
<rtg> soren: Hardy for now. I'll make sure Intrepid is consistent
<soren> Don't worry about intrepid.
<soren> It's handled quite differently.
<rtg> soren: I want to make sure the main kernel flavors have it enabled.
<soren> rtg: all my vm's are amd64 ones, so I don't actually use the virtual kernel flavour much.
<soren> rtg: (the production ones are running hardy)
<soren> Yes, they should all have the same ip filtering capabilities.
<rtg> soren: Intrepid has connection tracking enabled for all flavours.
<soren> Right.
<perfector> will increasing the kernel shared memory improve overall performance?
<arturo-xinerama> hey everyone. I'm trying to follow online instructions to use my Microsoft Ergonomic Keyboard, but modprobe usbnek4k says no such module found
<arturo-xinerama> running kernel 2.6.24-19-generic
<arturo-xinerama> last thing I read this module was included in the 2.6.24 kernel release
<chris_goe> arturo-xinerama: you can use "/sbin/modprobe -l" to see which kernel modules are available
#ubuntu-kernel 2008-08-20
<leleobhz> http://www.mail-archive.com/ubuntu-devel-discuss@lists.ubuntu.com/msg04922.html
<leleobhz> im getting a error like this when i try to compile intrepid lattest kernel on hardy
<smb_tp> leleobhz, The quickest way would be to increase the abi number in debian/changelog
<rtg> leleobhz: the contents of the git repo aren't always buildable.
<leleobhz> i dont get it from git rtg 
<leleobhz> ive got this from packages.ubuntu
<leleobhz> 2.6.26-5.18 <--- is ok? previous is 5.17
<smb_tp> leleobhz, no abi number is the one before. so 2.6.26-6.17
<leleobhz> really
<leleobhz> smb_tp: thanks
<BenC> leleobhz: this is all documented on the kernel team wiki
<leleobhz> my X session has crashed
<leleobhz> someone can rewrite what comes after smb_tp said to me?
<smb_tp> Just BenC: leleobhz: this is all documented on the kernel team wiki
<leleobhz> oh, ok.
<BenC> smb_tp: Can you look into bug #257293 please
<BenC> smb_tp: possible SRU for hardy
<BenC> smb_tp: filed by AMD
<rtg> BenC: 2.6.27-1-server sure works better no my dual quad-core then 2.6.24-19
<BenC> rtg: No comparison to 2.6.26-5?
<rtg> BenC: no ethernet in 2.6.26-5
<smb_tp> BenC, Ok, I'll have a look
<rtg> smb_tp: you've already started on it. it was the patch from AMD on the mailing list (Monday?)
<smb_tp> rtg, I was about to look it up. But if I am on it, let me see
<smb_tp> rtg, BenC: hm ok, might the the one from the mailing list but there would probably be not difference between different ram sizes...
<smb_tp> oh reading further down it is
<smb_tp> ok, already got a test kernel for hardy for this one
<smb_tp> BenC, for Intrepid and this I got a question. Would you prefer cleanup patches from upstream to be included or rather the patch kept minimal?
<BenC> smb_tp: Your call
<smb_tp> BenC, Ok, Then I'd go for getting the cleanup patches as well. Keeps Intrepid closer to upstream
<BenC> smb_tp: Is the patch for intrepid already in 2.6.27?
<smb_tp> BenC, all patches are upstream. Wait a sec I check when it got in
<BenC> smb_tp: If so, I'd skip it for now
<smb_tp> BenC, got in between 26-rc5 and 27-rc1
<BenC> smb_tp: Ok, skip it for intrepid then
<smb_tp> BenC, Ok, will mark it as won't-fix with a comment for intrepid in bug bug
<smb_tp> Or better fix released
<BenC> smb_tp: No, we will fix it...mark it for Alpha5 as in-progress
<smb_tp> ok
<infinity> BenC: You around?
<BenC> infinity: yeah
<infinity> BenC: I assume you have your finger on the pulse of kernel bugs slightly more than I do.  Was curious if we were (A) aware of the "r8169 occasionally drops media for no good reason" bug, (B) knew that it appears to be fixed upstream in (handwavy) 2.6.26ish, and (C) had any plans to fix it in hardy? :)
<infinity> BenC: (It keeps knocking my co-lo machine off the interwebs, so I'm keen to get it fixed, but wasn't about to go hunting for patches to backport if the work had been or was being done)
<leleobhz> someone can help-me with pexpect.sendline?
<BenC> infinity: Wasn't aware, but I'd shoot an email to smb to see if he can look at an SRU for hardy
<smb_tp> infinity, Is that the stock kernel driver or from the backports-modules? Quite a few drivers there are covered by compat-wireless
<infinity> smb_tp: It's not wireless, it's realtek's GigE driver.
<infinity> smb_tp: And, fair point on the backports-modules.  If there's a backport fix there, I'll be happy.  Didn't think to look.
<smb_tp> infinity, Oh, sorry then r# drivers always make me think of wireless
<smb_tp> infinity, Not sure if there is something, but if you drop me an email, so I don't forget...
<infinity> smb_tp: Now that I know who to bug, I'll bring it up with you when I have more time.
<infinity> smb_tp: (Or, at least mail you when I have the time to lay down more coherent thought)
<smb_tp> infinity, ok, cool
<soren> I have a server that seems to not want to boot 2.6.24-19-server. It's currently running 2.6.24-17-server. Are there any known regressions in 2.6.24-19? It's a remote server, so I can't see any error messages that I can use to search on launchpad.
#ubuntu-kernel 2008-08-21
<smb_tp> soren, Not that one immediatly comes to me. Since that is remote, might it also be that there is no network?
<soren> smb_tp: No, it never comes up. I've checked the logs afterwards (I can boot it up in a special rescue mode).
<soren> Actually, I tried booting it with kvm from the special rescue mode, and I got a panic in create_proc_entry, IIRC. I really need that machine to be up, so I quickly pointed lilo at the old kernel and got it running again.
 * soren considers giving 2.6.21 a chance
<soren> Er..
<soren> 2.6.24-21, of course.
 * soren does that. It's late at night, anyway.
<smb_tp> soren, Ok, proc might be something to look. I scanned over the changes and did not catch something immediately
<soren> smb_tp: No, 2.6.24-21 doesn't love me either.
<smb_tp> soren, too bad. :( If you could find out where it hangs, later of course. For the moment you seem to be stuck with -17
<soren> smb_tp: http://people.ubuntu.com/~soren/bootfail.png
<soren> smb_tp: Anything you want me to try before I go back to -17?
<smb_tp> soren, no thanks. I take that and dig
<soren> Lovely, thanks.
<soren> Quite a novel use of kvm there :)
<smb_tp> soren, yep. as long as the bug persists with virtual hw as well. hm, could it also create memory dumps... :)
<soren> Sure, if that would be helpful.
<soren> I can't imagine why it won't boot, though. It can't possibly be hardware related if it fails in kvm, too.
<smb_tp> soren, Not immediatly but I could keep this in mind. Havn't used crash on x86 yet
<smb_tp> soren, this atm function is defined in net/atm/clip.c so it sound a bit like something in network. but no change in that file, as far as I can see on a quick look
<soren> I'm a bit afraid it might be an initramfs thing..
<smb_tp> soren, how that?
<soren> Sorry, I was half talking about something else. The -17 kernel won't boot now, either.
<smb_tp> soren, no prob with that. but that is really strange. 
<smb_tp> soren, the kernel parms have not changed?
<soren> Ah, I'm being an idiot.
<soren> I tried to use the kernel as my initramfs.. Typing is hard at this hour.
<smb_tp> soren, interesting concept. :) but true its quite early for you...
 * soren crosses fingeres
<soren> And I've got pingage. \o/
<smb_tp> soren, \o/ the old kernel or was that even a newer one?
<soren> Oh, still the old kernel.
<smb_tp> soren, ok, then I keep on looking. :)
<soren> smb_tp: Which module had the atm_clip function?
<smb_tp> soren, The atm net driver
<smb_tp> soren, oh, rather atm protocol families... 
<soren> It's listed in System.map... Does that mean it's in the kernel image and not in a module?
<soren> System.map-2.6.24-21-server:ffffffff80657170 t atm_clip_init
<smb_tp> soren, afaik yes
<smb_tp> soren, confirmed CONFIG_ATM_CLIP=y
<soren> Yeah, just found that too
<smb_tp> soren, The bad thing is that if git doesn't fool me there has been no single change in net/atm between -17 and -19
<soren> I agree.
<smb_tp> soren, The strange thing is, this atm driver is built in, so why does it only crash for you...
<soren> Yeah. It's quite weird.
<soren> And I don't have atm hardware.
<smb_tp> soren, That doesn't matter. If I read correctly its some protocol driver that gets always initialized.
<soren> Ah, yes, that's probably true.
<soren> smb_tp: If you can think of anything you think I should try, just shout.
<smb_tp> soren, I'll do, but for the moment I am clueless. Maybe it would be good to postpone it till tomorrow.
<smb_tp> soren, tomorrow for me, later for you...
<soren> YEah. I'm on my way to bed, too.
<soren> Er, no, tomorrow for me too. It's 2 AM here :)
<smb_tp> so it is tomorrow :)
<smb_tp> never mind
<soren> Oh, right :)
<smb_tp> good night then
<soren> You too :)
<smb_tp> thanks
<smb_tp> :)
<liquidbeef> Hello, I'm reading a book (LDD Linux Device Drivers) and I want to start doing some of the examples. In the book, it tells me to build my own kernel so that I can have the proper headers, but reading some other discussions, it tells me I just need the kernel headers package (check), how do I properly link to them?
<soren> Do you guys have an opinion on dkms? I'm strongly considering switching kvm to use it in Intrepid, but I have no experience with it.
<soren> Hi, guys. I was hoping you could help me out a bit.. I'm having the weirdest problem.
<soren> I have a server that refuses to boot anything but 2.6.24-17-server. If I give it a newer kernel, it fails like this: http://people.ubuntu.com/~soren/bootfail.png                 
<soren> (I got that screenshot by pointing kvm at the disks from a rescue system.)
<soren> ...so it's not hardware related (since it happens in kvm, too).
<soren> This works, though: kvm -kernel /mnt/boot/vmlinuz-2.6.24-19-server -initrd /mnt/boot/initrd.img-2.6.24-19-server -append "root=UUID=96c1a0f4-28af-4de4-a1f1-c9fe254545ed" -hda /dev/sda -hdb /dev/sdb
<soren> So the kernel and initrd image is fine.
<soren> And lilo manages to boot the -17 kernel just fine. 
<soren> ...so lilo is working, too.
<soren>  nothing changed in the atm code (see the reference in the backtrace) between -17 and -19.
<amitk_> soren: does kvm have external modules that need to be recompiled with every kernel?
<soren> It breaks at the same place for both -21 and -19.
<soren> amitk_: Yes.
<amitk_> soren: why?
<rtg> soren: dkms is the preferred solution for ABI sensitive 3rd party kernel modules.
<soren> amitk_: Well, the kernel ships some kvm modules, but half of a kvm release is kernel modules, so there are updates outside of the kernel.
<amitk_> soren: or rather, what are those modules and why are they external?
<soren> amitk_: they're replacements for the kvm modules in the kernel.
<soren> amitk_: It's mostly to avoid the pain of updating the modules in the kernel build, and since upstream provides them in a way that's easy to build out-of-tree, it makes sense to use it.
<amitk_> soren: I think this would be a wrong use of DKMS. But if the objective is to short-circuit the kernel upload dependency temporarily till kvm matures, then I guess DKMS is a good way to go about it.
<amitk_> IMHO, ofcourse :)
<soren> amitk_: Why do you think it would be a wrong use of it?
<amitk_> soren: multiple sources of kernel modules (open source ones at that!), for one. In my mind DKMS is for modules that have no hope of being merged into the kernel (fglrx, nvidia), are open but alpha-grade right now.
<soren> Each kvm release has a userspace and a kernel space part to it. This is hardly surprising, given kvm's nature. kvm's release schedule is not synced with linux's, so either we're stuck with whatever is in the kernel we're shipping, or I have to spend a day or two merging a new kvm release into our existing kernel tree every time there's a new kvm release.
<soren> virtualbox has chosen a different approach. A week doesn't go by without someone filing a new bug with the problems that arise from that approach.
<soren> dkms seems rather immune to this.
<amitk_> soren: Understood. Till kvm becomes 'feature complete' I guess it might be easier to just package it separately (using dkms).
<soren> Granted, this is a smaller problem in Intrepid where IIUIC, you've redefined what constitutes an ABI bump, but if I had switched to dkms for hardy, my life would have been much, much easier.
<soren> I can upload a kvm version that uses dkms and see how it fares. We still have a week before FF :)
<amitk_> soren: Go for it.
<soren> Any clever input on my other problem (the boot failure mentioned above)?
<amitk_> soren: did I read correctly that networking is through ATM?
<soren> No. 
<soren> There's no atm hardware at all.
<smb_tp> The crash is just reported int the atm init code
<soren> smb_tp: There more I think about this problem, the more confused I get. It makes very, very little sense.
<smb_tp> This code should be run an all machines since the driver (some sort of protocol) is built into the kernel (not a module)
<smb_tp> And suddenly (on this server) it crashesh when trying to create a proc entry
<soren> ..but only when I use lilo to boot the kernel.
<smb_tp> With grub it works?
<amitk_> soren: you changed from grub to lilo?
<soren> I haven't tried with grub, but I'm quite reluctant to just throw away this setup before I've figured out what's wrong.
<soren> amitk_: Always used lilo on that box.
<soren> It boots from RAID1.
<soren> smb_tp: I tried using kvm's own boot loader.
<smb_tp> soren, Ah ok, and that did worked better?
<soren> smb_tp: I can pass a kernel, initrd, and kernel command line to kvm, and then it boots that instead of using the on-disk boot loader.
<soren> smb_tp: Yeah, that worked fine. So the kernel and initrd are both in good shape.
<smb_tp> soren, very very odd. 
<soren> Hmm...
<soren> I think I'll try grabbing the kernel and initrd and try booting it on my laptop with lilo..
<smb_tp> Might be something to try. And otherwise we might try to gather as much msg log from working and non-working cases as we can. And try to find differences in mem allocations/addresses...
<smb_tp> soren: http://www.mail-archive.com/debian-bugs-closed@lists.debian.org/msg195980.html
<smb_tp> soren, There is also some other place that mentions lilo option "large-memory"
<soren> smb_tp: large-memory looks very interesting indeed..
<soren> smb_tp: Well, cover me with eggs and flour and bake me for forty minutes... It works!
<soren> smb_tp: I owe you one!
<smb_tp> soren, So it seems you need a lilo update... :)
<smb_tp> Or hardy might...
<soren> Yeah.
<smb_tp> soren, I am not yet at the bottom of the report, but there seem to be a relation to the initramfs size...
<soren> From -17 to -19 the initrd *just* squeezed over 8MB (8192*1024*1024 bytes)
<soren> Er..
<soren> 8192*1024 bytes, I mean.
<smb_tp> soren, :) We all get carried away by those giant nombers nowadays...
<smb_tp> soren, Ok, bottom line seems it should be fixed in 1:22.8-5
<smb_tp> While fixed is relative: debian/liloconfig: Warn about large initrd images, as not
<smb_tp>      all systems can successfully boot when the 8MB barrier is reached,
<smb_tp>      it depends a lot on system BIOS and chipset configuration.
<soren> -6 sets large-memory by default, it seems.
<soren> Well, it puts "large-memory" into newly generated lilo.conf's by default.
<smb_tp> Yes, that seems to be the only change there (beside of a new email address...
<smb_tp> Well anyways. You can boot our shiny new (well almost) kernels again. :)
<smb_tp> ... and I should remember panics near net init are also near ramdisk init...
<soren> I can. I'm very happy!
<smb_tp> Nice to be of service :)
 * smb_tp goes and brews some coffee...
 * soren too
<fbond> Hi, I'm trying to sort out some inconsistent reports regarding Ubuntu kernels on VIA C3 CPUs.
<fbond> This is all about support for CMOV, as I understand things.
<fbond> I've got one user trying to use 8.04 Server Edition on a C3 and is getting "This kernel requires the following features not present on the CPU: cmov
<fbond> Unable to boot - please use a kernel appropriate for your CPU."
<fbond> (Or similar)
<fbond> He gets this message on the first reboot *after* installation.
<fbond> Then I hear from another user (discussion at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/254453) that 8.04 server edition works fine on his C3, which claims to be a Samuel 2 (and therefore shouldn't support CMOV).
<fbond> So here are the choices:
<rtg> fbond: the actual requirement is PAE.
<fbond> PAE?
<rtg> physical address extension support in the page table  mechanism
<rtg> its also a known problem.
<fbond> rtg: Known in intrepid, you mean?
<rtg> or rather, the issue that its not detected at install time is known.
<rtg> dunno about Intrepid, but probably.
<fbond> So does 8.04 SE install the -server kernel?
<fbond> Maybe more pertinent: is the problem specific to the -server kernel (I had been assuming it is)?
<rtg> fbond: I'm unfamiliar with 'SE', but the issue is specific to the server kernel.
<fbond> rtg: Okay, that's what I thought.
<fbond> SE = Server Edition
<rtg> fbond: ah. should have guessed
<fbond> I have one user claiming that SE installed -generic, and another is having this issue with SE, so I assume he somehow got -server.
<fbond> Just trying to figure out what the heck happened.
<rtg> fbond: -generic should work fine. it supports 586 and higher
<fbond> rtg: Yeah, I know :)
<fbond> Who would know the server installatino process well enough to tell me how one could get a different kernel in different install runs?
<rtg> fbond: you could look on the server CD and see  for sure, but I don't think it has the generic kernel.
<fbond> rtg: Thanks for your help.
<rtg> fbond: I think one of the real problems is that the server CD boots the generic kernel, but installs the server kernel.
<fbond> I think one user is using the "server" isolinux boot target on a Desktop CD, or something.
<fbond> rtg: Yes, that is related to the problem the user that actually used the Server Edition CD is having.
<fbond> Oh, that boot target doesn't exist anymore...
<rtg> fbond: you can use the alternate installer to install a command line only -generic kernel for use on appliances (such as the VIA C3)
<fbond> rtg: Yep.  In fact, I think the user that reports SE works on his C3 really just did that.
<fbond> rtg: So the issue at hand is not related to CMOV, though?
<rtg> not as far as I know. I'm not really sure what CMOV is.
<fbond> There are some C3s that support CMOV.  Would those C3's still not support -server due to the PAE requirement?
<fbond> rtg: There's a lot of confusing information out there.
<rtg> fbond: I know for a fact the VIA C3 doesn't support PAE, which is a requirement of the server kernel.
<rtg> fbond: New P6 OpCodes: CMOV (conditional move)
<mjg59> CMOV is a P6 opcode, not a (required) i686 one
<mjg59> But everything that supports PAE should support cmov
<fbond> mjg59: So ... which kernel options determine PAE/CMOV requirements for a given kernel build?
<mjg59> PAE will be required if CONFIG_HIGHMEM64G is set
<fbond> Okay.  Is CONFIG_M586/CONFIG_M686 relevant?
<mjg59> If the kernel's not build with i586 or C3 support, then it'll probably end up requiring cmov
<mjg59> s/build/built/
<fbond> mjg59: I've seen in the past reports that gcc is buggy and uses CMOV when compiling for 686 (despite the fact that it is an optional instruction).  Is that the source of that dependency?
<fbond> Sorry for all of the questions :)
<fbond> I'm going to document all of this somewhere obvious so that other people can avoid spending a lot of time hunting this info down.
<mjg59> fbond: cmov is about the only useful bit of the i686 instruction set in most cases
<mjg59> So yeah, gcc uses it. The kernel build system is smart enough not to do that if you've asked it to support a CPU that doesn't have cmov.
<fbond> mjg59: Would you consider this a bug in gcc?
<mjg59> fbond: Arguably, but it's an argument that occured a long time ago and it's not changing now
<fbond> mjg59: Okay, I can settle with that.
<fbond> Thanks!
<zul> BenC: any reason why CONFIG_XEN is not turned on for the generic kernels?
<BenC> I think because it wont turn on unless we enable 64-bit DMA which does a lot of other weird crap
<BenC> disables some drivers in fact (legacy drivers, but drivers we always had in generic kernels)
<laga> BenC: did you have a chance to review aufs? or are you watching for me to submit that minor fix for the config?
#ubuntu-kernel 2008-08-22
<Wellark> hi! is the new hso-driver included in the intrepid kernels?
<Wellark> http://www.gossamer-threads.com/lists/linux/kernel/919938?page=last
<cking> Wellark: the hso-driver is not in the current intrepid kernel source
<Wellark> cking: is it going to be included?
<Wellark> I'm working on network-manager and there are devices that need that driver
<amitk_> Wellark: we are still contemplating if Ubuntu will carry 2.6.27 for intrepid. If that happens, hso is already there.
<amitk_> currently we are at 2.6.26, but we have a 2.6.27-rc tree called ubuntu-next available for testing if you need.
<Wellark> but if you decide to stick with .26 will the hso-driver be included?
<Wellark> or is it too early to tell?
<amitk_> Wellark: it could be backported if it is a single driver. Wait another week to check if we make the move (probably will). Otherwise ping us again.
<Wellark> ok. great!
<tjaalton> does ubuntu-next work with DKMS/nvidia?
<tjaalton> apparently it should
<tjaalton> wow, my laptop stays suspended with .27-rc3
<tjaalton> unlike with .26 where it resumes right away
<amitk_> tjaalton: looks like we have another supported for 2.6.27 :)
<amitk_> *supporter
<Wellark> what's the main concern about .27? not enough testing?
<amitk_> Wellark: that fact that .27 will probably get released _very_ close to our freeze
<Wellark> just send Linus an email.. :P
<amitk_> :D
<tjaalton> amitk: indeed :)
<TommyBJ> Will the kernel for intrepid be .27 or .26 ? 
<_ruben> not decided yet
<TommyBJ> Aha. When is this decision due?
<_ruben> within a week i think
<TommyBJ> Ok. Thanks :)
<Wellark> just add it to topic already :)
<TommyBJ> :>
<Edulix> hello
<Edulix> anyone knows something if similar to this: http://www.bitwizard.nl/remote_devices/ is being worked on nowadays? :P
<Edulix> for webcams specifically
<Edulix> uhm I should probably better ask in ##kernel
<BenC> So far I have not seen one Nay on 2.6.27 for intrepid
* BenC changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.26-5.14 (based on 2.6.26 final) |  Latest news: Possibly moving to 2.6.27 kernel for Intrepid/8.10. Decision within a week. | Next meeting: Aug 19, 16:00 UTC | Kernel Team machine: http://kernel.ubuntu.com
<zul> rtg: those xen patches are targeted for 2.6.27 assuming that it goes into intrepid
<zul> BenC: only one?
<BenC> zul: I've seen none
<rtg> BenC: well, you know I'm in favor 'cause I'm thinking about how to get 2.6.27 into Hardy.
<laga> BenC: did you have a change to review aufs?
<smb_tp> While I am not so sure about 2.6.27 in Hardy, I think it a good ideao for Intrepid
<BenC> laga: Yeah, going to sync it
<laga> BenC: using my patch or from upstream?
<zul> rtg: it would make life so much easier for somethings
<BenC> laga: yours
<laga> yay
<BenC> I guess now's a good time to install 2.6.27 on my laptop
<rtg> BenC: I'm test building -rc4. Shall I push the rebase if it compiles?
<BenC> rtg: I've already rebased it locally and pushed
<rtg> BenC: I must have just missed it.
<BenC> Forgot to push the -rc4 tag, so coming
<BenC> rtg, smb_tp, cking, amitk: I think I'm going to assume that 2.6.27 will be going into intrepid and start preparing a package for upload
<rtg> BenC: works for me.
<cking> BenC: ditto
<smb_tp> BenC, good for me too
<poningru> hey quick question, how can I have a particular upstream driver updated?
<poningru> namely madwifi
<poningru> err as in updated in linux-restricted-modules
<BenC> crazy...BSD alone is not GPL compatible to the kernel
<amitk> BenC: \0/
<poningru> the latest madwifi supports a class of netbooks that a lot of people would like to convert to ubuntu
<BenC> poningru: madwifi is the latest upstream release
<poningru> in hardy?
<BenC> yes
<BenC> we aren't syncing to svn repo
<amitk> poningru: you probably need something from the madwifi trunk, not the release
<poningru> yeah ofcourse
<poningru> amitk, no iirc the latest from stable is the working one
<poningru> its aspire one btw
<poningru> checking
<BenC> poningru: I'd test 2.6.27 and see if the ath5k/ath9k driver works for you
<BenC> we are likely ditching madwifi to support those drivers instead
<poningru> SWEET
<poningru> cause I am pretty sure ath9k works
<rtg> poningru: you must have an AR2425.
<poningru> checking
<poningru> damn it you are right madwifi stable is not .10.5.6
<poningru> thats the one that works
<poningru> its called the ar5006EG
<BenC> that would be ath5k, wouldn't it?
<rtg> BenC: it might be 9k. Luis said that it supported one of the 5k chipsets.
<rtg> ar5006EG is an AR2425.
<rtg> they have some confusing model numbers
<poningru> indeed
<rtg> I should be getting one today or Monday, so I'll know soon for sure.
<poningru> aspire one?
<poningru> or the wifi card?
<rtg> no, an AR2425
<rtg> wifi card
<poningru> sigh I guess I will stick to my dkms solution for now
<poningru> yeah I thought the .10.5 was the stable madwifi
<BenC> poningru: not willing to try the 2.6.27 kernel packages?
<poningru> well not for distribution
<poningru> BenC, creating a no hassle ubuntu install for these netbooks
<poningru> but yeah going to test out intrepid one of these days
<poningru> and I guess get a .27 kernel for it
<poningru> wait is intrepid going to have a .27 by default?
<poningru> or .26
<rtg> poningru: we are currently testing .27 for Intrepid
<poningru> oh sweet
<poningru> rc3 just came out right?
 * poningru checks kt
<rtg> poningru: -rc4
<poningru> 0.0
<poningru> I shall test and file bugs! but first a ppa
<BenC> time to reboot...
<BenC> well...everything seems to be functioning well
<smb_tp> ... famous last words? ;-)
 * BenC goes to lunch
#ubuntu-kernel 2008-08-23
<pwnguin> is there anything left of apparmor upstream?
#ubuntu-kernel 2008-08-24
<zul> BenC: thanks for 2.6.27 
<juanpaul> hello, i'm having trouble to compile kernel on ubuntu. I've downloaded the kernel source via git, but, where i can download the 'linux-ubuntu-modules-<version>' via git?
<juanpaul> no one?
<juanpaul> solved: download git://kernel.ubuntu.com/ubuntu/ubuntu-hardy-lum.git or apt-get source linux-ubuntu-modules-<version>
<hyperair_> the iwl4965 driver in linux-backports-modules-2.6.24-21-generic causes a kernel panic when rmmod-ing. so i can't hibernate, suspend, or shutdown without a kernel panic.
<hyperair_> anyone notice that?
<pjwaffle> Hi!
<pjwaffle> I want to compile latest (trunk) kernels for ubuntu... Would this be useful for ubuntu?
<Ng> what's the best way to bring bugs in a -proposed kernel to the kernel team's attention?
<Ng> I don't want to just start subscribing people randomly ;)
<Ng> (wrt bug 260664 - reproduced on a thinkpad X41)
<BenC> Ng: Best way is probably kernel-team@ or ogasawara
<mo0n_sniper> so will it be 2.6.26 or 2.6.27?
* BenC changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.27-1.2 (based on 2.6.27-rc4) |  Latest news: Moved to 2.6.27 kernel for Intrepid/8.10. | Next meeting: Aug 26, 16:00 UTC | Kernel Team machine: http://kernel.ubuntu.com
<mo0n_sniper> that's good....I hope
<Iulian> Yay!
<ilmari> it means the wifi on the asus eee 701 will work out of the box
<Ng> BenC: ok thanks
<leleobhz> compiling kernel 2.6.26 on hardy...
<leleobhz> II: Checking for changes to ABI... HASH : reserve_ibft_region                      : 0xd5bca5ec => 0x2d09b21a HASH : dump_stack                               : 0xb4e32191 => 0x6b2dc060
<leleobhz> EE: 2 symbols changed hash and weren't ignored
<leleobhz> what can be?
<ogasawara> Ng: wrt bug 260664 - https://lists.ubuntu.com/archives/kernel-team/2008-August/002995.html
<ogasawara> Ng: I wasn't sure if you are subscribed to the ml
<pwnguin> ogasawara: is something like this too late for intrepid? https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/215604 
<leleobhz> someone can explain to me how ABI works with kernel?
<leleobhz> II: Checking modules for generic...previous or current modules file missing!                                                                                 
<leleobhz> make: ** [module-check-generic] Erro 1                                                                                                                       
<leleobhz> why this occour?
#ubuntu-kernel 2009-08-17
<AnAnt> Hello, in alpha3 PC beep was working on my laptop, yet in alpha4 it doesn't, is this a kernel or pulseaudio issue ?
<apw> cking, this bug seems to have come back with some comments:
<apw> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/347623
<ubot3> Malone bug 347623 in linux "Samsung q45 does not produce key-release events for Fn-Keys (patch included)" [Low,Fix committed] 
<apw> smb, this was the pad thing: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/300143
<ubot3> Malone bug 300143 in linux "tablet devices show up as non-functional joysticks" [Undecided,Fix committed] 
<cking> apw, hrm.. ok, will pop it on my todo list
<apw> cking, they verified it in -proposed and reported something odd like down works fine and up is odd or something (brightness)
<cking> 80+ steps to dim the light is a little too much to ask I suppose.
<laga> apw: did you see my message about the aufs config option? i'm afraid i killed my irssi session last night :)
<apw> laga, best to repeat it now :)
<laga> apw: mythbuntu needs CONFIG_AUFS_BR_RAMFS so its diskless clients can boot properly
 * ogra wonders why 
<ogra> ltsp works fine as is 
<ogra> dont you base the mythbuntu diskless mode on ltsp anymore ? 
<laga> ogra: the xino lookup table is placed in /tmp. and if there's no ramfs support, that won't work in initramfs
<laga> ogra: i can only assume you're placing the xino elsewhere
<laga> let me restate that
<ogra> stgraber would know i think
<laga> you use some kind of temporary in-memory file system which is not ramfs AFAIK. aufs can place the xino table there
<laga> for mythbuntu-diskless, our COW branch is on NFS - and the xino table can't go there, so it falls back to /tmp, which is broken in karmic
<ogra> oh, NFS
<laga> due to that config option lacking
<ogra> how evil :P
<ogra> yeah, NFS and union mounts were never good friends, thats a good reason indeed
<apw> laga, so this is an aufs2 only issue affecting only karmic?
<laga> yes
<apw> laga, is there a bug filed?
<laga> apw: no. :)
<laga> i guess i should do that then. :)
<apw> can you get one filed for me, i'll go see why that option is off
<apw> laga, have you tested that turning this thing on actually works for you?  if so can you record that in the bug
<laga> apw: yes, it works for me
<laga> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/414738
<ubot3> Malone bug 414738 in linux "Mythbuntu-diskless needs CONFIG_AUFS_BR_RAMFS" [Undecided,New] 
<smb> apw, May I kindly remind you of bug 406419. I believe you wanted to do a correct SRU mail for that. :)
<ubot3> Malone bug 406419 in linux "Ubuntu 8.04.3 amd64 on Dell PE R610 : Front USB ports do not detect newly inserted USB device" [Medium,In progress] https://launchpad.net/bugs/406419
<apw> *burp*
<micahg> do you guys do support in here or should I send people to #ubuntu + 1?
<micahg> *people :)
<rtg> micahg, depends on what you mean by support. we're willing to discuss kernel bugs, etc.
<micahg> rtg: I had a user tell me a broadcom chipset isn't supported, I found an open bug regarding it, I'm just wondering where to send him if he can't solve it
<rtg> micahg, well, wl.ko (if thats the driver in question) is a binary blob driver, so there's not a lot we can do to fix Broadcom issues.
<micahg> so if broadcom dropped support we're stuck
<rtg> micahg, I think thats unlikely, but their support is typically directed towards monetized projects on specific platforms. they don't really seem to care otherwise.
<micahg> but the new intel drivers require the karmic kernel, right?
<rtg> micahg, the Intel drivers _are_ part of the kernel. I assume you're talking about the Xorg drivers? If so, then yes - you'll need them in order to use the KMS enabled kernel drivers.
<micahg> right, so someone trying to use an intrepid kernel with karmic will break stuff?
<rtg> micahg, yep - won't work too well with the desktop.
<ukev> hi, I've a curios problem with the usb stick subsystem of the kernel with usb pens(?) >= 8GB. Reading works fine but writing crashs after ~100-200MB with IO Error. USB drives (harddisk) works fine and the two usb sticks (8 GB and 16 GB) are working fine with other computers (osx), where can I look to locate the problem?
<micahg> ok thanks rtg
<ogasawara_> smb: re the ext4 patches, did you happen to save your patched kernels you built somewhere that I might quickly be able to point testers too?
<apw> rtg ok ... i've reconstructed your abstracted debian form against head.  i've scripted the initial split so it can be applied again to any other repo we need.  just test building it now, and then will push it for review
<ogasawara> smb: no worries if not, I can rebuild
<smb> ogasawara, Let me check. I am not sure... Brain image not complete yet. :)
<ogasawara> heh
<rtg> apw, cool
<apw> i shoved a couple of tweaks on the top the first lets you use all the targets in debian.master/rules
<apw> the second fixes the insertchanges target
<smb> ogasawara, Hm, no, it seems I got the packages removed. Sorry
<ogasawara> smb: no problem, I was just being lazy :)
<smb> ogasawara, Understandably, for the amount of time a build takes. :)
<ukev> hi, I've got a curios problem with the usb disk subsystem of the kernel with usb pen drives >= 8GB. Reading works fine but writing crashs after ~100-200MB with IO Error. USB drives (harddisk) works fine and the two pen drives (8 GB and 16 GB) are working fine with other computers (osx), where can I look to locate the issue?
<apw> rtg ok seems to build ok ... the proposed stack is here: git://kernel.ubuntu.com/apw/ubuntu-karmic.git abstracted-debian
<rtg> apw, cool. I'll have a look as soon as I get mvl-dove sorted
<apw> good luck with _that_
<rtg> apw, oh, its close. there is some mind numbing udeb crap to deal with, but everything else is working.
<apw> yay udebs ...
<bjf> rtg, sorry, should have asked my question here ...
<bjf> rtg, I just updated my karmic tree and the mvl-dove branch doesn't build, is that expected?
<rtg> bjf, ok, try the mvl-dove branch again
<apw> rtg heard any issues recently (-5/-6) with rfkill after resume?  needing an rfkill unblock
<rtg> apw, nope, but its likely wifi driver dependent (unless its the laptop driver)
<bjf> rtg, still not building, however this looks different: dpkg-architecture: warning: Specified GNU system type arm-linux-gnueabi does not match gcc system type x86_64-linux-gnu.
<rtg> bjf, how are you building?
<bjf> rtg, not with debuilld, am reading up on that now
<bjf> rtg, export $(dpkg-architecture -aarmel)
<rtg> bjf, here is the rune: debuild -eCROSS_COMPILE=arm-none-linux-gnueabi- --prepend-path=$(HOME)/proj/arm-tools/arm-2008q3/bin -b -aarmel -us -uc
<bjf> rtg, CROSS_COMPILE=arm-none-linux-gnueabi- fakeroot debian/rules binary-$1
<rtg> bjf, the key environment setting is '-aarmel'
<bjf> rtg, that is set by: export $(dpkg-architecture -aarmel) right?
<rtg> bjf, uh, dunno. 
<bjf> rtg, just ignore me
<bjf> rtg, operator error
<rtg> bjf, thats easy enough :)
<bjf> rtg, dove should be producing a uImage but seems to be producing a zImage
<rtg> bjf, hmm, you're right.
<bjf> rtg, also, I'm getting a bunch of errors/warnings after "Now running lintian..."
<rtg> bjf, they're OK, just noise 'cause I'm too lazy right now.
<bjf> rtg, np
<rtg> ogra, uploading dove right now, but it still produces a zImage.
<Nafallo> something in 2.6.31-6-generic turns my eeepc into flickerville. I would assume that has been reported already?
<rtg> Nafallo, flickerville is such a technical term :) I assume you refer to your display?
<Nafallo> hehe. yeah :-). or graphics rather.
<Nafallo> whenever something moves on the screen, the whole UNR desktop flickers
<Nafallo> I booted into ABI 5 for now :-P
<rtg> Nafallo, Is that intel graphics?
<Nafallo> yeah. let's see if I can see what lshw -C VGA says.
<Nafallo> nothing. maybe it's graphics :-)
<rtg> Nafallo, lspci ?
<Nafallo> product: Mobile 915GM/GMS/910GML Express Graphics Controller
<Nafallo> lshw -C display
<Nafallo> 00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04)
<rtg> Nafallo, as I suspected. Please start an LP bug, make sure ogasawara knows that it is a regression.
<Nafallo> oki
<Nafallo> woha! I found the report bug link for the right package!
<Nafallo> woha! I found the report bug link for the right package!
<Nafallo> took a bit :-P
<Nafallo> ubuntu-bug -p linux managed to cause OOM conditions.
<Nafallo> had to reboot.
<Nafallo> so much for following instructions ;-)
<lesshaste> hi
#ubuntu-kernel 2009-08-18
<ameno> will the vanilla kernel build configs get synced/fixed?
<amitk> jjohansen: Have you seen: pastebin.ubuntu.com/255032 ?
<apw> smb, i see that 27.31 just dropped reverting something... might want to check we didn't slurp it up someewhere
<amitk> seems like a nice reference to git: http://progit.org/book/
<smb> apw, Thanks, seems we are safe. Did not find the original patch in our trees.
<apw> smb, phew ... 
<amitk> ogra: should the bootloader be set to "flash-kernel" for dove as well?
<amitk> ... to facilitate updates?
<ogra> amitk, depends on the design NCommander develops
<ogra> which he didnt document *anywhere* 
<ogra> (grmbl)
<amitk> ogra: I assume it should be for imx51 atleast?
<ogra> yes, for imx51 we use flash-kernel for updates (not as the bootloader indeed)
<ogra> bootloader == redboot, flash-kernel is the upgrade tool for kernel and initramfs in flash
<ogra> (where flash might be mtd or SD here )
<amitk> ogra: ok, I've pushed that fix to the FSL branch (rtg, FYI). Will await your instructions for dove.
<ogra> dove uses uboot as bootloader, i'm not sure how NCommander planned to implement it
<rtg> amitk, did you change to uImage as the target (I haven't looked at all my email yet)
<ogra> https://blueprints.launchpad.net/ubuntu/+spec/mobile-karmic-marvell-desktop is the dove spec
<amitk> rtg: not yet. It requires adding the uboot-tools dependency. I'd much prefer NCommander to finish his design before making those changes.
<ogra> right
<ogra> nobody apart from him even remotely knows how the images will look like
<rtg> amitk, I think all it requires from the kernel side is uboot-mkimage.
<ogra> i asked him to document it already but seems he didnt yet, https://wiki.ubuntu.com/Specs/KarmicMarvellDesktop looks quite empty
<ogra> right, for uImage you need a dep on uboot-mkimage
<amitk> rtg: uuh, right. uboot-mkimage, not uboot-tools
<ogra> and indeed make the build process call "make uImage" instead of zImage
<ogra> i think thats a clear fact that we'll need it 
<ogra> marvell wont switch to another bootloader
<amitk> true
<ogra> i dont know how the whole rest of the bootprocess will look like though 
<ogra> theoretically we shouldnt need flash-kernel given that uboot should be able to read the kernel and initramfs binaries from disk
<rtg> ogra, will you ever need udebs for Dove? I've disabled all but the nic-modules
<ogra> we might at some point, not urgent now though
<ogra> but i think your naming of the headers wil cause probs
<ogra> http://paste.ubuntu.com/255034/ is a snippet from the livefs builder script
<ogra> can you shuffle the name a bit for them ? 
<rtg> ogra, much like linux-image-* ? I suppose.
<ogra> yeah
<ogra> well, it even looks for linux-image-2* and linux-headers-2*
 * apw waves to rtg.  i see you pulled in some of the abstraction stuff into the arm branches
<rtg> apw, its where I actually developed the proof of concept. master came last
<apw> ahh makes more sense when you think about it that way
 * rhkfin_ wonders if #403656 aka CVE-2009-2692 (incorrect proto_ops initializations) will get a fix soon... (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/413656)
<ubot3> Malone bug 413656 in linux "Local root exploit via CVE-2009-2692 (incorrect proto_ops initializations)" [Unknown,Confirmed] 
 * Nakkel wonders if anyone notices rhkfin_'s wondrings about #403656 aka CVE-2009-2692 (incorrect proto_ops initializations)
<ogra> luckily that doesnt affct 9.04 at least
<ath> really?
<ath> why?
<ogra> but #ubuntu-security would be the better place to ask about 8.10 and 8.04
<ogra> because the 9.04 kernel sets vm.mmap_min_address to 65535 via sysctl, the issue only shows up if thats not the case
<ogra> well, actually if its set to 0
<ogra> but its definately a question for #ubuntu-security more than here
<ath> cat /proc/sys/vm/mmap_min_addr
<ath> 0
<ath> Reaaallly safe
<ln-> *definitely
<ogra> well, thats not the default
<mjg59> If you've got wine or dosemu installed you'll have it at that address
 * rhkfin_ has 0 there too..
<ogra> right wine wipes that setting
 * rhkfin_ thinks it makes it an issue for 9.04 too... 
<ogra> but doesnt make it more on topic here :)
<rhkfin_> -> #ubuntu-security...
<ogra> right :)
<rtg> apw, if you're OK with the abstracted-debian branch, then I'm just gonna do it for master, then make all of the topic branches work right with rebase.
<apw> rtg am happy with it, i already implemented it for head on my abstracted-debian branch
<apw> that contains the runes to allow it be reconstructed on any master
<rtg> apw, I'd just planned on cherry-picking and squashing those 4 commits.
<apw> it might be worth squashing 2-4 and leaving 1 as a separate entiry
<apw> entity as that better lets someone implement the same on older trees
<rtg> which we are going to do (smb^^)
<apw> as the first is a 'programatic step' and 2-4 is just the delta
<apw> ie can be cherry-picked back to older debian's
<apw> but yes squash 2-4 for sure
<rtg> apw, why don't you go ahead and push those changes the way you'd like to see them
<smb> rtg, Was your comment about the branches or the security issue?
<rtg> smb, about master as well as the topic branches.
<smb> rtg, I have not followed to be honest. I know you had done some things to the karmic arm branches to make rebasing a simple rebase. But I had no time to look at what you actually did
<rtg> smb, so now that yingying has slapped you around, are you gonna backport the igb driver?
<apw> rtg i am guessing we could do the equivalent on just the branches on jaunty... ie make i safer by not modifying the master branch
<smb> rtg, If that is completely new, why not. They could use a few new numbers to be a bit more diverse
<apw> as the conversion there is the programatic step and then the patch on top
<apw> that can just as well be in the branch
<rtg> apw, why wouldn't we do Jaunty master? The rebase issues there are at least as problematic as they are for Karmic, what with the netbook and arm branches
<lesshaste> hi all
<apw> rtg we can, from a risk point of view we could choose to leave master alone but do the same trick inside the branch
<apw> it depends how risk averse we are feeling
<rtg> apw, these are build issues. I consider that to be pretty low risk, if not zero.
<apw> fair enough
<smb> apw, Likely most of it is in the buildenv, so at least it would be failing early
<apw> yeah likely so, fair enough, i am convinced
<apw> rtg shall i prepare a jaunty master delta to see how it looks?
<rtg> apw, sure
<apw> i am assuming you are handling karmic en-toto as its complex with the branches there
<apw> then i can see how easy my jaunty netbook branch rebases too
<rtg> apw, nope, just [ush the master branch changes and I'll fix the topic branches after the fact.
<apw> ok i'll squash 2-4 and push that 
<amitk> rtg: fsl-imx51 doesn't need uboot (ATM)
<amitk> only mvl-dove needs it for now
<amitk> also, fsl-imx51 will still use zImage, while mvl-dove will use uImage
<rtg> amitk, oops, wrong flavour.
<ogra> as long as yu dont switch -generic to uboot :)
<ogra> i suspect even grub2 wouldnt handle that :)
<rtg> amitk, I just slammed HEAD on the fsl-imx51 branch to drop the build-dep patch
<amitk> rtg: ack
<gonzo_> Hi! Two questions: 1. Are the kernels at http://kernel.ubuntu.com/~kernel-ppa/mainline/ built from  http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=summary
<gonzo_> 2. With the latest 2.6.31 kernels my DVB-T receiver stopped working. It seems that the modules are not built anymore. Is that known?
<NCommander> rtg, ping?
<rtg> apw, I though we were gonna squash the karmic master branch 'ARM: IMX51:' patches out of existence?
<rtg> NCommander, yo
<NCommander> rtg, I just wanted to compare notes w.r.t. to the dove kernel on the generation of the output files (I heard that the kernel packages are getting twisted to build uImages now)
<rtg> NCommander, if that is what you want, then now is the time to make the change to uImage
<NCommander> Well, I did a writeup of what I'm sorta hoping to get w.r.t. to filesystem layout in the Marvell spec (it was living on the internal wiki until earlier today: https://wiki.ubuntu.com/Specs/KarmicMarvellDesktop)
<rtg> NCommander, I'll have a look. I'm in the middle of reorganizing the dove branch, so it'll be a bit.
<NCommander> rtg, I'd appeicate your input in it 
<NCommander> oh right
<ogra> using uImage saves extra hacks and the dove cant use a zImage anyway
<NCommander> ogra, right, and then we can just update any boot script (if we use one, which I'm in favor of) as part of the postinst after the updated ramdisk is generated
<ogra> beyond that marvell will take care of the load adresses change in the kernel tree and you dont need to make the up yourself
<ogra> s/of/if/
<ogra> s/the/them/
<NCommander> ogra, load address changes?
<ogra> for mkimage you need load adresses
<NCommander> Right
<NCommander> Oh, Marvell gave us a set of addresses to use for uImage/uRamdisk?
<ogra> the kernel tree has some for uImage
<ogra> mkimage wont run without proper load address
<ogra> to create a uImage mkimage is run
<NCommander> I was using the addresses from the sheevaplug, but I much rather use a more sancationed address :-)
<NCommander> ^- ogra 
<ogra> right, make uImage will set the ones definaed by marvell
<NCommander> \o/
<ogra> *defined
<NCommander> Yay for making life easier
<ogra> thats how make uImage works
<NCommander> Ah, I didn't know there was a pre-existing target in the Marvell kernel tree to spit out a uImage
<ogra> so the only change you will need will be to initramfs-tools 
<ogra> if you even need a uInitramfs
<amitk> NCommander: the 'make uImage' target isn't just in the Marvell kernel tree. Upstream kernels also support it IIRC
<apw> rtg, we were and erm did
 * apw looks whats occured
<rtg> apw, they appear to be back in the repo
<apw> yes they do
<NCommander> amitk, that's good to know
 * apw must have the original branch here somewhere
<amitk> ogra: what command are you running?
<ogra> i run fakeroot debian/rules binary, kill that if i see it starting to build (assuming it configured) and then run make uImage 
<rtg> apw, I'm wondering if I didn't do it because of the way I rebase against origin/master.
 * ogra knows thats wrog but seemed the fastesr
<ogra> *fastest
<apw> rtg as in you think you might have undone it?
<amitk> ogra: use fakeroot debian/rules prepare-dove
<rtg> apw, right. after you pushed I likely did 'git fetch origin;git rebase origin master'. Since I still had those commits in my master branch, then I probably pushed 'em back out.
<apw> hmm perhap :/
<ogra> ogra@dove:~/kernel/mvl-dove$ fakeroot debian/rules prepare-dove
<ogra> make: *** No rule to make target `prepare-dove'.  Stop.
<amitk> ogra: the prepare target will create the debian/build dire
<ogra> hrm
<amitk> are you on the dove branch?
<apw> well i can get rid of them again in short order
<ogra> i thought so
 * ogra curses git once again
<rtg> apw, I've already done that. 
<rtg> I'll just re-push, OK ?
<apw> rtg ok then
<ogra> ogra@dove:~/kernel/mvl-dove$ git branch
<ogra> * master
<apw> absolutly
<ogra> meh
<bjf> ogra, building that way in the dove/mvl branch isn't working
<ogra> how do i have to build it then ? 
<apw> rtg do the dove and imx51 branches have my patch to allow all targets trhough?
<ogra> right, git fetch only gets me 
<ogra>  + ba9ee58...a5dde05 fsl-imx51  -> origin/fsl-imx51  (forced update)
<ogra>  + b5c2598...a436a05 master     -> origin/master  (forced update)
<bjf> ogra, you need to:debuild --no-lintian -eCROSS_COMPILE=arm-none-linux-gnueabi- --prepend-path=/home/toolchains/arm-2009q1/bin -b -aarmel -us -uc
<rtg> apw, not yet. I'm in the middle of it.
<ogra> bjf, no
<apw> ahh so prepare-dove won't work
<bjf> ogra, no?
<apw> you would need to do fakeroot debian.mvl-dove/rules prepare-dove to get it to work
<ogra> bjf, a) i dont crossbuild, b) i dont want to use debuild, amitk wants the binary from make uImage
<apw> that will be fixed shortly
<rtg> apw, master HEAD pushed. I suggest you make sure your update doesn't recreate those damn IMX51 patches.
<apw> heh yep am updating now to make sure it doesn't
<amitk> ogra: make ARCH=arm CROSS_COMPILE=arm-linux- O=`pwd`/../build/
<amitk> ogra: you'll need to create a ../build and copy the .config there first, though
<apw>  fakeroot debian.mvl-dove/rules prepare-dove 
<rtg> amitk, dove won't build out of tree yet
<apw> somthing like that ought to get it prepared in theory
<ogra> it did so last week
<amitk> ohh right, drop the O=
<ogra> the kernel i currently run is built from your mvl-dove tree
<apw> ogra, yeah but someone keeps wanting machinary changes, and they have risk of breakage
<apw> :)
 * ogra hugs apw 
<ogra> that seems to work :)
<apw> ogra, that should get fixes shortly when we rebase those trees onto the new abstracted stuff
<ogra> sure, i only care about an uImage to give feedback to amitk 
 * ogra doesnt want to touch the packaging :)
<apw> rtg on this abstracted form for jaunty... it occurs to me we are also going to want the stuff to allow us to change the source package name and the like
<rtg> apw, correct
<apw> and so i am thinking that actually i should really be looking to take the karmic machinary
<apw> and all the nice fixes therein
 * amitk steps out for a bit
<rtg> apw, agreed
<apw> good.  thats much easier (i hope)
<bjf> ogra, are you talking mvl or fsl?
<ogra> mvl
<rtg> apw, my goal is to have the packaging for all branches in all repos look mostly the same.
<apw> yeah so thats also the right thing that way
<ogra> bjf, amitk wants to know if the resulting uImage from make uImage works fine so we can enable it in the package 
<jjohansen1> amitk: no I haven't seen pastebin.ubuntu.com/255032, where did you hit it
<ogra> instead of running make zImage
<ogra> apw, hmm, still fails with "make: *** No rule to make target `include/config/auto.conf', needed by `include/config/kernel.release'.  Stop."
<bjf> ogra,ok
 * ogra just ran make oldconfig now ... seems to work
<ogra> though it used my existing /boot/config-2.6.31-0-dove apparently
<amitk> jjohansen1: just saw it randomly on my laptop (rebooted since and not seen)
<amitk> bjf: make uImage is a supported target in the kernel. If that works already, then we don't have to do postinst munging of zImage to uImage. Therefore, I asked someone who had the HW to test if the resulting kernel is bootable.
<amitk> I recall that sometimes the kernels aren't bootable (wrong addresses, perhaps)
<ogra> amitk, well, it definately worked on friday i'm currently running that uImage on my dove
<jjohansen1> amitk: hrmm okay that is a strange failure
<ogra> i just dont have the latest merges
<ogra> but i doubt they change anything wrt mkimage 
<bjf> amitk, I had been building that way before this last week and I was giving the mobile guys my uImage to test with
<amitk> ogra: but you did a manual mkimage then, right?
<bjf> amitk, that had/has been working
<ogra> amitk, no
<ogra> amitk, oh, sorry, i did 
<ogra> i used debuild and used the vmlinuz from that package 
<bjf> amitk, the issue right now is that the work that rtg and apw have been doing has "changed" things a bit
<amitk> bjf: ok, great. Then we should change rule.d/vars.armel in the mvl branch (build_image = uImage, kernel_file= arch/$(build_arch)/boot/uImage, etc.)
<bjf> amitk, yes
<rtg> amitk, don't forget the prerm, postinstall, etc scripts
<amitk> ack
<amitk> rtg: does this new debian.* world order mean that all the debian.* directories are in the master branch?
<rtg> amitk, yeah, have a look at Karmic master. There is now a debian.master
<rtg> the only thing under the debian directory is rules.
<rtg> s/thing/file/
<rtg> and some other invariant stuff
<amitk> doesn't debuild complain (about the relatively empty debian/ dir)?
<rtg> amitk, run 'fakeroot debian/rules clean' first
<amitk> rtg: I see it now. But can't _all_ the debian.* directories now live in the master branch? That way all the topic branches only muck with code.
<apw> amitk, the debian.branch is still only in the branch currently
<apw> if you do that, to change something which needs to add code and modify configs say
<apw> you would have to commit half to master, the other half to branch and then rebase the branch to get the whole
<apw> or somthing nasty like that
<rtg> amitk, I found that the packaging rules vary enough across topic branches that it was simpler to just separate them out.
<amitk> ok
<cking> **
<cking> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<cking> **
<rydberg> I have a question regarding suspend problems in 2.6.31-6-generic not present in v2.6.31-rc6
<rtg> rydberg, rfkill related?
<rydberg> Hello Tim, long time no see. I cannot say, sorry - was just wondering if these problems seem common, and thus whether I should simply wait with whistle-blowing until after karmic catches up with rc6. I guess from your answer that it is common indeed.
<rtg> rydberg, we did note some suspend issues with bluetooth. try 'sudo rfkill block all' prior to suspending.
<rtg> if you indeed have bluetooth.
<ogra> amitk, http://paste.ubuntu.com/255224/ ... lets see if it boots now :)
<rydberg> i usuall keep it off, but i will have a look anyways, thanks for the tip
<rydberg1> rtg, no dice using 'rfkill block all'. What does work so far is a pristine rc6, without ramdisk.
<rtg> rydberg1, what is your platform?
<rydberg1> its a macbook air 1,1 running karmic alpha 4 plus updates. I just noted there were updates in the karmic kernel today, I will try building those and report back
<rtg> rydberg1, its just packaging changes. I doubt it'll have any effect
<rydberg1> oh, ok
<rtg> you have ath5k wireless? 
<rydberg1> the bcm4328, which works with the bcmwl dkms package
<rtg> rydberg1, try 'sudo modprobe -r wl' before suspending.
<rydberg1> oki
<smb> apw, FYI, I pushed all repos
<apw> ack, thanks
<rydberg1> nope, still hangs with blinking cursor on suspend
<apw> you might want to boot with no_console_suspend, and then perform the suspend from VT-1 using sudo pm-suspend
<rtg> rydberg1, do you still have older Ubuntu kernels installed, like 2.6.31-5.24 ?
<rydberg1> thanks apw, ive been doing all those things, there is a distinct difference in behavior between ubuntu-2.6.31-6 and v2.6.31-rc6
<rydberg1> trying the 2.6.31-5 now
<rydberg1> same thing there, not suspending but hanging. i am happy to wait with further testing until a rc6 rebase, i am hopeful it will work
<apw> 2.6.31-6 is an -rc6 rebase?
<rydberg1> i thought it was rc5?
<apw> nope its definatly an -rc6 rebase
<rydberg1> i just read the git tree, couldnt find the rebase point but that changes things drastically. Ok, ill dig a bit more
<apw> the -rc6 kernel you are testing, is that our mainline build?
<rydberg1> its staight off linus' tree
<bjf> apw, the reading back he tested 2.6.31-5 not 2.6.31-6
<apw> $ git show `git merge-base linus/master Ubuntu-2.6.31-6.25`
<apw> commit 64f1607ffbbc772685733ea63e6f7f4183df1b16
<apw> Author: Linus Torvalds <torvalds@linux-foundation.org>
<apw> Date:   Thu Aug 13 15:43:34 2009 -0700
<apw>     Linux 2.6.31-rc6
<apw> rydberg1, can we confirm which ones of ours you have tested?
<rydberg1> i have tested the two packages 2.6.31-6-generic and 2.6.31-5-generic
<rydberg1> and i have tested the -rc6 from linus, without ramdisk
<rydberg1> the two former hangs on suspend, the latter works flawlessly, both suspend and resume
<apw> that implies the bug is in our delta, so you could consider doing a bisect between -rc6 and Ubuntu-2.6.31-6.25
<rydberg1> yep
<rydberg1> "day" means US day time, I suppose? this will take a couple of hours :-)
<apw> day ?
<rydberg1> as in bug day - im in europe
<ogra> bug days in ubuntu usually span across all timezones
<rydberg1> long working hours, then :-)
<ogra> starting at NZ moring and ending in pacific evening
<ogra> well, the ubuntu developer and bugtriager teams span across the whole world ;)
<ogra> (as well as the users reporting bugs :) )
<Q-FUNK> ogasawara: thanks for subscribing yourself to the bug :)
<rydberg1> rtg, apw: ill start off verifying the problem between 64f1607ffbbc772685733ea63e6f7f4183df1b16 and the karmic head, just to make sure its not my kernel config that makes it work
<apw> sensible idea
<rydberg1> tlsup seems to have a problem compiling here, same for you?
<ogasawara> dhillon-v10: hi!  thanks for sitting in on the meeting
<dhillon-v10> ogasawara: Hi how are you
<ogasawara> dhillon-v10: great, so you mentioned you'd be interested in helping out
<dhillon-v10> ogasawara: yes how can I get started
<ogasawara> dhillon-v10: one of the biggest problems we face as a team is dealing with a large volume of bugs coming in
<ogasawara> dhillon-v10: I think dealing with some of these bugs would be a great starting point
<dhillon-v10> ogasawara: yah I read that in the wiki, I am actually working with Ubuntu-doc team in the wikis and such
<ogasawara> dhillon-v10: awesome.  we can also always use help cleaning up or documentation on the wikis also
<dhillon-v10> ogasawara: :)
<ogasawara> dhillon-v10: as it happens, today we're holding a kernel bug day
<dhillon-v10> ogasawara: I am subscribed to the mailing list and I get a lot of bugs in my mail but I can't solve any of them can you help me with that
<dhillon-v10> ogasawara: most of them are sound related, I mostly work in computer vision
<ogasawara> dhillon-v10: sure, do you have a list of them you can point me to
<dhillon-v10> ogasawara: please elaborate yourself, I don't get it
<ogasawara> dhillon-v10: you mentioned you have some sound related bugs which you'd like to try to work on, I'm wondering if you have specific bug #'s we can work through
<dhillon-v10> ogasawara: oh sure just one sec.
<dhillon-v10> ogasawara: how about this one: Bug 414977
<ubot3> Malone bug 414977 in pulseaudio "in karmic, any application being started mutes the volume" [Undecided,Fix committed] https://launchpad.net/bugs/414977
<ogasawara> dhillon-v10: hrm, that's reported against pulseaudio (ie not the kernel) but it seems Daniel's commited a fix?
<ogasawara> dhillon-v10: I do know that the upgrade to pulseaudio 0.9.16 cause some regressions
<ogasawara> dhillon-v10: which I believe they are trying to resolve by uploading test packages to their PPA
<dhillon-v101> ogasawara: sorry about that
 * apw ^5's ogasawara 
<apw> ogasawara, i've rearranged the regressions review to next monday, sorry we forgot yesterday even though you were ahead
<dhillon-v10> ogasawara: my internet just  got disconnected, I fixed that 
<apw> and got it out on time
<rydberg1> rtg, apw: 64f1607f: good (suspends, resumes)
<ogasawara> apw: no worries, wasn't much to review this week anyways
<rydberg1> rtg, apw: ad1dfe69: good (suspends, resumes)
<rydberg1> rtg, apw: thus the problem lies somewhere in the configuration, not the tree itself (phew, saved me a couple of hours of bisecting :-))
<dhillon-v10> ogasawara: So what was that you were saying before my Internet got disconnected
<apw> ogasawara, we did meet this morning in and doa  quick review
<apw> rydberg1, interesting, now to bisect the configuration delta
<ogasawara> [10:37:40] <ogasawara> dhillon-v10: hrm, that's reported against pulseaudio (ie not the kernel) but it seems Daniel's commited a fix?
<ogasawara> [10:38:33] <ogasawara> dhillon-v10: I do know that the upgrade to pulseaudio 0.9.16 cause some regressions
<ogasawara> [10:38:49] <ogasawara> dhillon-v10: which I believe they are trying to resolve by uploading test packages to their PPA
<ogasawara> dhillon-v10: do you have another kernel bug we could look at?  Or I can put together a list for us to work through.
<dhillon-v10> ogasawara: I think you should put together a list, thanks
<ogasawara> dhillon-v10: would you prefer to target sound related bugs?  If not, I'll assemble a variety.
<dhillon-v10> ogasawara: I doesn't really matter :)
<ogasawara> dhillon-v10: ok, care to privately msg me your email address and I'll send you a good starter list with instructions
<dhillon-v10> ogasawara: how do I do that
<ogasawara> I'll message you
<dmclain> Whats the equivalent of kern.maxproc for Ubuntu?
<dmclain> in /etc/sysctl.conf?
<dmclain> Whats the equivalent of kern.maxproc for Ubuntu in /etc/sysctl.conf?  I didn't see a default in there for it, but I think I need to set it higher than the default for the box.
<Q-FUNK> ogasawara: is there anything I should do, now that we narrowed down the source of the regression and attached screenshots?
<ogasawara> Q-FUNK: I pasted the bad commit we bisected to the upstream bug report so hopefully it'll get passed along
<ogasawara> Q-FUNK: I noticed that in the thread on LKML you'd posted that another user mentioned they were not seeing issues . . .
<ogasawara> Q-FUNK: looking at the config they posted it seems they have CONFIG_FS_POSIX_ACL list disabled so they won't be affected by that patch
<Q-FUNK> ogasawara: I mentioned this earlier as well and attached that user's config to the LP bug.
<ogasawara> Q-FUNK: since the bad patch is ifdef'd with CONFIG_FS_POSIX_ACL
<Q-FUNK> indeed
<ogasawara> Q-FUNK: you did?  maybe I missed that
<Q-FUNK> good point
<Q-FUNK> I'll reply to him and point this out
<ogasawara> Q-FUNK: if you like, I can build you a test kernel with that config disabled
<ogasawara> Q-FUNK: else we can try to revert that commit, but I recall it didn't revert cleanly on the latest Karmic
<Q-FUNK> ogasawara: sure, why not.  against 2.6.31-rc6 ?
<ogasawara> Q-FUNK: yup
<Q-FUNK> ogasawara: sure, let's have a go at it
<ogasawara> Q-FUNK: k, gimme a bit, I have to queue up another build first but you're next in the queue
<Q-FUNK> ogasawara: ok, fair enough :)
<apw> rtg ok i've reconstructed abstracted debian against jaunty before smbs latest pushed its here:   git://kernel.ubuntu.com/apw/ubuntu-jaunty abstracted-debian
<apw> will update it shortly to the latest tip#
<apw> smb, am i only expecting to find one new tag in jaunty?
<smb> apw, In theory there should be one new one, yes. Why?
<apw> i was expecting a tag for security and a new proposed one?
<smb> apw, Which proposed? :)
<apw> we have no -proposed to jaunty now then i guess?
<smb> apw, Right, the old one just was accepted and I had no time to create the new one
<apw> ok cool thanks, thought i was going mad for a sec there
<smb> apw, Relax, its just me being slow
<apw> heh no i think thats the definition of _me_ being slow :)
<smb> Heh, lets agree on that it is past beer o' clock for both of us. We are entitled to being slow. :)
<apw> yeah thats all very true, and worse my beer store is empty
<apw> i must go get some more asap
<smb> Not even cider?
<apw> nope ... not a drinkable thing other than ... water
<smb> eek. thats an emergency
<rydberg1> bring some for the rest of us, too :-)
<apw> heh a plan indeed
<smb> We should pre-order for Portland. The bars tend to get out of stock if we arrive. :)
<rydberg1> quite the contrary happened when Las Vegas hosted the yearly American Physical Society conference: they were kindly asked never to return :-)
<rtg> apw, looks good. i assume you test built?
<rtg> apw, you're gonna have to rebase your Jaunty abstracted-debian branch against Ubuntu-2.6.28-15.49
<rydberg1> rtg, apw: ad1dfe69 with config-2.6.31-6-generic: fail (hangs on suspend)
<rydberg1> looking at suspicious modules now
<smb> rtg, apw I might make a new proposed tomorrowish. Maybe it is more worth the effort to rebase against that...
<rtg> smb, lets get it tip of the tree soonish
<smb> rtg, I guess apw and me will sort things out tomorrow morning
<rtg> bjf, amitk, git://kernel.ubuntu.com/rtg/ubuntu-karmic fsl-imx51 for a preview of the havoc I'm gonna wreak on your branch
<bjf> rtg, debuild: fatal error at line 630:
<bjf> cannot find readable debian/changelog anywhere!
<bjf> Are you in the source code tree?
<rtg> bjf, fdr clean first
<bjf> rtg, ok, thats working, when we settle on this we'll need to do some wiki updating
<rtg> bjf, right. my hope is to have all of the topic branches behave the same way.
<bjf> rtg, I'm looking at that tree & branch, what should I notice?
<rtg> bjf, just make sure I didn't lose any IMX51 patches.
<bjf> rtg, that's kind of hard to tell, I'm not sure what amit commited
<rtg> bjf, do you HW to run the kernel on?
<bjf> rtg, that's part of the reason I went back and reapplied *all* the patches to jaunty, I don't have to remember what I did or didn't apply
<bjf> rtg, however, it was/is harder for amit since the patches are against .28 not .31
<rtg> bjf, yeah, well, the fsl-imx51 branch was a little disorganized wrt to master because of the way the rebase script works
<bjf> rtg, well my build of the mvl-dove branch worked just fine
<apw> rtg yep, already done here, will push it shortly (rebase to smb's latest tag) will get with him to get it on tip in the am
<rtg> bjf, the dove branch is much simpler right now because its not  a rebase against master, its just the debianiozed build system for the kernel that Marvell provrides.
<rtg> apw, thanks
<rtg> apw, as soon as you have that sorted in the  AM, how about tackling the netbook branch?
<bjf> rtg, is your plan to rebase the dove branch against master?
<rtg> bjf, the dove branch _is_ rebased against master
<rtg> (or will be when I push it)
<rtg> bjf, shit, never mind. the dove branch won't get rebased against master until Marvell produces a 2.6.31 final.
<bjf> rtg, ok, you said earlier it wasn't, look forward to your push
<rtg> bjf, it's fsl-imx51 thats currently rebased against master (when I push it)
<apw> rtg absolutly, my plan is to get the thing on tip and get smb to review, as he's not seen it yet
<apw> and in parallel frig it onto the current netbook branch, and then prove that a rebase works
<bjf> rtg, the packaging stuff you have been hashing out with mobile guys and with cjwatson, is that all handled in the "meta" package
<rtg> bjf, the meta package is a bit of a different animal. its the package we use to maintain upgradeability when the kernel package name changes.
<rydberg1> rtg, apw, current status: the config-2.6.31-6-generic breaks the karmic head, compared to a slimmed custom configuration. Will take a while to single out the configuration culprit (taking a break now).
<Q-FUNK> ogasawara: can you put the link to this new kernel on the bug, when it's ready?  I'll be heading to bed soon here.
<ogasawara> Q-FUNK: will do
<Q-FUNK> ogasawara: thanks! :)
<NCommander> apw, did you ever get a chance to apply the sparc config patch i sent to you?
<apw> NCommander, remind me of the patch, i thought i saw all the patches get pulled, but i may have blinked
<NCommander> apw, it was the patch that fixed the d-i folder to disable all the modules that couldn't be built on SPARC (like DAC960), and a few config tweaks)
<NCommander> apw, I can resend/paste-bin it if need be
<apw> was there a subject
<apw> so i can check
<NCommander> apw, probably SPARC configuration
<apw> NCommander, resend it and i can check
<ghostcube> hi i just wanted to know if anyone is taking care about the mainline kernels too
<ghostcube> :)
<ghostcube> or is this only release support
<Fjodor> Hi guys. Does anyone know what happened to the gspca driver in the 2.6.31-rc series from http://kernel.ubuntu.com/~kernel-ppa ?
<ghostcube> hmm i have a problem with mainline 2.6.31rc6 and winbond chipdriver with lmsensors
<ghostcube> it doesnt load the modul rc5 does
#ubuntu-kernel 2009-08-19
<jjohansen1> ghostcube: is that the windbond-840 module? or the winbond module in staging?
<ghostcube> w83627ehf  kernel modul
<ghostcube> W83667HG chipset on an asusu p5q-pro 
<ghostcube> loads fine in rc5 but in rc6 is telling me device busy or not ready
<jjohansen1> ghostcube: dkms?
<ghostcube> no 
<ghostcube> just wanted to mention it its not the biggest bug ever :) but i dont get why its not loading heh
<jjohansen1> ghostcube: can you file a bug, and mark it as a regression
<ghostcube> yeah i can do so where to file ? to l aunchpad ?
<jjohansen1> ghostcube: yeah if you run ubuntu-bug -p linux
<jjohansen1> it will gather all the information (logs, etc), and automate most of the bug filing process
<ghostcube> ok so i will boot up into rc6 and do the command :) can this be tomorrow i dont know if i can file tonight
<ghostcube> thx and see you 
<jjohansen1> ghostcube: when ever is convenient for you
<ghostcube> ok :)
<praveen> hiii
<praveen> can anyone tell me how do I find the offset from two given addresses. They both are void* and I can't subtract them
<LeadingEdgeEntre> looking for 7 figure thinkers leadingedgeentrepreneurs.com
<Fjodor> Hi guys. Does anyone know what happened to the gspca driver in the 2.6.31-rc series from http://kernel.ubuntu.com/~kernel-ppa ?
<mcasadevall> apw, sparc patches resent, look for [patch] SPARC config patches
<ameno> Fjodor: http://ubuntuforums.org/showthread.php?p=7794205
<ameno> it has been confirmed, that the configs are not synced, but not if anyone is fixing it or when :/
<ameno> i did not dare to whine too much though :)
<apw> ameno, i am aware of he issue
<apw> its not that the configs are not sync, but that the wrong series config is being used and mainline has changed the name of a couple of the main top level options
<apw> which triggers whole subsystems to dissappear
<ameno> ah ok, someone else here told me the "out of sync" story
<ameno> so its not as trivial as i thought
<ameno> can we help somehow?
<smb> I guess we just need to find either a way to have a special mainline builds config for older kernels (not using kms by default) or switch to karmic configs instead. But that might prevent testing from Jaunty (and earlier) environments
<apw> yeah the logical first step is to try a build using those karmic configs and see if that fixes the underlying issue
<apw> as smb says that may trigger the kernels not being useful on jaunty without manual configuration
<apw> in that case we would at minimum need hints on what to do when using them on the mainline builds wiki
<NCommander> apw, bah, shoot me w.r.t. to the SPARC patches, something has gone freaking horribly wrong :-/
<NCommander> apw, I don't get why it failed in the DC and not for me, I removed the modules it wanted ... *sigh*
<apw> NCommander, its like that
<NCommander> apw, ?
<Q-FUNK> morning!
<apw> NCommander, i was just saying life tends to go wrong
<apw> Q-FUNK, morningg
<laga> apw: don't mean to psuh anything, it'd just be nice to know for planning: will there be another kenrel upload with that AUFS config change before beta?
<apw> the change is commited, so it'll be in the next kernel upload
<apw> that'll likely be whenever the next -rc is out
<Q-FUNK> apw: weren't we working on some old regression that affects SCx200 geodes, at some point?
<apw> Q-FUNK, couldn't say any more, too long ago
<Q-FUNK> apw: bug #241307
<ubot3> Malone bug 241307 in linux "kernel oops during bootup in LTSP" [High,In progress] https://launchpad.net/bugs/241307
<Q-FUNK> still unresolved
<apw> indeed.  there are a number of bugs unresolved
<apw> the issue there is that although we know the patch which triggered it, its not trivial to back out
<apw> its the kind of thing where someone with the h/w would be in the best position to fix it
<apw> to work out what in the new code is tripping the oops
<apw> with that info we could then quirk the code for the machine i assume
<Q-FUNK> apw: I have the hardware, but I lack the knowledge to hack on kernels.
<apw> is that your bug?
<Q-FUNK> yup
<apw> Q-FUNK, what was the latest kernel you tried on this thing?
<Q-FUNK> apw: good question.  some 2.6.28 IIRC
<apw> migth be worth trying a karmic kernel, as there appear to be yet further a20 updates
<apw> in the latest kernels, which seem to talk about issues on more embeded systems which don't have a keyboard controller
<apw> and the bit you commented out included that controller setup
<Q-FUNK> apw: noted. might be worth commenting that on the bug as well.  it'll make it easier for me to pass the info around.
<apw> done
<Q-FUNK> thanks!
<apw> rtg is this valid:
<apw> ifeq ($(disable_d_i),)
<apw>         $(DEBIAN)/rules do-binary-udebs;
<apw> endif
<apw> as in .orig.gz + diff upload mode the rules is not going to executable
<apw> normally we run things like perl <foo>
<apw> so i'd expect us to be using make -F
<rtg> apw, you could try $(MAKE) -f $(DEBIAN)/rules do-binary-udebs;
<apw> right, that would seem appropriate replacement
<smb> I try that immediately
<apw> well with $(DEBIAN) too
<apw> smb, take the one from main debian/rules file
<apw> rtg in karmic we would be ok, as we have that file +x and we are still makeing -sa kernels
<apw> but i think the issue will be there too
<rtg> apw, how odd
<apw> i have the feeling that buildd chmod +x debian/rules then run it
<apw> so we have gotten away with it before hand
<rtg> apw, how about debian/debian.env ? 
<apw> that we generate during the build, so its got whatever perms it has when we make it
<apw> so its unaffected by the -sa !-sa thing
<rtg> apw, only if the 'clean' target is run
<rtg> otherwise its part of the diff
<apw> hrm yes you are right
<apw> bum
<apw> i wonder if it needs to be -x
<rtg> apw, its likely the buildd runs 'clean' first, but I'd have to check for sure
<smb> apw, I replaced that make call and am rerunning the build now
<apw> oh yes they do
<apw> rtg i'll confirm that by uploading netbook
<smb> apw, btw, I run clean first as well
<apw> yes but thats before the diff stage
<apw> the -x on the master version is my fault
<tseliot> amitk, mjg59: do you know why the touchpad resolution is reported as 1x1 in the kernel? Here's the relevant kernel commit which introduced the resolution: http://git.kernel.org/?p=linux/kernel/git/mingo/linux-2.6-x86.git;a=commitdiff;h=ec20a022aa24fc63d3ab59584cb1e5aa9a21d46c;hp=d7ed5d883c09c5474f842dcb148515dfaef2a567
<apw> but it rasises an issue that an upload version won't work cause they get lost anyhow
<apw> so it'll be like you are seeing
<apw> even if its fixed in the git tree
<smb> I will get to tun both variants, atm the patches change +x to debain/rules stub and -x on debian.master/rules. Probably debian/rules needs the +x
<apw> i am pretty sure the the buildd process has to chmod +x debian/rules
<apw> due to the orig+diff handling and there being on requiorement on language for debian/rules
<smb> Sounds like a reasonable bet
<apw> hense we have never noticed this internal connection before
<apw> i only thought of it cause i am looking at the whines as i make the netbook upload to test
<apw> dpkg-source: warning: executable mode 0775 of 'debian/debian.env' will not be represented in diff
<smb> yeah, there has been much whining ever
<lool> apw: dpkg-buildpackage will always chmod debian/rules; search for chmod in /usr/bin/dpkg-buildpackage
<lool> That's the only executable file from the diff.gz
<apw> lool, thanks, that meets my expectations
<rtg> apw, whats that apt proxy/cacher package that you use?
<apw> i use apt-cacher-ng, seems to be almost painless
<smb> me too
<apw> rtg, i was looking at the imx51 branch on karmic that you rebased
<apw> it seemed you were deleting the whole of debian and debian.master then crteating debian.imx51
<apw> that seems counter intuitive, is that just a hang over?
<rtg> apw, no, it seemed the best way to avoid _any_ conflict in the debian directory
<rtg> those commits will always be on top
<apw> but by definition it creates a git conflict on the remove commit
<apw> and i thought the point of the split was that the new stuff would always be in debian.<branch> and couldn't conflict
<rtg> you know, I remember thinking about that yesterday, and now you've reminded me.
<rtg> so if newfiles are created in debian.master, then we'll have issues with theremoval, right?
<apw> or if they change too, i believe you will get a change/remove conflict
<rtg> shit, guess I'd better fix that
<apw> on the netbook branch i just left it in there
<apw> and added the change to add DEBIAN=xxx
<rtg> I use tab completion, so I try to get rid of duplicates
<apw> rtg ahh i see, that is annoying for me too :/
<rtg> apw, ok, thanks for spotting that
<apw> its a work in progress all round
<rtg> bjf, that means more mucking about in your dove branch
<smb> You still might call it master.debian and master.whatever
<smb> err
<smb> dumb
<smb> I meant master.debian and soemthing like arm.debian
<rtg> smb, indeed, one could. 
<bjf> rtg, i'm shocked!
<rtg> I shocked that you're shocked!
<smb> bjf, Hard to believe :)
<bjf> smb, indeed :)
<ogra> rtg, how is the imx51 renaming going, looks like i might have a livefs build server later today 
<ogra> i'd like to build images with the properly named packages ;)
<rtg> ogra, the kernel is renamed, but I have been ignoring the headers package naming issues for now.
<rtg> ogra, I still need to do the -meta package as well
<ogra> well, imx51 will have to replace the existing imx51 headers packages
<ogra> else we end up with a massive mess
<ogra> currently there exist header packages in the archive due to the fact that imx51 was built in karmic from the main package for quite a while
<rtg> ogra, those packages should get reaped eventually
<ogra> so we have to be cautious these get properly replaced ... and indeed however yu name them, dont forget upgrades ... 
<ogra> it will likely be a hell of conflicts/replaces you need
<ogra> for the kernel itself meta should take care as long a meta is named like in jaunty (which i think we agreed on)
<ogra> so there noting special is needed
<rtg> ogra, meta names are likely part of a LiveCD seed, aren't they?
<ogra> not seed, but yes, they get used in the liveimage
<ogra>         armel)  
<ogra>                         case "$SUBARCH" in 
<ogra>                                 imx51)
<ogra>                                         LIST="$LIST linux-babbage"
<ogra> thats the imx51 snipped from the livefs builde
<ogra> r
<ogra> *snippet
<ogra> its just a matter of renaming it to linux-imx51, one line change 
<rtg> ogra, didn't we switch from -babbage to -imx51 ?
<ogra> the tricky part is debian-installer
<rtg> ah, never mind
<ogra> for A4 i tried linux-babbage :) 
<ogra> but that ended up with a mess with the headers 
<bjf> smb, where am I in your queue? (the FSL patch redo) (I'm not pushing, i'm just asking in case I get asked)
<smb> bjf, Something around #2 or #3
<bjf> smb, timewise, you think this week or next?
<apw> ameno, the latest mainline daily was built with karmics config, perhaps you could see if that has the bits you expect in it
<smb> bjf, I try to get the abstract stuff in place to use it with the arm branch too. Rather this
<bjf> smb, ok
<apw> smb, we gonna have as separate source upload for arm in jaunty like we do in karmic?
<ameno> apw: yes, looks like drivers/media was compiled in \o/ will test it now...
<smb> apw, Yes, it seems we need that too
<apw> smb the patch stack in the abstracted-debian contains the changes to let the name come fromt he changelog
<rtg> bjf, its actually also on my list of things todo, buts its lower down after Karmic and LTS backports stuff.
<bjf> smb, is there anything I can help you with w.r.t. FSL
<apw> but you want to get with rtg to make sure you have the latest naming jiggles right
<smb> apw, Yeah, another reason to get that going first
<smb> apw, Yep, my intention. I got an eye on his discussions too
<apw> smb the netbook branch looks good with the new layout
<bjf> rtg, what's on your todo?
<rtg> bjf, Jaunty FSL
<smb> bjf, Not that I can say now. I likely will run in issues when actually pulling your patches
<smb> bjf, But I will get back to you then
<bjf> rtg, oh :-)
<apw> smb, just awaiting the PPA builds of it to confirm its a builder
<bjf> smb, ack
<apw> smb, thats with your little fixy applied for the udeb problem
<smb> apw, Ok, mine here seems to run now for quite a while
<smb> apw, So it looks somewhat good, but I wait for it to fionish
<apw> smb, about 10 mins from done i'd say here.  and its buildng in a buildd env as a better test
<smb> rtg, If you say Jaunty FSL, are we about to collide with things?
<rtg> smb, yep, its gonna take some hackery and git futzing
<rtg> I was gonna wait until netbook/master settled
<smb> rtg, Actually it sounds as you are about to go for the same things as I wanted
<apw> smb, yeah sounds like a 100% duplication rather than a clash
<rtg> smb, if you've time, then feel free
<rtg> I'm still working on Karmic dove, then -meta, then LTS, then ....
<apw> smb, i can work with you based on my netbook experience here in theory
<smb> rtg, Probably not the same. I get confused by the fact that the patchsets for imx51 are from fsl as well
<_ruben> not sure if this is a -kernel thing, but any clues as to why a partition wouldnt show up under /dev/disk/by-label and by-uuid, it is present under by-id and by-path
<apw> _ruben, it would depend on whether it has a uuid and label, they are often filesystem format specific
<apw> it there needs to be space allocated to it in the fs format not all do
<apw> those files are made by udev
<Frank83> Greetings Guys. Yesterday my Update Manager downloaded a Kernel Update (uname -r = 2.6.28-15-generic) but now today the Update manager is showing me again that I should update the kernel to... 2.6.28-15? Is that normal or is this a fix of the previous kernel?
<_ruben> apw: hmm .. it has both a label and uuid according to blkid, its an ext2 partition
<apw> then its most likely an issue with udev
<apw> hrm, can you paste the output of /sbin/blkid -o udev -p /dev/sdX1
<apw> where X matches your disk
<mjg59> Frank83: -15 is the ABI version, not the package version
<mjg59> Frank83: Some updates may keep the same ABI
<_ruben> Invalid output format udev. Choose from value, device, list, or full
<apw> _ruben, what version of ubuntu are you on
<smb> Frank83, Normal in the sense we had -15 accepted from proposed and today a now version from sercurity came, with the same abi number
<Frank83> mjg59, Ah, Thanks. That I didn't know. I'll download it, then.
<Frank83> mjg59, If I made a change to this kernel (Installed Compat-Wireless package to support my Wireless), will this update roll back those changes?
<smb> mjg59, While you are around. Did you get the feedback about acpi_video and _DOD and _DOS? Though there seems to be much change upstream
<_ruben> apw: fresh intrepid upgraded to jaunty (my pxe env doesnt do jaunty yet) .. but the problem was there in intrepid as well i think
<mjg59> smb: Yes, there's a discussion in upstream bugzilla
<smb> Frank83, No, it includes it
<apw> Frank83, did you install compat-wireless by installing linux-backports-modules ?
<Frank83> apw, Negative. I installed it from the source page of the project.
<tseliot> mjg59: shall I take it as a no?
<smb> Frank83, Oh, in that case it might replace it again
<smb> Frank83, Have you tried backports-modules?
<mjg59> tseliot: Sorry, I didn't highlight
<Frank83> smb, Okay. I'll take that into account. No, I haven't tried those, didn't even know of their existence until you mentioned it. What do they do?
<mjg59> tseliot: At a guess, the hardware doesn't support it?
<smb> Frank83, That package contains the code from compat-wireless put into a separate dir, so it supersedes the normal kernel drivers
<smb> Frank83, And is preserved on updates
<tseliot> mjg59: is it possible that the kernel doesn't know about the resolution? (just asking)
<apw> smb, my netbook build failed, seems the debug crapola isn't quite right
<apw> working on it now
<Frank83> smb, Wow, that will save me a lot of time! Thanks! Wonder why I didn't find / saw that in the project page
<smb> apw, My build is still running, odd, as if the concurrency_level is wrong...
<Frank83> smb, If this kernel update breaks up the compiled compat, then I will install the modules. Installing the modules over the compiled compat doesn't look like a good idea to me.
<apw> rtg, this bit in the karmic stuff that handles the ddebs
<smb> Frank83, You should find it it aptitude. or "sudo apt-get install linux-backports-modules-jaunty"
<apw>         mv ../$(dbgpkg)_$(release)-$(revision)_$(arch).deb \
<apw>                 ../$(dbgpkg)_$(release)-$(revision)_$(arch).ddeb
<apw>         grep -v '^$(dbgpkg)_.*$$' $(DEBIAN)/files > $(DEBIAN)/files.new
<apw>         mv $(DEBIAN)/files.new $(DEBIAN)/files
<apw> rtg, that looks wrong to me... i think that bit should be debian/ throughout
<apw> if you agree i'll fix it
<Frank83> smb, I will search for those. Many thanks for the help. :-)
<smb> Frank83, you're welcome :)
<smb> mjg59, Do you happen to have the bugzilla number for that discussion?
<mjg59> smb: Not offhand
<rtg> apw, I think you're right. its the first time the debug packages have been built.
<apw> yep ... will get this bugger built eventually, and fold the changes back to karmic
<smb> mjg59, Ok, np. Just wanted to make sure you got the info that allowing _DOS or _DOD in both places as a valid video device got the backlight working for that one guy with the acer laptop
<rtg> apw, test it locally by 'sudo mkdir /CurrretnBuilding ' in your chroot
<rtg> but spell it right
<apw> rtg heh, yeah
<rtg> it makes  mammoth file foreach flavour, roughly 500MB
<apw> yeeks
<rtg> which is why I don't do it very often
<mjg59> smb: http://bugzilla.kernel.org/show_bug.cgi?id=13577 I think
<ubot3> bugzilla.kernel.org bug 13577 in Power-Video "Broken backlight control on Acer Aspire 8930G due to buggy DSDT/ACPI Video" [Normal,Resolved: code_fix] 
<smb> mjg59, sounds similar. Though the reporter here had a 6920G, but Acer seems to be consistent in that respect
<mjg59> Yes
<smb> mjg59, In the case I had the problem were multiple definitions but only one had _DOD *and* _DOS defined as the code required. All others only had only one. So changing the if cases to allow one or the other in video and video_detect solved that
<ameno> apw: the current vanilla image looks ok and the module i missed before works
<ameno> the headers and source package seem broken though
<ameno> 1,4kB is a bit small for a kernel source package ;)
<ogra> its just good compression :P
<mdz> ogasawara: bug 388923 needs to be unwound...looks like a lot of unrelated bugs have been marked as duplicates of that bug
<ubot3> Malone bug 388923 in linux "package linux-image-2.6.28-13-generic 2.6.28-13.44 failed to install/upgrade: subprocess post-installation script returned error exit status 10" [High,Triaged] https://launchpad.net/bugs/388923
<mdz> ogasawara: I've added code to apport to handle the nvidia-common case already
<mdz> but there are some others mixed in there
<ogasawara> mdz: ok thanks, I'll take a look
<mdz> ogasawara: when I come across an apport-package bug, I generally try to extract the error message from DpkgTerminalLog.txt and put it into a comment, so it's easier to triage onward
<mdz> ogasawara: eg, I just did bug 390905
<ubot3> Malone bug 390905 in linux "package linux-image-2.6.28-13-generic 2.6.28-13.44 failed to install/upgrade: podproces post-installation script zwrÃ³ciÅ kod bÅÄdu 1 (dup-of: 388923)" [Undecided,Invalid] https://launchpad.net/bugs/390905
<ubot3> Malone bug 388923 in linux "package linux-image-2.6.28-13-generic 2.6.28-13.44 failed to install/upgrade: subprocess post-installation script returned error exit status 10" [High,Triaged] https://launchpad.net/bugs/388923
<mdz> ogasawara: I'm using bug 386042 as the master bug for this one: /usr/share/debconf/confmodule: line 42: printf: write error: Broken pipe
<ubot3> Malone bug 386042 in grub "package linux-image-2.6.28-13-generic 2.6.28-13.44 failed to install/upgrade: subprocess post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/386042
<mdz> and 385771 for the update-grub merge failure
<ogasawara> mdz: I'd been using bug 269539 for the update-grub merge failure
<ubot3> ogasawara: Error: Could not parse data returned by Malone: The read operation timed out
<mdz> ogasawara: oh, thanks. sorry about that
<Q-FUNK> ogasawara: howdy! would you happen to have a kernel for me to test drive?
<ogasawara> Q-FUNK: unfortunately not yet, fails to build and I haven't been able to dig through the log yet
<Q-FUNK> ogasawara: oh?  just disabling that config option makes the build fail?  
<ogasawara> Q-FUNK: I had to disable quite a few config options which turned that config option on
<ogasawara> Q-FUNK: but I'm not sure why those would then result in a failed build
<ogasawara> Q-FUNK: hence me needing to look at the build log
<Q-FUNK> ogasawara: interesting.  something tells me that sending your logs to Al Viro might be a good idea, as it seems that his recent changes feature a number of interesting regressions, this panic on Geode being only a small fraction of the lot.
<Q-FUNK> ogasawara: if nothing else, it could prevent some seriously broken code from being included in the 2.6.31 final release
<Q-FUNK> keeping the LKML in the loop might also be appropriate, in this particular case, me thinks.
<ogasawara> Q-FUNK: indeed
<ogasawara> Q-FUNK: I was having some git issues yesterday so I just want to make sure the failed build wasn't a result of that
<ret>  with kernels > 2.6.28-12 when I'm done installing them I continue to get `avc_has_perm_no_audit kernel panic not syncing'
<ret> then the keyboard becomes nonresponsive.
<ret> what ought i do
<jjohansen> ret: do you have selinux enabled?
<ret> jjohansen: I do
<jjohansen> ret: my guess is you need updated policy
<ret> jjohansen: how would I go about this?
<jjohansen> ret: have you tried pulling in the latest policy, you could also try audit-to-allow
<jjohansen> hrmm, or something like that its been a while since I looked at that
<jjohansen> ret: ubuntu-hardened is a better channel to ask selinux questions in
<mdz> bah, why is it kernel-team@lists instead of ubuntu-kernel@lists like everything else?
<ret> jjohansen: eh, looking at the config shows that its been mucked with
<ret> audit2allow --verbose returns nothing ;\
<ret> looks like its fixed though.
<ret> thanks
<rtg> bjf, amitk: repushed Karmic fsl-imx51 with updated the debian abstraction according to apw.
<rtg> hmm, garbled structure sentence
<apw> s/according to/as suggested by'
<ogra> so i can blame you for all the breakae now ? cool ;)
 * ogra tickles apw 
 * apw falls off his chair
<mdz> ogasawara: do you have a master bug for the "missing /boot/grub" errors?
<mdz> like bug 394729
<ubot3> Malone bug 394729 in linux "package linux-image-2.6.28-13-generic 2.6.28-13.45 failed to install/upgrade: subprocess post-installation script returned error exit status 1 (dup-of: 388923)" [Undecided,New] https://launchpad.net/bugs/394729
<ubot3> Malone bug 388923 in linux "package linux-image-2.6.28-13-generic 2.6.28-13.44 failed to install/upgrade: subprocess post-installation script returned error exit status 10" [High,Triaged] https://launchpad.net/bugs/388923
<ogasawara> mdz: for that one I don't.  I've usually been going back and forth with bug reporters to find they've uninstalled grub somehow and mark them invalid
<mdz> ogasawara: that's weird, uninstalling grub shouldn't remove /boot/grub I don't think
<ogasawara> mdz: or I've seen the case where they don't have their /boot partition mounted and it fails with the same issue
<ogasawara> mdz: have you started using a master bug?
<mdz> ogasawara: no
<mdz> ogasawara: are there any others which are common enough that we should add bugpatterns for them?
<ogasawara> mdz: aside from what I have documented in that wiki, I haven't seen any
<mdz> ogasawara: only a few of the ones on the wiki have bugpatterns that I see
<mdz> ogasawara: thanks for adding 386042, I think that one warrants a bugpattern
<ogasawara> mdz: I can do the bugpattern for that if you haven't already 
<mdz> ogasawara: doing it now
<ogasawara> mdz: awesome, thanks
<mdz> ogasawara: done
<amitk> rtg: ack
<mdz> ogasawara: I'm not sure what to do with the --fsys-tarfile ones
<mdz> those are definitely not kernel bugs, but it's hard to tell where they belong
<mdz> I've been putting them on no package for now
<mdz> but probably we should bugpattern them
<mdz> getting more reports isn't helping
<rtg> amitk, bjf: there are some more fsl packaging changes coming down the pipe. Steve L was not happy with libc-dev and headers package names.
<ogasawara> mdz: what's the master bug for that one?
<ogasawara> mdz: at least we can group them together first
<mdz> ogasawara: I don't think there is one.  I think it means the disk filled up
<mdz> ogasawara: we could set up a master bug, or we could just point people to a wiki page
<mdz> a lot of these would have been redirected to grub or initramfs-tools if the user were running karmic
<smb> rtg, I assume those will be in your preview branch at some point. Then I can pick those up when I do the dance for Jaunty
<rtg> smb, I'll shove them into the core repo later today, as soon as I sort out the naming issues.
<ogasawara> mdz: I'd maybe lean towards pointing to the wiki page
<mdz> ogasawara: I've come across a few duplicates of bug 78478, which isn't on the wiki page yet and doesn't have a bugpattern
<ubot3> Malone bug 78478 in grub2 "Package: linux-image-2.6.20-5-generic fails to install" [Undecided,Fix released] https://launchpad.net/bugs/78478
<smb> rtg, Ok cool. I make sure I closely follow that lead
<ogasawara> mdz: whoa, 2.6.20 :)  I actually hadn't seen that one yet.
<ogasawara> mdz: I'll add it to the wiki and get the bugpattern
<mdz> ogasawara: I believe that's the case where someone installs grub2 (pre-karmic)
<mdz> and update-grub is /usr/sbin/update-grub
<mdz> but /etc/kernel-img.conf still points to /sbin/update-grub
<mdz> ogasawara: I think we need to write some code to automatically extract the error message from DpkgTerminalLog.txt before submitting the bug
<ogasawara> mdz: that would be awesome to have it injected in the bug description
<mdz> ogasawara: the fsys-tarfile error is a nasty one, because it can be legitimate
<mdz> you get that error if a package is trying to overwrite a file in another package, e.g.
<ogra> mdz, flash-kernel on armel uses the symlinks 
<ogasawara> mdz: so we should have a master bug then
<ogra> (just seeing your mail)
<mdz> ogasawara: the actual error depends on what precedes that in the log
<mdz> in this weird case we're seeing, there is no error message preceding it
<mdz> just
<mdz> Unpacking linux-image-2.6.28-13-generic (from .../linux-image-2.6.28-13-generic_2.6.28-13.44_i386.deb) ...
<mdz> Done.
<mdz> dpkg-deb: subprocess paste killed by signal (Broken pipe)
<mdz> dpkg: error processing /var/cache/apt/archives/linux-image-2.6.28-13-generic_2.6.28-13.44_i386.deb (--unpack):
<mdz>  subprocess dpkg-deb --fsys-tarfile returned error exit status 2
<ogasawara> hrm, not exactly helpful
<mdz> that "Done." indicates the preinst finished successfully (I don't know why the kernel preinst does that but it does)
<ogasawara> mdz: I pushed a bugpattern for 78478 but used "Could not find postinst hook script [update-grub]." as the reg exp
<ogasawara> mdz: but it seems it could also use "The provided postinst hook script [/sbin/update-grub] could not be run."
<mdz> ogasawara: I've not had much luck making a bugpattern for the above...it's finicky about multiline patterns
<mdz> ogasawara: did you test that pattern?
<mdz> it contains square brackets, which are regex metacharacters
<mdz> ./test-local <bug number> will tell you if it matches a particular bug
<ogasawara> mdz: I'm going to uncommit it
<Fjodor> ameno, apw: Thank you for explaining
<Fjodor> apw: Is there any timeline for when it is resolved?
<apw> Fjodor, for what to be resolved?
<apw> Fjodor, too many threads going on
<Fjodor> apw: Oh sorry, I should have mentioned :-$ The problem with 2.6.31-kernels from kernel-ppa not having a lot of media/video modules
<apw> try the latest daily
<apw> that i build with the karmic configs, ameno seemed to think it was better
<Fjodor> apw: Ok, great! Thank you :-)
<ameno> better yes, but did you read my two lines afterwards too? :)
<ameno> apw: ^
<apw> you'll ahve to repeat them
<ameno> apw: the headers and source package seem broken though
<ameno> apw: 1,4kB is a bit small for a kernel source package ;)
<mdz> ogasawara: I've escalated bug 269539 with the foundations team because it has so many duplicates
<ubot3> Malone bug 269539 in ucf "package linux-image-2.6.27-3-generic failed to install/upgrade: "Conflicts found! Please edit `/var/run/grub/menu.lst' and sort them out manually."" [Undecided,Confirmed] https://launchpad.net/bugs/269539
<ogasawara> mdz: thanks
<apw> ameno, yep aware of those, thats a systemic problem in karmic builds, am working on testing the fixes for that right now
<mdz> ogasawara: bug 391519 is another of those weird "failed to run depmod" with no error messages. do you have a master for that?
<ubot3> Malone bug 391519 in linux "package linux-image-2.6.28-13-generic 2.6.28-13.44 failed to install/upgrade: subprocess post-installation script returned error exit status 1 (dup-of: 388923)" [Undecided,Invalid] https://launchpad.net/bugs/391519
<ubot3> Malone bug 388923 in linux "package linux-image-2.6.28-13-generic 2.6.28-13.44 failed to install/upgrade: subprocess post-installation script returned error exit status 10" [High,Triaged] https://launchpad.net/bugs/388923
<mdz> we saw it during the sprint
<mdz> cjwatson was looking at it
<mdz> bug 330834 is another
<ubot3> Malone bug 330834 in linux "Depmod segfaults when configuring linux-image-2.6.28-8-generic" [Undecided,New] https://launchpad.net/bugs/330834
<Fjodor> apw: So hopefully the next daily could have those packages fixed? I don't care about the source, but I need the headers...
<apw> Fjodor, hopefully yes
<mdz> ogasawara: 407420 is the one that we found during the sprint; if you don't already have a master, I suggest we use that one
<Fjodor> apw: Great :-)
<ogasawara> mdz: nope I don't have a master bug for that, I'll add 407420 to the wiki
<mdz> ogasawara: bzr commit -m 'Add bugpattern for bug 407420 (failed to run depmod)'
<ubot3> Malone bug 407420 in linux ""Failed to run depmod", no clear reason why" [Undecided,Incomplete] https://launchpad.net/bugs/407420
<mdz> ogasawara: we need a tool which scans open bugs for those which match apport bugpatterns and marks the duplicates automatically
<apw> rtg, we have a bug in our abstracted stuff, which is stopping the headers and source being made correctly
<apw> i have a fix in testing, which i'll push shortly to master
<apw> but you will want to apply the same fix to your arm copies of debian.master
<apw> as they are disconnected now right?
<rtg> apw, fsl-imx51 is descended from master, but mvl-dove is not yet
<apw> it has a complete copy of debian.master as debian.imx51 which will need fixing too
<apw> will get the patches up shortly
<dhillon-v10> hi guys
<apw> hi
<dhillon-v10> apw: how are you
<apw> not bad, holidays soon :)
<dhillon-v10> apw: so what are you working on now
<apw> hrm
<rtg> apw, guess he had no patience
<apw> or no network :)
<rtg> apw, so, what are the issues in Karmic debian.master ?
<apw> there appear to be 3 issues
<apw> 1) debian/files is always debian/files (the ddeb issue)
<apw> 2) we cannot call $DEBIAN/rules for udebs
<apw> 3) packages are built in debian/name, we broke the indep targets here
<apw> i am just testing the indep one on karmic then will push them so you can see
<apw> the last one is way my headers are empty on my mainline build
<rtg> apw, the other thing we need to figure out is how to build libc-dev for armel from the distro kernel package
<apw> why does it have to come from the distro one?
<apw> hrm is that cause we need just one common one for armel?
<rtg> apw, there can only be one libc-dev, and the distro kernel package is what userspace is built against
<apw> rtg that looks like it may be a simple edit
<apw> if you check out debian.master/control.stub.in
<apw> its directly in there with a list of architectures
<rtg> apw, perhaps, I was just looking at it. the other thing we shold change while we're at it is SRCPKGNAME-libc-dev, SRCPKGNAME-headers-PKGVER-ABINUM.
<apw> yeah if there are names which must not change they should not have that in them
<rtg> apw, correct
<apw> did we decide what the _all name is for the headers on the brnaches?
<rtg> apw, we;ll have to distinguish linux-headers ackage names through the ABI. for example, I've started fsl-imx51 at 100.
<apw> oh nng.  so non-overlapping ABI for those branches?
<rtg> yep
<rtg> too many dependencies on the package name layout
<apw> fair enough
<apw> i hope 100 abi bumps is sufficient :)
<rtg> you and me both!
<apw> so 200 for dove, and onwards to victory
<rtg> thats my plan
<apw> rtg, ok those changes seem ok so i've pushed them to karmic master
<rtg> apw, what does printdebian do for us?
<rtg> perhaps stuff in debian*/scripts/misc ?
<apw> rtg printdebian allows the build tools to find out where the debian directory is, ie. where the changelog is
<rtg> apw, is that a standard target?
<apw> did i push that, hrm, that was meant to go out as a patch on our list
<rtg> s'ok, just wondered
<apw> nope its meant to be something we are going to need for the buildscript.git stuff
<apw> to find out which of the multiple debian*/changelogs are the real one in this tree
<apw> so its can annotate it before build etc.
<apw> i can pull that one out and email it, that was my intent
<rtg> apw, no, go ahead and leave it
<apw> we are going to have 'fun' every time we rebase master ... 
<devinheitmueller> Hello all.  I popped in three weeks ago to see about getting the xc5000 firmware into Karmic (launchpad 403642), and was told it should happen in the next week.  Just wanted to see if I can poke somebody for a status on that (especially since a new version of linux-firmware was spun a couple of days ago and it wasn't in there)
<devinheitmueller> (according to my notes, on 7/30, pgranger said it would be ready "next week")
<bjf-afk> devinheitmueller, try posting an email to the ubuntu kerne-team mailing list
<devinheitmueller> ok, worth a try.
<devinheitmueller> Certainly the experience has me wondering if anybody is actually reading the launchpad bugs.
<bjf-afk> devinheitmueller, we do our best, and we do get to as many as we can
<devinheitmueller> (since, like most bugs, it appears to be in the exact same state it was when it was opened)
<devinheitmueller> Yeah, I know you guys are understaffed.
<bjf-afk> bug 403642
<ubot3> Malone bug 403642 in linux-firmware "Include xc5000 firmware in Karmic (now properly licensed)" [Undecided,New] https://launchpad.net/bugs/403642
#ubuntu-kernel 2009-08-20
<Fjodor> apw: I will probably go to bed soon, but did you have any luck with getting working headers packages built for the daylies? And also, when do they get uploaded (relative to UTC)?
<cdE|Woozy> I just noticed kernel 2.6.31-6 spitting out "ACPI Error", is this something to worry about?
<cdE|Woozy> http://pastebin.ubuntu.com/256174/
<soren> Does anyone know why CONFIG_GFS2_FS_LOCKING_DLM is disabled in Karmic?
<apw> soren, i would guess it has its default value and noon has ever asked for it
<soren> Consider yourself asked  :)
<soren> It used to be enabled (in previous versions of Ubuntu)
<apw> you sure, we didn't have gfs2 did we?
<soren> We do have GFS2.
<soren> ...and have had for quite a while.
<soren> Without the DLM, it's not much fun.
<apw> soren, yep seems to have gone away, strange
<soren> i can haz it back, plz?
<apw> file me a bug will ya, and assign it to apw
<soren> apw: Sure.
<apw> soren, and let me know the number here
<apw> smb, damn these udebs are complex.  i think i 
<apw> have it sorted out now.  will know in 10 mins
<soren> apw: Sure.
 * soren looks it up
<smb> apw, I can believe. Just let me know if you have updated your patches, then I run those on the builds I have
<apw> i'll let this build run, and if it works (and i think it will) then i'll push you a copy
<smb> Ack
<apw> man this would all be so easy but for kernel-wedge which is just a POS
<apw> i know where stuff is la la la not listening
<apw> its such a pain that udebs are dependant on binary-debs ... so it makes every damn thing
<soren> apw: bug 416325
<ubot3`> Malone bug 416325 in linux "Please reenable CONFIG_GFS2_FS_LOCKING_DLM" [Undecided,New] https://launchpad.net/bugs/416325
<soren> apw: It's not like kernel-wedge is sacred. You can fix it if you like :)
<apw> heh yeah ... i'd love to walk into the mine field.  could i have a blind fold?
<apw> we are being mean to it, its not worth fixing it for this
<ghostcube> hi
<levonshe> Hello all, please simple question - linux_source-2.6.30  package is not anymore on ftp server, why? 
<levonshe> The second simple question - to use compiled 2.6.31 kernel, it is required to install linux-libc-dev_2.6.31-6.25_i386.deb package ?
<asac> some more ids for cdc_ether ... can we pick them to support more ericsson modems? http://www.spinics.net/lists/netdev/msg104788.html
<asac> pgraner: ^^ ?
<apw> levonshe, linux_source-2.6.30 has gone becuase we have moved on to 2.6.31 kernels in karmic
<apw> the linux-libc-dev is a headers package for compiling programs, and necessarily is version locked with the kernel as it carries the headers from there kernel
<levonshe> apw, first thank you, still I confused - say I want to use 2.6.30 on jaunty ( I am actually have it now) and syscalls do not supposed to change , so application (user space) programs do not require libc-devel ? (my programs srill works)
<apw> though by that standard installing the updated libc headers wouldn't change anything either
<apw> the packages are not designed for backport like that so its not supprising they are setup for normal use.  which is to have that package installed in parallel with the kernel
<arand> I get a kernel panic on shutdown, I would like to know the easiest way to capture it for attaching to bug report? It does not show up anywhere in /var/log/*
<smb> arand, Might happen after the devices are synced. Likely the best chance is to disable splash, set console to a small font and take a picture when you see the panic on the way down
<levonshe> apw, can you comment - how /boot/abi file is used , because I am compiling upgrading kernel/modules/drivers and did not receive any complaints for ABI compatability ?
<apw> the boot/abi files are used for abi comparisons between kerrnels, allowing us to detect such a change and handle it before a kernel release
<arand> smb: okay, will do. I'm not sure if it's a panic/Oops but something locks and requires a REISUB, and what I see with splash disabled does look much like a panic... *looks into changin resolution.
<smb> arand, https://wiki.ubuntu.com/KernelTeam/KernelDebuggingTricks might help
<smb> arand, also /etc/default/console-setup
<arand> smb: cheers
<levonshe> apw, sorry to monopolize you , but couple of things I am thinking : the release notes for libc-devel describes all kind of changes in kernel, but I think they should state which new functionalities are available at user space, so where is the document  for application programmer?
<apw> as far as i know there is none, the main thing is the ABI is meant to be backwards compatible
<apw> so in theory you would only get newer interfaces specified
<apw> where it is not you would be entering the land of needing to get the libc updates to match
<apw> and likely beyond what is possible to expect to work well with both kernels
<andresmujica1> hi, anyone nows if ogasawara use a template for kernelteam bugday wiki page? i want to update a little bit the launchpadlib section, but i'm not sure if there's a template for it or just modifying the last version would do it...
<rtg> pgraner`, whats the story with DVB firmware? Are they all under Jockey control now?
<pgraner`> rtg: not yet, pitti is on holiday once he gets back it will get flipped
<rtg> pgraner`, k, just responding to a k-t email
<smb> andresmujica1, I would guess she generates it somehow. But best ask directly in around two hrs
<andresmujica1> smb: yeap, that's what i'll do.. tks 
<rtg> apw, can you give me a quick review of the perl syntax for http://kernel.ubuntu.com/~rtg/0001-UBUNTU-SAUCE-Improve-error-reporting-in-postinst.patch ?
<apw> rtg looks fine to me, $! in a string context is the error message translation of errno from the previous system call
<apw> so he has added $! in each case into the error mesasge.
<apw> ack from me
<rtg> apw, thanks
<rtg> I've not programmed perl in about 47 years
<amitk> heh :)
<apw> rtg a good plan indeed
<rtg> apw, as the keeper of checkpatch, I assumed you were fresh on it :)
<apw> sadly true
 * apw collides with rtg :)
<apw> i love that git slaps one
<rtg> apw, a Karmic push?
<apw> yeah, you just pushed that patch we were talking about
<apw> and i was about to push the abstraction fixes
<rtg> apw, seems like I should let 'em into the wild as soon as possible.
<apw> it told me to stop and i ma rebasing them
<apw> will push them in a few secs
<rtg> copyright fix?
<apw> that plus about 3 others
<rtg> cool. I'll use 'em to fix my *&#$^!^* arm builds.
<apw> copyright, empty udebs, fixing some bad links
<apw> git just decided to gc itself ... grrr
<rtg> apw, yeah, it rips on me about once a  day.
<apw> first time i've seen it in ages... damnable thing
<apw> always seem to do it when you have a disk hog runing so you notice it cause it takes ages
<apw> 700k objects hrm ... thats dirty
<apw> rtg ok i've pushed a pile to karmic, seems to work for me
<rtg> apw, horking
<rtg> devinheitmueller, you should hassle that slacker pgraner`about the xc5000 firmware. I don't think he's got enough to do.
<devinheitmueller> rtg: heh.  I wasn't trying to get on anybody's back.  I just wanted to give a poke and make sure it didn't fall off the table.
<rtg> devinheitmueller, I'll milestone the bug so that it doesn't accidentally get overlooked.
<devinheitmueller> Thanks.
<devinheitmueller> I spent months getting the licensing worked out with Xceive, and it would definitely help alot of users if this thing worked "out-of-the box"
<rtg> devinheitmueller, ok, milestoned _and_ assigned to the boss :)
<devinheitmueller> Thanks.  I appreciate it.
 * devinheitmueller suddenly realizes that "rtg" is Tim Gardner.  Doh.
<rtg> I'm infamous ?
<devinheitmueller> Well, you're the same guy I'm talking to via email.  I just didn't make the connection.
<devinheitmueller> But yes, you are infamous.  :-)
<rtg> I'm just hiding behind and obscure nick :)
<rtg> s/and/an/
<devinheitmueller> Indeed.  If it had been "tg", I probably would have made the connection much faster.
<devinheitmueller> The whole "tim is my middle name" thing threw me off.
<devinheitmueller> Anyway, a pleasure to make your acquaintance.
<rtg> hmm, can't help it. got stuck with that name years ago.
<ogra> raving tim gardner ?
<ogra> or is it rocking ?
<rtg> raving suits me :)
<devinheitmueller> ogra: I might have guessed  "ranting".
<rtg> or ranting even.
<ogra> lol
<bjf> apw, are you mucking with my dove branch? (i have some patches to submit but can wait)
<apw> i am not mucking with it, but it will be getting mucked with shortly
<rtg> apw, do you get this lintian noise ? 'copyright-without-copyright-notice'
<apw> rtg checkin
<apw> g
<rtg> seems harmless
<apw> how does one find out what it even means
<rtg> apw, dunno. perhaps solicit the expertize of a packaging expert. alternately, read the debian policy manual (ugh!) http://www.debian.org/doc/debian-policy/
<apw> rtg if i run lintian on a karmic dsc i just built from master
<apw> i get W: linux source: ancient-standards-version 3.6.1 (current is 3.8.2)
<apw> E: linux source: build-depends-on-obsolete-package build-depends-indep: gs
<apw> W: linux source: native-package-with-dash-version
<Q-FUNK> lintian-info
<Q-FUNK> which package still has 3.6.1 as its source standard?
<apw> the kernel
<Q-FUNK> rtg: on which package?
<Q-FUNK> url to its dsc?
<Q-FUNK> lemme see what I can do to overhaul that...  url please?
<rtg> Q-FUNK, http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux_2.6.31-6.25.dsc
<Q-FUNK> thanks.  fetching...
<Q-FUNK> right. debian/control is indeed somewhat outdated
<Q-FUNK> this has got to be one of the scariest build trees I've ever seen.
<rtg> apw, I cleaned up 'UBUNTU: abstracted-debian -- drop the debian directories from headers part 2' and repushed. You left some changelog fuzz in the patch.
<Q-FUNK> rtg: copyright with copyright:  it misses an actual (C)CCYY in there
<rtg> Q-FUNK, send a patch ?
<Q-FUNK> rtg: I'm letting the whole package build in background.  will send a patch afterwards with as many fixes as possible
<rtg> apw, there was also a typo; prunt --> prune
<Q-FUNK> I tend to be fairly good at fixing lintian errors
<rtg> Q-FUNK, thanks, its takes someone with more knowledge of debian policy then I have
<apw> rtg, sorry man, that was fail on my part.  it failed to cherry-pick from jaunty, so i hand applied it, badly
<rtg> apw, its there now (I think)
<apw> rtg ye looks correct now
<apw> foolish me, i was doing two things at once in the same tree, the prerelease builder stepped on my toes...
<apw> do one thing at once ...
<rtg> apw, happens to me all the time.
<rtg> apw, I _really_ like uploading from zinc :)
<apw> i do all mine from chin, but yes the difference is astounding
<rtg> apw, do you do your packaging on chin?
<apw> no i mostly do it local, then push the blob to chin in the background
<apw> as i often upload it to more than one ppa say
<rtg> apw, with the git repo on zinc, its pretty straighforward to just do it from there
<apw> are you doing your packaging as well on zinc
<apw> yeah thats pertty sensible ... why don't i do that?
<rtg> apw, yep, have karmic chroot now
<apw> nice
<smb> cd ..
 * apw eyes a sierra nevada beer ...
 * smb has a Baisinger special
<smb> rtg, Analizing contents of common packages:
<smb> \o/ seems all files are present
<rtg> smb, cool.
<smb> rtg, This was for jaunty-i386. I want to do amd64, lpia and amrel too and then repeat with a created source package
<smb> rtg, but it looks so far quite good
<rtg> apw, I'm thinking, that with sufficient care, most of the rules.d files for topic branches could be run directly from debian.master
<apw> rtg that seems likely
<rtg> smb, I breathlessly await your results. I'm chomping to get on with the LTS backports.
<apw> rtg ... once smb is happy i am hoping he will squash the bug fixes so you will have a stack of about 4 patches you need
<smb> rtg, I try to make quick. I wanted to go on with jaunty-arm too
<apw> with the middle one being a scripted thing
 * apw is waiting to do netbook
<rtg> apw, I dunno if we'll ever be able to script it entirely. some of these branches are gonna be quite unique.
<smb> apw, Maybe you can start of with squashing and sending a sort of pull/review to our list?
<apw> smb sure ... 
<apw> rtg i mean that there is a scripted way to may the base for a branch
<apw> as in converting a branch to the method
<apw> and a verbial script to make the first entries before customisation for a branch
<smb> rtg, btw. I see a linux-mvl-dove_2.6.31-200.2_source.changes for binary NEW for karmic. Is that one you want to be eradicated too?
<rtg> smb, yeah, I'm working on the next dove upload
<apw> rtg does rfkill userspace remember anything and apply it on boot to your knowledge?
<rtg> apw, nope, its possibly stored in BIOS NVRAM or something, but nothing in the driver or userspace
<ameno> no vanilla build today?
<fabbione> hi guys
<fabbione> rtg: ping?
#ubuntu-kernel 2009-08-21
<DanaG> hmm, any chance of getting the find_task_by_vpid symbol re-exported? http://lists.mandriva.com/kernel-discuss/2009-07/msg00018.php
 * apw waves
 * smb waves back
 * cooloney waves back to apw
<apw> yo
<apw> smb, up for reviewing a branch for me?  just pushed up what i think will be the netbook branch for karmic, to its official location.  could do with an eye over it
<smb> Yeah sure, let me finish a little thing off here, then I have a look. 
<apw> np, thanks
<cking_> apw, who maintains those kernel team suspend/resume test scripts?
<apw> suspend_test ?  thats mine
<cking> I've found that sometimes we may need to ensure the RTC is sync'd with UTC for it to work.
<apw> well we cirtainly can't change its utc status
<apw> as it may be localtime for windows, do you mean that we should note its not and use a different time?
<cking> not sure of the correct workaround - it's just that I've seen one user where hwclock --utc --systohc fixed the problem - so I expect some how we need to check for this kind of localtime/UTC difference
<apw> we got into a lot of trouble for doing that in the past :)  windows like it to be localtime
<cking> hrm
<cking> that certainly concurs with my experience when I was installing Windoze 7 to benchmark the I/O - the clock was 1 hour out
<apw> well i can see how it wouldn't work if the clock isn't in UTC
<apw> hrm, actually better check the kerel
<apw> we use an absolute utc seconds in the kernel interface, need to figure out if it _is_ utc in the interface
<smb> apw, Looking at your netbook branch, most things look neat (want that insert-changes for jaunty too. :)) but the "start new release" seems to create abi files with -6.25 numbers. Are you not needing -400.0?
<apw> hrm, error
<apw> will check thanks
<smb> oh sorry, my fault
<apw> smb, oh no its actually removing them
<smb> yeah just saw so
<apw> but that is wrong, that should be in the previous commits
<apw> ie. the abi should have been zapped two commites before
<apw> will sort that out thanks
<smb> right, makes sense
<apw> cking, if you have a machine you can set the clock to localtime om
<apw> on, then you could test something for me
<cking> ok I do have one here
<cking> ready for testing
<apw> date '+%s'; cat /sys/class/rtc/rtc0/since_epoch
<apw> what does that say
<apw> hrm i think mine may be in localtime too
<apw> apw@dm$ date '+%s'; cat /sys/class/rtc/rtc0/since_epoch
<apw> 1250842773
<apw> 1250846375
<cking> Hrm. It's a hardy box which don't have that proc file
<apw> pup
<apw> usb stick?
<cking> yeah - gimme 10
<apw> cking, the test i am sure you can guess, but basically can you test setting a sleep at date +%s output + 30s and suspend, and then try at the proc file output + 30s and suspend... see whcih is correct
<cking> will do once I've got the machine booted
<apw> yep. and you suck eggs by first removing the shell ...
<cking> to see if it's fired one can use: cat /proc/driver/rtc | grep alarm_IRQ | awk '{ print $3 }'
<apw> interesting
<cking> yes = IRQ is triggered
<cking> after it's should have fired, it will be no (IRQ has fired)
<apw> so its in the inverse of whether it fired?
<apw> smb, ok i've hopefully fixed the branch and repushed
<cking> yep - check out http://kernel.ubuntu.com/git?p=cking/scripts/.git;a=commit;h=3577ea60c525f4e3d91b2f7afa009fa68e4a6ff8
<cking> date '+%s'; cat /sys/class/rtc/rtc0/since_epoch - gives me:
<cking> 1250843781
<cking> 1250843773
<smb> apw, Ok, if the intention is to do no abi checks at all it seems to be good
<apw> for the first version i don't have any abi information
<apw> once thats built i will pull the abi info from the builds and we can start checking it
<apw> i suppose i should have taken the abi from the tip really shouldn't i
<apw> bum
<smb> Oh right, the logic with -0.0 would not work here
<apw> i guess 400.0 could contain the tip of the karmic trees info
<apw> dunno if i care enough to fight it
<smb> you could have, it should be good. In the fist version it looked half like you tried to have that
<smb> It should be fine both ways
<smb> apw, I would rather leave it as is (in favour of getting a condensed jaunty patchset for abstracted ;-))
<smb> But I am biased here
<apw> yeah i think i'll leave it for now as i have tested the result
<apw> yours is next
<cking> using since_epoch looks like the trick to fix it
<apw> cking, thanks ... will put something together there
<cking> apw, it may be worth doing a sanity check that the alarm works before doing those suspend tests, c.f. my script earlier
<cking> just bear in mind that since_epoch won't work for Hardy kernels
<apw> yeah, will do
<apw> smb, ok just pushed the squashed version to my repo, cast an eye over it and if you are happy you can pull it into master
<cking> time for a coffee
<smb> apw, great. thanks. will do
<apw> cking, thats 11s'ies
<cking> I've been working since 7
<apw> then you are allowed
<cking> much appreciated
<apw> though now i want one ... grrr
<cking> autosuggestion 1: apw 0
 * apw slaps cking 
<smb> apw, Would the jaunty branch still need the insertchanges to follow abstracted debian? (just as I saw that in the karmic netbook branch)
<apw> oh yeah, that would be needed over there too
<apw> converted to main branch
<apw> shall i do that
 * apw _will_ do that
<smb> apw, Would be neat if you just dropped into your repo. Then I pick and test the whole
 * smb give apw one of those famous hugs
<apw> daniel back i can't breath :)
<smb> hehe
<amitk> apw: cking: so are you two going on vacation together?
<apw> heheh ... can you imagine ... i'd end up eating his children, i am untrained
<amitk> heh
<apw> smb, applied to both karmic and my jaunty branch
<smb> apw, cool pulling and testing
<apw> smb, it had better be right by now!  i am tired of a-d ...
 * apw callls now 11:00
<smb> apw, I'd be very careful to report otherwise.
 * smb looks and sees 11:44
<apw> see i am late for my coffee, *slurp*
<smb> You can never be late, just in the wrong timezone
<apw> we i want to be late, so i can have it now and now wait for 11
<cking> yawn
<apw> smb, the hardy changelog has no 24.58 in it, is that to be expected?
<smb> apw, yes. it was a proposed that will be overridden (actually never went there, but I kept the numbers)
<apw> smb, ok thanks
<smb> apw, Oh, there is something I have to tell you about the abstracted builds
<apw> good or bad?
<smb> \o/ seems all files are present
<apw> hurrah thank goodness for that
<apw> and only the right ones i assume :)
<smb> Well it does not exactly tell about the contents. Probably I check on the abi and config files, just to be safe...
<apw> i am assuming the contents are the same
<apw> presumably we could make a source tarball before and after those commits
<apw> and then compare them
<apw> as in -x them and diff -u the two trees
<apw> they should be the same
<smb> But it has the same number of packages as before and the packages contain the same files. The only change could be in generated files that do not lead to files being present
<apw> and i likely mena the binary actually
<apw> bah i say upload it to a ppa, and see what it makes :)
<smb> :) yeah. that is sort of the next step
<smb> and boot the produced kernel
<juliux> hi
<juliux> it is possible to disable the powersaving on the vga port?
<juliux> i have here a server which crashes sometimes and then i can't press a key to get the vga/monitor back online;)
<apw> juliux, i am pretty sure that would be possible from userspace
<apw> is it a raw VT or showing X
<juliux> raw VT
<juliux> no x is running
<smb> juliux, Does "setterm -powersave off" work?
<juliux> smb: i will try it out
<smb> juliux, maybe needs a "-blank 0", I am not sure
<juliux> cannot (un)set powersave mode
<smb> juliux, seems only to work typed on the console
<juliux> i am logged in via ssh atm
<juliux> i will try it directly at the system
<smb> juliux, Just tried it with a system here ssh does not work. On the console it does do something
<juliux> smb: ok
<juliux> but seeterm is only working if i am logged in, right?
<smb> From the description is sound like echoing control sequences to the current terminal. Probably its ok as long as the term has the right caps (and ssh virt term does not)
<smb> But I have not tried otherwise
<bjf> amitk, ?
<amitk> bjf: so you've applied all the patches (1st set) as-is (including support for every FSL SoC), right?
<bjf> amitk, that is correct, I believe there were only two patches that that didn't get applied "as-is"
<amitk> but I thought that when you did the second set (earlier), you'd tweezed out only the imx51-specific bits
<bjf> amitk, that is correct
<bjf> amitk, that i what I attempted to do
<ogra> amitk, btw, does the current build boot for you on the B1 ?
<ogra> doesnt work for me 
<amitk> ogra: not tried it. I'm working on fec ATM
<ogra> ah, ignore me then, FEC is more important
<amitk> bjf: so in your git tree on kernel.u.c, you now have the 1st set (~60 patches) applied as-is and the 2nd second imx51-specific?
<bjf> amitk, no
<bjf> amitk, I have a fsl branch in my repo, that contains all ER9-SP patches (300+) applied "as-is"
<amitk> aah, ok
<bjf> amitk, it _is_ confusing
<amitk> I'll find it impossible to replicate that on karmic. When we are having trouble just porting imx51-specific bits, I can't imagine the effort the forward port the entire SoC stack
<amitk> *the effort to
<bjf> amitk, I understand
<bjf> amitk, the only way for all the soc support on karmic is for FSL to do it themselves 
<bjf> amitk, at some point there are going to move to a more recent kernel
<amitk> bjf: so what do you suggest? Should I stick to just porting the single squashed patch that I had in jaunty to karmic and add the new ER9-SP patches on top?
<bjf> amitk, I think that is all that you can do, as long as we are only supporting reference design boards then we should be ok
<bjf> amitk, if we have to support an OEM customer, then we are going to have problems (bigger problems than just supporting the reference design)
<bjf> amitk, just supporting a single reference design is going to be tough enough
 * amitk nods
<smb> *** Jaunty master tree is now abstracted ***
<bjf> smb, must be time for some fsl pathing then :-)
<smb> bjf, I wonder how you guessed. :)
<rtg> bjf, patching --> patching ?
<rtg> pathing*
<bjf> rtg, ack  (pathing -> patching)
<bjf> rtg, pathing is a new technique we use on fsl patches when we apply them
 * rtg thinks bjf is smoking something
<ogra> so are you pathing your patches too ? 
<mdz> I just had my first real, live kernel crash which was saved as a dump automagically in Karmic
<ogra> heh, first time i see someone happy about a kernel crash :)
 * ogra is happy he finally has a kernel since today at all ... dont want that to crash though
<bjf> rtg, mvl-dove tree is missing the "ubuntu" directory tree
<rtg> bjf, thats because its a straightforward rebase from their repo. I've no Ubuntu goodness in it (yet)
<bjf> rtg, I'm going to need that though aren't I?
<rtg> bjf, the most obvious thing missing is aufs for the LiveCD
<bjf> rtg, apparmour
<rtg> bjf, yep, you're gonna need it. its the next thing I'm working on, but there are some build issues.
<rtg> bjf, you can still run without AA
<bjf> rtg, I'll ignore it for now
<bjf> rtg, my new dove-z0 flavour generates: Could not open /home/bradf/karmic/mvl-karmic/debian/linux-image-2.6.31-200-dove-z0/lib/modules/2.6.31-200-dove-z0/modules.alias at debian.mvl-dove/tests/check-aliases line 10.
<rtg> bjf, thats the VERSION bs. I don't think you got rebased correctly.
<bjf> rtg, haven't rebased since your change, didn't know the two were related, thanks
<rtg> bjf, git reset --hard HEAD~10; git fetch origin; git rebase origin/mvl-dove
<rtg> bjf, did you notice there are some updates in the dove git repo in the -rc5 branch?
<bjf> rtg, those weree the updates I recently posted and you've already pulled
<rtg> bjf, correct, but I also changed the config files as art of those changes
<rtg> part*
<bjf> rtg, ah, you are talking about *our* dove repo not *marvell's* dove repo, my mistake
<bjf> rtg, I'll look at the latest changes you've made
<bjf> rtg, to our dove branch
<rtg> bjf, yeah, sorry.
<bjf> rtg, np, my confusion
<NCommander> rtg, can you upload a .2 of the dove metapackage so we can get around the failed to upload issues :-/
<rtg> NCommander, if I _knew_ what the problem was....
<NCommander> rtg, <bigjools> NCommander: the package is building a binary version that already existing
<NCommander> rtg, usually happens when a binary package moves between packages, or similar cases
<ameno> apw: are the vanilla builds now totally broken? :)
<apw> ameno, maybe?
<rtg> NCommander, its a new package. what could be colliding?
<ameno> apw: no dir for the last two days
<apw> ameno, ahh they were disabled today hwile i fixed a bug, must have missed the mornign build
<apw> yeah its off building something now
<NCommander> rtg, I'm looking more indepth
<ameno> oki, thanks
<apw> good job you mentioned it today though :)
<NCommander> rtg, I think LP crapped itself; your package is both superseeded AND published: https://edge.launchpad.net/ubuntu/+source/linux-meta-mvl-dove/2.6.31.200.1
<smb> apw, Hm, I hope it knows that the configs in jaunty are now under debian.master...
<apw> claims to superceed itself
<NCommander> apw, thats a bug :-/
<apw> smb, it does, well only cause its got fixed for karmic
<apw> a bit of luck i fixed it earlier this week 
<smb> apw, Phew, yeah :)
<apw> else you'd be doing it
 * smb hides
<NCommander> rtg, bah, fixed (in theory)
<NCommander> rtg, the source package was promoted to main while the metapackage was building
<NCommander> rtg, which caused LP to loose its mind since it tried to find a now non-existant package in universe, and promptly bombed during upload
<rtg> NCommander, its the kind of problem I like, i.e., one I don't have to fix.
<NCommander> rtg, thanks for your hard work in this. Remind me when we next meet in meatspace to buy you $BEVERAGE
<rtg> NCommander, $BEVERAGES
<ogra> $BEVERAGES++
 * NCommander sets a price limit of $10 dollars or less per BEVERAGE
<laga> apw: yay, thanks again for that AUFS fix
<apw> laga, np, what woke you up there?
<laga> apw: it just got uploaded/published i think
<laga> and i got the bug mail
<apw> ahh yes it is being
<NCommander> rtg, failed again, needs version bump. sorry :-/
<rtg> NCommander, uno momento
<rtg> NCommander, done
<NCommander> rtg, thank you
<pef> hello
<rtg> bjf-afk, new dove bits, enabled the ubuntu build, rebased against master to bing things up to -rc6
<ameno> apw: jfyi, the headers seem to be fixed (recompiled the virtualbox module with them), but the source package is still broken
#ubuntu-kernel 2009-08-22
<lamont> how much pain would there be in having CONFIG_SECURITY_FILE_CAPABILITIES on in karmic, I wonder?
<jjohansen> lamont: isn't that something to wonder about before feature freeze is a couple days away?
<jjohansen> lamont: in short I think it is probably not that painful
<lamont> well, there is that....  OTOH, it just came up in discussion today
 * lamont -> bed
<pef> hello
<LCID_Fire> Hi - could anyone tell me what "EE: Previous or current ABI file missing!" means?
<LCID_Fire> It seems like it is due to cross compilation amd64->i386 - but I don't know how to sort this out
<AceLan> LCID_Fire: have you setup a chroot environment?
<LCID_Fire> AceLan: You mean pbuilder?
<AceLan> LCID_Fire: no, a chroot environment, so that you can have a clear i386 environment with the amd64 host
<LCID_Fire> AceLan: I get this error message when I attemt to build i386 on my amd64 machine as well as on launchpad!
<AceLan> LCID_Fire: https://wiki.ubuntu.com/KernelTeam/BuildKernelWithChroot
<AceLan> LCID_Fire: I read this page and setup the chroot environment, and I can compile i386 kernel on my amd64 laptop
<LCID_Fire> AceLan: you might be right - but basically launchpad sets up a chroot environment when it builds - and it still doesn't work on i386 - the build script seems to miss something having to do with cross compile
<AceLan> LCID_Fire: I'm not familiar with the launchpad :p
<LCID_Fire> AceLan: I'm not familiar with the strange way debian kernels are built ;)
<AceLan> LCID_Fire: haha
<AceLan> LCID_Fire: looks like you have abi problem while launchpad compiling your kernel
<LCID_Fire> what I don't get is - what does it need the ABI for? either it should generate it anew or it should just ignore it - very strange
<LCID_Fire> AceLan: like I said - I think the script messes up
<AceLan> https://wiki.ubuntu.com/KernelTeam/BuildSystem/ABI
<AceLan> LCID_Fire: I have no idea about the ABI problem :p
<LCID_Fire> AceLan: me neither
<dhillon-v10> iulian: hi how are you
<ghostcube> hi
<ghostcube> i just installed 2.6.31rc7
<ghostcube> the problem with the w83627 modul is still existing
<ghostcube> FATAL: Error inserting w83627ehf (/lib/modules/2.6.31-020631rc7-generic/kernel/drivers/hwmon/w83627ehf.ko): Device or resource busy
<ghostcube> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/416063
<ubot3`> Malone bug 416063 in linux "kernel modul w83627ehf doesnt load into kernel 2.6.31rc6 from mainline ppa" [Undecided,New] 
<ghostcube> anyone alive :)
<ghostcube> http://pastie.org/591711
#ubuntu-kernel 2009-08-23
<AnAnt> Hello, why  CONFIG_USB_DEVICEFS is not set in karmic ?
<hyperair> why would it be?
<hyperair> i believe i saw somewhere while configuring my kernel that it was deprecated
<AnAnt> well, I use a CAD tool that needs it Altera's programmer
<hyperair> try getting it to use /dev/bus/usb instead?
<hyperair> or better yet, bug the developers to fix it
<laga> i bet the developers *love* changing their software everytime a kernel developer decides user space should update ;)
<AnAnt> can't CONFIG_USB_DEVICEFS just be enabled ?
<hyperair> apw: ^^
<AnAnt> laga: that's sarcasm ?
<laga> AnAnt: yes.
<hyperair> laga: moer like they should have just used libusb to begin with?
<laga> hyperair: i'm not aware of the timeline, ie what was there first. 
<AnAnt> CONFIG_USB_DEVICEFS is set in jaunty
<ghostcube> hmm, i have a question. what is causing my eth1 not to be started by default on my mainline kernel 2.6.30-5. i must restart interfaces manually. Is there anything that is done on the ubuntu patched kernels that is doing this automatically? cause my nameserver that is written into ibterfaces doesnt get set at interface startup 
<hyperair> it wasn't deprecated yet.
<hyperair> AnAnt: it wasn't deprecated *then* but is *now*
<AnAnt> hyperair: you mean that even if it is enabled, it won't work ?
<hyperair> it probably would, but it's deprecated
<hyperair> why don't you compile a kernel and see?
<AnAnt> hyperair: how ?
<hyperair> there's a wiki page somewhere
<AnAnt> hyperair: apt-get source linux ?
<hyperair> no, install linux-source-<kernel version>
<hyperair> https://wiki.ubuntu.com/KernelCustomBuild
<AnAnt> ok
<ghostcube> oh well hyperair i didnt want to double post i just recognized iam not in ubuntu-kernel as ia had posted
<ghostcube> :D
<hyperair> O_o?
<AnAnt> hyperair: is that vanilla kernel ? 
<hyperair> AnAnt: the steps there can be applied for compiling the ubuntu-patched kernel as well
<AnAnt> hyperair: I mean what's the package for ubuntu-patched kernel ?
<hyperair> AnAnt: linux-source-<kernelversion>. i already mentioned this earlier.
<AnAnt> oh ok, I was asking if that package is the vanilla or the ubuntu-patched one
<hyperair> oh.
<Quintasan> Hello. I'm getting little bit tired of bug 330824, anyway I can help? The -15 kernel introduced random freezes for me -14 worked fine till I tried to copy or delete something. I'm stuck on jaunty since fglrx is not working with karmic's kernel
<ubot3`> Malone bug 330824 in linux "Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28" [Medium,Confirmed] https://launchpad.net/bugs/330824
<lessshaste> hi all
<odinsbane> greetings I was curious about using a newer kernel with jaunty is there a way to get the backport kernel modules?
<Twigaathy> yo
<Twigaathy> I just got a segfault - got this in my logs. Anybody know why this happened/what went wrong?
<Twigaathy> Aug 23 23:18:19 polaris kernel: [  599.481239] udevadm[10261]: segfault at 0 ip b7e0b613 sp bfb5dc58 error 4 in libc-2.9.so[b7d94000+15c000]<6>md: resync of RAID array md2
#ubuntu-kernel 2010-08-23
<jk-> cooloney: ping?
<cooloney> jk-: hi
<jk-> cooloney: could I get you to test my clk code on omap?
<jk-> cooloney: sorry, s/clk/debug macro/
<jk-> cooloney: the 'debug' branch here: http://kernel.ubuntu.com/git?p=jk/dt/linux-2.6.git;a=shortlog;h=refs/heads/debug
<cooloney> jk-: no problem, just a moment 
<cooloney> jk-: it's quite slow for me to git fetch, pls wait for a while
 * cooloney will upgrade his network to 4MB
<jk-> cooloney: no problem, thanks :)
<amitk> cooloney: 4Mbps? Will that really change anything? I thought the problem was due to limited bandwidth between China and US...
<cooloney> amitk: yeah, that won't change the problem here. 
<cooloney> amitk: but it's double my speed soon
<cooloney> and the upgrade is free
<amitk> cooloney: heh :) free is good
<lag> cooloney: Morning
<lag> Hey jk- amitk 
<jk-> hey lag
<lag> cooloney: ...
<lag> cooloney: You're not getting away from me that easily 
<amitk> lag: how is it going?
<lag> amitk: Chugging along, and you?
<amitk> lag: I see light at the end of the tunnel (and it is moving away from me)
<lag> amitk: Ouch! :)
<lag> amitk: My situation will improve when I catch hold of that slippery cooloney ;)
<amitk> heh
<cooloney> lag: morning man
<lag> cooloney: There you are :)
<lag> cooloney: What's going on with L24.9?
<lag> cooloney: I haven't heard anything; no emails, messages or calls
<cooloney> lag: yeah, sebjan is back
<cooloney> lag: and he is working on that, 
<cooloney> lag: i'm also waiting for that
<lag> cooloney: No worries - I'll continue to wait ...
<cooloney> lag: np, man
<cooloney_> jk-: good news, it boots fine
<jk-> cooloney_: woot! thank you for testing
<cooloney_> jk-: oh, wait, CONFIG_DEBUG_LL=y is right?
<cooloney_> jk-: i am using the omep3_defconfig
<jk-> cooloney_: yeah,  CONFIG_DEBUG_LL=y and CONFIG_EARLY_PRINTK=y
<jk-> (and maybe with 'earlyprintk' on the cmdline)
<jk-> (to give it a thorough test :) )
<cooloney_> ok, np, 1 sec
<jk-> it *should* be the same as the !CONFIG_DEBUG_LL case, but I'd like to make sure
<cooloney_> jk-: yeah, it works fine too
<jk-> cooloney_: awesome, thanks
<cooloney_> jk-: one question, 
<jk-> cooloney_: yup?
<cooloney_> jk-: if i wanna debug in a arch/arm/kernel/head.S, just wanna print out some register value,
<cooloney_> beside printhex helpers
<cooloney_> any other choice
<jk-> cooloney_: yeah, i'd suggest printhex and printascii - are these not suitable for your usage?
<cooloney_> jk-: i'm afraid that will corrupt some registers
<cooloney_> jk-: http://pastebin.ubuntu.com/482255/, booting message of your kernel
<jk-> cooloney_: yeah, corrupts r0-r3.
<jk-> cooloney_: looks good
<moldy> hi
<lag> Has anyone been working with Sony Fn buttons? I vaguely remember someone working on them recently
<lag> jk-: Was it you?
<jk-> lag: not me :/
<lag> I remember someone saying something like "I have them fixed, and I didn't even have the hardware"
<lag> jk-: Okay :(
<moldy> http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html mentions (for example) an ubuntu kernel version 2.6.34-5.14 for lucid. how would i install that kernel for testing?
<jk-> sounds like something Colin would say :)
<lag> moldy: Wait one, I'll get you the URL
<lag> moldy: You can either look them up here: https://edge.launchpad.net/ubuntu/+source/linux
<lag> moldy: If they're not there you can use your git tree to build your own *.deb
<moldy> lag: thanks, i will have a look
<lag> moldy: Our git tree: http://kernel.ubuntu.com/git
<lag> moldy: The Lucid repo: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=summary
<lag> moldy: tag 2.6.34-5.14: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=tag;h=b2c6db6e3155efd7f3af1d871c7a279f4f116d37
<moldy> could i just install a kernel .deb from maverick on lucid?
<lag> Sure
<moldy> lag: would that also install all the modules, or would i have to install them separately?
<lag> moldy: If you install the .deb, the modules will be installs with the kernel
<lag> installed*
<moldy> ok, thanks
<lag> moldy: No problem 
<lag> Hey JFo 
<JFo> hey lag 
<lag> JFo: How do you search just for kernel bugs on Launchpad?
<smb> with much despair
<lag> :(
<smb> lag, It should be possible to limit them to package linux I guess/hope
<lag> smb: You mean like this - https://bugs.edge.launchpad.net/ubuntu/+source/linux
<smb> yeah that looks ok
<lag> But then you get really random ones like bug 43531
<ubot2> Launchpad bug 43531 in linux (Ubuntu) "Kernel isn't very useful without a boot loader, but doesn't depend on one (affects: 1) (heat: 5)" [Medium,In progress] https://launchpad.net/bugs/43531
<lag> How is that a kernel bug?
<smb> Would be a bug in the packaging
<smb> And one we probably should look at
<JFo> lag, sorry, got distracted by something shiny
<lag> smb: It's 4 years old :)
 * lag is not surprised :)
<smb> Heh, yeah. 
<lag> Is Ben Collins still with us?
<smb> At least we then should check whether this is really valid
<smb> Nod
<smb> No
<lag> The last person to complain about it did so 3 years ago
<smb> Sounds like a real good candidate for getting rid of.
<smb> Though we probably need to check whether you could clean up away your boot loader
<smb> lag, You could do that in your copious spare time. :)
 * ogra wouldnt blindly close it regarding the initial reporter :)
<ogra> there should be plenty of duplicates of that one btw 
<ogra> we had a time where we had one for each arm flavour to at least recommend a bootloader iirc 
<lag> I'll assign myself to it and try to put it to bed
<lag> smb: Hmm ...
<smb> lag, Actually there is a "Recommends: BOOTLOADER" in flavour.control.stub
<smb> So this rather looks fixed by now
<jdstrand> smb: hey. I saw your email response re xen/hardy. have you gotten any upstream feedback?
<lag> smb: I have to confess, I don't know a great deal about packaging, but I guess there's always time to learn
<JFo> smb, I've added to the needs-review list so we can verify before responding and closing
<lag> What's the best way to review this?
<smb> jdstrand, I updated the bug report. There is/was an upstream discussion about this. For Hardy and earlier the code is so different that we ended up doing what the upstream code intended but was wrong
<lag> Teach me sensai
<pgraner> smb, am I correct in my assumption that the gobi-loader package is not yet in Lucid?
<tgardner> pgraner, should be universe
<smb> pgraner, It won't ever be. In Lucid all is included in lbm
<smb> tgardner, pgraner Only Maverick has the universe package
<pgraner> smb, ok, then is the lbm package there yet? I'm assuming it will be -wwan?
<jdstrand> smb: ack. don't let me keep you. ping me when you are ready and I can get it uploaded and building
<smb> Uploaded but I think not accepted yet
<pgraner> smb, ack
<smb> jdstrand, Test kernel compiling right now
<smb> pgraner, And yes, will be lbm-wwan
<lag> JFo: Should bug 525801 still be on the Top50?
<ubot2> Launchpad bug 525801 in linux (Ubuntu) (and 1 other project) "[i915] NULL pointer dereference in intel_tv_detect() (affects: 18) (dups: 9) (heat: 90)" [High,Invalid] https://launchpad.net/bugs/525801
<lag> JFo: bug 527361 - same
<ubot2> Launchpad bug 527361 in linux (Ubuntu Lucid) (and 2 other projects) "hotplug interferes with ethernet card (affects: 1) (heat: 23)" [Medium,Incomplete] https://launchpad.net/bugs/527361
 * JFo looks
<lag> JFo: bug 553498 - same
<ubot2> Launchpad bug 553498 in linux (Ubuntu Maverick) (and 2 other projects) "Dell Studio 155x hang on resume from suspend (SCI_EN) (affects: 15) (heat: 85)" [High,Fix released] https://launchpad.net/bugs/553498
<lag> I think the Top50 is out of date
<JFo> first one you gave me is marked invalid
<lag> Exactly 
<pgraner> smb, thx
<lag> Second is fixed released
<JFo> oh, you are saying the list is out of date
<JFo> of course it is
<lag> As is the third
<JFo> I was in meetings all last week
<lag> Ohhhhhhh
<lag> np
<JFo> and we had no meeting
<lag> Was getting confused 
<JFo> I see
<lag> I'm guessing the Top50 is static 
<JFo> there is a bug meeting today
<JFo> it is
<lag> kk
<smb> jdstrand, To be clear here. This is not any upstream solution as anything upstream did might be really hard to get backported and it just went into 2.6.36-rc2. We might in the long term want to fix the other issues in there. But they are different. 
<lag> You'd best get on your Python course ;)
<pgraner> tgardner, you been seeing issues with the latest maverick kernel? I'm getting real bad jitter on music playing doing normal day to day tasks, I mainly see it on window opens
<smb> jdstrand, I hope the explanation in the bug is understandable. But basically I would like to get the test kernels tested on xen (I can do normal bootup) to make sure this is really the fix.
<tgardner> pgraner, I haven't been using Maverick on a laptop whilst playing music. I've mostly been testing the Lucid ext4 stuff for stability
<jdstrand> smb: ok
<JFo> pgraner, I don't see it on my desktop
<jdstrand> smb: I have started reading https://help.ubuntu.com/community/Xen myself
<JFo> will fire up my Mav lappy to test
<jdstrand> smb: I wonder if lamont has a spare builder he could try it out on
<pgraner> tgardner, I can get it to do it every time, its on this i5 box 
 * pgraner wonders
<smb> jdstrand, There is a link to kernel trap in the bug now for some of the discussion. It has been kicked off abit earlier by someone doing xen. Though it did not sound fatal at the beginning.
<smb> jdstrand, lamont maybe can. But it sounds a bit more complicated. Have been chatting with him
<pgraner> tgardner, this box is still having huge issues with memory, it has 2 gigs and it has a half gig in swap
<tgardner> pgraner, wouldn't swapping account for the jitter? I have to wonder _why_ its swapping. are you running some huge mem hog, or you still have a leak somewhere?
<pgraner> tgardner, I have Evolution, Xchat, Chromium and Rhythmbox open, nothing big other than Chromium
<tgardner> pgraner, ok, does it jitter right after a reboot, or does it take awhile?
<pgraner> tgardner, takes awhile a few hours
<pgraner> tgardner, I just killed chromium and it stopped and it freed a ton of memory
<tgardner> pgraner, then that sounds like a leak (no pun intended)
<pgraner> tgardner, swap went down to 229meg from 500
<tgardner> pgraner, did it completely clear your swap?
<pgraner> tgardner, nope
<tgardner> pgraner, how about after 'sudo sync'
<tgardner> you really shouldn't have much in swap if all your progs are active.
<pgraner> tgardner, with 2 gigs your right, it only dropped it a hundred kb
<tgardner> pgraner, what does slabtop show? anything exceptional?
<pgraner> tgardner, 135936 135919  99%    0.03K   1062      128      4248K kmalloc-32
<pgraner> thats the top entry
<tgardner> pgraner, just reading the man page to see how its sorted
<tgardner> pgraner, 'c' sorts by cache size
<pgraner>  31956  14366  44%    0.96K   1998       16     31968K ext4_inode_cache
<pgraner> top entry after "c" sort
<tgardner> pgraner, thats consistent with tangerine which is running a lucid kernel
<tgardner> did your music stop stuttering after killing chromium?
<pgraner> tgardner, yep
<tgardner> pgraner, the evidence kind of points there, though I _still_ don't think you should be swapping
<pgraner> tgardner, me either, it was doing this in Prague and the ureadahead fix made it better, but seems to not have fixed it
<lamont> smb: yeah, I can test for you
<tgardner> pgraner, all ureadahead did was free some mem which just pushed back the time when swapping started
<pgraner> tgardner, my netbook has 2gig and it never swaps (cuz I didn't crate a swap partition on the SSD)
<tgardner> pgraner, same with mine, i.e., no swap
<pgraner> tgardner, understand, but its similiar symptoms, due to that the ureadahead I never noticed this
<tgardner> lemme wrap up a few things and I'll go play with my SSD based machine on Maverik
<smb> lamont, Currently uploading the 64bit versions to people.c.c which have been at least booting on the generic version. So 64bit should be available in a couple of minutes
<lamont> cool.  say when/where and I'll go grab it for testing
<amitk> pgraner: do you have some power save mechanism enabled for the disk? e.g. sata link controller
<pgraner> amitk, nope
<pgraner> amitk, stock out of the box
<smb> lamont, 64bit test kernels ready at http://people.canonical.com/~smb/lp620994/ , the 32bit versions will follow later (and if I may add a little whining here: it would all be quicker if I would be able to scp from tangerine to people directly :-P)
<lamont> smb: yes, I'm very familiar with that challenge
<tgardner> ogasawara_, lemme know when you're done on tangerine so I can bounce for the -security kernel
<lamont> smb: so... good news, bad news... domU boots
<lamont> Error: /usr/lib64/xen/bin/xc_restore 23 7 1 2 0 0 0 failed
<smb> Hm, any kernel errors?
<jdstrand> fyi, since lp deleted the last kernel, I made the previous hardy kernel available in ubuntu-security-proposed, with appropriate warnings etc in the bug
<lamont> [  381.653530] audit(1282571471.116:7): dev=vif7.0 prom=256 old_prom=0 auid=4294967295
<lamont> and some entries about learning, propagating, forwarding, disabled, disabled state for vif7.0
<smb> jdstrand, Yep, saw that.
<lamont> that is all dmesg has
<lamont> and daemon.log looks pretty benign
<lamont> http://paste.ubuntu.com/482411/
<smb> lamont, Darn, not very helpful. Not being familiar with xen, so what should xc_restore do?
<lamont> I'll admit to using xen, not to understanding it
<lamont> basically, the guest has a golden image that is being restored.  I additionally rebuilt said image from scratch, to the same result
<smb> lamont, Somehow the paste looks like the errors are in bringing down several interfaces. But then it claims success anyway... Confusing
<smb> lamont, Is the end result a usable DomU or one without any networking?
<lamont> I'm sshed into domU
<lamont> so that feels like "networking" :-D
<smb> lamont, Also, even if that maybe should be obvious, were those errors probably there before? :) Ok, I'd be counting this as network, too
<lamont> dunno
<lamont> http://paste.ubuntu.com/482413/ <-- smb: the previous reset of the (then up) guest
<smb> Looks shorter but also has the error about brctl failing
<smb> lamont, jdstrand I wonder whether jj knows the xen output better to tell whether this is bad or ok... 
<jdstrand> maybe. zul might as well
<jdstrand> zul: would you mind taking a look at ^
<smb> It is at least not crashing anymore. But I want to be a bit more confidence before calling this a fix
<jdstrand> smb: what I would like to do when you are ready is to build the kernel in the ubuntu-security ppa, copy it to hardy-proposed and get feedback in the bug from the reporters/subscribers
<jdstrand> smb: once we have positive feedback, I can publish to -security
<jdstrand> smb: for you, just use 'hardy-security' as the distribution name and I'll take care of the rest
<smb> jdstrand, The test kernels I am uploading to the people page are exactly that. Based of the last release and the patch added
<smb> I just did not finalize it
<smb> So the version number is smaller that the actual security release
<jdstrand> smb: sounds great. I too would like some more feedback from zul and jj
<lamont> smb: I'd be -1 with the current state
<jdstrand> smb: but when you feel they are ready for wider testing, let me know
<smb> jdstrand, Exactly. As soon as we are confident about the fix. I would finalize the source package and all. But at the moment as lamont says there might be issues and this might not be the final resolution
<jdstrand> right
<jdstrand> smb: I was just trying to communicate my plan. specifically, not going straight to -security
<smb> jdstrand, Ah, maybe missed that. Ok with that
<smb> lamont, Another question for my understanding: is the same kernel used for the host and the guest or are they different?
<lamont> same
<smb> Ok, thanks
<jdstrand> smb: oh, I missed your comment regarding test kernels in the bug
<jdstrand> smb: sorry for the confusion
<smb> jdstrand, np. we might have been adding comments around the same time
<jdstrand> yes I think so
<jdstrand> smb: anyway, people testing your kernels is just fine by me
<smb> yeah does not matter exactly from where they come. And coming from a people page might stress more on the "this is maybe not final" thing
<pmatulis> how can i troubleshoot a network module (igb) having difficulty with bonding when booting?  need to manually load 'bonding' module
<ogasawara> tgardner: go ahead and bounce tangerine
<tgardner> ogasawara, ack
<bjf> Sarvatt: wecome aboard
<bjf> s/wecome/welcome/
<Sarvatt> thanks bjf! :)
<JFo> yeah Sarvatt great to have you! :)
<vanhoof> pgraner: ping
<pgraner> vanhoof, yo
<vanhoof> pgraner: yooo
<vanhoof> pgraner: can you add ~canonical-hwe-team to c-k-t in lp?
 * pgraner looks
<vanhoof> pgraner: getting Sarvatt setup, so adding our team to yours should get him access indirectly
<vanhoof> otherwise if you want, just add sarvatt
<Sarvatt> sorry for the trouble, and thanks :)
<pgraner> Sarvatt, whats your lp id?
<Sarvatt> sarvatt
<pgraner> vanhoof, I'm going to add him as that how all the hew guys are done
<bjf> Sarvatt: that's very tricky of you :-)
<Sarvatt> :)
<vanhoof> pgraner: cool
<pgraner> Sarvatt, vanhoof: done
<Sarvatt> pgraner: thanks a ton!
<pgraner> Sarvatt, np
<smb> tgardner, tangerine bounced ok and I can use it again?
<tgardner> smb, yep
<smb> ok. ta
<JFo> bjf, do you have a minute to help me test out my desktop mumble settings in the Ad-hoc room??
<smb> JFo, I won't be able to join the bug review call as I am still busy with the xen regression
<JFo> smb, no sweat
<JFo> thanks for the heads-up
<smb> It more a head down. And sort of late... 
<JFo> heh
<ogasawara> manjo: there's a work item you have for the kernel-maverick-config-review - "investigate memory stick options and produce proposal"
<ogasawara> manjo: I actually have no recollection of what the reasoning behind that was for or the proposal that was going to be produced.
<ogasawara> manjo: just curious if you still have that on your radar? or is it something we should just postpone and readdress for Natty?
<jdstrand> lamont: you mentioned a 'pristine' image for your xen instance. how do you guys do snapshots with xen. I have xen setup here on some real hardware and am looking for anohter test case...
<jdstrand> smb: I just rebooted into the .75 kernel after setting up on i386. my trace is very similar but slightly different than what is in the report
<smb> jdstrand, Without using xen?
<jdstrand> smb: I setup hardy/xen on some real hardware with the -xen kernel. Got it all working with .73. Rebooted into .75 and have a similar but slightly different trace
<smb> jdstrand, Ok, sort of gives a test system and shows the issue. Can you pastbin the trace?
<jdstrand> smb: actually, I attached it to the bug
<jdstrand> smb: http://launchpadlibrarian.net/54226707/620994.log
<jdstrand> smb: this machine is dedicated to testing this bug atm, so just let me know what you want me to test
<smb> jdstrand, Ah ok. Seems splitup can also be a single page which then gets avoided and ends in a zero range 
<jdstrand> jjohansen: re me testing> ^
<smb> jdstrand, Basically there are two approaches. #1 don't avoid touching the guard page in mlock. Which could be used to use mlock to grow the stack
<smb> #2 implement even better testing that in my version 1 of patches
<smb> Which I am currently trying to implement
<jdstrand> I have only the highest level understanding of the issue, as I came into this CVE late in the game. I'm happy with what you decide and am able to test
<jjohansen> I think #2 is probably the way to go
<jjohansen> though /me is still trying to catchup on this one
<smb> I guess yes. (which will need some fixing in more recent kernels too). Seems in the older version I actually can make use of the fact that mlock there actually passes around the previous vma pointer.
<smb> But I need to be carefull
<jdstrand> it would seem #2 is the better of the two, since it seems closest to upstream intent
<smb> For Jaunty to Lucid/Maverick we might take the upstream version (after a bit of cooking there)
<manjo> ogasawara, I think we can move it for N
<ogasawara> manjo: ack, will get it moved.  thanks.
<manjo> ogasawara, I don't think I will have the bandwidth to do any investigation this cycle 
<manjo> ogasawara, thanks
<ogasawara> JFo: I've moved your kernel triage summit work items to have a maverick-beta milestone since a 10.10.10 milestone will be too late.
<JFo> ?
<JFo> not sure what you mean ogasawara 
<ogasawara> JFo: you had some work items for organizing the triage summit (in the kernel-maverick-bug-handling bp).  I thought you'd set the date to be sept 11 for that?
<lamont> jdstrand: lvm snapshotting.  I'm a bit fuzzy on it, but can point at the scriptages
<ogasawara> JFo: assuming that date is still correct, the work items for organizing I suspect would need to be done by maverick-beta (sept 2).
<lamont> smb: any new news?
<smb> lamont, Not finite ones. I think I got something better, but probably would let jjohansen look over the patch and then start building it
<JFo> ogasawara, oh heh yeah, sorry. my brain is moving way slow
<lamont> cool
<jdstrand> lamont: nah, thanks. it sounds like you are probably doing it outside of the xen-tools commands
<lamont> jdstrand: I'm pretty sure our use predates those commands
<smoser> hey all. is there an expected/target date for the next lucid SRU kernel ?
<bjf> smoser, it's looking like the end of next month right now
<smoser> for entry into -proposed ?
<bjf> smoser, honestly, there is a proposed in right now and then a security upload and then the following will be the next regular upload
<bjf> smoser, ack
<smoser> can i see the changelog for the "proposed in right now" ?
<bjf> smoser: is there one you are looking for?
<bjf> smoser, commit that is
<rabidsnail> Hi all.
<rabidsnail> Is there any way I can tell the kernel "don't allow this process to access swap; when I run out of physical memory, fire a signal"?
<smoser> bjf, bug 574910 is what i am hoping for
<bjf> smoser, if you are asking about the patch jj posted on friday, that's not in proposed
<ubot2> Launchpad bug 574910 in linux-meta (Ubuntu) (and 4 other projects) "High load averages on Lucid while idling (affects: 25) (dups: 3) (heat: 174)" [Undecided,New] https://launchpad.net/bugs/574910
<smoser> :-(
<smoser> yeah, i was hoping
<bjf> smoser: it's going to be at least 3 weeks before that gets into proposed, and probably not that soon
<smoser> bjf, thanks for your time.
<lag> dpkg-gencontrol: error: package linux-image-2.6.35-18-omap not in control info
<lag> What does that mean?
<smb> often that you forgot to run clean
<lag> I thought control was built by fdr clean
<lag> The scripts run clean
<smb> Then it depends whether there is the right info in debian/control.d to include that arch/flavour in the control file
<lag> Okay, I'll look into it
<smb> lag Is this a new flavour?
<lag> Thanks
<lag> No
<lag> OMAP3
<lag> I've built it 100's of times before
<tgardner> ;aglucid?
<tgardner> lag, lucid?
<lag> tgardner: Maverick
<lag> The build before it said something about a stamp
<tgardner> lag, its in the debian/control that I just generated. 
<lag> I've fdr cleaned manually and rebuilding 
<lag> Okay
<lag> I'll let you know if it's still an issue 
 * tgardner lunches
<jdstrand> jjohansen, smb: fyi-- I only have i386 available for testing the xen issue
<jdstrand> jjohansen, smb: so whenever you are ready, please also compile i386
<jjohansen> jdstrand: hrmm, okay I can install an amd64
<jjohansen> jdstrand: actually smb kicked off the compiles
<smb> I am compiling both. Though i386 is slower
 * jjohansen notes it would sure help if x86 virtualization could be nested
<smb> jdstrand, Do you have access to tangerine?
<jjohansen> smb: I don't believe he does but I can copy kernels out for him
<jdstrand> smb: I do not
<smb> jjohansen, Ok, amd64 is done already, but i386 is still doing xen, so that takes a bit more.
<smb> Also note that this is a totally untested version
<jjohansen> smb: yep :)
<lamont> jdstrand: it also didn't fit my use model.  I see the guest exist, but when we save it and then try to restore, it falls flat
<lamont> that is, when I rebuilt it (which does a wipe-n-build, save, restore), the guest was pingable for many of the steps, and then failed to restore in the end
<smb> jjohansen, jdstrand its probably not really useful, but the i386 build on tangerine finished now as well
<jjohansen> smb: thanks, I'll copy it over for jd
<jdstrand> it is quite useful to me, it is all I can test :)
<smb> jjohansen, When looking at the patches, the mistake might be trying to avoid find_vma in the checking function...
<smb> jdstrand, Only unusful insofar as lamont is not happy with the 64bit version
<jjohansen> right, I was thinking that may be an issue
<smb> I hoped that it would be possible to avoid it as do_mlock uses find_vma_prev and passes in the prev pointer.
<jdstrand> ah, I missed that :)
<jjohansen> smb: right
<smb> jdstrand, I hope with the current patch it will be relatively simple to make a version with find_vma. That could even skip the new variable and do the checking below. Just be aware not to change anything around the splitting. openvz patches break if touching that. the custom-binaries are so much fun... :-P
<smb> s/jdstrand/jjohanson/
 * smb feels like he needs to go away from the keyboard when already mixing up names
<ogasawara> slangasek: are you on archive admin duty today?  If so, could I get the 2.6.35-18.24 kernels in the new queue processed?
<jjohansen> hehe, smb go eod already :)
 * smb hears and obeys
<jdstrand> jjohansen, lamont, smb: rebooting with pre3 on i386 doesn't trace back, but gives:
<jdstrand> Error: /usr/lib/xen/bin/xc_restore 4 1 1 2 0 0 0 failed
<jdstrand> let me try with .73 to be sure
<lamont> jdstrand: different numbers here, but same answer: Error: /usr/lib64/xen/bin/xc_restore 23 5 1 2 0 0 0 failed
<slangasek> ogasawara: yes, will do
<jdstrand> jjohansen, lamont, smb: k, I rebooted with .73 with a guest that was running (ie, it triggers xc_restore on boot) with no error
<jjohansen> jdstrand: thanks
 * ogasawara lunch
<Akendo> Hi gyus
<Akendo> Someone know, about a bug by compiling a kernel with a gcc4.4 under Ubuntu 10.04? 
<bjf> Akendo: what does 'gcc --version' return?
<Akendo> root@akendo:~/kernel/linux-2.6.35.2# gcc --version
<Akendo> gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
<Akendo> Copyright (C) 2009 Free Software Foundation, Inc.
<Akendo> This is free software; see the source for copying conditions.  There is NO
<Akendo> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
<bjf> Akendo: ok, that looks like the stock gcc
<Akendo> stock gcc?
<bjf> Akendo: lucid one
<bjf> Akendo: what "bug" are you referring to?
<Akendo> Hm
<Akendo> My config to compile the kernel do not work anymore
<bjf> Akendo: then i'd suspect your config changes and no the compiler, are you saying you can't build the kernel?
<Akendo> I've tryed to compile the 2.6.35.2 but now getting after a successfully compiling the errror during the boot " no sync fs" but the same confi runns with the 2.6.34 without a doubt....
<bjf> Akendo: have you tried using our 2.6.35 kernel?
<Akendo> Was my first guess too, tried with complete new config :/ 
<Akendo> hm
<Akendo> No
<bjf> Akendo: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.35.3-maverick/
<Akendo> Hm
<Akendo> Nice :D, i will give it a try :/
<bjf> Akendo: hold on one sec. looking for another url for you :-)
<Akendo> Very kind of you ;-)
<Akendo> Don't end this in a error using a kernel from a (testing) next release?
<bjf> Akendo: I don't understand that last question
<Akendo> If i install a kernel that is for the next Ubuntu release, shout this not made an error in the current running system? 
<\_^_\> I hav esome questions regarding #616501.
<\_^_\> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/616501
<ubot2> Launchpad bug 616501 in linux (Ubuntu) "Kernel > 2.6.32-20 doesnât boot, /dev/disk/by-uuid/... not found (affects: 1) (heat: 582)" [Undecided,New]
<bjf> Akendo: could be that's why i'm trying to find you a different link, we have a "maverick" kernel on lts package that i'm looking for
<Akendo> xD
<\_^_\> Every kernel after 2.6.32-20 (Ubuntu) doesn't boot with root=UUID=.. option.
<tgardner> bjf, http://launchpad.net/~kernel-ppa/+archive/ppa
<bjf> tgardner: thanks!
<Akendo> Thanks
<\_^_\> But when I change it to root=/dev/... it works.
<bjf> Akendo: ^
<Akendo> i also use this
<Akendo> There was some errors in the history with that, don't like uuid
<Akendo> :)
<\_^_\> The hard drive is a PATA. As far as I know there was some change regarding PATA in kernel.
<bjf> Akendo: hmm, don't know about that issue, maybe tgardner is aware of it
<\_^_\> However I want to find out why this happens. So where should I start investigating.
<Akendo> I remeber this problem a time ago
<Akendo> i guess that was why i prefer self compiled kernels
<bjf> Akendo: the thing is, if there is an issue with that kernel, we'd like to know about it and get it fixed for everyone
<bjf> Akendo: that way we keep the kernel up-to-date for you (you have better things to do than build kernels) :-)
<Akendo> normaly it's just 1 min work so i dones't care. It's also easyare than running a gentoo :D
<Akendo> essayer*
<bjf> Akendo: so, that's my recommendation, not sure i helped you out or not
<Akendo> we will see
<Akendo> Was just wondering, normaly there was no problem doing it. But i has removed some old stuff an i still used the gcc-4.2 
<Akendo> i  think after switch to a newer version, he miss something ... but not sure about :/
 * jjohansen -> Lunch
<Akendo> But thanks for the help
<bjf> \_^_\: that bug has a work around specified in it, have you tried that?
<bjf> \_^_\: comment #5
<\_^_\> bjf: comment #1--#5 are mine. So I tried everything which is written there. ;)
<bjf> \_^_\: so you have a workaround, i've added it to the list of bugs that the kernel team will discuss tomorrow morning
<\_^_\> bjf: Great. Thanks. If I can do anything to help, please add a comment to my report.
<bjf> \_^_\: will do
#ubuntu-kernel 2010-08-24
<jj-afk> back on later
<syn-ack> jj-afk: Congrats on the inclusion. ;) It's finally about time! good work to you and Pete and the rest of the crew. :)
<jj-afk> here's hoping the latest upgrade doesn't break me
<jj-afk> rebooting
<jk-> ever the optimist
<amitk> heh
<jk-> amitk: http://devicetree.org/PowerDomainBindings : do we expect devices to have multiple power inputs?
<amitk> jk-: you mean a single device drawing power from multiple regulators?
<jk-> amitk: exactly, yup
<jk-> (maybe an ethernet device with a separate line for the phy?)
<jk-> although, the ethernet and the phy may be considered separate devices...
<amitk> jk-: yes, there are such devices. I think the MMC driver in OMAP (atleast the rx51 board) is one such example
<amitk> brb
<jk-> amitk: ok, thanks
<smb> jjohansen, Ok, I cannot find the way from split_vma to make_pages_present. Likely too much inlining there so see it on a glance. In the end make_pages-present is called with an addr >= end. Not sure its worth to try to understand that too much. I go ahead and build kernels for the variations we talked about.
<jjohansen> smb: I couldn't find it either
<jjohansen> smb: that is I didn't find make_pages_present in split_vma
<jjohansen> but mlock_fixup calls it directly
 * jjohansen wonders if the stack trace is broken
<jj-afk> g'night
<lamont> smb: how's things?
<dholbach> hi guys
<dholbach> can something be done about bug 622583?
<ubot2> Launchpad bug 622583 in linux-meta-rt (Ubuntu) "Remove the linux-meta-rt packages (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/622583
<dholbach> it says that another kernel was uploaded for review but never received any
<smb> lamont, Got two new variations to try... if you ain't bored of it by now. One (pre4) is on tangerine in hardy-amd64 the other I need move out of nc
<smb> dholbach, Looks like this is an archive admin question
<dholbach> smb: but the kernel that's up for review?
<dholbach> smb, the bug I mentioned it also currently stuck at a review-before-archive-admins-do-their-work level and I thought it'd be good to have the kernel team have a look at it
<smb> hm, yeah. Wonder whether that is the real rt one or moved over to preempt. Someone needs to chech that
<smb> abogani, are you around?
<abogani> smb, Yeah
<dholbach> thanks guys
<smb> dholbach, was looking at your bug above and I am not sure about the kernel for review thing
<smb> abogani, Is this the -rt version or something for -preempt that apw was trying to look at?
<abogani> smb: Lowlatency should be the preempt replace.
<abogani> lowlatency should be kernel which apw should review.
<smb> Ah ok and -rt will be continued in universe
<smb> or where ever it is now
<abogani> smb: No it is died.
<smb> Ok, so I am now well confused. :) What kernel is "An updated version was uploaded on http://kernel.ubuntu.com/git but it never receive a review." referencing in the bug report above
 * smb is still trying to get some hardy security wreckage fixed and is a bit out of any other context...
<lamont> smb: rebooting into pre4 now
<abogani> smb: Lowlatency should be replace preempt. Realtime should be replace rt.
<abogani> smb: There are only two kernels on Zinc owned by me :-)
<lamont> Error: /usr/lib64/xen/bin/xc_restore 23 3 1 2 0 0 0 failed <-- smb
<smb> abogani, This would still leave a 50:50 chance to know which kernel you mean. Though I guess as it says remove -rt it means -realtime. Did you ask someone to review?
<smb> lamont, So still no joy there.
<lamont> correct
<smb> lamont, Ok, give me a few minutes to move pre5
<abogani> smb: In any case don't bother with the -rt/-realtime, please. I give up to continue that effort.
<smb> lamont, btw have you once tried pre2 from the peoples page (or maybe still on tangerine, too)? To at least see what happens when we do not try to do anything smart
<smb> abogani, Ok, so basically the request in that bug means: Please remove any -rt kernel and meta package from the maverick archive?
<smb> abogani, And sad to hear you give up. Did we have too little time to help you there?
<lamont> smb: I haven't
<lamont>  http://people.canonical.com/~smb/lp620994/linux-image-2.6.24-28-xen_2.6.24-28.77~pre2_amd64.deb is 404
<smb> lamont, *lalala* try again
<abogani> smb: No. I would be very happy if I had received the rights to upload these packages after more than 3 years I'm working on it (that is since Feisty/Gusty and I'm the only one).
<dholbach> abogani, I can't quite remember, did you apply for those upload rights?
<abogani> dholbach, Of course Sir.
<smb> abogani, I know the process to get that is a bit long winded. Normally someone has uploaded the packages for you. The problem then is that that someone remains the same one or two people which then can give you their endorsement for upload rights. I did that for one upload but that is not really long enough
<dholbach> abogani, how did it work out?
<smb> And I am ready to admit that I fail often to review if I am not reminded daily and beaten with sticks. There nearly always seems something urgent going on. :(
<abogani> dholbach: Sorry?
<dholbach> abogani, the application process, what was blocking the application there?
<abogani> dholbach, The lacking of endorsements.
<lamont> smb: pre2 only has headers and linux-libc-dev on people.c.c
<smb> lamont, hm, ok. Need to fix that up. No idea where those went. pre5 should be there now and complete
<dholbach> abogani, that sucks - who's been your main sponsors?
<abogani> dholbach, Ben Collins and Luke Yelavich
<dholbach> abogani, I see
<lamont> smb: rebooting nao
<smb> lamont, Ok, seems pre2 I have to compile again. :-/ binaries seem have to have vanished
<lamont> Error: /usr/lib64/xen/bin/xc_restore 23 3 1 2 0 0 0 failed <-- pre5
<smb> lamont, gah!
<smb> lamont, Is in that version the guest unreachable too or can you ssh in like in pre1
<lamont> I haven't been able to ssh to any guests in anything pre1-5
<lamont> if I rebuild from scratch, I see it come up during that process, then we do a stop & restore and the restore is what fails
<smb> lamont, Hm, maybe I got that wrong then. I thought ssh was possible with pre1
<lamont> host has booted for all pre1-5, and you asked if I had networking at all: I said I had sshed in (to the host), maybe you took that to mean guest
<smb> Yeah, that was my confusion
<lamont> and by "up during the rebuild", I mean pingable from off-host
<smb> Hm ok which means we have no information at all from within the guest... I assume the guest process is not running anymore when the error occurs
<lamont> no it isn't.  we've stopped it and are trying to restore
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<ogasawara> diwic: around?  just had a quick question about two of the patches you sent that you're wanting to land in the Maverick Beta kernel...
<ogasawara> diwic: ALSA: HDA: Fix front mic on Dell Precision M6500
<ogasawara> diwic: ALSA: HDA: Add Sony VAIO quirk for ALC269
<ogasawara> diwic: I didn't see them upstream in Linus' tree, just curious if they're in Takashi's sound tree?
<ogasawara> diwic: if so, do you have the sha1's you could point me at, just so I can add them to the commits in our Maverick tree when I apply them.
<diwic> ogasawara, I'm around
<diwic> ogasawara, so these were submitted upstream yesterday and Takashi hasn't been around today
<ogasawara> diwic: ah ok.  They seem harmless enough so I'll still pull them for Maverick.  Just be sure to also submit all 5 to upstream stable.
<diwic> ogasawara, the happy users are in bug #519066 and bug #618271
<ubot2> Launchpad bug 519066 in alsa-driver (Ubuntu) "Microphone doesn't work on Dell Precision M6500 (affects: 10) (dups: 1) (heat: 70)" [Medium,In progress] https://launchpad.net/bugs/519066
<ubot2> Launchpad bug 618271 in alsa-driver (Ubuntu) "[Realtek ALC269] ALSA test tone not correctly played back = no sound at all (affects: 2) (heat: 10)" [Undecided,In progress] https://launchpad.net/bugs/618271
<ogasawara> diwic: that way when we rebase to a stable kernel which contain the patches, we'll just drop the one's we're carrying in favor of the official upstream patch.
<diwic> ogasawara, so to sum up, when I send the patch to upstream, it should have a "Cc: stable@kernel.org" in the commit message, a launchpad buglink and a sign-off?
<diwic> (assuming it's suitable for stable)
<ogasawara> diwic: yep
<diwic> okay, thanks
<ogasawara> diwic: if they went upstream without the "Cc: stable@kernel.org", just send an email to stable@kernel.org once the patch has landed in Linus' tree asking for the patch to be considered for the next stable patch set.
<bjf> diwic: this should help some, https://wiki.ubuntu.com/Kernel/Dev/StablePatchFormat
<ogasawara> diwic: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=blob;f=Documentation/stable_kernel_rules.txt;h=e213f45cf9d7505c9c9e1fbd088eb91cd83292f4;hb=HEAD
<diwic> bjf, ogasawara, thanks, I'll have something to read now :-)
<diwic> bjf, so for upstream I'd use ogasawara's link, and for the email to ubuntu-kernel mailinglist, I'd use bjf's link?
<ogasawara> diwic: yep
<bjf> diwic: ack
<diwic> Does upstream like launchpad BugLink rows?
<bjf> diwic: at this point, i don't think they mind them
<ogasawara> diwic: probably depends on the maintainer.  I haven't had issues when I've submitted patches upstream which had a BugLink.
<ogasawara> diwic: the nice thing about the BugLink is that either the launchpad janitor or our own scripts will close the bug when it gets into our tree.
<diwic> Someday when I'm feeling happy I'm going to add a switch to git commit that adds Cc: stable and BugLink lines ;-)
<manjo> tgardner, LTS backports is for servers only ?
<tgardner> manjo, that is the supported configuration, but it  seem to work well for many desktops.
<JFo> but if it doesn't we let you keep the pieces :)
<manjo> tgardner, so there are separate desktop and server kernels that you build? or just one kernel works for both?
<tgardner> manjo, the same flavours are built for both Maverick and its backport to Lucid
<tgardner> same x86'en flavours that is
<manjo> ok thanks
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - in 1 hour - #ubuntu-meeting
<bjf> ##
<ogasawara> bjf: 1hr or 2hr?
<bjf> ogasawara: you are correct, was looking at london time and not gmt
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - in 2 hours - #ubuntu-meeting
<bjf> ##
<JFo> tgardner, have you seen this? https://bugs.launchpad.net/ecryptfs/+bug/623087
<ubot2> Launchpad bug 623087 in ecryptfs "ecryptfs file permissions broken with kernel 2.6.36-rc2 (affects: 2) (heat: 12)" [Critical,In progress]
<JFo> apparently folks testing against RC1 are losing data
<tgardner> JFo, hmm, thats bad. why do we have a bug against 2.6.36 already?
<JFo> good question
<JFo> apparently some folks are doing some testing with the RC
<tgardner> I haven't even officially announced the natty repo
<JFo> heh, you know how those folks get when they get the maple syrup in them. All antsy in the pantsy
<tgardner> JFo, looks like Tyler is already on it
<tgardner> JFo, you should change the package from ecryptfs to linux
<JFo> k, will do
<JFo> ugh, sometimes I really hate LP
<smb> jdstrand, lamont, jjohansen, Just some update: I have installed xen on a test system without any guest configuration. .37 seems to boot ok (though network does not work atm), all of the prex kernels seem to crash when booting Dom0 in page_remove_rmap (which has not been looked at yet at all)
<jdstrand> ack
<jjohansen> smb: ouch, its spreading
<jjohansen> smb: have you verified whether a stack vma split by the mlock is merged back together correctly, or are we getting into a situation where the stack vma is getting really fragmented
<smb> jjohansen, Not really spreading. That is probably just the next thing that breaks. I was already somewhat scared of how this guard page might interact
<jjohansen> smb: yeah I know, it was a "its spreading like the plague" type statement ;)
<smb> jjohansen, I have not had a system up enough to be able to look at that
<jjohansen> smb: ack
<smb> There is a lot of "in theory" there atm :/
<jjohansen> yeah
<smb> ouch, page->flags = 7365696666696e does not feel too right
<smb> bjf, <chiming sound>
<bjf> smb: my clock says 3 min
<smb> mine seem to be undecided. but you are right the majority says 2m
<bjf> ##
<bjf> ## Meeting starting now
<bjf> ##
<jjohansen> chase: can I get you to look at something quick?
<jjohansen> cnd ^
<cnd> jjohansen, look at what?
<cnd> in #ubuntu-meeting?
<jjohansen> no just a sec
<smb> jjohansen, *sigh* maybe I have an idea what else could be wrong
<jjohansen> smb: oh?
<smb> jjohansen, There is also the place where the guard page is added. And that also just checks for very basic things. Which could be wrong for splitted stack vmas...
<jjohansen> hrmm, yeah
<smb> Might be worth to try. I don't want to try understand why the other thing crashes without really really needing to
<smb> And maybe something I need to understand is whether find_vma would expand any vma if it can...
<jjohansen> no find_vma shouldn't expand them
<jjohansen> my bet is its in the simple tests, that basically assume the stack is a single vma
<smb> Which makes the code looking a bit weird as there is this test for find_vma ((addr & PAGE_MASK) - PAGESIZE) != vma. if there is not yet a vma for the address below wouldn't find_vma return NULL?
<smb> but yes, the rest assumes that single vma 
<smb> ah now, the semantics is different
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - August-31 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
 * tgardner lunches
 * smb dinners
 * jjohansen -> lunch
<smb> jjohansen, lamont, jdstrand Yo! Seems pre6 finally boots in xen mode as badly as the .73 kernel did. It comes up claims to have a network but no pings go well (but as said this was before). I got the 64bit versions moved over but now pgraners tyler seems to have vanished
<smb> Hm, no reconnect works... must be network flux
<jdstrand> smb: I had networking going here with dhcp, so I can test that
<jdstrand> smb: do you have i386 builds?
<smb> jdstrand, Yes, but not (yet) for you. Those need moving
<jdstrand> smb: k, just ping me and I'll test
<smb> sure
<jdstrand> smb: thanks for all your work on this :)
<smb> jdstrand, Heh, well I broke it, so I have to fix it. :) Though it rather was upstream/Linus.
 * smb wonders whether the more recent kernels really work with xen
<jdstrand> it would be worth testing
<smb> jjohansen, Did you have time to test the ec2 kernels of security?
<jjohansen> smb: I haven't yet, I will try it today, but I expect they will fail
<smb> Hrm, we might have been a bit quick with the release here. We really should make sure we await at least feedback on the ec2 kernels before claiming the release is good.
<jjohansen> smb: sorry, its one of those things, I meant to test, and then it slipped through the cracks
<smb> But maybe Lucid or Karmic mm is broken in a way that it handles the badness better. Though the last bug I fixed now would cause asummption of ENOMEM when looking at split vmas of the stack. Well, its not only you having forgotten to do the test. Its also kees and jdstrand to be careful to have all oks.
<smb> jdstrand, Ok, pre6 i386 versions now on people.c.c/~smb/lp620944
<jdstrand> smb: ack
<smb> jjohansen, If you are interested doing a second glance over the patches of pre6, I put them to chinstrap (0005 + 0006)
<jjohansen> smb: okay, I'll look at them as soon as I am done testing on EC2 :)
<smb> jjohansen, wfm :) thanks
<jjohansen> hrmm, Lucid boot testing passed with the security kernel, I expected problems
<jdstrand> smb: .77 i386 generic passed qrt test-kernel*
<jdstrand> smb: still testing -xen, but so far so good
<smb> jjohansen, Well, there is a lot of other things different. Could be even differences in what userspace does
<jdstrand> smb: I can say for sure that networking works just fine, and so does xc_restore
<smb> jdstrand, \o/ :)
<smb> I'd probably give it to lamont tomorrow and then prepare packages to upload. Question is whether we want to do similar fixes to Dapper even as xen does not exist there.
<smb> jdstrand, Maybe something to discuss with kees
<jdstrand> smb: how similar is the code in dapper?
<jjohansen> jdstrand: were you doing anything special to tickle xc_restore?
<jdstrand> jjohansen: I start a vm, then reboot the host. it will trigger a save on shutdown and a restore on boot
<smb> jdstrand, very similar. I believe between hardy and dapper there was not much change.
<jjohansen> jdstrand: right
<jdstrand> jjohansen: an easier way would probably be to look in the initscript
<jjohansen> jdstrand: nope reboot, and stop for ec2
<jdstrand> smb: we can discuss with kees when he comes online, but my feeling is we get hardy fixed, see how it goes and then consider backporting hardy's patches to dapper at the next security update
<smb> jdstrand, I think we probably should do it as this now might leave the loophole of allowing a user-space app which partially locks the stack to crash things. Maybe its worth to make a test case for that
<smb> jdstrand, But yes, first hardy and see, then look forward
<smb> 11pm... /me thinks its a good time for eod
<jdstrand> smb: have a good night. thanks again
<smb> np. somebody remind me tomorrow to update the bug. :)
<jdstrand> smb: do you want me to point people at pre6 so they can maybe test through the night?
<smb> yeah that sounds like a good idea
<jdstrand> k
 * lamont fetches pre6
<lamont> Error: /usr/lib64/xen/bin/xc_restore 23 10 1 2 0 0 0 failed <-- jdstrand, smb, et al.
<lamont> that's pre6
<lamont> there was a known issue with lucid vs xen at one point
<lamont> sigh.  let's see if ACTUALLY REBOOTING INTO PRE6 works better for me.
#ubuntu-kernel 2010-08-25
 * abogani waves
<abogani> apw: Are you around?
<RAOF> He's on holiday, isn't he?
<jj-afk> yes he is on holiday this week
<abogani> Ok Thanks!
<diwic> this is just a long shot, but does anybody know if the latest lucid kernel upload (somewhere around 12 - 16 aug?) had something in it which could break ACL permissions? 
 * smb yawns
<ikepanhc> smb: good morning
<smb> ikepanhc, good morning
<smb> lamont, If you are around: pre6 finally seems one that loves us
<ikepanhc> smb: last time we talk about if there are hardy proposed upload, then I can rebase netbook-lpia and wait for 1 week (normally) making sure no big regression..
<ikepanhc> smb: I saw you have a security release on hardy last friday.. any suggestion for netbook-lpia branch?
<smb> ikepanhc, I would wait with Hardy atm
<ikepanhc> smb: atm?
<smb> ikepanhc, We are currently (and maybe have by now) to resolve a regression that shows up when using xen
<smb> at the moment
<ikepanhc> smb: oh....
<smb> ikepanhc, I had some proposed uploads there but let the be removed. I guess there will be another security upload to fix things
<smb> ikepanhc, "rmadison -asource linux" would show you all versions currently in the archive of the linux source package
<ikepanhc> smb: thanks, trying
<smb> It can take more arguments for filtering even more, you would need to play around what is best
<ikepanhc> smb: I can write a script to record the version string
<ikepanhc> smb: if there is any update, I will have the notify
<smb> right, that way you won't need to watch it yourself
<ikepanhc> smb: great tool, thanks
<smb> eh, np. :)
<ikepanhc> smb: but it does not show the hardy-proposed, only hardy-update
<smb> Because currently the proposed pocket is empty
<ikepanhc> smb: oh
<ikepanhc> smb: thanks
<smb> If there is something in proposed it will show up
<ikepanhc> smb: package in proposed will be remove after some time? (guess 1 or 2 weeks)
<smb> I am not exactly sure how quickly this is but basically when it is moved to updates.
<lamont> smb: pre6 is love. thank you.
<lag> What #channel would it be best to ask about video editing?
<amitk> lag: #ubuntu to start?
<lag> amitk: Done
<lag> amitk: It's going well 
 * lag whistles 
<amitk> lag: if they haven't kicked you out yet, then I guess it isn't a bad place to start ;)
<lag> amitk: Why would they kick me out?
<lag> amitk: They can't kick me out, "I am the law" :D
<amitk> lag: for being offtopic or something... 
<amitk> lol
 * ogra thought you are the lag
<amitk> lag is all the scheduler bugs we have :)
<lag> ogra: You were told off for cracking rubbish jokes yesterday in the meeting room!
<ogra> hey, i didnt pick your nick :P
<lamont> smb: fwiw, osmium is back in the building game, running pre6.  how soon do we get a kernel-nami
<lamont> ?
<smb> kernel-nami?
<lamont> long story.  how soon should we expect to see a new kernel in -updates or so?
<amitk> multiple kernel build requests? :)
<smb> lamont, That depends on some other tests that John wanted to do with ec2. But when we think this set is good I would assume this gets released as a security update
<lamont> smb: cool.  eta on that? or is it "blocked on John, bug him not me"?
<Akendo> HI
<smb> lamont, Hard to say. Actually osmium being up again with that seems good enough to go forward. But in the end its the security teams call
<smb> So probably today or tomorrow
<lamont> \o/
<jdstrand> smb, lamont: this should definitely go through -security. a -security update regressed xen, so a -security update should fix it. that said, if you want it to have wider testing, we can build it in such a way as to have it copyable to -security but go through -proposed first
<jdstrand> smb: I've done boot and qrt tests for -generic and boot and xen tests on -xen for pre6, and it all seems good
<lamont> jdstrand: I'm happy with it, osmium is happy with it, though I'd like to see it finish the current build and start a new one or 3 before going +1 all over it
<smb> jdstrand, I think one of the ppa builders is a pretty good testing. The only thing we might want to find out is John mentioning some problems with ec2.  I also seem to fight something but that seems to be related to the phase of the sun, luck and using a desktop install on a laptop 
<jdstrand> smb: what are you fighting? the network thing?
<smb> jdstrand, That (though that was on .73 too) and that this afternoon the boot crashes again in unmap_vmas when doing some hald-addon-dell 
<smb> Its the same pre6 kernel that seemed to boot yesterday
<jdstrand> smb: hmm
<jdstrand> smb: was the unmap_vmas crash with -generic or -xen?
<smb> jdstrand, That is with xen (when trying to bring up dom0)
<jdstrand> smb: but it isn't a reliable crash?
<smb> At the moment it seems relatively reliable. Though one of the boots went past it to hang in graphics. I try to go back to .73 and do a few reboots there
<smb> jdstrand, Phew, it seems at this time of day even the old .73 kernel crashes
<jdstrand> I'll install ubuntu-desktop on my i386 too
<jdstrand> oh, well, no regression :) I'd like to test locally too
<smb> No it (luckily) seems not
<jdstrand> smb: now, if we start building it soonish, I could maybe get it out today. I realize we want jj-afk's input, but we could start building assuming that he will ack it, with the understanding that we would pull it if he nak'd it. otherwise, it would likely be tomorrow. I'm fine with how you want to handle it
<smb> jdstrand, I think we are at least quite positive (now that the old one crashes too) to have at least an improvement. I would say we should at least go ahead and initiate the build, even if we have to abort/throw away the builds.
<smb> I will go ahead and make a source package for you
<jdstrand> smb: that was my thinking. thanks
<akgraner> apw, ping
<tgardner> akgraner, he's on vacation for another week
<ogra> tgardner, hey
<akgraner> tgardner, ahhh ok  - my computer over heating again :-(  he told me to let him know if it keeps happening
<tgardner> akgraner, hold it under the kitchen tap for awhile. that'll fix it.
<tgardner> ogra, whats up?
<smb> We normally suggest the fridge...
<akgraner> tgardner, hehe I sure it will one way or another ...
<ogra> tgardner, will we get the scurity fixes from kees into omap4 ?
<ogra> (we discussed that in a call yesterday and i wasnt sure)
<tgardner> ogra, I told kees I would do it when I get the 2.6.35 kernel from TI
<akgraner> hehehe - I'll poke around with it some more and get everything documented and wait for apw to return them :-)   Thanks tgardner
<ogra> ah, perfect
<akgraner> s/them/then
<smb> jdstrand, chinstrap:~smb/security has some files waiting for you :)
<jdstrand> smb: thanks!
<boing00> hi
<boing00> is it somehow possible to bind all kernel processes to one core?
<jk-> boing00: no, they're mostly per-CPU
<boing00> yes I found some exist once per core
<boing00> no way to not have that?
<boing00> is there a realtime patch maybe?
<manjo> sconklin, kiss tickets for the san antonio show in sept is around $300 ... pretty expensive 
<sconklin> huh, I wonder if I could still get access. I know that once in the facility I can get to the dressing rooms, because they still have the same security guys and I know them
<smb> jdstrand, So at least running a server install, I get no crash _and_ network. Maybe things there get confused by the fact that network is started by NetworkManager later and has no configuration in the usual places
<jdstrand> smb: that sounds totally plausible
<jdstrand> smb: so the kernel is building
<smb> sounds good. Lets see how jj-afk gets along if he comes on and how lamont feels 
<jdstrand> smb: also, what do you think about changing the permissions of ~smb/security on chinstrap? the directory is 755, I propse 750, but the group to use is not totally clear. perhaps some kernel-team group? ubuntu-security would need to be added to it though
<smb> jdstrand, Doing 750 is simple. But i think that would be ok as none outside should be there
<smb> jdstrand, So ok, I made it kernel_devs which you and kees are incidentally already members
<jdstrand> smb: sounds perfect
<tgardner> smb, sconklin: would one of you review my last Lucid LBM pull request (and get it uploaded). There are some folks waiting on it.
<smb> tgardner, I might just have gained a bit of spare time
<tgardner> smb, its a total hack (as is most of LBM), but it fixes the atl1c issue
<smb> I think I read a bit on it just not the details. Latest atl1c was not recent enough
<tgardner> nope
<tgardner> bjf[afk], you around yet?
<bjf> tgardner: sorry, yes i am
<tgardner> we were gonna have a chat about stable stuff, right?
<bjf> tgardner: yes, i think sconklin and i are ready
<smb> tgardner, Looking only at the packaging change only this looks so much like custom-binaries. And I thought we would be rid of them when hardy goes... :-P
<tgardner> smb, I know, ugly as hell
<lamont> smb: fwiw, osmium has several builds under its belt at this point with pre6.  +1 from me
<jjohansen> smb, jdstrand: when that isn't the networking problem I was having on ec2
<smb> jjohansen, We were waiting for your results here, too. Did you have time to look at it again?
<jjohansen> smb, jdstrand: I booted server based instances, and instances with the regular kernel would boot, but pre6 would get stuck when they tried to contact ec2-services
<jjohansen> smb: not, yet it turned out to be more than a couple hours sleep :)
<smb> jjohansen, My problem with network seemed to come from the desktop installation. The server install works good here
<jjohansen> smb: I am bundling up the pre security fix kernel for a test now
<jjohansen> smb: good to know
<jdstrand> networking was solid here as well
<smb> My guess is it needs /etc/network/interfaces set up sanely
<smb> which is not the case with NetworkManager doing things later
 * jjohansen wishes that they would fix network manager to work for console as well
<lamont> jjohansen: servers shouldn't need network mangler
<jjohansen> lamont: no they shouldn't, but there are cases where desktops fail and networking should just work from the console
<lamont> yep
<lamont> I would like it if the machine were at least usable remotely before the local user logs in
<jjohansen> yeah that is another thing I would like
<jjohansen> and I would like wireless to work properly from the console without login too
<jjohansen> smb, jdstrand: so the .73 kernel on EC2 is hanging at the same place waiting for ec2-meta data
<jjohansen> The kernel definitely boots to that point, and I don't believe the -pre6 kernel is the problem
<jdstrand> jjohansen: thanks for testing. I think this means that .75 regressed no more than .77 would on ec2
<smb> So again bad but no regresssion after .73
<jjohansen> right
<jjohansen> so its good to go
<jdstrand> smb, jjohansen, lamont: are you guys ok for me to get .77 out then?
<smb> ok
 * jjohansen needs to figure out what is failing in hardy ec2
<jjohansen> jdstrand: ack
 * lamont is +1
<smb> jdstrand, You, kees and me need probably take some time to think on dapper, jaunty, karmic and lucid (though lucid would get a change through upstream stable as it looks)
<jdstrand> smb: sounds fine. kees is traveling today. like we said yesterday, maybe revisit for the next -security update?
<smb> jdstrand, That sounds like a plan. We just need to make some decision about how to proceed. In Dapper we likely want the same patches as in Hardy. Lucid would get upstream changes through stable which also include a change to introduce double linked lists in vma structures. This sounds potentially dangerous for Karmic and Jaunty. So maybe we want something in between
<jdstrand> smb: ack
<jdstrand> I will test the actual builds for hardy after i386 is done. that is likely ~4 hours
<lamont> 4 more hours?
<smb> jdstrand, Sounds good. I probably will try to be eod at that point today
<smb> lamont, Lots of kernels
<jdstrand> lamont: there is a fairly good chance I won't get them published tonight do to i386 taking so long and 'real life'. that said, I can pocket copy them to ubuntu-security-proposed or otherwise make them available to you
<lamont> jdstrand: I have access to where they're building
<jdstrand> oh duh
<lamont> being on the team and all
<jdstrand> I forgot
<jdstrand> hehe
<smb> lamont, -rt, -openvz, -xen and the usual -386 and generic and server and virtual....
<lamont> mostly as a lurker, to be fair
<jdstrand> lamont: well, there you go then :)
<jdstrand> smb: just so we are clear-- this was not an ABI bumper, correct?
<lamont> jdstrand: you might find better happiness in the future if you manage to nudge the build onto roseapple instead of vernadsky/etc
<smb> jdstrand, nope
<jdstrand> lamont: I'm not sure how to do that
<jdstrand> and by 'not sure' I mean "don't know"
<lamont> jdstrand: it involves talking someone into putting i386 on manual and then scoring your build through the roof and then going back to auto
<lamont> IOW, fugly pain
<jdstrand> heh-- noted
<lamont> and should probably only be done when you're totally behind the 8 ball
<lamont> and having said that, roseapple joined the game today, after your build started.
<slangasek> does anyone here know if the linux-fsl-imx51 kernel package should be kept around for maverick?
<slangasek> AFAIK it's not being used for any images this cycle; I'm guessing it should be pruned
<slangasek> (the subject has arisen because linux-linaro has just added an imx51 flavor to /its/ builds, and it's all getting to be a few too many kernels, I think)
<slangasek> smb: you seem to be the ast uploader of this package (to lucid-security) - do you know or have an opinion?
<smb> slangasek, I am not sure about any users here, I would probably ask in mobile and arm. But I would not cry too much if it goes
<slangasek> bjf: actually, I see that your kernel meeting notes from yesterday mention fsl-imx51, but I'm not sure how to interpret what's written :)
<slangasek> smb: ok
<bjf> slangasek: i believe it's just Lucid, we don't have a topic branch for fsl in mav
<bjf> slangasek: the meeting notes were referring to on going work in the Lucid fsl banch
<bjf> s/banch/branch/
<slangasek> bjf: right, the package is automatically carried over to maverick from when the archive opened - and in fact, the version in maverick is missing at least two security updates that are in lucid-updates
<slangasek> bjf: oh - I misread the fsl-imx51 header as attached to the line above it, sorry
<bjf> slangasek: consensus here seems to be it can be pruned
<slangasek> bjf: I was trying to figure out how you would move the mvl-dove branch forward into maverick frsl-imx51! :)
<slangasek> bjf: great; I'll double-check with #ubuntu-arm and then do the needful
<bjf> slangasek: very carefully
<slangasek> bjf, smb: thanks
 * smb is out
 * ogasawara lunch
 * jjohansen -> lunch
<lamont> woot!  kernel bulids finished.. <-- jdstrand 
<lamont> even ia64 :-p
<jdstrand> I unfortunately have to leave in 10 minutes...
#ubuntu-kernel 2010-08-26
<amitk> morning all
<ikepanhc> amitk: good morning
<jjohansen> morning amitk
<amitk> hi ikepanhc, jjohansen 
<ikepanhc> jj never sleep...
<amitk> security people never can...
<amitk> ikepanhc: I hope you meant vacation instead of vocation in your email. Vocation is just more work :)
<ikepanhc> eh.....
<ikepanhc> ahley
<ikepanhc> I must need more coffee
<ikepanhc> next time I will write "day off"
<ikepanhc> I sent two mail because after push the sent, I found my phone number is wrong... seems not only number is wrong
<amitk> heh
<smb> morning all
<RAOF> Good morning.
<AceLan> good morning
<RAOF> Hm.  Has the kms-disablement sauce for i8xx chips got lost somewhere in the Maverick changes?
<smb> Guess we would need to use the SOURCE for that. :-P
<RAOF> Perhaps I could phrase that in a slightly less passive way: Hm.  The kms-disablement sauce appears to have got lost somewhere in the Maverick changes.  Is this intentional?
<smb> I probably can find out who committed the change, but I would not remember (if I ever knew) why.
<smb> RAOF, So those rather seem to have vanished in either a rebase or rework of the tree. I think the best option here is to ask ogasawara when she comes online.
<RAOF> Will do.  Thanks.
<jjohansen> smb: what do we need to do to kick the mainline builds?
<smb> jjohansen, We should not need to do anything. Do we miss one?
<jjohansen> smb: hrmm, I'm not sure.  I am trying to figure out what is meant by "due to the kernel-package in ubuntu being broken once again, I can't build myself"
<jjohansen> https://bugzilla.kernel.org/show_bug.cgi?id=16711
<ubot2> bugzilla.kernel.org bug 16711 in ext4 "Oops with 2.6.36-rc1" [High,New]
<smb> jjohansen, Need to look at the bug, maybe meaning the source package...
<jjohansen> right maybe
<smb> jjohansen, Is he really comparing 2.6.35-rc2 with 2.6.36-rc1???
<jjohansen> smb: I believe so
<jjohansen> he report 36 rc1 and rc2 fail
<smb> cannot see 36 rc2 from the upper level (if not hidden in the links)
<jjohansen> smb: yeah mean neither I assum he did something manual for rc2
 * jjohansen questions the rc2 bit altogether
<smb> Well on the rc2 side of it is 35 not 36
<smb> at least in the text
<smb> what he may mean is probably different
<jjohansen> his last comment he mentions both rc1 and rc2 oopsing
<jjohansen> first comment .35-rc2 works
<smb> ah I see in the jpeg
<jjohansen> yeah
<jjohansen> I'll get him to clarify what is broken with the ppa
<jjohansen> better than wasting time guessing
<smb> I would not really be worried about a -rc1 oopsing,  I rather be surprised it boots at all
<smb> I thought apw changed it to have patches
<smb> but let me check
<smb> jjohansen, mainline build -rc2 is actually there
<jjohansen> smb: well I am not particularly worried, I pretty much ignore anything before -rc3
<jjohansen> ah cool, I haven't really poked
<jjohansen> My first concern was potential AA bug
<jjohansen> second was kernel packaging being broken in some way
<jjohansen> I would much rather him do the bisecting on something broken than us :)
<smb> No I guess its "how can I compile the same"
<smb> It should be possible with git and the patches that now are added
<smb> Andy removed the source package as that was often useless
<jjohansen> hrmm, /me is going to have to look into the packaging changes sometime
<smb> jjohansen, Basically from the BUILD.LOG you get the sha1 -> 76be97c1fc945db08aae1f1b746012662d643e97
<smb> (which is Linus -rc2 commit in this case)
<jjohansen> ah, sha1 for upstream kernel is good :)
<smb> Then there are now 5 patches to add debian packaging and configs and whatnot.
<jjohansen> gah, /me needs to look into overheating I've had my laptop shutdown twice today because of it
<jjohansen> and the one time I had the cpu locked to low 800 MHz
<smb> jjohansen, nast, you may be the hero of akgraner then. She got that too 
<jjohansen> heh, only if I figure it out
<jjohansen> at least its easy to replicate
<smb> Do fans at least try to cope with it or do they remain on low speed?
<jjohansen> just let the flash player run :(
<jjohansen> it seems they are remaining low speed
<jjohansen> at least the time that I had the cpus locked to their lowest freq
<smb> If the temp goes up I would expect them to go faster
<jjohansen> yes, I would too
<smb> Can be fun to track that. I think there have been cases which were a sde effect of accessing the ec the wrong way
<jjohansen> yeah, it can be bios (unchanged), ec, acpi, ...
<jjohansen> every stupid machine is different
<smb> Yes, sadly
<jjohansen> These are the frightening messages I get
<jjohansen> Aug 25 18:49:20 ortho kernel: [ 5178.678361] Critical temperature reached (128 C
<jjohansen> ), shutting down.
<smb> At least thermal shutdown happens at some time. Though 128 seems a tad too high
<jjohansen> yeah, quite hot
<jpds> ls
<guest1> I got a problem running kernel 2.6.35 in Ubuntu 10.04
<smb>  guest1 It might help to say what the problem is...
<guest1> PS/2 Keyboard and PS/2 Mouse dont work with X window system after I boot with 2.6.35 (custom compiled).
<smb> Have you tried the backport 2.6.35 driver that is pre-compiled? In the kernel-ppa I believe
<smb> https://launchpad.net/~kernel-ppa/+archive/ppa has a linux-maverick
<smb> Actually I meant kernel when saying driver
<guest1> No. Actually I have an AMD Athlon II 245 system. Ubuntu work just perfect with the default kernel i.e. 2.6.32-24-generic. I downloaded kernel 2.6.35 from kernel.org and recompiled. Everything works fine in text mode. After running X, KB and mouse wont work.
 * smb wonders why someone would compile a kernel when the default system works
<smb> And using a custom compile you may end up with options set differently which mean probably some drivers not configured...
<guest1> But I want to try Ubuntu with 2.6.35. Plz help.
<smb> See ppa
<smb> That is a 2.6.35 kernel
<guest1> Ok. I will check that out. Thanks for the help.
<jcrigby> tgardner, just got your email
<jcrigby> tgardner, when is drop dead time for sending you different update
<tgardner> jcrigby, that really has more to do with the beta freeze rules from Linaro
<jcrigby> ok
<jcrigby> let me look and see if I can figure out what went wrong with the merge
<jcrigby> I'll get back to you
<tgardner> jcrigby, ok
<jcrigby> what is lirc btw?
<tgardner> jcrigby, infrared controller
<jcrigby> ok, I saw some noise about that on kernel team list
<ogasawara> RAOF: hi, just want to confirm with you the kms-disablement patches you're referring to are the following 6 patches - http://pastebin.ubuntu.com/484007/
<ogasawara> RAOF: as they do indeed appear to have been dropped from Maverick, now to investigate/remember why
<jcrigby> tgardner, I just did a git diff of my head and don't see any missing debian stuff.  http://pastebin.ubuntu.com/484025/
<jcrigby> tgardner, sorry diff of my HEAD and Ubuntu upstream
<tgardner> jcrigby, I have 2 trees; Linaro-2.6.35-1003.7 and Ubuntu-2.6.35-19.25 checked out into separate directories. diff those to see what you come up with.
<jcrigby> ok, maybe I sent you a bad pull request the linaro version should be 1004.8
<tgardner> jcrigby, or maybe I forgot to 'reset --hard FETCH_HEAD'. doh!
<tgardner> diffing again....
<jcrigby> I was wondering about that.  How to format a pull request that is a complete rebase
<tgardner> jcrigby, ok, my bad. I totally screwed the pooch. its looks good to me.
<jcrigby> tgardner, wonderful
<jcrigby> tgardner, that is great news
<jcrigby> and yes it did boot on beagle
<jcrigby> tgardner, btw do you guys stop rebasing now
<jcrigby> for maverick that is
<tgardner> jcrigby, thats a bit up to ogasawara, but usually we won't reorder anything after Beta that has a tag.
<jcrigby> ok, just hoping to avoid another mega rebase for awhile:)
<ogasawara> tgardner, jcrigby: I actually have taken the approach to still rebase onto any upstream 2.6.35.y stable release
<jcrigby> thats, fine.  It gets easier each time I do this
<tgardner> jcrigby, besides, rebases are good for the soul. it forces you to look at conflicts.
<jcrigby> good point
<jcrigby> I suppose I should try out git rerere so I can remember confict resolutions automatically
<bjf> is there a way to look at the buildd queues, i'm curious to why it's taking so long before my source uploads are building
<tgardner> bjf, you're meaning the PPAs, right?
<smb> httos:launchpad.net/builders
<smb> errr
<smb> https://launchpad.net/builders
<tgardner> hmm, thats kind of a handy link
<bjf> tgardner: yes, and smb, thanks for the link 
<smb> welcome
<bjf> smb, is there a link that shows the amd64 ppa job queu (so I can see exactly where I am in the queue right now)?
<smb> bjf, I don't know a good one, only the general build score, but that does not really mean much
<bjf> smb, ack
<smb> maybe lamont knows some magic that apprentices can use
<lamont> bjf: the ppa queue is not exposed in the api... /ubuntu/maverick/amd64/+builds (or maybe /u/a/m/+b) is the queue for a given distroarchseries
<lamont> and laggy in a meeting
<jdstrand> smb, jjohansen, lamont, elmo: fyi, I just unembargoed the fix for xen
<lamont> jdstrand: woot.  I'll kick them ppas shortly
<smb> jdstrand, Cool
<jdstrand> smb: nice work. I know that was rather painful
<jdstrand> smb: and thank you again :)
 * lamont remembers to wait for the publisher run
<jjohansen> jdstrand: thanks, and smb yes very nice work
<smb> Sort of a Murphy issue, anything that could be wrong was wrong. o_O
<smb> tgardner, About the packaging, maybe we should ask about that. Probably the replaces is not needed because the 35 package is not an upgrade path to the 34 package. But maybe I have not grasped the whole concept
<tgardner> smb AFAIK the conflicts forces you to remove the conflicting package _first_ before you are able to install the new package. thats the primary behavior I'm interested in.
<smb> Right and the Replaces causes the old one to get actually removed when you are updated via the meta files. I just want to prevent us showing the next package and being told of again
<tgardner> smb, I'm reading the Debian policy manual...
<tgardner> smb, but there is no meta file upgrade path. you'll have to explicitly change from compat-wireless-2.6.34 to compat-wireless-2.6.35
<tgardner> smb, another issue with replaces is that it only replaces files, not packages.
<smb> right, that would be point to have that requirement only for compat-wireless-2.6.34 as that will upgrade
<smb> hm, I probably should read the manual myself
<ogasawara> lag: I'm adding your SOB to the arm patches for 613855
<tgardner> yes, so I think the current combination of conflicts and replaces is correct.
<tgardner> smb, http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
<lag> ogasawara: That would be fine, thank you
<smb> So thats the 7.6.2 usage
<tgardner> I think so, though I don't really understand the mail-transport-agent example
<smb> Its a bit complicated because its for virtual packages
<smb> But I think it declares to provide bla and conflict and replaces it. So when you install this packages it would uninstall all other packages that provide bla
<tgardner> well, I think I want the behavior to be explicit. no automatic replacement, etc. you'll have to explicitly remove the conflict.
<smb> Most of the time yes, so the only time this should happen is when I have lbm-wireless-generic installed and the new meta package points to lbm-compat-wireless-...
<tgardner> smb, correct.
<smb> Which is what is done so you were right that only the conflicts is needed for the other package
<smb> I got it now as well
<tgardner> once we're on to the next ABI series, then this is no longer a problem
<smb> right, if people want to change, they should make that decision knowingly 
<smb> And I think that would be all we were asked to. I would just take what you had pushed and make the adaption for the conflicts and buglink
<tgardner> don't I have a public buglink? or did I get the wrong one?
<smb> No I thought you said you forgot to add a buglink on the latest patch
<smb> I mean yes you have the public bug in the mail
<tgardner> I amended and re-pushed
<smb> ah ok
<smb> Then lets do lbm try 3
<achiang> can someone help me to understand kernel package names vs. the actual kernel binary? output from dpkg -l gives, e.g. linux-image-2.6.32-24-generic           2.6.32-24.41, 
<achiang> so from that, i understand that 24 is the ABI version and .41 is the build number
<tgardner> achiang, so far, so good.
<achiang> my question is, in practice, do we ever increase the build number without also changing the ABI?
<achiang> e.g., would we ever ship a 2.6.32-24.42 ?
<tgardner> achiang, no, though the build number is completely arbitrary, the ABI number is not.
<tgardner> oh, lemme back up a littlwe
<smb> But we increase the build number without abi bum
<tgardner> yeah, what smb said
<smb> In fact we know should have an 2.6.32-24.42 in proposed
<tgardner> bump*
<smb> yep
<achiang> ok, i think i understand. all kernel updates that do *not* require an ABI bump will simply have an increased version number, which dpkg --compare-versions would understand to be greater, right?
<achiang> and that's how apt would know to pull down and install the new, updated package?
<tgardner> achiang, correct
<smb> yep
<tgardner> achiang, and when the ABI bumps, then we update the meta package so that it references the _new_ package
<achiang> is there any way to get the ubuntu version number out of vmlinuz? or is that only stored in the debian packaging?
<smb> The build/upload number _always_ increments, though not always by 1
<achiang> nod
<smb> You see it in uname -a
<tgardner> and in /proc/version_signature
<achiang> smb: no, you only see the package name, not the version string
<smb> Linux maximegalon 2.6.32-25-generic #43
<achiang> maybe my terminology is messed up
<achiang> oh!
<achiang> duh
<smb> So this is 2.6.32-25.43
<achiang> darn, i can't pass an arbitrary kernel path to uname
<smb> err, why would you want to do that?
<achiang> tgardner: smb: ok, thank you for the explanations, they make sense.
<achiang> smb: i am doing some evil stuff for an OEM customer's customized system update tool. don't ask, it's horrible.
 * smb puts his fingers into his ears
<achiang> smb: well, conceptually, i want to know: "is this kernel newer than that kernel?"
 * smb still cannot hear achiang 
<achiang> where "this kernel" might live somewhere in the filesystem (not /boot/) and "that kernel" is typically the one in /boot/
<smb> But yeah, basically you can compare version numbers, newer always inclrements. With the + and ~ magic of course
<achiang> but the version numbers don't really live anywhere, except in the debian packaging; or by combining some fields from uname
<smb> so 2.6.32-24.41~pre1 comes before 2.6.32-24.41 
<smb> Well that information is in the kernel image too. If you boot you see it. In dmesg
<achiang> but certainly, if you saw /boot/vmlinuz-2.6.32-24-generic you could not figure out if it was newer or older than /my/special/path/vmlinuz-2.6.32-24-generic
<smb> not from that filenames alone
<achiang> because the kernel in /my/special/path might have a greater version number, but it's not easy to figure out. unless maybe you use strings and grep
<smb> right strings and grep will work
<achiang> is there a case to be made for incorporating the version number into the file name (instead of merely package name) for generic ubuntu? or is my use case truly unique?
<achiang> obviously not for this cycle, but for future cycles
<smb> no, as the parts that are used now are used for modules dir and we certainly don't want separate directories for each upload
<achiang> i guess basing the filename on package name makes life a little easier in the non-ABI change case
<achiang> ah, that makes sense too, re: modules
<smb> I guess this is just a very special usecase, but I tried strings/grep and it looks quick and simple (as long as you are not truely evil and want to do the same for old releases like Hardy ;-))
<achiang> smb: actually, yes, i sadly do need a solution for hardy as well
 * smb runs away
<achiang> smb: hm, strings seems to work on a hardy kernel
<achiang> strings vmlinuz-2.6.24-27-lpia |  grep '2\.6\.'2.6.24-27-lpia (buildd@midyim) #1 SMP Thu Apr 8 18:04:46 UTC 2010
<achiang> oops, the output is garbled
<achiang> there should be a newline after grep '2\.6\.'
<smb> no it does not. its aways #1
<achiang> urk
 * achiang runs to wherever smb is running
 * tgardner lunches
 * jjohansen -> lunch
<ogasawara> tgardner: when beta freeze lifts next week, could I get you to help me upload pciutils (just need to update the pci.ids file).
<ogasawara> tgardner: it's for bug 601079
<ubot2> ogasawara: Bug 601079 on http://launchpad.net/bugs/601079 is private
<tgardner> ogasawara, funny you should mention taht. I uploaded pciutils about 20 minutes ago
<ogasawara> heh awesome
<ogasawara> tgardner: I'll just mark that fixed then
<tgardner> ogasawara, yep, I think thats a safe move
<tgardner> ogasawara, are you subscribed to maverick-changes@lists.ubuntu.com ?
<ogasawara> tgardner: I'm not at the moment, but I'll subscribe now so I see the notices
<tgardner> its a good way to survey what kind of development activity is going on
 * ogasawara lunch
<DJAshnar> Any plans to incorporate the kernel patch for the damn Toshiba Sattelite ACPI/DSDT bug causing us to be forced to turn of ACPI and then only run ONE cpu core?  http://bugzilla.kernel.org/attachment.cgi?id=23958
 * DJAshnar hears crickets
 * DJAshnar stomps on em
<bjf> DJAshnar: it looks like that patch is already in maverick
<bjf> DJAshnar: though not in the form of the link you gave
<DJAshnar> on my Sattelite c655d s5057, it hangs on ACPI on boot unless I use the older patched kernel
<DJAshnar> booting the generi kernel in maverick just leaves me a blank screen.  I have a radeon 4250 chipset if that helps
<bjf> DJAshnar: that's likely a different issue
<bjf> DJAshnar: try rebooting, hold down the left shift key to get into grub and remove "quiet spash" from the boot command line
<DJAshnar> no joy
<achiang> DJAshnar: well, do you now get debug output on your screen?
<DJAshnar> no
<achiang> DJAshnar: were you able to get into grub and edit the kernel command line?
<DJAshnar> yup
<achiang> DJAshnar: hm, weird. try repeating, and add "ignore_loglevel earlyprintk=vga"
<achiang> so "quiet splash" should go away and the other two should be added
<DJAshnar> just a black screen...
<achiang> DJAshnar: hm, maybe the earlyprintk argument was wrong. maybe just remove it completely, actually
<achiang> but do keep ignore_loglevel
<DJAshnar> no luck
<achiang> that seems rather bad, and i'm out of ideas, sorry
<kees> I love the daily upstream kernel debs. very handy!
<DJAshnar> how can I update the kernel daily?
<tgardner> kees, I've opened the natty repo, but I've not really advertized it yet
<kees> tgardner: oh! very cool. I guess I should start rebasing nx-emu and yama...
<tgardner> kees, I dropped the nx emulation patches for now. had some conflicts, so I need to get back to it
<kees> tgardner: okay, I'll go poke at it.
<DJAshnar> cannot reserve MMIO region... wth?
<\_^_\> bjf: We chatted recently about bug #616501 and you told me that this will be part of some review by kernel team. Do you know what came out of this review?
<ubot2> Launchpad bug 616501 in linux (Ubuntu) "Kernel > 2.6.32-20 doesnât boot, /dev/disk/by-uuid/... not found (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/616501
<bjf> \_^_\: yes, i'm embarrassed to say it didn't happen, we will do it monday a.m.
<bjf> \_^_\: it's on our list, we just need to talk about it
<\_^_\> bjf: OK, thanks a lot. :)
<bjf> \_^_\: np
#ubuntu-kernel 2010-08-27
<ogasawara> jjohansen: could you help take a look at bug 624915
<ubot2> Launchpad bug 624915 in linux (Ubuntu Maverick) (and 3 other projects) "maverick kvm guests not seeing virtio disks (affects: 1) (heat: 6)" [High,Confirmed] https://launchpad.net/bugs/624915
<RAOF> ogasawara: Yeah, those (or specifically the intel ones) are the patches I'm thinking of.
<ogasawara> RAOF: I've been trying to find the irc logs to back up what I remember, but I've been unsuccessful.  Basically what I "recall" is that we purposely didn't carry those kms-disablement patches forward to Maverick as they appeared to be a temporary work around at the time and we were hoping to see a proper fix in Maverick.
<ogasawara> RAOF: Obviously if that's not the case I'm can reapply them to Maverick.  Just let me know.  And I assume you'd want all 6 patches reapplied
<ogasawara> ?
<ogasawara> or just the intel ones?
<RAOF> All the intel ones, certainly; we've given up on them working properly.
<RAOF> (For Maverick, at least.  Maybe, *maybe* the âthrow a flock of writes at the GTT and wait untill they stickâ patch will be in Natty's kernel)
<ogasawara> RAOF: do you want the radeon ones too just for good measure?
<RAOF> This is where I want an inverse-launchpad.
<RAOF> Where I can go and see âhey, everyone with a ES1000 is doing fineâ :/
<jjohansen> ogasawara: sure
<ogasawara> jjohansen: thanks
<ogasawara> RAOF: I can get these applied no problem.  we are in beta freeze though so the actual upload will have to wait till post beta.  we can add a beta release note though.
<RAOF> ogasawara: So, I haven't found any new bugs on the ES 1000 for Maverick.  Maybe that means kms is working for it now.
<ogasawara> RAOF: hrm, so maybe we still leave that patch out then
<RAOF> Yeah.  Keep an eye on it, but leave it out for now.
<ogasawara> RAOF: ack
<jj-afk> back on later
 * amitk smiles at GregKH poking fun at Ubuntu's colors: http://lwn.net/Articles/402328/rss
<lamont> Found Xen hypervisor 3.2,  kernel: /boot/vmlinuz-2.6.24-28-xen.dpkg-tmp
<lamont> giggle
 * smb is not sure he wants to know how that happened
<lamont> it went away before the end of the package install
<lamont> that was just apt-get dist-upgrade
<smb> Ah, then I guess I can relax again :)
<lamont> well, it probably shouldn't notice .dpkg-* kernels
<smb> Maybe, but it would be a update-grub problem which is nothing I need to immediately worry. At least not enough to cause a Friday boc delay. 
<lamont> correct
<lamont> boc?
<smb> beer o clock
<lamont> beer on
<smb> not yet
<smb> About 3hrs away, though
<tseliot> mjg59: do you know if there are any additional power savings that we could do with radeon and RS880 (e.g. in the Northbridge) so as to make laptops run cooler? (The RS780 guides on AMD's website should also be relevant for the RS880)
<tseliot> mjg59: I'm using kernel 2.6.35 (and I've also tried some patches to disable plls for display controllers that are not in use, without heat reduction though)
<rafael_n_azevedo> good morning
<rafael_n_azevedo> i'd like to know if i compile a kernel vanilla i will lose something ?
<rafael_n_azevedo> because i'm using lucid n i'd like to compile it
<bjf> rafael_n_azevedo: if you get the right sources and build correctly you shouldn't "lose" anything  https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<bjf> rafael_n_azevedo: why do you want to build your own kernel?
<rafael_n_azevedo> just to compile it on my laptop to "run better"
<rafael_n_azevedo> or u think isn't necessary
<bjf> rafael_n_azevedo: that implies that you are going to change something and that you know what to change to make it "run better"
<bjf> rafael_n_azevedo: i don't think it's necessary
<rafael_n_azevedo> the realy thing it that i would like to learn it 
<rafael_n_azevedo> to learn to compile a kernel
<bjf> rafael_n_azevedo: well, see the link i posted above and give it a shot
<rafael_n_azevedo> ok thanks a lot
<ogasawara> GrueMaster: hiya, thanks for jumping in here, just wanted to inquire about bug 605488
<ubot2> Launchpad bug 605488 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "BUG: scheduling while atomic: mmcqd/46/0x00000002 (affects: 2) (heat: 12)" [High,In progress] https://launchpad.net/bugs/605488
<ogasawara> GrueMaster: seems like the original conditions (ie swap enabled) to trigger the bug are not the same with the latest images
<ogasawara> GrueMaster, lag: do either of you know if swap will be re-enabled in later images?
<GrueMaster> Unfortunately we haven't had a properly working image since Alpha 3 to test this.
<ogasawara> GrueMaster: ah
<GrueMaster> And ogra would know more about whether or not swap will be reenabled.
<ogasawara> GrueMaster: for now then I'm going to leave the bug open for tracking purposes.
<ogra> i only disabled it because of the existing bugs
<ogra> but it appears nobody can reproduce it anymore
<GrueMaster> I'm pulling today's images.  If I can get them to work somewhat, I will reenable swap and test this.
<ogasawara> ogra: so would you consider if ok to close the bug for now?  or would you rather we leave it open into better testing can be done.
<ogra> close it and lets see if it comes up again ... we can always re-open
<ogasawara> ogra: ack, thanks
<ogasawara> GrueMaster: if it re-appears after your testing, re-open the bug.
<GrueMaster> ok
 * smb is out
 * ogasawara lunch
<MarkKohler> I'm tracking down a mostly repeatable crash in ath5k, but when I switched from the Lucid kernel to the packaged mainline kernel, I stopped getting crash dumps. Any ideas on why that would be, or how I can get crash dumps with the mainline kernel?
<nUboon2Age__> I'm having trouble with trying to run 2.6.32-24.  I get "Error: cannot read the Linux header.. error: you need to lead the kernel first.  Failed to boot both default and fallback entries.  Press any key to continue."  If i press a key it just gives the same error.  I'm with Jono at a Global Jam and he recommended you all might be of help.
<nUboon2Age__> JFo-swap: we're listening to "Cooking by the Book".. Jono shared it w/ us
<[reed]> I'm trying to get the packages from bug 554099 for lucid, but I'm having a hard time. I added ppa:kernel-ppa/pre-proposed, but now I'm getting errors complaining about symbol module_layout version disagreement and such
<ubot2> Launchpad bug 554099 in linux-backports-modules-2.6.32 (Ubuntu Maverick) (and 9 other projects) "Qualcomm Gobi 2000 3G (gobi_loader/qcserial) broken (affects: 56) (dups: 4) (heat: 341)" [Undecided,Invalid] https://launchpad.net/bugs/554099
<[reed]> should I have only pulled a specific package or something?
<[reed]> or what exactly
#ubuntu-kernel 2010-08-29
<bvb> Hi! Is there a .deb release for a kernel with vga_switcheroo enabled? I'm running Lucid 64 bit.
<dev001> I'm installing Ubuntu 10.04.1 LTS Server as a Xen DomU Guest.  Finally found the _right_ sources for DL'ing Ubuntu Lucid kernel+initrd for Xen DomU guest install, @ ".../dists/lucid/main/installer-amd64/current/images/netboot/...". 
<dev001>  There, however, I find both ./xen/{vmlinuz,initrd.gz} & ./ubuntu-installer/amd64/{vmlinuz,initrd.gz}.  My understanding was that currrent Ubuntu uses pvops-enabled kernels, and that sepearte xen-specific kernels are no longer required. 
<dev001>  If true, what's the difference between those 2 URLs' contents?
#ubuntu-kernel 2011-08-22
 * apw yawns
 * smb yawns back
 * RAOF organises a yawnathon.
 * _ruben joins in
<apw> they are contagious
<apw> RAOF, while you are awake, https://bugs.launchpad.net/do/+bug/698009, this bug is rather confused, any oppinion on whether having vmwgfx is a good thing
<ubot2> Ubuntu bug 698009 in linux "Request to enable vmwgfx driver in kernel config " [Wishlist,Confirmed]
 * apw is inclined to say yes given those who ask for it.  and i suspect its safe
<smb> (famous last words)
<apw> heh, oneiric is so unstable its hard for me to "improve" it by much
<RAOF> apw: Yes, I think having vmwgfx is likely to be a good thing.
<RAOF> apw: I was going to bring it up at the next "what should the kernel config be" session at UDS; it's not urgent to enable.
<apw> RAOF, ok thanks, works for me, may as well get it in for oneiric beta2 me thinks
<RAOF> Aww, man.  That means we might want to enable the mesa bits, too.
<apw> well that you can think about if we do it :)
<apw> rsalveti, yo ... i was wondering if you'd see the email about "UBUNTU: SAUCE: omap3: beaglexm: fix DVI initialization" and whether it was needed etc
 * ppisati -> lunch
<rsalveti> apw: hm, not yet, will check
<apw> yay terminator just dumped core ... bah
<ogasawara> bug 830298
<ubot2> Launchpad bug 830298 in linux "TOMOYO bugfix patches" [Undecided,Confirmed] https://launchpad.net/bugs/830298
<ogasawara> CVE 2011-2518
<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-2011-2518)
<herton> ppisati: I just noted when reviewing that on fsl-imx51 we use 'Tracking bug' instead of 'Release Tracking Bug' in the changelog entries, not a problem, just a cosmetic thing (sru-report still should work with it). I think it could be left that way
<ogra_> apw, well, plant it, water it and you might get lots of small terminators ;)
<ppisati> herton: ok, take notice
<herton> ppisati: more boring nitpicking :P, fsl-imx51 "distribution" entry should be lucid-proposed, not lucid on top changelog entry. same with ti-omap4 you just prepared, which should be maverick-proposed.
<ppisati> herton: ok
<ppisati> herton: do you fix it or i'll repush it?
<herton> ppisati: yes, please repush and retag it
<herton> s/yes,//
<ppisati> herton: btw, can't find any natty/ti-omap4 -proposed tracking bug, right?
<ppisati> ok, i'll do
<apw> ogra_, heh
<herton> ppisati: right, that's ok, no natty update in progress, the previous one didn't have yet the opened tracking bugs stuff
<ppisati> herton: ok
<ppisati> while rhese
<ppisati> here
<ppisati> i'll s/Tracking bug/Release tracking bug/
<herton> ok cool
<ppisati> herton: fsl-imx51 re-pushed, check it out
<ppisati> herton: lucid/fsl-imx51
<ppisati> herton: you already fixed lucid/mvl-dove
<herton> ppisati: nope, lucid/mvl-dove was already ok. it was just fsl-imx51 and ti-omap4 that weren't -proposed
<ppisati> herton: ok
<ppisati> herton: maverick/ti-omap4 done too
<herton> ppisati: ack, looks ok now
 * ogasawara back in 20
 * herton -> lunch
 * apw bounces to test out a new kernel
<apw> [    1.798684] WARNING: at /home/apw/build/ubuntu-oneiric/ubuntu-oneiric/fs/sysfs/dir.c:455 sysfs_add_one+0xc0/0xf0()
<apw> [    1.798687] Hardware name: Studio 1537
<apw> [    1.798688] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel
<apw> _backlight'
<apw> ogasawara, am seeing this on most of my boxes, i assume it is todo with those backported backlight patches
<ogasawara> apw: quite likely.  have you tested reverting to verify?
<ogasawara> kamal: ^^
<apw>  ogasawara, not as yet, just noticed it on a third box and decided it was real
<kamal> apw, ogasawara: I'll take a look
<kamal> apw, ogasawara: yes, I see that intel_backlight warning also -- yes, it is definitely caused by the backported backlight patch -- I'll dig deeper and sort it out.
<cking> apw, perhaps we should have tests were we compare kernel logs before and after a kernel upgrade to catch these kind of regressions
<apw> cking, dunno, maybe so, quite why apport isn't picking them up is more of a worry
<kamal> does apport generally care about warnings?
<ogasawara> kamal: not anymore
<apw> rtg_, i vaguly reember you talking to bdmurray about doing something with warnings in apport
<apw> did we turn the _all_ off ?
<ogasawara> I believe they're no longer reported
<apw> hmmmm
<rtg_> apw, you mean WARN_ONCE and its ilk ?
<bdmurray> any kernel oops with WARNING in it is not repored via apport / kerneloops anymore
<ogasawara> kamal, apw: so we won't be flooded with bugs, but I would like to get this fixed if possible or revert and reapply with fix post beta-1
<kamal> ogasawara: I'll look at this issue immediately (please don't revert just yet :-)
<ogasawara> kamal: ack.  just fyi, the latest I can probably squeeze in an upload is tomorrow afternoon at the latest (my time, ie PDT) in order to make beta freeze.
<kamal> ogasawara: ack
<jjohansen> rebooting
<kamal> ogasawara, apw: I see the cause of the intel_backlight issue -- testing a fix now.
<ogasawara> kamal: ack
 * tgardner --> lunch
<kamal> ogasawara: will I need to file a new bug in order to submit this (tiny) backlight patch?  or can I use the same bug number (for BugLink:) as we used for the original backlight backport patch?
<ogasawara> kamal: use a new bug number
<kamal> ogasawara: ack
<ogasawara> kamal: be sure to send it upstream too - https://lkml.org/lkml/2011/8/17/163
<kamal> ah ha
<kamal> yup
<apw> kamal, thanks for looking at that, one less for the rest of us
<kamal> apw: np -- i was the instigator of all this anyway :-)
<apw> bad kamal
<ogasawara> apw, tgardner: any other last minute patches you want in before I upload?
<apw> ogasawara, nothing here, everything i am holding i want in first after beta-1
<tgardner> ogasawara, nope, but I've recently pushed some build patches
<ogasawara> tgardner: yep, saw those.
<tgardner> ogasawara, lemme know if I've broken something
<ogasawara> tgardner: will do
 * ogasawara kicks off test builds
<tgardner> ogasawara, shouldn't that top commit 'UBUNTU: i915: do not setup intel_backlight twice' be a SAUCE patch ?
<ogasawara> tgardner: bah, yep.  I'll fix it up
<tgardner> ogasawara, perhaps you should build master without any of the rules changes for now, just leave them on master-next.
<ogasawara> tgardner: my test builds seems to be fine, but I can hold those patches for now till the first post beta1 upload.
<tgardner> ogasawara, well, I've found at least one inconsistency. I'd like to run it through a PPA build before I'm sure of them.
<ogasawara> tgardner: ack
<tgardner> ogasawara, so, just cherry-pick the config and i915 patches onto master, right?
<ogasawara> tgardner: yep
<tgardner> cool
<kamal> ogasawara: SAUCE?  oops.  I thought that it would only be SAUCE if it was Ubuntu-specific and not destined for upstream.  no?
<vanhoof> kk
<vanhoof> wrong window :)
<openfly> anyone know if there are dox anywhere on how the ubuntu kvm packages are built?
<openfly> like configure flags and the sort?
<openfly> and if really lucky package definitions
<RAOF> openfly: "apt-get source kvm"?
<openfly> yeah i guess that's the best there is
<openfly> just kinda wish it would be less of a pain
<openfly> compiling custom packages with all the dependencies from that direction is going to be time consuming
<openfly> was kinda hoping someone had scripted something
<RAOF> openfly: No, it'll be easy.  If you need to change configure flags, just change them in debian/rules and then rebuild the package (optionally in a pbuilder or sbuild chroot).
<ogasawara> kamal: SAUCE "This is a patch that the submitter has authored and is not yet upstream. The patch likely has been submitted to upstream but is of enough value for Ubuntu to carry it in our tree regardeless of upstream acceptance."
<kamal> ogasawara: ok, got it (until I forget again ;-)
<ogasawara> kamal: that's why we have tim OCD gardner to remind us :)
<kamal> next time I'll mark it like "UBUNTU: OCD: fix the foobar frobnaz"
<openfly> yeah but the dependencies on kvm are a nightmare
<openfly> =/
#ubuntu-kernel 2011-08-23
 * smb tries to wake up
<RAOF> This sounds like a job for bees!
<smb> Nah, more like very strong coffee...
<RAOF> Infused with bees?
<RAOF> Everything is better with bees âº
 * smb wonders about the bee thing that seems to go on....
<smb> B B B
<smb> Still not better...
<RAOF> B-)
<RAOF> See?  Much better!
<smb> Heh :)
<smb> Seems one way to tell that apw is awake is to watch for new tracker mails pouring in ... ;)
<smb> apw, morning
<apw> smb, heh tracker emails ?
<smb> apw, modifying the cve-bzr-tracker that I am still subscribed to 
<apw> smb, heh yeah thats first thing normally cause it kills my machine stone dead ... as it pays the 'its 24 hours so acces timess needs to change' pain on alll my repos
<apw> i then make some tea in parallel while it runs :)
<smb> Heh, yeah sounds like a good way to not to actually pay that time in person... :)
<apw> literally takes 10 minutes of heavy crunching the first time, disk burried
 * apw notes that this one shows a huge heap of updates on arm like we haven't rebased arm in agaes, i guess with all the regressions on master thats not unexpected
<smb> If its Lucid, then sort of. At least ec2 skipped 3 or 4 versions. But only the first had a lot of changes. Still could have been one or two stable ubdates
<apw> yeah most likley that much behind.
<apw> smb, though 78 CVSs moved from pending to pending (x), so something was very very behind
<apw> kees will be pleased indeed to see them all go out
 * smb shouts
<apw> smb are you "there" or is pulse bust at my end
<smb> yes :-P
 * apw cries
<smb> Not much more joy
<apw> smb, can you see my lips even ?
<smb> apw, were making fun of you
<smb> well we hear you
<cking> we can here you
<smb> but you cannot hear us
<smb> we won't repeat that
<cking> smb, you can see how many writes you did to the fs using: cat /sys/fs/ext4/sda1/lifetime_write_kbytes
<smb> cking, Hm, I guess that would require it to pass the recovery phase which it fails because any writes seem to fail...
 * ppisati -> lunch
<zul> can we get CONFIG_BLKIO_CGROUP turned on for omap4, i already opened bug #831954 about it
<ubot2> Launchpad bug 831954 in linux "CGROUPS_BLKIO need to be enabled on omap4" [Undecided,Incomplete] https://launchpad.net/bugs/831954
<apw> zul on which release
<zul> oneiric
<tgardner> apw, on it
<apw> tgardner, seems you read even faster than i
<smb> zul, Another thing for lxc?
<apw> tgardner, we might want to see that *_CGROUP_* are the same in master and there
<apw> tgardner, as i suspect there will be something else missing tommorrow
<zul> smb: yeah wheee
<apw> zul i assume lxc works on i386/amd64 ?
<smb> apw, Sounds quite reasonable... 
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<zul> apw: pandaboard
<apw> zul, i know you need ti-omap4, i mean if the config is right in x86 then its worth syncing all cgroup things over at the same time
<smb> apw, And the other answer should be yes
<tgardner> apw, funny, I was just thinking the same thing.
<zul> apw: agreed
<apw> smb, so lxc does work yes ?
<smb> apw, Yes, and I was thinking that it seemed to work with the last other cgroup change. But seems not all of it
 * bjf -> morning walk
<tgardner> ogasawara, pushed rebase to v3.1-rc3 plus makefile patches to ubuntu-p
<ogasawara> tgardner: sweet, was just about to start that
<tgardner> ogasawara, now you can take an extra 20 minutes :)
<ogasawara> heh
 * apw isn't sure she can take a full 40 minutes of that
 * ogasawara cringes at the thought
 * bjf -> back
<ppisati> have we ever had arm vexpress kernel built?
<ppisati> it seems the server/arm people need it
<ppisati> and they are asking to had this arm flavour
<tgardner> ppisati, linaro agreed to supply that flavour
<ppisati> tgardner: we supply or they supply?
<tgardner> ppisati, tey, as in linaro
<tgardner> they*
<ppisati> uhm
 * ogasawara back in 20
<ppisati> tgardner: it seems they need it for the cloud images (that they will run on qemu in this case)
<ppisati> anyway, i'll reroute them to linaro
<tgardner> bjf, are you deaf ?
<bjf> must be, can you hear me?
<smb> yes
<bjf> huh
<smb> killall pulseaudio
<Daviey> ppisati: Thanks for the heads up
<ppisati> Daviey: ah, you are here :)
<Daviey> tgardner: Did linaro agree to provide it "in ubuntu archive" ?
<tgardner> Daviey, IIRC they were going to do that. contact John Rigby.
<Daviey> tgardner: ta
<apw> Daviey, it is rather late in the day to be noticing you don't have a kernel isn't it?
<tgardner> Daviey, of course there might be a maintenance issue. Linaro typically abandons a release as soon as its out.
<amitk> tgardner: Daviey: John (for the config) and Ricardo Salveti (for uploads to archive if necessary)
<Daviey> apw: who uses THAT?
<apw> that ?
<Daviey> a kernel.. we just ride along the userspace.
<smb> and we likely have no need for a vexpress thing... :-P
 * smb at least has no hw for that
<Daviey> The reason for wanting it, is that we were advised that the vexpress platform is better to virtualise than the ones we were using.
<amitk> smb: very few people in the world do and most are concentrated around a place called cambridge, UK
<Daviey> this is really purely for using full virt.
<Daviey> smb: you do have hardware for that!  it's called qemu-system-arm :)
<tgardner> Daviey,  actually, I thought it was the only armel flavour that worked with qemu
<amitk> tgardner: there is now basic omap support too
<Daviey> Other people know much more about this crap than i do :)
<apw> i thought we dropped versatile cause qemu did omap support now
<tgardner> amitk, Daviey: well we _do_ have omap2 support in oneiric
<tgardner> or omap3 rather
<smb> bjf, If that was intended to be speed it did not work
<ppisati> yep, qemu should grok the omap3 kernel nicely now
<smb> err speech
<Daviey> NCommander / ogra_ / lool: Should we use omap3 as our favoured qemu-system-arm platform?
<ogra_> Daviey, well, that limits you to 512M
<apw> so what have you been testing with for the last 4 months
<ogra_> and makes your image creation more complex 
<Daviey>    mm   mmmmm    mmm  m    m
<Daviey>    ##   #   "# m"   " #    #
<Daviey>   #  #  #mmmm" #   mm #mmmm#
<Daviey>   #mm#  #   "m #    # #    #
<Daviey>  #    # #    "  "mmm" #    #
<ogra_> mmm ?
 * apw wonders why your R is lifting its foot
<lool> Daviey: There are pros and cons; vexpress has some network issues, but otherwise mostly works; OMAP supports emulation of a bunch of different boards and will actually emulate the OMAP3 boot ROM (vexpress just starts into an ELF binary from the cmdline); vexpress goes up to 1 GiB, beaglexm up to 512 MiB; network, keyboard and mouse emulation on OMAP is tricky, but you get flash
<Daviey> lool: tgardner seemed to think that linaro was working on a vexpress kernel, is this intended to be in the archive, do you know?
<lool> Daviey: it's in the archive
<lool> Daviey: as well as our omap kernel
<lool> Daviey: the d-i flavor for vexpress is temporarily disabled as it lacks a couple of modules in the config which are now required
 * Daviey is now really quite confused.
<lool> Daviey: rmadison linux-linaro-vexpress
<lool> Daviey: rmadison linux-linaro-omap
<Daviey> Gah.
<Daviey> There seems to be pockets of unknowns floating around.
<lool> Daviey: Note that there are 3 OMAP kernels in Ubuntu ATM; linux-ti-omap4 for OMAP4 only (not supported in qemu), linux builds an OMAP3-only flavor (should work in QEMU), and linux-linaro-omap builds and OMAP2+ flavor which works on OMAP3 + OMAP4 and in QEMU
<Daviey> lool: So you think linux-linaro-vexpress is our best bet, for most memory support?
<lool> Daviey: that seems right, but the network issue is a big deal for a cloud usage
<lool> Daviey: for a local run, it's fine though; but you can't test network install for the same reason
<tgardner> Daviey, as is the maintenance window
<lool> one thing I didn't try is setting up the network over serial; that's really ugly, but it would be reliable and slow
 * Daviey sobs.
<jibel> apw, bug 827197 is not fixed on today's desktop images.
<ubot2> Launchpad bug 827197 in linux "/usr/bin/ecryptfs-setup-private fails with exit status 1 during install - User's home directory not encrypted" [High,In progress] https://launchpad.net/bugs/827197
<apw> jibel, what kernel is on the CD you have
<ogra_> lool, but the beaglexm vm needs a proper vfat, vexpress can just run with vmlinuz and .img file ... its quite some extra effort to add partitons etc
<jibel> apw, 3.0.0-9.13
<jibel> apw, it was fixed on .12 according to changelog
<apw>  jibel looking at it now
<jibel> apw, thanks
<lool> ogra_: I don't think it's an obvious disadvantage; for instance with vexpress you have to keep the kernel up-to-date inside the installed system and on the host, while with OMAP you just apt-get update
<lool> just... different, both with advantages and disadvantages depending on the load
<ogra_> sure, omap is also better supported, but you still have to do more implementation work in the beginning
<cr3> hi folks, do some drivers take different code paths for some pci devices depending on their revision number? ie, is the revision important to know when troubleshooting a pci device?
<apw> ogasawara, about?  seems something odd has happend to the ecryptfs fix, it seems to have undone itself, even though you had to disable module checks... 
<ogasawara> apw: eh?
<apw> cr3, yep, some quirks only apply to specific revisions or chip revs or any number of other things
<apw> ogasawara, seems although all the pre-requisite changes are in the commit, as of now ecryptfs itself is still =m in some cases.
<apw> ogasawara, i cannot fathom how that is possible
<kirkland> apw: why's ecryptfs so much trouble this cycle?
<apw> kirkland, some idiot added TPM based key support to it :/
<cr3> apw: awesome, thanks for the confirmation! And, just to be extra sure, like wearing a belt and suspenders, the class of a device is not likely to change between revision numbers of a pci device, right?
<tgardner> cr3, you mean like changing from a network device to a disk device ?
<apw> cr3, i'd have not thought it was possible no
<apw> ogasawara, shall i push the fix to that onto master-next
<ogasawara> apw: yes please
<ogasawara> apw: will prep the upload asap
 * ogasawara tries to figure out what happened
<apw> ogasawara, done ... its utterly dumbfounding
<kirkland> apw: okay, how's that complicate things for us?
<cr3> tgardner: maybe not as drastic as that but perhaps change from "RAM memory" to "FLASH memory", assuming a Memory controller
<apw> kirkland, it added a huge dependancy pile which has to be =y to allow ecryptfs to be =y and cause we don't autoload it it has to be =y
<tgardner> cr3, perhaps in the prototype or development phse, but certanily not after a production release.
<tgardner> phase*
<apw> and it silently moved itself =m to fix the depenancy issues and we didn't notice
<apw> ogasawara, perhaps i should add erypt_fs =y to the enforcer
<cr3> tgardner: that's a reasonable use case, thanks, exactly what I needed to know!
<ogasawara> apw: yep, that would be a good idea
<kirkland> apw: ugh, that's nasty;  tyhicks will be on board next Monday;  perhaps he can help out
<tgardner> ogasawara, don't commit the makefile changes on master just yet.
<ogasawara> tgardner: ack
<ogasawara> tgardner: I'm just gonna do the ecryptfs bits and upload
<tgardner> ogasawara, good thinking
<apw> ogasawara, ok pushed the enforcer bits too, feel free to rebase them after the upload if thats easier
<ogasawara> apw: ack, thanks.
<apw> ogasawara, did we get the seccomp bits in time ?
<ogasawara> apw: I could actually sneak them in now, kees sent a pull request this morning
<tgardner> apw, I'm looking at them right now
<tgardner> ogasawara, I'd say wait on seccomp. ecryptfs is more important
<ogasawara> tgardner, apw: am thinking we should just wait till post beta-1 though
<apw> ogasawara, it feels like a first upload after beta-1 material to me, gives a few weeks to rip it out if its pants
<ogasawara> apw: agreed
<tgardner> apw, hey mr perl wizard. when you have time look at ubuntu-p.git. 'Missing argument in printf at debian/scripts/abi-check line 174.' implies that the ABI checker needs some love.
<apw> tgardner, sure, been seeing that for some time i think
<tgardner> apw, ack
<apw> tgardner, added to my todo
<sconklin> hey apw, can you confirm that https://bugs.launchpad.net/ubuntu/+source/linux/+bug/805494 is fixed? I'll do the bug updates if you say it's good for Lucid and Maverick
<ubot2> Ubuntu bug 805494 in linux "ubuntu/rtl8192se driver breaks build when running 3.0 and above kernels" [Low,Fix committed]
<bjf> ##
<bjf> ## Kernel team meeting in one hour
<bjf> ##
<tgardner> sconklin, I think its pretty obviously a fix since it wouldn't build otherwise. I'll check again with a quick test build
<tgardner> sconklin, updated to  verification-done-lucid on bug #805494
<ubot2> Launchpad bug 805494 in linux "ubuntu/rtl8192se driver breaks build when running 3.0 and above kernels" [Low,Fix committed] https://launchpad.net/bugs/805494
<apw> sconklin, indeed that is a build test if it built its ok
 * tgardner --> lunch
<bjf> ogasawara, we're just going with the moin text that the bot pukes out?
<bjf> ogasawara, for the meeting notes
<ogasawara> bjf: that's what I did last week, seemed easier
<bjf> ogasawara, not sure what that buys us may as well just point at the irc log
<ogasawara> bjf: I added a blurb to the meeting README in kt-tools about it as an alternative to running the minutes through the irc2moin script
<ogasawara> bjf: true
<herton> tgardner, apw, sconklin: bug 805494 needs to be marked verified for maverick as well. I did build tests under 3.x kernel with maverick sources just in case, will mark verified for it as well.
<ubot2> Launchpad bug 805494 in linux "ubuntu/rtl8192se driver breaks build when running 3.0 and above kernels" [Low,Fix committed] https://launchpad.net/bugs/805494
<tgardner> herton, ack
<herton> sforshee: we got positive feedback from testing bug 828550, can you send your patch to the mailing list to be reviewed/applied?
<ubot2> Launchpad bug 828550 in linux "kernel BUG at /build/buildd/linux-2.6.32/drivers/gpu/drm/i915/i915_gem_evict.c:183!" [High,Incomplete] https://launchpad.net/bugs/828550
<herton> *on bug
<sforshee> herton, ack
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Oneiric Kernel Version: 3.0 || Ubuntu Kernel Team Meeting - August - 30 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<cking> yawn
<ogasawara> tgardner: just fyi, i ran updateconfigs for the seccomp config changes and pushed over the top of master-next
<tgardner> ogasawara, did it just resort ?
<ogasawara> tgardner: yep, just moved em to ubuntu.common
<tgardner> ah, thanks.
<jjohansen> rebooting
<bdmurray> This is indicative of something bad right?
<bdmurray> [  423.586548] aufs au_xino_do_write:378:python[4582]: I/O Error, write failed (4294967268)
<soren> bdmurray: You're out of space.
<soren> bdmurray: 4294967268 == -28
<bdmurray> soren: not me but thanks!
<soren> ENOSPC = 28.
<soren> bdmurray: It's guesswork, but it sounds plausible to me.
<bdmurray> soren: aufs                   3097704   2522256    415552  86% /
<soren> bdmurray: Hm.
<soren> bdmurray: pass
<soren> bdmurray: All I know is that 4294967268 is -28 written as an unsigned int.
<soren> bdmurray: and -28 is what you'd get if made a system call that failed due to not enough space.
<soren> bdmurray: ..and then I put two and two together.
<gswallow1> Hiya, dumb question I think. First, I asked #ubuntu and got crickets.  Is there a better place between there and here?  And second, I have been trying to install 10.04.2/3 on an HP BL460g7, with some cursed ServerEngines CNA.  So far the only thing I can get to bring up the network on this card is Maverick.  I have read on teh Googlez that there is a way to choose a "Maverick backports" kernel or something and still install Lucid.  Do
<gswallow1> oh, hey. https://answers.launchpad.net/ubuntu/+source/ubiquity/+question/164536
#ubuntu-kernel 2011-08-24
<openfly> question.  using maverick kernel 2.6.35-30.58 with ixgbe driver 2.0.62-k2 i get like 2.8 gbit throughput from kvm instances
<openfly> but upgrading to 3.4.24 ixgbe with NAPI enabled
<openfly> i get like 80 mbit
<openfly> anyone got any ideas on why that may be?
<philipballew> hey I found a bug. ubuntu 10.10 and 11.04 will not restart
<smb> morning
<cking> morning smb
<smb> cking, Early start today?
<cking> smb, normally up at 8am nowadays
<smb> sounds ghastly... :)
<cking> needs must
<_ruben> up at 8am .. the luxory :/
<smb> sounds like having kids... :-P
<FreezingCold> What does Ubuntu compile in the kernel by default?
<diwic> does bjf run a script that automatically marks things new -> confirmed? 
<jk--> FreezingCold: you can view the config options in /boot/config-$(uname -r)
<smb> diwic, I think that is a bot doing things based on apport feedback
<_ruben> smb: just one ;)
<FreezingCold> jk-: For things like the LiveCD though, don't they have to have everything compiled already...?
<diwic> smb, it's just surprising to find bjf being reported as the "changer" (see bug 832552)
<ubot2> Launchpad bug 832552 in linux "Network problem - some pages load extremely slow" [Undecided,Confirmed] https://launchpad.net/bugs/832552
<jk-> FreezingCold: no, they can still use modules. It needs to be compiled, but not necessarily *compiled-in*
<jk-> (modules are still compiled on the CD image)
<FreezingCold> All the modules are compiled?
<smb> diwic, Usually things start being done in the name of whoever develops the scripts. Which is the user who runs them then. At some point it may be good to change it to a distinquishable bot name
<diwic> smb, okay
<smb> diwic, But I guess that way Brad gets to know when the scripts went wrong
<smb> FreezingCold, Very roughly anything that can be compiled as a module is done that way. Except things marked experimental. And there is a certain set of very commonly used things that gets built in
<FreezingCold> smb: I thought some things had to be built in?
<FreezingCold> What the main differerence from built in and module?
<ohsix> if they have to, then the kconfig won't let you build it as a module
<_ruben> modules can be unloaded/reloaded
<_ruben> and only loaded when needed
<smb> There was a time when loading a module had time penalties. And of course you need anything built-in that you need to access additional modules. That would matter ore when not using an initrd
<smb> And a module driver only takes up memory when loaded. So the main kernel binary is smaller
<ohsix> there was some scsi stuff that was really slow when not built as a module back in the day, dunno if that is still true
 * apw yawns
<smb> ohsix, I believe there was that for any modules
 * smb waves to apw
<ohsix> specifically ones that had to wait for stuff internally
<smb> ohsix, Well I mean to load a module delayed the boot
<apw> smb, i think one of the issues was the locking was terrible so if you loaded loads of them there was a huge linearisation of the boot
<smb> Yeah, and more serial stuff which is now done in paralel too
<apw> once they sorted that out there was actually possibility to paralleised the boot more using modules than if builtin
 * smb thinks he and apw are saying the same in different words. But /me is not wake enough to tell immediately ... 
<ohsix> to the endless entertainment of the people who still cargo cult rules of thumb like building everything in is faster
<smb> Oh an probably one other exception being when user-space is not clever enough to try loading a module in case it is needed and there is no other hook to make it autoload...
<smb> apw, right? ;)
<smb> Doh! Guess apw left his machine to succumb to relatime...
<apw> smb, modules> right
<apw> smb, relatime> also right
<jk-> hey smb & apw
<smb> jk-, Hello man from (down)underworld... :)
<jk-> heh, I just queued up some Underworld songs, too :)
<smb> :D
<smb> Grrr... "your bug has been marked as  a duplicate of bug y" (which you cannot see because lp won't let you (timeout)
<apw> smb, you clearly didi not need to know
<smb> Oh well, who needs any zeitgeist anyway...
<apw> smb, who can say given i 1) cannot say it, and 2) have no idea what it does
<smb> apw, and 3) there does not seem to be anything missing when it crashes (again)
<FreezingCold> What's the safest way to restart OpenSSH?  I'm connecting over SSH btw.
<apw> FreezingCold, i believe you can /etc/init.d/restart ssh when connected thought it and it doesn't restart the connected sessions ... but really you should test on a system you don't care about
<jk-> apw: init.d is *so* last year
<jk-> :P
<smb> The challenge is to remember what has been converted and whatnot... :-P
<apw> right ... indeed.  ssh probabally is
<apw> and i've even mixed the two syntaxes havn't i
<smb> apw, thinkso
<smb> /etc/init.d/openssh restart
<smb> oh no
<smb> openssh is last year too
<smb> So only /etc/init.d/ssh restart
<smb> or restart ssh
<diwic> apw, btw, the lack of hw volume sync when switching ports in pulseuadio, I think that is fixed now. Can you verify?
<apw> diwic, i assume that is a pulse update yes ?
<diwic> any 0.99.2 based one should do it
<diwic> apw, ah sorry, it is not yet fixed
<apw> diwic, ok the affected machine is dist-upgrading ...
<apw> diwic, bah, thats annoying
<diwic> apw, just asked upstream about it.
<philipballew> my computer hangs on reboot but shutdowns fine. can someone help tell me whats wrong
<apw> philipballew, it would help to know what sort of computer and which release
<philipballew> well apw its on 10.04 10.10 11.04 and it is a emachine t6420
<smb> philipballew, Have you tried https://wiki.ubuntu.com/BIOSandUbuntu#Reboot_Methods ?
<philipballew> i should mention is shuts down fine
<philipballew> just not re-boot
<smb> power off and reboot are done differently 
<apw> yep, as smb says that likely means a buggy bios and we need to try the alternative means of rebooting to see if any of them work
<apw> if they do then the kernel can be quirked to use one that works
 * apw adds emachines bios writers to his "first against the wall" list and then uses his fork-lift to return it to the shelf
<philipballew> i ran reboot force, pci, efi and acpi
<philipballew> you were the one apw a few weeks ago who told me to :)
<apw> philipballew, could well be, i could never remember even 1% of the irc conversations i have, i'd need another fork-lift for my brain
<smb> ever? :)
<philipballew> haha, also my bios not wont detect my cd drives...
<philipballew> ^ not buying a emachine again
<philipballew> but that is irrelvent
<philipballew> and well, as a ubuntu member and user i figured i should see if a bug needs to be reported
<smb> I think pci, efi and acpi may be the first things to be broken. And I believe f(orce) is a modifier to be used with any. You may try t(riple fault), k(eyboard controller) or r(eboot vector) if you have not yet.. You see the rebooting message as the last thing on the console, right?
<philipballew> when i reboot it has the xubuntu logo and the text on the screen saying how its shutting down proccess. then it says will now restart and then it hangs
<smb> Right, so at least from the description it sounds like being right at the final point of triggering a reboot and that not working for some reason...
<philipballew> exactly
<smb> So for completeness, I would at least try the other three methods above...
<philipballew> that means having to manually hold the power button down and risk hardware damage
<smb> why?
<smb> At that point you are mostly shut down
<smb> Ok, there is a few more stop start cycles to the hard drive
<philipballew> well i dont want to break the desktop if i dont have to i guess
<philipballew> i might try to remove all pci devices to see if any were causing the problem to
<philipballew> not sure if thats messessery
<philipballew> *nessessery 
<smb> Maybe an last resort  option. Actually, is that a desktop machine (not a laptop / netbook). Just wondering whether they do not have reset buttons...
<smb> (just to avoid the power off)
<philipballew> its a desktop
 * apw thinks that taking the entire macine appart to see if its the cards is more likely to break it than powering it off acouple of times
<ashwinipatankar> I need to change the parameter of /proc/sys/fs/mqueue/* , any way to do that  ? specially msgsize_max
<tgardner> apw, do you remember the system tap config option ? bug #832606
<ubot2> Launchpad bug 832606 in linux-ti-omap4 "Build dbgsyms for use by systemtap" [Undecided,New] https://launchpad.net/bugs/832606
<tgardner> cking, ^^
<tgardner> ah, its not just one option. CONFIG_RELAY, CONFIG_DEBUG_FS, CONFIG_DEBUG_INFO, and CONFIG_KPROBES
<cking> I've no idea what's required to build it
<cking> bit lame, sorry
<tgardner> cking, it turns out to require a number of options.
 * cking hopes it does not add much bloat
<tgardner> cking, its stuff we already have enabled.
<cking> ah
<tgardner> ogasawara, 'Review non-modular modular table'. wtf is that ?
<ogasawara> tgardner: https://wiki.ubuntu.com/KernelTeam/Specs/KernelOneiricConfigReview#Non-modular_modules
<tgardner> ogasawara, ah. the description cause a short circuit in my logic path somewhere
<ogasawara> tgardner: basically the list of modules which should be =m but are not so need review as to why
<ppisati> tgardner: i'm on it, and it seems everything is already there
<ppisati> tgardner: some sample scripts i'm using work
<ppisati> tgardner: but i had a failure with something that was supposed to work
<tgardner> ppisati, you're referring to systemtap ?
<herton> tgardner: it seems the patch for CVE-2011-2699 isn't applied on maverick master-next
<ubot2> herton: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2699)
<tgardner> herton, checking
<brendand> sconklin - hi
<apw> tgardner, i suspect you didn't push maverick ... meant to mention it
<sconklin> brendand: good day, what's up?
<brendand> sconklin - quick talk about the two up-coming kernels
<ppisati> tgardner: yep
<sconklin> yeah, go ahead
<apw> tgardner, sounds like you got to the bottom of the systemtap thing
<brendand> sconklin - we have a resourcing problem next week, in that one lab will be unmanned all of next week, as our engineers there are sprinting in london
<tgardner> herton, pushed
<herton> ack
<brendand> sconklin - so we need to make a decision on whether to test like, tomorrow
<brendand> sconklin - at the very latest
<sconklin> brendand: you need to make a decision by tomorrow about whether to test when? Next week?
<sconklin> Is next week unavailable in any case?
<sconklin> Are you saying that the only opportunity to test is the rest of this week?
<brendand> sconklin - essentially, yes
<sconklin> Current status is here: http://people.canonical.com/~kernel/reports/sru-report.html
<brendand> sconklin - yeah, i see there are 3 bugs still to be verified for both of them
<sconklin> there are three bugs requiring verification. The same three for Lucid and Maverick.
<sconklin> They will probably not be verified by tomorrow. However, if testing resources exist now and won't next week, you could test on the hope that verification will pass on all these (and I think it will)
<brendand> sconklin - that's going to be the plan. if you need to respin, then i'm afraid there'll be a delay in getting cert testing done. let's up it all works out
<brendand> s/up/hope/
<sconklin> brendand: no, I think that's a good plan as long as it's ok to parallelize the tasks a bit. And if we have to respin, we'll just have to wait. 
<sconklin> let me make sure the latest Lucid respin is actually in -proposed
<sconklin> brendand: yes, Lucid in -proposed is good
<lamont> ValueError: invalid literal for int() with base 10: '173-updates'
<lamont> wtf.
<apw> lamont, that doesn't look like a valid number to me, it has letters in it
<ogasawara> bug 825259
<ubot2> Launchpad bug 825259 in nvidia-common "File "/usr/lib/python2.7/dist-packages/NvidiaDetector/nvidiadetector.py", line 87, in __get_value_from_name v = int(name) - ValueError: invalid literal for int() with base 10: '173-updates'" [High,Fix released] https://launchpad.net/bugs/825259
<lamont> and  yet, that would be why dist-upgrade fails.
<lamont> bah.  stale mirror? ogasawara ?
<ogasawara> lamont: was fixed last week I believe?  possibly a stale mirror.
<apw> or you need to update nvidia-common first then dist-upgrade
<lamont> ogasawara: only I'm running an oneiric kernel on a natty system
<lamont> so no new nvidia-common
<bobweaver> Hi there I was wondering what kernel is the most stable at the time ? 
<apw> bobweaver, the latest in -updates in each series is normally the most stable we know of
<ogasawara> lamont: hrm. could possibly ping tseliot to see if the fix is SRU'able.
<bobweaver> apw:  I install nre kernel 3.0 and it is not stable so I want to install new one off mainline and would like to know what you think 
<lamont> ah, right.  I'm running oneiric kernel because of r8169 being a great way to not run natty
<bobweaver> I am running 10.10 
<apw> bobweaver, i use the latest natty kernel on my natty boxes, which is where i am where i need stability
<tseliot> ogasawara, lamont:  nvidia-173-updates is available only in oneiric, no wonder the nvidia-common in natty fails on dist-upgrade. I think we should SRU it
<lamont> tseliot: I fully support this idea
<lamont>             try:
<lamont>                 v = int(name)
<lamont>             except ValueError:
<lamont>                 v = 0
<lamont> ^^ because that is a horrible workaround
<bobweaver> I tryed switching to 2.6.38-02063808-generic and nvidia has troubles ctrl+alt+f1  does nothing and also when I install nvida driver pymouth splash wont work 
<lamont> tseliot: and to further confuse things for you, nvidia-173-updates is not installed  on the machine
<tseliot> lamont: I'll backport it. Can you add the dist-upgrade use case in the bug report, please? (so as to support the SRU)
<lamont> sure
<tseliot> lamont: I know, it's enough to have it available in the apt cache, there's no need to have it installed any more
<apw> oh so having src from a newer series would bite you ?
<tseliot> yep
<bobweaver> andy I am a n00b kinda lost 
<lamont> tseliot: in the apt cache, with a priority of 60, fwiw
<tseliot> apw, lamont: this is how we do hardware detection now for Jockey
<lamont> tseliot: is it just nvidia-common that I need to grab from oneiric to make my machine truly happy atm?
<tseliot> lamont: yep
<apw> bobweaver, i am unsure why you are on all these odd versions in the first place.  it wouldn't be something we do a lot of, we only use them for testing
<bobweaver> ohh cool
 * apw bitches at tgardner as his build is crawling along
<tgardner> apw, gomeisa ?
<bobweaver> out of the main line what one would you choose 
<apw> tgardner, yep, so either your parallel build code is bust, or you are killing the machine
<tgardner> apw, its burying things, but it'll be done in 10 minutes
<apw> tgardner, bah why is my build not getting a fair shake i wonder
 * lamont finally reboots
<tgardner> apw, dunno, but dpkg-buildpackage seems to have some magic that really thumps things.
<apw> seems you have 3x the processes that i do, odd ... but the machine is really struggling under a high but not outragous load
<tgardner> apw, I can drive tangerine into triple digits
<photon> hi. I'm on 10.04 LTS, I manually updated my kernel to 2.6.38-something. Synaptic shows that Canonical provides only updates until October 2011 for that kernel. Is this a bug?
<photon> Shouldn't it support the kernel until 2013?
<apw> photon, which kernel did you install ?  where did you get it?
<smb> apw, Do we maybe say lts backport kernels are only supported until the next one gets out?
<bobweaver> I will try 2.6.9.2 now lastest natty one hope that that works 
<apw> smb, the backport kernels are supported for servers currently up to the next LTS on approved hardware, is my understanding
<photon> apw: sudo apt-get install linux-image-2.6.38-10-generic
<photon> apw: in Synaptic it shows Canonical provides critical updates for linux-image-2.6.38-10-generic until October 2011.
<photon> apw: I thought this kernel is used in 11.04, for which support does not run out this October, does it?
<apw> photon, ok thats not an official kernel for the LTS and therefore it is likely getting an 18m lable by default
<photon> apw: does this mean I *will* get security updates for this kernel after October and this is just a default label with no meaning? Or do I need to get a different kernel to have longer support?
<apw> photon, to install a backports kernel you should be using 
<apw> o
<apw> bah
<bobweaver> sudo dpkg -i linux*
<bobweaver>  bob crosses fingers 
<apw> photon, to be using the right backports kernel you should be using the linux-lts-backports-natty meta package
<apw> else you won't get any updates at all even if they are available
<apw> they are only supported currently i beleieve for servers but they will be recieving -security updates for that
<photon> E: Couldn't find package linux-lts-backport-natty
<apw> likely any support datage in synaptics is suspect
<tgardner> photon, linux-image-server-lts-backport-natty
<photon> install a server package on a desktop system won't break things?
<apw> doh, yep
<lamont> well then.
<lamont> booting with certain usb drives plugged in causes the machine to take forever to boot, complaining about read errors...
<tgardner> photon, it'll work fine, but you can also install linux-image-generic-lts-backport-natty
<photon> ok, thanks, installing now.
<tgardner> apw, despite your build annoyances (to me) it still completed in 15m9.060s
 * apw has asked for clarification of the support dates from the powers that be, noting that synapics needs updating
<photon> thank you apw. the backport-natty package is now installed. how should I continue? the newest kernel that is shown is still only linux-image-2.6.38-10-generic.
<photon> or does the backport package simply ensure that I get updates even after October?
 * photon is kind of new to this, apologizes.
<photon> tgardner: are you still there?
<tgardner> photon, have you rebooted ?
 * photon rolls eyes
<photon> brb
<bobweaver> well that did not work nvida current wont even install now 
<herton> tgardner, ppisati: I see we're missing cherry-picking commit 76597cd upstream for fsl-imx51 and ti-omap4 (maverick, natty) (the cve crasher fix)
<bobweaver> what is pae ? 
<bobweaver> compaired to mainline kernels 
<bobweaver> ?
<tgardner> herton, looking...
<bobweaver> is it better to get kernel from synaptic or from mainline ? I cant seem to get just the right one nvidia-current either wont install or installs then ctrl+alt+f123456 dont work 
<bobweaver> just not my day today I guess 
<bobweaver> I guess I will try 3.0.3-030003 now 
<bobweaver> cant belive it is this unstable 
<bobweaver> or that noone will tell me which one is the most stable for 10.10 
<bobweaver> nvidia-current (260.19.06)...                                                                      [fail] 
<bobweaver> great 
<bobweaver> oh this gets better 
<bobweaver> all  nouveau are now not working and I lost xsession 
 * bobweaver turns green 
<apw> bobweaver, why are the official kernels not good enough?  
<apw> bobweaver, and i have told you, the ones in the archive are the most stable those in -updates
<apw> bobweaver, you are installing what seem like mainline kernels, which are even labelled as of unknown quality and for testing only
<bobweaver> andy that is the only way that I know how to do it 
<apw> if they break you get to make little sculptures with all the little shiney pieces
<bobweaver> I try synaptic but it crashes  
<apw> bobweaver, but what is it you are trying to do
<bobweaver> install a stable kernel 
<bobweaver> that can handle nvidia 
<bobweaver> current 
<apw> well all of the -updates kernels have paired up nvidia drivers, ones which ahve been tested
<bobweaver> it fails every time 
<apw> well that is a little out of our expertise.  i am not sure random kernels from god knows where is going to help any
<bobweaver> or when it dont fail ctrl+alt+f1 dont work 
<bobweaver> I need that 
<bobweaver> ctrl+alt+f1 
<bobweaver> maybe I am not installing right 
 * ogasawara back in 20
<bobweaver> this is how I do it 
<bobweaver> douwnload the three files 
<bobweaver> mkdir name 
<bobweaver> cd name 
<bobweaver> cd ..
<bobweaver> opps 
<apw> yeah but if you want the latest official kernel you should be able to get that using update-manager
<apw> does update-manager not work for you?
<bobweaver> sudo mv three files to name 
<bobweaver> cd name 
<bobweaver> sudo dpkg -i linux*
<bobweaver> I see that there are patches on the mainline page do I have to put them in the folder when installing kernel ? 
<apw> that is a reasonable command set to install a non-standard kernel, but you want a stable supported one right?  those don't come from the mainline kernles page
<bobweaver> ohh thanks 
<bobweaver> How do I use update manager 
<bobweaver> to do this 
<bobweaver> sudo apt-get update && sudo apt-get upgrade ??
<apw> update-manager installs the latest and greatest of everything ... thats its job
<apw> there is a command 'update-manager'
<apw> if you do manual updates you are in riskier territory
<bobweaver> not installed 
<bobweaver> installing 
<apw> how on earth have you manaaged to not have update-manager !?!  this is not a normal install (any more)
<bobweaver> ob@bob:~/Downloads/3.1$ update-manager 
<bobweaver> The program 'update-manager' is currently not installed.  You can install it by typing:
<bobweaver> sudo apt-get install update-manager
<bobweaver> bob@bob:~/Downloads/3.1$ sudo apt-get install update-manager
<bobweaver> it si kubuntu 
<bobweaver> might have something to do with it ?
<apw> maybe no idea what you are meant to do there :(
<bobweaver> says I have to reboot brb 
<cking> apw has enough fun with unity
<bobweaver> thanks for helping me bro 
 * apw looks up the word fun just to be sure
<smb> must be the kind of fun where you bedn over
<cking> ho ho
<bobweaver> ok installed update manager launched it and it says that there is no updates to install 
<bobweaver> Oo
<bobweaver> question do I have to uninstall all kernels that I have from main line. then install one from say synaptic then update-grub then try up-date manager again 
<apw> bobweaver, now i am confused as to where you are, what kerenls do you have installed, perhaps pastebin the list 
<bobweaver> sure 
<bobweaver> http://paste.ubuntu.com/673917/
<bobweaver> that is update-grub
<bobweaver> let me know if you want to see any thing else 
<bobweaver> right now I have loaded 3.1.0-0301rc2-generic
<apw> bobweaver, so you don't have a single official kernel at all ?
<bobweaver> no 
<bobweaver> I removed it 
<apw> because it didn't work?
<bobweaver> when I had the bright idea to install 3.0 
<bobweaver> no there was a nvidia bug 
<bobweaver> could not use ctrl+alt+f1 or f2 or f3 ect 
<bobweaver> to drop gui 
<apw> using nvidia or nouveau ?
<bobweaver> nouveau for when I cant load nvidia 
<bobweaver> nouveau is deafult right ? 
 * apw tries to remember if nvidia drivers do c-a-f1 or not
<bobweaver> use to work 
<bobweaver> untill I re-install 
<bobweaver> lspci -nn | grep VGA 
<bobweaver> 02:00.0 VGA compatible controller [0300]: nVidia Corporation C77 [GeForce 8200M G] [10de:0845] (rev a2)
<tgardner> apw, pushed 'UBUNTU: [Config] Restore prepare-% target' to oneiric
<apw> tgardner, thanks :)
<tgardner> apw, read the commit log, yuo'll enjoy my bit of english prose.
 * apw suspect that #ubuntu-x might have some ideas on the nvidia side of issues
 * apw wonders how we ever coped before distributed vcss came on the scene
<apw> tgardner, shouldn't that be w*nkers ?
<smb> and what is preapre ? :-P
<tgardner> apw, I thought that might be a bit obscene in some cultures. tossers is just understated enough...
<tgardner> smb, argh! mis-spelling. well, it'll just have to remain.
<smb> Its not as I would not be able to parse, but the opportunity to ask was just too sweet.
<apw> tgardner, heh but so not very british :)
<apw> would you like some scones ?
 * smb would like some ice-cream...
<tgardner> apw, I thought tossers and w*nkers were related ?
<bobweaver> Once again I would like to say thank you so much for helping me. See I did not even know the difference between main line and the other one that you pointed out. Thank You again 
 * herton -> lunch
<jjohansen> rebooting
<bobweaver> apw:  Andy you are the greatest man everything is working so good right now 
<bobweaver> used synaptic to get kernel 
<bobweaver> then removed all others from mainline 
<bobweaver> rebooted and installed nvidia reboot again and everything I mean everything works 
<bobweaver> I can not thank you enough 
<apw> bobweaver, sounds good.
<bobweaver> you made grey water turn clear 
<bobweaver> maybe one day I can return fav to you or someone else 
<cking> send apw a beer ;-)
 * tgardner --> lunch
<herton> seems I'm completely blind today, just ignore my 'adding to CCs' messages...
<apw> herton, happens, only really embaressing when someone upstream is on there
 * herton -> eod
#ubuntu-kernel 2011-08-25
<Book_em_Dano> My pc is displaying a "soft-lockup detected on CPU#1..." error message which halts the bootup process, how can I resolve this?
<BenC> Book_em_Dano: file a bug report with the full message of the lockupâ¦take a pic if needed
<smb> morning
<apw> morning
<abogani> morning
 * ogasawara back in 20
<ogasawara> apw: I thought we were going to disable compcache?
<apw> ogasawara, and in better news I have also gotten it working again i think
<apw> ogasawara, we were talking about removing the ramzswap ubuntu/compcache) yes
<apw> though it was still being used by casper.  welll actually as i discovered its not working at
<apw> all in natty cause the casper bits just don't work at all
<apw> and that explains why our minimum memory supported had to be bumped in natty
<apw> (i bet)
<apw> anyhow ... i am about to push you some patches with ramzswap reverted as its broken beyond belief
<ogasawara> apw: ack
<apw> and as i've had to fix casper i've fixed it to support zram instead which is a staging driver in the main kernel
<apw> </end nig
<apw> </end nightmare>
<ogasawara> apw: do we want to get a beta freeze exception for this and upload?
<apw> ogasawara, oh no i see no need to doing anything before b1 as the casper userspace is so broken than it simply cannnot corectly load the driver anyhow
<apw> which is good else smoke pours out :)
<ogasawara> heh
<apw> and we released with this broke without noticing for natty :/
<cking> quality
<apw> cking, assured
<cking> right
<apw> ogasawara, if ramzswap made it into P please zap it there
<ogasawara> apw: ack
<apw> ogasawara, i've just pushed the drop of ramzswap given its completely fooked anyhow
<apw> makes no difference if its in
<ogasawara> apw: cool, thanks
<apw> ogasawara, now we wait on foundations to review their side so we can get the functionality back
<tgardner> apw, do you need to diddle the modules bits in debian.master/abi after reverting compcache  ?
<apw> tgardner, ahh yeah must have to... let me unf*ck that
<tgardner> apw, I haven't built it yet, just was wondering
<apw> tgardner, thats what happens when you remove it and test and fix and build, and then decide to revert instead
<tgardner> apw, should likely do the same for ubuntu-p
<apw> tgardner, ogasawara is on the case for p
<ogasawara> apw: yep, I'll fix up p
<tgardner> same with all the config settings ?
<apw> they go naturally but i am commiting anyhow
<ogasawara> yep, am working on syncing all my config changes right now
<tgardner> cool. I'll just crawl back into my hole now.
<apw> tgardner, ok that should be better now
<tgardner> apw, wfm
 * tgardner --> lunch
<jdstrand> kees: hey. I'm looking at this: http://www.openwall.com/lists/oss-security/2011/08/15/3. can you verify if oneiric is affected? based on dates alone, I am thinking not, but want to be sure
<kees> jdstrand: oh, ew. I will check
<jdstrand> thanks
<jdstrand> kees: fyi, I've also got some new kernel CVEs coming in, but it'll be a few minutes before I check them in
<kees> okay, cool
<kees> jdstrand: yeah, oneiric is fine. we're already carrying the fixes
<kees> 1ae2a2c0515870d784f1ea101b079bd0962b6cd5 and 8b180803c66ccc825d2969c1ea9929fcb7fba98e in our tree
<jdstrand> cool :)
<shbk> hello,does anybody have experience with compiling of modules for kernel?   I've described problem detailed here : http://gekannt.narod2.ru/       .thanks in advance
<shbk> I have headers : sh@sh-laptop:~$ uname -r
<shbk> 2.6.32-33-generic
<shbk> I can't find  linux/module.h, but linux/kernel.h is
<shbk> I read that I should compile kernel  yourself
<shbk> but there are opinions that I shouldn't and that it's enough only headers
<shbk> but there is something wrong, I don't know,  should I at first compile kernel?
<shbk> I can  explain this as my precompiled ubuntu 10.04 hasn't source code , so I should  compile it or 
<shbk> can I just put source in /usr/src folder?
<shbk> if I do  find /  -name *module.h   I receive:
<shbk> /usr/src/linux-headers-2.6.32-33-generic/include/linux/module.h
<shbk> /usr/src/linux-headers-2.6.32-33/drivers/media/dvb/frontends/s921_module.h
<shbk> /usr/src/linux-headers-2.6.32-33/arch/sparc/include/asm/module.h
<shbk> /usr/src/linux-headers-2.6.32-33/arch/mips/include/asm/module.h
<shbk> /usr/src/linux-headers-2.6.32-33/arch/xtensa/include/asm/module.h
<shbk> /usr/src/linux-headers-2.6.32-33/arch/h8300/include/asm/module.h
<shbk> /usr/src/linux-headers-2.6.32-33/arch/mn10300/include/asm/module.h
<shbk> ooops, sorry 
<shbk> so I'm confused what to do
<shbk> I asked on #ubuntu , #ubuntu-devel, but they sent me to here
<jdstrand> kees: ok, finished checking in the new CVEs, there are several new kernel ones, including Kaminsky's tcp seq one
<kees> jdstrand: ok, thanks
#ubuntu-kernel 2011-08-26
<sconklin_> , thanks
<abogani> morning
<smb> morning
<amitk> morning smb
<smb> amitk, Hey, someone barely known by now... :-P
<smb> amitk, Hows things?
 * apw laughs at smb ;)  morning
<smb> apw, At least at and not about? :) morgning
 * apw was giggling about your "hey stranger" message
<apw> as i said the same thing yesterday
<smb> apw, Oh well, we seem to have this thing ongoing. :D
<apw> yep
<amitk> smb: hehe, Doing good, today being a somewhat laidback day..
<amitk> any of you staying back on sat after plumbers?
<amitk> we're planning to sample the local juice
<smb> amitk, Nice. :) Oh yeah, its Friday anyways... Probably not. We mostly arrive before
<apw> we'll have to sample the juice on tuesday i suspect :)
<amitk> locals tell me they're open between 1100 and 1600 and a 4-5 varieties per juice shop he's never survived more than 3 shops
<amitk> s/a/at
<smb> Isn't there something about the "grapes of wrath"...
<apw> its the prune juice that'll takes you on
<hrw> hi
<hrw> can someone change linux-source-3.0.0 to conflict/replace with linux-source-3.0?
<apw> hrw can look at that yep, do you have a bug open?
<smb> apw, I think that was sort of not seen necessary as any release update path never would see 3.0... and probably assuming whoever installs an alpha knows how to get rid of it...
<hrw> apw: not yet
<apw> yeah not many people ever even install it
<hrw> Bug #834586 
<ubot2> Launchpad bug 834586 in linux "linux-source-3.0.0 should replace/conflict with linux-source-3.0" [Undecided,New] https://launchpad.net/bugs/834586
<hrw> I use linux-source-VER to bootstrap cross compiler
<apw> hrw thanks
<vista_killer> hi
<vista_killer> i have upgrade from 11.04 to 11.10 and i still have this bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/791089
<ubot2> Ubuntu bug 791089 in linux "crash after rebooting or shutting down from Ubuntu 11.04" [Undecided,Confirmed]
<vista_killer> i have this problem and with 11.04 \
<hrw> bugs... I need to do git bisect and find when backlight control on my laptop died
<tgardner> apw, I've just pushed the patches for CVE-2011-2918 and noticed (at the very end) that there is no BugLink in any of them.
<ubot2> tgardner: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2918)
<tgardner> apw, hmm, it must be bug #834121
<ubot2> Launchpad bug 834121 in linux-ti-omap4 "CVE-2011-2918" [Medium,Invalid] https://launchpad.net/bugs/834121
<tgardner> apw, ok, all fixed and repushed
<apw> tgardner, how the heck did i lose that?  sorry for the effort
<tgardner> apw, np. you should check the bug report and make I've set everything correctly
<tgardner> make sure*
<apw> tgardner, in theory kees' processing will fix any errors you make
 * ogasawara back in 20
<ericm|ubuntu> tgardner, the freescale kernel we are working on - we want to separate the large bulk of GPU code out of the tree, but DKMS apparently doesn't work very well - as it's taking too much time to compile on the target machine, and it needs all the dev packages
<ericm|ubuntu> tgardner, so I'd think the l-b-m way might be a better choice
<tgardner> ericm|ubuntu, indeed, I don't think DKMS is appropriate for an ARM platform.
<ericm|ubuntu> tgardner, ok thanks Tim
 * apw suspects lbm style may work better, but why does it need to be separate in the first place
<apw> ericm|ubuntu, ^^
<ericm|ubuntu> apw, we want to keep a tree as close as upstream
<ericm|ubuntu> apw, and in the end of the day - a linaro kernel will ideally be generated from the upstream version, and an out-of-tree GPU module will be something workable if someone wants an accelerated graphics
<apw> ericm|ubuntu, the problem is you still tie yourself together upload time wise, as you cannot upload the final meta package until your graphics driver part is built. otherwise people tend to lose their kernle or graphics or both
<ericm|ubuntu> apw, yeah - that's a big headache
<tgardner> ericm|ubuntu, it might make package management simpler if you put the GPU code in the ubuntu directory (which is sort of a wart on the side)
 * apw nods, good point
<ericm|ubuntu> tgardner, true
<apw> does that imply we have gpu code for arm which is under a sensible licence 
<apw> ARRRG, /me was upgrading a build box, and the power cable dropped out the wall... the worst possible time in the middle of an update-manager -d update 
<tgardner> apw, doh!
<apw> tgardner, i know, that sickening feeling as the background noise just falls away
<apw> luckily a scratch install is completely possible the machine has nothing on it
<apw> but ... i hope to get away with it yet
<tgardner> apw, it'll be just your luck that there is /var/lib/dpkg borkage :)
<apw> well unexpectedly it booted ... so fingers crossed
<kees> apw, tgardner: everything should be sorted on the tracker/bug stuff
<apw> kees, thanks
<tgardner> kees, ack
<pgraner> ogasawara, ping
<tgardner> pgraner, you scared her off
<pgraner> ogasawara, I think she is having network issues then, they were waiting for her in the release meeting
<pgraner> s/ogawawara/tgradner/g
<tgardner> pgraner, fat fingers this morning ?
<ogasawara> apw: how bout here?
<apw> yep .. all good now
<ogasawara> so pitti brought up a question in #ubuntu-devel as to why we don't reflect the actual stable version in out packages now that we have a 3 digit version scheme...
<ogasawara> is there any reason I'm not seeing that we shouldn't start using for ex 3.0.3-x.y instead of 3.0.0-x.y
<tgardner> ogasawara, because we don't always take all of stable, so the version number isn't very reliable 
<ogasawara> tgardner: that's true
<tgardner> ogasawara, or we end up reverting stuff where those reverts don't always go back to upstream stable. I think a version number that tracks stable would lead folks to a false assumption
<apw> plus it would engender false abi changes just to take the upstream version into account
<tgardner> kees, I've got an archive issue that is stumping me. On a pristine Lucid server with -security and -updates enabled, why can't I install linux-headers-generic-lts-backport-maverick ?
<tgardner> The following packages have unmet dependencies:
<tgardner>   linux-headers-generic-lts-backport-maverick: Depends: linux-headers-2.6.35-30-generic but it is not going to be installed
<tgardner> yet it works if I enable -proposed
<kees> tgardner: hmm, that means something is missing from the archive :(
<tgardner> kees, rmadison looks right
 * kees looks
 * kees scratches his head
<tgardner> kees, good, I don't feel quite so stupid
<kees> tgardner: what I find strangest is that apt-cache policy shows it.
<kees> $ apt-cache policy linux-headers-2.6.35-30-generic
<kees>   Candidate: 2.6.35-30.56~lucid1
<kees> wtf.
<kees>   linux-headers-2.6.35-30-generic: Depends: linux-headers-2.6.35-30 but it is not installable
<jwi> bug 824080? :)
<ubot2`> Launchpad bug 824080 in linux-lts-backport-maverick "missing binary package linux-headers-2.6.35-30" [Undecided,Confirmed] https://launchpad.net/bugs/824080
<kees> yes, that would be it :)
<kees> tgardner: looks like the backport kernel is missing a binary package in its build
<kees> e.g. normal "linux" source has:
<kees> linux-headers-2.6.38-8: Header files related to Linux kernel version 2.6.38
<tgardner> kees, its interesting that linux-headers-generic-lts-backport-natty works.
<kees> yeah
<tgardner> kees, I think the binary _does_ exist: https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/2628554/+files/linux-headers-2.6.35-30-generic_2.6.35-30.56~lucid1_amd64.deb
<kees> tgardner: that's "...-30-generic", it's missing "...-30"
<kees> and yet...
<kees> Package: linux-headers-2.6.35-30
<kees> that's in the control file for it. O_o
<kees> hm. there's an arch: difference, not sure why that would cause issues, though
<tgardner> kees, cause we only build for amd64/i386
<tgardner> for LTS kernels
<kees> tgardner: right, should be fine
<tgardner> kees, linux-headers-2.6.35-30 does not exist in -updates, only in -proposed. linux-headers-2.6.35-30-generic which depends on linux-headers-2.6.35-30 exists in -updates as well as -proposed. It looks like linux-headers-2.6.35-30 did not get copied to -updates correctly.
<kees> tgardner: but it doesn't even show up in launchpad
<sconklin> The following three fixes have not been verified in Lucid or Maverick, and will be reverted unless they are verified 'real soon now':
<sconklin> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/583760
<ubot2`> Ubuntu bug 583760 in gentoo "[PATCH] Mouse cursor dissappears with nouveau" [High,Confirmed]
<tgardner> kees, where does rmadison get its onfo ?
<sconklin> https://bugs.launchpad.net/ecryptfs/+bug/509180
<ubot2`> Ubuntu bug 509180 in linux "ecryptfs sometimes seems to add trailing garbage to encrypted files" [Undecided,Fix committed]
<sconklin> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/801610
<ubot2`> Ubuntu bug 801610 in linux "Include enic & fnic drivers in ubuntu-installer" [Undecided,Fix committed]
<kees> tgardner: from the Packages files in the archive, iiuc
<kirkland> tgardner: from the Cloud!
<kirkland> :)
<tgardner> kees, well, according to rmadison, linux-headers-2.6.35-30 only exists in lucid-proposed, which explains the problem.
<tgardner> it should _also_ exist in lucid-updates
<kees> tgardner: right, so it must have been overwritten before it was correctly copied.
<tgardner> kees, is this something an archive admin can correct?
<kees> tgardner: I'm not sure. the missed copy is pretty serious -- that implies some kind of AA tool failure.
<kees> tgardner: so we should get an AA involved.
<sconklin> tgardner, kees There was a failure in copying some kernel packages recently that resulted in some files going into universe. Maybe this is another case or a symptom of that
<sconklin> cjwatson fixed it
<tgardner> sconklin, possibly.
<cjwatson> I don't think the thing I fixed has anything to do with this
<cjwatson> TBH, it would probably be easiest to fix this by copying the new one from lucid-proposed, if that's at all feasible
<cjwatson> hm, one red bug there
<cjwatson> linux-lts-backport-maverick 2.6.35-30.56~lucid1 (in lucid-updates) plain didn't ship that binary package.  Expand that version in https://launchpad.net/ubuntu/+source/linux-lts-backport-maverick and look at the list of binaries ...
<cjwatson> so not an AA tool failure, the package was just wrong
<cjwatson> (somebody pass this on to tgardner when he comes back?)
<cjwatson> 2.6.35-30.58~lucid1, the newer version in lucid-proposed, appears to have corrected this
<cjwatson> whether that was intentional or a consequence of something else I have no idea
 * jjohansen -> lunch
#ubuntu-kernel 2011-08-28
<apw> cjwatson, that rings a bell there was an report of a missing _all package i think which got fixed, i thoguht the branches got respun, perhaps this is simple communication failure
<kalith> Hello !
<kalith> This is my first time using IRC, so please forgive me if I ever do something wrong (I'm also not a native english speaker).
<kalith> Anyway, I'm here because I have a problem with a game controller that is not properly recognized.
<kalith> Can somebody help me on this ? Should I file a bug report ?
<kalith> Thank you for your time, and I hope I didn't disturb anybody.
<jjohansen> kalith: yes please file a bug report
<jjohansen> kalith: I suggest you plug the controller in and then from a terminal do
<jjohansen> ubuntu-bug linux
<kalith> jjohansen: thank you, I'll do that now.
<kalith> jjohansen: bug report posted, thank you for your help ! (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/836335)
<ubot2`> Ubuntu bug 836335 in linux "Sony Playstation 2 controller PC adaptator : buttons are not mapped correctly" [Undecided,New]
#ubuntu-kernel 2012-08-20
<ppisati> moin
<diwic> is it safe to just run "sudo depmod"?
<diwic> I'm triaging a bug and suspecting that the stuff in /lib/modules/<current> has become corrupt for some reason
<diwic> as the sound card is not detected on bootup, but successfully starts showing up if "sudo modprobe snd-hda-intel" is called.
<mustafa_> how to take part into kernel development as a developer? could you inform me?
<diwic> mustafa_, hi! It depends on what area you're interested in
<mustafa_> what is the structure of kernel development? (areas)
<diwic> mustafa_, and what knowledge you currently have. 
<mustafa_> how can I get detailed info? and any news group for that? for communication?
<diwic> mustafa_, are you interesting in writing code, writing documentation, analysing bug reports, helping people on IRC, etc?
<mustafa_> diwic writing code
<diwic> mustafa_, maybe http://kernelnewbies.org can be a good starting point for you?
<mustafa_> diwic I will scan it 
<mustafa_> diwic any other recommendation?
<diwic> mustafa_, yes, learning by doing - find something that you would like to fix or improve and see if it is possible
<mustafa_> diwic thanks
<cooloney> ppisati: do you have sometime to help do sbuild testing on your pandaES?
<cooloney> ppisati: i got several package building failure on PandaES 
<ppisati> cooloney: nak, still busy with 3.5 kernel, and i need my board for testing&c
<cooloney> ppisati: np, man
<MacSlow> Greetings everybody!
<MacSlow> If someone has a moment (or two) and could skim LP: #1038926 and give me his/her best guess at a way to work-around this, I'd be very grateful :)
 * ppisati -> out for lunch
<ppisati> (there's 33C outside, wish me good luck...)
<ogra_> ppisati, dont melt !
<phillw> Hi folks, could some one please advise as to against what this bug should be reported...http://pastebin.com/SRLnr5fB
<ppisati> 34c now...
<dileks> ppisati: underess!
<dileks> 35c here
<rtg> ppisati, you should annoy an archive admin to get Ubuntu-3.5.0-207.13 published and send  out the ABI bumper announcement.
<rtg> bug #1035348
<smb> bug 1035348
<rtg> smb, seems the bug bot has died
<smb> or lp
<rtg> smb, true. more likely LP
<smb> At least it tells me I lost it (or its private)
<ppisati> lp works here
<ppisati> but not that bug...
<ppisati> bah...
<ppisati> rtg: we need that headers fix for the 3d driver, so i'll cut a new relase with what we've now + that fix
<ppisati> rtg: and i'll send a pull req
<rtg> ppisati, you gonna rebase against master-next ?
<rtg> or just cherry-pick it ?
<ppisati> rtg: cherry-pick, there's a regression in latest master (somehwre between 9.9 and 11.11) and i'm boisecting it
<rtg> ppisati, ah, right. I forgot about that.
<ppisati> rtg: hopefully i'll fix today, but i don't want to delay the 3d driver for unity3d
<rtg> ppisati, if you get Ubuntu-3.5.0-207.13 promoted, then I can upload directly to -release
 * ppisati notes he can't really type today...
<ppisati> rtg: with whom do i need to talk to get it promoted? release manager?
<rtg> ppisati, yeah, go on #ubuntu-release and see if infinty is around.
<rtg> infinity*
<ppisati> infinity: ^
<ppisati> rtg: infinity: actually rsalveti told me that even with this fix pvr-omp4 still doesn't work
<ppisati> so it's not as urgent as i thought
<rsalveti> ppisati: it works!
<rsalveti> it's not stable enough, but not related with sgx
<rsalveti> the kernel is freezing from time to time on my panda, without any logs at the serial 
<rsalveti> but works just fine at the 4430 panda
<rtg> rsalveti, well, it _is_ a staging driver, right ?
<rsalveti> seems it's an issue at the power management side on panda ES
<rsalveti> rtg: yeah, but the issue I got is not related with sgx itself 
<rsalveti> which I'd not be surprised, as for the landing team tree we had to turn cpu idle off for a while 
<rsalveti> CONFIG_OMAP_SMARTREFLEX_CLASS1P5 was also causing issues, but it's currently disabled at our kernel
<rsalveti> ppisati: but probably something to check, omap 4460 should behave better with SR1.5
<ppisati> rsalveti: do you experience these hangs even with agreen tilt-3.4?
<rsalveti> ppisati: not with the current head
<rsalveti> but was when using the tree from last cycle
<rsalveti> *last linaro cycle, 12.07
<ppisati> rsalveti: so i'm probably missing something that went in lately
<ppisati> rsalveti: or it's a config diff
<rsalveti> yup
<ppisati> rsalveti: i dont' see any tag about 12.07, do you know what HEAD was pointing back then?
<rsalveti> ppisati: http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=commit;h=5bab9831a9d00db116a7db5634bb3386ae17f152
<rsalveti> ppisati: but you might look at the git log just before the tag 
<rsalveti> check the ones related with smartreflex 
<rsalveti> http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=shortlog;h=refs/heads/tilt-3.4
<akua> I am building my own linux 3.5 kernel to install on 10.04 ( needed for some peripherals ). After a few tries I have what seems to be good .debs. I did it with the "cp ubuntu-kernel/debian/control-scripts/* /usr/share/kernel-package", "tar xvf linux-3.5.1.tar.bz2",  "make-kpkg --initrd --append-to-version=-custom1 kernel_image kernel_headers". 
<akua> It installs and reboots fine, but then I try to build the nvidia drivers ( because I need CUDA ), and it complains about finding headers...
 * ogasawara back in 20
<akua> The first error is:  "Unable to find the kernel source tree for the currently running kernelâ¦â¦." 
<akua> Then I had to symlink: :/usr/src# ln -s linux-headers-3.5.1-custom1/   linux-3.5.2
<akua> Then the error is: " If you are using a Linux 2.6 kernel, please make sure
<akua>          you have configured kernel sources matching your kernel
<akua>          installed on your system. "
<balloons> it appears like the builder got stuck (or is simply still that far behind) on building the LTS enablement packages -- https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport
<ogasawara> balloons: it's still that far behind
<balloons> https://launchpad.net/builders doesn't show a bug bug queue
<balloons> odd.. anyways.. ok.. :-)
<ogasawara> balloons: the original quantal upload just finished earlier today
<ogasawara> balloons: last I checked, i386 was going to kick off in 4hrs
<balloons> ogasawara, wow.. 4 days.. you'd think your building libreoffice on arm or something :-)
<jsalisbury> rtg, ppisati, did you guys happen to see this bug: 1038846
<rtg_> jsalisbury, looks like a duplicate
<jsalisbury> rtg_, ok, I'll mark it as such
<rtg_>  jsalisburyoh, hang on. I just commiutted a fix for that bug.
<jsalisbury> rtg_ ok
<rtg_> jsalisbury, forgot to mark it as fix committed
<jsalisbury> rtg_, cool, thanks
<rtg> ppisati, don't forget the ABI bumper email to the installer list so that they can take advantage of your new kernel.
<ppisati> rtg: actually i never sent any email...
<ppisati> rtg: besides, i found the problem and fixed it
<ppisati> rtg: i'll have a new kernel soon
<rtg> ppisati, I _know_ you didn't send any email. Thats why I'm bugging you.
<ppisati> :)
<ppisati> rtg: so, what's the ml? and what do i have to tell them?
<rtg> ppisati, hmm, there some stuff about this in the wiki. lemme find it...
<ppisati> rtg: besides, i just cut a new release
<rtg> ppisati, its not an ABI bumper, is it ?
<ppisati> rtg: yes it is
<rtg> ppisati, well, might as well hold off until its built
<ppisati> rtg: ok, then let's do it tomorrow
<rtg> ppisati, ack
 * ppisati -> EOD
<rtg> ppisati, there is a blurb in https://wiki.ubuntu.com/KernelTeam/StableHandbook/StablePackageBuilding about sending out ABI bumper emails
<cking> rtg, thanks for handling a bunch of those eCryptfs patches while I was away, I will see if I can back port some of these to lucid, natty etc and get some tests written to catch regressions
<rtg> cking, that works for me
 * rtg -> lunch
<infinity> bjf: No copies for precise for ti-omap4 or armadaxp?
<bjf> infinity: they were still building when i last checked
<bjf> infinity: if they are ready, they can go as well
<infinity> bjf: ti-omap4 should be done, I think.  I can bump up aramdaxp.
<infinity> bjf: I'll just copy when they're ready then, if there was no other reason to hold them back.
<infinity> Oh, there was a new ti-omap4 a couple of hours ago.
<infinity> Right, I'll give that a nudge too.
<bjf> infinity: nope, just waiting for buildds
<infinity> bjf: I'll get it all built and copied over the course of the day, then.
<bjf> infinity: thanks
<infinity> bjf: No hardy in this round?
<bjf> infinity: nope \o/
<infinity> bjf: Don't fret too much about overrides and other bits possibly being slack on my part, I'll make sure everything's consistent by the end of the day when I get the ARM builds caught up. ;)
<bjf> infinity: ack :-)
 * smb -> EOD
<bjf> infinity: though they pay me specifically to fret
 * bjf will just do it silently
<infinity> *grin*
<rtg> jsalisbury, rebooting tangerine for kernel update
<jsalisbury> rtg, ack
<hggdh> bjf: for the precise LTS-HWE, when are the package linux-image-generic-lts-quantal created?
<hggdh> s/are/is/
<rtg_> hggdh, it lives in a PPA for now, and won't be uploaded to Precise main until 12.10 is released.
<hggdh> rtg_: indeed, and I am looking at the PPA, but I do not see this package
<rtg_> hggdh,  linux-meta-lts-quantal
<hggdh> rtg_: this is still pointing to 3.5.0-10
<bjf> hggdh: are you looking at: https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport
<hggdh> bjf: I am
<bjf> hggdh: yes, the meta is still -10
<bjf> hggdh: may be due to the buildd carnage of last week
<rtg_> hggdh, 3.5.0-10 is the right version because 3.5.0-11 has yet to finish building
<hggdh> rtg_: ah. I will wait for it, then, otherwise I will need to perform another carnage on the test scripts
<rtg_> the build is still awaiting completion of i386
<rtg_> hggdh, LP says it will start building in one hour. we'll see...
<hggdh> :-)
 * rtg -> EOD
#ubuntu-kernel 2012-08-21
<ppisati> moin
<smb> morning and ciao ppisati ;)
<ppisati> smb: ciao Stefan :)
<ppisati> brb
 * ppisati goes to preparare some more ICED coffee...
<ppisati> it's already 29C here...
<cooloney> ppisati and smb morning
 * henrix is having probs with isp... again
<hrw> hi people
<hrw> I bought Toshiba harddrive with usb 3.0. Connected to desktop (running quantal) and got this in dmesg: http://paste.ubuntu.com/1158604/ - disk is unusable as it connects/disconnects all the time
<hrw> http://paste.ubuntu.com/1158610/ is lsusb -vvv output
<hrw> ideas?
<cooloney> ppisati: nice trip for vacation. heh
<xnox> hrw: I am all ears, since I am experiencing similar. But for me it might be lvm related.
 * xnox is not kernel dev, just a lurker.
<ppisati> cooloney: thank you :)
<hrw> xnox: http://www.digipedia.pl/usenet/thread/19505/33113/ is what I want to check
<hrw> xnox: disk will be mostly used with usb2.0 laptop but for future use I prefer usb3.0 ;)
<xnox> hmmm... for me it just spins down and gets "ejected" and then all of my LVs and VGs are borked =/ giving i/o errors. not sure it's the same.
<cooloney> ppisati: if you need me take care of some ARM stuff during your vacation, please let me know
<ppisati> cooloney: feel free to chime in, the ti-omap4 lp bugs page is always looking for some love :)
<cooloney> ogra_: hey, i'm looking at the bug https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/746137
<ubot2`> Ubuntu bug 746137 in jasper-initramfs "Page allocation failure on Pandaboard and Beagle XM" [Undecided,Fix released]
<ogra_> cooloney, ah, cool, note that this isnt arm specific 
<ogra_> seems to be an issue with many USB based wlan cards
<cooloney> ogra_: you mentioned to use GFP_ATOMIC instead of GFP_KERNEL, is that any bug about that?
<ogra_> cooloney, not sure, marvin24 pointed me in #ubuntu-arm to it 
<ogra_> ask him, i guess
<cooloney> ogra_: oh, can we reproduce on x86? actually i got this on my pandaES frequently
<ogra_> i think you can if you boot with a really low mem= value and have the same highmem split in the kernel 
<ogra_> but ask marvin24, he was really into that bug for a while
<cooloney> ogra_: ok, cool
<cooloney> ogra_: also from infinity's comments, looks like if we change vm.min_free_kbytes = 32768, the issue is gone
<ogra_> right, its just that we dont want to set that var for everyone...
<ogra_> and setting a sysctl variable conditionally isnt easy
<ogra_> also its somnething that looks like the kernel should set it right
<ogra_> instead of userspace with hackish detection scripts
<hrw> II: Checking modules for generic...previous or current modules file missing!
<hrw>    /home/hrw/HDD/devel/ubuntu/linux-3.5.0/debian.master/abi/3.5.0-10.10ubuntu1/amd64/generic.modules
<hrw>    /home/hrw/HDD/devel/ubuntu/linux-3.5.0/debian.master/abi/3.5.0-10.10/amd64/generic.modules
<hrw> make: *** [module-check-generic] BÅÄd 1
<hrw> argh...
<hrw> how to disable all abi checks etc? I want to test some usb3.0 patches and kernel compilation drives me mad
<cooloney> ogra_: looks like marvin24 is not online
<ogra_> patient :) its noon here, he is probably at lunch
<cooloney> ogra_: oh, got it, i assume he is in US
<ogra_> germany 
<ogra_> about 80km south of me 
<cooloney> ogra_: that's close. how's you imx6 board.
<ogra_> fine, idling on the shelf 
<ogra_> i'm working on an automated qemu based testsuite atm ... so i havent looked much at real HW the last days
<hrw> ok, time to reboot and check will usb3 drive work
<cooloney> ogra_: i think ppisati probably have already sloved this issue in Ubuntu-3.5.0-208.14
<ogra_> dunno, i havent seen the issue on that kernel ... but then i didnt do many RAM hungry tasks yet
<cooloney> commit e3a095d141d53651dd9f406502cbdb87f456c002
<cooloney> Author: Andy Green <andy.green@linaro.org>
<cooloney> Date:   Wed Jun 27 15:10:23 2012 +0800
<cooloney> HACK force min_free_kbytes set by proc to min 32K to workaround smsc problems 
<cooloney> Signed-off-by: Andy Green <andy.green@linaro.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
<cooloney> commit a8fe4ec3a2207dfc7b18a9875569864a68e6cb87
<cooloney> Author: Andy Green <andy.green@linaro.org>
<cooloney> Date:   Wed Jun 27 12:16:28 2012 +0800
<cooloney> HACK force min_free_kbytes to 32K to workaround smsc problems 
<cooloney> Signed-off-by: Andy Green <andy.green@linaro.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
<cooloney> ogra_: i saw it set that min_free_kbytes to 32K as minium value
<ogra_> ugh, ugly 
<ogra_> we cant do that for omap i suppose
<ogra_> might work for omap4 indeed
<cooloney> ogra_: yeah, only on ti-omap4 branch
<cooloney> actually there is no kernel config option for that default value. i think we can introduce one
<ogra_> in mainline ? 
<ogra_> on the pandaboard that bug isnt hitting as hard as on the beagle ... so that fix would have to go into master too
<cooloney> if it is a right method to solve the issue, i think it is good for mainline
<ogra_> k
<cooloney> ogra_: right, but master also includes x86.
<cooloney> probably have an option named CONFIG_MIN_FREE_KBYTES, if the min_free_kbytes < CONFIG_MIN_FREE_KBYTES, then let min_free_kbytes = CONFIG_MIN_FREE_KBYTES
<cooloney> so we can set CONFIG_MIN_FREE_KBYTES as 32K in omap and omap4
<ogra_> yeah
<ogra_> sounds good
<cooloney> ogra_: but maybe kernel maintainers will push that back as why not change that in userspace. heh
<ppisati> ogra_: cooloney IMO that issue was never really resolved
<cooloney> ppisati: ok, so even with the patches you applied from linaro, we still have this issue, right?
<cooloney> ppisati: i will try this kernel soon
 * cooloney out for dinner
<apw> hrw, i assume you figured out the abi disable
<hrw> apw: yes and got my usb 3.0 device working
<hrw> will open bug against quantal kernel
<apw> hrw, lets us know the bug number here
<hrw> sure
<hrw> bug 1039478
<ubot2`> Launchpad bug 1039478 in linux "WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?" [Undecided,New] https://launchpad.net/bugs/1039478
<hrw> patches attached
 * henrix -> lunch
<ppisati> rsalveti: http://people.canonical.com/~ppisati/linux-image-3.5.0-208-omap4_3.5.0-208.14~plus1_armhf.deb
<ppisati> rsalveti: http://people.canonical.com/~ppisati/linux-headers-3.5.0-208-omap4_3.5.0-208.14~plus1_armhf.deb
<ppisati> rsalveti: i rebased all the missing tilt-3.4 patches on our Q/omap4 kernel
<ogra_> plus1 !
<ppisati> rsalveti: check if it makes any diff wrt your pvr hangs
<ppisati> ogra_: plus4! :)
<ogra_> with such a name it *must* be better :)
 * ppisati crosses fingers...
<rsalveti> ppisati: sure, will test it
 * ppisati goes to enable -DDEBUG and -Wall in arm/arm/mach-omap2 again...
<ogra_> so that the rigbuffer eats all our ram again !
<ogra_> *ring
<ppisati> ogra_: just in my build, to catch as much crap as possible
<ogra_> yeah, i wasnt actually complaining, i just tried to sound like :)
<verwilst> hi
<verwilst> i'm currently debugging a gfs2 kernel oops with the 12.04 kernel
<rtg> ogasawara, I uploaded the LTS meta package that you had in the can.
<verwilst> https://bugs.launchpad.net/ubuntu/+source/gfs2-utils/+bug/1020207 this bug is currently attached to gfs2-utils, but i think it's a kernel issue
<ubot2`> Ubuntu bug 1020207 in gfs2-utils "gfs2 kernel oops when deleting file on other cluster node" [Undecided,Confirmed]
<ppisati> diwic: i've an atom board with nvidia chipset, and i'm running the nvidia driver
<ppisati> diwic: /proc/asound/cards shows both the intel and nvidia card
<ppisati> diwic: but aplay shows only the intel side
<ppisati> diwic: what could be wrong?
<diwic> ppisati, hmm
<diwic> ppisati, can you give alsa-info?
<diwic> ppisati, or check in dmesg for strange errors
<bjf> cking: bug 1039561
<ubot2`> Launchpad bug 1039561 in ecryptfs "The ecryptfs test file-concurrent.sh hangs on both natty and lucid" [Undecided,New] https://launchpad.net/bugs/1039561
<Worf> I hope here is the right place for questions like this: Maybe i'm missing something obvious, but i tried a minimal ubuntu install with debootstrap and with  linux-image-3.5.0-11-generic, and i have all kinds of hardware support issues. Like no mouse device, harddisk devices missing, network card missing, ... Did i miss something? I admit i'm not familiar how kernel stuff is packaged in Ubuntu ...
<cking> bjf, can you add some more context? which kernel perhaps? ;-)
<ppisati> diwic: it's an old board i've it around
<Worf> 3.5.0-11.11 for amd64 to be precise
<ppisati> diwic: and i was trying to getr video (and audio) playback via hdmi
<ppisati> diwic: it's not connected now
<ppisati> diwic: e.g. does aplay go through the sound server? or does it check the hw device?
<ogasawara> Worf: did you make sure to also install the linux-image-extra package?
 * ogasawara back in 20
<diwic> ppisati, aplay -l would list the hardware devices only
<bjf> cking: kernel versions added
<ppisati> diwic: ok so if it's no there it's an hw/kernel problem
<Worf> ogasawara: ok, it looks like that would be what i missed ... sorry for bothering ...
<diwic> ppisati, yep. I would look in dmesg for errors
<cking> bjf, /me has a look
<diwic> ppisati, (note that aplay -L lists something different)
<ppisati> diwic: it's disconnected as i said, i'll give it a second look tonight
<diwic> ppisati, ok
<ppisati> rsalveti: any news on plus1 kernel?
 * henrix will be out for a bit
<hrw> jsalisbury: ping
<hrw> jsalisbury: bug 1039478 is what I would like to talk about case today I will have to give disk back to the owner
<ubot2`> Launchpad bug 1039478 in linux "WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?" [Medium,Triaged] https://launchpad.net/bugs/1039478
 * apw curses overlayfs ...
<ogra_> switch back to unionfs :)
<smb> overlayfs withers and dies...
<cwillu_at_work> the cool kids use btrfs with compression :p
 * hrw curses xhci
<xnox> cwillu_at_work: the cool kids also do not notice their data vanishing into the clouds
<cwillu_at_work> sure they do
<cwillu_at_work> the checksums would fail!
<xnox> then what?
 * cwillu_at_work had daily backups long before btrfs was a twinkle in cmason's eye
 * xnox ext4 doesn't need checksums cause it doesn't loose dat
<cwillu_at_work> in other news:  ext4 adds checksums
<xnox> =)))))
<hrw> drivers/video/backlight/progear_bl.ko should be disabled for all ubuntu kernels
<hrw> the device which uses it has transmeta cpu so 586 and 128MB ram
<jwi> hrw: the xhci patches should be trickling down through -stable to quantal fairly soon
<hrw> jwi: yep
<hrw> jwi: good part is that disk owner lacks usb3 so will not have a problem. and she is using winxp 
<jsalisbury> hrw, ok.  I'll take a look at those patches today.  It sounds like v3.6-rc2 has issues, so you can't test it properly?
<hrw> jsalisbury: looks like usb is not working at all
<hrw> jsalisbury: I do not have ps/2 keyboards anymore
<hrw> jsalisbury: rc1 did not even brought 'cpus' online (i7-2600K) - only #0 and #7 were up
<jsalisbury> hrw, ok.  we'll have to take a look at the patches and see if they can be easily backported to v3.5
<hrw> jsalisbury: I applied them to 3.5.0-10.10 source without fuzz
<jsalisbury> hrw, cool, so it should be an easy cherrypick.  I can build a test kernel this afternoon.  We can submit the patches to the kernel-team mailing list for consideration in to Quantal
<hrw> cool
<rtg> ogasawara, linux-meta-lts-quantal is still waiting to build.
<ogasawara> rtg: sheesh, 9hrs!
<hrw> reboot...
<hggdh> bjf: quantal-on-quantal, VM, show failure on ecryptfs stress test, see https://jenkins.qa.ubuntu.com/view/SRU%20Kernel/job/sru_kernel-quantal-virtual_amd64-kvm-virtual/ 
<hrw> re
<hrw> jsalisbury: mainline kernel rev '9160338de92c0305329be5163a76f849806e83de' with 3.5.0-10.10 config booted fine
<bjf> hggdh: that's "stress" not ecryptfs and you can ignore it though i'll make a note of it
<hrw> jsalisbury: and usb3.0 disk works after plugging
<jsalisbury> hrw, thanks for the info. Is that the only commit that would need to be cherry-picked?
<hrw> jsalisbury: no, its today's HEAD of mainline ;D
<hrw> jsalisbury: those 3 patches which I added to bug were extracted from mainline
<hggdh> bjf: sorry for the mixup :-)
<bjf> hggdh: not a problem
<jsalisbury> hrw, ahh, ok.  
<hrw> HEAD + http://paste.ubuntu.com/1159318/ config == http://paste.ubuntu.com/1159319/ dmesg
<hrw> and disk works
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<bjf> hggdh: why don't you file that as a bug against the tests so i don't forget :-)
<ppisati> isn't it meeting time?
<smb> cking, apw I just did an upgrade of my quantal 64bit alternate kvm and I think there is still an issue with the default cirrus gfx and the X driver. Has one if you a similar vm to cross check?
<cking> smb, not one handy
 * ppisati -> EOD
<smb> ok, maybe I just file a bug and let it be ignored like the other bugs ...
<cking> smb, lemme know the bug number and I can see if I can reproduce it tomorrow
<smb> cking, sure
<cking> smb, aren't you supposed to be packing for your travels soon?
<smb> cking, Did that already, but trying to pass on some other pointers to things I may forget
<smb> Gosh, cannot even get a graphical desktop now after the latest upgrade
<smb> Maybe its the great plan of dprecating unity2d before really having a replacement 
<cking> smb,  I guess that's it
 * cking uses server images for his VMs
<smb> At least the part of now not getting a desktop, the clash between the cirrus drm module and the x driver was before
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues August 28th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<smb> cking, bug 1039648
<ubot2`> Launchpad bug 1039648 in ubuntu "kvm/cirrus: X driver will not load when kernel module is loaded" [Undecided,New] https://launchpad.net/bugs/1039648
<cking> smb, I'm nealy finished in installing, will try to repro
<smb> cking, wow that was quick. I suppose you already had the iso
<cking> smb, no I have a fat pipe to download the images
 * smb forgot cking 's big ass pipe
<cking> ..and speedy laptop too
<rtg_> cking, are you actually getting 50mbit ?
<rtg> apw, what iwlwifi errors are you seeing? 'fail to flush all tx fifo queues' ?
<apw> rtg, http://paste.ubuntu.com/1159446/
<apw> rtg, the end of the trace occurs after i rmmod and modprobe it again to get it working
<cking> rtg, yep, I'm getting 50mbit 
<rtg> apw, I'm only seeing 'fail to flush all tx fifo queues' once in awhile
<apw> rtg, i think i have seen that in the past, but not recently
<rtg> apw, you're getting some pretty ugly warnings even after the firmware restart
<cking> smb, yep, I can reproduce that bug
<smb> cking, Ah good, I mean bad, but good that it is the code broken and not me
<cking> smb, alpha3 worked, updated it and it breaks
<smb> cking, Right it as working at some point. And before todays upgrade the desktop came up when I blacklisted the kernel module
<cking> smb, desktop is so heavyweight for my kind of testing, I normally just install server 
<cking> ..so I would not normally encounter this bug :-/
 * rtg -> lunch
<smb> cking, Me too, but sometimes I want to do some desktop in box stuff. And some other people seem neither... 
 * henrix -> EOD
 * smb -> away
<jsalisbury> hrw, re. bug 1039478 I have a test kernel building now with those three patches applied.  I'll post a link to the bug shortly.
<ubot2`> Launchpad bug 1039478 in linux "WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?" [Medium,In progress] https://launchpad.net/bugs/1039478
 * cking -> EOD
<hrw> jsalisbury: I do not have hardware now - gave it back to the owner
<verwilst> hi, i'm following up on a bugreport that handles a gfs2 kernel oops, very reproducible
<verwilst> if there is a kernel developer/maintainer here who could have a look?
<verwilst> https://bugs.launchpad.net/ubuntu/+source/gfs2-utils/+bug/1020207 for those interested
<ubot2`> Ubuntu bug 1020207 in gfs2-utils "gfs2 kernel oops when deleting file on other cluster node" [Undecided,Confirmed]
<verwilst> makes redhat cluster suite on ubuntu unusable when using gfs2
<dupondje> verwilst: assigned it to 'linux' package, cause this is a kernel bug :)
<verwilst> yeah, didnt really know who are what to assign :)
<verwilst> so i thought, let's ask here ;)
<verwilst> i've put my fair share of hours into this bug, so i hope i get some response :)
<dupondje> is the bug already reported upstream ?
<verwilst> it's fixed upstream
<verwilst> as seen in one of my many comments :P
<verwilst> it's fixed in 3.3-rc6 even
<dupondje> but not in the stable 3.2.x updates?
<verwilst> rah
<verwilst> i messed up the bugreport
<verwilst> can somebody set it back to confirmed? :)
<verwilst> no
<verwilst> not in 3.2
<dupondje> you could spank upstream about that
<dupondje> Kernel OOPS'es should get backported imo
<dupondje> then they get automaticly in ubuntu also
<verwilst> that's what i'm doing :)
<verwilst> just applying pressure to both parties :)
<dupondje> :)
<verwilst> plz revert the fix released :) since i with my pleb powers cannot
 * dupondje trying to contact mozilla developpers to fix a critical bug, now thats a no-go :(
<dupondje> me neither ... i'm sorry :)
#ubuntu-kernel 2012-08-22
<verwilst> hello, i would like to test a small patch to the kernel that fixes a kernel oops: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1020207/comments/11 but my kernel doesnt seem to build with make-kpkg :(
<ubot2`> Ubuntu bug 1020207 in linux "gfs2 kernel oops when deleting file as first action after mounting" [Medium,Confirmed]
<verwilst> fsam7400.c:(.text+0x3b0): undefined reference to `populate_rootfs_wait'
<verwilst> maybe somebody here feels like creating a new kernel deb with this patch that i can test? :)
<apw> verwilst, i'll have a look in a minutre
<verwilst> apw, awesome thanks! just gimme a yell
<apw> verwilst, so is this against precise ?
<verwilst> yip
<verwilst> the 12.04 kernel oops'es as soon as you remove a file on gfs2 :)
<verwilst> it's fixed in 3.3-rc6, which this mini patch is a backport of
<verwilst> if i can test that this patch works, the redhat guy is willing to give his ACK for -stable inclusion mainline
<apw> verwilst, whats in the bug is all mangled, and if you want a specific patch included so you can send in a Tested-by it might make sense to email me the patch so i can apply the exact patch
<apw> verwilst, email in pm
<apw> verwilst, if there isn't a patch i can make one out of that hunk .... let me know
<verwilst> apw, well, i just pasted the thing i made :)
<verwilst> i can mail the patch itself
<apw> which ever you want
<verwilst> it's the one in the comments, right? #11, the 4 lines
<apw> i am assuming thats the one you wanted
<apw> but it is you who is asking, so i derfer to you :)
<verwilst> apw, you have mail :)
<verwilst> it's done in fs/gfs2 btw
<verwilst> maybe i should have done it from the root
<apw> verwilst, i'll cope ... which commit in the upstream kernel is this a backport of?  am just doing the commentary
<apw> verwilst, and i am going to take the liberty of adding your signon
<apw> signoff
<verwilst> apw, http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=718b97bd6b03445be53098e3c8f896aeebc304aa
<apw> verwilst, and we don't need the other hunk ?
<verwilst> apw, normally no, since out_inodes doesnt exist in 3.2
<verwilst> apw, https://www.redhat.com/archives/linux-cluster/2012-August/msg00151.html
<apw> ok.  /me shoves it on a buildder
<apw> verwilst, ok looking at this if we take a previous fixup patch we can take the patch you want unaltered
<apw> verwilst, so that might be a better solution as the missing error case (which your version doesn't have to fix) looks like something we want to fix also
<verwilst> the -EROFS?
<verwilst> that would be VERY nice apw :)
<verwilst> apw, this patch is actually part of a series with some more handy-looking patches: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=891003abb0db6bfffd61b76ad0ed39bb7c3db8e1
<apw> verwilst, ok i'll build a kernel with that as well
<verwilst> apw, not sure about the possibility to get those in, just wanted to show you as it might  make gfs2 a better experience on precise :)
<apw> hmmm, a tricker proposition if people are not hitting the issue
<verwilst> the one i pasted is (for now) the only showstopper for me
<apw> from an SRU perspective
<verwilst> yeah
<verwilst> apw, it was just FYI :)
<apw> verwilst, ok here is the first one: http://people.canonical.com/~apw/lp1020207-precise/ with just your one hunk
<apw> verwilst, second one with the unaltered patch is building now
<apw> verwilst, ok they are both there, the earlier timestamp is your patch, the later timestamp is the two cherry-picks ... test them if you could and let me know
 * apw pokes verwilst
<verwilst> apw, i was out for f00d :)
<verwilst> apw, should i test them both?
<ogra_> eat cake then ...
<apw> verwilst, i would suggest testing the newer one, and if that works we can suggest that to dave woodhouse
<verwilst> alright great
<verwilst> so there are more gfs2-related fixes apw?
<apw> verwilst, this contains just the foundation patch and the full cherrypick of the patch you were porting part of
<apw> we might also suggest separatly that one at least of the other two you mentioned be pushed to stable, but that is a separate transaction me thinks
<verwilst> yeah idd
<verwilst> the gfs2_grow thing for example
<verwilst> oh well, they all look like nice fixes :)
<verwilst> apw, with that other patch included, backporting gfs2 fixes should be much more straightforward i guess in the future
<ppisati> http://www.cnx-software.com/2012/08/20/codethink-launches-the-baserock-slab-arm-server/
<ppisati> ogra_: ^
<ppisati> ARMv5? no, i mean, really?
<apw> ppisati, ? core ARMv7-A processors
<apw> ppisati, i note they all have massive fans on them, not sure thats the idea :)
<ogra_> the v5 system is the management 
<apw> oh thats dumb, so you have to have a different distro on management, awsome
<ppisati> but those could be candidates for the arm builders
<verwilst> apw, well, it certainly boots in kvm.. :)
 * cking reboots
<verwilst> apw, will test a normal server with a cluster now :)
 * ppisati -> out for lunch
 * henrix -> lunch
<verwilst> apw, great success!!
<apw> verwilst, good news
<apw> verwilst, so i'll reply to that original thread with the two patches together
<verwilst> yip
<verwilst> apw, so, do you decide what goes into the new precise kernel?
<apw> verwilst, not on my own no, but a bug with a fix is something which is SRUable
<apw> verwilst, and if it goes into stable then it will hit precise without any action anyhow
<verwilst> apw, i would certainly think so :) thanks a lot for the help btw!
<apw> verwilst, np
<verwilst> apw, will you push it towards stable?
<apw> verwilst, i think the appropriate thing is for me to add your tested-by (if thats ok) to these two patches and email them as a set in reply to Steven
<verwilst> okido
<verwilst> apw, i kinda sent a mail to him as well though, but without the tested-by thing.. feel free to reply and take credit where needed :D
<verwilst> in all my excitement.. :D
<verwilst> ( linux cluster ML )
<apw> verwilst, heh just want him to know you tested it, so i'd add Tested-by: your email in the bottom
<verwilst> well, i pointed him to the link you gave me, so if you add it to the patches there... :)
<rtg> apw, are you guys working on overlayfs ?
<apw> rtg, i am working on it yes, but not related to this discussion above; crashing heap of junk
<rtg> apw, ah, bummer
<verwilst> apw, i'm going to install your kernel on every node of my cluster
<apw> verwilst, that is the *1111* one that you tested right ...
<verwilst> Linux vm02-test 3.2.0-31-generic #48~lp1020207v201208221111 SMP Wed Aug 22 10:19:27 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
<apw> rtg, i have an id patch accepted, an NFS fix pending, and another i am investigating
<apw> verwilst, ok i have cleaned up that directory then so only the relevant files are in there, and added the tested-by:, if you want to check its the email you don't mind being in the public record, and if not tell me in PM what you want :)
<verwilst> it's fine apw :)
<verwilst> nothing my dspam can't handle ;)
<apw> verwilst, heh good, as i am not subscribed to that list, i'll let you keep an eye and poke me if i need to do something with those patches, i am hoping Steve will pass them on, if not then i should
<verwilst> he usually replies pretty quickly
<verwilst> precise is really starting to get somewhere imo
<verwilst> 2 months ago i was on the brink of switching everything to centos :)
<verwilst> because it felt more enterprisy
<verwilst> every step of the way to a working cluster was riddled with bugs :)
<verwilst> but now i chased enough people to fix my last hurdle, it's started to look very nice :)
<verwilst> my faith has been restored
<verwilst> ;)
<verwilst> well, 1 hurdle left in lvm2, but hey
<xnox> verwilst: clvm?
<verwilst> yip
<verwilst> the no-monitoring patch thing xnox :)
<xnox> verwilst: yes. indeed. Do you think we should not have it? TBH I don't know what that monitoring does.
<verwilst> it works for me now because i manually removed the patch from the deb and recompiled, but hey, it will be a warm fuzzy feeling when it will be really fixed
<verwilst> xnox, it's only used to build udeb's iirc
<xnox> verwilst: also in quantal we had clvm init script borked for a little while. Now fixed.
<verwilst> xnox, because dmeventd isnt running or something similar i think
<verwilst> xnox, it's the same in debian though
<verwilst> xnox, ah, is the init script something backportable to precise?
<xnox> verwilst: it should be applied the whole time, it's just in the running system you can specify monitor=1 or whatever the option is.
<xnox> verwilst: precise has it. quantal dropped it for couple of months. So if you recompiled from quantal, beware ;-)
<verwilst> xnox, yeah, but that's the part that's broken :) monitor=xx isnt read anymore
<xnox> verwilst: ah =) interesting.
<verwilst> xnox, i think i took it from debian
<verwilst> the .95
<xnox> verwilst: well quantal now has .95 merge with bug-fixes on top of debian. there are a few things different on debian. 
<verwilst> xnox, https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/833368
<ubot2`> Ubuntu bug 833368 in resource-agents "clustered lvm commands fail with "activation/monitoring=0 is incompatible with clustered Volume Group" error" [Undecided,In progress]
<verwilst> xnox, well, it's currently a test setup, i hope to reinstall them once i go production with all the 'native' precise packages :)
<verwilst> except like libvirt 0.9.13 etc ;)
<xnox> verwilst: well precise has old lvm2 (missed the feature freeze), so you might have to backport lvm2 from quantal.
<xnox> verwilst: but I probably should hunt that patch from .96 and apply it in quantal, possibly precise as well.
<verwilst> xnox, is there a .96?
<verwilst> ah
<verwilst> in the bug you mean
<xnox> yeah.
<verwilst> bugreport*
<xnox> from upstream *gasp*
<verwilst> that would be awesome idd, my coding foo surely isnt strong enough :)
<verwilst> but for the rest, it's working very well
<verwilst> now that the gfs2 thing is solved
<verwilst> i lost many evenings on that problem :P
<xnox> well, we are here to help ;-)
<verwilst> xnox, 2.02.95-4ppa1 is my version
<verwilst> 2.02.95-4 simply recompiled
<verwilst> what did you 'fix' in the init script?
<xnox> verwilst: init stayed the same. But for example the debian version is broke some symbols & the multiarch was done fully. Fixed those.
<xnox> also applied the usual ubuntu patches.
<xnox> I would recomend you to use $ backportpackage to rebuild quantal's lvm2 for precise into your ppa
<verwilst> backportpackage?
<verwilst> ubuntu-dev-tools.. xnox, am i missing out on some good stuff here? :)
<verwilst> i always do apt-get source, dch -v ... debuild -S -sa; dput
<verwilst> :)
<xnox> verwilst: well it does that... automated... and it can also upload it into the ppa for you or build locally =)
<xnox> verwilst: also it has the handy $ pull-lp-source and $ pull-debian source
<xnox> verwilst: it takes these arguments: pkgname [exact-package-version | $distro-series]
<xnox> by default grab latest ;-)
<verwilst> where has that been all my life! :)
<cking> bah, setting up chroots on various boxen takes forever
<cking> hrm, seemed to have hacked around my blasted Virgin Media Super Hub TCP timeout issue. stupid device
<apw> cking, vhub> what did you do?
<cking> apw, http://smackerelofopinion.blogspot.co.uk/2012/08/virgin-media-super-hub-and-ssh-timeouts.html
<apw> silly me
<cking> apw, it is really a ghastly device
<apw> cking, it sounds lame indeed, and this is the V2 device the first ones were utter balls i believe
<cking> yep
<cking> well, I've not had to reboot it like the previous kit I had, so that's a bonus I suppose
<apw> heh swings and roundabouts perhaps
<cking> apw, well, it is fast, so mustn't grumble really
<apw> cking, its like 10x what i have i recon
<ppisati> rsalveti: how was kernel testing?
<verwilst> apw, you have another mail
 * ogasawara back in 20
<rsalveti> ppisati: working fine, built a bunch of packages, used glmark for a while, stable still
<rsalveti> ppisati: seems we got a winner
<brendand> bjf - some forewarning. this DC move has screwed up our server testing capacity, so the next SRU runs may be sans a bunch of servers
<bjf> brendand: ack, thanks for the heads up.
<ppisati> rsalveti: cool
<ppisati> ogra_: ^
<ogra_> :)
<ppisati> correct me if i'm mistaken but:
<ogra_> ppisati, convince ndec, he didnt belive yours is more stable ;)
<ppisati> new kernel + pvr-omap4 = unity3d working, right?
<ppisati> ogra_: tsk.../me neither, actually... :)
<xnox> do we have any bleeding edge / recent kernels backported for lucid?
<bjf> xnox, no
<xnox> bjf: ok, thanks.
<cking> sconklin, ping
<sconklin> cking: yes? I'm replying to your email now . . .
<cking> sconklin, ack
<cking> sconklin, I'm still unsure what kind of "clamping" tool I'm expected to use on that splitter. it is quite chunky and I've only got weedy alligator clips
<sconklin> sorry, perhaps that bit of kit hasn't arrived yet
<sconklin> stand by for a link/photo
<sconklin> oh, and stand by for a revision to my email - I made a mistake in the chart
<sconklin> cking ^^
<sconklin> http://www.amazon.com/Fluke-i400-AC-Current-Clamp/dp/B000EA1ETC/ref=sr_1_5?ie=UTF8&qid=1345654831&sr=8-5&keywords=fluke+clamp+current+probe
<cking> sconklin, OK - did anyone order that for me?
<sconklin> yes, you should receive one. I received my later than the splitter, so I suspect it's on the way
<sconklin> s/my/mine/
<cking> sconklin, ack, do we have a tracking number? I'm having a bad week for deliveries mysteriously not making to my door
<sconklin> cking: ask pete, He handled that during the QA sprint in Lexington, and I wasn't there
 * cking notes that clamp looks like it has some powerful grip, ideal for keeping the kids under control ;-)
<sconklin> cking: it doesn't actually make contact with the wire under test - it measures the sum of the current passing through the clamp loop.
<cking> sconklin, yep, I comprehend that. just looks like a mean grip to it
<sconklin> cking: yep, watch yoru fingers
<sconklin> cking: revised email sent
<cking> sconklin, ta
 * ppisati goes for some groceries
 * rtg -> lunch
<jdstrand> smb`: hey, on bug #1031090, am I supposed to be able to load the kvm_intel module in a precise guest on a *quantal* host?
<ubot2`> Launchpad bug 1031090 in linux "kvm_intel not loadable in a quantal guest" [High,In progress] https://launchpad.net/bugs/1031090
<rtg> jdstrand, smb is on his way to san diego
<rtg> apw, ^^
<jdstrand> smb`: I updated to 3.2.0-30.47-generic in the guest and am running 3.5.0-10.10-generic on the host
<jdstrand> hmm
 * apw looks
<apw> jdstrand, that was being fixed indeed, i don't think i have seen final resolution on the right fix from upstream
<jdstrand> apw: I see. so my quantal host doesn't have the necessary bits either?
<apw> well your precise guest is playing host
<apw> jdstrand, so i am not 100% sure if that would tickle the same issue or not
<jdstrand> apw: this is where it gets confusing-- so, I am running an i7 quantal host (my laptop). I start a precise openstack vm. in the precise vm, loading kvm_intel fails
<jdstrand> $ sudo modprobe kvm_intel
<jdstrand> FATAL: Error inserting kvm_intel (/lib/modules/3.2.0-30-generic/kernel/arch/x86/kvm/kvm-intel.ko): Operation not supported
<apw> is there anything at the bottom of dmesg from that invocation ?
<jdstrand> [  550.189256] kvm: no hardware support
<jdstrand> the kvm module is loaded
<apw> this fix was slated to fix he opposite combination so i am not sure if he would have tested the other way round
<jdstrand> right
<apw> so your test isn't going to test the verification requested there
<apw> though being a valid combination we'd expect it to do something
<jdstrand> it just happens to be that I upgraded in the meantime and am trying to test an openstack CVE on precise :)
<jdstrand> apw: the bit I was concerned about was that the linux task was marked "Won't Fix", but this seems very related
<jdstrand> apw: I'm happy to file another bug, or to comment in the existing one
<apw> linux should be invalid as in theory invalid as that bug is specific to the other combination
<apw> i think we should file a new one, as its as likely to be unrelated as not
<apw> in cause if not symptoms, but do put the new bug number in the old bug 
<jdstrand> apw: interesting. If I do: sudo rmmod kvm_intel ; sudo modprobe kvm_intel nested=1 I get this in dmesg:
<jdstrand> [  972.774373] kvm: VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL does not work properly. Using workaround
<apw> jdstrand, you were loading it without nested=1 ?  isn't that required ?
<apw> for your use combination?
<jdstrand> apw: I was trusting /etc/init/qemu-kvm.conf to dtrt since /etc/default/qemu-kvm has KVM_NESTED=" nested=1"
<jdstrand> (the default)
<jdstrand> I just wanted to be *sure* nested=1 was set
<apw> jdstrand, hmmm ... so i guess can we test nested=1 and see if it makes things work for starters
<apw> as yeah indeed what you said should be true, but perhaps is not
<jdstrand> ha!
<jdstrand> that was it
<jdstrand> the upstart job isn't working right
<jdstrand> apw: ok, thanks
<apw> jdstrand, phew :)
<jdstrand> indeed
<apw> sconklin, bjf, fyi i hacked on the cve-autotriager to wack armadaxp appropriatly when released, which should clean out the cve matrix some
 * henrix -> EOD
<bjf> apw, very nice, thanks
 * bjf -> lunch
 * cking --> EOD
<rtg> sforshee, can you subscribe me to bug #1040215
<sforshee> rtg, done
<rtg> sforshee, thanks
#ubuntu-kernel 2012-08-23
<ppisati> brb
<siretart> apw: sorry for being a PITA :(
<apw> siretart, ?
<siretart> apw: your patch for fixing the xattr issue in overlayfs does not seem to be sufficient
<siretart> bug #1039402
<ubot2`> Launchpad bug 1039402 in linux "[quantal] overlayfs over r/o NFS mount fails to overwrite existing files" [Medium,In progress] https://launchpad.net/bugs/1039402
<apw> what specifically are you doing and what is failing
<apw> and how is it failing
<siretart> apw: have you seen the screenshot? it documents my testcase pretty precisely
<siretart> https://launchpadlibrarian.net/113349441/screenshot-bug1038075.png
<siretart> apw: interestingly, a 'rm /etc/resolv.conf && echo foo >/etc/resolv.conf' does succeed
 * apw goes retest, as thats my test case too
<apw> siretart, the rm echo combination would indeed avoid the bug
<siretart> apw: TBH, I'm not sure about your patch. you check for ovl_copy_up_xattr() returning -EOPNOTSUPP. However, if the underlying fs does not support it, I'd expect the vfs_listxattr call in line 32 to already indicates that (line 34), in which case '0' is returned
<apw> siretart, heh and looking in there i would expect so too, though i ended up at this fix not by inspection but by debugging it and confirming we were returnign that error code
<apw> siretart, and indeed my machine here running the -pre1 of the kernel i sent you works
<apw> hmmm
<siretart> so maybe the fix is correct but incomplete
<apw> except your test is identicle to mine, so i cannot see how i am not testing the same way you are
 * apw goes check that the -pre1 and final kernels behave the same
 * siretart goes installing the kernel on bare metal as well
 * henrix -> lunch
<siretart> apw: funny, I cannot reproduce the problem when booting 'normally', but it does still persist in the nfsroot scenario that involves the 'live-boot' package
<apw> siretart, so the kernel fixes something then
<apw> i can only assume it is about how the nfs mount is mounted
<siretart> hmm.. maybe the -o nolock option?
<siretart> apw: indeed, it seems that -o nolock does make a difference. can you confirm that?
<apw> siretart, sigh, will do
<apw> ok confirmed it works in my testing without -o nolock with the kernels i posted
<siretart> yes, I can confirm that too
<siretart> however, in that nfsroot environment there is no nfs locking daemon available
<apw> siretart, how can i confirm its mounted nolock ?  as my testing mounting -o nolock works
<siretart> apw: grep ',nolock,' /proc/mounts
<apw> siretart, ok its not there dispite  asking for it
<apw> siretart, can you paste your entire mount line please
<siretart> mount -o nolock -o ro -t nfs 1.2.42.40:/i4lab.stand/proj/fai/nfsroot.quantal64 /mnt
<siretart> results in this line in /proc/mounts for me:
<siretart> 1.2.42.40:/i4lab.stand/proj/fai/nfsroot.quantal64/ /mnt nfs ro,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=131.188.42.40,mountvers=3,mountport=57036,mountproto=udp,local_lock=all,addr=1.2.42.40 0 0
<apw> siretart, ok i am simply unable to mount the damn thing no-lock, is there anything special on the export side?
<apw> siretart, oh and you are mounting as v3 there ... mine defaults to v4
<siretart> I'm using these export options: (ro,no_root_squash,sync,no_subtree_check,insecure)
<siretart> yeah, we have disabled v4 as we have experienced a number of problems with it (*cough*solaris*cough*)
<apw> siretart, ok how have you disabled v4
<apw> i suspect that is why i am not seeing it
<siretart> apw: I'm checking. but maybe you can force it by using '-o vers=3' as mount options?
<apw> ahh that does it
<apw> siretart, ok, so this is yet a third bug, i am starting to hate you :)
<apw> siretart,  i have it reproducing now, its definatly something different as it has a differnet error code to user space
<apw> siretart, i am also a bit confused by the nosupp thing as that should be caught in copy_xattr and clearly is not
<apw> siretart, so will go debug it yet more ... bloody nfs
<siretart> apw: you have my sympathy :-(
<siretart> I know that we have disabled v4 in the automounter, but that's not relevant here. would need to ask folks here how we did it, but it seems that's not relevant anymore
<siretart> just FTR, we disable NFSv4 by setting RPCNFSDCOUNT="-N 4 200" in /etc/default/nfs-kernel-server
<ppisati> infinity: can you promote 3.5.0-209.15?
<ppisati> rtg: do i need to send an email to ubuntu-installer for every upload? don't they follow -meta?
<rtg> ppisati, might be a little early in the day for Adam. you need to send an email to the installer list for every ABI bump because it requires manual intervention in the d-i
<ppisati> rtg: ok
<stgraber> hello, I'm being nagged about bug 995998 as it's affecting quite a few thin client deployments, can the fix be cherry-picked in 12.04?
<ubot2`> Launchpad bug 995998 in linux "fix hp t5745 and hp st4757 lvds patch in drm" [Medium,Confirmed] https://launchpad.net/bugs/995998
<rtg> stgraber, seems pretty straightforward
<cking> iso testing thursday is taking longer than I anticipated today :-/
 * ogasawara back in 20
<infinity> ppisati / rtg: No one normally sends us mail about ABI bumps, I just promote and do the bumps based on what's in proposed.
<rtg> infinity, actually, we're _supposed_ to send email notifications of ABI bumps. whether they are actually necessary depends on the person uploading the d-i
<infinity> rtg: Do you actually do so?  If so, it's to a list I'm not subscribed to, and I do most of the d-i ABI uploads. :P
<infinity> (Anyhow, the only reason I didn't do omap4 yesterday was because I was tossing around the idea of doing some d-i bugfixes in the same upload)
<rtg> infinity, ubuntu-installers and kernel-team@lists.ubuntu.com are the 2 lists that get the ABI bump announcement
<infinity> Ahh, well, I am subscribed to kernel-team, I just rarely read it. ;)
<infinity> Anyhow, I don't need the reminders, so it's moot.  I agree that it's still good practice to send them.
<xnox> rtg: infinity: maybe the ABI bump emails were relevant before we were using $dev-proposed. It was an indication to me - do not do partial dist-upgrade until things settle.
<ppisati> do any of you have a working dvi <-> vga adapter?
<ppisati> i bought one but it seems it's not working...
<cking> ppisati, co-incidentally, I just picked one up that works as you asked that question
<ppisati> doh!
<ppisati> brand?
<ppisati> shape? price?
<cking> no idea, let me send a photo of the pins
<ppisati> mine is exactly this one: http://www.qvs.com/images/DVI_VGA_ADAP.jpg
<cking> ppisati, see http://en.wikipedia.org/wiki/Digital_Visual_Interface, mine is the DVI-A
<ppisati> bought from amazon
<cking> yep, looks the same to me 
<cking> DVI-A (analogue) for VGA
<cking> I love DVI, so many standards in one handle socket
<ppisati> :(
<cking> s/handle/handy/
 * ogasawara lunch
 * cking -> EOD
<cyphermox> hey; seems like there's a bad side effect to a fix included in 3.2.0-29.45; just thought to bring it up if you run into other reports of it: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1035590
<ubot2`> Ubuntu bug 1035590 in linux "Kernel update on 10 Aug 2012 affects nm-applet signal strength" [High,Confirmed]
<herton> cyphermox, yes, the fix that brought this bug should be this: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-precise.git;a=commit;h=d5b65f764c414a8da02c479f7fa57cfaee603fd3
<herton> came through 3.2 stable update
<herton> at least we think it is this one, that was the only change to ipw
<herton> cyphermox, should we revert it, or will this be handled through nm? I think we can't ask stable upstream to revert this, seems just something that affects our nm+kernel
#ubuntu-kernel 2012-08-24
<cyphermox> herton: right, we don't want to revert this, it's going to be in backported kernels too
<cyphermox> I think I'll cherry-pick a patc
<herton> ack
<cyphermox> a patch from NM to fix up this detection code, should make everything work again.
<cyphermox> (and will be future-proof)
<herton> cyphermox, ok cool. I'll mark the linux tak invalid
<herton> *task
<cyphermox> herton: thanks
<ppisati> moin
<ppisati> brb
<verwilst> apw, one gfs2 bug squashed, another one pops up :P
<verwilst> i kinda feel like i'm the only ubuntu user that uses gfs2 :P
<verwilst> ( which probably is pretty true :) )
<apw> ppisati, moin
<ppisati> i've a problem with my mutt setup: from time to time, it seems to hang there... grrrr...
 * henrix -> lunch
<ogasawara> rtg: I'm gonna prep an upload, anything you need to push before I kick off test builds?
<rtg> ogasawara, do you think 3.5.3 will land today ?
<ogasawara> rtg: I am expecting it soonish.  I do plan on doing another upload tuesday before beta-1 freeze, so we can pick it up then if it does land.
<rtg> I guess if it does we can still upload next week
<rtg> ogasawara, fire away
<rtg> ogasawara, did I mention I pushed ubuntu-r v3.6-rc3 yesterday ? still got some armhf build problems that I'll go after today.
<ogasawara> rtg: ah cool, thanks
<rtg> ogasawara, should prolly sync with Quantal as well
<ogasawara> rtg: I need to get back in the habit of pushing to both
<rtg> ogasawara, I've got the checkpoint tag. I'll just go through and apply the relevant patches from Quantal
 * ogasawara back in 20
<herton> rtg, I'm still looking at that gso stuff. If I didn't got it wrong, netif_needs_gso is true if we are going to emulate the GSO stuff, that's why we return 1 there. But I think I was wrong about using the check inside netif_needs_gso for Lucid, seems the features flags from the device can also be used later, eg., inside dev_gso_segment->skb_gso_segment which also calls skb_gso_ok inside it 
<rtg> herton, I'm tempted to just dump the whole mess. I don't think it is really vulnerable, at least not like Precise and later are.
<herton> rtg, seems to depend on the driver+hardware used for that CVE to be triggered
<rtg> herton, agreed, so I'm not real concerned. its more of a PITA then its worth.
<herton> rtg, only sfc is using that gso_max_segs, so probably is the only one affected
<herton> actually, since other drivers don't set gso_max_segs, it seems only sfc is doing gso...
<LoT> what's the latest Precise kernel that is not in -proposed?
<bjf> LoT: 3.2.0-29.46
<LoT> in the latest precise kernel, did a rss-counter bug (fixed in 3.4.x) get patched?
<LoT> bjf:  that's what i found, from checking the repos.  see last message
<bjf> LoT: you could check the git repo to see if the commit you are interested in is there
<LoT> not even sure what the commit was
<LoT> i'm not a kernel expert, i'm being stabbed by a user of my shell(s) who claims they are a kernel expert...
<bjf> LoT: there are likely over 150+ commits
<LoT> saying we should upgrade to 3.4.xx
<LoT> i said to them to shut up :p
<rtg> ogasawara, repushed Ubuntu-R-sync and ubunt-r. I'll get the LTS packaged and built after lunch
<ogasawara> rtg: ack
 * rtg -> lunch
 * cking messes up an rbd snapshot and calls it a week. fail
 * cking -~> EOD
<infinity> bjf: Are armadaxp and ti-omap4 being invalidated and re-based for precise to catch the same bugfix as master?
 * ogasawara lunch
<bjf> infinity: since that is the point of the bug fix, i'm assuming so though i've not heard anything about them specifically
<bjf> infinity: and since the folks responsible for those two flavours are gone for the day ...
<herton> bjf, infinity: the bot at least will open new bugs for ti-omap4 and armadaxp once the current master precise packages built on the ppa, they should get notification this way also
<herton> *are built
<bjf> herton, good point, thanks
<infinity> herton: That seems odd.  Shouldn't the bot be opening derivative bugs when the source is uploaded, not when the binaries build?
<infinity> herton: Seems like some unnecessary lead time, there.
<herton> infinity, it was just to ensure the packages build and there are no other problems on the branch before the rebase, already happened that we had packages that failed to build one or other time, but could be changed
 * rtg -> EOW
<DanMD> Hey there everyone :), is there anyone out there with any experience building the ubuntu-precise kernel?
<DanMD> I have a very strange issue.. Basically I am compiling one of the tags in the ubuntu-precise git repo, I am able to install it and everything works fine. However, if I try and build a kernel module for it, the kernel module cannot be inserted
<DanMD> insmod will simply give me a "Killed" message and a line in dmesg says "BUG: unable to handle kernel paging request at ffff8800e018105e"
<mjg59> DanMD: There's a bug in your kernel module
<DanMD> mjg59: Thank you so much for replying!! I was thinking that as well, but I created my own kernel module that does nothing but printk, it doesn't actually contain any code.
<DanMD> mjg59: Other than the module_init and module_exit functions
<DanMD> mjg59: It seems like any module I try and create with the linux-headers package that was created in the build fails this way
<DanMD> mjg59: Could there possibly be anything wrong with how I built the kernel?
<xnox> bug 1038055 is now believed to be kernel issue
<ubot2`> Launchpad bug 1038055 in ubiquity "cannot unlock LUKS devices, in kvm with cirrus graphics" [Undecided,Invalid] https://launchpad.net/bugs/1038055
<xnox> specifically graphics fail to initialise correctly
<slangasek> jsalisbury: ^^ xnox's bug #1038055 is a rather significant issue for quantal VMs running under kvm; can you get it on The List?
<ubot2`> Launchpad bug 1038055 in ubiquity "graphics fail to initialise correctly, in kvm with cirrus graphics (after LUKS install)" [Undecided,Invalid] https://launchpad.net/bugs/1038055
#ubuntu-kernel 2012-08-25
<jsalisbury> slangasek, sure thing
<slangasek> thanks much :)
<jsalisbury> slangasek, added to the kernel team hot list.  
<jsalisbury> slangasek, I also added our standard mainline kernel test request/blurb
<slangasek> ah, right
<slangasek> ok, will do that this weekend-ish
<jsalisbury> slangasek, cool, thanks.  that just lets us know know if its already fixed in the mainline kernel.  If it is, we can cherry-pick the fix.
<slangasek> xnox: hurray, I just tested in my VM and got the opposite result ;)
<slangasek> ah, I didn't install linux-image-extra
#ubuntu-kernel 2013-08-19
<jjohansen> brendand: are you done with https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1205381
<ubot2`> Launchpad bug 1205381 in Kernel SRU Workflow security-signoff "linux: 3.2.0-52.78 -proposed tracker" [Medium,In progress]
<brendand> jjohansen, yeah i just reset it to fix released. you can go ahead
<jjohansen> brendand: alright, thanks
<rtg> apw, kernel.ubuntu.com/~rtg/3.11.0-3.6 for -rc6 test binaries
<smb> rtg, There might be no him this week
<rtg> ogasawara, http://kernel.ubuntu.com/~rtg/3.11.0-3.6 to try out on your misc HW. I'm gonna upload this since it has passed smoke testing on 3 relatively disparate platforms.
<ogasawara> rtg: ack
<ogasawara> rtg: boot tested on 3 different intel boxes here, all running fine here on 3.11.0-3
<rtg> ogasawara, cool
<infinity> brendand: Around?
<brendand> infinity, yep. hi
<infinity> brendand: What's the ETA on cert testing for raring finishing up?
<brendand> infinity, tomorrow morning. i was hoping to get results today but our test lab was a bit undermanned this morning and a snag was hit
<brendand> infinity, if you really want to i can push it now, but spoke with bjf on friday and the consensus was that it's better to get it fully tested since it will be the kernel for 12.04.3
<infinity> brendand: Ahh, hrm.  Has it passed on any reasonable cross-section of machines yet?  Yeah, it'll be the .3 kernel, but that also puts in a bit of a scheduling mess. ;)
<infinity> (Unless we slip the .3 release, which we're considering, if Cert won't have the time/manpower to catch up)
<brendand> infinity, catch up with what?
<brendand> infinity, it's passed on a fair number of systems already
<infinity> brendand: Catch up with whatever magic you guys do for ISO cert for point releases.  I'm a bit hazy on that, personally. :)
 * rtg -> lunch
<lamont> I really am hating the lockups I see with my NVIDIA Corporation GT218 [GeForce 8400 GS Rev. 3] (rev a2)
<infinity> lamont: nvidia or nouveau, which kernel, etc?
<lamont> infinity: since about quantal
<lamont> beyond that, give me commands
<lamont> 3.8.0-27-generic is the kernel version that just locked up on me
<infinity> lamont: lsmod might be helpful if you honestly don't know which video driver you're using. :)
<lamont> nouveau
<lamont> is loaded and depending on things, anyway
<lamont> | grep nvid has 0 lines
<infinity> lamont: But if it's nouveau's fault, you probably want to whine at tjaalton, and possibly try the non-free driver to see if it suffers similar issues.
<infinity> (If both drivers hate you, it could be hardware, overheating, etc)
<lamont> heh. ok
<lamont> ISTR switching didn't help much.  OTOH, it's pretty well ventilated, etc.
<lamont> but ok
<infinity> It's pretty rare for both drivers to fail in the same or similar ways, unless your card is bust.
<infinity> And heat's the usual cause of video lockups.
<infinity> Unless you have an i915, then the usual cause is lolintel.
<lamont> infinity: the driver thing was more not really remembering if I'd ever cared enough to switch to non-free
<lamont> but I'll do that, and see what it does, then assume heatdeath if that's relevant.
<tjaalton> lamont: you might have luck triaging that one with mlankhorst
<lamont> fwiw, it tends to happen when one is stupid enough to scroll with the thumbwheel or otherwise switch rapidly between screens/windows
<tjaalton> he's working on the driver upstream
<lamont> there was a time when I didn't call that behavior 'stupid'
<infinity> tjaalton: mlankhorst was going to be my other suggestion, but he's not in here and fails to tab complete. ;)
<tjaalton> infinity: yeah, noticed the same :)
<tjaalton> lamont: file a bug (ubuntu-bug xorg) and then poke him on #ubuntu-x for instance
<infinity> lamont: Ahh, hrm.  That's a curious behaviour pattern.  It's a hard video lockup when you do that?
<tjaalton> and if it's easy to reproduce, maybe try the saucy kernel, or fresh mainline
<lamont> infinity: SYSTEM lockup, frequently
<infinity> lamont: I'd give 20-to-1 odds the non-free driver won't have that same problem, then.
<lamont> but yeah, video locks hard, then goes all whackamole
<lamont> getting into the box to get info has proven problematic
<infinity> lamont: Well, it could still potentially be bad hardware if the actual precipitating event is just "flipping a ton of buffers" and you have bad RAM.
<lamont> infinity: two identical machines (ordered/shipped in the same order) both exhibit the problem.
<infinity> But it smells more like a driver bug, from your description.
<lamont> needless to say, my wife is not happy either
<infinity> Ahh, and that nails it even more.
<infinity> Definitely try the non-free driver, at least on her kit. :P
<tjaalton> yeah
<infinity> Wife happiness is important.
<lamont> heh.  shall do
<lamont> it might actually have started in precise... can't recall for sure
<lamont> I mean, it's _possible_ that there was a defective lot of graphics cards, but....
<infinity> Possible, but unlikely.  Especially since that sort of behaviour would be "a bad batch of video RAM that happened to land on my two video cards", which is slimming the odds a bit.
<infinity> Or you have two fans that have both stopped spinning, and you haven't noticed. :P
<arges> bjf[afk]: hi i noticed that bug 1201869 was marked 'fix released', but that particular bug was reverted from the kernel. is this a mistake, or do i just need to create a new bug when I submit a new SRU
<ubot2`> Launchpad bug 1201869 in linux (Ubuntu Raring) "poor networking throughput across an OpenStack Neutron router on 3.5/3.8 kernels" [Medium,Fix committed] https://launchpad.net/bugs/1201869
<infinity> arges: That was just the LP janitor marking it Fix Released because it was mentioned in the changelog, just set it back to In Progress.
 * infinity does that.
<infinity> arges: Same thing will happen for raring when it's released, same remedy applies.
<arges> infinity: ok i'll set it when i see it. thanks
 * rtg -> EOD
#ubuntu-kernel 2013-08-20
<brendand> infinity, https://bugs.launchpad.net/kernel-sru-workflow/certification-testing/+bug/1211934. sorry for the delay
<ubot2`> Launchpad bug 1211934 in Kernel SRU Workflow "linux: 3.8.0-29.42 -proposed tracker" [Medium,In progress]
<infinity> brendand: Many thanks.  I'll release that right now before I pass out.
<brendand> infinity, are your working hours 10am - unconsciousness?
<infinity> brendand: Something like that.
<brendand> infinity, hardcore
<infinity> brendand: One man's hardcore is another man's stupid. ;)
<brendand> infinity, i was being nice :)
 * henrix -> lunch
<henrix> hmm.... i can access http://kernel.ubuntu.com/git but git fetch is failing me with 'Name or service not known'. is anyone else seeing this?
<henrix> sorry for the noise. it was just my ISP. again.
<smoser> anyone want to comment for me on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1181755
<ubot2`> Launchpad bug 1181755 in aufs-tools (Ubuntu) "aufs include is broken" [High,Confirmed]
<rtg> smoser, I'm lookign at it
<smoser> it seems to me like we're just not collecting up a uapi directory ?
<rtg> smoser, not sure yet, but it seems quite broken.
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<hallyn_> jodh: smb: fwiw, qemu-system-x86_64 on i386 should simply run a 32-bit guest iiuc
<smb> hallyn_, Thats what I _heard_ but it made a difference
<jodh> smb/hallyn: where can we get definitive answers to these questions?
<hallyn_> jodh: what questions
<smb> hallyn_, I guest the one what is the expected behaviour doing qemu-system-x86_64 inside a 32bit guest. 
<hallyn_> jodh: keep in mind that while i'm fighting it, debian wants to obsolete the /usr/bin/kvm wrapper.
<hallyn_> make you use qemu-system-$arch
<hallyn_> so if *that* turns out to be the problem (which I would doubt) then we shoul djust get rid of kvm :(
<smb> hallyn_, Not sure this is also something that might get deprecated, but currently alternates sets up a qemu link that either goes 64bit or 32bit depending on the installation
<hallyn_> smb: so are you implying that the first level guest is 64-bit on 32-bit, and second level guest thinks its pure 64-bit so does things slightly differently in kvm kernel bits?
<hallyn_> smb: i shoudl shut up, you guys are making fine progress.  i will read through the bug tomorrow and see if i can jump in with anything.
<smb> hallyn_, Well I can only guess what the host is (my guess would be 64bit). Which then starts an instance that is 32bit and using 64bit qemu binary to start another 32bit guest seems to do something weird at some point
<smb> Not quite sure yet what, but somehow it seems to cause hangs on modprobe
<hallyn_> smb: you mean host is 64-bit hw and 32-bit userspace?
<hallyn_> otherwise why would it default to creating 32-bit guest.  never does for me
<smb> hallyn_, Because you ask it to though openstack ami? 
<hallyn_> oh
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 2 minutes
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues August 27th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
 * rtg -> lunch
 * rtg -> EOD
<hallyn_> smoser: drat, i didn't realize the mainline kernelbuilds don't have overlayfs.  there's a waste of 5 mins
<smoser> doh!
#ubuntu-kernel 2013-08-21
<jodh> smb: re bug 1208455, I've tried running with 'qemu -enable' on a 64-bit canonistack instance and this appears to consistently kill the canonistack instance :(
<ubot2`> Launchpad bug 1208455 in linux (Ubuntu Saucy) "general protection fault running apt-get inside double nested kvm VM" [High,In progress] https://launchpad.net/bugs/1208455
<smb> Only -enable? Or -enable-kvm? Anyway, err kills the whole instance? Maybe let me know the image number and I look myself
<jodh> smb: 'qemu -enable-kvm'
<jodh> smb: I've been trying with image ami-0000047d.
<jodh> smb: the image boots, but running prepare-testbed runs using qemu kills the canonistack instance.
<smb> jodh, Ok, let me start one and look into its environment
<jodh> smb: thanks
<smb> jodh, Bah, so at least thing I was wrong about is qemu always being the same as arch. Obviously (looking at canonistack and another machine) it is always i386/32bit. Not that this would explain the crash (or should). Just is not what my expectation was.
<smb> In my local testing I was using qemu-system-i386 in all cases then, not as I thought both, depending on 1rst level guest.
<smb> jodh, But beside of that, prepare-testbed has the 2nd level guest running...
<smb> jodh, Are you still using the variant without byobu and with nographics?
<jodh> smb: I've disabled byobu, but wasn't running with nographics. I'll re-add that...
<smb> jodh, Very likely, as you are now on a 64bit instance, you would want at least use qemu-system-x86_64 again (sorry I should have verified that before)  as peeking inside the running instance of prepare-testbed shows the guest without VMX and I am not sure forcing core2duo and qemu-system-i386 go together well
<smb> jodh, But give me a few minutes I am verifying this now on canonistack
<jodh> smb: ack.
<doko> apw`, ogasawara: do you run the trinity tests on the ubuntu kernels?
<smb> jodh, Ok, sorry for the delay, at least prepare-testbed was running through successfully with qemu-system-x86_64 -enable-kvm on the 64bit instance and peeking inside the testbed VM it had VMX and kvm modules loaded
<jodh> smb: using qemu-system-x86_64 for prepare-testbed+run-adt-test and then using just 'qemu' for the final vm seems to have killed the qemu-system-x86_64 vm.
<smb> That final VM, that had graphics enabled (no -nographics)? It seemed to make a difference on the outer call
<smb> Maybe something about iommu or lack of... (thinking alout)
<jodh> smb: yes, it uses "-nographic" so I can log the output of the vm. I can try again withouth, but I'm at the point when I'm thinking maybe we should rethink the whole testing strategy to avoid nested kvm's altogether atm. Even if we can find the correct combination of architectures, qemu binaries and qemu options, it all feels very fragile to me.
<smb> jodh, Yes, at least going through combinations of cpu bitsize and guest arch. :/
<smb> jodh, From what I heard the sec-team was saying they use nested VMs, but probably a 64bit first level all the time and probably not deeper that a 2nd level
<smb> It sounded yesterday that what you try to accomplish may be done without nesting but multiple VMs... So you could potentially avoid these issues
 * henrix -> lunch
<ogasawara> doko: nope, is that something you'd like to see ran?
<doko> ogasawara, the debian kernel maintainer asked me to run this for x32, making it a prerequisite to enable the x32 syscalls in the debian kernel
<doko> just wondering if it would make sense to run this for ubuntu kernel builds in general
<ogasawara> doko: we'll take a look
<doko> thanks
<disposable> why is it that if I boot up 3.9 kernel with the 'gfxmode $linux_gfx_mode', i get black screen. It works fine without that line in grub. Before 3.9, that was never an issue even with kernels without ubuntu patches.
 * rtg -> lunch
 * rtg -> EOD
#ubuntu-kernel 2013-08-22
<infinity> sforshee: Your wireless drivers suck.
<infinity> sforshee: http://paste.ubuntu.com/6012393/
<infinity> sforshee: ^-- The result of trying to turn on wireless via my hardware rfkill.  Rebooting "fixed" it.
<sforshee> infinity: the log plainly says it's a hardware error, so I'm blameless :-P
<infinity> sforshee: Uh huh.  If you say so, Freshest.
<sforshee> infinity: which kernel is that?
<infinity> sforshee: 3.11.0-3.7
<infinity> sforshee: I'm not really in a convenient place to debug/diagnose right now, but it seems that booting with wireless enabled works, resuming with it disabled, then enabling it causes the above.  Untested if booting disabled and enabling does the same, but probably.
<sforshee> infinity: okay, I'll try to reproduce later. I think I only have one machine with a hard rfkill switch, and it happens to be the machine I'm using to do stuff right now.
<infinity> sforshee: Bonus points if it happens to be an IvyBridge thinkpad (x220, t420, etc)
<infinity> s/Ivy/Sandy/
<mwhudson> i have an x220 here
<mwhudson> otoh, not saucy
<sforshee> infinity: it's a thinkpad, but not sandybridge. Arrendale.
<infinity> sforshee: Alright, when I'm not squirting blood into a baggie at the Red Cross, I'll see if I can come up with more useful debugging info.  But if you can reproduce, great.
 * Sarvatt was expecting brcmsmac fail there since sforshee got pinged, but instead an actual hardware error with "magic" intel firmware..
<Sarvatt> hrm can't reproduce it on an x1 carbon with 6205 wifi, guess you need an old 6200 or 6300 using firmware version: 9.221.4.1 build 25532
<infinity> Sarvatt: I just blame sforshee for *all* my wireless issues.  He did this to himself at one point by being silly enough to actually solicit me for wireless bugs.
<Sarvatt> sforshee: your ilk might hit it, most snb shipped with 6205...
<Sarvatt> infinity: is that 6300?
<infinity> 03:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 3e)
<infinity> (Yes)
<Sarvatt> yeah, they went to a new gen of wifi cards for 6200 series for snb but kept older 6300 around
<Sarvatt> but if he has an ilk with 6200 it probably uses the same firmware as that
<Sarvatt> obviously a firmware bug, not anything he can fix though :P just need to report it to intel
<infinity> I'm less convinced on the "obviously a firmware bug" unless it was recently revved.
<infinity> But I can bisect that later too.
<Sarvatt> not sure if that was, but some intel wifi firmware did get revved in 3.11, the ones shipping in haswell systems can't use firmware from 3.10 on 3.11 because the api changed
<Sarvatt> https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/iwlwifi-next.git/commit/?id=a2d0909a687b4d250cc2b7481072e361678745ba just 7260/3160, nevermind
<Sarvatt> going to assume they broke old cards to make the new ones work right, thats how intel works :) see 4965 and older intel wifi cards having to disable 802.11n after 2.6.35 kernels aka https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/630748
<ubot2`> Launchpad bug 630748 in module-init-tools (Ubuntu Natty) "iwlagn degrades quickly during normal wifi session" [High,Fix released]
 * smb waits for coffee to kick in
 * amitk thinks about how effective a coffee bath might be...
<smb> Probably depends on how hot the coffee is... but then effective in doing what? :)
<amitk> smb: subcutaneous nicotine absorption
<smb> amitk, Could it be that you listen to too many urban legends? :)
<amitk> :)
<rbasak> Do we have an lpae -generic kernel for ARM yet?
<rbasak> I'm not sure what naming scheme we settled on in the end. Was it -generic-nonlpae and -generic, or -generic-lpae and -generic?
 * henrix -> lunch
<rtg> kamal, I've assigned you bug #1215411
<ubot2`> Launchpad bug 1215411 in linux (Ubuntu Saucy) "libcpupower.so is not installed from linux-tools (saucy)" [Undecided,In progress] https://launchpad.net/bugs/1215411
<rtg> jsalisbury, bug #1215051 and bug #1215269 appear to be straightforward Raring regressions. Have you seen them yet this morning ?
<ubot2`> Launchpad bug 1215051 in linux (Ubuntu) "KVM/QEMU guest bridged network loss on kernels 3.8.0-27, and 29" [Undecided,Confirmed] https://launchpad.net/bugs/1215051
<ubot2`> Launchpad bug 1215269 in linux (Ubuntu) "Unable to boot after kenel update (3.8.0-29)." [Undecided,Incomplete] https://launchpad.net/bugs/1215269
<jsalisbury> rtg, I'll look at them now
<kamal> rtg, ok, but I'm not sure how we'll address the libcpupower.so problem ...  I omitted the libcpupower.so symlink on purpose:  I think that including it would break the ability to have multiple simultaneous  linux-tools-3.8.0-{nn} packages installed
<kamal> rtg, I'll discuss with apw
<kamal> rtg, the two raring regressions jsalisbury is looking scare me too
<kamal> *looking at
<bjf> ogasawara, is .3 going to be released today?
<rtg> kamal, I didn't really understand what he was complaining about in the bug, which is why I dumped it in your lap
<ogasawara> bjf: I'd assume so, infinity I think it in charge of pulling the trigger
<kamal> rtg, ok, I _do_ understand it  :-)   I just don't know how I'll fix it.   my lap is a good place for the bug.
<ogasawara> bjf:  I have not heard officially that i's not
<jsalisbury> kamal, rtg, 1215051 appears to have been introduced in 3.8.0-27, but 1215269 seems to have been introduced in 3.8.28 or 29.  I'll bisect both of them.
<kamal> jsalisbury, excellent, thanks man.
<jsalisbury> kamal, np
<xnox> So on precise, xubuntu & kubuntu had miss-matched and out of date kernels. I've bumped the seeds, can anyone tell me what else needs to happen such that next cd respin gets matching new kernel & udebs & debs?
<xnox> infinity: apw` ^
<federico_> Hi. since kernel 3.8.0-29.42 I'm experiencing total freezes at random times. Once or twice a day. No issues with previous kernels. I had freezes in two different machines.
<rtg> federico_, kamal and jsalisbury are currently pursuing regressions in 3.8 stable. you should start a new bug using 'ubuntu-bug linux'
<federico_> rtg: I booted 3.8.0-27 now, should I reboot on the other version to file the bug?
<rtg> federico_, yeah, if it will stay up long enough
<henrix> jsalisbury: bug #1214852 may actually be a dup of bug #1215155 as the user refers to an external hd (i'm assuming usb)
<ubot2`> Launchpad bug 1214852 in linux (Ubuntu) "encrypted drive can't boot" [Medium,Confirmed] https://launchpad.net/bugs/1214852
<ubot2`> Launchpad bug 1215155 in linux (Ubuntu) "regression in linux-image-3.8.0-29-generic: ipod shuffle 2g does not mount any more" [Medium,Confirmed] https://launchpad.net/bugs/1215155
<henrix> jsalisbury: the installation kernel is -19, which doesn't contain the issue; then, after the upgrade, it doesn't boot. so... it *could* be the same bug
<jsalisbury> henrix, ack
<jsalisbury> henrix, is the fix you have for 1215155 in the 30.43 kernel?
<jsalisbury> henrix, doh, nevermind, I just read your email 
<henrix> jsalisbury: no, it is not. but i have a test kernel (let me get you the link)
<henrix> jsalisbury: :)
<henrix> jsalisbury: http://people.canonical.com/~henrix/lp1215155/
<henrix> jsalisbury: ^^ this is the test kernel containing the fix
<jsalisbury> henrix, great.  I'll ask the bug reporter in 1214852 to test your kernel before all the other testing requests
<henrix> jsalisbury: thanks
<infinity> xnox: What do you mean by "you bumped the seeds"?
<infinity> xnox: I see no seed changes and, in fact, they should have been correct for precise.
<infinity> xnox: Oh, ffs.  They use their own installer seed.  I missed that. :/
<xnox> that.
<infinity> What a mess.  We need to fix that.
<xnox> infinity: one of them is using pae, the other one generic. and neither use enablement kernels.
<infinity> xnox: Thanks for cleaning that up.
<xnox> infinity: no problem. it was guess work for me. I kind of new it was done before, and I went by "bzr log -p"
 * rtg -> lunch
 * rtg -> EOD
<xtofury> ok I finally got my 8" touchscreen working :)  thanks to whomever posted that apk of tscalibrate that actually works proper.
<xtofury>  there is one issue that's popped up.  There are no FTDI drivers in makemenu :(
<xtofury> anybody deal with this one yet?
<xtofury> err menuconfig meant
#ubuntu-kernel 2013-08-23
<kgunn> anyone know much about lttng on arm ?
 * henrix -> lunch
<kgunn> hi there, anyone running lttng on arm/touch regularly ? user side potentially ?
<kgunn> i got it loaded, will calibrate, create a session....but then just get Error: command error after i create my session
<rtg> kgunn, cking was experimenting with it, but he's on holiday until next week IIRC
<kgunn> rtg: thanks...do you know if it _should_ work? (e.g. user error :) possibly ?)
<rtg> kgunn, I'm pretty sure Colin had some success, but I couldn't tell on which platform. Likely an N4
<kgunn> rtg: cool, i'm on n4...
<bjf> jsalisbury, do we have standard instructions on the wiki for enabling proposed?
<jsalisbury> bjf, yes, let me grab the link
<jsalisbury> bjf:  https://wiki.ubuntu.com/Testing/EnableProposed
<rtg> sforshee, isn't this one of your tarbabies ? bug #1215633
<ubot2`> Launchpad bug 1215633 in linux (Ubuntu) "Wireless driver fails with hardware watchdog - doesn't reset" [Undecided,Incomplete] https://launchpad.net/bugs/1215633
<sforshee> rtg: I haven't seen errors quite like those before
<rtg> sforshee, perhaps you could get him to try prior rc kernels, etc.
<sforshee> rtg: I'm perusing the recent brcmsmac changes, as he says the problem just appeared recently
<rtg> sforshee, ack. its your baby now.
<sforshee> rtg: sure would be nice to have Linus's tags in our saucy repo. The last one that's there is 3.9-rc8.
<rtg> sforshee, your wish is my demand. git fetch origin --tags
<sforshee> rtg: thanks!
<rtg> smb, does your ACK on the 2 x86 thermal patches extend to Precise ?
<smb> rtg, Yes, it would have been on it IF I could click
<rtg> smb, cool
<rtg> ogasawara, got anything in the pipeline ? I'm gonna upload this wifi fix.
<ogasawara> rtg: go for it, I've got nothin
<bjf> continuous integration
<rtg> ogasawara, well, I've got those friday short timer feelings, so I'd like to just blow off and go have a beer. oops - did I say that out loud ?
<ogasawara> rtg: dammit, it's only 9am!
<rtg> its after 5 somewhere
<ogra_> tsk, mericans ... 
<ogasawara> rtg: well don't feel bad, I'm skipping out for a long lunch today too
<ogra_> sleeping until 5 and then complaining about the time
<rtg> ogasawara, did you notice that those brits have _another_ day off  on Monday ?
<ogasawara> rtg: I did
<rtg> I may have to join them in solidarity :)
<ogasawara> rtg: do it.  we also got the following monday off
<rtg> true. I'll spend it madly packing ('cause I really hate packing)
<ogasawara> that's right!
<ogasawara> I'll throw a welcome party for you
<rtg> how abot a long lunch ?
<ogasawara> sure, that too
 * henrix -> EOW
 * rtg -> lunch
 * rtg -> EOW
#ubuntu-kernel 2013-08-24
<root_gnewsense_o> hi
<root_gnewsense_o> what is the opiniojn on gnewsense ?
<root_gnewsense_o> opinion
<root_gnewsense_o> I got it running cool in recovery mode (in a RAM disk ?) but cannot get it to run in "normal" mode
<root_gnewsense_o> how do I copy the ram disk to the normal boot ?
<root_gnewsense_o> i'm running it in vbox
<root_gnewsense_o> and ubuntu
<root_gnewsense_o> on xp
<root_gnewsense_o> kernel build was easy on ubuntu but a bugger on gnewsense
<root_gnewsense_o> missing headers....
<root_gnewsense_o> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
<root_gnewsense_o> xxxxxxx
<root_gnewsense_o> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
<root_gnewsense_o> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
<root_gnewsense_o> anyone there ?
<root_gnewsense_o> 139 apparently
<root_gnewsense_o> mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
<root_gnewsense_o> mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
<root_gnewsense_o> mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
<root_gnewsense_o> mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
<root_gnewsense_o> mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
<root_gnewsense_o> mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
<root_gnewsense_o> mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
<root_gnewsense_o> mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
<root_gnewsense_o> mmmmmmmmmmmmmmmm
<root_gnewsense_o> mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
<root_gnewsense_o> mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
<root_gnewsense_o> mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
<root_gnewsense_o> hmmm dead channel
<root_gnewsense_o>  I'll delete it
<seanvk1> quit
<seanvk1> exit
<zequence> Ubuntu Studio devs would like help uploading one last package before FF. Anyone around who could assist?
<zequence> lp:~ubuntustudio-dev/ubuntustudio-default-settings
<zequence> Ah, sorry. Wrong channel :/
#ubuntu-kernel 2014-08-18
<srp> Hello. Using DreamStudio (based on Ubunto 12.04 LTS), since kernel upgrade to 3.2.0.40 (low latency) the machine will not boot anymore. It hangs with a blank screen during the initialization process. I now have kernels 3.2.0-39 (low latency, pretty much stuck to it) and 3.8.0-32 (low latency) installed but the latter will not boot. I have looked at syslog for each kernel but could not find anything odd. Can someone point me towards investigating this issue
<srp>  further?
<srp> s/Ubunto/Ubuntu
<srp> by "looked at syslog" I mean trying to boot with either kernel and then comparing the logs in the hopes of finding what was the step that was "hanging"
<srp> the one thing I could find that seemed strange was that, in the working kernel there's "Console: colour VGA+ 80x25" whereas the locking kernel there's "Console: colour dummy device 80x25"
<srp> since this happens very early in the log, I am unsure whether it could be the problem or not
<dorimon5> "perf samples too long (2519 > 2500), lowering kernel.perf_event_max_sample_rate to 50000". this error turns my ubuntu server hang, i will happpen every 3-4 hours. need some help.
<RAOF> dorimon5: That error isn't what's causing your server to hang.
<RAOF> dorimon5: Why do you think that's the cause of the hang? (ie: What symptoms do you see, what have you done to debug, etc)
<dorimon5> RAOF: i run this command to monitor the kernel log "watch dmesg | tail -50", the last log before hangs happen is this "perf samples too long (2519 > 2500), lowering kernel.perf_event_max_sample_rate to 50000"
<dorimon5> RAOF: im currently using kernel 3.13.0-34-generic. according to my research it is a kernel bug. i want to verify if it is really true and i want to know what is the stable kernel as of now.
<RAOF> And what are you doing when the kernel hangs? Anything in particular?
<RAOF> It does sound like a kernel bug, but the log output you're looking at is at best a symptom.
<dorimon5> RAOF: just reboot the computer. :)
<RAOF> dorimon5: No, I mean what are you doing *before* the kernel hangs.
<dorimon5> RAOF: ahhh. im sorry. :). as of now, my ubuntu server work as a diskless-server (if are you familiar), i
<dorimon5> RAOF: i am using AOE (ATA OVER ETHERNET)
<RAOF> And your server is just entirely idle?
<RAOF> Until it dies?
<dorimon5> RAOF: hhhmm. nope
<dorimon5> RAOF: it is safe to manually install kernel 3.15 in my server, because accordning to them, it is already fixed in kernel 3.15
<RAOF> Depends on what you want it to do. It's mostly safe, but you won't have any Ubuntu changes on it (you might want a kernel-PPA build for convenience, though).
<RAOF> For me, the annoyance with non-Ubuntu kernel is no overlayfs, so schroot doesn't work.
<soren> I'm a bit confused to find "3958afa1b272 net: Change skb_get_rxhash to skb_get_hash" in the Trusty kernel. It changes the kernel API incompatibly with upstream. Upstream didn't include it until 3.14 and Trusty is 3.13, right?
<soren> It makes it really hard to write a generic #ifdef to check for this rename. Is there a special macro that says that this is an Ubuntu kernel so that I can apply a different version check there?
<smb> soren, Apparently it was to get some drivers upgraded to the latest. And I think Trusty should have something
<soren> I really think you ought to provide a compatibility macro so that the API at least matches upstream's 3.13, even if the ABI doesn't.
<smb> soren, That is some road we really did not want to go
<soren> smb: Ok... So what do you propose as a solution to people who want to write kernel modules that rely on that function?
<smb> soren, To check the uts variable thing, which I would tell you as soon as I find it again
<smb> UTS_UBUNTU_RELEASE_ABI
<smb> defined in utsrelease.h (generated)
<soren> smb: So you genuinely expect module authors to handle the fact that Ubuntu renamed a function at a different time than the rest of the world?
<soren> smb: Just so that you don't have to add a macro to fix it?
<smb> soren, Renamed to an upstream change
<soren> smb: BEFORE UPSTREAM!
<apw> soren, would after upstream be any better ?
<soren> Upstream did it in 3.14. You did it in 3.13.
<soren> apw: At the same time would be the sensible thing.
<soren> So I can't even use the LINUX_VERSION_CODE macros to check this, because Ubuntu went ahead and did something else.
<smb> So you have to cope with it when wanting to write code for 3.14+ anyway 
<soren> smb: I sure do.
<soren> smb: So I wrap it up in #if (LINUX_VERSION_CODE <= KERNEL_VERSION(3,14,0)  or whatever.
<apw> LINUX_VERSION_CODE is an upstream meaning one cant change that anyhow
<soren> smb: Except I can't, because Ubuntu is different. For no apparent reason.
<smb> soren, You would know the apparent reason if you looked at the buglink on those patches. 
<soren> apw: I'm not suggesting you change LINUX_VERSION_CODE. I'm suggesting you add a macro to replace skb_get_rxhash with skb_get_hash so that people's modules work.
<apw> soren, we are differnet there to get some h/w support people needed
<apw> soren, and if you file a bug and propose one i wouldn't be supprised if we accepted it
<soren> apw: I did file a bug, but: 
<soren> 07:59 < soren> I really think you ought to provide a compatibility macro so that the API at least matches upstream's 3.13, even if the ABI doesn't.
<soren> 08:01 < smb> soren, That is some road we really did not want to go
<soren> https://bugs.launchpad.net/intel/+bug/1358162
<ubot5> Error: ubuntu bug 1358162 not found
<soren> Oh, whoops.
<soren> Gah, I followed the BugLink from that commit and clicked "REport a bug" so now it ended up reported against Intel.
<apw> i think what smb is saying there is that we wern't going to have considered it, we change too many things in the api too often
 * soren fixes
<soren> apw: And how do module authors generally work around this?
<soren> apw: If you do it often, this must be a common problem.
<apw> soren, we added the UBUNTU_ABI macro as upstream "compat" asked how to tell what ubuntu kernel version we were, that made them happy at least
<smb> I probably misunderstood what soren wanted, too. What I meant is, we don't want to go a stable abi path (the way others do)
<soren> smb: And I'm all in favour of that.
<soren> smb: That's how we've always done it. We've offered API compatibility instead.
<soren> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1358162
<ubot5> Ubuntu bug 1358162 in linux (Ubuntu) "skb_get_rxhash prematurely renamed to skb_get_hash" [Undecided,New]
<smb> soren, So show us the bug and we can think about it in a better way than someone whin...complain about it on irc first thing in the morning ... even worse Monday morning
<smb> thanks
<soren> It's right there ^
<smb> Sorry, for the harshness
<smb> I saw it
<reillyeon> Can I get someone to take a look at this bug? It seems like the fix is a simple cherry-pick: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1353021
<ubot5> Ubuntu bug 1353021 in linux (Ubuntu) "USB HIDRAW Feature Report Implementation for HID devices not working correctly in Ubuntu 14.04" [Undecided,Confirmed]
<rtg> reillyeon, patch sent on the k-team list
<reillyeon> rtg, thank you
<stevespiegel> hi. is there a documented way to create a new kernel flavor? I'm making some modifications to the linux kernel and would like to install the modified kernel along side the one developed by the kernel team. seams like the easiest way to do this is a kernel flavor? but I dont see any docs for this
#ubuntu-kernel 2014-08-19
<apw> stevespiegel, not really, what sort of modifications are you looking to make, perhaps the new support for variant abi would do what you want
<jpds> Is there a reason CONFIG_XFRM_STATISTICS isn't enabled in our kernels?
<rtg> jpds, looking...
<rtg> jpds, no good reason that I can see. I'm also looking at CONFIG_XFRM_MIGRATE and CONFIG_XFRM_SUB_POLICY.
<rtg> I'll turn on CONFIG_XFRM_STATISTICS at least.
<jpds> rtg: Cool, thanks.
<jpds> rtg: There's also: CONFIG_SECURITY_NETWORK_XFRM.
<rtg> jpds, yup, was just looking at that
<rtg> jpds, do you have a use case ?
<jpds> No.
<jpds> I know _STATISTICS at least is useful for debugging ipsec connections.
<rtg> jpds, is it only used for selinux ?
<rtg> _SECURITY_NETWORK_XFRM I mean
<jpds> Looks like it (wrt netlabel).
<rtg> jpds, ok, I'll enable it as well.
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues August 26th, 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.
<svenx> guys, the latest linux-image-3.13.0-34-generic, despite having defined CONFIG_SND_HDA_INTEL=m just like the previous kernels..
<svenx> ..does not contain the snd_hda_intel.ko module at all.
<svenx> has there been some problem with the packaging?
<svenx> my bad, it's in the 'extra' package. let's see
#ubuntu-kernel 2014-08-20
<amitk>  
<apw> amitk,   
<amitk> apw: :) that would've been about the time my son was banging on the keyboard and managing to switch to a different tmux session
<amitk>  
<apw> amitk, i am impressed :)  he will clearly be a geek
<amitk> apw: how is the ubuntu kernel team?
<apw> amitk, we're good ... still churning out kernels
<smb> grumpy and whining. as always that means
<amitk> heh
<apw> heh and that of course, but that needs no saying
<amitk> smb: LPC/ELC is in your neighbourhood this time
<amitk> will you be there?
<smb> amitk, I will be there. Though neighbourhood is a loose term (about 5hrs from here)
<amitk> smb: beats a 15 hr flight, right?
<amitk> smb: great, I'll see atleast some of you there
<smb> Yeah, true. Actually we all are there
<smb> amitk, So you won't even avoid apw :-P
<amitk> smb: apw drinks beer, why would I want to avoid such an outstanding citizen?
<smb> amitk, :) Don't we all do that
<apw> amitk, sounds like a plan :)
<smb> mostly
 * amitk makes a note to avoid you guys the evening before the EAS microconf
<amitk> apw: when is the phone coming out?
<apw> amitk, i don't think i am privy to such minutia :)
<amitk> apw: what SoC will it contain?
<apw> amitk, i am definatly not the one to ask :)  i tend to look at these things and coo about the shiney case; plus i've not see any yet
<amitk> apw: haha :)
<cking> ppisati, did you get the fluke meter working?
<cking> apw, can you sync stress-ng 0.01.31-1 into utopic, I had to make some minor fixes to the man page and help after autosync'ing got turned off earlier this week
<apw> cking, sure
<cking> ta
<apw> cking, and done
<ppisati> cking: nope, because the meter didn't turn on
<ppisati> cking:  i did the hw mod instead
<ppisati> cking: i think it's a problem with the fuse behind
<ppisati> cking: it says "1/8amp for 220v" but there was a 250mA fuse
<cking> ppisati, there is a 220/110 V voltage selector on the back - did you follow the manual?
 * cking hopes it didn't blow up
<ppisati> mlankhorst: FYI - bug 1359262
<ubot5> bug 1359262 in mesa (Ubuntu) "Chrome + Radeon + hardware acceleration: black Google maps tab" [Undecided,New] https://launchpad.net/bugs/1359262
<mlankhorst> ok I'll look
<leighman> hey, trying to load a backported drm module on 14.04 using dkms but it is tainted
<leighman> is it to do with signing? can I enable that?
<leighman> taint code in 4098
<leighman> drm and i915 module
<apw> leighman (N,BFTL), i think  it tells you why when  it taints, in dmesg
#ubuntu-kernel 2014-08-21
<srp> howdy. Is there any way to compare kernel config params (i.e. the CONFIG_ bits in config-<kernel-version>) between two different versions?
<srp> other than writing a program to do so or comparing by hand, I meant
<gerald_> q
<apw> srp (N,BFTL), not really, mostly by writing comparitors
<leighman> hey, trying to load a backported drm module on 14.04 using dkms but it says it is tainted
<leighman> is this to do with signing? can I enable signing somehow?
<leighman> taint code is 4098
<leighman> drm and i915 module
<apw> leighman, i think  it tells you why when  it taints, in dmesg
<apw> though it is very likley them not being signed is what it says
<apw> you cannot sign external modules as the key used to sign internal modules has been destroyed deliberatly
<apw> why do you care that it is tainted
<leighman> apw: it disables trace events
<leighman> due to http://lwn.net/Articles/588799/ I think?
<leighman> /proc/.../tainted gives 4098
<leighman> which seems to be TAINT_OOT_MODULE and TAINT_FORCED_MODULE
<leighman> TAINT_FORCED_MODULE causing trace events to be disabled as in the lwn article
<leighman> so I think I might be out of luck?
<leighman> but eg. vboxdrv does not appear in modinfo to be signed but is not listed as tainted
<apw> no idea how vbox would avoid that, unless it specifically messes with those flags somehow
<apw> leighman, it sounds like you have a valid usecase for the patch mentioned, no idea how ugly it would be to port
<apw> you might want to start a bug on this against "linux" so we can consider fixing that
<apw> as we have a lot of OOT modules which tracing sounds useful in
<apw> actually the patch looks pretty self contained, so it might be applicable
<apw> leighman, ^
<leighman> does look like a nice simple patch actually *he says*
<leighman> okay, will file a bug against linux and subscribe you?
<leighman> apw: ^
<apw> let me know the bug # here as i won't find it otherwise
<soren> smb: Thanks for looking into https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1358162
<ubot5> Ubuntu bug 1358162 in linux (Ubuntu Trusty) "skb_get_rxhash prematurely renamed to skb_get_hash" [Undecided,Fix committed]
<soren> smb: I have a small request, though.
<soren> smb: Here's that patch I applied to handle it: https://github.com/JioCloud/contrail-vrouter/commit/c31ab9b1d05acb6814a3ee8ddda16882cdcc0672
<soren> smb: After your patch gets applied, skb_get_rxhash will be #defined twice.
<apw> then i suggest you make yours say
<apw> #ifndef foo
<soren> smb: What would you suggest? A more specific KERNEL_VERSION (does that even change between kernel revisions in Ubuntu)?
<apw> #define foo
<soren> apw: That's what I was meaning to do, but I wasn't sure if that'd be sufficient (since it depends on import order).
<apw> in the version check?
<apw> soren, though this new version will be a new ABI i am sure
<apw> (our new version)
<soren> apw: How does that help me?
<apw> you know you only need the compat for that one abi
<soren> apw: Anyway, what I was wondering was if you could wrap your #define in #ifdef as well... Or am I completely off here?
<soren> apw: ...so that it won't depend on a specific order of #include's.
<leighman> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1359670
<ubot5> Ubuntu bug 1359670 in linux (Ubuntu) "Unsigned oot modules are wrongly tainted and trace events disabled" [Undecided,New]
 * apw suspects if anything we should #undef it
<soren> apw: I dunno. It might not be a problem at all. I just saw the change and wasn't sure if #ifndef'ing on my side would be sufficient.
<apw> soren, might not, i think you are lucky in that it has not been uploaded yet.  I suspect for us we should #undef before defining it to be sure we are getting what we expect.
<apw> smb, ^
<soren> apw: I was exactly hoping to get this addressed before the upload.
<soren> apw: Thanks for considering it.
<apw> leighman, i assume this is 14.04 which is giving you trouble
<leighman> apw: yup
<apw> leighman, ok i've pushed some test kernels to your bug, if you could do the do on those.
<leighman> apw: is there a linux-tools-3.13.0-35  - I get unsatisfiable dependency on linux-tools-3.13.0-35-generic
<leighman> apw: anyway taint bitmask looks correct and no messages in dmesg about disabling tracepoints
<apw> leighman, that is good enough for me, i'll push that out for review
<leighman> apw: awesome, thanks
<leighman> apw: when would it land if so?
<apw> if accepted, in the next SRU round, of the order of 3 weeks
<leighman> apw: cool,thanks
<rtg> stgraber, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1344049/comments/3
<ubot5> Ubuntu bug 1344049 in linux (Ubuntu Trusty) "Please cherry-pick tc rule fix for userns" [Undecided,Fix committed]
#ubuntu-kernel 2014-08-22
<zyga> bjf: hey
<zyga> bjf: quick question, what was the reason for the delay of the last pack of kernels (that we're currently testing)
<bjf> zyga, it was just 2 days. we were working through some process issues.
<bjf> zyga, you have this week and all next week for testing
<zyga> thanks
<stgraber> rtg: thanks for the ping, will test now
<rtg> stgraber, yeah, bjf is pretty harsh about reverting unverified patches
<bjf> tjaalton, bug #1353405 and bug #1338582 need verification
<ubot5> bug 1353405 in linux (Ubuntu Trusty) "[i915_bdw] fix a warning message during resume from suspend" [Undecided,Fix committed] https://launchpad.net/bugs/1353405
<ubot5> bug 1338582 in linux (Ubuntu Trusty) "[i915_bdw] No picture on BDW-Y SDP with latest kernel" [Medium,In progress] https://launchpad.net/bugs/1338582
<tjaalton> bjf: indeed, verified
<bjf> tjaalton, thanks much
<Beeelow>  /msg NickServ identify whatever
<arges> smb: hey still around?
<stgraber> rtg: fix confirmed, sorry for the delay!
<rtg> stgraber, no problem. did you fix the tag ?
<jrsharp_> hey all
<jrsharp_> I'm attemping to build a specific kernel release for armhf (3.13.0-47-generic) and I'm wondering the best way to get the specific toolchain that used to create the distributed binary for 3.13.0-47-generic...
<jrsharp_> based on dmesg output from that booted kernel, it appears to be gcc-4.8, but for my purposes, I want to try to duplicate the results of that build as exactly as possible
<jrsharp_> would it have been built using the gcc-4.8-armhf-cross package on an Ubuntu x86 build host?
<jrsharp_> and I see that gcc-4.8-armhf-cross is in main on 14.04...
<jrsharp_> I am using 12.04... will that prevent me from picking that package up?
<jrsharp_> putting the toolchain aside for the moment, how would I find out what kernel config was used to build that distributed kernel binary?
<jrsharp_> (besides /proc/config.gz on the running kernel)
<rtg> jrsharp_, all packages are built using native compilers, so the armhf bits are built on an arm host
<rtg> though you can build using a cross compiler environment, e.g., trusty-amd64
<rtg> install an LXC container or trusty-amd64 chroot 
<stgraber> rtg: yup
<jrsharp_> rtg: thanks!
<jrsharp_> as for the kernel configs...  /proc/config.gz is not available on this one
<infinity> zequence: *nudge*, re: precise lowlatency.
<infinity> zequence: ... which is in your PPA, un-nudge.
#ubuntu-kernel 2014-08-23
<srp> sometime ago, a new kernel was automatically installed which did not boot. I resorted to booting the previous kernel version, but when 14.04 comes out I'd like to do a dist-upgrade and I'm concerned the upgrade will also render my machine unbootable under the new Ubuntu. Can anyone help me figure out what's wrong with the kernel? . So far, I have looked at the syslogs when booting both the broken and the working kernel, but could not spot the reason why it
<srp>  does not boot. Any hints on what to look for?
<lfrlucas> Hi. I had experiencied this NFS error 3 or 4 times, after some weeks of uptime: lockd: server zeus not responding, still trying
<lfrlucas> ubuntu 14.04
<lfrlucas> nfs clients show this message, and the only solution is to reboot nfs server (zeus)
<lfrlucas> any idea? it seems an kernel related bug...
<dannas> http://pastebin.com/qW3chdas
<dannas> I'm trying to build a custom kernel from the the latest change in Torvalds tree,
<dannas> End up with "Unable to mount root fs",
<dannas> (see pastebin above for the instructions I've executed)
<dannas> Question 1: Is there some obvious step missing when I try to build the kernel?
<dannas> I've followed the instructions in https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
<dannas> My first theory: initramfs image missing. But I it's present in /boot (see pastebin above).
<dannas> Second theory: wrong boot-opts are passed to the initramfs script (trying to figure out how to troubleshoot that, I had hoped that I would be given a rescue shell by the initramfs enviroment, but that doesn't happen).
<dannas> Hm, CONFIG_BLK_DEV_INITRD is not set. (but a initrd is still present in /boot) I'll redo the steps once more; this time copying my current config instead of using make localmodconfig
#ubuntu-kernel 2014-08-24
<apb1963> Aug 24 06:45:07 asterisk kernel: [97749.037199] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0        x42000020 DMADBG_7=0x000002c0
<apb1963>      68 Aug 24 06:45:07 asterisk kernel: [97749.037208] ath: Could not stop RX, we could be confusing the DMA engine w        hen we start RX up
#ubuntu-kernel 2015-08-17
<cetex> apw: thanks for the answer a few days ago. I figured the specific binary i needed (to manipulate pstate aggressiveness) x86_energy_perf_policy isn't going to change too much, so i just built it manually and put it in /usr/local/bin.
<baojg> when compile kernel ,what is the linux-headers-generic file? how do i create it?
<apw> cetex, np
<apw> baojg, where are you seing linux-headers-generic.  that is normally the meta package name
<baojg> look
<baojg> ii  linux-headers-3.13.0-32                  3.13.0-32.57                        all          Header files related to Linux kernel version 3.13.0
<baojg> ii  linux-headers-3.13.0-32-generic          3.13.0-32.57                        amd64        Linux kernel headers for version 3.13.0 on 64 bit x86 SMP
<baojg> ii  linux-headers-3.18.20-031820             3.18.20-031820.201508081633         all          Header files related to Linux kernel version 3.18.20
<baojg> ii  linux-headers-3.18.20-031820-generic     3.18.20-031820.201508081633         amd64        Linux kernel headers for version 3.18.20 on 64 bit x86 SMP
<baojg> ii  linux-headers-generic                    3.13.0.32.38                        amd64        Generic Linux kernel headers
<baojg> root@41D-CNC-SD:~/linux-stable#
<baojg> the 3.13.0-32 is the header file  14.04 install.
<baojg> and the 3.18.20-031820 is the file i create when compile aginst kernel 3.18.20 
<apw> baojg, right so that is a package, and generated from the linux-meta source pacakge
<baojg> what command i should use to create the package.?
<baojg> anothe quesion :i use fakeroot debian/rules binary-indep to create linux-tools-commomn,but it hang when install the usbip bin,can you gave some suggesion?
<apw> baojg, you would need to get the source for linux-meta and set its version to the abi you are using and then build that package
<apw> but installing hte reuslt will opt you out of all later updates from ubuntu
<apw> baojg, not sure i've seen any such hang in any builds i have done, a simple file install doesn't sound like something which should hang, it may be fakeroot related
<apw> but as i say that doesn't happen to me in my experience
<baojg> first run,i met that : not found usbip.h file,i correct it.but then the hang occurs.
<apw> i might have more of an idea from the output produced before the hang, perhaps pastebin the output
<baojg> i compile 3.18.20 stable kernle to create ubuntu package on 14.04 ubuntu server.
<baojg> wait for a while ,please
<baojg> cd /root/linux-stable/debian/build/tools-perarch/tools/usb/usbip && make install CFLAGS="-g -O2 -static" CROSS_COMPILE=
<baojg> make[1]: Entering directory `/root/linux-stable/debian/build/tools-perarch/tools/usb/usbip'
<baojg> Making install in libsrc
<baojg> make[2]: Entering directory `/root/linux-stable/debian/build/tools-perarch/tools/usb/usbip/libsrc'
<baojg> make[3]: Entering directory `/root/linux-stable/debian/build/tools-perarch/tools/usb/usbip/libsrc'
<baojg>  /bin/mkdir -p '/root/linux-stable/debian/build/tools-perarch/tools/usb/usbip/bin/lib'
<baojg>  /bin/sh ../libtool   --mode=install /usr/bin/install -c   libusbip.la '/root/linux-stable/debian/build/tools-perarch/tools/usb/usbip/bin/lib'
<baojg> libtool: install: /usr/bin/install -c .libs/libusbip.lai /root/linux-stable/debian/build/tools-perarch/tools/usb/usbip/bin/lib/libusbip.la
<baojg> libtool: install: /usr/bin/install -c .libs/libusbip.a /root/linux-stable/debian/build/tools-perarch/tools/usb/usbip/bin/lib/libusbip.a
<baojg> libtool: install: chmod 644 /root/linux-stable/debian/build/tools-perarch/tools/usb/usbip/bin/lib/libusbip.a
<baojg> libtool: install: ranlib /root/linux-stable/debian/build/tools-perarch/tools/usb/usbip/bin/lib/libusbip.a
<baojg> libtool: finish: PATH=".:/usr/local/squid/sbin:/usr/local/squid/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/sbin" ldconfig -n /root/linux-stable/debian/build/tools-perarch/tools/usb/usbip/bin/lib
<baojg> ----------------------------------------------------------------------
<baojg> Libraries have been installed in:
<baojg>    /root/linux-stable/debian/build/tools-perarch/tools/usb/usbip/bin/lib
<baojg> If you ever happen to want to link against installed libraries
<baojg> in a given directory, LIBDIR, you must either use libtool, and
<baojg> specify the full pathname of the library, or use the `-LLIBDIR'
<baojg> flag during linking and do at least one of the following:
<baojg>    - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
<baojg>      during execution
<baojg>    - add LIBDIR to the `LD_RUN_PATH' environment variable
<baojg>      during linking
<baojg>    - use the `-Wl,-rpath -Wl,LIBDIR' linker flag
<baojg>    - have your system administrator add LIBDIR to `/etc/ld.so.conf'
<baojg> See any operating system documentation about shared libraries for
<baojg> more information, such as the ld(1) and ld.so(8) manual pages.
<baojg> ----------------------------------------------------------------------
<baojg> make[3]: Nothing to be done for `install-data-am'.
<baojg> make[3]: Leaving directory `/root/linux-stable/debian/build/tools-perarch/tools/usb/usbip/libsrc'
<baojg> make[2]: Leaving directory `/root/linux-stable/debian/build/tools-perarch/tools/usb/usbip/libsrc'
<baojg> Making install in src
<baojg> make[2]: Entering directory `/root/linux-stable/debian/build/tools-perarch/tools/usb/usbip/src'
<baojg> make[3]: Entering directory `/root/linux-stable/debian/build/tools-perarch/tools/usb/usbip/src'
<baojg>  /bin/mkdir -p '/root/linux-stable/debian/build/tools-perarch/tools/usb/usbip/bin/sbin'
<baojg>   /bin/sh ../libtool   --mode=install /usr/bin/install -c usbip usbipd '/root/linux-stable/debian/build/tools-perarch/tools/usb/usbip/bin/sbin'
<baojg> ....
<baojg> ...
<baojg> look, it hang in the libtool install.
<apw> ugg flood, thats why i asked you to pastebin it not paste it
<baojg> oh sorry,i dont know the pastebin.
<apw> so while it is hung what is actually running (ps) and what are they doing, perhaps attach strace to the stuck bits
<baojg> need some time to learn it
<apw> there is a command pastebinit which shoves the data into pastebin and gives you a link to paste
<baojg> pastebinit
<apw> a command line command
<baojg> is it availble on mac?
<apw> that i have no idea
<apw> you can run it on your ubuntu server though
<baojg> http://paste.ubuntu.com/12106805/
<baojg> APW, on the make log and ps.
<baojg> only
<apw> baojg, are you reallly running the actual build as root?  that sounds rather dangerous to me
<baojg> http://paste.ubuntu.com/12106856/
<baojg> yes .root,but use fakeroot
<apw> ok
<apw> well that ps listing is too limited to see what is pending, perhaps try a pstree and look for the branch which has the build in it
<baojg> creen(893)âââbash(894)ââârules(36104)âââbash(8456)âââmake(8457)âââsh(8458)âââsh(8482)âââmake(8483)âââmake(8484)âââsh(8485)âââsh(8493)âââsh(8494)
<baojg> the process 9494 is the last one 
<baojg> ps show /bin/sh -c list='usbip usbipd';.......
<apw> baojg, and not other branches down from make there
<apw> then i'd stick an strace on that last shell and see what it thinks it is doing
<baojg> not other branches down from make there ... what do you mean?
<apw> then, it must be that shell, so attach strace to it
<apw> and find out what the heck it is doing
<baojg> apw,when are you in the ubuntu-kernel room usually?
<apw> baojg, my nick is in here pretty much always, i vary depending on day and physical location, though currently mostly europe tmie
<baojg> strace the stuck process,but it only says stopped by SIGSTOP.
<baojg> no sense ,maybe
<baojg> i have something  other to  do,so have to leave .sorry apw. meet another time 
<apw> baojg (N,BFTL), that implies it was trying to talk to the terminal while in the background or similar
<tseliot> apw: hi, am I right to assume that ABI -26 in vivid is the same as -26 in -lts-vivid in trusty?
<apw> tseliot, yes the -lts-backports are the very same trees just compiled locally
<tseliot> apw: great, this means I can re-use my patch for ABI 26 from trusty :)
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues Aug 25th, 2015 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!  If the question is should I file a bug for something, likely you can assume yes. || Channel logs: http://irclogs.ubuntu.com/
#ubuntu-kernel 2015-08-18
<apw> 11:49:44            apw | baojg (N,BFTL), that implies it was trying to talk to the terminal while in the background or similar
<baojg> apw,when enter into the usbip dir,i can autogen.sh,configure ,make,make install ,but when call through the deb rules, hang.
<baojg> some fact:when build the binary-generic, i must use make with -j1,otherwise it will abort.  
<tseliot> apw: any ideas as to why fglrx is failing even though the build succeeds? http://d-jenkins.ubuntu-ci:8080/view/DKMS/view/W%20-generic/job/dkms-wily-release-generic-fglrx_core/
<apw> tseliot, that is more likely harness faliure, i did ask jibel yesterday now i think about it
<apw> tseliot, but in the short term i'll run a new one and see if that works
<tseliot> apw: ok, thanks
<cristian_c> jsalisbury: hi
<cristian_c> jsalisbury: I'd like to know if you have contacted the author of commit
<ricotz> apw, hi :), is there going to be a 4.2rc7 based build in the kernel ppa?
<apw> yes
<ricotz> ok
<apw> currently doesn't build on all arches
<chiluk> apw, rtg, ogasawara_, bjf, are you guys having an irc meeting this week?
<chiluk> I really REALLY look forward to those every week.
<ogasawara_> chiluk: I thought jsalisbury canceled since everyone is preoccupied with sprinting/plumbers
<chiluk> ah ok.. I just pay attention to the kernel-team calendar... 
<jsalisbury> ogasawara_, chiluk yes the meeting is canceled
<apw> chiluk, anyhow you'd have missed it by 2:42 after the start :)
<cristian_c> jsalisbury: hello
<chiluk> apw... it's called being patient...
<jsalisbury> cristian_c, hello, still working on upstream on the issue
<jsalisbury> s/on/with/
<cristian_c> jsalisbury: ok
#ubuntu-kernel 2015-08-19
<jpds> Why does the vivid-lts kernel on trusty install thermald?
<apw> jpds, because it is recommended with the pstate_idle that contains
<unixabg> apw: greetings, any word on the overlayfs and casper?
#ubuntu-kernel 2015-08-20
<Laney> hey
<Laney> anyone know how to resume from suspend after some timeout?
<Laney> I want to write a script to reproduce a suspend/resume bug by cycling it until it happens
<davmor2> Laney: I think nuclearbob is doing something along those lines for UT he will be on in a US timezone later today if you get no joy prior to that
<Laney> I just found something called rtcwake
<Laney> seems to work
<apw> unixabg, ok in theory i have a casper mod which lets it do multiple layers
<apw> unixabg, now i am not sure i can test this well, but i think you can
<mjeanson> Hi, I was wondering if there is a policy concerning micro release exceptions for dkms package that break after a kernel update/backport?
<apw> we tend to backport things like that fairly agreessivly
<apw> i dont thing it is written down anywhere
<mjeanson> apw: I prepared updated packages of lttng-modules-dkms for trusty and vivid that build with all current kernels but I had to do minor version updates and cherry pick a lot of patches, any chances of having this sponsored?
<apw> mjeanson, does it work with wily as well?
<mjeanson> apw: wily has 2.6.x, vivid 2.5.x and trusty 2.4.x and hte major version must match with the userland tools version, so I backported kernel enablement patches in each branch
<mjeanson> it would be so simple if we could just backport the wily package
<mjeanson> but then we would also have to backport the userland stuff
<apw> mjeanson, if you have packages we can get them reviewed and sponsored
<mjeanson> apw: great, they are in my ppa, let me get the links
<mjeanson> trusty: https://launchpad.net/~mjeanson/+archive/ubuntu/ppa/+sourcepub/5317334/+listing-archive-extra
<mjeanson> vivid: https://launchpad.net/~mjeanson/+archive/ubuntu/ppa/+sourcepub/5317328/+listing-archive-extra
<apw> mjeanson, won't be today, will look into them tommorrow if noone else has
<mjeanson> apw: great, thanks for your help
<infinity> mjeanson: Keep in mind that the trusty version needs to build with 3.13, 3.16, 3.19, and 4.2
<infinity> mjeanson: Because of HWE kernels.
<mjeanson> infinity: it was tested against 3.13, 3.16 and 3,19
<mjeanson> 4.2 will require additionnal patches
<infinity> mjeanson: Kay.  4.2 will be needed too in a couple of months, so may as well fix it now instead of then.
<infinity> mjeanson: The 4.2 header packages from wily should install on trusty just fine, so easy enough to test that way.
<mjeanson> infinity: isn't 4.1 the current kernel for wily?
<infinity> mjeanson: It'll be 4.2 shortly, sorry, that's in the kteam PPA.
<infinity> mjeanson: https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa/+packages
<infinity> Forgot we hadn't promoted that yet.
<infinity> Though, part of why it's not promoted is that we're waiting on dkms fixes.
<apw> infinity, and the other is the lack of a compiler that builds ppc64el
<infinity> apw: Yeah, you could "fix" that by forcing 4.9 until doko fixes his -5 build.
<apw> i was hoping he had it fixed, but i see his build is pants in the PPA
<infinity> apw: He "fixed" it in the PPA, but it broke for other reasons.  Maybe I'll just upload to the archive with only the ppc64el fix.
<infinity> In fact, I think I'll do that this afternoon.
<apw> infinity, nice
<mjeanson> infinity: well, the master branch of lttng-modules doesn't yet build against 4.2
<infinity> mjeanson: That would be nice to fix. ;)
<mjeanson> infinity: I'll get the devs attention when they get back from linuxcon
<infinity> mjeanson: Shiny.
<infinity> apw: Minimal GCC fix uploaded to adconrad/staging.  If it builds fine, I'll copy it to the kernel PPA (so your kernel can build), and -proposed.
<apw> infinity, sounds good, i assume it'll be 24 hours, if its done when i wake i'll copy it over
<infinity> apw: About 9 hours.
<apw> ok cool, so it sounds like i should copy it in the morning
<infinity> apw: Or I'll get it before bed, but that's about the same time.
<infinity> apw: If you beat me to it, copy to proposed too, please. :)
<infinity> Though, maybe not until we've validated that it fixes the kernel build.
<infinity> Which takes about 25m to fail.
<apw> if you've not copied it when i wake up, i'll cpoy it to the PPA and respin the build
<infinity> I guess I can game that by copying the kernel into my staging PPA as soon as the ppc64el gcc build is done.
<apw> yeah if you copy it with binaries, it will only build the broke one i think right ?
<infinity> apw: Or copy source-only and kill all the other builds, whatever.
<unixabg> apw: greetings, thank you for the repsonse on the mod of casper.
<unixabg> Do you have available in a .deb?
<unixabg> I could remaster a stock iso image to include that and then test stacking squashfs in overlay.
<apw> unixabg, not in a .deb ... this pastebin is a replacement scripts/casper for in the initrd on the iso: http://paste.ubuntu.com/12137968/
<apw> unixabg, that work for you ?
<apw> (as in does that make sense to you)
#ubuntu-kernel 2015-08-21
<mjeanson> infinity: apw: Here is a new version of lttng-modules-dkms that builds against 3.13, 3.16, 3.19 and 4.2 : https://launchpad.net/~mjeanson/+archive/ubuntu/ppa/+sourcepub/5320274/+listing-archive-extra
<mjeanson> the patches are from this branch https://github.com/mjeanson/lttng-modules/tree/stable-2.4-trusty
<unixabg> apw: Yes that should be fine. I will try to test soonish and report back. Thanks.
<unixabg> s/soonish/over the weekend for early next week/g
<apw> mjeanson, ack
<apw> unixabg, thanks
#ubuntu-kernel 2015-08-22
<pthreat> Im compiling a custom kernel for some old hardware, when I try to make modules_install I get can't read private key. How can I solve this
#ubuntu-kernel 2015-08-23
<unixabg> apw: On casper patch testing may I am assume that a stock wily-desktop.iso will be ok to test with?
<apw> pthreat (N,BTFL), the key is built during the main kernel build process
<apw> unixabg, should be against the versions in that yes
<unixabg> apw: just to make sure I am not missing something simple, I am testing by extracting iso image
<unixabg> then I create a partial squash that should be able to be stacked on top with live-partial-squashfs-updates
<unixabg> then I generate a new iso and test the stacking. This is how I test on debian so I am assuming
<unixabg> it ok to do with casper and ubuntu.
<unixabg> Ah I just did a break=mount and I see that the casper needs to be in the initramfs. Ok that might
<unixabg> explain alot.
<unixabg> s/casper/modified casper/
<apw> unixabg, yeah in initrd
#ubuntu-kernel 2016-08-22
<hggdh> phillw: this is, indeed, the current kernel for yakkety. Why the version string, though, I do not know
<phillw> hggdh: thank you, sir. I'll *carry on testing* :)
<hggdh> :-)
<bjf> phillw, from the changelog the odd abi number is to avoid namespace clash with xenial kernels while yakkety ist still a 4.4 kernel (which hopefully isn't for much longer)
<phillw> bjf: thankyou for the clarification :)
<xnox> phillw, hggdh: the version string is correct.
<xnox> all other kernels in 4.4 series were built for xenial and copied into yakkety.
<xnox> this one was built in yakkety  with sources different from xenial.
<xnox> hence the probably-will-never-class-with-xenial version number.
<xnox> in theory this would not be required at all, as by now, one usually has a new kernel series in the development release - e.g. v4.6/v4.7/v4.8 but we are not there yet.
<xnox> phillw, also see #ubuntu-release backlog from last week.
<phillw> xnox: I'm on the mailing lists, but missed this one.. Would it be possible to put out a mail to clarify for any others who are testing and scratching their heads? :)
<xnox> phillw, #ubuntu-release is IRC channel.
<xnox> phillw, there is nothing to clarify and nobody is scratching their heads =)
<phillw> xnox: okies, just me being dumb, in that case :)
<xnox> version strings really do not matter at all, and encode ABI
<xnox> phillw, to be honest we could be using ephemeral key hash in the package names, to encode the ABI.
<xnox> just to make sure the abi tag is meaningless fingerprint like string.
<phillw> that is something else you've just taught me! I was under the false impression that grub always chose the highest number for the default kernel :)
<xnox> nope.
<xnox> it picks last configured kernel.
<xnox> ubuntu -> vmlinuz -> symlink to last kernel image that dpkg postinst was called on.
<xnox> that has always been the case.
<phillw> thanks, I'll leave you good people in peace!! On the plus side, if I do get asked I can reply... saves another person landing here asking!!!
<xnox> Your kernel's Performance Events Subsystem does not support your processor type.
<xnox> horum, but ibm say it should be....
<chrisccoulson> does the kernel in yakkety support MADV_FREE?
<apw> chrisccoulson, that is documented as 4.5+ so we will, and currently don't
<chrisccoulson> apw, ah thanks. See bug 1613258 for context - the new glibc defines MADV_FREE
<ubot5> bug 1613258 in glibc (Ubuntu) "signal 4 ILL_ILLOPN in webbrowser-app tests (glibc upgrade?)" [Critical,Triaged] https://launchpad.net/bugs/1613258
<apw> chrisccoulson, that may have been built with the 4.6 which was in -proposed for a time (glibc)
<apw> that said, i am supprised that glibc is assuming it can use it
<apw> infinity, ^
<apw> chrisccoulson, oh but it is likely the seccomp bits right?  so just a profile change ?
<apw> chrisccoulson, in the sense it is resonable for glibc to define it, and the kernel to return EINVAL or indeed work, but we need the seccomp profile to reflect that possibility
<chrisccoulson> apw, we'll probably end up doing the same as http://code.qt.io/cgit/qt/qtwebengine-chromium.git/commit/?h=49-based&id=b12ffcd411d4776f7120ccecb3be34344d930d2b
<apw> chrisccoulson, wouldn't it make more sense to try MADV_FREE and if it fails ENOSUPPORT or whatever dropback to whatever it does when it doesn't have _FREE ?
<apw> so one uses it in 4.5 and not before that all shiney and automatically 
<chrisccoulson> apw, we could probably do that
<apw> i assume it uses like _DONTNEED or similar instead
#ubuntu-kernel 2016-08-23
<rtg> dannf, did you ever figure out the 4.6 boot issue on arm64 ?
<dannf> rtg: very close - but not there yet. boots fine on cavium 1s, but not xgene. config related, probably ~5 more bisect runs needed
<rtg> dannf, ok, thanks
<bjf> cyphermox, http://pastebin.ubuntu.com/23082650/ this is a recent regression. This is Trusty on ppc64el.
<cyphermox> bjf: ah?
<cyphermox> bjf: is that system using multipath?
<bjf> cyphermox, yes
#ubuntu-kernel 2016-08-24
<cyphermox> bjf: could you run 'sudo grub-install --verbose /dev/sda1' on that system where you saw the failure? it may tell us more about why it's unhappy
<bjf> cyphermox, http://pastebin.ubuntu.com/23083835/
<Odd_Bloke> Do we have a finger-in-the-air estimate of when 4.6 will land?  (Days or weeks?)
<apw> Odd_Bloke, i think that is in negative territory atm, it actually tried once, but i'd say 1 week not 3 weeks
<Odd_Bloke> apw: Cool, thanks. :)
<tjaalton> is there a command to clean up old kernels?
<apw> tjaalton, if they are installed "normally" then apt-get remove --purge should be killing them off
<tjaalton> normal yeah, if you mean autoremove that only removed one of them
<tjaalton> on this machine there are still 43 left :)
<apw> tjaalton, if you have been "naughty" and installed things by hand, you can give the manual ones back to autoremove with: sudo apt-mark auto `apt-mark showmanual '^linux-(headers|image|image-extra|cloud-tools|tools)-[0-9]'`
<tjaalton> this is my sisters' machine, so normal upgrades.. I'll give that a go thanks
<apw> tjaalton, i wonder then how they ended up manual, which they i think must be to avoid the new autoremove magic, well unless it is precise or something
<tjaalton> trusty
<apw> that should definatly work correctly (in theory :))
<tjaalton> yeah, I've seen this elsewhere too
<apw> yeah i think it may well be that we added it in trusty and it did not do anything to grandfather in old kernels or something
<tjaalton> well, looks like on my xenial install only linux-image-extra-* are getting autoremoved
<apw> tjaalton, hrm, cat /etc/apt/apt.conf.d/01autoremove-kernels
<apw> can you pastebin that
<tjaalton> apw: http://pastebin.com/xggDPuL5
<tjaalton> I removed them by hand
<Sarvatt> tjaalton: purge-old-kernels :D
<tjaalton> oh
<tjaalton> it'll happily remove linux-generic tho
<tjaalton> and other metapackages, and the kernel I haven't booted into yet
<tjaalton> so, seems kinda broken :)
<ricotz> smb, hi, will there be a 4.4.19 based xenial kernel-ppa-build available this week?
<smb> ricotz, rather no as that will be part of the next cycle which starts next week
<ricotz> smb, hmm, I see
#ubuntu-kernel 2016-08-25
<manjo> apw, hello.. did you get a chance to see my email ? regarding "module disagrees about version of symbol module_layout" ? 
<apw> manjo, i see it, what compiler did it use to build this version?
<manjo> apw, xenial what ever is default .. 
<manjo> apw, in the PPA buildes 
<manjo> apw, also arm64
<apw> well they that would likley be gcc5 so that ought to be ok.  the message seems to imply that the kernel and modules come from different builds with different configs most likely
<manjo> apw, right that is why I am stumped .. coz it is a full kernel build in the PPA 
<manjo> apw, something is not right 
<apw> manjo, well how is the kernel getting to the CPU could that be out of sync with the initramfs
<manjo> apw, I am seeing this with DI install .. di I built using this kernel 
<apw> right but how are you making sure that the module and vmlinux are from the same build
<manjo> apw, not sure what you are asking .. the kernel built in a ppa, the DI built in that same PPA so DI would be picking up kernel and modules from that PPA ..
<apw> manjo, which of d-i's outputs are you booting, a netboot ?
<manjo> ah! sorry .. yes netboot 
<apw> and how are those bits getting to the board
<manjo> apw, pxe tftp usual di 
<apw> and can you tell from the logs it got a consistant set in this boot
<manjo> apw, oh do you suspect that the server might be corrupted ? 
<manjo> apw I did not even think of that case .. 
<apw> well i'd want to confirm these were a matched pair, that it wasn't using the wrong vmlinxu or something
<manjo> right let me check to make sure 
<apw> you know how fickle all this tftp bullshit is
<mamarley> I noticed you mentioned GCC5 earlier, and also that the kernel in Yakkety is currently built with GCC5.  Is there an issue building kernels with GCC6?
<apw> mamarley, i believe there is currently yes, at least for 4.4, not sure which upstream kernels have support for it
<mamarley> Ah, OK.  I was curious because I had been using the 4.7 mainline kernel, and that works fine with GCC6.
<apw> yeah i only was peripherally involved, i know we had to do special things for 4.4 in yakkety, when it stops being an issue is not something i have asked
<manjo> apw, so I verified that the bits are coming from the right place 
<manjo> apw, nothing funny there 
<manjo> apw, https://pastebin.canonical.com/163979/
<manjo> apw, https://pastebin.canonical.com/163980/
<manjo> oops I left out the imp cut paste in the prev pastbin 
<rtg> dannf, how is 4.6 arm64 looking ? ogasawara mumbled something about ROCKCHIP needing to be enabled ?
<apw> manjo, and you have downloaded those and confirmed they are a consistant set content wise
<manjo> apw, yes built yesterday .. ubuntu-installer dir looks kosher
<manjo> apw, with CONFIG_MODVERSION it should re-generate Module.symvars .. and the modules should link with that correct? .. unless there is some code missing which I doubt is the case 
<apw> manjo, looking at the kernel code emitting that, it really thinks the symbol table for that thing is different for the vmlinux and the module pair
<apw> manjo, which either implies they are from differnt builds, or the modules and kernel are built differently in the same build
<apw> manjo, quite how that could occur if you are sure they are form the same build, i guess it depends how different the build is from our standard ?
<dannf> rtg, ogasawara : yep: LP: #1616672
<ubot5> Launchpad bug 1616672 in linux (Ubuntu) "4.6.0-11.13 from ckt PPA fails to boot on X-Gene" [High,Confirmed] https://launchpad.net/bugs/1616672
<ogasawara> dannf: thanks
<rtg> dannf, is that sufficient for now ? infinity would like to get a 4.6 kernel promoted soon, and this appears to be the only blocker.
<manjo> apw, the process is simple, take unstable, add patches, adj configs, fix changelog and build in ppa ... I have done this a number of times in the past with 4.3, 4.4, 4.5 etc and did not see this issue 
<dannf> rtg: i'm fine w/ it - i'm moving on to 3.8-rc to see if there was a fix since, but that is having its own problems, so i can't promise any "real" fix anytime soon
<manjo> apw, Y kernel skipped 4.7 so I can only use unstable which has a 4.7 tag 
<rtg> dannf, ok, I'll add this patch and upload soon
<apw> manjo, other than looking at the build log for oddness, i have nothing.  there is more info at debug level you might want to up loglevel to debug on boot
<manjo> apw, ok crazy question .. can I disable CONFIG_MODVERSION ?
<apw> you could, but what it is telling you is wrong implies that the values in that structure are not going to be read right, whcih is likely going to explode in your face next
<apw> as the structure layout the kernel is going to drop onto that data in the file isn't the same shape
<manjo> lol right ok .. 
 * manjo tries to find a vein .. 
<dannf> infinity: just a heads up that a 4.8-rc3 w/ ubuntu config is blowing past the size limit for xgene/uboot. might make that compressed image support work for d-i more critical
<infinity> dannf: Joy.
<infinity> dannf: I have no issues with compressed images, as long as you make sure every platform supports it. :P
<infinity> dannf: (Been down this road with PPC, where we switched from coff to zImage and had to switch back because some firmware/bootloaders didn't like it)
<infinity> dannf: Unless you mean just compressing the uImage for xgene, not the vmlinux.  Then that's trivial.
<dannf> infinity: i mean for both. we *could* just do x-gene, but the only other bootloader i think we care about is UEFI, which deals with it
<dannf> s/do x-gene/do just x-gene/
<infinity> dannf: So, wait.  Is the current zImage uncompressed on arm64?
<dannf> infinity: actually - i guess qemu might be another example - i'll test that as well
<dannf> infinity: yes
<dannf> infinity: that's what i'd like to change - but need to get d-i/f-k in place before i send that patch
<infinity> dannf: qemu can take raw zImages fine, and in the non-raw case, it's using firmware (uboot or ovmf), so should be fine.
<infinity> dannf: It doesn't look uncompressed to me...
<dannf> infinity: does it say COFF?
<infinity> dannf: My uncompressed PPC kernels are huge in comparison.
<leitao> rtg, I sent an email to the kernel mailing list regarding kernel issue on ppc64el.
<leitao> I am not seeing it at https://lists.ubuntu.com/archives/kernel-team/2016-August/thread.html. Maybe it was not received because I am not part of the mailing list.
<infinity> dannf: Although, file(1) thinks it's a DOS executable, not a bzImage, so... Maybe it is uncompressed. :P
<infinity> (Also, wat)
<dannf> infinity: it is - EFI stub
<infinity> dannf: Anyhow, any modern u-boot can boot zImage/bzImage, as can EFI, and if that's all we care about, you should be good to go.
<apw> that could be compressed still
<infinity> dannf: And raw qemu.
<infinity> But, yeah.  My PPC kernels are, like, 30MB.  How big is your arm64 kernel?
<dannf> infinity: right - but the uImage needs to have the right compress field, which brings me back to https://code.launchpad.net/~dannf/debian-installer/xgene-uboot-gzip-support/+merge/300645
<apw> an x86 kernel is a binary, just a small one which uncompresses itself, so it isn't a gzip
<infinity> dannf: Why are we using uImage/uInitrd at all?
<infinity> dannf: Surely the u-boot on any arm64 system is new enough to load raw kernels.
<dannf> infinity: xgene only supports uImage - at the time only armhf supported raw zImage
<infinity> dannf: Wow.  That's.  Derp.
<infinity> Well done, arm64 folks.
<apw> they have to be backwards somewhere
<ogra_> just flash a new u-boot during install :P
<infinity> ogra_: Chicken, meet egg.  How do you boot the installer?
<ogra_> details 
<infinity> :)
<ogra_> :)
<dannf> can't flash u-boot on mcdivitt
<infinity> dannf: If that's tested and you're pretty sure it doesn't suck, just go ahead and commit, it doesn't need review, IMO.
<dannf> infinity: ack
<infinity> dannf: I have to upload a fresh d-i in about half an hour to pick up netcfg, so this'll get in there if you commit now. :P
<infinity> dannf: For future reference, don't let me block you on d-i stuff unless it's a large enough change that you're pretty sure I'll revert and/or yell at you for not asking for a review.
<dannf> infinity: in 1:1 w/ bossman, so will be at least 20 minutes
<dannf> infinity: understood :)
<infinity> dannf: And those goes double if you're committing without uploading, cause I review the full delta before upload anyway.
<infinity> dannf: On second thought, I'll just merge it, I'm operating on a clock. :)
<dannf> infinity: ack
<infinity> dannf: Merged and uploaded.
<dannf> infinity: thx!
<rtg> leitao, unmoderated
<leitao> rtg, weird. Anyway, sent you a private email
<rtg> leitao, no, I mean I released it from the moderation queue
<rtg> anyways...
<leitao> rtg, got it. So it is moderated. Thanks
<rtg> apw, that looks like a mainline cross compile problem, though it likely also exists in our Ubuntu cross builds
<apw> rtg "that" ?
<rtg> apw, https://lists.ubuntu.com/archives/kernel-team/2016-August/079743.html
<apw> hrm
<rtg> apw, I doubt if I've ever run the cross compiled ppc64el kernel
<apw> rtg, ok that is using your 4.7.0-0.4 debian tooling etc, and is supplying CROSS_COMPILE=powerpc64le-linux-gnu-
<apw> rtg, so i would expect that to do something sane
<rtg> apw, upstream makefile bug ?
<apw> or we lost our own fixes
<rtg> apw, shouldn't have. I don't remember any conflicts in the debian directory
<apw> both the primary makefile and our rules look to pass it as normal
<apw> hrm
<rtg> this sounds vaguely familiar
<apw> rtg, ok yes, this is actually only the host tooling which is coming out as x86, and as these are cross compiles that is entirely expected
<rtg> apw, host side device tree compiler ? so its not really a problem.
<apw> rtg, right it does mean you cannot build out of tree modules against these test builds
 * apw replies on the mailing list as well
<jhg_> greetings!
<jhg_> are there any nightlies that track linux-next or netdev with binary kernel packages?
<apb1963_> help attempted in #ubuntu but no resolution.  No response in #ubuntu-server yet... and so now I'm asking here.  Aptitude is giving me an abortion when trying to install libsnmp-dev.  Details here: http://pastebin.com/AAaZgFid   
#ubuntu-kernel 2016-08-26
<LocutusOfBorg> apw, can I bother you about having the virtualbox kernel modules from 5.1.4 syncd in ubuntu kernel? 
<LocutusOfBorg> I'm still waiting some days to sync virtualbox 5.1.4 into Ubuntu archive
<LocutusOfBorg> if nobody complains in Debian I'll sync it
<apw> LocutusOfBorg, we can cirtainly do that once it arrives yes, poke me when it lands and i can get that done
<LocutusOfBorg> ok so I'll sync it now :)
<LocutusOfBorg> I hoped you were able to use the debian one or my ppa one
<LocutusOfBorg> I would like to wait it to migrate from Debian before, are 10 days an unacceptable delay?
<apw> oh i can probabally use a PPA one if needed, hmmm, i guess i need to figure out where it needs syncing to, i guess that'll be the 4.6 kernel
<LocutusOfBorg> the fixes are for kernels up to 4.8
<LocutusOfBorg> BTW aren't the merges in kernel propagated automagically to newer kernels?
<LocutusOfBorg> I would like to have it in yakkety, whatever kernel will have
<LocutusOfBorg> (if possible, of course)
<apw> LocutusOfBorg, they are until the tree diverges, which it now how, anyhow thats my problem
<LocutusOfBorg> ok
<LocutusOfBorg> if I can make it smoother, please let me know
<bjf> cyphermox, i've created lp: #1617345 for that grub update on ppc64el that i was chatting with you about the other day
<ubot5> Launchpad bug 1617345 in grub (Ubuntu) "package upgrade broken for multipath system, specifically ppc64el" [Undecided,New] https://launchpad.net/bugs/1617345
#ubuntu-kernel 2016-08-27
<_ami_> i added allow_signal(SIGKILL) in my kernel thread work function. kill -9 <thread_id> does not stop the thread function. any pointers?
<_ami_> code: http://pasted.co/0ac16746 
<dantab> Quick question, maybe people here can answer it quickly: Do xqd card readers already work on linux?  I assume yes, but I would like to hear from people before I buy one. Searching on the net was not so successful. 
#ubuntu-kernel 2016-08-28
<antipsychiatry> Hi. Online?
<antipsychiatry> What u do for the secret service not using MIND READING against us ?????????????????????????????? How can we protect against their mind reading technology??????  Read: stopeg.com
#ubuntu-kernel 2017-08-21
<_Xenial> How can the protected memoory be audited?
<_Xenial> For checking that the key is not readable.
<_Xenial> JanC this leaves the possible problem of loading the SDCARD reader driver on bootside
<_Xenial> When it comes to kernel commands there is nearly no help.
<_Xenial> The old kernels have a command line list
<_Xenial> Also it wastes the entire SDCARD on a 4mb header
<_Xenial> Due to partition tables being stored at the head of the device.
<_Xenial> If partition tables were stored at the end of the device the header can be raw
<_Xenial> partitioning has consistently caused problems
<_Xenial> JanC can you devise how to load the SDCARD reader kernel mod on bootside?
<_Xenial> The thought is using mkinitramfs and applying the sdcardreader driver.
<_Xenial> What is involved with ubuntu, what does ubuntu put into the default ramfs, this needs to be known.
<_Xenial> brb
<_live_session_us> Does somebody run the kerneland cause overvolts all over the system?
#ubuntu-kernel 2017-08-22
<hwpplayer1> Hi people
<thgarnie> hi, I noticed that x86_64 ubuntu kernel configuration enables CONFIG_FUNCTION_TRACER on all SKUs. On x86_64 it hads a call on each function by default, do you know why it is enabled?
<thgarnie> -hads +adds
<thgarnie> Waste about 1.2% time in average on hackbench.
<kees> ogasawara, apw: ^^
<apw> hwpplayer1: you trade off debugability against performance always
<apw> it adds 4 or 5 noops to the top of an untraced function iirf
<apw> iirc
<thgarnie> no, not on x86_64
<thgarnie> that's what the config says
<thgarnie> the reality is a call __fentry__
<thgarnie> Not sure if it is badly implemented on x86_64 (because you can do mnop-mcount) or because it is hard to do the nop swap.
<thgarnie> Correction, the nop is added a runtime instead of using -mnop-mcount. Odd that it didn't happen when PIC is enabled then hum.
<thgarnie> Not sure why I see a 1.2% average difference with/without function tracing on hackbench.
<hwpplayer1> apw : it is not that easy
<jjohansen> sforshee: pull request sent to the ml
#ubuntu-kernel 2017-08-23
<Laney> meow
<Laney> can you tell me (or point me to a reference for) whatever changed recently wrt what's trusted to sign kernel modules?
<Laney> I generated and enrolled some keys on my system and have been using them to sign wl.ko for a while now, but this just stopped working for me on artful
<Laney> "PKCS#7 signature not signed with a trusted key"
<Laney> mokutil shows my key is still in there
<Laney> :'(
<apw> ^
<apw> ^ sforshee i think we switched up patch stacks for signing enforcement ... 
<sforshee> Laney: I just committed a fix for that yesterday
<Laney> ohhh
<Laney> so my old thing will work again?
<sforshee> yes, once that fix gets out
<Laney> â¥
<ricotz> klebers, hi, was there any progress regarding https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1699772 ?
<ubot5> Ubuntu bug 1699772 in linux (Ubuntu) "linux-image-4.10.0-24-generic, linux-image-4.8.0-56-generic, linux-image-4.4.0-81-generic, linux-image-3.13.0-121-generic Regression: many user-space apps crashing" [Critical,Confirmed]
<nacc> sforshee: would you be able to help debug why s390x (in artful-proposed or artful) fails to build openafs-modules-dkms?
<nacc> sforshee: LP: #1625091
<ubot5> Launchpad bug 1625091 in openafs (Ubuntu) "openafs-fileserver 1.6.18.3-1 ADT test failure on s390x" [Undecided,Confirmed] https://launchpad.net/bugs/1625091
<nacc> sforshee: i've put up a few logs i've gotten
#ubuntu-kernel 2017-08-24
<sforshee> nacc: did you miss comment 6 on that bug, where I pointed you at bug 1711835 ?
<ubot5> bug 1711835 in openafs (Ubuntu) "openafs 1.6.20-2ubuntu2 ADT test failure with linux 4.12.0-12.13" [Undecided,New] https://launchpad.net/bugs/1711835
<nacc> sforshee: err, yes, i guess i did! :)
<nacc> sforshee: sorry for the noise!
#ubuntu-kernel 2017-08-25
<stgraber> sforshee: where can I get that 4.13.0-6.7 kernel?
<stgraber> sforshee: based on the lxd logs, it looks like something's broken with apparmor profile namespacing, but I'd need to reproduce this myself to see exactly what
<sforshee> stgraber: ppa:canonical-kernel-team/unstable
<stgraber> sforshee: for the lxc one, I'm actually wondering if it's not the current resolvconf/networkd mess that's breaking DNS in there. When were those tests run?
<sforshee> stgraber: today
<stgraber> hmm, guess I'll have to look at what they broke in artful now...
<sforshee> jjohansen: some snapd adt tests are failing with 4.13, and all the failures have the message "Failed to query AppArmor policy: Permission denied." Any idea what's going on there?
<sforshee> jjohansen: bug 1713103
<ubot5> bug 1713103 in snapd (Ubuntu) "snapd 2.27.3+17.10 ADT test failure with linux 4.13.0-6.7" [Undecided,New] https://launchpad.net/bugs/1713103
<tyhicks> sforshee: are you able to run commands on that test machine? if so, the output of `ls -al /sys/kernel/security/apparmor/.access` would be hadny
<tyhicks> s/hadny/handy/
<tyhicks> sforshee: oh, I've got yesterday's linux-next kernel running in a VM
<tyhicks> on artful:
<tyhicks> -rw-rw-rw- 1 root root 0 Aug 15 17:38 /sys/kernel/security/apparmor/.access
<tyhicks> (artful kernel 4.11.0-13.19-generic)
<tyhicks> on linux-next:
<tyhicks> -rw-r----- 1 root root 0 Aug 24 21:26 /sys/kernel/security/apparmor/.access
<sforshee> tyhicks: those were adt tests so no I don't have access
<tyhicks> looks like the apparmor kernel query interface was upstreamed with different file permissions than what was previously in ubuntu
<tyhicks> sforshee: no worries - I'll update the bug with my findings so that jjohansen knows the problem when he starts his day
<sforshee> tyhicks: thanks, appreciate it!
<stgraber> tyhicks, sforshee: tracked down the LXD adt failure with 4.13, the problem is a change of apparmor syntax to represent a stacked profile
<stgraber> before 4.13:
<stgraber>    lxd-aatest_</var/lib/lxd>//&:lxd-aatest_<var-lib-lxd>://unconfined (27047) 
<stgraber> after 4.13:
<stgraber>    lxd-aatest_</var/lib/lxd>//&:lxd-aatest_<var-lib-lxd>:unconfined (23835) 
<stgraber> this is tripping our test for ":<profile>://unconfined"
<stgraber> I'll send an upstream tweak for our testsuite so that it supports both syntaxes
<tyhicks> jjohansen: ^ was that intentional?
<jjohansen> tyhicks: give me a sec
<tyhicks> no worries, just making sure you saw stgraber's investigation
<stgraber> jjohansen, tyhicks: If this is expected, I'll send this upstream: http://paste.ubuntu.com/25390829/
<stgraber> which should make both our policy and test support both syntaxes
<jjohansen> tyhicks: the switch from :ns://profile -> :ns:profile was intential
<jjohansen> both formats have always been valid
<jjohansen> I guess you weren't around when I asked the question
<jjohansen> it came down to readablity
<tyhicks> I suppose it is nice to save a couple chars since that string length is limited
<jjohansen> well yes there is that too
<stgraber> jjohansen: do we need to have both syntaxes listed in change_profile?
<jjohansen> stgraber: ? you can use either, they are both valid, always have been
<stgraber> jjohansen: right now we generate a profile which contains: "change_profile -> lxd-aatest_</var/lib/lxd>//&:lxd-aatest_<var-lib-lxd>://*"
<jjohansen> oh, you mean the documentation? yes they should be
<stgraber> Will that match someone doing a change profile to "lxd-aatest_</var/lib/lxd>//&:lxd-aatest_<var-lib-lxd>:unconfined"?
<stgraber> or is the check done against the provided string as it came from the user
<jjohansen> stgraber: the check is should be post parse
<jjohansen> but it is possible there is a bug
<stgraber> ok
<jjohansen> so, I would say that is a bug on our end, I'll take a look
<stgraber> I don't know that there is a bug, was just wondering whether we need to allow both syntaxes in the profile so that we don't end up with one being blocked for our users
<stgraber> anyway, I've confirmed that listing both syntaxes doesn't cause problems, so we'll just go with that, safer that way
<jjohansen> stgraber: yes its a bug, but at least there is a work around of listing both
<sforshee> jjohansen, tyhicks: also some apparmor test failures here - https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-canonical-kernel-team-unstable/artful/amd64/l/linux/20170825_162923_61ef2@/log.gz
<tyhicks> jjohansen: looks like pivot_root regression test failures
<tyhicks> probably related to the lack of profile transition functionality
<jjohansen> sforshee: yes there are a few regression test changes to go with the kernel, we need to get those pushed out
<jjohansen> there are the pivot root transitions, a couple of query tests going from xpass to pass
<sforshee> jjohansen: ack, thanks for taking a look
<jjohansen> the longpath fix which we already have in ubuntu
<tyhicks> xpass -> pass
<tyhicks> nice
<tyhicks> jjohansen: I think bug 1713103 is probably the most important failure right now
<ubot5> bug 1713103 in linux (Ubuntu) "snapd 2.27.3+17.10 ADT test failure with linux 4.13.0-6.7" [High,Triaged] https://launchpad.net/bugs/1713103
<tyhicks> jjohansen: I did some quick triage, left my findings in the bug, and then assigned it to you
<jjohansen> ack
<tyhicks> sforshee: we spoke one or two weeks ago about the need to target both the 4.12 and 4.13 kernels for artful backports
<tyhicks> sforshee: however, I'm just getting around to the backport
<tyhicks> sforshee: do I still need to target both or is 4.13 sufficient?
 * tyhicks isn't sure when 4.13 is expected to land
<tomreyn> before 4.14!
<tomreyn> .12 has rc7 before going 'stable'. .11 had rc8, .10 had rc8. we're at 4.13.6, i'll give it another one or two rc's.
<tomreyn> that's unless hpe ilom ent into kernel space recently ;-)
<tomreyn> ... or someone actuall ylooked at inifiniband code from an infinite perspective.
<tyhicks> sforshee: nvm, I went ahead and backported to 4.12 and tested both 4.12 and 4.13. Patches sent to the kernel-team mailing list.
#ubuntu-kernel 2019-08-19
<jibel> could someone have a look at bug 1840122 ? It started on eoan with kernel 5.2
<ubot5> bug 1840122 in linux (Ubuntu) "System fails to reboot from live session or ubiquity-dm - squashfs_read_data failed to read block" [High,Confirmed] https://launchpad.net/bugs/1840122
<jibel> I downgraded casper too but the issue still remains to it could be a problem with 5.2
<jibel> it's on the installation media only and downgrading the kernel is rather hard there
#ubuntu-kernel 2019-08-20
<Laney> anyone have any clue on https://paste.ubuntu.com/p/PvQmwK55hw/ ?
<Laney> just upgraded to eoan and I can't connect to my wifi network at home any more (scanning works though)
<Laney> :'(
<apw> Laney, that sounds ... odd
<apw> what encryption is it using ?
<Laney> umm good question
<Laney> apw: https://paste.ubuntu.com/p/C6MnFFdZgk/ <- "nmcli con show" of the connection
<Laney> I didn't set any fancy stuff up, just normal WPA whatver the unifi thing does
<Laney> ah it says "WPA2 Only" "AES/CCMP Only"
 * Laney tries rebooting back to 5.0 quickly
<Laney> RAH it's not built there
<Laney> should have said this is broadcom ð
<Laney> yeah same with 5.0
<apw> brcm ... are you saying that your brcm drvier is a dkms which didn't build ?
<Laney> it built for 5.2 but not 5.0, the fcf-protection thing
<Laney> hacked that out, built it and still broken on 5.0 on the same way
<apw> Laney, waht were you running before ?
<Laney> disco
<apw> but 5.0 there
<Laney> yeah
<Laney> HMM
<Laney> https://bbs.archlinux.org/viewtopic.php?id=248470 this is blaming NM
<apw> so the update to the dkms pacakge in eoan
<Laney> well it's not definitive
<apw> (is most likely)
<Laney> ah OK I guess I can try downgrading that first if I stay on 5.0
<apw> yeah lets see if that works
<apw> need to figure out which thing needs help for sure, and that sounds like a logical test
<Laney> same
<Laney> ok let me try network-manager then
<apw> in theory now you have a 5.0 kernel which you have run before with a brcm you had before, which doesn't work now, erp
 * Laney slowly downgrades back down to disco :)
<apw> Laney, that aes-only is not something i see here, how did you ask for that
<apw> is that from your ap, or an iwlist thing
<Laney> it's from the AP
<apw> what are the other options
<apw> i am wondering if this is just a very bad choice the kernels no longer support
<jeremy31> apw AES is CCMP
<Laney> "Auto" is the only other option
<Laney> O_O
<apw> though the 5.0/brcm thing makes that less pheasable
<Laney> I'm online
<Laney> so it seems like it was network-manager after all, WTF
<apw> say what now, network-manager ?
<apw> just how does it manage that ???
<apw> Laney, ^
<Laney> apw: not a clue, I'm just asking upstream if it's anything they've heard of
<jeremy31> bcmwl has never been the easiest to deal with
<Laney> apw: seems like they are owning the problem, you're off the hook :>
<jeremy31> Laney: do they have a patch to fix it?
<Laney> not yet
<apw> Laney, so they know what 'it' even is ?
<Laney> nope
<Laney> apw: well, ...
<Laney> 20/08 12:10:31 <thaller> wpa_supplicant[1348]:   * akm=0xfac04
<Laney> 20/08 12:10:36 <thaller> wpa_supplicant[1348]: nl80211: MLME connect failed: ret=-22 (Invalid argument)
<Laney> 20/08 12:11:00 <thaller> that's RSN_AUTH_KEY_MGMT_FT_PSK ...
<Laney> 20/08 12:11:15 <thaller> seems the driver doesn't like that...
<Laney> he's investigating the log at least
<Laney> follow along in #nm if you like
 * apw does that
<apw> Laney, i am right in thinking you downgraded nm and it started workgin ?
<Laney> apw: correct
<apw> Laney, so likely nm doing somethig new
<Laney> whatever it started doing to wpa-supplicant presumably
<Laney> jeremy31: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/2f8a4e90f0fd0f900996e3081d49f8799bba4c6f
#ubuntu-kernel 2019-08-21
<alkisg> Hi, in ltsp, to netboot clients, we're passing 2 initrds. This works fine up to and including ubuntu 19.04.
<alkisg> But I just tried the 19.10 lubuntu daily build, and the 5.2 kernel there doesn't see the additional initrd, it's like if we only passed one.
<alkisg> Any recent commits that broke it? Any related changes?
<apw> alkisg, as in you say initrd=x initrd=y ?
<alkisg> apw: exactly
 * apw is supprised that works at all, that you don't only get hte last one
<alkisg> apw: oh the kernel has supported it since ages, and in the recent years all boot managers added support for that,
<alkisg> grub, syslinux, ipxe, anyone that I tested has had patches in the recent years to support it
<alkisg> *anything
<apw> alkisg, the kernel supports concantenation of initramfs objects in a single passed block
<alkisg> apw: although, I tried concating the two initrd, and that didn't work either, which probably means a change in the kernel itself
<alkisg> So if someone is able to test that ^ (create an initrd with just a /test file, append it to initrd.img, boot, and see if /test is there),
<apw> alkisg, the kernel only gets initrd=<start>,<len> of a single block
<alkisg> and it doesn't work with 19.10 like it doesn't work for me, then I guess he reproduced the issue...
<apw> alkisg, so all of the bootloaders must be concantenating; so it would be continuration which would have to be broken
<alkisg> I'm testing in the exact same system with the same bootloaders etc
<alkisg> (ipxe, in this case, I'll test kvm in a few minutes)
<apw> alkisg, and would be equivalent for your test and the bootloader test
<alkisg> Right, so it sounds to me like something in the kernel initrd decompression code has broken in 19.10
<alkisg> Maybe my initrd.gz has different compression parameters and it can't follow it? Maybe the early microcode thing? I don't know...
<apw> alkisg, a good point what are you using for that
<apw> as in 19.10 the default compression changed to lz4 initramfs-tools
<apw> though we have not turned off any compression options
<alkisg> apw: find . ! -name ltsp.img | cpio -oH newc | gzip > "$_DST_DIR/ltsp.img"
<apw> alkisg, do you have a dmesg of the failed boot
<alkisg> Moment...
<apw> alkisg, i can see no significant changes in the code to decode the initramfs from 5.0 to unstable
<apw> alkisg, would you attach all of this to an 'ubuntu-bug linux' please too and tell us the number
<alkisg> apw: ok; then I'd best collect all these and do a proper report tomorrow morning. Thanks a lot :)
<apw> alkisg, thanks ... do ping me with the bug number
<alkisg> will do
<ogra> alkisg, apw, the bootloader typically just loads the initrds back to back into ram and hands the kernel the adresses of that merged ram space ... (we use this feature in core too, grub is very easy there if you just hand it two initrds, u-boot is a bit more tricky since you need to do the math and loading yourself) ... but this only works if both initrds use the same compression ... i'D bet there is a difference between the two initrds alkisg loads
<apw> ogra, i wonder why that restriction exists, as its not like the decompresson format individually would understand the reset in the middle
<apw> i am sure it iterates at the top level there, strange
<apw> i would think that is a bug, and likely the bug
<ogra> well, the bootloader loads the compressed bits back to back ... the kernel tries to uncompress ... my guess would be it only looks at the header at the start of that ram area so wont know that the second half uses a different compression
<ogra> (also, i think, the kernel typically doesnt know there are two parts, it only gets start address and size from the BL)
<alkisg> ogra: thanks, I'll try with lz4 or whatever else it is, and with uncompressed ltsp.img, and report back... but a bit later, too sleepy now...
<alkisg> ogra: I was guessing that the code would be like "while ... check initrd header; decompress; done" => i.e. it would check the header/compression type on each new initrd it sees while "walking the list", not just once at start...
<alkisg> But OK if it's a restriction, we can match it from the ltsp code
<apw> alkisg, let me know in the bug if it does work with the 'same compression'
<apw> alkisg, as i am not sure we are not going to end up missmatched with cpu firmware too
<ogra> well, this is stuff i found during testing with u-boot, ipxe or grub might work differently (i never tried different compressions etc on grub and never used ipxe), i'm just assuming that the process is similar on other bootloaders
<apw> ogra, right, this would be a kernel side limitation, just very odd
<ogra> well, for u-boot is it pretty clear that the kernel only sees a single initrd blob in ram because it only hands start address and size over ... might be different in the other cases
<ogra> (size=complete size of both parts)
<apw> ogra, right there is only 'here,this-big' option to the kernel
<apw> ogra, and it decompresses till the compressor says 'done' then it tries again if we are not at the end
 * alkisg starts testing with kvm and a single concatenated initrd, which should be faster to test with...
<ogra> aha ... well, if it tries agan if not at the end that might indeed mean it should support multiple compressions
<ogra> and then i agree there is a bug ... i didnt know the kernel does that
<alkisg> Here are the first results, with concat:
<alkisg> initrd.img: ASCII cpio archive (SVR4 with no CRC) => 19.10
<alkisg> ltsp.img:   gzip compressed data, last modified: Wed Aug 21 11:46:58 2019, from Unix ==> fails with gzip
<alkisg> cat ltsp.raw initrd.img.original > initrd.img (no gzip) ==> succeeds
<alkisg> So it works fine with raw, but not with gz now; while it worked from debian jessie and ubuntu 16.04 that I'm testing with, until all the recent versions up to 19.10
 * alkisg tries to see how to make it lz4...
<alkisg> unmkinitramfs ../initrd.img.original .
<alkisg> cpio: premature end of archive
<alkisg> apw: premature end of archive? maybe bad initrd in 19.10?
<alkisg> (that's the stock one from the live cd)
<alkisg> OK that would explain it then, why it can't follow up with the next one
<apw> alkisg, odd
<alkisg> So not a kernel thing, but a mkinitramfs thing
<ogra> well, if its invalid, how would the livecd's boot ?
<ogra> i'd assume we'd have heard if they do not ...
<alkisg> ogra: e.g. if it's just some padding, it could do that
<alkisg> I.e. decompress correctly, even with "oh premature end", but then it won't be able to follow up with the next initrd
 * alkisg downloads the ubuntu.iso instead of the lubuntu one...
<apw> right if it was a byte long it might parse and unpack the cpu firmware in section 1, the real initramfs in section 2, and think there is a section 3 of the padding and barf there
<alkisg> apw: do you know if an installed systemd uses different code to update-initramfs vs the live cd? I'm only testing with live cds for 19.10...
<alkisg> *system
<alkisg> (live cds worked fine up to 19.04 too)
<apw> alkisg, the initramfs is different in contend but made the same way
<apw> content
<alkisg> OK the content shouldn't matter with rdinit=/bin/sh, so...
 * alkisg is downloading yesterday's ubuntu.iso, let's see...
<apw> alkisg, i just mounted up the eoan ubuntu desktop image on my machine here, and the initrd in that is extractable without that error
<apw> (and this machine is also running eoan)
<ogra> apw, oh, since i have you here ... whats the reason for all the armhf metapackages (linux-raspi2, linux-snapdragon) to be in unverse (i have been trying to derive clssic images from core based ones using u-image and noticed that ... the server rootfs build in u-image doesnt have universe in its sources.list so you cant instal a kernel on these devices without hackery)
<alkisg> Hrm. Let me see what happens with yesterdays'...
<apw> ogra, because things end up in main through need mostly, and things which only end up in core avoid seeding
<apw> $ md5sum /mnt/casper/initrd
<apw> f3a8e1484ad2ebcca4437a8bf949266b  /mnt/casper/initrd
<apw> alkisg, ^ is the one i can dething
<ogra> apw, well, we officially support server images for pi and dragonboard ... that is what made me curious
<ogra> i'd have the metas expected to be seeded via -supported or some such
<apw> ogra, and the "we" part is where care is needed; does "ubuntu" or "canonical" support those
<alkisg> (different one here) 4b0a58102b099fa26d89aad3a7952e7a  initrd.img.original
<ogra> canonical AFAIK
<ogra> (which in turn includes ubuntu i think)
<apw> anyhow that isn't quite what main means; and you will find people arguing both ways to put it in main and not
<ogra> we're offering these builds to customers for commercial products ... 
<ogra> heh, ok 
<ogra> well, it just made me curious ... i didnt mean to start a discussion about it 
<apw> that is a separate commercial concern and not related to ubuntu support status
<ogra> ok
<apw> as we support each of those for customer specific times; and peopel tend to assume main == 5 years
<apw> (in an lts)
<ogra> right
<apw> ogra, but we also move things to main to make isos, so ... 
<apw> we can support longer than the ubuntu marked support not less
<apw> sort of thing
<ogra> yup
<alkisg> apw: same problem with http://cdimage.ubuntu.com/daily-live/20190819/eoan-desktop-amd64.iso
<alkisg> I'm running unmkinitramfs in 18.04,would it matter?
 * alkisg tries booting the live cd to unmkinitramfs in 19.10...
<apw> alkisg, maybe, does that old version support lz4
<alkisg> It does show the contents
<apw> oh, then not that
<alkisg> Oh never mind. 56k
<apw> alkisg, md5sum of your .iso please
<apw> 56k ?
<apw> 19 ?  i have an .iso from 21
<apw> with a date of the 21st
<alkisg> apw: no the iso was fine, but unmkinitramfs isn't,
<alkisg> I saw early/main and thought it was ok, 
<apw> oh
<alkisg> but it only managed to uncompress the -rw-r--r-- 1 alkisg alkisg  30K ÎÎ¿Îµ  28  2018 AuthenticAMD.bin
<alkisg> So no lz4
<alkisg> OK that would explain the "premature" error, but not the "second initrd isn't shown when booted" error
 * alkisg moves to test from 19.10 now...
<alkisg> Heh nice desktop icons :D
<alkisg> Verified that 18.04 can't decompress 19.10 initramfs (same md5sum, works in 19.10)
<alkisg> cat /cdrom/casper/initrd ltsp.cpio.gz > test1; unmkinitramfs test1 .  ==> premature end of archive (all inside 19.10)
<alkisg> cat /cdrom/casper/initrd ltsp.cpio > test2; unmkinitramfs test2 .  ==> works
<alkisg> apw: would you consider it a bug when unmksquashfs fails when lz4+gz initrds are joined?
 * alkisg moves on to testing netbooting again, but with uncompressed ltsp.img...
<apw> alkisg, i thnk the manual page has a bugs section saying it is a bit crap
<alkisg> Ah
<apw> BUGS
<apw>        unmkinitramfs cannot deal with multiple-segmented initramfs images, except  where
<apw>        an  early (uncompressed) initramfs with system firmware is prepended to the reguâ
<apw>        lar compressed initramfs.
<apw> actually so crap it is hard to believe the text is right !
<alkisg> Nope, 19.10 can't load even lz4+raw; I don't know how to create lz4+lz4 to test that. Checking dmesg...
<apw> raw comes first
<alkisg> I mean my raw, not the microcode
<alkisg> I didn't say that correctly, I mean this:
<alkisg>         find . ! -name ltsp.img | cpio -oH newc > "$_DST_DIR/ltsp.img"
<alkisg> vs this:         find . ! -name ltsp.img | cpio -oH newc  | gzip > "$_DST_DIR/ltsp.img"
<apw> ahh
<alkisg> unmkinitramfs in 19.10 works without gzip, fails with gzip there,
<alkisg> the kernel fails in both cases
<apw> and you are concatting them how
<alkisg> cat 1 2 > 3
<apw> makes sense
<apw> alkisg, there seems to be an lz4 command
<alkisg> I tried this silly test: 19.10 kernel, 18.04 initramfs, plus ltsp.img ==> works
<alkisg> So it's not a kernel change, but something in the new initramfs that makes the kernel choke
<apw> ok which is raw+gz+gz i assume
<alkisg> Right
<apw> so you need to make the raw+lz4+lz4
<apw> and the command lz4 with no arguemnts seems to be a compressing pipeline
<alkisg> OK let me install that and test, ty
<apw> alkisg, it is also possible that there is padding at the end of an lz4 that the kernel does not grok, we will find out from this test
<alkisg>         find . ! -name ltsp.img | cpio -oH newc | lz4 > "$_DST_DIR/ltsp.img"
<alkisg> This has the same issue
<alkisg> I.e. it only sees the first initramfs
<alkisg> Since raw+lz4+raw didn't work... yes it sounds like a padding in lz4
<apw> alkisg, can you give me the actual error the kernel emits please, it matters
<alkisg> apw: I don't see anything in dmesg, where would I find that?
<apw> alkisg, never mind, i'll see if i can repo
<alkisg> Ty :)
 * alkisg tries injecting a couple of zeros between, in case it's a matter of padding...
<apw> alkisg, don't think that will work, it expects the first two bytes of the remaining space to be a file magic
<alkisg> Yeah it didn't; although it does have a few nulls at the end, adding/removing some didn't help
<apw> [    0.288625] Initramfs unpacking failed: junk within compressed archive
 * alkisg didn't have that in dmesg
<apw> alkisg, as i can reproduce it, i will poke for a bit
<apw> alkisg, could you file that bug for me
<apw> alkisg, a +filebug will be fine
<apw> alkisg, which kernel does this work with previously ?
<alkisg> apw, 19.04; will check in a bit and file bug, ty
<alkisg> apw: I think it's a bug in mkinitramfs though, not in the kernel, e.g. it might generate invalid length of lz4 or something...
<apw> alkisg, also it does handle padding, as long as it is 0's
<apw> alkisg, or the lz4 format is not length aware, or
<alkisg> OK... but then this is the first kernel that we try lz4 booting, right?
<alkisg> So "it worked in 19.04" doesn't make any sense
<alkisg> Since it was gz, and gz still works
<alkisg> So lz4 might have been broken since its initial implementation, and noone would have noticed, since concatenating something after lz4 isn't too common
<alkisg> (or passing multiple initrds)
 * alkisg wonders how to check if 19.04 used lz4 or gz
<apw> alkisg, it only just changed in eoan
<alkisg> OK then it sounds possible that it never worked correctly with lz4
<alkisg> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1840945
<ubot5`> Ubuntu bug 1840945 in linux (Ubuntu) "Concatenated lz4 initrds don't work" [Undecided,New]
<alkisg> I didn't run ubuntu-bug, as it would report the host, not whatever's inside kvm
<alkisg> And I only had kernel/initrd inside kvm, so I couldn't run ubuntu-bug from there either
<alkisg> If needed, I can do an installation inside a VM... but I'm not sure if it'll help
<apw> alkisg, no that is enough
#ubuntu-kernel 2020-08-17
<sub526> Hi all, Iâm having two identical Linux x86_64 systems with different Ubuntu kernel versions. The 1st one has Ubuntu 16.04.4 LTS kernel and the 2nd systems has Ubuntu 18.04.4 LTSkernel. I see that, the older distro version kernel(Ubuntu 16.04.4 LTS) is bit faster compared to the system with later version(Ubuntu 18.04.4 LTS). perf bench sched
<sub526> messaging -g 64 resulted "Total time: 2.838 [sec]" in older Ubuntu version whereas in other machine "Total time: 9.834 [sec]". Also, time taken to load the driver(insmod) also varies between two systems. What is best way to debug and solve this issue?
<sub526> Ubuntu 16.04 machine has 4.4.0-66-generic kernel and Ubuntu 18.04 machine has 4.15.0-91-generic
#ubuntu-kernel 2020-08-19
<sub526> Hi all, I'm having Ubuntu 18.04.4 LTS (4.15.0-91-generic kerne) system, I need downgrade the kernel to 4.4.0-66-generic kernel. Is it possible to downgrade, if so how to achieve this?
<jceel> hi everyone
<jceel> my company has designed a board based on an AArch64 SoC that I would like to add Ubuntu support for
<jceel> I need to at least add a custom device tree file for my platform to the kernel package
<jceel> so far I have forked ubuntu-bionic kernel from the official repo and set up APT repository to host kernel image and module packages
<jceel> and made the appropriate changes in the kernel source tree
<jceel> however, the resulting kernel-modules package does not contain my .dtb file
<jceel> even though it is correctly wired up in the Makefile and I can see that make dtbs_install installs it
<jceel> how to proceed with debugging it?
<sarnold> jceel: I know next to nothing about the kernel packaging, but there's often a debian/*.install file of some sort to describe which files go in which packages -- there may be something similar
<jceel> sarnold: there are no such files in kernel packages, so I'm guessing they must be generated by something
<sarnold> dang :(
<jceel> in fact there's so much makefile code in those packages that it may take weeks to understand all of that
<jceel> the interesting thing is that the resulting /lib/firmware/.../device-tree directory tree doesn't contain all the built dtb files but only some of them
<jceel> yet I can't find a list of those files
<jceel> (I tried grepping some characteristic names)
