#ubuntu-kernel 2006-01-30
<HiddenWolf> Hi guys.
<HiddenWolf> I'm looking through lsmod, and I can't figure which module is taking care of networking.
<HiddenWolf> I'm trying to see which module to check for, since I don't think dapper-live is loading it. 
<mjg59> HiddenWolf: "Taking care of networking"?
<mjg59> ipv4 is built in
<HiddenWolf> mjg59: I'm trying to figure out how I can see if the driver for my network chip is loaded.
<sn9> lsmod
<HiddenWolf> yeah, I did lsmod, but I can't find anything that looks like a network driver.
<HiddenWolf> nforce4 card
<sn9> drivername: forcedeth
<mjg59> Yeah, it's forcedeth for the dodgy nvidia stuff
<HiddenWolf> 0000:00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
<sn9> there is also nvidia'sm own driver
<HiddenWolf> ah, forcedeth is loaded
<HiddenWolf> I'll see if the dapper livecd does the same.
<HiddenWolf> brb
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-14.19 upload{ing,ed} (Quiet Serenity - AKA, "Hopefully the last ABI bump for awhile") | Daily Diet of Destruction: http://people.ubuntu.com/~bcollins/kernels-daily/
<mxpxpod> BenC: so, I take it you figured out the sleep issue?
<BenC> yeah
<mxpxpod> awesome
* mxpxpod hopes the kernel is ready at lunch for download :)
<BenC> I didn't have a chance to upload the .deb (my upload b/w is really low), but you should see .14 within a day
<mxpxpod> BenC: sweet, thanks
<BenC> sure thing
<mxpxpod> BenC: now, about that bluetooth hid thing...
* BenC is off for an early lunch
<mxpxpod> heh
<BenC> oh, I am going to get a bluetooth mouse on my lunch break :)
<BenC> I'll have that figured out soon
<mxpxpod> suhweet
* mxpxpod would hug BenC, but doesn't know him well enough so just shakes his hand
<BenC> I'll take any excuse to buy new hardware...makes it easier to convince my wife :)
<mxpxpod> :D
<BenC> "But mpxpoad can't use his scroll wheel...you want him to be able to use his scroll wheel, don't you?"
<mxpxpod> now there's a good excuse if I've ever heard one ;)
<lamont__> hrm... new kernel.
<dilinger> is ndiswrapper 1.8 in 14.19?
<dilinger> and is 14.19 available somewhere yet?
<zul> have you tried daily kernels?
<zul> http://people.ubuntu.com/~bcollins/kernels-daily
<dilinger> http://people.ubuntu.com/~bcollins/kernels-daily/20-01-2006/i386/
<dilinger> 13.19
<dilinger> no abi bump
<sn9> 14.19 is out? where's the changelog?
<zul> oh..
<dilinger> sn9: /topic
<sn9> it says upload{ing,ed}
<zul> http://kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-2.6.git;a=blob;h=234d6ababa5bbc2ab9593981fad754c33e267a2e;hb=71bfab2f7f42806da679986e3098964b0e348b2c;f=debian/changelog
<sn9> thanx
<dilinger> hm, no mention of ndis 1.8
<sn9> no mention of i2c bugs either
<sn9> any ETA to a powerpc .deb of this version?
<zul> soon..
<HiddenWolf> Guys, can anyone help me figure out if I'm having a regression from Breezy here or if I'm just doing something wrong.
<sn9> maybe you're doing something regressively wrong :)
<HiddenWolf> Possible. :)
<HiddenWolf> I just upgraded breezy > dapper. Went smooth, save libnotify.
<HiddenWolf> My tvcard now only produces a tearing noise, like there is static
<HiddenWolf> Haven't changed the hardware, same software, same settings.
<HiddenWolf> 0000:05:08.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)
<sn9> did you dist-upgrade, or just the kernel?
<HiddenWolf> 0000:05:08.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
<HiddenWolf> dist-upgrade
<sn9> that was likely a big mistake at this stage
<HiddenWolf> Everything else is smooth. :)
<HiddenWolf> why would it be a _big_ mistake? 
<sn9> no easy way to go back when things go wrong
<HiddenWolf> I tested with a livecd, this was the only thing I couldn't test, and the only thing that went wrong. 
<HiddenWolf> So I'm trying to get together the data, figure out if it's kernel or something else, and file a bug.
<sn9> i installed breezy in july, and endured a lot of brokenness until release
<HiddenWolf> Save for the tvcard-sound and my multimedia keys, it's less broken than breezy for me at the moment.
<sn9> one thing i noticed about the dapper kernel is that genrtc is now a module and needs to be added to /etc/modules
<sn9> dunno what effetc that might have on v4l
<HiddenWolf> I'm not kernel-savy, do I need either of those modules?
<sn9> i was assuming you're using v4l to test the video capture
<sn9> random things break without genrtc
<HiddenWolf> the video capture is ok, it's the audio that goes with it that's bust.
<sn9> oh, alsa broke for me too
<sn9> i2c bug
<BenC> mxpxpod: ping
<BenC> mxpxpod: My bluetooth mouse is working perfectly, scroll wheel and third button (wheel click)
<BenC> it's a Kensington PilotMouse
<BenC> need to reboot
<mxpxpod> BenC: hmm
<mxpxpod> BenC: I'll try my microsoft mouse with the newest kernel
#ubuntu-kernel 2006-01-31
<chmj> BenC: ping 
<chmj> hello  fabbione
<fabbione> hey chmj 
<chmj> any know b0rkages with dist-upgrade to dapper and ide-* modules? 
<fabbione> no idea
<chmj> new kernel and initramfs can't mount my root fs :-/ 
<chmj> regenerated image with ide-* modprobed still wont do it 
<BenC> chmj: pong
<BenC> chmj: when initramfs drops shell, check lsmod and dmesg
<chmj> BenC, still around ?
<BenC> yeah
<chmj> cool 
<chmj> lsmod is not in busybox 
<chmj> so I $> cat  /proc/modules 
<chmj> the image I generated has ide-disk,ide-core and ide-generic 
<BenC> that's odd
<BenC> ide-core should be in the kernel
<BenC> so this is a self compiled image?
<chmj> but its nope
<chmj> dist-upgrade 
<chmj> the breezy kernel boots but all the devices don't work 
<chmj> funny thing, whn I reload the modules, they create the neccessoty file and I can mount the drive from busybox 
<BenC> so ide-core exists in dapper kernel?
<BenC> something's wrong there, because it should not
<BenC> I just checked, all arch's have CONFIG_IDE=y
<BenC> chmj: does dmesg show that the drives were detected, and it's just that the device file isn't created?
<BenC> if so, that's a udev bug
<chmj> hmm 
<chmj> busybox doesn't seem to have dmesg 
<chmj> ahhh 
<chmj> the drivers are detected just before it drops the shell
<BenC> are you sure you have the latest udev?
<BenC> try upgrading, and rerun "sudo update-initramfs -u"
<chmj> hmmm 
<chmj> dist-upgrage surely should have installed that 
<chmj> :-/
<chmj> gtg, laterz
<zul> heylo
<bubbalwz> BenC: wake up
<dilinger> demanding, aren't we? :p
<bubbalwz> yes
<bubbalwz> i'll hold his wife hostage if he ignores me
<bubbalwz> and fabbione's wife too
<BenC> bubbalwz: yo
<BenC> good luck holding my wife down, I've tried
<fabbione> bubbalwz: you know your kid is not really your.. don't you?
<BenC> lol
<fabbione> also.. if you hold my wife.. good luck.. you can keep her :P
<zul> ah thats not nice..
<fabbione> zul: nah.. we know bubba :)
<BenC> bubbalwz: btw, my wife says hi :)
<zul> fabbione: ah ok..
<BenC> bubbalwz: btw, make sure megaraid_mbox is loaded
<bubbalwz> heh
<bubbalwz> it is
<bubbalwz> well, it's in my /etc/mkinitramfs/modules file
<fabbione> zul: i mean.. we know him bibblicaly :)
<BenC> bubbalwz: cat /proc/modules make sure it is loaded
<zul> fabbione: great...thanks for the imagery in my head now
<BenC> or modprobe megaraid_mbox
<bubbalwz> well, it's not in 2.6.10
<BenC> what about just megaraid?
<bubbalwz> just megaraid is in 2.6.10
<bubbalwz> and it's loaded, as i'm on the box 
<BenC> is it loaded?
<BenC> ok
<bubbalwz> megaraid 41704 6 - Live 0xf881a000
<bubbalwz> scsi_mod 127552 3 sg,sd_mod,megaraid, Live 0xf8835000
<BenC> so it's breezy where it breaks?
<bubbalwz> yep
<bubbalwz> 2.6.12 is a nogo
<BenC> is megaraid in breezy?
<bubbalwz> yep, megaraid, megaraid_mbox and megaraid_mm
<BenC> ok, did you load megaraid_mbox in breezy (after you get to the busybox shell)?
<fabbione> BenC: i think the megaraid /megaraid_mm split up might miss a PCI ID
<BenC> yeah, there's a way to force it though
<bubbalwz> nope, but I can try (not on the console of the box now, but can try later)
<bubbalwz> just tell me what to do
<BenC> modprobe megaraid_mbox
<bubbalwz> k, i'll try that
<bubbalwz> i did verify that megaraid_mbox was in the initrd image
<BenC> echo "101e:1960" > /sys/bus/pci/megaraid_mbox/new_id
<BenC> echo "101e:1960" > /sys/bus/pci/drivers/megaraid_mbox/new_id
<BenC> that one
<bubbalwz> ok
<bubbalwz> wish I could try it now, but i cant
<bubbalwz> if that works, then what?
<bubbalwz> and, would it be possible to install a clean version of breezy off cd ?
<BenC> if that works, then you just need to add a custom script to initramfs stuff to do it for you
<BenC> to do a breezy install, you'd need to drop to shell and do the same thing
<bubbalwz> so is this fixable?
<BenC> yeah, if it works, we can do a fix in the  next kernel for breezy
<BenC> just a one-liner
<bubbalwz> ok, cool
<bubbalwz> i'll try that when i get home and get back w/ you
<BenC> ok
<bubbalwz> gracias
<bubbalwz> tell britey i said hi
<BenC> ok, later dude
<bubbalwz> later on
<BenC> fabbione: did I tell you I have a bluetooth mouse on my pb now?
<BenC> so sweet to be able to move my mouse from across the room :)
<fabbione> BenC: no
<fabbione> and i nees still to get my touchpad configured properly
<BenC> I was going to get the apple bt mouse, it it was single button
<bubbalwz> omg what to do w/ just 1 button :)
<fabbione> yeah, i don't really mind the single button
<BenC> got a kensington instead
<fabbione> BenC: i took the webcam with me
<BenC> blah, I need scroll wheel :P
<fabbione> and cloned the trees on my lappy
<fabbione> BenC: there is a scroll wheel on the apple
<fabbione> i will show it to you sunday
<fabbione> it's a little tiny ball on top 
<sn9> only the mighty mouse has that. the others are one-button
<BenC> the guy in the store told me it only had the one button
<sn9> the mighty mouse is also the only apple mouse that can right-click
<BenC> yeah, the bt apple mouse doesn't have scroll or second button
<BenC> fabbione: I paid a hefty chunk for the 17" case for my pb too...that sucker was expensive
<sn9> are you running 2.6.15-14 on your pb?
<BenC> of course :)
<sn9> because i have 2.6.15-13 on the iBook and keywest i2c segfaults on load
<BenC> that's a snd-powermac issue, which should be fixed in -14
<sn9> thanx
<BenC> well, it shouldn't oops anymore, but I can't guarantee that sound is working :)
<sn9> works perfectly in -9, so what broke it in -13?
<fabbione> BenC: sound seems to work here on 14
<BenC> sn9: I reworked snd-powermac so that it would work on more systems (and work reliably on systems where it was a little quirky)
<BenC> fabbione: it should, you have the same pb I do :)
<BenC> sn9: I just can't test them all, so it's a little hit or miss
<BenC> easy to fix though
<BenC> toonie should be working great, but tumbler and snapper may need a little extra tweaking
<sn9> with the breezy kernel, snd-powermac would refuse to work unless dmasound-pmac was loaded and unloaded prior to loading snd-powermac
<BenC> yeah, that should be fixed with the new driver
<BenC> the main thing that was reworked was the gpio access
<BenC> snd-powermac will get a lot more robust in 2.6.16/17
<BenC> hopefully support digitial in/out and everything
<sn9> but that was only true on iBooks. on TiBooks, it had no problems
<sn9> really? i would love to have the mic working
<BenC> sn9: right, that's because the gpio mechanism was guessing
<BenC> now the gpio (on recent systems, atleast within the past 3 years) will be done correctly
<mxpxpod> BenC: so, I just downloaded the new kernel and alsa still doesn't work :(
<BenC> ls -l /proc/asound
<mxpxpod> BenC: let me log into irc from my ibook
<bryanf> BenC: this is mxpxpod
<BenC> ok
<bryanf> here's ls -l /proc/asound/
<bryanf> -r--r--r-- 1 root root 0 2006-01-26 12:51 cards
<bryanf> -r--r--r-- 1 root root 0 2006-01-26 12:51 devices
<bryanf> -r--r--r-- 1 root root 0 2006-01-26 12:51 modules
<bryanf> dr-xr-xr-x 2 root root 0 2006-01-26 12:51 oss
<bryanf> -r--r--r-- 1 root root 0 2006-01-26 12:51 pcm
<bryanf> dr-xr-xr-x 2 root root 0 2006-01-26 12:51 seq
<bryanf> -r--r--r-- 1 root root 0 2006-01-26 12:51 timers
<bryanf> -r--r--r-- 1 root root 0 2006-01-26 12:51 version
<BenC> ok, it's not detecting the card
<BenC> hmm
<sn9> check dmesg
<BenC> dmesg it probably empty
<BenC> but if there is anything it will be near the i2c uni-n messages
<sn9> my /proc/asound looked just like that under 2.6.15-13, but dmesg revealed the segfault
<BenC> segfault should be gone with 014
<BenC> -14
<bryanf> BenC: there's no segfault in my dmesg
<bryanf> BenC: just so you konw
<bryanf> s/konw/know/
<BenC> it's just not detecting it properly
<bryanf> strange
<BenC> I'll get a test snd-powermac.ko module for you with some debug output
<bryanf> cool
<bryanf> BenC: also, lsmod shows that nothing is using snd-powermac
<BenC> right, it wouldn't
<bryanf> ok
<zul> ps axuw
<zul> doh..
<BenC> 1 init <zombie>
<sn9> lol
<cjb`> Wah.  Our kitten is unlucky.
<cjb`> He picked up a {rare,fatal,incurable} reaction to a common virus.  :(
<cjb`> Gonna have to put him to sleep in the next few days.
<BenC> that sucks, sorry to hear that
<mxpxpod> BenC: ping
<BenC> yo
<mxpxpod> got that module for me?
<mjg59> BenC: Can we pull ACPI head?
<mjg59> Contains a workaround for stuff that breaks battery reading on a pile of Acers
<BenC> I can cherry, but I'd rather not pull from heads that might be syncing aganst 2.6.16-git
<BenC> mjg59: is that the smart battery thing?
<BenC> if you can get me a commit id I can cherry pick it
<bubbalwz> BenC: ok, i'm at the console now
<bubbalwz> only have megaraid and megaraidlegacy under drivers
<bubbalwz> no megaraid_mbox, even after i modprobed it
<bubbalwz> if i do echo "101e:1960" > /sys/bus/pci/drivers/megaraidlegacy/new_id
<bubbalwz> i get shit like sda: asking for cache data failed
<mxpxpod> BenC: I take it you haven't worked up the debug module
<mjg59> BenC: Nope
<bubbalwz> fabbione: http://72.14.203.104/search?q=cache:MaSOb-BO-BsJ:people.ubuntu.com/~fabbione/irclogs/ubuntu-kernel-2005-04-19.html+megaraidlegacy&hl=en&gl=us&ct=clnk&cd=3
<mjg59> BenC: It's due to placeholder values in the battery object
<mjg59> They never actually get used, but the interpreter bitches
<BenC> bubba: atleast it is seeing the drives
<BenC> unload megraidlegacy, and try just megaraid
<BenC> look under /lib/modules/2.6.1*/kernel/drivers/scsi/megaraid/
<bubbalwz> how do i continue
<BenC> load some of those modules up
<bubbalwz> to try and boot
<bubbalwz> after i load a module
<BenC> find the right module and do the new_id thing on it
<bubbalwz> megaraid failed 
<bubbalwz> megaraidlegacy is the right one
#ubuntu-kernel 2006-02-01
<BenC> megaraid failed?
<BenC> ENODEV?
<bubbalwz> nah, a bunch of errors
<bubbalwz> pages and pages
<BenC> weird
<bubbalwz> but megaraidlegacy loads.. just trying to figure out how to continue booting
<BenC> if legacy is right, then maybe try modprobe sd_mod
<bubbalwz> then what?  exist?
<bubbalwz> exit
<bubbalwz> synx?
<bubbalwz> err, sync
<mjg59> BenC: http://www.kernel.org/git/?p=linux/kernel/git/lenb/linux-acpi-2.6.git;a=commit;h=defba1d8f233c0d5cf3e1ea6aeb898eca7231860
<BenC> mjg59: ok
<BenC> bubba: yeah, exit
<BenC> mjg59: Can you email that to me? I'm in osx right now
<bubbalwz> after i type exist
<bubbalwz> exit, i get "Kernel panic -not syncing : Attempted to kill init"
<BenC> weird
<BenC> getting the same thing on another system
<BenC> but that's dapper
<mjg59> BenC: Ok
<BenC> thanks
<bubbalwz> any ideas?
<psusi> so... anyone get the big flame war lately on lkml about device naming and cdrecord?
<psusi> why is the linux kernel group so up in arms about the generic scsi bus/target/lun naming scheme?
<bronson> Is there any reason CONFIG_9P_FS is not set in 2.6.15-11?
<bronson> v9fs is starting to look real useful...  is there any downside to making it a module?
<bronson> Ah well.   Bug #29859 in kernel-package (Ubuntu): "Please enable CONFIG_9P_FS (v9fs) by default"
<BenC> I'll look into it
<bronson> BenC, thanks!
<BenC> done, will be in the next upload (assuming it builds)
<zul> heylo
<BenC> hey zul
<zul> hey BenC how is it going?
<BenC> not too bad
<BenC> you have any updates for me?
<zul> probably not til sunday
<zul> git tree is on the fritz again
<BenC> ok, I had noticed you had marked some bugs with "in my tree", so wanted to get those whenever you're ready
<zul> yep no problem
<torkel> BenC: ping
<BenC> torkel: pong
<torkel> BenC: Do you have some time to take a look at a kerneloops from a HP DL145 with dual opteron?
<torkel> it'is running breezy with linux-image-2.6.12-10-amd64-k8-smp, ver 2.6.12-10.26
<torkel> it does not happen every time, but it is repeatable
<mxpxpod> BenC: ping
<BenC> sounds like the amd64 regression in the breezy kernel
<BenC> mxpxpod: hey, give me 15 minutes and I'll have a debug enabled snd-powermac for you
<mxpxpod> BenC: suhweet
<BenC> torkel: there's already a bug report on it, with about 12 people subscribed
<BenC> torkel: search launchpad.net/malone for regression on linux-source-2.6.12 package
<torkel> BenC: will do
<torkel> BenC: any idea if and when it will be fixed?
<fabbione> torkel: as soon as i can get to build the kernel again
<fabbione> torkel: if it is what i think, somebody is going to have a LOT of fun fixing it
<torkel> fabbione: oh...
<fabbione> torkel: it seems to be a binutils regression
<fabbione> if i can confirm that, somebody is going to cry a lot
<fabbione> basically -9.23 built with old binutils (as in the archive) works fine
<fabbione> a local build of 9.23 with new binutils seems to break
<fabbione> but i need to reproduce the overall situation in very clean environment
<fabbione> to be sure 100% that we are working on the right bit
<fabbione> it's not simple, htat's why it is taking time
<torkel> fabbione: ley me (or maswan) know if there are anything we can do to help you
<fabbione> torkel: thanks, ig you can reproduce any of the problems mentioned in the bug, it's cool
<fabbione> otherwise just sit/wait and hope
<BenC> torkel: subscribing to the bug would be best, that way you will find out when fabbione has a test kernel
<torkel> BenC: sure. I just have to find it. I obvoulsy suck at searching in malone :-(
<BenC> I'll find it real quick
<BenC> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/26859
<torkel> ah, it was filed under 2.6.15 :-)
<fabbione> uh
<fabbione> MALONE BUG
<BenC> yeah, all the bugzilla imports got put to 2.6.15 :/
<BenC> I even asked for special casing, but it wasn't done
<zul> great...my stress level went up 10 times
<BenC> mxpxpod: ready for some testing?
<mxpxpod> BenC: well, I can test in 3 hours (lunch), but go ahead and send me the module
<BenC> doesn't require a reboot
<mxpxpod> BenC: no, I know, but I'm on a windows machine at work and my bosses would get mad if I brought out my laptop to test it
<BenC> you have "bosses"?
<mxpxpod> BenC: yup
<BenC> http://people.ubuntu.com/~bcollins/kernels/tumbler-testing/
<BenC> -1 is in there, I'll do -2, -3, etc as needed
<BenC> this should let me know where it is failing in the detect phase
<mxpxpod> BenC: ok, sweet
<torkel> hm, I'm not 100% sure it is the same bug I'm hitting. I have put the oops at http://pastebin.com/525630
<torkel> let me know if you want me to attach it to bug (or if you want me to file a new one)
<BenC> torkel: does linux-image-2.6.12-9 work for you?
<BenC> that's the true test
<torkel> BenC: I'll check, but it will probaly take until monday before I get a chance doing it
<torkel> *bleh* the true test says that it crashes with linux-image-2.6.12-9 too :-(
<torkel> guess I should file a bug...
<BenC> yeah, sounds like a different issue
<BenC>   storage.firmware_version = 'FAAG'  (string)
<fabbione> lol
* BenC wonders if his dvd driver maker is homophobic
<sn9> which drive?
<BenC> Matsushita DL DVDR
<zul> well that explains it Matsu*SHIT*a
<sn9> hmm no DL on rpc1.org
<sn9> you sure that's the model number?
<BenC> not the model number
<sn9> oh, dual layer
<BenC> [   18.571270]  hdb: MATSHITADVD-R UJ-846, ATAPI CD/DVD-ROM drive
<BenC> yeah
<BenC> MATSHITA
<sn9> hmm they only have a UJ-846S listed, as a hitachi oem drive
<sn9> with F101, not FAAG
<bryanf> BenC: ok, I've got the module downloaded... how do I replace snd-powermac with it? or just insmod snd-powermac-1.ko?
<BenC> rmmod snd-powermac
<bryanf> yeah, did that
<BenC> insmod snd-powermac-1.ko
<bryanf> you want the dmesg output?
<BenC> yes
<bryanf> [  403.189930]  snd_powermac: no version for "struct_module" found: kernel tainted.
<bryanf> [  403.272456]  (I:1078) status = 0
<bryanf> [  403.272492]  (I:1080) status = 0
<bryanf> [  403.272517]  (I:1082) status = 0
<bryanf> [  403.272553]  (I:1085) status = -19
<BenC> just the relevant part from the insert
<bryanf> [  403.272617]  (I) codec normal reset !
<bryanf> [  403.684014]  Trying to free free IRQ61
<BenC> ok, hold on a sec
* bryanf holds
<BenC> great, it's not finding the lineout
<bryanf> oh fun
<BenC> that's a start, sit tight while I check something out
* bryanf sits tightly
<BenC> please do find /proc/device-tree | grep -- -mute
<bryanf> BenC: nothing
<BenC> there has to be something, it found the amp-mute
<bryanf> I promise you, there's nothing :(
<BenC> rgrep -- -mute /proc/device-tree
<bryanf> Binary file /proc/device-tree/pci@f2000000/mac-io@17/gpio@50/gpio6@70/audio-gpio matches
<bryanf> Binary file /proc/device-tree/pci@f2000000/mac-io@17/gpio@50/gpio5@6f/audio-gpio matches
<BenC> cat both those files for me please
<bryanf> BenC: hmm...
<bryanf> oh
<bryanf> gpio6@70: amp-mute^@
<bryanf> gpio5@6f: headphone-mute^@
<BenC> sweet
<bryanf> ?
<BenC> false failure, you don't need a lineout
<BenC> you just have headphone
<bryanf> oh, ok
<bryanf> so why isn't it finding my speakers?
<bryanf> s/speaker/soundcard/
<BenC> you're speakers are plugged into the headphone
<BenC> just a label
<BenC> same on my powerbook
<bryanf> hmm
<bryanf> ok
<bryanf> and why isn't alsa seeing my soundcard?
<BenC> -2 is waiting for you
<sn9> what's the difference between line in and microphone on the screamer chip?
<BenC> one probably doesn't really exist
<bryanf> BenC: here goes:
<bryanf> [ 1265.155267]  (I) codec normal reset !
<bryanf> [ 1265.563886]  (I) tumbler_init returned
<bryanf> [ 1265.563956]  (I) TAS i2c address is: 35
<bryanf> [ 1265.578091]  headphone: 0, lineout: 0
<bryanf> [ 1265.580846]  (I) snapper init client
<bryanf> [ 1265.628910]  input: PowerMac Beep as /class/input/input6
<BenC> does it work?
<bryanf> yeah!
<sn9> why is it initing both tumbler and snapper, though?
<BenC> damn skippy
<BenC> sn9: snapper is just a tumbler varaint
<bryanf> BenC: so, what was the problem?
<sn9> ok. any hope of sound in on the tumbler?
<BenC> bryanf: just overly agressive error checking on my part
<BenC> sn9: not for dapper
<sn9> darn
<bryanf> ok, gotta log out of GNOME to get sound... brb
<BenC> benh is working on implementing all the codecs for digital in/out in ppc sound
<bryanf> BenC: does this mean you'll need to make another kernel bump?
<sn9> even burgundy?
<BenC> supposedly
<BenC> topaz, onyx, burgundy,...
<bryanf> BenC: ok, this is strange
<bryanf> I have a sound card
<bryanf> but no sound
<sn9> try aplay
<bryanf> sn9: nope
<sn9> could be muted
<sn9> check your mixer flags
<sn9> PC Speaker cannot be off, or you get no sound
<bryanf> it's on
<sn9> does dmasound-pmac work on your machine?
<bryanf> sn9: no such device
<sn9> you have to "sudo modprobe -r snd-powermac" first
<bryanf> snd_powermac is still in use
<sn9> that could be your problem right there
<bryanf> ok, let me log out of GNOME... brb
<bryanf> sn9: dmasound-pmac works
<bryanf> at least the console beep works :)
<sn9> then, without rebooting, "sudo modprobe -r dmasound-pmac && sudo modprobe snd-powermac"
<bryanf> sn9: doesn't work
<sn9> you tried?
<bryanf> yup
<sn9> because on the tumbler in earlier kernels, dmasound-pmac had to be loaded and unloaded prior to snd-powermac, or the symptoms you describe would appear
<bryanf> strange
<bryanf> BenC: any clues?
<sn9> it was ubuntu-specific, too
<sn9> debian did not suffer this problem
<bryanf> wait a minute...
<bryanf> somehow the master volume control got muted...
<bryanf> it's working now
<sn9> that was the first thing i told you to check. gah!
<bryanf> :P
<bryanf> let me reboot and see if it's the dmasound thing or something else
<sn9> well?
<bryanf> ok, it's the dmasound-pmac issue
<sn9> still?
<bryanf> yup
<bryanf> I've never had that issue before
<sn9> i've had it since i first installed ubuntu on the iBook in July (breezy)
<bryanf> that's strange....
<bryanf> and there's no workaround?
<sn9> /etc/modules
<sn9> mine has the following lines:
<sn9> dmasound-pmac
<sn9> -r dmasound-pmac
<sn9> snd-powermac
<BenC> you have to load it first?
<sn9> among others
<bryanf> BenC: yup
<sn9> yes
<bryanf> BenC: maybe something's wrong with the alsa init code
<sn9> and has been for a long time
<bryanf> sn9: I've never seen that before... that's the strange thing
<BenC> try, instead, plug/unplug of the speakers
<BenC> I bet that does it too
<bryanf> BenC: plug/unplug? how do I do that with the speakers?
<sn9> funny thing is that the problem is ubuntu-specific, i.e. works the way it should on debian
<bryanf> BenC: do you mean the headphones?
<BenC> do you have external speakers or headphones?
<bryanf> yeah
<BenC> that'll work
<bryanf> I'd have to reboot to find out if that would work
<bryanf> but it's still messed up that the alsa module doesn't init the card right
<bryanf> anyway, I've gotta go back to work...
<sn9> right, and the fact that internal speakers require it is sick
<BenC> it used to be that way for me, but the rework I did seemed to fix it somehow
<BenC> was hoping it was the same for tumbler
<sn9> i thought the tumbler was the only chip that had this problem
<sn9> because it always worked fine on TiBooks
<bryanf> BenC: so, any clue as to why it's not initting correctly?
<bubbalwz> BenC: still no luck on the megaraid
<leb2005> hi for all
<leb2005> i want to change my interface of mu wireless from wlan0 to eth0 how 
<leb2005> i want to change my interface of my wireless from wlan0 to eth0 how 
<leb2005> i want to change my interface of my wireless from wlan0 to eth0 or to eth1 
<leb2005> how please 
<sn9> you mean the name of the interface?
* BenC wonders why it matters that it's wlan0
<BenC> bubbalwz: I'm out of ideas
<bubbalwz> ok, when I do the ""> new_id stuff under megaraidlegacy
<bubbalwz> i see the same messages i see when the machine boots on 2.6.10 kernel
<bubbalwz> so i know that is the right module
<bubbalwz> and the right id
<bubbalwz> i just need to figure out how to get farther
<bubbalwz> and can that ID not be added to the kernel?
<BenC> it can, yeah
<BenC> so the module loads, what does dmesg say?
<BenC> does it show the drives?
<bubbalwz> sda: asking for cache data failed
<bubbalwz> it says that when the machine boots on 2.10
<BenC> does it show the partition table?
<bubbalwz> and thats what it says once i load that module from the 2.6.12
<BenC> tried loading sd_mod?
<bubbalwz> yes, i loaded scsi_mod and sd_mod
<bubbalwz> then exited
<bubbalwz> and kernel panic
<BenC> did you check dmesg before exit to see if it showed the partition table?
<bubbalwz> nope, but i will try that
<bubbalwz> i keep seeing shit in searching about the controller being seen but not disks
<bubbalwz> http://72.14.203.104/search?q=cache:MaSOb-BO-BsJ:people.ubuntu.com/~fabbione/irclogs/ubuntu-kernel-2005-04-19.html+megaraidlegacy&hl=en&gl=us&ct=clnk&cd=3
<bubbalwz> this mentions that some ID's were lost 
<bubbalwz> this card also appears as a Netraid card
<bubbalwz> http://www.ussg.iu.edu/hypermail/linux/kernel/0503.3/0487.html
<psusi> isn't the [xxxxxxxx.yyyyyy]  that the kernel prints at the start of each line of it's output the time that the message was printed?  what format is that in?
<zul> bbl
<bubbalwz> http://www.ussg.iu.edu/hypermail/linux/kernel/0503.3/0487.html
<bubbalwz> err, sorry
<BenC> psusi: I think it's a delta actually
<BenC> ah, probably just jiffies since boot
<psusi> I thought it was jiffies since boot myself... but why don't they start the count at 0?
<psusi> I could have sworn the last time I looked at it at home, it started at 0, and was something like the number of ms since boot
<psusi> but that doesn't appear to be the case on this machine at work
<bubbalwz> BenC: do you think those URL's mean anything?
<bubbalwz> would it cause problems having both megaraid, megaraid_mm, and megaraid_mbox all in the initrd
<BenC> bubbalwz: shouldn't
<mxpxpod> BenC: any luck with the sound issue?
<sn9> he's determined that tumbler init code is still borked
<mxpxpod> heh, nice
<mxpxpod> sn9: by the way, this is bryanf 
<sn9> oh, then you know as much as i do
<mxpxpod> k
<mxpxpod> :)
<sn9> i'm still waiting for a .deb later than -13 so i can try it myself
<BenC> still waiting for you to tell me if plug/unplug of the headphones works :)
<BenC> will tell me if it's the same problem or not
<BenC> sn9: -14 is in the archive
<sn9> really? lemme check
<lmanul> BenC, Have you seen malone bug 28543 ? Desktop guys told me I should ask/harrass you about this :-p
<lmanul> Oops, no ubugtu here : https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/28543
<sn9> nope, apt still gives me -13
<lmanul> sn9, same here, but I got -14 on my amd64 box, maybe the 86 one isn't out yet ?
<sn9> powerpc here
<crimsun> http://archive.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.15/linux-image-2.6.15-14-powerpc_2.6.15-14.19_powerpc.deb
<sn9> hmm
<crimsun> apt-cache policy linux-image-2.6.15-14-powerpc
<sn9> i was going by the linux-image-powerpc metapkg
<BenC> metapkg version is pretty useless
<BenC> I'm thinking about making it match the image abi number though
<mxpxpod> BenC: I'll go check
<mxpxpod> BenC: nope, that doesn't work
<lmanul> BenC, about the above bug, is there something I can do to help diagnose th problem ?
<BenC> lmanul: https://wiki.ubuntu.com/DebuggingIRQProblems
<BenC> and please don't paste large output into bug comments anymore :)
<BenC> just attach them, it's easier to read things
<lmanul> Woops, sorry :)
<lmanul> Got it
#ubuntu-kernel 2006-02-02
<lmanul> And thanks for the link :)
<mgalvin> BenC: https://launchpad.net/bugs/28660 ... just a heads up i am in front of this machine now so let me know if there is anything you think I should try out
<BenC> the problem with dmasound workaround, I'm at a loss for right now
<lamont-away> BenC: since /etc/elilo.conf exists, the kernel postinst stops and asks if it should do that.   It needs to quit asking.
<BenC> lamont: it's that way for any loader that has to be run afterwards
<BenC> ia64 needs silent_loader=Yes in /etc/kernel-img.conf
<lamont-away> oh, is that all?
<lamont-away> which just means we need to change the creation of same...
<lamont-away> or better yet, change the default :0)
<BenC> right
<BenC> lamont__: Confirmed, I set silent_loader in /etc/kernel-img.conf and installing the kernel didn't prompt me, it just ran elilo without interaction
<lamont__> nice.
<lamont__> so how do we change the default kernel-img.conf?
<lamont__> BenC: actually, it'd be nice if breezy updates didn't prompt either... that kinda means changing the default to yes, doesn't it?
<sn9> BenC: apparently the sound problems in the dapper kernel aren't limited to snd-powermac
<BenC> emu10k is a seperate issue
<BenC> and also fixed
<sn9> damned|nb is having a similar problem with snd-hda-intel
<BenC> lamont: not sure if changing the default is right
<BenC> would affect lilo users
<BenC> sn9: similar to what, powermac?
<sn9> here's the dmesg line he pasted:
<sn9> [17:17:39]  <damned|nb> [   20.840586]  HDA Intel: probe of 0000:00:1b.0 failed with error -16
<lamont__> BenC: similar to what we did for mkinitramfs vs mkinitrd....  if arch==ia64, then set the default
<lamont__> my $silent_loader   = '';
<lamont__> $silent_loader='Yes' if ($arch eq "ia64");
<zul> heylo
<bubbalwz> BenC: after i laod the modules, you told me to run dmesg; dmesg isn't available from busybox
<bubbalwz> as soon as i exit busy box i get a kernel panic
<BenC> cat /proc/kmsg
<mxpxpod> BenC: ping
<mxpxpod> BenC: ping?
<bubbalwz> BenC: k, looks like it loads according to kmsg
<bubbalwz> megaraid detected; 1 logical drive
<bubbalwz> scsi0: LSI Logic MegaRAID
<bubbalwz> scsi device sda: 390590464
<bubbalwz>  /dev/scsi/host0/bus0/target0/lun0: p1 p2 p3
<bubbalwz>  /proc/megaraid is there, config looks good
#ubuntu-kernel 2006-02-03
<zul> heylo
<zul> BenC: that alsa emu101k patch doesnt apply cleanly
<BenC> I already pulled the PM patch
<zul> ok cool..:)
<aperry> BenC: ping ?
<BenC> aperry: pong
<aperry> BenC: is this the place to bother you with problems with snd_powermac ?
<BenC> snd_powermac will be fixed in the next kernel upload
<sn9> ETA?
<aperry> so the issue is already known to you :-)
<BenC> couple of days
<aperry> that's actually what I wanted to know :-)
<aperry> BenC: since I haven't really try to find out yet, what was the problem ? was it the fix for toonie that broke it ?
<BenC> no, it was a small problem in the conversion to platform functions
<aperry> BenC: ok. Well, thanks for your time. And your work :-)
<bubbalwz> BenC: did you see the results i posted?
<mxpxpod> BenC: ping
#ubuntu-kernel 2006-02-04
<mxpxpod> BenC: are you around?
<mgalvin> might anyone know the cleanest or proper way to bump the kernel ABI when also doing dch -i?
<mgalvin> BenC: ping?
<zul> heylo
<zul> from the sucks to be you file...some guy at work got his car stolen from the parking lot
<BenC> zul: wow, that does suck
<BenC> zul: sure it wasn't repo'd? :)
<fabbione> hey BenC 
<fabbione> BenC: can you send me your X config for the PB?
<fabbione> i can't get the touchpad up to a decent speed with the default settings
<fabbione> it's like reaaaaaaaly sloooooooooowwwww
<mxpxpod> BenC: any luck with sound?
<BenC> fabbione: neither can I
<BenC> mxpxpod: not yet
<mxpxpod> BenC: I found something else out... if I have ifup'ed the AE, then ifdown it and try to suspend without removing the bcm43xx module, my ibook freezes when it tries to wake up
<BenC> interesting
<mxpxpod> BenC: yeah, I thought so too
<BenC> I have ifdown in my suspend script, and ifup in my resume script
<BenC> haven't noticed that problem
<BenC> but bcm43xx is still experi., so I expect it to be like that
<mxpxpod> BenC: also, using the module you gave me (and after doing a modprobe dmasound-pmac && modprobe -r dmasound-pmac && insmod ~/Desktop/snd-powermac-2.ko), if I return from sleep, I have to change the volume before sound works again
<mxpxpod> BenC: same here ;)... just letting you know
* lamont-work flushes the backlog of list email... sorry for any dups and stale and such
<zul> lovely...i work in a high crime wave area
* lamont-work flushes kernel-bugs, curses at malone, and screams "INCOMING!!!"
<lamont-work> seems that malone is preserving the originator's email addr when forwarding to kernel-bugs --> lots and lots of 'mail from non-subscriber' holds
<lamont-work> unlike kernel-team, the bulk of the messages on kernel bugs were actual maiul
<mgalvin> does anyone know the proper way to deal with or bump the abi after a dch -i to allow a clean compile of an updated kernel package, the wiki is not quite accurate for dapper?
<zul> Benc: arrgh...stop spamming my email ;0
<zul> hey mdz 
<mdz> good morning
<lamont-work> hrm... 2.6.15-14 Conflicts with 2.6.12-9?
<lamont-work> or am I just misreading things...
<lamont-work> that is, the dist-upgrade screeched to a halt asking if I _really_ wanted to remove the running kernel and waited for input... this would be bad in a synaptic upgrade on grandma's computer.
<lamont-work> or maybe it's just hppa that does that...
<sn9> i kept wondering how is was that other ppl in the channel were able to get -14 from apt and i wasn't. it turns out i kept forgetting to specify "-t dapper" to apt-get
#ubuntu-kernel 2006-02-05
<lamont> RAMDISK driver initialized: 16 RAM disks of 65536K size 1024 blocksize
<lamont> mice: PS/2 mouse device common for all mice
<lamont> Unable to handle kernel NULL pointer dereference (address 00000000000004c8)
<lamont> swapper[1] : Oops 11012296146944 [1] 
<lamont> Modules linked in:
<lamont> hrm..
<zul> heylo
<zul> BenC: i should have something for you tonight
<BenC> zul: ok
<zul> sorry for being late ;)
<mjg59> BenC: We still don't have the 8180 drivers - do you want a patch at some point?
<zul> for the wireless driver? we tried previously but the ones we used were crap
<zul> i got an email from some guy saying that the cvs ones were working fine  though..
<mjg59> zul: Yeah, the CVS ones
<BenC> mjg59: I can try looking at them today
<zul> or i can do it when i get home
<zul> its up to you guys..
<fabbione> hey BenC 
<zul> hey fabbione 
<fabbione> hey zul
<fabbione> BenC: do you think you can merge http://people.ubuntu.com/~fabbione/qc-usb-messenger-1.1.tar.gz into the quickcam driver?
<fabbione> BenC: i did try but didn't exactly suceed
<fabbione> success
<fabbione> if you can't .. no big deal
<BenC> sure, I can give it a go
<fabbione> thanks
<fabbione> i have the hw to test the merged bits, but not the standard once
<fabbione> ones
<fabbione> (i can't type today)
<fabbione> brb
<zul> mjg59: do you have the hardware to test the rt8180?
<mjg59> Christ no
<zul> meh...ok
<Lathiat> BenC: ping
<Lathiat> BenC: every had a look at the orinoco scanning patch? would be usefull so it had good network-manager support
<BenC> yeah, I did
<BenC> last I checked it didn't apply to the tree, IIRC
<Lathiat> http://www.projectiwear.org/~plasmahh/orinoco.html is the patch i tend to use
<Lathiat> last updated to 2.6.14-rc5
<sn9> DO NOT INCLUDE THAT PATCH
<Lathiat> oops i got someone fired up already :)
<Lathiat> sn9: why not?
<sn9> it is only for older kernels
<sn9> the current dapper kernel works unpatched
<Lathiat> oh you know im an idiot when i just tested it
<Lathiat> i put it in my breezy laptop
<Lathiat> duh
* Lathiat tries in his other laptop
<Lathiat> baha, ok, it works
<Lathiat> sorry ;)
<Lathiat> i wonder if that means its in 2.6.15, if so, cool
<sn9> it's in the newer orinoco drivers that are in dapper
<sn9> BUT:
<Lathiat> did monitor go in too?
<Lathiat> hrm, maybe not, still scan is cool.
<BenC> I think I merged monitor support
<sn9> you must include "orinoco force_monitor=1" in /etc/modules prior to "airport"
<Lathiat> ...
<Lathiat> airport?
<Lathiat> not everything uses the airport part :)
<Lathiat> but right
<Lathiat> ok
<sn9> if you load that module
<sn9> if not, just that line then
<Lathiat> hah, that doesnt work so wel
<sn9> some cards will lock up in monitor mode, too
<Lathiat> mine has worked in the past with the above url patches but yeh
<sn9> firmware downgrades for DOS are still to be found on the 'net
<bryan__> BenC: ping
<BenC> bryan__: pong
<bryanf> BenC: I don't mean to be a bother, but how comes sound?
<bryanf> BenC: if you have any modules for me to test, let me know
<zul> ooh...my rt2600 thingy works
#ubuntu-kernel 2007-01-29
<illusina> Hi, I'm trying to compile a 2.6.19 kernel with the realtime patches applied (as instructed at https://help.ubuntu.com/community/HowToVanillaKernelWithRealtimePreemption)
<illusina> However, after about 20 minutes of building, it errors out with WARNING: "pm_send_all" [arch/i386/kernel/apm.ko]  undefined! WARNING: "pm_active" [arch/i386/kernel/apm.ko]  undefined!
<illusina> Full error message at http://rafb.net/p/9YM0Op33.html
<illusina> I am running ubuntu edgy eft, currently running: 2.6.17-10-generic #2 SMP Tue Dec 5 22:28:26 UTC 2006 i686 GNU/Linux
<_MMA_> illusina: There are low latency kernels in Feisty you can use. Thought this doesnt help with your current situation. This channel isnt for support either.
<mjg59> illusina: Warnings don't stop compilation
<BenC> mjg59: The missing symbol warnings in modules do error out now
<BenC> and prevents the module link step
<BenC> illusina: But the basic answer is that this channel is for ubuntu kernel development, and stock build questions are better asked in more general forums
<pschulz01_> BenC: Is there anything particular you need help with at the moment?
<BenC> pshulz: bug triaging
<BenC> pschulz01: ^^
<pschulz01_> BenC: Ta.. 
<BenC> there's wiki pages on how to help
<zul> hey
<illusina> BenC: thank you for the input, I will find somewhere else to post this question
<okaratas> http://www.ozgurkaratas.com/doc/Ubuntu_Sunucu_Rehberi.pdf
<okaratas> i writing ubuntu server turkish guide..
<Mithrandir> zul: xen-3.0 ftbfs; if you could please test-build before uploading, that'd be useful.
<tepsipakki> oh great.. the Fujitsu Esprimo I've been trying to get to work.. almost all of the devices listed by lspci are marked as "unknown device"
<tepsipakki> this is with dapper
<pschulz01> tepsipakki: You can get a more up to date data file.
<pschulz01> tepsipakki: looking..
<pschulz01> tepsipakki: See the 'update-pciids' in the 'pciutils' package.
<tepsipakki> pschulz01: thanks.. that did the trick :)
<tepsipakki> anyway, I can't get the X driver to work, but that's OT here
<zul> hey
<kylem> BenC, ping?
<BenC> kylem: pong
<kylem> nm. :)
<kylem> oh, right, i recall now.
<kylem> we have a wishlist bug for the nozomi external driver. there's a cleaned up version in -mm, so i'll merge and track that.
<BenC> kylem: Ah, ok
<BenC> Mithrandir: ping
<Mithrandir> BenC: You sent me a contentless ping.  This is a contentless pong.  Please provide a bit of information about what you want and I will respond when I am around.
<zul> hah..
<BenC> Mithrandir: ping with content
<BenC> Mithrandir: mainly want to know about deadline for kernel upload to get into Herd 3
<zul> gah...redhat bite me
<zul> er...whats the point of that ppc config to the kernel-team mialing list?
<kylem> no clue, i just approved it since it was obviously not spam.
<Mithrandir> BenC: if you can have it in in ~12 hours, that'd be good.
<BenC> Mithrandir: I think I can handle that
<Mithrandir> thanks
<BenC> let me run through a build/boot cycle
<BenC> Mithrandir: be warned, it's an ABI bump
<BenC> so lrm and linux-meta to follow
<Mithrandir> sure, that's not hard.
#ubuntu-kernel 2007-01-30
<Mithrandir> BenC: did you drop the planned kernel upload?
<poningru> hi anyone alive?
<TheMuso> c
<poningru> is there a possibility of getting this module uploaded http://www.promise.com/support/download/download2_eng.asp?productId=139&category=driver&os=3&go=GO#
<poningru> TheMuso: I am having the hardest time getting it built
<poningru> cause they have a weird ass makefile
<TheMuso> poningru: Sorry dude, didn't mean to do that. KVM and speakup like doing funny things with each other
<poningru> blargh?
<mjg59> Why is sata_promise.ko not adequate?
<mjg59> poningru: Given that there's an in-kernel driver for the hardware already, it's unlikely that we'll include it. Why do you want it?
<poningru> mjg59: that module is apparently causing troubles
<mjg59> poningru: Which one, and where?
<poningru> sorry sata_promise.ko
<mjg59> Got a bug number?
<poningru> nope about to file one ;)
<mjg59> Ok, based on reading that driver, there's no real chance of us including it
<poningru> hmm k
<mjg59> It seems to hook straight into the scsi layer
<mjg59> Rather than using libata
<poningru> hmm ic
<poningru> http://lwn.net/Articles/122289/ thats the patch that created support for this device back in 2.6.11
<poningru> atleast in this hardware config sata_promise.ko is failing
<poningru> so I have to test out couple of other hardware configs to make sure
<poningru> the big prob is this box is an old ass dell optiplexx
<mjg59> In what way is it failing?
<poningru> just wont boot even if just the pci card is plugged in and the hdd is plugged directly into the mobo's ide controller
<mjg59> Won't boot in what way?
<poningru> yeah let me copy the logs hold on
<mjg59> Thanks
<poningru> err do you know which logs I should look under?
<poningru> /var/log/dmesg* hasnt turned up anything
<poningru> mjg59^^
<mjg59> poningru: If the system is alive when it stops booting, /var/log/kern.log is probably the best bet
<mjg59> Otherwise you're going to have to copy them down by hand
<poningru> frack
<poningru> ok let me do that then
<poningru> mjg59: ok well the last thing is this: udevd-event[1772] :run-program:'/sbin/modprobe' abnormal exit
<poningru> right before this there is a huge stack trace
<poningru> mentioning everything from libata and sata_promise to mem pointers
<poningru> hmm you know what hold on let me see if I can put it on my camera phone
<poningru> mjg59: well it drops me down to the busybox cli after a while
<poningru> is there anything I can run in this that will show anything useful?
<poningru> mjg59: http://img220.imageshack.us/img220/9712/0130070621wp0.jpg
<poningru> http://img219.imageshack.us/img219/1164/0130070622rb0.jpg
<poningru> let me know if you want to see more screencaps
<mjg59> poningru: Which version of Ubuntu is this?
<poningru> feisty
<mjg59> Ok
<poningru> grabbed the cdimage like 2 days ago
<mjg59> I suspect that it's related to https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/78224
<poningru> ah hmm
<poningru> well mine is a bit different
<mjg59> If you could boot without the splash and quiet options, and add vga=ask then choose the 80x50 mode, you ought to be able to get more of it
<poningru> ooh ok
<mjg59> Alternatively, if it drops you to busybox, does shift+pageup work?
<poningru> doh
<poningru> let me try both
<poningru> hold on
<poningru> the vga option and shift+pageup worked
<poningru> let me grab some better screenies then
<poningru> yeah nm its almost word for word what that bug shows
<poningru> except ofcourse the other hardware modules
<mjg59> The important bit is what the "EIP is at" line says
<poningru> EIP is at pdc_port_start+0x96/0xc0 [sata promise] 
<mjg59> Ok
<poningru> btw this bug is in sarge, etch and edgy 
<mjg59> Heh
<mjg59> So probably upstream
<poningru> yeah
<poningru> I was going to try a vanilla but never got around to it
<mjg59> Interesting. It's not entirely clear where it's failing.
<mjg59> Anyway. Can you follow up to that bug, stick the "EIP is at" line there as well, and mention the precise kernel version you have installed?
<poningru> yep
<poningru> btw thanks for helping with this
<poningru> I was confoozled for a while with this
<mjg59> No problem
<mjg59> We'l try to get that fixed
<poningru> thanks :)
<poningru> done 
<zul> hiho
<Mithrandir> zul: did you seem my prod about xen-3.0 FTBFS-ing?
<zul> when?
<zul> the xentop issue in -4?
<zul> yeah fixed in -5 :)
<Mithrandir> good
<BenC> Mithrandir: can I still upload kernel now?
<BenC> fell asleep last night while builds were finishing
<BenC> but it's ready
<kylem> BenC, i think feisty is frozen atm.
<BenC> kylem: that's why I'm asking the freezer for an exception :)
<kylem> hehe
<Mithrandir> BenC: ok, go ahead.
<BenC> Mithrandir: bombs away
<Mithrandir> thanks
<mjg59> BenC: Why do we build prism2_cs?
<BenC> mjg59: For some people, it works better than the alternative
<mjg59> BenC: Here, it doesn't work at all
<mjg59> Despite me having an entirely normal prism 2 card...
<BenC> does hostap_cs work?
<mjg59> Yup
<BenC> is there conflicting PCI id's in them? If so, I can disable them in prism2_cs
<mjg59> It's not PCI
<BenC> or you can just wait on the driver-manager to select the one you want :)
<BenC> I thought PCMCIA used PCI id's of sorts
<mjg59> But yes, there are going to be conflicting IDs - prism2_cs and hostap_cs should drive the same hardware
<BenC> I thougth I cleaned out the ones in prism2 that hostap had
<mjg59> Similar, but PCMCIA is effectively ISA
<mjg59> BenC: I suspect it's matching on some subdevice thing
<mjg59> PCMCIA_DEVICE_PROD_ID123("D",  "Link DWL-650 11Mbps WLAN Card",  "Versi\
<mjg59> on 01.02", 0x71b18589, 0xb6f1b0ab, 0x4b74baa0), // D-Link DWL-650 11Mbps 802.11\
<mjg59> b WLAN Card
<mjg59> That's binding from prism2_cs
<mjg59> Are you sure there were people that found prism2_cs to work better? prism2_pci I could believe.
<mjg59> Oh, it's loaded orinoco_cs as well
<mjg59> This is something of a mess...
<BenC> Yeah, for most of edgy, I had prism2_cs disabled because it wouldn't compile in .17, and sufficient numbers of folks complained about hostap_cs not working to get me to fix it
<mjg59> Got a bug number?
<BenC> let me check the change log
<mjg59> Actually, it's using orinoco_cs
<BenC> so it's not prism2_cs, or it's not hostap_cs?
<BenC> I found what I think was the bug, but it mainly mentions prism2_usb
<BenC> at least it was the bug that prompted me to fix things
<mjg59> By default, prism2_cs binds and nothing works
<mjg59> Yeah, prism2_usb is a reasonable choice
<mjg59> I don't think prism2_cs is
<BenC> wasn' the first mention of it (I rejected any bugs dealing with it before that)
<fabbione> kylem: 81782 is an easy one.. tho i don't think we will rebuild d-i or cdimages for it
<fabbione> kylem: might be still good to get the kernel in case cjwatson decides to upload a new d-i (at least we can get netboot/netinstall to work)
<Mithrandir> we'll need a new d-i once the new kernel is in, yes.
<fabbione> Mithrandir: yeah but that's edgy...
<BenC> mjg59: Disabled prism2_cs in git
<mjg59> BenC: Ta
<Mithrandir> BenC: lrm accepted
<BenC> Mithrandir: I'll wait to make sure linux-image and lrm build ok before uploading linux-meta
<Mithrandir> BenC: thanks.  linux-image will need NEW processing and I'm leaving for the movies in about an hour, so if they're done before I'm back, either get another archive admin to process them or wait for me to do it (at about 21 UTC, I suspect)
<BenC> Mithrandir: ok, thanks
<BenC> Mithrandir: how's the weather there since we left?
<Mithrandir> BenC: slightly warmer and a bit more snow.  So it's nice.
<BenC> Miss it already...Oslo was a nice place
<Mithrandir> it's a lovely place. :-)
<zul> BenC: yeah kernel-package is crap
<pinskian> hi
<Mithrandir> kylem: you don't happen to know anything about the LSI 1068 RAID controller in Dapper, do you?  It's supposedly supported, but not with hardware raid activated.
<Mithrandir> it's also supposedly fixed in 2.6.16.
<kylem> it sounds familiar.
<Mithrandir> I don't have a machine yet, but I'd be very interested in getting it fixed in dapper, if that'd not too big of a backport.
<kylem> i'm struggling to remember what the problem is. does it use the cciss driver?
<Mithrandir> https://launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/37452 is the same bug, it seems
<Mithrandir> so yes, it seems like you've committed a fix for it.
<kylem> woo. go me. :)
<kylem> oh. no, it doesn't work right yet. 
<kylem> i don't have hw to test, and no one has identified which patches fix it.
<Mithrandir> I'll get hardware to test it on in a couple of weeks, then
<kylem> so i guessed, and wrong.
<Mithrandir> well, as long as there exists _some_ fix for it, I'll be able to find out which.
* Mithrandir urges the i386 kernel to finish building so he can go to bed.
#ubuntu-kernel 2007-01-31
<zul> whee..
<kylem> woohoo. killed my email backlog.
<kylem> now i can go back to reading bugs.
<infinity> Ooo, can you do my email next?
<infinity> I have unread mail from ~3 years ago.
<kylem> damn, chief.
<kylem> i have this phobia of unread email
<infinity> I fear it so much that I never read it, which may explain the above.
<kylem> haha.
<kylem> so is launchpad ever going to stop having baltix as the default distribution?
<kylem> it's really starting to annoy me. :)
<infinity> It's alphabetical.
<infinity> We've requested many times to get Ubuntu at the top of the list.
<infinity> Sort of like all the online shops with "USA, Argentina, Aruba..."
<infinity> Perhaps just renaming the distro to Abuntu would be easier.
<kylem> haha.
<Mithrandir> BenC: lrm ftbfs.
<Mithrandir> FATAL: modpost: GPL-incompatible module ath_hal.ko uses GPL-only symbol 'paravirt_ops'
<mjg59> Winning.
<Mithrandir> you can't call udelay or ndelay if the kernel's built with paravirt..
<Mithrandir> winn0r.
<Mithrandir> this only hits i386, for additional fun.
<mjg59> Non-free modules can't call udelay if the kernel's built with paravirt?
<mjg59> Superb.
<Mithrandir> indeed.
<mjg59> In that case, I think we lose.
<Mithrandir> we can make it work as long as you're not using paravirt, can't we?
<mjg59> Is madwifi the only problem, or is that just where it bailed?
<Mithrandir> unsure, I haven't tried the rest.
<mjg59> I haven't looked at the implementation
<Mithrandir> it has a #define which is used in the case where PARAVIRT isn't defined
<mjg59> Ok, so paravirt_ops gets rewritten on boot if you're not running virtualised
<Mithrandir> I don't have any madwifi hardware to test, though
<mjg59> So I /think/ we can get away without it
<mjg59> Mithrandir: I guess the easiest way to test would just be to badger lrm to #undef CONFIG_PARAVIRT
<Mithrandir> yeah, my thought too
<mjg59> And see what explodes
<mjg59> Mithrandir: Oh, mdelay is just a wrapper around udelay. So it'll be bitten too.
<Mithrandir> it blew up differently (slow_down_io being defined in both paravirt.h and io.h)
<Mithrandir> how bad would it be to not build madwifi?
<mjg59> Mithrandir: I think people would be unhappy
<mjg59> Why is paravirt.h getting included?
<Mithrandir> io.h includes it, amongst other things.  I could try disabling CONFIG_PARAVIRT across the board, though
<mjg59> Ah, yeah, that was what I meant
<Mithrandir> mmm, big hammer applied.
* Mithrandir does a full build of the package.
<fabbione> Mithrandir: hopefully it won't trash the ABI again
<Mithrandir> uh, why would it?  It's lrm
<fabbione> oh ok
<cjwatson> devicescape is switchable on a per-driver basis, isn't it?
<cjwatson> if we merge it
<Mithrandir> oh, fun, same problem with ltmodem
<Mithrandir> BenC: this needs to be solved ASAP after herd 3, I'm just kludging around it for now.
<mjg59> cjwatson: Yes
<cjwatson> mjg59: do you know specifics of driver status with devicescape?
<cjwatson> like, which ones are a significant improvement over ieee80211
<mjg59> bcm43xx ought to be
<mjg59> Well, frankly, all of them ought to be
<mjg59> With the possible exception of zd1211rw
<Mithrandir> oh, and fglrx too.  Win
<cjwatson> BenC: did you merge the iSight and Apple Remote patches from mjg59? I don't see them in the changelog
<Mithrandir> .. and nvidia.
<mjg59> Mithrandir: Unsurprising
<Mithrandir> mjg59: really annoying nevertheless.
<Mithrandir> I just hope this'll work.
<fabbione> Mithrandir: i can test nvidia here if you want me to before upload
<fabbione> just hand me some -generic i386.deb
<Mithrandir> I just need to make it build first, but thanks.
<BenC> cjwatson: It's in my local tree only
<BenC> cjwatson: you have a powerbook, right?
<BenC> because I'm gonna need this tree tested with the new bcm43xx devicescape based driver
<mjg59> The dscape bcm43xx driver needs different firmware to the softmac one
<cjwatson> BenC: sure, given a binary
<BenC> mjg59: Are you serious?
<cjwatson> mjg59: huh? as in, not fwcutter?
<mjg59> fwcutter, but it needs version 4 firmware
<kylem> BenC, yeah, v4 firmware.
<BenC> so not different, just new enough
<cjwatson> how do I tell if the stuff I have in /lib/firmware/ in v4?
<cjwatson> s/in v4/is v4/
<mjg59> softmac doesn't work with v4 firmware
<mjg59> So
<Mithrandir> BenC: have you seen my rants in backlog about the paravirt_ops being marked as GPL-only?
<BenC> Mithrandir: Yeah
<Mithrandir> can you lart upstream about it?
<Mithrandir> (please)
<kylem> uh, this should havebeen fixed.
<mjg59> Mithrandir: I can't imagine that changing
<BenC> paravirt_ops is being split into paravirt_ops and paravirt_module_ops
<BenC> just to fix this
<mjg59> Oh, right
<mjg59> That's handy
<kylem> http://lwn.net/Articles/216636/
<Mithrandir> that'd make me happy, yes.
<Mithrandir> BenC: do you think just undef-ing it all over the lrm tree will allow the modules to work correctly (as long as you're not using paravirt) or will it just blow up?
<BenC> Mithrandir: no, that wont fix it
<BenC> it'll fail at module load time
<Mithrandir> is there a workaround which is quicker than "new kernel"?
<BenC> nope :/
<Mithrandir> can you give me a new kernel, like, now?
<BenC> like "now", I have to take the kids to the bus stop...so give me 10 minutes
<Mithrandir> ok
<Mithrandir> with either paravirt disabled or that fix from Ingo or something. :-)
<Mithrandir> thanks.
* Mithrandir gently prods BenC
<BenC> Mithrandir: ok, working on it now
<Mithrandir> thanks.
<BenC> I like Rusty's patch better
* kylem is worried neither of those got merged for 2.6.20...
<BenC> Nope, they didn't
<kylem> fuck.
<Mithrandir> could we just back out the paravirt stuff for herd 3 and reintroduce it later?
<kylem> ah well, rusty's diff is pretty small.
<BenC> Mithrandir: Either way will take me the same amount of time
<Mithrandir> BenC: ok
<BenC> plus I made some loose guarantee's that it would be enabled for various testing purposes
<kylem> lrm has the new madwifi, right?
<BenC> it has 0.9.2.1...the "new" madwifi wouldn't compile
<BenC> so no, it isn't fixed yet
<BenC> but I can do that post Herd 3 without a kernel upload
<kylem> ok.
* kylem was going through bugs.
<cjwatson> BenC: Scott says Ian has already uploaded the udev pieces needed for driver-device-manager - are you aware of that?
<Keybuk> err?
<Keybuk> sorry, I got confused
<Keybuk> it doesn't need the udev pieces anyway?
<cjwatson> Ben thought it did
<Keybuk> I can categorically say that the udev pieces won't make it for feisty :p
<cjwatson> and I don't think it can meaningfully progress until drivers aren't bound by default, otherwise the UI ain't gonna do much
<Keybuk> because I have no intention of doing them until the *start* of a release process, given the big change
<cjwatson> thanks for telling us so early :-P
<Keybuk> there appears to be some confusion :p
<cjwatson> can you and Ben actually talk to each other about this please
<Keybuk> the spec doesn't refer at all to the udev changes we've discussed
<cjwatson> "The kernel currently has no mechanism to stop from binding a device to an already loaded driver. Upstream suggests unbinding after noticing this, and binding to the preferred driver. This is not ideal, and is the portion that is likely to require kernel changes."
<cjwatson> the udev changes are the resolution of that
<Keybuk> right
<Keybuk> but the sentence includes an "in the meantime"
<cjwatson> my understanding from talking to Ben was that he had expected the udev change to be done, and was writing code based on that assumption
<Keybuk> the udev change relies on a very experimental patch to integrate modprobe into udev
<BenC> cjwatson: Had no idea
<Keybuk> as well as one of our own
<BenC> cjwatson: is that udev in Herd3?
<Keybuk> I hadn't planned it for feisty at all, which is why there wasn't a spec for it
<BenC> cjwatson: Because this may be a hell of a test round if it is in udev and enabled
<BenC> Mithrandir: In the interest of time, I'm uploading without a build-test, and building while the buildd's do
<BenC> Mithrandir: so if there's a build failure, I'll have a quick fix
<Mithrandir> BenC: cheers.
<BenC> I don't forsee a problem though
<Mithrandir> tell me when it's uploaded.
<cjwatson> BenC: no, it is not, as Keybuk says
<BenC> ok
<cjwatson> BenC: when I first came here Keybuk had confused driver-device-manager and udev-device-mapper
<cjwatson> BenC: but in any case, in Oslo you seemed to think that udev no-autobinding was going to land, and now apparently it isn't
<BenC> cjwatson: No, I had no idea whether the udev parts would or not, since Ian taking over udev was even news to me :)
<BenC> the kernel part is done and will be in Herd 3
<BenC> Mithrandir: fire in the hole
<Mithrandir> BenC: cheers
<Keybuk> Ian isn't taking over udev?
<Keybuk> he's taken over the bits that touch things like lvm, evms, etc.
<BenC> Keybuk: Maybe we could use a "state of the udev address"
<BenC> I've no idea what's going on with it
<Keybuk> not much :)
<Keybuk> in theory, it just maintains itself now; unless we want to make changes to it
<Keybuk> it needs someone to keep up with the rules changes, etc.
<Keybuk> I'd figured it'd make the most sense to be under the kernel team, as it's tightly coupled to the kernel
<Keybuk> it needs a gentle hand, one who can say "no!" to any request for adding "/dev/mylittlepony"
<zul> hi
<kylem> morning.
<Mithrandir> Keybuk: what about /dev/ponies/woody ?
<zul> how is going kylem 
<kylem> dude. mylittlepony is awesome.
<Keybuk> definitely no /dev/ponies
<kylem> OMG PONIESS?!!?
<Keybuk> you can have /dev/pony0, provided the kernel has a pony subsystem :p
<kylem> zul, it's fucking cold. i want to go back to oslo.
<zul> kylem: heh
<Mithrandir> echo hay > /dev/ponies/woody
<zul> kylem: it was colder last week
<kylem> suck.
<zul> -24 at one point
<BenC> I got ENOENT on /dev/pony0
<BenC> I think the driver is busted
<kylem> file a bug.
<kylem> :)
<BenC> Assign it to Kurt I guess
<kylem> haha.
* kylem whacks L"Kyle" on his bugs mailbox and starts to make good on some promises from last night.
* Mithrandir notes that the kernel is just too big
<kylem> oo is bigger i think
<Mithrandir> I don't run mdebdiff on that too often
<kylem> maybe you should. :P
<Mithrandir> anyway, accepted
* Mithrandir goes to kick the publisher
<BenC> Mithrandir: thanks
<cjwatson> BenC: please let me know how much extra work it will be in the d-d-m UI to account for udev not disabling auto-binding
<BenC> cjwatson: will this feature not make it into feisty at all?
<BenC> because not having the udev changes doesn't make it difficult, it makes it impossible
<BenC> kills driver-backports too
<cjwatson> the spec says "Upstream suggests unbinding after noticing this, and binding to the preferred driver
<cjwatson> "
<cjwatson> is that definitely not a viable workaround?
<BenC> cjwatson: Not safe..in the case of ide drivers, you cannot unload or unbind
<cjwatson> I don't think it would kill driver-backports, just limit its scope?
<BenC> it would limit driver-backports to hot having updated drivers, just new ones
<BenC> cjwatson: If the case of other drivers, binding, unbinding and rebinding to a new driver can have unexpected results that I'd rather not try to find out about
<BenC> s/If/In/
<cjwatson> can *anything* useful be done with d-d-m without that? like module options?
<Keybuk> I'm happy for Ben to take over implementation of the udev side
<mjg59> Every module could be hacked and refuse to bind unless passed a magic option
<mjg59> But, uh.
<Keybuk> I can forward him the modprobe patch which it can be built on
<cjwatson> that seems sensible
<cjwatson> BenC: driver-backports would work fine even without d-d-m for updated drivers, surely, as long as the backported driver were deterministically installed
<cjwatson> BenC: and as long as the backports package *isn't* installed on every system
<BenC> cjwatson: Yeah, but deterministically means relying on undocumented ordering, or modprobe patching to prefer a subdir, which we can do
<cjwatson> s/deterministically installed/deterministically used/
<cjwatson> modprobe already prefers /updates
<cjwatson> we can and should use that
<BenC> is that on purpose or by accident? :)
<cjwatson> that was done by SuSE for essentially the same purpose as we propose
<BenC> ah, then yeah, driver-backports is ok
<cjwatson> there's enough code in there for it that it's clearly on purpose
<BenC> d-d-m is likely to just do module ops and create modrobe.d files
<cjwatson> sorry, RH, not SuSE
<BenC> s/ops/params/
<cjwatson> changelog says
<cjwatson> o depmod: updates/ dir overrides (for RH, thanks to Thomas Vander Stichele)
<cjwatson> BenC: can we move forward with driver-backports with that approach RSN then?
<cjwatson> I'd like you to get your other items out of the way before sinking lots of time into udev changes which may turn out to be too risky to land
<cjwatson> BenC: same for ubiquity-driver-updates
<cjwatson> BenC: I think at this point it is probably safest to accept that driver-device-manager needs to be feisty+1 and do the other work without reference to it, then have d-d-m ready to land first thing in feisty+1
<BenC> cjwatson: Makes sense to me
<BenC> d-d-m is only slightly useful without the udev parts
<cjwatson> BenC: do you think those two can make FF (with Kyle's help if necessary)?
<cjwatson> they're both important so can slip a bit if need be, but I'd rather they could land
<cjwatson> (as I said, the vendor process doesn't need to be there for FF)
<BenC> driver-backports just needs an upload
<cjwatson> ok
<BenC> ubiquity can be done pretty easily from my side, if you are doing the ubiquity parts
<cjwatson> there are no ubiquity parts
<cjwatson> the spec is misnamed because it assumed the implementation before we worked out how it would work
<BenC> ah, right, ok, then even less work :)
<cjwatson> actually, no, sorry, that's not true
<BenC> I thought we passed an option so the initramfs asked for the drivers or something
<cjwatson> there are some things that need to be done by ubiquity, but actually they'll probably be done by casper hooks
<BenC> ubiquity needs to make sure it copies them over
<cjwatson> right, that will be a casper hook
<BenC> ok
<cjwatson> but same difference I guess
<BenC> I can have all that done before Herd 4
<cjwatson> it is not entirely clear that I will have time to do the casper work, but I'll work that out and delegate if need be
<BenC> ok
<mdz> BenC,cjwatson: should we talk this out by phone?
<cjwatson> maybe, but perhaps not right now
<BenC> yeah, maybe reread the spec and make sure I got everything right
<Mithrandir> BenC: ftbfs, due to missing ABI thang.
<BenC> doh
<Mithrandir> care to fix?
<BenC> Mithrandir: fixed and uploaded
<Mithrandir> thanks
<BenC> np
<Mithrandir> BenC: uh, how does that fix it?
<Mithrandir> or does the ABI checker read the changelog?
<BenC> it reads the changelog
<Mithrandir> ok
<Mithrandir> accepted
<Mithrandir> BenC: http://librarian.launchpad.net/6012650/buildlog_ubuntu-feisty-i386.linux-source-2.6.20_2.6.20-6.10_FAILEDTOBUILD.txt.gz ; ftbfs
<BenC> yeah, looks like the best thing is just to make paravirt_ops no a GPL export for this upload
<BenC> take out the patch, doing that now
<Mithrandir> thanks
<mjg59> BenC: Uhm.
<mjg59> BenC: Is that a change that's been made upstream?
<BenC> mjg59: No, but it's temporary
<mjg59> If not, I think we're in murky legal waters.
<kylem> not really. the tenuous nature is if a vendor ships a patch which changes an export, they're acknowledging it's a derived work.
<BenC> it used to be just EXPORT_SYMBOL, so I could claim that at one point it wasn't _GPL only :)
<mjg59> While clearly the GPL allows us to change the symbol name, it implies that the modules we ship are derived works
<mjg59> Well, implies more strongly than would otherwise be the case
<kylem> heh, i found it hard to believe a court would rule that some other companies code is a derived work because an unrelated linux distro changed an export.
<BenC> the case could be made that changing a config option should make the same source bind differently to the GPL or not
<mjg59> kylem: The work is the combination of the other company's code and the GPLed kernel code
<BenC> shoudn't
<kylem> the legal onus isn't on us...
<mjg59> kylem: When we're shipping the work, it is
<mjg59> module+EXPORT_SYMBOL_GPL = GPL (in theory)
<mjg59> If we can't provide the source, we're not permitted to distribute the work
<BenC> a) The symbol recently changed, so one could easily claim we are using the old version, b) it's temporary, and c) I don't think we are functionally different than with the paravirt-mod-op patch
<kylem> that's not really the case since there's no precedent.
<mjg59> BenC: I understand that there's a reasonable technical argument
<mjg59> But I'm unhappy about setting a precedent where we'll s/_GPL// in order to get non-free drivers linking
<BenC> mjg59: But I do understand your argument
<mjg59> Even if it is temporary
<kylem> i'm moderately amused they were allowed to change it by linus. i guess since paravirt being EXPORT_SYMBOL() never made it into a real kernel release...
<mjg59> Given the alternatives, I think it would make more sense to just disable paravirt for this herd release
<kylem> if my laptop wasn't utterly unusuable atm because i'm pruning and repacking ten gig of git trees, i'd try to argue more, but given it's utterly noninteractive.
<mjg59> That way we're unarguably in the clear
<kylem> er.
<kylem> BenC, that's an easy fix to make.
<mjg59> And we can fix it in time for the next upload
<kylem> oh. you didn't push.
<BenC> urg
<BenC> I don't want to disable paravirt
<zul> http://ozlabs.org/~rusty/paravirt/?cs=cac1791e2d5f
* kylem hits chuck.
<kylem> look at the timestamp.
<zul> meh...ill g o back to work then :P
<kylem> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0dbe5a111382fd1320ff4b1d889e5b8c41290619;hp=a517b9f9fe8e57437b0b9b50e279220aaf651268
<Mithrandir> kylem: since clearly, one sha1 hash in the url isn't enough. :-P
<kylem> meh.
<lifeless> yknow, linus is clcearly right. thts so much simpler than 'http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=1023;hp=1025
<kylem> i rightclick, and i hit "open link" what's so hard about that?
<BenC> Mithrandir: uploaded
<lifeless> didn't say 'hard' ;). said simple.
* kylem notes lifeless must be a masochist who writes out links by hand.
<kylem> :)
<BenC> according to that commit, it sounds like the intention of _GPL is just to keep it local until the API settles
<Mithrandir> BenC: let's hope it builds fine this time around.
<mjg59> BenC: Ok, I'll go with that
<zul> meh..
<psusi> what is the internal buffer size used for pipes?  I seem to remember hearing it was only 4k on lkml at some point...
<Mithrandir> building looks good so far.  I'm hoping it'll be good.
<sioux> hi
<sioux> what's this story about multimedia kernel?
<TheMuso> sioux: There is a low latency kernel for Feisty, but afaik it isn't officially supported.
<Mithrandir> it's in universe, yes
<BenC> Mithrandir: Have you tried pushing LRM for i386 back through?
<Mithrandir> no, since the i386 kernel isn't published yet
<Mithrandir> BenC: the ABI should have been stable between all those builds, right?
<kylem> doubtful given he was mucking with exported symbols...
<Mithrandir> well, that should only have affected i386.
<Mithrandir> Let's hope that's true.
<kylem> heh.
<kylem> indeed.
#ubuntu-kernel 2007-02-01
<zul> mmm...beer..
<BenC> Mithrandir: Between the first and last yes
<Mithrandir> goodie
* Nafallo 2&1> bed
<poningru> guys writing the herd 3 release notes
<poningru> any suggestion I can put under kernel?
<poningru> so no one??
<crimsun> try the changelog.
<poningru> looking at it
<poningru> seems just like bug fixes
<poningru> nothing big that can be 'featured'
<crimsun> "just" is an understatement.
<poningru> oh ofcourse
<poningru> keep in mind marketing speak
<poningru> ;)
<BenC> poningru: paravirt + vmware VMI ops, but it may be premature since there's a small chance that it might not make it in release
<poningru> meh I'll put it in there
<poningru> wait its not already in there?
<BenC> it's in there for Herd 3
<poningru> oh so it might get taken away? doesnt matter as long as its in there for herd 3
<BenC> but mark it in testing phase
<poningru> kk
<poningru> thanks :)
<BenC> we're still investigating the performance inpact on bare metal systems
<BenC> impact
<kylem> morning folks.
<BenC> morning kyle
<kylem> s'up?
<BenC> not much
<BenC> mjg59: pinger
<zul> hey
<mjg59> BenC: Hi
<BenC> mjg59: Hey, rt2x00 drivers don't build with the dscape you sent me
<BenC> everything else seems to work fine
<BenC> I tried the stock rt2x00 and the one you sent with d80211
<BenC> it's like it's expecting a whole different API
<mjg59> Hm. I hit workqueue issues, but I thought they looked ok otherwise
<mjg59> But that patch is pretty ancient now...
<kylem> mjg59, i thought we had rt2x00 building before?
<mjg59> I didn't think so for dscape
<mjg59> Everything else, yeah
<BenC> everything else compiles fine, and I removed the old stuff, and disabled stock bcm43xx
<BenC> mjg59: So what do people need to do to get v4 firmware?
<BenC> obviously it isn't out in the wild as much because softmac can't use v4
<mjg59> Run fwcutter on a v4 image
<mjg59> There's some listed in fwcutter's readme
<mjg59> We probably want to hack fwcutter to postfix the v4 name and add a default fwpostfix argument to the dscape bcm43xx driver
<mjg59> In order to support co-installation
<cjwatson> is there any v4 firmware on the web anywhere, like the older linksys firmware?
<mjg59> Yes
<mjg59> See the fwcutter readme
<BenC> mjg59: I'm not so sure I want to bother with multiple drivers for the same hardware
<BenC> I either want to switch to the d80211 or stick with stock
<BenC> at least for bcm43xx
<BenC> Mithrandir: I fixed the kexec-tools build failure on ppc if you wouldn't mind allowing ubuntu2 through for universe
<mjg59> BenC: It would be good to get these things tested, but I'm really not in a position to make the call
<BenC> mjg59: I've got testers for the new driver
<BenC> there were like 4 people in oslo ready to kill me because of how crappy bcm43xx is :)
<mjg59> By testing I mean at a distro-user sort of level :)
<mjg59> Right
<BenC> right, but I assume that if a user already has setup bcm43xx once, they will know how to do it again
<mjg59> Once we've got some idea of how good it is in wireless-dev, we probably want to look at pulling Michael Busch's tree
<kylem> security is uploaded.
* kylem crosses fingers.
<BenC> mjg59: The way I have it setup now, I can enable/disable it on demand from .config's so it is at least in our tree
<mjg59> BenC: Yeah
<mjg59> Oh my.
<mjg59> USB bcm43xx is apparently pretty much RNDIS
<mjg59> So. Much. Crack.
<Mithrandir> BenC: sure, I'll do
<BenC> Mithrandir: thanks
<BenC> kylem: Stone cold rejected!
<kylem> lol.
<kylem> wrong alias.
<BenC> at least it isn't just me that does that :)
<kylem> it would be nice if we only had to upload to one place to hit all 3.
<BenC> this sucks...I setup acpi scripts to disable my second core, and force my first to 1GHz when I'm on battery and I still only get an hour of battery
<Lure> BenC: how old is battery (mine gets at that level after 8-9 months)
<BenC> it's just a few months old...been that way since I bought it
<BenC> I should install winxp and see if it's the same
<kylem> pfft. old hat.
<kylem> you want vista now.
<kylem> ;-)
* kylem ducks and runs.
<BenC> hehe
<Lure> kylem: vista ultimate signature edition to be precise ;-)
<kylem> heh
<Lure> BenC: -6 kernel includes new serio we were talking recently? 
<mjg59> BenC: How are you disabling the second core?
<mjg59> There should be pretty much no power benefit to doing so
* Nafallo got IPv6 back
<Nafallo> thanks etc :-)
<zul> kylem: meh...windows 3.1 is better its shiney
<BenC> mjg59: echo 0 > /sys/.../cpu1/enable
<BenC> Lure: Should
<zul> mmmm....shiney..
<mjg59> BenC: Hm. I have a feeling that that may do little other than just prevent tasks being scheduled on it
<Lure> BenC: ok, then it does not help for HP problems
<BenC> Lure: Check changelog to make sure
<BenC> mjg59: Would be nice if it physically disabled and powered down the CPU :/
<Lure> BenC: will now build custom kernel with patch from kernel bug 7689
<mjg59> BenC: Don't think that's possible on any existing hardware
<kylem> BenC, easy way to check... is there still interrupts occuring on cpu1?
<BenC> guess I'll have to disable it in the bios when I travel to get any decent battery life
<BenC> kylem: /proc/interrupts doesn't even show the second one after I disable it
<kylem> huh.
<BenC> and it shows migration of tasks/interrupts to the first cpu when I do
<BenC> so the second cpu is atleast not doing anything
<kylem> it's probably just ready for hot-unplug then.
<BenC> but I guess it's still drawning power
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/CategoryKernel | 2.6.20-6.11
<BenC> stupid xchat
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/CategoryKernel | 2.6.20-6.11 - Things are getting solid now. Use it, but there are still a few missing modules.
<mjg59> BenC: As I said, as far as I know even disabling it in the bios won't have any significant effect on power saving
<BenC> mjg59: Only getting an hour of battery totally sucks then
<mjg59> Well, yes
<BenC> If this is hardware design, then I'm never buying an HP again :/
<mjg59> What model is it?
<BenC> I would rather it be a linux kernel bug
<BenC> dv5000
<maks_> x41 doesn't do much more battery life..
<BenC> coreduo
<mjg59> It's consumer, so it's always likely to be worse than business-class
<mjg59> But yes, Linux is poor at PM
<BenC> is it just a shit battery?
<mjg59> What does /proc/acpi/battery/state say when on battery?
<BenC> I willing to fork cash for a higher rated battery if it will help
<BenC> present:                 yes
<BenC> capacity state:          ok
<BenC> charging state:          discharging
<BenC> present rate:            0 mA
<BenC> remaining capacity:      4356 mAh
<BenC> present voltage:         14800 mV
<BenC> the thing that gets me is that rate is never shown
<BenC> but I tested the lifetime at idle by wall-clock to see how long it lasted
<BenC> dead idle, no screen blank, 1 hour
<mjg59> And it lasts an hour?
<BenC> wonder if I can fix the rate state with a BIOS update
<mjg59> That implies it's drawing 60 watts
<BenC> I watched cpu state too, and it shows them both at 1GHz (1.6GHz is max)
<BenC> I wish it would drop lower, to maybe like 800MHz or so
<mjg59> 1GHz is probably the lowest it goes
<BenC> it is
<mjg59> You're into rapidly diminishing returns after that
<BenC> 3 levels, 1, 1.3 and 1.6
<mjg59> If the processor is idle, it makes no real difference what clock speed it's at
<mjg59> Most of the chip will be switched off anyway
<BenC> right
<BenC> if I do a make -j3, battery life turns into quick death :)
<BenC> I'd be lucky to get 20 minutes out of it
<mjg59> So there's no point in dropping the frequency further unless you can drop the voltage further
<mjg59> And my suspicion is that dropping the voltage further is impractical for some reason, so they might as well nail it at 1GHz
<BenC> guessing I just need a better battery
<mjg59> BenC: Given that power draw? No
<mjg59> (Assuming it's reporting accurately)
<mjg59> 60 watts is insane
<BenC> is 6600mAh capacity average?
<BenC> stupid hp...I gotta install a windows program that checks my bios and downloads a newer version if I need it
<BenC> zul: nice job on the 2.6.19 xen
<zul> BenC: thanks
<zul> ill upload the xen-meta tonight so it will be easier to install
<BenC> zul: Any chance of it getting into feisty with 2.6.20?
<zul> i could try but dont count on it
<zul> its not very trivial ;)
<kylem> BenC, any idea if we have a "sun galaxy x4100/x4200" anywhere in the company?
<BenC> I think montreal has those boxes
<kylem> k.
<BenC> if not, then data center has them
<kylem> BenC, btw, i'll be a little late starting tomorrow, i'm heading into mtl to pick up some stuff tomorrow.
<BenC> I know we have some somewhere :)
<BenC> cool
<JanC> hm, my "cheap" MSI-based (Centrino) Core Duo does > 2h on battery...
<kylem> my macbook core2 lasts 6 hours...
<kylem> ... running macos... :)
<BenC> I got spoiled with 3.5hours on my powerbook
<JanC> kylem: I guess that's with a better battery...  :)
<kylem> my x30 lasted for ~4 hours on its 4 cell...
<maks_> my x41 lasts one hour .. :P
<kylem> maks_, ouch dude.
<kylem> heya phillip!
<plougher> hi
<JanC> BenC: disabling the second core might actually be counter-productive, if it doesn't power-down...  :)
<zul> right lunch time...bbl
<zul> *grumble*
<kylem> ?
<zul> ExceedOnDemand is just so much fun
<cjb> zul: Hi, got a sec?  On edgy, booting domU Ubuntu guests works fine, but as soon as I change the kernel= line to point to a Fedora kernel instead, I get an "Error 22".  Any ideas?
<cjb> Something like "Upgrade to feisty" or "Downgrade to dapper" or "You have to build Xen from their dist" is all good, if that's the answer.
<zul> try feisty but I dont know where the Error 22 is coming from, need more info
<BenC> HL is unable to deliver to the address supplied to us for your manual order.  Please either forward a correct physical address via reply to this email.  Please supply this information within 48 hours or we will direct DHL to destroy the shipment.
<BenC> I hate DHL
<kylem> "destroy the shipment" wtf.
<cjb> zul: Thanks.  What kind of more info is good?  The log says "failed to balloon" and not much else.
<cjb> (But I can certainly get it online.)
<zul> cjb: which kernel which arch
<BenC> cjb: Sounds like you are trying to boot a non-domU kernel, which wont work
<BenC> kylem: No doubt...what a waste
<BenC> DHL sucks in my area...they can never deliver here, unlike UPS or Fedex
<kylem> ouch.
<zul> BenC: ask them how are they going to destroy the shipment :)
<cjb> BenC: Hm, so, I had this VM running inside an FC5 machine, and the kernel is the same that it uses, which I presumed was a domU.
<cjb> Fedora's /usr/bin/pygrub stuff confuses me.
<BenC> last time I got a DHL shipment, the guy brought it in a cadillac because he didn't want t waste the gas with the delivery truck
<cjb> BenC: DHL held up our first OLPC prototype laptop in Alaska so the FDA could clear it.  ;-)
<BenC> FDA!?
<cjb> that's what we said.  :)
<kylem> uh. isn't alaska in the us? :)
<cjb> yeah, it's a customs point for DHL.
<kylem> weird.
<zul> kylem: its a freak state like hawaii
<BenC> Alaska is a US state!?!
<BenC> pshaw
<kylem> it would really fit in better as part of the yukon.
<zul> one of those freak ones...like peurto rico
<BenC> I feel bad for puerto rico, they can't even vote
<mjg59> The Russians must be kicking themselves for selling it
<BenC> I know, right. Countries only appreciate over time...lose money selling it at current rates
<zul> like the french with the louisana purchase?
<kylem> mjg59, i think they kicked themselves hardest during the cold war.
<kylem> mjg59, would have needed smaller missiles if they still had it. 8)
<zul> kylem: the yukon would be more milatarilistic then..
<pina> hi did ubuntu for server need array conf, for proliant ML 370 ??, configuragion array to raid for scsi 
<kylem> blink.
<zul> hmmm...alcatel just layed off 400 people
<cjb> ah -- I see "ERROR: Unrecognized image format" in the xend-debug log.  
<cjb> the kernel I'm using is "vmlinuz-2.6.15-1.2054_FC5xenU".  Any ideas?
<TheMuso> p/c
<kylem> BenC, have you been keeping lrm in git?
<BenC> no
<kylem> hmm. possibly we could do that and put it in /srv/.../private?
<BenC> maybe the debian part
<BenC> the .orig.tar.gz doesn't make sense there
<BenC> debian/* I mean
* kylem nods.
<Nafallo> bzr <3 :-)
* kylem likes it when people nominate themselves for getting ignored.
<Nafallo> :-P
<cjb> hmph:  "at least one of the specified interfaces does not exist!" in the xen-hotplug.log.
#ubuntu-kernel 2007-02-02
<metres> Hi all, i'm trying to compile 2.6.19 vanilla kernel onmy edgy installation but i am unable to reinstall my ATI driver back... I noticed that I cant select VESA_FB as module as it was... do anyone have an idea ?
<infinity> metres: This isn't a support channel.
<metres> sorry...
<ake> Is there a new kernel coming to breezy any time soon?
<ake> If so i would like to get a small fix added that is already there in later kernels.
<ake> In check_process_timers before the cputime_div calls
<ake> never kernels have a "if (!nthreads) return;" which is missing in the 2.6.12-10.
<ake> We have been hit by that one repeatedly the past two weeks.
<ake> The missing if-statement results in a crashed kernel.
<doko> BenC: hmm, the atheros driver isn't yet fixed in the new kernel?
<Mithrandir> doko: no, it failed to build and was backed out again
<BenC> doko: No, the stuff I tested failed
<doko> :-/
<BenC> failed to build
<fabbione> hey Ben
<derjoerg> hi all, can I also ask questions about custom kernel build for ubuntu here?
<derjoerg> especially kernel 2.6.19.2 with linux-vserver 2.2.0-rc9 ?
<BenC> fabbione: hey
<zul> hey fabbione 
<zul> BenC: if its not updated im going to try to update the kvm userland stuff this weekend if thats ok
<fabbione> BenC: can you please merge from http://www.kernel.org/git/linux/kernel/git/steve/gfs2-2.6-nmw.git ?
<fabbione> oh he is offline
<neuralis> BenC: hey there
<BenC> hey
<neuralis> nevermind, i figured this out. nvidia driver stupidity, i thought the kernel was at fault. d'oh.
<kylem> hey Ben.
<kylem> BenC, get your laptop sorted?
<BenC> got a new laptop
<BenC> Core2Duo, 945 graphics chipset
<BenC> with vmx enabled :)
<Nafallo> vmx? intel svm? :-)
<kylem> BenC, nice.
<kylem> BenC, you running amd64?
#ubuntu-kernel 2007-02-03
<BenC> No, the amd64 alt cd was oversized, so I did the i386
<BenC> crimsun: ping
<crazy_rzt> Hi
<crazy_rzt> ip route add default table 222 proto static nexthop via $GW1 dev $IF1 nexthop via $GW2 dev $IF2
<crazy_rzt> With this line(and others...) i have Load-Balance and redundancy working 100%.
<crazy_rzt> But, i dont need this Load-Balance, only redundancy.
<crazy_rzt> what i need to do to not nexthop every pkt? only if a iface goes down?
<zul> crazy_rzt: try #ubuntu this isnt a support channel
<crazy_rzt> ok sorry
<crazy_rzt> thkz for advice
<crimsun> BenC: pong
<BenC> crimsun: I have a new laptop that has hda sound, and alsa recognizes it, and acts like it's working, but no sound is coming out
<BenC> checked alsamixer and all
<BenC> has two codecs
<BenC> Codec: SigmaTel ID 7634
<BenC> Codec: Motorola Si3054
<crimsun> erg, I'll need to backport those fixes
<crimsun> BenC: please file a bug and subscribe ubuntu-audio to it, and I'll try to address that this weekend
<BenC> crimsun: Thanks
<zul> heh...https://wiki.ubuntu.com/SimpleVirtualization
<BenC> mjg59: ping
<fabbione> BenC: thanks dude
<fabbione> http://hera.kernel.org/git/?p=linux/kernel/git/steve/gfs2-2.6-nmw.git;a=summary
<fabbione> BenC: i need you to pull from that tree for the next kernel
<fabbione> there are important bug fixes for GFS2
<fabbione> including a fix for a deadlock that makes it impossible to use
<fabbione> the nmw tree is basically bug fixes for "Next Merge Window"
<fabbione> so it's safe to pull
<BenC> Ok
<BenC> fabbione: Can you email that to me so I can make sure I remember?
<fabbione> BenC: sure. i will do that when i am back to the office.
<fabbione> the network at the hotel stinks
<BenC> kylem: I got my ia32 architecture manuals, did you get yours?
<fabbione> BenC: we have a fix for GFS1
<fabbione> for .20
<BenC> cool
* fabbione needs to get to it soonish
<fabbione> they commit it yesterday in CVS
<Eruantalon> Is the ivtv driver included by default in the prpposed feisty kernel?
<kylem> BenC, didn't order them yet.
<BenC> kylem: Make sure you give them a shipping address and not a postal address :)
<BenC> my package got all the way here via DHL before they noticed that it was going to a PO Box
<kylem> hehe.
<BenC> Eruantalon: Yes
<BenC> nice books though
<kylem> yeah, when i ordered the itanium manuals a few years back, they came like next day.
<Eruantalon> BenC: Can I upgrade to the feisty kernel without upgrading the rest of the system as it is still unstable?
<BenC> Eruantalon: You can, but it isn't supported...e.g. it works (I do it), but there may be unforseen problems
<Eruantalon> would that be 2.6.20-6.11 then?
<BenC> plus, you'll have to upgrade module-init-tools and initramfs-tools to, which means libc6, which means you just grabbed some important feisty parts already
<BenC> yes
<Eruantalon> BenC: So just doing feisty would be simpler? I just need ivtv...
<BenC> not simpler, just that you might as well take the plunge
<BenC> feisty isn't totally unstable right now
<BenC> I'm running it on my laptop, and haven't had any problems yet
<Eruantalon> BenC: Ok. I think i might do it. It's just that i was hoping to make this install a rather stable one( it is for my server that going to run mythtv)
<BenC> Eruantalon: I would say a server install is very stable in feisty right now
<BenC> most of the instability would be in desktop stuff
<Eruantalon> BenC: Ah. But is not just server: also mythtvfrontend and similar stuff. But if it is just applications chrashing now and then that would really be a problem
<BenC> there's no crashing
<Eruantalon> oops. i meant to write not a problem.
<BenC> if you want ivtv, take the jump, else wait for April 20th
<Eruantalon> BenC: It is tempting. Btw any difference when running kubuntu?
<BenC> these are questions for #ubuntu, I can only tell you that the kernel is stable
<Eruantalon> ok. thanks
<Eruantalon> A kernel related question. If I am using only kernel, that is no closed source drivers or outside stuff then a freeze of my computer because of an app would be a kernel bug(or hardware) or is it so that apps will always inherently be able to crash even a bugfree kernel?
<Eruantalon> Is the platform constructed so that a userspace app will be able to lay down the entire system or is that considered a bug when that happens?
<cjb> Eruantalon: Yes, you can make the argument that any crash is a kernel bug.
<Eruantalon> cjb: Unless bad hardware or closed drivers... right?
<kylem> wrong.
<kylem> it's entirely plausible, and in most cases, very likely, that X will wedge your machine.
<cjb> that's because X is a kernel driver ;-)
<Eruantalon> cjb: Yes isn't it?
<Eruantalon> BenC: When upgrading to feisty will it be necessary to remove old modules etc. from the old kernel or will they not conflict?
<BenC> Eruantalon: of course we handle that...else upgrades would be pretty busted
<Eruantalon> BenC: You guys are good aren't you :-)
<Nafallo> ofcourse they are :-)
<Nafallo> they are the best. sabdfl hired them...
<Eruantalon> just waiting for the cd-image to finish 2h lefts
<mjg59> BenC: Online now - context?
<BenC> mjg59: nm, I think
<BenC> basically rt2x00 wont compile with dscape
<BenC> it has hwmode stuff in it's local dscape that isn't in the wireless-dev one
<mjg59> Yeah, I think we had that conversation already :)
<mjg59> Eh. Pain.
<BenC> so I resorted to disabling rt2x00 and using strictly rt2x00-legacy
<kylem> fucking muppets.
<mjg59> Ok, I'll look into it
<mjg59> I have none of the hardware
<mjg59> But if it builds, we're all good
<BenC> Neither do I
<BenC> it only affects rt61 and rt73
<BenC> rt2[45] 00 was already built with -legacy since the CVS stuff doesn't actually work for my rt2500pci
<mjg59> Ha
<Eruantalon> Will there be more lirc support in the feisty kernel?
<Eruantalon> included by default that is
#ubuntu-kernel 2007-02-04
<crimsun> BenC: ping, which LP bug # is your Sigmatel HDA issue? Otherwise, ``lspci -nv'' is useful
<BenC> crimsun: No idea how, but it's working now
<BenC> after a few reboots, it magically made sound
<kylem> BenC, that's whacked.
<BenC> even weirder, now it's not working
<BenC> I got the drum and login sounds
<kylem> lsof it and see if something is holding it open?
<BenC> haven't paid attention since then
<crimsun> still, ``lspci -nv'' would be very useful
<Keybuk> crimsun: talking of which, I have a sound card issue <g>  the microphone jack doesn't work
<crimsun> Keybuk: tail -2 /proc/asound/oss/sndstat
<Keybuk> crimsun: SigmaTel STAC9200
<crimsun> ``lspci -nv'' somewhere :)
<crimsun> good thing I'm wading through these sigmatel changes
<Keybuk> that's why I jumped in <g>
<crimsun> thanks
<BenC> Sigmatel is the same one I have
<Keybuk> the interwobble suggested that it was something to do with the port needing to be set to either mic or line mode, depending on the impedence of the jack sensed, which the driver we have doesn't do (so it sits in limbo)
<crimsun> crafty Dell?
<kylem> crimsun, your most recent dump of patches on kernel-team@ what dist where they targetted for?
<crimsun> kylem: feisty. Apologies, I'll resume making that explicit.
<kylem> cool. SEP then. 8)
<crimsun> BenC: / Keybuk: does unloading snd-hda-intel then reloading it with model=ref help?
<Keybuk> BenC: what Dell did you get?
<kylem> woot.
<kylem> pizza's here, pucks about to drop.
<kylem> time for the canadian saturday night ritual.
<Keybuk> crimsun: that grew extra Input Source settings I think
<Keybuk> and the Mic one works
<crimsun> Keybuk: so toggling Mic results in audible sound capture?
<Keybuk> yeah
<crimsun> awesome, I'll add your id to the quirk list, thanks.
<crimsun> BenC: do you also have 0x102801d6 for the Subsystem?
<BenC> let me check
<crimsun> thanks.
<BenC> Subsystem: 107b:0366
<crimsun> ah, you have a Gateway
<BenC> yeah
<crimsun> I'll send up those diffs in a jiffy.
<Keybuk> "a Gateway" ?  as in one of those computers with the cow motif?
<crimsun> yeah, moocow
<BenC> it goes along with my surroundings
<BenC> I just have to make sure the bull doesn't try anything weird with my laptop now
<Keybuk> the electric fence stops your laptop from escaping?
<kylem> moo.
<Keybuk> cows make more of a "brrrmmmma?" sound
<BenC> "aka Backport support for Ben Collins's laptop"
* BenC feels special
<BenC> crimsun: Thanks
<kylem> lol
<pradalover> I have an upgrade issue
<pradalover> hello
<Eruantalon> Are there any plans to improve lirc support in the ubuntu kernel?
<BenC> Eruantalon: nope
<Eruantalon> Well there's a straight forward answer :-)
<BenC> Eruantalon: the long answer is "if someone does the work"
<Eruantalon> Where can i file a bug against lirc in feisty? https://launchpad.net/ubuntu/+source/lirc/0.8.0-9ubuntu1 doesn't seem to be the place
<BenC> or at least specs it out so we know what's involved
<BenC> https://bugs.launchpad.net/ubuntu/+source/lirc/+filebug
<BenC> put feisty in the summary line
<Eruantalon> Ah it seems to be there already
<BenC> crimsun: ping
<BenC> Eruantalon: a bug asking for better lirc support in the kernel?
<Eruantalon> no. I can't compile the lirc source
<Eruantalon> https://bugs.launchpad.net/ubuntu/+source/lirc/+bug/78140 i think this is the one.
<Eruantalon> BenC: Besides there are MANY bugs asking for better lircsupport in the kernel. Or rather they just want the module by default.
<ivoks> BenC: is it a known thing that kvm doesn't work in feisty? :)
<ivoks> doesn't work = crashes
<ivoks> if not, i could report bug and add all details i can
<BenC> ivoks: it does now
<BenC> latest kvm+linux-image-2.6.20-6-* works
<BenC> ivoks: There's a known crash already has a bug, dealing with nx bit
<ivoks> i tried today's up2date
<BenC> is it a win2k install, crashing?
<ivoks> no, ubuntu and redhat
<ivoks> that's all i tried
<BenC> probably same crash
<BenC> or are you getting an abort(13/30)?
<ivoks> yes, on ubuntu - 13
<ivoks> but on redhat, whole kernel crashes i and i have to hard-reboot
<BenC> yeah, that's an issue with the bootgraphix on the CD, not emulated
<ivoks> right
<BenC> Add -no-kvm for the install
<ivoks> oh, thanks for the tip
<BenC> after install, using straight kvm will work
<BenC> my new laptop supports vmx, so I can do more testing now :)
<ivoks> :)
<BenC> had to use the xeon over vnc before that
<ivoks> mine toshiba also supports VT, but... omg, i'll never buy toshiba again :)
<ivoks> that's why i got my self a new computer, just for testing
<rikai> whats wrong with toshiba?
<rikai> Out of curiosity
<BenC> This new laptop is a gateway, but it has the best keyboard I've used since the powerbook
<ivoks> rikai: they don't want to give specs
<rikai> ah
<ivoks> rikai: BIOS is buggy and causes lots of issues
* stgraber has a buggy ACPI with its toshiba laptop
<stgraber> Unable to resume from suspend to ram
<rikai> Isn't that the Phoenix-based bioses mostly?
<stgraber> yes, that's a phoenix (at least here)
<ivoks> stgraber: mine too... how does it die?
<rikai> Yeah, phoenixbios-based toshiba's are really crappy.
<stgraber> it goes to sleep correctly (orange led flickering), then at the resume, the LCD simply doesn't switch on, no harddisk noices, ...
<ivoks> stgraber: check out bug #82996
<stgraber> I have to remove the battery+power supply to be able to boot it again ...
<rikai> I had to get ubuntu to stop locking up on an m65... turns out its because it turned off the fan as soon as ubuntu took over from the bios, so it was consistently running with no fan.
<ivoks> this is how my toshiba wakes up: http://librarian.launchpad.net/6160425/crash.jpg :)
<stgraber> At least you see something :)
<ivoks> yay! :))
<stgraber> I've found a small ACPI mistake in the dsdt but even once fixed I still don't have a working suspend to ram
<stgraber> at least with Feisty I've a working suspend to disk :)
<mjg59> The DSDT is pretty irrelevent when it comes to suspend to RAM
<BenC> doko_: ping
<BenC> anyone running feisty with an atheros card?
<stgraber> me
<BenC> crimsun: Patches worked, but I had to fix a typo...no quirk struct, was named something else
<crimsun> BenC: ok, thanks
<BenC> oooh...2.6.20 is released
<Nafallo> kewl
<Eruantalon> How long time does it normally take for a new release of the kernel to go into feisty?
<kylem> eight point three five fortnights.
<Eruantalon> ?
<Eruantalon> :-S
<gnomefreak> Eruantalon: in the beginning of devel fairly fast as we start closing in on release a bit further apart. (it all depends on bugs and stuff)
<Eruantalon> ok
#ubuntu-kernel 2008-01-28
<joejaxx> hello all i redid a patch for bug 162090 against the latest hardy kernel revision i was wondering if someone could review it :D
<ubotu> Launchpad bug 162090 in linux-source-2.6.22 "appletouch does not recognize trackpad in macbook3,1" [Undecided,Confirmed] https://launchpad.net/bugs/162090
<joejaxx> it is a git diff :)
<tonyyarusso> Could someone please tell us at least a temporary workaround to https://bugs.edge.launchpad.net/ubuntu/hardy/+source/linux/+bug/129910 ?  The things people have found so far only work some of the time, so are clearly missing something.
<ubotu> Launchpad bug 129910 in xserver-xorg-video-ati "Blank ttys when using vesafb (vga=xxx)" [Unknown,Fix released] 
<kraut> moin
<Kano> hi, i added 2 patches to
<Kano> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/185719
<ubotu> Launchpad bug 185719 in linux "remove duplicate pci ids bcm43xx/ssb prism54/p54pci" [Undecided,New] 
<Kano> they are tested and working
<Kano> dont forget the firmware (b43-fwcutter)
<Kano> laga: did you try aufs?
<Kano> anybody awake
<gicmo> I am
<gicmo> but I am not sure of I am of any help ;-)
<Kano> i just want those patches integrated
<Kano> and best: addone of current (28.1.) aufs to lum
<Kano> new code since today
<gicmo> I have nothing to to with the kernel team ;-)
<rtg> abogani: I'm not registered so can't reply. Can you put a patch on zinc somewhere?
<abogani> rtg: Sorry i don't know that you aren't registered.
<abogani> rtg: Sure! Please check it at my home on Zinc (/home/abogani/1-rt-compat-symbols.diff).
<abogani> rtg: Only one note: i don't have idea if CONFIG_XEN is still necessary.
<rtg> abogani: no problem. I chose not to register since the conversations regarding kernel stuff should be in the open.
<rtg> abogani: your patch is a good example of why lrm should be under git revision control. However, the size of the binary blobs makes it somewhat unmanageable.
<rtg> abogani: FYI - Xen has not been enabled yet.
<abogani> Agreed
<zul> rtg: patch should be coming today
<rtg> zul: good timing since I totally fubared the -5.8 upload.
<zul> oh?
<rtg> I rebased against 2.6.24, but somehow missed the ABI check failiure.
<zul> heh oops :)
<rtg> anyway, -6.10 will be the next upload.
<rtg> zul: correctiom, it was the -5.9 upload that fialed.
<zul> heh i have a patch for lum as well so Ill be doing that one first (ie sending email to kernel team list yadda yadda)
<rtg> zul: be sure to check the xen build against -6.10. I'm done rebasing for awhile.
<soren> rtg: So, I might still be able to get something shoved into the kernel before alpha 4?
<rtg> soren: dunno yet if the -6.10 upload will get cooked in time.
<rtg> soren: send me you pull request anyway.
<soren> rtg: Will do.
<laga> rtg: any news wrt unionfs?
<rtg> laga: refresh my memory.
<laga> rtg: sure. there was supposed to be a new l-u-m upload with a unionfs patch which fixes bug #103044
<ubotu> Launchpad bug 103044 in linux-ubuntu-modules-2.6.22 "kernel oops during boot on a nfs root diskless system, SRU TEST CASE" [High,Confirmed] https://launchpad.net/bugs/103044
<rtg> laga: likely this week. kees is still testing...
<laga> rtg: that's good news. i'll ask him if i can have the patch
<rtg> laga: we were both traveling last week, so there has been disruption in our workflow.
<laga> yes, i figured as much. 
<rtg> laga: you should be able to get what you need from the git repo.
<laga> oh. i haven't seen any related commits. guess i should look again.
<rtg> laga: i just read the bug report. I don't think the problem you are seeing is solved.
<laga> oh. :/
<soren> rtg: pull request sent.
<laga> which would explain why i can't find the commit.
<laga> because i already have the latest l-u-m from gutsy-proposed.
<laga> rtg: any chance it will get solved?
<rtg> laga: do you know of an upstream patch for it?
<laga> rtg: no. i didn't ask upstream because ubuntu still has 1.4 which is quite old
<rtg> laga: if you can find and test one, I'll consider it. An oops satisfies SRU policy.
<rtg> laga: otherwise your solution may be Hardy.
<laga> rtg: i do not believe that hardy solves my problem.
<laga> this setup on hardy still breaks, i just never got around to look at the OOPS
<rtg> laga: we have a better chance of getting upstream to look at it.
<rtg> in Hardy that is
<laga> to be honest, i just need a working stacking file system in hardy. gutsy doesn't matter.
<laga> rtg: oh. does hardy have newer unionfs?
<rtg> laga: ok, I'll have -6.10 uploaded soon which is based on -6.10. unionfs looks like it is still 1.4
<laga> rtg: yes, that's why i was asking :)
<rtg> laga: perhaps you could make a patch for current upstream unionfs and test it against Hardy?
<laga> rtg: i need a stacking file system for Mythbuntu - people can have diskless fat clients that way. if unionfs can't be fixed, aufs ("another unionfs") might be an alternative. it requires a very small kernel patch (just a few symbol exports) to get NFS working, though.
<laga> rtg: you mean i should build current unionfs and test it in hardy? what about the apparmor changes needed for unionfs in gutsy?
<rtg> laga: since AA is not in the kernel, I imagine upstream unionfs will have those fixes. dunno for sure.
<rtg> s/not/now/
<laga> oh.
<laga> i didn't know that apparmor made it in the kernel. that's good news.
<laga> rtg: if my testing was successful, would you add current unionfs to hardy or just cherry-pick patcheS?
<rtg> laga: I would probably add current unionfs. It will get some scrutiny however, given the problems we've had in the past.
<laga> rtg: yes.
<laga> thought as much :)
<laga> rtg: would adding aufs be an option? that'd mean there was another stacking filesystem which also works with NFS while keeping unionfs in a known, stable-enough state
<rtg> laga: yep.
<rtg> laga: it should go into ubuntu-hardy-lum/ubuntu/fs
<laga> rtg: i've just remembered that upstream aufs has suggested some patches which would need to be applied to the kernel. ogra told me you (as in "the kernel guys") wouldn't do it which would make adding aufs pointless
<rtg> laga: it depends on what the patches are. I'd have to see them first.
<laga> let's see...
<laga> rtg: here's patch #1:
<laga> http://aufs.cvs.sourceforge.net/aufs/aufs/patch/sec_perm-2.6.24.patch?revision=1.1&view=markup
<laga> #2: http://aufs.cvs.sourceforge.net/aufs/aufs/patch/splice-2.6.23.patch?revision=1.1&view=markup
<laga> #3 http://aufs.cvs.sourceforge.net/aufs/aufs/patch/put_filp.patch?revision=1.1&view=markup
<laga> #4 http://aufs.cvs.sourceforge.net/aufs/aufs/patch/deny_write_access.patch?revision=1.1&view=markup
<laga> that's all he has mentioned.
<rtg> laga: I'll look at 'em in a bit. I have some other stuff I gotta work on.
<laga> rtg: sure. me too, actually, so i'll stop procrastinating here :)
<Kano> hi rtg 
<laga> Kano: no, i haven't tried your aufs yet. it's possible that it goes to l-u-m though
<Kano> well i did not see a big difference in todays snapshot
<Kano> rtg: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/185719
<ubotu> Launchpad bug 185719 in linux "remove duplicate pci ids bcm43xx/ssb prism54/p54pci" [Undecided,New] 
<rtg> Kano: its on my list
<Kano> then apply it
<rtg> Kano: patience
<Kano> thats nothing i have got
<Kano> laga: same position, updated cvs
<Kano> btw. you should be able to use my precompiled kernels too
<Kano> http://kanotix.com/files/kernel/kernel-update-pack-generic.tar.gz
<Kano> in source dir all patches
<Kano> if you want to compile on your own use em
<Kano> or just use all from kernel + extra (maybe without avm as you dont have the dependency for that)
<laga> Kano: thanks, probably won't have time before the weekend to do anything
<Kano> i can you give already made images using live-helper too
<Kano> if needed 2 with same settings, one unionfs next aufs
<laga> Kano: i don't need live disks, i just need a working stacking file system in the ubuntu repos :)
<Kano> well the aufs source does not compile directly
<Kano> as it needs at least 2 extra files
<laga> Kano: the necessary patches are in ubuntu now, the aufs-source maintainer has updated it. he even used one of your patches :)
<Kano> did not see the export
<Kano> where is it?
<Kano> last weekend all applied
<laga> oh
<laga> i was talking about the aufs-source package
<laga> nothing in git yet
<Kano> well i tested a kernel with all patches proposed, did not see any difference compared to applying only one
<laga> Kano: do you realize you need to configure the aufs module accordingly?
<Kano> i just copy 2 extra files to my headers and compile aufs 
<laga> there are some defines which toggle those settings
<Kano> well i just use autodetection that way
<laga> it's documented somewhere in the top-level directory of the aufs source tree. don't have it here on my laptop
<laga> there's no auto-detection IIRC, just defaults. i could be wrong, though
<Kano> http://kanotix.com/files/kernel/kernel-update-pack-generic/source/
<Kano> http://kanotix.com/files/kernel/kernel-update-pack-generic/source/sec_perm-2.6.24.patch
<Kano> thats the absolute minimum
<Kano> other way would be
<Kano> dont use that patch and compile aufs STATICALLY as kernel patch
<Kano> same would work for unionfs too btw
<Kano> btw. when i use unionfs, i can boot with live-helper but network-manager does not run
<Kano> it works with aufs however
<Kano> maybe thats why u does not use networkmanager by default and uses stupid dhcp entries in /etc/network/interfaces...
#ubuntu-kernel 2008-01-29
<Xsss4hell> any way to install the latest stable kernel wihthout much hassle and hoff? I don't want to comile it, can't I just aptitude it?
<kraut> moin
<Kano> btw. the amd64 kernel is suboptimal, it does not show the splash
<bullgard4> Does the Intel M processor use 16- or 32-bit Littleendian?
<ln-> BenC: ping. can you tell me what "Declined for Dapper by Kees Cook" means in https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/65631 ?
<ubotu> Launchpad bug 65631 in linux-source-2.6.15 "skge driver broken: invalid call to spin_unlock causes system crash" [Medium,Fix committed] 
<ln-> (someone told me to ping you)
 * laga summons rtg
<zul> is there a community kernel team meeting today?
<laga> i don't knopw
<laga> know*
<laga> rtg: looked at the patches already?
<rtg> laga: aufs? not yet.
<laga> rtg: good. aufs upstream is willing to look at the ubuntu kernel and see what it takes to make aufs work with it
<rtg> laga: if the kernel patches simply expose some symbols, then it ought not be too difficult.
<laga> rtg: that's all they do i believe. i'm not sure what's needed to work around some API changes introduced by apparmor (IIRC).
<laga> only the aufs guy can tell, i suppose
<laga> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=summary <- is that the kernel tree he should look at?
<rtg> laga: yep
<juliank> laga: the new aufs upload in Debian (today or tomorrow) will fix the issues, using the patch Kano proposed. 
<laga> juliank: i just saw your email.
<laga> juliank: sorry if parts of my msg were redundant, i wrote it earlier today and didn't have the opportunity to send it till now
<juliank> laga: who plans to include aufs into l-u-m? 
<laga> juliank: rtg said he'd be cool with doing that if i submitted a patch. granted, he has to review the kernel patches proposed by junjiro first
<laga> juliank: with the patches in your package, does the kernel need to be patched at all? (except for the lhash patch which I do need)
<juliank> laga: I'm running the normal ubuntu kernel and it works. But some patches may boost performance or improve security.
<laga> juliank: it depends on rtg then.
 * laga digs up lhash patch
<rtg> when you guys are ready, send the patches (or a reference to them) on kernel-team@lists.ubuntu.com so I don't forget them.
<laga> juliank: which patches would you recommend?
<juliank> laga: I never used them, but I would say: splice, lhash [nfs] , put_filp [nfs]
<laga> sec_perm is not needed anymore with your patches.
 * laga adds question mark
<juliank> laga: Right. It's patched like unionfs in l-u-m, but I don't know if this is the best way.
<laga> juliank: does the sec_perm patch actually apply to the ubuntu kernel? 
<laga> juliank: have you verified that the ia_file patch doesn't break anything? just commenting out stuff looks scary to me :)
<juliank> laga: by Kano. upstream did the same, see his last e-mail. - The problem with upstream's patch (although they may be better) is the size.
<juliank> everyone: Is security_inode_permission enabled in the Ubuntu kernel?
<laga> juliank: the last email from upstream is from 6:00am, correct?
<juliank> laga: 17:34 (CET)
<laga> juliank: i must be blind. the only email i see from around that time is the one i wrote (17:37)
<juliank> laga: Maybe it's not on the list yet. 
<juliank> the patch is at http://jak.kicks-ass.org/~jak/upstream.diff
<laga> juliank: or he only sent it to you. anyways, if junjiro did the same thing, why not
<juliank> The question is: Are the API changes caused by AppArmor only?  See the simple patch from Kano at http://jak.kicks-ass.org/~jak/01_vserver_apparmor.dpatch
<laga> juliank: if we put it into l-u-m, does it really matter how big that patch is?
<laga> juliank: i believe the ia_file api change is caused by apparmor patches - at least i found an apparmor patch which removes that member. vanilla 2.6.24 still has it.
<juliank> laga: I know this. I'm talking about the other changes.
<laga> ah.
<laga> interesting. that ia_file patch was indeed there earlier
<juliank> laga: The aufs-source package will be kept and people who build aufs with it should use the same set of patches like l-u-m.
<laga> juliank: sounds good. but which patch are we going to use? :)
<juliank> laga: Kano's patch is much easier to maintain. it's 2-4 kb, whereas upstream's patch is about 57 kb.
<juliank> And Kanotix is a live disk, which means it should work
<juliank> After Alpha 4, we should start building disks using aufs instead of unionfs (but keep it as a fallback, like in debian-live)
<juliank> laga, rtg: I'll provide a patch to add fs/aufs to l-u-m, based on the code in the aufs-source package (new revision not uploaded yet) 
<rtg> juliank: thanks, much appreciated.
<juliank> rtg: It would just be good to keep most of the configuration in http://jak.kicks-ass.org/~jak/conf.mk  - should I simply add CONFIG_AUFS=m to config/[archs] and keep the config.mk file inside fs/aufs/ - it exports many variables and EXTRA_CFLAGS
<rtg> juliank: If you figure out how to build it under l-u-m, then I can go from there.
<laga> juliank: how does the lhash patch fit in? :)
<Dekans> hello guys
<Dekans> what are compilation options for a live CD kernel ?
<dade`> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/151016
<ubotu> Launchpad bug 151016 in linux-source-2.6.22 "New in 2.6.22-13: system takes a LONG time to resume from suspend" [Undecided,Confirmed] 
<Mithrandir> Dekans: it's the stock -generic kernel
<dade`> is this fixed on any new hardy kernel ?
<Dekans> I would like to make a live CD with a vanilla patched kernel
<dade`> someone in the last comments says it's fixed in -14-2 but there is no confirmation
<Dekans> Mithrandir: Mithrandir is the /boot/config-`uname -r` good ?
<Mithrandir> Dekans: it should be, yes.
<Dekans> and I can easily the -generic kernel of a live CD ?
<Dekans> +replace
<dade`> nobody cares about me :(
<dade`> hmm, an easy way to install hardy's kernel on gutsy ?
<juliank> Any list moderator here?
<juliank> rtg: I finished all patches, but the post "[l-u-m] [PATCH] UBUNTU: Add aufs module version 0+20080129" needs to be approved by a moderator first
<rtg> juliank: just did
<laga> wow
<laga> juliank: thanks for the patches
<laga> rtg: thanks for comitting them
<alex_joni> does anyone happen to know when pci_get_device() was added into the kernel?
<alex_joni> (do newer 2.4 kernels have that? or only the pci_find_device()?)
<Kano> hi, it seems you forgot to add the aufs config to lum
<laga> heh
<laga> yeah
<Kano> just compiled and it was without
<laga> took me some time to fix that
<rtg> Kano: workin on it.
<laga> rtg: great.
<Kano> did you see my casper patch (similar to live-helper)?
<Kano> you should upload a fixed casper package too
<laga> Kano: julian might be interested in that. i think he's going to provide aufs patches for the live disks tomorrow
<rtg> laga: the patch didn't apply clean to debian/config/i386 or amd64 because of a prior patch from Fabio. Simple enough to fix.
<Kano> i did that yesterady already
<Kano> will just change the patch position
<Kano> why are my 2 other patches are not used?
<Kano> http://kanotix.com/files/fix/casper-aufs.patch
<Kano> thats for casper
<Kano> then you can use union=aufs
<laga> hum. NFS branch not supported with aufs. either i did something wrong or the autodetection is not working.
<rtg> lum pushed
<rtg> I'm outta here
 * laga makes a mental note to bug julian tomorrow and leaves
<Kano> at least i have got now only 2 extra module packages besides lum...
<ln-> BenC: ping. can you tell me what "Declined for Dapper by Kees Cook" means in https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/65631 ?  (someone told me to ping you)
<ubotu> Launchpad bug 65631 in linux-source-2.6.15 "skge driver broken: invalid call to spin_unlock causes system crash" [Medium,Fix committed] 
<Kano> ln-: how about using sk98lin and blacklist skge?
<BenC> ln-: means it wont be fixed in dapper
<ln-> BenC: any idea why not?
<BenC> ln-: without reading it, I can only guess because it doesn't meet our Stable Release Updates policy
<ln-> BenC: it's a security vulnerability; https://bugs.launchpad.net/bugs/cve/2006-7229
<BenC> ln-: looks like it is fixed in dapper already...probably why it was declined...already fixed
<ln-> BenC: but it isn't fixed!
<BenC> ln-:   * [UBUNTU:drivers/net] drop invalid spin_unlock calls in skge (CVE-2006-7229)
<ubotu> The skge driver 1.5 in Linux kernel 2.6.15 on Ubuntu does not properly use the spin_lock and spin_unlock functions, which allows remote attackers to cause a denial of service (machine crash) via a flood of network traffic. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-7229)
<BenC> ln-: that is in the latest changelog for 2.6.15
<BenC> ln-: if you can show that this is reproducible in 2.6.15-51.65 upload, then I'd say take it up with kees
<ln-> BenC: please take a look at the skge.log attachment at the end.. i.e. this: http://launchpadlibrarian.net/11562782/skge.log
<ln-> ok, i admit there is no spin_unlock visible in it, but still an excellent way to crash the system.
<BenC> ln-: I'm going to need to see the version of the linux-image-2.6.15-51-386 package for that log
#ubuntu-kernel 2008-01-30
<ln-> Package: linux-image-2.6.15-51-686
<ln-> Version: 2.6.15-51.64
<BenC> that's not the one with the fix
<BenC> it was fixed in 51.65
<BenC> make sure you have all the latest updates from dapper-security
<BenC> reboot, and retest
<ln-> i do have all the updates from dapper-security...
<BenC> either you're mistaken, or that upload has not been released yet...either way, you aren't testing the version that has the fix
<BenC> I'm checking the upload status, give me a minute
<ln-> thanks
<BenC> ln-: looks like that upload is pending
<BenC> ln-: kees would know more
<ln-> do you think there's something wrong in ubuntu's "process," if a thing broken in Oct 2006 doesn't get fixed by Feb 2008, even if the fix is known and is trivial?
<BenC> ln-: considering there's a work around and there is no data-loss involved, it's a rather trivial issue to begin with
<BenC> ln-: kees handles security, so you really should talk to him
<ln-> i'll try to ping him again tomorrow.
<ln-> ... or why bother.
<BenC> ln-: well, if there's is an issue with the process, kees would be willing to explain or possibly improve
<BenC> ln-: I'm sure he would appreciate input, or being put on the spot :)
<ln-> ok, i'll ping him then..
<Kano> laga: somehow this kernel has problems to be used with live-helper
<Kano> so something else is wrong..
<kraut> moin
<Kano> hi, current aufs in lum works for me
<Kano> but
<Kano> with standard ubuntu config (too many old legacy drivers) i get this
<Kano> http://paste.debian.net/48033
<Kano> which results in no dma for hdc
<Kano> a pure libata kernel has no problem at all with it...
<Kano> also, i see no reason to try blacklists on those 2 modules, debian has even bcm43xx completely disabled, you could do that too
<Kano> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/185719
<ubotu> Launchpad bug 185719 in linux "remove duplicate pci ids bcm43xx/ssb prism54/p54pci" [Medium,Triaged] 
<Kano> as soon as tools like discover are installed blacklisting does not work
<Kano> hostap_pci is completely unstable btw. dont know why
<Kano> p54pci works fine
<Kano> did anybody try ath5k?
<laga> hey juliank 
<laga> juliank: aufs doesn't work with nfs branches. it was complaining that i need to apply the lhash patch (and add the config option)
<juliank> laga: Are you running the latest git kernel?
<Kano> hi laga , well it worked for live mode, but you can add those ;)
<laga> juliank: "latest" as in "pulled right after rtg committed your patches", yes.
<laga> Kano: great :)
<Kano> did you get the link in pm?
<laga> yes
<Kano> it has some problems shutting down, but before i got kde boot errors
<laga> haven't tried it yet, i don't need live disks at the moment :) 
<laga> oh
<Kano> you can use vbox or vmware to boot it too
<juliank> laga: the latest ubuntu-hardy.git +  ubuntu-hardy-lum.git should work
<Kano> you will see a huge difference when you boot with union=unionfs 
<laga> Kano: speed-wise?
<Kano> then network-manager does not work
<Kano> i dont get why the same kernel works on hardy with networkmanager
<Kano> with unionfs
<Kano> maybe somebody changed networkmanager
<laga> my nick comes up #2 in google when you search for "unionfs sucks", so don't expect an answer from me
<Kano> good point ;)
<laga> note: i've changed my opinion since then. current unionfs is probably just fine with a vanilla kernel, but i guess i'll never find out :)
<Kano> well not for me, with the test i did...
<laga> juliank: the changes which have been committed since then are not relevant - except for the missing entries in debian/config/i386 which i added myself
<Kano> i even had the strange issue with unionfs that in a vm a simple du -h /dir returned an error - a real pc did not have that error however
<laga> odd.
<juliank> laga: do cat /sys/fs/aufs/config
<laga> unionfs doesn't work well with bonnie either. not sure what's causing that.
<Kano> could never trace it why this happend, aufs worked
<juliank> laga: what does not work? build or mount?
<laga> juliank: mounting. 
<laga> juliank: i'm booting the VM now..
<Kano> it builds, thats not the problem
<Kano> do you want a sample iso?
<juliank> Kano: You have an ISO?
<Kano> of course
<juliank> Kano: size?
<Kano> with that kernel, but based on etch
<Kano> live-helper created
<Kano> until some other things are patched in u i will not use it
<laga> juliank: CONFIG_AUFS=m, CONFIG_AUFS_FAKE_DM=y, CONFIG_AUFS_BRANCH_MAX_127=y, CONFIG_AUFS_SYSAUFS=y, CONFIG_AUFS_RR_SQUASHFS=y
<laga> juliank: that's /sys/fs/aufs/config
<laga> if fails with the error message: aufs test_add:357:exe[2033]: NFS branch is not supported, try some configurations and patches included in aufs source CVS
<juliank> laga: I'm fixing it.
<laga> juliank: great.
<Kano> well you would need to patch+compile the kernel first to try
<laga> patch what?
<juliank> Kano: The Ubuntu kernel has the patches.
<Kano> juliank: fine, then it should be easy to update just lum
<Kano> a few seconds ;)
<juliank> Kano: One variable name is wrong, that's all.
<Kano> good, can update lum with ease
<Kano> scripted ;)
<juliank> laga: Do you have a build log of l-u-m?
<laga> juliank: no, but i can make one real quick :)
<juliank> laga: I'm building
<juliank> laga: try to add KSRC=$(PWD) to the top of ubuntu/fs/aufs/Makefile and build it.
<Kano> also could you enable aufs for powerpc too?
<juliank> laga: I will send a patch soon
<juliank> Kano: Soon.
<Kano> did somebody have got no framebuffer support on amd64 live cd or is it just me?
<Kano> i386 live cd has a splash
<Kano> amd64 not
<Kano> juliank: what do you think about a blacklist option for casper, i have that for kanotix
<Kano> it writes to /etc/modprobe.d/custom-blacklist
<Kano> before udev starts
<laga> juliank: i don't think it's working
<laga> same message
<juliank> laga: I need a build log.
<laga> juliank: http://www.pastebin.ca/884456
<laga> juliank: here's the KSRC patch i added: http://www.pastebin.ca/884457
<juliank> laga: rebuild with KSRC=$(srctree)
<laga> am i supposed to use that string literally or should i expand srctree?
<juliank> laga: as written. it's a variable
<laga> oops. that's gonna take a few minutes, just deleted the squashfs image for my diskless client.
<laga> juliank: ok. CONFIG_AUFS_LHASH_PATCH and friends were picked up properly, but i'm still getting that error message. 
<laga> juliank: ok. CONFIG_AUFS_LHASH_PATCH and friends were picked up properly, but i'm still getting that error message. 
<laga> juliank: i don't see a config option for the put_filp patch in sysfs
<juliank> laga: /sys/fs/aufs/config
<juliank> laga: output of grep '^.*[[:space:]]put_filp[[:space:]]vmlinux[[:space:]]EXPORT_SYMBOL' Module.symvers
<juliank> ?
<juliank> laga: sorry, typo
<laga> AUFS=m, AUFS_BRANCH_SYSAUFS=y, AUFS_RR_SQUASHFS=Y, AUFS_SEC_PERM_PATCH=y, AUFS_SPLICE_PATCH=y, AUFS_KSIZE_PATCH=y
<laga> i left out the CONFIG_ part. 
<laga> juliank: what do you need grepped?
<juliank> laga: not needed. I know the problem now.
<laga> juliank: great
<juliank> laga:  the patch is at http://www.pastebin.ca/884477 -
<laga> thanks, building now
<laga> juliank: awesome, it's working.
<juliank> laga: I'll send the patches to kernel-team
<laga> juliank: great
<juliank> laga: patches sent
<laga> :)
<laga> it takes 27s from power-on to having X loaded with aufs in my diskless environment
<laga> that's very nice IMHO :)
<juliank> laga: Could you try to use the rr flag for the nfs root? I need to know if this works.
<juliank> laga: in the aufs mount options
<laga> juliank: i'm not using nfs root, i'm using a squashfs root with a nfs share on top. still want it?
<juliank> laga: your nfs root is specified in dirs= or br=, then yes
<juliank> laga: s/root/share/
<laga> ok
<juliank> I always kill my ssh proxy because I close the window ssh is running in.
<laga> juliank: well.. aufs does not fail, but of coruse the system won't boot because / is read-only :)
<juliank> laga: that's good.
<juliank> thanks
<juliank> exit
<Kano> laga: how about exporting it again via nfs and boot via network?
<Kano> rtg: hi, didnt you say you remove the pci ids when i report the bug?
<laga> Kano: i think if you increase the frequency of your questions it'll get fixed faster
<Kano> rtg: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/185719
<ubotu> Launchpad bug 185719 in linux "remove duplicate pci ids bcm43xx/ssb prism54/p54pci" [Medium,Triaged] 
<Kano> i dislike that idea with blacklisting
<Kano> laga: best tell him that this change is needed, also you could forget the bcm43xx patch when you disable that module (same for prism54), debian disabled bcm43xx
<Kano> bye
<rtg> laga: so what does Kano think is wrong with blacklisting? 
<laga> i have no clue
<laga> in that ticket, he says that it'd break if "discover" was installed
<amitk_> rtg: what version of ALSA is in the stock kernel?
<rtg> amitk_: dunno, some mix of 1.0.15 plus. I've removed it from the kernel for -6.10 and put it in lum (1.0.16rc2)
<amitk_> rtg: aaah...
<amitk_> rtg: are we updating to a newer version of alsa in lum?
<rtg> amitk_: is that the sound of something stuck in your throat ? :)
<amitk_> hehe
<rtg> amitk_: I pulled ALSA this AM, so the version in lum is very current.
<rtg> Its actually -rc2 plus 8 or 9 more patches.
<rtg> amitk_: by the way, I'm still build testing... You mileage may vary.
<crimsun> Jaroslav (employed by Red Hat now) anticipates releasing 1.0.16 final next Tuesday.
#ubuntu-kernel 2008-01-31
<Kano> hi, did you notice the nv 71.86.04 and 96.43.05 drivers?
<Kano> also i man not sure if completely disabling alsa in the kernel is a good a idea
<Kano> there are several modules which have alsa build-deps
<Kano> CONFIG_VIDEO_SAA7134_ALSA=m
<Kano> CONFIG_VIDEO_CX88_ALSA=m
<Kano> i dont think you get those externally
<Kano> also how about adding em8300 cvs to lum...
<Kano> hda-intel is really better in new alsa but you miss modules
<Kano> btw. compiled 386 kernel,as this does not use smp you can use hostap_pci, that module is not smp save
<crimsun> Kano: lum already has newer alsa.
<Kano> i know, i compiled it
<Kano> but you miss modules!
<Kano> these have depends on alsa in the kernel
<Kano> which are not in external alsa
<kraut> moin
<Kano> rtg: why do you completely disable alsa? then modules with alsa depend does not build!
<mvo> how should we handle dapper->hardy upgrades? I assume -686 should transitioned to -generic. what would be people with -386? should we move them to -generic, leave them with -386? there is some code in the release-ugrader already that will move multi-core people from 386 to generic. 
<stgraber> As there are some cases where -386 is needed (very old computers), I don't think moving everyone to -generic is a good idea as it may break some system.
<stgraber> You could also detect the CPU (as you probably do for multi-core CPU) and based on that move them to -generic or keep them on -i386
<Kano> just uname -m
<Kano> if itis not i586 or i686 then keep it
<Kano> i guess it is very rarely needed. i just tested the kernel, and did not really like it, had shutdown problems. ok the system was a e6600 ;)
<mvo> stgraber: thanks, the current strategy is to not change it unless its a multicore cpu, but I was wondering if that is wise given that a lot of people will have -386 on their dapper install. but if the only disadvantage is that they won't have multicore, then that sounds not too bad
<mvo> I like the idea of kano
<mvo_> with the US awake now, maybe I can ask my earlier question again: how should we handle dapper->hardy upgrades? I assume -686 should transitioned to -generic. what would be people with -386? should we move them to -generic, leave them with -386? there is some code in the release-ugrader already that will move multi-core people from 386 to generic. I like the suggestion of simply checking uname -m 
<mvo_> but I wonder what machine will not work with -generic and what the installer does in this case
<mvo_> (or how it detect which ones need -386)
<rtg> mvo_: -generic requires at least a 586 class CPU. 
<mvo_> rtg: so uname -m and checking for i586 is safe? everything iwth i586 or i686 can get -generic then and the rest remains untouched
<rtg> mvo_: that is my belief.
<mvo_> rtg: great, thanks
<zul> whats mask in the linux-ubuntu-modules commit message for external driver?
<rtg> zul: dunno
<rtg> zul: comment it out
<zul> ok
<bdmurray> BenC: still around?
<BenC> bdmurray: in some vague way, yeah :)
<bdmurray> I've suspended and resumed using the Live CD and discovered some SQUASHFS errors in dmesg right after some "Buffer I/O error on device sr0".  Is that worth reporting?
<Mithrandir> the live CD shouldn't allow suspend.
<bdmurray> I thought it should allow suspend and not hibernate.
<Mithrandir> your CD reader might well be connected over USB, in which case you'll go boom
<bdmurray> hmm, that's true.  having it seems like a good way to get people to test suspend w/o having to install the development release though
#ubuntu-kernel 2008-02-01
<BenC> bdmurray: I'm pushing a change to enable usb persistent, which might help
<Kano> hi, why are so many old ide drivers enabled? i prefer a config completely without CONFIG_IDE...
<Kano> otherwise some new laptops dont boot at all
<BenC> Kano: i haven't seen evidence that an ide driver being enabled keeps a new laptop from booting
<BenC> Kano: and not all ide drivers/chipsets are replaced by libata-pata ones
<Kano> one new samsung laptop only boots with that specific config
<Kano> then the generic pata works in most cases
<BenC> point me to a bug report or more information
<BenC> Kano: we can't work 'in most cases'
<Kano> kanotix thorhammer rc7 used a kernel completly without config_ide and there are only very few bad reports
<BenC> especially if 'most cases' == regressions
<BenC> oh well, every dist is different
<Kano> it is based on ubuntu git 2.6.24 kernel
<BenC> i'd much rather find out why the samsung couldn't boot in our current config
<BenC> Kano: we are less than 3 months from release, too late to discuss now about disabling ide
<Kano> well i do that in my mod then. before you release i use etch as base and only a modified kernel
<BenC> if you have specific information about the problem you are talking about, then i can look into it...otherwise this is a waste of time...again
<JanC> I have at least one desktop system (P3 on an MSI mobo with Via chipset) that still has /dev/hd* devices in gutsy...
<ln-> besides, you cannot expect ubuntu to run on every machine.
<Kano> btw. did you test the amd64 desktop iso?
<Kano> it does not show any splash
<JanC> an from what I can see, this is not uncommon for older systems
<Kano> i386 does
<BenC> Kano: so you don't have information on this samsung/
<BenC> Kano: i tested it today, fresh install, and it has working splash
<Kano> BenC: it is not my laptop,but when the user is online i can talk to him
<Kano> why fresh install, i talk of the live cd
<BenC> Kano: uh, because i did an install of a live cd...was pretty sure that was cleae
<Kano> also do you think disabling alsa in the kernel is a good move?
<BenC> clear
<Kano> maybe depending on your gfx card
<Kano> this was x700 se
<Kano> ati
<BenC> this was an ati as well, don't have the exact chipset, but it was mobility
<BenC> Kano: not sure what you mean by disabling alsa
<Kano> one of the last changes
<Kano> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=255995ce42b024e084500e570ae3e357f7647480
<BenC> if that's been done, it's because alsa will be moved to lum
<Kano> yes but lum does not contain all
<Kano> also when you compile external modules which would provide alsa sound that will not work
<Kano> expect the ones from alsa
<BenC> we know this, and are providing the headers for the lum modules separately
<Kano> example
<Kano> CONFIG_VIDEO_SAA7134_ALSA=m
<Kano> this is the sound module for a video card
<Kano> not in alsa at all
<Kano> same for cx88-alsa (ok, maybe not so often needed as dvb)
<BenC> we know this, and are going to work on making sure everything is there
<Kano> you could add then em8300 too
<BenC> we spent lots of time at uds discussing this exact situation
<Kano> maybe let it default to oss
<Kano> do you know that module?
<BenC> look, without sounding too irritable, i have better things to do than answer a million questions from you right now
<Kano>  cvs -z3 -d:pserver:anonymous@dxr3.cvs.sourceforge.net:/cvsroot/dxr3 co -P
<Kano> em8300
<Kano> needed for dxr3 and similar cards
<Kano> modules dir
<Kano> you could add the firmware too
<BenC> you could spend a little time cloning our tree, adding it, and requesting a pull
<BenC> we do have lots of other things to tend to as well
<Kano> sure
<Kano> that and dmraid45 is missing, then you only need a cooler kernelconfig ;)
<Kano> saily there is no official dmraid patch against 2.6.24 yet
<Kano> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/97655
<ubotu> Launchpad bug 97655 in linux-source-2.6.20 "dmraid45 target please" [Wishlist,Won't fix] 
<Kano> the changes for dmraid work, but i did it for dmraid rc14, rc13 is outdated
<ln-> Kano: you are wasting your time.
<Kano> you dont want raid5 ?
<ln-> no.
<Kano> stupid
<kraut> moin
<Kano> rtg: Blacklisted bcm43cc and prism54?
<Kano> the module is bcm43xx
<Kano> also blacklisting would not help for discover
<maks_> disabled in debian :)
<Kano> yes but not in ubuntu
<BenC> I don't think we really use discover
<maks_> BenC: you own me an initramfs-tools sync :)
<maks_> Kamion dude did the klibc part
<Kano> BenC: saidly it is installed by default by live-helper
<BenC> maks_: ah, we do need to sync that
<maks_> xorg should no longer need that crap
<BenC> Kano: used and installed are two different things
<maks_> discover usualy comes with an init script
<maks_> BenC: yep, that be cool
<laga> any ETA on the new kernel upload to hardy?
<rtg> laga: been waiting for the Alpha stuff to thaw.
<laga> are there daily kernel builds on a ppa or something like that?
<laga> otherwise, i'll just do a local build and push to my repo
#ubuntu-kernel 2008-02-02
<zoke> I need to get linux-ubuntu-modules synced with upstream since something new and awesome was introduced
<zoke> see Tormod's latest comment at https://bugs.launchpad.net/ubuntu/+source/linux-wlan-ng/+bug/185179
<ubotu> Launchpad bug 185179 in linux-wlan-ng "card is not recognized in live session" [Undecided,In progress] 
<zoke> should this be synced, this means that the linux-wlan-ng pacakge will not be needed
<zoke> meaning that everything should "just work"
<zoke> since prism2 usb devices are quite common, this would make ubuntu far more accessable to several more people
<freepenguin> now I've finally the page of ubuntu free penguin edition: http://www.freepenguin.it/ubuntufp-download-en.html
<ph8> Hi guys, i've got a Dlink DGE-530T on an ubuntu-server install (with xen kernel from apt), it's detected my network card, it connects at full duplex - it appears however that when i try and transfer large amounts of information into the machine (e.g. a file backup over local network) the network card stops responding - i can't see any error messages, can anyone think of where i should start?
<Kano> hi rtg 
<Kano> rtg: you tried to enabled sound again,but you left out some former active ones like
<Kano> CONFIG_VIDEO_SAA7134_ALSA is not set
<Kano> CONFIG_VIDEO_CX88_ALSA 
<Kano> also why dont you use # CONFIG_B43LEGACY?
<Kano> you could disable the bcm43xx if you like
<Kano> BenC: # CONFIG_B43LEGACY is not set
<Kano> still
<Treenaks> I have a wishlist bug for the usb-storage driver.. should I file a bug on the Hardy kernel package, or try to find an upstream place to ask?
<Treenaks> (if you know how the USB subsystem works, it should be a simple 1-function fix, but I don't know how it works :))
<Treenaks> (it's sending one magic string of bytes to a new device when it's detected, so it switches into a working mode)
<JanC> Treenaks: isn't that something that userspace should do?
<Treenaks> JanC: there's already a "fix" like this for a "nozomi" 3g modem
<Treenaks> JanC: I have a different ("Option") 3G modem, which now requires userspace intervention..
<Treenaks> JanC: but I can't get to it soon enough (the device firmware crashes if the usb-storage driver talks with it for too long)
<Treenaks> and udev doesn't see the device before it breaks
<JanC> ah, right
<Treenaks> so now I have to manually run that program manually every time I plug it in..
<Treenaks> -manually
<JanC> hm, a belgian 3Gmodem ã 
<Treenaks> JanC: yeah, once it works, it's great.. but initialization sucks a bit :)
<Treenaks> It might even annoy me enough to brush up on my C skillz and learn the kernel USB API :)
<blueyed> Does somebody mind to comment on bug 188226? I think this should be decided asap.
<ubotu> Launchpad bug 188226 in linux "Kernel should use CONFIG_FAIR_CGROUP_SCHED" [Wishlist,New] https://launchpad.net/bugs/188226
#ubuntu-kernel 2008-02-03
<patko> my cdrom mounts only if I remove the ata generic driver on fujitsu xa2528
<patko> my dmesg: http://forum.ubuntu-fr.org/viewtopic.php?pid=1508516#p1508516
<kraut> moin
#ubuntu-kernel 2009-01-26
<Kano> hi, did anybody port snd-bt-sco to 2.6.28 yet?
<johanbr> that's been deprecated for a long time
<Kano> and is the new varinat working or not
<Kano> as that required a kernel patch too
<johanbr> works for me
<Kano> whats the package with the client tool
<johanbr> bluez... at least in jaunty
<Kano> will take a look
<emgent``> hello.
<Kano> hi rtg 
<rtg> Kano: 'morning
<Kano> are you working on 2.6.28.2 yet?
<rtg> yep, just haven't pushed it yet as its an ABI bump
<amitk> rtg: when do you expect to push?
<Kano> i know, i have got a new alsa workaround
<Kano> just need to find the correct postition
<Kano> who was the alsa maintainer here?
<rtg> amitk: likely today. I'm traveling beginning Wednesday, so if I don't get it started soon, I won't get all the packages uploaded in time.
<rtg> Kano: what is the alsa workaround?
<Kano> http://www.alsa-project.org/db/?f=bf479d3ab19f7ac37f7c1a17d4d4210de8fe5e1c
<Kano> this system needs model=laptop
<Kano> to get the mic working
<rtg> Kano: you need to talk to TheMuso about patches in user space.
<Kano> i created other alsa patches already, just to need to remember the correct postition
<Kano> sometimes it is easy when you can use other patches as example
<Kano> you still have got snd-bt-sco in media but not enabled it seems
<Kano> well it must be in connexant file it seems
<Kano> will test it
<Kano> there are already some other hp workarounds in there
<`emgent`> BenC: around ?
<`emgent`> there is a critical problem in hardy kernel, some times dhcp association with ethernet card (driver r8169) work and some times not.. i found a fix in kernel.org GIT
<`emgent`> http://git.kernel.org/?p=linux/kernel/git/jgarzik/netdev-2.6.git;a=commitdiff;h=523a609496dbc3897e530db2a2f27650d125ea00;hp=e93dcb11dd6468000f2f018bd887e94b074ce931
<`emgent`> someone can take a look ?
<Kano> http://kanotix.com/files/kernel/unused-patches/2.6.28-patch_conexant-hp_dv6700.diff
<Kano> most likely that,but will do a test 
<`emgent`> kanotix ?
<`emgent`> O_o
<`emgent`> BenC: anyway when you have time take a look danke.
<Kano> rtg: can you push it now? i dont want to compile -5 kernel and then -6 again...
<smb_tp_> `emgent`, Do you have a lp bug number for that?
<`emgent`> smb_tp_: no, and i dont have a lp account here.
<`emgent`> i'm at work and i'm involved in a project based on ubuntu hardy.
<`emgent`> so, i found bug and fix..
<rtg> amitk: I pushed 2.6.28-6.16. How long does it take you to test build an ARM kernel?
<smb_tp_> `emgent`, do you have an account privately? if not I file one but it would be good if you could then mail me a bit more information about it.
<Kano> rtg: thanks, will add my patch and compile
<rtg> NCommander: whats the story on this ARM kexec patch that Rusty is objecting to?
<amitk> rtg: too long
<amitk> rtg: are there config changes?
<rtg> amitk: ok, I'll just take a chance that ARM will actually compile. it takes me about 10 hours to build a test kernel.
<`emgent`> smb_tp_: ya i have an account. I'm Master Of Universe Ubuntu Devel.
<amitk> wasn't infinity giving us a porter machine or two
<rtg> amitk: no config chnages that I'm aware of.
<rtg> amitk: yes, I thought the porter was gonna be ready any day now.
<rtg> amitk: do you have an opinion on this kexec patch that I took on faith from NCommander? Is it really borked  as Russel says?
<smb_tp_> `emgent`, Great, if you could create a report later and assign it to me stefan-bader-canonical, so we have something to track the stable updates process, that would be awesome.
<`emgent`> ya will do when i'm back to home.
<amitk> rtg: yes. Which is why I forwarded it to arm list for comments. I would say, revert it for now.
<`emgent`> smb_tp_: danke.
<smb_tp_> `emgent`, bitte
<rtg> amitk: done. I thought it had been tested and worked.
<MalikLamin> hi guys, I need to make my helloWorld driver works on my kernel, its version is  2.6.27-9, it should printk helloworld at the module init, I guess it is the version dependency
<MalikLamin> could someone help me
<MalikLamin> i  'd like to write a module wich is intended to work in multiple versions of the kernels , how do I solve the version dependency????
<mjg59> You can't build a module that will work with all kernel versions
<mjg59> It has to be recompiled against the target kernel
<MalikLamin> yeap, but there are macros that make it possible, not for all kerns, but for some of them...
<MalikLamin> so I dont know what is wrong with my sourcecode
<MalikLamin> it should at least print hello 
<MalikLamin> printk( KERN_ALERT "HELLO")
<apw> looks to be missing a ;
<MalikLamin> no man, not becouse of that
<apw> so what does it say when you try and use it
<DGMurdockIII> hey
<DGMurdockIII> i havy a qustion about a driver
<DGMurdockIII> that i want to be added
<Kano> rtg: do you remember the kernel patch for alsa? it is verified now
<rtg> Kano: there have been about a zillion alsa patches. which one in particular did you have in mind?
<Kano> http://kanotix.com/files/kernel/unused-patches/2.6.28-patch_conexant-hp_dv6700.diff
<apw> cking, yeah i agree, and telling the size of each set is tricky
<cking> apw: perhaps a recap of the points is required?
<apw> my gut is that if the other os does it that way we are less likely to have regressions turning it on, than if it did no
<apw> indeed
<apw> so we have a some recently released amchines which have synaptics touchpads
<apw> when we suspend and resume those touchpads get lost, not reinitialised correctly
<apw> bus analysis shows we are not resetting the auxillary ps/2 bus before trying to reaquire them
<apw> and this is preventing them from being picked up
<apw> other ps/2 mouse drivers commonly do reset before reaquiring the device on resume
<apw> and it is suggested that drivers for other OSs do the same
<apw> ...
<apw> the question outstanding is how to add this reset where it is needed without breaking the existing user set
<apw> options are:
<apw> 1) enable it on the assumption it is benign and offer a module option/dmi list to disable it where this is wrong
<apw> 2) leave it disabled, and add an option to enable it when required
<apw> ...
<apw> to my mind if it is true that commonly other OSs reset first then this should be low risk, but it is hard to know for sure
<apw> so one option would be to enable this for Jaunty with an override available and see who hollers
<apw> the basic question is which set is larger the set which are happy with a reset or those which will break with it
<cking> It is something that we only know if we get a suitable amount of alpha testing
<apw> we have two sets of information
<apw> 1) noone has complained before and we do not have it now in our kerenls
<apw> 2) the other OSs do do it
<smb_tp_> my guess would be, that with 2) there never will be known whether the assumption is true because who will enable an option if nothing is wrong
<smb_tp_> how badly will be the bad case is the question?
<apw> yeah, going 2) is the safe route but will never tell us the answer
<cking> This is a dilemma.
<apw> well we might regress all synaptics touchpads out there
<apw> i think smb_tp_'s point is quite compelling, if we go 2) we will never ever know
<apw> if we go 1) we get shouted at an go 2) if we were wrong
<smb_tp_> So the worst that happens is that a lot of touchpads might not work unless an option is given...
<apw> so 1) is higher risk, but lower maintenance
<apw> that would be the worst case yes
<apw> planning on having a 'disable the new reset' option available
<apw> votes?
<cking> I am convinced that option 1) is a good idea as we have heard that other OS's do it that way 
<apw> i feel 1) for now, with 2 as a fall back
<smb_tp_> Hm, what about an printk to say "if your touchpads goes on strike use this option"?
<apw> smb_tp_, we could do that
<apw> if we believe people look at dmesg of course
<apw> release notes perhaps too if it makes it to release
<cking> smb_tp_: well we will see it when they report a bug :-)
<smb_tp_> That would remove searching for users. And we could say please mail to us if that is not working. So we know whether this hits
<cking> Also, the extra port write should be relatively benign
<smb_tp_> apw, Release notes yes. Unfortunately who really really reads them? ;-)
<apw> heh noone of course
<cking> apw: This is a good opportunity to try it - it's not an SRU fix which could mess up a whole load more 
<smb_tp_> Personally I would vote for 1) with a printk. It is nothing critically that renders a machine unusable. With the print it will be pretty obvious what ifs wrong if it goes wrong.
<cking> Very try - it will be catagorised as a suspend/resume regression.
<smb_tp_> Actually for Jaunty it is not a SRU, yet
<cking> s/try/true/
<smb_tp_> rtg, What would you think?
<apw> ok i think we have a concensus here.  that 1) with option to turn it off and a printk warning when its on
<cking> apw: I'm happier with that now we've thought it through
<apw> i think if i pencil in the dmi matching code, then switching the default would be a trivial 1 bit change to the patch should it be deemed crap by release
<cking> apw: good call
 * smb_tp_ nods
<rtg> smb_tp_: what do I think about what?
<apw> ok i'll take that as the plan, and if rtg changes things, its only a 1 bit change still
 * rtg is ripping his hair over CRDA.
<smb_tp_> rtg, About what we discuss here. Its is something for Jaunty you know. :)
<rtg> smb_tp_: and you want me to read 47 minutes of scroll back? 
<apw> the short summary is that some synaptics touchpads do not work following resume if they are not reset first, the other OS apparently does so we do not
<rtg> didn't I already see a patch for that?
<cking> you are kidding?
<apw> so the options are we add it and allow it to be disabled, or we allow it to be enabled, but the belief is all new synatics will need it
<apw> where did you see a patch for that?
<rtg> I think it came from Mario at Dell. It might already be in the Jaunty tree
 * apw checks, but i am using very recent jaunty kernels
<apw> mario did file the bug which you would have had email from too
<rtg> apw: It'll come to me eventually.
<apw> nothing since july in those drivers (patch wise)
<apw> he has been hastling about it as some of their machines are affected
<rtg> nothinhg in Hardy or Intrepid?
<cking> and I've been drowning in "Critical" issues to fix it so I passed it to apw
<rtg> and its 'hassle', no T
 * apw goes check
 * cking notes that the problem with dictionaries is that one needs to be able spell correctly to be able to look up the word you need to check
<apw> indeed.  and that if you are dyslexic at all then you can't even see the error
<rtg> apw: whats the only thing I ever hassle you about :)
<apw> there is no obvious difference in reset handling from hardy to jaunty
<apw> so it must be something else related i guess
<apw> heh ... not using this channel?
<rtg> maybe I was hallucinating, but I sure thought I remembered a touchpad reset patch.
<johanbr> I believe you're talking about https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317270
<ubot3> Malone bug 317270 in linux "Dell Studio XPS 16 touchpad doesn't return from resume" [Medium,In progress] 
<rtg> anyway, a DMI based reset is fine with me.
<apw> rtg the main question is the default, on or off
<rtg> we should annoy upstream with it as well. they might have some thoughts.
<apw> we are tending to on for jaunty 
<apw> yes if we wanted to defualt on, upstream would be the first place i'd wanna send it
<rtg> default to off for Intrepid preserving current behavior?
<apw> we have been only asked for Jaunty
<apw> so i wouldn't be looking to modify there, but i guess off if it went there
<apw> and on in jaunty
<rtg> go for it then. we have time to find regressions.
<apw> thanks all, i call that concensus
<ch05en> Hi, I've got a repeatable bug in the UDF filesystem that enables me to crash my box at will
<ch05en>  If you create a file with illegal utf-8 filename and copy it over to a writeable udf filesystem you panic the box
<laga> ch05en: report a bug and mark it as a security vulnerability
<ch05en> ok
<laga> i'd say ;)
<EagleScreen> any plan to move to 2.6.29 for Jaunty?
<rtg> no plans
#ubuntu-kernel 2009-01-27
<dandel> the kernel has a acpi regression on certain toshiba laptops. ( not sure how to read this tho )
<dandel> @bug 294323
<ubot3> Malone bug 294323 in linux "Special Function keys broken after upgrade ( Toshiba Satilite P305D, 2.6.27 kernel) (dup-of: 261318)" [Undecided,New] https://launchpad.net/bugs/294323
<ubot3> Malone bug 261318 in linux "Regression: new Toshiba Laptop Support (tlsup) driver breaks Toshiba hotkeys; input device does not support 'kbd' input handler" [High,In progress] https://launchpad.net/bugs/261318
<pwnguin> dandel: intrepid or jaunty?
<pwnguin> dandel: fwiw, my laptop acpi keys work today, they didnt a few datys ago
<dandel> intrepid/jaunty from hardy
<dandel> i used the jaunty kernel on intrepid and the keys worked.
<dandel> however when i do a suspend it kicks out almost always and the battery power don't always read the status right.
<dandel> i posted the bug details too, i checked everything, and some change in how interrupts where handled caused this.
<dandel> i even included the traceback i got during boot too... 1 sec... going to boot up the laptop, is the update path from 8.10 to 9.04 cleared to not fail in any manner?
<dandel> oh, and when i turn the laptop off with shutdown on the 2.6.27 and 2.6.28 kernels it resets the system
<dandel> ok... 2.6.28-5 disables irq9 on me... with the latest dev files.
<dandel> and suspend is just as broken as ever.
<dandel> @bug 294323
<ubot3> Malone bug 294323 in linux "Special Function keys broken after upgrade ( Toshiba Satilite P305D, 2.6.27 kernel) (dup-of: 261318)" [Undecided,New] https://launchpad.net/bugs/294323
<ubot3> Malone bug 261318 in linux "Regression: new Toshiba Laptop Support (tlsup) driver breaks Toshiba hotkeys; input device does not support 'kbd' input handler" [High,In progress] https://launchpad.net/bugs/261318
<dandel> i got the update done, to the 2.6.28 kernel, however regression is still there on suspend
 * popey pokes apw with bug 321813 (as suggested by Ng)
<ubot3> Malone bug 321813 in gnome-power-manager "[jaunty] system re-suspends itself after wake from suspend" [Undecided,New] https://launchpad.net/bugs/321813
<Ng> (I spied apw mention a similar thing elsewhere around the same time popey mentioned it ;)
<apw> popey, ?
<apw> yeah i am whining about it
<apw> popey, ahhh ... yes your bug is a dup
<dballester> hi to all
<apw> popey, bug #306310
<ubot3> Malone bug 306310 in linux "Resume (from memory) goes back to sleep automatically" [Medium,In progress] https://launchpad.net/bugs/306310
<dballester> I'm using desktop ubuntu 8.10 kernel 2.6.27-9-generic x86_64, looking for /proc/sys/vm/page_cache and doesn't exist. Do you know if you use any patch invalidating the user to modify the % of memory usable as cache?
<dballester> or have you introduced a new way to do it?
<dballester> thanks
<popey> thanks apw 
<apw> i did a fair bit of analysis on it and on my laptop there seem to be two separate buttons pressed, and and xevent detected.  i suspect if you get 'only' two suspends for each press, that you get one hal key and one xevent
<apw> you should find things ok if you use user-switcher menu to suspend
<apw> popey, could you test the user-switcher suspend
<popey> ok
<popey> yes, thats fine
<apw> perfect, so it does sound exactly like the one i have marked it dup of
<apw> i am not convinced it is a kernel issue.  or i should say its possible that getting two hardware keys like i do for a triple suspend may well be
<apw> but i think there is an interaction between X and hal which is triggering the remaining (your only) two suspends
<popey> would xev tell me if I'm getting two events?
<LimCore> hi
<LimCore> it seems that sata performance is epically low in some ubuntu kernels. I get x10 slower time transfer (6 MB/s) then normal for this hard drive (60 mb/s)... Any chance to have this fixed soon?
<LimCore> Im on ubuntu 8.04 amd64  2.6.24-22-generic
<LimCore> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/119730
<ubot3> Malone bug 119730 in linux-source-2.6.22 "Slow SATA performance" [Undecided,Won't fix] 
<klotz> I have installed linux-crashdump in Intrepid and am getting "memory not reserved" on reboot; I would like to debug a kernel crash.  I have searched launchpad.  Can anyone help me validate my linux-crashdump procedure?
<CarlFK1> klotz: I have no idea what crashdump is, but do you know about netconsole?
<CarlFK1> (sounds like it may be the same)
<CarlFK1> klotz: on buggy box: modprobe netconsole netconsole="@/,@192.168.1.155/"
<klotz> linux-crashdump preserves vmcore after a crash and lets you analyze it; I am filing a bug on it not working and will post bug number here.  But thanks for news on netconsole.  I will read up on it; perhaps there is some dmesg output being lost.  Thank you CarlFKl.
<CarlFK1> on 192.168.1.155 box: $ netcat -u -l -p 1133
<klotz> Thanks I will do that, CarlFK1.  Bug for linux-crashdump installation is 321970.
<klotz> CarlFK1 I used "@/,6892@192.168.x.y/" since I wasn't sure 1133 was default port or not. thanks!
<CarlFK1> did it dump anything?
<klotz> No output from netcat yet.  modprobe succeeded.  dmesg says "network logging started"
<CarlFK1> whoops, 1133 isn't...  6666 is :0
<CarlFK1> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317227
<ubot3> Malone bug 317227 in linux "skb_over_panic skbuff.c:128 invalid opcode: 0000 [1] SMP " [High,Triaged] 
<CarlFK1> thre is where I used it
<klotz> Thanks CarlFK1 I will run this and verify later.  Thanks for all the help.
<CarlFK1> glad I could help
<JesperHansen> Is it possible to compile the Atheros 802.11 from module-assistant? If yes, then what is the name of the wireless card in MA?
<maxb> JesperHansen: "the Atheros 802.11"? You mean the ath5k driver?
<maxb> Or possibly ath9k
<maxb> or possibly even madwifi
<JesperHansen> ye... Perhaps one of them. I only see the alias in Hardware Drivers
<maxb> ok, well, first up: Which release of Ubuntu are you using? And then, why do you want to compile it?
<JesperHansen> 8.10 and I want to use the 2.6.28 kernel tree so I can get ext4, so I can get rid of the intense fsync() hang in firefox on sqlite commits
<maxb> I'm not aware of an m-a packaging of the module but if you are building your own kernel, why not just build the atheros module as part of it?
<JesperHansen> atheros module is in the 2.6.28 tree?
<maxb> Well, it's certainly in the 2.6.28 jaunty kernel, which I assume means its in the standard tree
<mjg59> Yes, ath5k and ath9k are both in .28
 * JesperHansen sets in for a compile
#ubuntu-kernel 2009-01-28
<JesperHansen> brb in 8 hours. 1GHz compiling netbook ftw.
<JesperHansen> maxb: thanks
<dandel> hmm, my acpi bug might of been worse than i thought.
<dandel> when i try to suspend the whole system tries to suspend and then just flat dies ( can't even ssh in to it, only fix is to hard boot it )
<dandel> @bug 294323
<ubot3> Malone bug 294323 in linux "Special Function keys broken after upgrade ( Toshiba Satilite P305D, 2.6.27 kernel) (dup-of: 261318)" [Undecided,New] https://launchpad.net/bugs/294323
<ubot3> Malone bug 261318 in linux "Regression: new Toshiba Laptop Support (tlsup) driver breaks Toshiba hotkeys; input device does not support 'kbd' input handler" [High,In progress] https://launchpad.net/bugs/261318
<dandel> that was mislabeled, and got marked as the tlsup regression, however the issue is even further issues.
<dandel> 2.6.24 kernel had working acpi (without the tlsup package. )
<dandel> 0o' ok... this is new. can't even mout the loop back.
<JanC> JesperHansen: eh, I compiled a linux kernel on a Compaq Armada Pentium MMX 166MHz in (much) less than 8 hours?   :P
<JesperHansen> JanC: I am guessing you selected what you wanted or already had a compile complete.
<JesperHansen> But I am lazy here and just selected the ubuntu defaults along with kernel default
<JesperHansen> But I see I already had a compile, so I only had to compile the ath module
<JanC> I only compiled what I needed (more or less, I didn't investigate every single option that I didn't understood 100%)
<JanC> but still, that laptop had 64 MiB of RAM and a very slow hard disk
<JesperHansen> But its complete compiling and installed, so I'll try and reboot
<JanC> ã
<JesperHansen> brb
<JesperHansen> hmm.. that didn't go well
<JesperHansen> hmm.. compiled the kernel with ext4 along with fakeroot make-kpkg --initrd kernel_image kernel_headers. Installed it, along with grub (0.97-29ubuntu48). And booting into the kernel then doing tune2fs -O extents,uninit_bg,dir_index /dev/sda1, and fsck -pf /dev/sda1, then rebooting, only to see grub fail. I am guessing I forgot to change fstab. 
<JesperHansen> The msg. given is: mount: mounting /dev/disk/by-uuid/that-long-uuid on /root failed: Invalid argument
<JesperHansen> which file in the busybox directory tree contains the information about which arguments is passed to mount?
<maxb> erm.... I'd be very surprised if the grub shipped with intrepid could boot off ext4
<JesperHansen> it doesn't
<JesperHansen> that's why i took... the one in 9.04
<JesperHansen> http://changelogs.ubuntu.com/changelogs/pool/main/g/grub/grub_0.97-29ubuntu48/changelog was added in 0.97-29ubuntu47, the one in 8.10 is 0.97-29ubuntu45
<maxb> huh
<maxb> playing mix-and-match between distroversions scares me
<maxb> but if you were going to have done that all along you might as well have grabbed jaunty's kernel rather than building your own
<JesperHansen> well, not gonna help much now :)
<JesperHansen> wonder if I should have grub updated first, then initramfs
<maxb> hmm
<maxb> I don't really know about the boot process in-depth
<maxb> but I'm wondering if there's a program in the initramfs that needs ext4 support to be able to find the uuid
<maxb> Sounds like falling back to a good old /dev/sdXY would be worth a try
<JesperHansen> hm, says the same as with the uuid format. The uuid also links back to the /dev/sda1 device node. But it still tries to mount it as ext3 and erroring because of unsupported optional features.
<kaimerra> I am running Hardy and checked that my kernel config has AHCI module support.  How would I use that instead of the default ata_piix?
<JesperHansen> kaimerra: you could blacklist it? Probably someone will come with a better suggestion
<kaimerra> its worth a shot :)
<JesperHansen> I wonder if I compiled ext4 into the kernel or as a module by now... 
<JesperHansen> ah, grub finds out its ext4
<kaimerra> blacklisting ata_piix did not work, it still loaded
<JesperHansen> seems like I did compile it as a module and not into the kernel. Didn't even notice what I selected :/
<JesperHansen> ext4 is in the daily build, right?
 * domas kicks hardy kernel
<domas> it doesn't print full stack traces, I had problems in interrupt handler, and kernel was complaining about FS code
<domas> :)
 * JesperHansen beats up grub error 13
<booxter> hello guys! are you interested in fixing SD/MMC card functionality on laptop models with latest Ricoh card controllers? There's an upstream fix you can cherry-pick into intrepid and jaunty
<booxter> here is a corresponding launchpad bug with fix instructions and custom PPA kernel: https://bugs.launchpad.net/ubuntu/+bug/311932
<ubot3> Malone bug 311932 in ubuntu "SD card insertion is not detected on HP EliteBook 6930p" [Undecided,New] 
<smb_tp_> booxter, Thanks for the report. We will look into that. It looks simple enough to be suitable for intrepid.
<booxter> smb_tp_: tnx
<JesperHansen> maxb: got grub2 installed and got ext4 to working
<JesperHansen> the mouse is seriously laggy though
<ion_> According to http://marc.info/?l=linux-kernel&m=114539842118897&w=2, seccomp causes overhead. If that is still true, perhaps it should be disabled in Ubuntu kernels.
<ion_> Ah, commit cf99abace7e07dd8491e7093a9a9ef11d48838ed: âmake seccomp zerocost in scheduleâ
<proppy> Hi, what does SAUCE: mean in ubuntu kernel update context ?
<pwnguin> it means the patch isn't upstream for some defintion of upstream
<pwnguin> think the "special sauce" that makes ubuntu burgers great
<proppy> :)
<proppy> thanks for the clarification
#ubuntu-kernel 2009-01-29
<bbs> hmm
 * bbs merges btrfs into jaunty testing locally
<fabbione> anybody from the kernel team awake?
<smb_tp> fabbione, Would not call it awake but there
<fabbione> smb_tp: wtf is going on with your hardy kernel releases?
<smb_tp> fabbione, Can you be more specific?
<fabbione> yesterday there was an update from hardy-updates that had all the changes that were missing and I reported
<fabbione> today there is an update from -security that kills them all
<fabbione> smb_tp: remember when I come here to say that there were missing commits from 2.6.24 ?
<smb_tp> fabbione, That is because I have to base -security on -updates. I will re-upload a new proposed today
<fabbione> smb_tp: an update yesterday mentioend them in the changelog
<fabbione> bah. this kind of release management stinks
<fabbione> it's far from being serious
<fabbione> specially on an LTS
<fabbione> there have been weeks to get this right
<fabbione> and you are still missing fixes from kernel stable branches
<smb_tp> You alsway had this compared to a -propsed kernel
<fabbione> i don't use -proposed
<fabbione> it was pushed either by mistake or something
<fabbione> fact is that either there is a bug in LP or somebody did push the wrong buttons, stuff like that _should not_ happen
<smb_tp> thosse fixes you mention should not have been in -updates.
<fabbione> well in one way or another they got there
<fabbione> root@vultus5:~# grep proposed /etc/apt/sources.list
<fabbione> root@vultus5:~# 
<fabbione> and i am sure of what i saw because i was happy that i didn't have to rebuild my kernels one more time
<smb_tp> That is bad. Good for you but wrong in the process
<smb_tp> I have to check that
<fabbione> well i strongly recommend you check what happened and why
<fabbione> and also find a way to fix missing fixes a bit faster
<fabbione> it's been over a month now that I reported those
<fabbione> and not all of them affect just second class citizens
<smb_tp> Well, sure
<fabbione> anyway.. enough rant.. need to finish rebooting machines
<fabbione> later
<smb_tp> thanks anyway. later
<johan> Hi, the ubuntu kernel is currently not including the utrace patches, what needs to happen for them to be included?
<apw> smb_tp_, i see there are yet more stable updates being sucked up
<smb_tp_> apw, Yeah, there were more this morning, for Jaunty as well
<apw> yeah mad levels of updates these days
<smb_tp_> a big chunk was the wrappers stuff of our former colleagues. but still quite some more serious stuff as well
<scelestic> hi
<scelestic> i'm trying to figure out what the cleanest way would be to get a openvz kernel in 8.10, seems there's no patches for the shipped kernel and the stable kernels on openvz.org seems to be a bit dated
<smb_tp_> scelestic, I guess the cleanest way would be to build a patchset of openvz tree against the v2.6.27 base and then try to merge those on top of a 8.10 tree.
<scelestic> smb_tp_: alright, will give that a try then
<tjaalton> apw: does linux-libc-dev from linux-lpia ship the drm headers?
<apw> tjaalton, i am just rebasing it to jaunty head as we speak
<tjaalton> apw: excellent, so are you bumping the ABI version as well?
<apw> so i would guess the answer is no right now and yes soon.  _if_ it has its own
<apw> there will be an abi bump yes
<tjaalton> to be in line with the rest?
<apw> i am planning on just incrementing it
<apw> would them being in line be helpful?
<tjaalton> yes, otherwise it's confusing
<apw> hmmm hadnt considered that
<tjaalton> because libdrm-dev currently depends on linux-libc-dev (>= 2.6.28-5.15)
<tjaalton> so I'd like to avoid having different deps for different archs
<apw> i wonder if the linux-libc-dev is the same or an lpia version
<apw> hmmmm
<tjaalton> maybe, but in libdrm's case the only thing that matters is if it has the headers or not :)
<apw> tjaalton, i am not entirly sure i can guarentee that they stay in step
<apw> as there are bound to be different releases in each
<apw> if there are ever more in lpia they will necessarily get out of sync
<apw> and i don't think its recoverable at that point
<tjaalton> let's worry about it then ;)
<tjaalton> when that happens
<tjaalton> or, I'll just bump the deps independently
<tjaalton> not that hard
<lesshaste> hi
<lesshaste> is this the right place to ask about trying to report kernel panics?  Specifically I was looking for help with crashkernel
<bbs> well whats the problem 1
<bbs> and two please write a bug report
<bbs> no matter where you are if you find a panic crash segfault whatever -- write the report :)
<bbs> makes it documented for later perusal and hopefully repair
<lesshaste> bbs, I am afraid it's all very unsatisfactory... For the last few ubuntu kernels including the current  2.6.27-11-generic my system simply freezes with caps lock blinking periodically
<lesshaste> takes anything from a few hours of use to a few days
<lesshaste> so it's not clear to report unless I can set up some sort of crash reporting I was thinking
<lesshaste> I am trying to get kexec working as I thought might provide a way to get something useful to report
<lesshaste> any help much appreciated as I don't really see any docs on this online
<bbs> lesshaste: caps lock or everything blinking
<bbs> that would be an OOPS
<lesshaste> bbs, just caps lock
<bbs> well blinking is an OOPS
<lesshaste> everything else completely frozen
<bbs> any logs?
<lesshaste> ok
<bbs> yes OOPS
<lesshaste> not that I can see.. where should I look in case I missed anything
<lesshaste> /var/log/messages seems to have nothing interesting
<bbs> lesshaste: i'm concerned that maybe it cant be logged
<bbs> but let me check something
<lesshaste> ok thanks
<bbs> hmm
<bbs> lesshaste: what do your dmesg logs say
<bbs> anything weird
<lesshaste> bbs, is that the same as /var/log/messages?
<bbs> what are you normally ding at the time
<bbs> no its not
<bbs> are you familiar with dmesg?
<lesshaste> bbs, where is dmesg logged? Other than the current record you get just by typing dmesg
<lesshaste> or do you just mean the current one?
<bbs> /var/log/dmesg
<bbs> .0
<bbs> .1.gz
<bbs> etc
<lesshaste> of course.. sorry
<bbs> np
<bbs> check for OOPS or syscall or something weird
<lesshaste> looks harmless to me.. would you like to see some?
<bbs> well it would be at the bottom
<bbs> zcat the ones with .gz and | less
<lesshaste> zcat /var/log/dmesg*gz|grep -i oops  ?
<bbs> no
<lesshaste> they all end harmlessly
<lesshaste> with 
<lesshaste> [   36.498604] type=1505 audit(1233257658.981:3): operation="profile_load" name="/usr/sbin/cupsd" name2="default" pid=3920
<lesshaste> [   36.701944] ip_tables: (C) 2000-2006 Netfilter Core Team
<bbs> yes this is standard
<bbs> weirdness
<bbs> what are you normally doing when it hapens
<lesshaste> just using X
<lesshaste> I suppose I always have a web browser open
<lesshaste> and I am using wireless
<lesshaste> it's probably going to turn out to be the madwifi driver in the end
<lesshaste> but it would be nice to actually be able to report something useful!
<lesshaste> you don't think adding crashkernel to the bootprompt
<lesshaste> and using kexec will work?
<lesshaste> hi foka 
<lesshaste> bbs, sorry I have to go in a moment.. what do you think?
<lesshaste> bbs, I would love to fix this
#ubuntu-kernel 2009-01-30
<Shock> hi, is there a 32 bit kernel with PAE enabled?
<infinity> amitk: The ARM porting box (rimu) is online now.
<infinity> amitk: FYI.
<JesperHansen> Does the cursor get laggy after installing the 2.6.28 tree kernel on 8.10?
<JesperHansen> and how do I see the difference between Pentium M and Pentium-4 M=
<JesperHansen> ?*
<JesperHansen> Question: What should I enable in the kernel to get /proc/profile for kerneltop?
<Pirate0> is here sysfs coders?
<Pirate0> or anyone who knows device drivers?
<Pirate0> is here anyone who has made device driver?
<Ng> fabbione: hey!
<Ng> fabbione: I'm told you're the man to know for sparc stuff :)
<Ng> fabbione: I just netbooted a Netfire V210 with the dapper sparc boot.img and the kernel died when I told it which interface to use for DHCP
<Ng> fabbione: I'd prefer to be using hardy, but I'm not sure if that will work now that sparc is unofficially supported
<smb_tp> Ng, fabbione uses a self compiled hardy kernel (there is some fix missing in the kernel currently in updates). But the one I gave to compile for -proposed this morning should now be near what he uses...
<Ng> smb_tp: aha
<smb_tp> *sigh* Its stuck in the accept queue
 * smb_tp goes nudging some archive maintainer
<Ng> smb_tp: so the box in question was running dapper previously and I upgraded it to hardy and the kernel doesn't even start
<smb_tp> Ng, It might be this update from stable that I missed. IIRC fabbione said something like it doesn't boot because of this
<smb_tp> Ng, there were two sparc related changes missed "SPARC64: Loosen checks in exception table handling" and "Fix link errors with gcc-4.3"
<Ng> smb_tp: I'm no kernel expert, and maybe there's a quiet option enabled that I'm not seeing in silo.conf, but literally the hardy kernel won't even initialise, it says "Loading linux..." and then sulks indefinitely
<smb_tp> Ng, Right that doesn't sound like the kernel. Unfortunately I only know how to spell SPARC and have never come near one. Is silo somewhat close to lilo code?
<Ng> smb_tp: I doubt it, but I don't know. BenC might, he's credited in the manpage ;)
<smb_tp> Ng, Heh, you can try whether he is fit (health wise) enough
<Ng> smb_tp: i suspect I've missed fabbione for the night/weekend too, so unless infinity has ideas, I guess I'll have to
<smb_tp> I just know that lilo had some problems when the ramdisk went above a certain limit. 
<smb_tp> There you had to give it some "bigmem" option to go on. Otherwise it seemed to crash as well.
<sbeattie> smb_tp: I think the delay on hardy processing may be the finishing out of some -proposed packages that inadvertantly got into the 8.04.2 alt and server images.
<smb_tp> sbeattie, Oh, ok. I was wondering what happened there. fabbione mentioned it this week and first I thought I saw something but then could not find any traces anymore
<fabbione> guys.. just a few minutes.. i need to catch up on a few things
<fabbione> Ng: ^^
<fabbione> Ng: aren't the V210 the ones in the datacenter?
<Ng> fabbione: yep
<fabbione> Ng: so the installer in hardy is borked..
<fabbione> the fix that's missing from hardy will make the machine unbootable after a kernel update
<fabbione> but smb_tp will fix it, or kittens will die
<fabbione> last installation I did was: feisty/gutsy -> update to hardy
<Ng> fabbione: this was a dapper machine I updated to hardy
<fabbione> Ng: to get a more detailed output:
<fabbione> oh
<fabbione> so you were running hardy
<fabbione> hold on..
<fabbione> i can give you the latest hardy kernel + that one patch to boot hardy
<fabbione> but it's a UP kernel
<smb_tp> fabbione, I don't want kittens to suffer. The bug fixes are uploaded but stuck in the queue
<fabbione> or i could give you the patch
<fabbione> Ng: to boot the kernel in verbose mode on sparc you do:
<fabbione> boot: Linux -p
<fabbione> you add the -p
<Ng> aha
<fabbione> i am sure the crash you see is in the MiniRTC driver
 * Ng waits for it to POST to test that
<fabbione> [   22.042878] Mini RTC Driver
<fabbione> [   22.076708] Unable to handle kernel NULL pointer dereference
<fabbione> [   22.143468] tsk->{mm,active_mm}->context = 0000000000000000
<fabbione> [   22.210012] tsk->{mm,active_mm}->pgd = fffff8003042a808
<fabbione> [   22.272400]               \|/ ____ \|/
<fabbione> [   22.272407]               "@'/ .. \`@"
<fabbione> [   22.272413]               /_| \__/ |_\
<fabbione> [   22.272419]                  \__U_/
<fabbione> [   22.448136] swapper(1): Oops [#1]
<fabbione> something like this
<fabbione> (much longer)
<Ng> fabbione: yep, that's the one
<Ng> win
<fabbione> Ng: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.24.y.git;a=commit;h=68b498d251d97de9adda518fda42cfe1451063b7
<fabbione> and this is the fix
<fabbione> you can do a chroot on anotehr machine and build + that fix
<fabbione> or just wait for smb_tp new kerne
<fabbione> Ng: i hope this helps :)
<fabbione> Ng: for the installer.. well i haven't isntalled a box in ages
<fabbione> apt-get dist-upgrade works way too well :)
<Ng> the tricky part is getting a fixed kernel onto the machine since I also can't boot the old dapper kernel anymore (I think because in the process of cleaning up after the upgrade, I removed an unused UP kernel and it rebuilt its initrd)
<bbs> Ng: just boot a sysrescuecd
<bbs> and chroot
<Ng> indeed, I meant remotely :)
<bbs> thats easy peasy :)
<bbs> ah
<bbs> well thats a different story
<Ng> I'm going to be vaguely near it on monday afternoon, so I'll try and do something then
<Ng> fabbione: thanks very much for the info :)
<fabbione> Ng: you can still netboot from that kernel
<fabbione> Ng: so get the fixed one built
<Ng> hmm, interesting point
<fabbione> Ng: then check how debian-installer source turn the kernel into a netboot.img
<fabbione> you won't need to piggyback the initrd as it is already on the disk
<fabbione> the fix is within vmlinuz
<fabbione> put that netboot.img to a tftpboot server
<fabbione> netboot blabla initrd=1/ root=/dev/...
<fabbione> the only tricky part is to get the initrd values right
<fabbione> as silo doesn't undestand /dev/sd*
<fabbione> but IIRC we did setup raid on those boxes
<fabbione> and you should have something:
<fabbione> sda1 -> empty
<fabbione> sda2 -> md0 -> /boot
<fabbione> sda3 -> md1 -> /restoftheworld
<fabbione> in that case you would have:
<fabbione> initrd=1 or 2/initrd-2.6.24-23...
<fabbione> i don't recall if 1 = sda1
<fabbione> or 0 = sda1
<fabbione> so in your setup it's either 1 or 2 to get to sda2
<smb_tp> Ng, BTW, the new kernel package should be on faure. I test build there. Or is that the box you are currently working on?
<Ng> smb_tp: it is
<Ng> I'm going to pick this up next week, thanks guys :)
<smb_tp> Ng, Murphy
<smb_tp> Ng, I hope until then someone accepted the upload to proposed, so you can get the kernel there
<WishingMaster> can any one tell me how to upgrade to latest kernel?
<WishingMaster> what is the address of the repository?
<WishingMaster> any one who knows how to upgrade the kernel?
<Rocket2DMn> hey guys, i need some help deciding what package to place bug 322610 under
<ubot3> Malone bug 322610 in linux "[Regression] Screen brightness not 100% at boot or resume from monitor sleep" [Low,Confirmed] https://launchpad.net/bugs/322610
<Rocket2DMn> I spoke with some guys from the X team, and they think it's probably an acpi kernel issue
<Rocket2DMn> that was my instinct as well - should i keep it filed under linux or place it under something else like acpi-support?
<Rocket2DMn> problem exists for the user in the .27-11 kernel, but not .27-9
<smb_tp> Rocket2DMn, This might be. So linux is correct. Have you tried with acpi_backlight=vendor or acpi_backlight=video, yet
<Rocket2DMn> what do you mean smb_tp ?
<smb_tp> Rocket2DMn, There have been several issues with acpi and baclight. This is an option which can be placed with the boot options in grub. The default is that backlight is controlled by acpi generic driver and also by vendor specific ones. With that option you can try to select one of them only
<smb_tp> Rocket2DMn, But the package is right
<smb_tp> Rocket2DMn, I mean forthe bug
<Rocket2DMn> smb_tp, in the kern.log's there is some stuff about thinkpad_acpi - it looks like it is surrendering control to the generic driver
<smb_tp> Oh, its a thinkpad
<smb_tp> Then there is another place. Sorry it is a bit complex at the moment
<Rocket2DMn> that happens in both kernels, the only real difference i could find was in lshal where 2 udi's were found in the old kernel and only one in the new kernel
<Rocket2DMn> (see comment 20 for my previous statement)
<Rocket2DMn> smb_tp, i understand it's complicated, that's why i'm here :)
<Rocket2DMn> and it's a lenovo thinkpad, not an ibm
<smb_tp> put an entry "options thinkpad_acpi backlight=1" into /etc/mdprobe.d/options 
<smb_tp> Lenovo or IBM doesn't matter in that way :)
<Rocket2DMn> ok smb_tp , ill have my buddy try that, then i'll finish the triage on the bug
<Rocket2DMn> that is just forcing the thinkpad_acpi module to be used, yes?
<smb_tp> Rocket2DMn, Yes, correct. If there is generic support (even if it is not working correctly) it will leave the backlight alone. Please mention the outcome of the option in the bug. 
<Rocket2DMn> ok, thanks smb_tp , i expect the triage will be finished later this afternoon
<smb_tp> Rocket2DMn, No hurry. We know of issues there. It is just hard to fix without breaking several others. ;-)
<Rocket2DMn> heh, i know how that goes.  thank you for your help
<smb_tp> np :)
<mgolisch> heya
<mgolisch> do ubuntu kernels contain any crashdump facility? i allways wondered why there are analisis utilities like crash but i didnt seem to find anything like redhats netdump or something
<mgolisch> would be great if anyone could enlighten me about that
<mgolisch> realy annoying if there is nothing to trackdown kernel panics
<Kano> hi, is something missing in the 2.6.28 kernel so that lvm does not work in the initrd?
<andersk> There used to be.  What version? 
<Kano> -6
<Kano> a 2.6.24 kernel boots
<andersk> Bug 314879 caused LVM to stop working a few weeks ago, but it's been fixed. 
<ubot3> Malone bug 314879 in lvm2 "root on LVM broken since latest udev 136-2" [High,Fix released] https://launchpad.net/bugs/314879
<soren> I believe I fixed that the very day it broke.
<Kano> but i use udev .114
<soren> Erm... That sounds.. impossible.
<soren> Current lvm2, mdadm, devmapper, etc. state Breaks: udev (<< 136) or something like that.
<Kano> older lvm
<Kano> lvm2           2.02.06-4etch1
<soren> etch?
<soren> Erm... You're on your own, dude.
<Kano> so this should work with jaunty?
<soren> It does.
<Kano> will try it
<Kano> could somebody update module-init-tools in jaunty? it is even older than lenny
<soren> You could?
<Kano> i am no u developer
<Kano> i test the live images and reuse the kernel
<soren> is there a problem with the current module-init-tools?
<Kano> not directly a problem, but when i want to use the u fixes and put it in a repo with lenny it does not update of course
<soren> That maps very poorly to anything resembling a priority for Ubuntu.
<Kano> well it would be nice however
<Kano> preXX does not looks so good as 3.4 too ;)
<soren> Incidentally, that also maps very poorly to anything resembling a priority :p
<Kano> also there must be some keyboard issues with some ps2 (via kvm) or usb (mainly ms wireless) keyboard which are new - 2.6.27 did not have those issues
<dtchen> soren: OTOH, encrypted / on lvm remains broken in current jaunty (bug 317297, bug 317442)
<ubot3> Malone bug 317297 in cryptsetup "[jaunty] cryptsetup for root on encrypted lvm not called in initramfs." [High,Confirmed] https://launchpad.net/bugs/317297
<ubot3> Malone bug 317442 in cryptsetup "initrd does not contain conf/conf.d/cryptroot file for encrypted root" [Undecided,New] https://launchpad.net/bugs/317442
<mgolisch> any hints on the crashdump stuff?
#ubuntu-kernel 2009-01-31
<bbs> balbir: hey :)
<apt_get> Hi
<apt_get> I have many link status loged into my console
<apt_get> after switching to another kernel version, this logs dont goes more to console.. but only to kern.log
<apt_get> where can I configure to put state changes of a iface into console
#ubuntu-kernel 2009-02-01
<warren> Hi, does anyone know the status of compcache inclusion in the upstream kernel?
<radii> warren: I haven't seen any compcache patches posted to lkml, which I would suspect should come before inclusion.
<warren> I see.
#ubuntu-kernel 2010-02-01
<matti> OQ
<_stink_> hey folks.  i'm testing LTSP on lucid.  when i installed the alpha, the included kernel was 2.6.32-10, which isn't found in the repos.  now that i've upgraded to .32-12, i'm finding a new bug in a system call, and want to verify that it worked under .32-10.  only problem is that i need a .deb file for linux-generic-2.6.32-10 so i can install it in the chroot that LTSP thin clients boot from.  anyone know how I can find a
#ubuntu-kernel 2010-02-02
<mirsal> ogasawara, ping
<mirsal> ogasawara, if you have some time, could you have a look at bug #115719 and bug 416492 ? 
#ubuntu-kernel 2010-02-03
<octocpp> how do i send acpi_osi=Linux as a boot param while booting from the cd, I tryed acpi_osi=Linux,acpi_osi="Linux",acpi_osi=linux, acpi_osi="linux", acpi_osi=!Linux and evern tryed acpi_osi=eatshit and i ge tthe same result, like a hundred acpi errors saying stuff is not found, I cant make it our bcause it doenst stop scrolling even after like 5 minutes
<octocpp> I have the  insyde h2o bios on this laptop and I cant even boot without calling up acpi=off
<octocpp> i cant seem to even try acpi_osi=Linux
<johanbr> sounds like your bios doesn't handle acpi very well
<octocpp> it is a new bios that changes the way we have to interact with the hardware somehow from what Ive read, I cant believe that windows is the only OS that has the lowdown On how to operate this laptop, it is a Tooshiba Sattelite l505d_es5025
<octocpp> is that what MS is up to now? getting firmware writers to block linux from being able to even use the machine? or is the kernel just falling behind the time a bit? Or should I just return this piece of crap laptop that can only run windows?
<johanbr> it was probably never tested with linux
<johanbr> there are lots of crappy bioses out there
<octocpp> the L303 has worked but i guess there are some acpi issues
<octocpp> I cant even get it to boot without acpi=off, but then I only have one CPU and I am sure a ton of other  problems
<octocpp> is there some common work around for this that I am unaware of?
<octocpp> Or I just have to wait untill they start to work with that Bois in the kernel?
<johanbr> there may be workarounds, depends on how badly broken it is
<johanbr> you could try booting with "noapic nolapic"
<octocpp> yea, Ill try them out reall quick
<johanbr> well, gotta go... good luck
<gnomefreak> is it just me or is 2.6.32-12 broken? i get an error when booting. "something over range" i dont recall first word so i used something
<gnomefreak> i cant report the bug using ubuntu-bug it gives me "The problem cannot be reported: This is not a genuine Ubuntu package" I'm using the Ubuntu kernel
<indus> test
<Ayla> hello
<indus> Ayla, please file a bug first , they will only look at that
<indus> bye
<Pici> We've stopped having random channel attacks since moving to the new ircd, probably should /mode -q $~a  here (that will let unidentified users speak)
<Pici> ping me if there are any questions about that. 
<MaximLevitsky> I need sources of kernel package of 2.6.33-rc6, so I could patch them with my driver, and expose in an PPA
<MaximLevitsky> http://kernel.ubuntu.com/~kernel-ppa/mainline/ contains only binaries
<jk-> MaximLevitsky: linux-source-2.6.33_2.6.33-020633rc6_all.deb
<MaximLevitsky> jk-: not that
<MaximLevitsky> I need .tar.gz, .dsc, files
<MaximLevitsky> so I can build new package
<MaximLevitsky> but I guess that make-kpg will do that
<_ruben> why repackage a complete kernel for a driver? drivers can be installed seperately just fine .. ideally using a dkms package for instance
<MaximLevitsky> _ruben: I did several changes in several places
<MaximLevitsky> I sent patches upstream
<_ruben> ah
<MaximLevitsky> This is same reason I patch against 2.6.33
<MaximLevitsky> I initially targeted 2.6.32,  but for merge I ported everything to 2.6.33
<_ruben> guess one of the ubuntu kernel devs will have to help out here .. perhaps best to send an email to the -kernel mailinglist
<MaximLevitsky> Maybe
<MaximLevitsky> Only one question
<MaximLevitsky> Does ubuntu customized kernel 2.6.33 exist?
<MaximLevitsky> or it is vanilla git
<jk-> MaximLevitsky: it's vanilla git
<_ruben> those mainline builds are annlia
<_ruben> err
<_ruben> vanilla
<MaximLevitsky> Thanks a lot
<jk-> so you can probably just make-kpgk it
<MaximLevitsky> jk-: that what I am doing now
<jk-> cool.
<ssam> is there a special way that i should mark Bug #508746 as having a patch upstream?
<ssam> i have linked to the commit in a comment
#ubuntu-kernel 2010-02-04
<gangil> Hi , can anybody direct me to documentation which categorizes the huge source code of the kernel into different parts ? I mean it tells the src code about the X functionality is here and so on..
<gangil> ??
<Kano> apw: you saw 2.6.32.7?
<mirsal> hello
<ssam> is there a special way that i should mark Bug #508746 as having a patch upstream?
<ssam> i have linked to the commit in a comment
<JFo> ssam, there is a way to set an upstream bug watch
<ssam> JFo, i can't find an upstream bug. just the kernel commit
<JFo> ah, then that is ok :)
<JFo> the commit is fine
<JFo> as long as we also know what kernel it is in
#ubuntu-kernel 2010-02-05
<AnAnt> Hello, does linux-headers-2.6.31-19 include the changes in linux-headers-2.6.31-18 ? I ask because I don't see anything about linux-headers-2.6.31-18 in the changelog
<JediMaster> Hey guys, hopefully in the right channel here, I'm trying to upgrade a VM from 9.04 to 9.10, I've tried it in the past and it's failed due to some problems with the kernel
<JediMaster> it's a xen VM, and currently has 2.6.24-27-xen installed
<JediMaster> I've done the do-release-upgrade and not rebooted and I've tried installing linux-image-2.6.31-19-virtual but I get:
<JediMaster> Ignoring non-Xen Kernel on Xen domU host: vmlinuz-2.6.31-19-server
<JediMaster> if it makes any difference I have no access to dom0 only domU
<gangil> Hi , where can I get started with compiling the ubuntu 9.10 kernel , I mean any links..
<gangil> ?
<gangil> Is this the right place to ask beginner kernel questions?
<ivoks> wiki.ubuntu.com/KernelTeam
<ivoks> ?
<ivoks> gangil: i'd start here https://wiki.ubuntu.com/KernelTeam/KernelGitGuide
<gangil> ivoks: I have already downloaded the source kernel linux-2.6.31 , I needed a guide for kernel compilation and starting off with the source code :)
<gangil> I did google it , but didn't quite get good results 
<gangil> If anyone has any easy source or link , please share it
<ivoks> first google link for ubuntu kernel build
<ivoks> https://help.ubuntu.com/community/Kernel/Compile
<ivoks> 7.
<JediMaster> can anyone verify that the linux-image-virtual package will install a xen domU compatible kernel?
<mirsal> hello
<mirsal> ogasawara_, ping
<jepler> I last tuned in to ubuntu kernel development/building for 8.04, where a flavour could apply patches from debian/binary.custom.d/flavour/patchset/*.  Is this facility gone in the lucid kernel?
<lool> apw: I have an issue with "debian/rules updateconfigs": it empties debian.master/config/amd64/config.flavour.preempt and others
<lool> Actually only debian.master/config/amd64/config.flavour.preempt
<lool> and it changes a bunch of configs despite not having changed anything in the configs myself (yet)
<lool> I see rtg just added the amd64 preempt flavour
<lool> Looks like updateconfigs wasn't run after adding the preempt flavour
<apw> lool, ok
<lool> apw: I'm preparing a series of patches updating the configs
<lool> Including one running updateconfigs
<apw> lool, yep its broken right now it seems, i am working on it
<lool> apw: I'm saying, I'm sending a patch as part of a stack which will fix this
<lool> Might actually be simpler if you dont updateconfigs too
<lool> apw: So I'm working on the versatile config, and the update is getting really large
<lool> I'm basically trying to minimize delta with common configs
<lool> Is it ok if I dump this as a very large config update?
<apw> i was juist told you had it down to two config changes by ogra
<lool> apw: That's to fix video output
<lool> apw: Problem is that the versatile config is a mess
<lool> apw: So in subsequent commits I'm trying to bring it in shape
<apw> as its only used to qemu, as long as it boots thats all that matters
<lool> apw: Ok; my goal is to have the config as close to a desktop config as possible
<lool> So I'm working on minimizing the length of the versatile and common.armel files
<apw> well if it was as close as possible  the config changes sahould be reducing delta, and so moving stuff up to common.config ... and that is good so go for it
<lool> apw: That's exactly what I'm doing
<apw> then thats good, when will i get it, as i can't sensibly do any updates if you are doing something so invasive
<lool> However, it's a bit long because things like CONFIG_PCI were missing, or CONFIG_NLS so I have to flip all the right options
<lool> (Since the config update tool defaults to the upstream defaults, not the ubutnu commons IIUC)
<apw> lool, depends how you do it
<apw> if you add CONFIG_PCI to the flavour and rebuild the others will default from the common
<lool> apw: I'm adding everything to the versatile flavour, yet a bunch of new delta keeps appearing after updateconfigs
<lool> I could copy the common config at the top of the versatile flavour perhaps
<apw> lool yep though that is how the config construction is meant to proceed
<lool> Ok; I think I'm done
<lool> I need to test build this huge diff
<lool> apw: So a) it boots (didn't try with a root device) and b) has nicer fonts   ;-)
<lool> I didn't build modules, nor an actual kernel package, just the zImage in the lucid tree
<lool> Now I just need to figure out how to fix my umask when pushing to kernel.u.c
<lool> Ah it's a bug with zsh
<lool> apw: I've sent the pull request
<lool> versatile-config-fixes branch in lool/ubuntu/ubuntu-lucid.git repo
<apw> lool, thanks got it ... have you tested it?  ie. can i just spoon it in in your name?
<lool> apw: As I said, I've booted it to the kernel panic rootfs not found
<lool> apw: Which is an improvement over what we have in archive right now which doesn't output anything (probalby doens't boot)
<lool> apw: I just finished building the modules too
<apw> ok, then i'll shove it into the repo
<lool> apw: So technically, it should be a win and should build
<lool> apw: What I intend to work on next is making more drivers builtin this kernel (storage, ethernet etc.) and that should be it
<apw> i'll squash your first two commits, into a combined 'un-f*ck preempt configs'
<lool> ok
<lool> the second commit is just "updateconfigs" which is why I split them
<lool> (doing updateconfigs without the first fix resulted in the version config being copied in a bunch of places)
<apw> yeah, i am going to squash them for this commit, and then just squash them into the preempt add, as that was just a fook up
<apw> it should never have existed and just will cause issues for M
<lool> Ok
<apw> good spot thanks
<lool> I think that's the only weird thing I saw from preempt/amd64
<lool> But I did cross other oddities between i386 and amd64 while poking armel; nothing serious, just surprizing differences in this or that non-arch specific feature being a module or builtin for instance
<lool> Anyway, the way to go is probably your config enforcer for the core stuff
 * lool => dinner and WE
<lool> apw: thanks for review and merging and have a safe trip back
<apw> lool yeah we have review of that on the agenda for this week if we get that far
<apw> and i think yes we will add rules to keep them in sync through the enforcer
<apw> you too
<lamont> where is umask hidden in /proc/NNN/?
<jk-> lamont: looks like it isn't in there
<jk-> lamont: is this for a once-off thing? or something you need to script?
<lamont> one off
<jk-> gdb -p process
<lamont> I'm actually going to just to a mother-of-all straces to find where it's happening
<jk-> p /x umask()
<lamont> yeah
<jk-> ok, fair enough :)
<lamont> I verified that it wasn't what I wanted it to be, and put a workaround in place for it
<jk-> also, -e trace=umask  may make your "mother of all strace" less "mother of all"
<mirsal> ogasawara, ping ?
#ubuntu-kernel 2010-02-06
<lifeless> apw: you said 'nomodeset' right ?
<apw> lifeless, ack, and rember to try VT switching
<lifeless> tried that
<lifeless> and commented in the bug ;)
<BUGabundo> good afternoon guys
<BUGabundo> sorry to bother on your Saturday,but can anyone take a peak at bug 518058
<BUGabundo> thanks in advance
<BUGabundo> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/518058
<crimsun> some very unscientific, hand-waving comments on -12.17-generic vs. -12.17-preempt: with generic suspend and resume each takes 1s, with preempt each takes 2.5s; casual audio playback/capture (through PA) is largely unchanged between both [largely within a std dev]; battery life is decreased with preempt.
<crimsun> again, nothing extraordinary given what enabling CONFIG_PREEMPT=y does.
<crimsun> (oh, and CONFIG_HZ=1000)
<crimsun> (also, PA is already an RT task via RtKit, so I wouldn't have expected it to change)
<TheMuso> crimsun: Interesting, and not surprising.
<arand> How would I tell which mainline version the -10 and -11 kernels for Lucid are based on?
<crimsun> see either gitweb or the package changelog
<crimsun> e.g., -12.1[67] are 2.6.32.6; -11.15 is 2.6.32.4; -10.14 is 2.6.32.2
<arand> crimsun: cheers!
<arand> I'm forwarding a kernel bug upstream, this seems ok for that purpose?: http://pastebin.com/m6ec89868
<crimsun> arand: for references to daily, please check the associated build log and include the actual git-describe / changeset hash
<arand> crimsun: okays, otherwise seems ok?
<crimsun> arand: I would clarify "built from" to "based on"
<arand> crimsun: ok, for the hash, is that the "commit 56dca4ceb7b39aa4173aa1cb822c860ced2be1ec" line from the build log? And would 
<arand> ... "long<v2.6.33-rc6-228-g56dca4c>" be of any use including as well?
<arand> crimsun: In the case of the log here: http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/BUILD.LOG
<crimsun> yes, and yes.
<arand> crimsun: Okay :)
<crimsun> either would work, but I find git-describe more useful
<arand> crimsun: Ok, reported: http://bugzilla.kernel.org/show_bug.cgi?id=15242 dunno if the acpica-core designation is correct...
#ubuntu-kernel 2010-02-07
<slytherin> apw: FYI ... Latest karmic-security bump for ports-meta causes wrong image to be installed (linux-image-2.6.31-15-*) instead of latest from -security (linux-image-2.6.31-19-*).
<wzssyqa> does lucid's initrd support btrfs as boot?
<wzssyqa> and what about the grub?
<crimsun> hmm, no JFo
<lool> apw: Sorry, for some reason "make modules" seemed to work here, probably it ignores errors, but the kernel .deb build fails for versatile with my config updates; I'm working on it
<lool> It was two issues affecting a dozen of config options
<lool> Ok, I got qemu to actually crash when using kexec
<lool> qemu: hardware error: pl011_write: Bad offset fcc
<lool> Filed #518567
<lool> LP #518567
<lool> Ups echan
<lool> apw: I've sent the pull request for the fixes; it still breaks at the abi check step though
#ubuntu-kernel 2011-01-31
<ttosttos> I'm running 10.10 on a Thinkpad X200... I get a kernel crash when trying to hibernate... suspend works fine... I'm wondering if this is the right way to get some guidance.....
<smb> Hm Thinkpad X200... I wonder whether that was the thing with the tpm driver...
<smb> But gone now anyway...
<smb> Morning
<abogani> smb: Good morning to you.
 * smb waves his cup of coffee to abogani 
<abogani> :-)
<RAOF> Good morning, caffinated sir!
<smb> RAOF, That would be "not-yet-sufficiently-caffinated" :-P
<cjwatson> Could somebody look at bug 709694?  It's RC for 10.04.2
<ubot2> Launchpad bug 709694 in linux-backports-modules-2.6.32 "Lucid package linux-backports-modules-wireless-lucid-generic broken" [Critical,Triaged] https://launchpad.net/bugs/709694
<cjwatson> and it's effectively a regression in lucid-updates
<apw> cjwatson, looking
<apw> cjwatson, it looks to me that it was built (in the canonical-kernel-team PPA with the kernel) but was missed with the pocket copy
<apw> cjwatson, i believe that the version in the canonical-kernel-team PPA is the one intended to complete the -28 set, i am unsure as to why it was not pocket-copied with the kernel meta etc
<cjwatson> apw: so I should do that?
<apw> cjwatson, i suspect so yes, i was just closing the loop with pitti to see if he has information
<cjwatson> ack
<apw> smb, about ? 
<smb> apw, Just came back
<apw> smb, most handy :)  you have some lucid systems still i think?
<smb> apw, One or the other.
<ohsix> apw: cgroup-bin was breaking suspend
<apw> smb, thanks for that
<apw> cgroup-bin ?
<ohsix> the package, it has configs & a daemon to move things into cgroups
<ohsix> some kernel threads didn't like that when there were no resources in the group to get their job done
<apw> ohsix, oh, hrm ... interesting ... so lets get a bug files against that, or your existing bug opened out to that a well ...
<apw> ohsix, that does at least explain why you are one of the few hitting it
<ohsix> i'd had it installed for a few months to poke at it; that was enough to break stuff
<apw> tgardner, didn't seem you had the x35 (3873) cve assigned to you in the sheet ... added
<tgardner> apw, huh. thanks
<Kano> hi apw , did you get my message about RTL8192CE firmware?
<apw> Kano, i saw it mentioned yes.  we may have rebased on upstream firmware base since then
<apw> i have not explicitly checked it is in there
<apw> dpkg-buildpackage -S -rfakeroot -I.bzr -I.bzr-builddeb -I.git -I.gitignore -i'\.git.*'
<apw> sconklin, ^^
<Kano> also the rt8192se driver is crap
<Kano> basically it is in the kernel directly but does not work
<Kano> so you have just got 2 non working drivers
<Kano> the .32 kernel driver version sometimes worked
<Kano> best works ndiswrapper...
<apw> Kano, realtek has a questionable track record with open source drivers, indeed
<apw> we tend to rely on backports modules for those, and much finger crossing
<Kano> but they dont work
<maks_> it's crap hardware too.
<Kano> fee free to send me a minipci card with something better
<maks_> vorlon has a funny post about getting rid of it.
<Kano> well ndiswrapper is ok but...
<Kano> why is the native driver not working
<Kano> maybe you could get testhardware *g*
<Kano> like samsung n510
<apw> Kano, i personally tend to stay the heck away from anything which has rtl in it, just too hard
<Kano> prism 54 softmac is not better, i have got those cards too
<Kano> does never work with 64 bit
<Kano> somehow i only get non working cards
<Kano> and there is not even a win 64 bit driver, at least i did not find one. for 32 bit ndiswrapper would work too,but native work there
<tgardner> sconklin, just uploaded linux-meta 2.6.32.29.34 to the c-k-t PPA to enable compat-wireless 2.6.37
<tgardner> sconklin, you should roll the ABI on everything else in Lucid and get them uploaded.
<sconklin> tgardner: Aye. Is this an exception to the current freeze?
<tgardner> no, this is going into your c-k-t PPA, not the archive.
<sconklin> tgardner: yeah, I just wanted to know how much of a hurry there was
<tgardner> sconklin, well, I think you should have _all_ the ABI dependent packages consistent lest we miss getting one of them copied.
<tgardner> you --> we
<sconklin> yep
<hallyn> i'll try here real quick - any recent update expected to break ability to tether over 3G?
<JFo> <-grabbing an early lunch so I can dig through papers for the Tax people :-/
<apw> hallyn, not that i have heard of no
<hallyn> hm.  this is gonna really screw up my week :)
<hallyn> suppose tmobile coudl be messing with me, but seems unlikely
<hallyn> ok, thanks, i'll start tracing
<Kano> apw: btw. you are right, the firmware is in rtlwifi dir, i used an older driver..
<cnd> sconklin, thanks for the heads up on the w3c touch stuff :)
<cnd> I just reviewed it and have some comments for him
<sconklin> Doug is a really nice guy, would welcome contact. He'll be at LGM in Montreal, I'm pretty sure
<cnd> LGM?
<Kano> apw: just one thing, why does the r8192ce_pci module has got this extra id: pci:v000010ECd0000092Dsv*sd*bc*sc*i*
<sforshee> cnd, are you very familiar with the ntrig digitizer?
<cnd> sforshee, sadly, yes...
<Kano> and the rtl8192ce module from kernel .38 not
<sforshee> cnd, i could use some debugging tips if you have any
<cnd> sforshee, what's wrong?
<sforshee> i have a dell latitude xt2 where the pointer jumps around and clicks all the time
<sforshee> i've had to blacklist the driver just to make it usable
<sforshee> hid_ntrig, that is
<sforshee> it's spewing out multitouch events constantly
<bjf> http://www.zdnet.com/blog/btl/intel-hit-with-chipset-design-flaw-in-sandy-bridge-rollout/44257
<cnd> sforshee, hah, yeah, that's ntrig for you
<cnd> you can try calibrating it
<cnd> that should help
<cnd> let me get you the link
<sforshee> cnd, thanks, i'll give it a try
<cnd> https://wiki.ubuntu.com/Multitouch/Calibration/Ntrig
<cnd> sforshee, I have the same problem on my dell studio 17 with ntrig
<cnd> it's what I use for my MT development
<sforshee> cnd, I saw your name in the driver changelog, so I thought I'd hit you up :)
<cnd> yeah... though most of the work was done by henrik rydberg
<cnd> who no longer is with us
<cnd> and probably never wants to touch that driver again
<cnd> I think it's going to be a festering sore spot for us until ntrig hw is so old that we can just forget about it
<manjo> tgardner, are you suggesting this package ? linux-backports-modules-net-maverick-server
<sforshee> cnd, getting build errors for undefined references to usb functions, is some library needed besides libusb-dev?
<cnd> sforshee, maybe, alas this isn't my code either...
<sforshee> cnd, okay, I'll work on figuring it out
<tgardner> manjo, no, I'm suggesting linux-image-server-lts-backport-maverick
<manjo> tgardner, ack will ask them if that works 
<sforshee> cnd, everything's installed, and I got the build working by manually adding libusb.a in the makefile instead of -lusb, not sure though why -lusb isn't working
<sforshee> but calibrating did fix the problems
<sforshee> thanks for the  help
<smoser> smb, around ?
<smb> smoser, indeed
<smoser> bug 686692
<ubot2> Launchpad bug 686692 in linux "natty kernel does not boot on ec2 t1.micro" [High,Fix committed] https://launchpad.net/bugs/686692
<smoser> seems still broken on i386
<smb> smoser, still is relative. seems differently broken now. I am on it
<smoser> It does function on amd64 now.  which is fan-tabulous. do you want me to open a new bug ?
<smb> smoser, yep likely new bug
<smoser> i'll open a new bug.
<apw> +  /proc/device-tree: can't find root
<apw> an interesting diagnostic from 38
<smb> apw, Interestingly CONFIG_COMPACT seems to have been turned on in Natty now, despite being marked experimental. Sadly turning it off does not help my case... :-/
<apw> smb, i don't think it was one which i was asked about, may have been a requirement for THP or something
<apw> which it did ask about
<smoser> bug 710754 opened
<ubot2> Launchpad bug 710754 in linux "natty kernel does not boot on t1.micro in arch i386" [Undecided,New] https://launchpad.net/bugs/710754
<hallyn> apw: actually it just might be new kernel bug at usbpn_probe+0x28c/0x2c0.  hm
<apw> smb, ^^
 * hallyn pulling down the kernel-ppa daily over neighbor's wifi for a test
<smb> apw, yeah yeah. saw it asked for it as well. :)
<smb> apw, btw, TRANSPARENT_HUGEPAGE selects COMPACTION and that MIGRATION. wibble
<apw> smb, could have done indeed, thats pretty scarey stuff
<apw> that is mel gormans fault if its bust
<apw> (the guy we met in ireland)
<smb> apw, Remember him. Well as said. Its seems still bad with that compaction thing taken back
<smb> but it was a nice red herring
<apw> heh, always like herring-rouge
<apw>   ath: Country alpha2 being used: AM
<apw> tgardner, any idea what the heck that means ?
<tgardner> apw, not a clue
<cnd> sforshee, good to hear :)
<cnd> we should probably package that up...
<sforshee> cnd, it's a hack, i hard-coded the include path
<sforshee> it would be nice to find a better solution
<cnd> yeah
<sforshee> the lib path rather
<sforshee> when I get a few minutes I'll see if I can find something better
<cnd> well, the whole thing too :)
<cnd> a big hack
<sforshee> I'm wondering if there's another libusb somewhere that's getting pulled in instead, because there's no error about not finding the lib, just about unresolved symbols
<cnd> hmmm
<sforshee> cnd, 'readelf -s /usr/lib/libusb.so' shows the missing symbols are present
<hallyn> kernel-ppa daily won't finish booting
<komputes> JFo: can you have another look at https://bugs.launchpad.net/bugs/701561 and let me know if any additional info is needed before assigning it.
<ubot2> Launchpad bug 701561 in indicator-applet "IBM ThinkPad X31 not seen as laptop - battery status not available" [Undecided,New]
<JFo> yep, komputes, I need the apport-collected data  
<JFo> not sure if there was anything else that apw mentioned wanting
<komputes> JFo: that hasn't been collected by opening the bug - apw mantionned that laptopdetect had to be run as sudo, which was done - result being it's detected as a laptop, yet still no battery status
<komputes> JFo: you want apport collect info for the kernel
<JFo> the first bit there didn't make much sense to me "that hasn't been collected by opening the bug" Correct, that hasn't been collected. unless you meant something else. :)
<JFo> I do :)
<apw> komputes, so we do think it is a laptop
<komputes> apw: indeed
<komputes> JFo: will do
<JFo> thank you sir :)
<apw> komputes, so what does the laptop-detect -v say ?
<komputes> apw: "We're a laptop..." 
<apw> but what _exactly_ for example mine says
<apw> We're a laptop (ACPI batteries found)
<komputes> apw: sec
<komputes> apw: "We're a laptop (dmidecode returned Notebook)" 
<apw> komputes, i assume that was sudo yes ?
<apw> what does it say without sudo?
<apw> komputes, ^^
<komputes> apw: yes that was with sudo
<komputes> apw: without it said "We're not on a laptop (no relevant hints found)"
<komputes> hint*
<apw> komputes, what do the following return
<apw> ls /sys/class/power_supply
<bjf> ls
<apw> ls /proc/acpi/battery
<bjf> -EWRONGWINDOW
<komputes> apw: will find out and get back to you on those
 * tgardner --> lunch
<bdmurray> JFo: bug 710371 has been tested with the upstream kernel build but I'm not familiar with your tagging policies
<ubot2> Launchpad bug 710371 in linux "kernel oops on ssh through ipsec vpn" [Undecided,New] https://launchpad.net/bugs/710371
<JFo> ok, thanks bdmurray 
 * jjohansen -> lunch
<JFo> stepping away for a bit, not feeling too well.
<emgent> good evening
<emgent> We are looking for a wireless linux kernel devloper (injection patches branch), spot job.. someone interested ?
#ubuntu-kernel 2011-02-01
<Kano> apw: is rc3 compiling already?
<apw> Kano, very likely, they are completly automated, i don't start them
<Kano> well the tag was 6h ago...
<apw> yep and they are built daily at about 9am UTC
<apw> that is when build resources are available
<Kano> ah
<Kano> is the build script available?
<apw> yep in the kteam-tools git repository on zinc
<Kano> zinc?
<apw> kernel.ubuntu.com
<Kano> http://kernel.ubuntu.com/git?p=ubuntu/kteam-tools.git;a=summary
<Kano> those then
<apw> quite why you need them so urgently however is beyond me
<darren> g'day people, I think I have a kernel bug, and reading the kernel bug reporting process it says to test the "latest development Ubuntu kernel version", but I'm not sure what and where that is, anyone able to help?
<smb> darren, That would currently mean, is that bug still in the Natty kernel. 
<smb> Which is a 2.6.38 based one. If it is simple to reproduce/test you may use a life cd or usb stick
<darren> yes but what is it, is it a package I can find somewhere is it a tag in a git tree somewhere ?
<darren> or is a snapshot of the latest live cd the only way to get it ?
<smb> The kernel on its own is a package: So you can get it from the archive, launchpad (https://launchpad.net/ubuntu/+source/linux/+publishinghistory) or the right git tree (git://kernel.ubuntu.com/ubuntu/ubuntu-natty.git)
<smb> Currently the latest Natty kernel is: https://launchpad.net/ubuntu/natty/+source/linux/2.6.38-1.28
<darren> Cool thanks.
<darren> also will I have any problems running a Natty kernel on Maverick ?
<smb> One cannot completely say no, but afaik there are people doing that already. But I would not say that you will not have any problems.
<darren> ok so it can work but might not.
<smb> right. I don't know of any problems yet but there might be. X could have some dependencies unknown or there have been LVM userspace problems in the past with Hardy
<smb> darren, One thing to keep in mind is to install linux-headers*all*, linux-headers-*<your flavour (like generic)>* and linux-image-*<your flavour>* together. That way you have the headers required for any dkms packages (for example the ati or nvidia binary drviers)
<darren> hmm ok
<darren> also before I spend too much time playing with this. When I got the latest maveric kernel my network card stopped working, but when I boot into the older 2.6.35-24 kernel it seems to work fine. Is there anything else that changes when I choose a different kernel from the grub list that I should look at ? or is the kernel the only thing that will be different?
<smb> darren, Mainly the kernel. But there are a few things depending on it: like the initrd or if you have installed backports modules those need to go along
<smb> one things to check would be whether your network card's module came from backports. "modinfo <module>" shows the path it comes from
<darren> so if it is a backport the filename: will have backports somewhere in the path ?
<smb> Unfortunately not but it will have an "update(s)" in it instead of "kernel"
 * smb cannot remember whether it was update or updates
<darren> well I can't see either, so I guess it is not a backport
<smb> right, so it sounds like this is a regression in the last update. 
<apw> for regressions in updates we are most keen to know which version you had before
<smb> (in the bug report)
<apw> darren, sounds like we need a bug against 'linux' and when answering say its a 'regression-update'
<apw> run ubuntu-bug linux, that will ask you about the issue including if it is a regression
<darren> should I try the natty daily build before submitting a bug ?
<apw> darren, i would get the bug filed as you want to be running the broken kernel if possible
<darren> "want to be running the broken kernel" well I can run it, but can't submit the bug from it because I can't network
<apw> darren, well indeed depends if you have another option, for example i have wireless and wired on most of mine
<apw> if you can't you can't
<apw> then file it aginst the last working one, and add dmesg at least from the broken one
<apw> and say very clearly you are in the working one
<bdrung> was v4l removed from the natty kernel?
<darren> ok thanks for the help guys
<RAOF> bdrung: Yes.
<RAOF> bdrung: Or, rather, it's removed upstream, so it's removed in the natty kernel.
<bdrung> RAOF: that explains why the v4l plugin of vlc wasn't build
<RAOF> Indeed it does.  Also, why xserver-xorg-video-geode FTBFS.
<boban_> im having problems with PAE kernels
<boban_> anyone to help me reporting bugs?
<boban_> I have HP Probook 4520s with 4GB of RAM
<boban_> System normaly goes to suspend to ram
<boban_> but when i try to power it up, it starts up as it was powered off
<boban_> any sugestions?
<boban_> any1?
<diwic> boban_, for reporting bugs, try the "ubuntu-bug linux" terminal command
<boban_> i see
<diwic> boban_, is it only happening with the PAE kernel?
<boban_> but the isue is only for .37 and .38 PAE kernels
<diwic> boban_, I have a 4520s with 3GB here and haven't experienced the problem you're described.
<boban_> i see
<diwic> boban_, but then I haven't tried the PAE kernel, only i386-generic and amd64
<boban_> Issue is only with .37 PAE kernel
<boban_> i386 and amd64 works just fine
<diwic> boban_, see https://wiki.ubuntu.com/DebuggingKernelSuspend for some initial instructions 
<boban_> i have read those pages
<diwic> and see if you get something fun out of it
<diwic> ok
<boban_> i might just fill bug
<diwic> ok
<boban_> thank u anyway
<Kano> has anybody a fix for fglrx + 38rc3?
<apw> herton, yay ... 
<herton> hello guys
<JFo> hi herton :)
<apw> commit 5ef41308f94dcbb3b7afc56cdef1c2ba53fa5d2f
<apw> Author: Dan Rosenberg <drosenberg@vsecurity.com>
<apw> Date:   Fri Nov 12 12:44:42 2010 -0800
<apw>     x25: Prevent crashing when parsing bad X.25 facilities
<charlie-tca> JFo: any bugs in particular for the KernelBugDay?
<JFo> charlie-tca, looking at bugs in the New state today
<charlie-tca> Okay, I will look too, then
<JFo> mainly interested in making sure they reflect the apropriate status
<JFo> Thank you sir :)
<charlie-tca> Thank you
<tgardner> herton, what is you Launchpad ID. I need to add you to some teams.
<herton> tgardner: herton
<sforshee> bzr branch lp:~utouch-team/utouch/ntrig-calibrator
<sforshee> apw: ^
<apw> apw@dm$ bzr push lp:~apw/utouch/ntrig-calibrator
<apw> Created new branch.                                    
<bjf> herton, welcome
<herton> thanks brad
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<sconklin> https://kernel-tools.canonical.com/srus.html
<quup> hi, when I try to follow this tutorial: https://help.ubuntu.com/community/Kernel/Compile I get 
<quup> $ debian/rules updateconfigs
<quup> dh_testdir;
<quup> dh_testdir: cannot read debian/control: No such file or directory
<quup> is there some way to fix this?
<tgardner> quup, do 'debian/rules clean' first
<bjf> quup, you could try: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<quup> bjf: oh that looks a bit more up to date
<bjf> JFo, you will be attending the meeting ?
<JFo> yessir
<JFo> bjf, need me to do anything special?
<bjf> JFo, nope
<JFo> k
<bjf> ##
<bjf> ## Kernel team meeting in 10 minutes
<bjf> ##
 * JFo is ready
<bjf> JFo, your meeting report "Release Metrics", the "Lucid Updates Bugs" line is missing the trailing "===="
<JFo> gah, sorry about that bjf
 * JFo fixes
<bjf> np
<bjf> http://www.amazon.com/gp/product/B0037H9P4A/ref=oss_product   the essential kernel team debugging tool !
<JFo> oooh
<JFo> I was thinking it was a pitcher :)
<JFo> bjf, we need one of these http://www.kegclub.com/
<bjf> HEHE
<rtdos> just curious: is there a reason there has been more of a significant increase in system requirements in recent releases of ubuntu than in previous versions?
<apw> kees, how often do you merge back the kernel cve traacker?  all my pages seem to be at least days out of date
<kees> apw: I can do it now, one sec.
<tgardner> apw, http://people.canonical.com/~ubuntu-security/cve/pkg/linux.html
<kees> active/CVE-2010-3699: bad line '	The vulnerability described by CVE-2010-3699 probably exists, but I've' (need more than 1 value to unpack)
<ubot2> kees: The backend driver in Xen 3.x allows guest OS users to cause a denial of service via a kernel thread leak, which prevents the device and guest OS from being shut down or create a zombie domain, causes a hang in zenwatch, or prevents unspecified xm commands from working properly, related to (1) netback, (2) blkback, or (3) blktap. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3699)
<ubot2> kees: The backend driver in Xen 3.x allows guest OS users to cause a denial of service via a kernel thread leak, which prevents the device and guest OS from being shut down or create a zombie domain, causes a hang in zenwatch, or prevents unspecified xm commands from working properly, related to (1) netback, (2) blkback, or (3) blktap. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3699)
<kees> you can't use tabs. :P
<kees> it's a single space there...
<kees> (do you use "check-syntax" before committing?)
<kees> also, "Ubuntu-Description" is literally for the USN. anything else should go in Notes
<kees> tgardner: ^^
<tgardner> kees, egads
<apw> tgardner, but it is so easy to use
<tgardner> apw, indeed
<kees> http://people.canonical.com/~ubuntu-security/cve/pkg/linux.html should be updated
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Natty Kernel Version: 2.6.38 || Ubuntu Kernel Team Meeting - February-08 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<JFo> <-need food
 * tgardner --> lunch
<bjf> JFo, the script that generates: http://reports.qa.ubuntu.com/reports/jfo/kernel-buglist-by-team.html is that checked in somewhere ?
<JFo> yessir
<JFo> one sec
<JFo> bjf https://code.launchpad.net/~canonical-qa/canonical-qa-tracking/main
<JFo> it is in the misc-scripts dir
<bjf> JFo, which script is it in that directory ?
<JFo> it is a pair of them
<JFo> KernelBugListByTeam.py and kernel-buglist-by-team.py
<JFo> they are mainly copies of Leann's script changed to create this current list
<JFo> script/scripts
<bjf> JFo, thanks
<JFo> my pleasure
<kees> tgardner: since we're not doing security updates of the arm flavors, can I mark all the arm flavors on https://wiki.ubuntu.com/Kernel/Dev/ABIPackages as "abandoned"? I'm trying to find a way to represent reality, etc.
<tgardner> kees, works for me. I'm not gonna bother with ARM unless someone hollers.
<kees> okay, cool
<kees> tgardner: can we move ti-omap4 into universe for natty?
<tgardner> kees, in fact, we ought to since its not directly supported by the kernel team.
<tgardner> I also don't think anyone is making images from it, but I'd have to ask ogra for sure
<ogra> huh ?
<tgardner> ogra, kees wants to move ti-omap4 into universe
<kees> tgardner: oh, and should I do this for linux-lts-backport-maverick too? it's not been published for -security either
<ogra> we surely make omap4 images
<ogra> thats our omap4 kernel, yeah
<tgardner> kees, linux-lts-backport-maverick is officially supported and is on the 10.04.2 point release
<ogra> what makes you want to move it to universe ?
<ogra> its the official omap4 kernel
<tgardner> ogra, its not getting any security updates.
<ogra> why ?
<kees> tgardner: ah, when will it be respun for security updates?
<ogra> we are paid for providing them
<tgardner> kees, as soon as maverick gets promoted it'll have all the goodness in it.
<kees> tgardner: 2.6.35-25.44 ? it's in -security now.
<ogra> omap4 is 18 months fully supported
<tgardner> ogra, why is it nobody tells me this stuff?
<ogra> tgardner, no idea
<ogra> i thought pete knew about that
<tgardner> ogra, cooleney has been doing the ti-omap4 maintenence
<ogra> that didnt change
<tgardner> ogra, well, _he_ hasn'
<ogra> he still does it for natty
<tgardner> ogra, he hasn't been doing security updates.
<ogra> he is responsible for getting the ubuntu sauce on top of the linaro tree we will get now 
<ogra> since that task was moved away from the kernel team
<tgardner> kees, well, I guess ti-omap4 stays in main.
<ogra> tgardner, well, i dont know who should do them but i'm sure we have to do them
<ogra> i guess thats something pete and david should discuss somehow ;)
<kees> tgardner: ah, so, then, what about CVEs on the maverick ti-omap4?
<tgardner> ogra, yep. if you want security support, then it needs to get on our list of things to do
<ogra> kees, i guess easiest would be if cooloney added the patches 
<kees> tgardner, ogra: okay, so you guys will get that branch included in the cadence process?
<ogra> since he maintained the packages 
<ogra> but that needs to be sorted out on management level
<tgardner> kees, lemme take it up with pgraner. we're pretty short staffed.
<ogra> i think cooloney is the right person but i dont think where thats located resource wise 
<ogra> so needs top level discussion first 
<tgardner> cooloney is out for a couple of weeks
<ogra> i really dont get why that hasnt heppened already
<tgardner> ogra, too much to do, not enough people
<Q-FUNK> hi! what was the URL to the team's repository of stock vanilla kernels, again?  I need to test a 2.6.38 against what's in natty, just to make sure we don't have a regression.
<ogra> tgardner, i mean the assignment of the work
<ogra> to one of the teams
<tgardner> kees, the LTS maverick backport is built in the c-k-t PPA. its ready to be copied to -security
<kees> tgardner: doesn't it have to go through QA?
<tgardner> kees, they don't test anything but Maverick and Natty.
<tgardner> and occaisionally Lucid when we ask real nice
<kees> tgardner: pitti won't pocket-copy without QA sign off. they need to do the testing...
<tgardner> then thas gonna be a real problem.
<JFo> Q-FUNK, http://kernel.ubuntu.com/~kernel-ppa/mainline/
<kees> this is my point from last friday. :P
 * jjohansen -> lunch
<apw> skaet, forgot to mention i did the updates to the release page for kernel
<skaet> Thanks apw!
<JFo> apw, tgardner pgraner what packages do you want duplicate detection turned off for per bdmurray's e-mail?
<pgraner> JFo, didn't get an email
<JFo> went to kernel-team
<tgardner> JFo, likely just linux for now. lets see how well it works.
<JFo> sorry should have specified
<JFo> tgardner, my thinking as well
<pgraner> JFo, +1
<JFo> k
 * apw concurs for what it is worth
<JFo> k, thanks apw
 * apw_ notes that upgrading right now is a huge mistake ... unity core dumps
<JFo> :-/
<apw_> sounds like they may have just found it
<kamal> what's the tool that submits email pull-requests to the kernel-team list?  the thing that creates messages e.g. "The following changes since commit ... are available in the git repository at ..." ?
<jjohansen> git request-pull
<kamal> answer: git request-pull
<kamal> jjohansen: :-) thanks ;-)
<jjohansen> hehe :)
<bdmurray> JFo: I can update bugs tagged regression-proposed to regression-update for you
<JFo> well, not all of them will be bdmurray 
<JFo> sorry, got pulled away on a phone call
#ubuntu-kernel 2011-02-02
<tjaalton> hmm, so x86 suspend issues should be fixed on natty? I still get bug 704550
<ubot2> Launchpad bug 704550 in linux "Lenovo Thinkpad X61 fails to resume from suspend" [Undecided,New] https://launchpad.net/bugs/704550
<lag> apw: It seems we have the right idea already: https://wiki.linaro.org/PackageYourOwnKernel
<lag> apw: Thanks for your help :)
<apw> lag hehe good
<quup> I compiled the kernel just fine, I get the linux-image and linux-headers-...-generic package, the kernel boots and everything
<quup> but I can't install the headers package because: dpkg: dependency problems prevent configuration of linux-headers-2.6.38-1-generic:
<quup>  linux-headers-2.6.38-1-generic depends on linux-headers-2.6.38-1; however:
<quup>   Package linux-headers-2.6.38-1 is not installed.
<quup> how do I get a .deb for that as well?
<apw> quup, what did you build ?  binary-generic ?
<quup> apw: exactly
<apw> you also need to build binary-indep for the common headers
<quup> oh ok, thanks!
<smb> Or binary-headers
<apw> yeah binary-headers looks to do the least
<quup> worked perfectly! thanks :)
<stgraber> apw: oops, indeed, that channel is probably a lot better for that kind of discussion :)
<apw> stgraber, this is the right time to move
<apw> stgraber, so if you could get the whole dmesg in case there is anything before of interest that'd be good
<apw> stgraber, i suspect a locking issue from the diagnostic
<apw> is it easy for you to test a debug kernel in this setup?
<stgraber> yep, as soon as I get the VM re-installed, I'll make a snapshot to make sure I won't trash it again. Then testing will be easy
<apw> stgraber, thanks
<apw> stgraber, i'll shove some debug in and get something building in the meantime
<stgraber> cdimage is a bit slow so I'll need 15min to get a natty desktop image, then I just need to install it, install nbd-server and export some empty file ;)
<apw> my build server may be large, but its not going to be done before you :)
<apw> stgraber, 32 or 64 bit ?
<stgraber> apw: that one is 32bit
<stgraber> though if that's useful for debugging, I had the same issue with 64bit on Monday
<apw> stgraber, ok ... building with some lock debug
<apw> stgraber, don't care, just don't want to make both for speed reasons
<apw> building 32 bit now
<apw> stgraber, kernel will be here in about 5 mins ... http://people.canonical.com/~apw/lp711951-natty/
<apw> stgraber, ok kernel is there
<apw> stgraber, poke me when you have tested it
<apw> kees, could we get a mergy merge please, bored of these results
<apw> kees, how hard would it be to have a shadow set which are built from our tip, just for our packages, obviously emitted somewhere else
<kees> apw: the entire export mechanism is already in the cve tracker. just need to set env vars and type "make" in the toplevel dir.
<JFo> <- grabbing lunch
<apw> kees, got a recipe you use on people ?  then i can just dup it into mine :)
<kees> apw: but I can try to set up an automatic thing
<apw> kees, happy to run it myself if its that easy
<apw> i assume all the pre-reqs are on people if you can run it
<kees> apw: yeah, see ~ubuntu-security/bin/html-report.sh
<kees> apw: /home/ubuntu-security/bin/cron-cve-tracker.sh does the bzr pull before calling html-report.sh
<kees> apw: yup
<kees> you'll need ~ubuntu-security/.ubuntu-cve-tracker.conf for the repo settings
<apw> kees, cool will have a look at it tommorrow
<kees> okay
<stgraber> apw: just got back from lunch, looking at it now
<apw> stgraber, ahh ok
<apw> kees, ok that was so easy its already done :)
<apw> smb, sconklin, bjf, this url points to the kernel package etc as per the cve tracker, but showing the status as from the tip of our branch: http://people.canonical.com/~apw/cve/pkg/linux.html
<apw> auto updating much like the original
<apw> now we are not beholden to security team merges to get team status
<sconklin> "a man with two watched never knows what time it is. A man with one is always certain"
<sconklin> But nice job. At least we know which one to believe
<apw> they just mean differnt things.  one is how we thinkg we are doing, the other is how security think we are doing
<kees> apw: it's so easy to use. :)
<sconklin> yeah
<apw> kees, to get data out of yes :-p
<kees> heh
<apw> but we are instant gratification junkies here
<kees> apw: you may want to start using scripts/check-syntax too, otherwise the exports might blow up a bit if things aren't sane
<apw> kees, tried runinng it, but it needed unspecified pre-reqs to run and exploded in a heap
<kees> hm
<apw> kees, well we'll see it first anyhow, if our own tables explode
<kees> apw: now that you have the ~/.ubuntu-cve-tracker.conf, check-syntax should work
<stgraber> apw: same issue with the new kernel
<apw> stgraber, yeah not expecting anything fixed by it ... but some text in the dmesg 
<apw> with APW in it
<stgraber> http://paste.ubuntu.com/561540/
<stgraber> http://paste.ubuntu.com/561541/
<stgraber> http://paste.ubuntu.com/561542/
<stgraber> first paste is before starting nbd-client, second is after the first nbd-client, third is after the second nbd-client
 * tgardner --> lunch
<stgraber> apw: ^ (not sure how closely you monitor the channel ;))
<apw> stgraber, always best to add my nick, i am easily distracted by shiney objects
<apw> stgraber, have you got the entire thing as one dmesg?
<stgraber> I can cat all of them together ;)
<apw> i think its telling me the storey just not sure
<stgraber> http://paste.ubuntu.com/561545/
<apw> if you are 100% sure its the complete dmesg thats great
<stgraber> I basically did a "dmesg -c" between each so I shouldn't have lost any entry
<apw> [   26.659231] APW: taken
<apw> [   27.660130] Dev nbd0: unable to read RDB block 8
<apw> [   27.660144]  nbd0: unable to read partition table
<apw> [   27.660148] nbd0: partition table beyond EOD, truncated
<apw> [   36.754723] APW: taking &nbd_mutex
<apw> ok ... so that says an error path is not dropping the lock
<apw> not the last one but the one before!?!
<apw> stgraber, damn not enough info to diagnose ... will have to spin you another kenel, you about for a bit ?
<stgraber> apw: yep
<apw> stgraber, ooo might have an idea... what are the userspace tools called ?
<stgraber> nbd-client and nbd-server
<apw> stgraber, ooo I think I have it
<apw> stgraber, ok i have a theory, it might be bunnies
<apw> stgraber, building a test kernel with more debug to confirm
<stgraber> ok :)
<apw> stgraber, ok updated kernel in the same place
<stgraber> apw: ok, downloading it now
<stgraber> apw: http://paste.ubuntu.com/561560/
<stgraber> apw: http://paste.ubuntu.com/561559/
<stgraber> management to connect to it quite a few times, no hang
<apw> stgraber, i assume that is good yes?
<apw> stgraber, shame we didn't know about this a little earlier, we could have had this fixed for a2
<stgraber> apw: yep, that's perfect. I'm doing a bit more testing on it, mounting the same volume 6 times and trying to play with each mount, then unmount
<stgraber> to make sure it doesn't freeze at some point, but it looks great for now
<apw> stgraber, i think the fix is clear so i'll push it upstream
<stgraber> root@isotest-ltsp:/mnt# nbd-client -d /dev/nbd1
<stgraber> Error: Cannot open NBD: Permission denied
<stgraber> Please ensure the 'nbd' module is loaded.
<apw> stgraber, what triggered that
<stgraber> just trying to unmount
<stgraber> s/unmount/disconnect/
<stgraber> seems like I can connect fine but can't disconnect
<apw> hrm, i suspect that thats been in there for a long time
<apw> as nothing has changed other than this locking
<stgraber> open("/dev/nbd1", O_RDWR|O_LARGEFILE)   = -1 EACCES (Permission denied)
<apw> but i suspect its a different bug
<stgraber> that'll still make ltsp to fail as I need to connect, check the block device and disconnect everytime. If disconnect fails, the check will either be pointless or will crash somehow
<apw> well as i say there are exactly 0 changes other than this specific lock change
<apw> which only affect ioctl
<apw> so i am suspicious its not new
<stgraber> wasn't there in maverick ;) though might be caused by the new client
<apw> the EACCESS cirtianly implies the kernel hated you
<apw> stgraber, can you look see hwat nbd devices are listed in /sys
<apw> stgraber, anything in dmesg in concert with the open failure ?
<stgraber> nope, nothing shows up in dmesg
<stgraber>  /sys shows all 16 devices
<apw> stgraber, and are there any nbd-client thingies running?
<apw> and any nbd_threads ?
<stgraber> yep, my 7 nbd-client are still there
<apw> so you cannot stop any of them ?
<stgraber> indeed
<stgraber> and they are still working
<stgraber> so if I do: nbd-client -d /dev/nbd0
<stgraber> I get the error message
<stgraber> then if I try to mount it, it works just fine
<apw> and its not mounted
<apw> what does lsof /dev/nbd1 say
<stgraber> yep, I unmounted all of them before testing the disconnect
<stgraber> COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
<stgraber> nbd-clien 1395 root    3u   BLK  43,16      0t0 5489 /dev/nbd1
<stgraber> same issue using maverick's nbd-client
<stgraber> quickly trying to connect on the same nbd server from a maverick VM to make sure it worked fine then
<stgraber> root@desktop-maverick01:~# nbd-client -d /dev/nbd1
<stgraber> Disconnecting: que, disconnect, sock, done
<stgraber> apw: that's with the same userspace on both natty and maverick, so something must have change somewhere in the kernel
<apw> stgraber, yep ... shame we don't test more often
<stgraber> Should be possible to make some automatic test of it, that's basically what I did to get a test environment: http://paste.ubuntu.com/561547/
<stgraber> then nbd-client -d /dev/nbdX to test the disconnect
<kees> anyone have clues on how to further debug kernel-only edid failures? bug 712075
<ubot2> Launchpad bug 712075 in linux "[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid" [Undecided,New] https://launchpad.net/bugs/712075
 * bjf -> lunch
<ohsix> kees: ask ickle :]
<kees> ohsix: okay, cool
<kees> ohsix: where can I find them?
<ohsix> a lot are just plain wrong though; but theres a sysfs file to write a working cached copy iirc
<ohsix> #intel-gfx 
<kees> ohsix: the issue with this is that it spontaneously fails. it works most of them time and then in the middle of a running session, bombs out
<ohsix> ah
<apw> stgraber, are you able to compile the user space tools ?
<apw> if so could you try changng the open in disconnect() to be a O_RDONLY open and see if it works then ?
<stgraber> grabbing the source now
<apw> not sure if it makes sense that it cannot open it RDWR but wnat to know if that helps
<stgraber> root@isotest-ltsp:~/nbd-2.9.16# nbd-client -d /dev/nbd1
<stgraber> Disconnecting: que, disconnect, sock, done
<stgraber> worked fine
<apw> stgraber, hrm
<apw> stgraber, are there any normal commands, like status ones, from that client
<apw> and if so do they work
<stgraber> apw: hmm, now I can disconnect but can't reconnect after that ...
<stgraber> I have a confcall just now, will continue debugging after that
<apw> try making the other open thats RDWR in the thing RDONLY
<apw> pretty sure you shouldn't need to, but suspect it will work
<apw> stgraber, do you have a complete strace ?
<apw> stgraber, of the sucessful attach the first time
<apw>         if (ioctl(nbd, BLKROSET, (unsigned long) &read_only) < 0)
<apw>                 err("Unable to set read-only attribute for device");
<apw> stgraber, i think it is doing it to itself ... seting the device read only so even it cannot open it
<apw> possibly that is hanging over on last close and it should not, but i think it is right that the disconnect cannot open
<stgraber> apw: making all of them read-only works fine :)
<apw> stgraber, and you can  mount the disk still ?
<bryceh> JFo, mind putting kees' bug 712075 on the kernel team's review list?  Gots a patch from upstream.
<ubot2> Launchpad bug 712075 in linux "[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid" [High,Triaged] https://launchpad.net/bugs/712075
 * JFo opens the bug
<apw> bryceh, JFo done
<JFo> will do bryceh :)
<JFo> ooh, he's quick on the draw that one :)
<JFo> thanks apw
<apw> stgraber, i am not sure if i know if the userspace was broken or the kernel is now broken
<apw> stgraber, will think on that for a bit
<apw> stgraber, can u stress test the open close mount unmounts against it with the new tools
<apw> and let me knwo if anything else goes wrong
<apw> cirtianly test you can read/write files on the filesystems inside
<bryceh> apw, JFo, thanks
<soren> apw: I think 711951 is a dupe.
<soren> apw: I've just sent a patch to lkml to fix a lockig issue in nbd.
<soren> I was looking for the bug reference on launchpad when I found this new one.
<stgraber> apw: http://paste.ubuntu.com/561592/
<soren> stgraber: ^
<soren> https://lkml.org/lkml/2011/2/2/237
<stgraber> soren: so both of you fixed it apparently ;)
<soren> I've just sent the patch to the kernel-team ml.
 * jjohansen -> lunch
<tgardner> soren, has Paul queued it for upstream submission ?
<soren> tgardner: He told me to send it directly to akpm.
<soren> tgardner: I suppose that's a "yes".
<tgardner> soren: ok, I'll pull it in until it conflicts with the next rc candidate.
<soren> tgardner: ta very much.
<tgardner> apw, did you already have something on deck for this nbd lockup ?
<soren> I gues I should hav eincluded this link in my e-mail: https://lkml.org/lkml/2011/1/26/131
<tgardner> soren, I'll include it in the commit log
<apw> tgardner, yes
<apw> about to send it out
<tgardner> apw, check master-next first, perhaps we're colliding
<apw> tgardner, yeah i see that hallyn has a different approach removing it
<apw> hrm
<apw> tgardner, ahh ok so you pushed it, then i'll wait and do nothing
<tgardner> apw, well, they pretty much just ripped it out.
<tgardner> the mutex, I mean
<apw> tgardner, yeah, their argument is its not needed.  hard to say
<tgardner> apw, guess we'll find out when it goes to akpm
<apw> my patch does the opposite, and drops it during the long lived ioctl
<apw> yep
<apw> tgardner, so much for that effort :/
<apw> such is life
<tgardner> some days you bite the bear, some days the bear bites back
<apw> yeah ... food then i recon
<bryceh> apw, I'm about to forward bug #711275 upstream - seems a bit false positive-ish - but want to check first if this is something you already know about?
<ubot2> Launchpad bug 711275 in xserver-xorg-video-intel "[gm45] GPU lockup (EIR: 0x00000010) during boot - EIR stuck: 0x00000010, masking" [Undecided,New] https://launchpad.net/bugs/711275
<bryceh> apw, it appears to me that the GPU is hanging during boot but successfully resetting itself, but this still generates an apport crash report
<apw> bryceh, hrm, doesn't that sound a lot like the other one, the one where they recently said 'blacklisting vesafb fixes things'
<apw> though this continues rather than breaking
<bryceh> yeah
<apw> bug #702090
<apw> and didn't you send that up already?
 * apw pokes ubot2 
<bryceh> apw, yeah you're right
<apw> sounds like they are being luckier, perhaps ask them to try the blacklist 
<bryceh> apw, actually I hadn't sent that one upstream yet, but it does look similarish
<ubot2> Launchpad bug 702090 in xserver-xorg-video-intel "i965gm GPU lockup if vesafb is left loaded (EIR: 0x00000010 PGTBL_ER: 0x00000100)" [High,Triaged] https://launchpad.net/bugs/702090
<apw> bryceh, so i recon send one or other up, and test the vesafb thing on the new one
<bryceh> or maybe it's bug #686388 which I did revisit
<ubot2> Launchpad bug 686388 in xserver-xorg-video-intel "[i965gm] GPU lockup - Invalid GTT entry during Display B Fetch" [Unknown,Confirmed] https://launchpad.net/bugs/686388
<bryceh> anyway can't hurt to send another report up, thanks.
<apw> what happens when we flip over to to the drmfb doesn't bare thinking about
<bryceh> o_O
<apw> layering violations just isn't in it
<apw> we don't give anyone any time to handle the loss of the old driver
<apw> even the people with it open get a nasty shock
<apw> (plymouth)
<bryceh> erf
<bryceh> apw, btw I'm also seeing a spate of 'GPU hanging too fast, declaring wedged!' bugs - #710321  711645  711691
<bryceh>  bug #710321
<ubot2> Launchpad bug 710321 in xserver-xorg-video-intel "[i965gm] GPU lockup during login - GPU hanging too fast, declaring wedged!" [Undecided,New] https://launchpad.net/bugs/710321
<apw> bryceh, does that mean "i reset it a few times and it broke again and i am giving up"
<bryceh> apw, seems like a good guess
<bryceh> apw, but this is the first time I've seen that particular syntax in a message, so dunno if it's generic verbage or something specific
<apw> yeah odd indeed
<apw> 0x00000a78:      0x0a000002: MI_DISPLAY_BUFFER_INFO
<apw> Bad length (4) in MI_DISPLAY_BUFFER_INFO, [3, 3]
<bryceh> huh
<bryceh> that looks promising
<apw> bryceh, that looks bad, wouldn't that be a mesa injection thing
<bryceh> could be
<apw> 0x000010b8:      0x0a000002: MI_DISPLAY_BUFFER_INFO
<apw> Bad length (4) in MI_DISPLAY_BUFFER_INFO, [3, 3]
<apw> more than one in here too
<apw> so if each was breaking it ... that might make sense
<bryceh> where'd you spot that Bad length error?
<bryceh> oh I see it
<apw> in the gpu dump yeah
<apw> of course it could be the dump tool thats wrong :/
<apw> 0x00014a88:      0x0a000002: MI_DISPLAY_BUFFER_INFO
<apw> Bad length (4) in MI_DISPLAY_BUFFER_INFO, [3, 3]
<apw> there are a number in here
<bryceh> yeah the other bugs have it too
<apw> i suspect we could do with an arsenal script to look through these for errors and put them in as a comment on the bug
<bryceh> apw, yeah
<bryceh> actually what I'd like to do is modify the gpu hook itself to extract the warnings for us directly
<apw> bryceh, a better plan indeed if you can be bothered :)
<bryceh> and that's on my todo list, but down under a few other bigger priorities currently
<apw> there seem to be similar quantities of these errors in the ring as there are hangs in the dmesg
<apw> so i suspect they are worth investigating
<apw> bryceh, is there somewhere i could find a document on the format of the ring to see what it says for the sizes etc
<bryceh> apw, btw check out - http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/totals-natty-workqueue.svg
<apw> intel is a problem :)
<bryceh> apw, yeah probably at http://intellinuxgraphics.org/documentation.html
<bryceh> apw, and thus my interest in these gpu bugs today ;-)
<apw> heh indeed
<bryceh> and http://www.x.org/docs/intel/ looks like it has mirrors of the docs
 * apw screams about unity being balls
 * apw cannot cope with the stacking issues
<apw> how hard is it to stack windows in the right order
<jjohansen> apw: obviously harder than crashing
<bjf> apw, jjohansen, look at it this way, it's harder for people to notice kernel bugs when their desktop keeps crashing (or they don't have one)
<bjf> apw, jjohansen, there's a pony in there somewhere :-)
<apw> nice, a bright side
<jjohansen> whee yet another pathological oom killer death
#ubuntu-kernel 2011-02-03
<ohsix> any idea why bug 711429 is nonpublic?
<ubot2> ohsix: Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/711429)
<ohsix> marking a public bug a duplicate of a private one suxxx
<bjf> ohsix, i've added a somment asking why it's private
<ohsix> ok, thanks
<bjf> ohsix, not sure why you are asking in the kernel channel though, you might get more satisfaction in #ubuntu-devel
<ohsix> well, eyes; most things i have to ask about are fleeting in interest :]
<ohsix> it being private is almost good for me; then i don't have to follow up on the public one i posted
<bjf> ohsix, it was marked a duplicate by a bot
<ohsix> right
<bjf> ohsix, i'm trying to find out who "ownes" the bot, it shouldn't automatically mark public bugs duplicates of private bugs
<ohsix> keen, i've had it happen two or three times; wondered why it took that path
<bjf> ohsix, there's probably a way to file a bug against the bot
<bjf> ohsix, email sent, i'm guessing this will get fixed up fairly quickly
<ohsix> much appreciated
<apw> herton, http://reports.qa.ubuntu.com/reports/jfo/kernel-buglist-by-team.html
<apw> https://wiki.ubuntu.com/Kernel/Dev/KernelGitGuide
<apw> https://www.launchpad.net/ubuntu/+source/linux
 * apw pops to run some errands
<lag> Why would debian/tests/check-aliases fail?
<apw> lag, aliases are module aliases i beleive
<apw> does it produce any output when it fails ?
<apw> lag, it should have done
<lag> apw: No it didn't
<apw> it is saying that there are two entries for the same alias
<lag> apw: The 'die' died, but didn't produce output 
<lag> apw: I know what's wrong
<apw> lag, can i see the log up to that point pls
<SamuraiAlba> any fix for the "cannot reserve MMIO region" issue?
<lag> apw: The debian packaging system does not use $(make kernelversion)
<apw> it does make vmlinuz or similar right?
<lag> Instead it looking for ./debian/linux-image-2.6.35.7-1000-u8500/lib/modules/2.6.35-7-1000-u8500/modules.alias
<lag> Sorry, other way round
<apw> it does a make O=debian/build/build-flavour vmlinuz or whatever to be more accurate
<apw> which should work
<lag> Well $(make kernelversion) produces 2.6.35.7
<SamuraiAlba> The "cannot reserve MMIO region" is cutting into my boot time on Ubuntu 10.10 :)
<lag> And the debian packaging system is using 2.6.35
<apw> SamuraiAlba, i don't think i know that issue, got a bug # ?
<lag> So it's not looking in the correct directory for modules.alias
<apw> the default is to install them insto 2.6.NN-ABI-flavour
<apw> that is where they are on my system
<SamuraiAlba> Bug #577842 in linux (Ubuntu): âshpchp cannot reserve mmio regionâ
<ubot2> Launchpad bug 577842 in linux "shpchp cannot reserve mmio region" [Low,Triaged] https://launchpad.net/bugs/577842
<SamuraiAlba> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/577842
<ubot2> Launchpad bug 577842 in linux "shpchp cannot reserve mmio region" [Low,Triaged]
<SamuraiAlba> ahhh
<apw> lag, mumble ?
<apw> feels like we are spinning round each other
<lag> apw: Sure
<lag> apw: https://wiki.linaro.org/PackageYourOwnKernel
<apw> apw@dm$ make EXTRAVERSION='' kernelversion
<apw> 2.6.38
<apw> lag, ^^
<lag> apw: linux-u8500 (2.6.35.7-1000.0) UNRELEASED; urgency=low
<apw> apw@dm$ fdr printenv | grep 2.6.35
<apw> lag, could you paste the output of that
<lag> apw: https://pastebin.linaro.org/19/
<lag> apw: http://paste.ubuntu.com/561921/
<soren> Are kernel uploads to natty on a specific schedule (like e.g. every Thursday) or what triggers an upload?
<tgardner> soren, its fairly adhoc. we're waiting for the A2 release cycle to finish, then we'll upload when -rc3 is out.
<soren> tgardner: I see, ok.
<soren> tgardner: Cool, thanks.
<apw> smb, fyi i see you assigned self to CVE-2010-0435 in the cve tracker, but was not reflected in the Awsome sheet, corrected
<ubot2> apw: The Hypervisor (aka rhev-hypervisor) in Red Hat Enterprise Virtualization (RHEV) 2.2, and KVM 83, when the Intel VT-x extension is enabled, allows guest OS users to cause a denial of service (NULL pointer dereference and host OS crash) via vectors related to instruction emulation. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0435)
<smb> apw, did I? That sounds like some old cruft somehow...
<smb> IOW before awesome sheet existed
<apw> smb, could well be, but as you are assigned noone else will touch it
<apw> and its xen :)
<smb> apw, No kvm
 * tgardner thinks smb likes xen
<smb> apw, But anyway IIRC that was the one I thought had been moved to completed
<apw> oh yeah, doh, can't read for looking
<smb> tgardner, As much as I like tax declarations :-P
<apw> smb, could be ... prob best you sanity check it
<smb> apw, yup, will do. Thanks for the heads up
<tgardner> sconklin, I pushed a bunch of CVE updates on the maverick ti-omap branch. since I cherry-picked them from maverick master-next, do you think we need to go through the mailing list ACK process? I'm thinking not.
<sconklin> tgardner: no, especially if they cherry picked cleanly
<tgardner> sconklin, yep, that was sorta my criteria as well
<apw> tgardner, if the patch had an ack as a patch and applies clean its just noise otherwise
<apw> tgardner, is that a .33 branch?
<tgardner> .35
<tgardner> I went through all of maverick master-next and cherry-picked the CVE patches
<apw> tgardner, i think we should take an ack on maverick to mean an ack for all 2.6.35 based branches; if they arn't a rebase then i'd expect them to get it via cherry without additional comment
<tgardner> apw, yep, I think I'll codify that as policy in the wiki.
<apw> ack
<apw> right i am off-ski  .. speak latetr
<tgardner> apw, later dude...
<lag> kamal: Hi :)
<kamal> lag: hey man, howdy
<lag> kamal: I'm playing around with GPG keys (only because I have to :))
<lag> What's the difference between full and ultimate?
<lag> And how do I change my new uids from unknown to full/ultimate?
<kamal> lag: http://www.queen.clara.net/pgp/art4.html
<lag> Oh, they're already ultimate. They were unknown before?
<kamal> lag: you can mark other people's keys as "full" trust, meaning that you have a high level of trust in their signatures when they appear on other keys ...
<kamal> lag: you should mark (only) your own key as "ultimate", so that gpg will realize that it should absolutely positively trust any key that you yourself have signed.
<lag> kamal: Did you 'make' me do that for you when you signed my keys?
<kamal> lag: when you create your own key, gpg automatically assigns it "ultimate"
<lag> kamal: Make them 'full' I mean
<kamal> I didn't adivse you to fiddle with the trust levels at all
<lag> kamal: Is 'full' the default then?
<lag> kamal: For other people's keys I man
<lag> mean*
<kamal> lag: no, i think the default should be "no trust" for other peoples keys
 * kamal afk for a bit
<lag> kamal-afk: No problem - thanks for your help
<kamal> lag: got it sorted out?
<lag> kamal: I do - thanks dude :)
<kamal> lag: excellent :-)
<amitk> anybody's seen (or done) any changes related to the number of open files in the natty kernel? I've just installed natty for the first time and mutt is constantly complaining about "too many files open".
<amitk> wonder if anything changed in the kernel before I go search for mutt bugs
<tgardner> amitk, nothing that we've done on purpose.
<tgardner> amitk, apw uses mutt. 
<tgardner> as does pgraner IIRC
<amitk> tgardner: yes, I know. I was hoping he'd hit the problem first ;)
<tgardner> amitk, you're just lucky I guess
<bjf> herton, look at https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel  these are the simplest instructions we have, you can build upon them
<herton> ok, thanks
<tgardner> JFo, what tags should a CVE bug have in order to avoid getting spammed?
<tgardner> JFo, bug #711341 for example
<ubot2> Launchpad bug 711341 in linux "CVE-2010-3880" [Undecided,Incomplete] https://launchpad.net/bugs/711341
<bjf> tgardner, i am putting "kernel-cve-tracker" on all my cve bugs
 * JFo adds that to the ignore list
<tgardner> bjf, so much shit to remember, so little ability
<bjf> JFo, i think i mentioned it the other day but can't remember now
 * JFo checks
<bjf> tgardner, i think i put it on the wiki page, will verify
<bjf> tgardner, yup, it's there, 3rd bullet under #2
<JFo> bjf, I don't see it, but I am adding it now
<bjf> JFo, ack
<bjf> tgardner, also part of 3. Create an LP bug
<tgardner> are we both looking at https://wiki.ubuntu.com/Kernel/Dev/FixingCVEs ?
<bjf> tgardner, yup
<JFo> k, fixed and pushed. Let me know of any other tags you want ignored as you remember them :)
<bjf> there is a section above where you added your ARM branch text "3. Create an LP bug"
<bjf> tgardner, ^
<tgardner> bjf, sconklin: I'm rev'ing the ARM kernels beginning with Lucid. where is the wiki page that shows all of the flavours and notes for maintenance?
<sconklin> stand by while I find it
 * tgardner did a lazy search with no results
<JFo> doing another script run now, let me know if you see any other glaring fails
<bjf> JFo, can you approve my nominations for bug #712609 ?
<ubot2> Launchpad bug 712609 in linux "CVE-2010-4248" [Undecided,New] https://launchpad.net/bugs/712609
<JFo> yessir
<JFo> bjf, done
<bjf> JFo, thanks
<JFo> my pleasure
<apw> amitk, yep i use mutt, have used it relativly recently on .38 i thought
 * apw wonders at the wonders of 3G
<amitk> apw: I'm running 'watch -n20 "lsof | grep mutt | wc -l"' to track the number of open files, 884 currently (in ~1hr)
<JFo> smb, is bug 445456 still a CVE issue or is it marked incorrectly?
<ubot2> Launchpad bug 445456 in linux "kvm hangs booting windows XP Pro SP2 or later, since at least 2.6.28-15" [High,New] https://launchpad.net/bugs/445456
<smb> JFo, I don't think that ever was one. But let me quick check the reference
<JFo> ok
<JFo> has a CVE ref in the description it looks like
<smb> JFo, Hmm, its long ago but the refence is not completely unrelated. Leave it as is for the moment
<smb> I will need to have a closer look
<JFo> ok
<JFo> thanks for looking smb :)
 * smb decides to not only hate xen
<JFo> jjohansen, are you still working on bug 326849?
<ubot2> Launchpad bug 326849 in linux "KVM Kernel bugs in intrepid guests under jaunty host" [Low,New] https://launchpad.net/bugs/326849
<JFo> it looks stale/old
<smb> At least both would be unsupported by now...
<JFo> my thoughts too :)
<jjohansen> JFo: I think I let that one fall off when it went unsupported
<JFo> k, I'll close as out of support
<JFo> thanks for looking jjohansen :)
<jjohansen> hrmm no, no I let that one go when we couldn't get the extra info and kirland moved to invalid
<jjohansen> so even before it was out of support
<JFo> yeah, closed WONTFIX
<JFo> :)
<amitk> apw: can you tell me the output of 'ls -1 /proc/<pid>/fd | wc -l' where <pid> is the pid for mutt on natty
<JFo> amitk, I am running your command (for the last while since you posted it) and I only see 33 max
<JFo> but that is on Maverick
<JFo> are you looking from Natty?
<JFo> perhaps I missed that
<amitk> JFo: Natty, yes. I've got 1024 open
<JFo> hmm
 * JFo kicks his natty box on
<JFo> give me a bit to test some
<amitk> JFo: thanks!
<JFo> and I'll let you know what I see
<JFo> amitk, my pleasure
<jjohansen> amitk: 3
<jjohansen> amitk: of course mutt is also spitting back an error message so that may be of no help
<amitk> jjohansen: what error message?
<jjohansen> no such file or directory
<jjohansen> amitk: are you using maildir
<amitk> jjohansen: I am
<jjohansen> hrmmm so a bug in mutts maildir handling for you
<jjohansen> is 1024 your max fd for a process?
<amitk> jjohansen: strace'ing mutt is showing several messages like : "open("/home/amit/Mail/Canonical/ubuntu.kernel-team/new", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 EMFILE (Too many open files)"
<amitk> jjohansen: I didn't change anythning explicitly, haven't checked the default yet
<jjohansen> amitk: yep, its hit the per process limit
<amitk> so much for switching to natty toda
<amitk> y
<JFo> :-/
<jjohansen> amitk: you can always up the limit with ulimit but there is definitely a bug if its got 1024 open
<jjohansen> amitk: I check what my default limits are for maverick and natty and they are the same
<jjohansen> cat /proc/<pid>/limits
<cking> amitk, looks like the mutt developer does not subscribe to as many mailing lists as you do.
<jjohansen> my bet is he doesn't subscribe to lkml
<jjohansen> and neither do the thunderbird or evo developers
<amitk> cking: :) I don't download my lkml email. I use gmail to search thru lkml
<JFo> same here
<JFo> painful even then
<amitk> jjohansen: seems like a mutt bug for sure, or something funky in my setup. http://paste.ubuntu.com/562128/
<jjohansen> yeah I would say a mutt bug too
<JFo> <- lunch
 * tgardner --> lunch
<tgardner> JFo, why are some of these old bugs getting stroked? bug #185025 has its importance changed, but its been fix released for over 3 years.
<ubot2> Launchpad bug 185025 in linux-source-2.6.15 "Coolermaster Xcraft 360 USB drive fails" [Low,Fix released] https://launchpad.net/bugs/185025
<JFo> tgardner, that isn't me
<JFo> nor any of the scripts
<JFo> I use
<tgardner> JFo, k
 * JFo inquires elsewhere
<tgardner> sconklin-afk, bjf - how do you guys initiate a pocket copy from the c-k-t PPA? Subscribe the SRU team, or just annoy pitti on IRC?
<bjf> annoy pitti
<bjf> tgardner, ^
<JFo> tgardner, per the LP guys, apparently there was a change to how they calculate that from upstreams
<JFo> so that was expected
<tgardner> JFo, hmm, seems like useless churning.
<JFo> I agree, but apparently it is an attempt to do the right thing(tm)
<JFo> :)
 * JFo steps away to wrangle with his Natty machine
<JFo> brb
<tgardner> kees, are USN noticed automatically generated? In looking at the Dapper USN I noticed that not all of the CVEs in the changelog were reflected in the USN.
<tgardner> notices*
<kees> tgardner: they are manually generated because the changelogs are misleading. :)
<kees> tgardner: the 3 CVE mentioned in dapper were already fixed in a prior release.
<kees> tgardner: but those fixes were reverted in favor of the identical upstream fixes.
<kees> i.e.:
<kees>   * Revert "SAUCE: AF_ECONET prevent kernel stack overflow"
<kees> vs
<tgardner> kees, ok, looks like you're right.
<kees>   * econet: fix CVE-2010-3848
<kees>     - CVE-2010-3848
<ubot2> kees: Stack-based buffer overflow in the econet_sendmsg function in net/econet/af_econet.c in the Linux kernel before 2.6.36.2, when an econet address is configured, allows local users to gain privileges by providing a large number of iovec structures. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3848)
<ubot2> kees: Stack-based buffer overflow in the econet_sendmsg function in net/econet/af_econet.c in the Linux kernel before 2.6.36.2, when an econet address is configured, allows local users to gain privileges by providing a large number of iovec structures. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3848)
 * kees nods
<kees> argh ubot2
<tgardner> kees, how do you want to handle linux-mvl-dove which I just uploaded to the c-k-t PPA. Do you need a USN for them since they contain some CVE patches ?
<kees> tgardner: yup, if it goes into -security in main, it needs a USN. we can treat linux-mvl-dove just like all the others.
<kees> i.e. once the archive admin copies it to -security, we'll generate and send the USN for it.
<kees> tgardner: do you want me to add mvl-dove to the CVE tracker?
<kees> or is this an uncommon situation?
<tgardner> kees, ok, I'll try to remember to annoy you when it gets pocket copied. Is there an automatic way for you to get notified?
<kees> tgardner: not yet, but after talking with pitti, he'll ping us when it happens.
<tgardner> kees, yeah, you should add mvl-dovve to the mix as we're on the hook for security, etc.
<kees> karmic, lucid, maverick?
<tgardner> kees, I'll forward davidm's email regarding which ARM branches for which release.
<kees> https://wiki.ubuntu.com/Kernel/Dev/ABIPackages <- they're here
<kees> I just need to know which to remove the "**" from. :)
<tgardner> kees, well, remove '**' from Maverick mvl-dove. I'm still figuring out where we are on fsl-imx51.
<kees> okay, but leave it for karmic and lucid mvl-dove?
<tgardner> kees, I'm not sure I'm gonna bother with Karmic. Its so close to EOL. Leave Lucid mvl-dove as abandoned for now.
<kees> tgardner: works for me; thanks.
<tgardner> kees, I'll let you know if I make any more changes. I'll likely hold off on uploading ti-omap until we've exhausted the CVE tracker list.
<kees> cool
<JFo> grrrrrr
 * JFo goes to slap around his natty machine
<JFo> this is really beginning to piss me off
<JFo> amitk, I know you and jjohansen already pretty much figured the problem out
<JFo> just wanted to add
<JFo> Natty is making me want to get the hammer ahold of this laptop
<JFo> in a purely Hulk Smash sort of way
<jjohansen> JFo: download the maverick mutt .deb and manually install it
<JFo> k
<JFo> doing updates just now (which is likely a bad idea)
 * jjohansen -> lunch
<amitk> JFo: same problems with mutt on natty?
<amitk> or just hate it in general? ;)
<JFo> both, but in general just now :)
<JFo> there used to be a really nice "choose desktop environment" selector, that is gone
<JFo> and for some reason ,the wireless (that worked so well during install) won't stay connected
<JFo> I very nearly threw this thing across the room a few minutes ago
<JFo> :)
<JFo> very trying
<amitk> JFo: you can choose the Desktop in gdm _after_ you click on your userid
<bjf> JFo, bug #712723, bug #712737, bug #712744, bug #712749  (accept nominations please :-))
<ubot2> Launchpad bug 712723 in linux "CVE-2010-4080" [Undecided,New] https://launchpad.net/bugs/712723
<ubot2> Launchpad bug 712737 in linux "CVE-2010-4081" [Undecided,New] https://launchpad.net/bugs/712737
<ubot2> Launchpad bug 712744 in linux "CVE-2010-4082" [Undecided,New] https://launchpad.net/bugs/712744
<ubot2> Launchpad bug 712749 in linux "CVE-2010-4083" [Undecided,New] https://launchpad.net/bugs/712749
<JFo> bjf, on it :)
<JFo> amitk, it used to be simplet than that ;)
<JFo> simpler*
<JFo> looks like I have them all bjf
<bjf> JFo, thanks!
<JFo> let me know if I missed any, or if there are more :)
<JFo> my pleasure
<bhanu> not find the linux kernel debug images for makerich
<bhanu> not find the linux kernel debug images for makerick
<bhanu> I cannot find it in any repositories
<bhanu> Am I missing something
<JFo> bjf, we have a bug in the new script somewhere (likely something I introduced)
<JFo> It only tries to process 2 bugs
<bjf> JFo, point me at it
<JFo> it is the new-process-new script
<bjf> JFo, ack
<JFo> looks like it has been there for a while as I have been going through the list of bugs that it has been skipping and the overall number of bugs processed gradually dropped until there are only the 2 left
<JFo> :-)
<bjf> JFo, ok, so, here's "the plan", I'm currently finishing up 4 CVEs, as soon as I get them done I will work on the script and nothing else (within reason) until we get it fixed
<bjf> JFo, I may be able to start on it this evening but by tomorrow a.m. at the latest
<JFo> dude, no sweat
<JFo> I am in no rush. I am just glad that we can identify now where the possible problem is
<JFo> I'm going to keep looking at it, but some is still greek to me :)
<bjf> JFo, are you running it on cranberry ?
<bhanu> how do I install debug kernel on ubuntu
<JFo> bjf, not right now. I am running it on my local machine
<JFo> been trying to nail down some oddities while I am trying to document the run steps.
<JFo> this was the main one
<bjf> JFo, try it on cranberry, i have an account there now so it would give us a common environment to work in
<JFo> ok
<JFo> will do
<JFo> hmmm, can't get a bzr branch there
 * JFo tries something
<bjf> bhanu, i've not tried before, and i'm looking for wiki documentation but not finding any
<bjf> bhanu, maybe if you said what the problem is that you are having someone would be able to point you at a different solution than a debug kernel
#ubuntu-kernel 2011-02-04
 * abogani waves all
<abogani> Why "Bug Watch Updater" changes priorities? Is it a bot, isn't it? Which rules it follows for that type of changes?
<RAOF> It's refreshing the Launchpad status of upstream bugs.  So, those bugs have had their priorities changed upstream, and this is being reflected in Launchpad.
<persia> Good day.  I decided to work on a kernel today, and I'm a bit lost in terms of git and quilt and stuff, and hoped someone could help me understand what commands would let me manipulate the code.
<persia> I've run git clone on a linux-2.6 tree and a separate git clone on a tree that appears to contain some quilt patches.
<persia> I'd like to regress the linux-2.6 tree to the commit that is listed as the last time the quilt series was rebased, apply the quilt series, and move forward through the linux-2.6 revision history to try to get to current.
<abogani> RAOF: Thanks!
<RAOF> persia: That should be relatively straightforward.
<abogani> persia: Why don't you reset the tree to current and so apply the quilt series?
<persia> RAOF, I'd think so, but after reading about git branch and git checkout and remote branches, I'm left a bit confused as to the mechanism.
<RAOF> Yeah.  git can do that :)
<persia> abogani, Because the git history of the quilt series identifies a specific revision against which it was based and I want to test a build from that before I add more patches, so I can distinguish between issues with moving the patches forward and issues with the patches themselves.
<RAOF> So, my instinct would be to checkout the branch you want to apply the patches to, then âgit reset --hard $REVISION_SHAâ to go back to where the patches want to be applied to.
<RAOF> Then, apply and commit the applied patches one at a time.
<persia> And checking out the branch is something like `git checkout -b origin/mybranch` (where "origin/mybranch" is shown from `git branch -r`)?
<RAOF> Checking out is more âgit checkout -b nameI'dLikeMyBranchToHave origin/TheNameOfTheRemoteBranchItShouldBeBasedOnâ
<persia> OK.  That makes sense.
<RAOF> *Sometimes* you can omit the -b and the local branch name, and git will strip the âorigin/â bit off as the local branch name.
<RAOF> I've not worked out when this behaviour occurs.
<persia> Next, the git manual said that commiting things was a multistep process, but I got a bit confused about the details.  Is there something better than 1) apply the patch, 2) iterate over the output of lsdiff on the patch and run git add for each, 3) compare git diff --cache to the patch to make sure it took, 4) git commit ?
<persia> In this case I can't omit that: it just created a new branch that didn't seem to have any differences in the output of git log
<RAOF> I think the âgit applyâ command is what you're after.
<abogani> git quiltimport
<RAOF> abogani: Oh, really?  Even better!
<persia> Indeed.  The manpage of git-quiltimport seems much more straightforward than the manpage for git-apply
<persia> Next question is about going back to the start when I do something wrong.  From directory content inspection, it appears that git creates a new HEAD with a checksum and my identity from git clone.  Is there an easy way to get back to this, even after doing things like git revert --hard?
<persia> Err, git reset
<RAOF> git reset --hard doesn't *remove* any commits, so if you still know the SHA of the commit you want you can get it out.
<RAOF> There's probably a method for iterating over all the heads in the repository, too.
<persia> So I should record the SHA of the last commit in git log before starting, and then I ought to be able to get back to it (with history)?
<RAOF> Yes.
<RAOF> It's quite hard to actually kill commits, and each commit has a reference to its parent.
<persia> So applying a given commit inherently applies all it's parents?
<RAOF> That depends on what you mean by âapplyâ.
<RAOF> If you get *exactly* that commit into your tree, then you've also got all of its parents.
<persia> I tend to conceptualise VCSs as funny ways to interact with something akin to quilt, if that helps understand the semantics of "apply" as used above.
<RAOF> git *also* makes it easy to apply the *contents* of that commit as a diff to your current tree.  In that case, a *new* commit with just the contents of the old one is created.
<persia> Ah, I perceive the difference.
<RAOF> Yeah.  The quilt model is insufficient for describing how git (or bzr, for that matter) actually works, because a commit is inseparably diff+a bunch of metadata.
<persia> So, with reset, I'd end up back to the original point where the quilt series is supposed to apply, then with quiltimport I'd apply the patch series, and then I'd want to iterate over the set of outstanding bits of work to apply the contents of each to the tree?
<persia> Indeed, and most of my experience with VCSs is learning how to work around the metadata :)  Not entirely best practice, but perhaps I'll learn some day.
<abogani> persia: Which quilt series are you talking about?
<RAOF> Actually, in on reflection I think that what I suggested won't be any better than trying to apply the existing quilt series on top of trunk.
<RAOF> What *would* be better is applying the quilt series and then merging it into trunk.
<abogani> Agreed. The best thing is drop "quilt form" as soon as possible.
<RAOF> And, since git is stupid and thinks merges are symetrical, that would replace âgit pull --rebaseâ with âgit merge $BRANCH_TO_MERGE_INTOâ
<RAOF> That way git will do some of the conflict resolution for you.
<persia> Hmm...
<persia> So, given a git tree, would it make sense to create two branches: one based on the reset, and the other based on an -rc3 merge, and separately apply the quilt series to each to achive my testing goals?
<RAOF> No, I don't think so.
<rigved> hi everyone...i'm interested in kernel programming...can anyone guide as to where should i start
<RAOF> You would create one branch - one based on the reset, with the quilt patches applied.
<persia> And I'd build off that, and go test
<RAOF> Oh.  You would then merge that into rc3, and resolve any conflicts.
<RAOF> Which, I guess, would create a new branch based on rc3, with the patches applied.  I just wouldn't think of it like that :)
<persia> Um. except there's outstanding stuff in the tree that needed changes to merge into -rc3 (and those change commits are in the tree, but ahead of the quilt application point)
<RAOF> I guess it comes down to: what do you *want* to test?
<abogani> :-)
<RAOF> Do you want to test the patches on the most recent kernel, or do you want to test the patches on the kernel they specify?
<persia> I want to test two things: a) something that kinda looks like the code that the author of the quilt series was working on; b) the results of applying the same quilt series to a branch that recently was merged against -rc3; and c) the results of merging the Ubuntu sauce on top of that combination.
<persia> Err, three things.
<RAOF> Ok.  Well, the first thing to do in all those cases is to start with the commit the author was working on, and apply the patch series.
<RAOF> Once you've tested that branch, you can merge it into the branch that was recently merged against -rc3, and test that; then merge in the ubuntu sauce.
<persia> So git reset, git quiltimport, (twiddle, build, test), git merge, (twiddle, build, test), git remote add, git merge, (twiddle, build, test) ?
<RAOF> Yes.
<RAOF> Exactl.
<RAOF> git should help a little with the twiddle phase, and âgit statusâ will list conflicted files as âboth modifiedâ
<RAOF> Oh, yes.  git also doesn't automatically detect when you've reconciled a conflict, so you'll need to âgit addâ the reconciled file.
<persia> Excellent.  I think that lets me fiddle the code enough to make progress.  Monday, I can learn about kernel packaging :)
 * persia grumbles about SHA mismatches for commits at almost the same time and with the same message, and clearly the same thing, except something odd happened.
 * apw realises xchat isn't running :)
<smb> Productivity increased by at least 100% :)
<apw> smb, heh i wouldn't call preparing for a release meeting productive, depressing more like
<smb> apw, Ok, not really productive in the usual sense. But I would think not being interrupted by mumble or irc could half the time needed, thus half the pain. :)
<apw> heh some of that of course
 * cking can get some emails and docs written at last ;-)
 * smb stares scared on the amount of potential upstream stable changes that missed xen shadow files
<apw> smb, that xen split is a nightmare
<smb> apw, o_O (indeed)
<apw> i was quite serious when i said we should consider turnign it back into an overlay
<smb> apw, I just go ahead and start to sync up the auto-generated patches for stable releases to xen files from the tarball. Not that those all will have some impact, but I we really want no differences there to the original files
<smb> If that is done, we can think of the second step of folding them back
<apw> smb, you got an amd64 box you could boot test a kernel on?
<smb> apw, As long as 64bit is the only requirement, sure. I "guess" Natty? (not sure I have an install already, but I could at least do Natty kernel on Maverick)
<apw> yep natty on maverick is fine, just want to know it boots ok ... still building, will shout when its ready
<smb> ok, booting up the test box meanwhile
<apw> smb, couldn't be bothered to hump a second laptop with me
<smb> apw, Understandable
 * smb even found a natty install... with kernel 2.6.37... I guess that needs a slight update
<evdvelde> hi all, do you need to patch the Linux kernel to use Mobile IPv6?
<apw> evdvelde, not sure i know the answer to that off the top of my head
<evdvelde> apw: thanks for the honesty :) been googling for it, but last posts about it are from 2008, with a patch to the kernel... 
<apw> evdvelde, if you have a link to the patch i may be able to tell if its in already
<evdvelde> apw: i found the patch again: ftp://ftp.linux-ipv6.org/pub/usagi/patch/mipv6/umip-0.4/kernel/patch/
<apw> smb, could you boot test the amd64  -2.29 kernels here http://people.canonical.com/~apw/master-next-natty/ ... thanks
<apw> smb, well 32 bit is good at least
<apw> Ubuntu 2.6.38-2.29masternext201102041001-generic 2.6.38-rc3
<pgraner> apw, ping
<apw> pgraner, hiya
<apw> i've emailed you the update for the meeting today
<smb> apw, I think I probably should have started that dist-upgrade... 
<smb> I mean not
<apw> shouldn't ?
<smb> yeah
<apw> perhaps ... no worries
<pgraner> apw, can you send me the meeting invite, for some reason it dropped of the Ubuntu Engineering Cal
<apw> pgraner, sure
<pgraner> apw, thanks
<apw> you should get an invite shortly
<apw> pgraner, but it is at 16:00 UTC
<pgraner> apw, got it
<apw> pgraner, cool.  is your laptop a 64 bit install ?
<pgraner> apw, yep
<smoser> smb, i'll get to your xen image question today
<smb> cheers. Sadly I realized that with the laptop approach I currently use, I won't be able to do anything beyond a t1.micro anyway. But for the future I hope to set up a more capable environment. :)
<JFo> going to be 'nearby' for a bit. I am finally starting up my python focused time every week. Just ping me here and I'll check periodically, but I am mostly going to be buried in a book. :)
<ohsix> apw: posted the cgroup-bin suspend bug https://bugs.launchpad.net/ubuntu/+source/libcgroup/+bug/713187
<ubot2> Launchpad bug 713187 in libcgroup "cgroup-bin default configuration breaks suspend" [Undecided,New]
<bjf> JFo, i'm now starting to look at the arsenal issue
<JFo> bjf, ok, I think I have broken/fixed it further :)
<JFo> so there is another update to that one in the kernel-arsenal
 * tgardner --> lunch
 * cking --> beer time
<poelzi> could someone check this bugfix in please: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/706394
<ubot2> Launchpad bug 706394 in linux "kernel should have CONFIG_CFQ_GROUP_IOSCHED" [Undecided,Incomplete]
<tgardner> poelzi, looking...
<poelzi> i really would like that blk cgroups is enabled the next ubuntu kernel. it is so powerfull when used correctly :-)
<jjohansen> rebooting
<tgardner> sconklin, linux-meta-mvl-dove 2.6.32.214.15 did not get pocket copied whereas the kernel _did_ get copied.
<sconklin> ok, it'll probably be Monday if pitti's already gone
<sconklin> I'll try now
<sconklin> tgardner: he's gone for the weekend
<tgardner> sconklin, ok. I'll have fsl-imx51 kernels to annoy him with on Monday anyways.
<bjf> JFo, ping
<doctormo> My System76 compal based computer is currently running Ubuntu 10.10 but with the kernel 2.6.32 from lucid. This is because the newer kernel can not see pci memory for some reason which system76 have been unable to reproduce on their test machines. There is a report that this bug is still present in the natty alpha2 kernel.
<doctormo> I'm at a bit of a loss of what I can do. The bug is highly severe, but lost in the noise and lacking a fix.
<bjf> doctormo, don't know what to tell you, you are saying that somewhere between 2.6.32 and 2.6.35 the kernel broke for your system
<ohsix> it should be noted that the alternate init systems can use sysvinit type scripts as a lowest common denominator
<ohsix> so you can work from there and specialize if the package can take advantage of it
<bjf> doctormo, and the issue still exists even in natty
<ohsix> oops, sorry, wrong window
<doctormo> bjf: Yes
<jjohansen> doctormo: have you tried upstream kernels
<jjohansen> doctormo: basically you could try say a .33 and .34 based kernel and see if either of those are good
<doctormo> jjohansen: I could, but I'd like to try kernels in a ppa or some other easy to install and remove form.
<jjohansen> doctormo: and then knowing that we could work to a bisection point to find which patch caused the problem
<bjf> doctormo, jjohansen is correct, it could be a difference between the ubuntu kernel and a stock upstream kernel
<bjf> doctormo, that would help with bisecting the problem
<jjohansen> doctormo: we do publish an upstream kernel in deb form
<jjohansen> doctormo: https://wiki.ubuntu.com/Kernel/MainlineBuilds?action=show&redirect=KernelMainlineBuilds
<jjohansen> you should be able to pick a .33 and .34 from the archive
<jjohansen> eg. http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33.7-maverick/
<jjohansen> sudo dpkg -i to install
<jjohansen> dpkg -r to remove
<jjohansen> doctormo: just knowing whether it shows up in one of these is going to help isolate the bug
<jjohansen> doctormo: have you opened a bug in ll yet so that this can be tracked?
<doctormo> jjohansen: That wiki page says the mainline is a ppa, but it doesn't look like a ppa, it looks like a repository
<doctormo> But it gives no instruction on how to install the repository.
<jjohansen> doctormo: hrmm, I've never used it as a ppa I just grabs .debs from it
<jjohansen> nor would you want to in your case, as you don't want the latest
<jjohansen> you want to install specific older kernels for testing
<bjf> doctormo, those are in an account with "ppa" as part of the name, it's not a true ppa
<doctormo> It's not a ppa at all, perhaps renaming the thing would avoid future confusion?
<bjf> doctormo, it probably would but we're stuck with the name
<doctormo> bjf: Why are you stuck with the name?
<bjf> doctormo, we just are
<doctormo> bjf: No, seriously, I do community for work for ubuntu, what will happen if you change the name?
<bjf> the kernel team is used to it, it can't be a true ppa it has to be just an account with web access
<bjf> we have a bunch of automated scripts that build various kernels and put them there
<bjf> it's just not going to change
<doctormo> bjf: Based on convention, you're going to continue to confuse?
<doctormo> I'm going to report it as a bug with the community team, it's bad to have this sort of thing.
<bjf> good luck with that
<doctormo> bjf: *shrug* conventions like this need fixing.
<vanhoof>  /whois doctormo 
#ubuntu-kernel 2011-02-05
<poelzi> is there a better, working doc then https://help.ubuntu.com/community/Kernel/Compile ?
<poelzi> i wanted to fix some config problems for all archs, and just don't get it how, where to change it
<ogra> poelzi, see planet.ubuntu.com, there was a kernel build giude two days ago or so
<poelzi> all these scripts... man. i'm happy just running vanilla ;-)
<ohsix> is btrfs safe to use, for some definition of safe; if you're occasionally switching to new kernels, then back to the one for that version? (say, maverick vs. 37 and now 38)
<poelzi> ogra: can't find it anymore :-/
<poelzi> at least on my machine btrfs is broken with .37
<poelzi> worked fine with .36
<ohsix> good to know; was just curious about on disk formats and such, and a one way kernel boot :D
<poelzi> i use it as a build partition where i don't care if it's lost
<poelzi> i think the disk format is quite stable now
<ohsix> cool
<ohsix> xfs is not great in a laptop, so i'm looking at my options before a reinstall and just using ext*
<ohsix> you can lose a whole AG if theres a temporary read error at an inopportune time; and theres only a handful so it turned out to be quite a bit of important stuff here :\
<poelzi> yes. xfs i will never use again. it's on my blacklist now
<ohsix> do you know offhand where i can look and see whats rolled into an initrd as far as fuse filesystems go? or know if its done by fstab entries or a white list
<poelzi> a journalying fs that damages when power wents off is just broken like hell
<poelzi> i now just use ext4 on my notebook
<ohsix> never lost anything with the power; just did something stupud that was innocuous on other filesystems, didn't expect to lose 1/8th of all files, i thought the odds were on my side corrupting an inconsequential file (there are lots of those!) that i'd replace if debsums said so
<ohsix> laptop drives are a harsh mistress though
<xyclo> Hi, I want to install lowlatency kernel 2.6.37 on Ubuntu Studio 10.04. I found building instructions for Gentoo and in German. Anybody knows where I can get directions in english, or a pre-compiled one??
<doctormo> xyclo: There should be a lowlatency kernel already available for Ubuntu Studio
<xyclo> So I thought, but I cannot find anything newer than 2.6.32.24.25
<xyclo> Should I settle for that one?
#ubuntu-kernel 2011-02-06
<YankeesFan> !ops
<ubot2> Help! lamont, zul, T-Bone, mdz, or jdub
<YankeesFan> !staff
<ubot2> hey Christel, Dave2, Gary, KB1JWQ, Levia, Martinp23, SportsChick, VorTechS, jayne, jenda, marienz, nalioth, niko, nhandler, rob, stew or tomaw, I could use a bit of your time :)
<YankeesFan> !ops
<ubot2> Help! lamont, zul, T-Bone, mdz, or jdub
<LLStarks> bug 711568
<ubot2> Launchpad bug 711568 in xserver-xorg-video-intel "Dithering regression on Intel graphics with .38 Natty kernel" [Undecided,New] https://launchpad.net/bugs/711568
<ohsix> LLStarks: one of the developers says he's familiar with the problem but it hasn't been reported, if that's your bug can you post it upstream?
<LLStarks> will do
<ohsix> cheers
<ohsix> LLStarks: he's already comitted the fix referencing the LP bug; i guess you can skip it
<LLStarks> is there a place that i can reference that?
<LLStarks> ubuntu kernel git?
<ohsix> well, upstream, sec; i dunno where the commit would go
<LLStarks> -2 didn't have it
<LLStarks> ohsix, just in case: https://bugzilla.kernel.org/show_bug.cgi?id=28382
<ubot2> bugzilla.kernel.org bug 28382 in Video(DRI - Intel) "Dithering regression on Intel graphics with .38 kernels" [Normal,New]
<ohsix> ok thanks
<YankeesFan> if ur ready for the superbowl than give me a hell yeah
#ubuntu-kernel 2012-01-30
<shawn1> Hello
<shawn1> My kernel doesn't seem to be allowing me to use a multi-gpu card (GTX295).  It will only detect one core.  I checked lspci and that should show two entries for the GTX 295, but it only shows one.  I did lspci -A intel-conf2, though, and found "00:08.0 Non-VGA unclassified device: Device aebc:75c5 (rev 40)".  That item didn't show up on any of the other lspci detection lists.
<ohsix> do you get any messages about pci routing in dmesg? there's a few methods you can try if the bios doesn't set things up right
<unixpro1970> Shawn2, some gtx295 cards are 1 core while others are 2 core.
<unixpro1970> The single core gtx295 came later
<pip> !ciao
<ubot2`> Factoid 'ciao' not found
<pip> !list
<ubot2`> This is not a file sharing channel (or network); be sure to read the channel topic. If you're looking for information about me, type Â« /msg ubottu !bot Â». If you're looking for a channel, see Â« /msg ubottu !alis Â».
<abdo> Hello guys
<abdo> one of my servers had a kernel panic
<abdo> I can collect "linux-image-2.6.35-26.0.crash.gz" file from /var/crash
<abdo> I tried to use:
<abdo> gdb vmlinuz-2.6.35-26-server linux-image-2.6.35-26.0.crash
<abdo> and got:
<abdo> /tmp/linux-image-2.6.35-26.0.crash" is not a core dump: File format not recognized
<abdo> can any one help me and put me on the right path? thanks in advance.
 * ppisati -> starvation avoidance
<rbasak> I'm trying to cross compile an armhf kernel out of the git source for bisecting purposes. Is this easiest way? I found instructions for using xdeb but they break when when xdeb 404s on http://ports.ubuntu.com/ubuntu-ports/pool/main/z/zlib/lib32z1_1.2.3.4.dfsg-3ubuntu3_armel.deb. And the instructions at https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel don't cover cross compiling. Some help, please?
<ppisati> rbasak: export $(dpkg-architecture -aarmel); export CROSS_COMPILE=arm-linux-gnueabi-
<ppisati> rbasak: fakeroot debian/rules clean binary-omap4
<ppisati> rbasak: to get an armhf kernel, substitute "-aarmel" with "-aarmhf"
<ppisati> rbasak: yep, i should update those instructions
<rbasak> awesome, thanks!
<rbasak> I have an automated test rig now. I should be able to do an automatic bisection
<ppisati> rbasak: btw, what are you looking for with your bisection?
<rbasak> right now, the random panics. but I also wanted to have an arrangement ready to do it in the future
<ppisati> rbasak: random panic???
<rbasak> the installer fails randomly right now
<rbasak> I had some logs saved from friday, hang on
<rbasak> ppisati: eg. http://paste.ubuntu.com/819098/
<ppisati> rbasak: well, that's with the previous kernel
<ppisati> rbasak: but the panic looks strange'
<rbasak> ppisati: ah yes - I take it the installer hasn't been updated with the latest kernel yet
<ppisati> rbasak: tell me if it's reproducible with the new one
<rbasak> ppisati: I'd love a script to give me a working uImage and uInitrd out of the latest kernel. How would I do that?
<rbasak> I'm not yet very familiar with the tooling around the kernel builds
<ppisati> rbasak: uImage is definitely inside the .deb, so you can get it easily
<ppisati> rbasak: while initrd IIRC is built at install time
<rbasak> what about the installer initrd? that's the one I'm after
<ppisati> rbasak: so probably the easiest way is to insall the kernel somewhere and get the two files
<rbasak> If the uImage is in there I can extract that part, thanks
<rbasak> Is the installer uInitrd the same as an installed machine's uInitrd?
<rbasak> The one you gave me for the test the other day didn't work
<ppisati> rbasak: don't know, you should ask the #arm guys (ogra's angels)
<rbasak> OK I'll take it to #ubuntu-arm
<abdo> Can any one help me on my question?
<rbasak> ppisati: make: *** No rule to make target `binary-omap4'.  Stop.
<rbasak> ppisati: this is debian/rules out of ubuntu-precise.git, right?
<ppisati> rbasak: did you checkout the omap4 branch first? and did you clean?
<rbasak> ah, there's an omap4 branch? :-)
<ppisati> rbasak: git checkout ti-omap4
<rbasak> ppisati: now working, thanks :)
<ppisati> rbasak: tell me how it goes
<rbasak> will do!
<ppisati> a bug in Incoplete status will vanish after 60days of no activity, right?
<ppisati> *Incomplete
<herton> ppisati, for Ubuntu I think that's correct, there are more details: https://help.launchpad.net/Bugs/Expiry (assuming this is uptodate)
<ppisati> why bug 732628 is still showing up in linux-ti-omap4?
<ubot2`> Launchpad bug 732628 in linux-ti-omap4 "TOCTOU in mount.ecryptfs_private" [Low,Fix committed] https://launchpad.net/bugs/732628
 * ogasawara back in 20
<jsalisbury> ogasawara, A possible regression with ath9k devices in 3.2.0-12: bug 923512 and 923605
<ubot2`> Launchpad bug 923512 in linux "ath9k wireless stopped working after kernel upgrade to 3.2.0-12" [High,Incomplete] https://launchpad.net/bugs/923512
<ubot2`> Launchpad bug 923605 in linux "Wireless network card unable to connect to router with 3.2.0-12 kernel (dup-of: 923512)" [Undecided,Incomplete] https://launchpad.net/bugs/923605
<jsalisbury> ogasawara, I can bisect between the two kernels to identify the bad commit.
<ogasawara> jsalisbury: ok thanks.  the only thing that would come to mind is something in the 3.2.2 stable update...
<ogasawara> jsalisbury: everything else would seem unrelated
<ogasawara> jsalisbury: you'll want to find out specifically what version them mean when they say "working fine with the previous kernel version". do they mean 3.2.0-11.19 or an Oneiric kernel or ...
<jsalisbury> ogasawara, ahh, right.  thanks.
<smb> tgardner-afk, Not sure whether someone fixed something under our back or it makes a difference between bare metal and kvm-vm or is just random, but right now an cobbler install of precise-amd64 did work (with the usual whining about unloadable modules)
<ogasawara> diwic: is there a specific tag you want us to use to flag audio bugs which are likely due to the the new jack detection patches?  or do you want us to just ping you with the bug #'s?
<ogasawara> eg bug 923316
<ubot2`> Launchpad bug 923316 in linux "[regression] Speakers are not muted while plugin the headphone " [Undecided,Confirmed] https://launchpad.net/bugs/923316
<ogasawara> bug 923409
<ubot2`> Launchpad bug 923409 in linux "No sound" [Undecided,Confirmed] https://launchpad.net/bugs/923409
<ogasawara> jsalisbury: ^^ just fyi, you'll want to keep an eye out for any audio regressions as of 3.2.0-11.19 due to the new jack detection patches
 * ppisati disappears for a bit...
<diwic> ogasawara, ouch :-( 
<diwic> ogasawara, I guess pinging me or assigning bugs to me will be best, thanks
<ogasawara> diwic: ack, will do
<jsalisbury> ogasawara, I'll keep an eye out, thanks
<vanhoof> ogasawara: been otp for a bit, but tgardner let me know you found the prob already w/ cw-3.2, happy to test things out here for ya
<ogasawara> vanhoof: perfect, I'm just getting the bug filed etc.  Will get a patch thrown together and have you test.
<vanhoof> ogasawara: for reference: http://paste.ubuntu.com/822889/
 * tgardner -> lunch
<jwi> jsalisbury: i think bug 923094 is just about shipping that specific module in /debian.master/d-i
<ubot2`> Launchpad bug 923094 in linux "Debian Installer kernel (PowerPC) is missing therm_adt746x module" [Medium,Incomplete] https://launchpad.net/bugs/923094
<ogasawara> vanhoof: bug 923900, http://people.canonical.com/~ogasawara/lp923900/
<ubot2`> Launchpad bug 923900 in linux-backports-modules-3.0.0 "Enable iwlwifi drivers for compat-wireless v3.2 backports" [Medium,Triaged] https://launchpad.net/bugs/923900
<vanhoof> ogasawara: thanks
<vanhoof> will give it a go
<jsalisbury> jwi, right
<vanhoof> ogasawara: looks good, gonna do some testing now w/ new(er) cards
<vanhoof> ogasawara: http://paste.ubuntu.com/823004/
<vanhoof> ogasawara: thank you :D
<smagoun> A question on kernel ABI numbers. The ABI numbers need to be unique within a particular topic branch, but not globally - correct? So for example if you have a topic branch foo with ABI base 3.2-100, and another topic branch bar with ABI base 3.2-100, would there be package collisions if packages from each branch were in the same archive? (Not that this is good form)
<tgardner> smagoun, they need to be unique within an archive since all of the binary packages share the same directory.
<smagoun> tgardner: So we'd potentially wind up with linux-image-3.2.0-100-foo and linux-image-3.2.0-100-bar? Which isn't useful if you're trying to keep the two separate. Is that correct?
<tgardner> smagoun, it might be confusing if the binaries are unrelated ('cause its the form we have right now, e.g., linux-image-3.2.12-virtual and linux-image-3.2.12-generic)
<tgardner> note that I didn't get those example version numbers quite correct. it should have been linux-image-3.2.0-12-generic, etc
<smagoun> tgardner: makes sense. Is there a 'safe' ABI base that thirdparties can adopt as an ABI base if they want to avoid collisions with Ubuntu kernels for the forseeable future (say through 14.04)? -2000, for example?
<tgardner> smagoun, yeah, anything 3 digits with a unique flavour name is likely gonna be OK
<smagoun> tgardner: thanks. Is 4 digits off-limits, or just more typing than 3 digits and therefore less desirable?
<tgardner> smagoun, checkout how we've named the ti-omap4 stuff: https://launchpad.net/ubuntu/+source/linux-ti-omap4. 4 digits is fine (I mis-spoke)
 * smagoun looks
<smagoun> tgardner: Is there a specific reason for the jump in ABI between 3.0 and 3.2? I see 3.0.0-1205.10 in 11.10, and 3.2.0-1405.7 in 12.04
<tgardner> smagoun, since the kernel version is embedded in the package name there really wasn't a need to also rev the ABI series, but it might reduce confusion. I dunno... 
<smagoun> understood, thanks
<tgardner> so, no, I don't think there was a specific reason
 * tgardner is EOD
<hallyn> hm, is bug 923900 why my laptop lost 
<ubot2`> Launchpad bug 923900 in linux-backports-modules-3.0.0 "Enable iwlwifi drivers for compat-wireless v3.2 backports" [Medium,Triaged] https://launchpad.net/bugs/923900
<hallyn> wireless with latest update?
<hallyn> probably not...~.
#ubuntu-kernel 2012-01-31
<braernoch> Is there any way to check the value of symbols exported by built-in kernel objects at runtime?
<shawn1> I've been trying to find a place to get some help on an issue I'm having with the ubuntu kernel
<shawn1> lspci's not detecting one of my computer's components
<RAOF> shawn1: Your dual-core GPU?
<shawn1> it detects it as an unclassified Non-VGA device when I use detection method intel-conf2, but none of the other methods will detect it. 
<shawn1> haha
<shawn1> you remember me!
<shawn1> Yes,
<RAOF> It probably *is* a non-VGA device :)
<RAOF> What exactly are you trying to do?
<shawn1> It's a dual-core GPU
<shawn1> well
<shawn1> dual-GPU card, I should say
<shawn1> but it's only detecting one of the GPUs
<RAOF> Right.  And what are you trying to do?
<shawn1> lspci -A intel-conf2 shows:  00:08.0 Non-VGA unclassified device: Device aebc:75c5 (rev 40)
<shawn1> none of the other methods show anything on that address.  I'm trying to do distributed computing.
<shawn1> CUDA apps
<RAOF> Ok.  So your problem is that the nvidia binary driver doesn't see both GPUs?
<shawn1> no
<shawn1> lspci doesn't
<RAOF> And why is that a problem?
<shawn1> I've talked to NVidia - they said that if it doesn't show up at the lspci level, that there's nothing that the NVidia driver can do
<shawn1> I told them that I ended up finding it on intel-conf2 and they said that if one of the other detection methods located it, that it was probably a kernel bug
<RAOF> Ah.  Ok.  So, your problem is that the nvidia binary driver isn't seeing both GPUs, and the probable proximal cause is that lspci also doesn't see both gpus.
<RAOF> Ok.
<RAOF> Now, have you filed a bug?
<shawn1> Well, I'm not great in my knowledge of how the linux system works, but that's what it sounded like he was saying
<shawn1> Well, the linux guy just told me that, but it's been a bug that's out there for awhile, so I figured I'd check to see if there was a fix I was missing.  There are a lot of threads about people having problems with GTX 295s in ubuntu and I haven't found any resolutions yet.
<shawn1> Where would I file the bug?
<RAOF> You'd (a) first try running a Precise livecd, since that's got a newer kernel.  Maybe it's already fixed there âº and then (b) from the livecd, run âubuntu-bug linuxâ.  Also attach the âlspci -A intel-conf2â output.
<shawn1> Precise livecd?
<shawn1> how's that different from a normal livecd?
<shawn1> oh
<shawn1> Precise is the newest version?
<RAOF> Precise is the current development version, yes.
<RAOF> You can find daily livecd builds here: http://cdimage.ubuntu.com/daily-live/current/
<RAOF> Also, Alpha 2 will be released on Thursday, so you could try that (but it's not going to be significantly different to the current livecd)
<shawn1> ....How dangerous is alpha to my computer?
<RAOF> If you don't install it, very little.
<shawn1> I've got....like a 6 core, a GTX 295 and a GTX 460SE
<shawn1> oh, yes
<shawn1> so
<shawn1> if I run it off the livecd and the kernel works with the GPU, then I should know by checking the lspci, right?
<RAOF> Right.
<RAOF> Well, that would tell if the lspci output is correct, at least.  That doesn't guarantee that it'll work, but given what the nvidia people have said it would strongly suggest that it would work.
<shawn1> so the only file I need is the precise-desktop amd64.iso, right?
<shawn1> well I know that I wouldn't get to test it out except under circumstances where the driver was installed....
<shawn1> This was a Christmas gift and I bought a new power supply to be able to power everything, so I hope it works!
<shawn1> if not, I may have to sell it off, pay a little more, and settle for a GTX 580
<shawn1> (Since I'm using these exclusively for distributed computing, the GTX 295 is preferrable to the GTX 580 because while the DirectX version isn't as recent, the raw processing power is higher)
<shawn1> The 11.10 kernel seems to handle it better than the 11.04.  The 11.04 kernel wouldn't even let my machine start up....
<shawn1> the xserver, I mean
<shawn1> Well, thank you!  I'll wait for that to download and then I'll see what happens when I run it.  I'll write my results here, too, in case anyone else is wondering about multi-GPU cards in Ubuntu.
<RAOF> Yeah, you just need precise
<RAOF> -desktop-amd64.iso
<shawn1> yeah, that's what I'm getting.  40% downloaded.  I just have a wireless connection here.
<shawn1> The .ISO's too big for my CD, apparently
<RAOF> Ah, yeah.  You'll need a usb stick.
<shawn1> I'm guessing larger than my 128MB one, lol
<RAOF> :)
<shawn1> I don't suppose that there's a 'live quarter-inch-cartridge' image, is there?
<shawn1> =]
<RAOF> HEh.
<shawn1> Well....It looks li ke it's time for a Walmart run.  See you later!
<shawn1> ROAF
<shawn1> Hello from 12.04
<shawn1> unfortunately, it would appear that the kernel is still having the same issue with this GPU
<shawn1> but I'm installing a current driver just to make sure
<shawn1> @ROAF
<shawn1> It didn't work
<shawn1> any suggestions?
<RAOF> shawn1: Ok.  Now we go to stage 2, which was ââ¦and then (b) from the livecd, run âubuntu-bug linuxâ.  Also attach the âlspci -A intel-conf2â output.â
<shawn1> how do I attach that?
<shawn1> ugh
<shawn1> didn't have a launchpad account
<RAOF> Heh.
<RAOF> You can just run âlspci -A intel-conf2â then copy the terminal output into a text file and attach that.
<shawn1> got it
<shawn1> I just didn't know what you meant because I've never done a bug report before
<RAOF> That's ok.
<shawn1> bug report sent.  Thanks!!
<shawn1> Will they send me some sort of response if it gets fixed?
<shawn1> or do I just kind of have to find out
<shawn1> ?*
<shawn1> erg
<shawn1> I have to leave
<RAOF> You'll get
<shawn1> thanks for all of your help, though!!
<shawn1> okay
<shawn1> thanks!!  =]
<RAOF> You'll get notifications when something happens to the bug.
<ohsix> RAOF: i keep trying to get shawn1 to post his dmesg :D there are a few bios pci enumeration modes you can try in case the bios does something funny
<RAOF> His dmesg should now be attached to that bug :)
<ohsix> right, it's been a few days now though
<RAOF> Yeah, it was difficult to get information out of them.
<ohsix> i think the intel-conf2 thing might be a red herring
<JabberwockyA19> Is there a list of backports made from kernel 3.3 ? I would like to know if 12.04 will have hdmi audio support for nvidia/amd open source drivers.
<RAOF> JabberwockyA19: By and large the list is "none".
<JabberwockyA19> iceroot told me about the changelog send with each deb package in the kernel-ppa, I just grep'ed for hdmi and audio.
<JabberwockyA19> only found updates in kernel 3.3-rc1
<diwic> JabberwockyA19, afaict there are no backports for open source hdmi audio
<JabberwockyA19> I'm trying to move away from proprietary drivers, but I'm not going to run 3.3-rc1 on the work's pc just yet. Can't wait to test it out at home though.
 * ppisati -> back in 10mins
<apw> cking, would you be able to cast an eye over chinstrap:~apw/stddev to see if it is indeed what i intended
 * cking looks
<apw> apw@dm$ stddev 2.218344 2.222308 2.222326 2.218320 2.214328
<apw> 0.00298821300445593
<elmo> apw: the result matches numpy.std() for whatever that's worth
<apw> elmo, so i am as inaccurate as numpy
<cking> 0.0029882130044559338661
<cking> double precision
<cking> 0.002988 single precision
<cking> apw, did you find your sigma char? Ï
<apw> cking, thanks
<cking> libreoffice states "STDEV: Estimates the standard deviation based on a sample".  Heh, it should not estimate but instead calculate the stdev
<apw> cking, perhaps it is using RANDOM()
<cking> perhaps the GUESS() function
<cking> apw, LibreOffice calculates the "sample std dev" where as we are calculating the "population std dev". The latter applies if the samples are a random sample drawn from a larger parent population. 
<apw> cking, so some other stddev than the one we are using then ?
<cking> yep, for N samples, the "sample std dev" divides by (N-1) where as the one we are looking at divides by N
<cking> since our population is a complete set and NOT randomly selected from a larger set, we can safely say dividing by N is OK for the "population std dev" which we are using
<apw> gah
<cking> heh, but with N being large it won't make much difference. Anyhow, you want to see how much variance there is and either calculation gives you a gut feeling of high or low sigma.
<cking> apw, this may be your friend: http://easycalculation.com/statistics/standard-deviation.php
<sforshee> jsalisbury, re bug 923512, see http://marc.info/?l=linux-wireless&m=132798971403989&w=2
<ubot2`> Launchpad bug 923512 in linux "ath9k wireless stopped working after kernel upgrade to 3.2.0-12" [High,Confirmed] https://launchpad.net/bugs/923512
<ogasawara> apw: can I mark "generate config review for omap4" as DONE?  I recall you resolved that at the rally.
<apw> ogasawara, i'll have to check, not sure if i did or not on the latest info ... will add it to todays todo
<ogasawara> apw: ack, thanks.
<ogasawara> jsalisbury: "document kernel team workflow" (from https://blueprints.launchpad.net/ubuntu/+spec/other-p-bug-workflows)... that got resolved at the rally too?
<jsalisbury> ogasawara, yes, that was taken care of at the rally
<jsalisbury> sforshee, thanks
<ogasawara> jsalisbury: k, I'm gonna mark it DONE then.  thanks.
<jsalisbury> ogasawara, cool, thanks.
<sforshee> jsalisbury, np
<ogasawara> jsalisbury: you going to get a test kernel built with the patch reverted for 923512?  I'd like to know the outcome asap.  I can help get it built if you're tied up with other things.
<jsalisbury> ogasawara, yes I posted the first bisected kernel, which worked fine.  I'm building the next kernel now.
<jsalisbury> ogasawara, this is one of the bugs I was having an issue bisecting, re the email I sent.  I found a workaround by bisecting in one tree and building in another.  I still haven't found the root cause, but I'll investigate further today.
<ogasawara> jsalisbury: and by "next kernel" do you mean a kernel with the patch reverted that sforshee mentioned?  or are you just continuing with the bisect?
<ogasawara> anyone else on the team have hw which uses ath9k?
<jsalisbury> ogasawara, sorry, with the patch sforshee mentioned reverted.  I want to bisect seperatly to also figure out the mainline-build-one issue. 
<ogasawara> jsalisbury: ack, thanks.
<HFSPLUS> ....................../Â´Â¯/) 
<HFSPLUS> ....................,/Â¯../ 
<HFSPLUS> .................../..../ 
<HFSPLUS> ............./Â´Â¯/'...'/Â´Â¯Â¯`Â·Â¸ 
<HFSPLUS> ........../'/.../..../......./Â¨Â¯\ 
<HFSPLUS> ........('(...Â´...Â´.... Â¯~/'...') 
<HFSPLUS> .........\.................'...../ 
<HFSPLUS> ..........''...\.......... _.Â·Â´ 
<HFSPLUS> ............\..............( 
<HFSPLUS> ..............\.............\...
<HFSPLUS> ....................../Â´Â¯/) 
<jussi> !ops
<ubot2`> Help! lamont, zul, T-Bone, mdz, or jdub
<HFSPLUS> ....................,/Â¯../ 
<HFSPLUS> .................../..../ 
<HFSPLUS> ............./Â´Â¯/'...'/Â´Â¯Â¯`Â·Â¸ 
<HFSPLUS> ........../'/.../..../......./Â¨Â¯\ 
<HFSPLUS> ........('(...Â´...Â´.... Â¯~/'...') 
<HFSPLUS> .........\.................'...../ 
<HFSPLUS> ..........''...\.......... _.Â·Â´ 
<HFSPLUS> ............\..............( 
<HFSPLUS> ..............\.............\...
<HFSPLUS> !ops | jussi
<ubot2`> jussi: Help! lamont, zul, T-Bone, mdz, or jdub
<HFSPLUS> ....................../Â´Â¯/) 
<HFSPLUS> ....................,/Â¯../ 
<HFSPLUS> .................../..../ 
<HFSPLUS> ............./Â´Â¯/'...'/Â´Â¯Â¯`Â·Â¸ 
<HFSPLUS> ........../'/.../..../......./Â¨Â¯\ 
<jussi> Pici: 
<HFSPLUS> ........('(...Â´...Â´.... Â¯~/'...') 
<HFSPLUS> .........\.................'...../ 
<HFSPLUS> ..........''...\.......... _.Â·Â´ 
<HFSPLUS> ............\..............( 
<HFSPLUS> ..............\.............\...
<Pici> uh
<jsalisbury> ogasawara, a test kernel with SHA1 7a532fe7131216a02c81a6c1b1f8632da1195a58 reverted is building on tangerine now.  I'll update the bug as soon as the build is done.
<ogasawara> jsalisbury: thanks.  lets put it on the hot list discussion this morning and see if anyone else has ath9k they can help test with and speed things along
<jsalisbury> ogasawara, ok, thanks.
<ogasawara> jsalisbury: assuming reverting fixes the issue, I'd like to upload but it may be too late.  I have to check with the release team.
<jsalisbury> ogasawara, ok.  
<ogasawara> jsalisbury: ah, hallyn can reproduce.  I'd ping him when you have a test kernel.
<jsalisbury> ogasawara, will do
 * ogasawara back in 20
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<jsalisbury> ogasawara, the test kernel is done building for bug 923512, uploading to people now.
<ubot2`> Launchpad bug 923512 in linux "ath9k wireless stopped working after kernel upgrade to 3.2.0-12" [High,Confirmed] https://launchpad.net/bugs/923512
<jsalisbury> hallyn, There is a test kernel for bug 923512, which is s dup of your bug 924015.  When you have a chance can you test the kernel?
<ubot2`> Launchpad bug 923512 in linux "ath9k wireless stopped working after kernel upgrade to 3.2.0-12" [High,Confirmed] https://launchpad.net/bugs/923512
<ubot2`> Launchpad bug 924015 in linux "Wireless drivers broken with latest precise kernel (dup-of: 923512)" [High,Confirmed] https://launchpad.net/bugs/924015
<jsalisbury> hallyn, The kernel can be downloaded from: http://people.canonical.com/~jsalisbury/lp923512/
<hallyn> jsalisbury: love to.  it'll be a bit before i'm out of meetings
<hallyn> (meaning i can't reboot)
<hallyn> i'll start downloading now
<jsalisbury> hallyn, cool, thanks!
<ogasawara> jsalisbury: did you revert that commit from the latest precise, or did you do an upstream build with it reverted?
<jsalisbury> ogasawara, upstream build with it reverted.
<jsalisbury> ogasawara, should I also build from the precise tree?
<ogasawara> jsalisbury: for this case, it would be better to revert it from precise and build, as then it would be identical to what we'd upload.
<ogasawara> jsalisbury: I can do that real quick and have it built by the time hallyn is done with this meetings
<jsalisbury> ogasawara, cool, thanks.
<ppisati> jjohansen: bug 893147
<ubot2`> Launchpad bug 893147 in linux-ti-omap4 "CVE-2011-4131" [Medium,Fix committed] https://launchpad.net/bugs/893147
<jsalisbury> ogasawara, I'll update the bug with a comment that the kernels I uploaded are from an upstream build
<ppisati> jjohansen: never mind, it's in master-next...
<tgardner> jsalisbury, make deb-pkg -j64 INSTALL_MOD_STRIP=1
<ogasawara> hallyn: if you could give that a test that'd be great -> http://people.canonical.com/~ogasawara/lp923512/amd64/
<hallyn> ogasawara: wait, i should use that instead of jsalisbury's?
<ogasawara> hallyn: I'd prefer that.  the one that jsalisbury built was an upstream kernel.  I built precise with the patch reverted.
<ogasawara> hallyn: and I'd prefer you test something identical to what we'd upload
<ogasawara> hallyn: I'd like to squeeze this in before the Alpha if we have time
<hallyn> ok
<ppisati> tgardner: do you know PARTUUID?
<tgardner> ppisati, not sure what you're asking. are you talking about /dev/disk/by-uuid ?
<hggdh> sconklin: how is the kernel SRU code doing?
<skaet> ogasawara, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/924400 - will the upload address this?  or is it something new?
<ubot2`> Launchpad bug 924400 in linux "kernel NULL pointer dereference at 00000000000001f0" [Undecided,Confirmed]
<ogasawara> skaet: this upload would only contain a fix for 923512, I'd have to take a look at 924400
<ogasawara> skaet: I'm still waiting on test confirmation though for 923512
<skaet> ogasawara, ok,  thanks.    Let slangasek and myself know the results of the test confirmation.   We'll be doing a respin this afternoon, so want to pick up your regression fix if possible. 
<ogasawara> skaet: indeed, I'm hoping hallyn can get us his results soon
<skaet> :)
<hallyn> ogasawara: all good
<ogasawara> hallyn: sweet!  thank you!!
<hallyn> what pray tell was the bug?
<ogasawara> hallyn: bad patch from v3.2.2 stable
<ogasawara> commit b4a82a0a2e32777267b2c997fa55b90056447a40
<ogasawara> Author: Felix Fietkau <nbd@openwrt.org>
<ogasawara> Date:   Sat Jan 14 15:08:34 2012 +0100
<ogasawara>     ath9k_hw: fix interpretation of the rx KeyMiss flag
<ogasawara> skaet: ^^
<njin> bug 924400
<ubot2`> Launchpad bug 924400 in linux "kernel NULL pointer dereference at 00000000000001f0" [Undecided,Confirmed] https://launchpad.net/bugs/924400
<hallyn> great, thanks, glad to be back :)
<ogasawara> skaet: ok for me to upload?
<njin> can someone tell me under wich tag send this upstream?
<skaet> ogasawara, sorry, yup.
 * ogasawara uploads
<skaet> ogasawara, has anyone else reproduced the kernel oops that nijin is seeing with today's images?   bug 924400
<ubot2`> Launchpad bug 924400 in linux "kernel NULL pointer dereference at 00000000000001f0" [Undecided,Confirmed] https://launchpad.net/bugs/924400
<tgardner> apw, smp: Start up non-boot CPUs asynchronously
 * tgardner -> lunch
<ogasawara> skaet: not that I know of
<skaet> ogasawara, ack
 * jsalisbury --> lunch.  Be back in ~1hour.
<tgardner> bjf, do you know how to update a mini-iso image in cobbler after the initial import ?
<bjf> tgardner: nope
<jono> hey
<jono> is anyone seeing bugs in Precise regarding wireless randomly de-authenticating - I filed https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911059
<ubot2`> Launchpad bug 911059 in linux "Intel wireless randomly drops connection" [Medium,Incomplete]
<jono> I filed it a little while back
<jsalisbury> jono, There were a couple of requests in that bug to test some kernels.  Do you think you'll be able to do that?
<jsalisbury> jono, basically the latest Precise and latest mainline kernels.
<jono> jsalisbury, I will test that - which kernel?
<jono> I am running latest Precise now
<jono> and I still get the bug
<jsalisbury> jono, ok, the latest mainline can be found at: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.3-rc1-precise/
<jono> jsalisbury, do I just install the headers and image for my arch, reboot and select that kernel?
<jsalisbury> jono, yes.  you probably don't need the headers, just the image for your arch.
<jsalisbury> jono, further details on mainline kernels can be found at:  https://wiki.ubuntu.com/KernelMainlineBuilds
<jono> jsalisbury, downloading now
<jsalisbury> jono, cool.  It would also be great to know the last version of the kernel that did not have this issue, so we can bisect.
<jono> jsalisbury, I have had this since I upgraded to Precise
<jono> jsalisbury, ok, rebooting now into the new kernel
<jsalisbury> jono, can you see if you boot back into the latest oneiric kernel the issue goes away.  The latest oneiric kernel can be found at: https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/3061070/+files/linux-image-3.0.0-15-generic-pae_3.0.0-15.25_i386.deb
<jono> jsalisbury, ok I am now running:
<jono> Linux forge2 3.3.0-030300rc1-generic-pae #201201191835 SMP Thu Jan 19 23:51:25 UTC 2012 i686 i686 i386 GNU/Linux
<jsalisbury> jono, it looks like you were running linux-image-3.2.0-7-generic-pae when you reported the bug.  Did you try 3.2.0-12.20, which is the latest precise? 
<jono> jsalisbury, yep, I have been fully up to date in Precise
<jono> now I am running:
<jono> Linux forge2 3.3.0-030300rc1-generic-pae #201201191835 SMP Thu Jan 19 23:51:25 UTC 2012 i686 i686 i386 GNU/Linux
<jono> and so far so good
<jsalisbury> jono, hmm, interesting.
<jono> jsalisbury, mind you, it seems to randomly drop the wireless, so it might happen in a bit
<jsalisbury> jono, OK, it would be great if you can test the kernel for a while to see if the bug is really fixed.  If it is, we can try to identify what commit actually fixed it.
<jono> jsalisbury, absolutely, I will keep using this until it happens again
<jono> and hopefully it won't happen again :-)
<jono> this bug has been driving me nuts
<jsalisbury> jono, thanks, and just to confirm, you ran with 3.2.0-12.20 and that version had the bug.
<jono> jsalisbury, I have basically experienced the bug with every Precise kernel
<jsalisbury> jono, ok, thanks.  
<jono> thanks for taking the time to help me with this jsalisbury
<jsalisbury> jono, np.  It would be great to get this bug fixed.
<jono> yes indeed :-)
<jono> jsalisbury, the bug just happened
<jono> how can I get some useful debugging info to you?
<jono> I guess I should any info in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911059
<ubot2`> Launchpad bug 911059 in linux "Intel wireless randomly drops connection" [Medium,Incomplete]
<jsalisbury> jono, I think the next best thing to do is to have you test the latest oneiric kernel, and confirm the bug does not exist there.  Then we can bisect between the latest oneiric and earliest precise.
<jsalisbury> jono, can you test one more kernel, at:
<jono> sure
<jsalisbury> jono, https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/3061070/+files/linux-image-3.0.0-15-generic-pae_3.0.0-15.25_i386.deb
<ohsix> jono: does the randomness "feel" like it may be heat related?
<jono> ohsix, I don't think so
<ohsix> ok, i've only seen that with broadcom devices anyways
<jono> jono@forge2:~/Downloads$ sudo dpkg -i linux-image-3.0.0-15-generic-pae_3.0.0-15.25_i386.deb
<jono> dpkg-deb: error: `linux-image-3.0.0-15-generic-pae_3.0.0-15.25_i386.deb' is not a debian format archive
<jono> dpkg: error processing linux-image-3.0.0-15-generic-pae_3.0.0-15.25_i386.deb (--install):
<jono>  subprocess dpkg-deb --control returned error exit status 2
<jono> Errors were encountered while processing:
<jono>  linux-image-3.0.0-15-generic-pae_3.0.0-15.25_i386.deb
<jono> jsalisbury, ^
<jono> oh hang on
<jono> it is still downloading
<jono> LOL
<jsalisbury> jono, ok
<jono> just really slowly
<tgardner> jono, did you load with 11n-disable=1 to see if it had an impact ? 'sudo modprobe -r iwlagn;sudo modprobe iwlagn 11n_disable=1'
<jono> tgardner, I haven't tried that
<jono> how do I pass a kernel options at boot?
<ohsix> is there anyone that mirrors ddebs? (getting a big -dbgsym, say for the kernel is quite an ordeal, also it would be very nice if there was a package just with vmlinux in it, and in a place where perf can find it :)
<jono> or should I modprobe -r it?
<tgardner> jono, it would go into /etc/modprobe.d
<jono> tgardner, ok, I will try booting the Oneiric kernel first, see how that works and then try and do this
<jono> brb, rebooting
<jono> thanks folks
<tgardner> jono, just modprobe it by hand for now to see if it makes a difference (once you've tested Joe's kernels)
<jono> jsalisbury, ok I am now running:
<jono> Linux forge2 3.0.0-15-generic-pae #25-Ubuntu SMP Mon Jan 2 19:40:15 UTC 2012 i686 i686 i386 GNU/Linux
<jono> the package wanted me to install wireless-crda
<jono> which it grabbed from Precise
<jono> I am not sure if this will affect anything
<jono> I will see if this bug nails me
<tgardner> jono, you should be OK
<jono> thanks tgardner
<tgardner> wrt wireless-crda
<tgardner> jono, if the bug continues, then try 'sudo modprobe -r iwlagn;sudo modprobe iwlagn 11n_disable=1' with any of these kernels.
<jono> tgardner, I assume I don't need to reboot when I have run that command?
<jono> just re-connect to the network
<tgardner> jono, correct
<jono> thanks tgardner
<ohsix> is modprobe -r generally preferable over rmmod?
<tgardner> its the same thing
<tgardner> modprobe removed dependent modules
<ohsix> (i know modprobe != insmod though)
<tgardner> removes*
<ohsix> ah, cool
<cking> anyone tried to install the daily precise ISO on a netbook - this is taking forever
<tgardner> cking, yesterday
<cking> hrm, cursor won't move, it's kinda locked up 
<tgardner> hmm, maybe its gonna take along, long time
 * cking leaves it for another 10 mins
 * tgardner is EOD
<cking> EOD is a good idea
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues Feb 7th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<jono> jsalisbury, still working fine, I think the Oneiric kernel might be fine
<jono> which would suggest that the book does exist from a new kernel onwards
<jono> I am going to keep testing this kernel to see if it happens though
<jsalisbury> jono, ok, thanks.  
<jsalisbury> jono, maybe you can try the following tomorrow on a precise kernel:
<jsalisbury> sudo modprobe -r iwlagn;sudo modprobe iwlagn 11n_disable=1
<jono> indeed, will do
<jsalisbury> jono, thanks
<jono> thanks jsalisbury
<jsalisbury> jono, np
<hallyn> ogasawara: that kernel you had me try, did it by chance not have the lxc reboot kernel patch applied?
<ogasawara> hallyn: it should have
<ogasawara> hallyn: you're talking about the "Add reboot_pid_ns to handle the reboot syscall" patch right?
<hallyn> eah
<hallyn> yeah
<hallyn> ogasawara: never mind, separate tests confirm it should be working - sorry
<hallyn> (so something else is goign wrong here)
<ogasawara> ok cool
#ubuntu-kernel 2012-02-01
<\sh> moins
<apw> moin
<\sh> guys, somehow I'm missing a module in 3.2.0-* ubuntu kernel  series in precise
<\sh> and this module is named "aufs.ko" it's in 3.0.0-* series in oneiric but somehow I don't find it in the modules directory of 3.2.0-*
<apw> \sh, yep, thats gone
<\sh> woot?
<\sh> what's the replacement?
<apw> we are using overlayfs for our livecds
<ashish__> can i calc the cpu usage from stat file by reading it once 
<\sh> apw, that's a nice one...so live-boot from debian is broken now, because they are still using aufs
<ashish__> as i m geetting some skipped results
<apw> \sh, well i think we use live-boot too now, so i assume we have a fix for that somewhere
<apw> \sh, else we'd not be able to make cds ourselves
<apw> ashish__, skilled results ?
<ashish__> apw:skipped as in i am not getting the usage when the usage graph moves suddenly up n is down soon
<\sh> apw, well, I would like to see the fix ;) but why are we not building the module anymore...replaceing aufs with something better ok, but removing a module is not ok ;) somebody could rely on the availability of this module ;)
<apw> \sh, because it is an out of tree module which required a large amount of support effort to maintain
<apw> \sh, overlayfs is slated to be the replacement, and we don't want to have to support both for 5 years in P
<ashish__> i would like to know hw top gives dynamic usage 
<apw> \sh, and the only way to find out if people are using it is to remove it and see if they can use overlayfs
<apw> ashish__, dynamic useage of CPU?  as in instantaneous load ?
<\sh> ok...so how do we fix live-boot to use overlayfs
<apw> \sh, i have no idea ;)
<\sh> or how do I compile the aufs module by myself ;) 
<apw> \sh, well the code isn't going to be in the tree for much longer, as we have yet to find anything which can't be converted over
<apw> \sh, so you'd be porting it yourself to the tree to use it
<apw> \sh, as i say i believe we are using live-boot for our CDs, and i don't think its needed in the making just the booting of them in the default configuration
<apw> \sh, and we definatly have fixes in ubuntu to allow use of overlay in preference
<apw> \sh, now our liveCDs are made by the foundations lot who might be able to clarify my ramblings
<apw> \sh, they hang out on #ubuntu-devel, asking there about live-boot might get you closer
<\sh> cjwatson in charge for this?  :)
<ogra_> apw, dont mix live-boot with live-build :)
<apw> ogra_, heh i may be :)  if so then they will know :)
<ogra_> i dont think we use live-boot (that would replace casper i think)
<ogra_> but we use live-build to roll the rootfs
<apw> ogra_, ahh, then ... 
<ogra_> so \sh should send a patch to debian ;)
<\sh> ogra_, there was one
<\sh> http://live.debian.net/devel/rfc/overlayfs/
<\sh> but the patch is gone 
<ashish__> stat file gives me data but shld i include irq,iowait,softirq too  or they are included in user ,nice ,sys processes
<apw> \sh, thats handy indeed, perhaps it went in
<\sh> apw, no
<tkamppeter> Did someone already have a look into bug 917148? Working USB printing is essentially important.
<ubot2`> Launchpad bug 917148 in linux "Kernel problems when accessing USB printers" [Critical,Confirmed] https://launchpad.net/bugs/917148
<apw> \sh, thats unhelpful
<\sh> apw, it's WiP and the patch is gone from paste.d.n
<ogra_> \sh two solutions, use casper for your live images or fix debian :) 
<\sh> wait
<\sh> ogra_, I'm trying to get FAI working ;)
<\sh> no casper for me here ;)
<ogra_> well, then fix debian :)
<apw> tkamppeter, how do we know this is a kernel issue?
<\sh> ogra_, looks like the fix is in live-boot...now I need to find a way to enable it
<ogra_> aha
<apw> \sh, the fix is applied already ?
<\sh> apw, looks like...I just made a simple grep for overlayfs in the live-boot-initramfs-tools..and found it
<\sh> so I'm trying to enable it
<apw> \sh, so i think that rfc page has the incantation at the bottom
<apw> --bootappend-live union=overlayfs \
<\sh> apw, yeah...I'll play with it nwo
<\sh> now even
<apw> tkamppeter, how do we know this is a kernel issue? i can't tell from the bug how we have decided that
<smb> tkamppeter, Just skipping over it I see libusb segfaulting and some devices not properly attach as highspeed which sometimes is a hw fault
<tkamppeter> apw, I have used several different access methods (CUPS USB backend with old libusb 0.1.x, CUPS USB backend with new libusb 1.0.x, HP's packet mode, multiplex USB backend) and always get the same problem, the data stream breaks even at the same position in the file.
<tkamppeter> smb, all devices under test worked until Natty.
<tkamppeter> smb, can you see which libusb is segfaulting? 0.1.x? 1.0.x? Both?
<smb> tkamppeter, in the dmesg you provided in the bug: 1.0 it seems
<smb> segfault at 0 ip 00007f1e2f866ed8 sp 00007fff205f8970 error 6 in libusb-1.0.so.0.0.0[7f1e2f863000+d000]
<apw> tkamppeter, as this has been since natty it might also be worth checking precise too
<smb> tkamppeter, It would help to have a dmesg of something that just boots up starts a print job and fails
<apw> the precise kernel works well for me on oniric userspace for a quick test
<tkamppeter> apw, perhaps I should downdate libusb to Natty and repeat the HP backend and USB-libusb-0.1.x test.
<apw> tkamppeter, that is another good test to try
<diwic> ogasawara / apw, upstream has committed my fixes for bug 923316, bug 923409 and bug 924320. Should I wait a week for it to reach Linus's tree, or should I do something now for you to get it quicker?
<ubot2`> Launchpad bug 923316 in linux "[regression] Speakers are not muted while plugin the headphone " [Medium,In progress] https://launchpad.net/bugs/923316
<ubot2`> Launchpad bug 923409 in linux "[Both front and rear Line-In] No sound (codec parsing fails)" [Medium,Fix committed] https://launchpad.net/bugs/923409
<ubot2`> Launchpad bug 924320 in linux "[HDA Intel] output to hdmi:0 is heard through internal speakers as well" [Undecided,In progress] https://launchpad.net/bugs/924320
<apw> diwic, in precise or earlier, we've missed A2 now so there is little rush
<diwic> apw, ok so that means wait a week (i e until linus has pulled takashi's tree)?
<diwic> apw, and then I'll propose cherry-picks/backports to the k-t ML
<diwic> ?
<diwic> (yes, it's 12.04)
<tkamppeter> Didi someone have a look into bug 900802?  It is a trivial "add another device ID" bug. I have the iPhone 4S and it works great.
<ubot2`> Launchpad bug 900802 in ipheth "PATCH: Got the USB tethering of the iPhone 4S working" [Undecided,Fix released] https://launchpad.net/bugs/900802
<tkamppeter> apw, now I did a simple attempt to reproduce the bug on stock Oneiric, with the HP backend which uses libusb 0.1.x. I do not observe a segfault, but both dmesg and syslog say:
<tkamppeter> Did not find alt setting 1 for intf 0, config 1
<apw> tkamppeter, ok so if its failing in that configuration, without the segfault, then i would say get a natty kernel and boot that up, and see if just changing that fixes the issue
<tkamppeter> So good part of the job printed, meaning that the communication worked and suddenly it is not able any more to find the channel to the printer which it used for the already printed part of the job.
<apw> tkamppeter, the alt settng message is an initialising error, not something i would expect mid communication
<apw> anyhow the logical test now is get and boot a natty kerenl, leaving everything else the same, and re-test
<tkamppeter> apw, will do so now ...
<tkamppeter> apw, smb, I have booted the old kernel and it stops the same way. Seems that I have to try a libusb downdate now.
<apw> tkamppeter, ok so it sounds like its not a kernel level issue then ... 
<tkamppeter> apw, also downgrading libusb to Natty's does not help. The HP backend always says: unable to write data, 45 second io timeout
<apw> tkamppeter, so whats left thats not been changed :/
<apw> tkamppeter, it may be an interaction between libusb and another system library for instance
<tkamppeter> apw, on a Lucid VM it works.
<apw> one way to eliminate t
<apw> things might be install a Natty system and upgrade the various parts one at a time till it breaks
<tkamppeter> apw, on a Precise VM it does not work, so it broke somewhere on the way and virtualization does not unbreak it (then I would feature-request that a standard installation would install a minimum Linux with the real Linux in a VM).
<tkamppeter> apw, so the best to do now is to install a Natty VM ...
<apw> tkamppeter, yeah sounds like a plan
<tkamppeter> apw, I am doing so now ...
 * tgardner is repairing chroots on gomeisa
 * tgardner is rebooting tangerine in 5 minutes
<arges> smb, hello! question about bug 881542. do you know when this fix is planning on being released?
<ubot2`> Launchpad bug 881542 in linux "Ubuntu 10.04 LTS as guest freezes after xm restore" [Medium,Fix committed] https://launchpad.net/bugs/881542
<smb> arges, when it is out of proposed? :-P
<smb> arges, But seriously, let me check
<arges> smb, : )
<arges> smb, thanks
<smb> arges, Hm, this actually looks like it should be released already. Might just have failed to auto-update the bug because the patch from upstream stable replaced the sauce patch
<smb> 2.6.32-37.80 seems to be the release
<arges> smb, ok that's good to know. i can check that too 
<arges> smb, yes see 676dc3cf5 in ubuntu-lucid. 
<smb> arges, yep, I'll update the bug right now
<arges> cool. thanks
<tkamppeter> apw, smb, Installed Natty, sent the job, works ...
<tkamppeter> apw, smb, upgrading only libusb, still works ...
<tkamppeter> apw, smb, still there?
<apw> tkamppeter, and the kernel as well ?
<apw> it may be an interaction between those two both being updated, or a third thing
<tkamppeter> Trying to install the 3.0.0-15 kernel on Natty, but this does not work, when the postinst script generates the initrd, it gives a Python traceback, in /usr/bin/nvidia-detector.
<tkamppeter> And my VM is most probably not emulating an NVidia card on a system with Intel GPU.
<tkamppeter> apw ^^
<tkamppeter> apw, trying to also update the nvidia-common package ...
<tkamppeter> apw, now kernel installation completes.
<apw> yeah there was some bug or other in the detection back then, interesting
<tkamppeter> apw, seems to be missing versioned package dependency in kernel package.
<apw> i think it was ok as we never expect those combinations to ever exist together
<apw> those kernels arn't supported back there
<tkamppeter> apw, new kernel up and running, job sent ...
<tkamppeter> apw, job succeeded.
<apw> ok so its neither of those then, its something else ... now ... what is harder
<tkamppeter> apw, ldd /usr/lib/libusb-0.1.so.4 shows only linux-vdso, libc, and ld-linux=x86-64, so no non-standard libs libusb is depending on ...
<apw> well i guess we need to update those one by one till it stops
<tkamppeter> apw, so next candidates to update seem HPLIP and CUPS, where I cannot imaging that CUPS can break it. It is on USB communication level.
<apw> tkamppeter, well it could be an app->libc interaction, a bug in either
<apw> so i'd be interested in upgrading the underlying layers too
<apw> tkamppeter, i assume we know the job is the same binary data in the working and non-working cases
<tkamppeter> apw, so I am trying to upgrade these standard libs now.
<tkamppeter> apw, there is no binary file in the whole distro with vdso in its name. So it seems that linux-vdso is a part of the kernel and therefore is already upgraded.
<apw> tkamppeter, yeah that makes sense, its instantiated by the running kernel
<tkamppeter> apw, the other two are part of libc6, so this is the next package to update.
<apw> tkamppeter, ok
<tkamppeter> apw, this pulls a lot of other libs and all compilers: cpp-4.5, g++-4.5, gcc-4.5, gcc-4.5-base, lib32gcc1, lib32stdc++6, libc-bin, libc-dev-bin, libc6, libc6-dev, libc6-i386, libgcc1, libgomp1 libstdc++6, libstdc++6-4.5-dev, make, pkg-config
<tkamppeter> apw, the compilers, dev, and 386 packages are probably irrelevant. Should I try to update the others one by one until it breaks or should I simply update libc6?
<vanhoof> apw: ogasawara: my hair looks absolutely fabulous today
 * ogasawara is worried
<vanhoof> ogasawara: finally got it cut :)
<apw> tkamppeter, i think i'd go for libc
<tgardner> vanhoof, we need photographic proof.
<vanhoof> tgardner: http://ubuntuone.com/62ljS1z8foknvmaOG1dZep
<vanhoof> tgardner: :)
<tgardner> vanhoof, hmm, looking pretty clean cut :)
<jsalisbury> vanhoof == vanwho
<jsalisbury> :-)
<vanhoof> tgardner: i feel like a new man :)
<tgardner> vanhoof, I always marvel at how much less shampoo it takes right after a new haircut.
<tkamppeter> apw, installing libc6 ...
<vanhoof> tgardner: seriously
<tgardner> vanhoof, seriously, TMI ?
<vanhoof> tgardner: was having to pull the whole grandma trick of putting water in the bottle to make it last longer ;)
<vanhoof> lol
<tkamppeter> apw, sent job again, printing is still working.
<vanhoof> tgardner: you didn't notice the extra set of ears :)
<tkamppeter> apw, rebooted now to make everything using libc6 use the new version, another print job, still printed.
 * ogasawara back in 20
 * jsalisbury --> reboot
 * apw watches tooo many upgrades in profress ...
<apw> tkamppeter, hmmm, must be one of the other deps then
<tkamppeter> apw, trying to update HPLIP, but probability is low as the problem occurs also with CUPS USB backend.
<tkamppeter> apw, still prints correctly.
<apw> gargle
<apw> tkamppeter, then its something else, any other libraries the binaries use there?
<apw>  /b -x
<tkamppeter> apw, having updated CUPS, which pulled Ghostscript and now it seems that it has stopped.
<tkamppeter> apw, this changes the binary stream as Poppler is replaced by Ghostscript at one point, but in the rasterization produced by HPLIP's hpcups driver only randomn bits should different which should not break USB communication.
<apw> hmmm
<apw> tkamppeter, well we need to keep replacing bits till somethign tilts
<apw> tkamppeter, however unlikely
<tkamppeter> apw, now I can switch between the good state and the broken state: with Ghostscript it is broken and with Poppler it works.
<apw> tkamppeter, so perhaps something coming out of the gs version is malformatted and upsets the remote printer
<apw> and perhaps its not a transport thing at all
 * tgardner --> lunch
 * tgardner -> EOD
<emgent> hello guys
<emgent> kees: around ?
<noahmehl> I need some help with bridge-utils
<noahmehl> anyone here familiar?
<jono> jsalisbury, btw, still no network dropping issues with the Oneiric kernel
<jono> so it must be an issue in Precise
<jono> I will test the kernel switches next
<jsalisbury> jono, cool, it will be great to hear if the issue happens with n disabled
<jono> totally, will wrap this call and then try that
<jsalisbury> great
<jono> jsalisbury, want me to boot the latest 3.2 kernel and then run: sudo modprobe -r iwlagn;sudo modprobe iwlagn 11n_disable=1
<jono>  ?
<jsalisbury> jono, yes, thanks
<jono> jsalisbury, cool, will do
<jono> will update the bug report if I see an issue
<jsalisbury> thanks
#ubuntu-kernel 2012-02-02
<jono> hey jsalisbury
<jono> I am now running 3.3
<jono> and ran: sudo modprobe -r iwlagn;sudo modprobe iwlagn 11n_disable=1
<jono> lsmod doesnt show iwlagn in there, is that normal?
<RAOF> jono: Yeah; iwlagn got renamed to iwlwifi (somewhere between 3.0 and 3.2, I'm not sure where)
<RAOF> jono: There's an alias of iwlagn â iwlwifi, though, so modprobing iwlagn should have (correctly) loaded iwlwifi.
<jono> RAOF, cool
<apw> cking, ohhh, network ?
<cking> yep, now connected again, at last
<smb> cking, \o/
<soren> cking: I'm blown away by the battery life on my laptop in Precise. Thank you so much for all the work you've done on this.
<cking> soren, well, a really big thanks goes to pitti for fixing a load of user space bugs that we discovered doing the original research
<soren> cking: Well, still, you clearly did a lot of work on it, collected all the important data. The effect is astounding.
<cking> soren, I also suspect a lot of fixes in the kernel that landed in 3.2 helped, so it's mainly kudos to upstream ;-)
<cking> but at least we know what to expect for the next cycle ...
<ohsix> what's this regarding? at least the research, is there a blag about it or something?
<cking> ohsix, http://smackerelofopinion.blogspot.com/2012/01/improving-battery-life-in-ubuntu.html
<ohsix> thanks
<cking> ohsix, lots of data from the analysis can be found in: http://zinc.canonical.com/~cking/power-benchmarking/
<ohsix> hm i thought the devices that could use low power states already did, except for ALPM which was disabled for stabilitysomethings; will digest tomorrow, thanks for the refs
<cking> there is a lot of data there, so fee free to ask questions, I will see if I can answer them sensibly..
<ohsix> will fwts get some related tests? or is there another test tool for people to check this stuff or is it manual investigation when things start exploding
<ohsix> er i should mention i started reading the article before the one you posted, http://smackerelofopinion.blogspot.com/2011/12/improving-battery-life-in-ubuntu.html
<ohsix> if some of them might have stability implications how will they be tested
<ohsix> anyways, night :] will have more pointed questions tomorrow
<cking> ohsix, I don't think we will put any more power management related tests into fwts.  An aspm check has been added to fwts, but that's about it really 
<cking> as for tools for checking this stuff, it is a little tricky - the kit I used is expensive, so it's not a thing most users can do accurately
<cking> but I did make a few tools and put them into a PPA: see https://launchpad.net/~colin-king/+archive/powermanagement
<jwi> cking: do you expect your work to make a difference for bug 877560 ? any improvements in power.d/intel-audio-powersave ?
<ubot2`> Launchpad bug 877560 in linux "Audio codec draining power when not in use" [Undecided,Confirmed] https://launchpad.net/bugs/877560
<ohsix> cking: ah i didn't mean duplicating the results with the meter and whatnot, i meant aside from aspm; the other things mentioned in the list like quiesing usb/pci devices (presumably it's not done already for "stability") if in fact it's unstable on someones machine with it enabled, will there be some tools to assist with that
<cking> jwi, I think we need to test this with some accurate power measuring tools - powertop needs to be run for quite a while before we can trust the data from it - and it could be that the battery info isn't accurate
<cking> ohsix, no tools for this, that wasn't really in the project scope - my aim was to find the low-hanging fruit that could be easily fixed
<ohsix> i looked into doing something like that in the past but the battery type in the machines i have access to just provide the battery level from the charge controller, not any wattage or accurate gas gauge type measurements
<ohsix> and i couldn't gut my laptop to get a meter in there :>
<cking> ohsix, yes, so I basically had to be a bit invasive - I bypassed the battery info altogether and measured current drawn from the machine 
<ohsix> through the cable?
<cking> yep,
<ohsix> bah i could just read the article, no more silly questions
<ohsix> if there is a sort of aggressively enable sleep even if it breaks stuff, and you want to have some people shake stuff out, i'd be interested in that as well
<ohsix> night!
<cking> ohsix, sure, night! :-)
<cking> jwi, I've updated that bug with some advice to see if we can get more accurate idea of what's happening.
 * ppisati -> back in 10mins
<herton> ppisati, these arm bugs are waiting on verification: bug 912199 and 861296. The last one was already verified on other flavours, but to be on the safe side if it can be verified on normal omap kernel would be great, can you take a look at them?
<ubot2`> Launchpad bug 912199 in linux "Wrong Beagle XM detection" [Undecided,Fix committed] https://launchpad.net/bugs/912199
<ubot2`> Launchpad bug 861296 in linux-ti-omap4 "mmap fails to allocate 2030Mb heap on ARM" [Undecided,Fix committed] https://launchpad.net/bugs/861296
 * apw pops into the office, back in a bit
<rbasak> ppisati: I just got this panic on the current precise armhf installer kernel: http://paste.ubuntu.com/826304/
<rbasak> Does this mean anything to you?
 * apw admires the view
<ogra_> ppisati, you didnt by chance happen to stopwatch the boot with the PARTUUID parameter, did you (btw, you rock !)
<apw> ppisati, what sort of uuid did you use here?
 * ppisati just came back
<ppisati> ogra_: nope, because there's a delay after mounting the fs... $something is waiting on $something else, that's why i didn't take any measure, but it was definitely faster
<ppisati> herton: i'll have a look
<ogra_> ah, thats alread good news at least
<ogra_> i'm not sure how eas it is to redo our image build process to use GPT though, i need to research that 
<ppisati> apw: GPT UUID, the one from the second partition
<apw> ppisati, ahh so you put both down on the disk did you ?
<ppisati> apw: what you mean?
<apw> you put both a dos partition table and a gpt down on the same disk
<ppisati> apw: right, it's called an hybrid-mbr (but it's actually a GPT)
<ppisati> apw: so the old "bios" think it's a MBR, go ahead and boot it
<apw> very cools, ogra_ does that give you waht you need to do the speed comparison ?
<ppisati> apw: and once we have access to the first partition, we can chainload the loaders+kernel (that in turn can speak GPT)
<ppisati> rbasak: never seen that, how did you got it?
<ogra_> apw, well, after i found out how to roll GPT partitions (and if thats possible at all with the tools on the image build server) into our images
<rbasak> ppisati: nothing different to what I've been doing
<apw> ppisati, yeah thats most excellent
<rbasak> ppisati: just an attempt to netinst
<apw> ogra_, if you are careful yu may be able to add the gpt after installing, if the first partition is aligned correctly, there ought to be enough space
<apw> ogra_, cirtianly worth checking
<ogra_> thats the issue
<ogra_> changing the first partition alignment might break the first stage bootloader
<apw> normally we round up a bit for partition 1 .. to a cylinder boundary
<ogra_> at least on the TI images ... the rom code on tehse chips is a bit silly
<apw> so there ought to be a bit of space in there already without moving things
<apw> ogra_, like on my laptop here there is 2048 sectors wasted at the front
<apw> /dev/sda1   *        2048   150341631    75169792   83  Linux
<apw> so you may have some space there by default too
<ogra_> lucky you, for us its rather the opposite ;)
<ppisati> ogra_: actually you don't have to add anything, you have to convert the MBR to a GPT
<ogra_> anyway, i'll try to look into it asap
<ppisati> ogra_: once you have an image installed, fire gdisk and it'll tell you what you have to do
<ogra_> ppisati, with the size we currently use ?
<ppisati> ogra_: yep
<ogra_> oh, thats convenient
<ogra_> !
<apw> ogra_, i think there has to be enough space or something, i am sure its at least one track as i think grub hides in there
<apw> ogra_, and the gpt steals one of those blocks, but grub has redundant copies or something odd
<ogra_> ah, well, no grub for us yet :)
<apw> ogra_, then you definatly have room :)
<ppisati> herton: verification-done-oneiric? or was it verification-passed?
<herton> ppisati, verification-done-oneiric
<ppisati> herton: i passed 912199 but for 861296 some java madness must be done, prod GrueMaster for it
<herton> ppisati, ok. There is a testcase there though, I think you could use it instead of playing with java stuff
<ppisati> herton: ah right, i forgot about it
<ppisati> herton: i'll do
<apw> tgardner, no wired at the drop in desks, that would be tooo useful
<tgardner> apw, bummer. maybe you should sit next to Michelle ?
<smb> Bet he is
<tgardner> ogasawara, should ubuntu-q master-next HEAD be set to the same as master ?
<ogasawara> tgardner: yep.  I didn't even think to create a master-next yet.
<tgardner> ogasawara, ok, I'll take care of it.
<ogasawara> tgardner: great, thanks.
<ogasawara> tgardner: there have been a good number of patches applied to Precise that haven't yet made it to Q.  I'll get that sorted today.
<tgardner> ogasawara, good idea
<tgardner> ogasawara, master-next created
<ogasawara> ack
 * ogasawara back in 20
<GrueMaster> Prod me for what???
 * GrueMaster is starting to feel like livestock.
<ppisati> GrueMaster: will you do lp861296?
<GrueMaster> ppisati: What needs testing?  I already have the mmap testcases in my SRU test suite.
<ppisati> GrueMaster: ah, so you are automatically going to test it, cool
<GrueMaster> Well, like i said, which kernels?  I'm currently only testing omap4, imx51, and dove SRU kernels (I don't get notifications for any other platforms).
<ppisati> GrueMaster: omap3?
<GrueMaster> Ok.  I'll look into it.  It will take some time, as I only have 1 platform.
<ppisati> GrueMaster: k
<GrueMaster> So, looking at the bug, Natty forward?
<ppisati> GrueMaster: it seems there's even M to test
<GrueMaster> That's omap4.
<ppisati> ah ok then
<GrueMaster> omap was Linux main from Natty forward iirc.  In Maverick, it was a separate kernel.
<herton> testing is needed for linux-image-2.6.35-32-omap 2.6.35-32.65, linux-image-2.6.38-13-omap 2.6.38-13.55, linux-image-3.0.0-16-omap 3.0.0-16.27
<herton> linux-image-2.6.35-32-omap 2.6.35-32.65 isn't omap4, or am I wrong?
<herton> GrueMaster, ppisati ^
<GrueMaster> herton: I show linux (Maverick) as invalid in the bug.  And omap4 kernels end in omap4 not omap.
<GrueMaster> Separate trees.
<herton> GrueMaster, ah, that status should be wrong, the fix went to omap kernel as well
<GrueMaster> Ok.  You fix the bug, I'll run the tests.  :P
<GrueMaster> ppisati: So this bug is in all the latest SRU kernels for omap, or do I need some private build?
<GrueMaster> (just looking for clarification while I image).
<ppisati> latest SRUs
<GrueMaster> Cool.  Makes imaging and testing easier as I can just use my local mirror.
<bjf> join #ubuntu-server
<GrueMaster> ppisati: Not having a stable mac address on the beaglexm is going to slow me down some.  Just fyi.
 * tgardner -> lunch
<jono> jsalisbury, updated https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911059
<ubot2`> Launchpad bug 911059 in linux "Intel wireless randomly drops connection" [Medium,Confirmed]
<jono> the bug is definitely still present
<jono> tgardner, ^
<jsalisbury> jono, the bug is still present with N disabled?
<jono> yep
<jsalisbury> ok, looking at bug
<jsalisbury> jono, thanks for testing.  Maybe the best thing is to bisect and try to find the commit that caused this.  What do you thing tgardner ?
<jono> thanks jsalisbury - unfortunately it is making the current Precise kernel pretty much unusable on this machine
<jono> jsalisbury, also, if you want further community testing, I can have the QA guy on my team get some further input
<tgardner> jono, does it work pretty well with the oneiric kernel ?
<jono> tgardner, perfectly
<jono> although I didn't disableN
<jono> although I didn't disable N
<jono> just a regular boot of the kernel
<tgardner> jono, didn't you say tha your AP didn't have N enabled anyways ?
<jono> Linux forge2 3.0.0-15-generic-pae #25-Ubuntu SMP Mon Jan 2 19:40:15 UTC 2012 i686 i686 i386 GNU/Linux
<jono> tgardner, I am not sure if it does
<jono> it is the bog standard AT&T AP
<tgardner> dunno what that is
<jono> no idea what the AP is either
<jono> let me know if I can help any more with this though
<jono> such as if you need any log files
<tgardner> jono, the failure cases aren't logging anything useful
<jsalisbury> jono, would you be able to test some additional test kernels, if we bisect?  It may take several iterations.
<jono> jsalisbury, sure!
<jsalisbury> jono, cool, I'll post some links to kernels in the bug.
<jono> jsalisbury, cool, thanks!
 * cking --> EOD
<bryceh> jsalisbury, bug #912992 has some gfx fixes identified for snb, so you probably want that bug on your radar.
<ubot2`> Launchpad bug 912992 in xserver-xorg-video-intel "[snb-m-gt2+] Primary laptop display not working, external monitor works fine. [Fixed as of linux-image-3.3.0-994-generic_3.3.0-994.201201290428 from drm-intel-fixes branch]" [High,Fix released] https://launchpad.net/bugs/912992
<bryceh> jsalisbury, do you want me to subscribe or assign these kinds of bugs to you, or just ping on irc?
<jsalisbury> bryceh, pinging me would be great.
<jsalisbury> bryceh, adding the kernel-da-key tag will also put them on my primary report.
<bryceh> ok
<ogasawara> tgardner: I'm gonna prep an upload now that Alpha-2 is out.  Anything else you want in before I pull the trigger?
<tgardner> ogasawara, pick up sforshee's nvidia patches ?
<ogasawara> tgardner: yep, just did.
<tgardner> ogasawara, manoj bluetooth IDs ?
<tgardner> nm
<tgardner> ogasawara, hmm, can't think of anything else
<sforshee> tgardner, ogasawara: I'll have some radeon patches shortly as well
<jsalisbury> bryceh, do you happen to know the SHA1 for the upstream fix in bug 912992 ?
<ubot2`> Launchpad bug 912992 in xserver-xorg-video-intel "[snb-m-gt2+] Primary laptop display not working, external monitor works fine. [Fixed as of linux-image-3.3.0-994-generic_3.3.0-994.201201290428 from drm-intel-fixes branch]" [High,Fix released] https://launchpad.net/bugs/912992
<ogasawara> sforshee: shortly as in before EOD?
<sforshee> ogasawara, yeah, probably within the next 30 minutes
<jsalisbury> bryceh, if you don't know off hand, I can search for it.
<ogasawara> sforshee: cool, I'll wait then and squeeze those in before I upload.
<bryceh> jsalisbury, sorry, nope I don't know.  They alluded to snb work on the upstream bug but didn't specify patch(es).  I did see there's only a couple recent patches in the branch.
<jsalisbury> bryceh, cool, thanks.  I'll do some searching.
<jono> jsalisbury, will test the 3.1 kernel now and see how I get on
<jsalisbury> jono, thanks
<jono> :-)
<njin> Great this message: Busy inodes after unmount of sda1. Self-destruct in 5 seconds. Have a nice day...
<bryceh> jsalisbury, lp #915408 is also ripe and ready
<ubot2`> Launchpad bug 915408 in xserver-xorg-driver-ati "Garbled display on external screen when using 1920x1080 instead of 1920x1200" [High,Confirmed] https://launchpad.net/bugs/915408
<jsalisbury> bryceh, ok, thanks
<jsalisbury> bryceh, do you always add the  kernel-handoff-graphics tag to these types of bugs?
<jsalisbury> bryceh, if so, I recall we wanted to make a report to capture these.
<bryceh> jsalisbury, yes
<jsalisbury> bryceh, great.  I'm going to create a report based off that tag
<sforshee> ogasawara, I just sent the radeon patches
<bryceh> until now I had been assuming that was sufficient to get them on your todo list
<ogasawara> sforshee: ack, thanks
<jsalisbury> bryceh, adding that tag would really help :-)
 * tgardner -> EOD
<bryceh> jsalisbury, ok, I'll use both tags from now on, unless you tell me different
<jsalisbury> bryceh, cool, thanks.  you can drop adding the kernel-da-key tag once I create the new report.  So may just add it till then end of tomorrow.
<bryceh> alrighty
<jono> jsalisbury, so the 3.1 kernel has the bug
<jono> which narrows it down a little
<jono> man...it is bad in the 3.1 kernel
<jsalisbury> jono, him interesting.  I'll go back a little further and post an earlier kernel.
<jono> thanks
<jsalisbury> bryceh, New report is created: http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/_kernel_graphics_bugs_.html
<jsalisbury> bryceh, can you take a look and see if it looks accurate to you?
<jsalisbury> bryceh, it may not have the last two bugs you tagged for a half an hour or so.
<jsalisbury> bjf, ^^^ This is the report that's been on the todo list
<bryceh> jsalisbury, seems like about the right amount of bugs
<jsalisbury> bryceh, cool.  So no need to add that kernel-da-key tag.  Just the one you've been using.
<bryceh> ok, perfect
<jsalisbury> bryceh, thanks for getting me to do this.  It's been on the todo list for a while ;-)
<bryceh> it should be handy here on out.  I've got a backlog of upstreamed bugs I'm expecting to see kernel patches for down the pike.
<jsalisbury> bryceh, cool
#ubuntu-kernel 2012-02-03
 * cking on 3G again, my ISP is doing network infrastructure changes, i.e. providing lame service
<smb> cking, The change the infrastructure to make you buy the full product. 
<cking> if it carries on like this I will move to a different ISP
<cking> well, 3G seems to work well enough for irc and email and they hope to get it fixed by 1pm
 * cking notes they didn't say which day though
<smb> Prepare for the worst... Well on the other hand. Distractionlesser day
<cking> well, less mumble traffic today ;-)
<apw> cking, testing your 3G ?
<smb> cking, Right, which can be a big source of distraction
<cking> apw, 3G seems to work quite well from my loft .. not bad really
<smb> cking, while you are still there, have you had luck catching panics with netconsole before?
<cking> smb, I believe not, but I haven't used it much
 * cking can't recall 
<cking> the plus side is that it isn't too tricky to rig up
<smb> cking, Ah ok. Could not remember whether you had been using that at all
<smb> Thought I had something... though did not see any message which may say I did not
<cking> I've used it for debugging - but I'm not sure if I got any panics captured using it 
<smb> cking, <hope>is there a setup rune on your blog?</hope>
<cking> afraid not :-(
<smb> cking, Oh well. Now I have to use my own brain... ;-P
<cking> steady on
<ppisati> ok, i sent two patches to the kernel ml but the cover letter doesn't show up WTF???
<cking> ppisati, they show in my mailbox
<cking> with cover letter
 * cking switches network provider ..
<smb> ppisati, Oh, now it does
<smb> Seems to have taken a detour
<cking> apw, inotify test in your inbox
<apw> cking, ok
<herton> ppisati, do you have a panda a4 board?
<ppisati> herton: uhmm... i think i've an a2
<ppisati> herton: why?
<ppisati> herton: actually i've an A1
<herton> ppisati, just thinking if you could test the fix of bug 917264, but that requires this a4 board and hdmi. Anyway, as that bug is tested on previous release with the patch on top, I may well mark that as verified
<ubot2`> Launchpad bug 917264 in linux-ti-omap4 "HDMI resolutions are not detected on Pandaboard A4 (Omap 4430 ES2.3 silicon)" [Undecided,Fix committed] https://launchpad.net/bugs/917264
<ppisati> herton: ah! pandaES, that's even more rare than a real Panda :)
<apw> http://www.theregister.co.uk/2012/02/03/bt_vision_upgrade/
<brendand> can anyone think of a good reason why the first cpu core would be offlines by default on say a 16 core system?
<brendand> i've seen it on two systems. two different models of processor, the common thread being they are both 16 core
<hallyn> apw: bug 925028, is there any chance you'll have time for that?  do you have any idea what the problem is offhand?
<ubot2`> Launchpad bug 925028 in lxc "apparmor breaks lxc-start-ephemeral (apparmor+overlayfs returns -EINVAL)" [High,Confirmed] https://launchpad.net/bugs/925028
<brendand> Daviey - i'm seeing a couple of servers here running Alpha 2 which have one of their 16 cores offline by default. seems a bit strange - does it make any sense to you?
<skaet> hiya,  anyone know if bjf will be around today?
<apw> hallyn, another issue ?
<hallyn> apw: apparmor returns -EINVAL on any overlayfs file
<hallyn> apw: it's possible this is purely apparmor's problem and I should hit up jjohansen again, but I wasn't sure
<apw> hallyn, cirtainly we should get jj involved yes
<apw> hallyn, gawd what does this drivel even mean ...
<hallyn> the code, or my report?
<apw> hallyn, this is a case of it making sense to the reader, if they get lxc and apparmor i suspect
<apw> hallyn, so #3 does that say that you don't need a container here
<hallyn> right
<hallyn> just mount an overlayfs, have an enforcing apparmor policy, boom
<hallyn> which means, i'd expect libvirt to fail on livecd
<hallyn> (untested)
<apw> i'd not expect you to want to use libvirt on a live cd, but hey
<apw> hallyn, anyhow i'll poke jj and see what this means
<hallyn> apw: tahnks.  sorry, yesterday i was pretty sure it was just another missing hook, but now i'm thinking not...
 * ogasawara back in 20
<jjohansen> hallyn: hrmm, that sounds wrong, give /me needs to get kids off to school and then I can look at it
<apw> hallyn, what does this capabilities list even say ?  is that essentially "allow all" ?  the one in #3 ?
<apw> jjohansen, lets talks when you get back
<jjohansen> apw: sure.
<apw> jjohansen, you can teach me what this gibberish in dmesg means
<jjohansen> apw, hallyn: apparmor only return EINVAL in a few places
<hallyn> i see, the gibberish is my policy :)
<hallyn> anyway we don't want to allow all - we'll want to deny cap_mac_admin and cap-mac_override in final policy
<apw> hallyn, yeah i was trying to work out if the policy there was actually essentially a noop
<hallyn> apw: the one in the example was meant to be a noop
<apw> hallyn, ok cool ... thanks thats what it looks like
<hallyn> changing locales - biab
<skaet> ogasawara, did you ever hear back from bjf (from last week) about the rls-mgr-p-tracking report, and why its not updating?
<bjf> skaet: i just updated it this am, is it not correct?
<ogasawara> skaet: he fixed it
<bjf> skaet: it should have been working just fine
<skaet> Friday, 20. January 2012 02:01 UTC 	  Themes:   DARK   LIGHT
 * skaet trying again
<skaet> yeah,  cache reload still showing that to me. 
<bjf> one sec
<bjf> skaet, mine says "Friday, 03"
<ogasawara> looks up to date -> http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/rls-p-tracking-bugs.html
<bjf> skaet, i also looked at the timestamp on the file on cranberry and it is this am
<ogasawara> out of date -> http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/rls-mgr-p-tracking-bugs.html
<bjf> ogasawara: yes, the second is out of date
<skaet> bjf,  its the second one (rls-mgr-p-tracking) I'm trying to get working again.  :)
<bjf> skaet: ok, that wasn't clean. fixing now
 * skaet thinks we need to rename those reports and the tags....  later though.  :P
<bjf> skaet: it was turned off several weeks ago, i've re-enabled it and it's running
<skaet> bjf - any idea why it was turned off?
<bjf> skaet: didn't think anyone was looking at that one, just the other and it was sucking cycles
<bjf> skaet, it will now run with all the rest
<bjf> skaet: or maybe i turned it off last week when debugging that issue, and just forgot to re-enable it
<bjf> skaet: anyway, it should be fixed now
<skaet> bjf,  thank you.   the rls-mgr-p-tracking one is where folks are tagging things that should be considered.   rls-p-tracking is only those things that teams COMMIT to fix. 
<bjf> skaet: (as soon it regenerates)
<skaet> there's a delta between the consider and the commit - both are useful.
<skaet> however - the tags do seem to be causing confusion.
<skaet> maybe a transition to something like consider-p-tracking,  commited-p-tracking at some point in the future?
<bjf> skaet: feel free, it's in bzr :-)
<skaet> bjf,  heh,  A2 is out the door - time for a new learning curve for me I guess...
<jjohansen> apw: alright I am back
<apw> jjohansen, hiya, balcony ?
<jjohansen> sure
<jjohansen> apw: sure
<apw> [ 4184.672209] type=1400 audit(1328288723.893:35): apparmor="DENIED" operation="getattr" info="Failed name lookup" error=-22 parent=2619 profile="/bin/bash2" name="" pid=2634 comm="ls" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
 * jsalisbury see pulseaudio crash, then mumble freak out and consume 100% cpu, spinning on sched_yield()
<hallyn> maybe thats what used to happen to my banshee
<jsalisbury> hallyn, yeah, could be.  I have issues with banshee once and a while as well.  Now I know what to look at :-)
<ohsix> doom to he who uses sched_yield
<bjf> skaet: all reports should be updated now
<ohsix> why can't they just sleep :[
<skaet> Thanks bjf!   Yup,  now I can see all the new packages that need to be sorted into teams too.  :)   
<ohsix> jsalisbury: that looks like a pulse bug (the _yield thing, it's done a lot to wait on async queues, something has to go really wrong though)
<ohsix> i guess pulse crashing is wrong enough, but it should be getting a sigpipe or something in the client when it happens
<jsalisbury> ohsix, hmm, maybe mumble likes to do things really wrong 
<ohsix> how pulse exited is probably interesting too, killed by rtkit, killed by its own rttime quanta or killed by a crash
<jsalisbury> ohsix, yeah, I plan on digging deeper
<bjf> skaet: ok, i just updated the packate->teams matrix (this has to be done by hand)
<ohsix> src/pulsecore/shmasyncq.c:#define _Y pa_thread_yield()
<ohsix> :[
<ohsix> wait a minute, it only does that during debugging
<skaet> bjf - thanks.  I'll be making more changes to the package-team spreadsheet later today (lots of lovely new packages this release showing up)  do you want to teach me to fish,  so I can do the update for you in future?
<ohsix> i dunno what else could be calling _yield then, mumble only does in some speex performance test, not in the program proper
<bjf> skaet, bdmurray: i just regenerated all reports, they are now as up-to-date as i can make them
<bjf> skaet: can do
<skaet> bjf,  ok,  as soon as I get the next round of changes in,  I'll ping you and you can walk me through it.
<jsalisbury> ohsix, interesting.  I better check all my mumble settings again.  If I can get it to startup again :-/
 * ogasawara back in a bit
<GrueMaster> ppisati, herton:  linux-omap meta for maverick needs to be updated.  It only installs linux-image-2.6.35-24-omap. 
<herton> GrueMaster, indeed they were removed from linux-meta previously, I'll look into fixing it
<GrueMaster> Testcases pass once I got the right kernel installed.  Running the rest of the SRU gammit now.
<jono> jsalisbury, hey
<jsalisbury> jono, howdy
<jono> jsalisbury, just updated the bug
<jsalisbury> jono, cool, I'll take a look
<jono> I think that is all the testing I can do on the available kernels
<jono> thanks
<jono> the bug occurs between 3.0 and 3.1rc2
<jsalisbury> jono, thanks for testing. 
<jono> thanks
<jsalisbury> jono, I'll check what changed between  3.0 and 3.1rc2.  Would you be able to test some additional test kernels if I bisect?
<jono> jsalisbury, sure
<jsalisbury> jono, awesome!  I'll update the bug
<tgardner> apw, I'm wondering how you use debian/scripts/misc/insert-mainline-changes ?
<apw> insert-mainline-changes debian.master/changelog v3.2.3 v3.2.2..v3.2.3
<apw> tgardner, something like that
<apw> it allows you to specify the range in case you don't have the tags, so you can use sha1s if you need to
<apw> tgardner, then you'll find git diff shows what its done to changelog
<tgardner> and you've documented this where ?
<apw> :))
<apw> tgardner, if there is somewhere you'd recommend, i can add it
<tgardner> how abiout just getting it in the help message with a quick example
<apw> yeah that would have made sense
<apw> tgardner, i'll do it now and push it up, you can cherry it onto your rebase before you push
<tgardner> apw, so all I got from that was '* rebase to v3.2.3'. does that mean there were no buglinks ?
<apw> tgardner, thats the implication if i didn't mess up the incantation :)
 * apw checks
<apw> tgardner, indeed no buglinks so ... it did nothing, but thats not always the case
<apw> and i assume ogasawara used it for the 33-rc1 rebase, which would have had a bunch i bet
<apw> ogasawara, which reminds me, we probabally need to include -v when we upload the first one into Q if we want those buglinks to work
<ohsix> anyone know offhand of any of the ld_preload hacks to lessen the impact on the file cache for cron jobs and such? akpm had something on userweb.kernel.org but it's not there anymore
<ohsix> oh neat i think i found a descendent of it on google code
<cking> ohsix, is this what you are referring to? http://smackerelofopinion.blogspot.com/2009/06/does-prelinking-speed-up-boot-times.html
<ohsix> cking: not unless it uses an LD_PRELOAD hack to keep read pages out of the page cache (i'm trying to get a duplicity cron job that's run hourly to not completely destroy interactivity for most of the hour between runs)
<cking> ohsix, in which case, it's not what you're looking for
<ohsix> there was a flag added a while ago but it was wired up to a no-op, dunno if this got in http://lwn.net/Articles/449420/
<ohsix> looks like they made rsync use it already too, librsync doesn't (or can't, don't think it deals with files directly)
<tgardner> apw, have you pushed? vanilla 3.3 don't build anyways. working on figuring out the missing dependency
<tgardner> 3.2.3*
<apw> tgardner, waiting on atime wrappage update time disk hell
<cking> apw, that always seems to coincide with beer time doesn't it?
<apw> i think there is a cirtain alignment :/
<ohsix> bummer, _NOREUSE is still a no-op
 * cking -> EOD
<apw> tgardner, pushed
<ohsix> heh posix_fadvise DONTNEED on linux trashes all the file pages no matter who has it open, that seems fun
<vanhoof> ogasawara: heya
<bryceh> bjf, you might adjust your kernel bot to not bug reporters if the kernel-handoff-graphics tag is present; generally we only add that when we pretty much already know the bug's disposition (and usually have found a fix)
<bjf> bryceh: can do
<bjf> bryceh: you have an example bug?
<tgardner> ogasawara, pushed precise master-next with v3.2.3 stable. there is likely more carnage yet to come as I expect Greg will release v3.2.4 shortly due to compile issues.
 * tgardner -> lunch
<ogasawara> tgardner: ack, thanks.
<ogasawara> vanhoof: hi
<bryceh> bjf, yeah hang on
<bryceh> bjf, 912992 854986 
<bryceh> bjf, seems like there was another one I saw the other day but am not putting my finger on it
<vanhoof> ogasawara: quick question on the cw-3.2 lbm update for oneiric
<vanhoof> ogasawara: will what's in -proposed now have to land before we see the fix in 923900 land?
 * vanhoof is not exactly sure how the lbm cadence works
<ogasawara> vanhoof: hrm, it could go up separately, but I suspect bjf/herton will just want up coordinate it with the kernel in -proposed.
<herton> ogasawara, vanhoof: I't not sure how it was done previously, may be we could shove this new version into current -proposed
<bjf> herton, i'm fine with pushing it
<ogasawara> herton, vanhoof: it looks like https://launchpad.net/ubuntu/+source/linux-backports-modules-3.0.0/3.0.0-16.8 has already been uploaded to -proposed
<vanhoof> herton: yeah this is the first time i've encountered a bug like this 
<ogasawara> herton, vanhoof: so I suspect it'll move to -updates at the same time as the kernel
<vanhoof> ogasawara: and then the next upload would be another update to lbm to factor in bug 923900 ?
<ubot2`> Launchpad bug 923900 in linux-backports-modules-3.0.0 "Enable iwlwifi drivers for compat-wireless v3.2 backports" [Undecided,In progress] https://launchpad.net/bugs/923900
<herton> yes, 3.0.0-16.8 is the current one in -proposed, as it didn't move yet to -updates (and I think it will wait for more 1 week for it), I think a new lbm could be copied so it gets along when -proposed moves
<herton> we just would have to ask an archive admin to copy a new lbm over proposed again
<ogasawara> vanhoof: yep, sorry.  we would need another upload LBM to resolve 923900.  but as herton just mentioned, they should be able to shove that up now.
<vanhoof> ogasawara: no worries, and thanks for the info :)
<ogasawara> herton, bjf: I assume LBM is not under as strict a QA schedule as the kernel since it's an elective install.  and I'm sure vanhoof is willing to give you immediate testing feedback.
<vanhoof> and beer
<bjf> ogasawara: i don't think QA knows LBM exists
<herton> yeah, never saw anyone mentioning QA of lbm. I'll prepare a new lbm, and ask it to be copied then to -proposed. I already have to ask for a new linux-meta copy for maverick also, because of the missing omap/versatile metas
<vanhoof> herton: bjf: just poke me and I can get some widespread testing done quickly
<herton> ack
<bjf> vanhoof: ack, i'd expect monday actually before it hits -proposed
<vanhoof> bjf: good deal
<vanhoof> thanks guys :)
<tgardner> ogasawara, v3.2.3 boots, ship it!
<ogasawara> damn, we still gotta get 3.2.0-13.22 out.  /me checks if arm is finished building
<tgardner> ogasawara, I was thinking we might oughta skip -13
<ogasawara> tgardner: works for me
<tgardner> ogasawara, if you upload today, it should be done by monday.
<ogasawara> tgardner: ack, prepping the upload now
 * ogasawara gets ready to hammer on gomeisa
<tgardner> ogasawara, are the chroots on gomeisa behaving normally? I'm still having issues with resolvconf in the precise chroot.
<ogasawara> tgardner: i was doing test builds yesterday and all seemed fine
<ogasawara> tgardner: but I didn't look closely at the logs to see if anything was amiss
<tgardner> ogasawara, I need to make sure that the resolvconf issues aren't preventing package updates.
<tgardner> guess I should build a lucid host on one of my local boxes and make sure.
<tgardner> that sounds like a good weekend project.
<Beret> so, I just filed a fatal usb bug and a bot told me I was running an old kernel 
<Beret> which is not true :)
<Beret> anyone seen "HC died" messages?
<ohsix> what type of host controller?
<ohsix> and the bot checks the packages available vs. what's installed as a gentle reminder to update and try the latest
<ohsix> or you're running a kernel that doesn't match the regular version pattern
<Beret> I believe intel
<Beret> no
<Beret> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/926310
<ubot2`> Launchpad bug 926310 in linux "USB failing" [Undecided,Incomplete]
<Beret> I'm running the latest kernel in precise
<Beret> but that bug happened occasionally in oneiric and all the time in precise
<Beret> never in natty
<Beret> I thought my little kvm switcher was to blame
<Beret> so I plugged the keyboard/mouse in direct, and I get the same behavior
<Beret> doesn't matter what's plugged in
<Beret> given a little time, it dies
<tgardner> ogasawara, you've likely got precise tied up in a bow and ribbon and are ready to upload ?
<ogasawara> tgardner: I've got it ready, just waiting for powerpc test build to finish up
<tgardner> ogasawara, greg released 3.2.4 with the 2 reverts I suggested, but since they are already reverted from our tree we can just skip it
<ogasawara> tgardner: ack
<tgardner> ogasawara, so I just re-installed the precise chroots on a lucid host which seemed to work OK. I guess I'll re-install gomeisa one more time. you done for now ?
<ogasawara> tgardner: can you gimme 10min?  just kicked off a build.
<tgardner> ogasawara, no problem. I can do it later this weekend
<tgardner> I'm about EOD
<tgardner> it _is_ friday, the sun is shining, and I find myself in need of a beer
<ogasawara> I've purposely lowered the blinds to not be distracted by that giant fireball in the sky
<bdmurray> heh
 * tgardner is outta here
<bdmurray> jsalisbury: I just ran across bug 924455 (a ubiquity bug) which has an oops in it
<ubot2`> Launchpad bug 924455 in linux "kernel oops running installer" [Undecided,New] https://launchpad.net/bugs/924455
<jsalisbury> bdmurray, thanks, I'll take a look
<hallyn> tgardner: I'm looking at bug 898003.  Do you think it'd be reasonable to build usbip from the kernel package (as it all now ships under drivers/staging)?
<ubot2`> Launchpad bug 898003 in linux "usbip source is maintained in kernel tree now" [Low,Confirmed] https://launchpad.net/bugs/898003
<mjg59>  /win 34
<bjf> bryceh: the bot should not bother bugs tagged kernel-handoff-graphics any longer
<bryceh> bjf, awesome thanks
<htorque> bryceh: hi! about to test if bug 899159 is still a problem â mesa 8.0~rc2-0ubuntu4 is the right version?
<ubot2`> Launchpad bug 899159 in xserver-xorg-video-intel "[snb-gt2] GPU lockup render.IPEHR: 0x7b009004 [Needs mesa 7.11+git]" [High,In progress] https://launchpad.net/bugs/899159
<bryceh>   htorque sounds good
<Sarvatt> htorque: please please please dont test unigine benchmarks for it, they have an application bug and its not expected to work with whats up currently 
<Sarvatt> oilrush is the only unigine using app thats been updated to work right
<ohsix> what's the bug?
<Sarvatt> ohsix: https://bugs.freedesktop.org/show_bug.cgi?id=45238 it's fixed in mesa master by adding application specific hacks so it works but not on 8.0 branch yet
<ubot2`> Freedesktop bug 45238 in Mesa core "[regression] Unigine Heaven, OilRush broken in git" [Normal,Resolved: notourbug]
<ohsix> Sarvatt: thanks for the ref
<htorque> bryceh: didn't went well, immediately got a 0x7a000002 hang (no apport crash file)
<htorque> bryceh: unity somehow acted up (everything was running but no window manager/launcher/panel was showing), restarting unity fails with "intel_do_flush_locked failed: Input/output error"
<Sarvatt> bryceh: https://bugs.freedesktop.org/show_bug.cgi?id=42538
<ubot2`> Freedesktop bug 42538 in Drivers/DRI/i965 "Sandybridge GPU hang + reset while running OpenGL application" [Normal,Reopened: ]
<bryceh> htorque, ok, then the bug report should get forwarded upstream now
<bryceh> htorque, thanks for testing
<bryceh> Sarvatt, yeah looks like that is htorque's bug
<htorque> bryceh: not seeing those "[drm:pch_irq_handler] *ERROR* PCH poison interrupt" messages in dmesg, but else sounds similar to what i see.
<Sarvatt> those have nothing to do with the bug
<htorque> bryceh: what can i do with this apitrace.log to reproduce it?
<Sarvatt> those usually show up with a dock or kvm in use
<htorque> ok, ignored. :-)
<bryceh> htorque, not sure
<Sarvatt> its not packaged but you can replay the .trace with apitrace https://github.com/apitrace/apitrace its definitely a mesa bug
<htorque> Sarvatt: thanks, will try
<htorque> bryceh: Sarvatt: yes, that produces the same 0x7a000002 hangs for me
<Sarvatt> htorque: kinda odd is every reporter of the same bug I can find is using a desktop K series sandybridge CPU
<Sarvatt> 8086:0112
<Sarvatt> mobiles don't seem to be affected, no wonder I can't reproduce it
<Sarvatt> i only have desktop non-K series (8086:0102) and all the mobiles handy
<htorque> i only got a thinkpad with an arrandale with a hd 2000 :-(
#ubuntu-kernel 2012-02-04
<Kano> apw: did you notice that there is aufs3
<EvilResistance> is the ubuntu 3.0.x kernel backported to 11.04 (or available for 11.04)?
<Kano> EvilResistance: you can simply install mainline. even 3.3
<Kano> but you can get problems with extra modules
<EvilResistance> Kano:  you'll have to define "mainline"... i've been out of the loop with kernel stuffs.
<Kano> mainline=unpatched kernel code
<Kano> http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=M;O=D
<EvilResistance> any patched code?  the main reason i ask is because i'm curious about the power management patches, and whether they're in any of the kernels yet
<Kano> but you need updates/fixes for nvidia/fglrx and such things
<EvilResistance> mhm.
<EvilResistance> will the patches and updates be in 12.04 LTS?
<Kano> well when you dont need external modules then it is no problem at all to install a new kernel
<Kano> what gfx card do you use?
<bryceh> ( `lspci | grep VGA` )
<EvilResistance> 01:00.0 VGA compatible controller: nVidia Corporation G98M [Quadro NVS 160M] (rev a1)  <-- (from lspci)
<EvilResistance> its on a 3 year old laptop so...
<EvilResistance> :P
<Kano> then most likely you use nvidia binary
<Kano> i know patches to nv, but i only use u kernels and no u itself
<bryceh> G98 may work fine with just -nouveau
<Kano> depends on your definiting of work fine
<ohsix> really depends on your proclivity for whining about things
<EvilResistance> also depends on how much you care about the kernel complaining :P
<Kano> i usually use latest nv beta if it has got no errors for me
<ohsix> and how large the system latencies you can tolerate as it goes in and out of the blob
<Kano> which was the case with 295.09, but 295.17 is fine
<ohsix> does 295.17 do kms?
<Kano> i dont need kms
<Kano> do you need wayland?
<ohsix> heheh, so that depends on your definition of fine
<ohsix> no but i have a deep personal need to edit config files when i want to add a display
<Kano> bryceh: reclocking support will often crash, using boot speed is a joke. i prefer dynamic clocks, vdpau i like as well
<Kano> it is enough to see something in live mode
#ubuntu-kernel 2012-02-05
<fairuz_> Hi, I follow instructions here https://wiki.ubuntu.com/KernelTeam/GitKernelBuild to compile the mainline kernel.
<fairuz_> I get both the .debs but when installing the header, I got this error http://paste.ubuntu.com/830622/
<fairuz_> I look up at the log file and have this -> http://paste.ubuntu.com/830624/
<fairuz_> Is this a known issue? Thanks
<tdmackey> fairuz_: it's a virtualbox issue
<fairuz_> tdmackey: Hmm but I do not understand what it does there? (in my compiling and installing process)
<tdmackey> you have virtual box installed and it is trying to compile the virtualbox driver for your new kernel
<tdmackey> and your version is old and not compatible with the newer kernel source you're using
<fairuz_> tdmackey: ah ok. I found that the issue is solved with newer version of vbox.
<fairuz_> So maybe I can just upgrade vbox and recompile.
<tdmackey> yes.
<fairuz_> tdmackey: Thanks!
<fairuz_> tdmackey++
<fairuz_> tdmackey: I remove virtualbox using the software center but I still get the error. Can I just remove /usr/src/virtualbox folder?
#ubuntu-kernel 2013-01-28
<ppisati> moin
<smb> morning
<ashwini> is there any link to know how to use kgdb over ethernet with kernel 3.x ??
<apw> zequence, no that is fine for now, but for next time yes
<ppisati> brb
<hrw> hi
<hrw> is https://help.ubuntu.com/community/Kernel/Compile still the only source of 'how to adapt ubuntu kernel to your needs'?
<smb> hrw, There would also be https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel. Though it just might be 'different' and not add much more... not sure
<henrix> ogasawara: do you know who could verify bug #1103320?
<hrw> anyway 'debian/rules editconfigs' just kill my whole config anyway
<ubot2> Launchpad bug 1103320 in linux (Ubuntu Quantal) "Ubuntu 13.04 and 12.04.2: Login screen does not appear after installing OS on SL4545 G7" [Medium,Fix committed] https://launchpad.net/bugs/1103320
<smb> hrw, not sure I understand. It will run menuconfig with presets taken from the current flavour configs and saves them there...
<hrw> smb: before: 75624 config.flavour.chromebook after: 93 bytes of comments only
<smb> hrw, If the setting will not affect other flavours or is commonly used, things may get moved to one of the higher level config files (even config.common.ubuntu)
<hrw> smb: in other way: if just one kernel is built from tree then flavour file is just placeholder and all is moved to common/
<hrw> time to kill enforce checks 
<ogra_> that means you will miss ubuntu options the userspace needs 
<ogra_> well ... you risk to miss them at least
<smb> hrw, If that flavor actually has nothing from either the architecture or common configuration I would say yes. apw <-- ^ ?
<hrw> smb: it is chromebook kernel which I am trying to update
<smb> hrw, And as ogra_ said those checks are there for a reason. 
<hrw> sure, I know that
<apw> hrw,smb, right if you have one flavour the then all of the settings are common and move up
<apw> you can confirm the config is the same however by 'debian/rules genconfigs' and looking at CONFIGS/<name>
<hrw> CONFIG_USB_DEVICEFS is listed as deprecated. ubuntu still requires that?
<apw> seems to no longer exist in raring at least
<apw> if that is an accurate spelling
<hrw> I have 3.4 kernel
<apw> debian.master/config/enforce:value CONFIG_USB_DEVICEFS n
<apw> and we insist it is off, not on ?
<hrw> ahm right
<hrw> ogra_: can CONFIG_GPIO_TWL4030 land in omap kernels only (enforcement)?
<ogra_> not sure how configs vs. dtb will work but sure
 * ppisati goes out for lunch
<hrw> few more enforces to kill and kernel should get to state where I can try to build
<hrw> check-config: 41/41 checks passed -- exit 0
<hrw> uf.
<hrw> there were few other things which I would love to kill but no time
<hrw> thanks guys
 * cking going offline, electrical supplier is doing meter upgrade soon
<ogasawara> henrix: i'll ping narinder to verify 1103320.  he not online yet, but will be in a few hrs.
<henrix> ogasawara: great, thanks
 * henrix -> reboot
 * ogasawara back in 20
<infinity> apw: I can haz meta-lowlatency to match the kernels?
<apw> infinity, yeah i am doing them right now
 * ppisati -> gym
<ogasawara> infinity: random question re: the clean old kernels stuff, I thought you'd completed that work?
<infinity> ogasawara: It's mostly complete in raring, except for some "polish" work items.
<infinity> ogasawara: We haven't backported it to precise, which was also a goal.
<ogasawara> infinity: ack, thanks.  I had a random work item to check up on it's status.
<infinity> ogasawara: Oh, right, I saw that WI in passing. :)
<infinity> ogasawara: I think you'd checked.  DONEify it.
<apw> infinity, in better news it even seems to work for me :)
<infinity> bjf: Want to do a manual shankbot run for me to see if it wants to update the lowlatency tracking bugs?  I'm trying to sort out of Andy bollocksed them again, or if I'm just impatient. :)
<bjf> infinity, ack
<infinity> bjf: Oh, I see.  It takes two iterations. :/
<infinity> bjf: First one sets upload-to-ppa as Fix Release, second sets the promote-to-proposed task to Confirmed.  Weird.  Why the artificial delay?
<bjf> infinity, just the way it's coded
<infinity> bjf: (And one more run to fix that, please? :P)
<bjf> infinity, i'm runing it multiple times
<bjf> infinity, it doesn't loop on one bug/task until there is nothing to do
<infinity> Ahh, so you are.  It caught up to where I wanted it now. :)
<infinity> Cheers.
<bjf> infinity, i'm giving it one more for good measure
<ogasawara> apw: refresh my memory, you'd written a script we'd run after we rebase that would insert any BugLinks fixed in the latest rebase into our changelog
<ogasawara> apw: I can't remember the name of that script
<apw> ogasawara, insert-upstream-changes
<apw> debian/scripts/misc
<ogasawara> apw: ah, thanks!
<ogasawara> apw: I was looking in kteam-tools and was having no luck
<apw> heh
<einonm> Hullo, I've just posted a patch to the kernel-team list to fix an ubuntu kernel issue I discovered (Bug #1105250) ... the patch is probably also needed in the upstream kernel - what's the general procedure for that? Should I just post the patch upstream and wait for it to trickle down to you, or is a direct patch to ubuntu-kernel also good?
<ubot2> Launchpad bug 1105250 in linux (Ubuntu) "MSI laptop, crash on first suspend and suspend fails thereafter" [Medium,Incomplete] https://launchpad.net/bugs/1105250
<jsalisbury> einonm, yes, it's best to send the patch upstream for inclusion.  I can post a comment in the bug on how to do that.
<einonm> jsalisbury: Thanks. I've got a linux-next tree, so just run the usual get-maintaners on that, but also cc an ubuntu email?
<jsalisbury> einonm, yes, get-maintainers will tell you who to send it to.  Be sure to cc stable.  There is some info in the source tree ~/Documentation/stable_kernel_rules.txt
<einonm> great, will do.
<jsalisbury> einonm, thanks.  
<bjf> :w
<zequence> apw: The lowlatency meta for precise, is it still wrong?
<apw> 'still wrong' ?
<zequence> The wrong version
<apw> looks to match to me in the current pocket versions ?
<apw> linux-meta-lowlatency | 3.2.0.36.26 | precise-security/universe | source
<apw> linux-meta-lowlatency | 3.2.0.36.26 | precise-updates/universe | source
<apw> linux-lowlatency | 3.2.0-36.36 | precise-security/universe | source
<apw> linux-lowlatency | 3.2.0-36.36 | precise-updates/universe | source
<zequence> One ends with 26, and the other with 36
<zequence> But, that's ok?
<apw> zequence, no that is right.  the last number is the upload number for the package
<apw> so there has been 10 more uploads of the kernel than meta, which happens as you only
<bjf> jjohansen, bug 1106992
<apw> bump meta when there is an abi bump
<ubot2> Launchpad bug 1106992 in linux (Ubuntu) "tomoyo version mismatch, kernel panic" [Medium,Confirmed] https://launchpad.net/bugs/1106992
<zequence> apw: So, I can go ahead and test them now?
<apw> i am unsure if they ahve been copied out of the PPA as yet, do not appear to be yet
<jjohansen> bjf: okay I'll bug tetsuo and see what he says we should do
<zequence> Ah, a bit later than..
<bjf> jjohansen, thanks
<apw> zequence, ahh they were copied out 18 minutes ago, so the -23 and -37 versions are ready to go yes
<zequence> apw: Alright
<smb> :q
<chiluk> Hey everyone sorry for the improperly formated SRU mail on kernel-team .  Live and learn.
<chiluk> if it's still wrong feel free to let me know.
<bjf> chiluk, np
<bjf> chiluk, still wrong
<chiluk> nuts.
<bjf> chiluk, :-P
<chiluk> what should I have done differently?
<chiluk> I was trying to follow https://wiki.ubuntu.com/KernelTeam/KernelUpdates
<chiluk> perhaps the wiki page needs to be more pedantic ?
<bjf> chiluk, how long have you been following the mailing list?
<chiluk> not long enough... only a few weeks.
<bjf> chiluk, i'd point you at one if you've been there a while
<bjf> chiluk, do you have the brcmsmac patch from seth in your history? if so look at the patch 0/1 patch 1/1 mail for comparison
<chiluk> I do. reading..
<bjf> chiluk, so basically, the SRU text is correct, the patch shouldn't come in as an attachment
<chiluk> ok.
<chiluk> bjf, so what's the special sauce, that formats the patches and sends the e-mail?
<chiluk> git-send-email I'm assuming?
<bjf> chiluk, that's what i use though i have a script which has all the command line options that i want
<bjf> git send-email --no-chain-reply-to --thread --suppress-cc all --from "Brad Figg <brad.figg@canonical.com>" --to kernel-team@lists.ubuntu.com $1
<bjf> chiluk, ^
<chiluk> thanks bjf.
<bjf> chiluk, np
<infinity> bjf: And now he's going to send a patch to the list from you. ;)
<chiluk> give me at least a little credit.
<bjf> infinity, it's how i get credit
<bjf> dang
<infinity> chiluk: Where's the fun in that?
<chiluk> do you guys want me to send yet another e-mail? or do you want me to just do it right the next time around?
<chiluk> bjf infinity ^ ?
<bjf> chiluk, you can make the call. if you want to try git-send-email, that's cool otherwise we'll deal with it as it is
<chiluk> alright, I'll probably be sending out another SRU either later today or tomorrow.
<chiluk> so I'll git-send-email on that one.
<bjf> chiluk, https://wiki.ubuntu.com/Kernel/Dev/StablePatchFormat
<bjf> chiluk, also not that the patch needs to have the "BugLink: " line in it
<chiluk> I'll make that piece a bit more obvious in the wiki.
<bjf> chiluk, on the wiki page i referenced it is #1 in the comment body section
<bjf> chiluk, also, there is a python tool we have that is very usefull for adding all this "stuff"
<chiluk> linkage 
<chiluk> ?
<bjf> was getting there :-)
<bjf> chiluk, git clone kernel.ubuntu.com:/ubuntu/kteam-tools
<chiluk> and what's the wiki page you referenced above?  I only see one reference to buglink on the kernelUpdates page.
<bjf> chiluk,  kteam-tools/stable/bug-mod
<bjf> chiluk, https://wiki.ubuntu.com/Kernel/Dev/StablePatchFormat
<chiluk> hmm looks like the sru page might be better served by pointing to your link
<bjf> chiluk, probably, feel free to do so
<chiluk> will do.
<bjf> chiluk, the wiki is "kind of" a mess
<chiluk> that's what the new guys are for right?
<bjf> to make it messier? yup :-P
<chiluk> lol
<brennan> hello room
<brennan> how do you upgrade the dist?
<brennan> ????????????????????
<ppisati> sudo apt-get update && sudo apt-get dist-upgrade?
<ppisati> brennan: &
<ppisati> ^
<brennan> thanks man
 * ppisati -> EOD
#ubuntu-kernel 2013-01-29
<ppisati> moin
<smb> again... :-P
<smb> apw, one way fail
<smb> apw, meaning we hear you but not other way round :)
<apw> smb, situation normal, thank you pulse
<smb> As normal as any situation involving PA can be
<caribou> smb: morning
<caribou> smb: have you tried to use crash 6.1.0 on a Raring kernel ?
<caribou> smb: I get "(no debugging symbols found)" on the 3.8.0.2 ddebs
<smb> caribou, morning. maybe not. I honestly cannot remember...
<caribou> smb: ok, just wanted to check; I'll investigate
<smb> Though potentially I did with 3.7 based kernels. 
<smb> caribou, I would try to see how the last 3.7 we had works
<caribou> smb: well, the ddebs are not available for 3.7 kernels in the archive
<smb> caribou, Doh! Seems we would rely on whatever copy you or arges have. Since we cannot keep ours from vanishing.
<caribou> smb: I'll check what I have
<smb> Or re-build a kernel from git based on a tag
<diwic> If we have bugs in 12.04 that are fixed by using the -lts-quantal kernel, would it be appropriate just to advice people to move to that kernel or should one spend time trying to backport fixes to 3.2?
<infinity> diwic: Depends on the bug.
<infinity> diwic: If it's flat-out hardware enablement, asking them to switch to our HWE stack is reasonable.  If it's rather something broken in 3.2, finding the commit that fixes it and pulling it into 3.2 is the right thing, IMO.
<infinity> diwic: Keep in mind, also, that we don't have lts-backport on !x86.  So, if it's a bug that's not specific to some x86 hardware, not fixing it in 3.2 doesn't help, say, ARM users.
<infinity> That was a lot of negatives.
<diwic> infinity, hmm, ok
<caribou> smb: ok, I found the ddebs, I just no longer have the original 3.7 kernel package
<smb> caribou, Those should be on LP
<caribou> smb: I have the 3.7.0.4 ddeb
<caribou> smb: ok, got it
<smb> caribou, https://launchpad.net/ubuntu/raring/+source/linux/3.7.0-7.15
<caribou> smb: ok, got everything I need, I'll let you know what I find
<smb> caribou, cool. thanks
<apw> ogra_, about ?  i have a kernel i'd like you to test if you have a chance
<ogra_> now i am (i got a sick cat and need to spend 1-2h at the vet every day this week)
<ogra_> apw, ^^
<apw> ogra_, what fun
<ogra_> yeah
<janimo> apw, ogra_  said he'll land the userspace the orientation changes as soon as the kernel input side is changed for the nexus
<apw> ogra_, ok ... so ...
<janimo> I am fine with either chicken or egg first though, but users will need to be fully upgraded to have it working
<apw> ogra_, ok ... once you have tested that one, i'll spin you another with janimos orientation change
<apw> ogra_, so you can test your orientation fixes :)
<apw> and when you are happy we can upload together
<ogra_> given that the arm livefs builder is dead since days, i dont think we need to worry to much about ahlf a day delay between the uploads
<ogra_> ok
<ogra_> apw, perfect !
<ogra_> i wonder why i still saw the wifi messages in my build
<apw> ogra_, ok good.  i'll get your new one built in a minute
<ogra_> totally silent with yours
<ogra_> janimo, do you have the acceld changes handy ?
<janimo> ogra_, yes, I'll paste them again, a moment
<apw> ogra_, and note that the login screen doesn't have rotate
<janimo> ogra_, http://paste.ubuntu.com/1585333/
<apw> og
<apw> ogra_, that fixes things once you are logged in, but at the password prompt ?
<ogra_> apw, it will, as soon as i dropped the forced rotate from xorg.conf ;)
<janimo> I think we have an xrotate call somewhere there, which needs to be dropped
<apw> heh great
<ogra_> janimo, line 6 is wrong :P
<janimo> which is line 6? I think I only shuffled the matrix orders
<janimo> ah, DIR='right'
<janimo> is that the default orientation? Indeed that right is wrong
<ogra_> right 
<ogra_> *grin*
<janimo> that's why first tilt did not work I guess :)
<ogra_> doesnt od any harm, but you need to rotate once to actually activate the rotation if thats wrong
<ogra_> right, its one more tilt you need... i had the same issue in my foirst upload
<ogra_> grrr
<ogra_> i cant get the xorg.conf right :/
<apw> ogra_, seemed to work for me
<ogra_> great, uploaded the changes
<ppisati> has it ever happened to you that, during a bisect with, with  commit X being good, and commit X +  Y being bad
<ppisati> git bisect goes _behind_ commit X instead of picking one in between X and X+Y?
<einonm> ppisati:  could be due to branching between X & Y?
<rtg> ppisati, yeah, make sure its a linear range
<apw> ogra_, ok all of those changes are in the -release pocket now
<ogra_> yay
 * ogasawara back in 20
<tseliot> apw: what's the source package for linux-image-3.1.10-9-nexus7 ?
<apw> linux-nexus7
<apw> tseliot, ^^
<tseliot> apw: ok, thanks
<apw> tseliot, need something ?
<tseliot> apw: no, I just needed to know the name as I'm adding kernel names in my test suite for ubuntu-drivers-common so that I can tests for problems with my code and these name schemes
<ogra_> tseliot, there is also linux-ac100 (tegra2)
<tseliot> apw, ogra_: ok and do you know if linux-ti-omap4 has linux-headers-ti-omap4 etc.? (With this name scheme)?
<ogra_> it should, yes
<apw> it should be linux-headers-omap4
<apw> and linux-image-omap4
<ogra_> oh, right, the -ti is only in the source 
<apw> ti-omap4 is the source package name
<apw> -omap4 is the flavour name
<tseliot> ok, thanks
<smb> arges, Out of interest, is the xen package again flagged broken in raring +1? Right now it won't compile in my sbuild chroots (even the version you uploaded). And as a second thing, can I prevent others from fixing it while I look? ;)
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting today @ 17:00 UTC
<jsalisbury> ##
<zequence> apw: Am I expected to set the bug reports for regression-testing and/or Verification-testing to "fix released"?
<arges> rtg: was the bug you were seeing, you could suspend with pm-suspend, but there was no way to do it via the menu, or Fn-F7 (on mythinkpad)
<apw> infinity, i forget already what lowlatency testing was ... can you remind
<apw> ie when we do the regression testing what we are meant to set to what
<rtg> arges, I was just closing the lid. haven't really explored much further, but am uploading a bug report
<arges> rtg: ok. i might be hitting the same thing
<infinity> apw: If no lowlatency-specific bugs, mark verification-testing Fix Released if the parent kernel is done.
<infinity> apw: If specific bugs, verify, then do above.
<infinity> apw: For smoke testing, mark regressing-testing Fix Released, and tag the bug "qa-testing-passed" to appease the bot.
<apw> zequence, ^^ :)
<infinity> arges: If pm-suspend works, but various buttons and UI triggers don't, gnome-settings-daemon is probably wedged.
<arges> hmm
<zequence> apw: Thanks. I'll ask infinity some more, if I didn't get it yet :)
<apw> zequence, so this has no specific patches for lowlatency it is a pure rebase
<apw> zequence, so that means vefication-testing is not needed, so it can go Fix Released for no actions
<rtg> infinity, pm-suspends works even after upowerd augers in
<zequence> apw: Ok. Good
<zequence> apw: But, I still add the tag?
<zequence> Do I add it in a comment?
<infinity> rtg: pm-suspend should always work, barring kernel bugs or massive userspace sadness.
<infinity> rtg: But most of the higher level plumbing for this relies on gnome-settings-daemon being alive and willing to talk pleasantly to you.
<rtg> infinity, right, 'cause I think about all it does these days is blat something into sysfs
<infinity> rtg: Which doesn't sound like your sort of date.
<apw> zequence, the otehr testing one once they are boot tested, mark regression-testing fix-released and add a tag in the tags field at the top as above
<zequence> apw: So, this should be right then
<zequence> https://bugs.launchpad.net/kernel-sru-workflow/regression-testing/+bug/1105146
<ubot2> Ubuntu bug 1105146 in Kernel SRU Workflow verification-testing "linux-lowlatency: 3.5.0-23.22 -proposed tracker" [Undecided,In progress]
<apw> zequence, well verification-testing is done as there is none,
 * herton -> back in 1.5h
<caribou> smb: FYI, the debug symbols were fine in he 3.7 kernel in Raring
<smb> caribou, Ok. Thanks. Sounds like yet another thing moved around
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues February 5th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<apw> rtg, could you add me and cjw to the bug please, so we can see it
<rtg> apw, ack
<rtg> apw, done
<jsalisbury> rtg, is there a public bug?  Just wondering in case we get a bunch of duplicate reports.  Else, I can see if I can reproduce it and create a public report.
<rtg> jsalisbury, it'll be public as soon as the apport retracer runs
<jsalisbury> rtg, ack
 * ppisati goes out to find some food, before the food finds me
<smb> apw, arges, So the xen build fail was actually two parts. One (for which I found reference on xen-devel) is that the check for needing librt was using clock_gettime but that is not requiring it anymore. The other (for which I could not yet be bothered to search) is some part using ulong wihtout including sys/types.h (which probably something else used to do).
<smb> arges, I will include that in the stuff I am working on, so you won't have to worry about that ftbs :)
<arges> smb: ok great! let me know if there is anything i can do to help
<smb> arges, Just the usual grinding work for youknowwhat issues for the youknowho team... ;-P
<arges> : )
 * rtg -> lunch
<apw> rtg, bjf, there will be a new upowerd in the archive 'immently' which should fix things up
<bjf> apw, ack, i see there have been quite a few bugs filed against it
<apw> bjf, well it at least fixes my 32bit systems
 * smb -> donefortheday
<apw> smb, done in by the day
<smb> apw, Or so I guess :)
<zequence> Ah, I can be really slow sometimes
<zequence> Anyway, I think I got the bug handling for next time
<apw> rtg, you pushed just before me dammit, but you forgot the acks for the second one
<rtg> hmm, I thought I got both.
<apw> rtg, and both are missing the bug numbers
<rtg> apw, drat. why don't you push yours then since I'm clearly incompetent right now :)
<rtg> I didn't tag yet
<apw> :) ack
<apw> rtg, yeah i'll wrapit and upload it
<rtg> apw, ok
<rtg> apw, I'm about done for the day anyways
<apw> rtg np
 * rtg is outta here. back on Feb 5.
<infinity> smb: If the only reason it links librt is for clock_gettime, it doesn't need librt.
<infinity> smb: (Though, --as-needed linking will sort that out anyway)
<arges> computer suspends properly again! thanks
<infinity> jjohansen: You have a few pending security-signoff tasks for the current SRU round still, FYI.
<jjohansen> infinity: yep thanks for the poke, I'll get them done
<infinity> jjohansen: All good.  I'm sure you'll get them done before cert finishes. :)
#ubuntu-kernel 2013-01-30
<chiluk> anyone know if there is some sort of metering on the kernel-team list?  I used git send-email to send a patch request about 30 minutes ago, and it still hasn't shown up.
<chiluk> oh well, if it's not there by the morning I guess I'll resend.
<chiluk> night all
<ppisati> smb: moin
<smb> ppisati, morning
<smb> infinity, No, it actually uses other timer related functions which need librt. The configure script test was just wrong.
 * smb reboots 
<apw> chiluk, it is moderated if you are not a member, so if you use the wrong email addy ...
<apw> smb, ppisati, moin
<smb> apw, morning
 * apw flags already
<ppisati> apw: moin
<apw> ppisati, i am going to look at your arm -arm branch today, it needs some serious reading
<ppisati> apw: ack
<ppisati> apw: since i'll pull more patches in the future, another option is that we spin an arm-multiplatform topic branch
<ppisati> apw: that will predate the omap4 branch
<ppisati> apw: so i'll have more freedom to pull in patches from upstream and vendors
<ppisati> apw: without hurting master (and the stable team)
<apw> ppisati, it is quite close right now, it would be a shame to miss the chance to have them in one, but i can see your desire too
<ppisati> apw: yep, just wait until bjf complains :)
<apw> ppisati, i assume versatile and the like will always be 'no delta'
<apw> ppisati, so we could probabally have a -generic for arm with whatever is close, and then if something gets too big we could split that off
<ppisati> apw: yes, versatile is 100% upstream
<apw> ppisati, anyhow either way the branch contains the same stuff :)
<apw> so the review and test side is not about the destination
<apw> ppisati, i suspect we will try it as part of master for the experience and make a judgement nearer release if we want to pull some or all out
<ppisati> apw: i agree
<apw> and indeed leann has pulled it in already :)  now to re-review it
<psivaa> apw: Would like to know if there is any update/feedback on bug 1100386 pls
<ubot2> Launchpad bug 1100386 in linux (Ubuntu) "Raring server installations on VMs fail to reboot after the installations" [High,Confirmed] https://launchpad.net/bugs/1100386
<apw> psivaa, hmmm, no, i think we know what to do about that iirc, what did i decide i needed
<smb> apw, I think that was the cirrus vs. efi fb issue
<apw> smb, yeah.  and i think i had a change for that, somewhere, dammit
<psivaa> apw: smb: ok thanks, it would also help if you could comment on/assign the bug please
<ppisati> brb
<apw> psivaa, done
<apw> ogasawara, i am reviewing the ppisati pull you applied
<psivaa> apw: thank you
<ogra_> is the handling of DTB in our packages documented somewhere ? i get asked frequently about how we handle that by arm people that rol their own kernel packages
<tjaalton> I have a fresh quantal installation, ran dist-upgrade on it and it didn't pull the latest headers, although linux-headers-generic got updated
<tjaalton> now 'apt-get --fix-policy install' would fix the situation, but how is it possible to get in this situation? I enabled fglrx for testing stuff and things were "broken" :)
<tjaalton> -situation
<tjaalton> maybe not the right channel to ask
<ogra_> tjaalton, well, do you have the metapackage installed ?
<ogra_> linux-generic ?
<tjaalton> ogra_: no
<ogra_> why ?
<tjaalton> but linux-headers-generic, which depends on 
<tjaalton> ..the headers package
<tjaalton> it's a fresh install, it doesn't seem to pull it
<ogra_> its a requirement 
<tjaalton> how so?
<tjaalton> l-h-g did get updated, but it didn't pull the dependency
<ogra_> linux-$flavour is what gets installed during the build process
<ogra_> and this pulls in everything else (including the headers)
 * henrix -> lunch
<ogra_> its very weird if you dont have it after a fresh install, thats definitely a bug 
<tjaalton> it's a tree of metapackages, l-h-g is installed and that alone should've pulled the real one
<ogra_> well, linux-$flavour missing wil break on dist-upgrades at some point, it has to be there
<tjaalton> --fix-policy suggests a bunch of other packages too, like ecryptfs-utils etc
<tjaalton> it just depends on l-i-$f, l-h-$f
<ogra_> well, i dont get how you got into that situation at all 
<tjaalton> me neither :)
<ogra_> linux-$flavour cant tecnically be missing on a fresh install unless you forcefully remove it
<tjaalton> dpkg.log doesn't show it being removed
<ogra_> you should talk to the guys fiddling with the UEFI stuff, i bet it is related to changes there, but technically if linux-$flavour is missing you have a bigger prob
<tjaalton> I'll ask on -release
<ogra_> ++
<apw> tjaalton, i am interested
<apw> tjaalton, could you paste which packages you do have installed
<apw> oh i might have an idea, what is causeing it
<apw> tjaalton, so i need the list of headers packages and versions you have so i can check
<tjaalton> apw: http://paste.ubuntu.com/1589593/
<tjaalton> one thing that might cause issues is that I did change it to use my local mirror before the dist-upgrade, and it doesn't have i386 mirrored
<apw> so waht do you think is missing
<tjaalton> nothing anymore :)
<tjaalton> I can reinstall it to check again
<tjaalton> actually, l-h-3.5.0-17-generic isn't installed
<tjaalton> which should be there from the installation? dpkg.log shows it
<apw> yeah i would have expected it to be, but i don't think i can be to blame for removing it
<apw> oh and i bet it is too old
<apw> so it doesn't have the Suggests: from linux-image which would normally
<apw> stop it being deinstalled (in later kernels in that series and in raring0
<apw> so that is a known 'corner case' where apt-get autoremove can zap some of your headers
<apw> but it should be older headers not newer ones
<tjaalton> ah
<apw> and you should have gotten the new one installed without effort
<tjaalton> funny that dpkg.log doesn't show the removals
<apw> and that if not working is worrying
<brendand> henrix, ping
<henrix> brendand: hey!
<brendand> henrix, i was thinking, it would be useful if we could get an email when our task in the tracking bugs goes to Confirmed. is it possible to implement that in your scripts?
<brendand> henrix, it's just bug mail so easily gets lost
<henrix> brendand: right, this would require changing the bot, which is maintained mainly by herton.
<herton> brendand, let me know which email you want a notification sent and I'll add
<henrix> brendand: i use mailfilters myself ;)
<brendand> henrix, sure - but getting a whole team all set up with the proper mail filters...
<henrix> :)
<apw> ppisati, this -omap merge, if i build that does it work on omap4 as well ?
<ppisati> apw: yes
 * apw will test that
<ppisati> apw: audio, video, usb, srial, etcetc
<apw> ppisati, great
<ppisati> apw: beware that you'll have to use the hdmi output close to the edge of the board, they swapped it in 3.5
<apw> ppisati, thanks for the warning, piece of junk
<apw> sforshee, i am assiging you the cnd delta review, cause they sound like your kind of patches and you acked at least one :)  could you have a look and try and figure out if they still make sense
<sforshee> apw, ack
<apw> sforshee, on https://blueprints.launchpad.net/ubuntu/+spec/hardware-r-kernel-delta-review
<sabari> Hi 
<sabari> I am running Ubuntu 12.04 and when I run Oprofile to understand the CPU Utilization, I found that more time is spent on mem_cgroup_uncharge_common
<sabari> can some one explain what this is?
<sabari> We want our processes to be run effectively and more than 50% of the cpu is currently used by the system
<sabari> I also see free_pcppages_bulk as well 
<ohsix> when the system is mostly sleeping, the apparent cpu usage of the things it's doing between sleeps will be higher
<sabari> Ohsix is this for me?
<ohsix> yes
<sabari> I did profile the process which said that it is using 100% CPU
<bjf> brendand, can't your email client filter for those specific bug emails and flag them for you? 
<bjf> brendand, i'm not wild about special casing bot code for individuals
<brendand> bjf, ok - i'll see what i can do to avoid it
 * ogasawara back in 20
<qengho> ppetraki: Hi hi.  I'm trying to boot a Pandaboard with a raring desktop image.  ogra_ suggested I talk to you about today's image on cdimage not starting or kernel hanging or something.
<qengho> Er, ppisati, sorry, I meant you.  ^
<ogra_> ppisati, could anything regarding the changes you work on be at fault here (do we need to switch the builds to new kernels or so)
<ppisati> qengho: nope, since the R kernel is a Q kernel
<ppisati> qengho: do you have serial output?
<qengho> ppisati: Er, no.  I haven't even seen a DB9 cable this decade.  :(
<ppisati> qengho: did you first try a Q image on that board? did it work?
<ppisati> qengho: anyhow, modify uEnv.txt and delete "quiet splash", if you are lucky you should get some output on the lcd
<ppisati> qengho: or was it preEnv.txt? don't remember, check both
<ogra_> the latter
<qengho> ppisati: Er, okay.  I don't get any HDMI output at all, even a sync signal, at present.  FWIW.
<ogra_> ppisati, the heartbeat LED gets stuck
<ogra_> that sounds like its even before initrd
<ogra_> could be the bootloader indeed, hard to say without info from serial 
<qengho> I'll try to find a Q image.  Pointers accepted.
<ogra_> but afaik the bootloader hasnt changed since precise or so
<ppisati> qengho: don't you get a purple screen?
<ppisati> qengho: http://releases.ubuntu.com/quantal/ubuntu-12.10-desktop-armhf+omap4.img
<ppetraki> qengho, it happens a lot :)
<cnd> sforshee: apw: I can help review the patch delta
<cnd> is there a list of the patches somewhere?
<sforshee> cnd, https://wiki.ubuntu.com/KernelTeam/Specs/RaringKernelDeltaReview
<sforshee> cnd, I'd appreciate the help. It looks like a couple of patches that stalled when you tried to upstream them.
<cnd> sure, let me take a look
<sforshee> herton, there's a patch that's been posted for stable that improves wireless performance during background scans. I don't think there's been a backport to 3.5, but the patch for 3.4 applies cleanly.
<sforshee> herton, http://www.mail-archive.com/stable@vger.kernel.org/msg30134.html
<herton> sforshee, ack, will look into queuing it
<sforshee> herton, thanks. It really does help a lot. I had posted an equivalent patch before finding out about that one.
<cnd> sforshee: so those two synaptics patches are meant to make the 3 or 4 year old dell mini netbooks with a two-button clickpad work properly
<cnd> superm1 told me those types of trackpads will never be made again, because they were terrible
<sforshee> heh
<cnd> and yeah, it looks like it stalled due to people not following up upstream
<cnd> I have one of these netbooks, and I'd rather say at this point it's practically so slow as to be unusable
<cnd> and I have the newer model :)
<cnd> so I guess at this point we can decide to keep the patches to keep the machines humming along alright
<cnd> but either now or later we might as well drop the patches
<cnd> the patches merely set an informational property bit
<cnd> and users can still manually enable clickpad mode in the X synaptics drivers
<sforshee> hmm... they're easy enough to keep around I guess
<sforshee> it doesn't sound like there's much use in trying to further pursue it upstream though
<sforshee> cnd, thanks for the help. I guess I'll recommend hanging onto them as long as they keep applying cleanly.
<cnd> k
<sforshee> maybe some people are still trying to run ubuntu on those machines, who knows
<cnd> you never know
 * ppisati rushes out, be back later
<sforshee> apw, I updated the raring delta review suggesting that we keep cnd's patches as long as they aren't causing any problems and mark them no-up. Anything else I need to do to follow up?
<ogasawara> sforshee: thanks for that, I'll go ahead and mark em no-up.  that should take care of the review, go ahead and mark that as done.
<sforshee> ogasawara, ack
<apw> sforshee, hey ... fancy checking another patch for me, it seems we have "input: fix weird issue of synaptics psmouse sync lost after resume" which needs looking at as well
<apw> that would close out another wi
<ogasawara> jdstrand: thanks for the wi tip
<jdstrand> heh, sure
<jdstrand> I was surprised how fast the response hit my inbox and now even more surpised how fast you read it :)
<antarus> arges: Curious what the status is on https://bugs.launchpad.net/ubuntu/+source/unity/+bug/806248 and if there is anything I can do to move it along?
<ubot2> Ubuntu bug 806248 in unity (Ubuntu Precise) "unity::TimeUtil::TimeDelta returns an int value which overflows after 24 days of uptime" [High,In progress]
<antarus> (SRU for P)
<arges> antarus: hi
<arges> antarus: i'm waiting on somebody to upload it
<arges> antarus: so we just need a sponsor
<antarus> ok
<antarus> but ubuntu-sponsors are not even CC'd?
<arges> hmm thought i added that
<antarus> you probably did but there was some schenanigans with the debdiff
<antarus> peopel seem to hate on them lately
<antarus> which sucks because bzr is awful ;p
<arges> yea, i usually am submitting kernel patches or debdiffs. so trying to learn the bzr workflow too
<antarus> I'll see if I can bribe spamaps to upload it
<antarus> he seems to be wednesday's sponsor de jure
<arges> antarus: awesome thanks
#ubuntu-kernel 2013-01-31
<smb> morning
<ppisati> smb: hey
<ppisati> brb
<maswan> Hey, any reason for not building the kernels with CONFIG_NFS_V4_1? Even RHEL has it these days, and it is fairly annoying to have to maintain custom kernels just to be able to mount our storage...
 * ppisati -> out for lunch
<jpds> maswan: Someone likely just needs to add it, Debian got it recently: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=+627655
<maswan> Hope someone<tm> does it soon then. :)
<henrix> maswan: i'm not aware of any reason not to include this option, but if you want it included, the best way is to open a bug with this request
<maswan> will do
<apw> henrix, isn't it on in raring already?
<maswan> would be most excellent if it could make it's way to a precise update too.
<maswan> or is that too invasive?
<apw> debian.master/config/config.common.ubuntu:CONFIG_NFS_V4_1=y
<apw> so definatly already in raring
<maswan> excellent
<apw> it is not on in Q so I assume not before that either.  turning it on in older releases is harder, it would definatly need a bug, and lots of testing
<henrix> apw: yes, its in raring
<henrix> i checked in P and Q, and it is not there
<maswan> yeah, we know it isn't in P, since we have a bunch of P servers that would like it. :)
 * apw concurs
<henrix> maswan: could you please open a bug with this and paste here the bug #? i'll follow up with this
<maswan> henrix: Yeah, dusting off my launchpad:ese now. :)
<maswan> Hm. A possible option for us would also be an r-to-p kernel backport in the wait for a new lts, I guess, assuming it works.
<henrix> maswan: r on p is also possible, yes
<maswan> But if there is a major kernel update scheduled for P anyway, this is a change that I'd very much would like to be considered for it
<henrix> this change would be included in the regular SRU cycles, not really in a major kernel update
 * maswan nods
<maswan> henrix: 1111416
<henrix> maswan: ack, thanks. i'll make sure we'll have this option enabled soon
 * henrix -> lunch
<maswan> awesome!
<apw> bug #1111416
<ubot2> Launchpad bug 1111416 in linux (Ubuntu Quantal) "CONFIG_NFS_V4_1=y in Precise kernel update, please" [Undecided,New] https://launchpad.net/bugs/1111416
<apw> maswan, when you roll custom kernels is all you are changing from the main P kernel that option?  and if so and you have tested or even production run with that it would be good infrmation to have in the bug
<apw> it all helps to tell us it is stable and feature complete back there
<maswan> apw: We haven't yet, we're just deploying the new storage now. Will prod the guys in charge of that project to do that and test it proper.
<apw> maswan, or get henrix to post an 'official' test kernel with the changes he intends to apply 
<maswan> apw: that would be even better
<henrix> apw: maswan: will do that. i'll post a link in the bug to Q and P test kernels before submitting the patches
<maswan> henrix: excellent!
<apw> ppisati, i have been running your -omap kernel on omap4, and i think it just wedged
<apw> ppisati, seen anything like that?
<ppisati> apw: uhm no
<ppisati> apw: did it print anything?
<apw> ppisati, also i seem to have lost my heartbeat
<apw> ppisati, not anywhere i could see
<ppisati> apw: i compiled a kernel oevr usb and it was ok
<apw> ppisati, http://paste.ubuntu.com/1593378/
<henrix> maswan: i've just updated the bug with an URL to test kernels
<ppisati> apw: ok, i saw it in the past
<apw> ppisati, so did you say there was a bug open on this one ?
<apw> ppisati, i am probabally pretty rare in actually having ipv6 to trigger this
<maswan> henrix: thank you, we'll see if we can get some testing done tomorrow, or next week.
<apw> ppisati, if that is the actual cause of course
<apw> ppisati, anyhow i have also lost my heartbeat on that box, is that gone in 3.8
<henrix> maswan: sure, no prob. just update the bug with any info, as i'll keep an eye on it
<ppisati> apw: led? probably config skew
<apw> ppisati, yeah the flash-flash  flash-flash  related to load thing
<ppisati> apw: there's a but about a slowpath being hit, and the reporter said the board was both ipv4/6 connected
<apw> ppisati, now i have no lights when it is idle, which is 
<ppisati> apw: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/1030397
<ubot2> Ubuntu bug 1030397 in linux-ti-omap4 (Ubuntu) "slowpath in tcp_recvmsg on pandaboard es" [Medium,Incomplete]
<apw> not what i am used to
<ppisati> apw: ok, i'll turn heartbeat on
 * ppisati has used more the imx6 lately
<ppisati> that's why i probably didn't notice it
<apw> ppisati, that bug looks different to me, here is a real BUG
<ppisati> apw: yes, it's different
<ppisati> apw: but i think i saw it
<ppisati> apw: apw and it didn't hangs my board
<apw> it is hard to know whether it was the last thing, as the log is truncated at that point
<ppisati> apw: ok
<ppisati> i'll push 2 patches for imx6, then i'll switch back to see this on omap4
<apw>  ppisati np thanks
<apw> ppisati, i'll monitor it for a bit to see if it does it again
<caribou_> ivoks: ping
<ivoks> caribou_: yes?
<caribou_> ivoks: any idea of what's happening with the SRU on https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/833368
<ubot2> Ubuntu bug 833368 in lvm2 (Ubuntu Precise) "clustered lvm commands fail with "activation/monitoring=0 is incompatible with clustered Volume Group" error" [Undecided,In progress]
<xnox> i am meant to upload it.
<xnox> but got carried away in the sprint this week.
<ivoks> caribou_: ^ i'm not the right person for the question :)
<xnox> caribou_: is it urgent?
<caribou_> xnox: ah, ok I just didn't see it in any of the SRU queues
 * ppisati goes away for 20mins
<apw> ppisati, elloco died again .. this time with the disk light on
<ppisati> apw: let me turn on my panda
<apw> ppisati, nothing in syslog this time, just wedged
<arges> anybody getting 'fail to flush all tx fifo queues' with 3.8.0-2 on their centrino intel w/ iwlwifi driver?
<henrix> arges: yeah, i've seen it as well. but it should be fixed with c3e5d7181afb66657393066bccce0956fab09ab3
<arges> henrix: ok so that's in the next raring kernel?
<henrix> (haven't tested it myself as i rarely use wifi)
<arges> 3.8.0-3?
<henrix> arges: i guess so, its mainlined
<henrix> arges: here's the lkml thread i recently saw: https://lkml.org/lkml/2013/1/28/603
<ogasawara> arges: I don't think we have it just yet in raring, but I'll cherry-pick it for now
<arges> ogasawara: or I can do it. either way : )
<ogasawara> arges: meh, easy enough for me.  I'll let you build your own kernel though.  we just missed the upload this morning.
<arges> ogasawara: ok
<henrix> arges: ogasawara: note that i haven't tested it myself -- i just saw this thread in lkml, which caught my attention because i hit the same issue during weekend
<henrix> (and completely forgot about it until arges remind me about it :-) )
<arges> well i can test 
<ogasawara> arges: so maybe let me know how your test goes first and then I'll cherry-pick it
<arges> ogasawara: ack
<arges> should i file a new bug to track this btw?
<ogasawara> arges: nah, since it's the dev release we can be a little more lenient with the process
<arges> ok great. baking a new kernel...
<ogasawara> arges: plus we'll eventually pick it up whenever -rc6 goes out and we rebase
<ppisati> apw: http://paste.ubuntu.com/1593699/
<ppisati> apw: bt it's still compiling
<apw> yeah mine did that a lot before it stopped dead
<ppisati> apw: i'll let it finish a kernel compilation, then i'll ifup an ipv6 interface
<ppisati> http://www.theregister.co.uk/2013/01/31/ubuntu_uefi_bricking_samsung_laptops/
<apw> ppisati, yep, we've been trying to get fixes for that out for months
<apw> ppisati, ultimatly it is terrible firmware which loses its mind
<apw> ppisati, how do the dtbs get supplied to the kernel for the omap3/4 use ?
<ppisati> apw: we don't use them in panda&c yet
<ppisati> apw: if you want to use it, you need to manually copy to the fat partition
<apw> ppisati, so how does the kernel know it is for omap3/4 and adapt without the dtb
<ppisati> apw: and then modifiy uEnv.txt to load it
<apw> i thought the point was it used the dtb to know what it was on
<infinity> ppisati: What Andy's asking isn't "how do I use a dtb on Panda", but "how does the kernel know it's booting on a Panda"?
<ppisati> apw: arm/arch/mach-omap/boards* file are still compiled in
<infinity> ppisati: And if the answer is "it's build to assume it's on OMAP", that could explain why we can't make it work on vexpress.
<apw> ppisati, yeah i have been trying to boot the same kenrel on vexpress and its not having it for me at least, dispite appearing to be enabled
<apw> ppisati, even supplying a dt
<apw> dtb to qemu ...
<ppisati> apw: let me try
<apw> ppisati, thanks
<ppisati> apw: ah, maybe i know what's going on
<ppisati> apw: i think they are attaching the DTB at the end of the kernel
<ppisati> apw: so you don't see they are passing it
<ppisati> apw: and of course we can't do it
<apw> so you mean i would need to add the dtb to vmlinux for it to work
<apw> vmlinuz even
<apw> even in qemu with -dtb support
<apw> ppisati, can i leave you to try and figure out if it can be done manually
<apw> ppisati, so we can later figure out what one has to do to make it work right
<ppisati> apw: yep
<apw> thanks
 * ppisati goes for some dinner
 * ogasawara lunch
<ricotz> jsalisbury, hi :). do made some progress on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1094722 ?
<ubot2> Ubuntu bug 1094722 in linux (Ubuntu) "Raring: regression: fan keeps spinning at full speed after suspend" [Medium,Confirmed]
 * ppisati -> EOD
#ubuntu-kernel 2013-02-01
<ppisati> moin
 * apw yawns
<RAOF> Bees! A steaming hot cup of bees!
<apw> RAOF, how do you like your women ?
<RAOF> Very much.
<apw> "covered in bees"
<RAOF> No, silly. The women are covered in honey!
<apw> and things which are covered in honey, are convered in what ?
<RAOF> honeybees!
 * apw hands RAOF a little medal
<apw> RAOF, hows it going?
<RAOF> Pretty well.
<RAOF> I'm in Perth, staying at the in-law's, so there's a bit of extra babysitting available. :)
<apw> oh very nice :)
<RAOF> How about you?
<apw> yeah good i think, if i could wake up it might stop being, but in my current state ok thanks
<ashwini> can we use setjmp and longjmp in kernel mode ?? or any equivalent method ? kernel version 3.6*
<ohsix> for what? there are a bunch of mechanisms for jobs and threads
<ohsix> if you can be specific abotu what you're trying to do i might be able to point out an alternative
<ogra> The following NEW packages will be installed:
<ogra>   linux-headers-3.5.0-218 linux-headers-3.5.0-218-omap4
<ogra> apw, ^^^  what'S that ? (dist-upgrading my nexus7)
<apw> ogra, hmmm just doing it now ?
<ogra> well, i do my daily upgrade, so yes
 * apw tries
<apw> ogra, while i think about it suspend/resume is bringing usb0 back up on the nexus, and upsetting NM on my desktop
<ogra> apw, yep, NM will get fixed to ignore usb0 
<ogra> at least for certain usb id's
<ogra> so you can still set up usbnet manually by selecting the device from the indicator, but it wont attemopt autoconnection
<apw> hmmm, i thought you were fixing that n7 side
<apw> by not running the interface there unless you were using it
<ogra> well, i was abouot to, but was told NM would be fixed
<apw> that seems backwards, but i guess its not my problem
<ogra> it does that for other usb connections too so it makes sense to have some filtering apparently
<apw>   libdatrie1 liblightdm-gobject-1-0 libthai-data libthai0 lightdm
<apw>   linux-headers-3.1.10-9 linux-headers-3.1.10-9-nexus7
<apw>   linux-image-3.1.10-9-nexus7 linux-libc-dev python-imaging
<apw>   ubuntu-defaults-nexus7 ubuntu-settings unity-greeter
<apw> ok didn't do that for me
<ashwini> ohsix: what are the alternatives ?
<apw> ogra, you didn't install the omap binary on there did you ?
<ogra> i dont see ubuntu-drivers-common
<ogra> i assume thats at fault
<ohsix> ashwini: i don't know what you're trying to do
<ogra> apw, nothing special installed that could pull it in, check if you didnt already have it installed, i'm probably not in sync with your upgrading
 * apw notes that pretty much all use of setgjmp longjmp is wrong, in principle
<ohsix> and even the marginal uses won't hold in the kernel :p
<apw> ogra, i got a nice shiney new kernel and no omap stuff, odd
<ogra> weird
<ogra> i'll dig on then
<ogra> hmm, so purging linux-headers-3.5.0-218-omap4 leaves me with ....
<ogra> The following package was automatically installed and is no longer required:
<ogra>   linux-headers-3.5.0-218
 * ogra scratches head
<apw> that makes sense i at least, that would be a dep of the other
<apw> ogasawara, i have pushed a rebase to v3.8-rc6, booted and running here on 32 and 64 bit x86
<ogra> well, but it indicates that there was no dep that pulled in linux-headers-3.5.0-218
<ogra> thats the strange part here
<apw> linux-headers-3.5.0-218-omap4 was the dep, you purged it
<ogra> linux-headers-3.5.0-218-omap4 was not depended on by anything but its own meta though
<apw> oh indeed,
<ppisati> apw: did you check out the versatile support?
<apw> ppisati, sorry i have lost some history, did you send me something to test?
<apw> ppisati, otherwise, i tried hard to boot your kernel using qemu and options which seemed to be vexpress (not versatile)
<apw> ppisati, and note it is vexpress
<apw> ppisati, and i have failed to get it to do anything visible
<apw> (your kernel == the one in the archive)
<ppisati> apw: i sent a pull req yesterday about vexpress suport
<ppisati> apw: vexpress = "ARM Ltd. Versatile Express family"
<ppisati> apw: "enable ARM Versatile Express support"
<ppisati> apw: To: kernel-team@lists.ubuntu.com 
<ppisati> apw: here is a precompiled version of kernel, initrd and rootfs with vexpress support: http://people.canonical.com/~ppisati/vexpress/
<apw> ppisati, thanks ... i completely phased on that
<ppisati> apw: in the email there's the qemu command to boot it
<apw> ppisati, will get into it and get it applied thanks
<ppisati> apw: ack
<apw> ppisati, in all cases you are just enabling the specified option on the subject line for the omap flavour... yes ?
<ppisati> apw: yep
<apw> ppisati, great, i have rebased and the configs are different enough to break them, but they are easy to recreate
<ppisati> apw: ah yes
<ppisati> apw: i forgot, master-next requires an updateconfig before applying my patches
<apw> ahh ok
<apw> ppisati, oh excellent, now they work :)
<apw> ppisati, i was pushing the updateconfigs anyhow :)
<ppisati> apw: you can test it with my rootfs, but beware that the NIC drievr is a module
<ppisati> apw: so you need to install the kernel .deb in the rootfs to get networking
<ppisati> apw: ah, and my rootfs is linaro :P
<ashwini> any pointer for setjmp_pre_handler ?? How to use or any type of documentation ??
 * henrix -> lunch
<apw> ogasawara, i have applied ppisati's versatile stuff and am testing it now
 * ppisati -> goes to find some food
<ogasawara> apw: ack, thanks.  I think I'll prep another upload for today then.
<apw> ogasawara, i'll let you know when its 'good'
<apw> ogasawara, the rc6 testing went well on x86
<ogasawara> apw: good, I'm gonna test it all on my kit here as well
<arges> ogasawara: fyi. wireless patch c3e5d718 on my raring laptop has fix issues so far. is this included in rc6?
<ogasawara> arges: it should be, but let me double check
<apw> v3.8-rc6~20^2~10^2^2~7^2
<apw> arges, looks to be yes
<arges> thanks, i should be less lazy : ) 
<apw> yes, you should :)
<apw> ppisati, ack
<apw> if i can get a console i will be amazed
<ppisati> apw: you should have a console
<apw> ppisati, my panda(?) is hanging left right and centre with these kernels
<ppisati> apw: scheduling while atomic?
<apw> ppisati, no way to tell, it just hangs
<apw> though the scheduling whilst atomics in there may well be indicative
<ppisati> apw: i tested my patches on panda and it was ok
<apw> ppisati, and my board is hanging ... a lot ... but i use ipv6, a lot
<ppisati> apw: lemme try master-next tip
<apw> so perhaps there is a connection
<apw> or perhaps my board is dying, how the hell to tell
<apw> ppisati, i have no serial console output from my kernel
<ppisati> apw: that's weird
<apw> and maybe that would be telling me something, whats the runes to get that working
<apw> ppisati, no i think its config rather than anything else
<apw> i get uboot on there
<ppisati> ok so
<ppisati> flag@flag-desktop:/media$ cat preEnv.txt
<ppisati> bootargs=ro console=tty0 console=ttyO2,115200n8 debug earlyprintk=ttyO2,115200n8 root=UUID=be44da86-b040-478b-9ce9-4e99e29c2872
<ppisati> and media is my /dev/mmcblk0p1
<ppisati> you probably just need to add: "console=tty0 console=ttyO2,115200n8 debug earlyprintk=ttyO2,115200n8" and delete "quiet splash"
<apw> ppisati, ack
<apw> will have a look
<apw> so your versatile works a lot better than it did before
<apw> though on my image it implodes
<apw> [    5.086795] WARNING: at /home/apw/build/ubuntu-raring/ubuntu-raring/drivers/tty/serial/serial_core.c:400 uart_get_baud_rate+0xec/0x144()
<apw> [    5.098399] Division by zero in kernel.
<apw> but hey... its much better than it was
<ppisati> LOL :)
<apw> and that is with an image i got from debian so anything is possible
<apw> i'll get yours
<ppisati> but the img should mke any different
<ppisati> wait
<ppisati> QEMU emulator version 1.2.0 (Debian 1.2.0-2012.09-0ubuntu1)
<ppisati> your?
<ppisati> qemu-system-arm -version
<ppisati> *shouldn't
<apw> QEMU emulator version 1.3.0 (Debian 1.3.0+dfsg-1~exp3ubuntu6), Copyright (c) 2003-2008 Fabrice Bellard
<apw> ppisati, ^^
<ppisati> apw: that would explain it
<apw> it would?
<ppisati> apw: well, could be a bug on qemu
<apw> ppisati, i think its much more likely my fault to be hones
<apw> i'll confirm with your rootfs
<apw> if yours blows too then its qemu if not, i don't care ;)
<apw> well it is qemu or my -4 kernel build
<ppisati> flag@flag-desktop:~$ uname -a
<ppisati> Linux flag-desktop 3.8.0-4-omap #8~vexpressrc6 SMP Fri Feb 1 14:12:38 UTC 2013 armv7l armv7l armv7l GNU/Linux
<ppisati> apw: that's my pandaes booting current master-next tip
<apw> ppisati, mine boots too, but ... it doesn't stay working for more than 10s of minutes
<apw> ppisati, ok your image boots fine with my -4 kernel ..
<apw> so ogasawara that looks good in my testing
<ogasawara> apw: awesome.  I just want to finish up some quick testing on my kit here and then I'll push the upload
<apw> ogasawara, sounds great
<apw> QEMU emulator version 1.3.0 (Debian 1.3.0+dfsg-1~exp3ubuntu6), Copyright (c) 2003-2008 Fabrice Bellard
<apw> bah
<ppisati> apw: can you upload your img somewhere? i should try to roll my own ubuntu BTW
<apw> ppisati, its just the debian one
<apw> ppisati, i assume in theory if i dd off my panda with this -omap installed
<apw> ppisati, that would make a valid image
<ppisati> apw: yep, should be
<apw> ppisati, this debian image isn't worth worrying about, its an old armel one even
<apw> so ... we are better off making a new one off one of these pandas or someething
<apw> ppisati, the serial job isn't working on this board even though echo >/dev/ttyO2 works
<apw> ppisati, ever seen that?
<apw> ppisati, as in the getty is not throwing onto it
<ppisati> apw: do you have an /etc/init/ttyO2.conf?
<apw> ppisati, no i have a serial.conf which is meant to do the right thing
<apw> but i think it is broke ... debugging it now
 * ppisati still uses /etc/init/ttyO2.conf
<apw> ahh it doesn't work if you have console=tty0 console=SERIAL
<apw> stupid thing
<apw> fixed
<apw> ppisati, http://paste.ubuntu.com/1597104/ feels like the last thing it said before locking up
<apw> ppisati, and 100104 is like LIST_POISON or something isn't it?
<ppisati> yes
<apw> i'll let it do it again and see if it behaves the same
<apw> ppisati, even with these stability problems this is a good step
<ppisati> apw: i think it's ipv6 related because
<ppisati> apw: time DEB_BUILD_OPTIONS=parallel=4 fakeroot debian/rules binary-omap4
<ppisati> apw: and it's still compiling
<ppisati> (~1hr so far)
<apw> ppisati, could well be, i'll confirm it exists in this kerenl a couple more
<apw> and then move it to my ipv4 only lan
<ppisati> apw: truth be told, i got a "BUG: scheduling while atomic: cc1/19926/0x40000100"
<apw> elloco login: [  386.207427] BUG: scheduling while atomic: swapper/0/0/0x40000100
<apw> [  386.214782] BUG: scheduling while atomic: swapper/0/0/0x40000100
<apw> i have two, but they haven't eaten my lunch yet
<ppisati> my is still alive too
<ppisati> *mine
<ppisati> http://paste.ubuntu.com/1597185/
<apw> it seems a lot happier now it has a console ... hmm
<apw> we shall see
<apw> ogasawara, have you wrapped the kernel yet?  we might want seth's thing
<ogasawara> apw: heh, I was literally about to ping sforshee about that
<ogasawara> apw: I'd prepped the upload but failed to see his patch till after
<ogasawara> apw: I was going to redo it to include it
<apw> that is annoying when it happens
<ogasawara> apw: so I'm kicking off new builds
<sforshee> ogasawara, it's not critical, but it would be helpful for helping me debug a wireless issue that bjf has been seeing
<apw> if it it pushed, i can do the same and boot test them
<ogasawara> apw: I'm applying it right now and will push, gimme 2min
<sforshee> if it's too much of a hassle it can wait until next time
<ogasawara> sforshee: nah not much trouble, I'll squeeze it in
<apw> the more we have the less bad i feel about it being 36 hours after the last one
<ogasawara> indeed
<apw> ogasawara, i don't know if you followed along, but this -omap now supports omap3,4, some imx6 thing, and vexpress (for qemu) all out of the same bits
<apw> pretty good start me thinks
<ogasawara> apw: yep, I saw the chatter, it's sweet!
 * apw is going to make a qemu'able image from his omap board when this test is done
<ogasawara> apw: ok, pushed to master-next what I'm intending for the upload
<ogasawara> apw: I've not yet tagged or reset master
<ogasawara> apw: will do so after my builds and testing are good
<apw> yep
 * ogasawara back in 20
<ppisati>  /me -> EOW
<ppisati> meh
<ocdtech> What do these errors mean?  http://dpaste.com/903980/
<sforshee> ocdtech, it means there are some coding errors in the kernel you're trying to build
<ocdtech> sforshee: are the error in the code or the .config ?
<sforshee> ocdtech, the code
<ocdtech> my source is the 3.2.37 stable from kernel.org how would errors get introduced?  If run make -i will it complete?  I know the kernel may not run if it does.
<sforshee> ocdtech, you haven't modified the code at all? Applied any extra patches?
<sforshee> it's possible the errors only show up under certain configs, but it definitely looks like code errors to me
<ocdtech> sforshee: I applied only one patch from a known good tarball.  It was used on another machine in my office a few weeks ago.
<sforshee> ocdtech, to the same kernel version? If it was a different kernel version then it may contain changes incompatible with 3.2.37.
<ocdtech> sforshee: he was using 3.2.23 and the patch worked fine, but I can't find source for 3.2.23
<ocdtech> sforshee: think that's the problem?
<apw> ocdtech, well the simple test is to unapply the patch and see if it compiles without, if so then its the patch
<ocdtech> apw: I didn't know I could do that.  Off to google I go!
<apw> ocdtech, patch -R undoes patch
<ocdtech> apw: Trying it now
<ocdtech> apw: I get the same errors after patch is removed.  Would an environment variable cause these errors?
<apw> not likely
<apw> ocdtech, though i can also say that 3.2.37 built just fine in our mainline automated builds
<ocdtech> I've only been using linux for about 6-7 months.  This is my first kernel build so I was half expecting problems.
<sforshee> ocdtech, the errors are exactly the same?
<ocdtech> sforshee: yes
<sforshee> arch/x86/kernel/init_task.c:31:8: error: unknown field âdeadlineâ specified in initializer
<sforshee> ocdtech, I'm looking at 3.2.37 and there shouldn't be any attempts to initialize a field named deadline
<ocdtech> sforshee: is it refering to the I/O scheduler?
<sforshee> sforshee, this is initialization of the task_struct
<sforshee> gotta head out for a while, back in an hour or so
 * sforshee -> lunch
<ocdtech> sforshee: enjoy.
<ocdtech> what is the command for pulling the build .config out of the currently running kernel?
 * henrix -> EOD
<bjf> ocdtech, if you are running ubuntu you can find the config at /boot/config-$(uname -r)
<ocdtech> bjf: thanks
 * ogasawara lunch
 * llstarks dinner
#ubuntu-kernel 2013-02-02
<shieh> i got a PID of running process with C++ such as VirtualBox.how to know it has a thread?
<infinity> bjf: Can you commit http://paste.ubuntu.com/1600950/ to git so no one has a tizzy when I upload it? :P
<infinity> apw: ^-- Or you?
<apw> infinity, will do
<apw> bjf, infinity, done
<zombie05> yo
#ubuntu-kernel 2014-01-27
<vlad_starkov> I probably found a bug in some module. Can't boot Ubuntu Server on my machine. It raises CPU soft lockup errors all the time. The system even can't boot. 
<vlad_starkov> I tried to boot from grml USB flash, and it does almost all the same. But when I tried to boot grml with 'noudev' boot option, the grml has booted just fine and htop shows me all my 8 CPU cores with 0-2% load.
<vlad_starkov> What does 'noudev' boot option in my case?
<brendand> does anyone know about low-power states used in the phablet image? is there any sort of shifting of power states - say when the screen off button is pressed?
<BenC> apw: How goes the integration?
<apw> BenC, looking good according to the testing we have done, working on the 'final' version right now as it happens
<BenC> apw: Is it in git?
<apw> BenC, shortly ...
<BenC> I'd like to test out the ppc bits
<BenC> apw: I'm hoping no changes were made to the configs :)
<apw> i'll ping you when i've pushed it ... configs are identicle indeed
<BenC> Thanks for that
<vlad_starkov> Question: Given I can't boot Ubuntu Server 12.04. It always raises CPU soft lockup error. What would be the right strategy to find the buggy module and disable it?
<smb> The softlockup warnings should have a stack-trace that should hint what is waiting. That might indicate which area or even module is involved
<vlad_starkov> smb: so I have to wait while such information will appear on screen or should I apply some special 'verbose'-like boot option to get it?
<vlad_starkov> smb: the CPU lockups begins after 'Running /scripts/init-bottom ... done' and 'init: ureadahead main process (369) terminated with status 5'
<vlad_starkov> smb: then it continues with "BUG: soft lockup â CPU#0 stuck for 30s! [modprobe:476]"
<vlad_starkov> smb: then the same with "... [flush-8:0:557]"
<apw> BenC, on master-next let me know if it works ok :)
<BenC> apw: I'll test it tonight, thanks. 
<apw> BenC, great thanks
<vlad_starkov> BUG detected http://paste.ubuntu.com/6828163/
<smoser> [  588.212384] perf samples too long (2512 > 2500), lowering kernel.perf_event_max_sample_rate to 50000
<smoser> [ 8632.343242] perf samples too long (5010 > 5000), lowering kernel.perf_event_max_sample_rate to 25000
<smoser> what does the above mean ? I'm seeing it on trusty, on non-ssd laptop.
<mwhudson> smoser: the way perf works iiuc is that there is a ring buffer that the kernel shoves data into and the user space process reads it out and writes it to disk
<mwhudson> i think that message means the user space process isn't keeping up
#ubuntu-kernel 2014-01-28
<BenC> apw: I don't see anything on trusty/master-next related to ppc32
<BenC> apw: Is this in your personal tree?
<apw> BenC, my ballsup ... be a minute or two
<apw> BenC, ok
<apw> try that
<BenC> apw: Boarding a flight to dallas so will be later tonight. 
<BenC> apw: Thanks
<apw> cking, start on started dbus and cpu-device-added MODALIAS=x86cpu:vendor:0000:*
<smb> sforshee, was https://bugs.launchpad.net/neutron/+bug/1273386 something you were looking at?
<ubot2`> Launchpad bug 1273386 in linux (Ubuntu) "Neutron namespace metadata proxy triggers kernel crash on Ubuntu 12.04/3.2 kernel" [Undecided,Incomplete]
<cyphermox> I'm trying to figure out what is calling l2cap_sock_connect() here on my Ubuntu Touch device, because that seems to be failing with EINPROGRESS ... I looked at lttng and it doesn't seem to be able to trace that kernel function, do I have another option?
<sforshee> cyphermox: try this: trace-cmd record -p function -l 'l2cap_sock_connect'
<sforshee> then after your done collecting the trace run 'trace-cmd report'
<BenC> apw: Confirmed that e500mc builds and boots fine on my system
<brendand> anyone here i can discuss -proposed kernels with?
<apw> BenC, ack, thanks
#ubuntu-kernel 2014-01-29
<jarkko_> are we ever getting rid of these [   38.345030] HDMI: ELD buf size is 0, force 128 ?
<ohsix> only when all the devices that exist do it right :\
<antarus> 'no' ;)
<jarkko_> i have logitech keybad and logitech keyboard. any idea if they can be combined (unifying receiver)
<jarkko_> is that possible scenario
<ypwong> is there something gone wrong with mainline kernel building? there's only linux-headers debs since 2014-01-24-trusty: http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2014-01-24-trusty/
<jsalisbury> sforshee, resume bug: https://bugs.launchpad.net/bugs/1273369
<ubot2`> Launchpad bug 1273369 in linux (Ubuntu) "[Acer Aspire V5-551G] late resume failure" [Low,Incomplete]
<jsalisbury> sforshee, I'll find a suspend bug
<jsalisbury> sforshee, https://bugs.launchpad.net/bugs/1273991
<ubot2`> Launchpad bug 1273991 in linux (Ubuntu) "[Apple Inc. MacBookPro8,2] suspend/resume failure" [Undecided,Confirmed]
<sforshee> smb: bug 1273386
<ubot2`> Launchpad bug 1273386 in linux (Ubuntu) "Neutron namespace metadata proxy triggers kernel crash on Ubuntu 12.04/3.2 kernel" [Undecided,Incomplete] https://launchpad.net/bugs/1273386
<arges> sforshee: bug 1274066
<ubot2`> Launchpad bug 1274066 in linux-firmware (Ubuntu) "iwlwifi fails with latest firmware" [Undecided,New] https://launchpad.net/bugs/1274066
<bjf> brendand, the sru cycle kernels have moved into -proposed, please start testing :-)
<brendand> bjf, we can't, until later next week
<bjf> brendand, ok, good to know
<brendand> bjf, hope that's alright - what's the deadline now?
<xnox> rtg_: also, can the three or whatever it is gcc fixes patches cherrypicked? which are applied on all other android kernels as well?
<xnox> i guess i should test those first.
<rtg_> xnox, yeah, I'll get 'em after lunch.
<xnox> rtg_: cool.
<rsalveti> xnox: they should be fine (the gcc related fixes)
<rsalveti> rtg_: pushed 2 changes for flo (enabling backlight driver and new release) at http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-trusty.git;a=shortlog;h=refs/heads/flo, mind reviewing/updating our tree with them?
<rtg_> rsalveti, ack, after lunch
<rsalveti> rtg_: thanks
<diwic> ehm, is packages such as linux-image-generic-lts-raring supposed to be installable in 14.04 ?
<diwic> s/is/are
<bjf> diwic, why would you do that?
<diwic> bjf, exactly
<diwic> bjf, I mean that they seem to show up, but I think they should not?
<Faux> Especially as it's lies; they're 3.13 kernels.
<diwic> maybe it is to support some upgrade path
<diwic> but then a comment of "dummy transitional package" or similar would be in order
<bjf> diwic, it's wrong and we are looking into it
<bjf> diwic, thanks for catching that
<diwic> bjf, np
<rtg_> rsalveti, uploaded Ubuntu-flo-3.4.0-1.4 to the c-k-t
<rsalveti> rtg_: thanks, you can already upload this one to the archive as well
<rsalveti> rtg_: as we don't have 4.2 based images for it
<rtg_> diwic, bjf: those raring packages are transitional meta packages for folks updating from raring to trusty
<diwic> rtg_, did you mean people on 12.04 with raring enablement stack?
<rtg_> diwic, uh, right
<diwic> rtg_, right
<diwic> rtg_, maybe add a comment in the package's description about that?
<rtg_> diwic, well, it is factually accurate. I guess I could mention that it is only a transitional package.
<diwic> rtg_, yup
<diwic> thanks
<arges> sforshee: 8aac62706
<brendand> am i right to think that hdaps drivers aren't included in the standard ubuntu image?
<brendand> and i need to install hdapsd to get that to work?
<rtg_> xnox, goldfish uploaded to c-k-t
<xnox> rtg_: thanks.
<rsalveti_> rtg_: were you able to upload flo to the archive as well?
<rtg_> rsalveti_, its in c-k-t as well
<rsalveti_> rtg_: right, but not yet in the archive, right?
<rtg_> rsalveti_, nope. feel free to pocket copy it.
<rsalveti_> rtg_: ok, thanks
#ubuntu-kernel 2014-01-30
<cyphermox> apw: ogra_ tells me you could possibly help me with a debug kernel for mako -- I'm trying to figure out what's up with SCO on the device and running into major problems, it would very much help if we could make sure WLAN_DEBUG is defined when building the prima staging driver, and for log level to be way up for MAC, SME, and BAP for that driver
<cyphermox> (basically, any bluetooth-related crap)
<ogra_> apw, i can do a cross build for him on my lappie, but that will likely take significantly longer so if you have some spare time that would be nice
<Kano> Hi apw , why is 6.23 not in git?
<apw> pththhth
<Kano> apw: why is still no .orig file used?
<ohsix> i think he probably gave you the answer you could expect for any question
<Kano> well, it is really bad style when there is a final kernel
<ohsix> oh, they're not making linux anymore?
<Kano> well, usually is better to see the diff against a kernel release than only a complete tar or not
<Kano> btw. using a tar.xz orig would be smaller as well
<apw> Kano, change one thing at once, when i can get this heap of shit to build, then we can sort that out
<Kano> btw. there is a new firmware file in linux-firmware.git
<cking> apw,  what was the command you used to list out the udev CPU info the other day?
<apw> cking, /var/lib/udev had that in
<rtg> apw, pushed a 3.13.1 rebase since it looks like your bits are gonna build
<apw> rtg, great
<ogasawara> infinity: do we have any recommended docs for building custom netboot images?  (eg I want to build with a custom test kernel)
 * ogasawara check the google
<infinity> ogasawara: Probably not, but ask tomorrow, and me or Colin can give you guys some quick pointers.
<ogasawara> infinity: ok thanks
<jarkko> are you how busy here? :D
<BenC> Anyone happen to have a system with a Broadcom 5720 and mind dumping the firmware for me?
#ubuntu-kernel 2014-01-31
<jamie1> Hi folks, yesterdays saucy (3.11.0-15.25) kernel doesn't appear to be in ubuntu-saucy.git, is this correct?
<bjf> jamie1, that is correct, it contained an embargoed CVE fix
<jamie1> bjf: yes, CVE-2014-0038, now that it's public will this end up in git?
<bjf> jamie1, yes, soon
<jamie1> bjf: great, thanks!
<rtg> apw, are you gonna show me how to pocket copy binaries from the c-k-t PPA ?
<ppisati> apw: export $(dpkg-architecture -aarmhf); export CROSS_COMPILE=arm-linux-gnueabihf-
<ppisati> apw: fakeroot debian/rules clean DEB_BUILD_OPTIONS=parallel=32 AUTOBUILD=1 NOEXTRAS=1 binary-generic
<apw> infinity, that linux-signed is stuck in New
<infinity> I know.  I was smoking.
<infinity> Impatient. :P
<apw> who me ...
#ubuntu-kernel 2014-02-02
<cristian_c> Hello
<cristian_c> I've submitted a bug report (regarding a kernel bug) on launchpad almost two years ago
<cristian_c> recently, the bug status has been set to Triaged and I was told to read this wiki page: https://wiki.ubuntu.com/Bugs/Upstream/kernel
<cristian_c> I've read it but I've got some doubts yet. A dev has told me to contact the kernel team for preparing a faultless upstream report
<cristian_c> Please take care that when you provide the below information, you should be booted into the newest available upstream mainline kernel only. Failure to do this will have negative unintended consequences.
<cristian_c> it's the first question
<cristian_c> I do not know what I have to use between two different kernel since they cause different problems
<ogra_> cristian_c, it is more likely that you catch some kernel team devs during the week work here 
<ogra_> *work week
<cristian_c> ogra_, ok
<cristian_c> thanks
<ogra_> (they might read the backlog, though)
<cristian_c> ok
<apw> crisrian_c ... you might want to let us know the bug# so we can look at it
#ubuntu-kernel 2015-01-26
<shadeslayer> rbasak: hi there, it seems like I'm hitting the same issue as you were here http://irclogs.ubuntu.com/2013/08/01/%23ubuntu-kernel.html
<shadeslayer> rbasak: was there any fix for it?
<shadeslayer> I have a very reliable way of reproducing it in my schroot, when unpacking the firefox tar
<rbasak> shadeslayer: only fix is to not use overlayfs
<shadeslayer> :(
<shadeslayer> but I need it :(
<rbasak> You can configure schroot to clone the entire tree instead I think?
<rbasak> Or something like that.
<shadeslayer> that sounds expensive
<rbasak> Indeed.
<shadeslayer> Well, the workaround I added seems to work, which is basically, keep retrying the tar comand
<shadeslayer> *command
<rbasak> It's a race, so that might work eventually for you. It's not guaranteed to, though.
<shadeslayer> aha 
<rbasak> IIRC, the code in tar makes an assumption that doesn't hold true on overlayfs.
<rbasak> I can't remember the details. Something about fstat after the file has been written or something.
<rbasak> Probably inode number related.
<shadeslayer> well, the exact combination is eatmydata + overlayfs + tar, so I can imagine things going wrong
<Diziet> Hi.  I'm having a problem with     HOME=/ strace -ttfot git-clone -q git://kernel.ubuntu.com/ubuntu/linux.git
<Diziet> It falls over after almost exactly 2 minutes.
<Diziet> Without -q it works.
<Diziet> The strace shows the server sending EOF while the client is still waiting.
<Diziet> Where should I report this ?  It's quite inconvenient as it's making something in our CI system not work...
<apw> Diziet, which version of git is that ?
<Diziet> Debian wheezy
<Diziet>  1.7.10.4
<apw> why does that ring a bell
<Diziet> (Obviously the failure happens without the strace.)
<Diziet> The fact that it works without -q suggests to me that something is deciding that this process or this connection is "stuck", using a timer which gets reset by output (which is fairly copious with -v)
<Diziet> (I mean, copious without -v)
<apw> yep, that is something like the bug, and it is tickling my "this is familiar" noddle
<Diziet> As a workaround, perhaps the timeout could be increased to an amount sufficient to make "git clone -q linux" work ?
<henrix> apw: a grep in my irc logs (because it *does* ring a bell) shows a ref to bug #1228148
<ubot5> bug 1228148 in git (Ubuntu Precise) "git clone -q ends with "early EOF" error on large repositories" [Undecided,Confirmed] https://launchpad.net/bugs/1228148
<apw> henrix, thanks ... i knew i'd seen something
<Diziet> I am experiencing this problem with our git caching proxy.  Naturally I can't really sensibly tell the proxy not to use -q in its own git invocations.
<apw> henrix, oh yeah, i think we shelved this till zinc got upgraded to P
<apw> which i assume it already has
<henrix> yeah, it looks like it has been upgraded
<Diziet> That LP bug has a workaround (sending KA packets) but I'm pretty sure the timeout isn't in git itself.
<Diziet> It is probably in some proxy or wrapper you have.
<Diziet> So I don't think it is necessary for you to patch your git (although that would help people with broken^W NAT).
<Diziet> For me it would suffice to increase your timeout.  (I know it is at your end because I have repro'd the problem from my colo.)
<apw> Diziet, what is the config for the timeout
<apw> Diziet, as i can likely get that changed quickly
<Diziet> IDK.  I'm not sure it is actually in git.
<Diziet> There's a --timeout option to git-daemon which might be relevant.
<Diziet> And also a --timeout option to git-upload-pack.
<Diziet> I think the latter may be the one.
<Diziet> Are you running vanilla git-daemon out of inetd, or what ?
<Diziet> I'm going to try adding a --timeout to my own git-daemon here to see if I can repro the bug.
<apw> Diziet, i am pretty sure it is going to be timeing out, so 1) i am gc'ing the repo you are cloning, and 2) looking to change the timeout
<Diziet> apw: Thanks.  If you bear with me 10 mins or so I can probably confirm what to do to git to increase the timeout.
<Diziet> Are you running git from inetd, or from upstart ?  Is it git-daemon or something else ?
<apw> Diziet, great, pretty sure it is from xinetd
<Diziet> Can you check the command line you're giving it ?  I think it's probably   git-daemon blah blah blah --timeout=120 blah blah
<Diziet> But before you change that 120 I am going to try to repro the fault here.
<apw> Diziet, yeah looks to be ... bah ... i'll wait on your test to confirm, and then can set those wheels in motion
<apw> Diziet, though the bigger wheels would be to add these patches
<Diziet> Great, will get back to you.
<Diziet> Heh.
<Diziet> col tells me that it's fixed (as in, the KA patch is included) in trusty.
<apw> Diziet, yeah and i am sure that box is on P rig
<apw> Diziet, yeah and i am sure that box is on P right now
<Diziet> I can confirm that --timeout=30 makes my own git server produce the same problem.
<Diziet> So I think adjusting your --timeout=120 to (say) --timeout=2000 will probably help.
<Diziet> Actually-stuck processes consume very little resource so I think you should be fine with a big timeout.
<apw> Diziet, yeah, i'll see what i can get fixed
<Diziet> Thanks.  Should I expect a change soon (eg today) ?
<Diziet> I have sent an email to the bug suggesting increasing --timeout as a workaround.
<Diziet> (Of course that won't help people behind a NAT with a short timeout.)
<apw> Diziet, i'd hope, but not expect it to change quite that quick
<Diziet> OK, thanks.
<apw> Diziet, ok i've reuqested the timeout change, and am working on the fixes, we shall see what occurs
<smoser> hey
<smoser> wonder if someone has an idea... not necessarily kernel, but somewhat related.
<smoser> from trusty: http://paste.ubuntu.com/9887959/
<smoser> from utopic: http://paste.ubuntu.com/9887962/
<arges> smoser: its like one of those 'spot the differences' pictures. So you're wondering why the estimated minimum size is less in 3.16?
<smoser> yes. i had more info coming. but good job spotting the diff :)
<smoser> I'm not terribly concerned about the difference, but its causing a failure on a
<smoser> build of maas images
<arges> smoser: so without looking at the code, I wonder if some meta-data structures changed size and thus the minimal size changed. Whats the failure?
<smoser> after doing a of apt-get installs and such to a loop mounted image, on trusty I try to 'resize2fs' to 1400M (arbitrary historic size) and it fits fine.
<arges> smoser: one thing to try is use the older e2fsprogs with the newer kernel to see if there is any calulcation differences there
<smoser> do you think that resize2fs is able to use anything from the kernel ?
<smoser> i would not haave thought it would.
<smoser> but your suggestion would give more info to that
<arges> smoser: there is a patch that adjusts the inode struct which means it could be padded differently and have a different size too.. haven't exhaustively searched
<arges> the difference is 8114 bytes, but we have 145152 inodes... so maybe its a superblock change? 
<arges> smoser: another thing to look at is config differences between 3.13/3.16 to see if something was turned on that could affect structure sizes
<smoser> arges, but the file isn't mounted.
<smoser> so i'm confuse das to how kernel would be involved.
<smoser> isn't resize2fs just opening a file an dlooking around at it ?
<arges> smoser: not sure. strace and find out
<arges> downloading the image here and looking at it
<smoser> strace output: http://paste.ubuntu.com/9888176/
<arges> smoser: so you see a few ioctls before 'Minimum' gets printed
<arges> i'm not sure extactly how minimum size is calculated though.
<smoser> what i'm doing is in lp:maas-images.  something like this ends up getting run:
<smoser>   time maas-cloudimg2eph2 -vv --kernel=linux-generic --arch=arm64 \
<smoser>      $url root-image.gz \
<smoser>     --krd-pack=linux-generic,boot-kernel,boot-initrd 2>&1 | tee out.log
<smoser> and on utopic, it doesn't fit into 1400M and on trusty it does.
<smoser> and i think (doing a more controlled test now) that its significantly different.
<arges> smoser: do you know what size it ends up being overall?
<smoser> i'll have that later tonirhg. just started a run on utopic and one on trusty.
<smoser> i'll keep the images aroudn too so i can grab more debug info on them.
<smoser> but i have to go afk for a while. thanks for your thoughts.
<arges> smoser: hmm running this in vivid makes me run 'e2fsck -f *' first, then I get 290304 (this is on 3.19)
<arges> smoser: sure. this might be worth filing a bug at some point. feel free to ping me again
<smoser> hm..
<smoser> the downloaded image is dirty ?
<arges> that's what resize2fs 1.42.12 says
<smoser> hm..
<arges> md5 sum matches
<smoser> that could be relavant.
<smoser> well, you see the output that i got, it doesn't complain. 
<smoser> maybe i'll try more liberally sprinking 'e2fsck -fy the-image' 
<arges> 1.42.12 vs 1.42.9 wonder if there is some fix that exposes this... ugh
 * arges tries a trusty image for the heck of it
<arges> trusty image on vivid doesn't complain that i need to run e2fsck. size on 3.19/vivid 236103, 3.13/trusty 230329 so still a difference
<arges> smoser: if you want i can do a bisect and figured out which commit made it blow up in size.
<smoser> arges, 
<smoser> trusty: http://paste.ubuntu.com/9889226/
<smoser> utopic: http://paste.ubuntu.com/9889235/
<smoser> basically, note that 'df' reports a difference used of '980200' to '980216'
<smoser> but resize2fs on trusty reports min size of of ~1073M versus ~1582M on utopic.
<smoser> resize2fs does claim "estimated" size, but you'd hope it could estimate a bit closer than that.
<Diziet> apw: (git-deamon timeout) Thanks.
#ubuntu-kernel 2015-01-27
<apw> Diziet, as i think you have noticed the timeout has been upped for k.u.c
<apw> jibel, hey ... seems that DKMS testing didn't kick for vivid CKT (3.19.0-3.3) last night
<apw> tseliot, hey ... we have v3.19 getting close to release now, i see that some of your dkms packages are unhappy (as always)
<jibel> apw, I'll have a look
<tseliot> apw: I've been working on a new upstream release (that I had pulled from -proposed twice) that includes a fix for 3.18 but I haven't tested 3.19 yet. Is there a PPA for that?
<apw> tseliot, it is in the CKT PPA vivid pocket
<tseliot> apw: ok, I'll give it a try then
<smoser> bjf, i just opened https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1415077
<ubot5> Launchpad bug 1415077 in e2fsprogs (Ubuntu) "resize2fs behavior differs greatly between trusty and utopic and vivid" [Medium,Confirmed]
<smoser> arges, ^ is the bug for that resize2fs behavior.
<bjf> smoser, that needs to be fixed to fix the arm64 image issue?
<arges> smoser: thanks
<smoser> well... its complicated.
<smoser> we're building the maas images on utopic vms. 
<smoser> i could put a work aoround in place... to not do the resize you're seeing or just ignore it . 
<smoser> we're using utopic because (to my memory) qemu-static on trusty was failing, but i'm not able to reproduce that failure.
<arges> smoser: did you try trusty e2fsprogs on utopic yet? 
<arges> for that bug
<smoser> i'll try that 
<arges> smoser: i highly suspect its a userspace thing. trusty vm with lts-utopic kernel also shows the same size as 'trusty/3.13'
<smoser> arges, posted info on bug. 
<smoser> it is userspace, its purely a regression in the e2fsprogs
<smoser> hopefully ted will see this.
<smoser> he has been extremely responsive to my e2fsprogs bugs before.
<Diziet> apw: git timeout> Still does just the same thing for me.  Did someone forget to reload inetd ?
<apw> Diziet, hmmm, now thats a question
<apw> Diziet, they did not ... damn
<Diziet> Hmmm.
<Diziet> Just tried it again and it still fails after almost exactly 2 minutes.
<apw> Diziet, yep, damn, poking the appropriate people
<Diziet> Thanks.
<smoser> bjf, so we would hope to have vivid images available in daily in the next ~30 minutes.
<bjf> smoser, cool
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting today @ 17:00 UTC
<jsalisbury> ##
<apw> Diziet, ok, it looks to have been restart appropriatly now
<arges> smoser: check bug 1415077, I found the first 'bad' commit
<ubot5> bug 1415077 in e2fsprogs (Ubuntu) "resize2fs behavior differs greatly between trusty and utopic and vivid" [Medium,Confirmed] https://launchpad.net/bugs/1415077
<smoser> arges, does 'flex_bg' mean something for you?
<arges> smoser: so hopefully ted can comment on this, cause yea I don't know : )
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
<apw> isn't flex_bg the thing that lets you populate block groups as they are needed, rather than having to clean them all during mkfs time
<ppisati> o/
<ppisati> \o
<jsalisbury> ##
<jsalisbury> ## Meeting starting now
<arges> ppisati: wrong channel
<jsalisbury> ##
<arges>  : )
<jsalisbury> heh
<ppisati> o/\o <- high five
<bjf> smoser, do i have an image yet? 
<apw> jsalisbury, have you gone pop ?
<kamal> ... 'cuz this kteam meeting is dragging on and on and on . . .   ;-)
<kamal> ... longest kteam meeting evaaaar
<smoser> no. it failed. http://paste.ubuntu.com/9900803/
<smoser> so i'm going to allow the arm64 to fail resizing down.
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues February 3rd, 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.
<smoser> arges, googling flex_bg and resize2fs seems like this is not the first time.
<smoser> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696746
<ubot5> Debian bug 696746 in e2fsprogs "resize2fs: The combination of flex_bg and !resize_inode features is not supported by resize2fs" [Normal,Fixed]
<smoser> bjf, 20150127 build of vivid available.
<bjf> smoser, if i force my maas to update images will it pull that ?
<bjf> smoser, trying
<bjf> smoser, i don't think my maas sees anything new
<smoser> bjf, you point your maas at daily ?
<smoser> also there is a reverse proxy in the way, so... that can be annoying sometimes.
<bjf> smoser, yes, daily
<smoser> http://paste.ubuntu.com/9902210/
<smoser> http://paste.ubuntu.com/9902223/
<Diziet> apw: Thanks!  That clone works now.
<apw> Diziet, awsome, thanks for the feedback, i am working getting git fixed too
<Diziet> Good luck.
<bjf> smoser, i was too quick off the blocks. i just updated and it found a new image. trying to install
<smoser> horay!
<bjf> smoser, it works!
<smoser> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1411294 
<ubot5> Launchpad bug 1411294 in cloud-initramfs-tools (Ubuntu) "kernel panic during MAAS fastpath install of Vivid images" [High,Fix released]
<smoser> ^ that is fixed ?
<arges> smoser: so is this related ot the resize2fs issue? or different?
<bjf> smoser, yes, that bug is fixed
<smoser> bjf, that bug there is overlayroot had a bug that i fixed but no full test.
<smoser> so horay
<bjf> smoser, are daily image builds still busted or are they fixed as well? (was this a one off to verify that bug is fixed?)
<smoser> bjf, well, mostly should be fixed, but right now there is a transient failure in arm64 builds.
<alias_neo> Hi guys, anyone willing to answer a few (hopefully) simple questions to help me educate myself?
<alias_neo> I'm trying to figure out how I know which modules third party tools might have created/added/installed that i might have to rebuild after a kernel upgrade. I ask because recently, after updating the kernel on my kvm host I had to dpkg-reconfigure libvirt before it would work
<alias_neo> Ok, am i really unlucky or does this happen regularly? When i built my kernel with grsec earlier today, the version was 3.14.29, now kernel.org has 3.14.30 but grsec patch doesn't have a 3.14.30 yet
#ubuntu-kernel 2015-01-28
<apw> alias_neo (N,BFTL), the libvirt thing shouldn't be affected by the kernel at all, so i am confused ?
<tseliot> apw: I'm uploading a patched fglrx that works with linux 3.19. I'll do the same for nvidia soon. Does broadcom need a refresh too?
<eren> hello. I need to compile 3.18.3 with debug symbols on to be used in "perf" utility. I am using Ubuntu Server 14.04. Is there a documentation, ppa, or source explaining the way to achieve it?
<eren> I also need some firmwares as well
<eren> i tried installing 3.18.3 by downloading .deb file in kernel-ppa but debug symbols are off. Additionally, I need to get uncompressed kernel image
<eren> any help is appreciated
<apw> tseliot, bcmwl_kernel_source looks ok, and ta for the otehrs
<tseliot> apw: good :)
<apw> eren, we don't make those with debug in, no sorry, the debug symbols are just toooo big
<eren> apw: ok, I can compile them, no problem
<eren> apw: I'm cloning ubuntu/ubuntu-vivid.git. I also found this wiki page: https://help.ubuntu.com/community/Kernel/Compile
<eren> so, what should I do to enable debug symbols and get uncompressed image?
<eren> apw: are debug infos stripped after the compilation step because I see CONFIG_DEBUG_INFO=y in amd64 configuration
<apw> yes
<apw> eren, they are used to make .ddebs and then stripped to make the .deb
<apw> though in the mainline kernel case we do not make the .ddebs at all currently
<apw> as they are larger per flavour than all of the flavours put together
<eren> apw: ok, is there a way to not strip debug symbols as I see the kernel is compiled using debug symbols
<apw> eren, the norm is to make the deebs, so you end up with a small runnable kernel, and the ddeb has the dwarf info in it
<apw> ddebs
<eren> apw: ok, so ddebs are also generated to be installed?
<apw> eren, if you trigger a full build yex
<apw> yes
<apw> doing so off a buildder may be a little more tricky, you may need to override the checks for that
<eren> ok, compiling now with "fakeroot debian/rules binary-headers binary-generic"
<eren> after grabbing ubuntu-vivid.git, btw
<apw> eren, you will need to add full_build=true i believe, else it will short cirtcuit them for you
<apw> and make sure you have like 5G or so of space
<eren> well space and ram are not problem I have 24 core, 48G ram
<eren> apw: oh, I didn't add "full_build=true", should I pass this as an environment variable?
<apw> on the debian/rules line after it
<eren> DEB_BUILD_OPTIONS=parallel=24 full_build=true AUTOBUILD=1 fakeroot debian/rules binary-headers binary-generic
<eren> oh, after it, ok
<staylor> Question about building a custom kernel using the debian/rules, what's the correct way to sign the debs afterwards?
<apw> staylor, sign them for download ?
<apw> most people use a PPA to build them, and get the signatures from tehre
<staylor> apw: I mean I've built a custom deb and want to sign the one I distribute
<staylor> apw: it's for some custom hardware so using our own internal mirror not PPA
<apw> staylor, i think debsign will do that, but you'll have to ship whatever key you are using, the public component
<staylor> apw: okay wasn't sure, all our custom debs get signed correctly just using debuild so wasn't sure about kernel packages.
<maxb> Normally people don't sign .deb files at all
<maxb> .changes and .dsc files get signed to authenticate them to a repository they are being uploaded to
<maxb> and Release files get signed to authenticate the contents of the repository to clients
<maxb> But debsign may still be the right answer for you, as it kind of sounds like you're trying to sign the .changes file that goes with your .debs to upload them somewhere
<staylor> yeah, using reprepro, though building with debian/rules doesn't generate .changes it seems.
<apw> staylor, they are they same as any other .deb, so whatever you are doing for them, ought to work
<maxb> Direct use of debian/rules is a layer too low in the stack of tools to get a .changes; dpkg-genchanges is normally invoked as a step of dpkg-buildpackage
<smoser> arges, bah. did tso's response on bug 1415077 seem correct ?
<ubot5> bug 1415077 in e2fsprogs (Ubuntu) "resize2fs -P minimum size differs greatly between v1.42.10 and v1.42.9" [Medium,Invalid] https://launchpad.net/bugs/1415077
<smoser> if the only option is to run 'resize2fs -M' multiple times (which results in slow reaad filesystem) then i'll probably just create a new fs.
<smoser> and copy contents and uuid and label
<shadeslayer> rbasak: I've upgraded the kernel to 3.16 from 3.13 in hopes that the problem got fixed upstream
<shadeslayer> rbasak: lets see if it works
<shadeslayer> ( atleast pull-lp-source seems to work manually )
<arges> smoser: looking
<arges> smoser: yea should have read the entire commit, but it seems reasonable. so i'd just adjust your scripts
<shadeslayer> rbasak: yeah, upgrading to 3.16 seems to have fixed it
<rbasak> shadeslayer: interesting, thanks. I wonder if the race is fixed or if the timing just changed.
<shadeslayer> rbasak: not sure, there were a few race condition fixes in git https://github.com/torvalds/linux/commits/master/fs/overlayfs
<shadeslayer> which made me think, lets try and upgrade to see what happens
<shadeslayer> though I'm not even on the stable kernel, which apparently is 3.18
#ubuntu-kernel 2015-01-29
<cmagina> should the hwe kernel be installed by default when doing a netboot install using the trusty-updates installer?
#ubuntu-kernel 2015-01-30
<apb1963> i'm on a 64 bit machine (ubuntu 14.04) and I just noticed that I do not have libc6-amd64 installed....  shouldn't it have been installed by something?
<tmpRAOF> apb1963: No; the libc6 that you've got installed will be the 64bit version.
<tmpRAOF> (Assuming you used the 64bit installer)
<Odd_Bloke> Hello kernel friends; someone has pointed out that the latest image we pushed to GCE has linux-image-3.16.0-30-generic installed, but linux-image-extra-3.16.0-30 isn't available in the repos.
<apw> Odd_Bloke, for utopic images ?  you are saying that the archive doesn't have a linux-image-extra for that version ?
<apw> Odd_Bloke, how are they determining that there isn't one?
<Odd_Bloke> apw: For trusty.
<Odd_Bloke> We have linux-image-extra-3.16.0-30 3.16.0-30.40~14.04.1 installed.
<apw> ? that is -extra ?
<Odd_Bloke> Argh, copy-paste fail.
<Odd_Bloke> We have linux-image-3.16.0-30-generic 3.16.0-30.40~14.04.1.
<apw> I see that in the archive pool on archive.ubuntu.com linux-image-extra-3.16.0-30-generic_3.16.0-30.40~14.04.1_amd64.deb
<apw> and a similar one for _i386, so it definatly exists
<apw> as i say what are they typing that tells them they don't have it
<apw> Odd_Bloke, ^
<Odd_Bloke> apw: http://paste.ubuntu.com/9953137/ (immediately after an update)  This _could_ be a GCE mirror problem; so let me dig on that.
<apw> Odd_Bloke, yeah, i am suspicious it is mirroring lag, but hten how did they get their -30 kernel ?
<Odd_Bloke> Nope, GCE archives are resolving to archive.ubuntu.com still.
<Odd_Bloke> apw: We built the image with the kernel on it.
<apw> Odd_Bloke, that is a -proposed kernel ... so your apt-sources need -proposed enabled to get -extras at that version
<Odd_Bloke> Oh, hm.
<Odd_Bloke> apw: That makes sense; thanks for your help. :)
<apw> Odd_Bloke, np :)
<cristian_c> tseliot, where can I find the newest mainline kernel?
<tseliot> cristian_c: http://kernel.ubuntu.com/~kernel-ppa/mainline/
<cristian_c> tseliot, ok, but what one between them?
<tseliot> v3.19-rc6-vivid
<cristian_c> tseliot, ok, but:
<cristian_c> <tseliot> in that case, upstream developers will only be interested in the upstream kernel, not in the ubuntu specific release (where we apply our own patches)
<Odd_Bloke> apw: How long until that kernel is expected to migrate?  Wondering if suggesting this guy just waits is a viable option...
<apw> Odd_Bloke, it is likely very soon, they were waiting on security signoff only i think last i looked
<tseliot> cristian_c: those are unmodified upstream kernels, regardless of the ubuntu release name attached
<tseliot> cristian_c: have a look at this: https://wiki.ubuntu.com/Kernel/MainlineBuilds
<cristian_c> tseliot, ok
<infinity> Odd_Bloke: Why are you building images against -proposed?
<infinity> Odd_Bloke: Please, with sugar on top, stop that. :/
<melmoth> Hola. On a 14.04 the hpsa module is in the linux-image-extra packages... How to have this module available during install time ?
<Odd_Bloke> infinity: I'm trying to work that out at the moment.
<apw> melmoth, from the CD installer ?
<apw> melmoth, from the alternate or live ?
<melmoth> good question; i m not the one makine the install apw, but i bet my customer is using the "regular" server cd
<melmoth> looks like his drive is not recognised and according to the model he is using, wich is certified, the controller is suppose to use this module
<apw> melmoth, anyhow being in the extra package is not a relevant question i don't think, as that does not define what is on the install image
<melmoth> ahhhh.
<melmoth> i was assuming whatever is in there is not in available during install time.
<apw> melmoth, but we'd need to know what image they are using, so we can investigate
<melmoth> ok. thanks.
<apw> melmoth, right now we don't even know which series they are installing
<smb> apw, If it is a 14.04 server cd image, the hpsa module would be in the block device udeb on cd. Right now I am not sure how to get the installer to ask you about it. Just trying again with expert mode enabled
<infinity> smb: The installer isn't meant to ask at all, it should just install the udeb and probe.
<smb> infinity, yeah and for utopic I seem to have seen something about block modules flying by. Though I had to manually udpkg the udeb before it would find the hpsa module on a different console
<infinity> smb: The second half of that sentence doesn't really make much sense.  If the block-modules udeb wasn't unpacking, we'd have hundreds of bug reports.
<infinity> Not to mention that elmo would kill me if hpsa wasn't working from the installer.
<smb> infinity, really? ahci is built-in... anyway just what I see right now with vms. Something about failing to open the modules.buildin.bin when trying to modinfo
<infinity> smb: Which CD are you using?
<smb> infinity, once the trusty release one. now the trusty .1 server-amd64 and at some point the modinfo works now... confused
<smb> infinity, in parallel I ran the utopic release server 64bit iso and still fail while the installer is asking about partitioning. And for that expert mode also seems ignored...
<infinity> smb: I'm willing to believe utopic is confused.  Less willing to believe that about trusty, given how many hpsa controllers we have in the DC.  Unless literally all of them are still running precise.
<infinity> smb: (And if utopic is broken, I'm also not going to fix it)
<smb> infinity, yeah. all agreed. I think I want to repeat all my steps with a trusty cd (release and . release) without expert mode and see how those compare exactly
<infinity> smb: Yeah.  If you can reproduce in a fully normal install, I want syslogs.
<infinity> smb: Also try a trusty daily to see if we've fixed it by accident for 14.04.2
<infinity> It's possible the missing modules.builtin is confusing something, but I doubt it.  I assume that's a red herring in your debugging.
<smb> infinity, will do that if I find it a problem in .1
<smb> infinity, Ok, pebkac... It helps if one does not move around those four letters. damn
<smb> Bah, how I consistently typed hpsa here and hspa when it came to modinfo is beyond me
<infinity> smb: Heh.  And the new name even makes sense!  HP Smart Array.
<smb> apw, anyway the hpsa module is included if they use server cd images
<Odd_Bloke> Right, I've worked out why we were building from proposed; it was so we could hit the GCE deadline and include the fix for bug 1390604.
<ubot5> bug 1390604 in linux (Ubuntu Vivid) "Outbound TCP Throughput drops to zero for several drivers" [High,Fix released] https://launchpad.net/bugs/1390604
<infinity> smb: As opposed to the old Compaq module which was something ridiculous with 37 Cs.
<smb> was that that cciss thing?
<infinity> smb: Yeah.
<infinity> smb: I don't remember what it stood for.
<infinity> smb: But same hardware, same driver, just pre-buyout rebranding.
<smb> infinity, of course it does not say. still around for the other pci ids I would think
<infinity> Odd_Bloke: Hrm, fair enough.  Were the images actually built with -proposed (ie: you may have gotten other -proposed packages in them too?), or was the kernel special-cased?
<Odd_Bloke> infinity: Proposed was enabled, kernel was installed, proposed was disabled.
<infinity> Odd_Bloke: Alright.  Still pretty icky, but I guess it could have been worse. :/
<infinity> I'm going to break my "don't release on Fridays" rule to unbreak you.
<Odd_Bloke> The fix we needed was in 3.16.0-28 and 3.16.0-29 is now what we'd get without proposed, so I'm going to stop using the proposed kernel in new GCE image builds.
<apw> smb, thanks for looking into that
<infinity> Odd_Bloke: -30 was just promoted, so if you hold off a bit, future images should be happy.
<ogra_> how could it get into that image though ... given it wasnt in the archive 
<infinity> ogra_: It was in proposed, and he was intentionally enabling proposed for kernels. :/
<ogra_> sounds like an issue with the way this image was built 
<ogra_> ah
<infinity> ogra_: We've covered this.
<ogra_> right, if it was intentional ... 
<Odd_Bloke> infinity: Thanks!
<Odd_Bloke> infinity: How can I track the promotion?  Is `rmadison linux-image-3.16.0-30-generic` my best bet?
<infinity> Odd_Bloke: Yeah.
<Odd_Bloke> infinity: Our GCE build process no longer uses proposed kernels, and we've pushed fixed images out the door. Thanks for your help!
#ubuntu-kernel 2015-01-31
<aeoril> I am wanting to start developing for Ubuntu.  I am interested in low level development (like kernel, drivers, modules, etc) but have not developed on Linux in a while.  I am trying to pick an appropriate image to start developing on from cdimage.ubuntu.com.  I found the images for Ubuntu 14.04.1 LTS (Trusty Tahr).  Would that be a good choice?
<apw> aeoril, most development goes on at the tip, both kernel and distro wise, so i'd recommend vivid for that use
<aeoril> apwx ok, thanks - that is good to know
<aeoril> apw ^
#ubuntu-kernel 2015-02-01
<studio_> hi
<studio_> i need some help
<studio_> is someone here to answer some questions?
<cristian_c> don't ask to ask, just ask
<studio_> sry got no answer in #ubuntu-touch... what kernel is ubuntu touch using?
<cristian_c> I don't know
<studio_> who can answer this question?
<studio_> can't find informations about the MT6582 and kernel 3.13.xx :(
<cristian_c> lol
<studio_> why "lol"?
<cristian_c> studio_, mt6582?
<studio_> sorry, i don't understand your "lol" ....
<cristian_c> studio_, mt6582
<cristian_c> is a SoC
<studio_> yes, and it is used for the bq E4.5
<cristian_c> studio_, I don't think you can install #ubuntu-touch on mediatek chips
<cristian_c> studio_, ah, ok
<cristian_c> I understand
<studio_> :)
<cristian_c> studio_, do you own a bq with ubuntu-touch installed?
<studio_> i thought i get my phone on this weekend, but i think it will arrive next week
<studio_> i have seen there is a "rc" channel for (bq) Ubuntu Phones
<studio_> therefore i asked ... on bq git is no new kernel :(
<studio_> @cristian_c any idea?
<cristian_c> studio_, I've never tried ubuntu-touch
<cristian_c> so I've no ideas
<studio_> where can i find informations about my search?
<cristian_c> #ubuntu-touch, I think
<studio_> hmm, there i get no answer ...
<cristian_c> wait...
<studio_> @cristian_c, still waiting ...
<studio_> hmmm ...
#ubuntu-kernel 2016-02-01
<caribou> apw: remember the vm.min_free_kbytes issue with kdump ?
<caribou> Bug: #1528101
<ubot5`> bug 1528101 in kexec-tools (Ubuntu) "ISST-LTE: kdump failed: second kernel booting hangs after /scripts/init-bottom when large min_free_kbytes value being set" [Undecided,Confirmed] https://launchpad.net/bugs/1528101
<apw> caribou, let me say vaguely
<caribou> apw: well, whe vm.min_free_kbytes is higher than crashkernel value, OOM kicks in & doesn't let kdump run
<caribou> apw: anyhow, it is much more complex to fix than what I thought : nowadays systemd-sysctl systemd unit takes care of loading the sysctl values and not procs
<apw> caribou, of course it does
<caribou> apw: well, since the bug was reported on Trusty I didn't bother to check Xenial
<apw> (i wasn't expecting you to have noticed, just expressing my frustration that systemd had changed the way something worked)
<caribou> apw: but just hacking propc to detect /proc/vmcore won't work & I don't feel like changing systemd.service-sysctl
<caribou> apw: :)
<apw> so you are saying that systemd is reading procps's config files directly and applying them
<apw> when we have a perfectly good program to do that alrady
<caribou> apw: yes; it applies everything in /etc/sysctl.d & add a symlink in there toward /etc/sysctl.conf
<apw> caribou, dammit
<apw> caribou, when we boot in kdump world do we boot a different "target" in systemd land
<caribou> apw: I force it to go to systemd.unit=kdump-tools.service but in that corner case, it never makes it to that target
<caribou> apw: I'm not tempted to bend over backward to fix a corner case where the user has set a kernel value that is not coherent with the use of crashkernel=
<caribou> apw: they should just raise crashkernel in that case (which is the workaround I proposed in the bug)
<caribou> I can always fix Trusty for that, but it will be a Trusty-only solution
<diwic> is it expected to get a "warning: file-aligned section .text extends beyond end of file" when installing linux-signed-image 4.4.0-2.16 ?
<diwic> probably not. filed https://bugs.launchpad.net/bugs/1540406
<ubot5`> Launchpad bug 1540406 in linux-signed (Ubuntu) "warning: file-aligned section .text extends beyond end of file" [Undecided,New]
<apw> diwic, do you have secure-boot enabled, and if so does it at least boot ok ?
<diwic> apw, I think secure-boot is disabled
<apw> caribou, i think that there are more than one way the cat gets skinned in userspace that we may be forced to do ti in the kernel
<apw> *that as there are*
<caribou> apw: do we _really_ want to go that far for such a limited set of possibilities ? (though I agree that allowing vm.min_free_kbytes to be larger than the whole memory makes no sense)
<apw> right, i am inclined to think we could at least reject that combination and get 95% of the way there
<diwic> apw, I enabled secure boot and booted the kernel, seems to work
<apw> diwic, ok, so at least that is something, could you shove that info in the bug pls.
<caribou> apw: your call; I will propose to add a simple upstart job that sets the value to what they want for Trusty for that bug
<diwic> apw, will do
#ubuntu-kernel 2016-02-02
<awe__> rtg ( or anyone else ), could you give me a hand with a snappy ripi2 kernel config question?
<awe__> I'm trying to determine of if our latest rolling snappy image was built with a particular kernel option
<apw> awe__, it is best to ask teh question, then we can poke people based on what the quesiton is
<rtg> awe__, fire away
<apw> awe__, installed kernels have a /boot/config-<version> with them
<awe__> I have the source package downloaded, but am not sure how to figure out what config options were enabled when the binary package was built
<awe__> on ripi2?
 * awe__ looks again
<rtg> awe__, we're talking raspi2, right ?
<apw> all kernels we produce should ahve configs in the .deb
<apw> awe__, but from the source tree you should be able to also "fakeroot debian/rules genconfigs"
<awe__> yes, running our latest snappy rolling image
<awe__> apw, cool that'll work!
<apw> which will make the same config in CONFIGS/*
<awe__> awesome
<apw> but you need to be checked out at the right version obviously
<awe__> I am
<awe__> ;)-
<apw> and it would still be better to get the one out of the binary .deb, as that _really_ _really_ was the one it used
<awe__> not sure how I'd do that?
<awe__> if it isn't in the binary deb?
<awe__> by the way, generating worked great after I realized I needed to run it on a xenial image
<awe__> thanks!
<rtg> awe__, it is boot/config-4.3.0-1006-raspi2 in he binary deb
<ogra_> apw, snappy doesnt support putting the config-$version into the snap ... which is why i enable on all arches the /proc/config.gz interface before giving my initial confiig to ppisati ... seems some script removes that again 
<awe__> ok, and that's just not getting installed then?
<ogra_> would be really helpful to keep that 
<awe__> got it
<awe__> sounds like something we should try to fix, but I'm good for now
<awe__> just needed to verify a BT option
<rtg> awe__, it is not 'cause these are intended for embedded systems
<awe__> k
<rtg> ogra_, same for config.gz, it just uses RAM
<ogra_> a few bytes :) 
<JanC> raspi2 has 1 GiB of RAM...
<JanC> most Ubuntu desktop systems had no more (sometimes even less) in the early years...
<JanC> :)
<ogra_> yeah ... it is really neglectable 
<ogra_> and common sense in the embedded world to have it 
<JanC> alternatively, the used diskspace would not really be relevant either, I think?
<JanC> especially if you would gzip it something
<ogra_> yeah
<manjo> apw, PARTUUID works now 
<manjo> apw, do you have a bug where I can post +1 ? 
<apw> manjo, your bug :)
<manjo> apw, oh crap  yeah :) 
<apw> manjo, and you can remind me of the number :)
<manjo> https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1531928
<ubot5`> Launchpad bug 1531928 in initramfs-tools (Ubuntu) "[Xenial] root=PARTUUID=<partuuid> is not recognized as valid syntax." [High,In progress]
<manjo> apw, added a note to that bug. Thanks aton! 
<apw> manjo, thanks
<ogra_> oh, why is that ? 
 * ogra_ remebers adding code to udev in 14.10 or so to support PARTUUID
<ogra_> (and in fact we rely on it heavily on phones)
 * ogra_ wonders i9fr that never made it into the main distro .... if there is new/better code, the phone code should be replaced everywhere 
<mauricfo> rtg, hey. if you have a chance.. on the xenial GA kernel.. will it ship as upstream tag v4.4 and no more, or it should include some more recent commits after v4.4 (e.g, up to a certain point in time) ?
<rtg> mauricfo, it'll havea boatload of 4.5 backport commits as well as several stable updates
<mauricfo> rtg, ok. so, if ppc64el cares about some specific commits, it'd be better to point them in the specific feature request/bugs now, just in case, or wait until some point to verify and then ask? (so not to generate noise on you guys)
<rtg> mauricfo, I'd say do it sooner then later, especially if they are already in 4.5-rc
<mauricfo> rtg, ok. thanks, tim!
#ubuntu-kernel 2016-02-03
<binBASH> Hi, where to find the kernel source of http://kernel.ubuntu.com/~kernel-ppa/ packages?
<apw> binBASH (N,BFTL), the base commit and patches are included, see the README in each
#ubuntu-kernel 2016-02-04
<rtg> kamal, you should add CONFIG_DMADEVICES=y to your 4.2 stable build (and enable all of the dependent devices). I think you'll find a compile issue with drivers/dma/bcm2835-dma.c 
<rtg> for the raspi2 build of course.
<kamal> rtg, huh.  I do test build bcm2834_defconfig   ... shoudn't that probably enable those?
<rtg> kamal, it doesn't by default
<kamal> rtg, well that's annoying
<kamal> (and yes, I see that's true)
<apw> stgraber, just had a new ADT failure lp: #1542049
<ubot5`> Launchpad bug 1542049 in lxc (Ubuntu) "lxc: ADT exercise test failing with linux-4.4.0-3.17 " [Undecided,New] https://launchpad.net/bugs/1542049
<stgraber> apw: so it's hanging on lxc-test-apparmor-mount then
<stgraber> could be network related maybe
<apw> stgraber, isn't that the bits jjohansen1 just changed for us ...
<stgraber> yeah, so either it's getting stuck on network somehow, or it's actually getting stuck on apparmor
<jjohansen1> well, not saying it isn't apparmor, but a better trace would sure help
<jjohansen1> apw: does 4.4.0-3 have the mount patch I did?
<apw> jjohansen1, i believe it does
<jjohansen1> apw, stgraber: maybe its time for me to just drop the patch bomb that has been waiting for ever behind other work
<jjohansen1> it has a lot of locking fixes in it
<apw> jjohansen1, confirmed
<jjohansen1> I need to port another couple of patches to it (I'll do that today), then lets give it a test build
<apw> jjohansen1, works for me
<apw> stgraber, can we tell if it is hanging there somehow, to confirm it is not just a network issue and we are doing this update for nothing
<jjohansen1> apw: well I would say some version of this has to drop for xenial, whether its this set or the moster 3.5 patchset that is still in dev and that won't make feature freeze
<stgraber> apw: I'll manually kick a retry on amd64 now. I confirmed locally that on current xenial, I can pull an image just fine so the network bits we're hitting seem fine right now.
<apw> jjohansen1, ok, i'd love to not have to rush them in but ...
<jjohansen1> apw: well the patchset I'm talking about was meant for vivid/wily and has been mostly just sitting for about 2 months, I agree we don't want to rush the 3.5 thing
<apw> jjohansen1, well if you want that in wily, we prolly want to get it into xenial first for sure
<jjohansen1> yeah
#ubuntu-kernel 2016-02-05
<AndreeeCZ> hi! Im trying to test the 4.4.0 kernel on rpi. I have downloaded and flashed ubuntu-embedded-16.04-raspi2.img and now would like to install this: 
<AndreeeCZ> https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/unstable/+sourcepub/5955607/+listing-archive-extra
<AndreeeCZ> however, im not exactly sure of the procedure. Do i just download and install the .debs ?/
<AndreeeCZ> or is it better to add some repository and upgrade from there?
<ppisati> AndreeeCZ: yep
<apw> s/b 4
<ppisati> AndreeeCZ: or you can add the unstable ppa 
<AndreeeCZ> ppisati, thank you
<AndreeeCZ> ppisati, whats the alternative to the usual /boot/config.txt ?
<ppisati> AndreeeCZ: we don't mount the boot partition in /boot
<AndreeeCZ> oh
<ppisati> AndreeeCZ: we mount it in /boot/firmware
<ppisati> AndreeeCZ: but the rest should be the same
<AndreeeCZ> ok i see
<AndreeeCZ> thank you
<AndreeeCZ> ppisati, do you know which xserver-xorg-video- driver do i install for the VC4 driver?
<ppisati> AndreeeCZ: no idea, sorry
<ppisati> AndreeeCZ: i've never used xorg on that board
<ppisati> AndreeeCZ: always headless
<AndreeeCZ> ok thanks
<rtg> AndreeeCZ, is that raspi2 kernel working for you ? I still haven't gotten around to testing it.
<AndreeeCZ> rtg, it boots
<AndreeeCZ> rtg, ssh works, apt too
<rtg> AndreeeCZ, cool.
<AndreeeCZ> the raspberry pi touchscreen works also
<AndreeeCZ> i mean the screen part of it, dont know about touch yet
<AndreeeCZ> i'm now struggling with how to get the VC4 driver
<rtg> AndreeeCZ, I'm just happy that it boots :)
<AndreeeCZ> ah okay :)
<menace> Hi, i already asked in #ubuntu-devel, but i found with your newsletter this channel, so i wanted to ask... how big is the chance that kernel 4.5 ist ending up in 16.04? are there any advantages for doing that, or anything i can look for, if the possibility rises? personally i would prefer kernel 4.4 for 16.04, since we want to deploy several thousand desktop machines with the 16.04 stack, but one never knows...
<menace> the timeframe seems to be quite narrow. kernel 4.5 can be speculated for the mid of march, you need (from your timetable extrapolated) ~ 2 weeks for testing and 7.4 is the kernel freeze.
<menace> there are some news, that 4.4 is *decided*, but i cannot find any substantiation for that claim on your release schedules.
<menace> or release notes.
<cking> menace, 4.4 it will be
<smb> menace, as cking said. 4.5 could never get enough testing until release
<menace> ah, thanks for the information.
<menace> just to satisfy my personal curiosity: what's the timeframe, complexity and tasks for testing a new kernel before an ubuntu release (besides running performance tests on several chipset architectures)? i could not find very much documentation about that in the wiki 
<cking> menace, it depends on the many factors, it changes every release depending on the kernel chosen, when it lands, the new features we enable and/or stuff we need to get stable and working well
<cking> so, it's hard to say exactly
<menace> okay, i can understand that. i just found https://wiki.ubuntu.com/Kernel/Debugging so at least i have some idea what things you have to test, though i'm sure, there are much more things, than on that site :D. thanks! :)
<apw> menace, there is also a host of dependant packages which have to pass against the kernel before we can ship it
<menace> ah, like special 3rd kernel modules or systemtap?
<apw> right dkms packages and the like, plus we test glibc against the new headers we produce, that kind of thing
<jdstrand> ogasawara: hi! I feel like in a recent xenial update, I started seeing this in my logs every 5 seconds: powercap intel-rapl:0: package locked by BIOS, monitoring only
<jdstrand> ogasawara: have you heard of this?
 * jdstrand wonders if it is a thermald change that was made on upgrade
<ogasawara> jdstrand: well that has to be annoying if it's every 5 secs.  I've not personally heard, but let me send a note to cking and inquire.
<jdstrand> thanks
<jdstrand> I can say that stopping thermald makes the messages stop
<jdstrand> but changing from QUIET to PERFORMANCE does not
<jdstrand> ogasawara: oh, I was wrong. it is every 4 seconds :)
<jdstrand> details...
<rtg> jdstrand, thermald _was_ just updated, but I think there was also something related to intel-microcode
<jdstrand> intel-microcode is still from november it seems
<ogasawara> jdstrand: cking notes he's just recently seen the same issue and will be digging into it first thing on Mon
#ubuntu-kernel 2016-02-06
<Wulf> hi
<Wulf> from which git commit number did you create 3.19.0-49?
<Wulf> how can I build your kernel packages? I get "cannot find readable debian/changelog anywhere!"
<ruchlos42> Wulf: found already these -> https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel ?
<Wulf> ruchlos42: not yet
<ruchlos42> there's also https://wiki.ubuntu.com/KernelTeam/GitKernelBuild and some others that may be stale :)
<Wulf> ruchlos42: it's building now
<Wulf> will probably take another 45min or so :/
<ruchlos42> at least it's not hours.. :)
<Wulf> I'm having the issue that I can reproduce a bug with 3.19.0-23 and later, but not with 3.19.0-22 and earlier
<apw> Wulf, you need for "fakeroot debian/rules clean" after checkout of the tag, to get a buildable tree
<Wulf> apw: yup.
<Wulf> git-bisect tells me about 6 steps (4 hours) left
<apw> Wulf, heh, fun ... is there a bug filed for what you are chasing, it would be good to file one ("ubuntu-bug linux") and to put the progress of the bisect in
<apw> (if you have or file one do let us know the number here so we can follow along)
<Wulf> apw: there are tooooo many bug reports for ubuntu kernel
<Wulf> apw: so no idea if there is
<Wulf> apw: I'll first finish my bisect, then create a new one
<Wulf> and a bad one... 5 steps left
<apw> Wulf, we'd rather have a new bug for your system normally, it can alwasy be dup'd against another bug later
<Wulf> apw: that's what I thought
<apw> good luck with the bisect
<Wulf> thanks :)
<Wulf> bad...
<Wulf> 1a48632ffed61352a7810ce089dc5a8bcd505a60
<infinity> Gesundheit.
<apw> Wulf, hrum, that'd be a hard one to revert, i wonder if it has been "fixed" on top in later releases
<apw> Wulf, but ... file us a bug with all the details and lets us know the bug number and how you reproduce the issue itself
#ubuntu-kernel 2016-02-07
<zkanda> Hello everyone, I'm very new to kernel debugging. I have a new laptop with skylake/nvidia drivers. I want to install the latest mainline kernel. But those won't boot, it would always says that disk not found. It works fine with 4.2/4.3 though. Any idea why?
#ubuntu-kernel 2017-01-30
<leitao> anyway idea why I am getting "l is not clean, please run 'make mrproper'" when compiling a kernel using the instructions from the Kernel/BuildYourOwnKernel wiki?
<leitao> duh, it seems that I have an old .config file.
<apw> leitao, or an empty include/config directory is the other classic
<leitao> apw, right. where should I put my .config file that I want to use to build the kernel?
<leitao> If I want to use a custom config file.
<apw> leitao, one normally adds the changes to config to the appropriate leaf config
<leitao> apw, what is leaf config in this case?
<apw> in debian.<branch>/config/.../config.flavour.<flavour>
<apw> and then runs fakeroot debian/rules updateconfig
<apw> if you have an entirely unrelated config you want to use you can drop then en-toto over the same file
<apw> and do the same thing.
<apw> fakeroot debian/rules genconfigs will drop as will be used configs into CONFIGS/*
<leitao> apw, it works. Thank you!
<apw> leitao, np
<dannf> is 4.11 still considered likely for zesty?
<Sarvatt> dannf: nope, it'll be 4.10
<dannf> Sarvatt: ack, thx!
#ubuntu-kernel 2017-01-31
<bgianf> Looks like you guys ported the following change to xenial's kernel tree: http://kernel.ubuntu.com/git/kernel-ppa/mirror/ubuntu-xenial.git/commit/mm?id=b56d2a75e1daae6ff6eedfb732eadf3c13df6090
<bgianf> This introduced a bug (infinite loop) when using transparent huge pages.
<bgianf> Fix is here: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/mm/huge_memory.c?id=8310d48b125d19fcd9521d83b8293e63eb1646aa
<bgianf> Everyone on my team is hitting this bug on xenial, what's the likely hood of getting the fix ported?
<bgianf> Went ahead and file here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1660518
<ubot5> Ubuntu bug 1660518 in linux (Ubuntu) ""mm/huge_memory.c: respect FOLL_FORCE/FOLL_COW for thp" needs to be ported to Xenial Kernel" [Undecided,New]
<smb> bgianf, Hm, looks like that FOLL_FORCE/FOLL_COW is already aked for (though for different reasons). There is hope to get it into this cycle
<bgianf> smb, cool thanks for the info. Was there somewhere I could have looked to see that it was already asked for?
<bgianf> Looked around briefly, didn't see anything...
<smb> bgianf, It was on the kernel-team mailing list (think there is some archive, too, but probably hard to find by search)
<smb> https://lists.ubuntu.com/archives/kernel-team/2017-January/082114.html
<bgianf> thanks for the link! 
<zioproto> hello all. I am new here. I would like some feedback about CONFIG_NET_DROP_MONITOR=n in the Ubuntu Kernel. It would be of great help to have it set to module. We use ubuntu for the openstack network node.
<rtg> zioproto, I just set CONFIG_NET_DROP_MONITOR=m in what will become the Zesty kernel.
<rtg> (based on your comment)
<zioproto> thanks
<zioproto> If this goes in Zesty I can package the application dropwatch for ubuntu
<zioproto> at the moment is packaged only on Fedora
<zioproto> https://fedorahosted.org/dropwatch/
<zioproto> but it really needs that Kernel support
<rtg> zioproto, It'll likely be a week or so before the 4.10 kernel gets promoted to the Zesty archive. (which is the version to which I've committed the CONFIG_NET_DROP_MONITOR patch)
<zioproto> rtg, thanks ! how does it work for the Xenial kernels ?
<rtg> zioproto, there doesn't seem to be a reason why it couldn't be set '=m'
<rtg> zioproto, please file a bug and assign me to it
<zioproto> rtg, here ? https://bugs.launchpad.net/~canonical-kernel-team
<rtg> zioproto, https://bugs.launchpad.net/ubuntu/+filebug
<zioproto> rtg, redirects to https://help.ubuntu.com/community/ReportingBugs
<rtg> zioproto, maybe you have to be logged in
<zioproto> rtg, this one works https://bugs.launchpad.net/ubuntu/+source/linux/+filebug
<zioproto> maybe the +source/linux was missing ?
<zioproto> rtg, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1660634
<ubot5> Ubuntu bug 1660634 in linux (Ubuntu) "Enable CONFIG_NET_DROP_MONITOR=m in Ubuntu Kernel" [Undecided,New]
<zioproto> I cannot assign it to another person
<zioproto> You may only assign yourself because you are not affiliated with this project and do not have any team memberships.
<rtg> zioproto, done
<zioproto> thanks!
<zyga> ogasawara: hey, I'm sorry to bother you with such a tiny thing; I wrote a patch that exposes bind mount as a flag in mountinfo, do you think it makes sense to send this anywhere? http://paste.ubuntu.com/23901026/
#ubuntu-kernel 2017-02-01
<zyga> ogasawara, jjohansen: I was wondering if you had the time to look at that small MS_BIND patch I've posted earlier on IRC 
<rtg> zyga, you need to email it to kernel-team@lists.ubuntu.com
<zyga> rtg: thanks for the tip, will do
<zyga> rtg: any suggestions on how to format the patch in gmail?
<zyga> should the simple attachment work?
<rtg> zyga, use 'git send-email'
<zyga> okay
<rtg> though an attachment ought to work as well
<slangasek> jsalisbury: just fyi, the source package for grub in Ubuntu is grub2, not grub
<jsalisbury> slangasek, ahh, ok.  must have made  a typo
<Amis> Hello! I'm battling frequent OOMs. First OOM: http://pastebin.com/R1SfbBCu Nothing sticks out to me though I'm not an expert. What is the exact reason or source for the OOM? There seems to be plenty of RAM remaining. Is it fragmentation? Am I missing something here? (Ubuntu server 16.04 LTS, 8GB, 8 core, 4.4.0-59-generic)
<jjohansen> zyga, ogasawara: yes I will look at it
#ubuntu-kernel 2017-02-02
<jjohansen> cking: so there is a fix for the regression posted to the ml, and I have debs in the dir mentioned in the bug
<cking> jjohansen, thanks, I'm just working on giving it a test. Thanks for sorting this out so quickly. Much appreciated
<jjohansen> heh, its not just you who needed it, its been causing problems for snappy
<jjohansen> oops :)
<cking> oh fun.
<jjohansen> yeah, but it showed up in a way we were thinking it was not a regression but showing up a new bug, ...
<cking> jjohansen, it passes the tests, thanks, I've acked the patch
<zyga> rtg: I think I just sent that first patch to the mailing list as you instructed
<rtg> zyga, I just unmoderated it
<zyga> rtg: not sure if I did things correctly
<zyga> rtg: thank you for helping me out
<rtg> zyga, it needs a Buglink, or at least an indication of what kernel to which it applies.
<zyga> rtg: what is the usual way to specify that?
<zyga> rtg: it is just an idea, this is not fixing a bug (more like adding a feature and asking for RFC)
<rtg> zyga, sforshee is our namespace expert. He is the one that should review the patch, and then maybe you could submit it uptream. He'll know to whom it should be sent.
<zyga> rtg: how should I ask sforshee for a review? just on irc here?
<rtg> zyga, he'll notice in a bit when he comes online
<zyga> rtg: I see, thanks
<sforshee> zyga: I'm online already. I just looked at the patch briefly - that's userspace visible, so usually I'd expect that to go upstream first
<zyga> sforshee: I'm not a kernel developer so I'm not familiar with the process, I chose to send it here to get feedback and discuss in a friendlier place than LKML
<zyga> sforshee: it's not a patch that should be applied yet
<zyga> sforshee: I'm working on an userspace problem that got somewhat stuck on being able to reliably detect that a given bind mount is already mounted
<sforshee> zyga: I want to look at it some more before I decide what I think about it, but I need to step away for ~30 min. I'll reply on the list later.
<zyga> sforshee: thank you
<jdstrand> rtg: hi! I noticed https://launchpad.net/ubuntu/+source/linux-signed/4.9.0-16.17 ftbfs. not sure if that was on your radar
<rtg> jdstrand, yeah, sometimes it takes awhile for the signed image to get sorted out.
<rtg> it is going to be superseded by 4.10 soon anyways
<jdstrand> I see
<jdstrand> rtg: ok, thanks!
<zyga> sforshee: I replied to your reply, I think I understand the problem better now and that my patch can be discarded
<zyga> sforshee: if you don't find any holes in my understanding of the topic and the reasoning I presented in the mail I think I can do everything I needed with an unmodified kernel
<zyga> jdstrand: enjoy your time off :)
<jdstrand> zyga: thanks! :)
#ubuntu-kernel 2017-02-03
<grentel> So I have the sources for a custom kernel based on linux-3.12.6...to build this custom kernel should I work from an older ubuntu or can I build it using the latest ubuntu?
<root____1> infinity: talk about the sun
<samiux> what if kernal module is updated/upgraded, the ubuntu box is required to be rebooted even livepatch is applied?
<samiux> what if kernal module is updated/upgraded, the ubuntu box is required to be rebooted even livepatch is applied?
<xnox> rtg, hi! there i regression of bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1557690 in the 4.8 kernels (yakkey + hwe-edge), I've opened bug https://bugs.launchpad.net/ubuntu/+source/linux-hwe-edge/+bug/1661620
<ubot5> Ubuntu bug 1557690 in linux (Ubuntu Xenial) "s390/kconfig: CONFIG_NUMA without CONFIG_NUMA_EMU does not make any sense on s390x" [Wishlist,Fix released]
<ubot5> Ubuntu bug 1661620 in linux (Ubuntu Yakkety) "CONFIG_NUMA is missing from the 4.8 kernels on s390x" [High,Triaged]
<xnox> could that be fixed please? =)
<xnox> i guess it's too late for 16.04.2 respin right =) i guess infinity would kill me.
<rtg> xnox, huh, looks like it didn't get set for Yakkety
<rtg> xnox, I'll make sure its set fr Zesty as well
<xnox> rtg, it is set in zesty and xenial =) only yakkety affect (and apperantely somebody tried to use that)
<xnox> *affected
<xnox> if you set it harder / policy checking enforced that would be nice =)
<rtg> xnox, looks like there is some weirdness with Kconfigs in Yakketty regarding NUMA. I'll get it sorted.
<xnox> rtg, thank you.
<rtg> xnox, https://bugs.launchpad.net/ubuntu/yakkety/+source/linux/+bug/1557690/comments/6
<ubot5> Ubuntu bug 1557690 in linux (Ubuntu Yakkety) "s390/kconfig: CONFIG_NUMA without CONFIG_NUMA_EMU does not make any sense on s390x" [Undecided,In progress]
<xnox> cool =)
<apw> xnox, it is too late for the official last respin, whether there will be one is another question
<rtg> tseliot, there is a 4.10 based kernel in ppa:canonical-kernel-team/ppa that is showing build failures against the usual nVidia DKMS packages
<tseliot> rtg: this is a good time to tell me about those failures, as I am working on an update :)
<tseliot> I'll look into them
<rtg> tseliot, serendipity
<tseliot> now, if only infinity approved nvidia-375 in zesty NEW... :P
<mamarley> tseliot: I don't know how far you are along, but in ppa:mamarley/staging I have nvidia-340 and nvidia-378 packages with patches for 4.10.  Those patches disable the CPU hotplugging support in the driver though because it was broken and I don't know enough about it to fix it.
<tseliot> mamarley: cool, I'll have a look at the patches then, thanks
<mamarley> No problem
#ubuntu-kernel 2017-02-04
<Guest47954> infinity
<Guest47954> active?
<Guest47954> hey leftyfb 
<leftyfb> Guest47954: ?
<Guest47954> do you have a custom kernel?
#ubuntu-kernel 2017-02-05
<Guest47954> How does any individual take the time to read through megabytes of code?
#ubuntu-kernel 2018-01-30
<oursland> Any chance to get the mainline-kernel PPA's build scripts to generate the linux-tools-$ver.deb and linux-cloud-tools-$ver.deb?
<apw> oursland, that is tricky, well cirtainly not possible for non-x86, maybe possible there
<oSoMoN> is there an upcoming fix for bug #1699772 ? I see that this was fixed in debian kernel 4.14.2-1 (according to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865303), and I tested 4.14.15 from http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.14.15/ but the problem persists
<ubot5> Debian bug 865303 in src:linux "libreoffice: Libreoffice Java features crash with Linux 3.16.43-2+deb8u1" [Grave,Fixed]
<ubot5> bug 1699772 in linux (Ubuntu) "linux-image-4.13.0-12-generic, 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] https://launchpad.net/bugs/1699772
<jsalisbury> oSoMoN, Does that bug still exist on Artful?  
<oSoMoN> jsalisbury, IÂ don't know, I tested on bionic only
<oSoMoN> is there a chance it's fixed on artful?
<jsalisbury> oSoMoN, ok, but it does exist on Bionic?  If so, I'll dig into it shortly
<oSoMoN> yes, it definitely exists on bionic
<jsalisbury> oSoMoN, probably not.  If it exists on Bionic, it is in Artful
<oSoMoN> I can repro when running libreoffice autopkgtests
<oSoMoN> or when creating a new database with libreoffice-base
<jsalisbury> oSoMoN, Ok, I'll take a look at the bug in just a bi
<jsalisbury> bit
<oSoMoN> thanks!
<jsalisbury> np
<oursland> Okay, second question.  Running "fakeroot debian/rules clean" then "fakeroot debian/rules binary" on an unmodified v4.14.15 (possibly other versions) fails to complete building claiming that SPL and ZFS require a fully built kernel first.  Is there a suggested way to build the kernel, headers, and tools from source that won't fail?
<oursland> And third question.  Even though there's a build failure, several .deb files are generated, including the tools.  When installed, they do not go to /usr/lib/linux-tools/4.14.15-041415-generic where linux-tools-common expects them, but rather to /usr/lib/linux-tools-4.14.15-041415.  Is this an error?
#ubuntu-kernel 2018-01-31
<LtWorf> why require authentication to join this channel?
<LtWorf> "authentication", the nickserver thing
<alkisg> LtWorf: because of spam bots
<LtWorf> i see
<apw> they tend to flip that status back and forth depending how much spam there is
<melodie> hi
<melodie> one of our LUG's users meet with an issue with the system freeze while using it, with LO, with FF. She is a newbie however she managed to send a pic and a dmesg after a reboot with sysrq. kernel version : https://framapic.org/RTFfSMQExMex/nZ06GcR3LSZo.png and dmesg : https://paste.ubuntu.com/26494950/ - question : is there another kernel she could install to solve this issue? If yes which one?  
<LtWorf> i don't think a screenshot and a dmesg after a reboot are particularly useful
<alkisg> melodie: I found 4.13 kernel highly problematic, and we switched a lot of schools here to 4.4, which appears a lot more stable
<alkisg> apt install linux-generic => installs kernel 4.4, but she would need to manually select it from grub's advanced options, and see if it's more stable, and remove 4.13 if it is
<melodie> alkisg I transmit on our ml, thanks
<alkisg> np
#ubuntu-kernel 2018-02-01
<alkisg> Good morning everyone.
<alkisg> Why do Ubuntu installations under UEFI have both linux-generic and linux-signed-generic installed? Actually, isn't linux-signed-generic enough for any installation, either UEFI or BIOS?
<alkisg> Erm, linux-signed-image-generic depends on linux-image-extra-XXX-generic, which in turn depends on linux-image-XXX-generic. So the packaging prevents us from only having the signed kernel installed. Would that be a bug to be reported?
<alkisg> I.e. linux-image-extra-XXX-generic should Depend on EITHER the signed or non-signed kernels
<xnox> alkisg, eh linux-signed-generic is no more than a detached signature, that is attached to an image.
<xnox> alkisg, i wonder if we need linux-image-extra-XXX-generic-signed?! =)))))
 * xnox thought we do need the image, ah, but i guess the unsigned metapackage is redundant.
<xnox> interesting
<alkisg> xnox: yes, I believe there's no point in having an unsigned version, but at the very least, allow uninstalling it by fixing the dependency there
<alkisg> (I mean, an unsigned version could of course be available in the archives, but there's no point in ubuntu ever installing it automatically or even having it in live cds)
<xnox> alkisg, somehow it feels to me that we only want signed kernels, everywhere, even if nothing knows how to validate that on a given arch.
<alkisg> xnox: sure, that would be fine; I'm not sure if people building the kernel locally can generate them though, so having the unsigned package in the archives will be needed as well?
<alkisg> Personally I have no need for the unsigned version...
<xnox> alkisg, yes, and well we need one too. Cause we build unsigned one first; then kick of a separate build which creates the signed one.... cause otherwise chicken-egg-problem
<mhzlp> Hi everyone :-) I would like to raise a question here, before starting a launchpad ticket
<mhzlp> Having a problem with one of my ubuntu machines. It is giving segfaults when loading specific kernel-modules (vendor-drivers for an isdn-card).
<mhzlp> Output of dmesg states "kernel BUG at /build/linux-fOTvIb/linux-3.13.0/arch/x86/kernel", enclosed in a "---[ cut here ]---" block.
<mhzlp> Problems started with the Meltdown/Spectre mitigation kernel versions, worked fine for years before that. 
<mhzlp> Do you think it makes sense to submit this as a bug ticket?
<klebers> mhzlp, Hi! Is this kernel module shipped by Canonical is it compiled out-of-tree?
<mhzlp> klebers: it is a drivers package which is available for download at the hardware manufacturer. that is why i am asking
<mhzlp> but they deliver the source code, so i built it with #139 and #141 kernel versions, but it failed. last working was #137
<mhzlp> well not the built itself failed, the loading of the module afterwards did
<klebers> that could be either a bug on the kernel itself or a bug on the driver that's causing the BUG to be called
<mhzlp> then it would make sense to open up a bug report in launchpad too, right?
<klebers> mhzlp, yes, please include the full stack trace (the 'cut here' block) and a link to download the driver package
<klebers> mhzlp, is it possible to reproduce the issue without having the hardware?
<mhzlp> will do, also have a strace of the module load prepared. to be honest, i am NOT sure about that, didnt try yet. there is a setup involved for the isdn cards, which afaik has some options for the SNs. Not sure if that would affect the module behaviour
<mhzlp> thanks for the brief evaluation and the hints so far
<apw> xnox, always signed> yes, and we have work in progress to fix that, but it was stalled awaiting to find out if older powerpc boot laoders will barf if we switc
<xnox> urgh
<apw> also it is somewhat back-burnered because of the meltdown debackle too
<apw> xnox, but yes, there seems to be no obvious reason we cannot ship a single signed binary, well as long as no platform moves to having more than one way to sign
<apw> xnox, indeed it was my plan-of-record to work on that over the "quiet time" in december ... so much for _that_
<alkisg> apw: would it make sense to fix the image-extra dependency in the meantime, as it's a small fix? So that people that want to uninstall the non-signed kernel, are able to?
<apw> alkisg, you cannot, if you remove that you have no kernel to attach the signature to
<apw> alkisg, the signed package doens't contain the kernel, only the signature, and copies and attached it in postinst
<alkisg> Thanks, looking (something still feels strange...)
<apw> alkisg, trust me, i wrote that bit :)
<apw> alkisg, the file /boot/vmlinuz-*.signed is not in apt control
<apw> with highsight this was not a good plan, but it was about saving download time as you need to have bot
<apw> both on a non-efi system, well ... we only wanted to use the signed one on efi systems
<apw> to reduce risk when introducing it, now we have experience with it we know it is utterly
<apw> fine in x86 at least, to boot a kernel with a signature on something which does not understand it
<alkisg> apw: ok, all is fine, I was thinking that grub would list two kernels etc, but it doesn't, my misunderstanding
<apw> nope because we did this, we also have to frig grub to hide the duplicate, all in all a poor design choice
<apw> and one we are going to remedy, likely last decdember, oops
<alkisg> :D
<apw> it was actually my number1 priority for 2 days before meltdown was dropped in my lap
<apw> such is the way of teh world
<apw> the best laid plans of mice and men
<alkisg> apw: regarding https://bugzilla.kernel.org/show_bug.cgi?id=198529, there's no response yet from the regression author, yet it affects a whole lot of i5 processors, would we care to fix it downstream?
<ubot5> bugzilla.kernel.org bug 198529 in x86-64 "Reboot on kernel load due to 92a0f81d" [High,New]
<alkisg> I.e. 32bit Ubuntu no longer loads on a wide range of i5 processors
<alkisg> I also mailed him, he didn't respond to that either
<apw> alkisg, we might have found a fix for that, if it is the same issue that wgrant found a fix for
<apw> smb, do we have any test kernels with that 32bit iommu thing appplied ?
<smb> apw, I have none
<alkisg> I'm available for testing, please ping me if someone has such a 32bit test kernel at any time
 * apw makes one
<alkisg> ty!
<apw> alkisg, what is your bug number ?
<alkisg> apw: https://bugzilla.kernel.org/show_bug.cgi?id=198529 => I haven't filed one in launchpad
<ubot5> bugzilla.kernel.org bug 198529 in x86-64 "Reboot on kernel load due to 92a0f81d" [High,New]
<apw> alkisg, do you have an ubuntu bug ?
<alkisg> no
<apw> smb, do we have a bug for that patch yet ?
<alkisg> I can file one if you want
<smb> apw, there were several (i386) not booting
<smb> https://bugs.launchpad.net/ubuntu/+source/linux-hwe/+bug/1744942, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1745118
<ubot5> Ubuntu bug 1744942 in linux (Ubuntu Artful) "Lenovo IdeaPad U460 fails to boot with 4.13.0-31.34~16.04.1" [High,Confirmed]
<ubot5> Ubuntu bug 1745118 in linux (Ubuntu Artful) "Unable to boot with i386 4.13.0-25 / 4.13.0-26 / 4.13.0-31 kernel on Xenial / Artful" [High,Triaged]
<smb> apw, there was a 3rd one but I am too lazy to search for that one as well
<apw> smb, that 118 one looks the most general
<smb> apw, yes, though the other one was reported first I believe
<smb> but on hwe kernel
<alkisg> I like the wgrant explanation on 118
<alkisg> There's a test kernel there
<alkisg> Should I try it or wait for yours, apw?
<apw> alkisg, if there is one there, have at it
<alkisg> Comment #14, https://people.canonical.com/~wgrant/linux-image-4.13.0-31-generic_4.13.0-31.34~16.04.1_i386.deb
<smb> That probably is already having the fix which he then submitted upstream... or at least close
<smb> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/patch/?id=55f49fcb879fbeebf2a8c1ac7c9e6d90df55f798
<alkisg> Yeah that blames the same commit that I blamed all right
<apw> alkisg, yeah i meant to mention it late last night, and forgot ... that is sounded similar enough to be worth testing
<alkisg> Currently installing, will reboot/test in a few
<alkisg> Yup, that fixed it. Thanks apw and smb and wgrant :)
<alkisg> I'll cross-reference the bug reports
<apw> wgrant is the man on that one
<apw> alkisg, so that is intended to be in the next xenial/linux-hwe upload
<alkisg> Very nice. There are still a lot of instabilities with 4.13, but that one was a show-stopper
<alkisg> apw, smb, is https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/patch/?id=55f49fcb879fbeebf2a8c1ac7c9e6d90df55f798 accepted upstream, i.e. should I close my upstream bug report now?
<apw> alkisg, it is very nearly ipstream, it is now in the pti branch which normally goes to linus pretty quick
<apw> alkisg, i would make sure you reference it in your bug
<alkisg> ty, doing so
<nacc> jsalisbury: fyi, LP: #1746818 is more fallout from the 16.04 HWE change to 4.13, if you wouldn't mind triaging
<ubot5> Launchpad bug 1746818 in smb4k (Ubuntu) "smb4k on Kubuntu 16.04 working no longer with new hwe kernel 4.13" [Undecided,New] https://launchpad.net/bugs/1746818
<nacc> (or someone else more relevant, if i'm wrong :)
<TJ-> That reminds me of another: Bug #1743094
<ubot5> bug 1743094 in linux (Ubuntu) "[regression] hibernation (freezes on resume) since 4.13.0-25.29" [Medium,Confirmed] https://launchpad.net/bugs/1743094
<oursland> "fakeroot debian/rules binary" fails to build the kernel, giving an error that SPL/ZFS expect a fully built kernel.  Any suggestions to get past this error?
#ubuntu-kernel 2018-02-02
<apw> oursland, i would need to see more of the log than that, also how did you generate the source
<apw> you could pastebin the log
<rbasak> We seem to be getting a number of regression-update reports: bug 1746806
<ubot5> bug 1746806 in sssd (Ubuntu) "sssd appears to crash AWS c5 and m5 instances, cause 100% CPU" [Undecided,Confirmed] https://launchpad.net/bugs/1746806
<rbasak> Sounds like a possible kernel regression on EC2.
<rbasak> jjohansen: ^ apparmor related perhaps, given the latest comment?
<jjohansen> rbasak: ? I think I am missing context can you paste the relevant bit of discussion
<rbasak> Oh sorry, you only just joined
<rbasak> We seem to be getting a number of regression-update reports: bug 1746806
<ubot5> bug 1746806 in sssd (Ubuntu) "sssd appears to crash AWS c5 and m5 instances, cause 100% CPU" [Undecided,Confirmed] https://launchpad.net/bugs/1746806
<rbasak> Sounds like a possible kernel regression on EC2.
<rbasak> jjohansen: ^
<jjohansen> rbasak: ack, looking
<jjohansen> rbasak: I've added a comment, don't hesitate to grab me to help
<rbasak> jjohansen: thanks, that's helpful. To be clear, I'm not working the bug; just trying to send it in the right direction.
<jjohansen> rbasak: ack, well, if you need me to run through any of the suggested tests to help figure out which way that is let me know, it will probably have to wait until next week as I am doing fosdem
<jjohansen> and am trying to get my presentation together today
<jjohansen> s/doing/at/
<oursland> apw, I have uploaded my checkout and build scripts along with the build log containing the error to: https://gitlab.com/snippets/1696811
#ubuntu-kernel 2018-02-03
<YoeyFu_> When is ubuntufied version of 4.15 likely to be included in the daily build for 18.04?
<s10gopal> how to fix  it ?  kernel-bug-exists-upstream https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1745646
<ubot5> Ubuntu bug 1745646 in linux (Ubuntu) "Battery drains when laptop is off (shutdown)" [Medium,Confirmed]
#ubuntu-kernel 2018-02-04
<gopal> how to fix it ? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1745646
<ubot5> Ubuntu bug 1745646 in linux (Ubuntu) "Battery drains when laptop is off (shutdown)" [Medium,Triaged]
<gopal> how to fix it ? https://bugzilla.kernel.org/show_bug.cgi?id=198665
<ubot5> bugzilla.kernel.org bug 198665 in Other "Battery drains when laptop is off (shutdown) . WOL disabled and no usb device connected." [High,New]
<gopal> https://bugzilla.kernel.org/show_bug.cgi?id=198665
<ubot5> bugzilla.kernel.org bug 198665 in Power-Off "Battery drains when laptop is off (shutdown) . WOL disabled and no usb device connected." [High,New]
#ubuntu-kernel 2020-01-27
<ndichtel> Hi all
<ndichtel> I'm trying to find some docs about supported kernel versions. This page is quite old: https://wiki.ubuntu.com/Kernel/LTSEnablementStack#Kernel.2FSupport.Ubuntu_Kernel_Release_Schedule (nothing after kernel 4.15). Is there something up to date somewhere else?
<apw> ndichtel, hmmm, well the supported versions are exposed most accuratly by the archive, but that being out of date isn't right for sure
<ndichtel> you mean mailing list archive?
<apw> ndichtel, hmm actually as that page only talks about lts release it is nominally mostly up to date, other than a lack of the latest backports
<ndichtel> for example, I'm interessing to know when the hwe kernel version will change
<apw> ndichtel, no that actual archive itself, the hwe version in 18.04LTS ?  it just changed to 5.3 didn't it ?
<ndichtel> there is a lot of vTBD for kernel versions ;-)
<apw> yes it did
<ndichtel> yes
<ndichtel> it just changes
<apw> well it announced on the kernel mailing lists, and normally it changes about 6-8 weeks after teh release of the next development release
<apw> so we have 6-8 weeks of lead time before teh point release which is about to drop for 18.04
<apw> but those diagrams are slightly out of sync with reality as we move hwe a little earlier than we used to so we don't slip the point release itself
 * apw will find someone to fix them up
<ndichtel> ok, thank you for the details
<apw> ndichtel, thanks for pointing it out
<ndichtel> ;-)
<ndichtel> sorry for the naÃ¯ve question: which mailing list can I subscribe to get the announcement?
<apw> kernel-team@ lists.ubuntu.com
<ndichtel> oh, I thought it was a private ml
<ndichtel> thanks
<zx2c4> apw: https://xn--4db.cc/5xyUvbQg/diff maybe this will help
<zx2c4> perhaps it just works out of the box O_o
<zx2c4> Lotta crazy scripting going on
<apw> zx2c4: close to what I have, just it is on top of the new versioned provides bits
<zx2c4> apw: version provides bits?
<zx2c4> am i on the wrong branch of the repo?
<apw> zx2c4, not published anywhere yet, i am fixing 3-4 bugs in the same area; yours includeed
<apw> zx2c4, should be finished tommorrow if i haven't pooched anything
<zx2c4> apw: oh cool
<zx2c4> i looked at those scripts
<zx2c4> dkms-build--{packagename}
<zx2c4> and
<zx2c4> dkms-builds--{packagename}-configure
<apw> zx2c4, i assume you will contact us direct if there are any security/urgent updates for the driver
<zx2c4> or something similar
<zx2c4> and i couldnt see anything in those that wireguard would need
<apw> yeah it is all a bit more complex than it needs to be because of nvidia not being really shipped by linux
<zx2c4> but if you do find yourself needing some hacky stuff like that, we cna probably put that upstream instead
<apw> zfs is a good exmaple to follow
<zx2c4> cept zfs has like 20 modules
<apw> right, but overall as you guestimated it is about as complex
<zx2c4> 18:12:51 <apw> zx2c4, i assume you will contact us direct if there are any security/urgent updates for the driver
<zx2c4> i'd probably be inclined to do that _but_ you (or kerneltoast) should join wgml and watch the [ANNOUNCE] emails
<apw> zx2c4, oh while a remember; where will the upstram bits land in the tree, ie where will the .ko express
<apw> zx2c4, can you pm where that is, and i'll get added
<zx2c4> drivers/net/wireguard.ko
<zx2c4> https://lists.zx2c4.com/mailman/listinfo/wireguard
<apw> ok good, so the dkms one will appear in wireguard/* so that is not going to clash
<zx2c4> ./5.5.0-rc6+/kernel/drivers/net/wireguard/wireguard.ko
<zx2c4> actually, that^
<zx2c4> alright thats fine
<zx2c4> wireguard-dkms builds into net/wireguard in fact
<apw> zx2c4, right but i don't let it go where it thinks it wants to :)
<apw> zx2c4, the dkms-build magic sorts that out for all of 'em
<zx2c4> so wireguard/wireguard.ko (apwlandia), net/wireguard.ko (dkms), and drivers/net/wireguard/wireguard.ko (upstream) all do not clash
<apw> i think dkms is updates/<omething>)
 * apw looks for a keyboard with all of the keys in the normal place
<zx2c4> https://git.zx2c4.com/wireguard-linux-compat/tree/src/dkms.conf
<zx2c4> DEST_MODULE_LOCATION="/kernel/net"
<zx2c4> kernel/net apparently, in fact
<zx2c4> O_o
<zx2c4> perhaps ubuntu overrides that though
<zx2c4> but, anyway, sure -- feel free to put it wherever you think is best
<apw> /lib/modules/5.4.0-9-generic/updates/dkms/wireguard.ko
<zx2c4> gotcha
#ubuntu-kernel 2020-01-28
<zx2c4> 18:12:14 <apw> zx2c4, should be finished tommorrow if i haven't pooched anything
<zx2c4> 18:12:31 <zx2c4> apw: oh cool
<zx2c4> apw: did this materialize?
<apw> I ended up sick, it is the top item on my list for when I get to my laptop
<zx2c4> Aw sorry to hear
<apw> i am a migrain sufferer, so its not so uncommon
<aberrant> hi all. I built a custom kernel (version 5.3.10+). Just went to do an apt-upgrade and I saw this: vmlinuz -> boot/vmlinuz-5.3.0-29-generic. Should I relink it to /boot/vmlinuz-5.3.10+ ?
<aberrant> not quite sure what happened here. I thought that since my kernel's version was later than the one from apt, it would be preserved?
<apw> aberrant, depending on which bootloader you are using i don't think those links are used very often
<aberrant> apw - grub, I think
<aberrant> apw - how do I tell what kernel will be booted?
<apw> pretty sure it will not be using those links
<apw> when update-grub runs it shows the menu entries in order
<apw> top to bottom iirc
<apw> failing that /boot/grub/grub.cfg and search for menuentry
<tomreyn> zx2c4: just out of interest: had you considered to also idle in / contribute to #debian-kernel (on oftc)?
<zx2c4> tomreyn: sure, will join
<aberrant> thanks.
<aberrant> grub-update shows 5.3.10+ first, so there we go :)
#ubuntu-kernel 2020-01-29
<pent1ckel> I know it is offtopic but:
<pent1ckel> zx2c4: congratilation. you made it into the kernel
<DalekSec> Indeed.
<DalekSec> !conga-rats
<ubot5> â« samba rumba bueno la conga cha cha cha
<zx2c4> pent1ckel: thanks!
<zx2c4> not offtopic! apw is adding it to ubuntu today
<zx2c4> apw: feeling better today than yesterday?
<pent1ckel> this is even cooler. as we will switch to ubuntu 20.04 as wireguard will be included by default. we using 18 and adding module and utils by our self which is OK but included would be very nice
<zx2c4> pent1ckel: plan is to backport it to 18 as well :)
<pent1ckel> even to 18? wow that would be even better
<amitprakash> How do I push a custom kernel to launchpad (no modules, firmware blobs added, no initramfs) Currently, I get a rejection w/ "Source/binary (i.e. mixed) uploads are not allowed."
<amitprakash> I have specified the .config file (and tried to push the .dsc file generated by deb-pkg
<apw> amitprakash, you can only build from source in launchpad; so from a clean source tree a dpkg-buildpackage -nc -S
<apw> not something with binaries attached, that is just not allowed
<amitprakash> apw: How do I push firmware blobs then? 
<apw> amitprakash, where are they expected to end up.  if they need to be in /lib/firmware normaly you would make a linux-firware-<my-special-thing>
<apw> package to carry those and then depend on that
<apw> the raspi2 is a good example of that having its own private firmare block package
<amitprakash> Got it, so package firmware first, get that in lp, then specify the fw as a dep so lp can pick up the files from /lib/firmware
<amitprakash> Let me give that a shot
<apw> right, and you can do both of those together in your ppa
<amitprakash> thanks for the guidance
<zx2c4> apw: youre alive!
<apw> zx2c4, yep
#ubuntu-kernel 2020-01-30
<zx2c4> apw: oh cool "UBUNTU: Ubuntu-5.4-5.4.0-13.16"
<zx2c4> it's been tagged
<zx2c4> !!
<apw> zx2c4, its on its way thorugh the sausage machine
<zx2c4> is that what "cranking" is?
<apw> just a colloquialism, as in 'turning the crank' over and over to make things happen
<zx2c4> haha
<sdhd-sascha> I already ask at netplan. I can't set link up on a bond device. The members of the bond are all in UP state. I can ping the local bond. What could be wrong ?
<sdhd-sascha> Not sure, what happens. But know i got a link. What i have done:
<sdhd-sascha> 1) add an ip addr on one bond member
<sdhd-sascha> 2) ip link set up dev bond0
<sdhd-sascha> 3) netplan apply
<sdhd-sascha> Now it works?!
<sdhd-sascha> Thank you 
<zx2c4> apw: is there a .deb built somewhere of those modules?
<apw> zx2c4, heh the sausage machine is not _that_ quick
<zx2c4> oh... my
<apw> zx2c4, and signing into the efi trusty thing takes time too
<zx2c4> tag was 2 hours ago.... this cranking machine must be some insane aparatus
<apw> zx2c4, the amd64 build is quick-ish, but there are other arches on there
<zx2c4> does it require you keep pressing buttons or is it pretty automaed
<zx2c4> automated
<apw> zx2c4, its mostly automated as you would expect; but it is building on the launchpad builders so it has to wait for availablity etc
<apw> zx2c4, and the arm arches take like 8 hours to build
<zx2c4> oooo it's a launchpad procedure so of course it takes forever
<zx2c4> holy cow
<apw> zx2c4, it was only actually uploaded like 20m ago, so ... it'll be a bit
<zx2c4> oh :D
<apw>       NEW : wireguard
<apw> s390x has finished and actually has built a new module ...
<apw> so that is hopeful
<zx2c4> haha cool what webpage is that
<zx2c4> https://launchpad.net/ubuntu/+source/linux/+publishinghistory is empty
<apw> yeah it gets built in a team ppa
<apw> zx2c4, once all the arches are built it gets one last review then copied to -proposed to be signed; then it gets properly tested before release
<apw> zx2c4, i expect i get to test wireguard :)
<zx2c4> hehe
<zx2c4> apw: http://demo.wireguard.com/ might be useful
<zx2c4> curl https://git.zx2c4.com/wireguard-tools/plain/contrib/ncat-client-server/client.sh | sudo bash && ping 192.168.4.1
<zx2c4> curl https://git.zx2c4.com/wireguard-tools/plain/contrib/ncat-client-server/client.sh | sudo bash && ping 192.168.4.1 && ip link del dev wg0
<zx2c4> curl https://git.zx2c4.com/wireguard-tools/plain/contrib/ncat-client-server/client.sh | sudo bash && ping -c 4 192.168.4.1 && ip link del dev wg0
<zx2c4> voila.
<zx2c4> output looks like this: https://×.cc/ygmapdKc
<apw> zx2c4: oh I use it in anger I will know if it works
<zx2c4> haha
<ricotz> sforshee, hi :), do you mind to retry they finished archs to reduce the automatic delay? https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/unstable/+packages?field.name_filter=&field.status_filter=published&field.series_filter=focal
<ricotz> s/reduce/avoid
<sforshee> ricotz: done
<ricotz> sforshee, ty
#ubuntu-kernel 2020-01-31
<zx2c4> apw: woah hey famous already https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-20.04-Adds-WireGuard
<zx2c4> also, cool https://usercontent.irccloud-cdn.com/file/Ww768WV1/image.png
<apw> zx2c4, the wheels are grinding ... as distros go we are pretty quick
<zx2c4> Sure sounds it!
<zx2c4> Aside from the sausage making process of course
<apw> zx2c4, that is as much as anything about multiple checks and balances
<zeripath> Hi! I've recently got a HP Omen 15 - it's got fancy keyboard backlights and I was wondering about how I could get them configured from linux without going in to windows
<zeripath> I've discovered that they're attached to the ACPI names(?) "\_SB_.WMID.LM02" to get and "\_SB_.WMID.LM03" to set 
<zeripath> so if I do echo "\_SB_.WMID.LM02" | sudo tee /proc/acpi/call > /dev/null; && sudo cat /proc/acpi/call; echo;
<zeripath> I'll get something that I can read the values for the current backlight settings from
<zeripath> but I don't know how to structure the Set
<zeripath> I've got the DSDT.dsl 
<zeripath> but I don't know how to read it.
<zeripath> What's interesting is that the windows client does a very different thing
<zeripath> it appears to send commands to 131081 -> (Which maps to 0x20009 which is what these things are mapped to) 
<zeripath> can anyone help me or give me some pointers?
<sarnold> zeripath: have you seen the acpica-tools package?
<zeripath> sarnold: heya! 
<zeripath> as in acpiexec?
<zeripath> so I used iasl to get the dsdt.dsl - which is where I've found the name
<tomreyn> WMI as in (Ms) "Windows Management Instrumentation", IIRC?
<tomreyn> and i think someone wrote a client for linux to make these systems work at all.
<tomreyn> https://wiki.ubuntu.com/Kernel/Reference/WMI
<tomreyn> https://lwn.net/Articles/391230/
<tomreyn> https://github.com/torvalds/linux/blob/master/drivers/platform/x86/hp-wmi.c
<tomreyn> zeripath: ^
<zeripath> tomreyn: Is there a userspace way of querying these?
<tomreyn> zeripath: this is all i know really, sorry.
<zeripath> So I think hp_wmi_perform_query() might show the way to do it but I'd rather do something in userspace at least to test stuf
<zeripath> Interesting the commmand number would be 0x20009 which is substantially higher than the ones in that function
<zeripath> The fans would be actually 0x20008 
<tomreyn> do you have "ACPI Error: Method parse/execution failed" for something involving \_SB_.WMID? i read 5.2.1 got some patches about HP WMI ACPI table parsing.
<tomreyn> actually 5.4.2, namely https://bugzilla.kernel.org/show_bug.cgi?id=201981
<ubot5> bugzilla.kernel.org bug 201981 in BIOS "ACPI Error Method parse/execution failed \HWMC, AE_AML_BUFFER_LIMIT - HP Envy x360" [High,Resolved: code_fix]
<tomreyn> zeripath: see what you have in sysfs
<tomreyn> +   lsmod | grep hp-wmi
<zeripath> There are a few of these errors - but I'm fairly certain that linux doesn't know about these LEDS
<zeripath> tomreyn: So I don't have hp-wmi as module in lsmod and I can't modprobe it either
<zeripath> I'll have another think about this tomorrow. Thanks for your help
<tomreyn> hmm should have been a module though?   grep HP_WMI /boot/config-$(uname -r)    tells me CONFIG_HP_WMI=m
<tomreyn> ubuntu 18.04 with HWE (linux 5.3)
#ubuntu-kernel 2020-02-01
<zeripath> tomreyn: so yeah hp-wmi is a module in my kernel but it won't modprobe it seems.
<zeripath> ah
<zeripath> I am an idiot
<zeripath> hp_wmi does modprobe
<zeripath> It becomes hp_wmi not hp-wmi
<tomreyn> zeripath: right, i forgot to do the conversion.
<tomreyn> <tomreyn> hmm should have been a module though?   grep HP_WMI /boot/config-$(uname -r)    tells me CONFIG_HP_WMI=m
<tomreyn> <tomreyn> ubuntu 18.04 with HWE (linux 5.3)
<tomreyn> i'm not sure what the exact sysfs path to look at would be, though
<zeripath> So yeah I've been able to get that module installed in to my kernel - I'm just trying to figure out how to use it 
<zeripath> I suspect I have to write additional functionality --
<zeripath> for example if I press the Omen key - which is where Home should be I get a hp_wmi: bad event status 0x5
<zeripath> tomreyn: it looks like I might have to try kernel at least 5.4.7
<zeripath> I get a lot of ACPI Error: Field [D128] at bit offset/length 128/1024 exceeds size of target Buffer (160 bits) (20181213/dsopcode-197)
<zeripath> with that module
<zeripath> but damn I have a bloody nvidia card
<zeripath> ARGH so I can't just randomly move to a newer kernel
<tomreyn> zeripath: exactly the ACPI errors i referred to above
<zeripath> yeah sorry
<zeripath> I don't think they are the issue for the backlight but it would make testing difficult.
<zeripath> Is there any chance that the fixes of 5.4.7 will be backported to the eoan line?
<tomreyn> chances are focal will release with linux 5.5, and if it will, there'll be a LTSE / HWE backport for ubuntu 18.04 LTS for it, which will most likely get compatible nvidia drivers.
<tomreyn> i can't tell about the backports, i'm not an ubuntu kernel dev.
<tomreyn> if you filed a bug report you'd likely increse the chances of it being considered
<zeripath> I'll have to figure out how to report a bug on launchpad then... 
<zeripath> I guess the other thing is to see how focal is doing...
<tomreyn> zeripath: "ubuntu-bug" / "apport" - general support would be in #ubuntu if you have any questions
<tomreyn> try doing both?
<zeripath> heh
<zeripath> I've done the ubuntu-bug thing
<zeripath> Ah So actually this is a seriously simple fix
<zeripath> I've applied the patches https://lore.kernel.org/stable/20191122185641.60711-1-hdegoede@redhat.com/
<zeripath> to a private dkms'd thing 
<zeripath> and the error goes bye bye
<tomreyn> oh you already posted those to the bug report, now we got two ;)
<tomreyn> your dmesg is not short of ACPI errors in general
<tomreyn> is the bios from september the latest?
<tomreyn> there's F.14 (you have F.13) at https://support.hp.com/us-en/drivers/selfservice/swdetails/omen-by-hp-15-dc1000-laptop-pc-series/26122182/swItemId/ob-243598-1
<tomreyn> but it only seem to be the latest intel microcode update
<zeripath> yeah that was my thought
<zeripath> Can we install that firmware without having to go to windows
<tomreyn> there's also this separate IC update https://support.hp.com/us-en/drivers/selfservice/swdetails/omen-by-hp-15-dc1000-laptop-pc-series/26122182/swItemId/ob-227043-2
<zeripath> a lot of the errors might be because I was adding and removing the hp-wmi module
<tomreyn> only if HP provides linux support for this system, via their support website, or through fwupd.org
<tomreyn> yes there are really only two classes of ACá¹I errors you have. one is about hp-wmi
<tomreyn> the other seems to be about the usb hub
<zeripath> yeah
<zeripath> SO I
<zeripath> have managed to hack the hp-wmi driver to return the values of my leds
<zeripath> woot
<zeripath> cat /sys/devices/platform/hp-wmi/keyboardleds                     [20:45:46]
<zeripath> #7da247 #42adff #ffaee2 #27b6ff
<zeripath> I just need to decide on how they are supposed to be returned and then I'll try storing them again...
<zeripath> damn that wasn't real
#ubuntu-kernel 2020-02-02
<zeripath> tomreyn: I did it. I can change the colour of my backlight leds.
* bjf changed the topic of #ubuntu-kernel to: The Focal / 20.04 LTS Kernel will be based on the upstream, 5.4 version
