#ubuntu-kernel 2006-01-09
<ppd> BenC: It gives me the same eject error with the new kernel :(
<BenC> what's the eject error?
<ppd> Can't eject. Last error: Invalid argument.
<BenC> invalid argument, that's not the bug error
<BenC> it does EIO, Input/Output Error
<BenC> does eject -s work for you?
<ppd> wait
<ppd> yes
<ppd> from the console as root it works
<BenC> then you did something wrong with the patch to scsi-ioctl.c
<BenC> recheck it, and make sure the ioctl fro CDROMEJECT  matches, and that the functions are properly copied
<ppd> I am using the archck patchset. Could that influence the result?
<ppd> http://pastebin.com/489438
<ppd> this compiled fine
<ppd> :(
<ppd> BenC: If you could have a look at it I'd be helped very much
<BenC> ppd: looks ok to me, not sure why it isn't working
<ppd> probably a newer eject version is needed?!
<BenC> no, shouldn't be
<BenC> are you sure you are using the built kernel?
<BenC> eject -s should be the same as eject -r with that patch, IOW, if eject -s works, then normal eject should aswell
<ppd> hm. I'll try eject from the console
<ppd> max@max:/usr/src/linux-2.6.14$ eject /dev/sda1
<ppd> eject: Kann nicht auswerfen! Letzter Fehler: Das Argument ist ungltig
<ppd> umount was ok
<ppd> probably I really started the wrong kernel... can't be....
<ppd> BenC: sorry for annoying you again. But this time I'm absolutely sure I run the patched kernel and it doesn't work
<ppd> BenC: I have done a strace eject /dev/sda1 but this didn't help me 
<ogra> ogra@aleph:~$ mount |grep mapper
<ogra> /dev/mapper/vg0-lvol0 on / type ext3 (rw,errors=remount-ro)
<ogra> /dev/mapper/vg1-lvol1 on /var type ext3 (rw)
<ogra> BenC, mjg59, thanks a lot !!
<ogra> i owe you a drink or something ...
<BenC> what for? :)
<ogra> pointing me to the right places :) 
<ogra> the via patch seems to run fine ...
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-11.16 uploading (The "Real 2.6.15" release, AKA The "If-Anything-Breaks-Its-Our-problem-Now" Release)
<infinity> Oh look, a new ABI.
<infinity> BenC: I need to give LRM some TLC... Any reservations about holding off on the LRM/-meta uploads until tomorrow, when I can make it all happy?
<infinity> (I can do -meta when LRM is done)
<fabbione> morning guys
<fabbione> oh oh oh
<infinity> ?
<fabbione> .15 final in the archive :)
<infinity> Indeed.
<Panda2> 
<Panda2>   ?
<infinity> Panda2: This is an English channel.
<Panda2> sorry, i'm dont know
<Panda2> Adam Conrad this cool nick
<Panda2> talk to me Adam Conrad
<Panda2> people?????????
<CataEnry> hi all
<pappan> BenC: hi
<pappan> any 1 here
<pappan> from kernel devel team
<CataEnry> hi all
<ppd> hi
<ppd> is it possible the several fixes need to be backported in order to fix that eject bug?
<BenC> no
<ppd> BenC: then either I patched the file badly or this fix ust won't work with 2.6.14!?
<BenC> Your error is not the same as what is in the bug report, but I have no idea why you are getting the error
<BenC> No sure how eject -s could work for you, but normal eject with the patch doesn't
<ppd> eject -s works with root rights
<BenC> do this
<BenC> strace -o eject.out eject
<BenC> and pastebin th eject.out
<ppd> two seconds :)
<ppd> http://pastebin.com/490104
<ppd> :)
<BenC> ah, ok, the CDROMEJECT ioctl is getting EIO
<BenC> I didn't realize that eject tries every method if they keep failing
<BenC> ls -l /dev/sda1
<BenC> let me see that
<ppd> brw-r-----  1 root plugdev 8, 1 2006-01-04 14:46 /dev/sda1
<BenC> ok, so updated eject wont help (sg_io needs write perms)
<BenC> from now on when testing the fix, do "eject -r", since that only does the CDROMEJECT ioctl that we are testing
<BenC> what type of device is this you are ejecting?
<ppd> an usb plugged harddisk
<ppd> eject -r gives inpout/output error
<BenC> and why exactly do you want to eject a harddisk?
<ppd> i don't want. gnome does...
<BenC> and gnome is complaining because it fails?
<ppd> gnome pops up an error message telling me "Eject. ... Invalid argument"
<BenC> can you do "sudo strace -o eject.out eject -s"?
<ppd> sure
<BenC> I think the issue here is that this device cannot be ejected
<ppd> http://pastebin.com/490110
<BenC> does that make the device inaccessible afterwards?
<ppd> if I plug it in again?
<BenC> no, right after eject
<BenC> can you remount it after ejecting it with eject -s?
<ppd> max@max:~$ sudo mount /dev/sda1 test/
<ppd> max@max:~$
<ppd> no problem
<BenC> then it's not really ejecting
<ppd> I think so. a harddisk can't be eject, or?
<BenC> well some usb devices can be, like ipods
<BenC> it basically puts the device offline
<ppd> my usb stick doesn't give an error when umounting/ejecting with gnome
<BenC> but eject -r still should not be returning EIO, since eject -s is not either
<BenC> can you try eject -r on the device?
<ppd> as user?
<BenC> yeah
<ppd> with strace?
<ppd> http://pastebin.com/490132
<ppd> here's the strace output
<ppd> i/o error
<BenC> ah, I see why eject -s isn't returning an error
<BenC> it actually is getting an error, just that eject is ignoring it
<ppd> that would be an option too :)
<BenC> does "sudo eject -s" take your USB device offline (can't remount it)?
<ppd> max@max:~$ sudo mount /dev/sdb1 test
<ppd> max@max:~$ cd test && ls
<ppd> lost+found  nvidia_patched  user
<ppd> max@max:~/test$
<ppd> stays online
<BenC> ok, then this is a different bug altogether, in that gnome should do something better
<BenC> I wonder if gnome calls eject, or calls it's own internal ioctl's
<ppd> hm, probably I can find something in libnautilus source
<ppd> or can iI strace nautilus eject ?
<BenC> you can try, but this is getting out of my expertise
<ppd> ok. thank you very much. So there's nothing I can do?
<zul> heylo
<ppd> BenC: a new version of eject wouldn't help? or hacking eject so that it ignores that error?
<ppd> scsi eject works as root
<BenC> it doesn't work, it just ignores the error
<ppd> so who causes the error?
<BenC> eject -s is the same as eject -r functionally in the kernel, after patching scsi_ioctl.c
<BenC> it's just that eject ignores the error from sg_io
<BenC> the device causes the error
<BenC> it's scsi eject that is ignoring things
<BenC> in the eject program that is
<BenC> if it checked hdr->status, it would see the error
<ppd> ok. so the error is neither in the kernel nor in eject?
<ppd> It's just that you shouldn't call eject for a usb disk?
<CataEnry> bye all
<fabbione> BenC: ping?
<BenC> fabbione: pong
#ubuntu-kernel 2006-01-10
<djst> BenC: hello. do you know if there are any plans on including the shfs module in the kernel?
<djst> currently, you need to compile it yourself using module-assistant, and it's a bit buggy
<djst> (Fabio told me to ping you about this, but he warned me that you had connection problems today)
<zul> heylo
<CataEnry> hi
<zul> heylo
<CataEnry> hi all :)
<zul> i love fire alarms
<lamont> hrm... what is the least-crackful, currently-purchasable-retail, 802.11 card for breezy?
<lamont> BenC: ?? ^^
<lamont> mjg59 - you laptop god you?
<mjg59> lamont: Uhm. No real idea.
<lamont> feh.
<mjg59> The best supported laptop stuff is probably Intel kit, and that's not available in anything other than minipci
#ubuntu-kernel 2006-01-11
<trappist> iptables is currently built against a minimal chunk of some old kernel source included in the package.  it all gets patched with patch-o-matic in a vain attempt to add some nice features that don't actually work because we're not patching the kernel and we're not building against our real kernel.  I'd like to work on iptables, but I'd need some help, or at least cooperation, on the kernel side.  where to go for this?
<fabbione> trappist: what do you need from the kernel that you don't have already?
<trappist> fabbione: well if we're going to use patch-o-matic, there needs to be some agreement on which patches to apply.  if not, nothing at all, but we're using it now - or trying to - and I'd like some of those things kept in.
<fabbione> trappist: prepare a list and post it to kernel-team@lists.ubuntu.com
<fabbione> with everything that you think should be done
<fabbione> and how to do it
<trappist> can do, thanks
<fabbione> BenC: ping?
<rikai> later all , to bed with me o/
<BenC> pong
<BenC> fabbione: yo
<zul> hey
<fabbione> BenC: OCFS2 has been merged upstream by linus..
<fabbione> i am not sure if we want to start tracking it from there...
<fabbione> does git allow you branch per directory?
<zul> hey fabbione 
<fabbione> hey zul
<zul> congrats on the kid
<fabbione> thanks :)
<zul> scarey you are going to have your unholy army soon ;)
<fabbione> ehhe
<zul> argh why couldnt i type last night
<BenC> fabbione: nah, we'll just keep what's in our archive for dapper
<BenC> will be nice to remove it for dapper+1 though, and just track 2.6.17
<fabbione> BenC: we might have to update OCFS2 and RH anyway across the line.. i was only wondering if we could do it easily traking linus or not
<zul> oh crud...the abi changed
* lamont__ sends zul down to ABIs-R-US to get some more, just in case we run out.
<zul> bleah..
<zul> yeah the firefox download is working again
<fabbione> hahaha
* lamont__ netboots dapper/hppa for giggles
<lamont__>   | Choose a language:                                                      |   
<lamont__>   |                                                                         |   
<lamont__>   |                               C                                         |   
<lamont__>   |                               English                                   |   
<lamont__> so many choices.... hrm...
<BenC> lol
<fabbione> lamont: same on sparc..
<lamont__> it's the b0rken keyboard chooser udeb that's my current annoyance with dapper... must fix that
<fabbione> i think the issue is console-data udeb
<fabbione> does it build for you?
<zul> brb...new kernel
<zul> BenC: ok quick question if you are around why does adiran bunk make all of those functions in the kernel static?
<cjb> I think he gave his reason in the thread; because they reduce to a constant at compile-time.
<cjb> Oh.  He's not here.
<BenC> zul: allows the compiler more flexibility I think
<lamont__> BenC: did we get the ide stuff I needed turned on in 2.6.15 yet?
<lamont__> (hppa needed, that is)
<lamont__> remind me what it is that reads kernel-img.conf again?
* lamont__ sees that ns87415 is in the kernel.
<lamont__> and that ide bus walking isn't automatic
<lamont__> and that tulips don't autoconfig either
<lamont__> hda: CD-532E-B, ATAPI CD/DVD-ROM drive
<rikai> brb, installing memory <.<;
#ubuntu-kernel 2006-01-12
<infinity> mjg59: Hrm.  on-demand requency scaling seems to have broken in the latest kernel for my Pentium-M... In the middle of a nasty compile, sysfs still claims my current frequence is 800MHz (instead of 2GHz), and the compile does seem slow, so I don't think it's being misreported.
<mjg59> infinity: Can you force it higher manually?
<infinity> How?
<mjg59> Echo stuff into sysfs
<mjg59> I can't remember which file off-hand, I'm afraid
<infinity> (base)root@cthulhu:/sys/devices/system/cpu/cpu0/cpufreq # echo 2000000 > scaling_setspeed
<infinity> (base)root@cthulhu:/sys/devices/system/cpu/cpu0/cpufreq # cat scaling_cur_freq
<infinity> 800000
<mjg59> Interesting
<mjg59> What does /proc/cpuinfo say?
<infinity> 1995.800 MHz, 3994.36 bogomips.
<infinity> But it was lying in the last kernel revision too.
<mjg59> Which seems to suggest it's working
<mjg59> Oh
<mjg59> Hm
<mjg59> I've no idea which one to trust here
<infinity> (ie: cpuinfo always said I was at full speed, despite the speed going up and down, according to sysfs)
<mjg59> But something's plainly broken
<infinity> Oh well.  I'll have to bug you about it later.  Bedtime now.
<mjg59> Night
<zul> heylo
<zul> BenC: more crack for you..
<ds> BenC: you around?
<ds> BenC: I'm willing to do some hacking/testing for #20622 if you have suggestions
#ubuntu-kernel 2006-01-13
<bastl> hi, can i reuse an customized debian kernel in ubuntu? It was fairly complicated to get swsusp2 and acpi run on that laptop, and would _really_ like to reuse that kernel now when im switching to ubuntu ...
<crimsun> does the default Ubuntu kernel not suffice?
<crimsun> (yes, you can reuse it with a possible loss of functionality)
<bastl> no, suspend resume didnt work with the live cd.
<bastl> it is an samsung X10 laptop, with a buggy dsdt, i had to fix that with weird tricks
<crimsun> well sure, then just drop in your kernel and adjust /boot/grub/menu.lst, then update-grub
<bastl> fine, that's it already. welcome a new ubuntu user ;-)
<fabbione> suspend resume cannot work from live cd :)
<crimsun> I'm pretty sure it'd work from an installed base
<crimsun> lots of people put a tremendous amount of work to get suspend and acpi up to par for Breezy
<bastl> fabbione: it didnt even suspend ..
<bastl> but i will install it first ...
<zul> heylo
<pkern> Hm. Why does Ubuntu ship with usbmon.ko but without debugfs?
#ubuntu-kernel 2006-01-14
<mjg59> BenC: The latest dev_acpi from http://free.linux.hp.com/~awilliam/acpi/dev_acpi/ seems to build against 2.6.15 with a trivial fix (add a NULL to the call it bitches about)
<infinity> BenC: You actually alive?
<BenC> yeah
<BenC> barely
<infinity> BenC: I saw you assigning bugs to me, so I'm assuming you are.
<infinity> How do you feel about pulling in the new ipw2200 driver?
<infinity> Looks shiny.
<BenC> ipw2200 is stock kernel code right now...is there any benefit?
<infinity> Fixes several bugs, including a kernel panic.  Changes look mostly low risk.
<infinity> http://ipw2200.sourceforge.net/#news
<BenC> ok, I'll give it a look
<infinity> Oh boy, more AVM fritz crap.  How many drivers do these people need for their products?
<BenC> hehe
<infinity> We already ship 12...
<BenC> new you'd like that :)
<BenC> the USB id changed, they need a new driver for that
<infinity> If only you were joking...
<ds> how do I get a patch vs. upstream with the ubuntu packaging, other than creating one myself?
<BenC> not sure I understand the question
<ds> the linux-source package is debian-native, and contains no patch files that are applied to the source
<BenC> correct
<ds> I'm imagining myself creating a diff between ubuntu and linus and/or -11.16 and -11.15
<ds> and I'm wondering if there's an easier way than diff -urN
<BenC> easiest way is using the git repo
<BenC> are you trying to track down a bug?
<ds> yes
<BenC> read up on git-bisect, it will save you tons of time
<ds> #20622
<ds> link to the ubuntu git tree?
<ds> er, nm
<BenC> apt-get install git-core, and read the wiki guide in the channel topic
<BenC> then "man git-bisect"
<ds> oh bother.  I don't have a git tree currently downloaded
<BenC> it's about 110megs
<BenC> it's worth the download, git-bisect will save you days of tracking down when a bug was introduced
<ds> I'm familiar with git
<fabbione> morning
<fabbione> Benc: ping?
<cjb> Evenin'.
<Mithrandir> BenC: which modules are needed to access ieee1394 cdrom devices?  Just ieee1394 or ohci1394 as well?
<BenC> Mithrandir: and sbp2
<fabbione> hey BenC 
<fabbione> BenC: what happend to zachery?
<fabbione> she did left me in the middle of a OOo2 build
<Mithrandir> BenC: ok.
<BenC> fabbione: dunno, let me check it
<BenC> fabbione: should be up in about 30 seconds
<fabbione> BenC: ok thanks
<fabbione> did it crash completely?
<fabbione> or just went in go> state?
<zul> heylo
<BenC> fabbione: rebooted itself
<BenC> need to restart my sat modem too
<fabbione> is the connection going down?
<BenC> not right now
<BenC> if you start a screen'd session you should be ok
<fabbione> yup..
<fabbione> i am screened
<fabbione> BenC: can you just give me a few minutes to start OOo2 build again?
<fabbione> so i can just logout and forget about it for the next 24 hours modulo zacehry crashes :)
<fabbione> BenC: done... you can reboot the router any time.. OOo2 is munging :)
<BenC> ok :)
<fabbione> BenC: btw.. my U60 decided to live again
<fabbione> so now we have 2 buildds online for main
<fabbione> i will still need to use your for OOo2
<fabbione> i don't have enough local disk do it myself
<fabbione> otherwise we are all set :)
<BenC> cool
<mdke> hi, with kernel -11 my system stops at the "Detecting and Activating Hardware" stage. I can ctrl C out of it but nothing works. Is this known? Works fine with -9 kernel
<cjb> Works fine here.  I'm not one of the maintainers, but I suggest filing a full bug report.
<mdke> cjb, alright, I will look
<mdke> cjb, I've filed it at 22203, but it's not "full" by any means, I have no idea what info to attach
<cjb> That's fine.  Someone will let you know.
<mdke> cool
<mdke> thanks, bye!
<cjb> Turning off 'quiet' and 'splash' in the boot options would be good.
#ubuntu-kernel 2006-01-15
<zul> heylo
<zul> brb
<ds> is there a simple way to build only a subset of packages from linux-source?
* lamont screams at amd64
<lamont> with an amd64 kernel, and i386 user space, xsane fails to find the scanner - "device busy"
<mjg59> Yay 32-bit ioctl emulation
<mjg59> That stuff's always broken
<lamont> sigh.  any trivial way to find _which_ ioctl is b0rked?
<BenC> which is why I am hesitant to provide an amd64 kernel for i386
<BenC> lamont: check dmesg
<lamont> I suppose I could always use 2.6.15, eh?
<BenC> why not just use i386 kernel?
<BenC> or 64-bit userspace :)
<lamont> oh, yeah. plenty of them.
<lamont> i386 kernel --> double time rate
<lamont> iz mother board issue that's "fixed" in amd64 kernel, but not in i386
<BenC> use noapictimer
<lamont> that's only implemented in x86_64
<BenC> nah, it worked for my sempron notebook (32-bit k8) with -k7 kernel
<lamont> didn't work for  me.
<lamont> [  225.362891]  ioctl32(xsane:10063): Unknown cmd fd(8) cmd(c00c5512){00} arg(ffff88c0) on /proc/bus/usb/003/001
<BenC> weird, did for me
<BenC> well, you know it's a USB ioctl, just parse cmd to find which one (referencing usb ioctl headers)
<BenC> gotta run
<lamont> kernel          /boot/vmlinuz-2.6.12-9-386 root=/dev/sda1 ro quiet splash noapictimer
<lamont> like that, I wonder?
* lamont gives noapictimer another chance
<lamont> brb
<mjg59> noapic nolapic also ought to work
<lamont> mjg59: which should I use?
<mjg59> If noapictimer doesn't work, try noapic nolapic
<lamont> "noapic nolapic" or each one separately in turn?
<mjg59> Both parameters at once
* cjb wonders if he's the only person in the world running 64-bit userland.  :)
<lamont> mjg59: noacpitimer caused the machine to not boot.
<lamont> noacpi nolacpi gave me doubletime
<lamont> which gets me back to fixing ioctl's in amd64
<lamont> interesting... chrooting into an amd64 chroot doesn't fix it either...
* lamont wonders what all he needs to install in order to have a working breezy/2.6.15 system
* cjb has a working dapper/2.6.15 amd64 system, fwiw.
<infinity> Meh.
<cjb> lamont: Wait, you're seeing double-time?  Have you tried acpi_disable_pin_1, or whatever it's called?
<cjb> Oh, I see, you're seeing doubletime with noacpi.  I'm not helping, then.
<infinity> mjg59: Feel like thinking more about my scaling problem?
<infinity> for i in *freq; do echo -n "$i: "; sudo cat $i; done
<infinity> cpuinfo_cur_freq: 800000
<infinity> cpuinfo_max_freq: 2000000
<infinity> cpuinfo_min_freq: 800000
<infinity> scaling_cur_freq: 800000
<infinity> scaling_max_freq: 800000
<infinity> scaling_min_freq: 800000
<infinity> That would appear to be problematic...
<mjg59> Hm.
<mjg59> Wonder what scaling_max_freq means
<infinity> And for reference:
<infinity> scaling_available_frequencies: 2000000 1600000 1333000 1066000 800000
<infinity> So, it sees all the available frequencies, then sets the max to 800000
<infinity> AFAICT.
<infinity> Benchmarks seem to bear this theory out (it's slow as hell right now)
<mjg59> On 2.6.5-11, I've got scaling_max_freq: 1200000
<mjg59> Can you echo 2000000 to scaling_max_freq?
<infinity> That's on a 1.2GHz X40 though, right?
<mjg59> Yeah
<infinity> (base)root@cthulhu:/sys/devices/system/cpu/cpu0/cpufreq # echo 2000000 > scaling_max_freq
<infinity> (base)root@cthulhu:/sys/devices/system/cpu/cpu0/cpufreq # cat scaling_max_freq
<infinity> 800000
<mjg59> Right
<mjg59> Sounds Dothan specific, then
<mjg59> What cpufreq module do you have loaded?
<infinity> centrino.
<infinity> Same as always, afaik.
<mjg59> Can you stop powernowd, unload that and load acpi-cupfreq?
<infinity> Hrm.  How can I see what processes are using a module?
<infinity> (Can't unload speedstep_centrino, in use)
<mjg59> Are you still in /sys/devices/system/cpu/cpu0/cpufreq ?
<infinity> Oh, I could be that retarded...
<mjg59> Yay kernel refcounting
<infinity> Err, no.  Leaving did no good.  Still a refcount of 1.
<mjg59> You didn't cd there, su and then cd out, did you?
<infinity> No, lsof confirms I'm not that dumb.
<mjg59> Ok
<infinity> (base)root@cthulhu:~ # lsof | grep cpu
<infinity> nautilus   5407   adconrad   25r      REG        0,3        0 4026531851 /proc/cpuinfo
<mjg59> Hm. No, it seems I can't unload mine either
<mjg59> Bloody thing
<infinity> Not sure why anything would hold a handle open on /proc/cpuinfo, but that shouldn't matter, I hope.
<infinity> Go, git, go.
<infinity> (base)adconrad@cthulhu:~/kernel/ubuntu-2.6$ git pull
<infinity> [...] 
<infinity> rsync: link_stat "/scm/linux/kernel/git/bcollins/ubuntu-2.6.git/refs/heads/for-jgarzik" (in pub) failed: No such file or directory (2)
<infinity> rsync error: some files could not be transferred (code 23) at main.c(1173)
<infinity> Maybe I should just go back to bed.
<fabbione> infinity: no, you need to purge the tree and clone it again
<infinity> Yeah, I'm doing that.
<infinity> Which is pretty icky, given how much data that is.
<zul> heylo
<BenC> yo chuck
<zul> yo ben
<fabbione> BenC: ping?
<BenC> fabbione: pong
<fabbione> BenC: hey
<fabbione> BenC: did you ever try to boot one of the -server kernels on i386?
<fabbione> -11- goes foobar on me really badly
<BenC> yeah, I have a bug report about that
<fabbione> and i need it for the cluster modules
<fabbione> ok
<BenC> going to test -12 on my i386
<fabbione> ok thanks
<fabbione> BenC: we might also need to kill cmirror from our kernel tree
<fabbione> it's part of redhat-cluster-suite
<fabbione> i am talking right now with upstream...
<BenC> feel free, you know all the cluster stuff :)
<fabbione> yeah sure
<fabbione> it would also be nice to get ipv6 working on hppa
<BenC> it's not?
<BenC> is that a 32-bit userspace, 64-bit kernel issue?
<fabbione> module ipv6 relocation of symbol in6_dev_finish_destroy is out of range (0x3ffeff7c in 17 bits)
<fabbione> tons of this
<fabbione> 32bit kernel
<BenC> ah
<fabbione> i still need to try to boot a 64bit kernel on that machine
<fabbione> BenC: did zachery died again?
<fabbione> oh christ
<mjg59> "First Mac with Intel processor today."
<trappist> fellas I sent an email to the kernel-team list per fabbione's suggestion about building iptables against the source of the running kernel and haven't heard a peep out of the list since then.  is my subscription busted or does that list really not see that much traffic?
<cjb`> But it's an iMac.  :(
<cjb> I think they might throw in an Intel laptop as the "One more thing.."
<fabbione> trappist: the mail is there, do you want to give people sometime to read and think about it?
<fabbione> pushing won't help
<trappist> fabbione: not trying to push.  I just haven't seen *any* traffic on the list and was beginning to wonder if my subscription had gotten lost.
<zul> trappist: its a very very low volume list
<trappist> zul: that answers my question, thanks
<zul> there is also something about in ubuntu-devel mailing list..
<BenC> trapist: I saw it, but I'm no iptables expert
<Mithrandir> BenC: did you have a chance to track down any of the unionfs bugs?
<Mithrandir> on ppc
<BenC> Mith: I was hoping the new unionfs woudl fix it
<Mithrandir> BenC: I can enable unionfs for ppc again and we can see
<BenC> Mithrandir: is it still broken with latest daily builds?
<BenC> I'm willing to test it
<Mithrandir> I don't have a working PPC, so it's a bit hard for me to test it. :-)
<BenC> I have G4/G5 so I can test if it's enabled
<BenC> been meaning to test the new yaboot anyway
<Mithrandir> ok, assuming the next live fs build works ok, please grab tomorrow's live image and test it.
<BenC> sure thing
<cjb> BenC: So, replacing your obsolete PB with a MacBook anytime soon?  :)
<zul> BenC: did you have a chance to do a pull yet?
<BenC> zul: I tried a pull, but it didn't work
<zul> blah...ill look at it
<zul> when?
<zul> BenC: fixed i just did a pull from my tree..
<zul>  http://zulinux.homelinux.net/git/ubuntu-2.6.git
<BenC> ok
<zul> i dont know what happened apache must have gotten screwed up or something
<ds> mdz: there's a new release of swfdec out
#ubuntu-kernel 2007-01-08
<zul> morning
<kylem> morning.
<zul> BenC: ping
<BenC> zul: pong
<zul> BenC: it looks like there is a coupld of problems with xen 3.0.4 freezing, i think we should stick with 3.0.3 and backport the framebuffer stuff
<BenC> zul: sounds good
<zul> because basically all what 3.0.4 is framebuffer, kexec and ia64
<zul> http://lists.xensource.com/archives/html/xen-users/2006-12/msg00691.html
<zul> and then we can just use the patch for 2.6.19 from redhat
<zul> is there a way to mangle kernel-package so it overries the default names in the control file?
<kinema> I'm interested in a kernel patched with the d80211/devicescape/wireless-dev tree and was wondering if I would need to compile a custom kernel or if there might be something already availiable.
<BenC> kinema: I'm hoping to have it integrated with feisty soon
<mjg59> BenC: I sent you that patch and everything :p
<BenC> I know, I need to get it in there :P
<mjg59> Ha
<kinema> BenC: You are a truly wonderful person.
<kinema> Overworked and underpaid I'm sure.
<BenC> thanks, but mjg59 did all the actual work...I'm just the procrastinator who'll eventually integrate it with the kernel image :)
<kinema> Well then I retract my statement and redirect it towards mjg59.
<lifeless> BenC: ignore my question from the other day - my hardware is fucked.
<BenC> lifeless: excellent
<zul> BenC: you just collect the spew
<BenC> well, not for you, but for the bug
<lifeless> BenC: :)
<lifeless> BenC: dell are replacing the motherboard and ram today hopefully. So excellent for me too. :)
<Mithrandir> BenC: speaking of kernel patches, it seems like the console switching one that mjg59 talked about some time ago wasn't removed in the latest upload?
<BenC> Mithrandir: removed?
<Mithrandir> the patch was to remove some console switching calls on resume.
<BenC> I did add a patch that disabled the console handling by power-management
<Mithrandir> hmm
<Mithrandir> then why doesn't it appear to work on my laptop.
<BenC> It's in -5.7
<BenC> make sure you have -5.7 and not -4.6
<Mithrandir> ah, the laptop's still on -4
<Mithrandir> I'll test with the new kernel and bug you if it's not fixed there then. :-)
<BenC> -5.7 is where it went in
<Mithrandir> thanks.
<BenC> np
<kinema> BenC: Not to be pushy but when might we expect to see a d80211 enabled Ubuntu kernel, unofficial, prerelease or otherwise.
<mjg59> BenC: There still seem to have been some dropped ACPI patches
<BenC> not to sound vague, but when I get it done..I've no idea
<mjg59> BenC: The toshiba_hotkeys_over_acpi thing vanished
<BenC> mjg59: forward porting ACPI patches was ugly...I dropped a lot
<mjg59> BenC: It'd be good if you could email me with the list of dropped patches
<BenC> I'll add that one to the list of things to get back in
<mjg59> Otherwise it's almost impossible to figure out what needs forward porting
<mjg59> Some of them may have been merged, others might just fail to apply due to churn
<BenC> ok
<mjg59> Thanks
<mjg59> There's a decent amount of this stuff that still isn't mainstream
<mjg59> Which is a right pain
#ubuntu-kernel 2007-01-09
<zul> hey
<juano> hello, i was wondering where to find a how to, or beginner tutorial for kernel developing
<johanbr> juano: kernelnewbies.org
<macd> any ETA on the bug affecting more than one domU in edgy kernel?
<Mithrandir> BenC: btw, I still have to sysrq-k the usplash when resuming in -5..
<Mithrandir> it might be something else, but I don't think so.
<BenC> weird
<BenC> the code is now just like dapper/edgy
<Mithrandir> we can poke it at the sprint if nothing else.
<macd> any ETA on the bug affecting more than one domU (xen) in edgy kernel?
<fabbione> macd: stop asking every hour.. when zul is around ask..
<\sh> BenC: did you receive any bug reports regarding latest dapper kernel and boot problems with areca sata adaptors?
<macd> hey I saw people talking...figured I put it out there, its not like Im spamming.
<BenC> \sh: not that I recall
<\sh> 2.6.15-23 boots ok, but 2.6.15-27.48 or 2.6.15-27.50 is not booting at all...
<fabbione> macd: i told you to get in touch with zul
<Mithrandir> BenC: mind if I remove linux-source-2.6.19 from the archive as well as old ABI versions (say 1, 2 and 3)?
<\sh> hmm...which package delivers the very first menu.lst for grub? linux-image-* or grub?
<Mithrandir> it's written by update-grub
<Mithrandir> that is, d-i makes the first, I though
<\sh> Mithrandir: but update-grub should use a menu.lst which I can provide (I'm doing automatic installations) and I wonder why my provided menu.lst is overwritten every time
<crimsun> are your static stanzas outside the automagic kernel markers?
<\sh> crimsun: no..I removed quite and splash from # defoptions
<\sh> quiet ,-)
<zul> morning
<cjwatson> BenC: after Herd 2, could you please move isofs back to storage-core-modules? fs-core-modules is too fat to go on all the cdrom initrds
<BenC> cjwatson: ok
<cjwatson> BenC: thanks
#ubuntu-kernel 2007-01-10
* okaratas iyi geceler..
<fabbione> BenC: ping?
<fabbione> BenC: if you have a chance please test .20-5 on your PB 17". It OOPS here like hell
<fabbione> and it can't get to boot the machine
<fabbione> best part is that it you get dropper to busybox, but usb keyboard doesn't work..
<tepsipakki> BenC: bug 76341 is still there with 2.6.20-5
<tepsipakki> (Intel ISA PCIC probe: not found)
<fabbione> kylem: 
<fabbione>   CC [M]   ubuntu/fs/gfs/glock.o
<fabbione> ubuntu/fs/gfs/glock.c: In function 'gfs_glock_be_greedy':
<fabbione> ubuntu/fs/gfs/glock.c:1820: warning: passing argument 1 of 'schedule_delayed_work' from incompatible pointer type
<fabbione> this looks like a consequence of the INIT_WORK changes you did
<BenC> fabbione: fixing it
<fabbione> BenC: did you also look at the PPC bug?
<BenC> ppc bug?
<BenC> ah, I see
<BenC> are the daily cd's using -5 yet?
<BenC> fabbione: BTW, where is it oopsing?
<fabbione> BenC: yes they should.. right at the beginning.. before starting init
<fabbione> BenC: so boot without splash and quiet
<BenC> fabbione: can you give me some info on what/where the oops is?
<BenC> I may be able to fix it without downloading the ISO, and booting my wifes computer with it :)
<fabbione> BenC: i can't get anywhere to save it . so if you can wait for a picture..
<fabbione> i think the OOPS is storage related since it can't find root afterwards
<fabbione> that's all i could see
<zul> i so much dislike winter 
<kylem> we haven't really had one yet...
<zul> it was freaking cold waiting for the bus
<kylem> hmm, -12. /me makes a note not to go outside.
<BenC> heh, it just started feeling like winter here
<BenC> got down to freezing last night
* BenC is not looking forward to the weather in oslo
<zul> distro sprint?
<Mithrandir> BenC: it's not cold now. :-(
<Mithrandir> around 0C here ATM.
<Mithrandir> I'm hoping for snow, though
<zul> thank you el nino
<Mithrandir> it'd be nice with -5C, clear skies and crisp air.  And lots of snow.
<BenC> Mithrandir: I don't want snow mucking with my flights, so let's save that till after I leave :)
<Mithrandir> BenC: you forget we're used to snow here, so once it starts snowing, stuff slows down for half a day or a day, then life goes on.
<BenC> Mithrandir: Wish it were that way here...people seem to think that snow means "end of the world"
<Mithrandir> lack of snow means "end of the world".
<BenC> ppl here do not know how to drive in the snow too...the first day of snow, there's cars all in the ditches and wrapped around trees
<Mithrandir> oh, sure, first day is chaotic here too, but the next day or so, people are "oh, this snow thing, this is how it works".
<BenC> "I have a big expensive SUV, I can handle 60Mph through the snow"
<BenC> ok, so it's not just here :)
<zul> BenC: i dont know how to drive in the snow :)
<BenC> I do, 5mph and use neutral before breaking when your car is rear-wheel drive
<zul> first winter i was driving in canada i  winded up in a ditch with my wifes car in the middle of no where
<zul> $200 to get the car out of the ditch
<BenC> hehe
<Mithrandir> BenC: or just don't brake.
<Mithrandir> it's fun going through a winter in a hilly city with just about zero brakes on the bike. :-)
<BenC> Mithrandir: ouch...I remember trying to drive in the snow when I had a motorcycle...but that was flat...the hills must suck for a bicycle in the snow
<zul> my wife goes "wheeee!" whenever she starts to skid and freaks me out
<BenC> zul: lol
<Mithrandir> haha :-)
<grazieno> hi people, can you help me with this bug? https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/75935
<Keybuk> BenC: how are you on the subject of process execution in Linux/
<BenC> Keybuk: depends on the difficulty of your question
<Keybuk> I want to change argv[1] 
<BenC> so that it shows different in ps?
<Keybuk> yes
<Keybuk> the cmdline, fwict, is stored as a character sequence with \0 between the arguments
<Keybuk> ps just treats \0 as a space, therefore
<Keybuk> so if I write \0 over argv[1] , 2, etc. all I get in ps is "progname                              "
<Keybuk> where the number of spaces afterwards is equal to the length of the previous arguments
<Keybuk> normally this results in a blank line :p
<Keybuk> I can't seem to find a way to _shorten_ the cmdline
<BenC> I think sshd does this...it actually rewrites the command line
<BenC> Have you tried changing argc as well?
<kylem> Keybuk, try a newline?
<BenC> hmm, argc is on the local stack, not a pointer
<Keybuk> BenC: argc is just a local variable to the function isn't it?
<Keybuk> kylem: shows up in ps asa a ?
<BenC> Keybuk: Check sshd and see what it does. I remember this being a common issue for people the last time I search around for it
<BenC> and I think I used sshd's approach to do it
<Keybuk> doesn't just change argv[0] 
<Keybuk> it
<BenC> No, it changes the whole command line
<Keybuk> changing argv[0]  and shuffling up the rest of the command line appears to be well understood
<Keybuk> but decreasing the length of the command line seems to be a new one :p
<BenC> could be
<zul> cool i didnt know you could pipe in shell commands for cvs commits
<Keybuk> 18428 pts/9    S+     0:00 test              $
<Keybuk> ^ that's what I'm seeing at the moment :-/  the extra spaces are where I've written \0 over the remainder of argv
<Mithrandir> setproctitle, maybe?
<kylem> -ENOSYS
<kylem> :)
<thom> hrm, the setproctitle manpage says "Peter Wemm <peter@FreeBSD.org> stole the idea from the Sendmail 8.7.3 source code by Eric Allman <eric@sendmail.org>.
<thom> "
<thom> so there might be something useful there
<Keybuk> thom: I would guess that has the same code as sysvinit
<Keybuk> which seems to be all about increasing the space available by moving the environment up
<Keybuk> I want to do the opposite, I have arguments that I want to *hide* from ps :p
<BenC> Keybuk: Maybe move the environment down?
<Keybuk> BenC: doesn't seem to be a way to move the actual kernel pointer
<Keybuk> just the local stuff in the heap
* Keybuk wonders whether he can futz around in kmem <g>
<kylem> we could add a syscall if you really want
<Keybuk> note-to-self: ps is in procps, not psutils <g>
<kylem> heh
<Keybuk> HAHAHAHA
<Keybuk> W!NN0R!!!
<Keybuk> I used the "find some magic loop-hole/bug in the kernel source" trick
<Keybuk> it assumes that if the last character in cmdline is not NULL, that it's been overwritten/extended into the environment, so calls strlen() on it instead
<kylem> heh
<Keybuk> char *cmdline_end;
<Keybuk> cmdline_end = argv[argc-1]  + strlen (argv[argc-1] );
<Keybuk> *cmdline_end = '!';
<fabbione> BenC: is there any chance to get mol running on ppc before Norway? (including a kernel that can boot my PPC?)
<fabbione> otherwise i am going to have to install some ssh on MacOS
<BenC> fabbione: If you can get me a screen shot of the oops, I can probably fix it...and as for Mol, I can add that in now
<BenC> fabbione: gfs1 is broken...i fixed all the warnings, but the aio_read and aio_write ops are the wrong proto, and I can't see how to easily convert them to the new proto
<BenC> fabbione: gfs2 just uses generic ops for aio_read and aio_write, and for the read/write callbacks
<BenC> fabbione: I'm going to commit the fixes I have now, but the remaining two warnings need fixing, else gfs1 remains broken
<fabbione> BenC: i will take a pic tomorrow.. mol would be cool.. gfs1 i know.. it's a bitch and i am talking about it with upstream.
<_MMA_> BenC: I get random shutdowns at boot with the feisty -generic and -lowlatency kernels. What info is need in a bug report? Where can I look?
<BenC> _MMA_: are you passing panic= on the kernel command line?
<_MMA_> In menu.lst?
<BenC> _MMA_: Yes
<_MMA_> Ill look.
<BenC> _MMA_: Main thing is, edit the command line in grub's menu (no need to edit the menu.lst file), remove the "quiet splash" options and try to see what exactly is going on
<_MMA_> k
<_MMA_> It happens about 25% of the time. Ill try to notice but it happens so fast.
<Lure> Keybuk: this might help explaining: http://lightconsulting.com/~thalakan/process-title-notes.html
<Lure> Keybuk: hp-ux even has syscall to do it ;-)
<Keybuk> Lure: that's all about how to *increase* the argv area, so that you can write an arbitrarily long string into argv[0]  (and overwriting the rest of the args)
<Keybuk> I wanted to *decrease* the argv area, removing the process's arguments from the ps list
<Keybuk> so all that trick isn't needed
<Keybuk> writing " " or \0 over top of the arguments "works", but it means that ->cmdline is still
<Keybuk> /sbin/init\0\0\0\0\0\0\0\0\0\0
<Keybuk> which means ps displays that as
<Keybuk> "/sbin/init          "
<Keybuk> if the arguments are quite long, you can end up with two or three "blank lines" in the output of "ps ax | less"
<Lure> Keybuk: ok, you abuse is nice ;-)
<Keybuk> yeah, I trick the kernel into thinking that I've used the above trick by putting something not '\0' in the last char of argv
<Keybuk> so the kernel assumes that argv now runs into envp
<Keybuk> it deals with that by only returning argv[0]  in cmdline, and using strlen to calculate the length of it
<Keybuk> because argv[0]  is right (I'm not changing it), that is a neat trick to hide the arguments from ps <g>
<BenC> fabbione: I forgot that mol was in ubuntu/, but was disabled because it didn't build anymore..it builds not, but I need you to test it
<BenC> fabbione: Pushed if you want to test it. You should be able to install linux-headers and cd ubuntu/misc/mol/; make -C /lib/modules/$(uname -r)/build SUBDIRS=`pwd`modules CONFIG_MOL=m
<fabbione> BenC: that assumes i can boot a kernel....
<BenC> fabbione: have you tried -5?
<BenC> don't you still have an edgy kernel on there?
<fabbione> BenC: the last one i can boot is .20-1 or .20-2 IIRC
<fabbione> all the others after do oops
<fabbione> some at randoms
<fabbione> some constantly
<fabbione> i will check better tomorrow and let you know
<BenC> ok
<fabbione> worst case scenario we will cook up something the first evening in Olso
<fabbione> Oslo
<fabbione> i need to run skype on ppc via mol
<fabbione> that's all i need
<fabbione> anyway i am off for the evening
<fabbione> thanks dude
<BenC> np
<zul> later
<macd> zul_, the bug concerning more than one domU on xen, any status on that?
<Jerub> hi!
<Jerub> ubuntu feisty has the 'ipset' package, which currently requires rebuilding the kernel with a netfilter patch-o-matic-ng thingy.
<Jerub> I'm currently working on a dynamic firewalling project that requires ipset support to work efficiently, and it'd be really nice if I could just say, 'it works in feisty' instead of having to say, 'rebuild your kernel like this'.
<lifeless> Jerub: how stable is the patch ? 
<Jerub> lifeless: good question, I'm just going to have a look at the svn log
<Jerub> well, we run it in production and haven't had any problems with it.
<Jerub> svn log says there was a commit in October '06 for a bugfix, commit before that was May.
<Jerub> so it's not a fast moving target.
#ubuntu-kernel 2007-01-11
<Jerub> 2.2.9a is basically trunk, and is the package in ubuntu
<lifeless> so, please file a bug on the kernel source package (linux-source in launchpad)
<lifeless> BenC: ^
<lifeless> Jerub: I was hoping BenC would be around, but hes apparently not, and infinity is ill I think
<BenC> linux-source-2.6.X
<lifeless> ah-ha, da man is here
<lifeless> BenC: any chance of including this ?
<BenC> Jerub: send me the patch, or paste a link to it here
<Jerub> http://www.netfilter.org/projects/ipset/index.html
<Jerub> weird.
<BenC> I don't see a patch
<lifeless> Jerub: its in patch-o-matic
<Jerub> the main site for it looks down now
<Jerub> was up yesterday I thought
<lifeless> its in p-o-m base
<lifeless> I think
<BenC> http://www.netfilter.org/projects/patch-o-matic/index.html ?
<lifeless> http://www.netfilter.org/projects/patch-o-matic/pom-base.html
<BenC> which patch?
<BenC> iptbles "set" match?
<Jerub> that's the one
<BenC> maybe I'm being dense, but I don't see a patch, just a desc
<Jerub> you're right, I don't see a downloadable patch either
<lifeless> I'm digging a little
<BenC> brb
<Jerub> I have the patch we apply to our own kernels, but I'd rather make sure to use the current upstream on
<lifeless> is it not http://svn.netfilter.org/cgi-bin/viewcvs.cgi/trunk/ipset/ ?
<kylem> lifeless, that's the userspace tool
<lifeless> kylem: dang. I was hoping it wasn't ;)
<kylem> :)
* Jerub asks in #netfilter
<lifeless> Jerub: so I'm pretty sure that its in 'base' - but I dont know what tha tmeans
<Jerub> lifeless: I think it's accessable via the 'patch-o-match-ng' program
<kylem> this is by far the most convoluted piece of crap i've ever seen.
<Jerub> but as I'm not the kernel developer on my team, and he's in england, I'm not sure how to use it.
<lifeless> http://www.netfilter.org/documentation/HOWTO//netfilter-extensions-HOWTO-2.html#ss2.2
<lifeless> garhfuckle
<lifeless> http://svn.netfilter.org/cgi-bin/viewcvs.cgi/trunk/patch-o-matic-ng/patchlets/set/
<kylem> so, uhm, i don't see anything in here that requires patching.
<lifeless> theres a pom-to-patch program that may be useful
<kylem> it seems to be entirely standalone.
<lifeless> yay for modular code
<lifeless> kylem: you're looking at the netfilter kernel module now ?
<lifeless> Jerub: what you do is svn checkout the patch-o-matic-ng svn tree
<lifeless> Jerub: then run the pom tools to get a patch out, or apply it or whatever
<lifeless> Jerub: so I suggest doing that in pom2patch mode
<kylem> lifeless, as far as i can see, they would be able to provide an external module and just build against headers like others do.
<lifeless> kylem: you're the kernel guy ;). I'm just facilitating.
<BenC> [    0.072411]  Booting paravirtualized kernel on bare hardware
<BenC> sweet
<kylem> hot.
* kylem is happy, his bcm4318 is working reasonably well on 2.6.20-rc4.
<Jerub> BenC: I'll get that patch for you shortly.
<zul> hmm?
<zul> BenC: ping...which paravirt are you running?
<BenC> the stock 2.6.20 paravirt, but with vmware's VMI patches
<BenC> for some reason my vmware isn't causing this kernel to show that it's using vmi paravirt though
<zul> cool
<zul> there should be some xen-paravirt patches being sent to akpm soon
<zul> macd: i dont have the problem if im not using ioemu
<Jerub> okay, I've built the patch, took a bit of wedging
<Jerub> http://shiny.thorne.id.au/~stephen/set-2.6.20.patch
<BenC> Jerub: Hmm...not sure about this one...File a wishlist bug on linux-source-2.6.20 and attach this patch to it, and I'll review it more in the next week
<BenC> Jerub: Why would people need to build a new kernel for this?
<BenC> It doesn't touch kernel code, just adds a module, which can be built just using the linux-headers packages
<Jerub> BenC: I honestly have no idea.
<BenC> Jerub: Save yourself the trouble of the bug report, this can be packages and/or built separately from the kernel
<BenC> s/packages/packaged/
<Jerub> excellent.
<lifeless> Jerub: the motu team may be willing to do that for you
<Jerub> okay, how do I ask this of them? 
<Jerub> :)
<BenC> #ubuntu-motu? I think that's the channel
<zul> yep
<lifeless> thts the channel
* Jerub follows the yellow brick road.
<BenC> crimsun: ping
<crimsun> BenC: pong
<BenC> crimsun: I have small issue that I've been meaning to ask you about
<BenC> my HP dv5000 laptop with HDA Intel sound doesn't have very high volume
<BenC> I checked alsamixer and everything's max'd
<BenC> was the same with 2.6.17, and still the same with 2.6.20 latest git
<crimsun> BenC: realtek or conexant codec?
<crimsun> (head -3 /proc/asound/card0/codec* )
<BenC> Conexant
<crimsun> ok, that's the issue that Rich Johnson (nixternal) reported
<crimsun> it's supposed to be fixed in alsa-driver 1.0.14rc1, but alsa's git/hg trees lack sound/pci/hda/patch_conexant.c
<crimsun> so what needs to be done is to pull in that file and any necessary changes to sound/pci/hda/hda*.c
<crimsun> sorry, alsa hg -does- contain those fixes
<BenC> is there a quick way I can get the alsa tree?
<crimsun> but what takashi and jaroslav have pushed to linus does not contain them
<crimsun> hg clone http://hg-mirror.alsa-project.org/alsa-kernel alsa-kernel
<crimsun> and 
<BenC> I have mercurial
<crimsun> hg clone http://hg-mirror.alsa-project.org/alsa-driver alsa-driver
<BenC> I need also driver updates too?
<BenC> alsa
<BenC> was hoping it was just kernel :)
<crimsun> one sec
<crimsun> just -kernel
<BenC> ok
<BenC> crimsun: what do I need to shutdown to release the ref counts on the snd modules?
<crimsun> this should do it: kill $(lsof -t /dev/dsp* /dev/snd/*) && sudo modprobe -r $(lsmod |grep ^snd |awk '{print $1}') && sudo modprobe snd-hda-intel
<lifeless> fugly
<BenC> crimsun: Yay, I have loud sound!
<BenC> problem is, I rebuilt all of alsa to install it
<BenC> crimsun: Anyway you can isolate the patches needed for patch_conexant.c?
<crimsun> BenC: err, all of alsa (meaning -libs, -utils, too)?
<crimsun> BenC: well, you need patch_conexant.c for sure. I'll dig through some history and see if sound/pci/hda/hda* need to be patched (I vaguely remember some additional changes there)
<BenC> all of alsa-kernel
<crimsun> ah
<BenC> had to reset my mixer settings, so hopefully just the conexant changes wont affect that
<crimsun> ok, yeah, I'm positive the changes you need are restricted to sound/pci/hda/{hda*,patch_conexant.c}
<crimsun> git pull over a 56kbps is fun!
<BenC> hehe, I can get just the hda subdir for you if you want
<BenC> you might need the history though
<crimsun> hmm, some workqueue changes I'm not familiar w/
<crimsun> is
<crimsun> destroy_workqueue(bus->unsol->workq);
<crimsun> deprecated in favor of:
<crimsun> flush_scheduled_work();
<fabbione> BenC: booting ppc now
<fabbione> BenC: http://people.ubuntu.com/~fabbione/IMG_4054.JPG
<fabbione> this is the best shot i can get
<fabbione> it's a bit out of focus
<BenC> that's a hairy looking oops
<BenC> udevtrigger, with only two modules loaded, failed to allocate memory
<fabbione> i get that on -1- too now
<fabbione> WTF
<fabbione> this is random
<fabbione> now -5- is booting
<fabbione> after 10 attempts
<BenC> are the oopses always the same?
<fabbione> yes
<BenC> you might have to pass that one by benh
<BenC> is it stable once you get it booted?
<crimsun> BenC: 3 patches against current ubuntu-2.6.git sent to kernel-team@ ; the last (patch_conexant.c) is awaiting moderation
<BenC> ok, thanks
<fabbione> BenC: looks like it
<BenC> I'll let you know if that by itself fixes things up
<crimsun> ok, thanks
<BenC> fabbione: Must be a race on initialization for one of the kmem_caches to get setup
<fabbione> BenC: pushing to benh
<lifeless> hmm, I have no sound :(
<fabbione> lifeless: did you wash your hears? :P
<lifeless> new motherboard
<lifeless> ah, fixed it
<lifeless> reload the sound modules. 
<lifeless> possibly it would not have broken if I had rebooted when changing the motherboard
<fabbione>   * ubuntu/mol: Fixes to build again. Fabio owes me a beer.
<fabbione>     - GIT-SHA f57afa67e6410d9c3a21d3bf64fb4274c8d83bd2
<fabbione> BenC: you bet.. if it works :)
<fabbione> BenC: 
<fabbione> ubuntu/fs/gfs/ops_file.c: In function 'gfs_aio_read':
<fabbione> ubuntu/fs/gfs/ops_file.c:452: error: 'buf' undeclared (first use in this function)
<fabbione> ubuntu/fs/gfs/ops_file.c:452: error: (Each undeclared identifier is reported only once
<fabbione> ubuntu/fs/gfs/ops_file.c:452: error: for each function it appears in.)
<fabbione> ubuntu/fs/gfs/ops_file.c:452: error: 'count' undeclared (first use in this function)
<fabbione> ubuntu/fs/gfs/ops_file.c: At top level:
<fabbione> ubuntu/fs/gfs/ops_file.c:1739: warning: initialization from incompatible pointer type
<fabbione> the gfs_aio_read change you did needs to be propagated somehow to __gfs_read
<BenC> shut, I didn't mean for that to go in
<BenC> shit
<BenC> I'll fix it...it will compile, but it will still be broken
<fabbione> actually.. ok
<fabbione> is it enough to revert that bit?
<fabbione> or should i propagate the iovec.iobase as buf?
<fabbione> yeah broken i know
<fabbione> BenC: if it is the only line to revert, please leave it to me
<fabbione> i have a bunch of updates in progress
<BenC> sure
<fabbione> thanks
<fabbione> can i just push to people.. right?
<fabbione> it's only gfs1 stuff.. so don't worry.. it won't clash with other changes
<BenC> Sure, just follow the commit templates so the changelog gets update right
<fabbione> yeps
<fabbione> i doubt it will be ready before the meeting
<fabbione> i am hoping to give it at least a test
<fabbione> BenC: .20-6 looks good on PPC.. mol too
<fabbione> BenC: read the scrollback :)
<BenC> fabbione: No oopses from -6?
<fabbione> BenC: do you know if it's possible to run mol in a window instead of full screen? i can't get to switch back to X
<fabbione> BenC: apparently no
<fabbione> and still fighting with the network.. but that's probably just my setup
<BenC> fabbione: Somewhere in /etc/mol/ you can set it up to use an X window instead of framebuffer
<fabbione> BenC: ok cool
<BenC> I was switching between fullscreen framebuffer and X when I was using it though...not sure why it wouldn't work for you
<fabbione> how? alt+ctrl+f7 ?
<BenC> yeah
<fabbione> hmm
<fabbione> i will have to test that again
<zul> hey
<doko> hmm, my notebook doesn't boot anymore after installation of l-r-m :-(
<thom> doko: atheros? 
<doko> thom: yes
<thom> launchpad #76294
<doko> great!
<IDOIT> hi all
<IDOIT> i know that /dev/mem is an image of the physical memory ..
<IDOIT> but i couldn't cat /dev/mem > file
<IDOIT> it says Operationg not permitted .. why ?
<IDOIT> more specifically .. i can copy the first 1.1 MB of it (using dd)
<IDOIT> i'm using 2.6.15-27-amd64-generic
<IDOIT> sorry .. is it a specific ubunto issue or it's a Linux kernel issue .. googling for it didn't help
<pmjdebruijn> IDOIT, the Ubuntu kernel isn't heavily modified, so it's probably a generic Linux issue (but this is just an educated guess)
<IDOIT> pmjdebruijn: this is my guess too .. but cause googling for this issue showed that this operation could be done normally "cat /dev/mem" .. 
<pmjdebruijn> IDOIT, how is the example article dated?
<pmjdebruijn> IDOIT, wait, do your have root priviledges?
<IDOIT> yes
<kylem> what you can do with /dev/mem varies by architecture.
<IDOIT> i know that it's an image of physical mem
<pmjdebruijn> kylem, any clue why AMD64 is limited?
<IDOIT> and i got the same result from intel 32 and AMD64
<kylem> pmjdebruijn, probably so that you can only read the BIOS, but that is just a guess.
<BenC> wow, vmware has a mac beta
<BenC> crimsun: Those conexant patches worked for me
<lifeless> BenC: mac intel ?
<BenC> lifeless: I would bet it isn't for ppc
<tumbleweed> I'm getting no sound on ati-ixp audio after hibernation resume (in feisty)
<Nafallo> BenC: would it be helpful if I recompile the current git and use rt2x00 instead of rt2500-legacy?
<BenC> You can try, but it doesn't work for my rt2500 cards
<Nafallo> ah, you've already tried.
<Nafallo> damn. I was hoping they would have came farther with it :-/
<Nafallo> thanks anyway. I'll put it down a bit on the prioritylist then :-)
<BenC> VMI: Found VMware, Inc. Hypervisor OPROM, API version 3.0, ROM version 0.3
<BenC> VMI: ROM license 'Proprietary' taints kernel... inlining disabled
<BenC> Booting paravirtualized kernel on vmi
<BenC> sweetness
<kylem> no more crashes?
<kylem> ah.
<kylem> i see.
<kylem> :)
<BenC> had to add "acpi=off noapic" to get it to boot
#ubuntu-kernel 2007-01-12
<crimsun> BenC: excellent, thanks.
<crimsun> tumbleweed: I'm aware of certain atiixp issues, but I haven't had time to drill down any changesets due to work.
<tepsipakki> hmm, I don't see the new linux-source-2.6.15 in dapper-proposed
<kylem> they need to be approved first.
<tepsipakki> oh, ok
<tumbleweed> crimsun: thanks
<zul> morning
* BenC has a working kvm
<zul> how is it?
<BenC> it's pretty fast, but not with stock kvm in 2.6.20
<BenC> If the new patches don't make 2.6.20, I'll patch it up though
<BenC> we also need a new kvm package...Debian's is too old
<zul> i can possibly do one this weekend
<thom> gar, who thought calling it kvm was a good idea. KVM means something else entirely
<BenC> Kernel Virtual Machine :)
<Mithrandir> thom: somebody who thought they were funny, probably.
<BenC> or Keep Viable Monkeys
<zul> keep viably mamories?
<zul> er...mamories
<zul> i need more coke..
<zul> muhahah...its alive
<zul> xen-headers-2.6.19-1_2.6.19-1_i386.deb
<zul> xen-doc-2.6.19_2.6.19-1_all.deb
<zul> xen-image-2.6.19-1-generic_2.6.19-1_i386.deb
<zul> xen-image-2.6.19-1-server_2.6.19-1_i386.deb
<fbenites> hi! 
<fbenites> i am trying to debug a usb driver, somebody have any hints?
<fabbione> BenC: ping?
<BenC> fabbione: pong
<fabbione> hey dude
<fabbione> BenC: do you mind to slam the webcam i gave to you in the bag to Oslo?
<BenC> sure
<fabbione> BenC: if we can't get it working i will give it to my wife on her m$ box
<fabbione> so i can see my son when away
<zul> awwww.//
<fabbione> yo zul
<zul> hey fabbione how is it going?
<fabbione> not too bad and you?
* fabbione is about to test bluetooth on ppc
<zul> good no complaints
<fbenites> fabbione: which cam chip?
<fabbione> fbenites: it's a quickcam but the chip is not supported by the stock kernel driver and the external one is OOPS'orama
<fabbione> i don't recall the details.. it's a few months that i gave it to ben with no luck
<fbenites> chip which? Pixart Img. ones?
<fabbione> i don't recall the details
<fbenites> i am one that one... someone wrote a driver, but it can just get a picture and no v4l...
<fbenites> so i am trying to port it to spca50x but no success... get some strange errors
* kylem reminds himself he needs to write a v4l2 netwinder camera driver.
<fabbione> fbenites: i could get video out of it, but it was a pain
<zul> i still need a netwinder ;)
<fbenites> fabbione: v4l and mencoder is a good combination
<fabbione> fbenites: it was a kernel problem.. userland was fine
<fabbione> the usb part of that driver was crap
<fbenites>  ...
<fabbione> qc-usb-messenger-0.8.tar.gz
<fabbione> found it
<fabbione> this is was the external driver
<fabbione>         { USB_DEVICE(0x046D, 0x08F0) },         /* QuickCam Messenger */
<fabbione> usb uuid
<fbenites> ok, there is no spca thing for it...
<fabbione> fbenites: with all respect.. i wasn't lying
<fbenites> ?
<fbenites> i just check the gspa_core.c file, didnt found the device
<thom> gar, xen in edgy is causing kernel panics :(
<zul> thom: did you follow the instructions in the wiki?
<thom> yup
<zul> did you install the xen-ioemu?
<thom> and this is the first domu, so it's not #71348 
<thom> pretty sure i did, yeah
<zul> ah..
<thom> glad i have ilo on the box ;-)
<thom> yes, i do have xen-ioemu
<thom> right, can i make xen not autoreboot so i can actually _read_ the oops?
<zul> add noreboot 
<zul> 2.6.16 or 2.6.17?
<thom> using the 2.6.17-6-server-xen0 kernel
<thom> gonna try the 2.6.16 from xensource in a sec
<BenC> shitty part about kvm is that it doesn't yet emulate 32-bit real mode calls (like what bootsplash uses), so the liveCD aborts
<pmjdebruijn> BenC, that's nasty
<BenC> need that fixed
<kylem> hmm.
<BenC> alternate CD install went fine
* BenC forgot how crappy breezy install was compared to now
<zul> *sigh* dapper doesnt recognize the ethernet card
<ivoks> anyone tried kvm?
<ivoks> i get soft lockups on modprobe :/
<zul> talk to BenC 
<ivoks> i think problem is same as with xen
<kylem> he's on the phone, he mentioned you need a newer userspace kvm have you tried that?
<ivoks> no, it crashes on loading module, so i didn't get to the userspace :)
<kylem> ah.
<zul> does your cpu support kvm?
<kylem> is there a bug yet, i can look at it
<ivoks> yes
<ivoks> i will report it, as soon as i grab debug info
<kylem> thnx.
<ivoks> well, i'm going to crash it now, so brb :)
<ivoks> eh, only way i could grab it is with camera, it's 1 minute movie :)
<cjwatson> BenC: FYI, I have one of mjg59's Intel Macs now, so will start beating on it soon
<BenC> cjwatson: excellent
<cjwatson> BenC: mjg59 reckoned there was a webcam patch he'd sent to you that wasn't merged yet?
<BenC> Yeah, I have it in my inbox
<cjwatson> it really is an excessively sexy machine. my wife had immediate hardware-lust
<kylem> hahaha.
<BenC> hehe
<cjwatson> "so does he want it back?"
<ivoks> um... if you need macs for testing...
<ivoks> i think i can arrange a machine or two for testing
<BenC> ivoks: spread the love...I could use a mactel for testing too
<ivoks> ok, i'll let you know how it turns out
<BenC> ivoks: thanks
<ivoks> i don't like them :(
* kylem snickers.
<zul> heh mactel for everyone
<ivoks> well, not for everyone... for ubuntu :)
* kylem was going to buy a macbook but none of the futureshops in ottawa have the 2GHz/4M model
<kylem> and an ipw3945 now that i know the stupid atheros wireless is just a pci express card.
<zul> futureshop? ick..
<zul> why not the macstore?
<ivoks> looks like i'm the only one on planet who doesn't like macs :)
<kylem> zul, the macstore?
<kylem> ivoks, i don't like apple
<zul> ivoks: neither do i
<kylem> ivoks, but it's the cheapest smallest core2duo machine i can find
<cjwatson> the installer job seems considerably easier now that grub apparently works
<zul> kylem: gimme a sec
<ivoks> kylem: try toshiba satellite pro U200
<ivoks> 12"
<kylem> ugh, trashiba.
<BenC> cjwatson: grub working is a plus :)
<zul> kylem: mac group
<kylem> do they still have tilde in the wrong location?
<zul> group.ca/frame.html
<kylem> zul, where is it?
<zul> www.themacgroup.ca
<ivoks> kylem: yes :D
<kylem> sigh.
<zul> kylem: 950 gladstone
<BenC> I hate this keyboard that james bought for the 965 server in mountain view
<BenC> the pipe is below the "return" key, and the return key stretches up to where the pipe is supposed to be
<kylem> BenC, ugh
<BenC> so when I type "cmd | foo" I usually end up getting just command to stdout
<ivoks> nasty
<kylem> zul, hmm, it's cheaper by $10 than futureshop, but only claims to have 512M while the apple online store and futureshop both say it has 1G
<zul> ah
<kylem> jesus, what a shitty website.
<ivoks> toshiba_acpi is broken in 2.6.20 :/
<BenC> ivoks: I need to add the hotkey via acpi patch
<ivoks> oh, ok...
<zul> kylem: powermac is still too expensive for me from that store
<ivoks> kylem: there bug #78976 :)
<kylem> thanks.
<ivoks> movie is best viwed with xine :)
<kylem> ok, that helps.
<kylem> is VT enabled in your bios?
<ivoks> yes
<kylem> spiffy.
<Nafallo> ivoks: agreed. atleast for DVD-support :-)
<ivoks> Nafallo: well, this mpeg had some postprocessing; this results in very bad picture with gstreamer, but very nice with xine/mplayer
<kylem> ivoks, it looks like it hung the cpu.
<ivoks> kylem: maybe it's related, but i'm getting this all the time:
<ivoks> APIC error on CPU0: 40(40)
<ivoks> for both CPU0 and CPU1
<ivoks> brb
<adon> hi everyone! I managed to make my card (Hauppauge WinTV express work) I had to edit the /etc/modprobe.d/options file to set the type of the tunner. Does anyone know if there is a reason why it is not hardcoded to the kernel?
<adon> Actually is this the place to ask this question?
<ivoks> adon: there is a reason; one chip can have lots of diferent tuners
<zul> #ubuntu
<adon> zul: ok
<cjwatson> mjg59: have you noticed the CD on that Mac apparently spinning down ridiculously often?
#ubuntu-kernel 2007-01-13
<blufox> Why does my ubuntu kernel gives me a high latency with my firewire camera?
<blufox> In isochronous mode 0 format 7 ... a 120x240 sized image takes around 14ms to reach the user buffer :(
<blufox> IRC documentation of the Basler Camera states that the image reaches the kernel buffers in around 6 ms 
<blufox> where is it then spending rest of the time ? 
<blufox> a whopping 8 ms somewhere it is spending ?
<blufox> is there something wrong with the firewire stack as such or is it a scheduler context switch latency problem?
<blufox> BenC, any solutions?
<okaratas> hello
<BenC> zul_: ping
<okaratas> * Ping reply from BenC: 25.25 second(s)
<BenC> okaratas: "ping" in msg is just a way of saying "hey"
<BenC> my IRC client shows my network ping time :)
<okaratas> BenC, hm okey, sorry :)
<BenC> np
<okaratas> BenC, can you examine my software? it sends an sms about network situation by the cell phone that you plugged in com port..
<okaratas> :)
<okaratas> http://openusability.org/projects/nagiosms
<BenC> I wont have time till Monday, busy getting ready for distro sprint, taking care of things around here before I leave
<okaratas> BenC, hm okey
<okaratas> good modnay :)
<kylem> BenC, kvm -11 seems to be in feisty now.
<BenC> kylem: Debian dev is working on getting it into debian, so I think we'll sync with that when it's done
<BenC> nothing against your package...just less delta :)
<BenC> kylem: It'll need to remove the depends of kvm on kvm-source for our purposes
<kylem> k-o.
* kylem goes back to adding modalias support for parisc devices.
<BenC> kylem: Do you know if our 2.6.20 packages are even building on parisc?
<BenC> I haven't done any builds since 2.6.17 on my a500
<kylem> i don't think infinity finished bootstrapping.
<kylem> i might try to corner people one evening in oslo.
<BenC> beat them till they submit
<BenC> I mean, work with them in a converging manner so as to bring this to a promising conclusion
<kylem> ahha.
<zul> hola
#ubuntu-kernel 2007-01-14
<zul> BenC: ping http://lists.osdl.org/pipermail/virtualization/2007-January/001948.html
<zul> we might able to do it now
<zul> ill have to test
<BenC> Can you send me the actual patches?
<kylem> roq.
<zul> sure...
<zul> there is 20 of them though
<zul> heh it will break kvm though
<zul> BenC: http://zulinux.homelinux.net/ubuntu/xen-paravirt/
<BenC> 492k of patches :/
<kylem> ouch.
<zul> yeah fun fun...and breaking of kvm
<zul> and that is only domU
<BenC> touches 44 stock kernel files
<BenC> 42
<zul> heh its getting better
<BenC> zul: At first glance, I'll say this is a no go for our main git repo
<BenC> should be great for a feisty 2.6.20 domU in universe though
<zul> BenC: sure..
<zul> ill just stop what im doing ;)
<BenC> "KVM Paravirtualized OK"
#ubuntu-kernel 2008-01-07
<kraut> moin
<luis_1234> Hello! Please let me know if you plan to support more Ricoh Memory card readers in the next kernel version. I have an Asus laptop (A6500) and those card readers (Manufacturer : Ricoh) do not work with Ubuntu. 
<luis_1234> I would have same question with future webcam support.
<maks_> luis_1234: what is upstream status of those?
<luis_1234> What is an upstream status?
<luis_1234> How can I check that?
<maks_> fixed in newer kernel merged in -mm discussed in sublist..
<luis_1234> exuse me but I ask first time here I do not know what is -mm discussed sublist
<luis_1234> Do you have a website where I can check which hardwares you support in the next ubuntu kernel?
<maks_> boot it
<maks_> same goes with -mm kernel
<luis_1234> thanks
<maks_> otherwise check lspci output against driver
<luis_1234> I tried everything, I also read that there is a project on sourceforge.net to support Ricoh Card readers in notebooks
<luis_1234> but that project does not support mine yet.
<amitk> luis_1234: is there _any_ driver out there that supports your card reader?
<luis_1234> NO
<luis_1234> I mean none for any Linux
<luis_1234> I would just like to know if you plan to support more of those Ricoh memory card readers or you do not plan.
<maks_> any is a bold statement for a noob
<amitk> in that case, Ubuntu will not be able to get the hardware working. You should write to ricoh about providing a driver or providing kernel developers with specs to write one.
<luis_1234> ok, thank you. 
<luis_1234> Have a nice day!
<amitk> and based on your assertion, no Linux distribution will be able to get it working
<Kano> hi, when will be rc7 synced?
<lamont> rtg: I'll let you decide what to do with the hug-day mail blocked in kernel-team
 * lamont runs out the door for a bit
#ubuntu-kernel 2008-01-08
<TheMuso> Is there any reason why an -rt flavour of LRM wasn't built? It appears that lum -rt was built, but not LRM. Same with linux-meta, theres no -rt metapackages.
<crimsun> it looks like they're simply missing from debian/control:^Binary
<TheMuso> Right
<TheMuso> But theres likely more to it than that.
<crimsun> (I would guess simple oversight, but...)
<Kano> hi, what about 2.6.24-rc7? when will it integrated?
<mjg59> Some time between now and release?
<Kano> now would be better
<zul> *sheesh* is it done yet is it done yet?
<zul> TheMuso: have you opened a bug report about it yet?
<TheMuso> zul: not yet. Had other things to attend to.
<kraut> moin
<Kano> hi, is the hardy kernel based on rc7 or not? i only see a version change patch but no rc7 tag?
<thegodfather> Kano: it's in git
<Kano> but why without tag?
<Kano> there are tags for rc6 down to rc1 but no rc7 tag
<Kano> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commitdiff;h=f89772020e23642cc2eac6f6dfb84970139075cf
<Kano> thats a real funny commit...
<Kano> did somebody check the rt73 driver? i only have non working reports about it
<kraut> Kano: arrrrrr ;)
<Mithrandir> BenC_: any particular reason why TASK_IO_ACCOUNTING and friends are not enabled?
<BenC_> Mithrandir: not that I'm aware of
<Mithrandir> BenC: https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/157191 ; pretty please. :-)
<ubotu> Launchpad bug 157191 in linux-meta "please enable CONFIG_TASKSTATS, especially CONFIG_TASK_IO_ACCOUNTING" [Undecided,New] 
<BenC> Mithrandir: it could be the perf overhead of enabling it, but I'll check
<Mithrandir> 'k.  I wouldn't think it'd cause performance overhead unless anything actually looked for the data?
<shaya> I see a new version of lrm, but it doesn't have the new version of fglrx
<amitk> crimsun: Is there a minimal asound.state config that will work across different HW e.g. set PCM to 60%. The idea is to use this config as a starting step to debugging non-working sound.
<_MMA_> amitk: It might be best to email crimsun as his time on IRC is rather sparse lately. Just stepped down from MOTU council and his job is demanding.
#ubuntu-kernel 2008-01-09
<crimsun> amitk_: unfortunately, no.  I've often started by mv'ing /etc/udev/rules.d/85-alsa.rules out of the way so that on a fresh boot, asound.state isn't `alsactl restore`'d at all
<amitk_> crimsun: would it be that hard to create a minimal asound.state with fore example Master, PCM, Line In?
<amitk_> crimsun: the problem we are trying to solve is not having to 1. delete asound.state, 2. kill mixer applet, 3. rmmod driver 4. modprobe driver just to get a clean slate
<crimsun> amitk_: the cleanest slate that can be gotten is simply not to `alsactl restore` on boot
<crimsun> amitk_: even with a "minimal" asound.state, there's no guarantee said mixer elements are even enumerated :/
<amitk_> crimsun: we want to _try_ one step better. Instead of a clean slate, give 'em a minimal default that is known to work on majority of that HW
<amitk_> crimsun: I understand the codec wiring will dictate a lot of details, but surely everyone will have Master, PCM and Line In?
<crimsun> amitk_: nope, some emu10k-based ones don't
<crimsun> a lot of usb ones don't
<crimsun> for HDA, Conexant, Realtek, and Sigmatel should
<amitk_> will 3-4 such minimal configs cover 90% of the HW out there?
<crimsun> hmm, yes
<crimsun> I'm guessing that 90% of the HW will be PCI-based, with the vast majority being HDA
<amitk_> crimsun: so if we can have them pre-installed as say, asound.state.intel, asound.state.dell or whatever, we could ask the user to check if sound works with 'alsactl -F -f <path to asound.state> restore'
<crimsun> amitk_: yes, that is feasible
<amitk_> crimsun: it could even be exposed in the mixer applet UI
<amitk_> crimsun: I can try to come up with something for HDA, Realtek, Sigmatel stuff. Could you help with the USB, emu10k ones?
<crimsun> amitk_: I'm afraid I can't promise, but I certainly will try.
<amitk_> crimsun: ok... thanks Daniel. I will keep you posted on this.
<crimsun> amitk_: http://pastebin.ca/search.php?q=alsa-info&s=Search should help
<crimsun> amitk_: for some time, we've been accumulating pastebinned codec dumps
<amitk_> crimsun: great... this might prove handy
<Hasufin> ....imbrandon or zul around?
<Hasufin> ..........was looking for imbrandon's fatx module
<Hasufin> id rather try not and ...... well you know, recreate the wheel
<Hasufin> im just reading old irc logs
<Hasufin> tons of info :P
<Hasufin> themuse - yeah I have that
<Hasufin> but it was my understanding, he got the thing built
<Hasufin> and had it up on his website somewhere :)
<TheMuso> Hasufin: Ah ok.
<Hasufin> or they had a patch or something
<Hasufin> Ive been reading irc logs
<Hasufin> thanks for replying and looking that up btw -- I appreciate it
<TheMuso> Hasufin: Are you willing to build it for your kernel yourself?
<Hasufin> Yeah, I'll have to get into the wiki's and such
<Hasufin> I haven't built kernel modules since........ uh
<Hasufin> redhat 6.x/suse 7.x days
<Hasufin> or built a kernel since then
<Hasufin> hmm
<Hasufin> i think im going to have to do the exact same thing he did
<Hasufin> he has a test fatx image posted
<Hasufin> but doens't have the module source or anything so
<Hasufin> this will be a learning exercise :)
<Hasufin> i just realized something
<Hasufin> wrong srever/cahnnel
<Hasufin> Zul -- (or imbrandon) if you have that patch........ :) i'd appreciate if you pointed it to me.
<kraut> moin
<imbrandon> Hasufin: what kernel version are you looking for the patch for ?
<Hasufin> im on gutsy
<Hasufin> 2.6.22-14
<Hasufin> generic
<Hasufin> .............if you only knew what ive been thru tonight to get a damn dos boot disk modified :)
<Hasufin> well... a dos boot iso
<Hasufin> i didn't find a program to pull out a binary boot image off an iso....
<Hasufin> holy crap has it been heck :P
<Hasufin> anyways another story
<imbrandon> ok i have two diffrent patches, one for the kernel to run ON the xbox, and one to just run on gutsy x86 and read/write fatx filestsems
<imbrandon> i'm guessing you need the latter ?
<Hasufin> yes :)
<Hasufin> hard drive is getting read errors
<Hasufin> so I need to run ddrescue on it to get all my xbox stuff off it
<imbrandon> ahh, is it unlocked or locked ?
<imbrandon> this wont unlock the drive
<imbrandon> it has to be unlocked by the xbox or xbhdm
<Hasufin> why im doing the whole dos thing
<Hasufin> trying varios spare drives i have to see if they are lockable
<Hasufin> I have the password, etc
<Hasufin> so I can unlock it
<Hasufin> the drive just has a lot of bad sectors on it...... 
<imbrandon> ahh ok, do you have xbhdm ? ( btw mostly any modern ide drive can be locked )
<Hasufin> which is causing linux not to boot... or to install
<Hasufin> ....no i don't have that...
<Hasufin> what is it?
<Hasufin> i haven't seen it in any of the readme's 
<imbrandon> xbox hard drive maker , it is a custom linux boot cd, that has the fatx modules, xbox harddrive clone utils etc
<Hasufin> :P
<Hasufin> wow
<Hasufin> nice
<imbrandon> one  sec lemme find it
<Hasufin> I will google it
<imbrandon> is more what you need
<Hasufin> well yes
<Hasufin> that would help me not have to do the insmod.... mount rmmod thing on my desktop
<imbrandon> ok here is the link, its 100% legal etc, but you can only gget it via torrent
<imbrandon> http://www.torrentz.com/ec05e2c927a69699896a929d9c73eeacce07838d
<imbrandon> read the README with it, but basicly there is a shellscripot in that zip that will make a custom iso just for your xbox with the eprom backup from your xbox or hdd passord
<imbrandon> boot off that iso with your xbox hdd as the only drive attached ( and past this feel free to join me in #buntubox , we're getting a little OT for -kernel )
<imbrandon> zul, did you ever commit the fatx stuff to l-u-m ?
<voyo> hi there, anyone alive? need to ask about format of kallsyms
<blueyed> Is somebody not affected by bug 177713? How can I debug this?
<ubotu> Launchpad bug 177713 in linux "2.6.24-2: Regression with idle cpu cycle handling" [Medium,Confirmed] https://launchpad.net/bugs/177713
<mtretin> Can anyone help me figure out why ACPI support causes my IDE drives not to be recognized? 
<blueyed> mtretin: what do you mean with "not to be recognized"?
<mtretin> w/o ACPI support, using the AHCI driver for my hdd and PIIX driver for my cdrom, when the kernel says it probes ide0 and ide1 it picks up my drive as /dev/hdb - when I turn *on* ACPI support int he kernel this doesn't happen 
<mtretin> blueyed: but it it doesn't pick the drive up as /dev/srX either
<blueyed> mtretin: unfortunately I have no clue, but others might help you know better (with this info). Have you search for a bug about it on launchpad.net?
<mtretin> I've been google searching for about a week for something relevant, and there are a few fixes -- none of which have worked, I'll try laynchpad now
<maks_> did you check for /dev/sdX mtretin 
<maks_> above you speak about srX
<mtretin> maks_: yup, there's nothing but /dev/sda :( 
<maks_> mtretin: what's your config?
<maks_> are you using stock kernels
<mtretin> maks_: I've treid stock, custom rebuilds using stock sources, and rebuilds using vanilla
<maks_> 2.6.24-rc7 ?
<mtretin> 2.6.23.13
<maks_> 23 is a strange release i don't trust it much..
<mtretin> I'm meaning to try .24 (that's latest unstable, right?) but time keeps in slipping into /dev/null 
<maks_> we have test builds on the debian side i guess ubuntu too
<maks_> they should just install fine
<mtretin> maks_: I switched to Ubuntu hoping everything woudl work out of box, so, I'd love to install one - but what repository is it in? 
<maks_> trunk http://wiki.debian.org/DebianKernel
<blueyed> maks_: Thanks for the hint, I can use those images instead of building it from git myself to test if my regression is still there.
<blueyed> bleh. idle regression still in 2.6.24-rc7-686 from http://wiki.debian.org/DebianKernel
<blueyed> Is this enough to send it to the upstream bugtracker? (.config might be involved, so I'll include it of course)
<bullgard4> uswsusp (0.6~cvs20070618-1ubuntu2) gutsy; urgency=low; mjg59: "* Don't build s2ram. It's not sensible on Ubuntu." I understand 'sensible' = reasonable. What is the reason?
<mjg59> Because we use pm-utils
<mjg59> And, in earlier versions, acpi-support
<mjg59> There's no reason to provide multiple packages that do exactly the same thing
<mjg59> If it doesn't work out of the box, that's a bug
<bullgard4> Thank you very much for explaining.
#ubuntu-kernel 2008-01-10
<bullgard4> Is the following a correct definition of a kernel quirk? ""In the kernel, quirks are routines or variables you program to make hardware work that has abnormal or out-of-spec behavior."
<amitk_> bullgard4: that definition sounds right
<bullgard4> amitk_: ok, thank you.
<xivulon> mjg59 hi, did you have a chance to look at the suspend-to-ram issues with fuse filesystems
<Toma-> Im trying to track down the change to the Makefile in lum as to why the rtl8180 and rtl818x drivers were disabled...
<Toma-> (for hardy)
<kraut> moin
<Toma-> Hey, im trying to find the reason behind rtl8180 and rtl818x drivers being disabled in the Makefile for linux-ubuntu-modules in hardy
<Toma-> Its not mentioned at all in the changelog
<linuxboy> Hi
<linuxboy> I'm having issues booting a new IBM box
<linuxboy> with 1 CPU (4 cores) it is fine
<linuxboy> with more then 1, it hangs at Brought up 8 CPUs
<linuxboy> this is on a gutsy 64bit frech install
<asac> hmmm ... still no restricted modules package for 2.6.24 -rt?
<rtg> asac: working on it.
<asac> \o/
<_MMA_> rtg: Are you looking at the metas also? linux-rt and such?
<rtg> yes
<_MMA_> Thank you.
#ubuntu-kernel 2008-01-11
<greg-g> question: for a bug that affects the output of acpi on a certain laptop model (making power management impossible), should that importance be set to Medium of High?
<greg-g> The importance is set in 2 of the components (the two "owned" by System76) but not the linux-source-2.6.24 package
<greg-g> bug in question: bug 130739
<ubotu> Launchpad bug 130739 in system76-driver "Power Mangement Issues on daru2" [Medium,In progress] https://launchpad.net/bugs/130739
<greg-g> https://wiki.ubuntu.com/Bugs/Importance wasn't clear to me on this issue
<linuxboy> hi
<linuxboy> anyone around ?
<abogani> Anybody knows what happened to the vmplayer packages for gutsy?
<linuxboy> there never was one
<Keybuk> mjg59: my SD card reader works now \o/
<mjg59> Keybuk: What did you do?
<Keybuk> had a Dell engineer round to replace the motherboard of the laptop
<mjg59> Ah
<mjg59> Ha
<Keybuk> after much debugging, and finding out that other people with D420s had working readers, I restored the windows image of the disk
<Keybuk> and it didn't work there either
<Keybuk> quick call to dell tech support and they had an engineer sent round today who replaced the motherboard
<Keybuk> I have a new bug now :-)
<Keybuk> HAL mounts the partition twice :-)
<chuck_> nick zul
<Hasufin> well now I know zul's name :P
#ubuntu-kernel 2008-01-12
<AnAnt> Hello, what's kernel modesetting ?
<JanC> setting video mode in the kernel driver ?
#ubuntu-kernel 2008-01-13
<misc--> I have just compiled a custom kernel (one that needed to be patched so I can use linux vserver) and all was successful but when I boot it up it says that it can't find /lib/modules/2.6.22.15 directory, even though it exists. Any ideas?
<Joe__> need some help... broke my system so it doesn't boot, found this thread: http://ubuntuforums.org/showthread.php?t=613779&highlight=kernel+panic
<Joe__> says I need to use the liveCD(in there now) to reinstall the kernel... how?
<Joe__> please help... I need to reinstall the kernel using the liveCd... but I don't know how
<Ciusbet> hi there
<Ciusbet> are there someone here?
<Ciusbet> i have a problem with semaphores in unix
<Ciusbet> how can i unlink a semaphore using unix shell?
<laga> hi. what's the best way to get a kernel patch integrated into hardy? i've filed a bug in launchpad against linux-source-2.6.24, i hope that's correct :)
<Ciusbet> laga, do you know, how can i unlink a semaphore using unix shell?
<laga> Ciusbet: no, sorry
<Ciusbet> laga ok thx
<rtg> man lame
<Joe__> anyone alive in here?
<amitk> Joe__: it is a weekend :)
<Joe__> I kind of jacked up my system
<Joe__> searched for the error and was told I need to use the liveCD to reinstall the kernel... but don't know how
<somerville32> Well, this isn't a support channel, Joe__ 
<amitk> Joe__: try #ubuntu for support
<Joe__> yeah, tried... they don't answer questions... thanks anyway
#ubuntu-kernel 2009-01-05
<Hobbsee> is it intentional that all jaunty upgrades pull lilo in by default, due to the kernel?
<apw> Hobbsee, i am not aware of our dependancies changing specifically on lilo
<apw> yep, our specified dependancies have not changed from Intrepid to Jaunty
<apw> debian/control.stub:Recommends: lilo (>= 19.1) | grub
<apw> would we expect that form to force lilo on?  that sounds bad to me
<apw> (and wrong)
<Hobbsee> apw: well, I suspect it's a bug in intrepid upgrades too then
<Hobbsee> i'm not sure if it actually turns lilo on or not, but installing two boot loaders by a normal dist-upgrade seems...strange?
<apw> frankly i would expect them to conflict: with each other
<Hobbsee> they don't seem to (as that's what I'd expect too). how strange.
<apw> Hobbsee, as the kernel only recommends them surly that wouldn't ever install them?  do we not rely on the d-i at first install to have picked one, and normal upgrades to keep that one up to datge
<Hobbsee> apw: a dist-upgrade installs recommends for new packages by default, i think.  and the new kernel qualifies as a new (binary) package.
<Hobbsee> (it keeps the metapackages right, but the bit that recommends grub itself is actually the kernel image binary, which keeps changing)
<apw> Hobbsee, hmmm well that might allow it to install one or the other, but i would hope that it would only install recommends with 'or' in them if one was not already installed
<apw> i wonder if apt has changed behaviour somewhere
<Hobbsee> apw: indeed.  it would be odd that apt doesn't say "the second is installed, don't install hte first"
 * apw wonders if there is any magic in update-manager to solve this
<apw> that makes it feel like a bug, but a bug in the update
<Hobbsee> could be.  I didn't use update-manager
 * apw gets the source
<apw> Hobbsee, is your dual installed machine 32 or 64 bit?
<Hobbsee> apw: 32
 * apw notes his 32 bit Intrepid install has both installed
<apw> but his 64 does not
<Hobbsee> i clean installed intrepid today, then dist-upgraded it
<Hobbsee> got jaunty, and lilo installed
<Hobbsee> haven't rebooted it yet.
<apw> well i have a laptop here (32 bit) which was installed from the Intrepid final CD and only has official updates on it
<apw> and that also has both loaders installed
<apw> my other laptop installed from the amd64 CD image only has grub
 * apw is suspicious of the 32 bit installer now
<Hobbsee> did you dist-upgrade it?
<Hobbsee> oh, wait, i misread you sorry
<apw> nope this was a virgin install from a CD, and the most it has is -proposed enabled
<apw> always updated using update-manager
<Hobbsee> very strange.
<apw> proper user stylee, and it seems to be infected with both
<apw> yes it does have proposed enabled too
<apw> according to the logs in /var/log/apt, it was installed in the initial install burst
<dholbach> hello my Kernel friends!
<dholbach> who of you would like to give a session at the next Ubuntu Developer Week? something about module packaging with DKMS maybe?
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep
<dholbach> is the preliminary schedule
<Keybuk> Thought of the day:
<Keybuk> what happens if init calls clone() with CLONE_PARENT? :p
<dholbach> hey Keybuk
<mjg59> Keybuk: Looks like failure
<dholbach> Keybuk: you could give a session about upstart at Ubuntu Developer Week - what do you think?
<Keybuk> mjg59: the clone() doesn't look like it'll fail?
<Keybuk> but it looks like if that process exited, lots of things assume that real_parent is not 0?
<mjg59> Keybuk: Right
<mjg59> Hence, failure :)
<Keybuk> in fact, it looks like there's lots of -> after that ;)
<Keybuk> definitely a "don't do that, then"
<mjg59> I think it's assumed that anyone writing init can already DoS the system whenever they want to
<apw> Keybuk, i concur with your analysis, bad karma will result from that
<apw> i suspect a very simple fix is possible, and probabally desirable
<Keybuk> *shrug* I tend to agree with mjg59 here ;)
<Keybuk> very few people write init daemons, and those who do already need to know about various special behaviours
<apw> i tend to be suspicious of anything which allows user space to blow the kernel up
<apw> yeah you are already winning if you can run init, but hey
<Keybuk> I can blow the kernel up from init easily ;)
<mjg59> exit(-1)
<Keybuk> just one function call ... exit()
<apw> yeah i know, but that is 'deliberate' it is designed.  this is a blammo, they are unsatisfactory at best
<apw> i am sure linus would agree with you
<dholbach> BenC: would you like to give a session at the next Ubuntu Developer Week? something about module packaging with DKMS maybe? :)
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep is the preliminary schedule
<dholbach> it'd be nice to have something like a "hands on" session where people could get involved in the kernel team somehow
<BenC> dholbach: I did dkms last time :) you want a new topic?
<dholbach> BenC: I could imagine that it's still interesting - if you have something better ... sure :)
<dholbach> pgraner: you could give a session about "mass-testing kernel fixes" :)
<BenC> dholbach: ok, If I don't come up with something better, I'll do dkms
<dholbach> BenC: will you just grab a slot on there?
<BenC> dholbach: ok
 * dholbach hugs BenC
<dholbach> you ROCK :)
<BenC> dholbach: no YOU rock!
 * dholbach looks forward to seeing everybody in Berlin soon
<Nafallo> you both rock... now, where's the fire? ;-)
<dholbach> Nafallo: eh? :)
<Nafallo> two rocks (stones) should lead to fire ;-)
 * dholbach is too slow today :)
<dholbach> BenC: which slot would you like to have? we can always change the session title afterwards
<BenC> dholbach: late on a Friday is good
<dholbach> 20 UTC? 19 UTC?
<BenC> dholbach: 19
<dholbach> BenC: alright, I'll add you to it
<BenC> dholbach: thanks...still catching up on email
<dholbach> BenC: same here :)
<dholbach> BenC: added
<alex_joni> can I use ppa to build custom flavours for a kernel?
<_MMA_> alex_joni: A custom kernel? Sure. I couldn't tell you how though. :P
<abogani> I can confirm it.
<alex_joni> abogani: can you then build other packages that depend on that kernel (e.g. with installed header files) ?
<abogani> alex_joni: I have done that job for rt kernel, headers and rt-tests packages without problems.
<rtg> tmiller0
<alex_joni> abogani: cool, that's nice to know
<alex_joni> one day I might bug you about details (if I can't figure it out ;)
<abogani> alex_joni: I think that you'll do it without problems and without any helps. ;)
<johanbr> Would it be possible to go back to building pcspkr as a module? The only 100% reliable way I've found to get rid of the noise is to blacklist the module.
<rtg> johanbr: I believe it is being built as a module: CONFIG_INPUT_PCSPKR=m
<johanbr> really? hmm... then my blacklisting stopped working for some other reason
<johanbr> it stopped working when jaunty rebased to 2.6.28
<johanbr> I assumed it was due to the "stuff more stuff into the kernel" move.
<zackr> are any of the people maintaining the lpia kernel online?
<rtg> zackr: that is sconklin
 * sconklin ducks
<sconklin> zackr: the mobile group has a tree for their work, and I'm in the process of bringing it into our main tree. What do you need?
<zackr> sconklin: ah, great. i have a machine with jaunty here and need to test a driver on 2.6.28, "fakeroot make-kpkg --initrd kernel_image" fails with "debian/ruleset/misc/checks.mk:36: *** Error. I do not know where the kernel image goes" is there any quick way of compiling 2.6.28 lpia package ?
<sconklin> zackr: oh, that's out of my knowledge base since I don't actually *build* those kernels yet, and everything we have for lpia is based on Hardy. But hold on a sec and let me see if I can find someone who should know.
<zackr> sconklin: that'd be great, thanks
<sconklin> zackr: still looking
<sconklin> zackr: so I understand - you want to cross-compile, this is not a native build, right?
<zackr> sconklin: no, it's a native build. i just want to have 2.6.28 lpia packages
<sconklin> ok, just making sure
<sconklin> zackr: You have to build it in a chroot, and here's a procedure for setting up that chroot environment: http://lwn.net/Articles/247003/ - I tried s/gutsy/intrepid/ in those instructions (on an intrepid host). I don't have a jaunty machine at the moment to make sure it also works for jaunty.
<zackr> sconklin: i'm a little confused. i have a lpia system running ubuntu already, i just wanted to compile new kernel on it. what would chroot give me in this case?
<sconklin> zackr: Sorry, I left out the important bit.  No one I talked to does native builds, they are all done on other archs as chroot.
<sconklin> but it should work
<zackr> sconklin: could you ask the person who's building the lpia kernels to write up a procedure for building a new kernel? in particular the make-kpkg line
<sconklin> zackr: the lpia kernels in the chroots are build using "fakeroot debian/rules <target>", so I don't think make-kpkg has been used or tested. Another option that was mentioned is to use a launchpad PPA to build them, but that's not really what you asked for at all.
<zackr> sconklin: ok, and what <target> are you using on those then? on my lpia machine "fakeroot debian/rules lpia" returns exact the same error as make-kpkg which is "debian/ruleset/misc/checks.mk:36: *** Error. I do not know where the kernel image goes to [kimagedest undefined] ...", so it looks like there's some patch to the debian/ that you guys are applying before building those kernels
<sconklin> zackr: that's possible. all my time has been spent looking at hardy, and there may have been something missed in Jaunty. Give me a few mins to have a look
<zackr> sconklin: thanks. btw, i had the same problem on hardy. essentially the question is how to get debian packages for either git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git on hardy or linux-source-2.6.28 if running jaunty
<sconklin> zackr: you can look at the current (hardy) lpia tree as easily as I can - it's here:  git://kernel.ubuntu.com/mid-team/hardy-netbook.git
<sconklin> That's what I'm doing now.
#ubuntu-kernel 2009-01-06
<junior_payne> does a kernel bug qualify as development discussion?
<crimsun> yes
<crimsun> (support for it, on the other hand, is a slippery slope)
<junior_payne> getting buffer I/O errors and end_request errors on my dvd any ideas on what could cause it? it's a sata drive using the sata_nv module I belive.
<junior_payne> example:
<junior_payne> Jan  5 18:55:53 quantum kernel: [79454.205582] end_request: I/O error, dev sr0, sector 684956
<junior_payne> Jan  5 18:55:53 quantum kernel: [79454.205592] Buffer I/O error on device sr0, logical block 171239
<junior_payne> it's not drive specific either. happens on both optical drives.
<junior_payne> I read other bug reports on similar cases but they were resolved and the workarounds didn't work for me. I was just wondering if there is some code I can look at to see if I could identify the problem.
<TheMuso> /c/c
<EtienneG_home> is there away to get SysRq on the console instead of syslog?  (for case when syslog is dead)
<EtienneG_home> or does it only work with serial console?
<Keybuk> how do I "git pull", but only up to a certain commit?
<soren> Do you have local changes?
<soren> I.e. will the pull involve a merge?
<soren> Keybuk: ^
<Keybuk> soren: no
<Keybuk> git fetch
<Keybuk> git reset --hard sha1
<Keybuk> seemed to work
<soren> Exactly what I would have done. :) If I needed to merge local changes, I think I would have had to create a new branch, do the git-reset trick there, and merge from that.
 * soren really finds git to be a hassle.
<Keybuk> it's just as hard to do that in bzr
<Keybuk> so I'm not complaining ;)
<Keybuk> anyone feeling brave?
<Keybuk> http://launchpadlibrarian.net/20947618/udev_136%7Egit%2B34ac42b-3_source.changes
<Keybuk> udev 136 now in my PPA :p
<soren> Keybuk: Should we update all packages shipping udev rules to put them in /lib/udev/rules.d, then?
<soren> Guess so.
<Keybuk> soren: I suspect it'd be easier to update dh_installudev
<Keybuk> but yes, in general
<Keybuk> since the rules file format has changed slightly, all packages at least need to be checked
<apw> they have changed the udev file format, what is with udev
<apw> Keybuk, ok i've got a patch to add modalias love for mmc
<Keybuk> apw: Kay's POV is that only distributors ship udev
<Keybuk> so it's better to make improvements and fix issues than retain backwards compatibility
<soren> Keybuk: Oh, the format changed? Are the changes listed somewhere?
<Keybuk> NEWS file, as usual
<Keybuk> the basic change is that things you probably tried to do before that didn't work now do
<Keybuk> ie. NAME=="a*", NAME=="*b" is now valid
<Keybuk> (previously it would only use one of those matches)
<Keybuk> also NAME="foo" is no longer special cased to be non-overridable
 * apw swears at the jaunty kernel
<apw> seems we have some nice little dri lockup in it
<cjwatson> anyone have a clue which device in https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/314175 corresponds to the CD drive?
<ubot3> Malone bug 314175 in debian-installer "Fujitsu U820 Hard Disk not detected by the installer" [Undecided,New] 
<rtg> apw: all of the DRI stuff is back to being modules, right?
<cjwatson> err, sorry - the hard disk I guess
<cjwatson> I thought it must be 8086:811a, but that module is available in the 8.10 installer unless I'm completely on crack
<apw> rtg it was a module yes in the kernel i was testing against, 2.6.28-4
<apw> i have booted it twice and twice had X lock up on me after about 10 mins
<apw> second time i got to login remote and found X sleeping and repeatedly trying to ioctl the dri deive
<apw> i guess i'd better file a bug on it
<soren> Keybuk: Yikes. All those "Removing obsolete conffile /etc/udev/rules.d/foo" are scary :)
<rtg> cjwatson: that ID is served by pata_sch.c --> debian/config/i386/config:CONFIG_PATA_SCH=y
<soren> Keybuk: Do you have a list of stuff that needs to be fixed along with the udev update?
<Keybuk> soren: nope
<soren> Keybuk: Ok.
 * soren makes a list
<Keybuk> anything with /etc/udev/rules.d in its contents
<soren> update-grub for instance, calls /sbin/vol_id, but that's gone now.
<soren> I somehow doubt it's alone.
<soren> Hmm... I suppose we could just (sort of) fix that now by pointing it at /lib/udev/vol_id, but its syntax (both output and arguments and such) is subject to change, isn't it?
<Keybuk> err, did I drop /sbin/vol_id? :P
<Keybuk> that's probably a bug :p
<soren> Oh. :)
<cjwatson> rtg: right, but that's present in 8.10 which the reporter is using
<rtg> cjwatson: how can you tell that he's using Intrepid?
<soren> rtg: cjwatson just knows.
<soren> He's like that.
<cjwatson> rtg: he says at the top. "This is during a netboot over internet installation of intrepid."
<rtg> ah, he says it in lower case :)
 * cjwatson accepts linux-backports-modules-2.6.28 binaries
<rtg> cjwatson: pata_sch is in d-i/pata_modules. would being a net boot have any affect?
<cjwatson> pata-modules is fetched by the installer once the network is up
<rtg> thats what I assumed.
<cjwatson> it's not in the initrd but otherwise it should still work perfectly well for netboot (if this didn't work, netboot wouldn't recognise *any* hard disks)
<Keybuk> rtg: it looks like changing to CONFIG_LEGACY_PTY_COUNT=0 alone gives us ~1.6s
<rtg> Keybuk: is there a graceful way to disable initramfs?
<Keybuk> rtg: don't put an initrd on the grub command line?
<rtg> Keybuk: so, you just comment out the menu.lst entry?
<Keybuk> rtg: yeah, or press "d" at the grub boot menu
<rtg> what about the volume ID problem? I had to specify the root as a /dev 
<cking> rtg: some insight on why root=UUID=xxxx does not work would be useful :-)
<cking> ..I was just thinking the same thing a moment ago
<rtg> cking: thats kind of what I'm asking. why doesn't the kernel know the volume ID by the time it attempts to mount the root device.
<rtg> is there something in the initramfs that trigger UUID functionality?
<cking> rtg: I just grabbed your no initramfs git tree and was going to put some debug in to see why it was failing
<Keybuk> I don't think the kernel supports root=UUID=
<rtg> cking: we're still building an initramfs, its just that there are fewer modules that go into it.
<rtg> Keybuk: isn't that kind of a sticky problem?
<cking> Keybuk: This is what I find a mystery: cat /proc/cmdline 
<cking> root=UUID=302714e7-5fcd-4db3-b0dd-c17d36bc7696 ro quiet splash
<Keybuk> it's a SMOP
<rtg> SMOP --> sticky problem
<Keybuk>                 case $ROOT in
<Keybuk>                 UUID=*)
<Keybuk>                         ROOT="/dev/disk/by-uuid/${ROOT#UUID=}"
<Keybuk>                         ;;
<Keybuk> (from the initramfs init :p)
<cking> Ahah
<cking> No wonder why I could no see how the kernel was parsing this
<rtg> cking: so the info is there, we just need to map it
<Keybuk> ugh
<Keybuk>                 /dev/nfs)
<Keybuk>                         [ -z "${BOOT}" ] && BOOT=nfs
<Keybuk>                         ;;
<Keybuk> who did _THAT_ hack?!
<mjg59> The kernel, 15 years ago
<Keybuk> eww
<mjg59> root=/dev/nfs was always supported
<cking> rtg: "we just need to map it" - err.. surely not in the kernel?
 * cking needs some strong coffee
<rtg> cking: where else? the kernel is the only thing up at that point, assuming no initramfs.
<cking> rtg: ..grub?
<cking> ..but that would be really perverse
<rtg> cking: I guess. grub has to be able to read the root device in order to boot.
<apw> but the kernel is what makes up the notion of a uuid in the first place
<cking> apw: err. true, but grub can do the mapping for most file systems too - I kind of think it's better to do it in the kernel though
<rtg> cking: I agree. if you do it in grub 1, then you'll have to do it again for grub 2
<cking> rtg: is the "if you do it" a SMOP for me? :-)
<rtg> cking: aren't you already busy?
<apw> actually it seems udev is responsible for the mapping, in userspace
<cking> rtg: ..always :-)  
<rtg> apw: but udev isn't up at that point
<cking> apw: yeah - the udev has a library that does a UUID mapping library which I coerced into grub
<cking> s/does a/has a/
<apw> very tricky all over
<apw> why _is_ initramfs so damn slow
<rtg> apw: thats rhetorical, right?
<apw> a bit of both, half a second just for an empty one is mad
<rtg> I suppose it takes a bit for busybox to launch
<Keybuk> define slow
<apw> half a second
<Keybuk> what is half a second?
<apw> it was quoted at UDS as something we want to stop using if at all possible
<Keybuk> where are you starting and stopping the clock? :)
<apw> because it has a half second overhead even if its emptry
<apw> sadly it wasn't me, thats why i am wondering why its such a problem
<Keybuk> for me, the time between the first and last line of initramfs (as near as damnit, anyway) is ~3.6s
<soren> Keybuk: New udev drops me at a initramfs prompt.
<apw> and why is it 3.6s
<soren> Keybuk: I'm still trying to work out why.
<Keybuk> soren: debug for me ;)
<apw> and more how much of that would need to be done after initramfs either way
<Keybuk> apw: 70-80% of initramfs time is spent in udev
<apw> so we can ignore that right?
<Keybuk> modprobe, bus scans, waiting for the root disk to show up, etc.
<apw> as we will have to run it in real root once we get there
<apw> if its not done already
<Keybuk> right
<apw> so, the real question is how much is done in there which is pointless
<apw> i am sure it was the 5 s boot guys at plumbers who said "half a second even if it is empty"
<soren> Keybuk: Ah, got it.
<Keybuk> soren: missing /sbin/vol_id? :p
<soren> Keybuk: You'd think so, wouldn't you? :)
<soren> No cigar.
<Keybuk> oh
<soren> /usr/share/initramfs-tools/hooks/lvm2 does:
<soren> cp -p /etc/udev/rules.d/85-lvm2.rules ${DESTDIR}/etc/udev/rules.d
<apw> rtg, have you got a boot time comparison for booting without an initrd time wise?  overall from bios to login?
<soren> At that point, there is no etc/udev/rules.d, so it's created. As a file.
<soren> Boom.
<rtg> apw: just anecdotal from pitti
<rtg> shaves approc 20 seconds
<Keybuk> soren: ah :)
 * apw worries about all the effort UUID in the kernel would be, if nothing would be saved
<cking> apw: I tried it today on a dell with an SSD, and saved ~8 seconds without initramfs
<Keybuk> soren: that should be /lib/udev/rules.d of course
<apw> cking, and any idea why it saves 8s ?
<rtg> apw: and thats without readahead
<soren> Keybuk: Well, yes. As a transition, the udev hook file should probable create the etc/udev/rules.d directory, though.
<cking> apw: less modules to load I suspect.
<apw> so you did more than add an initrd, you built extra things in?
<apw> thats all backwards, but you get my drift
<soren> Keybuk: Until we've fixed everything else to use /lib/udev/rules.d, this is going to blow up in our face, I think.
<Keybuk> soren: I disagree
<cking> apw: I took rtg's kernel https://lists.ubuntu.com/archives/kernel-team/2009-January/003987.html
<Keybuk> it's far easier to find the broken things if they break
<Keybuk> otherwise they'll just break later when we remove the transition
<cking> apw: The BIOS is the major time waster now :-)
<apw> so thats  comparing a stock to one with lots built in and no initrd
<apw> so its not really an apples with apples comparison
<Keybuk> actually
<Keybuk> interestingly
<Keybuk> there's no discernible difference in the kernel start time between everything built-in and everything a module
<apw> that is conflicting information from two sources
<Keybuk> you are free to replicate my test ;)
<soren> Keybuk: I don't see why we'd be more willing to break and fall apart in initramfs than outside of it. Once the system is running, udev deals fine with stuff in /etc/udev/rules.d. If anything, we should be more accepting in initramfs. Failure to boot is worse.
<Keybuk> soren: VERY few things should be installing rules into the initramfs
<Keybuk> those that are should definitely be fixed to use /lib anyway
<Keybuk> you'll note that udev doesn't really install any rules itself anymore
<soren> Keybuk: YEs, I noticed.
<cking> apw: I suggest you try the experiment yourself.. it won't take long .
<soren> Keybuk: There is one problem, AFAICS, though.
<soren> Keybuk: Ah, no, we can work around that.
<Keybuk> soren: what problem?
<soren> Keybuk: I was thinking that we'd need to make a hard, versioned dependency between lvm2 and udev, because older udev versions wouldn't work with rules in /lib/udev/rules.d, and lvm2 wouldn't allow me to boot until it's moved to lib/udev/rules.d, but I guess in the meantime we can just make lvm2 create the /etc/udev/rules.d directory in the initramfs.
<Keybuk> actually, it will need a hard version anyway
<Keybuk> it doesn't depend on udev at all, no? :p
<Keybuk> which is a mistake
<Keybuk> it inherently has the hard dep because of the split out of watershed
<Keybuk> huh
<apw> cking, yeah will have to do that, its all very confusing
<Keybuk> apw: ok, weird
<apw> Keybuk, ?
<Keybuk> lsmod | wc -l
<Keybuk> 67
<Keybuk> uname -r
<Keybuk> 2.6.28-4-generic
<Keybuk> that's a lot more things in lsmod than I expected!
<apw> 28-4 isn't an all builtin kernel, just a lot more built in
<apw> sound is likely half of it
<Keybuk> yeah, but I'm sure we talked about more of this stuff being built-in
<cking> apw: I'd like to understand it myself as deep analysis always results in better understanding - maybe when I have a spare moment :-)
<Keybuk> acpi_cpufreq
<Keybuk> parport parport_pc lp
<Keybuk> psmouse
<Keybuk> etc.
<apw> yep i thought those made the cut
<apw> as my machine hangs running that one i've not spent much time looking at it
<Keybuk> e4f65f4
<Keybuk> is what I built
<apw> that should do most fof it
<apw> i don't see lp in there
<Keybuk> ok, well it doesn't look like I fluffed the build
<apw> yeah its much better than mine, i have 105
<apw> (on an intrepid kernel) so something has improved
<Keybuk> see my last two mails to kernel-team
<Keybuk> https://lists.ubuntu.com/archives/kernel-team/2009-January/004023.html
<Keybuk> https://lists.ubuntu.com/archives/kernel-team/2009-January/004024.html
<apw> i think legacy count was done
<apw> interesting figures though
<cking> Keybuk: excellent analysis.
<Keybuk> apw: was done?
<apw> -4 has the legacy count fixed in it right?  i think you say that in your second one
<Keybuk> yes
<cjwatson> Keybuk: what are you going to do in postinsts when files in /etc/udev/rules.d/ turn out to be modified?
<Keybuk> cjwatson: leave them
<cjwatson> oh yeah, same name overrides
<cjwatson> as long as no bright spark changes their rule filename (e.g. number) at the same time ...
<Keybuk> shouldn't really matter if they do
#ubuntu-kernel 2009-01-07
<mateen_maldar> hi all , i builded the kernel on ubuntu but it gives error modules.dep not found while booting the kernel that i built
<mateen_maldar> can anyone here tell me how to resolve this issue
<andersk> What's the reason you built your own kernel?  That is almost never necessary. 
<andersk> But you might start by checking the documentation at https://help.ubuntu.com/community/Kernel/Compile 
<mateen_maldar> andresk: i want to make modification to 2.6.27.7 version that's why i compiled the kernel
<rlj> hi all! a quick style question: i'm preparing a trivial patch to add a keyboard quirk (actually, i posted it to the list in november but got no feedback, so reposting now), but there's since been a similar patch added for another computer which adds a function atkbd_inventec_keymap_fixup which is identical to my proposed atkbd_hp_zv6100_keymap_fixup function.
<rlj> in my reposting now, would the preferred way be to: 1) add a #define atkbd_hp_zv6100_keymap_fixup atkbd_inventec_keymap_fixup or 2) duplicate both functions in case they would diverge later on or 3) rename the function and share between both quirk code paths? (the functions are all callbacks called when dmi matches are found)
<mjg59> rlj: 3
<rlj> thanks
<cjwatson> cking: have you forwarded your ext4 patch to the Debian BTS so that their grub maintainers pick it up? It'd make it easier for me to get installer work done (there's a fair bit of translation involved so it's best done in Debian where possible)
<cking> cjwatson: I have not yet forwarded this (yet). 
 * pgraner notices cking is having problems forming coherent English sentences today...
<cking> However Tim uploaded this yesterday https://bugs.launchpad.net/ubuntu/+source/grub/+bug/314350/comments/3
<ubot3> Malone bug 314350 in grub "Grub: Add support for ext4" [Wishlist,Fix released] 
<cking> cjwatson: ^^^
<cjwatson> cking: yeah, I saw that, I just wanted there to be a record of it in Debian as well so that I can say "hey, there's a bug for it" when other Debian d-i developers ask me how this ext4 stuff is supposed to boot then
<cking> cjwatson: Should I just create a Debian bug report and reference the patch - even if the patch may not apply cleanly to the Debian grub?
<cjwatson> cking: it's a good start
<cjwatson> I don't see an existing bug for it
<cking> Will do
<cjwatson> looks like Debian grub2 already supports it as well but I have no idea whether it's ready to go
<cjwatson> http://paste.ubuntu.com/101668/ <- basic untested installer support
<cking> cjwatson: looks reasonably sane to me at a glance
<cjwatson> I wonder whether libparted will explode or merely fall over gracefully
<cking> hopefully the latter
 * apw wonders how advanced the grub2 work is.
<apw> did we bottom out on when we might offer it as an option
<tjaalton> IIRC it was meant to be offered as an option in jaunty, and revisit the default bootloader again for jaunty+1
<tjaalton> I'm interested in testing it on my preseeded installations
<apw> cjwatson, are we doing anything with grub2 for jaunty?
<apw> (installer wise)
<cjwatson> apw: it's on the foundations roadmap but at low-priority, so not sure yet
<apw> fair enough, if it is on someones  map it is at least not forgottten
<Ng> out of interest, which alsa and e1000e versions are in jaunty?
<TheMuso> Ng: alsa 1.0.18rc3 is the version, but there are some commits from 1.0.18 final.
<Ng> T	nice, that's the answer I wanted :0
<Ng> hopefully it has a new enough e1000e to support a 82567LF-2
<rtg> Ng: whats is the PCI ID?
<Ng> rtg: unknown, I've not bought the hardware yet, it's an Intel DG45ID motherboard
<rtg> Ng: drivers/net/e1000e/ich8lan.c: * 82567LF-2 Gigabit Network Connection
<Ng> hmm, I see people saying they've had to compile a newer e1000e driver than is intrepid, so maybe it's a weird variant
<rtg> Ng: this is Jaunty
<Ng> rtg: ah, any idea which version of the driver it is though?
<rtg> Ng: drivers/net/e1000e/netdev.c:#define DRV_VERSION "0.3.3.3-k6"
<Ng> k, thanks
<NCommander> rtg, if you have no objections, I'd like to merge in the patch from cjwatson after testing it so we can get d-i working for ARM
<rtg> the grub recommends patch?
<cjwatson> no, https://lists.ubuntu.com/archives/kernel-team/2009-January/004042.html, just a few minutes ago
<NCommander> Oh, cjwatson's here :-)
<rtg> NCommander: never mind, just read the list
<cjwatson> grub recommends was from apw
<cjwatson> apw: I don't think lilo and grub should conflict - the kernel's postinst has special stuff to run only one bootloader installer
<cjwatson> it's not just whichever one was installed last or whatever
<rtg> NCommander: done
<mjg59> And lilo's useful even if you're using grub to boot
<cjwatson> apw: you might want to have both installed simultaneously while switching from one to the other (typically a delicate operation so you don't want the packages to refuse to install at the same time, making it harder for you to revert if stuff goes wrong)
<NCommander> rtg, I'll test it here.
<rtg> mjg59: right, sometimes you use LILO for other devices.
<cjwatson> grub's postinst definitely doesn't overwrite the MBR and I don't think lilo's does either, generally
<apw> cjwatson, i was intending on saying the same thing, moving from one to the other might require both for safety
<rtg> apw: so, what is Hobsee complaining about? Does it bork the upgrade?
<apw> smb_tp, sru justification is in the bug, and pushed
<apw> rtg i think there may be no reall effect other than scaring people cause it installled lilo
<apw> i think all of the changes make sense overall
<apw> as having both is generally not what is wanted unless it is specifically requested
<rtg> what does the recommends order have to do with it if there is no net affect? 
<rtg> deleterious affect, I mean
<apw> that is why all of the changes are only targeted at jaunty
<apw> i believe this is interesting only because we now install 'recommends' as part of an update by default
<apw> and if neither is there, then the first of the | will be chosen
<apw> and we primarily want grub, so mostly would have to swap it without the change, rather than only on wanting lilo
<apw> cjwatson, about right?
<rtg> apw: that not how I understand recommends. regardless of order, both packages get installed.
<apw> then we need to get cjwatson's input here
<rtg> apw: according to hobsee's bug report, that is exactly what is happening.
<apw> well cjwatson's description i think says we install lilo cause of the depends, then the installer installs grub cause we are going to use it, and can't remove lilo cause its needed by the depends on the kernel
<apw> i agree if both get installed as deps regardless of the | then yes the change seems pointless
<rtg> in that case there is little difference between recommends and depends.
<apw> with 'install recommends' turned on its not at all clear that they are differnet really
<apw> in effect, other than being able to --no-install-recommends 
<cjwatson> rtg: it's a recommends: lilo | grub
<cjwatson> that means "one or the other"
<rtg> cjwatson: but that is not what the bug is reporting. grub is already installed, but then lilo is sucked in.
<cjwatson> rtg: the order only had anything to do with it due to a ubiquity bug, and it's not *necessary* to fix the order to fix this bug; however, saying that grub is the preferred alternative seems to make sense these days
<cjwatson> rtg: grub is installed for a different reason
<cjwatson> ubiquity *explicitly* installs grub, completely independent of the kernel recommends
<apw> rtg, no that was an error in the report.  it was already installed in intrepid before the update
<apw> what she saw was it being upgraded as the jaunty version is newer
<cjwatson> lilo is sucked in due to the recommends, although ubiquity should have removed it (but didn't)
<apw> not installed for the first time
<cjwatson> if it were "recommends: lilo, grub" then *that* would install both
<apw> cjwatson, i am correct in saying that we confirmed that the lilo was installed in intrepid before the upgrade to jaunty, from her log files 
<rtg> ok, so  recommends _does_ behave in a logical way.
<cjwatson> let's be clear though, swapping the recommends alternative order is not really to fix the bug that Sarah saw; it's simply because it makes more sense that way
<cjwatson> apw: yes (well, not directly from her log files, I went round and confirmed the bug elsewhere - essentially code inspection)
<apw> i think with the change we will have to remove lilo less often when it wasn't needed rigth
<cjwatson> yes
<apw> as basically we get one or the other, and must switch it if we were wrong in d-i
<rtg> cjwatson: if neither recommends package is installed, will it then pick the first one?
<cjwatson> rtg: one reason why people are suddenly complaining now is that lilo was fixed to deal with large kernel/initramfs combinations, but that fix breaks old BIOSes, so it asks a debconf question on upgrade
<cjwatson> which rather surprises people who didn't know they had lilo installed in the first place
<cjwatson> rtg: yes, it will
<rtg> ok, now I think I understand.
<cjwatson> apw: scrolling back, you said "can't remove lilo cause its needed by the depends on the kernel" - actually not, we're perfectly able to remove it since it's only a recommends, we just weren't even trying
<apw> ok...
<cjwatson> and that's the difference between recommends and depends
<cjwatson> with recommends, you can say "no, you fool, I don't want this" and that will be respected. If you try that with depends then the packaging system will whine at you for the rest of your natural life
<rtg> apw: ack'd
<apw> so the short form is ... we install the first one on the Recommends: line, we then work out if we need a different one and if so install it, we then _should_ remove the one we don't need which we don't
<cjwatson> I'm sure there's a truly ancient bug report about the recommends ordering
<Nafallo> hhaaha
<cjwatson> apw: right
<Nafallo> cjwatson: nice! :-)
<apw> thanks ...
<NCommander> rtg, I've kicked off a test build with cjwatson's change to make sure all the udebs will get properly built
<cjwatson> cf. bug 43531 for background on why the kernel recommends a boot loader, although be rather careful about taking action on that report as the interactions (as we discovered today) are REALLY subtle
<ubot3> Malone bug 43531 in linux "Kernel isn't very useful without a boot loader, but doesn't depend on one" [Medium,In progress] https://launchpad.net/bugs/43531
<apw> i have updated hobsee's bug to include the a NOTE that the problem is subtly different to how it was reported
<NCommander> rtg, I have to ask, does CONCERNECY_LEVEL actually work correctly? It's behaving a little ... strange
<rtg> NCommander: it only works when its spelled right
<NCommander> rtg, :-P
<rtg> NCommander: if not specified, its -j(NR_CPU*2)
<NCommander> Well, I'm building from my ARM board, but I want to offload via distcc to the PC
<NCommander> I'm getting hits in the distccd.log, so it seems to be working
<rtg> are you using .intrepid-env ? (should be .jaunty-env)
<NCommander> I just ran dpkg-buildpackage with the correct environmental variables exported
<rtg> NCommander: you can do that to, I'm just lazy.
<rtg> though, to be honest, I haven't used distcc in awhile.
 * NCommander has been dependent on distcc to build KDE on his NSLU2 ...
<rtg> I have this monster dual quad core that is quite swift.
<NCommander> Offloading ARM builds to the x86_64 makes them palletable
<NCommander> it would be too slow any other way
<apw> NCommander, does that mean we could have a crosscompiler based buildd?
<NCommander> apw, we do/did that for m68k for ages
<NCommander> apw, you still need your host architecture thing for things that can't be cross-compiled obviously, but considering I got my NSLU2 to build KDE in the same time it took the buildds ....
<apw> would that mean we could ahve arm builds in ppa's
<NCommander> apw, er, not quite, because you still need an ARM host
<apw> ah yes
<NCommander> apw, that being said, maybe we could convince IS to put QEMU in a XEN instance, and then the cross-compilers in it
<apw> rtg, are we planniing on another kernel upload before alpha3 ?
<rtg> apw: yep - I hope to include Ben's work regarding ACPI suspend.
<apw> cool.  thanks
<rtg> NCommander: what is the console baud rate on this board?
<NCommander> 115200
<NCommander> That should get you to the redboot prompt (if it starts trying to find bootp info, hit Ctrl-C to kill it and it will fall back to local booting)
<rtg> that's a ridiculously high baud rate.
<cjwatson> NCommander: generally we've been very reticent to rely on cross-compilers for buildds; the human effort required to babysit them generally seems to exceed the machine time you save
<cjwatson> (factoring in the extra cost of human attention)
<cjwatson> oh, geez, am I going to need a serial console when I get one of these board?
<cjwatson> s
<cjwatson> I was kind of hoping for VGA out
<NCommander> cjwatson, yeah
<NCommander> cjwatson, there is one
<NCommander> cjwatson, but at the moment, its not quite usable
<cjwatson> (and keyboard in, obviously ...)
<NCommander> cjwatson, its got USB ports
<cjwatson> guess I'd better find a serial cable for the moment
<NCommander> cjwatson, I bought a 20 dollar USB/Serial null modem cable
<rtg> ARM cross compiling is pretty well tested '
<rtg> 'cause its the only way you could do it.
<cjwatson> not for most packages in the archive
<cjwatson> for the kernel, maybe
<cjwatson> there is a large swathe of packages in the archive that simply won't cross-compile sanely
<cjwatson> and nobody has particularly cared about getting them going on arm; but it matters for us since we're building the whole archive
<cjwatson> allocating lots of human attention to making them cross-compile versus just throwing more hardware at the problem isn't really such a good use of resources as it seems on the face of it, IMO
<cjwatson> and we've already got over the initial hump of building the whole archive for armel, so it'd be silly to change now
<rtg> oh, I wasn't advocating that. 
<apw> i was only interested in those options for ppa stuff which needs a 'protected environment'
<cjwatson> yeah, the lack of ppa is awkward
<cjwatson> rtg: what would be the best feature to test for when asking the question "is this filesystem ext4", do you think?
<cjwatson> I was going to go with extents, but that's an EXT3_ symbol (although it doesn't seem to be supported by fs/ext3/ in the kernel so maybe it's ok)
<rtg> cjwatson: inode size
<cjwatson> rtg: hmm, that doesn't seem to be one of the feature bits though?
<cjwatson> rtg: or do you mean EXT4_FEATURE_INCOMPAT_64BIT or EXT2_FEATURE_INCOMPAT_META_BG or something?
<rtg> cjwatson: what are you looking at? something already on the disk?
<cjwatson> hmm, or maybe EXT4_FEATURE_RO_COMPAT_EXTRA_ISIZE or EXT4_FEATURE_RO_COMPAT_HUGE_FILE
<cjwatson> rtg: yeah, I'm looking for a feature flag I can test in libparted to return the proper filesystem type
<cjwatson> like, for ext3 it tests for EXT3_FEATURE_COMPAT_HAS_JOURNAL
<cjwatson> which is a pretty obvious "this is ext3" marker
<cjwatson> it's in libparted's probe code
<rtg> I think EXT4_FEATURE_RO_COMPAT_EXTRA_ISIZE is exclusive to an ext4v file system. The inode size is 256 as opposed to ext3 128.
<cjwatson> we actually create ext3 with inode size 256 nowadays
<cjwatson> but I can buy extra_isize, that appears to be a feature we don't turn on for ext3 according to /etc/mke2fs.conf
<cjwatson> cool, thanks
<andersk> I think EXT4_FEATURE_INCOMPAT_EXTENTS is the important one. 
<rtg> cjwatson: yeah, how about one of the incompatible flags?
<cjwatson> ok, fine by me
<cjwatson> I just wasn't sure what ext4 people considered to be the important thing about ext4
<rtg> I'm a little confused about your goal. Is it to determine how to detect and mount the file system?
<andersk> http://ext4.wiki.kernel.org/index.php/Ext4_Howto says that turning on the extents feature is how you convert an ext3 filesystem to ext4. 
<cjwatson> gotcha
<cjwatson> rtg: basically yes. libparted determines how the filesystem will show up in the installer's partitioner
<rtg> ok, so you're looking for a bit that says it can _only_ be ext4.
<cjwatson> I'm going to have mkfs.ext4 do the actual hard work, but I need some minimal support otherwise the partitioner falls over entirely when dealing with ext4 filesystems
<cjwatson> right
<TheMuso> 1/c -all
<TheMuso> gah
<rtg> NCommander: i hate RS/232
<NCommander> rtg, redboot does know how to work over telnet
<NCommander> (although I'm not quite sure it works on this board)
<rtg> its booting and requesting DHCP, just can't get the console
<NCommander> rtg, push ctrl-C during DHCP to cancel that, and then push it again to get to the RedBoot prompt
<NCommander> rtg, are you using minicom?
<rtg> I mean, I cannot get anything out of the console. wrong NULL modem
<lure> anybody here know how to fix lvm root after today's udev package? I am left in BusyBox with no clue...
<jbarnes> ugg has anyone fixed install-kernel yet?
<jbarnes> err /sbin/installkernel
<jbarnes> looks like /sbin/installkernel is just missing a call to do the mkinitramfs -o /boot/initrd.img-${ver} ${ver}
#ubuntu-kernel 2009-01-08
<crimsun> jbarnes: thanks for the heads-up. we probably want to use update-initramfs instead; i'm checking the logic to make sure it does the right thing when -u is used.
<crimsun> jbarnes: otherwise we need (duplicated) logic in installkernel :/
<jbarnes> crimsun: oh I haven't tried update-initramfs... I mainly just want my kernel "make install" to work :)
<crimsun> jbarnes: yes, i've modified the debianutils source package; i just want to make sure -c is the right thing
<jbarnes> cool
<tjaalton> the recent kernels fail to detect my disks on install
<tjaalton> -4.5 was fine
<tjaalton> filed bug 314992
<ubot3> Malone bug 314992 in linux "jaunty: installer fails to find the disk, worked with -4.5" [High,New] https://launchpad.net/bugs/314992
<cjwatson> tjaalton: might be a d-i bug after all (I notice given the comment about ATA modules you made in the bug). I commented
<rtg> cjwatson: fallout from config changes?
<cjwatson> rtg: just needed to rebuild the installer, as otherwise its kernel and the module udebs it fetched at runtime were skewed. no big deal
<rtg> cjwatson: cool. I think I'm about done making big config changes.
<tjaalton> cjwatson: it's still the same
<tjaalton> should've mentioned that on the bug..
<tjaalton> (ie. it's what I used, and no different from ubuntu8)
<cjwatson> hmph, ok
<cjwatson> will have to poke about
<cjwatson> I'm diving down a series of ext4 rabbit-holes today
<tjaalton> is it usable on the alternate installer yet?
<cjwatson> no, working on it.
<tjaalton> cool
<cjwatson> partman-ext3, partman-partitioning, parted, klibc ... it's a little bit complex
<tjaalton> :)
<tjaalton> cjwatson: hum, actually now I can see the disks after all, but I see that parted_devices has segfaulted
<tjaalton> so maybe I didn't have ubuntu9 when I thought I had (used se.a.u.c.. silly me)
<cjwatson> *parted_devices* segfaulted?
 * cjwatson blinks
<cjwatson> that program is 91 lines long, not a lot of room for madness
<tjaalton> yep, partman-lvm finished probing for lvm, and then boom
<cjwatson> can you run 'anna-install strace-udeb' and strace it?
<cjwatson> just run it with no arguments
<cjwatson> /dev/sda1 on /target type ext4 (rw,relatime,errors=remount-ro,barrier=1,data=ordered)
<cjwatson> not far now
<tjaalton> cjwatson: ok, and post the strace somewhere?
<cjwatson> yeah
<tjaalton> cjwatson: ok here you go http://users.tkk.fi/~tjaalton/foo/parted-devices-strace
<cjwatson> tjaalton: ok, thanks, bit of a head-scratcher but I'm looking at it ...
<cjwatson> tjaalton: anything unusual about /dev/mapper/rootvg-root that would save me time if I knew about it?
<tjaalton> cjwatson: shouldn't be.. what if I wiped it and tried again?
<cjwatson> let's not destroy the evidence eh?
<tjaalton> ok :)
<tjaalton> it was installed using some earlier jaunty installer, can't remember if it was before christmas
<tjaalton> the vg has four lv's (tmp, swap, root, var)
<cjwatson> what does 'dmsetup table' say?
<cjwatson> maybe 'dmsetup table /dev/mapper/rootvg-root'
<tjaalton> nothing..
<tjaalton> but just dmsetup table shows an entry about multipath
<tjaalton> oh right.. gah
<smb_tp> tjaalton, You have multipath hw? :)
<tjaalton> smb_tp: I do, but not this box :/
<tjaalton> so looks like enabling multipath breaks if trying to install a normal box.. I'll try without
<smb_tp> Does our multipath use on disk metadata to coalesce the devices ?
<smb_tp> That would be quite odd. Oh, hm, wasn't there somewhere a bug about changed scsi_id arguments...
<smb_tp> Gos it seems long time ago. IIRC there was a dry-run argument to multipath and you could increase debug level with -v#
<tjaalton> cjwatson: so it was "d-i disk-detect/multipath/enable" which broke it after all
<smb_tp> That way you would see the callouts done and the results
<cjwatson> hm, still bad that libparted segfaults
<cjwatson> (one moment ...)
<cjwatson> tjaalton: http://paste.ubuntu.com/102202/ might fix it; I'll put that in my next parted upload
<tjaalton> cjwatson: ok, I'll try it once it's out
<smb_tp> tjaalton, Just to be sure, what line did dmsetup target put out with multipath?
<smb_tp> It would be bad if that could cause normal disks to get grouped
<tjaalton> smb_tp: one moment, I'll enable it again
<tjaalton> smb_tp: it did "steal" the devices, meaning that rootvg-* were all empty
<smb_tp> Hm, might be the problem from the past that lvm normally does not scan dm devices
<tjaalton> smb_tp: http://paste.ubuntu.com/102204/
<smb_tp> Ah ok
<tjaalton> hmm, I wonder if I could install it anyway
<smb_tp> So enabling multipath put all disks into multipath groups (so it potentially can add more paths later). But its only one target so thats good. The problem is likely that lvm avoids scanning device-mapper devices since tis could be its own.
<smb_tp> Does pvscan -vvv give clues?
<tjaalton> /dev/mapper/rootvg-root: Aliased to /dev/dm-4 in device cache
<tjaalton> etc
<smb_tp> But nothing of actually scanning for metadata?
<tjaalton> http://users.tkk.fi/~tjaalton/foo/pvscan-out
<cjwatson> this is why multipath isn't on by default in the installer, I guess :)
<tjaalton> yeah, I need to isolate the preseed option for the relevant hw :)
<smb_tp> It definitely looks nt well tested
<smb_tp> The main problem is that partitioning a multipath device does not work. So you have to set up partitions before and then let multipath detect those...
<smb_tp> This is not the issue here, though
<tjaalton> smb_tp: multipath installation works fine :)
<tjaalton> I've got one BL406c here..
<tjaalton> grub doesn't support multipath yet though, but it only needs one small patch (bug filed too)
<smb_tp> I only worked with ESS6K/8K before. :)
<smb_tp> To clarify: multipath installation that work: with or without lvm and for which release?
<tjaalton> actually, it's without lvm
<tjaalton> there were some problems with lvm, mostly about it being unable to clean up an existing lvm setup
<tjaalton> on jaunty
<tjaalton> some packages should be promoted to main too, now I need to enable universe udebs
<smb_tp> Is it more than libvolume-id1 ?
<tjaalton> oh, and udev fails to init the devices properly, I need to run kpartx by hand in initramfs
<tjaalton> hmm, libvolume-id1 isn't installed on that system
<smb_tp> About lvm, you might try to add "types = [ "device-mapper", 1 ]" to /etc/lvm/lvm.conf and see what happens on vgscan
<tjaalton> well it's not using lvm atm
<smb_tp> Not sure this hit you as well, but we found this to be in universe this morning, but it should be in main by now
<smb_tp> Oh, that was meant for the system where multipath steals the volumes
<tjaalton> ah
<smb_tp> The kpartx problem might be in udev. There should be a online event which should trgger the kpartx. Historically it was an add event but that caused race conditions
<tjaalton> so what should I expect after the vgscan? dmsetup table still shows the same as before
<soren> vgscan looks at block devices for lvm superblocks. I don't think device-mapper gets told about them until they're activated.
<smb_tp> Sigh, might be jsut not enough then. I am a bit rusted here. It could have been a combination of this and filter rules. 
<smb_tp> lvm reads the start of the devices- If yu have multipath you get a device-mapper device that is not controlled by lvm
<tjaalton> multipath-udeb and libaio-udeb were the ones that should be moved to main for multipath support to work OOTB
<smb_tp> I remember you had to be careful that way. The rules had to exclude the nodes created by lvm otherwise you got strange problems when trying to remove lvs
<tjaalton> libaio1-udeb that is
<smb_tp> Ah, ok. So that is different to our temporary problem this morning
<tjaalton> I don't see why the udebs are in universe when the rest of the packages are in main
<smb_tp> That might be something to ask cjwatson.
<smb_tp> With respect to the vg which is stolen. I might have been misleaded here. From your log I see that mpath0 is scanned inedeed. But sure kpartx was not run, so we only get the full disk and that does not yealt the metadata
<smb_tp> So the solution might be to try after running kpartx -a for it. Which should give a mpath0p1
<tjaalton> this is inside the installer, the kpartx problem is when it boots up
<tjaalton> ah
<smb_tp> But still you only have mpath0 which is the whole disk. And the lvm data is on sda2
<tjaalton> yeah, so that's why it fails to remove it?
<smb_tp> Fail to remove what? Sorry got lost
<tjaalton> it installs lvm on top of multipath fine if I remove the existing lvm setup first
<cjwatson> tjaalton: which udebs?
<tjaalton> cjwatson: multipath-udeb, libaio1-udeb
<cjwatson> well, partman-multipath is in universe too ...
<tjaalton> ah, that too :)
<smb_tp> If you install on top of mpath0 You end up using the disk just without any partitions. Works for the normal disks as long as you don't have IBM zSeries
<cjwatson> did anyone ever write a MIR for it?
<tjaalton> cjwatson: let me check
<cjwatson> if that gets promoted we can promote multipath-udeb and libaio1-udeb at the same time
<tjaalton> cjwatson: no MIR wiki, but I've filed bug 309635 (and forgot about it already)
<ubot3> Malone bug 309635 in partman-multipath "Please promote partman-multipath, multipath-udeb and multipath-tools-boot to main" [Undecided,Incomplete] https://launchpad.net/bugs/309635
<cjwatson> and lool asked a question there by the looks of things
<tjaalton> yes..
<tjaalton> it got lost in the d-i bugfolder
 * tjaalton needs to change the filtering priorities
<tjaalton> well, it's perhaps enough to keep it in universe for now, but without grub support it's useless :)
<lool> Updated the bug; happy to revisit when we have a group of people with hardware to support the package
<lool> cjwatson: Or did you care for other reasons about multipath?
<cjwatson> lool: only because tjaalton's asking for installer support and appears to have hardware necessary to test it
<cjwatson> (and has been contributing installer tweaks)
<tjaalton> tbh I don't know for how long I have the hw
<lool> cjwatson: With your d-i hat on, I wouldn't mind you telling me that it's enough to support it
<tjaalton> but it's all coming from debian
<tjaalton> er, mp support that is
<lool> I don't think this is an extremely strong requirement, but I think we ought to be able to test/fix/support packages in main, and it's not clear to me that it will be possible if we don't have a couple of people with the hardware or shared hardware accessible on request
<lool> But I agree the package coming from Debian should already be in a working state
<tjaalton> it already works on jaunty
<lool> tjaalton: I mean over time
<lool> I would expect it to work
<tjaalton> lool: sure
<tjaalton> all they are lacking (like us) is support in grub, which they'll have in grub2 but not grub1
<lool> We discussed Grub 2 again at UDS jaunty
<tjaalton> yep
<tjaalton> got to go now ->
<cjwatson> yay, successful ext4 installation
<cking> cjwatson: way to go
<cking> cjwatson: booting from ext4 too?
<cjwatson> yep
<cjwatson> ext4 / + swap
<cking> cjwatson: yay!
<rtg> apw: fixed your jaunty ABI problem
<apw> rtg, what did you do?
<rtg> started a new release? I guess that wouldn't have changed the ABI. doh!
<rtg> never mind
<apw> but that _might_ be my issue actually ... hmm
<rtg> apw: no, it would still build. you must have added an ABI changing patch?
<apw> yeah hmmm arr ooo, but it might fix my new problem!
<apw> which is that the module.ignore is not working
<rtg> apw: thats 'cause its called 'ignore.modules'
<apw> if (-f "$prev_abidir/../modules.ignore") {
<rtg> hmm, i guess there is also a modules.ignore. how confusing
<apw> and $flavor.ignore.modules
<rtg> oh, modules.ignore is a global ignore, not per flavour
<apw> yeah
<rtg> apw: seems like it ought to just exit.
<apw> by doing the new release have you loaded up the abi files too?
<rtg> yep, but they ought to be the same
<apw> has not the name of them changed
<rtg> 4.8 --> 4.9
<apw> so when i have the changelog one element earlier am i not missing the abi or something
 * apw isn't sure anymore, more actual testing on going
<rtg> apw: but you said you're not having ABI issues, you're having module check problems
 * apw is scrapping all his results and starting clean rebased on the newrelease and will report back
<cjwatson> cking: thanks so much for that grub work, I'd have hated to have to do that - parted was hard enough ;-)
<cking> cjwatson: no probs - all I did was coerce in a patch from Quentin Godfroy - so kudos to Quentin really
<lool> update-initramfs: Generating /boot/initrd.img-2.6.28-4-generic
<lool> mkdir: cannot create directory `/tmp/mkinitramfs_YJPCAT/etc/udev/rules.d': File exists
<lool> Is this known?  I couldn't find it on LP
<andersk> Yes, bug 314879 
<ubot3> Malone bug 314879 in udev "root on LVM broken since latest udev 136-2" [High,Confirmed] https://launchpad.net/bugs/314879
<lool> thanks
<sconklin> I'd like to invite comments on our plan to detect and report suspend/resume failures: https://wiki.ubuntu.com/KernelTeam/SuspendResume
<jbarnes> sconklin: looks pretty good, I like the idea of the status file, that should help
<jbarnes> sconklin: one thing I mentioned at UDS was that it would be good if the test-suspend script also tracked time to suspend and time to resume somehow
<jbarnes> it should be able to calculate the total time using the timer since it knows when the wakeup should occur
<sconklin> jbarnes: thanks. Doing it this way ends up just being some small hooks between various systems.
<jbarnes> yeah
<sconklin> Agreed - the same component writes and destroys that files, so should be able to put timestamps in and throw a delta into the log.
<jbarnes> new platforms seem to be much faster... my x200s resumes in far less time than my t61, mostly due to bios improvements I think
<sconklin> I'll add that to the wiki page and make sure apw sees it, since he's working that side
<jbarnes> but I think there's lots of room to improve the kernel too, ideally it should be well under 500ms (about the time it takes to open the lid), so tracking time can help
<sconklin> That's very useful information to have.
<sconklin> well, here we get into the definition of what "resumed" means. Obviously at 500 mS you're not including wireless connectivity, but probably are including window manager fully usable.
<jbarnes> right
<jbarnes> though hopefully your wifi driver doesn't take 1m to re-associate :)
<jbarnes> if you google around you'll probably find some of the visa/whql platform requirements msft put out recently
<jbarnes> might be good to link to them or something
<sconklin> yeah. The plan is to have this first cut operational by next week, and then see what we need to focus on from there.
<jbarnes> cool
<maxb> Is anything that linux-backports-modules does special in terms of overriding modules shipped with the default kernel, or does it only work because the modules it ships are not included in the default kernel packages?
#ubuntu-kernel 2009-01-09
<angie> how do i build nvidia support into my xconfig for a ubuntu gresec kernel setup
<angie> how do i select the kernel i want to use in ubuntu
<angie> lik eeselect
<jonpackard> Hello. I'm testing the jaunty-armel 2.6.28-4-versatile kernel in qemu and seem to be running into problems. I've been comparing it against the debian-armel 2.6.26-1-versatile kernel. I can boot the debian kernel fine but I can't even get a kernel panic out of the ubuntu kernel. Could anybody please offer any suggestions?
<soren> keybuk: What is your suggested course of action wrt. bug 314879? You don't want udev's initramfs hook to create /etc/udev/rules.d, and I feel it would be wrong for lvm2, dmsetup, mdadm, etc. to move to /lib/udev/rules.d without a versioned dependency on udev, but you just /removed/ lvm2's dependency on udev, so I'm a bit confused where we're going here?
<ubot3> Malone bug 314879 in udev "root on LVM broken since latest udev 136-2" [High,Confirmed] https://launchpad.net/bugs/314879
<soren> New debhelper will make sure the rules files are installed in the right place, but the initramfs hooks all hardcode the location.
<Keybuk> soren: the removing the dep was a mistake, the dep can go back
<Keybuk> I'd assumed the dep was simply there for watershed
<Keybuk> so changed it to one on watershed
<Keybuk> btw, devmapper doesn't depend on udev - so there's no way to introduce a versioned dependency on it ;)
<soren> Ok. So a versioned dependency on udev (>> 134) ?
<Keybuk> udev (>= 136-1)
<soren> Hmm... Ok. So for devmapper we just change the path and pretend everything is fine?
<soren> (which it is, but still)
<Keybuk> yeah
<Keybuk> there's no configure-order dependency with udev
<soren> Ok. I can do lvm2, mdadm and devmapper.
<soren> (devmapper needs a no-change upload to move to /lib/udev/rules.d)
<Keybuk> no change?
<Keybuk> at least bump the b-d on debhelper?
<soren> Erm.. No, I didn't mean to do that, actually.
<soren> It doesn't need the newer debhelper to work. If people want to use the source package on older versions of Ubuntu, debhelper will DTRT.
<soren> The dependency is for the binary package, really, but there's really no useful way to express that.
<soren> Hmm...
<soren> Unless, of course..
<soren> We could make the new dh_installudev add the versioned udev dependency to a misc:Depends?
<soren> Oh, right, you said devmapper couldn't depend on udev.
<soren> brb
<Keybuk> well, I think it can
<Keybuk> but Debianistas do that silly "but you can use devmapper without udev, I want to uninstall udev, it should only be a Recommends" thing
<Keybuk> and of course, you can't have versioned Recommends
<Keybuk> honestly, I don't worry about it much
<Keybuk> they'll have the new udev anyway
<soren> Blargh, dmsetup's hook of course needs the new path.
 * soren needs to reboot
<smb_tp> Keybuk, BTW, forget my mail then. It was just about the same issue with rules.d
<Keybuk> anyone feel brave enough to set CONFIG_USB_DEVICEFS=n ?
<Keybuk> soren: have uploaded a version of watershed that installs into the initramfs, you'll want to depend on that too (>= 2)
<soren> Keybuk: Ah, yes. Will do.
<soren> Keybuk: Pushed devmapper, lvm2, and mdadm.
<redondos> hi. what is the reasoning behind disabling CONFIG_SND_DYNAMIC_MINORS in -generic and -server but not in -virtual?
<soren> Which Ubuntu version?
<redondos> soren: 8.04
<soren> No particular reason. Sounds like a mistake.
<redondos> the mistake being not having it enabled in all kernels?
<redondos> (or the other way around)
<soren> redondos: Mistake being that the virtual kernel differs.
<jonpackard> Hello. I'm testing the jaunty-armel 2.6.28-4-versatile kernel in qemu and seem to be running into problems. I've been comparing it against the debian-armel 2.6.26-1-versatile kernel. I can boot the debian kernel fine but I can't even get a kernel panic out of the ubuntu kernel. Could anybody please offer any suggestions?
<marijus> hello is there a testing ppa for 2.6.29?
<rtg> jonpackard: wait until Monday when Amit is back. 
<rtg> marijus: no test kernel yet
<redondos> thanks, soren
<jonpackard> Thanks rtg!
<Kano> hi rtg , do you want to include a backport of rt2860/70 from 2.6.29/staging? those wifi chips are very common
<Kano> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=91980990527258a075361490cecadbb7356fc0d2
<Kano> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c55519ff75224222f4668c92ae3733059269f575
<rtg> Kano: do those drivers actually work? I'm not interested in a bunch of bug reports on what greg refers to as "utter garbage"
<Kano> rtg: well i know one with one of those chips, could be simply tested when you add it
<rtg> Kano: I'll tell you what, you add it to your kernel and report back. I'm not really interested in a development driver.
<Kano> even if lots of netbooks already use em and those cheap draft-n sticks?
<maxb> Is it documented anywhere why linux-restricted-modules works the way it does? I am curious why linking the modules at boot-time is useful
<rtg> maxb: I've argued that it is a legal fiction. I'm trying to get that runtime link step removed based on boot time performance.
<maxb> I'm quite curious as to the rationale of the fiction even if it is fiction! :-)
<mjg59> maxb: Issues with the legalities of distributing binary-only modules that are linked against GPLed components
<maxb> where the gpl components are other .o files that make up the same module?
<rtg> maxb: metaphorically, its the difference of shipping with a loaded gun v.s. shipping a gun with the ammo packed in the same box.
<maxb> nice analogy :-)
<mjg59> maxb: Yeah
<maxb> ok, thanks. I'm happy now that I know why this crazy dance is happening :-)
<mjg59> (Note: Not legal advice, not in a position to speak on behalf of Canonical, blah blah blah)
<pwnguin> if linking at runtime is a legal fiction, then how is removing that step acceptable?
<maxb> I assume rtg was implying "fictionally legal"
<pwnguin> usually, "legal fiction" denotes a legal theory believed to not stand up in court
<maxb> Well, it probably doesn't matter too much. Intrepid's l-r-m only contains two wireless drivers, and one of those (madwifi) is becoming properly free
<pwnguin> i believe nvidia has a similar problem?
<maxb> That seems to have been migrated to dkms
<pwnguin> right. hrm
<pwnguin> which is sort of a link on package install or kernel upgrade, no?
<maxb> s/link/build-from-source/
 * maxb chuckles at cking's quit message
<pwnguin> i have join/parts on ignore on this channel, since a lot of activity is basically just that =/
<maxb> * cking has quit ("Me transmitte sursum, caledoni")
<pwnguin> and i can't figure out how to get irssi's activity monitor to ditch the boring activity status
 * maxb hunts for that setting in his own irssi config
<maxb> /set activity_hide_level JOINS PARTS QUITS
<pwnguin> there's two levels; one is people saynig things, which is white for me. the other is joins etc and is blueish
<pwnguin> maxb: if that works, thanks!
<maxb> wfm :-)
<pwnguin> maxb: I think adding NICKS helps, too
#ubuntu-kernel 2009-01-11
<marlock> hi to all
<marlock> i want to compile a kernel on a Centrino Duo T2500 processor
<marlock> what option i have to choos in processor features?
<marlock> pentium-m or pentium-4m?
<marlock> i read that core 2-newxeon is only for newer processor like the core2duo or the centrino2duo
<IntuitiveNipple> klasikahl: https://lists.ubuntu.com/mailman/listinfo/kernel-team
<klasikahl> thanks!
<klasikahl> i think i'll just write an email to the list... usually get more thorough responses that way
<IntuitiveNipple> klasikahl: Also, try this search (unfortunately Google kills the minus in -virtual): http://www.google.co.uk/search?q=%22-virtual%22+site%3Ahttps%3A%2F%2Flists.ubuntu.com%2Farchives%2Fkernel-team%2F&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:gb:unofficial&client=firefox
<klasikahl> i just hope the list isn't too high volume :P
<IntuitiveNipple> klasikahl: Yes, indeed
<IntuitiveNipple> No, we only get a handful a day
<kleve> hi
<kleve> is sbrk a specific memory allocator for linux?
#ubuntu-kernel 2010-01-11
<vish> apw: ogasawara: hi.. should Bug #503286 be sent upstream?
<ubot3> Malone bug 503286 in linux "Bluetooth killswitch does not remember previous session state" [Low,Triaged] https://launchpad.net/bugs/503286
<NCommander> ericm-Zzzz, ping, what's the status on dove 2.6.32?
 * NCommander would like to test a newer kernel ASAP to see if it helps with some of the thumb2 issues
<cooloney> NCommander: i think ericm-Zzzz already put dove .32 kernel package some where
<cooloney> NCommander: can you grab it and test on your side?
<NCommander> cooloney, I have no idea where they might be
<cooloney> NCommander: http://people.canonical.com/~ycmiao/dove-rebase/
<cooloney> NCommander: please take a look at this, I will work close to your TZ this week, heh
<cooloney> NCommander: i guess you got the email from Eric 'Status of the mvl-dove rebased patchset against 2.6.32.2'
<NCommander> cooloney, I'm still knee deep in my inbox, so I'll tell you when I get to that email :-)
<cooloney> NCommander: got you, -:)), enjoy the new dove kernel.
<ogasawara> vish: sorry for the delay, yes if you want to open an upstream bug report that'd be great
<vish> ogasawara: np . sure... upstream for kernel bugs is bgo  ? i found this empty > https://wiki.ubuntu.com/Bugs/Upstream/kernel
<ogasawara> vish: yah, bugzilla.kernel.org
<ogasawara> vish: i'll fill up that wiki
<vish> hmm.. k , another account i need to apply :(
<vish> ;)
<vish> ogasawara: done > http://bugzilla.kernel.org/show_bug.cgi?id=15047    what other information should i attach? 
<ubot3> bugzilla.kernel.org bug 15047 in Bluetooth "Bluetooth killswitch does not remember previous session state" [Normal,New] 
<vish> are all the apport data essential?
<ogasawara> vish: not all the apport data is probably essential (like the alsa stuff isn't relevant)
<ogasawara> vish: probably best to attach general stuff like lspci, dmesg etc.
<vish> yeah , ok
<doctormo> I'm trying to debug a problem with ipw2200 on a satelite m55, where can I got for some assistance?
<doctormo> If it's here, then the problem is that the device will do a scan, but will not connect to anything and the commands time out.
<doctormo> After that, the device is locked up, rmmod and modprobe produce errors and it's gone.
<doctormo> Ah irqpoll=1 is the fix... although I only managed to find that on a debian forum.
<Ng> would we expect 802.11n to work in the lucid kernel? (intel 5300)
#ubuntu-kernel 2010-01-12
<NCommander> cooloney, ping, Mobile meeting in #ubuntu-meeting
<cooloney> NCommander: thanks, just back from lunch
<slytherin> What is the procedure for version bump in linux-ports-meta package?
<macli> I could always follow https://wiki.ubuntu.com/KernelTeam/GitKernelBuild to build mainline git kernel before kernel-2.6.32, but now I always got error since kernel 2.6.33 release
<macli> The UTS Release version in include/linux/version.h does not match current version:"2.6.33-rc3-custom"
<macli> my running command: CONCURRENCY_LEVEL=2 fakeroot make-kpkg --initrd --append-to-version=-custom kernel_image
<hyperair> macli: that's a bug in kernel-package.
<hyperair> the UTSRELEASE or whatever macro that was is now defined in another header.
<hyperair> macli: replace /usr/share/kernel-package/ruleset/misc/version_vars.mk with this: http://pastebin.com/f59fbe34c, make-kpkg clean, and then start over. it should work this time
<macli> hyperair: I tried to update kernel-package, but it says already update
<hyperair> the bugfix hasn't entered kernel-package yet
<hyperair> this is a local change i made to mine
<hyperair> the bug is in bugs.debian.org somewhere
<macli> hyperair: I have replaced the version_vars.mk, now start compiling
<hyperair> good luck
<marks256> i'm trying to compile the 2.6.31 kernel to include the Lustre FS patch, but i am getting an error: Failed to create a ./debian directory: No such file or directory at /usr/bin/make-kpkg line 1048. Any ideas on how to solve this?
<macli> hi hyperair, it works, thanks a lot
<hyperair> np
<argued> I found some posts that 2.6.32 version could be a solution.. what do you think / recommend?
#ubuntu-kernel 2010-01-13
<slytherin> Can anyone please take a look at bug #506546 and take appropriate action?
<ubot3> Malone bug 506546 in linux-ports-meta "Bump version for karmic-security" [High,Confirmed] https://launchpad.net/bugs/506546
<kunal> hi..
<kunal> is it appropriate to ask questions about daily builds (of 2.6.33) here?
<kunal> I'm trying to test a patch for alsa - have got sound-2.6 git tree checked out
<kunal> but I'm stuck..
<marks256> I'm trying to compile 2.6.22 with the lustre kernel patch, but i'm not having any luck at all. I've tried following multiple tutorial, but no avail. My main problem is, i don't think the configuration is copying over. I was able to compile a kernel, but when i boot into it, i'm presented with what looks to be busybox, and the list of commands is limited. Plus when i do a modprobe -v lustre, nothing shows up. :(
<xteejx> Hey Kernel Team
<crimsun> mcgrof: are the compat-wireless dailies still being built somewhere?
<crimsun> mcgrof: i.e., the latest I see is 2010-01-06 on orbit
<mcgrof> crimsun: refresh
<crimsun> mcgrof: still 2009-12-11
#ubuntu-kernel 2010-01-14
<mcgrof> crimsun: try again
<mcgrof> crimsun: what link are you using
<crimsun> the link from Users > Download > compat-wireless-2.6 > wireless.kernel.org ... /download/compat-wireless-2.6/
<crimsun> (still shows 2009-12-11)
<ralsheb> im trying to compile/install an older vanilla kernel from kernel.org, one which ubuntu never used, im having problems compiling it and thking its because i need kernel headers that match the version im compiling, any idea where i can find these??
<AceLan> ralsheb: what's the error message?
<AceLan> ralsheb: paste the error message here http://paste.ubuntu.com/
<^arky^>  Is there meta bug for CE: hpet increasing min_delta_ns to 15000 nsec
<^arky^>  kernel errors in lucid
<slytherin> Can anyone from kernel team please sponsor the debdiff attached to bug 506546
<maxb> Hi, how does a KMS graphics driver decide what mode to set?
<maxb> My i915-based lucid system has suddenly started to set a mode with fewer rows and columns
<Kano> hi, you know that 2.6.32.3 (not 2) is out and 2.6.31.11 (not 9)?
<gnomefreak> does the kernel control TTYs?
<chrisccoulson> gnomefreak - what aspect of them?
<chrisccoulson> (although i might not be able to answer your question anyway) ;)
<gnomefreak> chrisccoulson: they are not usable at all.
<chrisccoulson> i've seen someone else mention that
<gnomefreak> there is not login screen just a black screen with some white lines across the top
 * gnomefreak wanted to file a bug just not sure what package
<dhillon-v10> gnomefreak, you can go ahead and use the linux package to file the bug against
<gnomefreak> dhillon-v10: linux-image...?
<dhillon-v10> gnomefreak, nope only linux, let me show you an example bug :)
<gnomefreak> k
<dhillon-v10> gnomefreak, check for example here: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/354705 the bug is filed against the linux(ubuntu) package
<gnomefreak> thanks
<dhillon-v10> gnomefreak, np
<gnomefreak> dhillon-v10: thanks its filed 
<dhillon-v10> gnomefreak, great :) now let's get fixing it
<gnomefreak> anything i can do let me know
<blizzkid> hi all. Was just thinking, how hard would it be for a good devver to create a tool that takes the generic kernel config and strips out the hardware support not needed for a specific machine?
<blizzkid> That would build a semi-custom kernel adapted to one's hardare and keep in the needed other modules
<bluesscream> If you have a 2.6.32 installed and you want to compile i.e 2.6.33-rc4 just run make localmodconfig
#ubuntu-kernel 2010-01-15
<freinhard> hi!
<freinhard> did the most recent kernel published for karmic contain changes in the dvb susbsystem? just reinstalled some external, not yet in the main tree, driver for my dvb-s device and /dev/dvb/ is gone but /dev/dvb0.* is there instead
<mohanohi> hi..
<mohanohi> is it possible to make a quad core processor work as combined single core ?/
<mohanohi> my software runs only using single core.. it is not built for multi core..
<amitk> it shouldn't make a difference, the app should just work
<mohanohi> speed..
<mohanohi> my each core is off 900mghz
<mohanohi> it only uses 900 :(
<amitk> you'd have to change your app to use threading for that
<mohanohi> i am using aqsis, an open source renderman renderer.
<mohanohi> its the only one .. :(
<mohanohi> you think it is not possible at kernel level to make the entire operating system think quad core as one processor?
<mohanohi> i think, its crazy idea..
<alex_joni> mohanohi: no you can't
<mohanohi> alex_joni: oh ok.. thanx for the info :)
<alex_joni> if there's only one process, that runs on one processor
<alex_joni> if you have 4 processors (cores), then you need a multi-threaded app to take advantage of that
<mohanohi> ok..
<mohanohi> i think i have to submit the job 4 times..
<amitk> submitting the job 4 times will start 4 _different_ processes that don't share the data
<amitk> mohanohi: to share data, the app needs to be multi-threaded
<mohanohi> amitk: its not like that..
<mohanohi> rendering a batch of 10 frames x 4
<mohanohi> yeah shading of data is not done.. but it utilizes my all cores..
<mohanohi> hope the developer makes it multi-threaded..
<tom3p> hello, i read that many usb devices are flawed and that kernel 2.6.8 has fixed this (worked around it). 
<tom3p> ï»¿Where can I find more information.
<tom3p> ï»¿I hope to patch 2.6.4-16-rtai to allow same fix.
<ivoks> there are rumors that 2.6.32 has ext4 bug/issue that impacts postgresql and apache performance
<ivoks> this is the commit:
<ivoks> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5f3481e9a80c240f169b36ea886e2325b9aeb745
<ivoks> (haven't tested it yet)
<mcgrof> anyone aware of upstart changes which would prevent booting older kernels?
 * mcgrof pokes at code
<johanbr> mcgrof, not sure about upstart, but newer udev won't work with older kernels
<mcgrof> johanbr: oh I see thanks
<mcgrof> yeah the upstart README indicatest kernels >= Linux 2.6.24 are supported
<mcgrof> johanbr: what about udev is screwy with older kernels
<johanbr> I don't remember the details, unfortunately...
<mcgrof> johanbr: ok thanks though I'll ask Mr google
<BUGabundo> evening
<BUGabundo> $ pastebinit /var/log/kern.log http://paste.ubuntu.com/357273/
<BUGabundo> Jan 15 21:58:02 BluBUG kernel: [    9.590629] Call Trace:
<BUGabundo> Jan 15 21:58:02 BluBUG kernel: [    9.590631]  <IRQ>  [<ffffffff810c4cfb>] __report_bad_irq+0x2b/0xa0
<BUGabundo> Jan 15 21:58:02 BluBUG kernel: [    9.590641]  [<ffffffff810c4efc>] note_interrupt+0x18c/0x1d0
#ubuntu-kernel 2010-01-16
<leleobhz> im trying to compile a custom kernel (to apply reiser4 patch), but everything i do i get a abi error
<leleobhz> tryed:
<leleobhz> skipabi=1 AUTOBUILD=1 dpkg-buildpackage -rfakeroot -ai386 -Tbinary-debs
<leleobhz> and skipabi=1 arch=i386 AUTOBUILD=1 fakeroot debian/rules binary-debs
<leleobhz> what im doing wrong?
<osmosis> can someone help me getting ati proprietary drivers installed?
<MTecknology> so when I do git tag -l, I see a massive list; I'm not sure which the latest is...
<MTecknology> I'm guessing this isn't the latest Ubuntu-2.6.31-9.29
<MTecknology> or is it? I'm jsut thrown off by numbers like Ubuntu-2.6.31-401.2
<MTecknology> oh... those are big for that reason
<crimsun> different arches.
<MTecknology> oh, thanks
<leleobhz> same abi problem with: MAKEFLAGS="V=1" CFLAGS="-m32" skipabi=1 AUTOBUILD=1 dpkg-buildpackage -rfakeroot -ai386 -Tbinary-generic
<crimsun> MTecknology: also, Ubuntu-2.6.32-10.14 is the latest x86-series one
<leleobhz> make[1]: ** [abi-check-generic] Error 1 || make: ** [binary-generic] Error 2
<leleobhz> someone have a suggestion?
<MTecknology> crimsun: thanks - I completely forgot that 10 shows up above 9 :P
<MTecknology> error: pathspec 'Ubuntu-2.6.32-10.14' did not match any file(s) known to git.
<MTecknology> crimsun: I'm back on Karmic btw
<MTecknology> crimsun: Ubuntu-2.6.31-10.35 ?
<crimsun> hmm?
<crimsun> e.g., git tag --contains de383e
<crimsun> (that would be "UBUNTU: SAUCE: move RLIMIT_CORE pipe dumper marker to 1")
<MTecknology> crimsun: It doesn't look like Ubuntu-2.6.32* is in the karmic branch
<crimsun> oh, karmic
<crimsun> right, karmic won't have it
<crimsun> 8 days agoUbuntu-2.6.31-18.55
<MTecknology> crimsun: I vote for new numbering... 0001, 0002, 0003..... :D
<crimsun> that would be really awkward
<MTecknology> ya... but it wouldn't confuse the novice/beginner such as me
<crimsun> why would 17.54 -> 18.55 be more confusing than 0001 -> 0002 ?
<MTecknology> easier to see the end in a list :P
<crimsun> eh
<crimsun> there are any number of ways to more intuitively do that, e.g., git tag -l Ubuntu* | sort -V
<crimsun> (I am not a git guru)
<MTecknology> I forgot the sort command... thanks
<dr_gogeta86> hi to all
<freinhard> hi!
#ubuntu-kernel 2010-01-17
<osmosis> i just had a server crash, appears to have been kernel related. i dont see anything in the logs. AHCI interrupts started climbing and then the box froze. Any crash dump info I can locate ?
<osmosis> using  2.6.24-26-server #1 SMP  on hardy LTS 32bit
<osmosis> i just had a server crash, appears to have been kernel related. i dont see anything in the logs. AHCI interrupts started climbing and then the box froze. Any crash dump info I can locate ?
<MTecknology> So... when menuconfig says "This enables support for systems with more than one CPU." does this include single proc dual core?
<RAOF> Yes.
<MTecknology> thanks
<dhillon-v10> MTecknology, hi there, you seem to be building a lot of kernels in the past days :)
<MTecknology> dhillon-v10: ya... ricing the crap out of it
<MTecknology> dhillon-v10: I also have a ~12sec boot :P
<dhillon-v10> MTecknology, nice :) that's pretty good, custom kernels give out a lot of performance
<MTecknology> ya, changing processes and a lot of other things helps too
<dhillon-v10> MTecknology, if you want to get involved in kernel development, you should keep on making custom kernels until you can do one eyes closed :) then you can start writing patches and such
<MTecknology> dhillon-v10: I could probably do it without a monitor - not eyes closed, my typing sucks
<dhillon-v10> MTecknology, nice :) 
<MTecknology> dhillon-v10: I've trimmed off over 60% of the default kernel, long ways to go until it's perfect though :P
<dhillon-v10> MTecknology, that's pretty good, there's is this book called Understanding the linux kernel you should read it, its pretty awesome and tells you a lot of info. (only if you have some time)
<MTecknology> I downloaded book- title sounds familiar; I have about 2,000 pages left I want to get through this weekend but I don't think I'll make it
<dhillon-v10> MTecknology, I haven't had the time to read it all, still in the process of reading it
<dhillon-v10> MTecknology, gotta go bye and good luck
<MTecknology> yup, ttyl
<leleobhz> compiling 2.6.31/karmic with patches applied i got abi-error: http://pastie.org/781743
<leleobhz> someone know what is wrong?
<Deiu> Hello!
<MTecknology> hi
<Deiu> I'm looking for a channel dedicated to kernel development (especially the networking part). 
<Deiu> Could someone please point me in the right direction? :)
<MTecknology> Deiu: there's #kernelnewbies on OFTC
<Deiu> MTecknology, thanks, I just found it as well.
<zhbvgt> http://www.pandamailer.de/?bettel=pimbolli
<groo_> hi/2 all
<groo_> who is responsible for backport in 2.6.32-10?
<groo_> latest -10 backported ath5k from 2.6.33 which broken ath5k with some cards (mine included), it gives an EEPROM error... patch is upstream and should be out for next linus RC
#ubuntu-kernel 2011-01-10
<hallyn> has anyone already complained about latest natty kernel upgrade with respect to broadcom wireless and nvidia?
<smb> hallyn, Sort of Henrik was running into it (at least broadcom) when he was around Andy
<smb> hallyn, So nvidia has the same wrapper problem?
<hallyn> smb: don't know if it's the same.  on first login it told me i couldn't run unity, but then i coudl run it by hand, and on another attempt to instal lkernel, I got:
<hallyn> run-parts: executing /etc/kernel/postinst.d/nvidia-common 2.6.37-12-generic /boot/vmlinuz-2.6.37-12-generic
<hallyn> /etc/kernel/postinst.d/nvidia-common: line 8: [: too many arguments
<hallyn> sound like nvidia-detector is bogus i guess
<smb> yeah that at least for a starter sounds like something not correctly catched in the script
<hallyn> oh, haha - i have intel graphics.  weird
<elm_> how to do a make install for all kernel modules?
<smb> hallyn, So at least that would not be your problem with unity then. )
<smb> :)
<hallyn> smb: at any rate, i'm having to tether right now...  should i file a bug, or is Henrik on top of it?
<smb> For the broadcom problem afaik he had a patch ready and just needed to bring it on
<hallyn> well lemme reboot one more time :)
<hallyn> oh, cool
<hallyn> thanks
<elm_> make install does not install my radeon kernel modulewhat can I do?
<towolf> hello. here's something i donât understand concerning wireless regulatory domains. my regdomain is as such: http://paste.ubuntu.com/552544 but iâm still getting this least common denominator world domain: http://paste.ubuntu.com/552526
<towolf> is this an ubuntu specific thing? on my openwrt i get the officially approved channel configuration.
<teamnoir> I'm getting: "fatal: The remote end hung up unexpectedly" when I try to git a copy of the kernel.  Is the git server messed up?  Or am I doing something wrong?
<ohsix> towolf: what wifi hw?
<towolf> iwlagn 5000 series
<towolf> on natty
<ohsix> ah hm, dunno; does it have an eeprom that sets the region? cuz those can get in the way
<towolf> could it be that the crypto verification of the regdb doesnât work at all? this is just a hunch though.
<towolf> ohsix, shouldnât be. and if at all it should be overridden.
<ohsix> if you can see it in iw get it's already been applied i think, you can check in dmesg for crda's/the kernels message that it loaded the regulatory info
<towolf> yes, it did apply it, but that isnÃt reflected in the channel list.
<ohsix> read the regulatory compliance stuff on the kernel.org wireless section; generally the regdb complements the eeprom and the compliance
<towolf> ohsix, on my openwrt the eeprom says US, but then openwrt overrides that and sets DE.
<ohsix> they have hacked up stuff :] and i dunno if they even use crda
<towolf> yes, they do. and there i can even use /sbin/crda, on natty it fails with -22, which iâve read is due to failed signature verification.
<ohsix> hrmph, that sucks
<ohsix> i wish they'd use openssl instead of gcrypt in the ubuntu package, so you can just drop in your own signing certificate instead of having to rebuild it
<towolf> ohsix, how would i do that? and by the way, the regulatory.bin has identical SHA1 on kernel.org, on natty, and in openwrt. somethign else is going awry
<towolf> essentially "iw reg set" has no effect, but it doesnât fail, and that puzzles me.
<ohsix> try iw reg set US and look in dmesg; it should show it changing the regdomain
<towolf> yes. it shows it. but then "iw phy0 list": no change at all. still world regdomain.
<ohsix> that might be an eeprom thing, crda doesn't change what the card does; it just applies channel policies on top of it
<towolf> can i query eeprom to see whatâs in there?
<ohsix> i don't have an iwlwifi device in front of me, but there's usually a tool to poke at the eeprom parameters
<towolf> ooh. you might be right and this is iwlwifi specific. just cross-checked with b43 driver.
<towolf> and that works.
<\sh> guys, is there an easy way (which could be done e.g. via break=premount into initramfs) to debug a kernel network module, and why so ever it take ages to initialize?
<lamont> apw: any estimate on when bug 693401 will hit hardy-updates?
<ubot2> Launchpad bug 693401 in linux (Ubuntu Hardy) (and 1 other project) "hardy kernel lacks support for ICH10 controller in Intel Server System SR1600UR (affects: 1) (heat: 238)" [Wishlist,In progress] https://launchpad.net/bugs/693401
<bjf> lamont, am looking into it
<lamont> ta
<bjf> lamont, it looks like it has been applied to the tree and we are at the beginning of an SRU cycle, it "should" hit -updates in 2 weeks
<lamont> awesome
<lamont> that's the blocker for 2 reasonably phat ppa builders
<virtuald> for someone in my loco channel (she /quit), with the latest maverick kernel she said, the kernel didn't recognize her phone when plugged in with a usb cable, and there was no mention of usb dmesg (http://paste.ubuntu.com/552589/). when she tried with the previous kernel it worked.
<virtuald> anyone know how that could be?
<Q-FUNK> wrt bug #396286 exactly what is the point of not attempting to backport ext3/ext4 fixes to Lucid?
<ubot2> Launchpad bug 396286 in linux (Ubuntu) (and 1 other project) "[Geode LX] [ION603] kernels >= 2.6.31 fail to boot [initramfs] (affects: 2) (heat: 15)" [High,Won't fix] https://launchpad.net/bugs/396286
<kees> smb: should linux-ec2 in -proposed be promoted to -updates yet?
<smb> kees, I think I did test that ok. So I would promote it
<kees> smb: okay, thanks
<virtuald> did you guys see my question? what should i ask for the next time she comes online, more than ubuntu-bug linux? i don't think she's the bisecting typeâ¦ unless the problem persists
<JFo> virtuald, what bug are you referring to?
<virtuald> jfo: no bug#
<JFo> then I am not sure to what you are referring
<virtuald> 22:41 < virtuald> for someone in my loco channel (she /quit), with the latest maverick kernel she said, the kernel didn't recognize her phone when plugged in with a  usb cable, and there was no mention of usb dmesg (http://paste.ubuntu.com/552589/). when she tried with the previous kernel it worked.
<virtuald> 22:51 < virtuald> anyone know how that could be?
<JFo> virtuald, not without a bug and the relevant logging (as supplied by 'ubuntu-bug linux))
<JFo> sorry, that first end-parens should have been a '
<virtuald> ok
<JFo> virtuald, that way we can see what information there is from her attempt to connect the phone
<JFo> it is possible there is some error
 * virtuald googles if there's some command line option to turn on usb debugging
<JFo> also, if her phone charges from the usb cable, I would be interested to see if it does that when plugged in
<JFo> virtuald, it would be helpful as well if she did a lsusb from the command line and attached that data
<virtuald> 8]
<JFo> that lsusb should be done when the phone is attached
<JFo> preferably
 * hallyn hopes that the upload to fix broadcom chips will be hitting natty archive soon...
<JFo> hallyn, me too :-/
<JFo> hallyn, I am told you should hassle tseliot to make sure it is happening :)
 * hallyn wonders where to find tseliot :)
<hallyn> JFo: do you have a workaround?
<ogra> JFo, why do you unassign people from bugs if you mark them fix released ? that steals their LP karma ...
<JFo> then LP karma is broken, becasue I remove them after I set it Fix Released
<JFo> hallyn, I don't
<ogra> JFo, but why do you remove them at all ?
<JFo> because once a bug is 'closed' there shouldn't be an assignee as far as I have been told
<ogra> well, its one thing that can turn people down ... its credit thats gone then 
<JFo> if you are a developer that really cares about karma......
<ogra> if its fix released why would it matter if there is an asignee
<ogra> many newcomers in the community do care about karma
<JFo> but they are not likely to be the ones fixing any of the kernels bugs
<ogra> why ? 
<JFo> seriously?
<JFo> were I to be a developer working on kernel bugs, I can't honestly say that karma would be the reason I would work bugs for Ubuntu.
<ogra> why wouldnt a teenie who wants to be a developer not file and fix a kernel bug he finds a patch for in some other distro for example
<ogra> karma is a thing to encourage people to contribute
<ogra> you and i might not care about it much ... community people do
<JFo> I guess I just don't see a Ubuntu Kernel Dev, Ted T'so or some Upstream level developer being all excited because his karma went up a few points.
<JFo> I supppose I am hindered by the high level of ability needed
<JFo> in order to solve the vast majority of these
<JFo> I could be wrong, and to be honest, I have almost no energy around the issue
<JFo> I'm just perplexed that it is, in fact, an issue
<JFo> I don't mean to imply that karma is useless, far from it
<ogra> i'm not talking about a ted t'so :)
<JFo> in other packages I am sure there is a bit of energy around it
<JFo> I just never have seen some teenager fixing kernel bugs.
<ogra> i'm talking about the teenage guy who does one of his first contributions and is excited
<JFo> I seriously doubt they are contributing in the kernel here rather than on the main kernel 
<JFo> but like I said, maybe I am wrong
<ogra> well, apparently the kernel team has its own bug policies (emmet just told me) so do as you like, i just noticed it and found it weird
<ogra> the bug control team has no policy to unassign closed bug
<ogra> s
<JFo> yeah, I work waaaaay outside of that
<JFo> well, time for a beer
#ubuntu-kernel 2011-01-11
 * achiang wonders if any of the kernel folks are awake and aren't enjoying themselves too much at the rally...
<cking> apw, do we have a k-t meeting today?
<ara> skaet, do you know why do we have two tracking bugs per release?
<ara> https://bugs.launchpad.net/ubuntu/+bugs?field.tag=kernel-tracking-bug
<ara> (different kernels)
<ara> is any of those no longer valid?
 * skaet looking
<bjf> ara, looking :-)
<bjf> ara, if you notice the abi is quite different, that's because some are for ec2 flavours
<bjf> ara, i'm trying to get to the kernel wiki page that has the ABI matrix but am experiencing technical difficulties
<bjf> ara, this page may be of minimal help: https://wiki.ubuntu.com/Kernel/Dev/ABIPackages
<skaet> ara, sconklin - are the kernels effectively 1 per SRU drop candidate?   When an SRU is released, the state should probably change to Released
<bjf> skaet, while you were disconnected i was responding :-)
<bjf> skaet, these are for regular and ec2 kernels
<skaet> bjf,  cool.  okie.
<bjf> skaet, https://wiki.ubuntu.com/Kernel/Dev/ABIPackages
<bjf> skate, ara, it's not obvious from the tracking bug, the only difference is the ABI numbers
<bjf> skaet, ara, we generate those tracking bugs with a tool, i'm modifying the tool to make the tracking bugs more obvious that they are for different kernels
<ara> bjf, thanks!
<m4t> hey, i put https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/673236 a few months ago
<ubot2> Launchpad bug 673236 in linux (Ubuntu) (and 2 other projects) "maverick toolchain producing unbootable (hanging) kernels (affects: 2) (heat: 63)" [Undecided,New]
<m4t> anyone know what the proper fix is?
<bjf> bdmurray, is there a LP api call that returns the version of the lpapi installed on the system and that the script is using?
<bdmurray> bjf: __version__ ?
<bjf> bdmurray, thanks
<hrw> hi
<hrw> natty's kernel has Vcs-Git: http://kernel.ubuntu.com/git-repos/ubuntu/ubuntu-maverick.git
<hrw> in debian.master/control file. should not it point to ubuntu-natty.git instead?
<sconklin> apw: ^^
<apw> sconklin, cheers, i owe you 1/1000th of a beer
<apw> i'll take it out of your ownings
<sconklin> apw: I'll die in beer debt
<sconklin> having broken a kernel AND the archive
<apw> hrw, thanks!  fixed!
<apw> sconklin, _a_ kernel, its not singular!
<hrw> apw: np
#ubuntu-kernel 2011-01-12
<cablop> the latest kernel is driving me crazy, sometimes it hibernates, sometimes just not
<cablop> would i change the hibernate module or something?
<czr> slightly OT, how do I regenerate initramfs in lucid using the current config? trying to add an aoe device to /etc/fstab for boot time mounting, but aoe module isn't loaded in time.
<czr> (stock kernel, nothing fancy, not even LVM)
<abogani> czr: I think that you should add the aoe in /etc/initramfs-tools/modules so regenerate initramfs image.
<czr> abogani, yes, but how to regenerate the initramfs-archive.
<czr> ah. update-initramfs.. silly me :-)
<czr> ah yes, the problem is more complicated. I need network up before mounting aoe :-).
<ogra> pgraner, http://forum.xda-developers.com/showthread.php?t=894960 that should get you going (very likely not upgradeable since it is based on the nvidia linux4tegra crap which is tied to karmic)
<JFo> cking, you about?
<cking> JFo, yep
<JFo> ah good :)
<cking> how can I help?
<JFo> as I know you are completely covered in work items, I was wondering about this bug 268035
<ubot2> Launchpad bug 268035 in linux (Ubuntu) "readahead-list null poiner dereferences (affects: 1) (heat: 3)" [High,In progress] https://launchpad.net/bugs/268035
<cking> JFo, ah, maybe it needs to be re-assigned. I foolishly looked at it and ran out of free cycles
<JFo> barring the fact that it has been spammed... was wondering if you wanted me to go through your assigned bugs and drop you from all the old ones, or if you were interested in remaining assigned to them
<JFo> no problem... everyone has :)
<cking> I'd prefer to be un-assigned
<JFo> ok, will do :-)
<czr_> is there a git for ubuntu kernel releases somewhere? something I could use to track whether certain reverts have been done and what the packaged kernel updates were at each point?
<JFo> thanks cking 
<cking> JFo, well, thank you :-)
<JFo> my pleasure as always :-D
<czr_> hmm. how likely is a bugfix being released with lucid kernel updates if the status of it in "linux (Ubuntu)" is "Fix released"? ( #544527 infact)
<czr_> having some kind of changelog of upcoming lucid kernel fixes would really be appreciated at this point.
<JFo> cking, one last question... can I assume that the change for bug 676997 will make it over into Natty? My impression is yes. :-)
<ubot2> Launchpad bug 676997 in linux (Ubuntu Maverick) (and 1 other project) "Volume keys don't function - mapped to WMI events and requires driver support (affects: 1) (heat: 71)" [Undecided,Fix released] https://launchpad.net/bugs/676997
<JFo> my assumption is that the main task simply didn't get Fix Released.
<cking> JFo, it's dependant on a WMI core getting upstream'd but if not, we should put it into natty - but that requires a little more work
<JFo> ah, I see
<JFo> I'll leave that one alone then
<cking> JFo, I will get back to it, probably next week or so once I've sorted out a S4 issue :-(
<JFo> no problem
<JFo> I want to leave the new ones you are working alone
<JFo> I just wasn't sure if that one was only needed in Mav
<czr_> found the proper git and found out that none of the bugs are referred there, so all my questions are moot now.
<RAOF> JFo: Bug #702125 will shortly be landing in your queue; it's an intel drm patch committed to -fixes.  We just need to make sure it gets in at some point.
<ubot2> Launchpad bug 702125 in linux (Ubuntu) "[PATCH] drm/i915/sdvo: Defer detection of output capabilities until probing (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/702125
<JFo> RAOF, thanks for the heads up
<JFo> I'll add it to my list
#ubuntu-kernel 2011-01-13
<AnAnt> Hello
<pmatulis> how can i more info on what's happening at the kernel level during the shutdown process?  i have a system that sometimes hangs at the very end of the shutdown
<cking> pmatulis, it could be that acpi S5 shutdown fails.
<pmatulis> cking: any way to get extra kernel debug logs (to a file)?
<pmatulis> cking: i see that if i use boot option '--debug', stuff does end up in /var/log/debug, but this seems more for services
<cking> well, one could try and bypass this by using apm to shutdown (which is ugly workaround).  I generally shove debug into the kernel at this point to see why it's not working. 
<pmatulis> cking: your debug different than mine?  ;)  (or special debug kernel?)
<cking> pmatulis, try kernel parameter "apm=power-off"   (I've never tried this) 
<cking> this should shut the machine down using the old BIOS APM mechanism.
<pmatulis> cking: also, this is wubi.  some special shutdown issues can arise?  (releasing the underlying file?)
<mjg59> cking: Wurgh. I'm pretty sure we'll refuse to touch apm if the system's booted with ACPI
<cking> mjg59, ok 
<mjg59> pmatulis: Does it work if it's booted raw (ie, non-wubi)?
<mjg59> pmatulis: There's some potential for things to go wrong during shutdown if / relies on fuse stuff that's no longer there
<pmatulis> mjg59: not sure, customer system
<cking> yep, factor out the wubi complexity first
<pmatulis> is there a special debug kernel somewhere?
<cking> pmatulis, no, we generally have to ask a kernel engineer to cruft one up.
<pmatulis> cking: k
<cking> apw, ^ any chance of generating a debug kernel for pmatulis?
<JFo> hi skaet :-D
<skaet> hi JFo,  no bug list for you yet, ;)
<JFo> :-) I thought not... I suspect you, much like me, got caught up in tons of other stuff
<JFo> no problem :-)
<skaet> will plan on hiding out somewhere this afternoon, and see what interesting things I can find...  :P
<JFo> ok :)
<JFo> skaet, you know... I'm ok if you don't find any too :-P
<skaet> lol,  indeed.
<ekoore> hi to all
<ekoore> i have a question
<ekoore> in what way i can disable a interrupt in the kernel?
<ekoore> can you help me?
<JFo> hi ekoore 
<JFo> may be a while before someone responds
<JFo> we are all at a series of meetings that last all week
<JFo> from what I am being told, there may be some sort of masking possible
<JFo> but it is difficult to answer off the top of the head
<ekoore> is possible disable  a interrupt of the kenrel, from grub?
<JFo> not that I am aware of currently ekoore 
<JFo> I can ask, but I am pretty sure the person who would possibly know is offline just now
 * JFo makes a note
<ekoore> is a long story
<ekoore> i have the file rc.local with a script that disable gpe11
<JFo> ok
<ekoore> rc.local is executte in the end of the boot process
<JanC> that's about ACPI interrupts?
<Kano> hi, are the changes files for the kernels stored somewhere?
<JFo> what do you mean exactly Kano?
<Kano> well when i only want to fetch a kernel from u repo it would be nice to parse the files
<JFo> what changes were added between kernels?
<Kano> no the changes file you get when you create a deb
<Kano> there you get checksum + names of the packages
<JFo> so the generated changelogs from the deb builds?
<Kano> basically signed, but i dont need the signed ones
<Kano> the changelog is there too yes
<Kano> or is there an extra repo only with kernels?
<JFo> hmmm, they should be available in Launchpad
<Kano> as ppa?
<Kano> i want something that i could parse...
<JFo> one sec...
<Kano> since the kernel does not disable hpa by default i would not need to recompile em
<Kano> i hated that default
<JFo> it will be in the build directory as a link
<JFo> from launchpad.net/ubuntu/+source/linux
<Kano> the the build dir always the same?
<bjf> Kano, does http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/annotate/head:/sru-report show you how to do what you want?
<JFo> well, you would select the specific build you want from there
<Kano> i want to write a script that fetches the latest kernel only
<Kano> this time the ones for natty
<Kano> but no udebs
<Kano> and i only need the generic(-pae) ones
<kamal> Kano: you can get the .changes file this way:   https://launchpad.net/ubuntu/+source/linux  , then click the arrow next to the kernel version under "The Natty Narwhal",  then select one of the builds (amd64, armel, i386) ...
<kamal> Kano: that'll take you to a page e.g. https://launchpad.net/ubuntu/+source/linux/2.6.37-12.26/+build/2125796  which has a link to the .changes file itself.
<Kano> ah there are the changes
<kamal> Kano: yeah, launchpad sure makes you work to find that :-)
<Kano> well not really optimal for scripts...
<Kano> click there ;)
<kamal> Kano: agreed
<Kano> it would be too simple when the changes files would be uploaded
<Kano> in the repo
<Kano> hmm i think i can parse it
<Kano> when the website will be still the same...
<Kano> wget -qO- https://launchpad.net/ubuntu/+source/linux|grep listing-archive-extra|head -1|sed 's/href=//;s/"//g'|wget -B https://launchpad.net -i- -qO-|grep \\.deb  
<Kano> something like that a bit more optimized then
<Kano> thx
#ubuntu-kernel 2011-01-14
<Kano> is there something wrong with fglrx + u 37-12 kernel?
<Kano> all i get is a crash
<Kano> with 37 mainline it works
<jjohansen> Kano: which 37 mainline?
<jjohansen> ie. how recent?  What is the head?
<Kano> yes 37 mainline kernel compared to 37-12
<jjohansen> Kano: right, but how recent is the mainline?
<Kano> well i did not test ubuntu, i tested with debian squeeze
<Kano> 2.6.37 final
<Kano> the u precompiled one
<Kano> will check nvidia tomorrow, but fglrx never worked
<Kano> http://kanotix.com/files/hellfire/ubuntu/
<Kano> thats that i used
<Kano> test system was i7-880 with hd5670 64 bit
<Kano> nothing changed expect kernel, .37 mainline works...
<jjohansen> Kano: hrmmm okay, I am not aware of any issues but I haven't been following the video drivers closely
<jjohansen> I'll poke apw and see if he knows anything
<Kano> maybe i install u tomorrow too
<Kano> but thats really curious
<jjohansen> Kano: yeah it is, what behavior did you see?
<Kano> crash on load of kdm
<jjohansen> black screen on boot, purple ubuntu screen
<Kano> i tested it with debian squeeze currently
<Kano> but u kernel
<Kano> + firmware+wireless-crda
<jjohansen> right, I recalled after the puple ubuntu screen Q
<jjohansen> so none of the crazy plymouth boot issues
<Kano> well i have got plymouth installed,but p works with mainline too
<Kano> it does not matter if i disable it or not
<Kano> using oss ati driver x works
<Kano> basically i thought i could use u kernel now without recompile, i always disabled your hpa hack
<Kano> but that was reverted for -12 kernel... so i wanted to try it
<jjohansen> ah, well I'm not sure why it isn't working, especially with mainline .37 working
<Kano> well the gcc is definitely different which is used
<Kano> i can install mainline kernel even with lenny
<jjohansen> Kano: which mainline did you use?
<jjohansen> ie who built it
<Kano> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.37-natty/
<jjohansen> okay, that should be the same version of gcc
<Kano> the linux headers install with lenny libc6
<Kano> but not the natty ones
<Kano> so gcc is different
<jjohansen> hrmmm /me is puzzled, our mainline kernels should be using the same build env
<Kano> they dont use pbuilder
<Kano> i really like the mainline kernels because of the backwards compat
<Kano> you have to disable modeset then you can use em with lenny too
<jjohansen> ah nice, I wasn't aware they were that backwards compatable
<Kano> only when you know what you do ;)
<Kano> the hardy gcc is used, hardy is mainly compatible with lenny
<Kano> Linux version 2.6.37-020637-generic (root@zinc) (gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)) #201101050908 SMP Wed Jan 5 10:17:13 UTC 2011
<Kano> from cat /proc/version
<lamont> I'm going to guess that seeing something on 3 different machines with three (or is it 2?) different types of hardware makes it likely to be in the kernel, not the individual hardware...
<lamont> when I hit the disk drive really hard, the swraid devices seem to decide that one of the drives has failed (usually complaining about a timeout in SCSI).. rebooting the machine magically restores everything to hunky-dory status
<lamont> lucid and maverick kernels, fwiw
<Kano> and pure mainline too?
<lamont> haven't looked
<lamont> lacking a machine to test on
<lamont> I may have to eat my words... the most recent failure may well have been a controller falling over
#ubuntu-kernel 2011-01-15
<bullgard4> [Ubuntu 10.10] dmesg reports: "EXT3-fs (sda7) recovery required on readonly filesystem." What does this mean?
<mjg59> You mounted a filesystem read-only, but replaying the journal required modifying the filesystem anyway?
<bullgard4> I don't think that you answer covers my situation: '~$ mount; /dev/sda7 on / type ext3 (rw, relatime, errors=remount-ro, commit=0)'
<bullgard4> s/you/your/
<mjg59> If it's / then it's initially mounted read-only
<mjg59> It only gets mounted rw later in the boot process
<bullgard4> Thank you for explaining.
<htorque> hello everyone! i cannot change the brightness level of my notebook's panel while plymouth is showing the theme.
<htorque> this happens with my integrated intel graphics but not with the dedicated nvidia gpu - is this a kernel bug? if it is, should i rather file the bug upstream (freedesktop/kernel? which component - i915?)?
#ubuntu-kernel 2011-01-16
<ScottL> in testing the ubuntu studio alternate image i've noticed quite a few kernel panics that i haven't experience in the past, is this a known issue for others as well?
<apw`> ScottL, what kernel does that image have in it
<dgtombs> hello all. i have no experience with kernel bug triage, so would someone mind taking a look at <https://bugs.launchpad.net/ubuntu/+source/linux/+bug/569812>? it seems there is a patch available for it but the bug has been ignored
<ubot2> Launchpad bug 569812 in linux (Ubuntu) "4G XS Stick W14 UMTS USB stick is not recognised as a UMTS modem (affects: 1) (heat: 20)" [Undecided,Confirmed]
<ScottL> apw`, after i take my dogs outside i'll check on the kernel version
<ScottL> apw`, i haven't been able to get a full ubuntu studio install but checking the build logs it appears to be: linux-image-2.6.37-12-generic
<ScottL> apw`, i would like to mention something about "[apw] document how to build a new derivative flavour/branch:TODO" from https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-version-and-flavours
<ScottL> apw`, as ubuntu studio project lead i wanted to mention that we don't expect an -rt kernel to be in the repositories again because of the misalignment of the available -rt patch and kernel version ubuntu uses for any particular release
<ScottL> apw`, however, our goal is to get a -lowlatency kernel into the repositories
<ScottL> apw`, abogani currently maintains such a kernel which is based on the default ubuntu -generic kernel without *any patches*, he maintains that it _only_ requires compile time flag changes
<ScottL> apw`, i don't know who else has design on new kernel flavours, but hopefully this information may make your this task easier
#ubuntu-kernel 2012-01-09
<brendand> can anyone tell me to what extent i can rely on /sys/power/state to tell me what sleep states are supported?
<brendand> any chance it may be deprecated?
<joshhunt> is there a location where i can always find the ubuntu diff for the current release's kernel? ie the 3.0.0-15.25.diff
<joshhunt> i seem to remember seeing this on pages like this https://launchpad.net/ubuntu/+source/linux/3.0.0-15.25 in the past, but i'm no longer seeing it
#ubuntu-kernel 2012-01-10
<notmwp> hey folks, could use some help with dmraid and kernels 3.1 and 3.2 on oneric, thanks in advance
<notmwp> specifically, oneric finds my intel fakeraid on stock kernel (3.0.0-14), but when I install 3.1.2 or 3.2.0 from kernel-ppa, it does not
<notmwp> I have a lot more information including some online discussion threads but don't want to spam the window :) 
<notmwp> hmm, looks like the 3.2 config is missing the "Ubuntu Supplied Third-Party Device Drivers" section, which includes a line to build the dm_raid45 module 
<notmwp> I'm assuming it's also missing some patches to enable these drivers... you guys must wait until late in the kernel release process to add that back in
<notmwp> aaaand looks like stefan bader is still reviewing dmraid45 for the precise alpha kernel
<Kurdistan> hi. is this the place to find ubuntu specific patches for kernel? http://patchwork.ozlabs.org/
<Kurdistan> if I am using ubuntu 11.10 is it possible to install kernel from 12.10 from http://packages.ubuntu.com/ like 3.2*?
<Kurdistan> anyone?
<jk-> Kurdistan: you're better off looking at http://kernel.ubuntu.com/git to see what's in the ubuntu kernel, rather than patchwork
<jk-> Kurdistan: specifically, the ubuntu/ubuntu-{natty,oneiric,precise} trees
<Kurdistan> jk-, thx. example: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.1.8-precise/
<Kurdistan> the patch in that there is that all the patches that are used for that kernel?
<jk-> Kurdistan: so those are the mainline kernel builds (ie, no ubuntu-specific stuff)
<Kurdistan> kernels in mainline har vanilla
<jk-> yep, exactly
<Kurdistan> jk-, so does patches there are does patches ubuntu uses for 3.1.8?
<jk-> Kurdistan: there is no ubuntu kernel for v3.1.x
<Kurdistan> I am thinking download from kernel.org and wanted to know were I easily can find ubuntu specific patches without beeing lost.
<Kurdistan> :)
<jk-> oneiric is 3.0, precise is 3.2
<jk-> Kurdistan: ok, what are you trying to get done?
<Kurdistan> jk-, is it possible to make pricise 3.2 work in oneric?
<jk-> Kurdistan: yeah, should be
<Kurdistan> I wanted to build newer kernel for 11.10 with ubuntu specific patches
<Kurdistan> otherwise I know how to install kernel from mainline
<jk-> ok, if you don't need to modify anything, I'd just suggest installing the precise kernel
<Kurdistan> but I also wanted to have the patches
<jk-> Kurdistan: and if you want to see patches, just clone the ubuntu-precise git tree
<Kurdistan> jk-, :) I do not know how to handle git.
<jk-> Kurdistan: two-step git introduction:
<jk-> git clone git://kernel.ubuntu.com/ubuntu/ubuntu-precise.git
<jk-> cd ubuntu-precise
<jk-> gitk
<jk-> ok, three-step :)
<jk-> .. or just browse on http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-precise.git;a=shortlog
<ohsix> you can just get the diff too, a bit hard to read unapplied though ;]
<Kurdistan> jk-, :) the link what should I download?
<jk-> Kurdistan: not sure I understand that question
<Kurdistan> jk-, you gave me the link. is it something I should download to understand?
<Kurdistan> or is the patches in that link for specific kernel?
<jk-> Kurdistan: no, that's just a page that displays the git history of the precise kernel, including diffs
<jk-> however, if you're just looking to install a 3.2 kernel, you probably don't need to look at any of that
<Kurdistan> jk-, okey I see.
<jk-> meta-question: why do you want a 3.2 kernel?
<Kurdistan> jk-, I am using 11.10.
<Kurdistan> jk-, :) I wanted to learn how to have newer kernel for 11.10.
<Kurdistan> thats all.
<jk-> Kurdistan: i know a couple of folks running the precise kernel on 11.10
<jk-> Kurdistan: if you want bleeding-edge, you could try installing precise anyway  :)
<jk-> I hear it's pretty stable now
<Kurdistan> http://packages.ubuntu.com/ should I then download kernel-image for 3.2 here?
<ohsix> you can run the mainline kernel builds that are built all the time too
<Kurdistan> jk-, hehe no no. I wanted to have 11.10 only intressting in newer kernel.
<Kurdistan> only have 1computer
<Kurdistan> ohsix, mainline do not have ubuntu patches. does kernel are vanilla.
<jk-> yeah, installing the precise kernel will give you better results than installing a mainline kernel
<Kurdistan> jk-, exactly.
<Kurdistan> :)
<Kurdistan> jk-, but are precise kernel specific for precise or does it screw up if I use it for oneric?
<jk-> Kurdistan: well, it *should* work, but it's not something that gets much testing
<jk-> there may be some incompatibilities between the kernel and userspace
<Kurdistan> jk-, I understand. so I should download kernel-image from http://packages.ubuntu.com/ ? what more?
<Kurdistan> jk-, :) okey it seems to not be problem free to upgrade kernel.
<njin> hello guys, i'm forwarding upstream a the BUG: unable to handle kernel NULL pointer deference at    (null), but i don't know under wich category report it, can you halp?
<njin> tThanks
<njin> Under drivers or under other ?
#ubuntu-kernel 2012-01-11
<jmlowe> I think I have found a bug in 3.2, I'm not sure how to proceede
<jmlowe> When I switch from the 3.0.0-14 from 11.10 to the one here http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2-precise I see a 265000% performance hit with my hp p800 raid controller using the cciss driver as measured by hdparm
<_ruben> jmlowe: hdparm isn't the right tool for determining performance, use bonny++/iometer/etc instead .. though 265000% is rather "impressive"
<ohsix> or palimpsest's builtin tests :]
<ohsix> (called Disk Utility in the menus under administration)
<ohsix> but yea you don't often use a disk without a filesystem so they are often more relevant types of tests
<czajkowski> apw: you about?
<brendand> apw - so what does it mean that the intel_iommu=off did the trick for that server? 
<brendand> https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/907377
<ubot2`> Launchpad bug 907377 in linux "HP ProLiant DL360 G6 has debootstrap errors during install of Precise Alpha 1" [High,Triaged]
<apw> brendand, means its a config option thats triggered it, one changed in precise.  we're reporting it now
<czajkowski> I'm having some images looking rather corrupt on Precise - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/914167
<ubot2`> Launchpad bug 914167 in linux "application images on system seem corrupted " [Undecided,Incomplete]
<jmlowe> _ruben: ack, but it should be a bit more stable, with i/o less than 100KBs measured by iotop and iostat, my raid controller acts like my pcie bus turned into a dsl line, I've got uninterruptible waits left and right and load north of 100, proper benchmarking tools will tell me what I already know
<_ruben> jmlowe: that's important details you didn't mention before :)
<jmlowe> _ruben: I have also since found that it is triggered by something and fixed by a reboot untill the next trigger, haven't determined what the trigger is exactly
<jmlowe> hey there is something "sched: RT throttling activated"
<vi390> is there anything known about if touchscreen drivers specific for Dell st2220t are in 3.0.0-14 kernel? (https://groups.google.com/group/fa.linux.kernel/browse_thread/thread/51eb74dac9866a4f/7c7e23afdee025e8?lnk=gst&q=Dell+ST2220T#7c7e23afdee025e8) is it still in there?  might have get removed, and how can I check that?   
<vi390> i need kernel 3.0.0-14.23 in apt it only says 3.0.0-14without the sub version. How can I be shure to get a .23 version?   I need this included https://bugs.launchpad.net/ubuntu/+source/linux/+bug/791833
<ubot2`> Launchpad bug 791833 in linux "Dell ST2220T Monitor responds to touch only on warm boot from windows" [Undecided,Confirmed]
<vi390> ooh, ok its the hashed number I guess, so i have the #23 already :)
<colorx> help hac x
<colorx> hac as
 * colorx Fatal error: Call to a member function setTitle() on a non-object in /home/cssmenum/public_html/builder/step1.php on line 77
#ubuntu-kernel 2012-01-12
<LetoThe2nd> good morning! i'm seeing a interesting issue at the moment: everytime i get my box back from s2ram, it then goes into heavy thrashing (load 8 and above) for about 30minutes, before settling down to the usual load < 1 and being usable again.
<LetoThe2nd> system is lubuntu 11.10, no special kernel, / fs is on btrfs spanning two devices. all updates installed, no very special workload (1x vbox, chromium, thunderbird, libreoffice, some terminals)
<LetoThe2nd> any ideas or additional information requests maybe?
<czajkowski> anyone running precise notices when you shut down machine and go to use it again battery is flat and machine never sut down?
<jnorman> Hello! Does anyone here know the easiest way to track what issues that has been patched between kernel 2.6.24-24-server and 2.6.24-30-server on Hardy?
<lamont> anyone around who can talk to me about the "arm mmap" fix?
<lamont> specifically, I need to know which version of the kernel package has the fix in lucid/maverick/natty...
#ubuntu-kernel 2012-01-13
<aashez> I'm using Ubuntu 11.04 on Packard Bell EasyNote NM85. After recent installtion, I'm getting error while botting as - udevd[398]: worker [82] unexpectedly returned with status 0x0100 - same for [83] [84] followed by - '/devices/pci0000:0d/0000:0d:0b.0'. I did not make any chnages in settings wrt system before the error. How can I fix this?
<aashez> I observed errors related to kernel before that I had to reinstall. Even now I guess the errors are related to kernel
<SpamapS> Packard Bell?!
<aashez> Yes
<aashez> I see some Packard Bell notebooks in Hardware compatibility list
<SpamapS> Oh, they still make stuff
<SpamapS> I thought they died years ago
<aashez> What I got is an old one. Well, is there any to find boot logs ? I can insert LiveCD and try to pastebin the exact errors ...
<SpamapS> sorry I'm no expert w/ such things. :-P
<aashez> Ok. The errors are close to what this link gives in first post - https://bugzilla.novell.com/show_bug.cgi?id=609338
<ubot2`> bugzilla.novell.com bug 609338 in Basesystem "cpqphp: NULL ptr deref in cpqhpc_probe+0x951/0x1120" [Normal,Resolved: duplicate]
<aashez> Is there any way to confirm whether the hardware of a system is compatible with linux installation apart from referring https://wiki.ubuntu.com/HardwareSupport/Machines/Netbooks
<aashez> ?
<josephliu> a16g, see my msg above... sorry that i type very slow. since it's difficult to type, on the phone.
<josephliu> a16g, also the driver atheros posted months ago on kernel mailing list is version 1.0.0.0. 
<josephliu> a16g, but the one we used now is 2.0.0.4
<tgardner> herton, you gonna do all of the recent stable updates?
<herton> tgardner: I think yes, at least that was brad's plan, we start taking the stable updates in
<tgardner> herton, ok, I'll leave you to it.
<jjohansen> tgardner: when are you going to upgrade tangerine?
<tgardner> jjohansen, I thought I'd wait until the archive isn't broken, but then I don't suppose libreoffice will have much of an impact. lemme give it a try...
<jjohansen> tgardner: okay, thanks
<LetoThe2nd> howdy! are there known issues with an uptodate 11.10/64b with S2RAM?
<LetoThe2nd> after resuming, it runs into heavy thrashing here (load well about 8), as opposite to after reboot and firing up the same tools resulting in a load far below 1
<tgardner> jjohansen, tangerine is updated. see last line in dmesg: sshd (2155): /proc/2155/oom_adj is deprecated, please use /proc/2155/oom_score_adj instead.
<jjohansen> tgardner: thanks
<aashez> Is there any way to confirm whether the hardware of a system is compatible with linux installation apart from referring https://wiki.ubuntu.com/HardwareSupport/Machines/Netbooks
<brendand> aashez - there's also the certification site ; www.ubuntu.com/certification
<brendand> aashez - neither of the pages tells you whether the system is compatible with the linux kernel in general though
<brendand> both are regarding ubuntu only
<aashez> I'm not sure if Packard Bell Easy note NM85 compatible or not
<aashez> Thanks for the link but it gives page not found on any further selection
<brendand> aashez - ergh :/ thanks for noticing. the links in the top table should work
<aashez> which top table?
<brendand> aashez - the one that lists by manufacturer. you can also use the filter results box on the right-hand side
<brendand> aashez - which release are you interested in?
<brendand> though i know for a fact we haven't certified the NM85
<aashez> brendand: Actually I installed 11.04 twice and had some errors after few days..
<aashez> kernel realted errors like https://bugzilla.novell.com/show_bug.cgi?id=609338
<ubot2`> bugzilla.novell.com bug 609338 in Basesystem "cpqphp: NULL ptr deref in cpqhpc_probe+0x951/0x1120" [Normal,Resolved: duplicate]
<aashez> I see very similar error as in the bug
<aashez> Which is what made me wonder if its hardware related problem
<aashez> brendand: Are you still there?
<brendand> aashez - yes
<aashez> Can you help me fix errors on boot like https://bugzilla.novell.com/show_bug.cgi?id=609338 ?
<ubot2`> bugzilla.novell.com bug 609338 in Basesystem "cpqphp: NULL ptr deref in cpqhpc_probe+0x951/0x1120" [Normal,Resolved: duplicate]
<aashez> Its ubuntu 11.04 on Packard Bell EasyNote NM85. I did chroot using LiveCD and tried to reinstall grub but no help
<brendand> aashez - afraid not
<Kurdistan> any one wake? :)
<Kurdistan> I got this error message
<Kurdistan> tried to compile 3.2.1 from kernel.org on ubuntu 11.10
<Kurdistan> Cache read/write disabled: /sys/kernel/security/apparmor/features interface file missing. (Kernel needs AppArmor 2.4 compatibility patch.)
<Kurdistan> I can not get apparmor patch from kernel.org
<Kurdistan> http://www.kernel.org/pub/linux/security/apparmor/ I can not find
#ubuntu-kernel 2012-01-14
<Kurdistan> hi again.
<Kurdistan> hi i tried to compile 3.2.1 from source. I downloaded it from kernel.org. After that I also downloaded kernel-ppa (mainline) patches for 3.2.1. After building the kernel I get error message about apparmor.
<Kurdistan> is there any apparmor patches?
<Kurdistan> The AppArmor v2.4 compatibility patches
#ubuntu-kernel 2012-01-15
<snadge> im so going to get flamed for this but anyway.. im running 12.04 on an 8150 bulldozer system
<snadge> great work by the way guys.. its rock solid :D
<snadge> but i want to undo your hard work by recompiling with bulldozer specific optimizations.. has anyone experimented with this, or can suggest if it will make any noticeable difference (percentage wise) with multicore compilation workload?
<snadge> eh.. i guess i'll just try it
<snadge> wtf.. i follow the ubuntu kernel build instructions
<snadge> and now its complaining that my build direectory "is not clean, please run 'make mrproper'"
<snadge> looking at the code.. it tests for the existence of .config or include/config .. and then errors if they exist
<snadge> even though the line before that creates include/config/kernel.release .. WTF!? :( *cries*
<snadge> and .config contains my customised configuration.. what am i doing wrong?
<snadge> im gonna start drinking alcohol in a minutes..
<snadge> i just patched that check out of the makefile (check for .config include/config)
<snadge> perhaps thats the official way to build an ubuntu kernel ;)
<snadge> other than that.. i followed the guide
<snadge> if my optimized kernel is significantly faster than the standard generic kernel.. i will be most annoyed
<snadge> release builds seriously have frame pointers and all the debugging options turned on? whut? :p
<snadge> how do i build the kernel-headers package.. if i've only built the "generic" flavour?
<snadge> theres like 100 people in here.. and nobody says anything :P
<Kurdistan> hi. when I try to apply patch ureadahead I got this message. http://paste.ubuntu.com/805394/
<Kurdistan> any one can help?
<Kurdistan> hi is it possible to run make menuconfig twice. first time I decided not to save the changes. then I run make menuconfig again and saved it now.
<Kurdistan> that will not effect anything?
<Kurdistan> I know adding same patch twice is not good. but what about running make menuconfig twice?
#ubuntu-kernel 2013-01-07
<ppisati> moin
 * smb yawns and starts actively ignoring lots of email
<cking> smb 47a133339c332f9f8e155c70f5da401aded69948
<cking> and also I need to try out c8b74c2f6604923de91f8aa6539f8bb934736754
<infinity> henrix: FYI, #1040557 could be hard to verify in anything other than quantal, given that it relies on booting in EFI mode, which we didn't support until Q...
<infinity> henrix: (Just noticed your comment on the bug asking to test it on oneiric)
<henrix> infinity: right, i took a look at the patch and didn't realised the 
<henrix> infinity: 'oneiric' part...
<henrix> infinity: thanks for the heads up
<infinity> (I'm not actually sure why we backported this back to 3.2 and 3.0, though it doesn't hurt to have it there either)
<infinity> cking: ?
<infinity> Oh, wait.  No.
<infinity> We support booting EFI mode on precise (and maybe oneiric).  I'm half asleep.
<infinity> But this bricking issue was only happening on Q kernels, wasn't it?
 * infinity shrugs.
<infinity> No harm either way, the patch is simple enough.
 * cking thought that prevention at all levels is better than bricking
<infinity> cking: Yeah, I'm not inclined to disagree.
<infinity> Just could be harder to validate this one than most.
<infinity> The weird catch-22 of "if it previously bricked machines, no one wants to test" (though, Samsung should be testing quantal for us there) and "if it didn't brick before, all we can verify is that your disabling bit worked" (oneiric and precise, I think).
<cking> infinity, indeed
<cking> who wants to test something that may brick one's machine?
<infinity> Pick me, pick me!
<smb`> donkey
<cking> as it was, we had jsalisbury did test this patch for me on a later kernel in the non-UEFI mode. the regression risk is really minimal
<smb> Obviously Samsung should test on their machines... they may even have some unbrick option... :-P
<cking> unbrick uption is "get a new motherboard"
<infinity> Well, "replcace the firmware" but, yeah, without bootstrap pre-firmware flashy bits (which either they lack, or their service centres don't know how to use?), it's a new motherboard for end users.
<smb> But the worst case we can get would be users whining about lost functionality on older releases. IF it ever did work without bricking
<infinity> I assume Samsung themselves fix it with a slightly less large hammer.
 * cking not sure how we proceed on this - my preference is to say it should go through w/o verification 
<infinity> cking: I want verification to the nth degree from Samsung on the Quantal kernel, but for P and O, I'm happy with someone just booting them and saying "yep, the module's disabled now".
<infinity> cking: Cause I'm pretty sure P and O weren't bricking things (though we've never had a straight answer there, the bug reports all seem to be Qish)
<cking> infinity, I will prod joseph later today to see if I can get him to re-test with Q
 * apw yawns
<infinity> Cause once I can get Samsung to say "yes, this fixes the world, yay", I intend to respin the quantal/amd64 images with the kernel update and stop the madness.
<smb> Maybe nobody really ran those releases in UEFI mode back then. Which is now more often caused be the other OS requirement
<cking> have we direct access to Samsung to get this tested ASAP then?
<infinity> smb: Tis possible that the laptops recently switched to being EFI by default instead of legacy but, even then, you'd expect a fair number of LTS installs.
<infinity> cking: AFAIK, we have some Samsung people standing by to test, but they're not "Linux people", so we'll need to produce an image and hand-hold them through it.
<infinity> cking: I'll be trying to make sure that happens this week.
<apw> that does match my information
<cking> infinity, thanks for the handling that :-)
<smb> infinity, True. At least nowish. Ok, people would need a second computer to open the bug report to shout at us. And blame it on the install rather on crappy hw
 * ppisati goes out (early) to hunt for food
 * henrix -> lunch
<ogra_> rtg, apw ... could one of you take care for bug 1096919 ?
<ubot2> Launchpad bug 1096919 in linux-nexus7 (Ubuntu) "please enable CONFIG_BLK_DEV_IO_TRACE in the nexus7 kernel" [Medium,New] https://launchpad.net/bugs/1096919
<rtg> ogra_, working on it...
<ogra_> gracias :)
<jsalisbury> rtg, it looks like bug 1064924 needs to be reverted per upstream.  Should I create a new bug and submit the revert request, or can I used the existing bug?
<ubot2> Launchpad bug 1064924 in linux (Ubuntu Quantal) "Please add LVDS quirk for the zotac zbox" [Medium,Fix released] https://launchpad.net/bugs/1064924
<rtg> jsalisbury, prolly stick to the original bug and note why we're reverting
<jsalisbury> rtg, got it, thanks
 * ogasawara back in 20
<dobey> what file should i edit to change the boot command line, if the grub menu won't let me edit the command line (pressing e or c at grub do nothing for me)?
<smb> apw, Are you aware of packaging changes regarding libcrypto in raring. Something that definitely did compile before the holidays now fails in the configure stage. *grr*
<apw> smb, i am not indeed, might be worth asking on #ubuntu+1-maint though
<smb> apw, will do...
<arges> smb: which package
<smb> arges, xen :-P
<arges> smb: i see xen-api/xen-api-libs on ftbfs only for armhf/powerpc
<smb> arges, Its the main xen package and even the version currently in the archive now fails in my sbuild environment...
<arges> smb: do you have a link to the failing .dsc?
<apw> dobey, most of the things you can change are changable from /etc/default/grub2
<arges> smb: oh nevermind you mean 4.2.0-1ubuntu5
<arges> err
<arges> 4
<smb> arges, If it is not only me and the first day it would be the pull-lp-source xen raring
<arges> smb: trying it now
<sforshee> hrm, I just experienced a thermal shutdown on my thinkpad :-/
<sforshee> I wasn't even abusing it that badly
<apw> sforshee, intel ?
<sforshee> apw, yep
<apw> raring 
<apw> have you s/r since boot ?
<sforshee> no, precise with the quantal hwe kernel
<apw> oh dear
<sforshee> I haven't installed a new kernel since mid last week though
<bjf> sforshee makes me sad
<sforshee> but I've had a thermal shutdown on this machine
<arges> sforshee: which kind of thinkpad? and which kernel version
<dobey> apw: thanks, i'll try that
<sforshee> arges, t410, 3.5.0-19.30
<sforshee> I meant to say I've never had a thermal shutdown on this machine previously
<arges> smb: ok i get the same error. I can work on a patch if you'd like
<smb> arges, No worries. I am on it anyway. Just wanted to find out whether this is sort of known
<xnox> Hello, kernels hackers =) does anyone has any hardware that can build ndiswrapper dkms module and load any driver to see if ndiswrapper works?
<arges> smb: cool. also did you see the crash patch I attached? added 'binutils' as a Depends. I think you are maintainer right?
 * xnox fixed it in raring and now I want to SRU it back to quantal & precise, as it is broken in quantal & precise is getting quantal kernel.
<apw> xnox, not me, i wonder if tseliot might
<smb> arges, I saw it. And yep, suppose I am sort of.
 * smb looks at his dirty fingers
<apw> smb is tarnished with it is probabally a better description
<tseliot> xnox: no, sorry, I'm not familiar with ndiswrapper
<rtg> ogra_, uploaded linux-nexus7_3.1.10-8.20 for bug  #1096919
<ubot2> Launchpad bug 1096919 in linux-nexus7 (Ubuntu Raring) "please enable CONFIG_BLK_DEV_IO_TRACE in the nexus7 kernel" [Medium,Fix committed] https://launchpad.net/bugs/1096919
<ogra_> rtg, thanks a lot ... lets see if that boots faster :)
<smb> apw, blursed...
<rtg> ogra_, yeah, might help ureadahead
<sforshee> no luck inducing a thermal event by loading cpus/io and trying to induce gpu activity
<sforshee> I wonder what happened to generate all that heat
<rtg> sforshee, thunderbird
<sforshee> I use mutt/offlineimap
<apw> sforshee, have you s/r since you rebooted ?
<sforshee> apw, no I haven't
<apw> cking is tracking a bug with i915 and s/r making it consume 3x the power
<apw> you might try it 
<sforshee> ack, I'll give that a try
 * sforshee disappears for a minute
<awe_> cking, ping
<cking> well, it's on my TODO list, not quite onto it yet
<cking> awe_, pong
<awe_> long time...
<apw> cking, thats why i say "tracking" and not "fixing" :)
<awe_> need some debug help with my thinkpad
<jsalisbury> sforshee, its bug 1086123
<ubot2> Launchpad bug 1086123 in linux (Ubuntu) "3x power consumption compared to quantal" [High,Triaged] https://launchpad.net/bugs/1086123
<jsalisbury> sforshee, v3.8-rc2 seems to resolve it, but the bug is against raring and not quantal
<sforshee> jsalisbury, apw: if it's a regression in raring then I shouldn't be affected since I'm using precise + quantal hwe
<sforshee> in practice s/r didn't seem to change anything
<sforshee> once my machine hits 95C the temperature starts backing off
<apw> man that seems hot to me
<sforshee> that's not the normal temp, that's with everything loaded
<sforshee> right now it's at 60C
<apw> i guess my old clunker just doesn't get so hot
<jsalisbury> sforshee, I can get my x201 to hit 100C by loading it up.  I've been able to do it from 2.6 all the way up to 3.8-rc2.  It's interesting it's just started happening to you though.
<sforshee> jsalisbury, well it's only happened this one time, and so far I can't reproduce it
<jsalisbury> sforshee, I usually control the fan manually if I'm going to do something that loads it.
 * apw whines about lenovos
<sforshee> jsalisbury, what's odd is that I've done highly parallel kernel builds on this machine before without problem. I wasn't being anywhere near as abusive when it shut down.
<cking> i3, and i5 seem OK, i7 based Lenovos seem to get quite toasty
<sforshee> this is i7
<sforshee> Intel(R) Core(TM) i7 CPU       M 620  @ 2.67GHz
<sforshee> westmere I believe
<jsalisbury> sforshee, thats what I got too: model name	: Intel(R) Core(TM) i7 CPU       M 620  @ 2.67GHz
<cking> I've seen that with a fully loaded CPUs and minimal GPU usage these i7 based lenovos get really hot.
<cking> and even Windows 7 users gripe about it being toasty hot
<sforshee> cking, mine gets hot, but when it hits 95C something is kicking in to mitigate it. The temp immediately drops down to about 89 then starts ramping back up.
<jsalisbury> sforshee, I can get my system to overheat by running a bunch of these silly little things in parallel:
<jsalisbury> http://paste.ubuntu.com/1507070/
<cking> sforshee, at 95 degrees C the CPU is scaled back I suspect
<sforshee> i was using stress
<sforshee> cking, likely
<jsalisbury> sforshee, have you ever updated the bios?
<cking> sforshee, the fan takes ~7 seconds to ramp upto full speed, so this means we have a window where the machine can't dump the excessive heat quick enough
<sforshee> jsalisbury, I can't recall for sure, but not anytime recently
<cking> passive cooling via CPU freq scaling is fairly fast, but even with the CPU scaled back it takes some time for the fan to dump the heat out of the laptop
<jsalisbury> cking, and if the fan is partially blocked by dust, or by sitting on a soft surface, it takes even longer :-)
<cking> jsalisbury, indeed. but the real kicker is that it seems that quite a few  i7 based Lenovos to get to the TjMax point really easily.
<sforshee> this machine is sitting in a docking station on my desk just like usual. Actually there was nothing unusual at all.
<sforshee> may have been some difficult-to-hit firmware or kernel bug
<sforshee> anyway, I think I'll just keep an eye on my temperature for now and go back to my normal work
<lynus> new 12.04 install on my acer S3-391 laptop,randomly freez ,no response to sysrq.Is there any way to get a kernel dump?
<cking> bah, one one the many machines in my office is beeping periodically and I can't find which one it is.
<apw> cking, check the smoke alarm too
<cking> apw, I can't mistake the smoke alarm - it screems at ~100+ dB
<apw> cking, mine goes "bip" once like eveyr 5m when its battery is going flat
<apw> drives one mental, cause its not long enough to find direction
<cking> apw, good point, mine are mains and battery powered
 * cking notes that a pure tone beep is directionally hard to detect
<cking> bah, this is driving me potty
<cking> maybe it's all in my mind
<apw> cking, time to start turning everything off one by one
 * cking starts with his brain
 * ppisati -> gym
 * rtg -> lunch
 * smb calls it an EOD
<apw> ogasawara, ok i've pushed a bunch of config stuff to the tree, it seems to build on everything we still have flavours for
<ogasawara> apw: ack
<apw> ogasawara, that represents the config review for 3.8 as much as i can stomach
<apw> http://kernel.ubuntu.com/~kernel-ppa/configs/raring/reviews/38early.html
<apw> ogasawara, ^^ (linked into the spec)
 * apw gives it up
<bjf> beeg.com
<bjf> lol
 * rtg -> EOD
#ubuntu-kernel 2013-01-08
<amitk> apw: smb: can you remind me again how we deal with ABIs? Why Ubuntu-3.5.0-21.32 is actually a 3.5.7 kernel?
<ppisati> moin
<smb> ppisati, moin moin
<smb> amitk, Not exactly related to ABI :) That is the -21. in the version
<smb> We never reflected the upstream stable number in our version. So that remains always 0
<amitk> smb: That is where I was confused. I was thinking of the -21 as the ABI, but I couldn't remember where the .0 came from
<amitk> smb: so we never change the .0, correct?
<smb> amitk, Right
<amitk> smb: thanks
<smb> amitk, I think that is actually consistent with the orig.tar we use. Which is always the upstream release tarball (except for the accidental version in Hardy which luckily will go away soon)
<amitk> smb: ok, makes sense when thinking of it in relation to the upstream release tarball and diffs
<apw> we would have liked to make it 3.8-21 style, but userspace very commonly looks at the kerel version string and asumes it can pull 3*int off the front of it, bad userspace
<amitk> apw: ack, that discussion is coming back to me now...
<caribou> smb: did you notice that the SRU request for the latest crash version got turned down ?
<caribou> smb: https://bugs.launchpad.net/bugs/1064475
<ubot2> Launchpad bug 1064475 in crash (Ubuntu Quantal) "crash version is outdated. Needs to import Debian version of the package" [Medium,In progress]
<smb> caribou, Yes, I saw it yesterday and was just reading through it again right now and thinking about a response
<caribou> smb: ok, just wanted to be sure you were aware of it
<smb> caribou, Yeah, thanks. I am. :)
<ogra_> rtg, gah, seems the config change wasnt enough ... ureadahead still cant find /sys/kernel/debug/tracing/events/fs/do_sys_open (and in fact it isnt there)
<rtg> ogra_, hmm, lemme check into it.
<ogra_> i thought that option would be enough
<ogra_> do we carry any ureadahead specific patch in our main kernel the nexus one could be missing ?
<rtg> ogra_, I don't think so, but I need to check that all the required options are enabled in the N7 kernel. First I have to research what they are :)
<ogra_> heh
<ogra_> k
<ogra_> i'll go on digging here as well
<rtg> apw, do you recall what is required for ureadahead ? AFAICT its just CONFIG_DEBUG_FS=y and CONFIG_FTRACE=y
<ogra_> ENABLE_DEFAULT_TRACERS ?
<apw> rtg, i think so, we might be carrying a patch for a tracepoint
<ogra_> (intrestingly not available on my precise x86 )
<rtg> apw, I was just trying to find if we are carrying a ureadahead patch. if so, its not got ureadahead in the description.
<rtg> apw, likely it was just a tracepoint, right ?
<apw> it was a tracepoint, and i think it was going upstream
<apw>     UBUNTU: SAUCE: trace: add trace events for open(), exec() and uselib()
<apw>     UBUNTU: SAUCE: (no-up) trace: add trace events for open(), exec() and uselib
<rtg> apw, is that raring ?
<apw> (lucid, precise)
<apw>     UBUNTU: SAUCE: (no-up) trace: add trace events for open(), exec() and uselib
<apw> quantal
<rtg> ok, then the N7 kernel would need it 
<apw> same in raring
<apw> so there it is
<apw> from the description i suspect that upstart should be being fixed to no longer need it
<rtg> ogra_, ok, looks like the N7 kernel needs another patch,
<apw> assuming the "syscall trace events whenever that gets merged"
<apw> comment is accurate
<ogra_> yeah
<apw> jodh, hey ... do you look after ureadahead now ?
<apw> rtg, might be steve actually
<rtg> apw, well, I'm pretty sure that patch is needed for N7 regardless.
<apw> rtg, yep i would say so indeed
<ogra_> ...
<ogra_> openat(3, "events/fs/do_sys_open/enable", O_RDWR|O_LARGEFILE) = -1 ENOENT (No such file or directory)
<ogra_> ...
<ogra_> whatever gets me that file in sysfs will do ;)
<rtg> ogra_, if memory serves, ureadahead did its own mounting internally in the program.
<ogra_> ah
<apw> yeah cause it is very very early
<apw> but those may only exist if the trace points exist
<apw> which brings us back to the patch
<ogra_> so it mounts the whole fs subdir ? 
<ogra_> (since all of that is missing here)
<apw> well i think it mounts sysfs doesn't it?
<rtg> it mounts the debugfs file system
<ogra_> k
<apw> debugfs, what he said
<apw> but i suspect the hierachy is made by declaring the tracepoints
<rtg> ogra_, I have an N7 I can test on before I upload again.
<ogra_> ok
<ogra_> you need to drop quiet and splash to see the ureadahead error
<ogra_> though a manual trace from userspace should help as well for testing
<apw> rtg, ogra_, yeah the trace point name match the only ones in fs on my system
<rtg> ogra_, it'll take me a bit since mine is still on Quantal.
<ogra_> great !
<ogra_> rtg, well, i'm up to date, probably uploading it somewhere and me pulling it is faster
<rtg> ogra_, ok, gimme a bit.
<ogra_> no hurry :)
<apw> rtg, by the looks of it this generic framework for syscalls may have made it in
<apw> see /sys/kernel/debug/tracing/events/syscalls#
<apw> we probabally could switch to that and drop the patches
<rtg> apw, perhaps stick that on a blueprint as a work item so we don't forget ?
<apw> ack
<apw> done
<ogra_> rtg, while you're at it, i only ran into the ureadahead issue because i was trying to get plymouth working ... it seemingly has an issue somewhere between fbcon and font handling (running console-setup before plymouth kiks in fixes it apparently) ... comparing the kernel configs, i see 8x8 enabled on x86 while only 8x16 is enabled on the nexus, could you also add 8x8 (in the hope that magically fixes plymouth)
<rtg> ogra_, um, which config option is that exactly ?
<ogra_> oh ...
<ogra_> the option would be CONFIG_FONT_8x8=y
<ogra_> but i just see there is another difference
<rtg> ah, font. I was looking for FB_*
<ogra_> ogra@nexus7:~$ grep FONT /boot/config-3.1.10-8-nexus7 
<ogra_> CONFIG_FONTS=y
<ogra_> gra@anubis:~/Desktop/nexus/kerneltree/nexus7$ grep FONT /boot/config-3.2.0-35-generic 
<ogra_> # CONFIG_FONTS is not set
<ogra_> thats intresting 
<rtg> ogra_, I have CONFIG_FONTS=y, CONFIG_FONT_8x16=y
<ogra_> yep, same here 
<ogra_> but x86 has:
<ogra_> # CONFIG_FONTS is not set
<ogra_> CONFIG_FONT_8x8=y
<ogra_> CONFIG_FONT_8x16=y
<ogra_> i dont really get how CONFIG_FONTS can be unset but the single fonts are still available
<rtg> ogra_, I don't know what that option does. lemme read up on it
<rtg> ogra_, Say Y here if you would like to use fonts other than the default
<rtg>           your frame buffer console usually use.
<ogra_> yeah, reading that too here
<rtg> so 8X8 and 8X16 would be the defaults
<ogra_> ah, k 
<rtg> or 8X16 at least. 8X8 isn't enabled on the N7
<ogra_>  yeah, if i enable it they are preselected 
<ogra_> 8x8 isnt enabled because it was explicitly disabled then
<ogra_> i dont see any reason why 
<rtg> probably
<rtg> ogra_, do you think its impacting plymouth ?
<ogra_> not sure, plymouth hardlocks if i dont cann console-setup first ... or at least setfont 
<ogra_> very hard to debug since i cant get any crash info, but setting the fonts in userspace seems to work 
<ogra_> s/cann/run/
<ogra_> weird typo ...
<apw> henrix, remind me, when i do a derivative with tracking bug, what do i change when i have uploaded it, i did it all wrong last time
<rtg> well, I can turn on 8X8....
<ogra_> in any case setting CONFIG_FONTS and not having 8x8 and 8x16 is a difference to our x86 kernel
<rtg> I'll make them hogeneous
<ogra_> thx
<ogra_> i'll see if that helps ... else i still need to do additional userspace hackery
<ogra_> it at least roules out one potential issue 
<ogra_> -o
<apw> henrix, my reading of the wiki is i should just make the prepare-*'s in_progress and then upload them
<henrix> apw: not sure i understand you're question, but usually you need to set the prepare-package-* tasks to 'in progress'
<henrix> apw: correct
<apw> and will shankbot handle the world from there
<henrix> apw: yep, the bot will monitor the progress
<apw> ok great
<henrix> apw: once the builds are ready, it will set the prepare tasks to 'fix released' and will set the 'promote-to-proposed' to 'in progress'
<apw> ok great
<henrix> apw: oh! i guess you we're talking about the lowlatency kernel... in this case, i believe the process is slightly different because you have the 'upload-to-ppa' task
<henrix> apw: in this case you'll need to set the prepare-package-* tasks manually to 'fix released' and the 'upload-to-ppa' to 'in progress'
<henrix> apw: and then the bot will take over.  it will set the 'upload-to-ppa' to 'fix released' once the packages are built
<apw> henrix, ok
<apw> yep presumably that is so 'they' can make the package, and 'we' can shove them in the PPA
<henrix> apw: although i guess that 'they' and 'we' is actually the same person :)
<apw> well no in this case it won't be eventually, this cycle they made the git bit and i am spinning from there
<apw> next time they will make the packages, i hope
<henrix> cool
<herton> apw, henrix, note that you set only prepare-package to 'fix released', and upload-to-ppa to 'in progress', prepare-package-meta can be left to 'in progress' and the bot will take care of it
<herton> it's confusing right now, I have plans to change that, on my todo
<herton> as well as it make "smarter", so if the bug has not the correct states it can try to fix itself
<herton> or prepare-package-meta to 'invalid', if there was no abi bump
<apw> herton, that is a mind-bending semantic indeed
<rtg> ogra_, http://kernel.ubuntu.com/~rtg/Ubuntu-3.1.10-8.21.1
<rtg> it has the font changes as well as the trace point patch for ureadahead
 * ogra_ downloads
 * rtg -> biab
<apw> herton, one for your long-term-todo list for shankbot ... change the title from <to be filled> to a valid version once the packages appear
<apw> herton, and did you as you change the lowlatency task, or you as shankbot
<ogra_> rtg, ureadahead works fine, thanks a lot !
<herton> apw, noted, should be possible to do it. No, I just changed it, that should be in progress
<ogra_> the font changes at least didnt cause any regression, havent tested more yet
<rtg> ogra_, excellent.
<rtg> I'll upload this version then
<apw> herton, i suspect shankbot could fix those too
<herton> apw, yep, I plan to make it able to fix these
<apw> it is quite opaque even with the wiki, i am bound to get this wrong time and time again :)
<apw> herton, and ... that is lowlatency in the pipe for Q and R
<ppisati> apw: UBUNTU: [Config] highbank -- disable DTB install" -- why?
<ogra_> to confuse you :)
<ppisati> indeed
<apw> ppisati, we don't make a highbank kernel anyhow and that bit stopped working
<apw> so i wacked it on the head
<ppisati> ah ok
<apw> bitrot setting in, we won't be able to get it back for much longer
 * ogasawara back in 20
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<ogasawara> bjf: http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-r-tracking-bug-tasks.html
<jsalisbury> ##  
<jsalisbury> ## Meeting starting now
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues January 15th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<philwyett> Can Toshiba laptop owners have some love and have bug 1048631 looked at and the patch in 3.8 put in raring and precise. Thanks :-)
<ubot2> Launchpad bug 1048631 in linux (Ubuntu) "If electrical cable is plugged in then Toshiba Satellite C855-10M reboots instead of shoutdown " [Medium,Confirmed] https://launchpad.net/bugs/1048631
<jwi> philwyett: if there's a patch upstream that fixes the bug, you probably want a kernel SRU. see https://wiki.ubuntu.com/StableReleaseUpdates#Kernel
<philwyett> jwi: Ok, will look. Thanks
<apw> philwyett, if you add the sha1 of the patch you think fixes it, then we can spin you test kernel with it on to confirm, and go from there
<apw> jsalisbury, ^^
<jsalisbury> apw, ack.  philwyett I'll update the bug and spin up a test kernel.
<apw> henrix, did i just hear we are respinning some of the kernels ?
<henrix> apw: yep, we need to respin P and Q
<apw> balls
<henrix> right, you need to respin lowlatency as well... :-/
<bjf> apw, why?
<bjf> oh
<apw> bjf, cause i just got them to spin lowlatency, and reviewed and sponsored them
<philwyett> apw, jsalisbury: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1048631/comments/48
<ubot2> Launchpad bug 1048631 in linux (Ubuntu) "If AC electrical cable is plugged in then certain model Toshiba laptops reboot instead of shutdown" [Medium,Confirmed]
<bjf> apw, well, the good news is that we are skipping the next cycle
<bjf> apw, we are just going to make this one really, really painful :-P
<apw> heh
<henrix> apw: its a pita to sync with everyone prep'ing kernels: stable team, lowlatency (you), armadaxp (ike), ...
<jsalisbury> philwyett, thats great.  so this should be automatically fixed in Raring when we rebase to v3.8.  I'll look and see if it will be queued for upstream stable and see how easy a backport would be.
<henrix> apw: ah, and the testing team, as they may start testing ahead
<apw> yeah, i wonder if we are asking too early to prep them, hmmm
<jsalisbury> philwyett, can you test v3.8-rc2 to confirm the bug is fixed: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.8-rc2-raring/
<jsalisbury> philwyett, if it is, please update the bug.
<jsalisbury> philwyett, we can then look at getting in into stable releases
<apw> jsalisbury, thanks
<philwyett> jsalisbury: Thanks will do and adjust bug as necessary.
<jsalisbury> philwyett, great, thanks!
<jsalisbury> apw, anytime ;-)
 * rtg -> lunch
<bjf> rtg, i did get raring and the 3.8 rc2 kernel installed on my intel box. nouveau is working just fine right now.
<bjf> rtg, i'll be able to do more testing when the dkms pkg is ready
<rtg> bjf, tseliot says it won't be ready until tomorrow
<bjf> rtg, that's ok with me
<philwyett> jsalisbury: Updated bug report. 3.8.0-rc2 mainline worked fine. Laptop shutdown correctly.
<jsalisbury> philwyett, great.  I'll see if it's already been submitted for stable and update the bug.
<philwyett> jsalisbury: Superb.  Many thanks.
<jsalisbury> philwyett, np.  thanks for testing.  I may have a stable kernel for you to test if that's ok.  I'll update the bug if it's needed.
<philwyett> jsalisbury: That's fine. Anythinng to help.
<jsalisbury> philwyett, thanks
<bjf> rtg, 3.8-rc8 kernel works fine on macbook-air
<rtg> bjf, cool
<rtg> bjf, its actually -rc2
<bjf> finger-bug
<jsalisbury> philwyett, it looks like commit b7e3830 wasn't cc'd to stable.  The commit applied cleanly to Precise.  I'll build a Precise test kernel and post a link to it in the bug.  If all goes well I'll send a request upstream for inclusion in 3.2.
<philwyett> jsalisbury: Will you also build the lts-quantal kernel? I can test 3.2 of course but I use the lts-quanttal kernel due too bug 1088829
<ubot2> Launchpad bug 1088829 in linux (Ubuntu) "USB devices not detected in USB 3.0 ports" [Medium,Incomplete] https://launchpad.net/bugs/1088829
<jsalisbury> philwyett, I can also build a Quantal kernel for testing.
<philwyett> jsalisbury: Nice one.
<jsalisbury> philwyett, are you using amd64 or i386?
<philwyett> amd64
<jsalisbury> philwyett, great.  I'll post links to the bug shortly.
<philwyett> jsalisbury: Thanks.
 * rtg -> EOD
#ubuntu-kernel 2013-01-09
<infinity> henrix_: The quantal/armhf linux build failed with a SEGV (probably cosmic rays).  I've retried it, but it won't be done for another ~8h.  Just a heads-up.
<henrix> infinity: ack, thanks.
<BenC> So is the intent to go with 3.8 for raring?
 * henrix -> lunch
<xnox> BenC: yes. As far as I remember that was announced by kernel team at the end of UDS.
<rtg> BenC, definitely
<rtg> cking, henrix: rebooting gomeisa for kernel update
<henrix> rtg: ack
<rtg> ppisati_, rebooting tangerine for kernel update
<ppisati_> rtg: ack
<janimo> apw, anything I can do on the nexus7 kernel config syncup WI?
<janimo> no hurry, just to make sure we're still on the same page wrt the scripted headstart you can give it
 * ppisati_ goes out for a bit
 * ogasawara back in 20
 * ppisati_ -> gym
 * rtg -> lunch
 * rtg -> EOD
<infinity> bjf / henrix: Is it an assumption in the bot, or human error, that prepare-package-signed was set to Invalid for a non-ABI bump kernel?
<bjf> infinity, probably an invalid assumption in the bot
<infinity> (For 3.5.0 in quantal and lts-quantal, no signed, which means they'll be out of sync)
<bjf> ugh
<infinity> If you'd like to whip up a pair of signed packages for me and throw them at the PPA, you can fix the bot later. :)
<bjf> infinity, will probably do that
<infinity> (Since I already promoted linux/quantal before noticing the error)
<bjf> infinity, i'm working on it
<infinity> bjf: Oh, wait.  Were all the reverts in modules?
<bjf> infinity, looking, but i don't think so
<infinity> Actually, you know what?  While what I was about to say was technically true, it's probably just confusing to make the distinction and branch the workflow.
<bjf> infinity, it's in the fs subsystem
<infinity> Much simpler to just say "if linux revs, linux-signed also must" than to say the more-true-but-more-error-prone "if linux revs, but the kernel image stays the same, linux-signed can be left alone".
<infinity> bjf: Yeah, check.  We need a new -signed regardless, then. :P
<infinity> bjf: Either way, like I said, it's probably just confusing to bother making the distinction anyway.
<bjf> infinity, agreed, let's not try to optimize it
<bjf> infinity, they are building
<infinity> bjf: My hero.  I'll fix up the bugs manually, if you want to make sure the bot gets this right next time.
<herton> infinity, bjf: it's fixed now. Our script to create tracking bugs was mistakenly marking it as invalid, as it did a substring check for 'prepare-package-', as previously we didn't have the -signed task, now it should behave properly
<infinity> herton: Oh, shiny.  Thanks for the quick fix.
<maxb> Hi. https://help.ubuntu.com/community/AsusZenbookPrime suggests using the kernel parameter acpi_osi= to make backlight control keys work. How concerned should I be about this breaking other unrelated things?
<maxb> (I have enough understanding of what this does to know that it's causing the kernel to lie rather a lot to the ACPI stuff)
#ubuntu-kernel 2013-01-10
<apw> maq/b smb
 * cking grabs a coffee
<skynix> hi , can someone tell me the timing for F2FS file system in the kernel comes in?
<skynix> only from curiosity
<infinity> skynix: Looks like it only made it into mainline just now, for 3.8
<infinity> apw: Does the upcoming 3.8 turn enable building the shiny new f2fs?
<infinity> s/turn //
<skynix> infinity: which were very good when it is incorporated in 3.8. thanks for the info
<ppisati> infinity: if it's buildable as a module, yes, it'll probably be there
<infinity> ppisati: I would hope it is.  I can't imagine Ted or Linux accepting a filesystem that couldn't be.
<infinity> s/Linux/Linus/
<infinity> It's obviously bed time for me.
<ppisati> infinity: of course, but could have $bad dependencies
<ppisati> infinity: anyhow, we usually build as far as we can so, i bet it'll be in R
<zequence-w> apw: I'm having trouble updating. All seems to go fine, but when I check the git log, no ABI bumb commit
<zequence-w> And I'm having trouble pushing
<skynix> thx bye
<apw> infinity, should do indeed, i seem to remember it is there
<apw> zequence-w, is there an abi bump in the original branch?  if not you won't need one
<apw> zequence-w, the scripting copies the base abi across, which can mean it is not needed if the fix on master was not a bump
<infinity> The fix in master was indeed not an ABI bump.
<zequence-w> apw: I see. Well, then perhaps my pushing problem was unrelated. Will try to push then
<apw> you will have to force the push as it is a rebase 
<apw> infinity, thanks
<apw> infinity, debian.master/config/config.common.ubuntu:CONFIG_F2FS_FS=m
<infinity> apw: \o/
<apw> not that one wants to be using a new filesystem in the first kernel it appears, ever
<infinity> I must have done something wrong.  This glibc_2.17 passed the testsuite on my first test build.
<infinity> No one rebases ~100 patches by hand and gets it right the first try, right...?
<ricotz> infinity, ;)
<apw> cking, you did the samsung fixes right, it prevented samsung_laptop loading on EFI right ?
<cking> yep
<apw> i have a report that the latest image we sent to them machine checks, and shows samsung_laptop loading
<apw> 3.2.0-29.46 would that contain the fix ?
<henrix> apw: if you're talking about bug #1040557 then it is not not
<ubot2`> Launchpad bug 1040557 in Ubuntu CD Images "UEFI boot live-usb bricks SAMSUNG 530U3C,np700z5c laptop" [Critical,Confirmed] https://launchpad.net/bugs/1040557
<henrix> apw: the fix for that bug is still on -proposed ( 3.2.0-36.57)
<apw> damn so whoever asked them to test, was somewhat premature, cking you are off the hook
<henrix> apw: this is the perfect timing for getting that tested, as we're on verification week ;)
<apw> well they can only test with a full CD image, due to the nature of the issue
<infinity> apw: 3.2.0-36.57 and 3.5.0-22.34 are the kernels we'd want tested.
<apw> and the CD images don't have -proposed in
<cking> testing that fix is problematic w/o the CD image
<infinity> apw: I can spin proposed images for them.
<apw> infinity, yeah they need a -proposed enabled image for them to do that
<apw> infinity, if you could do that then excellent, if you feed the details to langasek, he has been front man on this
<infinity> apw: Today's precise dailies should have the latest lts-quantal on them, BTW.
<infinity> Or, so the logs claim.
<infinity> Anyhow, I need a nap before I contemplate doing such things.
<infinity> apw: (PS: fix my MESH bug)
<apw> sigh :)
<zequence-w> apw: Ah, thanks. 
<apw> rtg, hey ... your -rc3 rebase seems to be lacking an updateconfigs; do you have it or should i push what i have
<rtg> apw, still working on it
<apw> rtg, ok
<rtg> apw, slammed HEAD, repull
<apw> rtg matches what i had, great
 * ppisati goes out for lunch
<rtg> apw, got distracted reading the maintenance manual for my laptop. got to replace a fan
<apw> rtg, heh :)  i have shied away from taking my laptops appart more than necessary to change disks
<rtg> apw, well, you know how I am with my 17" display. Can't live without it :)
<apw> rtg, oh _that_ machine, i am supprised it only needs a fan!
<rtg> apw, its a refurb, but the fan has always been a little noisy. now its getting intolerable. I'm gonna savage the old one for parts.
<rtg> apw, do you see that pitti rehosted ddeb.ubuntu.com ?
<apw> rtg, ahh no, whats changed
<rtg> big ass drive methinks
<apw> i thought they were going into the main pool
<rtg> http://ddebs.ubuntu.com now moved to a new host which has plenty of space, so we won't run into lost ddebs due to "out of space" conditions anytime soon \o/. I completed the migration now and rescued the last 5 days of ddebs from the buildds.
<rtg> from his g+ posting on Jan 8
<apw> yeah, and its still separate from teh archive ...
<xnox> rtg: are there any stats on how quick/slow it's growing in raring?
<xnox> we switched ddebs to xz.
<rtg> xnox, haven't the faintest idea
<rtg> apw, as soon as the armhf build is done I'm gonna upload Ubuntu-3.8.0-0.1. I think all the DKMS packages are in place.
<BenC> rtg: I've rebased on master-next and done a test build/boot on powerpc
<BenC> So I'll have that up shortly after you tag
<rtg> BenC, I've pushed the tag 'cause it looks like the armhf build is gonna complete OK. I'll likely upload within the hour.
<BenC> rtg: thanksâ¦is abi=0 proper for starting? I assumed it was going to be abi=1?
<rtg> BenC, what is proper about an ABI ? It merely needs to be unique with the version number.
<BenC> I just didn't know the build would accept 0 as a real abi, since it used 0 internally
<BenC> Never seen it used before :)
<rtg> BenC, I think the only magic ABI-UPLOAD sequence is 0-0
<BenC> Works for meâ¦just wanted to make sure before I do the same in the ppc
<apw> rtg, sorry been offline with wl hell, i don't think the WL update works, on 3.8 or 3.7
<rtg> apw, um, what is wl ? Broadcom ?
<apw> tseliot, i just installed a 3.8 kernel with your updated wl, and it seems to panic with 3.7 and 3.8
<apw> tseliot, [   27.716022] EIP is at wl_cfg80211_scan+0x2da/0x340 [wl]
<tseliot> apw: panic???
<apw> rtg, yeah brcm
<apw> tseliot, yeah
<tseliot> apw: what version of broadcom are you using and which one were you using before?
<apw> 6.20.155.1+bdcom-0ubuntu4 is what i just updated to
<apw> before that it wouldn't build with 3.8, so i assume a week or so sold
<tseliot> apw: I'm trying to understand if it's my patch that causes that or the new upstream release
<apw> tseliot, my main worry is it blammos with 3.7 as well, looked the same though it tended to break things bad
<rtg> tseliot, http://kernel.ubuntu.com/~rtg/Ubuntu-3.8.0-0.1/
<tseliot> apw: can you try this one, please? https://launchpad.net/ubuntu/+source/bcmwl/5.100.82.112+bdcom-0ubuntu3 (with kernel 3.7)
<apw> tseliot, working on it
<tseliot> apw: my patch shouldn't really affect 3.7 since it uses #if LINUX_VERSION_CODE < KERNEL_VERSION(3, 8, 0)
<tseliot> etc.
<tseliot> thanks
<apw> tseliot, yeah ...
<zequence-w> apw: precise and quantal lowlatencies are ready to be pulled
<apw> zequence-w, thanks
<rtg> apw, maybe I'll go tear my laptop apart whilst you dick around with wl. no use breaking all of those Broadcom users.
<apw> rtg ack
<zequence-w> apw: I had forgotten to push the tag. It's up now
<apw> tseliot, 5.100.82.112+bdcom-0ubuntu3 seems to work on 3.8 just fine
<tseliot> apw: sorry, I meant this one: https://launchpad.net/ubuntu/+source/bcmwl/6.20.155.1+bdcom-0ubuntu2
<tseliot> if 6.20.155.1+bdcom-0ubuntu2 works but 6.20.155.1+bdcom-0ubuntu3 doesn't, then it's my fault
<apw> tseliot, ok working on it, sadly my test box is this one
<tseliot> apw: that's still better than what I have - nothing ;)
 * smb sneaks out for an errand
<apw> tseliot, 6.20.155.1+bdcom-0ubuntu2 is no compile on 3.8 and same blammo on 3.7
<apw> tseliot, so that means it is the upstream update ?
<tseliot> apw: so it's a problem in the blob, not in my patch. The update was requested by hwe
<tseliot> apw: please file a bug report about that
<stgraber> cking: ping
<cking> stgraber, pong
<stgraber> cking: you have an x230 right? did you notice any brightness control problem starting with the 3.7 kernel?
<cking>  stgraber, I've not noticed any
<stgraber> cking: weird. I've been staying on 3.5 for a while for various reasons, including what I just reported as bug 1098216
<ubot2`> Launchpad bug 1098216 in linux (Ubuntu) "Regression in brightness control on Lenovo Thinkpad x230" [Undecided,New] https://launchpad.net/bugs/1098216
<stgraber> I'm now going through https://wiki.ubuntu.com/Kernel/Debugging/Backlight and adding some information to the bug
<cking> lemme see if I can reproduce
<stgraber> one detail that may be relevant is that I'm using mine with UEFI and without BIOS compatibility
<cking> ah, I'm not using UEFI on mine
<stgraber> it also appears that some tools use acpi_video0 and some others intel_backlight. The ones using intel_backlight (gnome-control-center) are still fine, those using acpi_video0 (gnome-settings-daemon + the hotkeys) can't change brightness anymore.
<Sarvatt> stgraber: https://bugzilla.kernel.org/show_bug.cgi?id=51231
<ubot2`> bugzilla.kernel.org bug 51231 in Power-Video "Backlight keys doesn't work on ThinkPad t430s" [Normal,Needinfo]
<cking> stgraber, works OK for me on 3.8-rc2
<stgraber> Sarvatt: definitely looks like it
<stgraber> cking: based on the kernel.org bug report above, my guess is that it only happens on UEFI-only systems
<Sarvatt> cking probably hasnt updated his bios in ages? :P
<stgraber> I'm using mine to test secureboot, so it's the latest firmware from Lenovo with UEFI+SB enabled (which forces BIOS compatibility off)
 * cking steering clear of UEFI on his own kit
<sforshee> stgraber, the firmware is obviously changing something. acpi_video0 only gives you 15 levels with 3.5 and 100 with 3.7.
<sforshee> stgraber, how about an apport-collect to attach the acpi tables?
<stgraber> sforshee: apport isn't terribly happy that I'm running a pre-release of the 3.8 kernel, but I'm now pushing everything that's listed on the wiki, including the acpi tables
<stgraber> sforshee: based on the workarounds on bugzilla, my guess is that the firmware does some version-specific tricks for Windows (as usual) and the kernel is now sending something slightly different, leading to different tables (explaining why acpi_osi="!Windows 2012" apparently fixes it)
<sforshee> stgraber, yep, that's what it sounds like. The relevant code should be in the DSDT
<stgraber> sforshee: bug updated with the tables
<sforshee> I wonder if Windows has some special requirements for the acpi backlight in win8
<sforshee> stgraber, thanks
<cking> sforshee, anything weird like that is expected
<sforshee> expect the unexpected ;-)
<stgraber> now to poke hallyn about my next >= 3.7 kernel bug (/me decided today was "let's make this laptop work with a recent kernel day") ;)
<apw> tseliot, https://bugs.launchpad.net/ubuntu/+source/bcmwl/+bug/1098225
<ubot2`> Launchpad bug 1098225 in bcmwl (Ubuntu) "[raring] bcmwl triggers panics with 3.7 and 3.8 kernels" [Undecided,New]
<tseliot> apw: thanks!
<rtg> apw, shall I hold off on uploading just yet ?
<tseliot> apw: also, please make sure to include your card model
<sforshee> yipee, If (\WIN8) conditions in the backlight code
<apw> tseliot, copied out of the lspci into the subject etc
<tseliot> apw: thanks
<cking> stgraber, your  x230 DSDT checks for Windows 2012, mine doesn't.
<apw> rtg, hard one, for me i am using brcmsmac, but it is not 1) default or 2) covers all the versions
 * cking did buy his x230 the week it first came out, so it has early release firmware
<stgraber> cking: you're probably on the old non-win8 firmware
<cking> yep
<apw> lucky cking 
<jwi> sforshee: makes sense, 3.7 is the first kernel that supports ACPI_OSI_WIN_8
<stgraber> cking: I bought mine a week or so after you bought yours but as I needed to do SB testing, I upgraded to the SB/win8 enabled firmware
<apw> rtg, i'd say give tseliot till EOW and decide then
<rtg> k
<sforshee> cking, stgraber: _BCM seems to do nothing if you don't say you're either Win7 or Vista
<sforshee> hmm, maybe. There are two sets of acpi backlight interfaces
<sforshee> wonder which one is being used
<sforshee> stgraber, what does 'cat /sys/class/backlight/acpi_video0/device/firmware_node/path' output on that machine?
<stgraber> \_SB_.PCI0.VID_
<hallyn> stgraber: i'm actually not remember that bug right now.
<stgraber> hallyn: http://paste.ubuntu.com/1412975/
<hallyn> stgraber: is it filed somewhere, or can you describe?
<hallyn> k
 * hallyn is happy to walk away from *($&%(*& cifs changes messing with userns patchset
<stgraber> hallyn: run that code and you get a stuck loop entry every time you call it. Only way to free it is to reboot
<hallyn> oh. right
<stgraber> hallyn: first spotted on 3.7 and still there with rtg's 3.8 kernel, so apparently I'm the only one doing that kind of weird things with loop devices as nobody else seem to have noticed :)
<hallyn> stgraber: now you don't get it without overlayfs, is that right?
<cking> sforshee, so my older firmware handles _BCM the same, but my _BCL does not have a Win8 special case 
<sforshee> cking, stgraber's is the same
<sforshee> I can't tell yet why it doesn't work
<stgraber> hallyn: I think that's right, let me see if I can easily try without it (ro bind-mount of / sohuld do it)
<stgraber> sforshee: oh, and something I just noticed. acpi_video0 appears to start working after I change the brightness in intel_backlight, but only in a limited range (actual_brightness shows 20 as being the minimum and 70 as being the maximum)
<hallyn> GAH - 2auth needed to d/l as text again 
<sforshee> stgraber, I suspect that there are only specific backlight levels that will affect any change
<hallyn> all right lemme play in a kvmbox.  
<stgraber> hallyn: a quick try with bind-mounting / ro into the test directory (instead of overlayfs) doesn't show the bug, though to be fair, that means that lxc won't actually touch the loop device, so it may take a completely different path and avoid the whole issue
<hallyn> stgraber: so i'm having my own new raring issue, attaching a tap device to virbr0 requires killing and restarting dnsmasq every time, else tap doesn't get an address.  <weird>
<stgraber> hallyn: the fact that everything unmounts cleanly and that nothing is reported to use the loop device is also very strange, as it's not what you'd expect if something was indeed keeping some kind of reference
<sforshee> stgraber, the code tries to find the level being written in a smaller list of values (which is the 16 levels you get with !Windows2012). If it doesn't find the value in the list it does nothing.
<sforshee> stgraber, I'll give you a list of values that ought to work, just a second
<hallyn> stgraber: yeah, i'll look clsely at the mountinfos, but...  it seems some inode may just be sticking around that's pinning the overlayfs...  or something
<sforshee> stgraber, 5 10 20 25 30 35 40 45 50 55 60 65 70 80 90 100
<sforshee> I think any of those value written to acpi_video0 ought to change the brightness
<stgraber> sforshee: yep, matches what I just got with trial and error :)
<stgraber> sforshee: setting anything else will change the value of brightness but not actual_brightness (and obviously not do any actual change)
<sforshee> stupid. Why report a bunch of brightness values that aren't supported?
<sforshee> stgraber, I'm not really sure what to do about this. It's just a case of stupid firmware afaict.
<sforshee> http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256.aspx
<sforshee> "All Windows 8 systems are required to report 101 brightness levels to Windows"
<sforshee> so it's a dumb way of meeting the requirements of Win8 I guess
<stgraber> hehe, yeah, reportin 101 brightness levels, 90% of which don't actually do anything and aren't even rounded to the closest valid value
<sforshee> I bet lenovo supplies a driver which does the rounding or something like that
<stgraber> probably
<hallyn> stgraber: have you pinged apw on this issue?  
<hallyn> given overlayfs is his baby...
<stgraber> hallyn: yep, he was around when we last talked about it here. I can't remember it ringing any particular bell though :)
<hallyn> or have you tried using aufs in place of overlayfs
<hallyn> ok, i'll play - ttyl
<stgraber> hallyn: ah yeah, testing with aufs may be useful to confirm it's indeed limited to overlayfs
<stgraber> sforshee: are there still ACPI quirk tables in the kernel to workaround that kind of specific stupidity? (as getting a fixed firmware pushed to all those machines is fairly unlikely...)
<sforshee> stgraber, do you mean quirking it to report as an older version of Windows? I'm not sure.
<apw> or roudning the values presented to those listed
<sforshee> apw, I'm pretty sure there's no quirk like that
<stgraber> right, either way, that firmware appears to be quite common on Lenovo Ivy Bridge machines and we'll probably see other manufacturer implementing that requirement in a similarly stupid way...
<sforshee> the problem with the quirk apw suggest is that each machine might have it's own unique set of valid backlight levels
<apw> sforshee, and a thingy to list them right ?
<sforshee> that would get to be pretty onerous to maintain, methinks
<sforshee> apw, to list the valid ones?
<apw> right
<sforshee> getting that list is equally likely to be a firmware-specific implementation
<sforshee> the standard interface to get the list is returning crap
<sforshee> but it has a separate internal list of valid values
<sforshee> what that list is named isn't likely to be common across different vendors, maybe even not for a single vendor
<stgraber> hallyn: confirmed to be overlayfs specific, same code using aufs doesn't trigger the bug
<hallyn> stgraber: interesting as i saw nothing really in changelog to account for that.  i'll peruse the diff when ig et back - biab
<sforshee> stgraber, apw: there is a way to quirk it for the equivalent of acpi_osi="!Windows 2012". Not sure what other negative impacts there might be though.
<apw> bloody windows
<apw> i wish they would just go bust
<apw> and a pox on lenovo for their choice of bios vendors
<apw> and two on dell for the choice of wireless vendors
<sforshee> apw, heh
<sforshee> brcmsmac doesn't support your chipset?
<apw> sforshee, it does indeed a bit, but that doesn't stop wl asking to install, and indeed being installed already
<apw> sforshee, and it it not reliable either
<apw> a twice daily dose of rmmod modprobe to keep it working
<apw> not that wl is great either
<apw> but unless we make the decision to switch people, and implement it, etc ...
<sforshee> have you tried 3.8? I made some improvements to brcmsmac.
<apw> sforshee, just switching to it now, so i'll know in a day or two
<apw> the worry is knowing which other chipsets don't work
<apw> we know mine doesn't but ...
<sforshee> apw, cool, let me know. I've been making more changes to brcmsmac lately than Broadcom has been, so I might be able to help.
<apw> sforshee, :) 
<davmor2> hey guys I have this issue http://www.youtube.com/watch?v=1n27V7TsOqs on my lenovo y580 is there anything I can do to help track the cause?
<arges> davmor2: best way to track issues like this is to file a bug
<arges> davmor2: https://help.ubuntu.com/community/ReportingBugs should help explain the process
<melkor> My sounds stop working sometimes, and I was curious if this could be a kernel issue? I am using the 3.7 mainline kernel (which is awesome except for this sound issue).
<melkor> Actually I'm using the 3.7.1
<stgraber> sforshee: I'm adding the kernel cmdline option to workaround that bug for now. Let me know if you need anything else and I'll reboot without it.
<sforshee> stgraber, ack
<herton> hggdh, you don't need to test current ti-omap4 kernels for Precise and Quantal, they need a respin as the master kernels, you can leave it for now (bugs 1095810 and 1095810)
<ubot2`> Launchpad bug 1095810 in Kernel SRU Workflow verification-testing "linux-ti-omap4: 3.5.0-217.24 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/1095810
<herton> I meant bugs 1095797 and 1095810
<ubot2`> Launchpad bug 1095797 in Kernel SRU Workflow verification-testing "linux-ti-omap4: 3.2.0-1424.31 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/1095797
<ubot2`> Launchpad bug 1095810 in Kernel SRU Workflow verification-testing "linux-ti-omap4: 3.5.0-217.24 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/1095810
<hggdh> herton: good to know, I thought they had already been respinned
<herton> hggdh, not yet, the tracking bugs for the respins are 1097912 and 1097595, I'll close the old ones as duplicates.
 * rtg successfully operates on his laptop fan
<hallyn> stgraber: well i do think there's a clue in the ext4-dio-unwrit process somewhere
<apw> rtg, ogasawara, ok the brcm issue is fixed once we have ubuntu5 in the archive
<ogasawara> rtg: did you already have an upload prepped?  if not, I can get it ready.
<sforshee> stgraber, keep an eye out for problems when running with the cmdline quirk. There are a number of places in the acpi tables where behavior depends on whether or not the OS reports itself as Win8. If nothing is broken though then a quirk to prevent claiming to be Win8 may be our best bet.
<stgraber> sforshee: well, I've been running a 3.5 kernel on that machine for the past 4 months without any problem, which I believe is pretty much identical to booting with that cmdline change
<sforshee> stgraber, okay. I'm going to wait a day or two to give the assignee on the upstream bug report a chance to respond, and if he doesn't I'll see what reaction there is to adding a quirk.
<stgraber> sforshee: ok, thanks
<rtg> ogasawara, everything is pushed and ready to go.
<rtg> just waiting on wl to get sorted.
<rtg> apw, so its good to go ?
<apw> tseliot says everything is good if bcm is good, and the last minute fix there in u5 fixes it for me
<rtg> apw, uploading as we chat...
<tseliot> \o/
<apw> rtg, fingers crossed
<rtg> ogasawara, suppose we outta crack a raring LBM one of these days ?
<ogasawara> rtg: oh probably.  do we have anything to shove in it?
<rtg> ogasawara, not that I know of.
<ogasawara> rtg: I can throw a stub package together
<rtg> ogasawara, we prolly have time yet, but it gets to be a PITA after release
<ogasawara> rtg: indeed and I always seem to forget until the last minute
 * ogasawara adds herself a work item reminder
<rtg> ogasawara, so feel free then.
<ogasawara> rtg: ack
<hallyn> stgraber: i wonder if the overlay bug is an opportunity to aks for better introspection of netns's...  though i'm not sur ewhat it would look like
 * jsalisbury watches his Internet connection crawl
<melkor> What is going on with this? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/606238
<ubot2`> Launchpad bug 606238 in linux (Ubuntu Quantal) "synaptic touchpad not recognized on dell latitude e6510 and others" [Low,In progress]
<ppisati> anyne having issue with msmtp and TLS?
<ppisati> msmtp: TLS certificate verification failed: the certificate hasn't got a known issuer
<ppisati> ok, they issued a new cert
 * ppisati disappear for a bit
<gQuigs> these instruction don't seem to work very well: https://wiki.ubuntu.com/Kernel/KernelBisection#Commmit_bisecting_upstream_kernel_versions
<gQuigs> the best upstream building instructions I've found on the wiki is https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
<gQuigs> I was wondering if I could remove the build instructions using mainline-build-one, from KernelBisection and replace it with a link to GitKernelBuild (and then the actual bisect instructions are fine)
<rtg> jsalisbury, ^^
<jsalisbury> rtg, ack
<jsalisbury> gQuigs, that should be ok.  Or maybe add GitKernelBuild as an alternative to mainling-build-one in the document?
<gQuigs> jsalisbury: I'm trying to simplify the instructions while I am at it.... 
<gQuigs> what are the benefits of keeping people using mainline-build-one?
<jsalisbury> gQuigs, Some folks may find it easier or may have been using it for a while.  It's good to have multiple options in case one doesn't work.
<gQuigs> would mainline-build-one the recommended way of building it?
<dlynes> Is this an appropriate channel to ask about udev regex?
<jsalisbury> gQuigs, it's what I've reccomended in the past and I use.  However, I guess it's up what someone finds easiest.  Using mainline-one-build requires some pre-reqs to be setup, so it's more time consuming up front, but easier for multiple builds.  Whereas GitKernelBuild might be easier for someone that only needs to do a build one time.
<gQuigs> jsalisbury: my only problem is you cna'
<gQuigs> can't just follow the instructions on that page... they don't work as is -  one example: http://askubuntu.com/questions/209511/how-to-bisect-upstream-quntal-kernel-on-precise
<jsalisbury> gQuigs, That failure looks like a chroot was not setup.  That's one of the pre-reqs required for mainline-build-one.  There is a set of scripts in kteam-tools/chroot-setup that do that.  Maybe the wiki page needs updating with some info on the kteam-tools scripts. 
<jsalisbury> gQuigs, so for now, maybe it's best to do as you suggest and reccomend GitKernelBuild for now, until mainline-build-one can be better documented.
<gQuigs> ok will do, I will leave the current mainline-build at the end as an alternative - noting for people building a lot
<gQuigs> thanks jsalisbury
<jsalisbury> gQuigs, thanks.  I've made a note to update the documentation for mainline-build-one.
<rtg> apw, ogasawara, I'm fixing a build failure with the 3.8 upload. I added a dependency on libaudit-dev in order to build perf, but libaudit-dev is a universe package. doh!
<ogasawara> rtg: oops, ack
 * rtg -> EOD
<hallyn> stgraber: the overlayfs thing has nothing to do with namesapces - http://paste.ubuntu.com/1518339/ reproduces
<hallyn> it simply appears to be a umount_tree() bug in overlayfs.  but i can't figure out why
<hallyn> stgraber: and finally, http://paste.ubuntu.com/1518435/
<hallyn> proves that it's doing 'mount' from inside a chroot (or pivot_root) that does it.  If I do the mounts without doing them under chroot, it doesn't do it.  under chroot, it does
<stgraber> hallyn: fun, so not even related to namespaces at all, interesting...
<hallyn> baffling
<stgraber> hallyn: and I'm assuming any kind of mount does that, not only devpts?
<hallyn> so why would current->fs-.root have anything to do with it
<hallyn> yeah
<hallyn> well, i've tried with proc, lemme try tmpfs
<hallyn> yup
<mrbojangles3> hello all, I am having some problems packaging a kernel module using debhelper v 8. right now the folder debian/*modules.in* is not getting created and causing the build to fail
<mrbojangles3> this is a storage driver, so if I understand correctly it needs to be built as a udeb?
<mrbojangles3> is this even the right place to ask about this? or should I head over to debian installer?
<JEEBsv> just a random question regarding the 3.8rcs from the mainline folder -- is the seeming disabling/removal of ath5k drivers (and some other ath stuff) intended?
<hallyn> stgraber: guess i should file a kernel bug (using http://people.canonical.com/~serge/stgraber.script.5), unless you've done it?
<hallyn> maybe smb or apw will have a good idea what's going on 
<stgraber> hallyn: I haven't so it's probably a good plan. You can drop all that lxc config from the script though
<mrbojangles3> maybe I can try this from a different angle, does anyone know how a file matching *modules.in* would be created? is that through the normal build process ?
<mrbojangles3> if I am trying to compile a module against the running kernel version?
#ubuntu-kernel 2013-01-11
<hallyn> stgraber: bug 1098378
<ubot2`> Launchpad bug 1098378 in linux (Ubuntu) "chroot+overlayfs seems to cause umount mis-behavior" [High,Confirmed] https://launchpad.net/bugs/1098378
<infinity> &&^$@! kernel panics...
<infinity> hallyn: Can you try that with 3.8?
<infinity> hallyn: (or try mounting something inside that isn't a tmpfs)
<infinity> hallyn: In the current 3.7 in the archive, there's a tmpfs leak that could be, perhaps, not helping here.
<hallyn> infinity: we confirmed with http://kernel.ubuntu.com/~rtg/Ubuntu-3.8.0-0.1/
<hallyn> can't do an upstream tree as we need overlayfs
<hallyn> it shouldn't be tmpfs since you don't have to mount a tmpfs to trigger it
<infinity> hallyn: Okay, I just saw your script used a tmpfs.  But if it's still there in 3.8, it's not the bug I was thinking of anyway.
<hallyn> infinity: yeah there are commented lines in the script which can be used as an alternate to the tmpfs mount - which mount devpts.  i added tmpfs bc stgraber asked if devpts might be the trigger :)  (it's not)
<MikeMin> Did anyone have any luck with http://rankone.us?
<infinity> apw: When you wake up, we need a new linux-signed to match the current linux (in raring).
<infinity> apw: Nevermind, tim got to it.
 * cking reboots
<henrix> cking: infinity: we are going to make an exception for bug #1040557 verification -- i'm tagging it as verified although we just know it doesn't cause regressions
<ubot2`> Launchpad bug 1040557 in Ubuntu CD Images "UEFI boot live-usb bricks SAMSUNG 530U3C,np700z5c laptop" [Critical,Confirmed] https://launchpad.net/bugs/1040557
<henrix> are you guys fine with that?
<cking> henrix, can I stall on this for 20 mins while I answer an email concerning this fix
<henrix> cking: sure :)
<cking> henrix, i'm fine with it, apw, any thoughts? ^^
<apw> yeah it is very very unlikely to cause problems and if it does it means you don't keys keys or something for a small number of machines
<apw> and the potential upside, our CDs are safer, seems worth that risk to me
<henrix> apw: cking: ack, thanks
<henrix> i'll add a comment to the bug and proceed to testing
<cking> henrix, apw explained it very succinctly 
<henrix> yep, i'll write that down on the comment :)
<henrix> thanks
<apw> henrix, feel free to quote me
<cking> the intelSNA X driver seems to be working fine for me
<jodh> I'm looking at bug 1085766, but the mainline kernel doesn't appear to provide/sys/kernel/debug/tracing/events/fs/ ? 
<ubot2`> Launchpad bug 1085766 in ureadahead (Ubuntu) "/var/log/upstart/ureadahead.log contains garbage" [Undecided,Confirmed] https://launchpad.net/bugs/1085766
<smb> apw, did I not see you talk about this recently...? That we have some event there not upstream
<apw> jodh, yes we have a patch for those trace points
<jodh> apw: ok, thanks. I've updated the bug, but sounds like someone may have to bisect our patchset then.
<apw> jodh, i am told actually there are now generic syscall ones
<apw> jodh, wich are hinted at in our patch
<jodh> apw: if you can send me some details, I'll take a look, but currently ureadahead is broken on seemingly everything but armhf
<apw> jodh, i'll poke it first, it could well be the patch is no longer working
<apw> it is about time someone knew how this worked again
<jodh> apw: see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1085766/comments/10.
<ubot2`> Launchpad bug 1085766 in ureadahead (Ubuntu) "/var/log/upstart/ureadahead.log contains garbage" [Undecided,Confirmed]
<apw> jodh, yep have the same in mine,
<cking> didn't the tracing output change in 3.7-3.8 
<ogasawara> henrix: hi, when is the 3.2.0-36 kernel in precise-proposed getting promoted to -updates?  today?
<ogasawara> henrix: oh wait, or is this the one we're letting this one bake an extra 3 weeks for the point release
<herton> ogasawara, it still has next week for testing on the schedule, waiting on security-signoff/certification-testing right now. I believe will be promoted some time next week
<herton> ogasawara, indeed, from what I remember this will be the one for the point release, not sure if it will be on hold or not
<ogasawara> herton: ok thanks.  I assumed we'd still promote it to -updates, we just wouldn't turn the crank on a new cycle.
<ogasawara> bjf: is my assumption correct ^^
<herton> ogasawara, yes that's correct
<ogasawara> herton: perfect, thanks
 * henrix -> lunch
<apw> jodh, ok this is part kernel, part ureadahead issues, am testing the fixes now
<jodh> apw: thanks - sounds intriguing :)
<apw> jodh, deprecation of an interface we are using for ureadahead and change of type affecting the interfaces for open in the kernel
<apw> i'll get some patches out shortly
<jodh> apw: thanks. I wonder how are we going to stop this sort of thing happening in the future though? Is there a list of deprecated interfaces that we could grep the archive for say?
<ogra_> one good step would be more detailed error msgs in ureadahead
<ogra_> it took me half a day to find the issue on the nx7 ... if it woulld have told me "cant open /sys/foo/bar" that would have been easier than having "exited with startus 5"
<jodh> yeah, I think that + mountall could do with some 'nose-cone polishing'. I've written a crude DEP-8 test for ureadahead that would detect the bug we're discussing, but if we can catch incorrect syscall usage before apps hit the archive, all the better ;)
<ogra_> ++ indeed
<jodh> ogra_: strace :)
<ogra_> yeah, thats what i resorted to indeed
<sforshee> apw, what was the bug you were seeing with the wl driver?
<sforshee> does it look anything like bug 1097509?
<ubot2`> Launchpad bug 1097509 in bcmwl (Ubuntu) "wl kernel module on BCM4313 causes kernel taint on boot" [Undecided,New] https://launchpad.net/bugs/1097509
<apw> sforshee, yes thats the one i'd say, looks identicle
<apw> sforshee, see teh latest bcmwl upload for the duplicate bug
<sforshee> apw, ack. thanks
<bjf> cking, bug 1098584
<ubot2`> Launchpad bug 1098584 in ubuntu-kernel-tests "ecryptfs.extend-file-random.sh.btrfs fails with "Failed to write 32 bytes, position nnnn: No space left on device"" [Undecided,New] https://launchpad.net/bugs/1098584
<cking> ta
<tyhicks> cking: hmm... there should have been enough free disk space there
<cking> tyhicks, yep, it is strange, I'm going to see if I can reproduce this one
<apw> jodh, ok the fixes for ureadahead are in, and linux changes are fix_committed
<jodh> apw: thanks very much!!
<apw> jodh, not sure when they will be uploaded for linux just yet, cirtainly by -rc4
 * cking reboots
 * cking reboots again,sigh
<apw> ogasawara, i am considering whether to upload this ureadahead change as it is not an abi bumper, and we are so far for -rc4
<ogasawara> apw: works for me
<apw> ogasawara, rtg, have anything in the pipeline for raring ?
<ogasawara> apw: he's out today so I assume he's already pushed anything he had
<apw> ogasawara, ok will check the lists and then roll it up
<apw> tseliot, one for you: https://bugs.launchpad.net/ubuntu/+source/bcmwl/+bug/1098628
<ubot2`> Launchpad bug 1098628 in bcmwl (Ubuntu) "BCM4313: bcmwl binary drivers do not work correctly with IPv6 hosts" [Undecided,New]
<ogasawara> apw: ack, thanks
<tseliot> apw: hmm... let me check
<tseliot> apw: did it use to work?
<apw> tseliot, i doubt i had ipv6 when i first switched away from wl
<apw> tseliot, and generally i use brcmsmac to give it some testing
<hggdh> herton: is bug 1095815 going to be set as a dup of bug 1097919?
<ubot2`> Launchpad bug 1095815 in linux-lts-quantal (Ubuntu) "linux-lts-quantal: 3.5.0-22.33~precise1 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1095815
<ubot2`> Launchpad bug 1097919 in Kernel SRU Workflow "linux-lts-quantal: 3.5.0-22.34~precise1 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/1097919
<tseliot> apw: does it help if you do something like this? System Settings -> Network ->  Wireless -> [select your network(s)] -> Options... -> IPv6  Settings -> Method: Ignore
<apw> tseliot, if i rmmod wl and modprobe brcmsmac it works fine, so i assume system level is configured
<apw> correctly
<tseliot> apw: what happens if you reinstall the previous upstream release?
<apw> it doesn't work with v3.8 right ?
<herton> hggdh, done
<hggdh> herton: thank you
<henrix> hggdh: sorry, i should have done that 2 days ago...
<hggdh> herton: no prob, I just wanted to be sure I was Doing The Right Thing ;-)
<tseliot> apw: right, I didn't port that driver to 3.8. Wait does 3.7 make any difference with this issue?
<apw> tseliot, dunno to be honest
<apw> tseliot, ask me in the bug to remind me, i've rebooted this latop 10 times today for other kernel issues, and frankly i cannot cope with rebooting again today
<hggdh> apw: for the record, bcmwl V5 only works with 3.7 up to, and including, 3.7.0-5
<tseliot> apw: hehe, ok, I understand ;)
 * cking reboots 
<infinity> apw: Say, what's the point of uploading a kernel whose only changes are a commit and a revert of that commit? :P
<infinity> apw: Oh, despite the weird changelog, I guess it has a 1-line diff.
 * henrix -> EOW
<apw> infinity, indeed there is a (v3.7+) on the ends
#ubuntu-kernel 2013-01-12
<skynix> Host/Kernel/OS  "Kanotix" running Linux 3.7.2 i686 [ Kanotix acritox-TrialShot Dragonfire32+KDE48 20120518-14:47 ]
<skynix> CPU Info        Intel Core2 Quad @ clocked at Min:1603.000Mhz Max:1870.000Mhz 4096 KB cache flags ( sse sse2 nx lm pni vmx )
<skynix> Videocard       NVIDIA GT218 [GeForce 210]  X.Org 1.12.4  [ 1280x1024 ]
<skynix> Network cards   Realtek RTL8111/8168B PCI Express Gigabit Ethernet controller, at port: d800
<skynix> Processes 166 | Uptime 2min | Memory 417.7/2016.4MB | HDD ATA ST3160021A,ATA ST3320620AS Size 480GB (8%used) | GLX Renderer GeForce 210/PCIe/SSE2 | GLX Version 3.3.0 NVIDIA 310.19 | Client Shell wrapper | Infobash v2.67.2
<skynix> .
<skynix> gut gut
<JEEBsv> tl;dr not sure if this is off-topic on this channel, but the (seemingly automatic) 3.8rcX builds in mainline/ for whatever reason seem to have athXk drivers turned off. Any reason for that?
#ubuntu-kernel 2014-01-07
<ppisati> moin world
<apw> moin moin
<ppisati> apw: moin tech lead :)
<smb> apw, No yawn (and bees)?
 * smb feels like lead, too :-P
<apw> ppisati, heh thanks :)
<apw> smb, very droll, very droll ... and man i feel like lead more than anything
<smb> apw, Oh btw, looking at  bug 1244176... (asked already on #ubuntu-devel but not sure it had been noticed) I think the reply there would be that Saucy images won't get re-spun. I have to figure out whether netboot mini-isos are. Otherwise do you have a howto for replacing kernels in isos?
<ubot2> Launchpad bug 1244176 in linux (Ubuntu Trusty) "Server 13.10 Install Fails with USB Keyboard (Appears to Hang)" [High,Fix released] https://launchpad.net/bugs/1244176
<ppisati> smb: well, after all, who is using usb keyboards nowadays?
<ppisati> couldn't resist sorry... :P
<smb> ppisati, Just about everyone... :-P But I guess the secret also is whether they are coming in through usb2 or 3... or actually i think there was ehci and ohci for usb1... 
<pkern> ppisati: People that use remote KVMs?
<smb> Yeah those too
<smb> But ppisati just "forgot" the sarcasm tags
<ppisati> i was ironic dude...
<pkern> I thought you'd argue that everybody installs within virtualization nowadays. :P
<smb> It was unfortunately ambiguous. :) But true, I think it was a mix of reporters doing installs on physical hw with the "wrong" usb keyboard type and those doing remote kvm installs. Like I did but just was lucky that the remote just means basement to me and there the machine has a ps2 keyboard... :-P
<smb> Ah, ok, not that it matters much but ohci and uhci where usb1 drivers... So that explains a bit why this was not hurting more people...
<apw> i assume the simplest work around here is to install raring and upgrade to saucy instead
<smb> Hm, yeah might be some other way... maybe not the most elegant but working
<eagles0513875> apw: are you around? there was a post to bug #+
<eagles0513875> whoops
<eagles0513875> bug #967399
<ubot2> Launchpad bug 967399 in linux (Ubuntu) "[11.10] Elantech trackpoint does not work Lenovo " [High,In progress] https://launchpad.net/bugs/967399
<eagles0513875> another person was asking if this was going to get pushed to an SRU in terms of the kernel. Nobody else seems to have responded about this patch making it upstream
<apw> eagles0513875, has anyone followed up on the upstream email thread do you know?
<eagles0513875> apw: nobody that im aware of as nobody filed a comment on that bug
<eagles0513875> is there an upstream bug filed for this issue?
<apw> eagles0513875, mostly they just use the mailing lists as they 'issue tracker'
<eagles0513875> im not subscribed there.
<eagles0513875> can we at least get this backported and then for 14.04 have a push for it to be in mainline
<apw> i have added some clarification on the position to the bug so everyone knows
<eagles0513875> apw: thanks :) do you have any reference to what thread it was so i can revivie it or just start another one.
<eagles0513875> apw: stupid question i cant seem to sign up wiht their mailing list
<eagles0513875> http://vger.kernel.org/
<eagles0513875> apw: what list should i subscribe to
<apw> http://www.spinics.net/lists/linux-input/msg26869.html is the list it is on i think
<eagles0513875> ok apw subscribed there. and will send an email to the mailing list
<apw> eagles0513875, ask avout that specific patch
<eagles0513875> will do
<eagles0513875> apw: what is the address to send to the list
<apw> its on the subscribe page i think
<eagles0513875> http://vger.kernel.org/vger-lists.html  all im seeing are the links to archives
<apw> linux-input@vger.kernel.org is the main list send, linux-input-request to join i thiknk
<rtg> apw, I updated a Lenovo laptop yesterday with 3.13 and it now cannot find the SSD. Stupidly I did not have an alternate version to make sure it really isn't HW failure. I'm checking that out this morning.
<rtg> a different laptop with the same SSD (although larger) works fine.
<apw> rtg, well that is typical isn't it
<smb> rtg, If that isn't one of these fastboot ones, you could check whether the ssd at least appears as a boot selection in the bios
<rtg> smb, good idea.
<apw> when you say canot find it, who says that?  the kernel
<apw> ?
<apw> if so you know bios and grub found it
<rtg> yeah, the BIOS finds the drive 'cause grub loads and launches the kernel. it drops to busybox after awhile because it could not mount the rootfs
<apw> ok then not completely gone
<smb> apw, Typically it would be if it happened when we are traveling
<apw> does dmesg have any indication of the device
<smb> Yeah, better than my state last time
<apw> smb, heh yeah
<rtg> checking dmesg.
<rtg> hmm, dmesg|grep sd shows nothing
<apw> what version did you have before the update i wonder
<rtg> 3.13.0-13 I think. what is the one I just uploaded ?
<rtg> that is the one that isn't booting
<apw> -0.15
<smb> rtg, anything grepping for ata
<apw> so i think that is -rc5 -> rc7
<rtg> apw, nothing about ata except false positives.
<smb> Interesting, so not even found the controller
<rtg> I'll boot the daily as soon as  its done flashing.
<rtg> it doesn't help that I left the charger 100 miles away. doh! hopefully I've still got enough battery.
<apw> rtg, it is one of those days for sure
<rtg> tuesday is the new monday
<smb> It might be a bit far fetched but at some point there was some discussion/patch that partially reverted fiddling with some bus master bit (iirc) when not doing kexec. Not sure but maybe the good old, remove battery and wait a bit trick works here
<rtg> smb: can't hurt to try
<rtg> smb, no joy on pulling the battery
<smb> smb, ok, so at least not that. hm
<rtg> I'm just reinstalling from the daily first, then I'll get 3.13 on it.
<smb> During the install you could check lspci -vvvnn and see which driver the SATA controller is attached to (I guess ahci)
<smb> Not that we forgot some vital other driver in the initrd
<eagles0513875> apw: their mailing list setup is so complex holy cow
<eagles0513875> apw: how do i send it to the proper list once im subscribed? 
<apw> linux-input@vger.kernel.org is the main list send address
<rtg> smb, apw: reinstalled from the daily, updated to 3.13-rc7. now everything works. wtf ?
<apw> rtg, these things are sent to try us and no mistake
<apw> rtg, oh do you have any dkms packages installed ?
<rtg> apw, nope, it was pretty much stock
<apw> rtg, as we have been ignoring abi on these kernels which has been causing me issues
<apw> rtg, not even for testing?
<apw> like vbox or similar
<rtg> not on my travel laptop
<apw> then it is a mystery indeed
<smb> rtg, what driver does the disk use (I may have missed it)? I could only think of a case where initrd was misbuild
<rtg> smb, checking
<rtg> smb, [    2.765203] ata1: SATA max UDMA/133 cmd 0x2148 ctl 0x215c bmdma 0x2060 irq 19
<rtg> [    4.112147] ata1.01: failed to resume link (SControl 0)
<rtg> [    4.268151] ata1.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
<rtg> [    4.268168] ata1.01: SATA link down (SStatus 0 SControl 0)
<rtg> [    4.327579] ata1.00: ATA-8: TOSHIBA MK5065GSXF, GP006B, max UDMA/100
<rtg> [    4.327599] ata1.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 0/32)
<rtg> [    4.332543] ata1.00: configured for UDMA/100
<smb> rtg, looking in "lspci -vvvnn" for SATA should yield which module is used
<smb> or driver
<rtg> smb: oops, wrong dmesg. this one is 'ata1.00: ATA-9: Samsung SSD 840 EVO 120GB, EXT0BB0Q, max UDMA/133'. lspci says 'Kernel driver in use: ahci'
<smb> Ah ok ahci then. I would think that one should be built-in
<rtg> CONFIG_SATA_AHCI=m
<smb> hm... ok not. :P
<rtg> maybe it was just an initrd problem
<infinity> It's been =m for ages.
<infinity> But yeah, mismatched initrds or some other wonkiness would make that blow up.
<rtg> its possible. we've been ignoring ABI changes
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
<xnox> \o/ 3.13 \o/ 
<rtg> xnox, its coming. gimme a bit
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues January 14th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<xnox> rtg: as soon as it lands, i'd want some config changes to be ported to nexus kernels to match the distro configs ;-) maybe after some user testing / 3.13 landing in release pocket + some time.
<rtg> dang, forgot the meeting
<tseliot> rtg: I haven't updated the binary drivers yet, just FYI
<rtg> tseliot, so you're kinda behind the eight ball
<tseliot> right :)
<rtg> tseliot, I imagine it'll take at least another day to propagate through the archive
<tseliot> rtg: I'll try to finish fixing at least nvidia 331 tomorrow
 * ppisati -> EOD
<medberry> infinity, does the raring kernel in precise lose support on January 27th? linux-generic-lts-raring-eol-upgrade?
<medberry> metadata in that package shows:
<medberry> Supported: 18m
<_bjf> medberry, no, we support it until 14.04.1
<medberry> _bjf, cool Thanks.
<medberry> https://wiki.ubuntu.com/Kernel/LTSEnablementStack says the same.
<pkern> _bjf: Will there be any overlap for the saucy kernel where saucy and trusty are supported?
<bjf> pkern, same deal .. the lts-backport-saucy kernel will be supported until 14.04.1
<pkern> bjf: So that's a "no" then.
<pkern> Annoying.
<medberry> pkern, .1 comes after the dot nothing
<medberry> so a bit of overlap
<bjf> pkern, 14.04.1 is the first point release which is after 14.04
<pkern> Hm.
<bjf> pkern, so yes, there is overlap
<pkern> So the trusty stack comes with a 12.04 point release.
<pkern> How much later will the first trusty point release be?
<bjf> pkern, one sec ..
<bjf> pkern, it's about 3 mo. after the initial release
<pkern> So the 12.04.x after 14.04 will come about 1 mo. later and saucy+trusty will be supported together for about 2 then?
<pkern> Just to get the timeline straight.
<pkern> Because the picture on LTS Enablement Stack is different and suggests a hard transition from saucy to trusty.
<bjf> pkern, 14.04 (april 17)  14.04.1 (around end of aug.)  lts-backport-saucy will end support around end of aug. when 14.04.1 comes out
<pkern> bjf: Thanks.
<bjf> pkern, np
<pkern> Oh hm. So no overlap then because it's only then when the trusty kernel hits precise?
<pkern> Because August is also the line on that picture.
<bjf> pkern, the lts-backport-trusty kernel for precise will be out about a week after 14.04 release
<pkern> bjf: But without installer support?
<bjf> pkern, if you mean that it there isn't a point release that has it as the default, you are correct
<pkern> Well, it might as well miss the necessary installer bits in proposed.
<xnox> pkern: we rebuild d-i shortly after lts-backport landing, and one has all installer bits / images in precise/daily generated.
<xnox> pkern: although we will not cut .5 isos, there is no reason to not have d-i / netboot available with lts-backport-trusty kernel.
<pkern> xnox: Ok, thanks, I guess that's something we can test, then.
#ubuntu-kernel 2014-01-08
<ppisati> moin
 * apw yawns
<smb> Bees!
<smb> Though that is RAOF 's line...
<apw> bees ... oh where, i am thirsty
 * smb rather suggests T's in that case
<apw> jibel, do you still look after the adt tests ?
<jibel> apw, yes
<apw> jibel, dunno if this has been reported, but it looks like the tests (for linux anyhow) are failing with a a testbed error
<apw> quitting: testbed failed: cannot send to testbed: ['IOError: [Errno 32] Broken pipe\n']
<jibel> apw, there is a timeout, but 1h is a bit short, it is set to 10k seconds by default. I'll have a look
<apw> jibel, hey thanks
<infinity> apw: What is the linux autopkgtest anyway?  Just a rebuild test?
<apw> infinity, yeah just a rebuild test
<infinity> apw: if so, that makes sense for rdeps changing, but not so much for linux itself (since it literally just built), so maybe I'll skip it.
<infinity> Yeah, just looked it up in git too.
<apw> yeah there is no way to represent that apparently
<infinity> So, I'll just skip it (the rdep rebuild test of glibc went fine, so yay)
<apw> thanks
<opecun> hey everyone. who can help me - http://pastebin.com/wcY5jV2N ?
<opecun> and then server reboots unexpected
<apw> ppisati, hey, CONFIG_ARM_HIGHBANK_CPUIDLE seems to be off for generic and on for generic-lpae, is that to be expected ?
<ppisati> apw: yes, becasue it caused trouble, we were expecting a fw update for that
<ppisati> apw: but i suspect we will never get one
<apw> so why is it not off for both
<ppisati> apw: because it's working for midway (ecx-2000) while it's broken for ecx-1000
<apw> ppisati, ok thanks
<ppisati> apw: 0bdf6c4 in S
<apw> ppisati, and am i right in assuming that CPU_FREQ is not needed on arm
<ppisati> apw: it's a mixed bag, it works (and it was explicitely requested to be on) on calxeda (all revisions)
<ppisati> apw: while it had problem in the past on other chips (like omapX)
<apw> ppisati, and yet it is off on arm ... hmmm
<ppisati> apw: you mean the default config is off?
<apw> yeah in 3.13 it is off
 * ppisati senses apw is preparing for a config review/diff...
<ppisati> apw: ok, leave it off
<ppisati> apw: i'll turn it on one by one
<apw> ppisati, ok great, and yes that is what i am doing
 * ppisati -> out for lunch
<ogra_> rtg, apw, was linux-maguro ever built in trusty ? i cant build it here due to gcc-4.6 not being available in the archive anymore 
<rtg> ogra_, nope
<rtg> ogra_, I think I'm gonna have to figure out how to make 4.8 work (if that is possible)
<apw> ogra_, those have likely not changes since trusty opened
<apw> ogra_, i guess if we needed to build 'em in the short term we'd build them in saucy and copy them forward; far from ideal
<ogra_> apw, well, i would like to do a test cross build with swap disabled in the config ... seems i cant do that on my trusty machines 
<popey> Hey kernel people. 3.13 broke my desktop (nvidia doesn't build).
<tjaalton> replied to k-t@ about this
<popey> I suspect I am not the only one running 14.04 on nvidia hardware.
<seb128> tjaalton, k-t@?
<tjaalton> kernel-team@
<ogra_> kernel-team
<apw> ogra_, in a saucy chroot perhaps
<ogra_> sigh, yeah ... 
<ogra_> (2Mbit here ... takes ages to set up, but thats what i will do then)
<apw> tjaalton, i thought we pre-vetted fglrx and nvidia to make sure they built
<tjaalton> apw: "this week" is not done yet ;)
<apw> popey, indeed not, which is why we have testing for nvidia which said it built, wtf
<tjaalton> ahh, so the test is broken?
<tseliot> aah, that's actually tricky
<apw> tseliot, tricky?
<tseliot> it will probably build but complain once the module is loaded
<apw> bah
<apw> tseliot, do we know what the issue is ?
<apw> popey, does your card work if you disable nvidia ?
<apw> might be interesting to test with 3.13 anyhow
<tseliot> apw: yes, they don't export a symbol any more. I'm testing my patches as we speak
<tjaalton> hmm right, the dkms build log is messy but looks like it built nevertheless.. dmesg log would be interesting to see when it tries to load it
<apw> tseliot, sigh ...
<apw> ok then at least the testing is working, even if it is of little value
<tseliot> ok, my patches work
<tseliot> at least with nvidia 331
<tseliot> I haven't touched fglrx yet
<tseliot> or the other nvidia drivers
<apw> are we saying all of them are bust the same way, fgrlx as well i mean?
<popey> apw: I end up in VESA
<popey> apw: i need to go to a hangout, can test more after
<apw> 3.12 is your friend then
<tseliot> apw: I haven't tested them all
<tseliot> fglrx won't build, as rtg said
<apw> how is that not on the failed list in our testing.  i have to say jenkins UI is designed by a moron
 * tseliot shrugs
<xnox> apw: ask CI team to setup ci.ubuntu.com view for you? that one has AMBER & RED for regressions & non-moron URLs direct to failed artifacts / logs of the hidden jenkins URLs
<apw> jibel, ^^ is that in your pervue, and does it make sense for the dkms testing stuff ?
<tseliot> apw, tjaalton, popey: nvidia-331 and nvidia-331-updates are in
<tjaalton> tseliot: thanks!
<tseliot> now I *only* have to fix the rest...
<tjaalton> :)
<popey> nice one
<jibel> apw, that'd be for the CI team but integrating DKMS testing to the ci dashboard has been postponed for a while. 
#ubuntu-kernel 2014-01-09
<miseria> "el desempleo un mecanismo creado por el capitalismo para oprimir los pueblos y poder mantener las ganancias millonarias" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
<ppisati> moin
<eagles0513875> apw: ping regarding that bug you requested a follow up on regarding multi touch track pad no response on upstream mailing list :( 
 * apw yawns
<apw> ppisati, moin
 * smb has coffee
<smb> moin2
<apw> eagles0513875, upstream is a slow grinding place, i'd expect a couple of days turn round before response
<apw> smb, a good plan
<apw> smb, re-moin
<eagles0513875> apw: im just worried it might fall through the cracks again 
<apw> could easily do indeed
<eagles0513875> apw: how can we push that it gets looked at
<apw> a difficult one when they won't respond
<apw> being insistant in a polite way normally works in my experience
<eagles0513875> apw: ok ill give it a few days
<apw> yeah it just needs monitoring
<ppisati> rtg: "Use Chromium on Linux? Adobe Flash Will Stop Working From April"
<ppisati> rtg: http://www.omgubuntu.co.uk/2014/01/chromium-npapi-flash-dropped-april-2014
<rtg> ppisati, installing the package suggested by sconklin did the trick
<ppisati> rtg: which one?
<rtg> ppisati, hang on a sec...
<rtg> ppisati, chromium-codecs-ffmpeg-extra
<ppisati> rtg: let me try...
 * apw confirms that very package fixed things on one of his laptops
<rtg> apw, gotta whack on trusty HEAD. I messed up the startnewrelease
<apw> rtg, i just pushed a chunk of config changes
<rtg> apw, yep, I checked first
<apw> ack
<apw> rtg, let me know when its pushed so i can rebase
<rtg> apw, done
<rtg> now, one moretest build to make sure I've got the modules check correct
<apw> rtg, wierd you signed all my commits off ;)
<rtg> uh, just habit I guess.
<rtg> git am -s
<apw> odd, you must 'replace' a commit in a completley different way to me
<rtg> apw, just this time. I knew I would have conflicts, so I just made your stuff patches, then reapplied
<apw> i'd normally revert the original, make a new one, then rebase -i back to the original and squash them together
<rtg> I think it would be handy to be able to cherry-pick a range of SHA1's
<apw> that is mostly what rebase does
<apw> you use -i and then hack the list about
<rtg> apw, its just all in how you look at it.
<apw> true indeed
<apw> git is both a hammer and a nail gun
<rtg> apw, sidenote - I was able to compile android-msm-flo-3.4-kitkat-mr1 with Trusty gcc-4.6 native
<apw> great
<rtg> kind of slow even on a calxeda
<rtg> now, on to packaging
<stgraber> hey there, because I spend any more time on this, is there any known apparmor problem with the new 3.13 kernel?
<stgraber> it looks like we don't have all of jjohansen's changes and that's making stuff blow up
<rtg> stgraber, not that we've noticed. jjohansen ?
<stgraber> rtg: I guess adding a "/etc/init.d/apparmor reload" to your post-rebase tests would be a good idea then :)
<stgraber> as that's how I usually detect that things are broken apparmor-wise (well, that and people shouting at me because LXC is broken and none of the QA stuff runs anymore)
<bjf> hmmm, just thecked and our apparmour test is failing in our automatic testing
<bjf> s/thecked/checked/
<rtg> stgraber, I've been assuming AA works from a cold boot 'cause I'm getting a IP address
<apw> stgraber, "it looks like" how are you detecting that
<stgraber> apw: "/etc/init.d/apparmor reload" is complaining heavily
<stgraber> apw: so it looks like we're missing the patches for the dbus rules, network rules and mount rules. That latter is causing problems with LXC which broke all of the CI desktop testing (I've proposed a few workarounds for them though)
<apw> stgraber, well woopy doo, shows how useless our testing is indeed
<apw> rtg, this might be tractible
<sforshee> stgraber: what kind of lxc problems does this cause? Because I've been failing in trying to create a container with a privete user namespace that will actually start.
<stgraber> sforshee: that bug shouldn't affect unprivileged containers (as I've been using them with the 3.13 from the kernel team PPA) but setting up cgroups so that those containers are happy is slightly tricky
<stgraber> sforshee: (I have a blog post ready for that, just waiting for slangasek to upload a fixed pam)
<sforshee> stgraber: bascially I'm doing lxc-create; container-userns-convert; lxc-start; then I get "failed to get real path" for the rootfs
<stgraber> sforshee: I never the convert tool myself, I usually do a straight lxc-create -t ubuntu-cloud -n <name> -f user-lxc.conf
<stgraber> sforshee: then with the right cgroup setup ($NAME/lxc in all controllers with $NAME chowned to the user and the current shell in $NAME/lxc/tasks), I can do lxc-start just fine
<sforshee> stgraber: I'll try that, thanks
<davmor2> tseliot: did you solve the issue with nvidia that popey was suffering with yesterday?  I only ask as I'm still getting low gfx mode on start up using 3.13
<popey> davmor2: its fine for me today after updating and rebooting
<apw> davmor2, i am pretty sure that he uploaded a new nvidia for that
<tseliot> davmor2: yes, I did
<davmor2> tseliot: it might be that optimus hates you then :(  let me uninstall and try again
<tseliot> davmor2: it's hard to tell without any logs or clues
<tseliot> davmor2: make sure the linux headers for your kernel are installed (and the linux-generic metapackage)
<tseliot> davmor2: and reinstall the nvidia driver
<tseliot> (the latest release)
<rtg> apw, is there a reason for CONFIG_MLX4_DEBUG to be different in ppc64el ? debian.master/config/ppc64el/config.common.ppc64el:CONFIG_MLX4_DEBUG=y
<apw> rtg, likely not, i am working my way down the list slowly, its pretty long
<rtg> apw, ok
<apw> if it is hurting you likely you can flip it, else ignore it and i'll wack it when i get there
<rtg> apw, nope, I just happened to notice it whilst researching another topic
<apw> ok it is much easier conflicts wise if you leave it be then :)
<rtg> np
<apw> rtg, should we have the auto-abi-bumper patch on this branch
<bjf> arges, so you are asking henrix and kamal about the proper proceedure here?
<arges> henrix: kamal : hey guys. I have a set of 4 patches (https://lkml.org/lkml/2013/10/16/818) that would make sense for stable. I've already sent one patch to stable and it was accepted. Whats the best way to format this email that makes it easier for everybody
<arges> I've already cherry-picked and build tested from 3.4 > and its clean and builds
<rtg> apw, prolly a good idea
<apw> rtg, will grub it
<apw> grab
<henrix> arges: so, if they are clean cherry-picks, you can simply send the email with the list of SHA1s to stable@
<arges> henrix: one email per hash?
<henrix> arges: no, you can list them all in the same email. just make sure you specify the stable series you want them to be applied to
<henrix> arges: let me try to find you an example..
<arges> henrix: thanks.
<henrix> arges: sorry, got distracted with something else... :p here's 2 examples
<henrix> arges: http://article.gmane.org/gmane.linux.kernel.stable/54115/ and http://article.gmane.org/gmane.linux.kernel.stable/64503
<arges> henrix: great! that's easy enough
<henrix> arges: something like the above should be enough
<arges> thanks
<henrix> np
<apw> rtg, i am wanting to shift a commit down the stack and bump the abi in the newrelease, is the tree stable ?
<apw> (master-next only)
<rtg> apw, yep, I'm working on the flo branch
<apw> rtg i noticed when i got 50M of stuff :)
<rtg> apw, prolly wondered wtf I was doing, huh ?
<apw> rtg, as you see the objects long before the new branch is metioned ... yeah :)
<rtg> apw, by the way, I figured out that one can cross compile the flo branch under precise-amd64. dunno why I didn't think of that yesterday. too many distractions I guess.
<apw> rtg, a good point, as that is exactly waht i have done with them myself, DOH
<apw> for the 3.0 ones
<rtg> flo is 3.4
<apw> yeah, but i have done what you suggested before, and forgotten
<zequence> apw: infinity: I'd like to apply for uploading rights for the Ubuntu Studio package set, and was wondering if one of you would be kind enough to add something to my application page, under "endorsements" https://wiki.ubuntu.com/zequence/DeveloperApplication#Endorsements
<hallyn> jjohansen: how is the apparmor mount set upstreaming looking?  (i havent' followed it on lkml at all)  
<jjohansen> hallyn: its waiting of the labeling work which is still getting revisions
<jjohansen> hallyn: it will comes its just been slow
<hallyn> jjohansen: what is the eta for a patchset to hit the 3.13 kernel that's in trusty?
<jjohansen> hallyn: I will send it today
<hallyn> jjohansen: thanks. 
<sforshee> hallyn: I've been trying to reproduce bug #1263738 but my containers with private user namespaces won't start. Is there a guide somewhere on how to set that up properly?
<ubot2> Launchpad bug 1263738 in lxc (Ubuntu Trusty) "login console 0 in user namespace container is not configured right" [High,Triaged] https://launchpad.net/bugs/1263738
<sforshee> hallyn: lxc-start says "Permission denied - failed to get real path  for ..."
<hallyn> for what? :)
<sforshee> it's the container rootfs
<hallyn> I'm guessing you have a cgroup issue.  you need to do:
<hallyn> sforshee: let me put up a wiki page with instructions, gimme a bit
<sforshee> hallyn: okay, thanks!
<hallyn> sforshee: i'll stick it in a wiki later (dont wanna deal with formatting right now) but: http://people.canonical.com/~serge/userns.wiki
<hallyn> you'll probably find some errors or something i forgot to put in.
<hallyn> stgraber: (^ you might have input as well)
<sforshee> hallyn: awesome, I'll try it out in a few minutes
<hallyn> sforshee: I'm about to go run an errand, but will look for any comments when i get back.  then i'll put it on the wiki tonight.  maybe it actually should go on linuxcontainers.org...
 * hallyn bbl
<stgraber> hallyn: I'll have a well formatted blog post up soonish with that, just waiting for pam to land in the archive first
<sforshee> hallyn: it's still not working, here's what lxc-start says:
<sforshee> lxc_container: Permission denied - failed with errno 13 to create /usr/lib/x86_64-linux-gnu/lxc/dev/lxc
<sforshee> lxc_container: failed to setup the console for 'c1'
<sforshee> lxc_container: failed to setup the container
<sforshee> lxc_container: invalid sequence number 1. expected 2
<sforshee> lxc_container: failed to spawn 'c1'
<sforshee> hallyn: also a few comments on the istructions
<sforshee> 1. In step 7 I had to use sudo, not sure if that's expected or not
<sforshee> 2. In step 9 you have a typo: memory/use_hierarchy
<sforshee> 3. I also had to use sudo in step 11
<sforshee> 4. Step 12: s/#HOME/$HOME/
<hallyn> sforshee: if you used sudo in step 7 then yo uwon't be able to start the container.
<sforshee> hallyn: I couldn't create the container without using sudo though
<hallyn> what happened
<sforshee> mapped_uid is .9999.
<sforshee> ubuntu-cloudimg-query is /usr/bin/ubuntu-cloudimg-query
<sforshee> wget is /usr/bin/wget
<sforshee> cp: failed to preserve ownership for â/tmp/ubuntu-cloudimg-query.rSlpz4/trusty.server.released-dl.current.txtâ: Invalid argument
<sforshee> failed to get https://cloud-images.ubuntu.com/query/trusty/server/released-dl.current.txt
<sforshee> lxc_container: container creation template for c1 failed
<sforshee> lxc_container: Error destroying container directory for c1
<sforshee> lxc_container: Error creating container c1
<sforshee> hallyn: ^
<hallyn> mapped_uid is .9999.   <- can you paste your lxc.conf?
<hallyn> (it sounds like you used $MAPUID without defining it)
<sforshee> lxc.id_map = u 0 100000 9999
<sforshee> lxc.id_map = g 0 100000 9999
<sforshee> lxc.network.type = veth
<sforshee> lxc.network.link = lxcbr0
<hallyn> note since you've created one as root, you should probably sudo rm -rf ~/lxcbase; mkdir ~/lxcbase
<hallyn> hm,m that looks ok.
<hallyn> and what is your /etc/subuid entry?
<sforshee> sforshee:100000:10001
<sforshee> hallyn: since then I've installed some updates which included lxc packages and rebooted the machine, now it doesn't work at all
<sforshee> lxc-create just says "Error creating container c1"
<sforshee> I get the c1 directory but no files in it
<sforshee> I should probably mention that I'm using lxc from the ppa
<hallyn> huh.  lemme restart from scratch
<hallyn> sforshee: oh wait.  are you on 3.13 kernel now?
<sforshee> hallyn: yep
<hallyn> if so pls revert to 3.12.
<hallyn> but that won't fix all problems.  i'm reproducing right now...
<hallyn> sforshee: huh.  it's working for me.  on a fresh ec2 trusty instance
<hallyn> sforshee: can you pastebin your lxc.conf and the commands you type and results?
<sforshee> hallyn: just a second, still trying to test with 3.12. I think there's still some screwed up permissions from when I did lxc-create with sudo.
<hallyn> ok
<hallyn> hm, now network didn't come up.  Not sure if that's something fixed in ppa.
<sforshee> hallyn: I had a couple of directories in ~/.cache which were owned by root. I blew them away and now lxc-create is running, I'll see how it goes.
<hallyn> cool
<hallyn> sforshee: yeah so for networking to work, you do need ppa:ubuntu-lxc/daily for now
<hallyn> sforshee: updated the copy of that file.  I'm going to wait to see stgraber's blog entry before deciding whether to put up a wiki page I guess
<sforshee> hallyn: I'm already using the ppa version. The container is running now.
<sforshee> hallyn: but based on 'readlink /proc/pid/ns/user' it looks like it's in the same namespace
<hallyn> and you created and ran it without sudo?
<sforshee> yep, no sudo
<hallyn> then you shouldn't be able to be root in the container without being in another ns.  which two pids are you comparing?
<sforshee> I screwed up, let me look again
<hallyn> k
<sforshee> ok, they are different
<sforshee> I forgot to ssh back in on my second terminal after rebooting :-/
<sforshee> so then it all seems to be working, except the part where I reproduce the bug
<hallyn> what do you mean?
<hallyn> if you control-c in the console your container doesn't reboot?
<sforshee> ah, it does
<sforshee> perfect
<sforshee> thanks a lot for your help!
<hallyn> sforshee: np.  and so now look at the login process in the container and look at its /proc/pid/*, and you'll see the files owned by GLOBAL_ROOT_UID (which becomes -1 in the container)
#ubuntu-kernel 2014-01-10
<alkisg> What's the difference between linux-generic-lts-saucy and linux-generic-lts-saucy-eol-upgrade ?
<Gavinmondo> Hello
<Gavinmondo> I've been suggested to come here from few users from #ubuntu
<Gavinmondo> I am having issue with https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1244176
<ubot2> Launchpad bug 1244176 in linux (Ubuntu Trusty) "Server 13.10 Install Fails with USB Keyboard (Appears to Hang)" [High,Fix released]
<Gavinmondo> I might hop on later on tomorrow if you could have it by then
<Gavinmondo> But ig not thanks for the try though
<Gavinmondo> gotta run thanks
<davmor2> tseliot: right so yesterday it turned out that the problem was my own creation I'd somehow ballsed up nvidia-prime's config and it wouldn't uninstall, install or reconfigure even when using dpkg --force-overwrite.  So I've done a fresh install of last nights iso. Still dropped to low gfx when I enable nvidia-331 and prime
<smb> apw, Hm thinking again about it we really only should the sub keyboard issue for the server image. IIRC we stopped doing alternate images (which was afaik the only other one using debian installer). Desktop/ubiquity should not be affected because that brings up a compete system with all modules, isn't it?
<davmor2> tseliot: what logs would be useful?
<smb> *usb keyboard
<tseliot> davmor2: if that didn't uninstall is because of LP: #1264611. And I have a fix for it
<ubot2> Launchpad bug 1264611 in nvidia-prime (Ubuntu) "package nvidia-prime not installed failed to install/upgrade: subprocess installed post-removal script returned error exit status 127" [High,Triaged] https://launchpad.net/bugs/1264611
<davmor2> tseliot: iirc that is why I couldn't remove it and it left it in an unconfigured state that really didn't want to be remedied
<tseliot> davmor2: installing dpkg-dev will work around that. I've also just pushed a fix
<davmor2> tseliot: there were a few other things I needed to test too with the install that needed a fresh start anyhow.  I'll update in a bit and see if that fixes everything then
<tseliot> ok
<apw> smb, hmmm maybe ... maybe not :)
<apw> BenC, yo ... just been looking at rebaseing your ppc bits onto v3.13, it seems there are a couple of patches which need a little mangling but one which is totally borked on rebase; have you done any porting work as yet ?
<BenC> apw: Not yet. I can look at rebasing over the weekend.
<BenC> apw: Which patch is totally borked?
<apw> BenC, "powerpc/85xx: Add DPAA/networking support for P4080DS" seemed particularly affected due to a rename and rearchitect of the init bits
<BenC> Ah. Luckily, I'm pretty familiar with having to rework that patch
<apw> BenC, a couple of the others rely on the configs for each machine being separate items and they ripped them out and went _GENERIC
<apw> as they use _HAVEs on the various machine defines to deifne feature sets
<BenC> Hmm...I'm not following that, but I guess I'll see it when I get into the rebase
<apw> BenC, 'config P4080_DS' et al have been replaced with config CORENET_GENERIC
<BenC> Ah, that makes more sense
<apw> BenC, once you have the rebase 'done' we can look to pull that baby back into master
 * BenC is pleased with this course of action
<apw> it has to make things simpler
<apw> BenC, might make sense to push your rebase to like the ubuntu-saucy repo as a rebase3.13 or something then i can find it and suck it up on monday
<BenC> apw: That works for me
<apw> infinity, heads up, i am building a fixed kernel for trusty in the ckt ppa, so it cna be tested first, but it will need copying out
<tseliot> davmor2: apparently linux 3.13 causes problems with nvidia + hybrid graphics...
<davmor2> tseliot: Yay! that'll be why it works for popey  and not for me then :(
<tseliot> davmor2: you should really stick with 3.12 for now. In the meantime I'll ask NVIDIA
<davmor2> tseliot: can't I did a fresh install I only have 3.13 :)  However it was working fine on the intel part so I'll just knock nvidia on the head for now
<tseliot> heh
<davmor2> tseliot: feel free to ping if you get a fix and want it testing :)
<tseliot> davmor2: ok :)
<kgunn> sforshee: ping
<sforshee> kgunn: hi
<kgunn> sforshee: (forgive me i'm a manager, so easier to ask than look)...is there a unit test for powerd screen blanking ?
<kgunn> sforshee: we're continuing to drive ourselves mad...
<kgunn> just hoping maybe there's a unit test for proving we're idiots and using powerd wrong
<sforshee> kgunn: I don't think there's a unit test, but really I'm not even sure exactly what you want to test
<kgunn> sforshee: i was just curious if there existed some basic functional test blanking/unblanking...checking results...stressing/out of order calling that sort of thing
<kgunn> sforshee: its ok...i was just checking
<kgunn> sforshee: i'm gonna get one of my guys to draw up a sequence diagram
<sforshee> kgunn: there's 'powerd-cli test' which tortures powerd via the dbus api in every way we could think of
<kgunn> of what we have...maybe you could review our thinking as well
<kgunn> heh
<kgunn> sforshee: thanks
<sforshee> kgunn: np
<bjf> jsalisbury, can i borrow some of your time? can you look over recent precise / lts-backport bugs and see if we've introduced any nasty regressions in this last round of -updates?
<bjf> jsalisbury, i'll so the same and ask sconklin to look as well
<sconklin> bjf: ack
<jsalisbury> bjf, sure thing
<sconklin> bjf - work off the "30 days report" ?
<bjf> sconklin, yeah, that's my thought
<jsalisbury> bjf, any specific type of regression or just any regression in general?
<bjf> jsalisbury, well .. this kernel is for the point release so anything that we would want to fix before it went into that release
<jsalisbury> bjf, got it
<jsalisbury> bjf, sconklin It looks like the "Last 30 days" report on cranberry is way out of sync.  The one on people looks ok though:
<jsalisbury> http://people.canonical.com/~kernel/reports/30-day-new.html
<sconklin> I was looking at people, thanks
<jsalisbury> bjf, sconklin, after a quick search, there looks to be maybe two bugs that could be nasty regressions and should be reviewed.  A third, not so bad, but worth looking at.  Want me to send email with the details, or just post bug links here?
<jsalisbury> bjf, sconklin The two more serious bugs are bug 1265417 and bug 1267321
<ubot2> Launchpad bug 1265417 in linux (Ubuntu) "crashed after install ubuntu and then click contuine testing" [High,Confirmed] https://launchpad.net/bugs/1265417
<ubot2> Launchpad bug 1267321 in linux (Ubuntu) "Kernel panic Ubuntu 12.04.2" [High,Incomplete] https://launchpad.net/bugs/1267321
<bjf> jsalisbury, i'm happy with buglinks here
<jsalisbury> bjf, sconklin Another recent regression, but not as serious is bug 1267368
<ubot2> Launchpad bug 1267368 in linux (Ubuntu) "FN+F5 - F6 not working" [Medium,Incomplete] https://launchpad.net/bugs/1267368
<jsalisbury> bjf, sconklin And one that is not a regression, but looks like it could be an easy cherry-pick fix is bug 1262388
<ubot2> Launchpad bug 1262388 in linux (Ubuntu) "8086:08b1 [Toshiba Satellite P55-A5312] Intel 7260 Wifi regularly crashes" [High,Triaged] https://launchpad.net/bugs/1262388
<sconklin> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1266005
<ubot2> Launchpad bug 1266005 in linux (Ubuntu) "Computer started to reboot instead of shutdown after kernel update" [Medium,Confirmed]
<bjf> infinity, when do 12.04.4 test images start getting spun?
<infinity> bjf: Better to ask Colin, he's driving that.
<bjf> infinity, ack
#ubuntu-kernel 2014-01-11
<miseria> "que veloz y en contravia se evapora nuestra vida, al mirar pasar la corriente desde la cima de un puente" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
#ubuntu-kernel 2014-01-12
<apb1963> I've been having severe load issues for months with 12.04.3... and I noticed today that I had no swap file or partition.  So I installed one.  Hard to be sure, but that seems to have helped but maybe it's my imagination, I don't know.  Anyway, as the load started to rise a few minutes ago, I was looking at top and I noticed there were 5 zombies.
<apb1963> I had thought zombies were a thing of the past, back when kernels were buggy or some such. 
<apb1963> But regardless, I wonder if there's anything I can do to figure out what the heck is creating this load?  I noticed the swap issue because kswapd0 was using a lot of CPU and in fact in the D status... now that seems to be resolved for the moment... so, I'm looking for what else might be causing all this grief.
<apb1963> Any recommendations?
<apb1963> Thoughts?  Ideas?  Words of wisdom?
<JanC> zombies happen because of buggy userspace
<JanC> apb1963: my guess would be that your system doesn't have enough memory; maybe you need to tune some applications to use less memory, or some applications are leaking memory and need fixing, or maybe you really need more memory
<apb1963> JanC:  thank you for your response.  Please review the output of free -m: http://paste.ubuntu.com/6736119/
<JanC> well, zombies should be irrelevant
<JanC> (at least in most cases, I don't know about corner cases)
<JanC> kswapd kernel tread using a lot of CPU sounds like it needs to do a lot of work for some reason
<apb1963> JanC: right... but that was prior to installing a swap file.  I don't know if it's coincidental or not.
<apb1963> not sure how it was running w/out swap space
<JanC> I could easily run my system without swap  :)
<JanC> at least, most of the time
<apb1963> yes, but as you surmised, I run close to the RAM borderline
<apb1963> I'm currently using 300M of swap
<apb1963> but none of that is the point... the point is the load starts to build quickly and makes the system unusable.. sometimes just the act of running top itself seems to help... other times I have to kill a few processes.. usually chrome, but not always.
<apb1963> At the moment plymouthd is the top user of CPU at 5%.  Load is 0.17 where I would expect it to be.
<JanC> running top can't solve this
<apb1963> I know.... that's why I'm here.  For suggestions as to what I should do... 
<JanC> and I don't se you running "close to the RAM borderline"
<apb1963>  <JanC> apb1963: my guess would be that your system doesn't have enough memory; maybe you need to tune some applications to use less memory, or some applications are leaking memory and need fixing, or maybe you really need more memory
<JanC> most of RAM is used by filesystem buffers & such, based on what you pasted there?
<apb1963> ok.... and?
<JanC> is this a 64-bit system, and were you doing a big I/O operation while things stalled?
<apb1963> 32 bit
<apb1963> and I'm not sure what represents a "big I/O operation" specifically.  I understand what you're asking in general terms, but I wasn't doing a file copy if that's what you're asking.
<JanC> yeah, big file copies can cause problems (especially with older kernels), but that's mostly on 64-bit systems AFAIK
<apb1963> those zombies are really bugging me... shouldn't the kernel have reaped them within minutes or less?
<JanC> apb1963: zombies are processes that have a parent process but the parent process didn't reap them
<JanC> so processes that stopped, but their parent didn't act on that
<JanC> stopping their parent process should get rid of them
<JanC> (stopping their parent process would mean they get re-parented to init, which would reap them)
<apb1963> so that's a good point... parents... looking for the option to ps that gives me wchan
<JanC> htop has an optio to show the process hierarchy in a tree  :)
<JanC> you can also see the PPID in top or ps though
<apb1963> unless I nkow which process is a zombie, I won't be able to find the parent.
<apb1963> found it
<apb1963> chrome
<apb1963> what a surprise
<JanC> zombie processes shouldn't be a problem, unless they get created at an alarming rate
<JanC> they should use almost no resources
<apb1963> well what I was concerned about was that they weren't getting reaped...  I forgot that the parent reaps, I was thinking it was the kernel...
<apb1963> so ok, then that's not the issue
<apb1963> just exploring possibilities here
<apb1963> I started up sar
<apb1963> thought I had it running... but that was on a previous incarnation
<apb1963> well, let me do my thing and when it starts to load up again, I'll stick my nose in again
<apb1963> Thanks for the help
<JanC> I had Firefox grow to 24 GiB some tiem ago, still not sure why that happened...  :-/
<JanC> usually it uses less than 2 GiB with > 100 tabs open (which is *way* less than Chromium with 10 tabs open)
<JanC> so maybe you have a process that sometimes grows to use a lot of memory, but maybe it disappears or releases that memory before you have a chance to debug; that's a hard thing to debug if you aren't monitoring
<apw> bug #1262010
<apw> ubot2, ?
<apw> lp#1262010
#ubuntu-kernel 2015-01-05
<hyperair> how does one debug an initramfs image these days?
<hyperair> i've spent the entire morning searching for ways to extract multi-segment initramfs images, but nothing seems to show me anything useful
<hyperair> aha, finally managed to find the XZ header
<hyperair> sdigh
<hyperair> sigh*
<apw> bjf, this lts uname issue you mentioned, it was uname -r which was wrong, right ?
<bjf> apw, thinking ...
<apw> bjf, looks like ~precise1 used to appear in uname -v only, and does not for -utopic, the other values and places look ok
<bjf> apw, i do a uname -vr though i think it's the uname -r that should be wrong
<bjf> apw, actually, it looks like it needs to be the uname -vr ... the ~<series> appears after the abi
<apw> bjf, yeah it used to be in a totally useless place; really it should be part of the series abi, and the directory into which it is placed, so upgrades work ... ugg
<apw> bjf, anyhow i see it now, and will sort it out
#ubuntu-kernel 2015-01-06
<backjlack> Hello!
<backjlack> Are there any known issues with btrfs on 3.13 on trusty?
<backjlack> I've received a report from someone who's seeing memory allocation failures on a system with 24 GB of RAM with dpkg and related operations.
<backjlack> http://pastebin.com/raw.php?i=GXaj1iHp
<backjlack> Basically, they're not actually running apps which require a lot of memory, but they seem to be running into some kind of problem.
<cking> backjlack, are there any special mount options being used?
<cking> i've seen issues with 3.13 btrfs on large memory systems with compression being used
<backjlack> cking: I'll provide /proc/mounts as soon as I get it, shouldn't take long.
<backjlack> sysctl config: http://pastebin.com/raw.php?i=3Guv4KaQ
<backjlack> cking: http://pastebin.com/raw.php?i=zNr62crU That's /proc/mounts from that system.
<backjlack> Please let me know if there's anything else you'd need or if you happen to have any recommendations.
<cking> backjlack, those mount options don't look like the one's I've seen issues with
<backjlack> Yeah, I know what you mean. I've had issues with compression on an older 3.10.
<cking> backjlack, it does seem that there are a lot of slabs being used for inodes, I make it ~4.65GB
<cking> but still, that's still not all of memory
<backjlack> There's btrfs as well.
<cking> backjlack, what's the kernel reporting in dmesg?
<backjlack> 3.13.0-43
<cking> backjlack, I mean, is the kernel reporting any out of memory failures in the kernel log?
<cking> backjlack, it does seem heavily loaded on memory, the conntrack messages possibly indicate lots of open connections etc..
<backjlack> This were logs I've received from the same system before the upgrade to 3.13.0-43: http://pastebin.com/raw.php?i=rSpQU9dk
<backjlack> http://pastebin.com/raw.php?i=rSpQU9dk
<backjlack> http://pastebin.com/raw.php?i=X8pggEsp
<cking> backjlack, I believe there used to be vm.zone_reclaim_mode sysctl that could be set 1 to force cached memory to be reclaimed
<cking> not checked on that lately, but it's worth a punt
<backjlack> cking: Thanks! I've passed that on.
<backjlack> Also, btrfs seems to have some kind of problem.
<cking> backjlack, in what way?
<cking> (mind you, btrfs is experimental, so it does not surprise me)
<backjlack> http://pastebin.com/raw.php?i=X8pggEsp
<backjlack> There's a btrfs related stack trace in there.
<cking> backjlack, i also suggest that vm.min_free_kbytes = 242000 is enabled (or see what it is currently set at), this may help
<backjlack> From what I've been told, these errors were still being encountered, even when that was enabled.
<cking> backjlack, it would be interesting to see how the slabinfo changes in time to see if there is any leaking or it perhaps is just running low on memory because you are running a memory intensive system config
<backjlack> cking: It's not my system, it's from a user. However, I'm interested in making sure the trusty kernel is stable and doesn't have problems.
<backjlack> It's being used by a lot of people and making sure it doesn't have such problems would be great.
<backjlack> What would you need? Periodic snapshots of slabinfo?
<cking> backjlack, periodic snapshots of slabinfo would be useful, eg. every minute or every 5 mins
<cking> as it stands, btrfs being used in production environments when it is "experimental" is a tad worrysome
<backjlack> It's a dev environment, but this is important.
<backjlack> Such usage catches bugs which are rather difficult to catch with automated fs testing.
<cking> sure, I agree, I think a bug should be opened, and we can work through this
<backjlack> I've requested snapshotting for slabinfo and will open an issue after I get the slabinfo snapshots over a period of 24 hours.
<cking> backjlack, well, I'm working on a thorough thrashing of btrfs and I will be backporting fixes once I've identified the kitten killer issues
<backjlack> There are issues even in newer kernels, like 3.14, 3.15 and so on.
<cking> 3.19-rc2?
<backjlack> I've got stacktraces, but couldn't reproduce so far.
<backjlack> I haven't tried that myself or in any dev environment yet. Reproducing the issues is rather difficult.
<backjlack> Getting a hard btrfs crash which takes down the whole system or just crashes btrfs reproduced can be very difficult.
<cking> backjlack, not with my tests, I crash it daily ;-)
<backjlack> Is there a repository for these tests?
<cking> backjlack, xfs tests, generic and xfs specific ones
<cking> I mean "btrfs specific ones"
<backjlack> Ah, I see. Ok, I'll try those as well.
<cking> and I'm testing against a wide mix of mount options, I've been hammering test configs for ~3+ weeks non-stop and I'm building a matrix of failure points
<cking> then I start identifying fixes and backporting them
<cking> I'm on the case
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 10 minutes in #ubuntu-meeting
<jsalisbury> ##
<bjf> apw, LP: #1400289   ...  can you verify ?
<ubot5> Launchpad bug 1400289 in linux (Ubuntu Vivid) "Hyper-V: drivers:scsi:storvsc: Fix a bug in handling ring buffer failures that may result in I/O freeze" [High,Fix committed] https://launchpad.net/bugs/1400289
<bjf> dannf, LP: #1381084  ...  can you verify?
<ubot5> Launchpad bug 1381084 in linux (Ubuntu Trusty) "xgene-enet: add 10GbE support" [Medium,Fix committed] https://launchpad.net/bugs/1381084
<apw> bjf, ack
<dannf> cmagina: ^ can you verify LP: #1381084 for bjf?
<ubot5> Launchpad bug 1381084 in linux (Ubuntu Trusty) "xgene-enet: add 10GbE support" [Medium,Fix committed] https://launchpad.net/bugs/1381084
<bjf> arges, there are two for you: LP: #1396235  and  LP: #1401150
<ubot5> Launchpad bug 1396235 in linux (Ubuntu Utopic) "Ubuntu - unable to use XMON debugger (running ppc64le on PowerVM)" [Medium,Fix committed] https://launchpad.net/bugs/1396235
<ubot5> Launchpad bug 1401150 in linux (Ubuntu Utopic) "Endianness issue in the VPHN topology update code" [Medium,Fix committed] https://launchpad.net/bugs/1401150
<arges> bjf: was just looking at those : )
<bjf> arges, would you be able to verify those if i let you have modoc for a bit?
<jsalisbury> ##
<jsalisbury> ## Meeting starting now
<jsalisbury> ##
<cmagina> dannf, bjf: sure
<arges> bjf: i'd be able to verify 1396235, but 1401150 is a perf fix i could only verify it doens't break things
<bjf> arges, ok, i'll see about freeing up modoc for a bit ... lets shoot for tomorrow if that's ok
<arges> bjf: works for me
<apw> bjf, utlemming is on the case
<bjf> cool
<bjf> sforshee, you think we can mark LP: #1275879 as verified?
<ubot5> Launchpad bug 1275879 in linux (Ubuntu Vivid) "Kernel panic " [High,Fix committed] https://launchpad.net/bugs/1275879
<sforshee> bjf: looking
<sforshee> bjf: I think so, we'll be getting that commit via upstream stable either way
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues January 13th, 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.
#ubuntu-kernel 2015-01-07
<nutin> I'm running kernel 3.16.0-28-generic on xubuntu, with a RealTek RTL8188EE wireless card. It appears that a bugfix for slow speeds with that card was accepted into the 3.18 kernel. Is there any recommended way to run a newer kernel than what ships with xubuntu? Thanks.
<apw> nutin (N,BFTL), no official version updates for 14.10 which I assume you are running from your version string, bug filing a bug with the info you have might get the fix back to v3.16
#ubuntu-kernel 2015-01-08
<backjlack> I'm seeing some weird behavior with tg3 on 3.13.0-43: queues don't show up for both NICs.
<backjlack> http://pastebin.com/D9xagZPN
<backjlack> Why doesn't em1 have the same setup for the queues? I haven't changed its configuration in any way.
<backjlack> Ok, it looks like it has the same setup, but the files aren't being created.
<seb_kuzminsky> if i build out-of-tree kernel modules against a non-pae i386 kernel, can i load and run them on a pae kernel?
<seb_kuzminsky> looks like the answer is "no", because when i try insmod i get: rtai_hal: disagrees about version of symbol module_layout
#ubuntu-kernel 2015-01-09
<apw> seb_kuzminsky, no for sure, the abi is different
<seb_kuzminsky> apw: yep, i see that now
<seb_kuzminsky> thanks!
#ubuntu-kernel 2015-01-10
<xperia> hi all. i am having a problem with loading the new build ipset module in ubuntu. it looks like i need to sign it first. can somebody tell me how this can be done on ubuntu ? i searched for infos but could not find something that works ? what are the needed steps ? downloading the ubuntu kernel sources. using a script and with what keys and from where ?
#ubuntu-kernel 2015-01-11
<yourbeau> hi
#ubuntu-kernel 2016-01-11
<tsimonq2> yay 4.4 is out!
<xnox> i have dual screen monitor setup with classy dvi & vga connectors.
<xnox> my vga screen this morning is 1024x768, instead of the expected 1920x1080
<xnox> on wily
<cristian_c> jsalisbury: hi
<xnox> apw, hi! i have more kernel config requests. Imho _KVM _VIRTIO_* should be set to =y, on s390x, if not throughout. See bug 1532886 
<ubot5> bug 1532886 in linux (Ubuntu) "s390x kernels are inconsistent for cloud stuff" [Undecided,New] https://launchpad.net/bugs/1532886
<xnox> would you please review them for sensibility and shepperd it past the nagging bot =)
<apw> xnox, are those causing issue, or just making you unhappy
<xnox> apw, the VIRTIO_BLK and VIRTIO_NET are failing to boot the cloud images.
<apw> xnox, but presumably that is because they are missing from the initrd or something, as much as not being =y
<xnox> sure.
<xnox> all i have is virtio_scsi.ko because of ./config.common.ubuntu:CONFIG_SCSI_VIRTIO=m
<apw> as it seems more logical for them to all be =m rather
<xnox> apw, no... cause then one requires to have initrd, and cannot do direct kernel boot, no?
<apw> xnox, ubuntu essentially does not boot without an initrd anyhow
<apw> right ?
<xnox> so virtio_blk ends up in -extra
<xnox> which is odd
<apw> well that is likely all wrong
<apw> likely because it has been =y so noone noticed it wasn't being pulled up to -image
<xnox> apw, and do we have any history into why they are =y?
<xnox> and in per-arch rather than in config.common.ubuntu?
<xnox> surely things that are the same on all arches, let's say pre-recent ports should have migrated into config.common.ubuntu?
<apw> "it doesn't work mumble mumble" without, and i think s390x came with it =m and we thought to use that to find out why
<rtg> apw, debian.master/config/s390x/config.common.s390x:CONFIG_VIRTIO_BLK=m
<rtg> debian.master/config/s390x/config.common.s390x:CONFIG_VIRTIO_NET=m
<rtg> those are wrong IMHO
<rtg> or at least inconsistent
<xnox> rtg, see full bug report -> bug 1532886 i have CONFIG_KVM there too, and ZLIB_DEFLATE
<ubot5> bug 1532886 in linux (Ubuntu) "s390x kernels are inconsistent for cloud stuff" [Undecided,Confirmed] https://launchpad.net/bugs/1532886
<apw> rtg, they are inconsistant, but there is no obvious reason tehy _have_ to be =m which is what we discussing
<apw> =y even
<rtg> right
<apw> we have a lot of stuff which is =y because in 2.6.32 they wern't loadable, and we've not come back to them
<xnox> apw, well back in the day we had normal and virtual kernel images. and normal had it as a module, and virtual had it as =y no?
<xnox> and then we merged all kernel flavours to one (or some such)
<apw> xnox, i don't thikn it is as clear as that sounds, but some of that occured
<xnox> and at that point i guess CONFIG_VIRTIO_* did =m -> =y
<apw> it did that becuase it didn't autoload, in the old days
<apw> but, it may well do so now
<apw> i think debian is all =m and happy, so 
<xnox> however, it seems that the current cloud-image building machinery doesn't have -extra image installed, and subsequently initramfs-update doesn't include virtio-blk (automagically or needs to be forced)
<apw> xnox, right so for sure that not being in linux-imageis _wrong_
<rtg> xnox, that is definitely a bug
<xnox> oh, lack of autoloading *sigh* those were the good old days =)
<xnox> i can check that it can autoload, with d-i on s390x on a virtual machine.
<xnox> becase udebs are packaged right and have virtio-blk, and in a qemu vm they should autoload....
<xnox> let me check that.
<apw> xnox, oh goody we have it half right, sigh ^2
<xnox> or rather "for once .udebs are on the ball =)"
<apw> rtg, heh and we might want to upload a 4.3 now :/
<rtg> apw, great :(
<apw> rtg, luckily i have the previous master-next should it come to it
<mamarley> Xenial will eventually be getting 4.4, won't it?
<apw> mamarley, yep, "soon" waiting on some dkms fallout to be resolved as much as anything
<rtg> apw, why don't you go ahead anf force push xenial master-next. I've updated unstable
<apw> mamarley, and inded we had just decided we wen't going need a v4.3 again
<mamarley> Oh, stuff like graphics drivers failing to compile?
<xnox> apw, virtio_net appears to be auto-loaded
<apw> xnox, that is enocouraging
<apw> xnox, so i'd say lets get that fixed in teh inclusion list if that fixes you
<xnox> i only see virtio_scsi.ko and virtio_net.ko in the installer =/
<xnox> sigh, i guess block-modules is not included in the d-i.
<xnox> and well, it's a must really.
<xnox> because then none of the d-i/server installer will install inside a virtual machine =(
<xnox> on some arches....
<xnox> build/pkg-lists/cdrom/powerpc.cfg:block-modules-${kernel:Version}
<xnox> build/pkg-lists/hd-media/amd64.cfg:block-modules-${kernel:Version}
<xnox> build/pkg-lists/hd-media/i386.cfg:block-modules-${kernel:Version}
<xnox> build/pkg-lists/hd-media/powerpc.cfg:block-modules-${kernel:Version}
<xnox> le sigh.
<xnox> so block-modules needs to be added to like ppc64el, armhf, arm64, s390x
 * xnox ponders which d-i builts are used for qemu installs
<apw> rtg, ok the tip i have was last changed on the 24 dec, do you recall doing anything since then to it ?
<rtg> apw, yeah, probably. lemme go back in my local log. I can find the last 4.3 tip
<apw> rtg, the source uploader has:
<apw> commit e0e8e4a3f07e4f489fae0fcbbade29ef4102d04f
<apw> Author: Tim Gardner <tim.gardner@canonical.com>
<apw> Date:   Tue Jan 5 07:35:27 2016 -0700
<apw>     UBUNTU: [Config] CONFIG_ZONE_DEVICE=y for amd64
<rtg> apw, yep, that is what my log shows as well
<rtg> I'll reset master-next
<apw> ok good enough thanks
<rtg> apw, pushed
<rtg> xnox, apw, I'll catch up on bug #1532886 after I get some lunch
<ubot5> bug 1532886 in linux (Ubuntu) "s390x kernels are inconsistent for cloud stuff" [Undecided,Confirmed] https://launchpad.net/bugs/1532886
<xnox> rtg, cool thanks. Well work with apw as to what you want to make things consistent and which way around.
<rtg> xnox, well, if we make VIRTIO_BLOCK and _NET consistent, i.e., =y, then no other changes are needed.
<xnox> sure.
<xnox> but i thought that apw wants to make them all =m and make sure they land in -image, rather than in -extra
<xnox> whichever =) as long as cloudimages still build and are bootable =)
<apw> rtg, prolly the expedient way forward and i will add a card to get that looked at by someone
<xnox> thanks =)
<xnox> apw, rebuilt s390x d-i in a ppa, with block-modules. virtion_blk & _net autoload correctly for me. However, I'm struggling to figure out if there is any initramfs that we want to /not/ have those modules.
<xnox> given that any disk-image can be trivially exported into a VM and booted.
<apw> xnox, right we likley would want them in every initrd, not in the kernel though as they don't go away then
<xnox> right.
 * xnox ponders where/how initramfs decides to include virtio_net or not.
<apw> xnox, it is likley on my list of "always include this if it exists"
<apw> it has quite an extensive list of that
<xnox> failing to grep for it.
<xnox> apw, yeah, we are good. we default to most, and that does "copy_modules_dir kernel/drivers/block" copy all the things.
<xnox> and kernel/drivers/net
<xnox> so turning virtio_blk|_net into modules should be a fairly safe and uneventful.
<xnox> still need to check that all the relevant d-i's have block-modules and that's about it.
<hallyn> apw: sforshee: async ping on bug 1531747, any ideas on how we should fix it?
<ubot5> bug 1531747 in linux (Ubuntu Xenial) "overlay: mkdir fails if directory exists in lowerdir in a user namespace" [High,Triaged] https://launchpad.net/bugs/1531747
<rtg> cking, was there an upstream update for the 'rhashtable: Fix walker list corruption' revert ?
<rtg> cking, nm, just saw https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1526811/comments/4
<ubot5> Launchpad bug 1526811 in linux (Ubuntu Xenial) "SRU: walker list corruption while being intensively stressed" [High,Fix committed]
<cking> rtg yep
<sque> skoe, Hi, are you here? I am interested in your work on bug #1525554
<ubot5> bug 1525554 in linux (Ubuntu) "[HP ProBook 470 G3, Intel Skylake HDMI, Digital Out, HDMI] No sound at all" [Medium,Incomplete] https://launchpad.net/bugs/1525554
#ubuntu-kernel 2016-01-12
<rtg> tseliot, I have a v4.4 kernel ppa:canonical-kernel-team/unstable - looks like fglrx-installer needs some love
<tseliot> rtg: ok, I'll have a look at it, thanks
<rtg> tsthanks
<rtg> tseliot, thanks
<soee_> hi, are there any plans to add 4.4 to Xenial ?
<apw> soee_, yes, we are working on getting the surrouding packages sorted out for that
<soee_> apw: ok, thank you
<apw> soee_, we would hope to have it in sooner rather than later, within a week or so
<soee_> that is great :)
<apw> soee_, 4.4 is expected to be the release kernel version so we'd better get it in :)
<soee_> 4.4 is LTS right ?
<apw> soee_, this release is an LTS and yes, 4.4 is a stable mainline LTS, which is handy
<soee_> thank you
<xnox> apw, infinity and I were discussing the virtio modules, which packages, -udeb packages and d-i builds they should be in, and I've now copied the log into bug #1533382
<ubot5> bug 1533382 in linux (Ubuntu) "A note on virtio blk and net modules" [Undecided,New] https://launchpad.net/bugs/1533382
<xnox> in case we will go ahead with making virtio_net|blk to be =m
<infinity> apw: Feel free to poke me for more context when you decide to tackle.
<dsmythies> I am having touble understanding some kernel configuration file changes between mainline kernel 4.4-rc7 and 4.4-rc8. There seesm to be a dependent changes that is forcing CONFIG_SND_EMU10K1_SEQ and CONFIG_SND_EMU10K1 and CONFIG_SND_EMU10K1X to be disabled, even if one tries to set them to "module" again, they get disabled during compile. see also: http://paste.ubuntu.com/14481736/ 
<dsmythies> A compile of mainline kernel 4.4 will have the modules if one just copies the -rc7 config file and uses it instead.
<dsmythies> I did notice in yesterdays IRC logs a mention of this: CONFIG_ZONE_DEVICE=y
<dsmythies> but am not sure if the context is related.
<dsmythies> So, my question: Is it intentional that the emu10k1 modules be no longer available? Or is this an unintented side effect of another change?
#ubuntu-kernel 2016-01-13
<tsimonq2> under "What do you need help with?" on https://wiki.ubuntu.com/Kernel/GettingInvolved , it shows an outdated link and I don't know where the real link would be.
<dsmythies> tsimonq2, I fixed the link. Try it now.
<apw> dsmythies, it is a consequence of CONFIG_ZONE_DEVICE turning off CONFIG_ZONE_DMA yes
<apw> dsmythies, not convinced the constraints are reasonable, at least for x86_64 where you don't have HIGHMEM so i think there is room for both though the config constraints prevent that
<apw> dsmythies, is that card used for something we are going to notice, like qemu ?
<tsimonq2> thanks dsmythies 
<rtg> caribou: could you have a look at bug #1528101 and tell me if kexec is functioning as designed ?
<ubot5> bug 1528101 in linux (Ubuntu) "ISST-LTE: kdump failed: second kernel booting hangs after /scripts/init-bottom when large min_free_kbytes value being set" [Undecided,New] https://launchpad.net/bugs/1528101
<caribou> rtg: sure
<apw> caribou, not sure if we have any sane way generically to know which options are good to keep and which are not for a kdump kernel, i wonder if we almost want a separate directory of overrides for kdump.
<caribou> apw: I've been running tests to try to come up with some sensible rules for the definition of crashkernel
<caribou> but there are so many variables that come into play that it is kinda hard
<caribou> for instance, I've been testing on VM with up to 22Gb : the default 128M works fine
<apw> so we might just say that this one is a speicifc override to be osmething sane like 1%
<apw> and be happy
<caribou> apw: but when I test on real hardware with 128G of memory, crashkernel=128M comes short not because of the memory but because of the fact that initrd is bigger and it OOMs
<apw> caribou, ok, even with your magic smaller one ?
<apw> so an =dep initrd is still too big for 128M /
<apw> ?
<caribou> apw: that was on trusty so the change was not there; I went on to rebuild with MODULES=dep & got bitten by the initramfs-tools bug that I fixed
<caribou> apw: it works now with a smaller initrd
<apw>  ahh ok
<apw> of course this bug might be moot with that fix too, hrm
<caribou> apw: but in this case, the boot sequence fails before kdump even comes into play
<caribou> apw: partly, on system with SSDs, the kernel hook would fail when building the smaller initrd file
<apw> which we should fix i assume
<apw> for this bug, they are setting min_free somewhere, presumably in /etc/sysctl.d.conf and we really should not be honouring that in the constrained environment
<apw> its not clear how one would know that though programatically
<caribou> apw: LP: #1532146 is waiting for a sponsor if you have a minute ;-)
<ubot5> Launchpad bug 1532146 in initramfs-tools (Ubuntu) "update-initramfs fails for MODULES=dep when root is on nvme device" [Medium,In progress] https://launchpad.net/bugs/1532146
<apw> caribou, yeah its on my todo list :)  i have another initramfs-tools bodge to ram in, just updateing aufs for a nasty hang bug
<caribou> apw: that's fine, as long as it is queued to be fixed somewhere
<caribou> apw: in that case (LP: #1532146), it doesn't even make it to kdump & fails before
<ubot5> Launchpad bug 1532146 in initramfs-tools (Ubuntu) "update-initramfs fails for MODULES=dep when root is on nvme device" [Medium,In progress] https://launchpad.net/bugs/1532146
<caribou> apw: so you're right, we should find a way to boot the kexec kernel w/o using any tailored sysctl values
<caribou> oups, wrong bug : bug #1528101
<ubot5> bug 1528101 in linux (Ubuntu) "ISST-LTE: kdump failed: second kernel booting hangs after /scripts/init-bottom when large min_free_kbytes value being set" [Undecided,New] https://launchpad.net/bugs/1528101
<caribou> rtg: so for your question : kexec doesn't even get activated so yes, works as designed ;-)
<rtg> caribou: since I don't really understand the fine points of the discussion, I'll bug apw and make him explain it.
<caribou> apw: everything in /etc/sysctl.conf + /etc/sysctl.conf.d should not be honoured when the kexec kernel boots
<apw> caribou, should not as in you think they are not, or you think they are and shouldn't ?
<caribou> apw: looks like they are (if indeed they hare changing vm.min_free_kbytes with sysctl)
<caribou> apw: so when the kexec kernel boots post-panic, the kernel should boot w/o implementing what's in sysctl.conf[.d] if possible
<caribou> apw: the kexec kernel is only there to allow for the capture of the kernel dump
<caribou> apw: so there is no reason to apply any user-define customization there
<caribou> am I being clear ?
<rtg> caribou: that makes sense to me
<caribou> apw: rtg: it should be trivial to add a check in /etc/init.d/procps to verify if we have booted in the kexec kernel & not apply the changes
<rtg> caribouhow would you preserve the original sysctl values ?
<rtg> nm, the new kernel would have them as part of its image.
<caribou> apw: rtg: /proc/vmcore is only present if we are booted on the kexec kernel post-panic. This is how kdump-config knows that it has to capture the content
<rtg> caribou: what agent applies sysctl values to the kexec kernel ? kdump ? the initrd ?
<tseliot> rtg: I've just fixed fglrx in xenial. It was pretty easy this time
<caribou> rtg: /usr/sbin/procps apparently
<caribou> rtg: no, /etc/init.d/procps
<rtg> tseliot, thanks, it was the primary show stopper for a 4.4 kernel in xenial
<tseliot> good :)
<ricotz> rtg, tseliot, nice :)
<apw> caribou, yeah, that sounds like a sensible option, i might suggest it ought ti possibly have a kdump.conf.d or osmething which is applies instead, just in case there is something you need
<caribou> apw: make sense; the override would only apply kdump.conf if it exists
<apw> caribou, then in the unlikley event there is something you need in both you link the ifle into both .d's and be happy
<caribou> apw: though, it does nothing for this bug as I doubt that touching something as central as procps would qualify for SRU
<apw> caribou, there is nothing to say you can't change things like that, we might need to make it opt in or something
<apw> caribou, so like if there is a kdump.conf we use that _rather_ than the normal ones, and they can make it empty
<apw> sysctl-kdump.conf
<apw> so that the default doesn't change perhaps, something like that
<apw> you are our dump expert, and if you say its wrong that kinda makes it wrong and wrong things can be fixed in sru's
<caribou> apw: well the argument that it only applies in the context of the kexec post-panic kernel an never in a normal user context migth be sufficient
<caribou> apw: am I ???? :-D
<apw> caribou, clearly :)
<caribou> ok, let me run with that  & see what I can propose; I'll also comment in the bug
<caribou> apw: ^
<rtg> caribou: would you like me to take a stab at the patch and run it by you ?
<apw> rtg, or you could sponsor it for him
<rtg> apw, that to
<rtg> too*
<apw> sweet sorted
<caribou> rtg: let me try it, then I'll run it by you guys
<rtg> ack
<caribou> apw: rtg: is it possible to force vm.min_free_kbytes as a boot parameter (for a temporary workaround) ?
<apw> caribou, it is possible yes
<apw> i can't say for cirtain without looking though
 * rtg does not see anything promising in Documentation/kernel-parameters.txt
<caribou> apw: don't bother, I'll look it up; thought you might know it off the top of your head
<apw> ak
<apw> ack
<caribou> apw: fedora fixed it a while ago : https://lists.fedoraproject.org/pipermail/kexec/2014-November/001478.html
<caribou> apw: not too found of how they fixed it though
<apw> caribou, no, but then there is precident, perhaps we can do that in SRUs and something cleverer in the new releases
<caribou> apw: indeed
<apw> cirtainly i'd not want to hard code it like that, ugg
<apw> and that only fixes it if it is in /etc/sysctl.conf at that, not sysctl.d ... hrm
<rtg> eeew!
<caribou> tbh, I'm not sure if the fix went in but it was reported
<caribou> rtg: apw: here is a question for you : does the kernel rely on sysctl settings to boot correctly (i.e. do we use that mechanism to fix some behaviors) ?
<apw> caribou, well as they are applied in root, they cannot be used to fix root disk related behavious
<rtg> caribou: there might be a lot more console noise
<caribou> rtg: I also see some hardening things in there we might want to keep
<rtg> caribou: doesn't kexec immediately reboot ? 
<rtg> after acquiring the dump
<caribou> rtg: yes
<rtg> in which case hardening might not be so important
<apw> caribou, and we don't bring up things like networking do we
<caribou> apw: yes, especially if we want to do remote dumps
<caribou> apw: but it is not even dependent on remote dumps : network comes up systematically
<caribou> made my life soo much easier when I developped remote dumps
<apw> caribou, then there are options there which may be necessary, hrm
<apw> caribou, how about then having an sysctl-kdump.conf which is loaded _after_ all the others, which can set things "back"
<caribou> apw: interesting; the only thing is to know _what_ to set "back"
<apw> caribou, well we literally only know of one thing which should not be set, so it could start with that
<apw> (if we know what a sane value is)
<caribou> apw: in worst case scenario, it would be the sysadmin responsability to add to this file in case of problem; at least the mechanism is there
<apw> caribou, yeah, something like that
<caribou> apw: & we override the values for things we know would cause problems
<apw> the only issue really is knowing what to put in that one
<rtg> perhaps just vm.mmap_min_addr for now (which we _know_ is causing problems)
<caribou> rtg: that's my idea for a starte
<caribou> starter
<caribou> rtg: apw: as I don't think we have an easy way to identify what was the original value in the kernel's namelist before sysctl changed it
<apw> caribou, yeah, and its magic essentially
<apw> asses
<caribou> apw: ok let start with that
<rtg> if it is never set after kexec boots, then it is by default set to the kernel value, right ?
<rtg> which ought to be OK
<caribou> rtg: the kexec kernel will apply the sysctl changes just like the regular kernel
<caribou> rtg: just trying to find a way to avoid disabling sysctl alltogether
<rtg> caribou: except that you are going to modify procps to do something different (I thought)
<apw> caribou, of course we know how much memeory we have, it is 128M so a fixed value for that is "ok"
<caribou> apw: let me run a first pass at it & see what I can come up with 
<apw> rtg, the point here is that sysctls can be requried for networking and the like
<apw> rtg, and knowing whihc are ok and which not is hard
<rtg> understood
<apw> caribou, i assume what happens now is we copy these into the initrd, apply them all there, and then again once we mount root (for non kdump boots)
<apw> caribou, which is why eliding them by name works for the fedora case
<caribou> apw: no, apparently the sysctl stuff is taken from thre real root & not the initrd
<apw> caribou, well that code is copying them into the initrd and they elide the problem one at that point
<apw> anyhow have a go and see what happens
<caribou> apw: sure
<dsmythies> apw: I do not actually have the sound card (Creative Labs SB Audigy) and came here on behalf of someone else, after helping them isolate the issue (at least to the point where I needed help here). Yes, his AlsaMxer program isn't working,as the card isn't being detected. I also wonder if some of those other sound card differences in the kernel configuration file are for the same reason (ref:  http://paste.ubuntu.com/14481736/ )
<apw> dsmythies, oddness, the delta i was shown was just the one card
<apw> rtg, ^ ?
<apw> rtg, did we investigate whether we could remove that config snippet for CONFIG_ZONE_DEVICE ?
<tjaalton> 4.4 doesn't see my nvme drive.. boot fails because of that
<tjaalton> mainlines at least
<tjaalton> are the soon-to-hit xenial packages somewhere?
<apw> tjaalton, ckt unstable ppa
<rtg> apw, I have not.
<tjaalton> apw: thx
<apw> rtg, i think we need to resolve what we are donig about that one before we release 4.4 as well
<rtg> apw, maybe have a diff setting for lowlatency ?
<apw> rtg, well whether we can in fact turn on both for the case we care about, amd64
<dsmythies> apw, rtg: Thiss issue is on both lowlatency and generic, but yes amd64.
<apw> rtg, obbvoiusly the config constraints don't let us, but i think on amd64 we have no HIGHMEM so we have one more spare bit, and if we do then we can have zone_dma and zone_device together
<apw> that means i386 can't have both, but we're not caring about those
<rtg> apw, yeah, I'm not too concerned about NVDIMM on 32 bit
<dsmythies> tjaalton: Have a look at this: http://askubuntu.com/questions/709794/dell-xps-13-9350-compatibility/719947#719947 I do not know if it is true or not that CONFIG_BLK_DEV_NVME=y is needed.
<manjo> I have been modifying debian/rules.d/2-binary-arch.mk to skip modules signing if the private key is not available .. is there a way to tell builds in LP not to fail of if private key is not available? or what is the correct way of building it ? 
<manjo> apw, ^ ? 
<apw> manjo, we generate the private key during the build ?
<tjaalton> dsmythies: sounds like initramfs fail to me
<manjo> install-%: MODSECKEY=$(builddir)/build-$*/certs/signing_key.pem
<manjo> apw, ^ looks like it expects the key to be there 
<manjo> apw, May be I am missing something .. I have been doing if [[ -f "$(MODSECKEY)" ]] ; then \ round the signing code ... which I don't think it the right thing to do 
<apw> manjo, right, it expects it to be there because it makes it
<apw> manjo, so it should be making it, why is yours not
<manjo> apw, ppisati ran into the same issue with arm builds (many months ago)
<apw> maybe so, if so he may remmber what he was doing wrong
<apw> manjo, but i say again, the build makes that key
<manjo> apw, ok let me build in PPA and get it to fail... that will give me and idea what is going on .. 
<apw> manjo, see certs/Makefile 
<apw>         @echo "### Now generating an X.509 key pair to be used for signing modules."
<apw> it is that key which we then use to _resign_ the modules after stripping them
<manjo> apw, I have been blindly carrying this patch is my PPA builds and May be it is not needed anymore ... let me build without it and see if the keys are generated 
<apw> manjo, we have always built our kernles in PPAs and never needed such a thing
<rtg> manjo, there is this patch for newer kernels: 'UBUNTU: [Debian] Update to new signing key type and location'
<manjo> rtg, ok so that must have fixed it for me .. I will drop this mod to skip signing 
<tjaalton> dsmythies: 4.4.0-0 finds the drive, but cryptsetup fails with "lvm is not available"
<caribou> apw: rtg: back to the vm.min_free_kbytes
<rtg> hmm
<apw> tjaalton, you'd think we would have noticed that lvm wasn't available in initrd ?
<apw> caribou, ?
<caribou> apw: rtg: how about I add an option to kdump-config that would re-apply values as found in /etc/default/kdump-tools ?
<caribou> apw: rtg: this option would be called by /etc/init.d/procps if /proc/vmcore is found
<apw> /etc/default/kdump-tools is in shell format right?  waht would you proposed to encode in tehre ?
<rtg> caribou: what would be the packaged defaults in /etc/default/kdump-tools ? Anything ?
<caribou> apw: yes, I would add SYSCTL=vm.min_free_kbytes=blah and loop through each SYSCTL varible found
<caribou> rtg: we can put anything we know can cause problems & sysadmin can add to it'
<rtg> seems reasonable
<apw> caribou, or perhaps SYSCTL_UPDATES=/etc/sysctl-kdump.conf or something and use that file
<caribou> this way I restrict modifications outside of the kdump-tools realm to a minimum
<apw> caribou, but i like the idea of passing the problem to kdump-config in procps
<caribou> apw: the advantage of looping through the existing /etc/default/kdump-tools file is that I don't need an extra file
<apw> i think making that file overly complex is a mistake because things like systemd read them for you and convert them to environment variables and the like
<apw> caribou, well mangling existing defaults which are there are difficult especially with that new non-standard format
<apw> by making that a differnt sort of entry you make it hard to migrate configs later etc
<apw> caribou, also why do we even need to change procps if you do it via kdump-tools
<caribou> apw: true; especially since kdump-config sources the default file at the begininng. I'll use your option
<caribou> apw: because, like in that specific bug, we don't get as far as running kdump-config, it fails before that
<caribou> I can reproduce it btw
<caribou> apw: that was my initial idea, but it has to happen right when procps runs
<apw> caribou, but can we just get in before it, by being earlier
<apw> kdump-config is running in initramfs or in real root when it runs
<apw> ?
<caribou> apw: real root, so is procps
<caribou> apw: so the procps modification is only to run sysctl -p /etc/kdump-config.conf if /proc/vmcore exists
<apw> caribou, i presume the issue then is that the act of setting it to a large value ooms the box immediadly
<apw> caribou, so you can't then set it back, you already ooms
<caribou> apw: exactly
<dsmythies> apw, rtg: For my own curiousity, could you point me to "the config snippet for CONFIG_ZONE_DEVICE". So far, I haven't been able to find it.
<rtg> mm/Kconfig:config ZONE_DEVICE
<apw> config ZONE_DEVICE
<apw>         bool "Device memory (pmem, etc...) hotplug support" if EXPERT
<apw>         default !ZONE_DMA
<apw>         depends on !ZONE_DMA
<apw> we might also need to fix the ZONE_SHIFT calculation, but, i can't see why this won't work
<tjaalton> apw: I'll check the diff between 4.3 & 4.4 initrd's and see what's going on there
<apw> tjaalton, lack of -extras perhaps ?
<apw> in your testing ?
<tjaalton> well this same thing is with mainline builds
<apw> caribou, so are you proposing to only apply that one file if you find it, and let kdump-ocnfig generate it or ?
<tjaalton> -extra is installed
<apw> caribou, as we cannot apply the real changes and then apply this one back over the top, as that will likely oom us in the middle
<caribou> apw: looks like it (I'm testing it at the same time)
<caribou> apw: I was thinking of applying the content of /etc/kdump-config.conf over the existing
<apw> i think you'll find the first will blammo on you
<caribou> apw: looks like the simple fact of applying vm.min_free_kbytes triggers the OOM
<apw> which makse sense when you look at the kernel code, it forfully empties memeory to make the boundary
<caribou> apw: then no matter what, we need to avoid this change to even happen
<apw> ugg
<apw> caribou, does the kernel know it is in kdump mode ?
<caribou> apw: yes, as it exposes /proc/vmcore
<caribou> apw: but isn't changing the kernel because one silly setup triggers OOM a bit of an overkill 
<caribou> ?
<rtg> apw, fix this in the kernel by ignoring vm.min_free_kbyte if kexec'ed ?
<apw> rtg, i am thinking about it, yes
<apw> if /proc/vmcore is valid in fact, but yes
<rtg> hmm
<apw> as kexecing is a valid way to reboot too
<apw> and in the normal case we don't care, but if we are exposing a dump file to uspace then we coudl ignore uspace
<apw> caribou, rtg, though there is a separate way of looking at this
<caribou> userland is changing a kernel setup in a limited memory context, I would rather avoid changing this value if we very well know that we're in a limited contgext
<apw> that the request for memory can _never_ succeed, the request for reserve is large than total ram
<caribou> limited memory context
<apw> returning -ENOWAY instead vbecaus the request is rediculous might be sane
<caribou> apw: true
<rtg> instead of OOM'ing
<apw> right ooming is rarely useful
<rtg> apw, doing it that way means we don't have to care if /proc/vmcore is valid
<apw> rtg, so the code as it stands divides the limit you specify between all the non-highmem zones you have
<apw> so if you say 1000 pages and you have 10 in DMA and 90 in NORMAL
<apw> it will demand 100 in DMA and 900 in NORMAL even though that is patently nuts
<rtg> apw, seems like refusing the sysctl is a reasonable action
<apw> rtg, though even if i make it say you need enough memory in your zones to cope there are likely to be combinations which are just numerically valid and not viable
<apw> rtg, and telling those appart is tricky at best
<apw> caribou, eliding specific entries in userspace falls to procps, to sysctl itself detecting /proc/vmcore and ignoreing some names textually (me thinks) which is a little vile, but no vialer than doing so in the kernel
<tjaalton> apw: weird, 4.2.0-16 doesn't have sbin/lvm either, but it still works
<caribou> apw: ok, I'm looking into that
<caribou> apw: and at the same time, asking for the kernel to keep a minimum of 312M free and setting crashkernel=128M makes no sense, they should just increase crashkernel
<apw> caribou, well they claim to be using 768M for crashkernel i think, but either way its bonkers
<tjaalton> apw: oh, nvme.ko is not shipped with 4.4 initrd, because the module location changed
<apw> tjaalton, i thought initramfs-tools looked at those by module name only ?
<tjaalton> dunno, but it should be in kernel/drivers/nvme/host/nvme.ko now
<apw> oh perhaps it is shipping all "block/*" or something
<tjaalton> instead of kernel/drivers/block/nvme.ko
<apw> tjaalton, can you file me a bug against initramfs-tools for that please
<rtg> tjaalton, that means I should fix debian.master/control.d/generic.inclusion-list:drivers/block/nvme.ko
<apw> and give me the # and i'll batch that up with the other two critical fixes
<apw> rtg, needs fixing there too yes
<rtg> apw, I'll take care of it
<tjaalton> rtg: you'll file the bug too?
<rtg> tjaalton, nope, its  dev kernel. I'll just fix it
<apw> i think he is saying he will fix the kernel bit, but i would love a bug for initramgs-tools for that bit
<tjaalton> right but initramfs-tools needs fixing too
<tjaalton> yeah I'll file that bit
<apw>                         copy_modules_dir kernel/drivers/block
<apw> yeah it copies on all block devices, and that just moved out of there
<tjaalton> fixed in debian https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807000
<ubot5> Debian bug 807000 in initramfs-tools "initramfs-tools: module nvme not included in block modules on kernel > 4.2" [Normal,Fixed]
<apw> tjaalton, not sure that that fix makes a whole heap of sense in the face of the change the kernel is making, long term, but hey
<tjaalton> apw: what do you mean? cryptsetup works again with that, just tested
<tjaalton> apw: heh, two bugs already filed about this
<tjaalton> https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1524879 https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1532146
<ubot5> Launchpad bug 1524879 in initramfs-tools (Ubuntu) "initramfs-tools, Xenial is missing NVME kernel driver" [High,New]
<ubot5> Launchpad bug 1532146 in initramfs-tools (Ubuntu) "update-initramfs fails for MODULES=dep when root is on nvme device" [Medium,In progress]
<tjaalton> the first already properly assigned :P
 * xnox thought apw was going to sponsor that cherrypick
<xnox> as asked on irc some friday back.
<rtg> ppisati, I forgot to mention that Ubuntu-4.4.0-1000.6 works well with your image
<apw> xnox, then i am already doing it indeed :)
<ppisati> rtg: good to know
<dsmythies> apw, rtg: I am not understanding the config dependency trail, or what to change in order to be able to compile a test kernel. Do I just delete that ZONE_DEVICE snippet?
<rtg> ppisati, hopefully it will work with Snappy as well
<apw> dsmythies, no, we want to test building with the config requirement for !ZONE_DMA removed and that turned back on
<ppisati> rtg: it will
<apw> and see if tht builds on amd64
<ppisati> rtg: though i might have found a problem with xenial/arm64
<ppisati> rtg: so, no matter if i cross or native compile
<rtg> ppisati, the module load problem ?
<ppisati> rtg: right
<ppisati> rtg: if i compile under wily is fine
<rtg> ppisati, I noticed that it seems to be a toolchain issue
<ppisati> rtg: while it blows in a xenial chroot
<rtg> dannf found that one, right ?
<ppisati> rtg: it happens if i crosscompile (xenial/amd64 -> arm64) or native (my arm64 ppa)
<ppisati> rtg: i found it, and dannf confimed he sees that too in xenial 4.3
<ppisati> dannf: ^
<rtg> ppisati, what is Linaro using ?
<dsmythies> apw: O.K. so delete this line: "depends on !ZONE_DMA" then. (sorry for being a bit think on thick on this one).
<ppisati> rtg: no idea
<ppisati> rtg: you mean the toolchain
<rtg> yeah, maybe Salvetti has some thoughts
<dannf> ppisati, rtg: my next step was to rebuild gcc w/o linaro patches to see if that fixes it
<dannf> (otp, sorry for lag)
<rtg> dannf, are there patches in gcc specific to that arm64 errata ?
<dsmythies> I meant to say "sorry for being a bit thick on this one".
<apw> dsmythies, yes, then readd CONFIG_ZONE_DMA=y to the config and run fakeroot debian/rules updateconfigs
<apw> and then see if the build builds any more, i suspect it may not
<apw> but it may be resolvable
<apw> (on amd64)
<dannf> rtg: yeah
<dsmythies> apw: I will report back, but it might be awhile (like hours).
<jmux> How can I build a kernel containing a ddeb package? I just have a linux-lts-trusty-tools ddeb as an output of my build.
<apw> jmux, how are you building them ?
<jmux> My problem is actually http://ddebs.ubuntu.com/pool/main/l/linux-lts-trusty/, which doesn't contain debug symbols for the range from 15-Jul-2014  to 10-Nov-2015
<arges> jmux: depending on the version it may be archived in launchpad
<jmux> apw: sbuild -A -s -d tramp --arch=i386 --add-depends=pkg-create-dbgsym linux-lts-trusty_3.13.0-34.60~precise1.dsc
<apw> right, we moved ddebs into the librarian around that time, though i would expect them to be in there
<apw> jmux, if you arn't on a real builder it will optimise away the .ddebs because they take an hour to package
<jmux> apw: I get the ddeb for the linux-lts-trusty-tools. I even set AUTOBUILD=1
<arges> apw: they are gone: https://launchpad.net/ubuntu/+source/linux-lts-trusty/3.13.0-34.60~precise1
<apw> you need something like full_build=true passed to debian/rules
<arges> this is how i've done it: http://chrisarges.net/2015/10/02/building-ubuntu-kernels-with-debug-symbols.html
<apw> arges, full_build=true is the approved incantation there, though the effect is similar
<arges> apw:noted
<jmux> Hmm missed full_build in debian/rules.d/0-common-vars.mk
<apw> jmux, it isn't something that one expects (like the spanish inquisition)
<jmux> Probably an other problem "man xz: Multithreaded compression and decompression are not implemented yet, so this option has no effect for now."
<jmux> So even if the build finishes in 10 minutes, the compression will take ages, I guess
<apw> it takes ages for sure, like 10 on our massivly fast boxes, hours on others
<apw> they make one cry in the main, whihc is why they get turned of by default for local builds
<apw> did you look and see if the one you needed was in the librarian though ?
<jmux> Is there a way to query librarian directly? The ddebs are in the build logâ¦
<apw> i'd say from the .changes from the buildd that the .ddebs were collected under the old system
<apw> arges, does sts still keep history on those?
<arges> apw: i don't think so
<arges> i didn't find in the librarian so best bet it to regenerate them.
 * jmux is not sure the debug symbols will actually help with MCE like http://paste.debian.net/365584/
<apw> jmux, nope, did you try what it suggests ?
<jmux> Yup - but didn't help me
<jmux> http://paste.debian.net/365586/
<apw> jmux, what are you hoping it will tell you?  that says that when we were handling a page fault the internal state of the CPU was found to be wrong and unfixable
<jmux> But these machines were working flawlessly on lucid for years. No idea, why they stop working on precise with trusty stack
<apw> well they may be throwing errors all the time which the old kernel doesn't understand at all (which being lucid it would not)
<apw> those newer kernels almost cirtainly have the ability to read MCEs at all whereas the older ones did not i suspect
<jmux> apw: might be. I've just started collecting information. Not sure if a backtrace contains info about the origin of the page fault.
<apw> jmux, if that EIP is accurate (and it implies it is not but hey) that is the very first byte of the exception handler
<apw> jmux, and is this a 32 bit kernel ?
<jmux> it might be a really unnoticed HW bug - no idea yet
<jmux> Yup 32bit
<apw> if the things is occuring often and reproducibly you could try rmeoving the MCE handler (if it is a module) and see
<apw> if the machine is symptomless afterwards
<apw> as it was on lucid, it may be just be that they are bogus, given it never exploded before
<jmux> Problem is I really don't know what triggers it. I got the exact HW of a known problematic box and it took 12 hours to trigger.
<apw> jmux, it is possible nomce on the kernel command line will shut it off for that purpose
<apw> of course if it is real, all bets are off in that case
<jmux> This happens for random people
<jmux> About once in a week
<jmux> Support has actually played with Intel C states in BIOS which fixed it for some people
<apw> oh lovely
<jmux> That's why I still hope it can be a kernel bug, I'll also update the kernel. But for that random bugs without a real triggerâ¦
<jmux> I had the crazy idea of the new kernel using more power, probably because of new featuresâ¦ instable systemâ¦ all I know is Lucid worked for years and problem started with the precise updates
 * jmux hopes that shipping truisty with xenial stack will help, but that's half a year away
<apw> jmux, they likley would have simply not been detected before in lucid
<apw> even if they were happening
<jmux> And something like "MCA: Internal unclassified error: 402" doesn't help
<jmux> I'll also try latest microcode updates
<jmux> If I get the same error tomorrow, I have probably at least one vaid data point. And there are BIOS updates.
 * jmux shivers thinking about BIOS updating a few thousand machinesâ¦
<apw> jmux, a job for life ... literally
<jmux> Oh - and I just got the MCE error via serial null modem connection
<apw> jmux, a google of the specific error shows people sending their CPUs back for replacement to good effect o.O
<apw> (which if it was true would make upgrading the BIOSen look like a fun game)
<jmux> apw: hmm If all machine would show this MCE, but currently they just have a blank screen. Without the null modem, I wouldn't have seen this.
<apw> jmux, yeah the "kms will guanretee you can see panics" promise, not so much
<jmux> Probably disableing DPMS for known machines would help here
<jmux> Probably installing mcelog will also help
<apw> good luck
<jmux> Everything linux wise I can deploy automatically. mcelog definitly makes sense, as this would probably allow to catch the MCE errors
<jmux> Hmm https://access.redhat.com/solutions/1161573 has the same HW. Guess I'll have to contact some server guys tomorrow
<jmux> "Following MCE logs were collected from serial consle."
<jmux> It's not page_fault but intel_idle, but otherwiseâ¦
<apw> jmux, i note it talks about using "nomodeset" which if you find a box which reproduces regularly is worth a shot
<jmux> The "reproduces regularly" is the problem. So actually a kernel update might help, or the solution will just state "get a new CPU"
<jmux> I hope my local crash will happen again in the next 12 hours
 * jmux hopes for a software solution
<jmux> apw: thanks for your support. /me will leave for the cinema in a few minutes
<dsmythies> apw: The build failed, and for the reason you predicted, ZONES_SHIFT, which cascades into a bunch of other errors.
<dsmythies> apw: #error ZONES_SHIFT -- too many zones configured adjust calculation
<apw> dsmythies, yep thanks, will have a look at it perhaps in the morning -- if the other plates stay up
#ubuntu-kernel 2016-01-14
<caribou> apw: I owe you an apology : I handed you a slightly rotten patch for initramfs-tools :-/
<apw> caribou, heh ooops
<apw> that might explain cking's failure then
<caribou> apw: yes it does; the patch was done on trusty and  one variable name changed
<apw> caribou, np, it went into my test PPA for this reason
<cking> and i like testing things :-)
<caribou> cking: :)
<caribou> apw: the variable ${root} got changed by ${dev_node} b/w the two versions
<apw> caribou, wanna mail me an update and i'll respin it
<caribou> apw: you should even be able to edit the quilt patch manually; I'll email you the details
<apw> ok, its not a quilt patch any more because we don't do that on native things and its in git and ...
<apw> but details of whatall exactly to change is good
<caribou> apw: true, that's a native package
<caribou> apw: ok, I just sent the mail
<caribou> apw: just wave at me when you want me to re-test it
<apw> thanks
<xnox> apw, i've upgraded to linux-generic 4.3.0.6.7 package from proposed, yet my /boot/vmlinuz and /boot/initrd.img symlinks still point at the old -5-generic abi files
<xnox> how should i go about debugging this? which bit is responsible to update them?
<apw> xnox, and you got linux-iamge etc installed ok ?
<apw> xnox, as they are updated from postinst there
<apw> xnox, the same postinst which builds you initramfs
<xnox> yeah i have linux-image-generic                  4.3.0.6.7
<xnox> let me read them, and re-run them again. (aka downgrade make sure everything is clean and check what's going on)
<apw> no that is the meta package, i mean the real binaries
<apw> linux-image-xxxxx-6-generic is the one which installs the links
<xnox> i have linux-image-4.3.0-2|5|6-generic, and headers, and extra
<apw> and the links will always be the _last_ one you installed
<apw> not the highest
<apw> and of course they are ignored for grub, not sure about zipl
<apw> do we generate a menu using the real files or just "current and previous" using the links ?
<xnox> at the moment we don't generate a menu, no.
<apw> so i assume it is static pointing at the links
<xnox> i do want to start generating menus, for all variants.
<xnox> yeap.
<apw> the links are right on my local machine for whatever that is worth
<apw> not that i would notice if half the time they were not
<xnox> apw, the whole lot is a mess. also is it even allowed to have perl as postinst scripts?!
<apw> xnox, heh, we've done it for years, so possibly
<xnox> so i download -5- of headers, headers-generic, image, image-extra.
<xnox> i will fully uninstall and purge -5-
<xnox> install these .debs again
<xnox> and expect the symlinks to be update.
<xnox> and expect the symlinks to be updated.
<xnox> e.g. when -5- gone, symlinks should point to -6-
<xnox> and when -5- is installed again, symlinks should point to -5-
<apw> should point to whatever prev pointed to
<xnox> removing linux-image-4.3.0-5-generic failed.
<xnox> symlinks still point to -5- and running postinst.d/zz-zipl fails cause the config points at broken symlinks
 * xnox files a bug.
<xnox> apw, http://paste.ubuntu.com/14495976/
<xnox> apw, i wonder if /etc/kernel/postrm.d/zz-zipl is run too early.
<xnox> reinstalling -6 on top, doesn't fix the symlinks, as
<xnox> Not updating initrd symbolic links since we are being updated/reinstalled 
<xnox> (4.3.0-6.17 was configured last, according to dpkg)
<xnox> which is true, but when one has broken symlinks on disk, surely they should be fixed to point at something real.
<xnox> apw, anything wrong in this case - http://paste.ubuntu.com/14496011/ ?
<xnox> apw, i am an idiot
<xnox> ...
<xnox> aghrrr
<xnox> so kernel updates / symlinks, and zipl-installer is using symlinks in /boot/
<xnox> i'm not sure what creates symlinks in /boot/ or manages them.
<xnox> also not sure if zipl can handle symlinks in /, rather than /boot/
 * xnox ponders which way it's better to fix these.... to follow kernel lead, or to follow zipl-installer lead
<xnox> i guess the real answer is, that i should generate entries for things in /boot/ properly.
<xnox> and zipl-installer expects to do do_bootloader by the kernel too, and we have no zipl support there....
<xnox> apw, is it fair to say that perl postinst scripts in linux kernel, are out of date with respect to changes done in e.g. debian? and it looks like the kernel clobbers and writes out the wrong kind of kernel-img.conf, unlike what base-installer / live-installer should be writting.
<xnox> and e.g. in debian linux maintainer scripts never create kernel-img.conf
<apw> xnox, they are very idffernet to debian yes, based on an older one from there yes
<xnox> apw, i think my machine has a botched installation on it. and e.g. fresh cloud images have 'link_in_boot = Yes' in the /etc/kernel-img.conf and then everything works correctly. 
<phillw> Hi folks, with all the rumours going around, is 16.04 LTS going to be 4.3 or may it be 4.4, or 4.5 ?
#ubuntu-kernel 2016-01-15
<xnox> 4.4 looks very juicy =0
<tsimonq2> phillw: well since i is usually every 3 point releases for Ubuntu, it's probably 4.5
<phillw> tsimonq2: I doubt 4.5 for an LTS... but, I'm happy to be proven wrong. 4.3 was the vote, as to if they sway to 4.4... I'm not too sure.
<tsimonq2> phillw: where was this voted>
<phillw> tsimonq2: read the mailing list. the kernel team do not 'vote', it is a technocracy just as the tech board are.
<mamarley> I asked in here just the other day and was told that 4.4 would be uploaded to Xenial "soon".
<phillw> mamarley: I've no idea who told you that :)
<mamarley> Let me check...
<mamarley> [11.01.16 13:14:44] 	 <apw> 	mamarley, yep, "soon" waiting on some dkms fallout to be resolved as much as anything
<mamarley> After I asked: "[11.01.16 13:13:55] 	 <mamarley> 	Xenial will eventually be getting 4.4, won't it?"
<phillw> mamarley: The Ubuntu Linux kernel team has announced that the Linux kernel in Ubuntu 16.04 LTS has been upgraded to version 4.4, the latest stable release made available.
<phillw> you mean that annoucement :)
<phillw> mamarley: this is pretty breaking news... http://news.softpedia.com/news/ubuntu-16-04-lts-now-based-on-linux-kernel-4-4-lts-498901.shtml
<mamarley> According to Launchpad, 4.4 hasn't been uploaded yet.  Softpedia isn't the most reliable news source...
<phillw> mamarley: for the admins, this is a major head ache... Trust me. But, in the cycle we are just past alpha 1 testing and alpha 2 is not due until near end of month. It will be interesting to see if ubuntu actually take part in the alpha2 to test the kernel out.
<pkern> Hi. Did you hear anything about Haswell Intel machines being slow with current 3.19/4.2 kernels (on trusty, but that might not matter)? The problem is cores stuck to 450 MHz.
<apw> pkern, don't think i have seen a specific result
<apw> s/result/report/g
<cking> pkern, not heard of any direct reports on this for Haswell
<cking> although I am aware of a few users seeing cpus getting stuck at a low freq allegedly because of a microcode update, but we've not figured out if this is a false report as yet
<g0g0boy> hey all, I have a problem with an update scenario
<g0g0boy> need assistance
<g0g0boy> was doing an apt-get update/upgrade and got an error: the following packages have unmet dependencies:
<apw> g0g0boy, which packages
<g0g0boy> recomended I run apt-get -f install
<apw> what series are you running ? do you have -proposed enabled ?
<g0g0boy> one line is: linux-image-extra-4.2.0-23-generic : Depends: linux-image-4.2.0-23-generic but it is not installed
<g0g0boy> second line is: linux-image-generic : Depends: linux-image-4.2.0-23-generic but it is not installed
<TJ-> g0g0boy: did you do "sudo apt-get dist-upgrade" ?
<g0g0boy> I didn the apt-get -f install which tells me that I have no space in /boot :( forget to clean out my old kernels.
<TJ-> g0g0boy: ahhh, first try "sudo apt-get autoremove". If that doesn't free up space then do "dpkg -l 'linux-image*' " and identify older kernel versions you no longer need
<g0g0boy> TJ- same error
<g0g0boy> TJ- same error again regarding depenacies
<apw> yep you are in a hole an no mistake, you need to finish the install before it will do anything else
<g0g0boy> I tried checking and deleting the old kernels to clear sapce but then get the depenacie error error  :(
<g0g0boy> going around in circles it seems
<apw> you might (as TJ- suggests) be able to request removal of an older kernel by hand
<apw> g0g0boy, is /boot separate partition ?
<TJ-> g0g0boy: once you've identified older versions you can remove them with "dpkg --remove linux-{image,headers}-<VERSION>" for each identified version
<apw> g0g0boy, if so you could simply move the old kernel/initrds out of the way on to /, finish the install and then move htem back
<TJ-> g0g0boy: once you've removed at least 1 older version there'll be space to fix with "apt-get -f install"
<g0g0boy> will try usually use command: sudo apt-get purge -y linux-headers-xxxxxxx
<apw> g0g0boy, likely you need to go under its view and use dpkg like TJ- suggests
<apw> as apt knows things are going on
<apw> and wnats to finish them first
<g0g0boy> okay will try dpkg
<g0g0boy> will let you know what happens, thanks for the suggestions
<g0g0boy> so far looks like it is working  :)
<apw> good stuff, TJ- ^
<TJ-> apw: we see that all the time - the default installer-created /boot/ is too small these days
<TJ-> the pain-point is added to because there is no kernel image autoremove function, so GUI users esspecially don't know about autoremove
<apw> TJ-, is there a bug filed to make that bigger, as it sounds like there should be
<apw> TJ-, does it not also run autoremove the gui "install updates" i thought it did, which is why the kernles are now marked to keep just the last 3
<TJ-> hmm, well, unless something has changed very recently. We see this issue very frequently
<TJ-> especially with broken boots after upgrades, due to an incomplete initrd.img
<g0g0boy> TJ-, apw: no luck  :(
<TJ-> g0g0boy: where are you at? have you removed some older kernel images?
<g0g0boy> I was able to remove some items with dpkg --remove which I thought did something cleard out most of the linux-headers 
<apw> headres are not in /boot
<g0g0boy> I stil lhave the following left
<TJ-> g0g0boy: what does "df | grep boot" report?
<apw> you need to remove linux-image-* for older versions
<g0g0boy> ::::::/dev/sda1                     240972     240619         0 100% /boot
<g0g0boy> brb
<g0g0boy> try removing those also
<TJ-> apw: this is the most relevant I can recall right now: bug 1357093
<ubot5> bug 1357093 in unattended-upgrades (Ubuntu) "Kernels not autoremoving, causing out of space error on LVM or Encrypted installation or on any installation, when /boot partition gets full" [Undecided,In progress] https://launchpad.net/bugs/1357093
<g0g0boy> confirmed everything was removed now but still getting errors, come back to you shorlty, Im just reading through some of the output
<g0g0boy> so I removed all linux-headers and linux-image-xxx so when I check for any kernels nothing appears
<g0g0boy> still get error when doing apt-get upgrade or dist-upgrade
<g0g0boy> try doing apt-get -f install and throws out a lot off output
<g0g0boy> it appears to complain that it cannot find the old linux kernels
<TJ-> g0g0boy: I'd recommend you /join #ubuntu since that is the correct support channel for these kind of issues
<g0g0boy> I have the output just dunno where to post it for review
<g0g0boy> LOL :( ok  :)
<g0g0boy> thanks anyways TJ-, apw
<TJ-> g0g0boy: waiting for you there :)
<pkern> cking: Urgh, that's a very good point.
<pkern> cking: We did indeed push new microcode.
<cking> pkern, it would be useful to double check that. if you do find an issue with the microcode we can ping intel about it
<pkern> But we already did confirm that it doesn't happen with 3.13, fwiw. We found it with 3.19 and 4.2.
<apw> pkern, presumably with the same firmware in place
<apw> (and cpu firmware if loaded very early in initramfs)
<pkern> Yeah, we package it up and it's the same.
<apw> i mean it was the same in each of the tests, 3.13 ok others not
<pkern> It was pretty clear that >3.13 used a different scaling method.
<cking> pkern, intel_pstate is now being used, is this specific to just one set of haswells?
<apw> cking, that feels really familiar, some patch to make one specific model use something differnt in intel_pstate
<apw> (perhaps it is tooo specific)
<cking> apw, b27580b05e6f5253228debc60b8ff4a786ff573a ("intel_pstate: Fix BYT frequency reporting") perhaps
<pkern> So I rebooted into 3.19 with the same firmware package installed and it's broken again. Now I can try to rollback the firmware.
<pkern> This is a Xeon E5-1650 v3.
<cking> pkern, sounds like https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1480349
<ubot5> Launchpad bug 1480349 in intel-microcode (Ubuntu) "Intel Microcode Breaks frequency scaling in XeonÂ® E5-2687W v3 & E5-1650 v3" [High,Incomplete]
<pkern> Argh. :) Thank you. I'll try rolling back the microcode update.
<cking> pkern, if it is, please add your findings to the bug and I will prod Intel again on this one
<pkern> I'll try reverting to the trusty version.
<pkern> Yup, microcode.
<pkern> cking: Ok, updated the bug. I theory I could try to bisect which microcode causes it, but still one'd need to raise it with Intel. \:
<cking> pkern, a bisect on the microcode would be useful if you can affort the time to do that
<cking> I'm contacting intel right now about it
<pkern> I guess I could just try 0x2d on this processor and see what happens. Would fit date-wise.
<pkern> (I have access to the errata but not when stuff got publically released, so I'd need to cross-ref multiple places.)
<cking> yep, 0x2d is a good start I think
<pkern> Ok, so 0x2b was actually even what the CPU was shipped with because there's no update in the package with that sig.
<cking> ok, that's a good starting point
<dsmythies> cking, pkern: Often CPU frequencies stuck low with the intel_pstate driver is due to somehow Clock Modulation being involved. You can test, by: 1 - disable the intel_pstate driver, as the acpi-cpufreq driver works fine with clock modulation; 2 - examine the Clock modulation MSR (0x19A) during the issue.
<dsmythies> apw,rtg: Re: A couple of days ago. Should I enter a bug report about the collateral damage due to the "depends on ZONE_DMA" issue? 11 devices are effected, all are sound cards. (reference: linux/sound/pci/Kconfig).
<apw> dsmythies, yes please and paste the number here so we can find it in the deluge
<TJ-> is there any guidance on when 4.4 will land for xenial? Been getting a few questions about testing it recently (I know it's only 5 days since release!) and I see the 4.4 tags in the repo
<manjo> rtg, can you install gcc 4.9 in tangerine amd64 chroot ? 
<manjo> rtg, the latest xenial gcc has bugs due to linaro merge 
<rtg> manjo, USE THE WILY CHROOT
<rtg> oops
<manjo> rtg, arm64 kernels don't boot .. yeah that is a good idea.. I will use wily 
<apw> rtg, :)
<apw> TJ-, we are in the last throws of getting the worst bits sorted, we are hoping "soon" like next week ish depending
<rtg> TJ-, I've got a 4.4 kernel staged in unstable
<manjo> apw, you like the yellin ?
<apw> (ppa not debian unstable)
<apw> manjo, heh he only has one hand
<TJ-> apw: thanks. that's 'sooner' than I expected. I'm running my own builds of v4.4 here, but had a few of the QA testers asking
<manjo> apw, oops tmi ... 
<apw> they can get a preview in the ppa:canonical-kernel-team/ubuntu/unstable but its not supported
<apw> as yet obviously
<apw> manjo, heh no not like that
<manjo> lol 
<pkern> After having added the 0x2d microcode update my machine didn't even boot. Oh well.
<apw> man
<dsmythies> apw, rtg: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1534647
<ubot5> Launchpad bug 1534647 in linux (Ubuntu) "Collateral damage due to kernel configuration change enabling CONFIG_ZONE_DEVICE (Kernel 4.4 amd64)" [Undecided,New]
<apw> rtg, ^
<apw> oh you did that already
<apw> rtg, i might look at that on monday if you haven't already
<rtg> apw, I have not researched it yet, so feel free.
<rtg> apw, I'm going through the bug list to see if there are some that apply to unstable, then I'll upload in a bit.
<apw> sounds good
<rtg> gotta keep xnox happy
<apw> he does get antsy :)
<xnox> rtg, hm?! =)
<xnox> rtg, did you see my comment about CONFIG_KVM btw?
 * xnox checks bug mail and pulls latest kernel git changes
<rtg> xnox, yes
<rtg> only applied to unstable though
<xnox> rtg, that's ok. no rush at the moment =)
<xnox> rtg, thanks.
<rtg> apw, nm, update script is running amok
<rtg> kamal, sforshee: I need to bounce tangerine and reinstall the xenial chroots
<sforshee> rtg: ack
<kamal> rtg, ack
<rtg> rebuilding xenial chroot on tangerine
<sil2100> Hello! I recently merged a new ppp version from Debian and noticed that ppp is blocked in -proposed due to ppp-modules not being built for s390x
<sil2100> Is there a reason for ppp-modules not being available for s390x ?
<rtg> sil2100, checking...
<rtg> sil2100, started bug #1534780 if you'd like to subscribe.
<ubot5> bug 1534780 in linux (Ubuntu Xenial) "Xenial: review s390x module exclusions" [Undecided,In progress] https://launchpad.net/bugs/1534780
<TJ-> rtg: apw had a user testing 4.4.0-0.11 from unstable; getting PCI "unable to assign BAR" errors and resulting inoperable device. (4.3.0-5.16 was fine). Testing with "pci=realloc"
<sil2100> rtg: thanks! :)
<rtg> TJ- have them test vanilla mainline in order to make sure its not an Ubuntu patch causing the problem. http://kernel.ubuntu.com/~kernel-ppa/mainline/
<TJ-> rtg: will do; there's been a long-standing (17 month) regression in the PCI bridge allocation code
<rtg> TJ- have you narrowed it down to a committ ?
<TJ-> I've been having to use mainline kernels with patches and I'm still waiting for YingHai Lu to get them into mainline. there's a mainline bug covering part of it at https://bugzilla.kernel.org/show_bug.cgi?id=81431
<ubot5> bugzilla.kernel.org bug 81431 in PCI "pci=realloc fails to modify bridge windows, causing devices to fail BAR allocation" [High,New]
<TJ-> rtg: right now the trouble is YingHai has a stack of patches because the rework is so invasive, and I don't think is focused on this stuff.
<rtg> great :(
<TJ-> For v4.1 my issue only needed 2 patches from the stack, but now I need the entire stack
<apw> barf
<TJ-> I'm currently pulling in git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git and the pci-for-v4.5-next
<TJ-> I have to rework those patches to apply on 4.4 right now, though
<TJ-> The user is 'phillw' and he's just posted the most recent kern.log (includes 4.4 and 4.3.x boots) here: http://phillw.net/kern.log
<phillw> o/
<TJ-> The line is "Jan 15 19:27:47 piglet kernel: [    0.687558] pci 0000:03:00.0: can't claim BAR 6 [mem 0xffff0000-0xffffffff pref]: no compatible bridge window"
<TJ-> this is with "pci=realloc" too
<TJ-> phillw: rtg suggests you test the upstream, mainline v4.4.0 build from http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4-wily/
<TJ-> phillw: did you notice, that last 4.4 boot doesn't have "assign-busses" ? I think you forgot to do "sudo update-grub" after changing /etc/default/grub 
<TJ-> I need to head off to dinner now
<phillw> TJ-: I'll do that now and reboot... I also want some food... it is 19:40 here and food time is about 17:00 :D
<phillw> As asked, I have issued sudo update-grub and WiFi still fails, logs are at http://phillw.net/kern.log
<TJ-> phillw: one last config option to try adding, "nocrs"... as in "pci=realloc,assign-busses,nocrs" then "update-grub" then reboot test
<phillw> TJ-: okies, can you hang on for a while, it is past 8pm here and I'm now cooking my meal I should have had at 6pm :)
<TJ-> same here, and yes
 * tsimonq2 runs a generic kernel fresh out of Linus' git repo
 * phillw runs what ubuntu will be using... TJ- food cooked, rebooting with your extra command.
<phillw> TJ-: file modified, still no WiFi, logs at http://phillw.net/kern.log
<TJ-> phillw: that last 4.4 boot configured the wifi device correctly!
<TJ-> as in, the 1 before this
<TJ-> phillw: can you show me "dpkg -l 'linux-image*' | pastebinit"
<phillw> TJ-: no, it did not. I have to reboot to 4.3 to have wifi
<TJ-> Yes, it did. But, no driver module claimed it
<phillw> okies.. just installing pastebinit
<phillw> TJ-: http://paste.ubuntu.com/14510427/
<TJ-> phillw: As I thought; your install didn't include "linux-image-extra-4.4.0-0-generic" which contains the ath9k and other drivers
<phillw> TJ-: so an apt get should resolve it?
<phillw> TJ-: we are about to find out :)
<phillw> TJ-: Linux piglet 4.4.0-0-generic #11-Ubuntu SMP Mon Jan 11 16:58:35 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
<TJ-> phillw: so, that was why the wifi never came up even after the BAR assignment was fixed
<phillw> so, it is add the ppa and then apt-get linux-image-extra-4.4.0-0-generic, which I assume will let apt know to grab the actual kernel as well :)
<TJ-> phillw: if you check the dependency "apt-cache depends linux-image-extra-4.4.0-0-generic" that should pull in the -image- and the -headers-
<phillw> phillw@piglet:~$ apt-cache depends linux-image-extra-4.4.0-0-generic
<phillw> linux-image-extra-4.4.0-0-generic
<phillw>   Depends: linux-image-4.4.0-0-generic
<phillw>  |Depends: crda
<phillw>     crda:i386
<phillw>   Depends: wireless-crda
<phillw> phillw@piglet:~$ 
<phillw> yup :)
<phillw> So, add the ppa and then issue the image-extra apt to get the system?
<TJ-> so asking for -extra- does the job. Usually, we have the meta-packages to pull in these dependencies
<phillw> early days, but the announcement is out and we do get asked!
<phillw> TJ-:  Thanks ever so much for your patience on this. Bits I do recall from cycles ago, others are new to me. I'm happy to answer questions from any of our testers now.
<TJ-> it would be a good test to remove (but save where you can reuse it) the pci=... additions, update-grub, and see if it works without those. I think you may need the pci=realloc but not the others, but you may get away without it, if the missing module was the core problem
<phillw> TJ-: back to "" and it has booted fine :)
<phillw> these kernel modules wil be the death of us all :)
<TJ-> LOL what a fuss!
<TJ-> well, at least *you* aren't affected by the PCI bridge window issues then
<phillw> indeed, just needed to ask for 'extra' and apt would have sorted it all out :D
<TJ-> I must have missed in the logs where the initial BAR assignment failure was solved later on
<phillw> I'll have a minion... oops, I mean volunteer, verify that adding the ppa and then the extra system results in a bootable system. tsimonq2 most likely has got 4.4 already, so I will need a volunteer without it installed on bare metal.
<phillw> and you, as with all on here, are welcome to pop onto #phillw. We are an affable bunch and have testers willing to help out across various areas.
<tsimonq2> phillw: no I compile directly from Linus' git repo
#ubuntu-kernel 2016-01-16
<apw> phillw, there should be meta packages in that ppa
<tsimonq2> I am now using the PPA, so if you need anything from me, like testing of something, just ping :)
<tsimonq2> and this is on i386
<phillw> apw: it's okay. My reason for wanting to try it out a.s.a.p. was that there sems a bit of doubt as to if the new kernel would land by Mon 25th Jan, this being the next alpha milestone when we can go and corral testers to crawl over testing and I also wanted to have it running in 'real' life (production machine).
<phillw> s/sems/seems/
#ubuntu-kernel 2016-01-17
<asdfgttt> hi..need some help
<asdfgttt> anyone wishes to assist a nub?
<tsimonq2> asdfgttt: state what you need and we can help from there
<asdfgttt> i915 driver seems to totally a random crash the entire system to the point , i need to power off
<asdfgttt> want to know how to trace the mamory of the system and send u a nice bug report with hex data
<asdfgttt> *at random
<asdfgttt> sooo? anyone?
<asdfgttt> im pretty sure its the intel driver, cos most of the times it screws the screen just before hanging..and a few times..it just screws the screen..alt+tab and it works again
<tsimonq2> asdfgttt: dmesg might help
<asdfgttt> could also be the oci-x driver...possibly
<asdfgttt> i cant dmesg cos after it crashes i MUST restart
<asdfgttt> anyways ssen the log its not impressive
<tsimonq2> I'm not the expert :D
 * tsimonq2 remains silent
<asdfgttt> and the bug ocures totally at random..sometimes the PC is on for hours watching video and so on..no problem..but sometimes it just hangs in 5 minutes
<asdfgttt> i apreciate ur sarcasm
<asdfgttt> ok..i dmeg'd..there is something there
<asdfgttt> 18.729123] ACPI Warning: SystemIO range 0x0000000000000428-0x000000000000042F conflicts with OpRegion 0x0000000000000429-0x0000000000000429 (\PM2S) (20150818/utaddress-254)
<asdfgttt> [   18.729133] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
<asdfgttt> [   18.729138] ACPI Warning: SystemIO range 0x00000000000004B0-0x00000000000004BF conflicts with OpRegion 0x00000000000004B8-0x00000000000004BB (\GPO2) (20150818/utaddress-254)
<asdfgttt> [   18.729143] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
<asdfgttt> [   18.729145] ACPI Warning: SystemIO range 0x0000000000000480-0x00000000000004AF conflicts with OpRegion 0x000000000000048C-0x000000000000048F (\GPO_) (20150818/utaddress-254)
<mjg59> asThat's harmless
<mjg59> Oops.
<asdfgttt> got kicked cos of flooding
<mjg59> asdfgttt: That's harmless
<mjg59> It's just telling you that the system firmware has reserved some space that a driver wanted to use, so the driver won't work
<asdfgttt> u mean the kick or the dmseges?
<tsimonq2> both :)
<asdfgttt> 1.359894] [drm] Replacing VGA console driver
<asdfgttt> [    1.360751] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
<asdfgttt> [    1.360755] [drm] Driver supports precise vblank timestamp query.
<asdfgttt> [    1.361246] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
<asdfgttt> [    1.361692] [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 23: Can't calculate constants, dotclock = 0!
<asdfgttt> [    1.371724] FDC 0 is a post-1991 82077
<asdfgttt> [    1.384702] [drm] initialized overlay support
<asdfgttt> [    1.407132] r8169 0000:02:00.0 enp2s0: renamed from eth0
<asdfgttt> [    1.466170] [drm] Initialized i915 1.6.0 20150731 for 0000:00:02.0 on minor 0
<asdfgttt> here is an error
<tsimonq2> asdfgttt: use pastebin.ubuntu.com
<tsimonq2> asdfgttt: or do dmesg | pastebinit
<asdfgttt> http://paste.ubuntu.com/14541012/
<asdfgttt> btw. i had the problem with 15.10 also..exactly the same
<asdfgttt> no problem under windows though... except getting a version of 2000 to boot on SATA but thats another story
<asdfgttt> monk..u see something?
<SuperSStarT> phillw its me!!!!
<SuperSStarT> reinv pls
<SuperSStarT> i mean the asdfgtt etc.
<phillw> he he..
<phillw> http://freenode.net/faq.shtml#nicksetup
<phillw> SuperSStarT:  ^^ 
<SuperSStarT> lickmyass and my shiny metal ass were taken
<phillw> que?
<SuperSStarT> passa...
<SuperSStarT> now i have a registered nick
<phillw> good.
<SuperSStarT> am i getting reinvited?
<phillw> you can just /j #phillw
<SuperSStarT> https://answers.launchpad.net/ubuntu/+question/281082
<phillw> SuperSStarT: you have a nice set of things.. .But you need to use ubuntu-bug.
<SuperSStarT> stupid question... kdump is installed and working
<SuperSStarT> will it triger the second kernel ..cos when the bug im investigating occures..the PC just freezes compl. i.e. dies
<SuperSStarT> someone there?
<SuperSStarT> help with filing a bug report?
<SuperSStarT> i alwazs get redirected to here > https://help.ubuntu.com/community/ReportingBugs
<SuperSStarT> help with filing a bug report? 
<SuperSStarT> i alwazs get redirected to here > https://help.ubuntu.com/community/ReportingBugs
<alkisg> Hi, with 4.3.0-5 I'm getting sata errors in dmesg and my ext4 root filesystem gets corrupted + remounted ro.
<alkisg> With 4.3.0-2 and with all other distros/versions that I have installed, it works fine
<alkisg> That's on an i5-4440 system. I'll continue booting with 4.3.0-2, but I was mentioning it in case it's a known problem and you were searching for a system where it can be easily reproduced
<alkisg> Part of kern.log, that shows the sata errors: http://paste.ubuntu.com/14543264/
<alkisg> It's 100% reproducible with 4.3.0-5, 0% reproducible with 4.3.0-2
<alkisg> (that's 16.04, btw...)
<apw> alkisg, there is a 4.4 kernle in ppa:canonical-kernel-team/ubuntu/unstable which will replace 4.3 shortly, it would be good to know if that has the issue or not
<alkisg> Thank you apw, installing...
<alkisg> it asked to remove checkbox-ng-service, proceeding...
<apw> thats an odd thing to ask to remove
<alkisg> (updating from the ppa)
<alkisg> I probably did the wrong thing just running apt-get dist-upgrade there, but it's ok
<alkisg> I usually reinstall when the final is out
<apw> well that might not be even related to the ppa, maybe
<alkisg> I did a dist-upgrade right before adding the ppa
<apw> anyhow, checkbox being missing is not going to ruin your day, you'll likley not notice
<alkisg> and another one after
<alkisg> sure
<apw> it isn't likley there was a publish between on the main archive i confess
 * alkisg crosses fingers and reboots
<alkisg> apw: it looks ok, thank you!
<apw> alkisg, that is good news, that kernel or a newer version of it should be promoted to the archive sometime this week if all things go to plan
<alkisg> If I see it again till release, I'll try to do a bisection
<apw> alkisg, that sounds good
<alkisg> Lunch time, cheers, thanks again :)
<phillw> apw: if the 4.4 lands into the xenial test builds before 25th Jan, that would be awesome :)
<SuperSStarT> phillw
<SuperSStarT> nope and I was getting PM's from mods saying to kick you.... and in public I was trying to diffuse things. But you'd add more fuel the fire and raise the temperature. Personally, I have no issues with you. Our channel etiquette is rather unique, but new comers tend to listen and watch for what is allowed instead of breaking through the barriers of 
<SuperSStarT> what is not. You can still contact me via #linuxpadawan and we can re-visit the 'shut up and listen' pa 
<SuperSStarT> SuperSStarT
<SuperSStarT> honestly... u descriminate between newcomers and what not in a place thats suposed to be about freedom mostly freedom of expression to keep some hierarchy 
<SuperSStarT> duuuuuuumb 
<SuperSStarT> saaaaaad 
<SuperSStarT> piiiiiiity 
<SuperSStarT> tell them or kiss them...its what it is 
<SuperSStarT> phillw
<SuperSStarT> yes with no hierarchy there is only chaos... My channel is a technocracy.... go look it up and understand exactly what it means. 
<SuperSStarT> SuperSStarT
<SuperSStarT> right now if i could id love to kick ur ass from greenwich to greenwich the world round. and i mean good. 
<SuperSStarT> they got jelous and u let them...with pleasure...saw it 
 * phillw ahh, where was I?... my apologies for the outburst above, said user was ejected from #phillw and decided to go on a one man (child?) mini-rant on other channels. This being one of them.
#ubuntu-kernel 2017-01-09
<dbazim> to: ivan Yes, USB3.0 from NEC worked well on ubuntu 14.04 all kernels until I upgraded to 16.04. It looks like uas problem. [sda] tag#11 uas_eh_abort_handler 0 uas_tag 12 inflight: CMD OUT. 
<dbazim> No problem if connect USB 3.0 disk box to usb 2 but speed is less.
#ubuntu-kernel 2017-01-10
<fossfreedom__> Hi all - project lead of Ubuntu Budgie here - battling with a ubiquity issue - but I noticed in the syslog trace what looks like a zesty kernel crash - can someone have a quick look and advise please? https://launchpadlibrarian.net/301822678/UbiquitySyslog.txt (scroll down a couple of pages) - for bug report https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1655119
<ubot5> Ubuntu bug 1655119 in ubiquity (Ubuntu) "ubuntu budgie zesty ubiquity crash when installing locales" [Undecided,New]
<smb> fossfreedom__, That is just a warning (as it says). Appears to point out a bios/setup problem for declaring the same xsave features for each core. Seems to go on ok and the set that gets used sounds sane. Don't think that is causing the problems you have.
<smb> Rather the many "permission denied" ones later when trying to access the filesystem
<fossfreedom__> smb: thanks for the clarification.  I'm rather clutching at straws as you can gather.  I don't understand why there are permissions issues.  cheers for the reply.
<smb> fossfreedom__, yw. a lot of the log looks a bit like stuff was not run as root...
#ubuntu-kernel 2017-01-11
<javier4> trying to build my kernel with apparmor patches, I get these errors
<javier4> https://www.irccloud.com/pastebin/uWrkMTiI/
<flocculant> jsalisbury: just grabbed new zest kernel from proposed - usb3 remount issue gone there now as well - many thanks :)
<jsalisbury> flocculant, great
#ubuntu-kernel 2017-01-13
<cjwatson> apw: do you by any chance have a real ZFS pool up somewhere (not the weird file-backed thing that I have)?  I'm looking into a bug
<apw> cjwatson, i don't but i bet cking does ^^
<cjwatson> cking: can you see whether   bash -c 'ulimit -f 1024; yes | head -n2097152' >/some/path/on/zfs   returns successfully or takes SIGXFSZ?
<cking> i have, let me fire up a server
<cjwatson> (it should take SIGXFSZ)
<cjwatson> found in the Launchpad test suite
<cjwatson> apparently this test case works correctly on Solaris 5.10 and FreeBSD 10.0-CURRENT
<cking> cjwatson, yep, looks like it fails on ZFS on Linux 
<cjwatson> shiny
<cjwatson> will file a bug
<cking> thanks, and once that's done I'll report that upstream
<cking> nice catch!
<cjwatson> the LP test suite kind of wants the whole planet to be in a correct state
<cking> cjwatson, fair enough, file systems should handle SIGXFSZ for sure
<cjwatson> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1656259
<ubot5> Ubuntu bug 1656259 in linux (Ubuntu) "Linux ZFS port doesn't respect RLIMIT_FSIZE" [Undecided,New]
<cking> cjwatson, thanks
<achiang> howdy, if I install linux-generic-hwe-16.04, does that also get me newer display drivers too somehow?
<achiang> trying to opt-in to the rolling LTS enablement stack
<rtg> achiang, if you are using an nVidia DKMS driver, then it likely won't change, though it has probably been tested with the HWE kernel.
<achiang> hm, no, not nvidia. just a dell xps13 with intel gfx (broadwell)
<rtg> achiang, then you'll get an updated i915 graphics driver from the new kernel.
<achiang> oh perfect, thx
#ubuntu-kernel 2017-01-15
<edmont> hi
<edmont> I'm trying to solve some audio/video problems with my Intel Skylake platform
<edmont> I tried many linux flavors and got the best results with latest LibreELEC alpha
<edmont> but I want a real OS, that's why I want to make it work with Ubuntu
<edmont> currently I have installed Ubuntu Gnome 16.10, and upgraded to Zesty
<edmont> how to see which Intel drivers are included in my kernel?
<edmont> and how to compare with the LibreELEC ones?
<apw> edmont, intel drivers are in sync with upstream in zesty, sofrom 4.9
<edmont> apw: what's the difference with libreelec then?
<JanC> I also have issues with Intel Skylake graphics, so this doesn't really surprise me...
<JanC> but then again, I haven't seen Intel graphics without issues in the last 3-4 years or so...
<JanC> sometimes I doubt they do any serious testing at Intel...
#ubuntu-kernel 2018-01-08
<f_g> bjf: thanks. like I said, we've already completed our in-house testing based on those and have begun rollout to users yesterday - no negative feedback so far, let's see what today brings ;)
<alkisg> If I want to buy a new intel cpu, can I buy something that won't have the meltdown/spectre performance impact?
<apw> not that i know of
<alkisg> Thank you apw
<f_g> I think one of the backports for 4.4 left an erroenous kfree in arch/x86/events/intel/ds.c
<f_g> f8365429a3dc1377e99d821be17cdeb76dd4b815
<f_g> vs 20cbe9a3aa2e341824da57ce0ac6d52cbffaa570
<f_g> the latter removes kfree(ds); from release_ds_buffer
<f_g> the commits are otherwise identical (modulo location of modified file and commit message/hashes)
<f_g> apw, bjf: ^^
<apw> f_g, odd
<f_g> probably just an oversight since the diff was manually applied / fixed up? not sure..
<apw> f_g, most likely, but still an odd differnce
<f_g> apw: users reported the following on some HP DL G7 boxes: https://imgur.com/a/vVbR0 , I'll see whether the kernel without the kfree gets rid of that
<apw> f_g, which tree is 20cbe9a3aa2e341824da57ce0ac6d52cbffaa570 in ?
<f_g> v4.4.110
<f_g> (~33 to be exact)
<apw> ahh ok
<tseliot> apw: hey, any reason why the updates seem to require libelf-dev to be installed? bbswitch said that when DKMS failed. Nvidia didn't build either, but I missed the log
<apw> tseliot, i do not, sounds odd anything would be different
<tseliot> apw: let me try removing that package, to see if I can reproduce the problem with nvidia
<tseliot> apw: yes, I can reproduce it: Makefile:969: *** "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel". Stop.
<apw> is that for out of tree bits using the kernel ?
<tseliot> apw: nvidia and bbswitch
<f_g> ZFS as well
<f_g> (when building out-of-tree)
<tseliot> apw: that's with 4.13.0-24.28
<f_g> (we reverted to FRAME_POINTER downstream)
<apw> tseliot, sounds like we should add that as a dependency of the headers
<tseliot> apw: I think so. I've tested this in artful
<tseliot> let me send an email, I'm not sure you are subscribed. Leann is
<ernstp> I noticed that the cves fixed in 4.13.0-22.25 are not fixed in 4.13.0-24.28 right now
<bjf> ernstp, that is correct. the meltdown patches have been applied to the code that was in the previous -update
<bjf> ernstp, the CVEs that were sitting in -proposed will be reapplied and released at a future date
<dsd> apw: hi again, anything i can help with to help the KPTI work move forward?
<dsd> (artful)
<leitao> when I try to build trusty kernel on ppc64el I got /home/ubuntu/kernel/linux-private/arch/powerpc/kernel/exceptions-64s.S:721: Error: unrecognized opcode: `hwsync'
<leitao> should I upgrade gcc in order to build the kernel?
<leitao> I am using standard gcc-4.8
<cjwatson> this isn't my field but wouldn't that be binutils rather than gcc?
<cjwatson> added in 2.25.1 I *think(*
<leitao> cjwatson, was binutils 2.25 made available on trusty?
<cjwatson> I don't know if the relevant feature was backported
<cjwatson> not my field, like I say
<leitao> cjwatson, no worries. I am wondering how it is being compiled.
<leitao> klebers, do you know?
#ubuntu-kernel 2018-01-09
<ricotz> sforshee, hi, could you push your master-next kernel branch for bionic?
<alkisg> Hi, I reported an nbd regression in https://github.com/NetworkBlockDevice/nbd/issues/57#issuecomment-333409103
<alkisg> and it was solved by the kernel maintainer in October, in https://www.spinics.net/lists/stable/msg192513.html
<alkisg> He said "and cc'ed stable so it'll make its way back to distro kernels"
<alkisg> I'd like to have that included in Ubuntu 18.04. Do I need to do something, or will it find its way?
<alkisg> (the 18.04 current kernel does have the issue)
<alkisg> Ah, here's the direct upstream commit link: https://github.com/torvalds/linux/commit/639812a1ed9bf49ae2c026086fbf975339cd1eef#diff-bc9273bcb259fef182ae607a1d06a142
<tjaalton> is it in 4.15?
<tjaalton> that would be yes
<alkisg> tjaalton: how would I test, by installing 4.15 from the mainline ppa?
<tjaalton> yes
<alkisg> ty, trying...
<alkisg> tjaalton: yes, the fix has been applied in 4.15...rc7
<alkisg> Is that what 18.04 will get? So I don't need to do anything?
<tjaalton> 4.15, yes
<alkisg> Thank you :)
<rzo1> any update when to expect kernel patches going public (timezone CET) ?
<TJ-> still regression testing, could be later today 
<TJ-> rzo1: .25 is in -proposed currently
<rzo1> thx 4 update
<f_g> TJ-: 108.131 is still missing the correction for f8365429a3dc1377e99d821be17cdeb76dd4b815 (see backlog) - is this intentional or did it fall through the cracks?
<sforshee> ricotz: pushed, sorry forgot to push it yesterday
<ricotz> sforshee, thanks
<ricotz> sforshee, I would recommend to cancel those pending builds https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/unstable/+packages
<ricotz> maybe same for https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/bootstrap/+packages since there are superseded too
<sforshee> ricotz: good point, I will do that
<retabell> Ubuntu-4.4.0-108.131 build fails with gcc version 4.7.2 Debian 4.7.2-5,  gcc 4.9.2 is build ok
<retabell> http://paste.debian.net/hidden/6dd6f136/
#ubuntu-kernel 2018-01-10
<vieira> is there a fix for meltdown comming out today for linux-hwe-16.04?
<TJ-> vieira: no patches for v4.10, you need hwe-16.04-edge (4.13)
<vieira> Ok, I just installed linux-virtual-hwe-16.04-edge and rebooted
<TJ-> vieira: 4.10 kernel from 17.04 reaches end of life on Jan 13th, so wasn't worth the effort to backport patches
<vieira> but have 4.13.0-21-generic
<vieira> I think it should be 4.13.0-25.29?
<TJ-> vieira: waiting for it to appear in the -security archive
<vieira> ahh ok! Thanks :)
<keithzg> Over in #ubuntu-server it was mentioned that I should mention this here: unable to boot past the RAM image loading on 4.4.0-108.131, meanwhile 4.4.0-104.127 continues to work fine. CPU is an Intel i5-4670K, motherboard is an ASUS Z87-A.
<TJ-> thanks keithzg 
<TJ-> possibly related Ask Ubuntu, with stack-trace photo: https://askubuntu.com/questions/994067/kernel-panic-after-spectre-meltdown-update-16-04
<bjf> keithzg, are you still around?
<keithzg> bjf: Yup
<Odd_Bloke> bjf: He's been active in... there he is.
<bjf> keithzg, ok, may have a new kernel for you to try "soon"
<TJ-> bjf: we're hoping keithzg can capture some log messages in the meantime ... got your camera handy, keithzg ?
<keithzg> Yup, camera's ready although it's not much to see currently!
<TJ-> hehehe, common problem
<keithzg> What little I have so far is now at https://photos.app.goo.gl/nqKrJHknd11NuCeO2
<TJ-> one last test, try adding "nopti" on that kernel's command line
<keithzg> TJ-: I haven't tried adding "debug" yet, should I try both, or just "debug" first, or?
<TJ-> keithzg: both, why not!
<TJ-> keithzg: it looks like 'debug' on it's own won't capture anything; looks like the kernel's initial setup is failing
<keithzg> TJ-: hehe, shall do
<bjf> keithzg, sorry, i won't have a new kernel for you to try. please file a bug and them come back here and tell me what the bug id is
<keithzg> TJ-: No dice, I just get the loading lines and nothing more.
<keithzg> bjf: Fair enough, shall do
<TJ-> keithzg: that's with 'nopti' ?
<keithzg> TJ-: Yeah.
<TJ-> keithzg: hmmmph, that IS strange
<keithzg> Well, that *and* debug
<keithzg> It's conceivable I don't know what I'm doing with editing GRUB entries on the fly
<TJ-> keithzg: which suggests some of the other x86/mm sub-system patches not directly related to the pti patch-set may be implicated
<TJ-> keithzg: you're editing the kernel command line via GRUB? pressing E on a highlighted entry, navigate to the line starting "linux ...", add the options towards the end of the line, e.g. " debug nopti" then IMPORTANTLY press Ctrl+X too boot with that change - don't return to the menu to start the entry else changes will be lost
<keithzg> TJ-: For whatever reason Ctrl-x just writes x to the editor, so I went with F10 as the alternate option, yeah. But now I'm wondering if there were quotation marks around the whole thing and I didn't notice and put my options outside of them? The much smaller window you get when running GRUB in a non-graphical mode makes things harder to visually parse, heh. I'm just going to try adding nopti to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub, regenerate 
<keithzg> grub, and then try another reboot.
<TJ-> keithzg: no quotation marks required when editing the GRUB lines
<keithzg> TJ-: Yeah I was just wondering in retrospect. And yeah, I verified that it's definitely trying to boot with that option, and definitely still hanging there. Bug report time!
<bjf> keithzg, ok, i will shortly have something for you to try... i'm waiting for LP to complete copying something
<bjf> keithzg, https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/pti
<bjf> keithzg, in that ppa there will be "real soon now" a newer 4.4 kernel
<bjf> keithzg, it's telling me the kernel is there now
 * bjf is stepping away for a bit
<keithzg> Well it's a banner day for errors for me, I just tried opening a bug on Launchpad and got Timeout Error ((Error ID: OOPS-809eb4fff20040fcf023ecf9bda0f5d3))
<keithzg> bjf: Only newer package I'm seeing is linux-libc-dev?
<TJ-> keithzg: maybe the LP server just got it's PTI patches :p
<keithzg> TJ-: hah!
<bjf> keithzg, 4.4.0-109.132 .. you probably need to pull down the .debs and dpkg -i them
<TJ-> see https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/pti/+sourcepub/8710767/+listing-archive-extra 4.4.0-109-132 
<TJ-> apt-cache policy shows it Candidate: 4.4.0-109.132
<keithzg> Hmm, apt-cache policy is still just showing me "4.4.0.108.113" as the latest for linux-image-generic. Manual .deb time then I guess!
<TJ-> keithzg: did you "apt update" ?
<TJ-> keithzg: presumably you added the ppa via apt-add-repository ?
<keithzg> TJ-: Yes and yes
<TJ-> keithzg: strange; I did the update and it shows 
<TJ-> keithzg: try "apt-cache policy linux-image-4.4.0-109-lowlatency"
<keithzg> TJ-: Yeah, I see it there then, as I do too with `apt-cache policy linux-image-4.4.0-109-generic`. I guess it makes sense to just apt install *that*.
<keithzg> Although I might need linux-signed-* correspondingly?
<TJ-> keithzg: if using Secure Boot, yes.
<keithzg> TJ-: I remain unsure, heh, been too long since I set up this server and I don't remember if I disabled that or not. Running `apt install linux-signed-image-4.4.0-109-generic linux-image-extra-4.4.0-109-generic linux-headers-4.4.0-109-generic` to be sure.
<keithzg> Installed, lets give this a shot.
<keithzg> Booted with 4.4.0-109-generic! That's with "nopti" still on the kernel command line, I'm going to try removing that and seeing if it's still fine.
<keithzg> Excellent, that seems to have done the trick. Many thanks, bjf and TJ- :)
<TJ-> keithzg: so do we know what was wrong? 
<keithzg> TJ-: I certainly have no idea, all I know is that the newer kernel packages from the PPA have resulted in everything appearing to be fine now on my system.
<TJ-> keithzg: Of course, I'd forgotten you've just updated to the very new build! I'm getting confused with the regression I'm investigating here
<keithzg> TJ-: It's a busy time :)
<bjf> \o/
<bjf> keithzg, thanks!
<keithzg> bjf: :)
<keithzg> Worth mentioning, I ran into this again on another server, also using an ASUS motherboard (different, however: P8Z77-V LX in this case) and an older Intel CPU (i5-3550).
<keithzg> Going to check in a bit if the newer PPA packages fix this one too (it does also reboot fine with the -104 kernel, so odds seem good). First I'm going to pick up a pizza, though, since this may be a long night ;)
<bjf> keithzg, we are rushing out the kernel you tested for us
<keithzg> bjf: Good to hear :) Hopefully there aren't any more issues lurking!
<f_g> TJ-, bjf: that keithzg issue was one I pointed out twice in here already (including the fix), apw said he'll look at it on Monday already :-/ seems like I should have filed an LP bug earlier? I was under the impression that nobody would look at those atm while being busy backporting the huge patch sets.. going forward, I assume LP is the way to go again to report improvements/regressions?
<apw> f_g: is that the _ds panic?
<f_g> yep
<f_g> (I know it's already fixed in the latest 4.4)
<apw> if so reporting that here was the right thing, iirc you were going to test if that fix was the fix, and we had people scrambling to test too but positive reports didn't make it in time to hit the first updates
<apw> reporting it here was worthwhile
<f_g> okay. you're right, I did not explicitly state that it actually fixed the issue, I just pinged a second time about it not yet being applied in the pti branch. I think I just assumed that it would get in in any case since it was an obviously incomplete backport - could have stated it more clearly.
<f_g> going ahead, should I file bugs at LP in general, or just for already released kernels? are there any plans for Spectre / IBRS / RETPOLINE / .. already (or ways to contribute to that?)
<f_g> (FWIW, we haven't received any other negative feedback, so things are looking good atm)
<apw> just bad luck on timing, we were juggling all the series at once
<apw> it will be in the next update, and that will soon, we are in free release mode
<apw> Spectre is in progress for sure
<apw> f_g, oh indeed it looks like there is a build in proposed with that fix right no
<apw> w
<apw> f_g, and i hear it was already approved for -updates, so it should be there 'soon'
<f_g> yes :) we only had to juggle two kernel releases here, and still missed some stuff in the first iteration. that's just how it is ;) gotta catch up on LKML now - if there is anything that can be done from over here regarding Spectre backporting/testing/.. just ping
<apw> ack
 * ogra didnt notice this channel became +r
<ogra> it seems the just released kernel doesnt boot on my desktop ... 
<ogra> i'm greeted with an oops right after grub loads it
<f_g> ogra: which kernel / distro?
<ogra> heh, ubuntu 16.04
<ogra> 4.4.0-108
<f_g> 4.4.0-109 likely fixes it, if the oops looks like https://imgur.com/a/vVbR0
<ogra> i had to go back to 4.4.0-104-generic
<f_g> see LP#1741934
<ogra> ah, i'm just behind one version then
 * ogra upgrades
<ogra> thx!
<acheronuk> apw et al. thanks for the hard work
 * alkisg also had an issue with 4.4.0-108 today... 4.4.0-104 booted, but -108 displayed a black screen without even loading the initramfs
<alkisg> I solved it by installing the -hwe stack, maybe I should have filed a bug report instead...
<apw> alkisg, if you get a chance try -109
<alkisg> apw: thanks, if they call me again from that school I will do so
<thresh> any known issues with 4.13.0.26.46 linux-image-generic-hwe-16.04 and kernel panics?
<apw> thresh: best to just tell us the symptoms you are seeing
<thresh> apw, as it's a hetzner server, I have limited visibility (and it seems IP KVM has issues, too).  I'm trying to boot it into rescue now to maybe have more info.
<thresh> here's what I got from the support: "But it seems as the server shows no video output anymore (or responds to key strokes) once the boot process is nearly finished and the login promt should show up"
<thresh> it's an AMD Ryzen system, too.
<thresh> I'm sorry I don't have a lot of info atm, still waiting for it to boot into rescue system.
<thresh> And it turns out I dont have a netconsole set up on that server :|
<thresh> the kernel version I've got installed is 4.13.0-26.29~16.04.2
<thresh> I was able to boot into the rescue system, and there are no logs, sadly.
<thresh> changed grub default back to the 4.8.0-56 and system booted up just fine.  I understand that that does not help.
<thresh> ok, tried booting back to 4.13.0-26.29~16.04.2, after some kernel initialization it freezes, and goes to "no signal" on KVM again.  Sadly, it seems to early for netconsole to kick in.
<thresh> and no panic stack trace on the screen either.
<metaphysician> On 16.04, xtables-addons dkms fails to build with the new 4.13 kernel.
<thresh> I do have another AMD system locally, although it's AMD Turion(tm) II, not Ryzen.  I'm going to test the upgrades tomorrow.
<thresh> (with physical access, too)
<sbeattie> thresh: given the 'had to go back to a 4.8 kernel', I'm guessing you hadn't run any of the 4.10 linux-hwe kernels? Do any of the 4.10 linux-hwe kernels work for you? Also you could manually install the linux-hwe-edge 4.13.0-21.24~16.04.1 to try to narrow it down to just being the meltdown/kpti patchset that's breaking things for your hardware.
<thresh> sbeattie, yeah, I've been using 4.8.0 since, well, it ran fine for me for quite some time.
<thresh> I'm going to try those kernels now.
<thresh> sbeattie, linux-image-4.13.0-21-generic=4.13.0-21.24~16.04.1 booted up fine (except did not bring up the network interfaces).
<ctennis> sorry for the question if it's already been addressed, but the MeltdownAndSpectre wiki page says the linux-aws kernel version for Xenial is 4.4.0-1047.56 whereas the linked 3522-1 says it is 4.4.0.1047.49.  Any clarity on which is correct?
<ctennis> USN-3522-1 that is
<sbeattie> thresh: likely need linux-image-extra-4.13.0-21-generic=4.13.0-21.24~16.04.1 too
<thresh> yeah, r8169
<thresh> but, I guess, that kinda sorta means that kpti patches are the problem
<sbeattie> ctennis: 4.4.0.1047.49 is the linux-meta version, which update-manager uses to know to pull in the specific linux-image 4.4.0-1047.56 package.
<ctennis> that's seemingly really confusing
<sbeattie> (more correctly, linux-meta-aws version, and linux-image-4.4.0-1047-aws)
<sbeattie> confusing> a bit yes, but it's what allows you to have multiple kernel images installed so that you can rollback if a specific version fails to work for you.
<ctennis> right, it's just the different #s between the two pages
<ctennis> I had 1047.49 installed, but it did NOT have 4.4.0-1048.57 with it
<ctennis> 4.4.0.1047.49 I mean
<ctennis> but just 30 minutes ago it became available, so now i have 4.4.0.1048.50 and the corresponding 4.4.0-1048.57
<ctennis> anyway, looks like its sorted now, and I was just in a small window of time between updates
<sbeattie> ctennis: uhhhh, it should not be possible to have linux-image-aws 4.4.0.1047.49 installed without also having linux-image-4.4.0-1047-aws (4.4.0-1048.57) installed, as the former has a direct dependency on the latter.
<sbeattie> also, to be explicit, both are referred to in USN-3522-1
<ctennis> This is what I had about 30 minutes ago: linux-aws is already the newest version (4.4.0.1047.49)
<ctennis> The Meldown page says just says "4.4.0-1047.56"
<ctennis> so I recognize maybe that's a different package, but at first glance it looks like...I'm not up to date enough
<ctennis> anyway, thanks for the response, and don't worry about me, I just wanted to get clarity.  I still think it's confusing, but it sounds like you're all on top of it.
<thresh> well, apparently, linux-image-extra-4.13.0-21-generic=4.13.0-21.24~16.04.1 failed to boot.
<thresh> hmmm.
<thresh> could be a r8169 which is crashes it, then, too..
<jsalisbury> thresh, would it be possible for you to open a launchpad bug?  This will allow allow all this info to be kept together and serachable by others.
<thresh> jsalisbury, sure - I'm just trying to single out the exact problem which causes the issue.
<jsalisbury> thresh, thanks!  I can work with you on the problem.  Can you post the bug number once you have it?
<thresh> yup, but I need to go home soon - will hopefully be able to work on it after a couple of hours.
<jsalisbury> thresh, ok, thanks
<thresh> the fact that it's on hetzner does not help a lot to debug, too :-(
<ricotz> klebers, hi, I noticed that the kernel metapackage for raspi2 depends on linux-firmware which seems not right and linux-firmware-raspi2 would be more fitting
<chiluk> is linux-firmware a metapackage that points a linux-firmware-raspi2?
<apw> nope
#ubuntu-kernel 2018-01-11
<rellis> So two things, first I just wanted to say thanks to all of you folks for so much kernel work over the holidays, you rock.
<rellis> Second I wanted to ask if anyone knows if the table on this page with versions is getting updated as new kernels become available? I'm just asking because my machines on 16.04 LTS linux-aws are getting 4.4.0-1048.57 which I don't see listed there. I wasn't sure if the page just hadn't been updated or I was misinterpreting what they're doing with that table.
<rellis> When I said this page I meant: https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown
<apw> rellis, i would expect the table to have the first version it was nominally addressed in to be in the table, so as long as you have a higher one than that
<klebers> ricotz, for which series?
<ricotz> klebers, noticed it with xenial, but probably all
<alkisg> Please also make it Recommends instead of Depends, as the rpi firmware in many times is provided outside of the real installation (e.g. netbooting), and linux-firmware-raspi2 postinst fails on chroots etc
<thresh> I wonder if the tools described in https://wiki.ubuntu.com/Kernel/CrashdumpRecipe will work for me to debug that crash?
<thresh> (with 4.13.0-21.24~16.04.1 and later)
<klebers> ricotz, alkisg: thanks a lot for the input, I'll discuss it with the raspi2 guy
<alkisg> Thank you klebers
<ricotz> klebers, yw
<thresh> I'm kinda curious right now - I've installed linux-crashdump;  I have GRUB_DEFAULT="1>2" to choose the working kernel on boot automatically (as it's a remote server);  what do I do now to force booting into the faulty kernel, and getting a dump out of it?
<thresh> (I'm kinda stupid, too, which is why I need some guidance)
<zioproto> If you are upgrading because of SPECTRE/Meltdown, be aware that your hardware could not boot if you hit this bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1742630
<ubot5> Launchpad bug 1742630 in linux (Ubuntu) "Booting from 4.13.0-21-generic leads to Oops: NULL pointer dereference - RIP: isci_task_abort_task+0x30/0x3e0 [isci]" [Undecided,Confirmed]
<zioproto> This is a "server thing" for us
<thresh> hey, I have this kernel failing for me, too
<thresh> but I wasnt that lucky to have the trace
<zioproto> thresh: read the bug description, it is already fixed in Debian
<zioproto> thresh: do you have Quanta hardware as well ?
<thresh> I'm on Hetzner dedicated server, which runs AMD Ryzen and some Supermicro motherboard IIRC.
<zioproto> thresh: it is a server thing as I mentioned
<zioproto> I hope the bug gets the right attention. I opened it this morning
<thresh> many thanks!
<zioproto> I figured out the issue was already fixed in Debian but in Ubuntu community it was unknown
<thresh> I was collecting data on the kernels I could boot before I could file a bug as well.
<zioproto> well, the issue is well described if you follow those link on Launchpad
<zioproto> discussion on the kernel mailing list and so on
<thresh> yep, I'm reading it at the moment
<zioproto> :)
<zioproto> So, I hope the information reached the right people and the bug gets triaged :) thanks !
<thresh> well, I'm definitely not the right person to fix it
<thresh> just someone who was struggling with booting the hwe kernel since yesterday
<zioproto> thresh: do you know who we can tag in this IRC channel so that the bug gets attention ?
<zioproto> we have to upgrade a ~100 servers Openstack cluster and we are blocked by this bug :(
<thresh> they person who offered help yesterday is not here, but he asked to file a bug on launchpad when I'm done - so I guess opening a bug is the way to get attention
<zioproto> thresh: makes sense :)
<zioproto> if you remember the nickname we can assign the bug on Launchpad
<zioproto> if somebody was already working on this specific issue
<thresh> it was jsalisbury
<zioproto> thresh: also it would be great of you can click in Launchpad "Yes This bug affects me"
<zioproto> so that we get an headcount of how many people have a problem with this kernel
<TJ-> zioproto: have you tested the latest image? 4.13.0-23 ?
<thresh> I cannot really confirm since i'm not sure this is the exact bug
<thresh> I'm having
<zioproto> TJ-: no I did not test it. But now I will go first to look at the changelog to see differences between 4.13.0-21 and 4.13.0-23. Thank you
<thresh> I think the latest is -26, no?
<thresh> and 21 vs 26 is mostly kpti patches
<thresh> zioproto, and I have a very different SATA controller I think
<zioproto> I cant find the changelog, do you have the link ?
<thresh> no, I'm reading /usr/share/doc/linux-image-extra-4.13.0-26-generic/changelog.Debian.gz on the machine where I have the image installed
<zioproto> I have this http://changelogs.ubuntu.com/changelogs/pool/main/l/linux/
<zioproto> but the version 4.13.0-23 is not listed
<thresh> http://changelogs.ubuntu.com/changelogs/pool/main/l/linux-hwe/linux-hwe_4.13.0-26.29~16.04.2/
<TJ-> -26 is the latest now... keeps moving too quickly for me :D
<zioproto> I have tested this version linux-image-generic-hwe-16.04         4.13.0.26.46
<zioproto> this is not working for me
<TJ-> zioproto: update the bug report so we know it's affecting the current image
<zioproto> TJ-: ok !
<TJ-> zioproto: I'd suggest altering the title so instead of mentioning the version, it says "PTI kernels" and list the versions tested in the description
<zioproto> all done
<thresh> hmm, I was able to run the mainline kernel 4.14, linux-image-4.14.13-041413-generic
<thresh> which one is the linux-image-4.13.0-26-generic based on? 4.13.13?
<thresh> alright, linux-image-4.13.13-041313-generic_4.13.13-041313.201711150531_amd64.deb also fails to boot
<thresh> linux-image-4.13.16-041316-generic_4.13.16-041316.201711240901_amd64.deb works
<thresh> (huge thanks to whoever maintains mainline kernel builds over at http://kernel.ubuntu.com/~kernel-ppa/mainline/)
<thresh> linux-image-4.13.14-041314.201711180632 fails, linux-image-4.13.15-041315-generic boots
<jsalisbury> thresh, do you have a bug open, so I can review all the data so far?
<thresh> jsalisbury, no, I'm going to open it right now, now that I have some informations.  many thanks!
<jsalisbury> thresh, great, thanks.  I'll review everything and see if we can create a test kernel or dig deeper if needed.
<thresh> there you go jsalisbury https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1742721
<ubot5> Launchpad bug 1742721 in linux (Ubuntu) "linux-image-4.13.0-26-generic / linux-image-extra-4.13.0-26-generic fail to boot" [Undecided,New]
<jsalisbury> thresh, thanks!  I'll take a look at it shortly
<thresh> \o/
<jsalisbury> thresh, Just to confirm, upstream 4.13.14 has the bug and 4.13.15 fixes the bug?  If that is the case, I can "reverse" bisect between those two versions.
<thresh> jsalisbury, yes, that's correct.
<thresh> I'm thinking about setting up make-kpkg or something to bisect, too.
<jsalisbury> thresh, perfect.  I'll start bisecting between those two versions and start buiding a test kernel.
<thresh> I've did that for debian, I wonder if that's the same for Ubuntu?
<jsalisbury> thresh, I can build test kernels fairly quickly if your able to test them?  There will be about 10 or so to test.
<thresh> jsalisbury, yeah, I can do that.
<jsalisbury> thresh, great.  Give me about 20 minutes and I'll have the first test kernel ready.
<jsalisbury> thresh, I built the first test kernel and posted a link to it in the bug.
<thresh> jsalisbury, thanks, Ill be able to test it in an hour (commuting home atm)
<jsalisbury> thresh, sounds good, thanks!  Just post the results and I'll build the next test kernel based on that.
<rellis> apw: Thank you for the reply.
<TJ-> Had a report in #ubuntu earlier; user with ~1200 AWS instances, testing the PTI upgrade and despite grub default being  -109, -100 is booting. I've asked them to enable the GRUB serial console logging to capture anything useful, because it appears the fallback kernel is being booted.
<Odd_Bloke> TJ-: That's a little confusing; -109 is the regular xenial kernel, not the custom AWS kernel (which is -1048, I think).
<Odd_Bloke> TJ-: If you see them again, could you ask them to file a bug in the cloud-images LP project?
<TJ-> Odd_Bloke: this user is installing their own kernels from what I could get from them
<TJ-> Odd_Bloke: I've asked them to file a bug if they can collect some useful data :) Not heard anything since (about an hour)
<TJ-> one thing I saw earlier - we've had so many PTI kernel upgrades that with package autoremove we've seen situations where all the installed kernels are PTI and leaving the system unable to boot without nopti
<thresh> jsalisbury, given linux-image-4.13.14-041314-generic_4.13.14-041314.201801111932_amd64.deb also fails to boot, and I have sm750fb loaded on a working kernel... https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=v4.13.15&id=c52278a636018cb8fa39b2538c6da5d35e6515f7 is likely the commit.
<thresh> jsalisbury, but, let's test kernels a bit more ;-)
<jsalisbury> thresh, I posted the next kernel in the bug report.  
<jsalisbury> thresh, sorry for the delay, juggling a couple other bugs as well.
#ubuntu-kernel 2018-01-12
<tsimonq2> .ir
<tsimonq2> whoops
<thresh> jsalisbury, thank you.  I wont be able to test them until this Sunday, sadly.
<tomreyn> good morning. do yuo think this https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1690085 and the linked kernel.org bug are actually the same? i would think they are actually unrelated issues.
<ubot5> Launchpad bug 1690085 in linux (Ubuntu) "Ryzen 1800X freeze - rcu_sched detected stalls on CPUs/tasks" [High,Confirmed]
<tomreyn> also, do you think the ubuntu bug could be ubuntu specific, or could be worked around in ubuntu? the workaround discussed in this bug report seems reliable to me.
<tomreyn> in my experience diabling ALSR is not necessary, and i would think CONFIG_RCU_NOCB_CPU is an acceptable compromise (for this cpou type)
<tomreyn> got disconnected, so i'll type it again:
<tomreyn> good morning. do yuo think this https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1690085 and the linked kernel.org bug are actually the same? i would think they are actually unrelated issues because one of these occurs only in high load (bugzilla.linux.org), the other only in low load (bugs.launchpad.net) situations.
<ubot5> Launchpad bug 1690085 in linux (Ubuntu) "Ryzen 1800X freeze - rcu_sched detected stalls on CPUs/tasks" [High,Confirmed]
<tomreyn> also, do you think the ubuntu bug could be ubuntu specific, or could be worked around in ubuntu? the workaround discussed in this bug report seems reliable to me.
<tomreyn> in my experience diabling ALSR is not necessary, and i would think CONFIG_RCU_NOCB_CPU is an acceptable compromise (for this cpou type)
<alkisg> On 16.04 a school reports that it cannot boot with vmlinuz-4.13.0-26-generic, is there an even newer kernel that they could try?
<apw> alkisg, there is a -28, but i would be supprised if that sorts any boot issues, not impossible, but supprising
<alkisg> apw, thank you... I'll also try with some from the mainline then
<apw> alkisg, do you get anything other than reports of "doesn't boot", and sort of diagnostics someone might be able to look at ?
<alkisg> apw: unfortunately the school IT teachers don't have a lot of linux exprertise, so I would have to travel there (e.g. half an hour drive) and do it myself... I'm doing that of course when the need is great, but usually not when an easy workaround exists
<apw> alkisg, we have never (as a linux community) entirely sensible about making the diagnostics easy for an end-user to report
<apw> alkisg, we did (in the pub over beer) talk about encoding panic stacks as QR codes and showing those
<alkisg> I have set up a very easy way for user-initiated vnc access, but of course that part only works when it boots
<alkisg> I've also worked once with a kvm/ip switch that gave me remote access even before the computer boots, but it's too costly for wide deployment
<alkisg> QR codes sound amazing
<alkisg> Another trick I'm using is: "boot from a live cd. apt install x11vnc kvm; x11vnc -connect srv1-dide.ioa.sch.gr; kvm -m 1024 /dev/sda"
<alkisg> So if they can boot from a live cd and the problem is reproducible under kvm, I can see it remotely
<apw> like that one
<f_g> alkisg: what was the last kernel which did boot? 4.13 has a bug with some SCSI controllers that panic on b oot
<alkisg> f_g: the 4.10.something kernel that 16.04 had
<alkisg> (before the 4.13 bump)
<f_g> as do 4.12, 4.14 and I think 4.15. I saw some patches flying around on LKML that might solve it, Debian's 4.9 and our downstream 4.13 just reverted the buggy commit for now
<alkisg> I can get the exact number if needed
<alkisg>  4.10.0-42 afaik
<f_g> alkisg: see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1726519
<ubot5> Launchpad bug 1726519 in linux (Ubuntu Bionic) "Unable to handle kernel NULL pointer dereference at isci_task_abort_task" [High,In progress]
<f_g> most systems failing to boot 4.13 that I have seen were that one
<f_g> and a simple revert fixes it
<f_g> just added the likely upstream fix as well as a comment, but AFAICT it has not been merged upstream yet.
<f_g> https://patchwork.kernel.org/patch/10154587/ in case you want to test it yourself ;)
<f_g> alkisg jsalisbury ^^
<alkisg> f_g: thanks, that would explain why I can't reproduce it in a VM
<f_g> alkisg: it's entirely possible it's some other HW-related issue though. but if you need to go there to investigate, I'd recommend having a build with the cherry-pick and one with the revert handy to test :P
<f_g> the Spectre/IBRS/IBPB commits in the pti branch have been picked from upstream's pti tip? or straight from LKML? or ... ?
<apw> they are patches we receieved from Intel, they are not likely the final solution
<f_g> apw: thanks for the info. it seems like the first round is getting finalized for upstream inclusion and might make it into -rc8, if it does will you rebase the non-s390 stuff to match what lands upstream?
<apw> f_g, will have to see what lands, if it is reptoline without ibrs (which i assume it is) it will depend how hard it is to merge them, as upstram will put ibrs on the top next
<apw> f_g, in large part it is effort and risk against timescales 
<f_g> tip/pti is currently retpoline only
<apw> right, and there is some concern that reptoline in its current form is not sufficient, so we ahve to err on the side of safe and slow
<apw> we are following along, and assuming we will go that way as soon as humanly sensible
<f_g> right. thanks!
<apw> though google appears to be of the opinion the westmere escapes are highly unlikely, and likely can be fixed by improving reptoline ...
<jsalisbury> f_g, alkisg I built a test kernel with the patch posted here:
<jsalisbury> https://marc.info/?l=linux-scsi&m=151557324907914
<jsalisbury> The test kernel can be downloaded from:
<jsalisbury> http://kernel.ubuntu.com/~jsalisbury/lp1742630
<jsalisbury> Can you test this kernel and see if it resolves this bug?
<gpiccoli> Hi, I was reading: https://help.ubuntu.com/community/UbuntuStudio/RealTimeKernel
<gpiccoli> It shows a table with multiple flavours of kernel, like -lowlatency, -rt and -generic. Thne it mentions "the first 3 above are provided through official Ubutu archives", meaning -generic, -preempt and -rt
<gpiccoli> I could only find -generic and -lowlatency though; is the information obsolete?
<gpiccoli> It could be edited in order to be more accurate, if it's the case.
<gpiccoli> tnx in advance for any clarification!
<alkisg> jsalisbury: I don't have any amd64 school installation to test with, they're all i386... :/
<jsalisbury> alkisg, I'll build a 32 bit kernel for you and let you know when it's ready.
<alkisg> jsalisbury: thank you
<alkisg> I'll go to the school and test on Monday then, when it opens
<jsalisbury> alkisg, There is an i386 version of the test kernel available now.  It can be downloaded from:
<jsalisbury> http://kernel.ubuntu.com/~jsalisbury/lp1742630/i386
<alkisg> jsalisbury: thank you, I can test this on Monday
<jsalisbury> alkisg, great, thanks!
<VulcanRidr> Quick question. I have noticed in the recent past that kernel upgrades do not seem to be writing a /run/reboot-required. Is this an intentional thing? Is there a new method of knowing the system needs a reboot? I'm working mostly on 14.04 boxes.
<TJ-> VulcanRidr: is unattended-upgrades package installed?
<VulcanRidr> TJ-: It is.
<VulcanRidr> root@unkarplutt:~# ls -l /run/reboot-required
<VulcanRidr> ls: cannot access /run/reboot-required: No such file or directory
<VulcanRidr> root@unkarplutt:~# dpkg -l unattended-upgrades
<VulcanRidr> Desired=Unknown/Install/Remove/Purge/Hold
<VulcanRidr> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
<VulcanRidr> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
<VulcanRidr> ||/ Name           Version      Architecture Description
<VulcanRidr> +++-==============-============-============-==================================
<VulcanRidr> ii  unattended-upg 0.82.1ubuntu all          automatic installation of security
<TJ-> VulcanRidr: hmmm, because for u-u that marker file is touched by the script /etc/kernel/postinst.d/unattended-upgrades
<VulcanRidr> Hrmmm...So where did that file go?
<TJ-> VulcanRidr: is it missing ?
<TJ-> do "dpkg -L unattended-upgrades" check if it is in the 14.04 package; I checked on 16.04
<VulcanRidr> TJ-: It sure isn't in there.
<VulcanRidr> That explains a lot...
<VulcanRidr> It is on the 16.04 box I checked, but it is certainly not on the 14.04 box.
#ubuntu-kernel 2018-01-14
<TJ-> Looks like the nvidia-graphics-drivers-340 will need patching again, for the 4.15 timer API changes
<mamarley> TJ-: The graphics-drivers PPA already has patched packages: https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa/+packages
<TJ-> mamarley: ha, thanks... so long since I used the proprietary drivers I had completely forgotten about that. Hit the build bug earlier when I installed 4.15rc7 :)
<mamarley> No problem.
<mabkenar> Hi. Where should I file a bug for this? I mean, against which package?
<mabkenar> I have a Thinkpad X200. I installed Ubunntu 16.04.3. It works fine out of the box.
<mabkenar> But when I install updates, it starts to behave weirdly. 
<mabkenar> All Unity eye-candies stop to work and cause a session refresh.
<mabkenar> I mean, when I press Alt (HUD), or Super (Dash), or even when I hover my mouse over an icon on the launcher...
<mabkenar> the system goes through a mini-crash: all elements on the screen disappear for ~2 seconds, and they come back again. I never see HUD, Dash, or the laucher tooltip that I intended to see.
<mabkenar> (Is it safe to say 3D accleration has stopped working after kernel update?)
<mabkenar> These are my system specs: Intel Core 2 CPU P8600 @ 2.40GHz x 2, Mobile Intel GM45 Express Chipset, 64-bit
<mabkenar> (and by the way, it is running Libreboot as BIOS, which I installed by myself)
<mabkenar> Thanks for your help in advance. I am masoud.abkenar.net.
#ubuntu-kernel 2020-01-08
<nyov> cking: hi! once upon a time, you wrote this answer: https://askubuntu.com/a/729758 - Are you (or anyone else) aware if this is fixable via ACPI (DSTD) table patches?
<sdhd-sascha> Hi, does anybody know, how to ensure that a zfs directory is synced to disk. I have trouble with `du` (directory usage size) 
<tomreyn> i assume "sync" doesn't then?
<cking> nyov, let me have a look
<nyov> cking: oh awesome. The relevant code would be here https://github.com/torvalds/linux/blob/master/arch/x86/kernel/apic/io_apic.c#L2210
<cking> sdhd-sascha, the du command won't give you the correct info, you need to use zfs list
<cking> zfs knows more about how much is really being used (because of snapshots etc) than du can provide
<cking> nyov, i doubt that dabbling with tweaking the DSDT will be an easy route to fixing this, best try the kernel parameter 'noapic' as as workaround
<sdhd-sascha> cking: thank you. 
<sdhd-sascha> The problem is, that "ubuntu-image" creates a temporary directory and `du` calculates the rootfs size. On my system i use /tmp/ on zfs with "sync=always" enabled
<sdhd-sascha> Is it possible to use "zfs list" to get a subdirectory size ? I also tried `sync -f $(find /tmp/subdir)` . But didn't help in the most cases
<sdhd-sascha> I also have create extra ZIL and L2ARC on a SSD ...
<sdhd-sascha> cking: or is there a system-call which i could call, to get the correct size ?
<nyov> cking: thankfully thats not necessary, the kernel finds the right workaround and it works. I was just curious if I could fix it, since I already have to fix so much else in the DSDT.
<nyov> (stupid notebook can't even wake up from standby)
<sdhd-sascha> @tomreyn: right, sync did not work immediately
<sdhd-sascha> After some seconds the dir size is corrected
<sdhd-sascha> ... just read some solaris posts. I think i can imagine the problem with COW and compression now
<sdhd-sascha> Shortest solution could be to iter all files and sum up the size. Or?
<sdhd-sascha> Would linux sys_newstat return correct values in all cases? E.g. compression
<sarnold> sdhd-sascha: have you seen this yet? https://lists.freebsd.org/pipermail/freebsd-stable/2010-May/056654.html
<sdhd-sascha> sarnold: not yet. What is the best place for kernel interface documentation ? i found something like "kernel.readthedocs.org"
<sdhd-sascha> thank you :-)
<sdhd-sascha> My last reading about kernel programming was around 2.2 ~ 2.4 ...
<sarnold> sdhd-sascha: there's no single good answer for kernel interface docs; the source code is the source of truth but also hard to digest; the zfsonlinux documentation is among the best documentation around, but is of course a bit specific to its own needs
<sdhd-sascha> okay :-) grep'ing the headers :-)
<sdhd-sascha> sarnold: just read the thread from the mailing-list. great, thank you, again +1
<sarnold> sdhd-sascha: woo, cool :)
<tqinli> Hi, I file this bug report 6 months ago: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1835940, wondering what is the plan to have the fix backport to 4.15 kernel ?
<ubot5> Ubuntu bug 1835940 in linux (Ubuntu) "perf core dump at tool/perf/util/namespaces.c:144" [Undecided,Confirmed]
#ubuntu-kernel 2020-01-10
<TJ-> Which would be the best package to report against to have ./drivers/pci/controller/pci-hyperv.ko included in linux-modules rather than linux-modules-extra, so it is available to the -server installer ? 
<smb> TJ-, the linux package. though I am not sure it is a matter of modules packaged. at least not on old world (the debian installer would use udebs) but maybe that new and shiny new one does
<smb> but in either case the request made against the linux source would be the right thing to do
<TJ-> smb: I thought so but wanted to check. I hit this due to deploying 20.04 into a Hyper-V guest that is using DDA (Discrete Device Assignment aka PCI-passthrough) for 2x NVMe storage devices
<TJ-> smb: Had to drop to the di-i shell and 'udpkg --unpack /cdrom/pool/main/l/linux/linux-modules-extra-`uname -r`_amd64.deb; depmod; modprobe pci-hyperv-intf; modprobe pci-hyperv' in order to have the para-virtualised PCI bus available
<smb> TJ-, the is a chance that this is still also done via the udebs but I am usually lagging behind with knowledge on future release
<smb> TJ-, but that can be fleshed out once there is a bug report about it
<TJ-> Bug #1859212
<ubot5> bug 1859212 in linux (Ubuntu) "Move pci-hyperv.ko from linux-modules-extra to support installation to Hyper-V using DDA" [Undecided,New] https://launchpad.net/bugs/1859212
<mwpastore> hi folks, I was playing around with hwe-edge in bionic and I noticed that kernel 5.3 includes zfs 0.8.1. this is problematic for two reasons: 1. the bionic zfs packages are all 0.7.5, and 2. zfs 0.8.2 has a lot of kernel 5.3 compatibility fixes. is there a plan for zfs in 18.04.4, and does it address these concerns? 
<sarnold> mwpastore: excellent question.. the 18.04 on root guide mentions HWE kernels just off-hand.. https://github.com/zfsonlinux/zfs/wiki/Ubuntu-18.04-Root-on-ZFS "Hint: For the HWE kernel, install linux-image-generic-hwe-18.04 instead of linux-image-generic"
<sarnold> it's not a strong enough mention for me to be sure that combination was actually tested, and since the hwe rolls along, it might have worked once but I'm not sure if it'd still work today
<mwpastore> sarnold: yes, 18.04.3 is/was perfectly fine, everything is lined up on zfs 0.7.5 
<mwpastore> the question is just what's going to happen with the next release
<mwpastore> that's just the root-on-zfs guide, anyway. plenty of folks using ZoL in Ubuntu with a separate root filesystem, I'm sure
<sarnold> yeah, I've got one of each
