#ubuntu-kernel 2006-02-20
<fabbione> BenC: i found a bug in linux-headers on ia64.. we need to ship arch/ia64/module.lds otherwise build of external modules will fail miserably.
<fabbione> i will try to get a fix in git, but i am utterly busy these days
<BenC> fabbione: ok
<zul> mental note...when hacking on grub dont do it on a live system
<fabbione> BenC: thanks dude
<fabbione> hey zul
<zul> hey fabbione how is it going?
<fabbione> zul: as usual
<doko> BenC: please could you update mISDN to a more recent snapshot/CVS checkout? going to update/package the mISDN user tools; I do not want to worlk with older ones
<BenC> doko: ok
<bluefoxicy> hey
<bluefoxicy> is there something weird as hell going on with dapper wrt vm space
<bluefoxicy> it seems to refuse applications more than 1 gig of accessible VM in 2.6.15-15-686
<bluefoxicy> seriously
<bluefoxicy> if I repeatedly mmap() the zero page in I hit 1 gig and it dies.
<psusi> did this work in breezy?
<zul> bluefoxicy: should be fixed soon i think..
<bluefoxicy> zul:  is it known?
<bluefoxicy> psusi: trappist said it worked on his i386 as it should (~3GiB mapped)
<zul> bluefoxicy: yeah its know afaik 
<bluefoxicy> ok
<psusi> I wonder if that toolchain breakage that is causing shared objects to be built with rediculous alignment requirements on amd64, causing lots of PROT_NONE pages to be mapped so the process looks like it is hogging a lot of memory when it isn't will ever be fixed...
<bluefoxicy> zul:  i stumbled across it because Yosh from #gimp on gimpnet thinks that the kernel by default does 2G/2G split instead of 3G/1G (3G application accessible) and I was trying to prove him wrong >/
<bluefoxicy> he still doesn't believe me
<bluefoxicy> any idea what causes that bug o.o that's kind of a major vm problem. . .
<zul> no idea...you would have to ask BenC
<bluefoxicy> ah ok, just curious.
<psusi> bluefoxicy: iirc, the default in linus's tree is 3/1, but it's a compile time option to change it
* psusi is glad he doesn't have to worry about that stuff anymore... got to love 64 bit
<bluefoxicy> yes i want to go 64 too
<bluefoxicy> but I have lots of sweet flash movies
<bluefoxicy> that I like to watch
<bluefoxicy> Rise of the Mushroom Kingdom <3
<bluefoxicy> and Super Mario:  Reloaded
<bluefoxicy> "Like you, apparently, free."
<bluefoxicy>   "Congratulations."
* psusi decided to give up all non open source software because closed source is the debil
<bluefoxicy> "But as we both know, Mr. Anderson, looks can be deceiving, which brings me to why we're here. . we're not here because we're free, we're here because we're not free, there is no denying purpose, for without purpose we would not exist. *1000 luigis show up*"
<bluefoxicy> 64 bit systems should be full position independent executable by default
<bluefoxicy> and we should hunt down and destroy elf text relocations
<bluefoxicy> stupid shit like prototyping a function within another function >:|
<bluefoxicy> int main() { int mybar=0; int foo(int bar); foo(mybar); }
<bluefoxicy> or little bits of inline assembly code that use %EBX
<bluefoxicy> <Dad> you should get your mom something for her birthday, you missed valentine's day >:|
<bluefoxicy> <Me> huh?  oh.  It's her birthday?  *shrug* Eh I don't like her anyway.
<BenC> I just love a well disguised pyramid scheme
<psusi> man I wish people would let the farce known as disk geometry die...
#ubuntu-kernel 2006-02-21
<bluefoxicy> didn't get anywhere with the K8 kernel
<bluefoxicy> it starts to boot, and then my newcastle cored machine just streaks the machine with green bars and hardlocks.
<pdr> anyone around?
<ajmitch_> sure
<fabbione> BenC: please pull from my archive. I have a couple of redhat cluster suite updates only.
<fabbione> hey BenC 
<BenC> fabbione: Hey, I'll pull from you after the meeting
<fabbione> i got a couple of updates in my tree.. it would good if you can pull before upload .22
<fabbione> ok perfect
<fabbione> i think for dapper+1 we will spare our troubles from manual merging
<fabbione> steve did publish gfs2 tree in git on kernel.org
<fabbione> but we can't switch to it yet
<fabbione> too unstable
<BenC> cool
<fabbione> it was about time :)
<fabbione> after tons of ranting ;)
<fabbione> i know for a fact that the GFS redhat team hates me
<BenC> lol
<fabbione> http://sources.redhat.com/ml/cluster-cvs/2006-q1/msg00178.html
<fabbione> https://www.redhat.com/archives/linux-cluster/2006-February/msg00120.html
<fabbione> i don't give them time to breath :)
<zul> heylo
<infinity> (base)adconrad@cthulhu:~$ ls /sys/bus/pci_express/devices/ -l
<infinity> total 0
<Keybuk> total 0
<Keybuk> lrwxrwxrwx 1 root root 0 2006-02-16 14:12 pcie00 -> ../../../devices/pci0000:00/0000:00:0e.0/pcie00
<Keybuk> lrwxrwxrwx 1 root root 0 2006-02-16 14:12 pcie00 -> ../../../devices/pci0000:00/0000:00:0e.0/pcie00
<Keybuk> lrwxrwxrwx 1 root root 0 2006-02-16 14:12 pcie00 -> ../../../devices/pci0000:00/0000:00:0e.0/pcie00
<Keybuk> lrwxrwxrwx 1 root root 0 2006-02-16 14:12 pcie00 -> ../../../devices/pci0000:00/0000:00:0e.0/pcie00
<Keybuk> lrwxrwxrwx 1 root root 0 2006-02-16 14:12 pcie03 -> ../../../devices/pci0000:00/0000:00:0e.0/pcie03
<Keybuk> lrwxrwxrwx 1 root root 0 2006-02-16 14:12 pcie03 -> ../../../devices/pci0000:00/0000:00:0e.0/pcie03
<Keybuk> lrwxrwxrwx 1 root root 0 2006-02-16 14:12 pcie03 -> ../../../devices/pci0000:00/0000:00:0e.0/pcie03
<Keybuk> lrwxrwxrwx 1 root root 0 2006-02-16 14:12 pcie03 -> ../../../devices/pci0000:00/0000:00:0e.0/pcie03
<Keybuk> -- 
<infinity> Yeah, what he said.
<Keybuk> interesting that they're all the "same" device
<infinity> Except for the part where I get aimed at a different bus/bridge, but whatever.
<infinity> Same shit.
<Keybuk> infinity: do any links you have of the same filename point to different destinations?
<infinity> Nope, same as yours. 00 to 00, 02 to 02, 03 to 03.
<infinity> Three 00, two 02, and three 03. :)
<infinity> thpethul.
* infinity should go to bed.
<Keybuk> BenC: so yeah, it'd be nice if it didn't do *that* :)
<BenC> ok
<BenC> all those symlinks from from the driver core, so pcie must just be doing something stupid with sysfs linking
<infinity> Yeah, I think we already concluded on the "something stupid with linking" front.
<infinity> :)
<BenC> ah, no it's not really that stupid
<BenC> each of those links represents a "pcie service" for that device
<BenC> the naming is just stupid
<Keybuk> except for the "creating symlinks that userspace can't deal with" stupidness? :p
<BenC> it should include the service number so it's unique
<Keybuk> pcie00:%d ?
<Keybuk> (same for the subdirs under /sys/bus/pci/devices/*/pcie%d ?
<BenC> can you ls -l /sys/devices/pci0000:00/0000:00:0e.0/ ?
<infinity> base)adconrad@cthulhu:~$ ls -l /sys/devices/pci0000\:00/0000\:00\:1c.2/
<infinity> total 0
<infinity> lrwxrwxrwx 1 root root    0 2006-02-17 06:22 bus -> ../../../bus/pci/
<infinity> -r--r--r-- 1 root root 4096 2006-02-17 06:22 class
<infinity> -rw-r--r-- 1 root root 4096 2006-02-17 06:22 config
<infinity> -r--r--r-- 1 root root 4096 2006-02-17 06:22 device
<infinity> lrwxrwxrwx 1 root root    0 2006-02-17 06:22 driver -> ../../../bus/pci/drivers/pcieport-driver/
<infinity> -r--r--r-- 1 root root 4096 2006-02-17 06:22 irq
<infinity> -r--r--r-- 1 root root 4096 2006-02-17 06:22 local_cpus
<infinity> -r--r--r-- 1 root root 4096 2006-02-17 06:22 modalias
<infinity> drwxr-xr-x 3 root root    0 2006-02-17 06:22 pcie00/
<infinity> drwxr-xr-x 3 root root    0 2006-02-17 06:22 pcie02/
<infinity> drwxr-xr-x 3 root root    0 2006-02-17 06:22 pcie03/
<infinity> drwxr-xr-x 2 root root    0 2006-02-17 06:22 power/
<infinity> -r--r--r-- 1 root root 4096 2006-02-17 06:22 resource
<infinity> -r--r--r-- 1 root root 4096 2006-02-17 06:22 subsystem_device
<infinity> -r--r--r-- 1 root root 4096 2006-02-17 06:22 subsystem_vendor
<infinity> --w------- 1 root root 4096 2006-02-17 06:22 uevent
<infinity> -r--r--r-- 1 root root 4096 2006-02-17 06:22 vendor
<infinity> (base)adconrad@cthulhu:~$
<Keybuk> -- 
<infinity> (That's my PCIe bus)
<Keybuk> and for me
<Keybuk> drwxr-xr-x 3 root root    0 2006-02-16 14:12 0000:01:00.0
<Keybuk> lrwxrwxrwx 1 root root    0 2006-02-16 14:12 bus -> ../../../bus/pci
<Keybuk> -r--r--r-- 1 root root 4096 2006-02-16 14:12 class
<Keybuk> -rw-r--r-- 1 root root 4096 2006-02-16 14:12 config
<Keybuk> -r--r--r-- 1 root root 4096 2006-02-16 14:12 device
<Keybuk> lrwxrwxrwx 1 root root    0 2006-02-16 14:12 driver -> ../../../bus/pci/drivers/pcieport-driver
<Keybuk> -r--r--r-- 1 root root 4096 2006-02-16 14:12 irq
<Keybuk> -r--r--r-- 1 root root 4096 2006-02-16 14:12 local_cpus
<Keybuk> -r--r--r-- 1 root root 4096 2006-02-16 14:12 modalias
<Keybuk> drwxr-xr-x 3 root root    0 2006-02-16 14:12 pcie00
<Keybuk> drwxr-xr-x 3 root root    0 2006-02-16 14:12 pcie03
<Keybuk> drwxr-xr-x 2 root root    0 2006-02-16 14:12 power
<Keybuk> -r--r--r-- 1 root root 4096 2006-02-16 14:12 resource
<Keybuk> -r--r--r-- 1 root root 4096 2006-02-16 14:12 subsystem_device
<Keybuk> -r--r--r-- 1 root root 4096 2006-02-16 14:12 subsystem_vendor
<Keybuk> --w------- 1 root root 4096 2006-02-16 14:12 uevent
<Keybuk> -r--r--r-- 1 root root 4096 2006-02-16 14:12 vendor
<Keybuk> syndicate co%
<Keybuk> -- 
<BenC> well, that pcie%02x is supposed to be an OR of the type and service (4 bits each)
<Keybuk> the pcie00 and pci03 directories just contain bus, power and uevent
<BenC> why it isn't unique is a little odd
<Keybuk> aye
<BenC> I'll have to ask about this
<Keybuk> that "pci device" does appear to the the pcie bus
<Keybuk> the pcie devices themselves (ie. the video card and friends) show up as ordinary pci devices
<infinity> Yes, they do.
<infinity> If they didn't, my laptop wouldn't work with breezy. :)
<infinity> (breezy's radeon driver didn't support PCIe, only PCI)
* Keybuk wonders whether nvidia-glx is talking via PCIe or PCI
<Keybuk> (and how to tell)
<infinity> It does PCIe.
<BenC> "because they are a bunch of clueless idiots"
<BenC> not really a helpful response
<BenC> Time to try Xgl, brb
<Keybuk> ah, "(II) NVIDIA(0): Detected PCI Express Link width: 8X"
<Keybuk> glxgears -iagreethatdanielsisachild says ~20000 FPS
<Keybuk> so I guess that works then
<bcollins> xgl totally hosed things up
<bcollins> guess it's not ready for ppc and/or radeon
<mjg59> Yeah, I've had a couple of people say that
<mjg59> Ooh. Based on LKML, people are booting Linux on the Macs.
<Keybuk> Mactels?
<mjg59> Yeah
<mjg59> Though ACPI is exploding on them
<mjg59> (During boot)
<mjg59> Wonder how he's getting console output
<mjg59> Looks like a gentoo person. Hmm.
<Keybuk> who is it?
* bcollins is doing the opposite
<bcollins> trying to get Tiger running on a P4
<mjg59> "Edgar Hucek"
<mjg59> Would be interesting to find out
<Keybuk> name doesn't ring a bell
<mjg59> Nope
<mjg59> Was doing some work on Xbox stuff at some point
<zul> never heard of him
<mjg59> Hmm.
<mjg59> We need to get hold of some Mac hardware.
<Keybuk> is Mactel stuff out in the shops yet?
<zul> supposedly
<Keybuk> we've apparently ordered one
<mjg59> An iMac?
<mjg59> Or a Macbook?
<Keybuk> Macbook
<mjg59> When? The originals batch should be being delivered nowish, but new orders look like they're pushed back until March...
<Keybuk> dunno, I guess it was probably about the time Jane said we'd be trying to do the work ;)
<mjg59> Heh
<mjg59> Booting a kernel should be fine, but we'll need to find out some way to get a console off it
<Keybuk> they don't have usual PC BIOS do they?
<Keybuk> I guess Linux's support for EFMI isn't quite there yet?
<Keybuk> surprised Intel haven't helped with that
<mjg59> EFI is fine
<mjg59> People have been using it to boot on IA64 for years
<mjg59> And elilo should work fine on x86
<Keybuk> why no console then?
<mjg59> Does EFI provide a sensible console?
<Keybuk> I don't know
<mjg59> (Once passed to the kernel)
<mjg59> I guess it might do - in which case vgacon probably works
<Keybuk> it's one of those things where until I see one, I won't know much about it ;)
<mjg59> Ah, yeah, IA64 has VGAcon
<mjg59> So it might work
<mjg59> That would make life easier
<mxpxpod> what would make syslogd spawn 9 new instances of itself when I resume from sleep?
<bcollins> sweet...never though I'd see osx installing on this P4
<zul> did you pay for your copy of osx?
<bcollins> *cough*Of course*cough*
<zul> hmm...maybe i should try..
<bcollins> the paid-for copy of osx wont install on normal PC hw without all the extra hacks
<zul> hehe
<bcollins> namely, needing sse3 hw
<bcollins> the "copy" I have has an sse2 hack, so I can atleast run it on my P4
<zul> oooo...i have sse2 as well...gimme..;)
<zul> *cough* gimme please *cough*
<bcollins> uh, I deleted it from my public high b/w system...no way I'm uploading at 27k/sec :)
<zul> heh...its ok...ill just go hang myself..:)
<Keybuk> bcollins: is there any particular advantage to the amd64-k8 kernels over amd64-generic?
<BenC> Keybuk: just that the compile-time options are more geared toward k8
<Mithrandir> Keybuk: they give you IO-MMU support, for instance.
<Keybuk> Mithrandir: btw, anything in particular you'd like me to test on this?  I know you've been doing some amd64 portability work
<Mithrandir> Keybuk: actually, yes.  If you run ddcprobe from the console, does it output sane values for you?
<Keybuk> yes, quite a bit
<Mithrandir> pitti has some problems with his card, but I'm not sure which one that is yet
<Keybuk> http://rafb.net/paste/results/I1NxVx81.html
<Mithrandir> hmm, so it appears it doesn't do edid for you either.. :-/
<Keybuk> interesting
<Mithrandir> any chance you could try ddcprobe from a i386 live cd?
<Keybuk> Xorg.0.log says the nvidia driver has read stuff from EDID
<Keybuk> as in boot the Live CD and try?  or just run the i386 binary on this?
<Mithrandir> as in, boot the live cd, pop out to the console and run sudo ddcprobe there
<Keybuk> right
<Keybuk> will have to do that a bit later ;)
<Keybuk> will give you the result tomorrow
<Mithrandir> the amd64 kernel doesn't have the vm86 syscall, so the i386 binary is useless on amd64.
<Mithrandir> thanks, no hurry.
<fishdish> another curiosity: there is this computer called TYAN VX 50. It has 8 slots for AMD Opteron processors. We are trying to fix Ubuntu to work with all the 8 processors. We have a problem though: 4 of the processors are connected to the motherboard with a PCI-E. Therefore there's a PCI-E to cross to 4 processors which are missing from the configuration
<cjb> fishdish: "are missing from the configuration"?
<doko> * Added support for Intel PRO/Wireless 3945ABG driver; this driver needs 16KB
<doko>   stacks in kernel.
<doko> BenC: this is from ndiswrapper-1.9. do our kernels have 16kB stacks?
<BenC> our stacksize is stock
<fishdish> yeah... 4 processors are seen, 4 missing
<fishdish> it seems that the PCI-E between the processors hides the add-on board from sight
<fishdish> this monitor sux even
<fishdish> I have noticed that this is a kernel issue. Some ppl on #debian thoguht NUMA had to be reconfigured.
<fishdish> but i think NUMA has nothing to do with it
<fishdish> which part of the kernel handles multiprocessing over PCI-E?
<fishdish> TYAN sells their product with Linux (suse) but i'd like to use Debian/alternative
<fishdish> Therefore in need to build  a custom kernel
<fishdish> i think this server is not the only one with such hardware... it would help also with many other hardcore workstations
<Keybuk> Mithrandir: didn't have any luck with the breezy live cd
<Keybuk> it spat random garbage at my monitor and X crashed
<fishdish> Keybuk tune the video mode
<Keybuk> fishdish: it's a live cd ... I can't ;)
<fishdish> ah, and it's not knoppix
<Keybuk> I suspect it's more that the nv driver can't drive this card, but thought it could
* fishdish is troubled with building custom kernels
<fishdish> nvidia drivers sux
<fishdish> they are like 10000 hours older than the current winoze drivers
<fishdish> windoz
<Keybuk> the nvidia-glx one in dapper works just fine for me
<fishdish> me i need sth to support processors behind PCI Express
<fishdish> it's a lot of guessing
<Keybuk> you'll almost certainly have to write it yourself :)  enjoy
<Keybuk> Mithrandir: I'll have to wait until I have real bandwidth before I can download and burn a dapper Live
<fishdish> i think so - the more i read the docs and ask people, the more i think so. Novell Linux Server can see the whole 8 processors but i don't want Novell Linux Server. I want Debian. The Real Linux.
<fishdish> ...so many diffrent kinds of computers to configure fro Linux..
<mjg59> Keybuk: Just boot to console mode
<Keybuk> mjg59: how do you do that on a live?  "s" as usual?
<mjg59> If all else fails, just pass init=/bin/bash
<Keybuk> does that not break casper?
<Keybuk> I don't know much about the breezy live
<mjg59> Dunno
<fishdish> bash sux why cant there be a shell script perl-alike?
<mjg59> I'm sure if you poke it hard, somethng will happen
<Nigelenki> amd64 kernel hard-locked when I opened gtk-gnutella, 2.6.15-15-generic
<fishdish> cool
<fishdish> what about running Ubuntu on a MIPS processor? the next computer i have is a MIPS -based development board that represents a handheld. If i build a Debian kernal with MIPS support and then build Ubutnu on top of it, will it work?
<fishdish> typos...
<fishdish> ...the CPU is an ARC 750D
<fishdish> the same core with nintendo Came Cube
<fishdish> ..i believe
<Nigelenki> mmm
<Nigelenki> ^3buntu
<Mithrandir> Keybuk: just installing xresprobe from dapper?
<Keybuk> Mithrandir: hmm?
<Mithrandir> Keybuk: you know you can install random stuff to the live cd?
<Mithrandir> Keybuk: so just change breezy to dapper and then do apt-get install xresprobe on the live cd.
<Keybuk> Mithrandir: only if you can get the live cd to actually *boot* :)
<Keybuk> it crashed
<Mithrandir> Keybuk: heh, tried with noapic acpi=off?
<Keybuk> Mithrandir: nope, too much effort <g>  will just do a dapper one later
<Keybuk> breezy live takes too long to boot
<Mithrandir> Keybuk: sure
#ubuntu-kernel 2006-02-22
<mjg59> bcollins: Around?
<mjg59> bcollins: I suspect there may have been a mismerge when you were trying the new ACPI patches
<mjg59> (The ones you reverted, that is)
<bcollins> shouldn't have been
<bcollins> I did git-revert
<mjg59> bcollins: On boot, I get a pile of "Could not allocate new owner id", and then ACPI gets disabled
<bcollins> in reverse order
<mjg59> bcollins: When you were applying them in the first place
<mjg59> Before you reverted them
<mjg59> I've just reapplied them to figure out what went wrong
<bcollins> ah
<bcollins> it's probably got something to do with the 64bit long id thing to 256 max
<mjg59> We had a patch applied to deal with the owner_id stuff, which conflicted with the acpi-ca patches
<bcollins> that was the only real conflict in applying them
<mjg59> Yeah
<bcollins> right
<mjg59> So I'm suspicious about these errors
<mjg59> bcollins: Indeed - just found a line that was missing
<mjg59> acpi_gbl_next_owner_id_offset never gets set back to 0, so everything explodes
<BenC> ah
<mjg59> And yes, that works much better now
<mjg59> Though pnpacpi has got broken - looks like there's a patch for that, though
<mjg59> BenC: Any chance we can have those back, then? :)
<BenC> yeah, want to send me your diff? :)
<mjg59> Hmm. Though interrupt routing still seems a touch confused.
<mjg59> Yeah, a pile of stuff is ending up on irq 0. Hm.
<mjg59> BenC: How can I disable MSI? I'm sure there's a boot parameter, but I can't find it
<mjg59> Ah - actually, this could be due to slightly changed acpi semantics - I may just need to rebuild all my modules...
<mjg59> BenC: Ok, got a fix for the interrupts
<mjg59> BenC: So I've sent you two patches, both to be applied after the acpi-ca patches are un-reverted. One fixes ACPI owner-id stuff, and the other fixes gsi allocation so PCI devices get interrupts
<zul> heylo
<zul> BenC: dont be goofy...thats evil..:)
<BenC> zul: I have macox running and using my rt2500 pci wireless card
<zul> sweet..
<zul> can you dual boot with it?
<BenC> yeah, I have it dual booting with ubuntu
<BenC> it's cool, the osx86 website has a howto for ubuntu install/dualboot of osx86 :)
<BenC> with a caption that says "the one that started it all"
<zul> mmmmmm...need osx
<BenC> we need to figure out how osx does it's splash screen, it looks the same as it does on ppc hw
<BenC> and it looks perfect on my nvidia/tv-out mame system, whereas our usplash looks a little corrupted
<zul> hmm..maybe i should do it at work...tell my boss is for educational purposes
<mjg59> BenC: Where did you get an rtl2500 driver?
<BenC> it'll need a p4 or athlon system (sse2 minimum, sse3 prefered)
<mjg59> Or is it just ported from BSD?
<BenC> mjg59: posted on a osx86 forum from someone who got it from the hw vendor
<BenC> it's a native driver
<mjg59> Sweet
<BenC> i386/ppc fat
<mjg59> I note that the iMacs still have Broadcom wireless
<mjg59> BenC: Does it do suspend/resume?
<BenC> hmm...haven't tried that yet
<mjg59> Oh, Pentium Ms have sse2 too
<BenC> oh crap
<BenC> I almost forgot, I've been wanting to test the darwine
<BenC> it's x86 only right now, but it's the whole reason I installed osx86
<BenC> it doesn't seem to support my built-in UHCI host controller either
<BenC> had to install a OHCI card
<BenC> UHCI is supported but my 82801 chipset seems to not work well (as reported by others too)
<BenC> oh wow, now that I spent all this time installing osx86, there's a ppc version of darwine that runs win32 apps
<BenC> using qemu
<mjg59> Haha
<zul> yay i have qemu working again
<bluefoxicy> you know
<bluefoxicy> the amd64 kernels in dapper are -VERY- -UNSTABLE-.
<bluefoxicy> I can barely stay up 15 minutes.
<infinity> They're stable for me.  Guess I'm just lucky...
<infinity> (Or you have hardware we don't like... Have you filed bugs?)
<bluefoxicy> I can't determine the root cause to file a bug.
<bluefoxicy> Last time I installed (about 1 hour ago) it froze when I tried to even boot a -k8 kernel, screen got green lines
<bluefoxicy> now, I have to boot a k8 kernel, the generic 2.6.15-15 does the same.
<bluefoxicy> this means the problem is not repeatabel.
<bluefoxicy> mm ok
<bluefoxicy> I can address 85TiB of virutual memory space
<bluefoxicy> I should not have problems with gimp dying when I hit 1GiB of allocated shit anymore.
<fabbione> bluefoxicy: try to boot with noapic
<bluefoxicy> fabbione:  i will the next time this thing freezes.
<bluefoxicy> fabbione:  would that be localized to x86-64 only?  I have been running a 32 bit dapper stabilly for quite  while.
<fabbione> it might be
<bluefoxicy> fabbione:  is there anything that need be said about JFS re not using it ever?
<fabbione> bluefoxicy: -EPARSE
<bluefoxicy> I tried to install with a jfs root, it seemed slightly tempermental. . . the system froze 2 or 3 times, and after that last one the dpkg database was hosed (I did not use apt or synaptic on that boot), the GDM Human theme was destroyed (was not written to at any point during that boot cycle), and gnome ceased to function properly (panel wouldn't start)
<fabbione> dunno i don't use JFS
<fabbione> file a bug
<bluefoxicy> so i'm on xfs now, which I have experienced things such as reset-button-while-writing etc etc and have a /home on xfs that's like forever old and has been through many failures and never lost data
<bluefoxicy> and I'm thinking, "Damn, it looks like JFS might just be flakey."
<bluefoxicy> fabbione:  yes but what kind of bug?
<bluefoxicy> "JFS appears to be very shakey and easy to damage, it should probably never be used" doesn't seem very descript.
<fabbione> a bug in which you write whatever is happening?
<fabbione> Ben will ask you for info
<fabbione> to see what he needs to know
<bluefoxicy> alright
<bluefoxicy> out of curiousity, do any of the ubuntu devs use jfs?
<fabbione> i don't
<fabbione> i am not stupid enough to use these useless filesystem
<infinity> I just use ext3, since that's the default.  I'm lazy that way.
<bluefoxicy> I installed with ext3 recently (a few months back) and it ate 900 megs more space or so o_o
<infinity> I used to use xfs, when I was more interested in tweaking to the Nth degree.
<bluefoxicy> I used to use reiserfs, when I didn't mind using piles of trash o.o
<infinity> I'd recommend ext3 or xfs to anyone, tell poeple to stay way the hell away from reiser, and I have no real opinion of jfs.
<bluefoxicy> trash that works pretty well, but still trash
<bluefoxicy> heh, you noticed it's a horribly implemented maze of shit too huh?
<infinity> <shrug>.. The code could ber perfectly elegant and lovely, and it wouldn't change the fact that it eats filesystems for breakfast.
<infinity> s/ber/be/
<bluefoxicy> eh, reiser always seemed stable to me integrity-wise
<bluefoxicy> but its underlying design is a bastardization
<infinity> You were lucky. :)
<bluefoxicy> hans reiser was and is like
<bluefoxicy> "OMG, XATTRS?  NOOOOOOOOOOOOO IDIOT."
<bluefoxicy> that was the beginning.  Let's not implement what normal people implement in our own way; let's change what we want to say a file system is and does.
<bluefoxicy> it went farther with Reiser4; someone described Reiser4 as having a symptom where "all directories are symlinks" or something
<bluefoxicy> besides the fact that Reiser4 added a new syscall that goes DIRECTLY into reiser4's code, past the kernel vfs
<bluefoxicy> when I started to realize what a psychopath hans was, I decided I should move away from reiserfs
<bluefoxicy> Right now I think he's an apprentice to other famous loons, including Theo de Raadt and RMS
<bluefoxicy> I'm sure he'll master the art of lunacy in time.
<bluefoxicy> bug filed.
<bluefoxicy> fabbione:  any ideas on the grub-install bug btw?
<bluefoxicy> fabbione:  grub-install hangs if you run it with /boot on xfs
<fabbione> known xfs problem
<fabbione> sometimes searching and reading docs will be helpful for you
<bluefoxicy> fabbione:  yes but what confuses me is
<bluefoxicy> I just run grub-install to prepare /boot/grub
<bluefoxicy> then kill it
<bluefoxicy> and run grub
<fabbione> did you read the documentation?
<bluefoxicy> "root (hd0,6)"  (or whatever partition is / with /boot on it) and "setup (hd0)" and it's good to go.
<fabbione> if so you wouldn't be confused
<bluefoxicy> no, not really
<bluefoxicy> do you have a link
<fabbione> it's in grub-install each time you attempt to run it
<bluefoxicy> um, grub-install doesn't give me output
<fabbione> that means you didn't even read the output from grub-install
<fabbione> it does
<bluefoxicy> Due to a bug in xfs_freeze, the following command might produce a segmentation
<bluefoxicy> fault when /boot/grub is not in an XFS filesystem. This error is harmless and
<bluefoxicy> can be ignored.
<bluefoxicy> fabbione:  not helpful.  *digs at command*
<fabbione> bbl
<bluefoxicy> oh come on
<bluefoxicy> you give me a load of crap and then run off
<bluefoxicy> so does anyone else know?
<fabbione> bluefoxicy: i need to go to the bathroom.. do you mind?
<bluefoxicy> oh fine
<fabbione> or should i send you to #ubuntu
<fabbione> ?
<fabbione> you decide
<bluefoxicy> just go
<bluefoxicy> i'm gonna sleep
<bluefoxicy> I still find it odd though that grub-install freezes but grub works perfectly
<bluefoxicy> more odd that some idiot wrote an xfs_freeze call into grub-install
<bluefoxicy> considering if /boot is on / the result is grub-install -> xfs_freeze -> access / -> xfs is frozen -> deadlock
<bluefoxicy> (happens during the ubuntu installation process if you try to install grub in said situation)
<Mithrandir> is there any way to extract the contents of a tmpfs in such a way that you can shove it into a file with ext[23]  or something?
<fabbione> uh?
<Mithrandir> I have a tmpfs unionfs mounted on top of another file system.
<fabbione> ok...
<Mithrandir> I'd like to pull all the files out of the tmpfs and put them somewhere (in an ext2 filesystem)
<fabbione> tar ?
<Mithrandir> how can I get the stuff which is just in the tmpfs?
<fabbione> ahhh
<fabbione> that way..
<Mithrandir> note the "unionfs" part. :-)
<fabbione> i don't think you can at all
<fabbione> or perhaps you can use timestamps?
<fabbione> see at what time you mount
<fabbione> and copy everything that has been modified since than?
<Mithrandir> ew.  I guess that'd be possible, though ugly.
<fabbione> i don't think you have any other choise
<Mithrandir> hmm, I think I can work around this.
<Mithrandir> it'll be slow, but work.
<fabbione> BenC: ping?
<BenC> fabbione: pong
<fabbione> hey BenC 
<fabbione> git pull rsync://rsync.kernel.org/pub/scm/linux/kernel/git/davem/ubuntu-niagara-2.6.git
<BenC> hey
<fabbione> it's almost there :)
<BenC> sweet
<fabbione> he is doing a test build
<BenC> dave rocks
<fabbione> i am working on a prebeta installer
<fabbione> http://vger.kernel.org/~davem/cgi-bin/blog.cgi/index.html
<fabbione> he does :)
<mjg59> BenC: Those acpi patches look ok?
<fabbione> BenC: he said to wait to pull.. but i am testing locally too...
<BenC> mjg59: just woke up, getting to them in a little bit
<mjg59> BenC: No problem
<BenC> [    9.389903]  Total of 32 processors activated (9895.93 BogoMIPS).
<BenC> gotta love that
<BenC> quad gige too
<fabbione> yeah
<fabbione> but there is a lot of tuning that needs to be done
<fabbione> look at the calibration delay loops per CPU and bogomips
<fabbione> some CPU's come up to 410 Bogo
<fabbione> other at 280
<BenC> fabbione: how did I get an email for upload of 9.24 that I did 4 months ago?
<fabbione> BenC: -ENOCLUE
<fabbione> ask Kinni or infinity?
<BenC> it was uploaded to launchpad, and aimed at breezy-updates
<BenC> and it used my gpg key :)
<Mithrandir> BenC: where did you see the squashfs 3.0 stuff?
<BenC> Mithrandir: no
<BenC> is it in?
* infinity senses that BenC missed a word in that question...
<BenC> yes, I did
<BenC> Mithrandir: it's in CVS
<BenC> :pserver:anonymous@cvs.sourceforge.net:/cvsroot/squashfs
<BenC> module is squashfs
<BenC> they may have a tarball, but I just grabbed CVS
<BenC> already tested booting the liveCD with v3 filesystem, so it should be good
<Mithrandir> they haven't released anything, so I'm a bit wary of just grabbing CVS.
<BenC> well, v2 is broken we know that, and v3 booted fine with no oopses, so I think the best bet is to move to v3
<BenC> Mithrandir: you can always repackage squashfs tools with a v2 and v3 mksquashfs
<mxpxpod> BenC: so, I've figured out that bcm43xx is causing syslog to go crazy
<BenC> mxpxpod: yeah, I've heard, I removed some debug output from ieee80211 in the next kernel upload
<BenC> Mithrandir: and then you could just use v3 for ppc
<mxpxpod> BenC: no, I mean that it's causing syslogd to spawn new processes
<BenC> mksquashfs == v2, mksquashfs3 == v3
<BenC> mxpxpod: oh, I don't see how that's possible
<mxpxpod> BenC: I don't either
<mxpxpod> BenC: but last night I had about 50 syslogd's running
<Mithrandir> BenC: true dat.
<mjg59> mxpxpod: If you're using our suspend script, it ought to be unloaded and reloaded over suspend
<mjg59> mxpxpod: Is that happening?
<mxpxpod> mjg59: which suspend script?
<mjg59> Oh, is this on PPC?
<mxpxpod> mjg59: yup
<mjg59> That's probably more complicated
<mxpxpod> BenC: and the syslogd's didn't spawn until I ifup'ed my ae
<mxpxpod> at first I thought it might be a daemon I was running that was doing it (apache, avahi, postgresql, etc.)... but I shut all those down and it still happened
<fabbione> BenC: do you think you have time to pull from Dave and test the resulting kernel on your e3k ?
<BenC> yeah
<fabbione> just to check if there are no "easy to spot" regression
<fabbione> i will do the same here as soon as i am done with a d-i image for hom
<fabbione> him
<BenC> mjg59: started a build with acpica patches un-reverted plus the two you sent me
<mjg59> BenC: Thanks
<zul> heylo
<zul> BenC: i should have some patches for you this weekend as well
<BenC> hopefully I'll be doing an upload later tonight
<zul> ok...
<fabbione> BenC: did you remember to pull from me?
<BenC> not yet, but I will
<fabbione> thanks
<zul> heh...bug #31698 is funny
<BenC> mjg59: kernel seems to boot fine, but I see a few of these
<BenC> [4294671.887000]  pnp: PnPACPI: unknown resource type 7
<BenC> [4294671.887000]  pnp: PnPACPI: METHOD_NAME__CRS failure for PNP0c01
<mjg59> BenC: Yeah. I think it's basically harmless, but I'll get you a patch for that
<BenC> ok
<crimsun> mjg59: belated pong
<mjg59> crimsun: Hi - you know alsa magic, right?
<crimsun> mjg59: depends on the card(s)
<crimsun> mjg59: which issue(s)?
<mjg59> crimsun: i810
<mjg59> crimsun: On an HP 6220 laptop - after suspend, the ac97 registers are identical but no sound comes out of the speakers
<mjg59> Headphones work, though
<mjg59> It has a headphone sense switch, but I made sure that the state of that was being restored
<mjg59> It's an ad19something codec
<crimsun> ah, that's the exact opposite of the ThinkPad issue. I've picked a PM support patch and will test locally.
<crimsun> (adds PM support to intel8x0)
<mjg59> Cool. 
<mjg59> The Thinkpad one doesn't seem to apply to all Thinkpads - my X40 is fine over suspend/resume
<mjg59> Have you got a patch I can test?
<mjg59> (I have the hardware)
<crimsun> not yet, let me get a url so you can look at the upstream changes
<mjg59> Thanks
<crimsun> mjg59: (sorry, got called away) http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-kernel/pci/intel8x0.c?r1=1.228&r2=1.229
<crimsun> (back to conference)
#ubuntu-kernel 2006-02-23
<zul> heylo
<mjg59> crimsun: Hm. Didn't apply cleanly, so I pulled in the latest dev release (which seems to incorporate it) - same problem
<fabbione> hey BenC 
<fabbione> BenC: i added the sparc abi files to git.
<fabbione> just pull when you are ready
<somervil_> ubuntu kernels 2.6.15-15, 2.6.15-14 are both producing "Bug: software lockup detected on CPU#0" in the midst of starting "Enterprise Volume Management" on my Inspiron 8600 (Pentium M)... Known issue ?
<zul> open a bug
<somervil_> Launchpad, or upstream ?
<zul> launchpad
<somervil_> k
<somervil_> thanks
<dilinger> fabbione: yo
<fabbione> hi dilinger 
<fabbione> BenC: david said to wait a sec to merge. the last fix i did was not good 
<fabbione> but he is already fixing it :)
<fabbione> anyway i am lagging to watch a movie
<zul> star trek movie is on tv
<BenC> which one?
<zul> the one with spocks brother
<BenC> spocks brother? I don't recall that one
<zul> where they try to find god
<zul> star trek v
<BenC> ah, that's right, I remember that one
<BenC> <voice type="kirk">Is THIS....God!?<voice>
<BenC> sweet, upgraded my sat connection so it's harder for me to hit the fair-access-policy restriction
<BenC> extra $100/month, but it's worth it
<zul> cool
#ubuntu-kernel 2006-02-24
<crimsun> mjg59: ok, thanks
<mjg59> crimsun: So it's not PCI configuration space, and it's not an AC97 register issue, so...
<doko> BenC: is the mISDN update missing in the last kernel upload?
<BenC> yeah, I needed to get some important fixes out, and mISDN merge isn't trivial
<psusi> I'm trying to learn git since it's used by the kernel... am I correct in understanding that it stores copies of every version of a given file, rather than diffs?  so it's going to use a LOT of space?
<infinity> BenC: Around?
<infinity>   AS [x]    drivers/macintosh/mol/_actions.o
<infinity> /bin/sh: m4: command not found
<infinity> make[5] : *** [drivers/macintosh/mol/_actions.o]  Error 127
<infinity> BenC: From the powerpc kernel build --^
<Mithrandir> hi infinity 
<fabbione> doh
<Lathiat> hrm
<Lathiat> the kernel is being built with gcc4 now?
<makx> default since long afaik
<Lathiat> makx: ah ok
<Lathiat> additionally, anyone know off hand if there is a reason IPVS is not compiled in the kernel
<mjg59> Lathiat: Any joy with your battery?
<Lathiat> mjg59: havent tried yet
<Lathiat> you said i needed git?
<mjg59> Yeah
<Lathiat> i'll do it tomorrow night
<Lathiat> dont have time tonight
<Lathiat> unles its in a daily build in the topic?
<fabbione> Feb 19 15:18:53 gordian kernel: [4294677.139000]      ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:DMA
<fabbione> Feb 19 15:18:53 gordian kernel: [4294677.139000]      ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:DMA, hdd:DMA
<fabbione> GO IDE-GENERIC!
<fabbione> BenC: ok.. now i got DMA/32bit I/O and unmasked irq
<fabbione> gonna check the system status on load now
<fabbione> yup that was it :)
* fabbione dances around like hell
<fabbione> i can finally move the mouse again when doing apt-get install
<BenC> fabbione: so it was ide-generic?
<fabbione> so it seems
<fabbione> now.. i would like to have a word with Scott
<BenC> yeah, that is definitely a udev issue, probably the same one I see in another bug report
<BenC> I think udev has a well disguised race or ordering problem
<fabbione> probably..
<fabbione> udev is a problem
<BenC> is there a cmdline util that can trunc() a file?
<BenC> just don't want to dd 4gigs to get rid of 900Megs on a cd image
<Mithrandir> :>$file ?
<BenC> I want to trunc it to 4gigs, not 0 :P
<BenC> Mithrandir: any progress with mksquashfs3?
<Mithrandir> use dd if=/dev/zero of=file bs=1G seek=4 count=0 ?
<Mithrandir> no, haven't had time, I was busy with random other crap on friday
<BenC> Mithrandir: sweet, that command worked perfect
<BenC> thanks
<Mithrandir> it's a sparse file, but I assumed that was what you wanted.
<visik7> I can't understand how the ubuntu kernel works, it's heavily different from a vanilla kernel
<visik7> anyone can explain me it ?
<mjg59> visik7: What do you mean by "Heavily different"?
<visik7> for example it check if gcc is 3.4
<visik7> vanilla kernels doesn't do it
<mjg59> Sorry, what checks if gcc is 3.4?
<visik7> make 
<mjg59> When?
<visik7> wait a moment
<visik7> removed kernel tree for erro
<visik7> I need some time to redownload it
<visik7> here I'm
<visik7> http://pastebin.com/562971
<visik7> here
<visik7> says gcc-3.4 not found
<visik7> why check if gcc-3.4 is present ?
<visik7> a 2.6.15.4 works perfectly with gcc 4
<visik7> and make menuconfig of this source is quite different from a 2.6.12 vanilla (I know that there are patches)  
<visik7> I know that there are patches but I don't understand why networking options is inside device drivers -> network support like old 2.4 kernels 
<visik7> and why there are so many way to get kernel source ?
<visik7> linux-source-2.6.12
<visik7> linux-tree-2.6.12-10.28
<visik7> apt-get source linux-image-2.6.12-10...
<visik7> things aren't so clear
<mjg59> Because 2.6.12 didn't work properly with gcc 4
<visik7> your or the vanilla ?
<mjg59> Any
<mjg59> Not on all the architectures we support
<visik7> oh
<visik7> ok
<mjg59> 2.6.15 is built with gcc 4
<rysk> hello,
<rysk> I wonder what's that chan is for ? I mean what's mean "ubuntu kernel discussion ONLY". If I'm coding a driver under ubuntu (while it's just a linux driver anyway) is that part of the subject ?
<mjg59> rysk: It's more for development of the Ubuntu kernel rather than kernel development under Ubuntu (if you see what I mean)
<mjg59> No harm in asking here, though, the worst that can happen is that you'll be ignored :)
<rysk> ok :) I'm just trying to get my graphical tablet working. Since it's recognized as an usb mouse, the driver i've made don't get to handle the tablet unless i'm forcefully unload the usbhid module. Well if anyone knows enough to tell me what to do i will be pleased to hear it :)
<mjg59> Hm. It identifies as a mouse?
<rysk> yeah, that's actually quite strange because the data sent by the tablet is not at the same format of the ones sent by a mouse
<rysk> but the hid interface protocol is set to 2 (mouse)
<mjg59> Sounds like the hardware is broken...
<mjg59> Might be possible to add a quirk to the mouse driver to refuse to bind to it
<rysk> well actually i was more thinking of detaching the mouse driver from it
<mjg59> If the mouse driver can't drive it, it's better for it never to bind it
<rysk> The hardware isn't broken. I guess it's just the vendor who said "Oh, yes, we use it like a mouse so it's a mouse !"
<rysk> well that's true
<mjg59> Stuff that claims to be a mouse ought to speak the mouse protocol
<rysk> actually it implements a very close protocol
<rysk> but since it absolute position and not relative position and it's have a pressure intensity, it's just put more info in the message
<rysk> Also that's fun because it doesn't reply to any input report asking. It's just said "TABLET"
<rysk> I bet it speaks the mouse protocol for the version with a magnetic mouse
<visik7> how can I compile only a module of the kernel without rerun all make modules that it's huge ?
<mjg59> visik7: With 2.6.12? You can't.
<rysk> make module.ko ?
<mjg59> With newer kernels, just make patch/to/module.ko
<visik7> :(
<visik7> ok thanks
<mjg59> rysk: Take a look at hid_blacklist in hid-core.c - best bet is probably just to add it to there, and then bind it with your driver
<rysk> ok thanks
<mjg59> You'll need to send that patch to LKML to get it added
<rysk> yes, I need to make my tablet works fine before that :)
<zul> wtf??!
<zul> canada is down 2-0 in olympic hockey
<damned|home> hi all. i'm trying to recompile dapper (2.6.15-15) kernel with standart config from source and get a error. am i able to get consultation here?
#ubuntu-kernel 2006-02-25
<MacMon> hello
<bluefoxicy> https://launchpad.net/distros/ubuntu/+source/linux-meta/+bug/32072
<bluefoxicy> It keeps fucking up like that from time to time.  no, I don't have extra info.
<ubijtsa> moin moin
<ubijtsa> Keybuk: I have just raised a defect on Dapper Flight4 - #32097, you may want to take a quick look when you have time..
<Keybuk> ubijtsa: you're probably booting the wrong kernel
<ubijtsa> Keybuk: Hmm..
<ubijtsa> Keybuk: there is only one kernel image + initrd in 'install/netboot/ubuntu-installer/i386/' on the CD
<Keybuk> *shrug* not my area of expertise I'm afraid
<ubijtsa> Keybuk: oh, sorry to have bothered you then :)
<purpleidea> is it fair game to ask questions about how to get an smp kernel working on a new duo core problem, or should i leave those questions to a different forum?
<mjg59> purpleidea: What doesn't work?
<purpleidea> seems a lot of people are having a problem with this laptop, just came out, inspiron 9400; originally would freeze just before gdm loads, but after x was loaded, now doesn't even boot too far past grub (since an upgrade)
<purpleidea> i have more comprehensive details if you want.
<purpleidea> or if this isn't the place, please tell me where i can figure it out, i've been looking everywhere, and a lot of people have similar problems, as per hardware wiki, etc.
<mjg59> Well, it certainly sounds like a bug
<mjg59> What are you trying to boot?
<purpleidea> absolutely. especially since the smp kernel "just works" right after install in fedora4
<mjg59> Is this Breezy or Dapper?
<purpleidea> originally breezy did the up until gdm thing, and dapper now is the stops right after grub. it says: can't find /dev/sda5 although it's there and the non smp boots
<mjg59> Hmm. We don't ship non-SMP kernels, do we?
<mjg59> Or do you mean booting with nosmp?
<purpleidea> nope, you seem to ship non smp, because it installed as the default, before the internet was even up
<Mithrandir> that changes in dapper
<purpleidea> i had to get the smp one with synaptic, which isn't working :(
<Mithrandir> dapper doesn't have non-smp kernels
<mjg59> We ship smp kernels only now
<mjg59> Then they get rewritten into non-smp ones on single processor systems
<purpleidea> well that's good then. from what i understand intel will eventually mostly stop making single core anyways... esp. since a quad is expected. in any case..
<mjg59> So does a dapper install CD boot?
<purpleidea> i installed originally off of a breezy cd, and upgraded breezy through synaptic from a dapper f3 cd. i haven't actually run the installer if thats what you're asking
<purpleidea> presently downloading flight4 in the odd chance anything will work better.
<mjg59> Ok
<fabbione> BenC: ping?
<BenC> fabbione: pong
<fabbione> hey dude
<BenC> what's up?
<fabbione> BenC: do you plan a 17.23 soon?
<fabbione> or 16.23 and later 17.24?
<BenC> 16.23 today
<fabbione> ok
<BenC> .24 in a few days
<fabbione> i am building .22 right now if you want to wait for the abi files
<fabbione> up to you
<BenC> for sparc?
<fabbione> yes
<BenC> ok, I can do that
<fabbione> *AFTER* .23 please pull from my branch on people
<zul> heylo
<chmj> dir
<chmj> dir
<chmj> dir
<chmj> oops, sorry 
<zul> i think you meant to say ls
<chmj> something like that, on a diff console too 
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-16.23 uploaded (PPC FTBFS fixed) | Daily Diet of Destruction: http://people.ubuntu.com/~bcollins/kernels-daily/
<Mithrandir> BenC: what's the reason for kprobes not being enabled?
<BenC> what is it?
<Mithrandir> http://www.redhat.com/magazine/005mar05/features/kprobes/ has some info on it
<Mithrandir> seems useful for doing instrumentation.
<cjb> Mithrandir: Overhead?
<BenC> Mithrandir: interesting, but is it useful to users?
<fabbione> BenC: are you aware of any problem with tg3 driver on 4xGE broadcom cards on SUN v210 ?
<fabbione> BenC: with .12 it seems broken
<fabbione> testing .15 now
<BenC> not that I know of
<zul> wohoo...next week nine inch nails concert..
<fabbione> BenC: could you be so kind to do a fast search for me?
<fabbione> while i keep going with .15?
<BenC> only thing I see is a problem with Debian when they removed the tg3 firmware
<fabbione> we do have the firware
<BenC> right, which should mean that there is no problem :)
<BenC> there are some workarounds for sun in tg3
<fabbione> such as?
<BenC> maybe look at enabling disabling for this particular hardware
<BenC> whether or not to call into eeprom
<BenC> is the device coming up, but just not transfering packets, or is there some failure message?
<fabbione> it comes up
<fabbione> i can netboot
<fabbione> so there is network wirewise 
<fabbione> i can't get packets in/out after i do ifup the iface
<BenC> the ordering of the devices in linux may not be the same as with OBP, so make sure you are using the right one
<fabbione> we did try all of them
<fabbione> moving the cable from eth0 to eth3
<BenC> any of them show link status?
<fabbione> yes the 2 i configured
<BenC> so they show "LInk at 1000Mbs Full Duplex" or whatever?
<fabbione> yes
<fabbione> that's OBP tho
<BenC> and connecting/disconnecting the cable causes link up/down to occur?
<fabbione> not to the kernel
<BenC> no, I mean in Linux
<fabbione> i saw only one link down/up
<fabbione> even if elmo did plug/8unplug a lot
<BenC> bring all the interfaces up, then connect/disconnect the cable and see what happens
<fabbione> eh
<fabbione> if elmo is still at the DC
<fabbione> let me see
<fabbione> i can only see one module param for tg3.. that's debugging
<fabbione> i wonder if we are using #if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE)
<fabbione> that might change something
<Pugget> ciao-  would anyone be willing to help a ubuntu (and debian) newbie compile the new 2.6.15 unbuntu kernel from ftp://ftp.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.15 ?  everyting compiles and then dpkg-gencontrol bombs with "error: package kernel-headers-2.6.15.4-ubuntu1 not in control info"
<fabbione> BenC: david says that it might be a known problem.. he is already fixing it :)
<Pugget> sweet :-)
<fabbione> Pugget: sweet? 
<Pugget> fabbione: oops, mis-interpreted the last message as if it were in reponse to my question, nm
<fabbione> Pugget: no.
<BenC> Pugget: apt-get install linux-source-2.6.15
<BenC> don't use the tarball from there
<fabbione> after almost 16 hours in the day i don't have time for that :)
<BenC> fabbione: BTW, my last kernel upload to fix ppc ftbfs was a little pointless since the ppc buildd's are down :/
<fabbione> how so?
<BenC> according to Kinnison, one has dead disk, and the other just isn't responding
<fabbione> SCORE
<Pugget> BenC: what should I stick in my sources.list so I have that package?
<fabbione> and i am booting slowlaris :/
<BenC> Pugget: uh, the default deb lines
<BenC> it's in dapper main
<Pugget> BenC: okay
<BenC> and if you are trying to do this on breezy, and install it on breezy, you are asking for trouble
<Pugget> BenC: figured as much - I just typed "upgrade dapper" into google...
<zul> arrgh....stupid totem..
<trappist> does 2.6.15-16.23 (or maybe one before it that I missed) fix the 1G/3G split?
<fabbione> trappist: what about reading the changelog? :)
<zul> fabbione: you are so smart..
<fabbione> i know :)
<trappist> there it is :)  nicely worded too, with a reference to the problem that exposed the issue for me
<BenC> changelogs are useful that way
#ubuntu-kernel 2006-02-26
<zul> heylo
<Mithrandir> BenC: (re kprobe) I was pondering using it for readahead measurements.
<mjg59> BenC: How much does enabling EFI in the kernel cost us?
* lamont wonders if he can get away with a "here are the hppa changes that make sense" megapatch
#ubuntu-kernel 2007-02-19
<Kano64> hi, as ndiswrapper 1.30 is too old now, how about using 1.37? 1.30 makes the system unbootable as soon as you installed an usb wlan driver with autoloading
<Kano64> http://kanotix.com/files/kernel/kernel-update-pack-noide/source/ndiswrapper-1.37-update.patch
<Kano64> userspace tools are in sid
<Kano64> btw. git does not compile
<Kano64> bye
<ajmitch> more drive by 'bugreports'
<kylem> he's really quite irritating.
<ajmitch> yes, I've seen him a few times in -devel
<zul_> i think thats the third time he's done it
<zul> gah...i just love it when my mailbox is full of junk
<zul> heylo
<Mithrandir> zul: so, I'm looking at binary NEW for xen-image-2.6.19
<Mithrandir> and I see stuff like:
<Mithrandir> lrwxrwxrwx root/root         0 2007-02-18 02:10:33 ./lib/modules/2.6.19-4-generic-amd64/source -> /build/buildd/xen-source-2.6.19/debian/build/install-generic-amd64
<infinity> Guess that answers that...
* infinity grins slyly at Mithrandir.
<Mithrandir> somehow, I both doubt you ship that directory and hope you don't.
<zul> ill fix it tonight
<Mithrandir> I'll reject the binaries for now, then.
<zul> thanks..
<Opermaxx> Hallo! Wei jemand mit welcher gcc-Version der Kernel fr Ubuntu 6.10 kompiliert wurde?
<lifeless> hi
<lifeless> I dont speak german sorry, perhaps you can repeat in english ?
<Opermaxx> Hi! Does anyone know with what gcc-version the kernel of Ubuntu 6.10 was compiled?
<lifeless> the the build deps show it just wanting gcc
<lifeless> so probably the default -4.0 I think in 6.10
<Opermaxx> but the wiki to my WLAN-Card says I need gcc-3.4; why is that?
<lifeless> I dont know
<lifeless> have you asked them ? :)
<Opermaxx> no, but it won't compile otherwise
<pkl_> normally when a gcc requirement is given, the reason for is also given...  No other info provided?  A bit naff.
<pkl_> what's the compiler output?  There are a couple of bugs in gcc 4.x which pefectly valid C code can hit.  Maybe this is the reason.
<Opermaxx> pkl_: it just says I need the gcc-3.4 because the Ubuntu 6.06 Kernel was compiled with that one
<pkl_> You say it won't compile otherwise.  Have you hit compiler errors or warnings trying to compile it with a gcc other than 3.4?
<Opermaxx> pkl_: well, it just gives some errors and says it won't compile; here is the wiki: https://help.ubuntu.com/community/WifiDocs/Device/DWL-G122_(Rev_B)?highlight=%28WifiDocs%2FDevice%29
<brentol> http://legacy.macnn.com/articles/07/02/15/ubuntu.axes.ppc.support/
<Opermaxx> brentol: talking to me?
<pkl_> Opermaxx: it doesn't actually say you _need_ gcc-3.4.  That's just the version used in the apt-get example.  My guess is the driver doesn't compile on linux 2.6.17.  Without the compile output, however, it is impossible to say.
<Opermaxx> pkl_: ok; but with the gcc-4.x it doesn't
<pkl_> What I'm saying is the failure to build is probably nothing to do with the compiler version, more to do with the _kernel_ version.
<Opermaxx> pkl_: but the newer package need 2.6.17 or higher
<zul> aieee...hes at it again
#ubuntu-kernel 2007-02-20
<zul> can someone ask the guy to updating all of these bug reports to stop
<kylem> who's this?
<zul> forget his name
<zul> caravena
<mjg59> zul: Done
<thotz> this bug should be set to HIGH: https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/84964
<thotz> there are more such bugs like https://launchpad.net/ubuntu/+source/casper/+bug/86255
<thotz> now in: https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/86255
<thotz> I'm not sure where the problem is, but it has something to do with jmicron
<Mithrandir> BenC: can you please, please, please, please get 43531 fixed soon?  It should be absolutely trivial.
<BenC> Mithrandir: just requires re-uploading every boot loader we have :P
<Mithrandir> BenC: why would it do that?  And, if that's needed then do that.
<BenC> I had forgotten about it. I'll get to it today
<Mithrandir> cheers.
<BenC> Mithrandir: Because the fix is to add a Provides boot-loader to every one so the kernel can depend on that
<Mithrandir> I considered raising it to critical or something to get your attention, but well, that's slightly excessive
<BenC> and then creating a no-boot-loader meta
<Mithrandir> why not just make nobootloader produce a deb and not just a udeb?
<BenC> I could do that for the latter I guess
<cjwatson> it isn't really anything to do with the nobootloader udeb, and the naming would be wacky
<cjwatson> but I guess
<BenC> I've been procrastinating on it because I'm not sure I'm going to like the outcome of it...worried about deps causing all sorts of unexpected weirdness
<BenC> cjwatson: Should I create a new meta package, or use the nobootloader udeb->deb approach?
<cjwatson> up to you, I was just sticking my oar in :)
<BenC> I can add a no-boot-loader to linux-meta easily enough
<cjwatson> actually I'd rather a new metapackage so that at some point in the future nobootloader can be synced again
<BenC> ok
<Mithrandir> BenC: when do you actually mark bugs as fix committed?  There's a 7-8 bugs milestoned for herd 4 which are fix committed and I am wondering if I can consider those fixed or if I should bring them forward.
<BenC> Mithrandir: Most likely fix released
<BenC> I'm a little slow still remarking things to released
<BenC> Mithrandir: marked all the ones that should be now
<Mithrandir> BenC: thanks.
<kylem> morning.
* Nafallo ponders when one of the missing drivers might be added-
<Nafallo> s/-/./
<Nafallo> qc-usb fwiw
<jbailey> Will Feisty grow things to autodetect p4-clockmod/acpi-cpufreq/etc?
<mjg59> You never want p4-clockmod
<mjg59> acpi-cpufreq ought to already be autoloaded when appropriate, I think
<jbailey> Hmm.  Last time I checked, I think my toshiba works with p4-clockmod, but not acpi-cpufreq.
<jbailey> mdy (our ISV guy) just upgraded to feisty, but we had to add acpi-cpufreq to /etc/modules.
<mjg59> No, you *really* never want p4-clockmod
<mjg59> It doesn't do voltage scaling
<mjg59> Ah
<mjg59> sed s/acpi/acpi-cpufreq/ -i /etc/init.d/powernowd
<mjg59> The module name has changed
<mjg59> Ought to fix that
<jbailey> Do all the chips support voltage scaling?
<jbailey> I thoguht that's why p4-clockmod was still around, for the chips that didn't.
<mjg59> Right, but there's no point in reducing the clock if you're not dropping the voltage
<JanC> mjg59: except if you want to use more power because everything takes longer?  :)
#ubuntu-kernel 2007-02-21
* poningru hugs BenC
<poningru> thanks for the sata_promise thing
<poningru> it works :D
<BenC> did I do something? :)
<BenC> Ah, cool
<poningru> :D
<Nafallo> BenC: is qc-usb trouble with the new kernel? or should I look in something other than ubuntu/ for it?
<BenC> Nafallo: It's one of those things that wasn't working when I originally moved to the 2.6.19/20 tree's, so it wasn't included
<BenC> maybe there's an update for it now
<Nafallo> thought so.
* Nafallo googles :-)
<Nafallo> looks like mandriva has it in there 2.6.20
<Nafallo> gaah. to tired to spell :-P
<Nafallo> their ofcourse
<Nafallo> http://rpmfind.net/linux/RPM/mandriva/devel/cooker/i586/media/contrib/release/kernel-tmb-source-2.6.20-2mdv-1-1mdv2007.1.i586.html
<zul_> patch would probably be better
<Nafallo> oki :-)
<Nafallo> I'll try to work on it then :-)
<H264> Hi
<H264> anyone awake?
<H264> hi
<Nafallo> BenC: qc-usb works. just need to be added again. I just apt-get sourced qc-usb and compiled against our current headers
<fdoving> are there plans to fix bcm43xx before feisty release? 
<Nafallo> yes
<Nafallo> AFAIK
<fdoving> good thing. i've confirmed bug 85404
<zul> BenC: its at 11 right?
<BenC> zul: Yeah
<zul> yippe skippe
<BenC> Nafallo: Thanks
<zul> hmmm...Power window kills 2 year old
<secureboot_> when doing a build, how do I just build for 386, not everything?  I'm using 2.6.20-source from Fiesty
<zul> secureboot_: check the wiki
<secureboot_> zul: yeah, i'm doing that now - the flavours option, i presume?
<zul> yep
<secureboot_> is there a good way to see all possible flavours?
<zul> check the debian/config but the flavours are generic,server,etc
<secureboot_> zul: ah - i saw k7 as an example, and thought it was an arch designation
<zul> its not
<zul> not in fiesty
<zul> but this channel is not for support
<zul> BenC: the xen paravirt stuff is in mm tree fyi
<BenC> zul: See if it applies against our tree?
<zul> not yet
<zul> but i can do it sometime today
<crimsun> BenC: at your convenience, please pull in the pending HDA fixes I've emailed to your @ubuntu.com. There are also four pending patches sent Fri Feb 2 to kernel-team@ .
<BenC> crimsun: The ones for kernel team are feisty?
<BenC> crimsun: Note, I've pulled all the ones you sent directly to me
<crimsun> yes.
<BenC> ok, will do
<crimsun> BenC: thanks. I believe Kyle asked me about them, so I resumed noting directly in the changesets. :)
<kylem> morning.
<Nafallo> afternoon kylem :-)
<kylem> evening.
<crimsun> BenC: apologies for pinging again, but ben.collins@u.c is preferred, correct? I don't see the ac'97, sigmatel or conexant ones I've sent there (at least according to gitweb via hera) on Feb 13, 14 & 17
<BenC> crimsun: Try now, I just pushed my tree
<crimsun> ok, thanks! (I probably need to wait a tick or two for the sync)
<BenC> mjg59: ping, do you have time for kernel meeting in #ubuntu-meeting?
<mjg59> BenC: Afraid not
<BenC> mjg59: Any quick input on d80211?
<mjg59> BenC: I think we ought to keep it, but possibly not as default
<BenC> mjg59: Ok, sorry you couldn't make it
<BenC> mjg59: Would you prefer I take you off the invite list, or are these meetings something you can make every so often?
<mjg59> Daytime UTC is generally hard for me
<crimsun> BenC: as a heads-up, my time is becoming more limited, but I'm working with Toby Smithe and Luke Yelavich to step in
<crimsun> (they're already part of the LP ubuntu-audio team)
<BenC> crimsun: Thanks for the info
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-8.14 Uploaded - Things are getting solid now. Use it, but there are still a few missing modules. | BUG STATUS (2.6.20): 263 Open, 122 Unconfirmed, 233 Unassigned
<Nafallo> :-)
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-8.14 Uploaded - Things are getting solid now. Use it, but there are still a few missing modules. | BUG STATUS (2.6.20): 252 Open, 84 Unconfirmed, 169 Unassigned
* BenC does his bit for the bug list today
<kylem> we need to figure out how to evict lowlatency from the tree... it's kind of... annoying when doing a full build...
<zul> but the number went up :)
<jdong> if I would like to ask for new fglrx in Feisty, would a UVF be necessary?
#ubuntu-kernel 2007-02-22
<tepsipakki> hi, is someone awake?-)
<tepsipakki> I'm doing the X11R7.2 merge, and someone pointed out that the drm-modules in kernel need an update
<tepsipakki> https://beta.launchpad.net/ubuntu/+source/xorg/+bug/84731
<tepsipakki> look at the latest entries
<crimsun> yes, I verified as much about two weeks ago when I was building against git
<crimsun> it was /really/ fun rebuilding the entire stack
<tepsipakki> :/
<tepsipakki> 03:46 < gravity> Urgh... the intel driver requires pieces of the server source to build now. This is going to get ugly.
<tepsipakki> that from #debian-x last night
<crimsun> I'll peek in later, need to sleep a couple hours now
<tepsipakki> heh
<Mithrandir> aiui, those bits would get dragged in automatically in newer intel driver releases.
<tepsipakki> I'm having problems with Thinkpad X60s shutting down the display when changing brightness. The workaround is to blacklist video.o, so this is a kernel-issue?
<tepsipakki> http://www.mail-archive.com/ibm-acpi-devel@lists.sourceforge.net/msg00092.html
<pkl_> tepsipakki: if you have to disable a kernel module to make it work correctly, then it is a kernel issue, yes.
<tepsipakki> pkl_: yeah, I'll file a bug
<BenC> technically speaking, that may also be an ACPI issue :)
<BenC> IOW, a BIOS bug
<tepsipakki> userspace?
<BenC> BIOS
<BenC> like your computer is broken because it doesn't use ACPI correctly
<tepsipakki> I knew it
<BenC> we can blacklist your computer from the video module though
<BenC> so file the bug, and attach the output of "sudo dmidecode"
<tepsipakki> I just filed it, will attach that to it
<zul_> heylo
<tepsipakki> BenC: bug 87028
<tepsipakki> hm
<tepsipakki> anyway, dmidecode output attached
<BenC> tepsipakki: thanks
<zdzichuBG> hi guys
<zdzichuBG> I believe you won't backport dyntics to Feisty kernel?
<BenC> zdzichuBG: that's correct
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-8.14 Uploaded - Things are getting solid now. Use it, but there are still a few missing modules. | BUG STATUS (2.6.20): 263 Open, 86 Unconfirmed, 172 Unassigned
<abogani> Mithrandir: Can i disturb you for one question?
<Mithrandir> abogani: sure
<abogani> What my Spec (https://blueprints.launchpad.net/ubuntu/+spec/realtime) lacks to achieve its mission (== inclusion in the Universe repositary)?
<seb128> hi
<Mithrandir> abogani: the kernel package would have to be done as a patch to linux-source and not ship a complete copy of the linux kernel source.
<seb128> I've a problem similar to bug #76489 with a RTL-8029 card, do you guys prefer a new bug because that's not the same card model?
<abogani> Mithrandir: kernel package is only a comfort for testers
<Mithrandir> abogani: well, it's what would end up in universe.
<seb128> pkl_: ping? about the bug I just mentioned, you marked it Fix Commited
<pkl_> seb128: yes a new bug would be prefered, because it will require a separate workaround.
<seb128> ok
<seb128> thank you
<seb128> what informations do you need?
<seb128> lspci output?
<abogani> Mithrandir: As you can see from https://wiki.ubuntu.com/RealTime now i release also a patch (obtained with a git-diff).
<pkl_> seb128: yes, as much information as you can give  :-) dmesg, and lspci definately.
<seb128> pkl_: bug #87078, do you need something else?
<pkl_> seb128: I'll have a look into the bug.  If I need more info I'll ask...
<seb128> ok, thank you
<zul> BenC: where does the ubuntu/ms/memstick.c come from?
<BenC> zul: Some evil place...I don't think it works though
<zdzichuBG> :( too bad, I think my laptop would love dynticks
<zul> ah ok because its missing a header file 
<zul> #86725
<ScottK> I recently reported a wireless bug (bug #86742).  I wanted to check in and see if it's complete so it'll be useful when someone gets to it.
<fdoving> .. what can make ksoftirqd/0 use ~90% cpu?.. anyone seen that before?
<BenC> fdoving: Usually some kernel task...could be anything, since it's a generic drop for some core tasks (network bottom halves I believe, etc)
<fdoving> ok. could it be related to the broken bcm43xx driver i try to use?
<BenC> could be
<fdoving> thanks, i'll keep that in mind and see if i encounter it again without the driver.
<BenC> fixed up bcm43xx coming tonight
<maks_> bcm43xx can be fixed?
<BenC> maks_: Withing reason :)
<zul> heh the mad bug reporter is at it again
<Nafallo> haha
<Mithrandir> so, I have an external USB-powered hard drive which seems to fail if I move lots of data to or from it.  Is there anything I can twiddle in the kernel to either give it more power (I guess that's impossible) or limit the transfer speed somehow?
<BenC> Mithrandir: there's some stuff you can set for usb-storage, they might help
<BenC> Mithrandir: does the hd have the ability to connect to external power so you can test your theory?
<Mithrandir> BenC: no, it doesn't.  It also seems to be happy in some cases, typically after being plugged in, unplugged a few times..
<Mithrandir> I have the same problem from multiple machines (two amd64s, one x40 laptop), so I suspect it's not just a dodgy usb controller.
<BenC> Mithrandir: do you have any other usb-storage devices to compare?
<BenC> ah, ok
<Mithrandir> I have another usb disk which has some of the same problems; my media player is fine (but that's solid state and just charges off USB)
<Mithrandir> I guess it could be that the disk is so shit it ends up overrunning its buffer somehow and then getting into a cough.
<Mithrandir> it typically looks like:
<Mithrandir> 273764.964000]  sd 1:0:0:0: SCSI error: return code = 0x00050000
<Mithrandir> [273764.964000]  end_request: I/O error, dev sdb, sector 4128
<Mithrandir> [275435.140000]  end_request: I/O error, dev sda, sector 202664311
<Mithrandir> and then Buffer I/O error and "lost page write" for a little while before ext3 abrts the journal and the fs is remounted r/o
<zul> maybe it needs an entry in the unusual_devs.h 
<BenC> Mithrandir: Are you sure the drive isn't going bad?
<BenC> Failed sector reads usually mean that..I would have expected usb-storage weirdness to cause a timeout rather than sector errors
<BenC> the return code is usually from the device itself
<Mithrandir> BenC: I haven't badblocked it, so no, I'm not sure
<Mithrandir> it also seems to refuse to talk SMART with my machine.
<Mithrandir> trying a badblocks test now.
<zul> later..
<JanC> maybe you can get the disk out of the case and put it in a PC?
<Mithrandir> I'd prefer not to void the warranty on a disk only a couple of months old. :-)
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-8.14 Uploaded - Things are getting solid now. Use it, but there are still a few missing modules. | BUG STATUS (2.6.20): 269 Open, 75 Unconfirmed, 168 Unassigned
#ubuntu-kernel 2007-02-23
<bluffer_> i had a query yesterday in #ubuntu but the irc logs say no one has replied is some on up now and have a few minutes to spare
<bluffer_> lamont 
<JaccoH> anyone using the BNX2 module? im referring to bugreport 86965.
<jbailey> BenC: Up for another round of talking about kernel modules shipped with packages? =)
<BenC> jbailey: shortly
<jbailey> BenC: All good.  Ping when ready.
* jbailey wanders to his corner of the boxing ring for some stretches.
<BenC> jbailey: Ok
<JaccoH> you box with kernel modules? :)
<jbailey> JaccoH: Sure.  What's a scarier weapon than, say, ACPI? =)
<JaccoH> you can like beat up the bnx2 module if you like :) 
<JaccoH> piece o #$3 :)
<JaccoH> mm anyway
<zul> JaccoH: can you attach lspci -vvv to that bug as well?
<JaccoH> besides the other lspci output you mean?
<zul> yep
<JaccoH> sure 
<zul> ill have a look when i can
* JaccoH walks to the server room.. goes through the pre flight sequency.. cover his ears.. man this thing is noisy :)
<JaccoH> its pretty hard to get this info of of it .. the network is pretty much crappy :)
<JaccoH> there you go zul
<zul> thanks..
<JaccoH> i first had to unset bonding.. cause I cannot work around the issue with bonding enabled
<JaccoH> anyway .. speak to you all later .. getting myself some food :)
<zul> BenC: ping
<BenC> zul: yo
<zul> 2.6.20 xen tree should be out today hopefully
<BenC> nice
<zul> gives me the weekend to play with it/package it
<zul> BenC: it crashes from time to time so I dont know if we want to put it in the archive...
<jbailey> BenC: Is "shortly" up yet? =)
<BenC> jbailey: Just about :)
<jbailey> Just making sure.
* jbailey stands in his corner doing callesthenics(sp?)
<zul> heh getting your workout today arent you?
<jbailey> BenC: *poke*
<BenC> jbailey: Hey, I'm having a hard time staying at the keyboard...might be best over the weekend
<jbailey> BenC: I'm conscious of the fact that at any item, I'm going on leave for 5 weeks.
<jbailey> BenC: So I don't mind defering, but if I disappear, we'll need to get this sorted out anyway so that we can get the various commercial packages done that we're committing to.
<BenC> ok
<zul> BenC: how long are we waiting for a response from the user these days?
<BenC> zul: I'm generally giving 30-60 days depending
<BenC> if there's no response for the first inquiry, 30 days
<BenC> if they've responded and then stopped, I give 60
<BenC> but if there's enough info there, then I wont close it
<zul> cool thanks
<mgalvin> quick question... there are mactel kernel patches available at:
<mgalvin> http://mactel-linux.svn.sourceforge.net/viewvc/mactel-linux/trunk/kernel/mactel-patches-2.6.20/
<mgalvin> would those have been applied to the ubuntu kernel by any chance?
<kylem> likely, yes.
<kylem> but i don't recall for sure.
<zul> i think they were applied early on in feisty
<mgalvin> ah, cool, thanks
<bdmurray> Howdy.  I ran across an interesting kernel bug in lp.
<crimsun> which?
<bdmurray> crimsun: kylem checked it out
#ubuntu-kernel 2007-02-24
<Kano> hi, some things about your current kernel
<Kano> a) ndiswrapper is too old, remove or update - with 1.30 and installed usb wlan drivers you get a system lock
<Kano> b) pata-sis is borken in git, -8- kernel worked
<Kano> if you want to fix some little things like hostap + via intel southbridge bugfix take a look here
<Kano> http://kanotix.com/files/kernel/kernel-update-pack-noide/source/
<Kano> ndiswrapper 1.37 is not fully stable with 2.6.20 for me, will try to find a stable svn snapshot
<Kano> bye
<mgalvin> crimsun: any idea if/when the patch mentioned in #
<mgalvin> https://launchpad.net/bugs/87253 will make it into feisty?
<crimsun> mgalvin: it's already in feisty's ubuntu-2.6.git; expect it in the next kernel upload (you'd have to ask Ben for an ETA)
<mgalvin> crimsun: ok cool, thanks, as long as it make it's way in eventually I am happy :)
<mgalvin> crimsun: i asked earlier and got an "i think so" but... do you know for sure if these are in or getting in... http://svn.sourceforge.net/viewvc/mactel-linux/trunk/kernel/mactel-patches-2.6.20/
<mgalvin> i only ask again because if they are not I am interested in looking into it, it just don't want to waste time if they are already in or planned to be in
<crimsun> I can only speak for audio [which I've addressed] 
<crimsun> I'm afraid I don't have any additional time atm to check
<mgalvin> ok, np, thanks
<mgalvin> i can dig in myself and check
<crimsun> be aware that some of that code is already outdated
<crimsun> certainly the sigmatel diff is incomplete
<mgalvin> crimsun: thanks for the heads up
<Whoopie> BenC: Hi, will tp_smapi added to ubuntu kernel 2.6.20?
<fforw> hi
<fforw> I have a Dell Latitude D820 laptop and have been trying to get feisty fawn running on it. works fine so far but teh wireless drivers don't work.. found the driver (ipw3945) and followed the build instructions (involving replacing a module from the kernel source)
<fforw> but now I get some "no rule for target ubuntu/net/d80211/ieee80211.o" error.. (translated back from German)
<fforw> any ideas?
<fforw> the module is ieeee80211, a prerequisite for ipw3945
<neuralis> er
<fforw> yes?
<neuralis> ubuntu ships ipw3945 in l-r-m; why did you build it manually?
<fforw> because it did not work..
<neuralis> you'll have to be a bit more specific.
<fforw> looked around and found instructions to install a newer version of it including the new ieee80211 
<fforw> lspci showed the device, the module was loaded but no activity.. everything seemed fine, it just can't find anything or connect to anything
<neuralis> strange. well, as long as you have the kernel headers and general build tools installed, compiling the new driver should simply work.
<fforw> the ieee80211 build process complains about a conflicting kernel version and wants to disable/outcomment it and add its own version
<fforw> conflicting module version
<fforw> in the kernel
<fforw> bbl
<[g2] > BenC do you still need a dmes/lspci for the Kernel SATA boot issue ?
<BenC> which boot issue?
<BenC> bug number would be helpful
<[g2] > BenC one sec
<[g2] > https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/84964
<[g2] > from my limited searching it still appears to be a critical bug
<[g2] > basically the box doesn't boot without "irqpoll" on herd 4
<kylem> i think my crestline reproduces that.
<kylem> [g2] , can you try booting with acpi=off or whatever and tell me if that helps? (it's what i did)
<kylem> (booting with irqpoll didn't fix things for me, which is why i ask)
<[g2] > kylem thx. I'm trying that now
<[g2] > it's good to know that someone has reproduced the issue also
<kylem> i just tried without the piix ide driver built into the kernel at all, and it's still an issue, so i'm kind of confused.
<kylem> livecd boots are fine, after install boots are boned, which confuses the hell out of me. :\
<kylem> [g2] , what is the symptom you see? i get "link down" on all sata links from ahci.
<kylem> hmm, i should try with i386.
<[g2] > kylem without irqpoll or acpi=off it won't boot from cdrom
<[g2] > that's i386 on a P4 with an intel 865 mobo
<kylem> and edgy works flawlessly for you?
<[g2] > kylem yeah
<kylem> ok.
<[g2] > edgy's installed on the hd
<[g2] > I'm really looking forward to feisty as I want the updated ivtv drivers
<kylem> can you cat /proc/interrupts from your working system and /msg it to me?
<[g2] > kylem sure is pastebin ok ?
<kylem> i think i just found something in common between working and non-working on my system.
<kylem> absolutely.
<kylem> i figured my acpi bios was just broken, but if other people are seeing this, something more insidious might be happening (the box i'm seeing it on isn't production so.. :/)
<[g2] > http://pastebin.ca/370648
<kylem> ah, no sata?
<[g2] > yeah it's a sata drive
<[g2] > but the sata driver isn't recognized
<[g2] > with acpi=off
<[g2] > well at least I didn't see it recognized
<kylem> hrm
<[g2] > I could reboot with irqpoll
<kylem> ahci uses msi for me, so even with pci=nomsi irqpoll i am still getting no luck.
<[g2] > irqpoll allows me to boot
<[g2] > boot from cdrom which is on ide
<[g2] > I've got a sata dvd drive and I don't remember if irqpoll worked with that
<kylem> hrm. ok.
<[g2] > kylem did you want to see the edgy working system ?
<kylem> /proc/interrupts and dmesg on pastebin would be fantastic.
<[g2] > from edgy ?
<kylem> yeah.
<[g2] > ok. sure
<kylem> i'm adding some crap to my kernel to see if i actually get any interrupts from libata (it shares the irq with uhci, so it's hard to tell.)
<kylem> for a while i thought maybe uhci was stealing the interrupts but it seems not.
<[g2] > http://pastebin.ca/370676
<kylem> thanks
<kylem> yeah, definitely looks like there's no interrupt.
<[g2] > libata
<BenC> so is piix conflicting with ata_piix?
<BenC> if that's the issue, I can fix it real quick
<kylem> no.
<kylem> not for me at least.
<BenC> the last comment is a different bug then?
<kylem> it's entirely possible intel managed to fuck the acpi bios completely on this sdv.
<BenC> I thought I had commented out the entries in piix that matched in ata_piix
<kylem> but it's pretty similar, edgy/feisty cds work, first boot into installed system fails miserably and no disks get see.
<kylem> n
<BenC> a conflict between piix and ata_piix seems impossible
<[g2] > kylem / BenC there's an oops in usb during the failed boot
<BenC> oh wait
<BenC> CONFIG_ATA_PIIX isn't defined, CONFIG_ATA_PIIX_MODULE is
<BenC> retarded
<kylem> [g2] , oh?
<[g2] > kylem yeah.
<kylem> interesting.
<kylem> i don't think i see that. can you try booting, wait for the initramfs, cat /proc/kmsg and take a picture of the oops?
<[g2] > kylem I can capture the boot on serial
<[g2] > I'll boot with console=ttyS0
<kylem> ok.
<[g2] > and capture it on my laptop
<[g2] > i'll pastebin in a minute or two
<BenC> kylem: This *_MODULE thing could be the cause of a lot of problems, so keep it in mind when you check bug reports
<BenC> I fixed all the ones I had
<kylem> _MODULE?
<BenC> kylem: The idea was that some of the pata drivers only had some of the matching PCI id's for the same IDE driver, so I had to keep the IDE driver enabled, but make it disable the matching PCI id's (so it would use pata)
<kylem> i see. hmm.
<BenC> but I used "#ifndef CONFIG_ATA_PIIX", and it wasn't matching
<BenC> it could account for this sort of thing (CD working, but normal boot isn't)
<BenC> piix, generic and siimage were the three drivers affected
<kylem> hmm.
<BenC> piix should only be used on a hand full of devices
<[g2] > http://pastebin.ca/370701
<BenC> g2: Can you pastebin "lspci -vv"?
<BenC> and /proc/interrupts
<zul_> heylo
<[g2] > BenC sure. Do you want me to boot edgy ant past that ?
<[g2] > or feisty with irqpoll ?
<BenC> either way should be fine
<[g2] > both are fine with me
<BenC> looks like your ICH5 and UHCI are sharing IRQ's, just wondering if anything else is on it
<[g2] > http://pastebin.ca/370715
<BenC> wtf
<[g2] > the UHCI, IDE and SATA are all on irq 169
<BenC> is this on edgy?
<[g2] > yeah
<BenC> ok, irq's are routed to different numbers...
<[g2] > 2.6.17-11-generic
<BenC> I wish libata would use the driver name instead of just libata for request_irq() :/
<BenC> weird, on this one ide, sata and uhci show same irq in lspci, but it's not showing that in proc/interrupts
<BenC> ah, 201 is the audio
<[g2] > I'm guessing the ide is getting remapped
<BenC> so libata is taking taking 169 twice, and uhci_hcd is taking it once
<BenC> Can you do /proc/interrupts on feisty?
<[g2] > sure
<[g2] > BenC do you want me to boot with irqpoll or acpi=off  ?  Does it matter at all ?
<BenC> try without
<[g2] > it doesn't boot without that's the original problem
<BenC> be better to see what it's doing with acpi irq routing
<[g2] > ok so irqpoll ?
<BenC> yeah
<[g2] > BenC ok... I'm winding up in BusyBox in the initramfs (I'm guessing there's a race condition)
<[g2] > in the initramfs /proc/interrupts has usb 18 with uhci_hcd:usb3, ide2 with 100K ints
<BenC> ah, ide2
<BenC> ok, are you in busybox?
<[g2] > ide1 is mapped to int 15
<[g2] > yeah
<BenC> rmmod piix
<BenC> modprobe ata_piix
<BenC> see if that does anything
<[g2] > device or resource busy ?  -f ?
<BenC> hmm
<BenC> ide modules are prone to being load-only
<[g2] > device or resource busy.
<BenC> ok, boot with whatever options you need to get to 2.6.20 being up
<BenC> rm -f /lib/modules/`uname -r`/kernel/drivers/ide/piix.ko
<BenC> update-initramfs -u
<BenC> then reboot without any options
<[g2] > there is no piix in drivers/ide
<[g2] > BenC this is from the LiveCD
<BenC> Ah, it's drivers/ide/pci/piix.ko
<BenC> But you can't do this from a livecd
<[g2] > nod
<[g2] > an yeah it is in ide/pci
<[g2] > BenC ok. I powered off for a few minutes and booted feisty with irqpoll
<[g2] > http://pastebin.ca/370766
<BenC> [g2] : Ok, can you pastebin lsmod output?
<[g2] > http://pastebin.ca/370780
<BenC> piix is definitely loaded, and shouldn't be
<BenC> do you have feisty installed or are you doing this from livecd alone?
<[g2] > BenC livecd, I'd like to get feisty installed
<BenC> You should be ok if you just rm the piix.ko driver
<BenC> next kernel upload will have that fixed
<BenC> I think piix and ata_piix don't play well together
<[g2] > ok
<[g2] > BenC / kylem thx -- Feisty's installed now
<BenC> getting rid of piix fixed it up?
<BenC> or still using irqpoll?
<[g2] > BenC no I just installed and rm'd piix.ko and booted
<BenC> sounds good, thanks for testing
<[g2] > so to be clear, no I'm not using irqpoll
<[g2] > and yes I am not loading piix
<[g2] > it's a pleasure testing :)
<[g2] > thx for the great help
<BenC> [g2]  next kernel update should be fixed without needing any special hacks
<BenC> np
<[g2] > next+1 :)
<[g2] > I'm apt upgrading now so I don't think you mean that one
<[g2] > BenC you don't really have a hardware lab to test kernels on correct ?
<[g2] > heh... other than "the world"
<BenC> [g2] : Lab, no, just the machines I have, and other developers have
<BenC> we have a support center that does testing for certain machines
<[g2] > BenC how might one get a machine added to support center ?
<[g2] > or do similar testing
<BenC> [g2] : Contact jbailey@canonical.com
#ubuntu-kernel 2007-02-25
<zul> BenC: did you get 2.6.20.1 yet?
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-9.15 Uploaded - Things are getting solid now. Use it, but there are still a few missing modules. | BUG STATUS (2.6.20): 269 Open, 75 Unconfirmed, 168 Unassigned
#ubuntu-kernel 2008-02-18
<osmosis> I dont get it. Is 2.6.19 still the lastest xen server kernel ?
<Brian323> Hello
<soren> osmosis: It's called linux-image-<version info>-xen these days, so right now: linux-image-2.6.24-8-xen.
<abogani> Bug #192559
<ubotu> Launchpad bug 192559 in linux-ubuntu-modules-2.6.24 "alsa update breaks kernel ABI" [Critical,New] https://launchpad.net/bugs/192559
<Kano> hi, could somebody disable the old nv legacy driver, users with nforce 560 chipsatz can not even boot...
<tseliot> Kano: what do you mean by "disable"?
<Kano> well you have got 2 drivers
<Kano> for the same
<Kano> amd74xx and pata_amd
<Kano> i would prefer the 2nd...
<tseliot> sorry, I misread your message, I thought you were referring to the graphic driver
<Kano> no ide
<Kano> btw.: echo blacklist amd74xx > /etc/modprobe.d/custom-blacklist; update-initramfs -uk all
<Kano> would fix this,but better disable old driver 
<Kano> also i would suggest to add a blacklist option for initramfs
<Kano> i have that for live mode of kanotix
<Kano> i can do: blacklist=module1 blacklist=module2 or: blacklist=module1,module2,module3 
<Kano> but for initramfs you would need that before the internal udev is started
<Kano> the option just writes /etc/modprobe.d/custom-blacklist with blacklist moduleX as content
<Kano> for each module
<Kano> using that you could "hotfix" these problems if needed
#ubuntu-kernel 2008-02-19
<osmosis> soren: thats the problem though, its not 2.6.24-8 ... it says  http://packages.ubuntu.com/hardy/admin/xen-image-2.6.19-4-server 
<osmosis> soren: err...i see, different name.
<osmosis> soren: wonder why the old package is still there too.
<osmosis> new, http://packages.ubuntu.com/hardy/base/linux-image-2.6.24-7-xen
<osmosis> yay! has amd64 support too.
<kraut> moin
<eradicus> hi kraut, do you have any idea why i get module.h not found, even if I have installed the header and source and had my /usr/src/linux pointed to the right kernel source?
<kraut> eradicus: did you do a find on the source-tree to find that file?
<abogani> eradicus: /usr/src/linux is a old-style linux source auto-pointer. Now /lib/modules/`uname -r`/build is used instead.
<abogani> check to have linux-headers-generic installed.
<eradicus> abogani: so i have to redefine /usr/src/linux to point to /lib/modules/`uname -r`/build ?
<Keybuk> gnargh
<Keybuk> resume from suspend consistently fails on this laptop under hardy
<Tonio_> hi there
<Tonio_> there is a patch for alsa and macbook that was on feisty and was lost during the edgy dev cycle...
<Tonio_> I discussed with crimsun_ about including it again and he is okay on rationale
<Tonio_> here is the patch http://paste.toniox.org/2813
<Tonio_> it closes bug 87253
<ubotu> Launchpad bug 87253 in linux-source-2.6.20 "internal speakers do not work on MacBook Pro" [Low,Fix released] https://launchpad.net/bugs/87253
<Tonio_> sound support on the concernd macbooks is only partial with the current driver (I can confirm the issue, I have one of those macbooks)
<Tonio_> I hope this patch can be included to the current kernel before hardy is released !
<JanCG> Tonio_, you might want to reopen that bug (or open a new one) with the patch attached
<Tonio_> JanCG: sure ;)
<amitk> Tonio_: just modify the existing bug 
<amitk> Tonio_: target it to linux-2.6.24, hardy
<amitk> I assume you have tested Hardy and it still doesn't work for you?
<Tonio_> amitk: without the patch, no it doesn't work ;)
<amitk> Tonio_: any reason why this patch hasn't made it upstream yet?
<Tonio_> amitk: they probably want something more generic that doing depending the dev id
<Tonio_> amitk: I suspect that the "if (codec->revision_id == 0x103401) -> else" isn't very welcomed
<Tonio_> amitk: btw crimsun_ would know more on that point, as it did the patch for feisty
<Tonio_> amitk: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/87253
<ubotu> Launchpad bug 87253 in linux "internal speakers do not work on MacBook Pro" [Medium,New] 
<Tonio_> amitk: I hope I filed it the good way, please lemme know if that's not correct ;)
<amitk> Tonio_: looks good
<amitk> Tonio_: although, for future reference, you should have left the old package (linux-source-2.6.20) in there and just add a new one for the hardy kernel, to maintain history.
<Tonio_> hum true..... I'll change that
<Tonio_> amitk: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/87253
<ubotu> Launchpad bug 87253 in linux-source-2.6.20 "internal speakers do not work on MacBook Pro" [Medium,Fix released] 
<Tonio_> amitk: should be okay now
<BenC> amitk, rtg, smb, king_: ping
<amitk> here
<smb> BenC: here
<rtg> BenC: yo
 * BenC waits for king and his new super fast cable line to respond
<king_> BenC: my cable is fast - I was just busy! 
<BenC> hehe
<king_> BenC: ..busy downloading loads of stuff :-)
<BenC> Ok, welcome to the Ubuntu Kernel Team meeting. As usual, you can find the agenda, as well as past minutes, at this location: https://wiki.ubuntu.com/KernelTeam/Meeting
<BenC> Not much in the way of team status...
<BenC> rtg: How about a quick overview of the -9 kernel aimed for Alpha 5, and the state of re-upload?
<rtg> the big items in -9 are /dev/mem and /dev/kmem protection.
<rtg> working on getting -9 to build, but no upload until after A5.
<rtg> also working on some ABI issues raised by Fabio.
<rtg> ALSA modules create a different ABI then the kernel.
<rtg> linux-meta has some deficcienties that need fixed.
<rtg> thats about all for me.
<smb> rtg: This will also get lum pulled freshly, won't it? Cause I had to fixup the dmraid45
<rtg> smb: yep
<smb> rtg: Good:)
<rtg> but not until thursday late.
<BenC> Alright, sounds like we have everything under control, even if the deadline for upload did get missed
<rtg> BenC: back to you...
<BenC> rtg: when was -9 uploaded?
<rtg> yesterday.
<BenC> the first upload
<rtg> the linux-headers package was fubar'd.
<BenC> Ok, that's part of the reason for missing the A5 freeze...deadline for upload of kernel was Sunday
<rtg> the its serendipitous, huh?
<BenC> not a problem, but something to watch out for
<BenC> Next up, QA bug list for the kernel, which seems to have been knocked out very well since last week
<BenC> The only thing I'd comment on right now is we have 11 bugs in the past column that are not assigned to anyone, so we should either close as wont-fix, or one of us pick them up
<BenC> Good job on getting things handled from last week though
<BenC> Well, other than that, we are pretty much done...anyone want to comment one anything?
<amitk> perhaps it is good to announce the patch deadline
<BenC> amitk: the patch deadline is rolling, and it's always the day before the kernel upload window starts
<amitk> BenC: aah. I misunderstood it then. Nevermind.
<BenC> Maybe it would be a good idea to link to the read-only ubuntu-kernel-release-schedule google cal though
<BenC> We can add it to the KernelTeam wiki resources
<king_> BenC: Does this mean we should refrain from putting in large patches into the kernel now?
<BenC> The kernel freeze itself isn't until March 4th
<BenC> but we should take care with whatever patches are going in right now
<BenC> Once we hit kernel freeze, we aren't doing anything except major bug fixes
<king_> OK -  I am probably going to refrain from putting a large and hairy patch for the broadcom b43 driver then ...
<king_> ..especially as there is a NDIS wrapper solution
<rtg> 2.6.24.2 already has  a big patch for B43.
<BenC> We may have some alternative with regard to b43
<king_> rtg: And there is another one for a specific revision 02 of a board. I think it should wait
<BenC> Ok, if there's nothing further...
<rtg> king_: depends. does it help? b43 is largely non-functional from what I can tell.
<BenC> Ok, meeting adjourned...have a great week everyone, and thanks for attending
<johanbr> rtg: Do you mean non-functional in general? If so, I think that's an exaggeration.
<smagoun_> The git tag for the 2.6.24-8.13 LUM upload doesn't match what's in the source package. Is that intentional?
<smagoun_> amitk: ^^^^
<amitk> smagoun_: yes. Since the top commit of PPA packages is thrown away when we rebase to latest hardy
<smagoun_> amitk: I'm referring to the Hardy LUM, not the one in the PPA. For example, commit 80b905953dde820e13869e1859427baaa0bba3ba is included in the 2.6.24-8.13 source tarball, but it's not present in the 2.6.24-8.13 tag in the Hardy LUM tree
<amitk> smagoun_: rtg probably repushed the 'UBUNTU: Ubuntu-2.6.24-8.13' commit, thereby nuking the old id. rtg, commit f0b376c9ec128db651d83d9f690af7351d6d2a37 should have the Ubuntu-2.6.24-8.13 tag, you need to delete the old tag and create a new one point to this commit.
<amitk> *pointing
 * amitk -> dinner
<smagoun_> amitk: That clears things up for me. Thanks for the help!
<rtg> smagoun_: Hardy LUM tags are corrected.
<smagoun_> rtg: thanks
<abogani> I'm incredible stupid :-(
<_MMA_> ?
<abogani> _MMA_, Bug #193078... Perhaps too much punches? :-(
<ubotu> Launchpad bug 193078 in linux-ubuntu-modules-2.6.22 "quickcam module will not load in rt kernel" [Undecided,New] https://launchpad.net/bugs/193078
#ubuntu-kernel 2008-02-20
<abogani> _MMA_, Read my very stupid replay... :)
<_MMA_> abogani: Ill reply. He has a attitude from the get go. (start of things) He wont test but Ill ask him again.
<abogani> bdmurray, ogasawara: Are you around? Could you set bug #193078 to "Won't Fix" for linux-ubuntu-modules-2.6.22, please?
<ubotu> Launchpad bug 193078 in linux-ubuntu-modules-2.6.24 "quickcam module will not load in rt kernel" [Undecided,Fix released] https://launchpad.net/bugs/193078
<abogani> Thanks :-)
<bdmurray> abogani: I've won'tfixed it
<abogani> bdmurray, Thanks a lot, Brian!
<abogani> _MMA_: Thanks, Cory.
<_MMA_> k
* abogani changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.24-7.11 | Latest news: 2.6.24 Release in Hardy | Next meeting: Feb 26, 17:00 UTC | Kernel Team machine: http://kernel.ubuntu.com
* abogani changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.24-8.14 | Latest news: 2.6.24 Release in Hardy | Next meeting: Feb 26, 17:00 UTC | Kernel Team machine: http://kernel.ubuntu.com
<tyrone> Hello, I'm not sure if you've heard of this, but the kernel header files seem to lack certain files. Particularly module.h. Any idea how to get them in there? Thanks
<tyrone> anyone on at all?
<tyrone> ubuto : sorry to bug you, but you seem to be the only user who isn't idling at the moment. Can I ask you a question? about the kernel headers?
<johanbr> It's pretty late. Try earlier in the day. And ubotu is a bot. :)
<tyrone> ... why does that always happen to me
<tyrone> lol. me and bots..
<tyrone> well.. either way, have you heard that module.h is missing from the linux headers on 22-14?
<kraut> moin
<maks_> BenC: can i please get at least an answer to my initramfs-tools sync mail
<kurt-georg> hi folks, i have a severe problem with hardware detection, can you help me? i believe it is a kernel issue.
<abogani> kurt-georg: Please, Fill a bug report. Obviously check is already exist in the bug database first! :-) Thanks! 
<kurt-georg> i did. i got no reaction.
<kurt-georg> Bug #192234, first reported on 2008-02-15 by  Georg Hooss
<ubotu> Launchpad bug 192234 in ubuntu "3-years old ehci usb hardware not recognized" [Undecided,New] https://launchpad.net/bugs/192234
<kurt-georg> yes
<kurt-georg> what more can i do if not asking here?
<abogani> http://lkml.org/lkml/2008/2/15/313
<rtg> suppose this'll make it into 2.6.23.3 ?
<rtg> s/2.6.23.3/2.6.24.3/
<zul> rtg: the patch is sitting on the ml moderators
<rtg> zul: flushed
<zul> thanks
 * amitk -> make dinner
<mkrufky> [OT] my latest request @ shipit.ubuntu.com was not approved  -- is this because Hardy is soon on the way??  I don't know where / who to ask why my request was denied
<TeTeT> mjg59: hi Matthew, can you tell me how it is decided which ACPI module is loaded, e.g. thinkpad_acpi on my T40p?
#ubuntu-kernel 2008-02-21
<zul> rtg: ping
<tquocvu_> anyone dig memory management in kernel ?
<bullgard4> What programs use or evaluate the contents of the file /var/log/udev?
<kraut> moin
<xivulon> Hi all
<xivulon> last daily build amd64 ISO, hangs my system during module loading in rcS.d
<xivulon> was very late yesterday night when that happened and didn't do much debugging
<xivulon> will be able to provide more info tonight
<xivulon> that was on a samsung q45
<xivulon> I guess 2.6.24.8.8
<gan> hai how to find out the difference between the two kernel version , it means by feature or something else
<gouki> 'morning
<gouki> Can someone please explain how is a kernel in .ISO format? http://lkml.org/lkml/2008/2/1/499 And how could I compile it (if it's possible at all)
<mjg59> You don't
<gouki> I don't compile it?
<mjg59> It's an iso with a kernel on, not a kernel in iso format
<gouki> So extracting and compiling will work? The .ISO part got me confused. Since most times, .ISO are used for burnable images.
<mjg59> Uhm.
<mjg59> That is a burnable image.
<mjg59> For a PS3
<mjg59> What are you actually trying to do?
<gouki> I'm wanted to try this new kernel on the PS3
<mjg59> (And why are you asking here?)
<gouki> ok mjg59, I won't bother you again. I was discussing this with Collin and he told me this was the correct place.
<mjg59> Well, it's not an Ubuntu kernel :)
<gouki> After all, it's a problem with the current linux kernel that is making ubuntu not recognizing the wifi interface on the ps3
<mjg59> That would suggest that we need the new wifi driver in our kernel
<gouki> Yes. Collin mentioned BenC was aware of this.
<mjg59> Ok. It'll probably be dealt with, then
<gouki> s/collin/colin
<gouki> From what I've heard, 8.04 will not have support for the PS3. So would this be done in 7.10?
<mjg59> No
<mjg59> At least, it's very unlikely
<gouki> If it won't be dealt for 7.10 and currently no one is working in Linux Cell for 8.04, support for the PS3 will end. 
<gouki> That's why I was asking about this kernel version
<gouki> At least people would have a working version of ubuntu running on their ps3
<mjg59> I still don't really understand what you're trying to do
<gouki> Understand how could I use that kernel version to provide Wifi support for the PS3
<gouki> Now, like I told you, the ISO part got me confused. 
<mjg59> That's not a link to a kernel. That's a link to a boot CD for the PS3.
<gouki> Even more confused about it being a burnable image :)
<gouki> Ohh, OK. I see.
<mjg59> One of the files it contains is a kernel
<mjg59> Like the Ubuntu images
<gouki> Ok; Thank you.
<xivulon> mjg59, are you in charge of pm-utils?
<mjg59> In Ubuntu? Yes
<xivulon> we used to have some code in pmi.acpi to disable suspend to ram/disk in loopinstallations
<mjg59> Hm. Is that not still there?
<xivulon> I looked at it a week or two ago' and wasn't there
<xivulon> I mean it is in pmi.acpi but not in pm-utils
<xivulon> in short in loopinstallations under hardy the suspend/hibernate buttons are enabled when they shouldn't be
<mjg59> Ah, right - and we're calling pm-utils directly, rather than going via pmi
<mjg59> Ok
<xivulon> grep host pmi.acpi
<xivulon> to find the relevant code chunks
<xivulon> thanks a lot
<xivulon> mjg59 bug #187463 
<ubotu> Launchpad bug 187463 in wubi "Disable suspend (ram/disk) in Loopinstallations" [Medium,Confirmed] https://launchpad.net/bugs/187463
<mjg59> Ok
<Kano> hi rtg , could you update aufs?
<amitk> mjg59: is there a standard keycode to trigger rfkill? KEY_WLAN perhaps?
<mjg59> amitk: KEY_WLAN is the correct one. I can't remember if you need to perform some association in the kernel, though
<amitk> mjg59: so if a device doesn't have a slider/switch to kill the radios, then the Fn+FXX combo to kill the radios should just generate KEY_WLAN (using setkeycodes), right?
<amitk> s/device/laptop
<mjg59> Right
<lkolbe> Hi! I'm currently building a kernel for feisty from the  official git repository plus one or two local patches; and I'd like to use ccache. Building occurs in a feisty chroot, with debuild. How can I tell debuild to use ccache?
<macd> lkolbe, its a bit easier to use ccache with pbuilder
<macd> lkolbe,   https://wiki.ubuntu.com/PbuilderHowto   
<Keybuk> mjg59: fprint > thinkfinger, right?
<jayc> amitk:ping
<amitk> jayc: hi
<jayc> amitk: I successfully built the hardy-ume and lum on my local machine and tried it on D0, but PPA build fails, can I push the changes to git?
<amitk> jayc: feel free to push it to the ume-hardy and ume-hardy-lum git trees, but don't upload anything to mobile PPA.
<amitk> jayc: early next week (25th) is a deadline to send a tested image to Intel, so I don't want to upload new stuff until then.
<jayc> amitk:ok, I will push the kernel stuff and inuka is working on the lum to add beta7 Gfx driver
<amitk> jayc: something in the PPA is broken for us too. We see the error you are seeing. It will be investigated.
<jayc> amitk: so, you don't want me to upload these changes to PPA until 25th?
<amitk> jayc: that is correct. I will be in Boston next week, so we can coordinate an upload since kernel, lum, lrm, meta and poulsbo X driver need to be co-ordinated.
<jayc> amitk: ok, does Mauri know about this, if not I will inform her
<amitk> jayc: go ahead and inform her if you need to.
<jayc> amitk:ok, thanks
<amitk> jayc: np, how is portland weather these days?
<jayc> amitk:it's been very since last weekend
<amitk> good to hear
<jayc> amithk:that's a rare thing here :-)
<amitk> hehe
<jayc> amitk:How about there, is it back to normal (below zero)?
<amitk> jayc: it's only been real cold one day since I got back (-10), rest of the time it has been -1 to +4
<amitk> I gotta go and try catch some sleep now
<amitk> good night
<jayc> amitk:good night
#ubuntu-kernel 2008-02-22
<mjg59> Keybuk: Yeah
<Keybuk> mjg59: fprint seems a little ...
<Keybuk> well, it's clearly a much better design
<Keybuk> but not that finished yet
<Keybuk> the pam module gets stuck because it doesn't actually produce a password prompt
<Keybuk> but then thinkfinger is evil and uses uinput to poke ENTER to clear the password prompt it does produce
<mjg59> Hm. I got a password prompt with my finput, IIRC
<Keybuk> with pam_fprint I get a generic "Swipe your right index finger" prompt that only allows you to swipe
<Keybuk> you can't enter a password instead
<Keybuk> and this doesn't work with gdm, gksudo, etc.
<mjg59> Set the modules lower down the stack to try_first_password or whatever
<Keybuk> how do you mean?
<Keybuk> I did it as:
<Keybuk>   auth sufficient pam_fprint.so
<Keybuk>  auth required pam_unix.so try_first_pass
<mjg59> Hm
<mjg59> That worked for me
<mjg59> I could just type a password at the first prompt
<mjg59> Though I was running code from ~ November
<Keybuk> that's the current code
<Keybuk> that gives me:
<Keybuk> warcraft scott% sudo -s
<Keybuk> Scan right index finger on UPEK TouchStrip
<Keybuk> [cursor here]
<Keybuk> only entering a password suffices
<Keybuk> err
<Keybuk> only swiping a finger suffices
<Keybuk> sorry
<Keybuk> pam_thinkfinger instead gives me
<Keybuk> warcraft scott% sudo -s
<Keybuk> Password or swipe finger: [cursor here]
<Keybuk> and I can either enter a password or swipe my finger
<mjg59> Well, sounds like a trivial amount of code to fix
<Keybuk> true, but then you'd need the same evil thinkfinger uinput hack to press ENTER at the prompt
 * toresbe just submitted https://bugs.launchpad.net/ubuntu/+source/linux/+bug/194196 
<ubotu> Launchpad bug 194196 in linux "Fails to insert nVidia SATA disk modules on boot causing boot fail" [Undecided,New] 
<toresbe> now correct me if I'm wrong, that goes to you guys, right? Not the kernel.org folks? I'm not familiar with launchpad.
<Keybuk> right
<toresbe> cool :)
<TheMuso> c/
<TheMuso> ugh
<bwlang_> I'm seeing some lockups on my laptop (lenovo t60p)... i don't have a serial prot and the sysreq keys are not working. How can i debug this?
<clever[rev]> bwlang_: can you crash it while in text mode?
<kraut> moin
<lkolbe> macd, thanks for the suggestion. I never managed to get the kernel build directly with pbuilder at all :(. 
<bwlang_> clever[rev]: it's pretty intermittent... i have not yet seen it without X running, but I don't spend very much time without X.
<Kano> hi rtg , how about updating the xpad driver for xbox 360 controllers? i just bought gh3 pc and want to use my guitar
<rtg> how about sending a patch once in awhile?
<Kano> against kernel?
<Kano> http://gentoo-wiki.com/HOWTO_Xbox_360_controller_on_Linux
<rtg> I have no idea where that driver lives. I assume its the kernel.
<Kano> you basically could update the xpad files
<Kano> from the cvs
<rtg> Kano: I don't want to know, nor am I interested in researching it. I want to be spoon fed the patch while I get on with other (much more critical) bug fixes.
<rtg> same with aufs.
<Kano> well will try to update the kernel later
<Kano> or should i try it external in lum?
<rtg> I'll leave that up to you.
<Kano> i thought i could directly play frets on fire now that ;)
<Kano> do you know that game
<rtg> who has time for games?
<Kano> it is fun ;)
<Kano> when you need to relax a bit
<rtg> when I need to relax I get my ass outdoors
<Kano> ok, thats another way
<johanbr> mjg59: Is there any chance I could ask you to take a look at bug #124797 (second core loses cpufreq support on resume) ?
<ubotu> Launchpad bug 124797 in linux-source-2.6.22 "CPU Frequency Scaling Monitor applet on dual-core doesn't work after resume" [Low,Confirmed] https://launchpad.net/bugs/124797
<rtg> tjaalton: ABI bump to -10 in git repo. I uploaded a bit ago, but -10 won't appear until the Alpha thaw happens.
<tjaalton> rtg: thanks, I believe there'll be a new nvidia blob soon, since they released new chips (9600GT, Quadro FX3600M) today/yesterday
<rtg> tjaalton: are all of the flavours represented in lrm now? virtual/xen/rt/server/generic/386/lpia ?
<rtg> tjaalton: we also need to think harder about getting lrm under git control. that would make questions like this moot since I'm too lazy to download that ginormous package.
<tjaalton> rtg: virtual & xen are missing
<tjaalton> rtg: if git works with large binary files, then I'm all for putting it under git
<amitk> tjaalton: git has no problems, but the meta date is huge, so you end up with a repo that is twice the size of real files. We need some way of decoupling the various binary tarballs from the build info in LRM. This build info needs to be in git, the binary tarballs - not really.
<amitk> s/date/data
<tjaalton> amitk: ah, ok. we've had some discussions with tseliot to revamp the packaging anyway (for ibex), so maybe it would be a good time to consider git
<bwlang_> damn... just hung again... this is the 4th time in 2 days.  I didn't see anything in launchpad about this.  Is there any way to debug given that I don't have a serial port on this laptop?  And magic sysreq doesn't work.
<rtg> tjaalton: my suggestion for putting lrm in git is to commit everything except the binaries, and perhaps create and commit a script that pulls the binaries (the correct versions, or course) from their respective web sites.
<rtg> tjaalton: I've been experimenting with linux-meta in git, and it works OK as far as having to rename the directory every ABI bump.
<rtg> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-meta.git;a=summary
<tjaalton> rtg: ok, that could work. maybe we can discuss the details in Prague ;)
<amitk> tjaalton: rtg: good beer should definitely help ;)
<tjaalton> good ol'fashioned coaster-design ;)
<dade`> hi
<dade`> I have the "rescheduling interrupt" bug
<dade`> https://bugs.launchpad.net/ubuntu/+bug/177895
<ubotu> Launchpad bug 177895 in linux "Kernel 2.6.24-2 causing ~1000 wakeups by "Rescheduling Interrupts"" [Medium,Fix released] 
<dade`> and i'm using 2.6.24-8.14
<dade`> so it's not fixed
<dade`> damit
#ubuntu-kernel 2008-02-23
<Kano> hi, what should ifneq ($(wildcard /CurrentlyBuilding),) do?
<Kano> i think this line must be wrong
<Kano> there is no * in the wildcard function so it is always /CurrentlyBuilding
<Kano> or not?
<Kano> in any case i dont understand if you want to raise the concurrency level only if it is buildd or not
<Kano> it is basically never raised if you compile it normally
<Kano> wi would completely get rid of that check...
<crimsun_> johanbr: I've purchased some bluetooth gear and will be troubleshooting the audio issues this weekend.
<Kano> btsco?
<crimsun_> Kano: the entire BT stack.
<Kano> but if you like to have that wildcard check it seem you negated it wrong
<Kano> the n is too much
<Kano> crimsun_: what do you say about the check??? why do you need a file/dir /CurrentlyBuilding to compile multithreaded???
<Kano> ps aux|grep -e -j
<Kano> shows 1 when it does not exist
<crimsun_> Kano: I'm not familiar with the build infrastructure or any hacks to enable features.
<Kano> look into 0-common-vars.mk
<Kano> stupid ^10
<johanbr> crimsun_: That's excellent news. The different developers (bluez/pulse/voip apps) seem to agree that continued rapid opening and closing of the alsa device causes many of the problems seen by users. But they have different opinions on whose problem this is. :)
<johanbr> crimsun_: In particular, I'd be grateful if you could try using the Twinkle voip app with a bluetooth sco headset, connected via the bluez audio service. There's a thread about this at http://tech.groups.yahoo.com/group/twinklephone/ (pardon the yahoo).
<johanbr> And feel free to ping me if I can help with any testing.
<Kano> rtg: http://kanotix.com/files/kernel/kernel-update-pack-generic/source/xpad-2.6.24.patch
<Kano> rtg: that finally works...
<Kano> selfmade
<Kano> please add
<Kano> Joystick (RedOctane Guitar Hero X-plorer) has 8 axes (X, Y, Z, Rx, Ry, Rz, Hat0X, Hat0Y)
<Kano> and 13 buttons (BtnX, BtnY, BtnZ, BtnTL, BtnTR, BtnTL2, BtnTR2, BtnSelect, BtnThumbR, ?, ?, ?, BackBtn).
<Kano> rtg: the patch works..
<Kano> but, amd74xx has still the same pci ids as pata_amd which is really bad
<Kano> remove em from amd74xx
<Kano> or backlist amd74xx
<Kano> if you really add it
<Kano> or dont compile it
<Kano> because both share the same id
<Kano> so if you like you could also update mit
<patko> sans xserver Ã§a ne marche pas non plus
<patko> obligÃ© de tout copier Ã  la mian
<patko> ooops, wrong box, sorry
<bullgard4> How to explain that systool considers acpi a sysfs bus?
<lkolbe> ahem, I'm building the kernel from git (with local patches; feisty-gittree) and get this:
<lkolbe> make[1]: Leaving directory `/tmp/buildd/linux-source-2.6.20-2.6.20/debian/build/build-386'
<lkolbe> Checking module listings...
<lkolbe> Modules have gone missing:
<lkolbe> affs amd-k7-agp amd-rng a[...]
<lkolbe> When he tries to build the modules it just bails out :(
<lkolbe> feel free to answer when I'm away, I'll have a look here on monday :)
<scar8> hello. will hdaps support be included in kernel? i cant make it work under Gutsy. i tried the patches from thinkwiki.org but they r for older kernel versions. Is it the right channel to ask this?
<cody-somerville> Is the kernel team going to fix bug #190410?
<ubotu> Launchpad bug 190410 in linux-restricted-modules-2.6.24 "[hardy] avm-fritz-firmware-2.6.24-7 is referenced, but package repositories include only avm-fritz-firmware-2.6.17-6" [High,Confirmed] https://launchpad.net/bugs/190410
#ubuntu-kernel 2009-02-16
<ia> hello. I try to compile custom kernel for jaunty(2.6.28-8.21) with ralink wireless driver as module and i get message ".../linux-2.6.28/scripts/Makefile.build:231: target `ubuntu/../drivers/staging/rt2860' doesn't match the target pattern"; module doesn't compile, but compilation of kernel go on. could you tell me, please, how to fix it?
<TheMuso> ia: You should only need the linux headers packages to build a new driver against the kernel.
<TheMuso> ia: So linux-headers-2.6.28-generic
<ia> TheMuso: eeem, i don't compile driver for existing kernel; i compile the whole kernel with necessary modules. afaik headers necessary only if you develop/compile modules for already existed and compiled kernel.
<TheMuso> ia: So do the current jaunty kernels not have the necessary modules? If so, you should contact the kernel team about that
<pwnguin> does ubuntu-kernel handle linux-firmware?
<pwnguin> there's a capitalization bug in the bcm bluetooth firmware =/
<pwnguin> bug #156133
<ubot3> Malone bug 156133 in linux-firmware "bluez suite lacks bluez-firmware package" [Low,Triaged] https://launchpad.net/bugs/156133
<pwnguin> ok, redid the title on that
<pwnguin> bug #156133
<ubot3> Malone bug 156133 in linux-firmware "bcm203x firmware improperly capitalized" [Low,Triaged] https://launchpad.net/bugs/156133
<pgraner> pwnguin: yep it does, what release are you having the prob? Intrepid?
<dtchen> pgraner: from last i looked at the bug, both intrepid and jaunty
<pgraner> dtchen: ok, I'll flag it for both releases. Thanks.
<dtchen> pgraner: / apw: thanks for the vanilla kernel builds, which made it possible to easily fix an upstream ndiswrapper bug (diff sent to tracker).
<pgraner> dtchen: cool glad its helping you. Would be great if you could drop a note to kernel-team@lists.ubuntu.com letting the team know
<dtchen> pgraner: sure thing. vanilla builds also made it easy to verify existence of another upstream ALSA bug - working on fixing that now.
<pgraner> dtchen: awesome!
<nataraj>  hi 
<nataraj> <nataraj> git branch
<nataraj> <nataraj>   master
<nataraj> <nataraj>   origin
<nataraj> <nataraj> * tmp
<nataraj>  tmp is v2.6.18 tag
<nataraj> <nataraj> but on compile i get 2.6.29-rc
<nataraj> <nataraj> what to do to get 2.6.18 kernel?
<Ng> smb_tp: I poked bug #311716 off Fix Released for Intrepid since there seem to be a bunch of people who've had brightness control break as a result
<ubot3> Malone bug 311716 in linux "The slider brightness Applet has value inverted after the last update (2.6.27-11)" [Medium,Confirmed] https://launchpad.net/bugs/311716
<Ng> (myself included, Thinkpad x300)
<smb_tp> Ng, is the result currently no brightness control or the still inverted control?
<Ng> smb_tp: no brightness control. The on screen display shows it changing, but it doesn't actually change (via keyboard hotkeys and the panel applet)
<smb_tp> Have you tried the acpi_backlight= options?
<Ng> smb_tp: the only thing I tried was to quickly rmmod thinkpad_acpi and modprobe it with backlight_control=1 (without rebooting), which didn't seem to do anything, but I'm not sure how useful a test that was
<Ng> I certainly can test that option though
<smb_tp> Hm, if i do not confuse this the x300 was different as it could/should not work with thinkpad-acpi. Or was that a different model. I think I saw some comments like that somewhere
<Ng> there are newer laptops sold as thinkpads which have a totally different internal setup to "normal" thinkpads, but the X300 is a "normal" thinkpad. Interally it's actually quite similar to the X61
<Ng> and the various thinkpad kernel modules do definitely work with it
<Ng> (and e.g. Nafallo's T61? sees the same thing, and I added a bunch of similar reports as duplicates of 311716 yesterday)
<Nafallo> R61
<smb_tp> Ok, so all the "real" thinkpads should be happy with "options backlight_enable=1" in the modprobe.d. This should generate a message in dmesg saying that thinkpad_acpi is controlling the backlight, not that it backs of. The problem here is that all those Thinkpads seem to have acpi information that claims to support the generic driver while in fact it does not work. and the thinpad_acpi driver backs off in that case.
<Ng> that being the case, the question would be how to get that option on the right machines - it seems a little harsh to regress the brightness control for a popular range of laptops and require people to set a modprobe option themselves (which may cause problems later)
<Ng> I'll test that and the acpi_backlight option later
<smb_tp> The crazy thing there is that the dsdt does not directly show any _BCL method (which is taken as an indicator that the acpi driver can handle this). It seems like hidden somewhere with indirect pointers which I still do not really grasp. We could make acpi_backlight=1 the default but it is quite hard to say how many models this would regress
<Ng> I'd be tempted to suggest contacting Henrique de Moraes Holschuh <hmh@hmh.eng.br> who is the maintainer of thinkpad_acpi and would probably know the models well
<Ng> there's an ibm-acpi-devel list that he's quite active on
<smb_tp> Ng, for the thinkpads the acpi_backlight option does likely not help. The driver directly queries the capabilities by testing some acpi methods and those will report acpi support even when it is not enabled. Right, this probably is the best approach there
<smb_tp> But in that case we should check whether the problems remain in Jaunty or in the generic upstream kernels
<mjg59> It'd be far easier to just fix the acpi backlight module than to try to figure out how to hack around it with vendor-specific drivers
<philsf> can someone who understands kernel backtraces please take a look at the following dmesg and give me a hint of what's goiing on? http://launchpadlibrarian.net/21975410/dmesg.log it's from Bug #325238, where there are other debugging information and attachments
<ubot3> Malone bug 325238 in linux "BUG: unable to handle kernel paging request" [Undecided,New] https://launchpad.net/bugs/325238
<Kano> hi rtg , how about merging this today: http://kanotix.com/files/kernel/unused-patches/2.6.28-ubuntu-qc-usb-compile-fix.patch
<rtg> Kano: how about following normal procedures and sending patch requests on the mailing list?
<smb_tp> mjg59, To figure out that is actually the real goal. The problem that I currently face is that it is quite mysterious to me how those machines involved do their generic support. The vendor driver does the right thing by backing of but that is bad if the generic implementation in the acpi bios seems just to do nothing at all
<mjg59> smb_tp: If _BCL returns a set of values where the first two are not included in the rest of the values, the entire list should be treated as the set of probable values. Otherwise the first two values should be ignored. The list should then be sorted.
<smb_tp> mjg59, The sorting and dropping came in through stable and I picked that up for future updates. What I am wondering is, that I always believed _BCL should be a method defined in the dsdt. Which isn't the case for those TPs I saw. At least not directly.
<mjg59> smb_tp: I was under the impression that _BCL was always there, but that _BQC sometimes provided an index rather than a value
<smb_tp> mjg59, That is the absolutely mysterious part. There is no such string as _BCL in the dsdt disassembly. But it must be somewhere. At least acpi finds it somewhere...
<mjg59> smb_tp: It's in an SSDT, not the DSDT
<smb_tp> mjg59, Hm, I feared I had some misunderstanding there. Strange enough I found a _BCL method in some DSDTs. 
<mjg59> smb_tp: It depends on the implementation
<mjg59> smb_tp: Generally you'll find it in an SSDT if the system has different graphics options - that way they can ship a single BIOS and load an appropriate SSDT at boot
<smb_tp> mjg59, Ah ok. Hm, this might be the stupid question of the month. How can I access and disassemble an SSDT?
<mjg59> smb_tp: acpidump will dump them as well
<mjg59> You just need to iasl -d the ssdt.dat files
<smb_tp> Ok, so the problem is that I asked for /proc/acpi/dsdt which doesn't dump everything
<mjg59> Right
<smb_tp> mjg59, Oh dear... Well, thanks a lot for that
<DnaX> someone can look this bug? https://bugs.edge.launchpad.net/linux/+bug/326621
<ubot3> Malone bug 326621 in linux "Ubuntu lacks support for Ralink rt2870 based 802.11n chipsets" [Undecided,New] 
<BUGabundo> hi
<BUGabundo> anybody else here can help me debug a friends laptop?
<BUGabundo> wired card buggy
<BUGabundo> prob Linux support
<BUGabundo> it's a SYS based laptop
<BUGabundo> humm anybody active here with some pointers?
<smb_tp> BUGabundo, What release? kernel-version, and maybe what wired card? :)
<BUGabundo> ibex
<BUGabundo> 2.6.27-11
<BUGabundo> sis190
<BUGabundo> I had to use the apci off to install
<BUGabundo> using wubi
 * BUGabundo in the middle I found out that wubi install 64 bits when able too!
<smb_tp> Ok, requireing acpi off is probably more than just a network card
<BUGabundo> card can get IP and DNS but will not ping anything
<BUGabundo> and NM takes about 5 sec just to notice un/pluging the card
<smb_tp> Do you see the any associated irq going up when doing pings
<BUGabundo> smb_tp: yes... after grub we can see a message warning about using a DUMMY acpi
<BUGabundo> smb_tp: irqs where? syslog?
<smb_tp> cat /proc/interrupts
<BUGabundo> just a sec
<smb_tp> Generally wondering why acpi=off was required. What happened otherwise? A hang somewhere or panic?
<BUGabundo> hang while installer started
<BUGabundo> but I can boot the laptop without it
<BUGabundo> smb_tp: what should I be looking for on interrupts?
<smb_tp> Since I don't know the card by heart I am not sure it is using interrupts or not. Is there a line which has the sis190 driver to it
<BUGabundo> let me get a lspci
<BUGabundo> SiS 191 Gigabit Eternet Adapter rev 02
<smb_tp> or pipe "ifconfig eth0" here
<BUGabundo> interrupt pin A routerd to IRQ 3
<BUGabundo> kernel module sis190
<BUGabundo> no network on that machine, any thing needed will be either "visual"
<BUGabundo> or by usb key
<d3xter> hey guys
<smb_tp> Right, pipe was rather overstated. Ok, but IRQ 3, so there should be one line in /proc/interrupts with that
<BUGabundo> smb_tp: looking at diff cat results it did change
<d3xter> I've got a little problem with 2.6.27. Sometimes my fan starts working at max speed and cpu is throttled to half of its speed and nothing happens, if i change it with cpu-freq applet. here is my dmesg: http://pastebin.com/f3fa05d91
<smb_tp> In the last column, is there a list of drivers or just one entry
<BUGabundo> smb_tp: it just states eth0
<BUGabundo> back
<BUGabundo> wrong escape key
<smb_tp> Ok, that means at least there are interrupts and the have to be from the card and no other driver should be listening
<BUGabundo> sure. ifconfig also show tx and rx traffic
<BUGabundo> and sometimes you can get network for about  2-3 mins
<BUGabundo> but then if falls to 10mb/s and stop working
<BUGabundo> even though it as an IP
<BUGabundo> I also tried to reboot into recovery, but no deal
<BUGabundo> could get IP with dhclient but would not ping
<smb_tp> Hm, is tcpdump installed? 
<BUGabundo_> back
<smb_tp> d3xter, This sounds a bit like the system sees high cpu temperatures.Have you/can you check the cpu temperature at that point?
<d3xter> smb_tp well that happends randomly, today it was at 62Â° C
<d3xter> and normally it can handle temps of about 82 or so
<d3xter> but the strange this is, that the fan works at max speed until i reboot, not matter how high the temperature is
<d3xter> the strange thing is*
<smb_tp> at least I would not expect throtteling to happen at that point. What says cat /proc/acpi/thermal_zone/THM0/trip_points ?
<d3xter> now the temperature is about 50Â° C :-/
<d3xter> and its still working at max speed
<d3xter> critical (S5): 126 C
<d3xter> smb_tp what does "CE: hpet increasing min_delta_ns to xx nsec" means?
<philsf> can someone who understands kernel backtraces please take a look at the following dmesg and give me a hint of what's going on? http://launchpadlibrarian.net/21975410/dmesg.log it's from Bug #325238, where there are other debugging information and attachments
<smb_tp> This happens if you have a fast hpet and the default interval is too small. 
<ubot3> Malone bug 325238 in linux "BUG: unable to handle kernel paging request" [Undecided,New] https://launchpad.net/bugs/325238
<smb_tp> d3xter, Though yours is running at 15MHz which isn't exceptionally fast. Still the system had problems to set a new minimal delay three times and for that increased this minimum time
<BUGabundo_> smb_tp: any more tips?
<BUGabundo_> i'm downloading jaunty daily and testing 
<d3xter> smb_tp, ah ok, hopefully it will work with jaunty :)
<BUGabundo_> but i dont want to place a new user on a devel branch
<smb_tp> BUGabundo_, Hard to tell over a distance. the sis190 has a debug option which maybe could reveal more. Not sure you would be able to vary network infrastructure with different cabling or hub... 
<BUGabundo1> smb_tp: ha??
<smb_tp> BUGabundo1, The difference between Jaunty and Intrepid for the driver itsels is minimal
<BUGabundo1> smb_tp: ahh.. I just tried running a kernel with no ACPI restritions and it failed to boot
<BUGabundo1> smb_tp: does any log of those failed boot get stored?
<smb_tp> Natively that would require the system to be up to a point it has a file system. I don't think wubi has a chance to do something there, but I don't know that environment...
<smb_tp> Normally the acpi problems happen before that point
<BUGabundo1> I'll check logs once it boots again
<smb_tp> Depending on the system hw there is a variation of options to try: hpet=disable, acpi=noirq, pci=routeirq. But generally boot without splash and quiet to get the most output so it is more visible where a hang occurs.
<BUGabundo1> yeah i saw ir jamming after CPU cores detections
<BUGabundo1> FYI that SIS laptop just booted from Live USB with daily jaunty
<BUGabundo1> it jammed at 2.5177 Write protecting the kernel read-only data : 6568k
<BUGabundo1> trying hpet=disable it stops on bluetooth rf comm ver 1.10
<BUGabundo1> acpi=noirq fails at 0.37 ..timer: vector=0x30 acic1=0 pin1=2 apic2=0 pin2=0
<BUGabundo1> humm ok that now moves.... just took 30 sec of no info, but its rolling
<BUGabundo1> but that was just to slow, and seeing a bunch of IO errors.
<BUGabundo1> I tested my usb pendrive md5sum files just to be sure, and every file was OK
<BUGabundo1> pci=routeirq acted like hpet=disable
<BUGabundo1> choosing ALL option on the installer seems to at least take the install a bit further
<domas> is there some secret dance, that would make 'make-kpkg' to produce package for vmlinux too?
#ubuntu-kernel 2009-02-17
<maxb> There's a single missing $ sign in ubuntu-jaunty-lbm debian/scripts/misc/prepare-compat-wireless.sh . Is there a committed around to save me filing a bug for a 1 character obvious change? :-)
<lamont> EDAC MC0: CE page 0x838dd, offset 0x0, grain 4096, syndrome 0x20, row 2, channel 0, label "": e7xxx CE
<lamont> should I be concerned?
<smb_tp> lamont, Maybe worried. A correctable error in a page. No idea what syndrome wants to say...
<alex_joni> maybe check /usr/src/linux/Documentation/edac.txt
<lamont> ta
<ia> hello. does anybody have some clues about how can my git lost tag for 2.6.28-8.22 kernel in ubuntu jaunty git tree? http://pastebin.com/m5c80ec62
<rtg_> ia: try git fetch --tags
<ia> oh, looks like git didn't loose tag; looks like in ubuntu jaunty git tree no tag for "UBUNTU: Ubuntu-2.6.28-8.22" commit  - http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=summary
<ia> rtg_: oh, thanks a log - it worked :-)
<d3xter> hey guys
<d3xter> is anyone here?
<d3xter> hm
<d3xter> what is sonics silicon backplane driver for?
<red-lichtie> I have a question about kernel packaging. As I see it, modules with experimental status are not build (delivered) as part of the standard kernel distribution. Would it not be better to distribute these modules and add them to modprobe.d/blacklist instead ? This way, if someone wants to use an experimental module, they don't have to compile everything ?
<red-lichtie> Or am I missing a simple way of compiling a commented out module in the config and adding it quickly to my system ?
<rtg_> red-lichtie: you can certainly edit the configs using 'debian/rules editconfigs', then build your own kernel
<red-lichtie> rtg_: I know but I was wondering if it would be easier to just blacklist the experimental modules and saving people from having to do a krenel compile
<red-lichtie> but I guess that they are 2 independant packages, so I guess that it might be a bad idea
<rtg_> red-lichtie: black listing in general is kind of a pain. modprobe is undergoing some changes for Karmic that will allow the kernel package to manage the black lists.
<red-lichtie> Another question: I need to load the omnibook module to get my bluetooth to work, so I have to recompile it at every kernel update. Is there some kind of hook that I can use to recompile user modules when a kernel is updated ?
<rtg_> red-lichtie: look up dkms
<red-lichtie> ty, will do
<rtg_> red-lichtie: I have an example DKMS based madwifi package at http://ppa.launchpad.net/timg-tpi/ppa/ubuntu
<mnemo> if I install one of the mainline vanilla kernel that apw packaged, how can I restore my box to the normal ubuntu stock kernel later? I tried "apt-get install --reinstall linux-image-generic" but that didnt work?
<apw> mnemo, they should install along side the original kernel as they have a different abi namespace
<apw> so your original kernels should be still on your grub menu
<red-lichtie> Can I simply diff/patch from 2.6.29 to 2.6.27 kernel source ? The reason I'm asking is because I'm having serious problems with iwlagn, and according to what I have read, this appears to have been fixed in 2.6.29 ?
<mnemo> red-lichtie: often it works to take small fixes from .29 and apply them to .27 but there are no guarantees of course
<red-lichtie> I can't be worse than it is right now :)
<mnemo> apw: ok I did "sudo apt-get remove VANILLA" now and that worked, thanks
<mnemo> apw: one more question... is it necessary to install source and header packages as well?
<rtg_> mnemo: no, they are needed only if you are building external modules.
<mnemo> rtg_: thank you
<mnemo> rtg_, apw: I added a clarification about which packages are needed and also uninstall instructions to the wiki page: https://wiki.ubuntu.com/KernelMainlineBuilds
<d3xter> the lan-driver shouldn't block the wlan driver, right?
<rtg_> mnemo: looks good.
<joumetal> Does bug 325121 have enough information to be confirmed? Reporter has answered to all questions and I don't know any other questions to ask.
<ubot3> Malone bug 325121 in ubuntu "Ubuntu Jauntyalpha 3 does not boot from Live CD" [Undecided,Incomplete] https://launchpad.net/bugs/325121
#ubuntu-kernel 2009-02-18
<praveen__> is there anyway i can know through some code that some process is suspended or not
<azimout> question: is it possible to use bootchart without an initrd? do you just add a script at S01?
<azimout> and, on a different issue, isn't the room topic a bit old?
<azimout> anyone?
<rtg> apw: is there sufficient information in the vanilla kernel signature that kerneloops can spew an appropriate blob?
<apw> i think we send him enough, but he never responded to say whether he was happy
<rtg> big surprise there :)
<ivoks> i'm getting 'Invalid or unsupported executable format' from grub on all jaunty's generic kernels since (including) 2.6.28-7
<rtg> ivoks: you must have HW issues. Surely lots of folks would have been howling by now.
<ivoks> could be... but -6 works :/
<ivoks> even after reinstall of all kernel
<ivoks> s
<rtg> have fsck'd ?
<rtg> s/have/have you/
<ivoks> could try that...
<ivoks> it's ext4
<rtg> ivoks: is it an ext4 upgrade, or was it install time formatted ?
<ivoks> upgrade
<rtg> hmm, there were a bunch of ext4 changes that went into -7.18
<ivoks> right, i've notices that
<ivoks> noticed
<rtg> ivoks: any change you could build a kernel with all of those patches reverted? I expected them via stable updates by now, but perhaps Ted has been finding issues with them.
<ivoks> i could try...
<rtg> ivoks: they are all labeled 'SAUCE: (revert before 2.6.28.y update) ext4:'
<ivoks> thanks
<ivoks> only 21 commits :)
<ivoks> is it possible to build i386 kernel on amd64?
<rtg> ivoks: you have to chroot the build.
<ivoks> oh, right!
<_ruben> hrm .. seems i just got bitten by http://kerneltrap.org/mailarchive/linux-kernel/2008/10/16/3678594 .. on 2.6.27-11-server
<_ruben> lets see if manually applying the patch helps
<_ruben> bah .. it does fix it, yet there's more to it to get scst kmod to build against that kernel
<rtg> does anyone know how to analyze a crash dump core? I've gotten past where I can copy a crash from /proc/vmcore, but am kind of stalled at the gdb point.
<Ng> smb_tp: we were expecting 2.6.24-23.49 to fix the rtc related kernel oops on sparc64, right?
<smb_tp> Ng, Was that rtc? Sorry got too many other patches through my head lately. But I think we expected it to fix the problem you had.
<Ng> hmm, I just netbooted the machine and installed the newer kernel package from proposed, but it's still doing it. I think I must have done something wrong, the initial version details printed by the kernel claim it's still .48
<smb_tp> It definitely would have to be .49.
<Ng> I guess I'll be netbooting it again and poking
<ivoks> rtg: so, reverting all ext4 commits since -6 did the trick
<rtg> ivoks: can you file a bug with the specifics, and your results that I can pass on to Ted ?
<ivoks> yes, but later... i have to rush now :/
<ivoks> take care
<Ng> smb_tp: yeah that was my mistake, I mounted the wrong partition. It boots now :)
<smb_tp> Cool
<rtg> Keybuk: uploaded 2.6.28-8.24 with the cpu governor changes
<Keybuk> rtg: thanks
<rtg> Keybuk: maybe you can teach me how to analyze a vmcore ? I can't seem to get the right info for gdb.
<Keybuk> you have the linux-kernel-debug package?
<rtg> Keybuk: not yet, just kexec-tools
<Keybuk> ah, you need the -debug thingy
<Keybuk> and apt-get install crash
<Keybuk> which is a bit like gdb
<Keybuk> that's what I've used in the past, anyway
<rtg> Keybuk: thats not a Jaunty package, is it?
<Keybuk> crash? should be
<Keybuk> it's even in main
<rtg> I meant linux-kernel-debug
<Keybuk> oh, no, that's in ddebs.ubuntu.com
<Keybuk> http://magazine.redhat.com/2007/08/15/a-quick-overview-of-linux-kernel-crash-dump-analysis/
<Keybuk> ^ that's a pretty good guide from a RH pov
<rtg> all of this is  a bit byzantine.
<Keybuk> it's the _kernel_ ;)
<Keybuk> some chickens have to be sacrificed
<rtg> ok, I'll grind through that.
<Keybuk> cool
<Keybuk> hwclock changes get us to the end of rcS in 9s
<maco> is kernel team also responsible for packaging the kernel?
<pgraner> maco: yes
<maco> pgraner: bug 272885 is worth looking then
<ubot3> Malone bug 272885 in linux-meta "linux-image package must depend on package grub" [Undecided,New] https://launchpad.net/bugs/272885
<maco> the postinst scripts in the kernel try to update grub, but if you're not using grub, it's a problem
<maco> it recommends, but recommends don't *have* to be fulfilled
<pgraner> rtg: since you the local pkg guru, what do you think?
<maxb> maco: remove/comment-out postinst_hook and postrm_hook  in /etc/kernel-img.conf
<maxb> sorry, that's overly generic advice
<maxb> I guess as far as that bug is concerned, bits of the last-good-boot infrastructure should not be in the "grub" package
<dtchen> i'd be a bit uncomfortable making grub a hard dependency, but i suppose there must be a time and place to move beyond lilo
#ubuntu-kernel 2009-02-19
<pgraner_> ogasawara: ping
<ogasawara> pgraner: pong
<pgraner_> ogasawara: can you add https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/272885 to the list?
<ubot3> Malone bug 272885 in linux-meta "linux-image package must depend on package grub" [Undecided,New] 
<pgraner_> ogasawara: I got bit buy this as well
<ogasawara> pgraner_: yup, consider it added
<pgraner_> ogasawara: great I'll see if rtg can fix it
<_ruben> what's the best way to get this (http://kerneltrap.org/mailarchive/linux-kernel/2008/10/16/3678594) included an upcoming kernel update (for atleast intrepid) ?
<smb_tp> _ruben, If there is no bug for that issue, open one and add pointers to the upstream fixes. Then ping us/me here with the bug number.
<rtg> ivoks: I got a response from Ted. Any more details on your ext4 problem?
<ivoks> i didn't report it yet
<_ruben> smb_tp: ok
<rtg> ivoks: if you want it fixed, then you gotta describe it.
<ivoks> hehe i know
<ivoks> i didn't have time
<_ruben> smb_tp: so far the only reference to this fix is the above mentioned url .. havent found any traces of an actual commit thusfar
<smb_tp> _ruben, Which make things normally harder since stable updates in general should come from upstream repos. The patch itself looks safe. I think I saw you comment somewhere thatyou tried this and it made a difference for you
<_ruben> smb_tp: correct, its one in the it-works-for-me category
<ivoks> rtg: bug 331558
<ubot3> Malone bug 331558 in linux "Unabe to boot linux-image-2.6.28-7 or newer" [Undecided,New] https://launchpad.net/bugs/331558
<_ruben> i could very well my lack of google-foo to find evidence of an upstream patch, as I'd be rather surprised if this hadn't gone upstream yet .. since a change in one part of the kernel broke another part
<rtg> ivoks: thanks. I'll let Ted know.
<_ruben> bugger .. 2.6.27.18 doesnt have the fix :/
<smb_tp> _ruben, Better be in the fixes-it-for-me. The bug/request should clearly state how things are without and with. So this gives an argument why this makes sense. And maybe upstream has to be reminded somehow. Or it did not make sense to them. It isn't even in the latest git. Justchecking tip
<smb_tp> No, neither
<_ruben> ah .. was about to check 2.6.28.6
<ivoks> rtg: great
<smb_tp> _ruben, The problem is likely that in theory both forms should yield the same results. 
<_ruben> smb_tp: hmm .. could be a problem scst itself then in some odd way .. a scst contributer claimed to have sent a patch upstream, which apparently never came through .. nor did a fix submerge within scst .. lets ask around for details
<_ruben> linus prevented said patch from entering mainline without detailed explanation
<smb_tp> _ruben, I would guess it was not enough reason. As said, regardless of the warning this should make no difference. And if so it has to be proved.
<blizzle> I was recommended to try the latest 2.6.29.x kernel in jaunty last night, as I can't get any joy with the 2.6.28.x kernels on my system. Bug is the same as thins one: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/314050
<ubot3> Malone bug 314050 in linux "Jaunty doesn't boot on my DELL Latitude C810 with current kernel" [Undecided,Confirmed] 
<blizzle> The 2.6.29.x kernel failed even to boot. I was recommended to report the issue here. 
<rtg> smb_tp: it would seem that 2.6.27.19 will render ext4 no longer experimental.
<smb_tp> rtg, I saw that big bunch of ext4 patches. I still have to look at them and then it depends when they are flushed. At least it won't cause regressions
<rtg> smb_tp: its the same set I'm carrying in Jaunty. I puklked from Ted's tree a few weeks ago
<smb_tp> I actually saw mails about this on both stable queues
<rtg> yep - I'm going to revert a bunch of SAUCE patches in favour of the official stable commits.
<smb_tp> Actually it could be a good indicator on how complete things are. If you pulled those from Ted's tree before, they should be at least near 1:1 wit what you have to revert
<maxb> On one of my machine's today's kernel update seems to have had an unacceptable impact on interactive performance.
<maxb> I assume it's the cpufreq stuff
<maxb> Rolling back to -7 ABI fixes things
<maxb> I shall now check the -8.x ones
<rtg> maxb: what are you doing that you would even notice interactive performance? Is it under load?
<maxb> even not under load, I found that screen redrawing was affected enough to be quite awkward
<maxb> It could take a full second just to redraw an xchat window after clicking a different channel tab
<rtg> maxb: can you change the cpu governor and see an effect?
<maxb> let me quickly get back into -8.24
<maxb> "quickly"
<maxb> it's fscking
<blizzle> I raised the issue earlier, got zero response, so I'll try again. I'm not able to boot jaunty using any 2.6.28.x kernels here, the bug has been reported: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/314050 .. If I use the patched kernel I can boot, but get other issues.. anyone one if/when this bug is likely to be addressed?
<ubot3> Malone bug 314050 in linux "Jaunty doesn't boot on my DELL Latitude C810 with current kernel" [Undecided,Confirmed] 
<blizzle> s/one/know
<maxb> The panel applet doesn't seem to be working
<maxb> oh, I have an apport-crash of cpufreq-selector
<blizzle> I should also mention that I've seen 2 machines unable to boot with the 2.6.28.x kernels (different hardware), and the 2.6.29.x latest kernel from the ppa failed to boot, also.
<maxb> Can someone point me to the right place in /proc or /sys to change the governor manually?
<rtg> maxb: /sys/devices/system/cpu/cpu0/cpufreq
<rtg> actually, /sys/devices/system/cpu
<maxb> right
<maxb> that fixes it
<maxb> My 3GHz processor was running at 375MHz, and was being excessively conservative about scaling up with 'ondemand'
<rtg> maxb: changing the governor fixes it? What specifically did you do?
<maxb> echo performance > thatsysfile
<maxb> echo performance > ..../scaling_governor
<rtg> maxb: would you open a bug report and add this detail? Keybuk and mjg59 will likely find it of interest.
<soren> maxb: 375MHz? Seriously? I didn't think it could go lower than 600.
<maxb> soren: that's what the panel applet claims....
<maxb> seems rather excessive, especially for a desktop part
#ubuntu-kernel 2009-02-20
<dholbach> hiya
<dholbach> I just had a strange experience with jaunty on my x61s - I pulled the plug and the screen went black and I couldn't get it back
<dholbach> I had this in dmesg:  [15560.738232] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0
<dholbach> and http://paste.ubuntu.com/120487/ in /var/log/Xorg.0.log.old
<dholbach> the only similar bug I found was bug 331685 - not sure if that's the same
<ubot3> Malone bug 331685 in linux "Ubuntu hangs in random moments" [Undecided,New] https://launchpad.net/bugs/331685
<Keybuk> /usr/include/linux/byteorder.h:8:3: error: #error Fix asm/byteorder.h to define one endianness
<Keybuk> Sparc is broken
<smb_tp> Keybuk, where? (which release)
<Keybuk> smb_tp: here, now
<smb_tp> Keybuk, Meaning Jaunty? :)
<Keybuk> yes
#ubuntu-kernel 2009-02-21
<Rocket2DMn> hey guys, had a quick question.  Bug 332170 is talking about a message printed during boot and seems to be related to a problem some people are having with their systems performing poorly.
<ubot3> Malone bug 332170 in linux "[Jaunty] Error appearing at boot - cpufreq: No nForce2 chipset" [Undecided,Confirmed] https://launchpad.net/bugs/332170
<Rocket2DMn> I see the message "cpufreq: No nForce2 chipset" also, but don't experience extra slowness, though I've always used ondemand for cpufreq
<mjg59> The message is harmless
<Rocket2DMn> thanks mjg59 , i'll let them know
<mjg59> Should really be KERN_INFO rather than KERN_ERR though
<Rocket2DMn> where do you see that it is ERR?
<mjg59> The sourcecode
<mjg59> I'll send a patch upstream
<Rocket2DMn> ah, if it was INFO would it be printed to the screen?
<mjg59> No
<Rocket2DMn> Ok, so you want me to change the bug to something saying that message should be KERN_INFO instead of KERN_ERR
<Rocket2DMn> ?
<mjg59> Feel free
<mjg59> The slowness is because p4-clockmod is binding and getting used with the ondemand governor
 * Rocket2DMn nods
<Rocket2DMn> is it just adapting then and will improve?
<mjg59> I've told Scott how to fix that
<Rocket2DMn> fix which? the printing or the slowness?
<mjg59> The slowness
<Rocket2DMn> Ok, so what we really have is two bugs in cpufreq then?  One for slowness and one for changing STD_ERR to STD_INFO ?
<mjg59> Fix slowness:
<mjg59> sed -i s/1000000/10000001/ arch/x86/kernel/cpu/cpufreq/p4-clockmod.c
<Rocket2DMn> I don't have the kernel source code, you are changing a value of 1 million to 1 million + 1?
<Rocket2DMn> Well, I'll take your word for it :)  Shall I include that in the report, or do you know if there is another report open for the slowness problem?
<Rocket2DMn> i thikn i see it
<Rocket2DMn> bug 332017
<ubot3> Malone bug 332017 in linux "Significant performance regression in 2.6.28-8.24 due to p4-clockmod" [High,Fix committed] https://launchpad.net/bugs/332017
<mjg59> No, one million to ten million and one
<Rocket2DMn> ah, I didn't read close enough, sorry.  Is the Scott in the bug I just listed the same Scott you mentioned earlier?
<Rocket2DMn> Scott James Remnant
<mjg59> Yes
<Rocket2DMn> Ok, great!  I'll just have this bug I started with be used to fix the KERN_ERR issue.
<Rocket2DMn> Thank you for your help mjg59 
<mjg59> Rocket2DMn: Patch just got accepted upstream, so it'll be fixed in 2.6.30. The fix can be backported easily.
<Rocket2DMn> for the slowness?
<mjg59> For the message
<mjg59> I'm chatting with the cpufreq maintainer about the slowness issue
<Rocket2DMn> Ah, i just marked as triaged, guess I'll change to Fix Committed.  Thanks for the update
<mjg59> Well, it's not committed to the Ubuntu kernel
<mjg59> So I don't know that fix ommitted is correct
<Rocket2DMn> that would be Fix Released
<Rocket2DMn> last time i checked anyway
<mjg59> I've lost track of how launchpad stuff is triaged nowadays
<Rocket2DMn> https://wiki.ubuntu.com/Bugs/Status
<Rocket2DMn> For us, Committed means its committed anywhere, even upstream
<Rocket2DMn> Hey you wouldn't happen to have a link to an upstream bug report or a commit page would you?
<mjg59> Nope, it hasn't been pushed yet
<Rocket2DMn> heh ok, back to Triaged we go.  That's all I have, thank you again for your time mjg59 .
<mjg59> No problem
<mjg59> It should turn up in the cpufreq git tree shortly
<Shanix_> hi all, I am getting the error -> kernel: [365385.583926] python[943]: segfault at 8908ec93 ip b7c50c8c sp bf843430 error 4 in libgobject-2.0.so.0.1800.2[b7c46000+3c000]
<Shanix_> is there anyway that I can fix it by add/remove certain package??
<mjg59> It's not a kernel problem - the kernel is just reporting that one of your applications crashed
<Shanix_> mjg59, I see. Thanks.
<TimStarling> I isolated a kernel bug a week ago, it's totally ubuntu's fault, not related to upstream, it's a regression and it's easy to fix
<TimStarling> I put a comment on the bug report and emailed the person who committed the bug
<TimStarling> but still no response
<TimStarling> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/297213
<ubot3> Malone bug 297213 in linux "Intrepid: Missing hdaps_ec kernel module" [Medium,New] 
<TimStarling> is there anyone here willing to look at it?
<TimStarling> quiet channel
<iulian> It's weekend.
<TimStarling> you mean you people have a life outside ubuntu?
<LLStarks> morning
<TimStarling> morning
<TimStarling> iulian: I'll take that as a yes
<LLStarks> what's up with the ubuntu kernel naming scheme?
<maxb> LLStarks: What do you mean?
<LLStarks> 2.6.28-8 = 2.6.28.6
<LLStarks> right?
<maxb> LLStarks: the -8 is the ABI number
<LLStarks> what does that mean?
<maxb> It means that that number will be incremented by the Ubuntu packagers to signify that kernel modules must be rebuilt
<LLStarks> but surely the kernel that gets packaged is based off of a point release, isn't it?
<marius_> hello, I posted a bug report with a patch. i wounder if I did everything right: https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/330259
<ubot3> Malone bug 330259 in linux-meta "Problematic volume control keys and mute key of several notebooks + Patch" [Undecided,In progress] 
<LLStarks> what version is the current jaunty kernel based on?
<marius_> is there anything else to be done by me ?
<LLStarks> what is the difference between 2.6.28-8 and 2.6.28.6?
<marius_> nobody here who can answer my question?
<maxb> LLStarks: the key thing to understand is that the .6 and -8 are telling you about totally separate concepts
 * LLStarks is n00b. Explain to me like you would a child.
<maxb> The ABI number, which always comes after a hyphen, serves one purpose only: to designate the compatibility (or not, as the case may be) of the built kernel with particular builds of modules
<maxb> The point release number designates the number of the upstream point release.
<maxb> A point release may *or may not* cause an ABI bump
<maxb> Conversely, and ABI bump may be required for reasons other than a point release
<maxb> (i.e. an Ubuntu-specific change)
<maxb> s/and/an/
<LLStarks> does -8 imply a point release has occurred?
<maxb> No
<maxb> the ABI number implies nothing whatsoever about point releases
<maxb> (Though it would be somewhat unusual for 7 ABI bumps to have occurred without a single point release happenning)
<maxb> (7, because it starts at 1)
<LLStarks> so. when i roll a 20-sided kernel +5 charisma and kms support, what i am getting?
<LLStarks> *kernel for
<maxb> To discover which point releases have been integrated into an Ubuntu kernel, you must inspect the package changelog
<LLStarks> **am i
<LLStarks> why is it like that? shouldn't such things like a point release be readily reflected?
<maxb> No
<maxb> The fact that you need to rebuild your kernel modules is a more significant event than the upstream stable branch happening to release
<LLStarks> i see.
<maxb> Information on which point releases are included is always available in the package changelog
<LLStarks> how can i tell which ABI i'm rolling when i use kernelcheck?
<maxb> I've not encountered kernelcheck, what is it?
<LLStarks> dot dot dot.
<LLStarks> http://kcheck.sourceforge.net/
<IntuitiveNipple> LLStarks: We now build upstream kernels and provide them in the archives
<LLStarks> i saw.
<LLStarks> no kms though.
 * LLStarks gives angry glare
<IntuitiveNipple> not yet, give it time!
<IntuitiveNipple> That'll come for Karmic
<LLStarks> can't you just enable i915.modeset?
<IntuitiveNipple> You'd have to ask Andy. So far as I'm aware they are being built with the Ubuntu configs... but... I've not actually looked closely at that :)
<maxb> LLStarks: I'm not entirely certain I understand your question, but assuming you mean "When I build my own kernel by non-Ubuntu means, which Ubuntu ABI am I getting?", the answer is "Quite possibly none of them, if you're building your own kernel, build your own modules too."
<IntuitiveNipple> You can get the abi with "make kernelversion" or "make kernelrelease"
<LLStarks> what folder?
<IntuitiveNipple> the root of the kernel source
<IntuitiveNipple> that's part of the standard kernel Makefile
<IntuitiveNipple> "kernelrelease" only works after "make prepare"
<TimStarling> can I repeat my question from yesterday?
<IntuitiveNipple> TimStarling: I saw it... not had time to do anything though
<TimStarling> ok
<marius_> I also got a question you got time for me ?
<TimStarling> so should I keep asking people until someone gives in and does it?
<IntuitiveNipple> TimStarling: I seem to recall several months ago, something similar happened with another module. Can't remember which one, though :s
<TimStarling> seems kind of silly that a module can just go missing like that
<IntuitiveNipple> There could have been a good reason... some (in)compatibility issue that wasn't logged in the changelog
<TimStarling> true
<maxb> I have noticed a trivial bug in the lbm prepare-compat-wireless.sh script - a missing $ sign on a shell variable expansion. Is there someone around who could just apply that trivial change?
<TimStarling> that's why I emailled Ben Collins first
<TimStarling> I've had this laptop for almost a year now, and ubuntu has slowly been supporting more and more components in it
<IntuitiveNipple> Looking at the commit diff you reference, I'm almost sure I've dealt with that previously.
<TimStarling> the hard drive has had a bit of corruption and I've been wondering if it's about to go, that's what made me think of hdaps
<TimStarling> if you need me to help test it, I'll be around
<IntuitiveNipple> ha.. found it! https://lists.ubuntu.com/archives/kernel-team/2008-September/003171.html
<IntuitiveNipple> Tim-away: Looks like the same forgetfulness as happened Gutsy > Hardy
<IntuitiveNipple> maxb: {WT} ?
<maxb> yes
<maxb> I guess I could send a patch to the kernel team, but it's a single character :-)
<IntuitiveNipple> ok
<IntuitiveNipple> they all count :D
<maco> hi amber
<maco> are you going to try to help with the bug jamming
<maco> ?
<maco> er...wrong channel
#ubuntu-kernel 2009-02-22
<maco> pgraner: hello?
<akgraner> maco: he'll be right back...he is cooking dinner
<akgraner> maco: it's his night...:)
<laga> akgraner: he converted you to ubuntu the other day, right? i seem to remember reading about that on planet ubuntu
<akgraner> laga: yep
<akgraner> luvin' it
<maco> laga: if you follow planet ubuntu women or ubuntu weblogs, you can see what she thinks about it
<akgraner> laga: correction he didn't the t-shirt did....
<laga> akgraner: good. took me a minute to figure out why you knew he was cooking dinner when i didn't see it in the chat logs. ;)
<maco> seeing akgraner  and assuming #ubuntu-women was why i was all OT before
<akgraner> laga: :)
<laga> akgraner: matching last names was a bit of a giveaway, though. :)
<akgraner> laga: he claims me once in a while...
<akgraner> maco: he's almost finished...sorry
<maco> haha thats fine. i'm both eating and trying to find kirkland to get him to ok a patch
<akgraner> maco: ok
<pgraner> maco: bug no?
<maco> pgraner: bug 327949
<ubot3> maco: Error: Could not parse data returned by Malone: The read operation timed out
<maco> -_-
<maco> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/327949
 * pgraner looks
<maco> this was marked as a dupe of the acpi_fakekey is broken bug, but then slangasek said fakekey's going away and the quirks should be in the kernel, stop relying on fakekey
<maco> so i'd like to learn to fix these hotkey bugs. i believe mine belongs in drivers/misc/asus_laptop.c
<pgraner> maco: your understanding is correct... we are quirking in the kernel now... apw is our hot key expert I need to check out the source and see if thats the right place (sounds like it tho)
<maco> pgraner: i do see ASUS_HANDLE(ls_switch, ASUS_HOTK_PREFIX "ALSC"); in the area under the /* display */ comment, so i *think* that's what i should look at
<pgraner> maco: so when you hit the hot key you don't see a scan code? ie. if you run xev in a term and it the hotkey you don't see anything?
<maco> exactly
<maco> pgraner: ^
<maco> nothing from xev or input-events
<pgraner> maco: what keys are borked?
<maco> video output switch and www key
<pgraner> maco: looks like those keys are not defined in the source 
<pgraner> #define ATKD_BR_UP       0x10
<pgraner> #define ATKD_BR_DOWN     0x20
<pgraner> #define ATKD_LCD_ON      0x33
<pgraner> #define ATKD_LCD_OFF     0x34
<pgraner> maco: it looks like the driver expects the DSDT table to provide those values, you'll have to disssasemble the DSDT to see what hex value its passing and then you can add it, and write the function to toggle it.
<maco> ok...
<maco> um, how do i find the dsdt?
<pgraner> maco: instructions are here: https://wiki.ubuntu.com/BIOSandUbuntu
 * maco looks
<pgraner> maco: I'll have apw or cking write a "hotkey" section to show you where to look in the dsdt for the hotkey info
 * pgraner has very little dsdt-fu
<maco> O_O wow iasl rocks
<maco> objdump is the only way i've ever tried disassembling anything, and that results in assembly
<maco> er, that's obvious i guess...seeing as it's disassembling....but i'm surprised to see stuff i can read easily instead of intel asm
<maco> (by which i mean, there are english words involved)
<pgraner> maco: lol, enjoy, I'll have my guys edit that page so I would suggest you subscribe to it. Does that give you enough to go on?
<maco> i'm attempting to see if, aside from reading this, i can actually understand any of what's going on :P
<maco> though i think i'll have to stop soon and wait for tomorrow since i actually have to write some assembly tonight for school
<maco> pgraner: thank you
<pgraner> maco: no prob
<penguin42> do you guys use any particular tags on bugs associated with the linux package - it strikes me you must get tons of stuff that could often be grouped into different things (e.g. USB, optical drives etc)
#ubuntu-kernel 2010-02-22
<qwer> anyone here know a crapload about linux drivers?
<qwer> I'm fairly knowledgeable, but I've a problem that no on in any other channel has been able to help me solve for about 2 weeks
<qwer> anyway, I'll just tell the story, mysteriously ubuntu 10.04 detects the sata_mv driver properly - as well as an old slackware install cd - I've tried about a dozen recent and current distros though - and even after mod probing sata_mv -> no block devices found.......I've no idea how to continue troubleshooting - I've messed with udevadm, modprobe, etc
<qwer> this has taken many hours out of my life, so I'd be happy to paypal anyone money if they help me fix it
<jk-> so 10.4 does work?
<jk-> (and what sata controller(s) do you have?)
<qwer> this is the hercules II by Marvell, supposedly great linux support, uses sata_mv kernel module
<jk-> so you have the module loaded, but no block devices?
<jk-> (and could you paste the output of: lspci -n | grep 11ab
<qwer> okay let me boot and try again
<qwer> you want me to do this with one that is working, or the huge majority that arent?
<jk-> well, what are you trying to do? :)
<jk-> (get 9.10 working? or something else?)
<qwer> 43:01.0 0100: 11ab:6081 (rev 09)
<qwer> I'm just trying to install, but none of the distros that will install recognize my hardware/show block devices/modprobe sata_mv, etc
<qwer> 42:01* sorry
<jk-> so you're not keen just to install 10.4 ?
<qwer> it barely works
<qwer> and I'm not going to be using on the server anyway
<jk-> ok
<qwer> I just have no idea why it works
<qwer> I'd love to figure that out, as I've been trying to get this computer (a box that needs this controller to see disksS) to work for weeks
<jk-> so what are you planning to install on this?
<qwer> arch
<qwer> does it matter?
<qwer> you have any ideas?
<qwer> I'll install whatever you want if you can get something to install
<lifeless> qwer: install 10.4 then :) it works 
<qwer> not really, too beta, lots of other problems, this is a server, I don't know WHY it works, same could be said for the fairly old slack disks that for some reason sees/configures the sata properly too
<jk-> looks like that device has been supported for quite a while; most recent distros should have it
<qwer> indeed, I've read all about that - supposedly awesome linux support - that is why I paid another 100 dollars for a sata controller after the first had terrible support
<qwer> I've done a crap load of troubleshooting, maybe if you can aide me with a bit more, I can find out why it isnt
<jk-> so maybe boot 9.10, wait 'till it drops to the initramfs shell and we can do some digging
<qwer> I've been digging for weeks, im stuck
<RAOF> You could also pass âbreak=mountâ to the kernel command line.
<qwer> did that lspci give you any ideas?
<RAOF> If it works in Lucid, does it work in all new kernels?
<jk-> it just tells me which device you have
<qwer> is that the same as hercules II sata controller?
<jk-> no idea about the names
<qwer> oh, what is 11ab then?
<jk-> marvell's vendor ID
<qwer> oh
<qwer> well give me some other stuff you want readouts on, maybe it will give you some ideas
<jk-> would be good to get it booted to a shell on a broken system
<qwer> i am
<qwer> thats how i got that readout, heh
<jk-> so `ls /sys/block/` gives nothing?
<qwer> omfg, it might have started to work for no reason at all, maybe the hardware is flakey - I'm checking a few things (amazing since I've been messing with this for weeks)
<qwer> k, I rebooted and tried the 64bit kernel, now there's no 11ab, hopefully it wasn't a fluke and the 32 sees it again
<qwer> bam, the 32bit kernel works - wow
<qwer> okay, hdparm says buffered disk reads are 2.5mb/sec?!
<qwer> jk-, I seem to have got it working though - and it seems to be a 64bit kernel bug, since only the 32bit works 
<qwer> i think i was mostly trying 64bit kernels at first
<qwer> and those two that works miraculously were 32bit
<twb> When booting lucid kernels, vga16fb is loaded by default.  How do I stop this?  None of video=vga16:off, video=vga16fb:off, vga=normal and nofb worked.
<twb> I can't reproduce this issue on sid.
<qwer> Wholy fucking shit - a bios update fixed EVERYTHING! And I've been using this hardware for 4 years...
<twb> "Holy"
<qwer> dude, this occasion calls for a serious misspelling
<qwer> I am flabbergasted
<twb> As you will
<qwer> As you are, sir
<qwer> I've been using this system for 4 years, and this mysteriousness took days out of my life
<qwer> little did I know could this be tracked back to a bios update
<twb> AHS
<qwer> always have sex?
<twb> All Hardware Sucks
<qwer> ahhh
<qwer> makes a bit more sense
<qwer> where is that from, and what do they say about softare?
<qwer> software*
<twb> ASS
<twb> It's from the monastery
<matti> :]
<twb> DNA is their third mantra.
<qwer> I wish I got your joke
<twb> Down, not across.
<qwer> because I'm in a great mood now
<qwer> lol
<matti> qwer: ;]
<twb> http://www.faqs.org/faqs/sysadmin-recovery/
<twb> I was reading the ITS tourist policy today, and I ran across "Use the :LUSER command to tell other users that you need help" or so.  It was a nostalgic moment, I can tell you.
<lool> apw: is there time for another linux upload before A3?
<lool> apw: (It would be great to have working initrd support with versatile in A3; currently it's busted)
<lool> I'm tentatively milestoning this as "Low" importance for A3; it's not dramatic if we miss the target  ;)
<apw> lool, i suspect i won't get a linux upload in, as i have so many arm ones pending which have key bugs in
<lool> apw: I understand, thanks either way
<apw> smb, this trigger-happy patch set ... whats the gen there, is this already in karmic or something?
<smb> apw, No, its not even upstream. (see cherry-picked from linux-next)
<smb> I just happen to be sort of involved in the development and we got testing
<apw> ahh so this is fixing a real bug ... for a real user of ours ... ok
<smb> apw, Yeah, hard to say how many. But there seem to be people out there capable to operate joysticks with more than 15 buttons
<smb> You could consider it as a regression even
<apw> i don't normally play games which require me to take off my socks
<persia> Good day.  I notice that all the kernel uploads get reported to the ubuntu-mobile mailing list.  I wondered why there, and not to ubuntu-devel.  I would think it would be of more general interest.
<smb> As we fixed something else which broke it
<persia> smb: I have at least four joysticks that have > 15 buttons if you need to test something.
<apw> persia, they get reported to the teams which  have asked for specific reports
<persia> apw: Would it improve your workflow to only have to report to the one team (ubuntu-devel@) ?
<apw> i'd actually expect most people who really cared to get the email via the lucid-changes list ... crtainly i do
 * persia suspects it would improve other workflows
<apw> ubuntu-devel is pretty noisy ... i suspect the installer would want it sent to them specifically regardless
<smb> persia, Only if beyond 30 or so. (Saitek X52) 
<persia> I have one of those :)
<persia> My first patch ever to Ubuntu was to make it work with vegastrike, even :)
<smb> persia, Then in should have stopped being detected since Karmic (as a joystick) ;-)
<persia> I don't have the X52 Pro though (it has 2 more buttons)
<persia> smb: It worked in Karmic, at least for some of the buttons.  I used it for some testing with input-utils for a user.
<persia> But I didn't try *all* the buttons.
<persia> Can we make it work again?
<apw> now i know you have one, never :)
<persia> There are some keyboards that are implemented as joysticks internally, and have >60 buttons.
<smb> Thats two patchs I was proposing for Lucid
<persia> smb: Please subscribe me to the bugs if you like, and I'll confirm behavioural changes.
<persia> For Saitek, I have the X52 and Strategic Commander, which both exhibit fairly odd characteristics for "joysticks".
<persia> But most of my joysticks/controllers are more pedestrian.
<smb> The bug was/is bug 492056
<ubot3> Malone bug 492056 in linux "Saitek X52 Joystick does not work" [Medium,Triaged] https://launchpad.net/bugs/492056
<smb> There is a test kernel linked. Though I probably have a hard time keeping up with newer Lucid kernels
<persia> smb: So you need a retest for each kernel release?
<smb> persia, I believe the one test is enough. If you had the same problem, the joystick would not have been detected as a joystick (joydev) as the number of buttons made it include BTN_DIGI and digitizers were blacklisted not to be joysticks
<persia> And presumably you need testing with all classes of unusual device (so left-hand gamepad keyboards, super joysticks, etc.)
 * persia laughs at repeated BTN_TRIGGER_HAPPY
<smb> It makes the people with many triggers happy :)
<persia> So, won't this break for stuff like keyboards with integrated joysticks that require both mappings?
<persia> Or like the Nostromo n52Pro which is a joystick and a mouse and a keyboard?
<smb> persia, Would those not have the normal keys as keys and only joystick buttons as buttons. Well, if you got time you are welcome to try that test kernel with all your odd devices
<smb> As far as I understand the code, the additional mapping is only done for class joystick buttons and that seems to be part of the hid descriptor
<persia> smb: Depends on the device.  The Saitek Strategic Commander is special in that it implements them all as joystick buttons in hardware.
<persia> I don't have a Microsoft Sidewinder Commander though, which would probably be the ultimate test for this.  It had enough buttons (implemented as joystick buttons) that people used it as a typing input device.
<persia> smb: Is there a lucid test kernel available?  I'm only seeing karmic listed in the bug.
<smb> Doh, never underestimate hw developers crazieness. The test kernel is actually lucid
<smb> Looks for the link to my people page
<persia> Found it.
<persia> I just saw comments about it being karmic.
<persia> I'll give that a test tomorrow.
<smb> Cool, thanks.
<persia> And please feel free to poke me if you need any sort of joystick testing.  I have a collection, and care about them working (although I don't use them as much as I'd like to have time to do)
<smb> Sure, now that I know. Atm, its the only problem I am aware of
<persia> Well, there's also an issue with how we're mapping joysticks with /dev/jsN and /dev/eventN, but that's a userspace bug (which I hope to find time to fix before lucid release).
<persia> And there's an issue with the joystick X input driver that certain devices get reversed axes.
<persia> And ...
<persia> (but it's all userspace)
<ricotz> hello, anyone here willing to answer a question?
<ricotz> i have a clean updated lucid install, and the cpu fan working normal on cold boot, when rebooting the fan spins up but doesnt spin down while lucid booting up, this is no temperature problem
<ricotz> so i think this should be a kernel problem
<ricotz> it is a hp 2510p notebook
<crimsun> apw: RE: hda_beep.c patch proposed for lucid, I concur that it appears (according to the git trees on zinc) that enabled = 1, but that means that the changelog entry for 2.6.28-13.44 is actually incorrect.
<crimsun> apw: and indeed, I can find no actual git history of the patch being applied to sound/pci/hda/hda_beep.c in smb's jaunty or the ubuntu-jaunty trees.
<crimsun> which probably would explain why it was never applied to karmic
<apw> crimsun, so the odd thing is that karmic doesn't have beep = 0 and yet the beep was not in karmic and appears in lucid so somethign else has changed... what i don't  know
<crimsun> apw: there was that whole libgnome mess in karmic to disable the system beep, but that's just one very small part
<crimsun> but the root of this particular issue is that the patch seems to never have been applied
<apw> ok so i'll get with smb to try and find out what the heck happened there
<smb> apw, Hmmm...
<apw> crimsun, what are you seeing in the 13.44 changelog?  i see no mention of diabling beep
<crimsun> [ Luke Yelavich ]
<crimsun>   * disable CONFIG_SND_HDA_INPUT_BEEP on amd64 and i386
<crimsun>     - LP: #331589
<apw> hrm
<apw> ahh thats -12.43
<apw> crimsun, so that is a config change, not a code change
 * apw goes find out why the config change is undone
<crimsun> ah, thanks
<apw> it seemed to be undone in karmic ... and we didn't seem to have the whining there we have in lucid ... hrm
<crimsun> perhaps beep was unmuted somehow and simply got saved as part of the state
<apw> well we tend to unmute everything under the sun on installing a new kernel
<apw> at least thats my experience ... i have always assumed that was userspace doing that
<crimsun> I'll chase up the alsa-utils end; we don't use alsactl init 
<apw> ok cool ...
<crimsun> eventually all this cruft in /sbin/alsa-utils needs to be converted over to /usr/share/alsa/init/*
<apw> crimsun/smb, i have this vague memory of turning it off in jaunty, then we put it back in karmic cause something in userspace was making sure Pc Beep was muted, and i think themuso was involved in that ... buts its a long time ago
<smb> Maybe that was when it was muted by something else and replaced by another sound. At least I don't seem to have that beep. Or maybe it needs a boot to textmode without gnome
<apw> smb, good thought ... there it is on VT-1
<apw> hit backspace on the shell and BZZZT
<crimsun> heh. If you have a 'Beep' mixer element, see amixer get 'Beep'
<crimsun> ( ->  amixer set 'Beep' 0% mute )
<apw> crimsun, yeah this is actually a different bug ... the vile beep i have here is changing volume when the mixer goes up and down
<apw> previously it would change frequency from vile deepness to ear splitting high
<smb> Strange- Seems I got one that does a beep but is not silent on 0...
<apw> so i think we have a new bug ... pc beep really makes a nasty fart noise
<apw> and i think this is relativly new
<smb> Here hda(alc268) it seems to work
<apw> yeah and mine is hda(Intel GM45 something something)
<apw> and is not well
<crimsun> ick, we're missing the beep consolidation that's in 2.6.33
<crimsun> namely, http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=123c07aeddd71fbb295842a8c19866e780b9a100 and its follow-on fixes 13dab08, 5f81669, 411fe85, 54f7190)
<smb> Looks "slightly" invasive
<crimsun> yeah, I don't think it's really all that useful for the release kernel given that there are cod alsa-driver builds for people really wanting it
<crimsun> apw: / smb: anyhoo, thanks for looking closer
<apw> crimsun, np.  i think we want to get whoever had the original issue to file a bug so we get the alsainfo off them
<apw> then we can try and find the codec which is affected, i suspect its the intel own codecs currently
<philsf> crimsun, I had a disconnection yesterday before getting your answer on my USB problem ( http://pastebin.com/f489fcdd0 ). you said something about driver or hw, and I think it's not hw. how can I test if if it's a driver issue?
<TheMuso> apw: It was turned off in jaunty, then a configs/packaging metadata shuffle re-enabled it again.
<tgardner> apw, lbm_nouveau appears to be working on my Dell w/nVidia, but I was a bit surprised to get an LBM package without selecting it.
<lifeless> tgardner: 
<lifeless> CONFIG_TASK_DELAY_ACCT not enabled in kernel - do you know anything about this? 
<lifeless> it was on in karmic, but is off in lucid
#ubuntu-kernel 2010-02-23
<ripperda> hello
<ripperda> hello, I'm having some trouble with a kernel serial console and hoping someone could lend a hand
<ripperda> I have a serial console working and getting boot messages. but no longer get messages once the full OS loads
<matti> :)
<pa> hi
<pa> do you know whether ubuntu kernel supports geoip target for netfilter, or if i do have to patch myself?
<cnd> tgardner, back at the platform sprint we brought the isl388* firmware for prism_softmac cards from karmic into lucid
<cnd> It turns out I put the fw files in the wrong place
<cnd> I'm looking to rectify it, but I'm realizing now that I can't find a license for the fw
<cnd> I'm wondering if they should be in linux-firmware-nonfree
<tgardner> cnd, if there is no license, then yes, it should go into non-free
<cnd> tgardner, ok, I'll work on that
<cnd> tgardner, as part of the prism fix, we need to revert the commit that added it into linux-firmware.git
<cnd> is it easiest just to send an email to kernel-team requesting the revert of the commit id?
<cnd> I assume that's easier than making a pull request for just a single commit revert
<tgardner> cnd, no, a pull request is fine. I've still got to make the packaging changes on top of that
<cnd> tgardner, k
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<cnd> pgraner, I'm looking at a huawei 3g bug in lucid, apw mentioned you might have the same card?
<cnd> bug 520372
<ubot3> Malone bug 520372 in linux "Huawei K3520 connection problems (Receive serial link is not 8-bit clean: Problem: all had bit 7 set to 0)" [Medium,Incomplete] https://launchpad.net/bugs/520372
<pgraner> cnd: nope I have a Novatel
<cnd> what model? I think novatels may be huawei rebranded
<bjf> ##
<bjf> ## Meeting starting now
<bjf> ##
 * smb is here
<matti> matti PRESENT
<matti> Ops ;]
<matti> PRESENT
 * smb was on the wrong channel. Meeting is in #ubuntu-meeting
<matti> smb: Ah.
<smb> matti, Though its over by now
<matti> I was on sudden meeting at work :<
<cnd> apw, when you talk about a potential dep issue with the firmware packages, what specifically is the issue?
<cnd> just files?
<apw> was the version with the files in linux-firmware ever uploaded?
<apw> if so then the files are now in two packages, which will break
<tgardner> apw, yes
<cnd> I believe so, but there won't be a file collision
<cnd> because the linux-firmware actually had them in the wrong location
<apw> on upgrade unless the l-f-nf has a 'conflicts: xxx' or something
<apw> ahh then we get away with it by luck ...
<cnd> so linux-firmware put them in /lib/firmware/prism54_softmac
<cnd> but the new linux-firmware-nonfree puts them in /lib/firmware
<cnd> where they should be
<apw> then we don't have an issue, cause there really is no collission, good enough
<tgardner> cnd, what about the original prism54/* files?
<cnd> cool
<cnd> tgardner, when I was looking for license I read a bit
<cnd> they are firmwares for older versions of the driver
<cnd> and are not used in lucid's kernel
<tgardner> cnd, ah, thats right. we're just dropping them.
<cnd> the new firmwares cover all of the same cards as the old firmwares
<tgardner> apw, I'll make sure the packaging is right before I upload ...
<apw> are we dropping any we get from our upstream here?
<apw> tgardner, yeah i figured you'd know what to do if there was an issue, just wanted to highlight it
<cnd> apw, these don't come from upstream (if you're thinking of dwmw2's tree)
<apw> indeed.  cool... 
<apw> ..
#ubuntu-kernel 2010-02-24
<gnomefreak> what is the package i can use to report kernel bugs? tried using ubuntu-bug linux and after i answer the questions i get a dialog saying its not a genuine ubuntu package
<apw> gnomefreak, which kernel do you have installed
<apw> as ubuntu-bug linux is the correct incantation
<gnomefreak> i have problems with 2.6.32-14-generic #20 so im using -13
<apw> what does dpkg -l | grep linux-image | grep -- -13 
<apw> say
<apw> sorry -14
<apw> gnomefreak, ^^
<gnomefreak> apw: ii  linux-image-2.6.31-14-generic 2.6.31-14.48 and ii  linux-image-2.6.32-14-generic 2.6.32-14.20
<apw> hmm ... that seems completely sane
<gnomefreak> apw: i get frequency out of range
<gnomefreak> -13 works fine
<apw> out of range on your monitor?
<apw> what graphics h/w
<gnomefreak> apw: yes and nvidia 
<apw> probabally related to a switch to nouveau
<apw> so yes we would want a bug ...
<gnomefreak> apw: that makes sense
<apw> you could try reporting the bug manually
<apw> and apport-collect bug# against it
<gnomefreak> apw: ok on nouveau or kernel
<apw> kernel as its doing KMS
<apw> you could try booting nomodeset and see how that looks
<gnomefreak> not sure how to boot with nomodeset
<apw> adding nomodeset in grub to the kernel command line
<gnomefreak> ok ill try that after i report the bug 
<gnomefreak> apport-collect is crashing after giving access so i will just try nomodeset for now. 
<gnomefreak> apw: for some reason it happen just that time. it worked this time normally
<apw> hrm
<gnomefreak> i havent done updates yet 
<tgardner> cnd, did you ever bottom out on the non-free firmware issues?
<cnd> tgardner: what do you mean?
<cnd> (I haven't read my inbox yet, if that's part of it)
<tgardner> the prism54 BS
<cnd> tgardner: it sounds like we just need to ship all the prism firmwares
<cnd> I'll get that in my tree today for you to pull
<tgardner> cnd, the non-free package isn't in git. just lemme know where you have it staged on zinc
<cnd> yeah, forgot about that
<cnd> I'll get it to you one way or another :)
<cnd> tgardner: you didn't uploade the 1.6 version I posted right?
<cnd> so I don't need to dch -i again?
<tgardner> cnd, nope
<cnd> k
<tgardner> cnd, you can always tell the current version of a package by looking in Launchpad, e.g., http://launchpad.net/ubuntu/+source/linux
<cnd> k
<Laibsch> Hi
<Laibsch> Would you guys please be so kind to cherry-pick wifi support for Asus netbooks as I wrote in bug 521967?
<ubot3> Malone bug 521967 in linux "support for new atheros wifi chipset" [Unknown,Fix released] https://launchpad.net/bugs/521967
<Laibsch> I guess it's quite important for lucid (and maybe even karmic, it's still two more months befor lucid is out), I tested it all the way back to .31 and it works fine
<tgardner> Laibsch, is that set for the .34 merge window?
<Laibsch> sorry, dunno
<Laibsch> it's slowly making way to mainline
<Laibsch> but I don't think it's already hit it
<tgardner> Laibsch, it'll show up in compat-wireless-stable then.
<Laibsch> OK
<Laibsch> IOW, no need to specifically backport it, it will automatically be there before the final release is made?
<tgardner> Laibsch, depends on when .34 closes, but yeah, its quite likely.
<Laibsch> OK
<Laibsch> good
<Laibsch> the ticket is open and targeted, so in any case, it shouldn't be forgotten
<Laibsch> would of course be nice to have it available in testing sooner rather than later ;-)
<Laibsch> tgardner: what about karmic, will it automatically show up there as well ?
<tgardner> Laibsch, that is less likely.
<Laibsch> Those are very popular netbooks
<Laibsch> I think it's quite important to have support for them in karmic
<lool> smb: Heya; is there a karmic-proposed update planned for the LXC stuff?
<lool> I think I saw the patch go through, and get an ack, but I didn't see the kernel in proposed
<lool> perhaps you have set some specific upload dates for these?
<smb> lool, Its only in the repo and I want to get the current proposed to updates and likely some other upload in between
<smb> So I cannot give a hard date
<smb> lool, You can get kernels from the kernel-ppa PPA if you want to test things
<lool> smb: Ok; thanks
<LuserN800> anyone know how to handle usb external harddrives that sometimes go into powersave mode? My debian does not like this and can't even remount it. I have to powercycle the disk. Any option I have to set?
<johanbr> LuserN800, if you've already turned off power management with hdparm, it's probably the drive's firmware doing that on its own
<johanbr> if so, any tool to change that would have to be vendor-specific
<LuserN800> johanbr, no I haven't switched it off
<LuserN800> in hdparm
<johanbr> try doing that
<johanbr> it may or may not work... power management on usb drives is a bit iffy
<LuserN800> But.. does linux handle this for some drive (correct firmware, documented..). The best would be if I could keep it.
<LuserN800> I will try right now hdparm. thanks a lot.
<LuserN800> Well, I'll have to wait 6h or something to see if it works. now the disk just floods me with "device descriptor read/8, error -110"
<AnAnt> Hello is linux kernel 2.6.32.9 packaged yet ?
<apw> nope the repo is frozen for a-3
<AnAnt> apw: not even the vanilla kernel ?
<apw> its in the mainline archive
<AnAnt> apw: URL please
<apw> https://wiki.ubuntu.com/KernelTeam/MainlineBuilds
<AnAnt> thanks
<apw> cking, what was that block tracer called?
<cking> blktrace
<cking> http://smackerelofopinion.blogspot.com/2009/10/block-io-layer-tracing-using-blktrace.html
<apw> heh thanks
<AnAnt> sl-modem kernel modules don't work correctly since kernel 2.6.31 (even against vanilla kernel)
<AnAnt> can someone help with that ?
<bjf> AnAnt, do you have a bug number?
<Laibsch> bjf: https://bugs.launchpad.net/ubuntu/+source/sl-modem/+bug/375148
<ubot3> Malone bug 375148 in sl-modem "no more /dev/ttySL0 device node" [High,Confirmed] 
<Laibsch> ;)
<Laibsch> bjf: skim through the many comments and fast-forward to comment 70
<Laibsch> skim, not skip ;-)
<AnAnt> Laibsch: this bug is not related
<AnAnt> not related to >= 2.6.31 kernel issue
<Laibsch> not? I thought this was the main problem we were talking about
<Laibsch> but you're right
<Laibsch> it occured before .31
<Laibsch> so, you shouldn't say they don't work correctly since 2.6.31
<AnAnt> LP #375148 is not related to kernel, it's related to udev
<Laibsch> which is closely related and if you don't think that bug has anything to do with the kernel, then why are you asking me to try with today's mainline kernel to see if that problem is fixed?
<Laibsch> you're comment is pretty scary
<Laibsch> udev IS kernel
<AnAnt> I didn't say that the request to test with today's mainline kernel has to do with #375148
<AnAnt> ok, let me put it another way, 375148 is about sl-modem not supporting creating device nodes through udev, but rather static device nodes
<Laibsch> AnAnt: "doesn't work correctly" is about the worst problem description you can give.  We've yet to hear anything else.
<tgardner> apw, what would cause an drm:intelfb_panic ? (when modeset=1)
<apw> tgardner, not sure i've seen any specific ones
<apw> pastebin the panic stack perhasp?
<tgardner> yeah, right (snort!)
<tgardner> apw, I think it has to do with interrupts. not sure yet, but I have the HW
<apw> is this with the franken-kenrnel?
<tgardner> apw, no, chromeos right now
<tgardner> which is essentially Karmic with diff config options
<apw> there was some interrupt patches recenting in stable i think
<tgardner> apw, I'm gonna try booting stock Lucid
<apw> good test me thinks
<manjo> anyone know the diff between broadcom-sta-source and bcmwl-kernel-source in lucid ? 
<manjo> they both claim to be broadcom wireless souce 
<manjo> jjohansen, ^^ ? 
<jjohansen> manjo: nope?
<manjo> apw, ? ^^
<apw> nope
<jjohansen> my wild guess would be a drivers for a different series of wireless
<manjo> apt cache search broadcom list both... after I enabled multiverse & partners ... 
<manjo> jjohansen, do you know if there is a gui to enable multiverse ? or vi /etc/apt/sources.list is the only way ? 
<manjo> jjohansen, I think I found the ans
<manjo> system->software sourecs
<jjohansen> manjo: got into System>Adminstration>software sources
<jjohansen> yep
<manjo> yep... I should have looked closely before asking :)
<cbmuser> hoi, 2.6.33 is out; anyone has installable debs already?
<apw> cbmuser, the mainline builds system will spot it 'shortly' and make some
 * jk- high-fives the mainline build system
#ubuntu-kernel 2010-02-25
<rackerhacker> jjohansen: i'm back with a linux-ec2 question if you're around ;)
<jjohansen> sure
<jjohansen> though I have a couple bugs against it, that I still have to look into
<jjohansen> rackerhacker: ^
<rackerhacker> ah, okay, that may be unrelated
<rackerhacker> i git a git clone of the latest, picked up the ec2 branch, but the fdr doesn't generate debian.ec2/build any longer
<rackerhacker> caught me a little off guard
<jjohansen> rackerhacker: do an fdr clean first
<rackerhacker> i did that... did a clean followed by a prepare-ec2
<jjohansen> how about binary-ec2
<jjohansen> or just binary
<rackerhacker> hmm, i'll give that a try
<rackerhacker> i think i owe you a case of beer for how much you've helped already ;)
<jjohansen> warning on this kernel it seem there is an issue with it not booting Bug #527208
<ubot3> Malone bug 527208 in linux-ec2 "ec2 instance fails boot, no console output on  c1.xlarge" [Medium,Confirmed] https://launchpad.net/bugs/527208
<jjohansen> on c1.xlarge
<rackerhacker> i'll go take a look at that one
<jjohansen> hopefully we can get it cleaned up soon, just haven't gotten to it yet
<rackerhacker> so far, it's been a rock solid kernel
<rackerhacker> but i'm not using it at ec2 ;)
<jjohansen> rackerhacker: glad to here its stable for you
<jjohansen> I assume your using it as dom0
<rackerhacker> domU actually
<jjohansen> ah, just not on ec2
<rackerhacker> i haven't tested it as a dom0 to be honest
<jjohansen> me neither :)
<rackerhacker> yeah, not on ec2... i work for a competitor
<rackerhacker> you haven't tried it as a dom0?
<jjohansen> nope, I have been to busy with other things
<rackerhacker> i could imagine... that lucid release is coming up quickly
<jjohansen> my focuses has been making sure it works for EC2, and then get back to other stuff
<jjohansen> yep, frighteningly fast
<rackerhacker> well i can certainly toss it around as a dom0 if that'd help you in the future
<rackerhacker> 2.6.18 is getting old :/
<jjohansen> rackerhacker: be my guest but I don't know that its something that will ever be supported again
<rackerhacker> alrighty
<rackerhacker> looks like fdr binary-ec2 just starts building it immediately
<rackerhacker> these are the steps i had noted from you before -> http://pastie.org/private/k0uazxqyxrrj0ygsp6qcq
<jjohansen> rackerhacker: yeah, the prepare isn't necessary if you are just looking to build
<jjohansen> fdr clean followed by fdr binary-ec2 will do
<rackerhacker> ah, i thought prepare was necessary to set up debian.ec2/build
<jjohansen> build will do it if it doesn't find the prepare stamp
<jjohansen> so it gets done, you just don't manually have to do it
<jjohansen> I do it to update the version string etc
<rackerhacker> ah, so dump my .config into the base directory and use binary-ec2?
<jjohansen> nope
<rackerhacker> sorry, i'm still new to the ubuntu way of doing this :/
<jjohansen> if you are updating the config, you can either do
<jjohansen> fdr editconfigs
<jjohansen> and that will refactor configs etc
<jjohansen> or you do a prepare
<jjohansen> dump your new configs into build
<jjohansen> and touch the stamps
<jjohansen> you need to make sure to touch the stamps files in the build dir, other wise what you dump in there will get overwritten
<rackerhacker> ah, i think the prepare route is the way i need to go
<jjohansen> think standard make time based deps
<jjohansen> yeah, if you are updating the configs and don't want to maintain a patch in git
<jjohansen> the other option is doing fdr editconfigs
<jjohansen> commit your config changes to your tree
<jjohansen> and then when you fetch our tree rebase, so that your changes are applied over top
<jjohansen> of course config changes will probably break you patch
<rackerhacker> i didn't think of that... good idea
<jjohansen> if you do that, you shouldn't need the separate prepare step
<rackerhacker> awesome
<jjohansen> rackerhacker: question, would us moving to a pv-ops based kernel for EC2 affect you?
<rackerhacker> jjohansen: are you talking about dropping the ec2 patchset and making it more like the upstream?
<jjohansen> rackerhacker: yep
 * rackerhacker gasps
<jjohansen> not saying it is going to happen, but it could
<rackerhacker> hah, we're still using /dev/sda and tty1, so that'd be painful
<jjohansen> we tried it with karmic and ran into some pretty serious problems we couldn't resolve
<rackerhacker> i did a ton of testing with 2.6.31.6 w/pv_ops and had a lot of time skew issues
<jjohansen> hrmm, I wasn't aware of time skew issues
<rackerhacker> as much as 8 minutes after 3-4 days on that kernel
<rackerhacker> we had to pull it due to the complaints and search for an alternative
<jjohansen> hrmm, that is something I will have to try
<rackerhacker> one of the canonical folks works for us now and he made the linux-ec2 suggestion
<jjohansen> ah
<jjohansen> well banging on pv-ops again and seeing if I can't make it work is on my todo
<jjohansen> knowing issues, is a very good thing
<rackerhacker> i think the most painful part for me is getting our customers off /dev/sda and tty1
<rackerhacker> the xvda -> sda patch is simple, and it works fine
<rackerhacker> but getting hvc0 out and using tty1 instead is rough
<jjohansen> rackerhacker: I think atm we would be patching our kernels to use those as well
<jjohansen> rackerhacker: if I get a kernel that looks like it is working I will point you at it
<rackerhacker> jjohansen: i'll be happy to test for you
<jjohansen> thanks
<rackerhacker> and i might be able to get my company to get behind it with whatever's needed
<rackerhacker> i need to get pvgrub rolling ;)
<poolie> hi, i upgraded /backup on my lucid desktop to ext4 the other day
<poolie> now it's getting io errors along the lines of
<poolie> Feb 25 17:45:37 grace kernel: [37152.894557] EXT4-fs error (device dm-4): make_indexed_dir: invalid rec_len for '..' in inode 2933963
<poolie> is anyone interested in debugging this, or should i just fsck and try to recover?
<amitk> poolie: it might be worth it just to post your dmesg to a bug and post a link here
<poolie> ok, will do
<poolie> csurbhi/amitk, i filed https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/527644
<ubot3> Malone bug 527644 in linux "lucid ext4  make_indexed_dir: invalid rec_len for '..' in inode" [Undecided,New] 
<poolie> let me know if you want any more info or if you have any suggestions
<apw> apw
<apw> apw_
<apw> poolie, i assume you fskc'd it as part of the upgrade to ext4 ?
<poolie> i did
<poolie> only the one time recommended by the upgrade doc
<poolie> during which it updates the checksums
<apw> reasonable
<poolie> i haven't changed those files since then though
<poolie> they're unchanged since 20070706
<apw> its somewhat supprising that the encoding of . and .. in a directory would be broke
<poolie> i'm a bit concerned because i upgraded /home at the same time, perhaps foolishly
<apw_> you have me concerned too, as i was about to do my rootfs 
<lifeless> poolie: did you run the example fsck flags?
<poolie> -D etc, yes, of course
<lifeless> poolie: the main thing it needs to rebuild is the new bitmaps; the directory tuning isn't needed as part of ext4
<lifeless> poolie: [sometimes it pays to ask paranoid questions :P]
<poolie> oh
<lifeless> poolie: anyhow, that make_indexed_dir isn't part of the new ext4 features; it does sound alarming though.
<poolie> actually I did not use -0
<poolie> it sounds like an ext3 thing
<apw_> # tune2fs -O extents,uninit_bg,dir_index /dev/sdb1
<apw_> is that the one you turned on?
<poolie> actually it was http://kernelnewbies.org/Ext4
<poolie> so extents,uninit_bg,dir_index
<poolie> and then fsck -CDf
<lifeless> you probably had dir_index already, knoowing your machines
<poolie> yes, i probably did
<apw_> hrm, that would explain why you are the first to be mentioning it.  you should record that in the box
<apw_> bug even
<lifeless> apw_: I don't think its related; I *know* I had dir_index on - and nearly all ubuntu upgrades to ext4 will have had dir_index on.
<lifeless> we turned it on by default about 4? years back
 * apw_ checks his
<apw_> Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
<poolie> it's in /etc/mke2fs.conf or something
<lifeless> apw_: looks about right to me
<poolie> apw_: so i should probably leave and have dinner in a sec 
<poolie> if this is not just a glitch it seems like a bad bug so i'd like to help it get solved
<poolie> is there anything else i can do?
<lifeless> poolie: have you done another fsck? (just -f, no -D)
<poolie> yes, see the bug
<lifeless> poolie: ok, sorry :>
<poolie> many errors, which it won't fix with -p
<apw_> ok ... thanks for the report
<lifeless> apw: can I run something by you ?
<lifeless> when I run iotop
<lifeless> I get 'CONFIG_TASK_DELAY_ACCT not enabled in kernel, cannot determine SWAPIN and IO %'
<apw> yep, that one seemed to have a measurable cost i think
<lifeless> ><
<lifeless> is there a kernel with it on ? was very useful for figuring out what apps are being bad
<lifeless> the other thing is, do we build debug packages for the kernel? for use with oprofile?
<lifeless> years ago I filed a bug asking for this, and we started, but I can't seem to find them now...
<apw> i don't think we have a kerel with it on no
<apw> the debug packages are in the ddebs.ubuntu.com archive
<lifeless> apw: ok cool
<lifeless> thanks
<lifeless> apw: you might want to close the bug I opened about DELAY_ACCT then :>
<apw> there was some discussion about it on kernel-team, not sure if it got bottomed out on or not
<jxiong> hello
<jxiong> folks, I spent several hours to try to find the vmlinux file for my laptop
<jxiong> do you have any ideas?
<jxiong> Linux ubuntu 2.6.31-19-generic #56-Ubuntu SMP Thu Jan 28 02:39:34 UTC 2010 x86_64 GNU/Linux
<nigel_c> Should be in /boot/vmlinuz-2.6.31.19-generic
<smb> jxiong, Have you tried ddebs.ubuntu.com ? There should be ddeb packages for kernels
<jxiong> smb: yes, I tried.
<jxiong> it doesn't include something like linux-image-XXX-debug/dbgsym..
<nigel_c> apt-file search /boot/vmlinuz-2.6.31.19-generic?
<jxiong> nigel_c: thank you, what I'm searching for is vmlinux, which includes debug info
<jxiong> vmlinuz is an executable image, it's a compressed binary code
<nigel_c> I'm pretty sure all the Ubuntu kernels have the config options enabled that include debugging info, so you should just be able to run gdb on any vmlinux. Vmlinuz is just the same thing gzipped IIRC.
<smb> As the pre-compiled seem to have vanished again, the only way seems to "apt-get source ..." the linux-image source and the compile it yourself :(
<jxiong> what a pity
<apw> Keybuk, hey ... i am struggling to get you the page numbers for pages you don't have mapped
<apw> ie. as you don't have the pages actually present in ureadahead you don't have the pfn numbers so you don't have the pfn's to lookup kpageflags
<Keybuk> apw:  how do you mean?
<Keybuk> mmap maps the pages, no?
<apw> no they are not present as you have never referenced them
<apw> so you don't have them in your pagemaps to map ... blah
<apw> now i think i have a different way round this
<apw> i think i can return the additional info in the mincore result
<apw> which brings me to the fact i think you have  a bug in your mincore use
<apw> as you for if (!vec[x]) 
<apw> but the manual says you can't do that, you can only rely on the value of bit 0
<apw> i suspect returning that information in mincore would be pretty handy for you
<apw> but ... it does rely on all users of mincore reading the manual page
<apw> Keybuk, what do you think
<Keybuk> sounds reasonable
<Keybuk> someone changed the mincore() manpage <g>
<apw> that interface seems to only allow me to return very small amounts of info, no more than a few bits, which makes it hard to return anything more than 'used/unused'
<manjo> apw, http://voices.canonical.com/kernelteam/
<manjo> smb, http://voices.canonical.com/kernelteam/
<apw> Keybuk, hey how is that plymouth race the one which leads to 'return' being fatal ... who has that?
<Keybuk> I have the ball on that one
<Keybuk> though it's your fault, you and your buggy kernel
<apw> excellent ... whats wrong with my beautiful kernel :)
<smb> apw, apparently sound
<manjo> \http://www.sonystyle.com/webapp/wcs/stores/servlet/ProductDisplay?storeId=10151&catalogId=10551&langId=-1&productId=8198552921665974276
<cnd> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ec67bbedcf290ef182a897017f65a2707106c7f8
<tjaalton> cnd: probably needs the other two commits for 1.52 as well?
<apw> then its probabally too big for lucid
<cnd> tjaalton: I'm going to try to build a module with just that commit to see if it works
<cnd> but yeah, that commit alone is pretty huge
<tjaalton> this one looks quite sensible to me
<tjaalton> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=232f5693e5c9483e222528ef81979e42ea2f2908
<cnd> tjaalton: we tend to just backport fixes, so unless this fixes a bug people are having we probably won't backport it
<tjaalton> sooner or later they will ;)
<cnd> cnd, it may, but it may also introduce more issues
<apw> linux-image-2.6.32-15-generic-debug_2.6.32-15.21~ddebrenameapw1_i386.ddeb
<apw> smb, ^^
<cnd> so we have to be judicious
<tjaalton> that patch needs at least this one http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ec67bbedcf290ef182a897017f65a2707106c7f8
<tjaalton> or manual backporting, of course
<cnd> tjaalton: yes, that's the same that I posted above
<tjaalton> uh, damn
<cnd> I'm going to build a module with just that commit
<tjaalton> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ee54500d7b960984df125bdd0cd2105d6150e8f1
<tjaalton> this one
<cnd> tjaalton: I assume you have hw for this?
<tjaalton> no
<tjaalton> well, I have an intuos4
<tjaalton> but not the new stuff
<cnd> tjaalton: would you mind testing a module if I get one built?
<tjaalton> cnd: sure
<apw>   INSTALL debian/-generic/usr/lib/debug/lib/firmware/yam/1200.bin
<smb> seems to be missing somethign
<cnd> tjaalton: please subscribe to bug 516777, I'll post the stuff there
<ubot3> Malone bug 516777 in linux "HP Touchsmart tm2 requires newer wacom driver" [Low,Triaged] https://launchpad.net/bugs/516777
<tjaalton> cnd: you mean to test it doesn't break mine?
<cnd> tjaalton: yes
<cnd> I'll post a test module to that bug
<tjaalton> cnd: right, might as well upgrade the desktop to lucid then (and test that suspend thing :)
<bjf> smb, ring me back please
<cnd> smb, tjaalton, apw: test module is up at http://people.canonical.com/~cndougla/516777/wacom.ko
<Keybuk> apw: am I missing something here?
<Keybuk> the mainline 2.6.33 build is missing devtmpfs
<manjo> smb, apw cnd I am dropping off 
<apw> Keybuk, ahh ... its beacuse its being built on karmic ... 
<Keybuk> apw: FAIL
<apw> well it depends what you think they are for
<apw> originally they were for testing on karmic... what it highlights is we need them to be built for both
<apw> or ... more specifically ... they are built for one ... which one needs to be part of that information
<Keybuk> happily it proves you can still boot lucid without devtmpfs <g>
<apw> yeah just about, slow as hell mind
<apw> i'll have a think about what we should be doing there over beer tonight
<apw> i don't want to have to build them all twice, that would suck
<cnd> smb, tjaalton, apw: http://people.canonical.com/~cndougla/516777/i386/wacom.ko if you need it
<cnd> http://people.canonical.com/~cndougla/516777/amd64/wacom.ko for amd64 (I moved it)
<smb> cnd, Sorry to be wincing. The i386 is for 2.6.31-13... :(
<cnd> smb: what?
<cnd> grrr... how did that happen
<smb> ok, its 2.6.32-13
<cnd> smb: should be better now
 * smb looks
<Keybuk> apw: if I want to apply a patch to one of your mainline linux-source packages
<Keybuk> what do I have to do to stop the ABI checker eating me?
<apw> the mainline builds i think they are disabled in there
<apw> check the check-abi script to see whats in it
<Keybuk> ok
<Keybuk> http://people.freedesktop.org/~glisse/0001-drm-radeon-kms-initialize-set_surface_reg-reg-for-rs.patch
<Keybuk> this may end up on kernel-team if it works
<Keybuk> apw: argh
<Keybuk> in fact
<Keybuk> where *IS* the source package for mainline builds?
<apw> supposed to be with them
<Keybuk> isn't
<Keybuk> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33/
<apw> there is a 64mb source package there
<Keybuk> no there isn't
<Keybuk> there's no .dsc or .tar.gz
<Keybuk> there's a deb that contains a tarfile
<Keybuk> but that *does not contain the debian directory or the config*
<apw> it doesn't ?
<Keybuk> no
<apw> well just checkout the one in our git tree into it
<Keybuk> example command?
<toabctl> hi
<toabctl> can anybody help with bug #527912 ?
<ubot3> Malone bug 527912 in xf86-input-wacom "Wacom Bamboo CTH-661 not recognized" [Undecided,New] https://launchpad.net/bugs/527912
<apw> git checkout origin/master debian debian.master
<Keybuk> apw: there's no .git either
<apw> so copy the debian* out of the lucid git tree
<Keybuk> will that work?
<Keybuk> all the changelog and versions and abis will be all wrong
<Keybuk> and it'll vomit the install
<apw> do you need that patch in .33 or in lucid ?
<Keybuk> I need to test the patch
<apw> if you want me to build you one
<Keybuk> I'm going to try and build off lucid
<Keybuk> that seems easiest
<Keybuk> I know how to do that <g>
<apw> yeah probabally is :)
<apw> toabctl, which release are you runningn
<toabctl> apw, lucid
<toabctl> apw, there changed something with wacom drivers
<apw> did it work before on karmic?
<toabctl> apw, i don't now. the board is 2 days old:)
<apw> so it may not be a supported version then
<apw> what usbid's does it have
<toabctl> apw, how can i get the usb id?
<apw> lsusb
<toabctl> apw, i think it should work with http://linuxwacom.sourceforge.net/index.php/main but this drivers only support xserver <= 1.6
<toabctl> apw, Bus 001 Device 010: ID 056a:00d3 Wacom Co., Ltd
<toabctl> apw, where's the place to find the usb-id <-> driver mapping?
<tjaalton> toabctl: the thing is that the X driver isn't being loaded for the device
<toabctl> tjaalton, and how can i fix this? maybe the driver supports the board...
<tjaalton> udevadm info --export-db
<tjaalton> attach that to the bug
<tjaalton> (need to add an apport hook for xf86-input-wacom)
<apw> tjaalton, we probabally should get that for kernel bugs too
<toabctl> tjaalton, added: see http://launchpadlibrarian.net/39785696/udevadm_info.txt
<tjaalton> apw: yeah
<apw> tjaalton, so does X input handle those direct?
<tjaalton> apw: via udev, yes. but they also need the kernel module for fancy features
<tjaalton> toabctl: thanks
<apw> ok ... so it may or may not work
<tjaalton> I need to check the list for bamboo
<tjaalton> toabctl: has it ever worked?
<toabctl> tjaalton, no. i got it 2 days ago
<toabctl> tjaalton, but there are comments on the web that i worked with karmic 
<tjaalton> huh, ok
<tjaalton> but it's a different driver on lucid, so something might be missing
<toabctl> tjaalton, the problem is (i think), that the wacom stuff changed completely with lucid (see alpha-2 release notes)
<tjaalton> like the udev rules for it
<tjaalton> oh really? :)
<tjaalton> (I know)
<toabctl> tjaalton, yes. hopefully just a udev rule is missing :)
<toabctl> tjaalton, the device is available in the output of udevadm. but what can i do now?
<tjaalton> toabctl: just wait for now
<toabctl> tjaalton, how long ?:-)
<bjf> toabctl, if it was working in karmic and you need the tablet, run karmic
<tjaalton> it doesn't have any ID_INPUT* stuff listed, so figuring out why input_id is not run
<bjf> toabctl, keep testing lucid alpha/beta releases and see when it gets fixed
<toabctl> bjf, i don't need the tablet. i'll give it back if it will not work in 2 weeks.
<toabctl> bjf, but i like to find out if it's possible that the tablet does the job.
<tjaalton> toabctl: could be that the kernel doesn't know it yet, otherwise it should be in the input subsystem I think
<bjf> toabctl, you could try a karmic live-cd image and see if it works
<manjo> JFo, bjf, applied you kernel-qa / tests patch and I implemented progress bar 
<manjo> JFo, bjf I will check in soon
<JFo> ok
<toabctl> tjaalton, in /lib/udev/rules.d/69-xserver-xorg-input-wacom.rules is no line for the id 056a:00d3 . maybe that's the problem? i don't know much about udev rules..
<tjaalton> toabctl: check bug 522318, there are new rules for a similar case where the subsystem is 'pnp'
<ubot3> Malone bug 522318 in xorg-server "Serial Tablet PCs not supported in lucid" [Medium,Fix committed] https://launchpad.net/bugs/522318
<tjaalton> toabctl: partly correct
<tjaalton> toabctl: I'll add something to the bugreport for you to try..
<toabctl> tjaalton, ok. thx
<tjaalton> toabctl: yeah I don't think wacom supports it yet, properly anyway. can't find the id from wacom_wac.c
<tjaalton> toabctl: is it the "pen & touch"
<tjaalton> ?
<toabctl> tjaalton, yes. pen & touch
<toabctl> tjaalton, some people say it works: see http://aur.archlinux.org/packages.php?ID=31540
<tjaalton> ok, those patches are not upstream then
<tjaalton> toabctl: there's a huge thread on linuxwacom-discuss about it
<toabctl> tjaalton, can give paste me a link ?
<tjaalton> the support might be in linuxwacom, but not yet in xf86-input-wacom..
<toabctl> tjaalton, and why does ubuntu no more supports linuxwacom?
<tjaalton> toabctl: because it doesn't work with xserver 1.7
<toabctl> and where is the source of xf86-input-wacom? the source package has as homepage http://linuxwacom.sf.net
<tjaalton> xf86-input-wacom is the way forward
<tjaalton> http://linuxwacom.git.sourceforge.net/git/gitweb.cgi?p=linuxwacom/xf86-input-wacom;a=summary
<toabctl> tjaalton, in the git repository is xf86-input-wacom-0.10.4 available, but the ubuntu packages has 0.10.3
<tjaalton> right
<tjaalton> the driver itself support it, as it turns out
<tjaalton> but not the kernel component
<cnd> bdmurray: re the wacom stuff, which arch did you test?
<bdmurray> amd64
<tjaalton> toabctl: maybe best to continue on ubuntu-x ->
<manjo> bjf, I pushed your changes and added progress indicator to copying log files 
<manjo> JFo, ^^
<toabctl> tjaalton, i asked on ubuntu-x, but nobody answered.
<JFo> cool, thanks manjo 
<tjaalton> toabctl: because you were having the discussion here already :)
<toabctl> ok. switch talk to #ubuntu-x
<cnd> bdmurray: can you paste uname -a?
<bdmurray> Linux artemis 2.6.32-14-generic #20-Ubuntu SMP Sat Feb 20 05:18:19 UTC 2010 x86_64 GNU/Linux
<bjf> manjo, two thoughts...
<cnd> apw, smb, do you know what would cause this when running insmod: wacom: no symbol version for module_layout
<bjf> manjo, one: I'd like to see all the log collection in a single function so it's real obvious where the log collection is happening
<manjo> bjf, did you see the changes I made after yours ?
<bjf> manjo, yes
<smb> cnd, I assumed it was my non-standard kernel. I would say it requires and external function module_layout
<manjo> so copy_files() does all the copying ie log collection .. 
<cnd> smb, could it be because I didn't build the whole kernel?
<cnd> just the drivers/input/tablet directory?
<smb> cnd, It might be
<bjf> manjo, no copy_files does the copy and the ui, I'd like to see the calls to copy_files in a single function "capture_logs" or some such
<manjo> ?
<cnd> smb, bdmurray: I'm going to try to rebuild the entire kernel and put up the resulting kernel, let's see how well that works
<bdmurray> cnd: okay
<apw> cnd it may well be yes.  its something modpost makes
<smb> cnd, you still might be able to just put up the module
<apw> scripts/mod/modpost.c:          mod->unres = alloc_symbol("module_layout", 0, mo
<bjf> manjo, lines 251 - 260
<cnd> smb, yeah, that's what I plan
<smb> cnd, I guess you just need the full compile to get a version function
<smb> versioned function
<manjo> bjf, oh ic 
<manjo> bjf, send me a patch
<manjo> bjf, I think that is a good point 
<bjf> manjo, actually I'm thinking I'd like the log and system information captured in a separate script which I could call without having to run the test
<bjf> manjo, what do you think of that?
<bjf> that may not have been very clear
 * manjo thinking ... 
<manjo> we can have it in a separate script 
<manjo> and source that script and use the function in kernel-qa as well
<bjf> manjo, the copy is happening at the very beginning, 
<manjo> so in kernel-qa you could do source new_script
<bjf> hmmm
<manjo> in case we want to use copy_files() anywhere 
<bjf> manjo, I'm running it right now and the progress bar has "[sudo] password for bradf:" in it
<manjo> yeah you are supposed to run sudo ./kernel-qa
<manjo> bjf, just type your passwd
<manjo> bjf, this is coz we have a sudo less environment usually
<manjo> bjf, I am also thinking of adding a function like ... exec_with_progress() .. so you can call it like exec_with_progress "somecmd parameters"
<bjf> manjo, if you put a "sudo date" before the first "copy_files" then the user is prompted for the password before the dialog comes up
<manjo> from the test case 
<manjo> bjf, no I should ask for the password in a dialog box 
<manjo> bjf, and I know how to do that 
<manjo> bjf, I did not do it coz we have passwd less env... but that is not good if we want to have it generic 
<bjf> manjo, why do you need to ask for it in a dialog box?
<manjo> bjf, so if you run ./kernel-qa it will ask for your passwd
<manjo> or kernel-qa needs to be installed with uid root 
<bjf> manjo, yes, and if you'd just put the "sudo date" as the first thing you get to type in your password and then the ui comes up
<bjf> it's simple
<manjo> ok
<manjo> bjf, dialog --passwordbox does it in a fancy way 
<bjf> manjo, I was looking at some bugs and I've noticed that checkbox is gathering hw information in an interesting way that we might look at
<manjo> bjf, :) we might just recreate checkbox finally 
<bjf> manjo, not intereted in that however, the hwinformation did look interesting, just a sec I'll get you a bug #
<manjo> bjf, I know what you are taking about 
<manjo> bjf, hwinfo and pciutils are not installed by default on servers for example 
<manjo> bjf, and its painful to deal with it coz checkbox croaks
<manjo> bjf, not that I am agianst the idea of looking into it ... just letting you know 
<bjf> manjo, then I don't think you know what I'm talking about
<manjo> ok]
<manjo> point me to bug please
<bjf> manjo, bug 399319
<ubot3> Malone bug 399319 in checkbox "Remove the HAL dependency from Launchpad HWDB and checkbox " [Medium,Fix released] https://launchpad.net/bugs/399319
<bjf> manjo, they are processing "udevadm info --export-db" and "grep -r . /sys/class/dmi/id/ 2>/dev/null" and "devkit-disks --dump"
<manjo> bjf, udevadm info --export-db
<manjo> yep we can have that 
<manjo> they changed to it after me bitching about it for 1yr
<bjf> manjo, but I think you want to look at how checkbox does it because I believe he combines it all into an xml file and submits it as a single xml blob
<bjf> manjo, I'd like to get it in the exact same format
<manjo> bjf, sure, you want to do it :)
<bjf> manjo, I'll look into it, it won't get done right away
<manjo> sure, I don't understand fancy langs like xml
<bjf> manjo, I was looking at it last night and his code is shit to follow
<manjo> :) lol
<manjo> bjf, I have had to ceal with it for 1.3yrs now 
<manjo> deal
<manjo> bjf, and I am no way python expert
<manjo> bjf, its more fun when it blows up in front of imp people ... and you are scrambling to fix it 
<manjo> apw, you still around ? 
<manjo> apw, I have an aspire one that boots from USB stick to a blinking cursor :) 
<cnd> bdmurray: still around? can you test out the amd64 wacom module?
<cnd> I just uploaded a new one to the same location
<bdmurray> cnd: yes, testing
<bdmurray> cnd: works great!
<cnd> bdmurray: it both loads AND it works for your wacom tablet?
<bdmurray> cnd: yes
<cnd> bdmurray: great! please log your results in the bug
<cnd> I still don't know whether we'll be able to put it into lucid, we'll at least need more testing
<cnd> cause the changes are rather expansive
<cnd> but we can look into other options if not
<LLStarks> apw, quick question. why isn't the kernel ppa an actual ppa?
<cnd> LLStarks: apw is likely gone for the day, which ppa are you referring to?
<LLStarks> the mainline kernel ppa
<cnd> LLStarks: hmmm... I'm guessing the reason is that no one ever really runs it as a ppa?
<cnd> I'm not really sure
<LLStarks> that would save me 4 wgets and dpkgs
<LLStarks> well, manual operations.
<cnd> LLStarks: why four?
<LLStarks> headers. image. generic.
<Q-FUNK> hi!
<LLStarks> headers all.
<LLStarks> wait.
<LLStarks> damn.
<LLStarks> headers. header generic. source. image.
<cnd> oh, yeah
<cnd> LLStarks: do you run mainline all the time?
<LLStarks> not always.
<LLStarks> breaks things from time to time.
<Q-FUNK> what kernel .config option do I need to have root=UUID work on cmdline?   I'm attempting to build my own minimal kernel as a test to debug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/396286
<ubot3> Malone bug 396286 in linux "[Geode LX] [OLPC] 2.6.31-generic: kernel panic near the end of initramfs" [High,In progress] 
<cnd> Q-FUNK: if you are doing testing, it may be easier to just use root=/dev/sd??
<cnd> instead of using UUID
<cnd> unless the UUID is particular to that bug
<Q-FUNK> cnd: it works with that, but then I constantly have to manually fix menu.lst
<mjg59> Also, the kernel doesn't parse that
<cnd> Q-FUNK: ahhh, have you looked at the differences between your kernel config and the ubuntu kernel config?
<cnd> that may tell you
<Q-FUNK> mjg59: doesn't parse what?
<mjg59> Q-FUNK: root=uuid
<cnd> mjg59: it parses something like root=UUID=299e7785-7c3d-4e90-9779-239cb237a4d2
<mjg59> Fairly sure that's done by initramfs
<Q-FUNK> mjg59: ok.  does ubuntu have a magic hack that converts something like root=UUID=299e7785-7c3d-4e90-9779-239cb237a4d2 to what the kernel expects?
<cnd> mjg59: yes, you're right
<cnd> Q-FUNK: how are you building your kernel?
<mjg59> Q-FUNK: No, it just does it itself
<mjg59> Which means it probably won't work unless you build with a ramdisk
<Q-FUNK> kernel-package, with the option --initrd
<cnd> Q-FUNK: I'm not too familiar with using kpkg, unfortunately
<cnd> I build kernels through the process described at: https://wiki.ubuntu.com/KernelTeam/KernelMaintenanceStarter
<cnd> someone else may be able to help you with kpkg
<mjg59> Which means it probably won't work unless you build with a ramdis4
<mjg59> Oops.
<Q-FUNK> ogasawara: seems that I have a winner.  something that gets included in the initrd.img is what causes https://bugs.launchpad.net/ubuntu/+source/linux/+bug/396286
<ubot3> Malone bug 396286 in linux "[Geode LX] [OLPC] 2.6.31-generic: kernel panic near the end of initramfs" [High,In progress] 
<Q-FUNK> only, I have no idea what exactly.
<mjg59> Q-FUNK: Hack initramfs-tools and add set -x to the top of it in order to see what's executing and when?
<Q-FUNK> mjg59: that sounds like a plan.  let's see if I can find the right file to hack for this.
<lifeless> there is a verbose mode
<lifeless> update-initramfs -u -v
<Q-FUNK> ogasawara: bug report updated.  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/396286  hopefully smb can make something out of it. :)
<ubot3> Malone bug 396286 in linux "[Geode LX] [OLPC] 2.6.31-generic: kernel panic near the end of initramfs" [High,In progress] 
#ubuntu-kernel 2010-02-26
<RAOF> apw: Would you like me to update linux-backports-modules-nouveau to 2.6.33, add the ctxprog generator, and do a little spring-cleaning in there?
<RAOF> Would someone kindly run git update-server on http://kernel.ubuntu.com/git-repos/ubuntu/ubuntu-lucid-lbm.git ?  Cloning over http is failing.
<lifeless> RAOF: lolol.
<lifeless> RAOF: :P
<RAOF> lifeless: I don't think anyone is unaware of how sucky git's push is.
<lifeless> RAOF: oh, I think some folk are :)
<lifeless> RAOF: ... the ones that like it
<RAOF> While I'm ragging on VCSs... would you kindly make bzr not silently trap everything I branch in 2a? :P
<lifeless> RAOF: its doing that because you told it to
<RAOF> Well, it's doing that because at some point in the past I bzr init-repo'd a directory somewhere above the directory I'm branching into.
<RAOF> The different repository formats are the only major source of friction I have in using bzr; it'd be nice if you could go back in time and make everything just 2a.
<lifeless> RAOF: it would be :)
<eggonlea> ericm: Morning!
<eggonlea> Do you know why OABI is enabled in ARM kernel?
<eggonlea> We prefer to disabling it if it's not necessary because this may cause unexpected issues (which has been found on Dove before).
<eggonlea> Karmic is EABI already, and Lucid should be as well, right?
<RAOF> apw: Bug #528190
<ubot3> Malone bug 528190 in linux-backports-modules-2.6.32 "Update to linux 2.6.33, Incorporate upstream's ctxprog generator" [Undecided,New] https://launchpad.net/bugs/528190
<cnd> apw, smb: although he hasn't stated such yet in bug 516777, bdmurray confirmed that the two wacom commits I added give him touchscreen functionality, and smb and tjaalton confirmed that it hasn't hurt their older wacom products
<ubot3> Malone bug 516777 in linux "HP Touchsmart tm2 requires newer wacom driver" [Low,In progress] https://launchpad.net/bugs/516777
<cnd> what do you suggest we do? pull it into lucid ourselves? put it in lbm or some dkms package?
<smb> cnd, Those were upstream, right?
<cnd> smb, yes in .33
<cnd> I can also submit to -stable if you think there's any chance they'll be accepted
<smb> cnd, We might consider it as bugfix in that case and pull it into the kernel directly (sort of pre-stable). I think apw was thinking along that line. But the final call would be his
<smb> cnd, It looks a bit big for general stable. So it might or might not work out to get it accepted. Might be worth contacting the maintainer of the wacom driver and ask about his feeling.
<cnd> smb, does it hurt to just submit to -stable and hope?
<cnd> or is it worthwhile to contact the maintainer first to get them on board?
<smb> There was one case with the interleaved ALPS/PS2 protocol which was also big. But the maintainer said it would help a lot of cases and had been upstream without any reports and so on. Much better to get with maintainer.
<smb> If you just send it to stable (you would need to cc the maintainer there, as well) you will need maintainer support anyway because its quite big
<cnd> ok
<cnd> smb, then I'll work with the maintainer about -stable inclusion, but should we wait on that before considering whether we throw it into lucid as a pre-stable?
<smb> cnd, Probably depends on how quickly we hear back. If it takes too long, we might go ahead based on our testing and because its harder after release.
<cnd> ok
<cnd> smb, if the wacom guy wants to support us pushing this upstream, what be the result? Are we asking him to push it himself? Or just a confirmation that we can add "This request is supported by the wacom driver maintainer"?
<smb> cnd, It could be either him or us. When you push things, I would add a cover mail saying that we had found that issues, talken with the maintainer, he thinks it good too, bla. And send it with cc the maintainer. Sort of we think it makes sense in stable though it is a bigger one. And then see what Greg says
<cnd> ok
<rackerhacker> anyone know why drbd is disabled in linux-ec2 for lucid?
<smb> Drbd is supposed to be a dkms package now (it was before but the kernel had an aditional moddule)
<rackerhacker> ah, okay, that makes sense
<rackerhacker> i was digging through the git logs and couldn't find it
<rackerhacker> thanks, smb 
<cnd> rackerhacker: the drbd module that was in the linux-image package was old anyways
<rackerhacker> cnd: yeah, i noticed that as well :/
<apw> rackerhacker, its gone now
<apw> in the main branch, and will go in the others as they track it
<rackerhacker> thanks apw 
<rackerhacker> i'm trying to dig up the patchset that adjusted hvc0 -> tty1 in linux-ec2
<rackerhacker> disregard - found it
<apw> RAOF, thanks for all those fixes.  I had done the update to t
<apw> the .33 but the other bits are good finds ... i'll pull that diff appart and pull them into the package git.  thanks
<apw> RAOF, although your changelog entries include changes to Conflicts/Replaces I cannot see any changes which implement those in the diff??
<RAOF> apw: You're quite right!  I don't know where those changes got dropped.
<dyek> Hi! Where can I find pv-grub? Is there a package that contains this (Xen?) utility?
<apw> RAOF, i uploaded the rest of it .... in the git tree i did it as a bunch of patches... thanks for the bits, if you get me the missing bit i can get that up in the next one ...
<RAOF> apw: Is the git tree clonable?  When I tried (over http), git complained that git-update-server hadn't been run.
<RAOF> If you could make it clonable, I'll make the next (set of) patch(es) against git, rather than the archive.
<apw> hrm, should be, but perhaps something got lost in the config for that repo.  it should clone over git as thats how i get it
<apw> its late here, but i'll try and look at it tommorrow
<RAOF> You probably clone over git+ssh?  And I don't think I've got ssh access there.
<apw> we have git: as well
<RAOF> I tried cloning over git, but maybe not hard enough.
<apw> git://kernel.ubuntu.com/ubuntu/ubuntu-lucid-lbm.git
<apw> it should be
<RAOF> Oh, and now of course it works!
<RAOF> I wonder what I was doing previously?  Oh, I probably had the kernel-team path component in there.
<apw> yeah, its not the same on http: as git: for some reason
<apw> RAOF, cool the update is built and published
<apw> i've also pulled in your two novueau commits over the top of my drm backport
<apw> which is in my 'red' PPA: https://edge.launchpad.net/~apw/+archive/red/+packages ... when it finished building
<apw> something else for your keen testing
 * apw wanders off
<RAOF> I'll give it a whirl.
<RAOF> Have a good evening!
<apw> RAOF, thanks ... any feedback appreciated ... its bed for me
<Ng> if one has a git checkout of the ubuntu lucid kernel, where would one find the config file that is going to be used to build an amd64 server kernel?
<lifeless> in debian/
<lifeless> IIRC
<Ng> aha debian.master/config/ looks relevant to my interests
#ubuntu-kernel 2010-02-27
<mozmck> using the ubuntu-karmic git tree, how do I compile the latest released ubuntu kernel?  (2.6.31.20.33 it looks like)
<cnd> mozmck: this wiki page has a lot of starting information: https://wiki.ubuntu.com/KernelTeam/KernelMaintenanceStarter
<mozmck> cnd: thanks, but I don'
<mozmck> t see what I was looking for there. 
<mozmck> I have the git tree, but I want to make a patch to the latest released version, so can I do this with the git tree or do I need to get the source with apt-get source?
<mozmck> hmm, looks like I can create a branch from a tag.
<ghostcube> hmm for #466935
<ghostcube>  there seems to be a patch
<ghostcube> https://bugs.launchpad.net/bugs/466935
<ubot3> Malone bug 466935 in linux "No Video Output in Karmic with ID 046d:09a1 Logitech, Inc. QuickCam Communicate MP/S5500" [Undecided,Triaged] 
<ghostcube> last post shows a logitech side telling about problems 
 * alecrim did a post about ubuntu karmic + n810 + linux 2.6.33 (http://tiny.cc/SIFng) 
#ubuntu-kernel 2010-02-28
<penguin42> are the 'perf' tools in the kernel built with any of the kernel packages?
<toabctl> hi
#ubuntu-kernel 2011-02-21
<dantalizing> anyone awake?
<jk-> technically
<jk-> but it seems to be a two-coffee morning, and I've only had one
<dantalizing> its too late at night to be morning
 * smb fetches #2
 * apw yawns
<smb> apw, Morning
<smb> cking, If you did not "hear" a good morning, your mumble is broken. :)
 * cking gives it a kick
<cking> smb, mumble failed again?
<apw> i think smb's router needs rebooting at midnight
<apw> bah i hate Qt already
<ogra> apw, do you have to add new Qt bits to the kernel now ?
<apw> ogra, heh thankfully not ... trying to figure out why mumble is broke on natty
<ogra> lol
<apw> finally annoyed me enough to try and fix it
<ogra> i think we all did already 
<ogra> and all of us gave up :P
<apw> wondering if it is actually a unity related issue
<ogra> (at least everyone i talked to up to now had at least one mumble prob)
<apw> or perhaps even a qt library issue
<ogra> might be compiz, yep
<apw> we seem to have asked for the input events, but they are not getting delivered
<ogra> try using std. gnome and metacity and see if it fails there too
<apw> is there a way to switch live?  i know unity does temporarily when resetting
<ogra> hmm, no idea, i usually do it at gdm
<amitk> apw: what is the problem? my mumble doesn't read my hotkey anymore
<novice27> hi. i am through with all the wiki bug triaging pages. but i am not getting from where to start? how to pick a bug and from where? please suggest.
<apw> novice27, hiya, our main trige guy is off today, he would be the best person to help you
<apw> novice27, but mostly we start with the 'New' bugs on the 'linux' package
<apw> which one can find on launchpad
 * apw drops to reboot, in the vein hope that the unity update will help ... i am sick to death of it crashing
<novice27> apw: okiez.. thanks... but i dont know how to start practically. but let me check the page :)
<apw> novice27, forgot to mention, his irc nick is jFo
<novice27> apw: thanks... :)...
<novice27> apw:  i want to get into kernel development.. i have decided to start with bug triaging.. can u please some more?....
<novice27> apw: *suggest
<apw> novice27, we usually suggest that, looking at bugs and gets you to see what areas there are, and what intrests you
<apw> and in trying to solve them, which tends to happen with ones you are interested about, you tend to learn new things
<apw> which help you as you start to find bugs and write fixes
<novice27> apw: do i need to read books on linux kernel programming?
<apw> it depends how you find it as you go, some people just read the code around an issue and pick it up that way
<apw> its personal preference
<apw> reading a book on it is usually interesting, but they do tend to be out of date
<novice27> apw: ya.. they are of 2006 edition... i will start with the isues then and try them. thanks for help...:)
 * apw whines about unity, impotently
<BigRedS> What's the difference between HIGHMEM4G and HIGHMEM64G (besides the '6')? Why would one choose just the 4?
<mjg59> Beacause enabling PAE means you take a performance hit
<BigRedS> But both are PAE aren't they?
<mjg59> No
<mjg59> You can access 4G without PAE
#ubuntu-kernel 2011-02-22
<beata|lemur> Howdy y'all. I'm following the Ubuntu kernel compile guides, checking out natty, running the 'debian/rules binary-$local' method, on AMD64 system. What I'd like to figure out how to do, is build for i386 on that same tree.
<AceLan> beata|lemur: you need to setup chroot environment
<beata|lemur> I presume, then, I can use the same build tree in the chroot?
<AceLan> beata|lemur: https://wiki.ubuntu.com/Kernel/Action/BuildChroot
<AceLan> beata|lemur: yes
<beata|lemur> I'll read it up then, thanks.
<AceLan> beata|lemur: no problem
<psusi> I'm trying to chase down a kernel BUG I just ran into on natty in dput().  It does BUG_ON(inode->i_state & I_CLEAR);  this was tripped when removing a dmraid partition device ( linear mapping ).  what is I_CLEAR?
<beata|lemur> *giggle* The last chroot experience I had was trying to build the natty kernel on hardy. That was..ugh..painful.
<psusi> hrm... maybe a multiple free problem?  hrm...
 * psusi sure is glad for make -j4
<beata|lemur> Hey. I'm happy for auto-jobbing. We didn't have that back in 1999.
<psusi> auto jobbing?
<psusi> you know what we DID have in 1999 that we don't anymore?  a defrag package ;)
 * psusi really needs to get that put back into the main archive, or at least universe
<beata|lemur> *laugh*
<beata|lemur> Oh dear. The chroot is grabbing over half a gig of archives.
<beata|lemur> It wasn't that long ago I wouldn't have had space on the whole disk. ;)
<ohsix> it's going to be much huger by the time it gets underway
<beata|lemur> I can believe it.
<beata|lemur> This chroot thing is a *lot* harder than I expected, even given the other one.
 * apw yawns
<apw> cking, moin
 * smb returns
<smb> apw, cking morning
<apw> smb, and to you
<cking> morning
<abogani> morning all
<smb> abogani, morning
<apw> smb, bug 
<apw> bug #723066
<ubot2> Launchpad bug 723066 in linux "[STAGING] ENE card reader fails with IO errors on streaming reads" [Medium,Triaged] https://launchpad.net/bugs/723066
<smb> apw, ok, thanks. I will include that into the reply
<apw> yeah, its pretty bust, we do not want it backported as it is for sure
<herton> apw, there are two bugs which also will be fixed by latest rebase, bug 722689 and bug 722310
<ubot2> Launchpad bug 722689 in linux "visual corruption of all screen after upgrading to 2.6.38.4.18" [Undecided,Confirmed] https://launchpad.net/bugs/722689
<ubot2> Launchpad bug 722310 in linux "Suspend fails due to tpm_tis: error -62 with kernel 2.6.38-4 (2.6.38-3 works)" [High,Triaged] https://launchpad.net/bugs/722310
<herton> I asked the reporters to test with the fixes included and they confirmed
<apw> herton, thanks, will make sure they are listed in the changelog  before i upload it
<rsajdok> Where is the list of bugs to bug day?
<apw> JFo, ^^
<JFo> rsajdok, we are looking at all the new status bugs
<JFo> I'll get you a link :)
<JFo> rsajdok, http://goo.gl/f5CAz
<JFo> that is the list of all kernel bugs in the new status
<JFo> we'll be working from there
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<JFo> rsajdok, here is a better list http://goo.gl/2wO4A
<tgardner> bjf, how about some CVE reviews so I can get them scraped off my list ?
<bjf> tgardner, i'll add you to my list
<tgardner> apw, your -rc5 kernel seems to be working well on emerald
<apw> tgardner, excellent ... just finishing up the boot tests here ... will shove it shortly
<tgardner> apw, one of the commit messages is wrong. it says -rc5 when it should say -rc6.
<apw> doh will correct
<tgardner> UBUNTU: v2.6.38-rc5 rebased fixes Bug #716811 ?
<ubot2> Launchpad bug 716811 in linux "[SandyBridge] kernel BUG at /build/buildd/linux-2.6.38/fs/nfsd/nfs4state.c:3132!" [Undecided,Fix released] https://launchpad.net/bugs/716811
<apw> tgardner, no that one is actually correct, it was an older bug
<tgardner> although it may be correct
<tgardner> ok
<apw> just added it for completeness as i closed it out
<tgardner> apw, the scheduler really seems to work well. even at 322 load average its fairly responsive on another SID
<apw> tgardner, that is most in-credible
<rsajdok> JFo: thanks
<JFo> rsajdok, thank you :)
<tgardner> apw, lemme know when you've pushed natty master so I can start the ti-omap-dev rebase.
<apw> tgardner, it should be as you have, i have just pushed the tag
<tgardner> apw, ack
<apw> oh its not on master yet sorry
<apw> will do that right now
<apw> tgardner, ok done on master correctly
<tgardner> apw, got it
 * apw goes do the lucid ones
<JFo> need cofee brb
<kees> tgardner: seriously, can't we just remove debugfs?? http://seclists.org/oss-sec/2011/q1/229
<kees> tgardner: it's horrible
<tgardner> kees, IMHO its no worse then a regular sysfs. Its just that folks are paying less attention to debug interfaces. Perhaps we can get smb to agree to not mount it by default? We should also fix these holes.
<kees> tgardner: sysfs has a regular interface, debugfs has become a dumping ground
 * smb had no issues with not mounting it by default
<tgardner> kees, well, maybe we can look at turning off the worst offenders (after fixing some of the permission problems)
<kees> tgardner: we can also mount it somewhere that only root can get to
<kees> tgardner: right, I want to keep the arbitrary memory writing interfaces totally gone (acpi/custom_method)
<apw> kees, might that not be achieveable by just chanign permissions on the directory to be mounted on
<kees> tgardner: but mostly this is just me pointing out yet more vulnerabilities in debugfs globally.
<kees> apw: yup.
<tgardner> kees, would mounting somewhere else be sufficient ?
<tgardner> nm
<apw> what mounts them up?  is that upstart
<apw> i think it needs to use debugs
<kees> tgardner: there are two classes of issue: root gaining arbitrary write (which we've fixed by dropping acpi/custom_method) and non-root messing with the system (for which there are tons of holes it seems)
<apw> for its boot tracing
<apw> so we might need to fix it there
<kees> afaik, ureadahead and the dri debugging hooks need debugfs
<kees> both should be running as root
<sforshee> I think debugfs is also needed for perf, isn't it?
<kees> none on /sys/kernel/debug type debugfs (rw)
<kees> none on /var/lib/ureadahead/debugfs type debugfs (rw,relatime)
<kees> sforshee: not sure.
<abogani> ftrace
<apw> kees, i meant more that upstart is likely mounting it early
<kees> abogani: ftrace is a rootly thing, though, right?
<kees> apw: likely mountall, but yeah
<apw> kees, so something you could just try probabally
 * kees has 2 days before feature freeze. :)
<sforshee> kees, looks like debugfs is needed for some perf functionality: https://perf.wiki.kernel.org/index.php/Perf_examples
<kees> sforshee: but that's all rootly stuff.
<kees> sforshee: i.e. not mounting it or making the mount 0600 shouldn't wreck that.
<sforshee> kees, yep, just an argument for not ripping out debugfs support completely
<kees> sforshee: well... I'm against allowing the root user instrumenting the kernel in general. I'd prefer a "debug" flavor for that kind of thing, but I know it's a losing battle. :)
<kees> sforshee: the middle ground is to just keep from allowing root to manipulate arbitrary memory.
<kees> apw: setting 0600 is still a kernel change (since the mounted fs determines the mode of the root node)
<apw> kees, i thought it was the OR of the root in the FS and the directory onto which it was mounted
<kees> apw: looks like not
<apw> ok, then likely yes a small change kernel wise
<apw> as its just that top directory
<bjf> ubuntu-meeting
<bjf> ##
<bjf> ## Kernel team meeting in 12 minutes
<bjf> ##
<kees> apw: I don't see a way to make the root inode 0600 without patching fs/libfs.c simple_fill_super()
<apw> kees, hm
<apw> probabally needs a _mode() version
<kees> apw: well, actually, I could change the mode after the simple_fill_super call
<kees> apw: in debug_fill_super, test the simple_fill_super return, then set sb->s_root->d_inode->i_mode
<kees> seems like a psychotic hack, though
<apw> i think add a new versionw hcih takes a mode
<apw> and make the existing one pass 0600 to it
<kees> apw: yeah. there aren't many users of simple_fill_super
<JFo> grabbing a bite bbiab
<jjohansen> smb: good news, the hardy -xen kernels do boot on ec2
<smoser> wait
<smoser> maybe
<smoser> i don't know that they dont
<smoser> i can test that fairly quickly
<jjohansen> smoser: oh, I took it as you had already tested
<smoser> no. i only know that i did something wrong when they failed.
<smoser> lets see.
<jjohansen> smoser: ah
<smb> jjohansen, partially good news then :)
<jjohansen> smb: yes
<jjohansen> smb: smoser and I were discussing whether it was worth while pulling pv-grub back to hardy
<smoser> oh wait...
<smoser> i wasn't necessarily going that far...
<smoser> first would be to get to using the archive kernels
<jjohansen> hehe, /me over enthusistic again
<smoser> that would require some changes in image building
<jjohansen> smoser: right
<smb> jjohansen, I was just commenting like that. :)
<smoser> using pv-grub would be wonderful.
<jjohansen> I think archive kernels is a given
<jjohansen> yes it would be
<smoser> ok. 
<smoser> so
<smoser> let me upload a kernel and ramdisk and see if they boot.  this is such a pain for hardy :)
<smoser> which is why we'd want to get to pv-grub
<jjohansen> yep
<kees> apw: I'm testing this now, what do you think? http://kernel.ubuntu.com/git?p=kees/ubuntu-natty.git;a=commitdiff;h=eca3653fb5aaa514c734821dc68813bb0fdc49fc http://kernel.ubuntu.com/git?p=kees/ubuntu-natty.git;a=commitdiff;h=f787804f21a3070e14df32ce8098b3f0b4a40646
<smb> jjohansen, smoser Though I think I noticed a slight pain with pv-grub once an ami is not booting. Just overriding the aki seemes not to work as simple (I guess I would need to publish a ramdisk there)
<smoser> smb, well, maybe
<smb> But I generally agree on the beauty of pv-grub
<jjohansen> smb: with hardy and lucid you could always just manually specify an aki instead of using the pv-grub aki
<smoser> well, they dont run
<jjohansen> so it should be no worse than now
<jjohansen> smoser: darn
<smoser> as there is no network driver in the image
<smoser> unless you get the -modules into the image
<jjohansen> smoser: okay, /me and smb will persue getting -xen to work
<smoser> although... we could potentially fix that by getting the netowrk driver into the ramdisk
<smoser> i think that would be very worth it
<smb> yep. just having to fiddle with the network driver does sound like it could be done without breaking our ppa builders
<smoser> smb, well, the ramdisks are manually built
<smb> Ok, so that would be an option, too. Probably even better than arguing for a change of the xen image if it can be avoided.
<smoser> yeah.
<smoser> smb, i might have been wrong on network
<smoser> http://paste.ubuntu.com/570675/
<smoser> that is output of lsmod in a current instance
<smoser> none of those look like network module to me 
<smb> smoser, neither to me. at least not an nif driver
<smoser> off topic, but i'm personally happy to see that kernel clock apparent time travel occurred on this hardy kernel (http://paste.ubuntu.com/570676/) ... ie, htats not a regression in lucid or maverick its been there for quite a while. i had never looked on hardy before
<smb> Is ifconfig -a show something
<smb> smoser, I saw it occasionally when restoring an instance
<jjohansen> smoser: time travel problems have plagued virtualization for a long time
<smoser> smb, yes, there is definitely a network device
<jjohansen> CONFIG_XEN_NETDEV_BACKEND=y
<jjohansen> CONFIG_XEN_NETDEV_FRONTEND=y
<jjohansen> smoser, smb ^
<smoser> so maybe it was disk that was failing 
<smoser> hold on
<smb> jjohansen, yup that makes sense with a network interface there but not in modules
<smoser> smb, you can poke around at ec2-50-17-93-174.compute-1.amazonaws.com if you'd like. please don't modify anhything though
<jjohansen> smb: yep, /me was just double checking
<smoser> smb, http://paste.ubuntu.com/570680/ is output of a hardy i386 instance booted with a differnet kernel ramdisk than it is expecting
<smoser> thats why i had suspected no network driver
<smb> hm, yes. on a very quick glance that looks like either the network driver is not working, the network not setup or the magic http-meta server missing
<smoser> well meta data service isn't missing multiple times in a row
<smoser> i've only seen that happen maybe 3 times ever
<smb> smoser, Yeah, I only came up with it because that is what usually happened to me when trying on my test-system (thanks for the uncloudify script btw, though unfortunately time seems to have warped without me having any to try again)
<smoser> yeah
<smoser> right
<smoser> but it seems like its something else, and i suspect that it is solved by installation of the apprpriate linux-modules package
<smb> It is really hard to say. Disk and network look to be ok from the messages...
<smb> smoser, If I have understood jjohansen correctly he was syncing up the patches for the ppa image. So that would only leave some configuration difference to be found
<smoser> right.
<jjohansen> hence the question does, the new image boot
<smoser> well. it boots.
<smoser> that is for sure.
<smoser> i suspect that re-bundling an image with its modules instlaled will work.
<smoser> so i guess, we need to test that putting them there would fix this
<smoser> and then try to work out exactly what is going wrong
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Natty Kernel Version: 2.6.38 || Ubuntu Kernel Team Meeting - March-01 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
 * tgardner --> lunch
<apw> JFo, you there?
<JFo> apw, yep
 * apw mumbles at you
 * JFo is on there
<JFo> I don't see you apw
<apw> and i cannot connect hrm
<JFo> ah, there you are
<kees> tgardner: well there you have it; greg doesn't want to take it.
<apw> kees, what was his objection
<JFo> apw, bug 709591 is one we only tagged kj-triage
<ubot2> Launchpad bug 709591 in linux "i915 doesn't detect HDMI display" [Undecided,New] https://launchpad.net/bugs/709591
<apw> JFo, and weher can i find the script which did this
<apw> JFo, cranberry?  if so where
<tgardner> kees, is he only objecting to 'debugfs: only allow root access to debugging interfaces' ?
<JFo> it is in the kernel team branch of arsenal
<JFo> it is the new-process-new-bugs.py under the contrib/linux/ dir
<apw> and what output did the run produce for that bug
 * JFo digs back
<kees> tgardner: I would note that viro just said that debugfs "should not be mounted on production systems".
<kees> apw: "debugfs has no rules and is for debugging only"
<tgardner> kees, I'm just replying in email something to that effect.
<kees> tgardner: okay
<tgardner> kees, and it was Alan Cox that said "don't mount debugfs"
<JFo> apw, can't find that one in the output. but I did find bug 714415
<ubot2> Launchpad bug 714415 in linux "BUG: unable to handle kernel paging request at 80808080" [Undecided,New] https://launchpad.net/bugs/714415
<JFo> the output is here https://pastebin.canonical.com/43753/
<JFo> same deal
<apw> what was the next line of the output
<tgardner> sforshee, wren't you having tpm suspend issues for awhile ?
<JFo> apw, it was for the next bug
<JFo> want me to pull out a few more?
<JFo> I should note, the output there is with the --verbose option enabled
<JFo> so there isn't much more for us to get without debugging print statements
<JFo> or rather debug print statements
<sforshee> tgardner, not me
<sforshee> mine was an i915 regression
<tgardner> sforshee, hmm, ok
<smb> tgardner, reading the tales from the unkown stable mailing list?
<tgardner> smb, about what?
<smb> About the regression they caused on some tpm hardware
<tgardner> smb, oh thatt. no, I saw some patches going by on LKML that fix the tpm patch that was reverted
<smb> tgardner, Yeah, noted the story on the stable mailing list. 
 * jjohansen -> lunch
<apw> JFo, for it to print Action: <blank> i think something odd happened in skipit
<JFo> I wondered that too
<JFo> but I still can't wrap my head around it enough to determine what
<apw>         if result and not self.reason:
<apw>             self.reson = "skip it returned true"
<apw> perhaps add (a correct) version of that to the bottom of skipit
<apw> and run it in ry run and verbose
<apw> dry
<JFo> k
<JFo> is it sad that it took me a bit of looking at that to determine what needed to be fixed? ;-P
<skaet_> JFo, which specific packages do your tools search for, for identifying interesting bugs?  my guess is linux,  linux-ec2, and ???
<JFo> the tools are looking only at linux for the moment
<JFo> we are still working out some issues
<skaet_> ok thanks.
<bdmurray> I've been looking at some kenrel debugging documentation particularly https://wiki.ubuntu.com/Kernel/CrashdumpRecipe - is it current / accurate?
<bdmurray> apw: are you still affected by bug 451390?
<ubot2> Launchpad bug 451390 in launchpad "limited upload rights no longer give series nomination accept/decline rights" [High,Triaged] https://launchpad.net/bugs/451390
<apw> bdmurray, has it been fixed?  i cannot trivially tell without asking mr watson to remove the work around
<bdmurray> apw: which work around is that?
<apw> the bug is that package sets do not give you the nom rights for the packages in, for the linux package mr watson added linux to each of the kernel uploaders direct rights
<apw> this works round the issue for the main package for which we use nominations, but does not solve the bug
<bdmurray> apw: ah okay I wasn't aware of *that* workaround
<apw> yeah though it means the other 20 packages on my list i don't have noms for
<apw> i think i'd need to find a bug on another package to confirm
<bdmurray> apw: its okay I'm playing with it on staging now
<apw> bdmurray, that was the only thing stopping me moaning every single day
<bdmurray> apw: actually if you could try one of the other 20 packages on staging.launchpad.net that'd be interesting
<apw> bdmurray, ok
<apw> shame everything i do on launchpad also triggers timeouts
<apw> dammit
<apw> fileing a bug doesn't work on staging for me ... 
<apw> bdmurray, it may be working (nomination s for other packages) i need to test it on live i guess
<apw> https://bugs.staging.launchpad.net/ubuntu/+source/linux-meta/+bug/722414
<ubot2> Launchpad bug 722414 in ubuntuone-android-files "syncable icon too small" [Medium,Confirmed]
<bryceh> apw, upstream is telling me "for all the 915/945 bugs can you please have the reporters test the latest kernel with the enlarged unfenced alignment."
<bryceh> google isn't informing me what an "enlarged unfenced alignment" is... do you recognize that?
<cking> apw, do you never sleep?
<RAOF> bryceh: That sounds like a libdrm commit to me?
<bryceh> RAOF, didn't get much more context than that
<bryceh> Bryce, for all the 915/945 bugs can you please have the reporters test the
<bryceh> latest kernel with the enlarged unfenced alignment. That's the most likely
<bryceh> cause of random writes, though I don't suspect it in this case.
<bryceh> figure I shouldn't forward all the rest of these bug reports until I've gotten people to test whatever he's referring to
<bryceh> but I suspect if it doesn't occur in tip, he won't care and we'll be on our own to dig out what patch(es) provide the fix
<jjohansen> cking: of course he doesn't
<RAOF> bryceh: Sounds about right :)
<bryceh> RAOF, however `git log | grep "unfenced alignment"` in linus' tree returns null
<bryceh> nor found anything in ickle's drm-intel tree
<bryceh> wonder if he is sending me on a snipe hunt ;-)
<bryceh> RAOF, hmm wonder if this is a possible solution to the vesafb bug?  http://git.kernel.org/?p=linux/kernel/git/ickle/drm-intel.git;a=commit;h=86b27d8050b6b2aec31063fa9f40b16fb347afb3
<RAOF> bryceh: I suspect ickle's talking about 5e7833
<bryceh> RAOF, ah thanks!
<smoser> jjohansen, smb i kicked off a hardy-server uec build that is going to use linux-xen from the ubuntu archive.  it should appear in a couple hours on uec-images.  its not using -proposed kernel, but it is loads closer.
<jjohansen> smoser: nice
<kees> smoser: do you recognize "2.6.31-302.7-rs" as an Ubuntu kernel version? looks like a fork of an early karmic linux-ec2 version or something.
<jjohansen> kees: that isn't one of ours
<kees> jjohansen: I didn't think so.
<chrismsnz> Hi Guys, I have a set of Supermicro 2u twins (4 nodes) running Lucid. A couple of them have been having OS trouble under high load
<chrismsnz> usually what happens is the machine is still reachable via connecting to a port (i.e. you can connect to the http port, memcache port and it will respond to ping), but anything further than that is unresponsive
<chrismsnz> so you can connect to the HTTP port, but you cannot request a document - it will hang
<chrismsnz> It can work pretty hard but as soon as it "crashes" like this the only thing you can do is reboot
<chrismsnz> I think it's a kernel problem with the version that comes with Lucid - what is the recommended kernel upgrade to try while still sticking with 10.04?
<chrismsnz> running 2.6.32-27-server
#ubuntu-kernel 2011-02-23
<smoser> kees, yeah, that string doesn' tmean anything to me.
<smoser> although i woudl suspect 'rs' == 'rightscale'
<smoser> kees, i appear wrong rs != rightscale, but rackspace
<smoser> https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/473711 indicates that
<ubot2> Launchpad bug 473711 in aptitude "aptitude crashes when trying to free an invalid pointer" [Undecided,New]
<kees> smoser: ah-ha. thanks!
<smoser> and I know that they have forked our -xen kernel
<smoser> or at least have maintained a xen ubuntu-like kernel
<bryceh> RAOF, hmm, well 
<bryceh> RAOF, hmm, seems 5e7833 is already in the natty kernel tree
<RAOF> Since when?
<kees> RAOF: Ubuntu-2.6.38-1.27
<kees> $ git tag --contains 5e78330126e23e009502b21d1efdabd68ab91397 | head -n1
<kees> Ubuntu-2.6.38-1.27
<RAOF> Thanks.  (I haven't yet got my natty ubuntu branch set up)
<bryceh> heh, there is also a b5e7833, which is completely unrelated
 * apw yawns
<smb> apw, o/
<apw> diwic, about ?
<diwic> apw, pong
<apw> diwic_afk, heh ... damn
<apw> diwic_afk, i wanted to ask you about your sound bugs ... and getting them closed on upload
<diwic_afk> apw, well, I saw two of them closed today
<diwic_afk> So it seems to have been working fine
<apw> diwic_afk, well no, as its not closing any which are alsa-driver
<apw> https://bugs.launchpad.net/ubuntu/natty/+source/linux/+bug/672699
<ubot2> Launchpad bug 672699 in ubuntu-cdimage "screen-reader does not work " [Undecided,Fix released]
<apw> argle
<apw> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/718402
<ubot2> Launchpad bug 718402 in alsa-driver "[Realtek ALC892] Recording problem" [Undecided,Fix committed]
<apw> that one was in the changelog, but not againt linux, so it wasn't closed
<apw> i wonder if they should be being moved to linux when they are deemed to need a kernle patc
<apw> patch
<diwic_afk> apw, hmm, maybe you're right
<diwic_afk> apw, it wouldn't be too hard for me to move them to Linux when I send the patch
<apw> diwic_afk, depends if you rely on them being in alsa-driver for tracking, as you can 'also affect' linux and at least you get the upload information splatted in, but otherwise probabally shift it to linux
<diwic_afk> apw, ok, that makes sense
<apw> diwic_afk, i can however assume if something is only on alsa-driver, and i have a buglink in the upload for it that i can just close it out fix released 
<apw> for the current situation?
<diwic_afk> apw, the general case is that the bug should be closed even if it is against alsa-driver.
<apw> yeah, there is no way to 'automate' via the nomal process, but we might be able to launchpad lib it.  for now i can just spin the list, it is short
<diwic_afk> apw, because the general case is that bugs against alsa-driver should really be against linux ;-) 
<apw> i assume alsa-driver exists just to say "sound issue" and then moves to linux or pulse or whatever is really the issue once someone in the know knows
<diwic_afk> apw, it exists because there is no way to subscribe the "ubuntu-audio" team via apport 
<diwic_afk> but yeah, it's handy and it works for us
<apw> diwic_afk, oh so actually if we had an arsenal script which literally just subscribed ubuntu-audio and moved them alsa-driver -> linux ... as soon as it saw them, would that do what you want
<apw> diwic_afk, ok closed off the two whcih wern't closed
<PhoenixSTF> hello
<PhoenixSTF> I got and issue with VT6421a controler that fails errors a lot with WD and samsung HDD, i have the 2.6.35-25 kernel and it is still bugging
<smb> PhoenixSTF, I vaguely remember some patches for that sort of combination, though they were very specific to the ids. It might be yours just is not included.
<PhoenixSTF> smb, can i help in some way to get it fixed?
<smb> PhoenixSTF, possibly. But give me a sec to find the changes again
<PhoenixSTF> smb, thanks m8 :)
<PhoenixSTF> smb, i got the chip in front of me so i can take a picture or ref the serial number or manufacteur code of it, if it helps
<smb> PhoenixSTF, nah, the os is more interested in internal things. I believe lspci should show it
<PhoenixSTF> smb, ok tell me what to do
<smb> Yep. So I found the last time they touched that. (sata_via: apply magic FIFO fix to vt6420 too)
<smb> but it checks for board id, so i need to check the code how that is looked up
<smb> PhoenixSTF, But you could look up what numbers (for vendor/model and subvendor/model) lspci will give you for the sata controller
<PhoenixSTF> smb, ok ill try and give you that, its a pci sata controler ok
<PhoenixSTF> ok i got 2 of them, on is working fine, the other one has got all the issues
<PhoenixSTF> 00:0c.0 RAID bus controller: VIA Technologies, Inc. VT6421 IDE RAID Controller (rev 50)
<PhoenixSTF> 00:0d.0 RAID bus controller: VIA Technologies, Inc. VT6421 IDE RAID Controller (rev 50)
<smb> Would both have WD disks connected? Actually you will need to use lspci -vvvnn to get the numbers in hex as well
<PhoenixSTF> yes
<PhoenixSTF> i swaped drives between boath controlers
<PhoenixSTF> i have 2 wd, 1 samsung and 1 seagate, the only one it doesnt complain about is the seagate
<PhoenixSTF> so i have now a samsung drive on it and gives me the bug of ICR something error
<PhoenixSTF> smb, the output is a bit big can i paste here?
<smb> Hm, that could then be a different problem than the one they got fixxed. You could pastebin it and send the link here
<PhoenixSTF> ok
<PhoenixSTF> http://pastebin.com/Z0qsP4cZ
<PhoenixSTF> oh the controler that is buging, works a bit better alone (I mean less errors), without the other controler on, 
<smb> Ok, so this one gets mapped to a board id of vt6421 and  for that the quirk gets enabled. Actually for that one even before the latest change
<PhoenixSTF> ?
<PhoenixSTF> well its a VT6421A not a VT6421
<smb> Means whatever that fixed, you already have it
<PhoenixSTF> does it matter?
<smb> not in the driver code
<PhoenixSTF> well if I have the fix why the issue?
<smb> that just looks at the 0x3249 from the model number
<smb> Just saying it is not that issue that got fixed
<smb> You probably have a different
<PhoenixSTF> ok
<PhoenixSTF> i got the same board extra do you whant me to mail it you? lol xD
<smb> When you say one controller alone works better it sounds a bit like there is some interaction. Heh, got enough not completely working kit. :-P
<smb> I suspect it would be good to try a recent mainline kernel (to see whether this still shows the same issues)
<PhoenixSTF> that is the thing the 1st controler, doesnt give any kind of trouble at all
<smb> and if that is the case, it would be best to open an upstream bugzilla
<PhoenixSTF> i had 3 controlers on it, and it was rock solid
<PhoenixSTF> the other 2 with are the same, gives me the creeps with WD
<smb> So it could also be a real hw fail
<smb> Maybe not if two show the same problem
<PhoenixSTF> that is it i tried the HD with my 1st controler, and everything is fine, i take it out of the server out it on my desktop and its fine... connect it to the 2nd controler in the server and ICR blabla bla
<PhoenixSTF> i got a seagate on the 2nd controler, ok no problem. Samsung, ICR blablabla
<PhoenixSTF> its the issue with WD and Samsung... i dont know if it is something to do with the controler manufacteur
<smb> From what I read in that part of the code it has to do with how much data a drive sends  before handshaking
<smb> apparently some wd drives do 40 double words while other only do half
<PhoenixSTF> whant me to send my HDD info?
<apw> smb, isn't it a bit odd that both those controllers are ide
<smb> Must admit that I am reaching my limit of usefulness. This goes into detail levels beyond me. 
<apw> identicle from the lspci output, yet one works and the other not
<smb> apw, yes, though both bound to via_sata driver
<apw> PhoenixSTF, these are both discrete sata cards yes ?
<PhoenixSTF> thanks anyway smb, sorry for the trouble, if you find anything or anyone that can give some help i would apriciate
<PhoenixSTF> discrete?
<PhoenixSTF> what do you mean?
<apw> as in physical cards plugged into a slot
<PhoenixSTF> yes
<PhoenixSTF> pci
<PhoenixSTF> boath
<smb> PhoenixSTF, Well the best advice is to do a test with a very recent kernel and then an bugzilla report
<apw> one card working and one not implies one of two things, either one card is broken, or the support for multiple cards sucks
<PhoenixSTF> i got the ubuntu server 10.10
<apw> one thing you might try is swapping the cards, so the other one is the 'first' one
<smb>         * https://bugzilla.kernel.org/show_bug.cgi?id=15173
<smb>          * http://article.gmane.org/gmane.linux.ide/46352
<smb>          * http://thread.gmane.org/gmane.linux.kernel/1062139
<PhoenixSTF> yes well anole it works better but still outputs errors with wd
<ubot2> bugzilla.kernel.org bug 15173 in Serial ATA "sata_via VT6421 softRAID" [Normal,Resolved: code_fix]
<PhoenixSTF> the only problem is with the WD and Samsung HDD
<apw> if its card related it should move to the other one, and if its s/w t should stay with the slot
<smb> PhoenixSTF, Those are links to the previous bug reports and some mial threads
<PhoenixSTF> smb, done that!
<PhoenixSTF> apw i moved the card to every combination possible in 6 pci slots 
<PhoenixSTF> 1st, last, second, one after another, one before the other etc
<apw> so order doen't matter then whether its detected first or second
<PhoenixSTF> no
<PhoenixSTF> or alone
<PhoenixSTF> even alone gives trouble with the wd hdd
<PhoenixSTF> I got a 1TB seagate, no problem at all
<smb> apw, From the the gmane article it sound like you can get hosed depedning on number of drives and how much they send after the host indicates a hold
<PhoenixSTF> the 500 Gb wd caviar.... well handshake problem and blablabla
<PhoenixSTF> a lot of handshake problems but only on that controler....
<apw> but he has two controllers and its ok on one of them if i am reading right; yet they are the same contollers
<apw> that bit makes less sense to me
<PhoenixSTF> apw, I know thats what is bugging me!
<apw> yet if i understand you, and we switch the two identlce cards round the issue follows the bad card (ie swap the two slots they are in)
<PhoenixSTF> apw, yes but only with the Western digital and Samsung HDD
<apw> so there has to be something different with that actual card than the other one
<PhoenixSTF> they are diferent in design
<apw> even if only triggered by the specific HDDs
<smb> apw, So that may be some physical defect that gets triggered by certain drive characteristics...
<smb> eh you said that
<smb> already. :)
<apw> smb, yeah a defect on both, neither fatal on its own, only in combination
<PhoenixSTF> apw let me correct that, alone gives some issues 2
<PhoenixSTF> less but it gives
 * smb is thinking... was that pci or pcie
<PhoenixSTF> PCI
<apw> but the nasty thing for us, is the kernel thinks the two cards are the same cards
<PhoenixSTF> ?
<smb> It are the same I thought
<apw> <PhoenixSTF> they are diferent in design
<PhoenixSTF> irq are diferent
<PhoenixSTF> one is 16 other 17
<apw> no the two cards are not the same
<PhoenixSTF> no they arent
<PhoenixSTF> the chip is
<apw> yet they are i'd the same
<PhoenixSTF> manufacteur isnt
<PhoenixSTF> one has a esata port, the OK one
<PhoenixSTF> the other doesnt
<PhoenixSTF> one is green
<PhoenixSTF> other is red
<apw> yet the PCI information including the manufacturer _is_ the same on the two cards
<apw> from your pci output
<PhoenixSTF> do you guys what a picture from boath cards?
<smb> very confusing
<apw> PhoenixSTF, no i beleive you when you say they are different
<smb> Right
<apw> i am not actually interested in that they are different, i am interested in the
<smb> Just they seem to report as exactly the same
<PhoenixSTF> i know you believe, just well something might stand out you might notice ....
<apw> fact they _say_ they are not different
<apw> which either means they genuinely report they are not different
<apw> or there is some other bug which gets the identity wrong
<apw> but as i understand PCI ids they are fundamental things the cards return when interrogated
<apw>         Subsystem: VIA Technologies, Inc. VT6421 IDE RAID Controller [1106:3249]
<apw>         Subsystem: VIA Technologies, Inc. VT6421 IDE RAID Controller [1106:3249]
<PhoenixSTF> ok let me get this easier on you I got one extra card, i can mail it to any one of you
<apw> who makes the two officialy ?
<PhoenixSTF> apw the chip is the same on boath
<apw> PhoenixSTF, without the exact HDD drives which trigger the issue, this is not going to necessarily tell us anything (having the card)
<PhoenixSTF> thats os the only thing that is the same
<apw> right so the first id's should match and the second id's the ones i have pasted should not
<mjg59> One possibility is that they're different revisions and that that information is available somewhere in a chip-specific register
<PhoenixSTF> i can mail the HDD 2, has long has you return it!
<PhoenixSTF>  xd
<PhoenixSTF> xD
<mjg59> apw: There's no real reason why subsystem IDs should vary
<PhoenixSTF> i am going to poweroff my server and take out the OK board!
<apw> mjg59, lets look at it a different way, is it reasonable for two completely different sata cards to have the same primary pci ids ?
<apw> it doesn't seem so to me
<apw> 00:0c.0 RAID bus controller [0104]: VIA Technologies, Inc. VT6421 IDE RAID Controller [1106:3249] (rev 50)
<apw> 00:0d.0 RAID bus controller [0104]: VIA Technologies, Inc. VT6421 IDE RAID Controller [1106:3249] (rev 50)
<tgardner> apw, clone makers do it all the time.
<mjg59> apw: Sure
<mjg59> apw: It's the common case for generic parts
<apw> they are allowed to do that?  oh dear
<apw> i'd have expected the subsystem id to vary on clones
<smb> apw, I guess what you get is the identity of the chipset used not necessarily the brand and type of card
<apw> so any card specific bugs ... and you are dead
<PhoenixSTF> so no way to fix it?
<mjg59> apw: Well, it's difficult to see how you can produce a card-specific bug
<apw> bad wiring anything really
<mjg59> If there's a problem at the physical layer then it doesn't matter - the card's just broken
<mjg59> Not going to fix that in software
<apw> no indeed.  i was thinking where there are some modes which work and others not
<mjg59> Any vendor who's sufficiently uninterested in product differentiation isn't going to have changed thedrivers
<mjg59> So if it works under Windows with the vendor drivers then there's something we're doing wrong
<PhoenixSTF> ok let but why with WD cards? and why in linux?
<mjg59> The most likely explanation is that there's some bit in the card firmware that influences the behaviour
<apw> PhoenixSTF, does this card work with the 'bad' drives in windows
<PhoenixSTF> not tested it...
<PhoenixSTF> not windows fan....
<apw> (who is :)
<mjg59> So it may just be a bad card
<PhoenixSTF> correct
<mjg59> Timing tolerances may vary between driver manufacturers
<smb> mjg59, The explanation for the older fix for wd was that those could send more after being told to wait and the change doubled the watermark of the fifo buffer. Asuming the windows drivers may have used the bigger value. O
<PhoenixSTF> mjg59, sorry but the issue is with specific HDD, Seagate no problems at all, WD and samsung... well thats anoter thing
<PhoenixSTF> i got transmithion problems with the samsung and the card is now alone
<PhoenixSTF> exception Emaks
<PhoenixSTF> and Bad CRC
<PhoenixSTF> has i said before, I have a extra card, COmplements of Amazon, and i can give it to charity, so i dont mind giving to a developer to check it out
<smb> To be honest, as apw said, its not only having the card. It could be interaction with specific drives or even the board 
<PhoenixSTF> dont mind sending the hdd along with it
<PhoenixSTF> i am Pro Ubuntu
<PhoenixSTF> when i mean pro is suportive
<PhoenixSTF> i dont mind lending or giving stuff to get something done...
<PhoenixSTF> has long has everybody benifits from it
<apw> we're probabaly not the best people to send such a thing to, probabally the driver maintainer would be better placed to make sure of it to fix the issue
<PhoenixSTF> or if you whant i can give access to my server with boath drives in it
<PhoenixSTF> apw, well i just want to help on getting it fixed, a lot of people are complaining on the same thing...
<PhoenixSTF> so who do i talk 2????
<PhoenixSTF> xD
<apw> hmmm, normaly i file bugs in upstream bugzilla and sub the maintainer in MAINTAINERS
<PhoenixSTF> oh and guys apw, smb, and mjg59, sorry for any trouble i might have caused and thanks for your support :)
<apw> no trouble
<PhoenixSTF> ok apw tell me how Yoda
<smb> Jeff Garzik would be sata maintainer, but in pathces there is also a JosephChang from via direct...
<PhoenixSTF> yes i see
<PhoenixSTF> so i register in it
<PhoenixSTF> what do i do?
 * apw is unsure what you are asking
 * smb probably would try writing to JosephChang. He cannot do worse than not respond
<PhoenixSTF> LOL
<sforshee> I'm looking more advice on the toshiba resume problem I asked about last week (hanging for 5 minutes in the ACPI _WAK method)
<sforshee> Messing with the triggering of the timer interrupt didn't change anything, I think what the bios is reporting is correct based on what I saw
<sforshee> Although I think there is some sort of problem related to the hpet, I'm not sure what it is or if it has anything to do with the hang during resume
<sforshee> I've pasted some excerpts from the disassembled AML and a trace of the _WAK method execution
<sforshee> http://pastebin.ubuntu.com/571148/
<sforshee> http://pastebin.ubuntu.com/571149/
<sforshee> Of interest is the point in the trace where the timestamp jumps 5 minutes into the future
<sforshee> This corresponds to the TRAP method in the AML source, right after it writes a value to some IO space
<sforshee> I assume this represents making some sort of call into the BIOS?
<sforshee> Any ideas on how to debug this?
<mjg59> Yes, it means it's going into the BIOS
<mjg59> It also means that there's no practical way to debug what it's doing
<sforshee> Whatever it's doing, it seems to be stuck in there until there's an interrupt from the hpet
<sforshee> Because if the hpet is in periodic mode when this happens, it resumes quickly
<mjg59> It's entirely possible that the system management code waits for an interrupt but doesn't actually set one up
<mjg59> Maybe we should just put the HPET in periodic mode over suspend/resume
<sforshee> The hpet is being used as the broadcast tick device, so would that be something the tick code would do?
<sforshee> The hpet resume as already run by the time this is happening
<sforshee> s/as/has/
<mjg59> It would need some special casing
<sforshee> okay, I'll poke around at the code a bit and see if I can come up with a sane way of doing that
<sforshee> thanks mjg59 !
<cking> I wonder if Windows puts the HPET into periodic mode over S3
<mjg59> cking: Windows doesn't do tickless
<cking> aha
<mjg59> I think they go to a minimum of 60Hz
<cking> hence we catch these corner cases and windoze doesn't
 * apw_ scoffs a dog
<apw_> heh ... doughnut
<smb> Who let the dog out? :)
<apw_> cat is away ..
<tgardner> apw: weren't you and JFo working on how to _not_ spam certain classes of bugs? tracking bugs for example.
<apw_> yeah some are excluded ... what got hit? 
<tgardner> apw: bug #718839
<ubot2> Launchpad bug 718839 in linux "QA Regression test kernel-security reports two failures on 2.6.24-28.84 Xen" [Undecided,Incomplete] https://launchpad.net/bugs/718839
<apw_> will look ... likely missing a tag
<tgardner> apw: so, something bjf's create-* tools should add ?
<apw_> waiting for it to load to check, but they have tags so likely we are avoiding them
<apw_> not
<bjf> tgardner, current versions of create-* tools addd "kernel-release-tracking-bug" and "kernel-cve-tracking-bug" tags
<bjf> apw, ^
<tgardner> bjf, which this tracking bug did not have.
<tgardner> guess that explains it
<bjf> tgardner, bug # ?
<tgardner> bjf: bug #718839
<ubot2> Launchpad bug 718839 in linux "QA Regression test kernel-security reports two failures on 2.6.24-28.84 Xen" [Undecided,Incomplete] https://launchpad.net/bugs/718839
<bjf> tgardner, for a while i was using "kernel-tracking-bug"
<bjf> tgardner, that is not a bug that we created
<tgardner> bjf, ah, I see.
<tgardner> then they deserve to get spammed :)
<bjf> well, i wouldn't say that but :-)
<apw> spam them spam them
<smb> tgardner, I seems the v2.6.32.29.13 is there. That it went from v2.6.32.28.13 would just mean there is no drm33 update
<smb> Or did I misunderstand the question alltogether?
<tgardner> smb,  there doesn't seem to be a v2.6.32.28.* tag
<tgardner> so, you skipped .28 ?
<smb> tgardner, Are you looking on kernel.org or kernel.ubuntu.com?
<tgardner> smb, git://kernel.ubuntu.com/smb/linux-2.6.32.y-drm33.z.git
<smb> tgardner, That would be my testing ground and proe to forgetting tags
<tgardner> ah, how inconvenient.
<tgardner> smb, what is the kernel.org path ?
<smb> tgardner, I (hope) to have it in the announce. git://git.kernel.org/pub/scm/linux/kernel/git/smb/linux-2.6.32.y-drm33.z.git
<smb> tgardner, But I just pushed the last tag to kernel.ubuntu.com
<tgardner> smb, OK, I changed path to kernel.org
<smb> Yes, that is better as its the official thing
<bjf> smb, your email had:  git://git.kernel.org/pub/scm/linux/kernel/git/smb/linux-2.6.32.y-drm33.z.git
<smb> bjf, Good, so that should be correct
<apw> http://people.canonical.com/~apw/cve/pkg/linux.html
<bjf> JFo, can you accept nominations on: bug #723945 ?
<ubot2> Launchpad bug 723945 in linux-ti-omap4 "CVE-2010-4258" [Undecided,New] https://launchpad.net/bugs/723945
 * jjohansen -> lunch
<JFo> bjf, I can
<JFo> bjf, I'm getting timeout errors
<bjf> heh, figures
<JFo> but I'll work on it until I'm done
<bjf> thanks
<JFo> np
<JFo> this timeout is making me crazy. I haven't been able to accept the first nomination yet :-/
<apw> bjf, did you get your noms done?
<bjf> apw, nope, but it's not holding me up
<apw> bug # ?
<bjf> bug #723945
<ubot2> Launchpad bug 723945 in linux-ti-omap4 "lockdep warning in KSM" [Undecided,New] https://launchpad.net/bugs/723945
<bjf> ok, that's just odd
<apw> bjf, hrm, timeouts for me on them all
<JFo> apw, I gave wgrant the oops number in #launchpad
<JFo> I'm hopeful that there is something going on behind the scenes to address it
<apw> JFo, ack, launchpad is a mess
<JFo> yup :-/
<JFo> bjf, any reason that guy changed the title of the bug?
<JFo> or was that expected
<bjf> JFo, not that i'm aware of, was just discussing with tgardner
<JFo> ah
<JFo> bjf, I am still checking your bug periodically, still no joy yet
<bjf> JFo, heh, thanks, maybe just ignore it til tomorrow
<JFo> I'l hold off and try again before I drop off tonight. Just wanted to let you know I hadn't forgotten about you :)
<jjohansen> sconklin, bjf: that hardy xen kernel from the ubuntu-on-ec2 ppa is special
<jjohansen> it builds by pulling in linux-source as a dependency and then copies the kernel source in and uses the debian dir and patches in the directory
<jjohansen> its a mess, and it is going away.
<jjohansen> but I am not sure how soon, there is still testing etc of the new image builds to be done
<jjohansen> the new image build == to how the packages are pulled in and rolled into the ami image to be published for use on ec2
<sconklin> jjohansen: ok, thanks, I'm just not clear on what kernels we deliver for ec2 and/or xen and where they are built, etc
<jjohansen> sconklin: apparently neither am I :)  I had thought we were pulling in a the hardy -xen kernel for the images, but what really was being pulled in was a custom ppa based on that.
 * jjohansen smb and smoser (mostly smoser) are working on changing that
<jjohansen> for the other kernels, there are the karmic and lucid ec2 topic branches, and maverick and natty -virtual flavors
<jjohansen> so just to be clear hardy will be moving to the the hardy -xen kernel but its not there yet
<jjohansen> sconklin: we also provided an intrepid ec2 kernel from the same ppa as the hardy kernel, but intrepid is no longer supported so you can forget it.  And we never supplied a proper jaunty kernel
<sconklin> ok, thanks.
<JFo> stepping away to grab some dinner bbiab
#ubuntu-kernel 2011-02-24
<smoser> for anyone who cares... (jjohansen, sconklin-gone, kees )... a short history of hardy on ec2 (as I understand it.. I wasn't really around for it)
<smoser>  * ubuntu started getting onto EC2 after hardy was released, or at least late in its cycle, and things were thrown together
<smoser>  * the ppa as utilized for a couple reasons, probably, some I'm not aware of, but the primary reason was so that you could include "ec2-modules", a virtual package that that ppa kernel build provided.
<smoser>   That package did not contain a /boot/vmlinuz , as ec2 didn't use one anyway (kernel and ramdisk loaded outside the image)
<smoser>   It was an optimization, that really turned out to be a pain
<smoser>  * image builds pulled from that ppa with 'ec2-modules', and publishing the kernels (aki/ari) was a manual process... its a pain
<jjohansen> smoser: yeah, that lines up with what I know, caveat /me wasn't around for it either
<smoser>  * we're now moving to using the linux-xen from the archive proper.  This makes the process identical to what we have for karmic, and very similar to what we have for lucid and onward, and its really much easier to maintain.  We're moving here, but we want to be careful and not regress anything.
<jjohansen> yep, and thanks again for doing the work on building the image
<smoser>  our daily builds are now pulling from the archive proper. we'll hopefully be able to refresh images with this new process.
<stoja> kernel 2.6.38 is compatible with Maverick ? I've got problems with fgrlx drivers :)
<htorque_> hello everyone! bug 721389 - there's a patch applied upstream, should i remove any tags from the bug report?
<ubot2> Launchpad bug 721389 in linux "Boot time regression 2.6.38" [Undecided,Fix committed] https://launchpad.net/bugs/721389
<apw> htorque, god work finding the fix ...looking at bug
<htorque> apw, heh, no credit to me - i only compiled and tested like mad
<apw> its more than most do, it is more common to get repeated "why have you not fixed this bug yet" calls
<apw> and you get your name in the kernel history for your trouble :)
<apw> bug 634487
<ubot2> Launchpad bug 634487 in linux "t1.micro instance hangs when installing java" [High,Confirmed] https://launchpad.net/bugs/634487
<apw> http://reports.qa.ubuntu.com/reports/jfo/kernel-buglist-by-team.html
<lamont> so... how come when I rebooted this morning, I lost wireless to my broadcom 4727?
 * smb looks for signs of solar winds
<lamont> wireless is kinda important to my sprinting
<smb> It would help us poor souls to narrow this to a certain release
<apw> lamont, on what release of what
<lamont> well... I tend to stay up-to-date on packages.  was clean on friday, and had working wireless
<apw> and don't tell me you updated when on the sprint
<apw> that is very very very stupid :)
<smb> n/me stays up to date on lucid
<lamont> y'all have done such a good job of not breaking me, that I forgot to not trust you
<apw> heh ... so what updated last night?
<lamont> well... I don't know that I rebooted at all this week
<lamont> reboots I'm not so good at doing that often when living on my laptop
 * apw is assuming this is dapper you are running
<lamont> maverikc
<apw> hmmm, not expecting issues with maverick
<lamont> neither was I
<smb> IS that broadcom usually using wl driver?
<smb> (so maybe dkms package compilation broke)
<lamont> I believe it is
<lamont> yeah - we get wl.ko
<smb> Is that loadable or complaining about symbols?
<apw> so do you have a wireless interface ?
<apw> yeah is it loaded, what does modprobe wl.ko say
<apw> the last kernel update in -updates was 3 weeks ago .. there is a -proposed from 14 hours ago thought
<apw> do you have -proposed enabled ?
<apw> or ... what does cat /proc/version_signature say
<lamont> http://paste.ubuntu.com/571617/ <-- grep -e ' installed' -e purge /var/log/dpkg.log
<lamont> no proposed
<lamont> cat /proc/version_signature 
<lamont> Ubuntu 2.6.35-25.44-generic 2.6.35.10
<apw> so you have not had a new kenel over the period
<lamont> http://paste.ubuntu.com/571620/ <-- iwconfig eth1
<smb> apw, but it seems a new wl dkms package
<apw> so its there as far as the kernel is there
<lamont> installing the backports-modules thing was an attempt that simply removed the interface completely
<lamont> smb: I reinstalled bcmwl-* in a first attempt
<apw> it has not changes since release
<lamont> it didn't help that I was wired in the room last night
<apw> so ... i'd say that nothing has changed
<smb> Ah ok
<smb> And the interface is actually there
<apw> so whats the symptoms
 * lamont ponders where the kill switch could be
<smb> just not associated
<apw> whats the machine
<lamont> inspiron 15R (N5010)
<apw> they sometimes have them near the hinge on the side
<apw> a little slidey bit of unmarked plastic
<apw> i didn't know my dell had one for a year till i knocked it :)
<lamont> old-dell had one, this one seems to not have the slidy bit
<lamont> though the f2 key does have a antenna transmitting thing going on there
<apw> does rfill list list it
<lamont> rfill?
<apw> worth hitting it, it may be bios controlled
<apw> rfkill list
<lamont> 0: dell-wifi: Wireless LAN
<lamont> 	Soft blocked: yes
<lamont> 	Hard blocked: yes
<apw> ok so thats blocked in HW as far as kernel is concerned
<apw> hit the key and re-run
<apw> apw@agent57:~$ rfkill list
<apw> 0: brcmwl-0: Wireless LAN
<apw> 	Soft blocked: no
<apw> 	Hard blocked: no
<lamont> 0: dell-wifi: Wireless LAN
<lamont> 	Soft blocked: no
<lamont> 	Hard blocked: no
<apw> smb, interesting, natty level we get info from the wl driver direct
<apw> now wait a bit and see if it assoc's
<apw> i fine wl takes up to minute to notice you have turned it back on
<lamont> bah
<lamont> thanks muchly
<lamont> brb
<apw> it is possilbe its persistant too
<apw> recorded in nvram by bios
<smb> apw, Yes, interesting. At least its not our fault this time. :)
<apw> handy for next time
<cooloney> apw: one quick question, if i wanna get the abi file of current kernel version, I can just build the kernel to get it
<cooloney> apw: instead of run script getabis
<apw> a build does generate the _new_ one yes
<apw> so you would need to build the previous versio
<apw> to get the abis for that version
<cooloney> apw: great, man. thanks
<cooloney> yeah, i think so
<Kano> hi, why is natty not yet rebased to rc6?
<apw> Kano, why do you think it is not
<Kano> no tag
<Kano> last is rc5
<apw> what is the last tag you have
<Kano> UBUNTU: v2.6.38-rc5 rebased fixes Bug #716811
<ubot2> Launchpad bug 716811 in linux "[SandyBridge] kernel BUG at /build/buildd/linux-2.6.38/fs/nfsd/nfs4state.c:3132!" [Undecided,Fix released] https://launchpad.net/bugs/716811
<Kano> seems to be the last rebased tag or not?
<apw> Ubuntu-2.6.38-5.32
<apw> is the last rebase tag
<apw> the commit you refer to there is simply a changelog update to an old commit
<apw> old release
<Kano> ok
<apw> you can simply tell from the Makefile though
<Kano> could you tell me how to disable everything execpt generic+generic-pae builds for use with pbuilder?
<apw> just change the flavours= list in the arch.mk
<Kano> and the udebs i dont need?
<Kano> also no libc-dev
<apw> remove the entries in kernel-versions.in
<apw> there is a do_ thingy for libc-dev to disable it
<Kano> ah
<Kano> because the interesting thing is,when i use prebuild kernels
<Kano> then nvidia drivers usually work against it but fglrx always fails - on a squeeze system
<apw> yes the binary drivers have not been updated, i don't expect either of them to work with natty kernels at the moment
<Kano> no thats not the problem
<Kano> they work with the pure rc6 kernels from mainline with ease
<apw> well it is a problem, and one we don't care about
<Kano> thats why i ask to build only the things which i need...
<Kano> i did that some time ago but forgot it already
<Kano> on hd install mainline kernels are fine
<Kano> just missing aufs is bad for live mode
<Kano> i first thought i do not need to rebuild em anymore because the hpa disable patch was removed but well, it did not work out that way...
<Kano> did you ever try r8192e_pci?
<apw> seems that the binary driver issues are the xorg changes and not kernel related
<apw> at least for ubuntu
<apw> nope
<Kano> most likely
<Kano> i hate that driver
<Kano> it is not working at all, also the 2nd driver as addon does not work
<apw> luckily its not one i own it seems
<Kano> the only way to use wlan with my samsung n510 is to use ndiswrapper
<Kano> also it seems that .38 needs a newer nouveau driver
<TeTeT> on a thinkpad t-61 I see an acpi video event generated when the lid is opened. I guess this comes from the BIOS and I wonder if I can somehow disable it by consuming it in a kernel module before it gets sent to user space, especially gnome-settings-daemon. Any hints if that's possible at all?
<Kano> the first thing you mentioned is in the debian.master/rules.d right?
<apw> yes
<apw> TeTeT, why would you want to suppress it ?
<TeTeT> apw: a customer is not happy with the video toggling when opening the laptop lid with an external display attached. They want to remove that
<apw> TeTeT, i am sure it is possible, though it would likely be easier to fix g-s-d to allow you to tell it to not do whatever it does when you get it
<TeTeT> apw: problem is that g-s-d does not differentiate between the fn-f7 hotkey and the video event upon lid open
<apw> they don't want it to enable the display
<apw> how do they both appear in input-events ?
<TeTeT> apw: they want to enable the display, but not the toggling between modes
<apw> are they different there?  if they are on different input event channels you may be able to make them separate X keys
<TeTeT> apw: don't know, I checked with acpi_listen, how to see it with input-events?
<apw> ls-input will show you all the differnet channels
<apw> often lid is a separate one, and you can see the event there
<apw> /dev/input/event2
<apw>    bustype : BUS_HOST
<apw>    vendor  : 0x0
<apw>    product : 0x5
<apw>    version : 0
<apw>    name    : "Lid Switch"
<apw>    phys    : "PNP0C0D/button/input0"
<apw>    bits ev : EV_SYN EV_SW
<apw> on this machine here i have an entire chanell just for the lid
<TeTeT> need to install input-utils via 3g first, one second
<TeTeT> argh, protocol mismatch, as I'm testing the natty kernel on lucid right now, need to reboot
<apw> TeTeT, heh yeah, i know, it is compatible so a rebuild is sufficient
<TeTeT> apw: finally rebooted, I see /dev/input/event0 for Lid Switch, EV_SYN, EV_SW and /dev/input/event5 for Video Bus, EV_SYN, EV_KEY
<Kano> apw: is that full_build var true for pbuilder?
<apw> Kano, yes
<Kano> then i should patch that too
<apw> TeTeT, so you need to  input-events 0 etc which will show you what comes out of there for each
<apw> hit the lid switch see what it does, then hit the other key and see whic channel that comes out of and what it looks like
<apw> you may be able to map the lid one to something else
<TeTeT> apw: the lid is fine, it's just the video toggle that needs to go. It reports EV_KEY KEY_SWITCHVIDEOMODE (0xe3) pressed and released
<TeTeT> let's see what fn-f7 does report
<TeTeT> nothing there
<apw> it'll be on one of the other channels, likely the keyboard
<TeTeT> apw: yes, it's on channel 7, ThinkPad Extra Buttons
<apw> what do you get for that
<TeTeT> the same, EV_KEY KEY_SWITCHVIDEOMODE (0xe3) pressed and released
<Kano> what was the position to disable d-i?
<Kano> kernel-versions.in`
<apw> yes
<apw> TeTeT, was there more than one line per button in either case ?
<TeTeT> apw: yes, first a pressed event, then EV_SYN code=0 value=0, then the released event, then another EV_SYN code=0 value=0
<TeTeT> apw: do you want me to pastebin the output?
<apw> for both yes please TeTeT 
<TeTeT> apw: ok, need to transfer it via USB
<Kano> hmm when i do a debian/rules clean with kernel-wedge 2.73 u 1, then i get unintialized value builddep
<TeTeT> apw: thinkpad key is http://pastebin.ubuntu.com/571717/ and video is http://pastebin.ubuntu.com/571719/
<mjg59> TeTeT: You could hack the ACPI video module not to send that event
<mjg59> On the grounds that you get the key event via the Thinkpad driver
<mjg59> But that's about the limit of it
<apw> it does seem that the lid should really produce a 'SW_LID' open close event and not that one
<TeTeT> mjg59: I unloaded thinkpad_acpi and the event is still generated - you think that's evidence that it comes straight from the bios?
<TeTeT> apw: the lid _also_ produces a EV_SW code=0 value=1 on /dev/input/event0 when closing
<TeTeT> and code=0 value=0 when opening, followed by a EV_SYN each time
<TeTeT> I wonder if that event is also generated on newer generation thinkpads
<mjg59> TeTeT: Yes
<mjg59> If it's coming via the video device it's a notification on the VGA device from te firmware
<mjg59> apw: It's common to send a display siwtch notification on lid state change to force the OS to reprobe outputs
<mjg59> Unnecessary in Linux, but common
<TeTeT> how could g-s-d differentiate between the user wanted fn-f7 and this implicit toggle?
<mjg59> It can't
<TeTeT> it seems that for the lid close / open it would be best to just apply it's configuration for that setting
<mjg59> Like I said, you can hack the ACPI video driver
<TeTeT> probably not me ;)
<mjg59> But no, there's no generic way to fix this
<TeTeT> apw + mjg59 : thanks for your time, guess I'll have to tell the customer that there's no way out of this short of hiring a kernel developer to get it done
<mjg59> TeTeT: Also, such a hack wouldn't go upstream
<mjg59> It'd be a one line diff, though
<TeTeT> mjg59: hmm, but where would I find that ACPI video driver when not in thinkpad_acpi?
<TeTeT> gpu/drm/i915?
<mjg59> drivers/acpi/video.c
<mjg59> Just comment out every line that says keycode = KEY_SWITCHVIDEOMODE
<mdz> apw, around?
<apw> mdz, hi
<mdz> apw, good day to you
<mdz> I'm wondering if there is a straightforward way to tell, from userspace, if a given pid is actually a kernel thread
<mdz> e.g. via something in /proc
<apw> hmm
<mdz> the only info I found so far was in top.c, which says:    /* if a process doesn't have a cmdline, we'll consider it a kernel thread
<mdz>       -- since displayed tasks are given special treatment, we must too */
<mdz> which seems less than rigorous
<mdz> but maybe it's correct?
<apw> not very satisfactory
<mdz> FWIW I'm wondering in order to fix https://bugs.launchpad.net/ubuntu/+source/apport/+bug/504340
<ubot2> Launchpad bug 504340 in apport "ubuntu-bug can't report bugs on kernel threads" [Wishlist,Triaged]
<mdz> it would be pretty straightforward to fix given such a test
<Kano> apw: i used this: http://kanotix.com/files/hellfire/ubuntu/ubuntu-kernel-build-only-generic.txt
<Kano> apw: and i still got:  linux-source/doc/tools/tools-common packages
<Kano> how to get rid of those
<PhoenixSTF> apw, hey m8
<apw> mdz its possible you could use the 'size' component of the /proc/$$/stat output, which seems to be 0 for such a thing
<mjg59> mdz: exe won't point anywhere
<Kano> i set source/doc to false, still there...
<apw> mdz, sorry /statm
<mdz> mjg59, since it's a root-owned process, I don't think I can even readlink(exe)
<mdz> apw, hmm, that sounds fairly unlikely to generate a false positive
<apw> mdz a quick sanity check here on a random latop on maverick seems to show size 0 only on things which i believe are kernel threads
<mdz> apw, statm looks the same for a zombie process :-/
<mjg59> mdz: Does a zombie have any vm entries in status?
<apw> mdz how did you generate a Z so i can poke one
<apw> yeah the whole of stat and statm on one would be good
<mjg59> And status
<mdz> http://paste.ubuntu.com/571741/ = stat, statm, status
<apw> mdz i assume $3 of /proc/<zombie>/stat is a Z
<mdz> apw, I happened to have one around
<mjg59> What does ps use for putting [] around them?
<apw> so you could elide those
<mdz> forking something which exits and not wait()ing for it should create one
<mdz> mjg59, that was the first place I looked but it makes my eyes bleed
<mjg59> Pragmatically, check size in stat and check that it's not a zombie
<mdz> and of course it puts [] around zombies too
<mdz> but it also says <defunct> so it's checking for state=Z probably
<mdz> mjg59, it appears there are no vm entries in status for a zombie
<apw> mdz, but a safer test might be statm $1 == 0 and statm $3 != 'Z'
<mdz> mjg59, but there aren't for kernel threads either
<mdz> yeah, I think it's probably most practical to do statm == zeros && state!=Z
<apw> mdz do you have stat and statm output for your Z, save me writing something to gen one
<mdz> apw, the pastebin link I pasted earlier is that
 * apw <-- blind
<apw> got it now
<apw> mdz, mjg59, ok in theory the $8 of stat is the process flags and converted to hex 200000 bit is PK_KTHREAD
<apw> PF_KTHREAD even
<mdz> apw, $8 == the eighth field counting from 1?
<mdz> if so, that's -1 for the iwlagn thread
<apw> yeah, the big big number
<apw> ahh $9 sorry
<apw> 9 (events/0) S 2 0 0 0 -1 2216722752 0 0 0 0 0 4894 0 0 20 0 1 0 32 0 0 18446744073709551615 0 0 0 0 0 0 0 2147483647 0 18446744073709551615 0 0 17 0 0 0 0 0 0
<apw> 2216722752
<apw> 84208140
<apw> 00200000
<apw> so thats a kthread ... of course you are relying then on that number never changing, which is tricky
<apw> but i guess for apport we might be ok there
<mdz> apw, that seems to work reliably
<mdz> apw, I don't suppose there's any way to find out which module owns that thread?
<mdz> then I could put that hint into the bug report
<apw> mdz not that i know of at the moment
<apw> and now that damnable unity is crashing on login again ... ARRRG
 * apw lunches
<PhoenixSTF> apw, when you come back i got some questions about that thing yesterday :)
<JFo> mdz, I updated that apport bug and fix released it.
<mdz> JFo, cool, thanks
<JFo> my pleasure :)
<PhoenixSTF> hey guys i was here yesterday with issues on a vt6421 pci controler
<PhoenixSTF> i got some new info, its givving issues no matter what hdd is on, and only outpust badCRC and Esmask error when using hi tranfers rates off the HDD
<PhoenixSTF> *high transfers rates
<PhoenixSTF> any fix for this specific issue for this pci board?
<hallyn> apw: what is the kernel team stance on taking patches from -mm?  (user namespace patches are there now, would be sort of nice to have them in natty)
<PhoenixSTF> back
<PhoenixSTF> apw you there m8?
<apw> s'up
<PhoenixSTF> hey
<PhoenixSTF> remenber yesterday i aked about a posssible fix for that card
<PhoenixSTF> well i narrow it down, it bugs with whatever hard driver is pluged on it, but only when massive amounts of data is requested
<PhoenixSTF> if it's like 2 to 10 Mb per sec its ok
<PhoenixSTF> when it goes over 30 it start with Badcrc and Esmask error
<PhoenixSTF> apw, any advice for me m8?
 * smb thinks of a blender but that is not helpful
<PhoenixSTF> smb, LOL yes well i got 2 choices, either put away 2 controler cards, and buy a new one, or beg for someone to please make fix
<PhoenixSTF> smb, i am on the begging part now
<PhoenixSTF> smb, altouth i will consider yours has a 3rd one!
<PhoenixSTF> xD
<smb> PhoenixSTF, To be honest the way you describe it. It sounds a bit like it actually could be really phisicallly broken. And there is not much any driver could do there.
<joaopinto> PhoenixSTF, SATA2 or SATA3 ?
<PhoenixSTF> os discos sao sata2, mas placa aceita 1,5
<joaopinto> keep english please ;)
<PhoenixSTF> sorry
<PhoenixSTF> ;
<joaopinto> PhoenixSTF, do you get something like https://bugs.launchpad.net/ubuntu/+source/linux/+bug/285892 ?
<ubot2> Launchpad bug 285892 in linux "ata1.00: exception Emask 0x0 SAct 0x807f SErr 0x0 action 0x6 frozen" [Unknown,Fix released]
<PhoenixSTF> yes well its a VT6421 controler so its accepst only 1,5 tops
<PhoenixSTF> the HDD are sata 2, samsung 1,5 tb and a Seagate 1tb
<DBO> chase told me I could come here and ask if there is anything I can do to help my system stay responsive during IO (non IO bound apps, actually pretty much everything, stop responding during hard drive read/writes)
<PhoenixSTF> ubot2, yes i have checked taht but still a lot of people complain about it only works for some
<ubot2> PhoenixSTF: Error: I am only a bot, please don't think I'm intelligent :)
<PhoenixSTF> oh crap ;)
<joaopinto> PhoenixSTF, with my newer system I have replace the HD 3 consecutive times, the motherboard was replaced, in the end I had to use a different HD brand
<PhoenixSTF> joaopinto, that was unlucky :S
<PhoenixSTF> joaopinto, that was unlucky well i just got these  boards i got a 3rd one and its working fine, with the same COntroler vt6421
<joaopinto> whatever was the issue somehow it was more severe with Linux, Windows was usable
<joaopinto> and also more severe between an older Fedora kernel and a recent Ubuntu version
<PhoenixSTF> so problem was the kernel,
<PhoenixSTF> i recon it takes a lot of work on a kernel
<PhoenixSTF> speacialy when new hardware comes out
<joaopinto> I don't know, from the comments on both bug 285892, bug 285892, and bug 569680 I was unable to figure the cause
<ubot2> Launchpad bug 285892 in linux "ata1.00: exception Emask 0x0 SAct 0x807f SErr 0x0 action 0x6 frozen" [Unknown,Fix released] https://launchpad.net/bugs/285892
<ubot2> Launchpad bug 569680 in linux "Hard disk write/read freezes for 10 seconds several times in session" [Undecided,New] https://launchpad.net/bugs/569680
<PhoenixSTF> yes the last one hapens to me
<PhoenixSTF> same error output and some more stuff
<PhoenixSTF> but thats about it
<PhoenixSTF> but only hapens when to mutch data is requested
<joaopinto> PhoenixSTF, does it happen at every boot ? Or do you have instances of long periods running without issues ?
<PhoenixSTF> joaopinto, its a home server, so boath hdd are not the system, and the problem only hapens when i start to use the hdd at full transfer speed.
<PhoenixSTF> joaopinto, if i am whatching a movie its ok, if i copy it it starts with the errors and freezing
<PhoenixSTF> joaopinto, and sometimes i guess i have periods of no issue with one hdd, its hard to figure out... sorry
<joaopinto> ok was just comparing with my case, which seemed to be initialization related, I could reboot and use the disk for several hours without errors, and perform the same activity after a power recycle and just getting freezes a few minutes after booting or during boot
<joaopinto> it was disk activity related, but not persistent between recycles
<PhoenixSTF> not the same thing.... it hapens whenever u use the hdd full speed
<joaopinto> ok
<PhoenixSTF> http://pastebin.com/c7AzfhQ1
<PhoenixSTF> here is my log
<hggdh> jj-afk: any news on the hardy ec2 kernel having a signature of -generic?
<sforshee> apw, have you seen this thread on lkml: http://thread.gmane.org/gmane.linux.kernel/1103561/focus=1104637
<sforshee> wondering if we have something we need to push upstream...
<herton> sforshee, indeed, we carry a patch which fixes this issue
<sforshee> hmm, wonder why we've been sitting on it then
<herton> while I was working with Mandriva, I submitted a different patch here: https://bugzilla.kernel.org/show_bug.cgi?id=26232
<ubot2> bugzilla.kernel.org bug 26232 in Console/Framebuffers "Multiple framebuffer oops and sysfs attribute deadlock" [Normal,New]
<herton> didn't knew Ubuntu fixed it 6 months ago, these days I was looking and found apw already had fixed 6 months ago the issue
<herton> I posted on lkml the same patch on bug report, but didn't got answers from what I remember
<apw> herton, yeah its one of those patches which is hanging about and i really really need to push up
<herton> Comparing the both solutions are ok, just I don't cared in my patch about mm_lock issue in do_mmap
<hallyn> apw: how do ya'll usually feel about taking patches (into natty kernel) from -mm ?
<apw> hallyn, depends what they are, i like things fixed
<hallyn> apw: alas these are not bugfixes, but user namespace patches
<hallyn> apw: there's probably no hurry on it.  It just came out of UDS that I would see about getting them into natty kernel, so I"m following up :)
<apw> hallyn, and why would i want them
<apw> well feature freeze was today 
<hallyn> bc they allow root in a container to not be able to kill or ptrace tasks in other namespaces
<apw> hallyn, it is pretty late to be changing semantics, so if you want them you will need to convince me they are worthy
<hallyn> apw: thanks, i think i'll be more interested in getting them into o release.  (though hopefully they'll go into linus' tree pretty quickliy anyway)
<JFo> bjf, still no joy getting those nominations approved.
<hallyn> apw: given ff, i have no desire to seek exception...
<hallyn> apw: thanks
<apw> hallyn, well if they are security related it may make sense to persue them
<apw> i normaly prefer them to be in mainline, even if its for .39
<hallyn> apw: yup, we'll see how they fare.  thanks
<apw> get them out for review, copy kees on them, i assume he is the protagonist
<kees> hm?
<kees> I am interested in hallyn's patches, but not in much position to drive them.
<apw> kees i think the key is if you deem them a security consolidation then we can be more flexible taking them
<apw> sforshee, would you email me the link to that thread so i don't forget to push out my patch pile pls
<sforshee> apw, will do
<PhoenixSTF> ok what is Ultradma mode?
<herton> apw, do you mind if I reply to that thread, saying that you will push the patch? I want to point Linus to the bug report with the testcase too
<apw> herton, sure, cc: me on the reply pls ... i am assuming you know my fix fixes this
<kees> apw: I guess I'm trying to say that I don't have a strong opinion about those patches, but if hallyn wants to see them in, go for it. hallyn will you be able to support those patches if something needs additional tweaking going forward?
<hallyn> yup, i'll be supporting (and continuing development) upstream anyway
<JFo> <- lunch
<hallyn> kees: apw: ^  however I'm happy waiting until I get a few more patches and getting the result into o
<jjohansen> apw: I have a small one line fix for aufs, its just a bug fix so its no rush but if your holding off it might be nice to get it in
<jjohansen> hggdh: I don't know why you are getting -generic need to look at it more
<hggdh> jjohansen: thank you.
<apw> jjohansen, nice ... get it to me, and i'll get it committed
<jjohansen> apw: just opening the bug
<jjohansen> but I already have the patch
<PhoenixSTF> apw, how can i force the reading on hdd to be slower?
<jjohansen> apw: sent
<jjohansen> rebooting
<bdmurray> bjf: I tried approving your nominations in bug 723945 but lp is timing out
<ubot2> Launchpad bug 723945 in linux-ti-omap4 "CVE-2010-4258" [Undecided,New] https://launchpad.net/bugs/723945
<bjf> bdmurray, thanks, jfo has been having the same problem
<JFo> yup, making me rabid
<JFo> there is an LP bug open
<bdmurray> I think if there were only 1 task it'd work out better
 * JFo digs the # up
<bdmurray> so create 1 task, approve nominations, open other tasks
<JFo> bug 723999
<ubot2> Launchpad bug 723999 in launchpad "structural subscriptions taking 4.8 seconds during nomination editing POST" [Critical,Triaged] https://launchpad.net/bugs/723999
<bjf> bdmurray, it's being done via a script which is adding all the tasks
<bdmurray> okay, I was just thinking that doing it in the other order might avoid the timeout
<bjf> bdmurray, it could be that it is making the problem much worse
<bdmurray> the email interface might be a way to workaround it
<charlie-tca> vanhoof: hear you? as on my speakers? 
<vanhoof> charlie-tca: on irc :)
<vanhoof> having some timeouts connecting to another server
<vanhoof> although things seem to be fine here
<bjf> vanhoof, you quit again
<charlie-tca> well then, I guess so
<vanhoof> bjf: i give up
<vanhoof> bjf: its anything across the pond for me
<bjf> vanhoof, yes, i see you just got dropped again
<blag> I have a patch that adds some functionality to the kernel.  Linus' (newest) branch of the 2.6.38 kernel already has a better way to do the same thing.  Should I upstream my patch to the Ubuntu kernel devs?
<bjf> blag, we'll get it from the next .38 rc
<jjohansen> bjf, sconklin: looks like we have some regressions in the lucid and maverick ec2 kernels, I am looking into it
<bjf> jjohansen, thanks for the heads up
<sconklin> thanks
 * blag reads the channel topic (specifically that the Natty kernel is going to be a 2.6.38)
<blag> bjf: cool.
<blag> we should totally call the Natty kernel a ".38 special" just for grins  :-)
<rsajdok> Are there other wiki page like this https://wiki.ubuntu.com/DebuggingKernelSuspendHibernateResume
<rsajdok> that describe other kernel problems?
<rsajdok> All right. I found https://wiki.ubuntu.com/Kernel/Debugging
<Krunch> what kind of problem are you having?
<rsajdok> Krunch: Personally I have not. I want to learn to write patches for various problems.
<Krunch> to write patch you first need to figure out what is the problem, this is probably a good start: http://www.dedoimedo.com/computers/crash-book.html
<rsajdok> Krunch: thank you:)
#ubuntu-kernel 2011-02-25
<eugenesan> Hi all, I am experiencing data loss on USB storage devices while entering S3, can qemu/kgdb help here?
<jj-afk> eugenesan: what kid of data loss?,  What fs is on the usb storage, did you sync and unmount before suspend, ...
<eugenesan> jj-afk: Looks like data not committed to filesyste, ext4 loose journal, for example
<eugenesan> jj-afk: I am talking about root filesystem on USB
<jj-afk> Ah Bug #706795
<ubot2> Launchpad bug 706795 in linux "[All releases] Suspending with rootfs on USB, causes silent corruptions, kernel panic on mount attempt, data loss and leaving system unbootable." [Undecided,Confirmed] https://launchpad.net/bugs/706795
<eugenesan> Indeed, this is the bug
<jj-afk> so it is possible that using a vm to test on will help
<jj-afk> it will depend some what on where the bug is and how good the vm's usb emulation/pass through is
<jj-afk> it certainly can't hurt to try replicating it on a vm
<eugenesan> jj-afk: yes, I'll just wanted to check if someone already have tried.
<jj-afk> however, I will note that suspend/resume with an external dev mounted generally causes the fs to be unmounted
<jj-afk> and treated as if they are ejected and then reinserted
<jj-afk> unplugged/plugged ..
<jj-afk> it might help if you set USB persist
<eugenesan> Well with rootfs this different. No mount/umount events. I suspect USB-host get's reset/sleep too soon, before data got actually written
<jj-afk> yes, and this can be device specific
<jj-afk> it will depend on the devices driver and the device firmware, ...
<eugenesan> do you mean USB dongle specific or specific for USB-MassStorage in general?
<jj-afk> both really, or the interplay between them
<eugenesan> actually bug is persistent on variety of USB hosts and USB dongle, and correct for all Linux versions and flavors.
<jj-afk> basically a bug in the device, the device firmware, the computers firmware, the usb mass storage layer, or even the fs could do it
<jj-afk> correct for all Linux versions and flavors?
<eugenesan> yes
<jj-afk> so the variety of devices would point to the machine or the OS
<eugenesan> I think this case is just not treated in code, since with SATA it's almost same data path but working.
<jj-afk> by all linux versions do you mean all other versions?
<eugenesan> I mean, issue reconstruct easily on every HW and any Linux version, and I tried many...
<jj-afk> eugenesan: ah okay thanks for clarifying
<jj-afk> so yeah that would point to something in the usb code not handling this correctly
<jj-afk> have you tried with other filesystems
<eugenesan> I even suspect, in past, there were similar reports regarding SD and SATA...
<eugenesan> Yes, they all affected
<jj-afk> eugenesan: okay, well I know I have run some linux devices with the root OS on an sd card that could successfully suspend resume.
<jj-afk> I will take a shot at replicating
<jj-afk> but yes I have heard of root on SD cards being corrupted by suspend/resume before
 * jj-afk is going to finish reading your bug now
<TeTeT> following up on yesterdays query on the video switch key upon lid open on a Thinkpad, I know built a kernel where I've commented out all KEY_SWITCHVIDEOMODE in acpi/video.c, but the event is still generated. The customer tells me that there is no such event generated when a RHEL4 desktop is installed on the T61
<TeTeT> I grepped for KEY_SWITCHVIDEOMODE in the source tree,  but didn't find anything that looks like it would be used
<TeTeT> strangely with sudo input-events 5 I know get a KEY_UNKNOWN (0xf0) pressed and released, instead of 0xe3 as yesterday
<amitk> cking: something for your bedtime hacking: https://lwn.net/Articles/429812/ :)
<cking> amitk, sounds all too familiar
<cking> I downloaded the image yesterday, but got sidetracked
<amitk> * Run Intel's power management reference code to override your BIOS's configuration.  This includes writing the ACPI tables for P-states and C-states, replacing those normally provided by your BIOS.
<amitk> wow ^^
<cking> funny how that seems to admit that ACPI has failed to deliver
<TeTeT> found it, I commented the acpi_bus_generate_proc_event(...) call as well, then there is no longer a keypress event generated, even not an unknown one
<herton> apw, just a heads up, the guy which reported that race with framebuffer tested the patch, https://lkml.org/lkml/2011/2/24/442
<herton> should be good to go to repost it
<smb> herton, apw is not around today (only by luck)
<herton> smb, thanks for informing, I'll check with him again later then
<smb> herton, He took the day off today. Later would need to be Monday
<herton> hmm, then perhaps I should CC him again on lkml, he wasn't kept on all messages on the thread, as its his patch he will need to repost
<smb> herton, Keeping him on cc definitely is good
<herton> I added him on CC on my replies to the thread, but some of the replies were not on the messages he was on CC I think
<smb> Yeah, I am not sure he will keep track of the thread when not on cc. He gets enough mail to loose track even for the ones written directly to him
<JFo> <-lunch and errands bbiab
<hggdh> JFo: bug 725089 <- SRU testing
<ubot2> Launchpad bug 725089 in linux "QRT test-kernel-security causes kernel panic on EC2 AMD64 image" [High,New] https://launchpad.net/bugs/725089
<smb> hm, trying to do something with tsc...
<smb> hggdh, Is that the first try with ec2 from regression testing or was there a previous run that was ok?
<hggdh> smb: to my knowledge -- which is quite fragmented -- the first. i386 passes, BTW
<smb> hggdh, Ok, thanks
<bjf> smb, what's the right way to bump the abi in dapper, it doesn't seem to be the same rules as later kernels (just changing the abi in the changelog)
<smb> bjf, There is a bumpabi target that you run
<bjf> smb, AH!
<smb> bjf, And also be careful that Dapper (as Hardy) needs the control files and stuff stored in git with the update
<kees> bjf: if you're bumping dapper's abi, can you try to get it and the -meta package using the same ABI number? right now they're off by one.
<bjf> kees, will try
<kees> bjf: cool; thanks
<kees> I'm not sure if the linux-source-2.6.15 package or the meta needs to be bumped twice.
<kees> let me look
<smb> kees, They use the same abi number. I guess what you want is the same upload number
<kees> smb: no, they're not the same abi in the package name (yes, all the deps are correct, but it's goofy)
<kees> linux-source-2.6.15 | 2.6.15-55.93
<kees> linux-meta | 2.6.15.56
<kees> note 55 vs 56
<kees> bjf: so, linux-source-2.6.15 needs to go to -57 instead of -56, and then the meta can go to .57
<kees> and then I can drop these special-cases for dapper I've got in the archive kernel ABI checker :)
<smb> Oh, right. Well actually there is no abi number in the meta package
<bjf> kees, ok, i just went to 56
<smb> Just that abi number and upload number are close 
<kees> smb: I don't know what you mean by "upload number"
<kees> bjf: can you move linux-source-2.6.15 to 57?
<bjf> kees, will attempt to do so
<smb> kees, For the meta package 2.6.15.56  the 56 is the uplload number
<bjf> kees, :-)
<kees> smb: heh, okay, well, for every other kernel package, upload number == ABI number.
<smb> kees, For the linux kernel package 2.6.15-56.93 the 56 is the abi number and the 93 is the upload number
<kees> bjf: cool; thanks
<kees> smb: uhmm...
<smb> kees, It probably serves just the mental sanity
<kees> linux | 2.6.35-25.44
<kees> linux-meta | 2.6.35.25.32
<kees> that's maverick
<smb> Usually we only need a new meta package when the abi bumps
<kees> the meta's upload number is .32 not .25. .25 is the Abi
<smb> but it could also be for a different reason
<kees> smb: the problem, I guess, was that dapper lacked an ABI number
<kees> smb: so I guess I'm hoping to align dapper's upload number with the ABI, since for all the other releases, there is both ABI and upload number in the meta version
<smb> kees, I am rather hoping to be in June soon and not to have to care about Dapper any longer. :)
<smb> Otherwise, yes we probably added a meta number to avoid further confusion later
<kees> smb: yes! I'm going to throw a party for dapper eol
 * smb wished he could be there to join. :)
<bjf> smb, are you looking at bug #725089 ?
<ubot2> Launchpad bug 725089 in linux "QRT test-kernel-security causes kernel panic on EC2 AMD64 image" [High,New] https://launchpad.net/bugs/725089
<bjf> ogasawara, hi :-)
<jjohansen> ogasawara: hey
<jjohansen> bjf: I started looking at that yesterday
<bjf> jjohansen, ah
<jjohansen> bjf: there is also a lucid issue that is different, hrmm not sure what its bug number is
<bjf> jjohansen, it's still unassigned and no additional comments so wasn't sure
<jjohansen> bjf: ah, yeah I actually got the info before the bug was opened
<jjohansen> I'll assign it to my self
 * ogasawara waves
<bjf> ogasawara, o/
<bjf> jjohansen, the lucid issue is with lucid-ec2 ?
<ogasawara> wtf, the kid starts crying right when I start typing
<sconklin> ogasawara: o/
<vanhoof> ogasawara: hi :D
<sconklin> hahaha
<vanhoof> ogasawara: its a sign 
<jjohansen> bjf: yep, its a failure in the qrt mem mapping checks
<bjf> ogasawara, are you traveling to uds ?
<ogasawara> bjf: I think so, wayne and I were discussing it yesterday
<jjohansen> bjf: hrmm just a sec, or was that on hardy
<bjf> ogasawara, wayne was saying "no NO! pleeeeese don't go"
<ogasawara> bjf: heh, a little :)
<ogasawara> bjf: we figured kai will be about 5mo at the time and a little more settled and better able to survive a week without me
<jjohansen> ogasawara: you could always bring him :)
<ogasawara> jjohansen: you guys would probably kill me on the flight over
<bjf> ogasawara, ah you new parents and your little fantasies 
<jjohansen> ogasawara: hehe not me, and think of the excellent excuse you would have to miss the config review
<ogasawara> jjohansen: heh having a kid was all part of my giant scheme just to get out of the config review :)
<ogasawara> bjf: I think I'm more worried about wayne surviving the week
<jjohansen> bjf: so the memory thing is lucid not the hardy issue
<jjohansen> ogasawara: hah, I knew it
<bjf> ogasawara, hehe i can imagine
<jjohansen> ogasawara: and well worth it :)
 * ogasawara will drop back in later ..
<kees> smb: so "upload" number should be used instead "revision"? should https://wiki.ubuntu.com/Kernel/Dev/KernelPackageVersioning be updated?
<bjf> jjohansen, just to be perfectly clear, there is a lucid issue that you know about ?
<jjohansen> bjf: yes, though I am not sure whether it is a regression
<bjf> jjohansen, do you have a bug # ?
<jjohansen> let me check if hggdh opened a bug for it
<jjohansen> bjf: I don't see one, I'll coordinate with hggdh and make sure there is one, and get the information attached and then let you know what it is
<bjf> jjohansen, thanks
<hggdh> I did open a bug, jjohansen 
<hggdh> jjohansen: bug 725089
<ubot2> Launchpad bug 725089 in linux "QRT test-kernel-security causes kernel panic on EC2 AMD64 image" [High,New] https://launchpad.net/bugs/725089
<jjohansen> hggdh: I figured you probably did but my lp foo is weak
<jjohansen> bjf: ^
<jjohansen> hggdh: thanks
<jjohansen> err wait
<hggdh> oops
<jjohansen> hggdh: not that one
<jjohansen> hggdh: the failed qrt memory test on lucid
<hggdh> jjohansen: yeah, sorry. No, no bug yet, I will open one
<lamont> is umask visible under proc/$pid??
<sforshee> lamont, not that I can find
<lamont> yeah - I resorted to gdb
<hggdh> jjohansen: you are talking about http://reports.qa.ubuntu.com/reports/kernel-sru/home/ubuntu/sru-kernel-test/lucid-2.6.32-313.25-ec2/m1.small-i386/qrt-kernel-security.txt
<hggdh> right?
<jjohansen> hggdh: yep, thanks
<jjohansen> bjf ^
<hggdh> jjohansen: so you want a bug on that?
<jjohansen> hggdh: yeah, that is doesn't pass the mem test is disturbing and I'll look into it
<hggdh> jjohansen: opening one now. It will be manually opened (no apport collection)
<jjohansen> hggdh: thats okay, and thanks
<cnd> kamal, thanks for the endorsement :)
<kamal> cnd: my pleasure :)
<JFo> k, I'm starving. See you guys Monday :)
#ubuntu-kernel 2011-02-26
<jj-afk> back on later
<Ntemis> hi
<Ntemis> am facing a usb problem and i cant find a solution
<Ntemis> my usb that has the server os on it gets disconnected randomly
<Ntemis> i can post a log if anyone here can share a thought or 2
<Krunch> pastbin
<Ntemis> okey thanks
<Ntemis> http://pastebin.de/15546
<Ntemis> Feb 23 06:44:35 UBUNTUNAS kernel: [  512.191039] NFSD: starting 90-second grace period
<Ntemis> Feb 23 06:44:51 UBUNTUNAS kernel: [  528.790084] usb 4-1: USB disconnect, address 2
<Ntemis> Feb 23 15:10:02 UBUNTUNAS kernel: [  131.011075] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
<Ntemis> Feb 23 15:10:02 UBUNTUNAS kernel: [  131.012212] NFSD: starting 90-second grace period
<Ntemis> Feb 23 15:10:33 UBUNTUNAS kernel: [  162.375496] usb 4-1: input irq status -75  received
<Ntemis> Feb 23 15:10:34 UBUNTUNAS kernel: [  162.540077] usb 4-1: USB disconnect, address 2
<Ntemis> Feb 20 16:25:46 UBUNTUNAS kernel: [  946.790077] usb 4-1: USB disconnect, address 2
<Ntemis> any ideas?
<Krunch> looking
<Ntemis> thanks
<Ntemis> if you need any other log please tell me
<Krunch> this is your keyboard being disconnected
<Krunch> the -75 error looks like the keyboard sending invalid usb message (EOVERFLOW)
 * Krunch double check 2.6.37
<Ntemis> keyboard was disconnected by me after i press enter
<Krunch> ok, so what is the actual problem?
<Ntemis> grub menu was not auto load the kernel so i had to connect keyboard so os would load
<Krunch> well, the logs show the keyboard disconnecting after linux has booted
<Ntemis> i loose connection with the server randomly
<Krunch> do you have console access?
<Ntemis> nope
<Ntemis> nothing
<Ntemis> no console no webgui access
<Krunch> i mean do you normally have console access?
<Ntemis> yes of course :)
<Krunch> i mean like serial, ilo, drac,... (not ssh)
<Ntemis> serial is disabled in bios
<Ntemis> only ssh
<Krunch> do you have root on another box on the same LAN?
<Ntemis> didnt understand this
<Ntemis> what do you mean
<Krunch> your box is crahing or hanging, local logs are probably not reliable, there are ways around that to collect relevant, reliable data but it usually requires either console access or administrative access to a system on the same network
<Ntemis> i have an openwrt router with 4 gbit lan and the server is connected to one of them
<Ntemis> i have 3 pcs that can do that
<Krunch> that said, there are still some interesting things in these logs (the hung task backtraces)
<Krunch> i see 13 reboots between the 20th at 07:54 and the 26th at 10:41, can you tell which ones if any were normal scheduled reboots and which ones were result of the problem?
<Ntemis> is there anything i can do from ssh to collect more info for you?
<Ntemis> no reboots at all
<Ntemis> i force shutdown
<Krunch> ok
<Ntemis> with hardware button
<Ntemis> hmmm
<Krunch> i don't think there is much more we can get when the system is running fine
<Ntemis> ok let me clear this out
<Ntemis> i have installed kernels from the mainline to test the hanging
<Ntemis> the only kernel that holded was the 2.6.37.1
<Ntemis> 2.6.37 was the most hangfull
<Ntemis> 2.6.37.2 is so so
<Krunch> you never saw the problem with 2.6.37.1 ?
<Ntemis> nope
<Ntemis> rock solid but only for 3-4 days
<Ntemis> after those i installed 2.6.37.2 and removed 2.6.37.1
<Ntemis> i have a small space and i need the mb
<Ntemis> os is only on a 4gb usb flash drive
<Krunch> ok, i would suggest to do the following
<Krunch> setup kdump
<Krunch> enable hung_task_panic
<Krunch> enable nmi watchdog
<Krunch> next time the problem happens, it is likely to cause a proper kernel panic and generate a vmcore (wherever you told kdump to put it)
<Krunch> the vmcore will contain more informations about the cause of the crash
<Krunch> right now there is not enough to determine what's going on
<Ntemis> ok thanks
<Krunch> although this is probably related: http://paste.debian.net/108901/
<Ntemis> brb
<Krunch> but that doesn't really tell us what is hanging
<Ntemis> wife :)\
<Krunch> (well, it's likely to be a storage problem but that can still be many things)
<Ntemis> you still here?
<Krunch> yes
<Ntemis> klutch do you thing if i disable ipv6 will improve anything
<Ntemis> Krunch: do you thing if i disable ipv6 will improve anything
<Krunch> i don't see how this would change anything
<Krunch> changing filesystem might help
<PhoenixSTF> Hello guys, how do I make m HDD slow its transmition speed?
<PhoenixSTF> apw, yout here m8?
<Ntemis> hi
<Ntemis> my kernel log reports i  must run the e2fsck
<Ntemis> how i do that?
<Ntemis> it read the hdd's must me unmounted
<Ntemis> is there a command to check the hdds after a reboot?
<charlie-tca> Ntemis: either boot using recovery menu or a live cd
<Ntemis>          VVVVBFGVG G GGHGGHHHJK;
<charlie-tca> Ntemis: was that a stroke or a mistake?
<hallyn> the 2.6.38 kernels seem to make my vaio laptop fan always race, whereas 2.6.37-12 is nice and quiet...
<Krunch> do you have the kernel logs at boot for each version?
<hallyn> hm, i think so
<hallyn> anything in particular i'd look for?
<hallyn> acpi msgs look the same
<hallyn> maybe i just need to tweak /sys/bus/acpi/drivers myself?
<Krunch> that's the first thing i would have looked at but someone who actually knows something about acpi might find something by looking at other non obvious difference
<hallyn> thx.  i'll take another closer look later, and file a bug if it persists
<jj-afk> hallyn: what is the load like
<jj-afk> yes, I am think acpi drivers too but I was curious if there are apparent load changes as well
#ubuntu-kernel 2011-02-27
<hallyn> jj-afk: hey - i was watching with top (this was last thu or so - the thing serves wireless for my house so I dont' reboto often) and load seemed just fine.  
<psusi> bug #593086 is a potential data loss when using lvm snapshots on karmic and lucid ( other releases not affected ).  It has been some time since I located the cause of the problem but the bug has languished since.  I nominated it to be tracked in karmic and lucid but it was never accepted.  could someone accept it please?
<ubot2> Launchpad bug 593086 in linux "Silent wraparound on > 2 TB LVM snapshots in lucid and karmic" [High,Triaged] https://launchpad.net/bugs/593086
#ubuntu-kernel 2012-02-20
 * apw yanws
 * smb scanning email... 120+ uploads to precise. It cannot be a feature, so it must be a bug
<ppisati> :)
<apw> henrix, hey welcome
<henrix> apw, hi! and thanks :)
<henrix> sorry for the delay. i have connected to irc and when straight for coffee
<apw> henrix, no worries, it was luck i saw you at all as i have login messages suppressed anyhow
<apw> henrix, oh and its still early in our timezone
<henrix> apw, yes, still early
<apw> and /me hasn't had an tea yet
<henrix> apw, i can't get started w/o my coffee. or tea
<apw> henrix, me either mostly, i can just about cope with irc before
<smb> henrix, Oh yeah, welcome 2
<henrix> smb, thanks!
<henrix> smb, also uk?
<smb> henrix, No, de :)
<henrix> smb, ah! close enough :)
<smb> henrix, yeah, just an hour, which sometimes can be confusing enough
<apw> yeah and he is about an hour lazier than me, so we align pretty well
<henrix> heh. i guess most of the people will be in a US timezone, or am i wrong?
<smb> henrix, and probably a word of "warning" that some of apw's hours are in +1, as well :)
<apw> we have a pretty good spread now not quite half are .eu now, as we have ppisati as well and colin
<henrix> great
<henrix> so, i was just checking if i already had access to the wiki but it looks like i don't
<apw> henrix, did you get your welcome email from pete with all the pointers on it
<smb> henrix, the wiki needs a special group assigned in lp
<henrix> apw, no, not yet. unless he used the canonical email, which i still don't know how to access
 * apw suspects we need pete or tim for that, and i don't they have done that yet
<smb> (at least the canonical one, the ubuntu one should be at least readable)
<henrix> smb, just checked my lp and no new group assigned
<apw> henrix, expect today to be a bust ... wht wheels grind slow
 * apw will ask IS if they are processing you
<smb> right, think one of tim or pete need to add the canonical one
<henrix> well, i received the initial email from IS and i have replied w/ all info requested. but haven't got any reply from them
<henrix> so, i guess i just need to wait
<apw> henrix, ahh good, yeah IS won't be around till 9, so you get to talk to us till then
 * ppisati loves sshfs
<apw> ppisati, its pretty cool indeed
<apw> henrix, so, as we'll be in the office tommorrow, you might take advantage there of the b/w to get the big repos you'll need
<henrix> apw, yep, i guess that's a good idea
<smb> best thing to do was to get linus tree and have a --reference to that for all of our trees when pulling
<henrix> yes, keep the disk usage lower. and it's faster
<smb> A lot for the initial clone
 * smb remembers not knowing that when starting and waiting looooong dark coffetimes of it
<apw> yeah so if you have nothing else to do, then i'd make sure you have an up to date linux-linus
<apw> i recommend a bare clone, so you don't accidentally use it ever
<apw> and use that as reference for all our trees, as they are all pretty close to linus
<henrix> ok, i do have the linus tree. i used that method to follow some -tip branches some time ago
<Elboras> hi
<apw> Elboras, hi
<apw> henrix, thats good, one less thing to wait for to download
<apw> henrix, you might want to clone down say the precise tree and look at that
<henrix> apw, right. i will
<apw> henrix, i'll let you try and find the information in the wiki :)
<henrix> apw, ;)
<apw> henrix, one of your tasks is to update any wiki information you find is unhelpful or incomplete
<apw> henrix, feel free to ask anything you need to, and we just ask you add anything you think is missing to the wiki so the next person finds it easier
<apw> henrix, if you are unsure you can ask for review of the changes or whatever works
<apw> but we no longer can see any issues with the wiki, it appears purfect, but its clearly not
<henrix> apw, ok, cool. i'll keep it in mind while going through all the info there
<ppisati> and that reminds me i should document all the cross-stuff
<henrix> when i find something that does not sound ok, i'll flag it and eventually update
<apw> henrix, yep you are a virgin eye on the data, something which you only are this once, so we need you to be critical of what you read, and where you have to ask ... that tells you and us there is something missing and it needs adding
<apw> henrix, don't put it off, just change it ;)
<henrix> apw, got it!
<ppisati> bug 922799
<ubot2`> Launchpad bug 922799 in linux "Oneiric update to 3.0.18 stable release" [Undecided,New] https://launchpad.net/bugs/922799
 * ppisati -> lunch
<tgardner> apw, you're not hearing me on mumble ? I can hear you guys.
<apw> tgardner, yeah try switching from pulse to alsa and back again, apply both ways, in mumble
<apw> tgardner, as we are not seeing red lips at all
<apw> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/936308
<ubot2`> Launchpad bug 936308 in linux "BUG: unable to handle kernel NULL pointer dereference at 00000004 (sd_revalidate_disk+0x21/0x290)" [Undecided,Incomplete]
<apw> smb, yan sd_validate_disk jobbie ^^
<smb> apw, bah, removing usb has become kind of a game of luck...
<apw> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/936652
<ubot2`> Launchpad bug 936652 in linux "BUG: unable to handle kernel NULL pointer dereference at 00000004 (locks_free_lock+0x9/0x50)" [Undecided,Confirmed]
<apw> bah
 * tgardner reboots tangerine
<popey> hullo kernel people!
<popey> I have an x220 which seems to have a fit every now and then and whilst it has an IP, no traffic will pass over the network interface
<popey> wondered what diagnostics I could get from it before I reconnect to the network and file a bug?
<popey> I have dmesg, ifconfig, a ping, lsmod... anything else?
<apw> info on what type of AP it is talking to
<apw> what encryption mode, periodicity of failure
<popey> apw: ta
 * apw calls it a day before it gets any worse ...
<tkamppeter> tgardner, hi
<tgardner> tkamppeter, hi
<tkamppeter> tgardner, I have a USB problem, I have recently updated my Oneiric box to the newest 3.0.0-16 kernel and now, after connecting a USB printer it takes several minutes until UDEV kicks in setting the group ownership to "lp" and running /lib/udev/udev-configure-printer.
<tkamppeter> tgardner, this can also have led to some people still complaining in bug 872711 or telling that the bug reappeared with kernel 3.0.0-16.
<ubot2`> Launchpad bug 872711 in linux "Kernel does not report some USB printers correctly, making them not being detected by CUPS" [High,Fix released] https://launchpad.net/bugs/872711
<tgardner> tkamppeter, possibly. do any of these devices require firmware to be loaded ?
<tkamppeter> tgardner, no. The only printer needing firmware is not connected currently.
<tgardner> tkamppeter, and it works reliably with 3.0.0-15 ? if so, then we ought to be able to bisect down to the offending patch.
<tkamppeter> tgardner, probably but not absolutely sure.
<tgardner> tkamppeter, it would help to be sure that it really is a kernel regression.
<tkamppeter> tgardner, should I paste the syslog for you?
<tgardner> tkamppeter, pastebin it
<tkamppeter> tgardner, this is what I mean with pasting ...
<tkamppeter> tgardner, http://paste.ubuntu.com/850262/
<tgardner> tkamppeter, the kernel doesn't seem real happy, 'usb 7-1: device descriptor read/64, error -110'. can you check if 3.0.0-15 has those errors?
<tkamppeter> tgardner, OK, will try to boot the old one ...
<tkamppeter> tgardner, booted 3.0.0-15 now and the printer is recognized and processed by UDEV within a second or two.
<tgardner> tkamppeter, good. please catch jsalisbury or bjf tomorrow when they return to work. the'll build bisect kernels for you so we can narrow down the offending patch.
<tkamppeter> tgardner, but error seems still to be there: http://pastebin.ubuntu.com/850279/
<tgardner> tkamppeter, seems like it might be a red herring
<tkamppeter> tgardner, false positive.
<tkamppeter> tgardner, now I tried to connect more than one printer and connected a hub with one of these firmware-hungry printers and now it is all like before with 3.0.0-16.
<tkamppeter> tgardner, seems that the firmware-hungry printer contaminates the USB stack somehow.
<tgardner> tkamppeter, did you have a udev update recently ?
<tkamppeter> tgardner, I do not know. The system is up-to-date, as I updated yesterday. Which version should I have?
<tkamppeter> tgardner, my UDEV is 173-0ubuntu4.1.
<tgardner> tkamppeter, I don't know what version it should be. I just know that udev can have an impact on firmware loading.
<tgardner> just looking at what might have changed recently
<tkamppeter> tgardner, when I connect several printers at once, some already connected get immediately UDEV-processed. Also some of the newly connected ones. But there can still remain unprocessed printers which get only processed after some minutes.
<tgardner> tkamppeter, can you correlate that delay from timing information in /var/log/udev ?
<tkamppeter> tgardner, will try.
<tkamppeter> tgardner, in the moment of plugging ther printer does not appear in /var/log/udev
<tkamppeter> tgardner, it seems that my udev stoipped logging with the last boot, last entry is from around the time when I booted into 3.0.0-15.
#ubuntu-kernel 2012-02-21
<smoser> hey all.
<smoser> looking at bug 937352
<ubot2`> Launchpad bug 937352 in cloud-initramfs-tools "root partition in may not be grown" [Undecided,New] https://launchpad.net/bugs/937352
<smoser> it *appears* to me that after a umount, a subsequent sfdisk (with call to BLKRRPART) returns device or resource busy.
<smoser> i'm wondering if there is some thing that is actually necessary to do to wait until the kernel would not any longer consider that resource busy.
<reisei> hi! How can I mesure the temperature of the core?
<jk-> of the earth? that's a bit tricky.
<jk-> reisei: intel CPU?
<reisei> jk-: omap cpu
<jk-> reisei: eep, that's a little more tricky; is there anything in /sys/class/thermal ?
<reisei> jk-: I'll check 
<reisei> jk-: there is nothing there
<smb> morning
<reisei> jk-: What will you suggest?
<RAOF> Is there actually a thermal sensor on that thing? :)
<reisei> RAOF: yep
<smb> RAOF, that at least is step 1 :)
<reisei> RAOF: may be you tell me how can I check the temperature?
<ohsix> if it's that hard to figure out it might be more prudent to check the datasheet and see if it even has one you can read
 * smb struggles very hard and fails... how about putting ones finger on the heat sink...?
<reisei> smb: thermak framework is better, I guess
<smb> reisei, Here goes the irone. But ok, yes, though that requires either a sensor on the board or the chip, the specs how to read it and someone who writes a driver for it. 
<smb> And I don't know any, ohsix, I guess you do not either?
<reisei> smb: if there are all this parts, if I got temperature in dmesg, but in some strange format, what should I do to fix it?
<ohsix> smb: i'd have to hit up the datasheets too, there's probably a diode somewhere that gets the temperature; but that doesn't always mean you can read it
<smb> reisei, I'd probably try to find the function in the kernel source that prints that message, and then try to find out whether that has enough info (which I usually doubt). If you have a datasheet you may find where it looks and maybe what things mean. If not maybe finding who usually commits to that file and try to get into contact with them
<smb> ohsix, Totally agree. Was just wondering whether someone may have done something there. Though it did not sound like there is a driver.
<reisei> smb: I found hwmon data. But what's the value it get? Something like 51600.
<smb> reisei, Have you checked Documentation/hwmon/sysfs-interface in the kernel tree... Seems millidegree C  is what it is. So 51.6Â°C ? If that is a reasonable value.
<smb> would be for x86 but no clue about arm
<reisei> smb: ok, but that seems to be wrong value. in the start of the system it show ~38Â°, but it should room temperature.
<smb> reisei, It could be wrong but may also be somewhere inside the chip that gets warm pretty quick. This is where you have to look into the datasheet and the driver. Since you read it from somewhere you should know which driver
<ryao> Is grub being compiled with GCC 4.6.2 in Ubuntu 12.04?
<ryao> lamont: I hope you don't mind me pinging you, but the official Ubuntu wiki shows you as the contact person for the #ubuntu-kernel channel. I am not sure if that is for things that the Ubuntu kernel team is responsible for maintaining or just this channel.
<cking> ryao, I suspect you probably need to ask that question in ubuntu-devel
<ryao> cking: I did, but then I noticed on the website that the Ubuntu kernel team is repsonsiblef or it.
<smb> Seems the ubuntu kernel team is stated as maintainer in the package... Not that we really do much to it
<ryao> smb: Who is responsible for compiling it?
<smb> ryao, well from the changelog the uploads have been done either by mvo or cjwatson. Maybe try to get mvo's attention. I'd say though, whatever the default compiler for precise is is used for compiling grub in precise.
<ryao> smb: Thanks. I will try to verify that with one of them.
<smb> ryao, cjwatson is not around for a while
<ryao> smb: cjwatson is in #ubuntu-devel while mvo is not. :/
<smb> ryao, Not sure whether he is really there or just his proxy. I think I saw some mail from him announcing to be on leave. Not sure it is already now or later
<ryao> Okay, thanks.
<smb> Though I see somebody else stepped up
<ryao> Thanks for your help. :)
<ericm|ubuntu> ppisati, ping
<ppisati> ericm|ubuntu: pong
<cnd> apw, tim cherry-picked a patch directly last week after a very brief conversation here on irc
<cnd> actually, before I go further, I realized the patch hasn't made it to linus yet
<cnd> nm for now
<cnd> and if you read the above as one normally would, it would seem very odd, but it's best to just assume I never said anything :)
<lamont> ryao: you want the team, not me, for that question
<ryao> lamont: Thanks.
<lamont> ryao: likewise, the buildlog for grub should tell  you what it's using for the build
<ryao> Thanks. ajmitch in #ubuntu-devel pointed that out. :)
<lamont> or more to the point, what it used for the build
<lamont> heh
 * ppisati -> back in a bit
<smoser> smb, around ?
<apw> smb, hey your maint-update-patch, if i ask it to sign off something, and there are no signoffs already, will it work correctly its looking like it does not
<smb> smoser, now and no I don't know what keeps the partition or drive busy
<smb> apw, PRobably not as that was rather not the case for anything coming down. Actually I would have asked people to at least have their sob when they want something included. :)
<smb> apw, You are not doing it the way it should be done... oops... wrong channel... :-P
<apw> :-p
 * ppisati -> lunch
<smb> smoser, Just a guess, but changing the partition sizes should likely generate change events for the drive/partitions, which then triggers things run by udev, and those again may open the disk/partitions. So maybe it helps to shed light into the issue when you log udev events/debugging in parallel
<smoser> smb, hm.. 
<smoser> i dont think that makes sense.
<smoser> the core issue is:
<smoser>  umount
<smoser>  sfdisk (with blkpart)
<smoser>  mount
<smoser> but it is the sfdisk that is failing
<smoser> oh...
<smoser> if what you're saying is true, then there is a race any time sfdisk is run
<smoser> udev really shouldn't be involved until *after* sfdisk has called BLKRRPART
<smoser> i have to run. will poke some more later, but please think some.
<smb> Actually I mentally ignored the --dry-run part in the sfdisk on the bug report. But thinking of it, it would be interesting to see how things are committed. I guess the events only should happen when doing a rereadpt ioctl
<smb> smoser, But I'll think a bit more
<apw> smb, yeah presumably as sfdisk exits
<smb> apw, Would be expected. Right now trying to re-create it locallly... and wondering whether this is just a different mode of getting it to fail. since there does not seem to be a settle wait between the growing and resetting the partition (in the test script)
<smb> anyway
<smoser> smb, yeah, the script i do see lots of failures on the re-start/reset of the script
<smoser> but i also see failures after umount
<smb> smoser, still waiting to see it happen on my local xen guest... maybe too slow... Just a 2GHz 8-core... :-P
<smoser> smb, 
<smoser> sudo sh -c 'd=/dev/vdb; p=${d}1; mp=/mnt; trap "umount $mp" EXIT; while : ; do mount $p $mp && umount $mp && sfdisk --re-read $d|| exit 1; echo -n .; done'
<smoser> simplify it and try it like that.
<smoser> i just saw that fail here.
<smoser> in a canonistack instance.
<smoser> i can give you access if you need.
<smoser> smb, ubuntu@10.55.60.111 if you want. i've imported your launchpad keys.
<smb> smoser, hm, that may change some assumptions. Ok, then I can check also a few other general setup questions
<smoser> smb, change some assumptions?
<smoser> i'm assuming that sfdisk --re-read is just sending the BLKRRPART call without doing anything
<smoser> and in this case when it fails, its getting a resource busy
<smb> smoser, Well assuming it is Xen or KVM based. Should not really make that difference but could yield different timings
<smoser> right.
<smoser> timings
<smoser> note, i'd never seen this before they upgraded canonistack to precise
<smoser> which brought a new kvm
<smoser> now we're seeing it quite often (maybe 1/2 boots)
<smoser> so yeah, there is obviously race involved.
<smoser> smb, 
<smoser> sudo sh -c 'd=/dev/vdb; p=${d}1; mp=/mnt; cleanup() { umount $mp >/dev/null 2>&1; } ; trap cleanup EXIT; umount $p >/dev/null 2>&1; while : ; do mount $p $mp && umount $mp && sfdisk --re-read $d|| exit 1; echo -n .; done'
<smoser> thats maybe a bit prettier, just cleans up after itself better.
<smoser> but i can run that and it will go for quite a while, and the ctrl-c it, and have it fail after 3 tries.
<smb> smoser, Could still be both. New kvm or slightly different behaviour in the kernel in general or userspace... Except if it now appears on all kinds of guests too
<smoser> right.
<smb> smb, I'll try the smaller version 
<smoser> smb, i got to run again. sorry to bother you and then run off, but i'm supposed to be on vacation. :)
<smb> smoser, Heh ok. no worries
<smoser> smb, thanks. later. and you can update that bug with anything you find or post back here.
<smb> smoser, will do in the bug
<apw> smb, whats that command which is grep foo /etc/passwd with ldap ?
<smb> apw, gentent?
<apw> that sounds likely
<smb> apw, I mean getent
<smb> apw, should be getent passwd <id>
 * ogasawara back in 20
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<jsalisbury> apw, Can any kernel config option be changed at boot time, or just a certain set of them?  For example, I'd like to boot a kernel with CONFIG_USB_XHCI_HCD disabled to save time by not having to build a test kernel.
<apw> jsalisbury, nope, they have to be specifically exposed either in sysfs or syscontrol
<apw> many require different code generated, so can only have effect at build time
<jsalisbury> apw, ahh, ok.  thanks!
<apw> jsalisbury, i've not got a headset here today, doh so won't be about for the 4:30
<apw> (now+29)
<jsalisbury> apw, ok.  Tim's out today as well, so it will probably be a quick one this week.
<apw> i know lets simply assign smb to them all :)
 * smb tries to mentally slap apw
<jsalisbury> :-D
<apw> jsalisbury, and call for the white coats as smb is going mental too :)
<jsalisbury> apw, heh
<smb> apw, what do you mean? going?
 * smb assumed he was there already
<apw> smb, thats not a prizon its your flat
<smb> apw, now I am completely lost :) I mean I thought I was already mental ;)
<smoser> smb, why would sync do anything other than change timing?
<smoser> oops. sorry to interupt meeting.
<brendand> bjf - did i just see a new Oneiric -proposed kernel pop up? the current one isn't finished verification yet
<smb> smoser, not ours but not being on yours :)
<bjf> brendand: i created the wrong tracking bug
<bjf> brendand: it's already marked invalid
<smb> ogasawara, Do we know about items assigned to the canonical-kernel-team here https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-ceph
 * ogasawara looks
<jsalisbury> ogasawara, possibly related to the rc6 patch: bug 937378
<ubot2`> Launchpad bug 937378 in linux "Patched kernel with rc6 enabled shutdowns" [High,Confirmed] https://launchpad.net/bugs/937378
<ogasawara> smb: I'm unaware of anyone actively looking into that
<ogasawara> smb: I'm not even sure what patch is being referenced there
<ogasawara> jsalisbury: ack thanks
<jsalisbury> ogasawara, could be one more too: bug 935965
<ubot2`> Launchpad bug 935965 in linux "RC6 enabled causes severe graphics corruption" [High,Confirmed] https://launchpad.net/bugs/935965
<smb> ogasawara, Right, probably as aware as I was before being asked in the server team meeting :)
<ogasawara> jsalisbury: yep thanks, was aware of that one already
<jsalisbury> ogasawara, ok thanks.  I'll add them to the hot list for tracking
<ogasawara> jsalisbury: I'm keeping an eye on https://wiki.ubuntu.com/Kernel/PowerManagementRC6 which is where most of the RC6 related bugs should be getting noted
<ogasawara> smb: yep, completely unaware
<smb> :) yep
<jsalisbury> ogasawara, I'll keep an eye on that as well.  Thanks
<ogasawara> smb: do you need me to follow up with anyone to get that postponed?
<ogasawara> smb: as I'm guessing it's not actually going to get done
<smb> ogasawara, We need to talk at least to them to let them know that assinging things to canonical-kernel-team without talking to us is as good as giving the task to john doe
<ogasawara> smb: indeed
<ogasawara> smb: I'm crafting an email, I'll CC you on it.
<smb> ogasawara, ACK, though I am pointing it out on irc as well right now. 
<smb> Daviey, and <SpamapS>. 
<Daviey> I don't know, without looking at my mail archive, who assigned it.
<ogasawara> smb: [08:44:00] <SpamapS> Daviey: I don't think there's anything for the kernel team to do for CEPH .. its more about QA and testing.
<smb> ogasawara, Right, the patches there seem to be optimizations
<smb> Which we probably want to put on q's list of todos to look at and get assigned to something we know of
<ogasawara> smb: so I'm guessing that means the work items could be postponed and are not blocking any others.  but I'll email clint and make sure.
<ogasawara> Daviey: ^^ I can CC you on that as well if you like?
<smb> ogasawara, Yes, thats is how I undestood clints comments on -server
<manjo> For launchpad bug table view install  https://chinstrap.canonical.com/~jamesf/lptables/lptables.crx
<manjo> oops
<manjo> bad mouse
<smb> apw, If you are not yet afflicted by the fridge contents: seems the umount not completely off the blkdev seems to be there at least back to natty... have not made it farther back yet
<apw> manjo, quality
<manjo> :)
<apw> smb, hmm, interesting, yet sd_revlaidate is newish ... odd
<smb> apw, Well can be completely unrelated oddness
<apw> yeah must be unrelated i guess
<jsalisbury> Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues Feb 28th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<smb> jsalisbury, not sure that worked as expected
<ppisati> EOD
<jsalisbury> smb, the topic change?
<jsalisbury> smb, ahh, right
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues Feb 28th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<jsalisbury> smb, thanks ;)
<prashs> Hello. My ubuntu is unable to find the bluetooth device connected to it. In kernel 2.6.32 i was able to do that. But once i upgraded to 3.0 i am right now unable to do it. Ubuntu is not recognizing my Bluetooth dongle connected :( What to do??
<jsalisbury> ogasawara, regression between 3.2.0-16 and 3.2.0-17: bug 938195
<ubot2`> Launchpad bug 938195 in linux "kernel 3.2.0-17-generic crashes constantly" [High,Confirmed] https://launchpad.net/bugs/938195
<ogasawara> jsalisbury: thanks
<jsalisbury> ogasawara, np.  I requested that the bug report test 3.3-rc4 just to see if the bug is fixed there.
<jsalisbury> ogasawara, I wasn't sure if it was rc6 related or not.
<ogasawara> jsalisbury: it might be, and it's a quicker test for them to try and disable it to see.
<jsalisbury> ogasawara, ahh, right.  I can request that test.  
<ogasawara> jsalisbury: cool, thanks.
<jsalisbury> ogasawara, I'll request that bug reports disable RC6 for any new bugs that come in that appear to be RC6 related.
<ogasawara> jsalisbury: great, that'd be good.  thanks.
<jsalisbury> ogasawara, Should these bugs only affect Sandy Bridge systems, or any system using the i915 driver and running the  3.2.0-17.26 kernel? 
<ogasawara> jsalisbury: should only affect sandy bridge
<jsalisbury> ogasawara, what's the best way to confirm a system is a Sandy Bridge?  With lspci -nn | grep "VGA"
<jsalisbury> ogasawara, then look for "Intel Corporation 2nd Generation Core Processor"
<ogasawara> jsalisbury: shoot, I thought we had a message thrown to dmesg that it was being enabled, but I'm wrong.
<jsalisbury> ogasawara, I see the following in the boot dmesg: agpgart-intel 0000:00:00.0: Intel Sandybridge Chipset
<jsalisbury> ogasawara, that should at least help me identify if a system is sandy bridge or not.
<ogasawara> jsalisbury: lspci VGA info would also likely include vendor:device id's of one of the following 8086:0102, 8086:0112, 8086:0122, 8086:0106, 8086:0116, 8086:0126, 8086:010A
<jsalisbury> ogasawara, cool, thanks.  
<jwi> jsalisbury: /proc/cpuinfo - client SNB is family 6, model 42.
<ohsix> sforshee: heh re: touchpad, after setting both keys to "toggle", i noticed if i press it fast enough the key events are not sent, but the light does change
<ohsix> since they originally were on/off events, it'd get out of sync either way
<sforshee> ohsix, both keys? there's more than one?
<ohsix> there's one key, but 2 events, one for enabled -> disabled (the light changes from white to orange) and vice versa
<sforshee> oh, so two scan codes
<ohsix> they didn't work as separate events since g-s-d doesn't trap XF86TouchpadOff (and on) or whatever, but only toggle
<sforshee> huh, that's not ideal
<ohsix> yea i didn't check and see if it did in the past, but i suspect that's why it stopped working
<sforshee> you really want the on/off since that's really what your machine is reporting
<ohsix> right, but the light can still get out of sync if it's pressed fast enough; so it sucks either way
<ohsix> if it didn't have a light whether it was toggle or separate on/off would be moot, and since the light can change without sending an event it's moot anyways
<ohsix> at least on my laptop
<ohsix> there are a lot of keymaps for other models that look out of date too
<sforshee> odd that it toggles the light without sending the event
<sforshee> what kind of machine was it again? HP?
<ohsix> yea, HP Compaq Presario CQ60-420US
<ohsix> (though it's had a mobo swap, dunno if it's exactly a 420us anymore :)
<sforshee> ohsix, which keymap is getting used?
<ohsix> it didn't match any of the ones that come with udev on natty, i had to make my own; i mimic'd the other touchpadon/off keysyms in the other ones and it still didn't work, but toggle did; after i found out g-s-d traps toggle
<ohsix> i filed a bug, let me find it
<ohsix> https://bugs.launchpad.net/ubuntu/+source/udev/+bug/935804
<ubot2`> Launchpad bug 935804 in udev "hewlett-packard keymaps mostly wrong or obsolete" [Undecided,New]
<ohsix> i haven't really figured out what i can do to usefully get it fixed yet, but i did know that all those keymaps were wrong after my investigation so that's the bug i filed :]
<ohsix> the thread didn't have any references so i wasn't able to see what actually happened because of it, so i haven't added anything more yet
<sforshee> yeah, keymaps are the only way to really support those since it looks like they come from the AT keyboard
<sforshee> so pursuing it in udev seems like the right approach
<ohsix> well supposedly you're able to report it to one of the linux mailing lists and they make the kernel send those events directly instead of adjusting the keymap
<ohsix> so if i were to do as suggested in README.keymap, i wouldn't even need a keymap file in the end
<sforshee> it depends on where the key events come from. The udev rule seems to apply those keymaps for the AT keyboard, and for that one you won't get them added at the kernel level.
<ohsix> except for the time window between it landing in a kernel release i can use and before then
<ohsix> ah, really?
<ohsix> i wasn't aware of any special rules or whatever regarding that
<sforshee> yes, if they're coming from a platform driver you can get them added in the kernel
<sforshee> the AT keyboard driver is completely generic though, and so it can't have a bunch of model-specific key codes added to it
<ohsix> would, say if that's already occuring, the keys come from the AT keyboard in the end? there is a wmi driver in play but i don't know what it's doing
<ohsix> eg, platform driver traps whatever and delivers D8 to the at driver, is that what happens or would there be a separate event device?
<sforshee> I'm judging based on how the hp keymaps are applied by udev. If you want to know for sure, use lsinput to identify the actual input devices and then use input-events to see which one is reporting the keys.
<sforshee> platform drivers have separate event devices
<ohsix> ya i've done that before, it used to be on a separate device
<sforshee> what device? hp-wmi?
<sforshee> hp-wmi doesn't even seem to recognize those scancodes
<ohsix> hm wait, it still may be on a separate device, do you mean exclusively or in addition to coming from the AT keyboard? i'm still a bit fuzzy on how everything fits together
<sforshee> i don't understand the question
<ohsix> not important, i think i'm confusing this whole event/keypress thing with another problem i had with my brightness keys (g-s-d sees 3 brightness changes for one keypress, never found out how)
<ohsix> and now my touchpad disable key isn't even working and it decided to do that while it was off, brb
<ohsix> rdesktop blows
<ohsix> heh i disabled it for the input-test test, since i took the focus back to rdesktop and it does an exclusive grab when it's in the foreground i couldn't reenable it
<ohsix> ok so, udev keymaps aren't irrelevant, g-s-d not trapping on/off is, good to know
<ohsix> maybe you can help me sort the multiple brightness adjustment thing too, but that will have to wait; overdue for something
<sforshee> yeah, it's time for me to get off of here anyway
<ohsix> thanks again
 * sforshee -> EOD
#ubuntu-kernel 2012-02-22
<herp> good day. I'd like to obtain the .config file of a particular ubuntu kernel (11.10 that is). Unfortunately, it is not in /proc/config.gz - where can I find it?
<herp> *sigh*
<pbuckley> he didn't wait long did he
<herp> ok - found it .. it's in /boot/config* when you boot it from an usb-stick.
<herp> bye
<apw> henrix, do we smell ?
<cking> one of us must
 * apw sniffs
<apw> smb, moin
<smb> apw, hi there
<smb> apw, probably all of you. being on the tube before. :-P
<apw> oh yeah perhaps
<apw> smb, can you try typing in the HUD on your desktop, on my atoms it gets so far behind in its search updates as to be 6-7s behind on 'open tab'
<apw> so in like an xterm, open hud and just say 'open tab' ... how long on a performant machine does it take to get in sync
<smb> apw, You are assuming I got a machine running that has it... Oh well can boot it up. Should anyways to get the latest goodness... :-P
<henrix> apw: :)
<henrix> join you in a minute. just refilling coffe
<smb> apw, it seems on my machine the delay does not really get bad. maybe a tiny slag
<smb> apw, Though it seems a bit less useful that it seems to take away input focus...
<apw> smb, try it on an atom netbook...
<smb> apw, yeah, on battery at least there is about a 5 sec delay until the options in the drop down settle
<smb> seems that compiz is taking a lot of cpu while doing so
<smb> Maybe it is not the search itself but to display the results in that fashionable half transparent look
<smb> apw, can you type anything in the new tab without clicking it first?
<apw> smb, hmm never used it ... /me tries
<smb> hm, fantastic. instead of saying "ubuntu-video-lens crashed" it now says "sorry, ubuntu experienced an internal error"
<cking> sounds windowsy to me
<smb> Very much. /me waits until we offer a link saying "look here for more info" which then opens a web page saying "sorry, don't know anything about this one"
<smb> Ok, I have to admit that windows experience is limited to ancient XP :-P
 * ppisati -> lunch
<jwi> ogasawara: based on the text in 'ath9k: fix a WEP crypto related regression', I think 'Revert "ath9k_hw: fix interpretation of the rx KeyMiss flag"' can go away in precise/master-next.
<apw> cnd, yo what was that click-pad enable thing?  to make that stuff turn on
<jsalisbury> smb, cool, looks like there is a patch for bug 914319  I'll build a test kernel with the patch and have people test
<ubot2`> Launchpad bug 914319 in linux "NULL pointer dereference at sd_revalidate_disk+0x30/0x2a0" [High,Confirmed] https://launchpad.net/bugs/914319
<smb> jsalisbury, Interesting. I had wondered about another change later (3.1) which does trigger change event processing on close
<smb> But not being able to reproduce the issue first place
<ppq> Hi. Will there be linux-image-generic-lts-backport-<codename-for-future-releases> in Ubuntu 12.04?
 * ogasawara back in 20
 * apw wonders idly if our tooling will cope with 3 digit upload numbers
<apw> ppq, will there be lts backport kernels from later releases in precise ?  that is the plan currently as far as i know, likely it will be discussed and confirmed at uds-Q of course
<ppq> apw: okay, thanks
<spindritf> Hey, which ppa should I add to always have the latest vanilla kernel for (and from) Ubuntu? I'm experciencing some x freezes (gpu locks) and would like to try the mainline kernel. I could only find this directory http://kernel.ubuntu.com/~kernel-ppa/mainline/ which seems to require installing new releases by hand 
<spindritf> found it here https://wiki.ubuntu.com/Kernel/MainlineBuilds
<cking> bjf, xfstest is fun to config up and get working
<bjf> cking, where are you getting it from? autotest ?
<cking> from the original source 
<bjf> cking, steve and i are using the version in autotest
<cking> doh
<bjf> cking, if you are working on that, i'm going to leave it in your hands
<ppisati> "
<pgraner> ogasawara, is rc6 pm on by default yet?
 * pgraner thinks not
<ogasawara> pgraner: it is, as of 3.2.0-17.26
<pgraner> ogasawara, cool
<herton> manjo, can you verify and tag bug 925552?
<ubot2`> Launchpad bug 925552 in linux "[12.04] Broadcom Bluetooth device (Vendor=0a5c ProdID=21f3) not supported" [High,In progress] https://launchpad.net/bugs/925552
<manjo> herton, ok
<herton> thanks
<vanhoof> herton: i'll follow-up on the other one that needs verification
<herton> vanhoof, cool, I pinged jmleddy too about that one
<vanhoof> herton: cool
<Plizzo> Hi! I have a server running Ubuntu Server 11.10 x64 and I'm experiencing random system freezes, can anyone help me?
<tkamppeter> tgardner, hi
<manjo> herton, what was the bug number again please ? 
<herton> manjo, 925552
<manjo> herton, ok got it .. I shipped that machine back to lex so I need to get one of the folks there to verify it for me, vanhoof fyi
<tkamppeter> tgardner, did you see ny bug report, bug 937662
<ubot2`> Launchpad bug 937662 in udev "After plugging an HP LaserJet 1020 UDEV needs several minutes to set up newly connected USB printer" [High,New] https://launchpad.net/bugs/937662
<manjo> herton, dennis and chris in lex are working on verifying that bug. 
<herton> manjo, ok, thanks
<cnd> apw: http://people.canonical.com/~cndougla/enable-clickpad.sh
#ubuntu-kernel 2012-02-23
 * ppisati -> reboot
<apw> arges, you still got the electric blue notifications?  ppisati seems to have them too
<arges> apw, they disappeared after another upgrade yesterday
<arges> apw, now i see other things.... highlight text in a webpage then right click... unfortunately i can't take a screenshot of it 
<apw> arges, ok that odd
<apw> arges, try a delayed screen shot perhaps
<arges> apw, good idea
<arges> now i can't click again... 
<arges> time for another cup of coffee
<cking> smb, see the hud graphs in https://bugs.launchpad.net/ubuntu-power-consumption/+bug/938584/+attachment/2770166/+files/hud-cpu-maxed-out.ods
<ubot2`> Launchpad bug 938584 in indicator-appmenu "hud-service consumes all the cycles on my CPU" [High,New]
<arges> ouch
<apw> cking, i wonder how manu menu idems hud really has to search when you think about it
<apw> its got just the menus for the current application, and those in the indicators
<apw> lets be, really, really, generous and say there are 1000 entries to search
<apw> how long can it take to do a earch on those
<cking> apw, i suppose the source will be enlightening
<apw> or heavy
<smb> I would assume a lot is because it restarts the search for every new key you type
<apw> smb, in the test case i typed 7 characters, so it might have had to redo the search up to 7 times
<apw> to lets say thats a search of 7k lines
<smb> apw, And draw its current map thoughts
<cking> where does it get the data from? dbus?
 * smb would not be surprised to find it polls back whether the drawing operation has not been done yet ever millisecond
<apw> cking, i suspect it does yeah
<cking> so it should cache this, bet it doesnt
<apw> yeah
<apw> smb, my desktop just went pop
<smb> apw, awsome
<apw> cking_, you lost your graphics yesterday, no VT switches right ?
<cking> yep and today, had to reboot at 10:20 ish today because it locked up
<apw> cking, just happened to me, xorg sleeping on a futex
<smb> apw, Does that means hangs/locksup or just that tendency to randomly turn of the display for a few secs that I sometimes see 
<cking> more than just a few seconds
<apw> mine was dead totally, had to be kicked in the eye
<ogra_> well at least your fonts didnt turn into rainbows (like it is here) and i guess your notifications didnt turn green either
<cos^> if someone says he has applied a patch on LKML, which kernel branch does it go?
 * henrix will be back in ~20min
<apw> cos^, to that maintainers tree, which in theory you can figure out from the MAINTAINERS file
<apw> ogra_, heh, there is a lot of luminous blue OSDs being reported too
<ogra_> fun
<cos^> apw: ok.. it should be in jikos tree but it isn't. maybe he hasn't pushed the commit yet..
<ppisati> HP to Make ARM Servers Available for Testing in Q2
<ppisati> http://www.pcworld.com/article/249988/hp_to_make_arm_servers_available_for_testing_in_q2.html
<ppisati> FYI
<ogra_> assuming they exist until then :P
<ppisati> :)
<ppisati> well, they said they'll openm a lab for selected costumer
<ppisati> in case the silicon is not ready yet, they can fake it via qemu :)
<ogra_> haha
<henrix> whois bjf
<henrix> ugh
 * ogasawara back in 20
 * tgardner reboots tangerine
<ogasawara> tgardner: be there in a bit
<skaet> ogasawara, is the linux kernel we have in the archive now going to be the one for beta 1?   (or are there some more bug fixes you're trying to land)
<tgardner> ogasawara, ack, interview call at 0900 if you wanna attend
<ogasawara> skaet: the one in the archive is what I plan for beta-1
<skaet> ogasawara, thanks. :)
<jsalisbury_> Is anyone else having issues with tangerine?
<ppisati> jsalisbury: it has been rebooted some minutes ago
<tgardner> jsalisbury, I'm trying to get it to reboot
<ppisati> jsalisbury: but otrher than that, it works here
<tgardner> ppisati, I don't think it actually rebooted
<jsalisbury> tgardner, ppisati, ahh, ok. thanks
<tgardner> ppisati, 16:02:15 up 3 days,  1:17,  2 users,  load average: 0.00, 0.03, 0.08
<ppisati> good point :)
<jsalisbury> tgardner, my sessions all got kicked off and I can't seem to log back in.
 * jsalisbury wonders if tgardner has a long enough arm to reach the power switch :-)
<tgardner> jsalisbury, gonna have too pretty soon
<tgardner> jsalisbury, looks like its back, 2 min uptime
<jsalisbury> tgardner, hmm, I'm back in now
<jsalisbury> tgardner, top looks really strange, a bunch of root RT processes
 * cking orders a USB3 -> SATA dohicky
<jsalisbury> tgardner, hmm, maybe that's normal.  Looks like watchdog, migration and kworker
<jsalisbury> 64 threads for each ?
<apw> jsalisbury, could be easily be one per cpu of many of those kernel threads
<apw> jsalisbury, to ensure deadlock avoidance
<jsalisbury> apw, that makes sense.  
<cking> it's not like they are doing much most of the time
<apw> if anything ever in many cases, just sitting there
<cking> and doing the very occasional wakeup
<cking> hrm, why has rhythmnbox lost all my mp3s?.  Bah
<apw> cking, synced to the contents of your phone
<cking> fortunately not
<cking> if my music collection gets sync'd to /dev/null I won't be a happy bunny
<ogra_> buy vinyl its more persistent anyway !
<ogra_> (though admittedly hard to listen to on flights)
<apw> ogra_, well as long as you don't play it with anything other than a laser
<ogra_> lol
<apw> they say you lose about 20% of the top end the first time you play it with a needle
<ogra_> you think needles wouldnt pass security ?
<apw> which is why the autophiles like it, it softens the top end right off
<ogra_> nonsense
<ogra_> digitalization swallows more 
<apw> oh i am not saying an mp3 is worth shit at all
<ogra_> unless you deal with hilarious big media to store flacs
<apw> the thing about digitisation loss though is you can target it, vinal lost is exponentially worse at high frequencies
<apw> either way i can't tell with my ears
<ogra_> needles dont do harm to records if your player is proper ... sadly the used vinyl has usually been played on record grinders
<ogra_> the hig feqs totally depends on the setup and on how much you invest
<ogra_> it *is* on the media ... if your first playing scratches it off is a different thing and a matter of the equipment
<apw> ogra_, indeed, though other than a non-contact reader, i am not convinces any needle based reader is able to not remove the high end, they are simply too heave to move out the way
<ogra_> the area where the needle touches the vinyl doesnt have any sounds on it 
<ogra_> vertically that is 
<apw> the needle is vibrated up left and up right to induce the sound
<apw> somethign is moving it
<ogra_> yep
<apw> ok, so that thing that moves, has to be moved, moved by the surface shape of the slot in the plastic
<ogra_> and there it matters how your player, your system, your needle itself etc is designed and combined
<ogra_> right
<apw> and the relative weight of that defines how much energis is required for the plastic to mvoe it
<apw> the higher the frequency the faster, and more the energy
<ogra_> if it would grind off the surface you would have black plastic dust all around if you played a record 
<apw> and at those higher frequency it is a thiner and thiner bit of plastic which does it
<ogra_> thats where the design of the cardtridge comes into play 
<apw> ogra_, nope, all it has to to is average the plastic into a flat line
 * tgardner rebuilds gomeisa precise chroots yet again
<apw> it doesn't need to remove any
<apw> just move it about
<ogra_> and the cut of the needle etc
<apw> of course a good needle has to be infinitly better than a bad one
<ogra_> i have 40year old records that still have all high freqs :)
 * tgardner reboots gomeisa
<apw> ogra_, and how can you tell that?
<tgardner> smb, need to bounce gomeisa. holler when your job is done
<apw> i can believe you have records that sound fine after 40 years
<smb> tgardner, sure
<apw> tgardner, subtle ...
<apw> tgardner, i wondered why my build was struggling, the chroot is gone :)
<apw> tgardner, what happened to em, will mine break if i update them?
<ogra_> apw, indeed, its hard to tell since my ears got 40 years older too :)
<smb> tgardner, I am gone
<tgardner> apw, more of that resolvconf package nonsense. it keeps breaking things on a lucid host
<tgardner> tangerine is working well
<apw> tgardner, yeah just have to upload 100MB there to get my build going :)
<tgardner> apw, whinger
<apw> tgardner, to the very core, always
<tgardner> apw, its rebuidling now...
 * smb found the copy /etc/passwd from the host approach breaking chroot updates in subtle ways
<jjohansen> apw: bug#925028 isn't entirely fixed by my apparmor patches.  It still requires profiles to have the attach disconnected flag, I am planning to look at it more today
<apw> bug #925028
<ubot2`> Launchpad bug 925028 in lxc "apparmor breaks lxc-start-ephemeral (apparmor+overlayfs returns -EINVAL)" [High,Confirmed] https://launchpad.net/bugs/925028
<apw> ok cool
<jsalisbury> ogasawara, this looks like it might be a quick fix by including the firmware in precise: bug 939231
<ubot2`> Launchpad bug 939231 in linux-firmware "Dlink DWA-160 (Atheros AR9170 802.11n ) is broken" [Undecided,New] https://launchpad.net/bugs/939231
 * cking -> EOD
#ubuntu-kernel 2012-02-24
<ogasawara> Sarvatt: thanks for getting that RC6 test kernel put together
<ogasawara> Sarvatt: I'll follow up with the release team first thing in the morning to see about an upload.  I do think it's a critical fix that we should have for Beta.
<Sarvatt> ogasawara: nono thank you for doing absofrigginlutely everything else including the call for testing and listening to me when i whinged about how it should be fixed when it wasnt really :)
<Sarvatt> 50% battery life is seriously important, i was getting a patch to blacklist samsung laptops from it ready, so glad it was easier
<ogasawara> Sarvatt: on the bright side, crimsun said he's got positive test results with your kernel \o/
<ogasawara> Sarvatt: I'm hoping the hard shutdown's we're seeing with the ASUS UX31's might also be fixed with it.  hopefully we'll have some test feedback by morning.
<Sarvatt> i'm absolutely 100% sure they will be, hoping for testing proving it though
<ogasawara> Sarvatt: yep
<ogasawara> Sarvatt: anyways, I'm off to bed now.  I'll keep you posted about the upload and will update the call for testing email with further updates.
<Sarvatt> that one person tested on eugeni's patch where rc6=1 really meant rc6 only in 3.4, would  be weird if rc6p only was fixed and i'm surprised the call for testing went so good when it was busted
<Sarvatt> the call for testing kind of excluded desktop boards since it required power readings on battery though and desktop boards without bios upgrades is where the pain will be outsde of ux31's
<Sarvatt> there were asus z68 motherboards where they fixed the rc6 problems via a bios upgrade that some people didnt apply i'm sure
<Sarvatt> and the bios upgrades bumped the voltages used during rc6, we had bugs about that a year ago when they first came out
<Sarvatt> really hope its fixed for the majority of people now :) the rc6p only graphics corruptions i've passed on to the x guys to spot in case bugs are filed against x drivers, https://launchpadlibrarian.net/93566331/Screenshot%20at%202012-02-21%2009%3A53%3A04.png is really noticable
<Sarvatt> its always black with with the random corruption there
<ogasawara> Sarvatt: we've gotten some fairly decent feedback, even with the borked patch, but indeed I want to make sure it's exactly what we want and expect it to do for when Beta ships and gets wider testing
<ogasawara> Sarvatt: yah, I gave bryce a heads up to keep an eye out for any possible graphics corruptions from rc6 too
<Sarvatt> ogasawara: do you think it has any chance of making the beta?
<ogasawara> Sarvatt: I hope so.  Beta Freeze was today, but we don't ship Beta-1 until next Thurs.
<ogasawara> Sarvatt: so there's time for an upload and respin of images, assuming I get the go ahead from the release team
<ogasawara> Sarvatt: which is why I intend to catch skaet first thing in the morning
<Sarvatt> ogasawara: really appreciate you doing that on a saturday, kicking myself for not noticing that problem with the original patch
<Sarvatt> oh friday, same difference, its much appreciated
<ogasawara> Sarvatt: no worries and I totally missed it too!
 * ogasawara really stumbles off to bed.  Sarvatt, shouldn't you be sleeping right now?!  isn't it like 1am or something for you?
<Sarvatt> yep, goodnight :)
<Sarvatt> done uploading i386 kernels to the same place as the amd64 ones so i can disappear now, yay
<krychek> hi, can anyone help me in opening an upstream kernel bug for this: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/811464 ?
<ubot2`> Launchpad bug 811464 in linux "Cannot mount media in DVD rom drive, Acer Timeline 4810TG." [Undecided,Triaged]
<krychek> i dont know which category to choose
 * smb reboots
 * smb thinks to be back
<smb> apw, bug 940198 if you are interested in subscribing
<ubot2`> Launchpad bug 940198 in unity "Help screen activates when switching desktops" [Undecided,New] https://launchpad.net/bugs/940198
<smb> hm, ok and enigmail feels incompatible with thunderbird 11...
<herton> ppisati, did you saw the failure of latest linux-ti-omap4 update for maverick? (bug 932237) Not sure why it's failing, since nothing in that area changed in last update...
<ubot2`> Launchpad bug 932237 in kernel-sru-workflow/verification-testing "linux-ti-omap4: 2.6.35-903.31 -proposed tracker" [Undecided,Fix released] https://launchpad.net/bugs/932237
<ppisati> herton: let me check
<ppisati> herton: cool, it was actually broken even in the previous kernel
<herton> ppisati, ouch
<ppisati> herton: now i'm testing the first kernel that was supposed to fix that bug
<herton> ppisati, ok. yes, weird that it "verified" on previous release
<ppisati> herton: actuallu it was broken even in the previous kernel, so i'm stating to think that it has always been broken in M
<ppisati> herton: i'm pretty sure i did the test by myself in O and it was ok there
<ppisati> herton: so, i'm retesting all the releases now
<herton> ppisati, ok, may be maverick has something else missing. but 861296 passed verification on M, so may be there is something different in tests, or something else
<herton> 861296 == bug 861296
<ubot2`> Launchpad bug 861296 in linux-ti-omap4 "mmap fails to allocate 2030Mb heap on ARM" [Undecided,Fix committed] https://launchpad.net/bugs/861296
<ppisati> herton: the fix for that went in .29
<ppisati> herton: .30 and .31 are broken or, at least, the case attached to that lp bug doesn't work on these kernels
<ppisati> herton: so, either we broke it after .29 ( and i'll know soon), or we never really fixed it in M and all the previus tests are moot
<herton> ppisati, true. I don't see any change related to mmap after .29
<ppisati> herton: ok, it's broken even for the kernel were the fix went it
<ppisati> cool
<ppisati> ok, i'll retest for N and O too now
<herton> ouch, ok
<ppisati> in the mean time /me -> lunch
<brendand> herton - do you know how much longer Lucid -proposed kernels will be coming in for?
<herton> brendand, do you mean how much time we have for testing? until end of next week
<brendand> herton - no, i mean how much longer we'll be building new kernels for Lucid?
<herton> brendand, I'm not sure. I think we have 5 year support on it
<herton> that means until 2015
<apw> brendand, another three years isn't it, though they do slow down in the last year ish
<herton> apw, isn't server supported by 5 years? so I suppose it means kernel along with it
<herton> but for certification may be 3 years indeed
<herton> (as desktop == 3 years of support)
<apw> herton, your numbers make sense, as to who is responsible for testing after that, and what they test on i suspect we should refer that to pete
<apw> to start the discussion on any changes
<brendand> i think our policy is to test the last LTS only
<brendand> so once precise is released we might stop
<brendand> not sure if it will be immediately or there will be a gap
<apw> brendand, i am not sure its as cut-n-dried as that, there was no capacity for hardy at all originally, so only lucid was done
<jMCg> Hello happy people o/~
<jMCg> I was wondering if someone here would like to assist me in hunting down a bug, or rather, finding a solution|workaround to a bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/818177
<ubot2`> Launchpad bug 818177 in udev "boot failures as /dev is not transferred to /root (because 'udevadm exit' times out waiting for a deadlocked worker)" [High,Fix released]
<jMCg> Even though my system is up-to-date, the VMs I'm trying to boot (which are just as up-to-date) are showing this exact behaviour.
<jMCg> (And in the host, vgscan is hanging, yes)
<jMCg> uhm... pretty please?
<jMCg> I mean: I've also tried out an other kernel now, thinking that maybe with -virtual, when initramfs isn't too busy doing stuff it won't hang, of course it turned out to still run into the same issue.
<jono> jsalisbury, looks like your test kernel fixed my bug
<jono> no wireless issues at all now :-)
<sforshee> tgardner, don't you have a linksys e3000?
<tgardner> sforshee, hang on, lemme check
<tgardner> sforshee, wndr3300, wrt310n, cisco-e3000
<sforshee> tgardner, the cisco-e3000 is probably the same thing
<sforshee> would you recommend it?
<sforshee> refurbs are only $50, I was thinking about picking one up
<tgardner> sforshee, I think so. I've not any problems with any of them to be honest. I'm using the wndr3300 as my firewall.
<sforshee> tgardner, thanks. I'd be using this one behind my firewall anyway.
<jMCg> I think I've mentioned this, but just in case it's unclear: The udev version I have installed is the one were but#818177 is fixed. -- But it the VMs I'm trying to boot don't get past init-bottom.
<ogasawara> Sarvatt: I'm sure you've already seen, but I uploaded the RC6 fix this morning, ie 3.2.0-17.27
<jsalisbury> jono, cool, thanks for testing
<cking> ogasawara, are we going to get in touch with all the testers and ask them to re-test then?
<ogasawara> cking: I'd like to.  I plan to respond to the call for testing email asking for anyone who has already tested to please re-test if possible.
<ogasawara> cking: and for sure I'll make sure those who reported bugs to please re-test.
<cking> cool, I'll retest once the kernel is ready ;-)
<ogasawara> cking: the amd64 kernel has finished building.  I'll probably wait for i386 to finish and then post my email.
<cking> ogasawara, I'll test tomorrow, got the H/W doing some other soak tests at the mo
<jMCg> is there a way for me to say in launchpad the released fix doesn't work? (re: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/818177 )
<ubot2`> Launchpad bug 818177 in udev "boot failures as /dev is not transferred to /root (because 'udevadm exit' times out waiting for a deadlocked worker)" [High,Fix released]
<jMCg> I wish I was as invisible in real life, as I am on the internet, when hitting a technoligical dead-end.
<jMCg> Or flying, flying would be a cool super power too.
<pbuckley> jMCg: make a launchpad account
<pbuckley> and put a comment
<jMCg> pbuckley: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/818177/comments/127
<ubot2`> Launchpad bug 818177 in udev "boot failures as /dev is not transferred to /root (because 'udevadm exit' times out waiting for a deadlocked worker)" [High,Fix released]
<pbuckley> then you have done what you can :)
<pbuckley> i unfortunately can not provide any direct assistance on this issue other then what i have already provided.. stick around though.. lots of smart people here ;)
<jMCg> pbuckley: I haven't - as it still doesn't boot.
<jMCg> pbuckley: I've been sticking around and asking (at very different times) for two days now.
<pbuckley> :(
<jMCg> Not sure if it's two days, because my sleep pattern is a bit b0rked.
<pbuckley> have you tried offering free beer?
<jMCg> I don't have any :-/
<jMCg> And I just drank the last bit of wine I have.
<jMCg> But I've got plenty of rakija.
<pbuckley> rakija?
<jMCg> pbuckley: that's schnapps made from plums
<herton> jMCg, it seems you are hit by lvm2 issue discussed at bug 802626. 818177 was mostly about firmware loading and udev exiting problem I think, a different issue
<ubot2`> Launchpad bug 802626 in udev "vgchange may deadlock in initramfs when VG present that's not used for rootfs" [High,Confirmed] https://launchpad.net/bugs/802626
<jMCg> herton: but if I boot the kvm with init=/bin/sh I don't see vgchange running
<jMCg> init-bottom then finishes: http://dpaste.com/707701/
<jMCg> So what's next after that?
<herton> jMCg, it's a "race" in udev exiting and vgchange invocation, you sometimes get vgchange stuck sometimes not, it doesn't matter what init you use
<jMCg> herton: no, init=/bin/sh doens't lead to that. it just exits after init-bottom.
<herton> basically udev while exiting in initramfs stops receiving/processing events, discards DM_COOKIE sent by the kernel, making vgchange stuck in a semaphore which never goes down (dmsetup udevcomplete doesn't run on receiving DM_COOKIE)
<jMCg> hrm.. I could just remove the lvm udevs?
<jMCg> I don't need them in the vm anyway.
<herton> jMCg, just take a look at 802626, there are some solutions posted there
<jMCg> herton: what I don't understand is why vgchange is invoked if vgscan doesn't deliver anything.
<jMCg> oh. I could also just remove the lvm stuff from my image.
<herton> vgchange is called from an udev rule. That's why also udev is stuck until timeout after udevadm exit
<herton> and you get the boot delay because of that
<jMCg> herton: it's not a delay, it's stuck. Forever.
<ohsix> did you wait forever? or just a while? :]
<jMCg> ohsix: I waited for a night (well, I slept).
<ohsix> i see
<herton> jMCg, if your problem is vgchange, may be the timeout workaround that was made isn't working in your case. still I would recommend you take a look at 802626
<jMCg> herton: right now I'm uninstalling lvm2 and mdadm from the image for the VMs and trying again.
<jMCg> In silent hope this fixes the issue.
<jMCg> :-/
<jMCg> Nope.
<jMCg> So, no lvm2, means no /lib/udev/rules.d/85-lvm2.rules -- still the issue persists.
<jMCg> hrm.. I think I should install grub and boot the VM's kernel, instead of booting the host's which uses the host's initrd.
<herton> jMCg, well you said vgchange was freezing on the bug report, may be your initrd wasn't recreated and vgchange is still running? Or it's another problem. Also are you using lvm, what's the setup. Probably you will have to debug what's freezing really, rebuild the initrd with an udev with debug messages etc. to see what's going on.
<jMCg> herton: no, what I said is, that even after the *host* was fully booted, vgchange was still running.
<jMCg> I'm using lvm on the host, the VM is on an LVM partition, but it's unaware of that fact, for the VM it's just a disk.
<herton> jMCg, ah, that's a problem on the host then. You should fix your host, the vm may be isn't finding the lvm partition
<jMCg> herton: it is.
<jMCg> What?
<jMCg> I think that didn't make sense. Maybe.
<jMCg> I pass the partition as /dev/mapper/vg0-web-root -- kvm finds the partition just fine.
<jMCg> herton: how do I do that: rebuild the initrd with a debugging message ridden udev?
<herton> jMCg, may be the vgchange stuck in your host is the root of your lvm issues, and it's probably the same problem discussed at 802626. I would suggest you solve the host issue first
<jMCg> herton: oh.
<jMCg> You mean, while it may be able to find it, it's unable to actually boot it, because vgchange blocks.
<herton> yes, could be
<jMCg> How can I dump the current grub menu?
<jMCg> *sigh* wonder why it doesn't boot....
<jMCg> Ima gonna go make some go make some foodz.
<jMCg> I wanted to goto the movies today, I guess I'll have to stay in until I'm fucking done with this fucking piece of shit.
<jMCg> whoops. Wrong channel. ~_~
 * jMCg embraces the kick/ban to come.
<pbuckley> lol
<bryceh> jMCg, tsk
<jMCg> sorry bryceh ._.
<jMCg> But I'm now stuffed with pasta, and ready to tackle this.
<bryceh> excellent
<jMCg> it boots!
<jMCg> The host, at least.
<jMCg> And no vgchange running on the host, so I suppose that's good.
<jMCg> Aaand, the vm hangs in the same spot.
<jono> jsalisbury, I see a new kernel release in Precise...does this include the fix for my bug?
<jono> if so, I can test
<ohsix> you can view the changelog :> it should reference the bug if it does, it's good to be verbose about patches, and people usually are
<ogasawara> jsalisbury: yo, just saw your email about 911059
<ogasawara> jsalisbury: I'm not seeing that patch upstream yet
<ogasawara> jsalisbury: but assuming it lands before kernel freeze, we can just cherry-pick is as pre-stable
<jMCg> So, after a short de-tour to make traffic server compile with clang, I'm back to debugging our lovely vm boot issue.
<BigglesPiP> Hello, I suspect there is a bug in 3.0.0-12 that means my NIC is always powered off before halt, want to go back to 3.0.0-9 and see if it works again there, but I can't find the old kernels...
<jMCg> BigglesPiP: checkout the brz tag and build it?
<BigglesPiP> really? I guess I'll find out in 45 minutes then, only have netbook chips available
#ubuntu-kernel 2012-02-25
<jMCg> short summary: I can't get grub to install while having the kvm "booted" with virt-rescue, I can't get the kvm to boot with the host's kernel/initrd, because of race conditions in udev/init-bottom
<jMCg> lovely.
<jMCg> Btw, trying to install a grub in the guest is just a straw -- there's no gurantee that it'll boot with that.
<Kano> hi, why is include/generated/compile.h not packaged?
<Kano> it is in the debian kernel headers
<Kano> http://packages.debian.org/wheezy/amd64/linux-headers-3.2.0-1-amd64/filelist
<Kano> the complete generated part is missing
<Kano> well not all, just that file...
<Kano> here is only the cross/config.h
<bethebunny> Is there any way I can tell the kernel to not buffer a pipe? I realize this is a bad idea, I just want to test some things
<jMCg> oh, wow. Something seems to have leaked from libguestfs into my host.
<jMCg> oh, joy. So, when I install more than one kernel in $host, it doesn't boot anymore.
<eagles0513875> hey guys :) 
<eagles0513875> is 3.2.0-16 or -17 going to be the final kernel for precise?
<eagles0513875> hey yofel
<eagles0513875> you a kernel expert
<eagles0513875> hey guys anyone around in here 
<eagles0513875> im getting a kernel panic with the latest precise kernel the -17 as well as the -16 http://picpaste.com/pics/sshot-55-LmLJQcdb.1330180894.jpg <-- shows the panic
<vitb_home> eagles0513875: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/935585  looks similar enough
<ubot2`> Launchpad bug 935585 in upstart "[kernel panic] init: log.c:786: Assertion failed in log_clear_unflushed: log->remote_closed" [High,Confirmed]
<eagles0513875> yep thats it  it
#ubuntu-kernel 2012-02-26
<dash> howdy. I'm running precise on a freescale mx53 and it doesn't have some kernel modules i'd like (for example, 'tun'). what's the recommended procedure for getting that? "apt-get source <my linux-image package>" and then build modules myself?
#ubuntu-kernel 2013-02-18
<alkisg> Samba crashes with the new linux-generic-lts-quantal kernel...
<alkisg> And virtualbox (-ose) can't compile its modules with dkms
<alkisg> smbd crash: http://paste.ubuntu.com/1675846/
<alkisg> brb with the older kernel to verify my setup is working there...
<work_alkisg> It works fine with the stock precise kernel, and it works only once with the lts-quantal kernel, even if I restart smbd it doesn't work again without reboot
<alkisg> Unfortunately apport asks to file a bug report but it just stops after asking a few samba-related questions
<ppisati> moin
<smb> morning
 * apw yawns
 * smb tries not to join
<apw> alkisg, is there any kernel messages with that from dmesg ? 
<apw> sac
<alkisg> apw: nothing in dmesg or syslog
<alkisg> Trying after 1 hour, it worked once more again, then stopped working again
<alkisg> (with no service reboots involved)
<apw> alkisg, so this is smbd which i think the #ubuntu-server people probabally deal with most
<alkisg> apw: ah, thanks, didn't think of that one, will join in a bit
<apw> alkisg, it must be an interaction between the two but they out to know how to debug it better than us
<alkisg> Gotcha, I'll first gather more info to be in a position to give better feedback and I'll ask there afterwards - thanks again
 * ppisati goes to move his car before he gets a fine :P
<apw> henrix, who did the replacent samsung brickage patch backports in the end, and are they already applied ?
<apw> henrix, "      efi: Clear EFI_RUNTIME_SERVICES rather than EFI_BOOT by "noefi" boot parameter
<apw> " that one just hit linus' tree and the merge commit says its anohter bit for that series
<henrix> apw: i believe we reverted our initial solution and applied the bits from upstream stable updates
<apw> henrix, well i think we may be missing a fix, which only appeared over the weekend, sigh
<henrix> apw: ups! :p
<apw> henrix, nothing we did wrong, just a bug found in it.
<apw> henrix, from the looks of it it is only effective if people add extra command line options, so i don't think it is a disaster or anything
<apw> s/effiective/an issue
<caribou> smb: apw: just tested latest linux-crashdump meta-package. Works like a charm !!!
<caribou> smb: apw: it now pulls kdump-tools which works as expected
<smb> caribou, Good to hear... so one more off the list...
<caribou> smb: I'm on the blueprint now.
<caribou> smb: the only thing is that I had to increase the crashkernel= parameter above 128Mb (192Mb worked) to get enough space
<caribou> smb: our default value is at 64Mb which is clearly too small
<smb> caribou, That would bring back the minimal initrd discussion. Which seemed to sometimes have weird side-effects (at least for me on a desktop with a card-reader)
<caribou> smb: I was never too worried about it, since anything above 2G was defaulting to 128Mb,but now it is no longer sufficient
<caribou> smb: let me test again with more memory in my VM
<caribou> smb: works fine with crashkernel=128M on a 4Gb VM. Maybe my first test was wrong
<caribou> smb: I'll look at it again later
<smb> caribou, Well, I would assume that it working or not rather depends on how big kernel and initrd are. Which is independent of the overall RAM...
<apw> at least it sounds close
<caribou> smb: partly true; the crashkernel= syntax makes a difference depending on the size of the available memory
<caribou> smb: crashkernel=384M-2G:64M,2G-:128M
<smb> caribou, I know. Though that is more of a "we don't want to take away too much if there isn't much" thing
<caribou> smb: yep. in the default case (i.e. < 2G) crash dump woudln't work
<caribou> smb: Debian defaults to 128Mb for all cases
<smb> Certainly, on a system with below 512M this is quite a waste... but then...
<caribou> smb: ok, I'm going to work on adapting apport to the new structure
<smb> caribou, ok
<lantizia> apw: are you about?
<ppisati> brb
<henrix> infinity: any luck with the bugs verification?
<infinity> henrix: Not over the weekend, no.  And it's a holiday in the US (and here) right now, so I dunno about today.
<henrix> infinity: ack
<infinity> lamont: Are you working today?  Did pinky get our console issues on sagari sorted so we can verify those SRUs?
<apw> lantizia, hi
 * ppisati -> gym
 * rtg -> lunch
<rtg> apw, you'll enjoy this: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1128840/comments/14
<ubot2> Ubuntu bug 1128840 in linux (Ubuntu) "Thousands of lines of "phy0 -> rt2x00pci_regbusy_read: Error - Indirect register access failed" printed to dmesg and to TTY's" [Undecided,Confirmed]
<apw> rtg :)
<rtg> apw, we'll probably get a diatribe out of it.
<apw> rtg, dogpile material and no mistake
<infinity> apw: Preeeeetty sure the "Linus Torvalds" the subscribed isn't actually Linus. :P
<infinity> s/the/they/
<rtg> infinity, his LP ID is kind of funny :)
<infinity> As is the email address is derived from.
<infinity> It's definitely not Linus. :P
<rtg> no, I think you're right
<apw> he cirtainly deserves to be subscribed to every single 
<apw> bug ... for having that name :)
 * apw calls it a day ...
 * rtg -> EOD
<infinity> hggdh: How goes the regression testing on the precise SRU?
<hggdh> infinity: sorry, forgot to check the results, give me a few minutes
<hggdh> infinity: done, bug updated.
<infinity> bjf: Want to do me a favour and turn the crank on the bot a few times and see where it settles?
<infinity> hggdh: I'm guessing there was some regression testing to be done for armadaxp for precise, too?
<infinity> ppisati: Were you planning to rebase precise/ti-omap4, or just skip that one, since it looks like it was an x86-only revert?
<bjf> infinity, ack
<ppisati> infinity: precise respin? wasn't aware
<ppisati> infinity: anyhow, if it's a x86-only fix, i'll skip it
<hggdh> infinity: for quantal, kernel 3.5.0-1609.11 is done. For precise, I will jump the gun and start the tests now
<infinity> ppisati: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/1124514
<ubot2> Ubuntu bug 1124514 in Kernel SRU Workflow "linux-ti-omap4: <version to be filled> -proposed tracker" [Medium,In progress]
<infinity> ppisati: I'll let you be the judge.  If you think it's pointless, please dupe that bug to the older tracking bug to get it off the bot's radar.
<ppisati> infinity: doh!
<ppisati> infinity: completely missed it...
<bjf> infinity, i think the bot has done it's all
<ppisati> infinity: done
<ppisati> infinity: but i invalidate it...
<ppisati> infinity: uhm, hope it's ok
<infinity> bjf: Cranking the bot again should look more pleasant now.  I think all I haven't released at this point is ti-omap4 and armadaxp on precise.
#ubuntu-kernel 2013-02-19
<bjf> infinity, turning the crank boss
<bjf> i swear i'm going to get the bot to also monitor this channel so you can tell it run
<infinity> +1
<infinity> bjf: I suspect we have an oops with 1117447 ... Maybe I should just handle it manually instead of trying to teach the bot WTF is going on there.
<infinity> bjf: (Its parent bug was duped to the new master bug, due to an x86-only revert, so the parent never got "promoted", so this one will sit in a holding pattern)
<bjf> infinity, if you mark the Kernel SRU Workflow task as invalid the bot will ignore it
<infinity> bjf: Sure, ignoring it wasn't what I was hoping for, but "the bot doing the right thing" probably means teaching it reasoning. :)
<infinity> bjf: So, ignoring it seems fine.  I'll do that and update it manually.
<ppisati> moin
<smb> moin
 * apw yawns
<henrix> apw: you around?
<henrix> i'm having a weird build failure for armel. this morning i had a build failure with this: http://pastebin.ubuntu.com/1681519/
<henrix> i tried a build in gomeisa and it was building fine, so i tried a rebuild
<henrix> but its failing again with same error but in a different file
<henrix> (previous file succeeded)
<henrix> apw: any ideas?
<henrix> apw: the current failure is here: https://launchpadlibrarian.net/131735908/buildlog_ubuntu-quantal-armel.linux_3.5.0-25.38_FAILEDTOBUILD.txt.gz
<apw> henrix, very odd
<henrix> apw: yep. looks like the file is corrupted, but it isn't
<henrix> apw: i can try another rebuild, but since the build can take a couple of hours...
<apw> we have had this before if it happens a couple of times on the same buildd, then we might need to get that buildd looked at
<apw> henrix, so i would note where it buolded and take the log, and put it back again
<henrix> apw: ok, i'll keep all the logs and retry
<henrix> apw: thanks
<apw> henrix, but it is a worry for sure
<henrix> apw: the build restarted in a different buildd (the 2 previous failures occurred in the same buildd)
 * henrix -> SIGFOOD
<apw> henrix, well that is a good thing to know, perhaps that original buildd is bust
 * rtg rebases raring against 3.8 final
<brendand> henrix, will the new -proposed kernels be prepped and ready for verification testing by the end of this week?
<henrix> brendand: yes
<sforshee> stgraber, did you ever get your x230 fixed?
<infinity> henrix: Curious.  Why did the recent SRU patches cause an ABI bump for quantal, but not precise?
<henrix> infinity: actually, i'm also a little bit puzzled with that. i know that Q failed to build in the ABI checks for armel and armhf, and P didn't
<henrix> infinity: i haven't analysed the reason yet
<rtg> different compiler versions ?
<infinity> henrix: Seems a bit odd.  Anyhow, the reason I need to pay attention is because I need to remember to copy the lbm/meta to security from the previous SRU when we release this one, which will be a bit annoying.
<infinity> (I still need to figure out how to win the "screw ABI numbers, let's just bump on every build" fight)
<henrix> rtg: that could explain it, i believe
<henrix> if i figure that out, i'll let you guys know
<infinity> Different compiler versions shouldn't be leading to different symbols being exported when one introduces the same patches, one would hope.
<infinity> But it's possible.
<henrix> well, i know if was failing for armel and armhf but not for amd64 and i386
<henrix> s/if/it
<infinity> henrix: That's even more weird.
<henrix> yep
<ppisati> armel? quantal?
<henrix> ppisati: yes
<ppisati> thos two words in the same sentence sound like an oximoron to me
<ogra_> yeah
<ogra_> not worth even wasting thoughts on it
<ppisati> +1
<infinity> Except that the problem was also there for armhf.
<infinity> So...
<ogra_> we never supported armel after 12.04 ... its "just there"
<ppisati> ah then...
<ogra_> yeah, indeed,, if its armhf too, its valid
<infinity> Which makes sense, since kernels compiled on armel and armhf should be identical.
<henrix> ppisati: right, i keep forgetting that and my scripts will try to build both armel and armhf
 * henrix goes remove armel from the Q builds!
<infinity> I had a dream last night that we replaced all our ARM buildds with datacenter-grade armv8 machines.
<infinity> Waking up to reality was unpleasant.
<infinity> henrix: No, don't do that.
<infinity> henrix: If we were going to do that, we should have done it before release, not now.
<maswan> infinity: those are what, at least a year out still?
<infinity> henrix: You're not going to have any armel-specific failures, so just leave it be.
<henrix> infinity: oh, i meant from my build test scripts ;)
<infinity> maswan: At least, yeah.  I guess I'm more optimistic in my sleep.
<infinity> henrix: Oh, sure.  You could have done that ages ago, since armel/armhf kernels should be identical, save timestamps.
<stgraber> sforshee: nope, they ended up having to ship the unit to Ontario for someone there to take a look. Should have it back by EOW
<infinity> henrix: That's true on precise too, for that matter.
<henrix> infinity: ack
<sforshee> stgraber, that's too bad
<ppisati> infinity: how abot those calxeda nodes that were spposed to replace all our buildds?
<sforshee> stgraber, so Ted Tso commented on the upstream bug that his x230 works fine, and he was using a newer firmware version than you had
<infinity> ppisati: People got all excited about getting me those, then I heard something about availability issues, then I heard... Nothing.
<infinity> ppisati: Given that I know Linaro just got some new toys along those lines, I should probably reopen that conversation.
<ppisati> infinity: life sucks and then you die.
<stgraber> sforshee: yeah, IIRC I was 2 firmware updates behind but they were just adding support for a longer serial number and some new hardware support (I definitely would have updated if I saw anything related to UEFI bugs). Anyway, I'll make sure the one I get back is fully up to date.
<infinity> ppisati: That's a bit dark for a Tuesday morning, but I can't say I disagree with the sentiment. :/
<sforshee> stgraber, okay. I didn't see anything in the changes that looked like it should address the bug either. But his bios version also wasn't listed on Lenovo's website ...
<hggdh> infinity: the Precise armadaXP kernel is all yours
<infinity> henrix: Want to crank the bot a couple of times, so the tracking bug agrees with hggdh?
<henrix> infinity: sure, in a minute
<henrix> infinity: should be all done
<infinity> henrix: Danke.
<rtg> apw, 'UBUNTU: [Config] CONFIG_MTD_ONENAND_SIM=n' caused a build failure. tsk, tsk.
<smb> rtg, he isn't listening right now
<rtg> smb, s'alright. I was just hassling him
<smb> rtg, Obviously, but it is more fun when he can see it. :)
 * rtg will be back in a bit
<bjf> bug 1092924
<ubot2> Launchpad bug 1092924 in UTAH "Cobbler install of recent raring-desktop images failing" [High,Triaged] https://launchpad.net/bugs/1092924
<doanac> bjf: yes - I spent some time running the 20130116 and 20130204 builds and out of 6 failures I hit, this stack trace was in 5 of them
<bjf> doanac, has someone tried installing the daily iso onto that machine just using a usb stick?
<doanac> bjf: I think plars does that type of install and it hasn't been a problem
<doanac> however, that way won't work for us in qa automation
<bjf> doanac, i understand, i'm just trying to get more data
<gema> bjf: given the rate at which this error happens, if it happened with a usb it'd be fixed by now
<gema> bjf: that'd be my take on it
<gema> bjf: it makes our automation on hardware non-usable
<bjf> gema, i'm quite aware of that
<doanac> bjf: do you think that trace is enough information to help?
<bjf> doanac, it helps, not sure it's going to be enough though
<bjf> doanac, it would be good to get that system up so that we can collect all the log information (that contains info about the system hardware)
<doanac> bjf: i can do that.
<doanac> how do you prefer I get that information?
<bjf> jsalisbury, ^ needs to be on our hot list (for now)
<bjf> doanac, "apport-collect 1092924"
<doanac> bjf: okay, I'll give that a shot right now. thanks
<jsalisbury> bjf ack
<bjf> doanac, if we can get more of the syslog than just the stack trace, that would also be helpful
<doanac> bjf: sure, I'll grab the full install log
<bjf> doanac, is this the same errors that you are having on the power testing systems?
<doanac> bjf: I haven't dug into those jobs, so I don't know for sure
<bjf> doanac, ack
<gema> bjf: it is
<gema> bjf: at least one of them
<bjf> gema, interesting since the HW is different
<gema> doanac: maybe we should try to reproduce on one of those machines also and attach some more logs
<gema> doanac: plars could get you access to those
<doanac> gema: i've got things set up now to make it pretty easy to reproduce a bug
<gema> bjf: indeed, we were seeing the same behaviour in the installs, but until now, we didn't have logs
<gema> bjf: now we can have some runs and try to gather more logs from those
<gema> doanac: sounds good
<bjf> gema, doanac, yes, please try to reproduce there and if you have problems, open a new bug with the logs for that system attached to that bug
<bjf> gema, doanac, we will dupe one against the other if it truly is a duplicate
<gema> bjf: ack
<lool> rtg, apw: Hey!  I was wondering whether someone is looking at updating hte Nexus 7 kernel with Android 4.2.2 changes?  there might be some interesting bug fixes there
<rtg> lool, last I looked the kernel had not changed.
<lool> oh really
<rtg> lool, that was a week ago. checking...
<rtg> lool, hmm, new branch: android-tegra3-grouper-3.1-jb-mr1.1
 * ogasawara back in 20
<rtg> lool, guess we'll take a stab at it.
<lool> rtg: seems to be about 3 commits on top of -mr1
<rtg> lool, I'll pick 'em up and test them on my N7
<lool> rtg: awesome, thanks!
<lool> video, proximity sensor and wifi fixes apparently
<lool> ogra_: ^
<lool> ogra_: https://android.googlesource.com/kernel/tegra/+log/android-tegra3-grouper-3.1-jb-mr1.1
<ogra_> lool, thanks
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<rtg> apw, ogasawara: uploaded raring rebase on 3.8 final
<rtg> working on N7
<ogasawara> rtg: ack
<rtg> herton, henrix: y'all might want to have a look at the bug states for bug #1130111. create-release-tracker puked a python stack dump after the bug was created. I assume it failed to set some states correctly.
<ubot2> Launchpad bug 1130111 in Kernel Development Workflow "linux: 3.8.0-6.14 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1130111
<herton> rtg, ack, do you have the trace
<herton> ?
<rtg> oh right, like I'd do something smart like that.
<herton> the bug looks ok, though since I changed create-release-tracker last week probably introduced a bug with it
<rtg> herton, I'll be smarter about it next time. I frequently use 'screen' which is lousy at allowing to scroll back (and it was a lot of stack dump output)
<herton> rtg, np, I'll try to reproduce
<rtg> herton, I was on Precise at the time
<herton> rtg, just noted that bug is pointing at the wrong kernel version. I guess create-release-tracker was running at some point before the version was ok at the changelog
<rtg> herton, I thought I updated the description. refresh ?
<herton> rtg, indeed :)
<cking> rtg, I've kicked off a clean smatch run, will take a few hours to complete
<rtg> cking, ack. thanks
<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 February 26th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
 * ppisati goes to get some food, brb
<bjf> doanac, once you file the bug for the power testing system, post the bug number back here please
<doanac> bjf: will do,
<rtg> lool, uploaded linux-nexus7_3.1.10-9.27, rebased on android-tegra3-grouper-3.1-jb-mr1.1. tests looked OK
<lool> rtg: \o/
<lool> rtg: thanks
<lool> ogra_: ^
<ogra_> yay
 * rtg -> lunch
<ogasawara> rtg: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1026831
<ubot2> Ubuntu bug 1026831 in debian-installer (Ubuntu Precise) "Seed the correct Q LTS backport kernel meta package in the 12.04.2 point release" [High,Fix released]
<rtg> ogasawara, https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1026831/comments/2
<ubot2> Ubuntu bug 1026831 in debian-installer (Ubuntu Precise) "Seed the correct Q LTS backport kernel meta package in the 12.04.2 point release" [High,Fix released]
 * rtg -> EOD
#ubuntu-kernel 2013-02-20
<ppisati> moin
<apw> moin
<odinsbane> I tried out the 3.8 kernel, and I cannot build the compat-drivers package anymore. 
<odinsbane> I'm not sure a good place to get help with that.
<apw> smb, did i ask you about 'CONFIG_ARM_CHARLCD-yy------
<apw> no not that thank you unity
<smb> heh
<smb> no
<apw> smb, CONFIG_MULTICORE_RAID456 
<smb> apw, that neither
 * smb looks
<smb> apw, OK, probably mostly performance and experimental... rather would tend to =n
<apw> smb, ack thanks
<zequence-s> I'm still a bit unsure of how much the mobile/ARM version of Ubuntu will be different from the desktop release, but I'm assuming the repo will be the same deal? A lot of people will be interested in the possibility of using the Ubuntu phone for multimedia, and some specifically for low latency audio, so I would be interested in adding a special kernel for that. 
<zequence-s> Anything stopping making -lowlatency available for the phones and tablets?
<amitk> zequence-s: only the fact that most such devices might be ARM-powered, so you'll need -lowlatency versions of specific SoC kernels
<rtg> zequence-s, the kernels for mobile devices will almost certainly be different versions and in different repos then the desktop/server kernel.
<rtg> much like the Nexus7
<zequence-s> amitk, -lowlatency is currently based on -generic (really the same kernel, just differently configured). I actually don't know how the ARM kernel performs for audio, so it could be it's ok, but if not, I'd just tweak the config and create a -lowlatency flavor of it
<zequence-s> rtg, There won't be any weird restrictions on those machines, so that anything is possible, like building your own kernel on the machine itself, or adding a PPA for it (maybe not exactly a kernel question)?
<rtg> well, building the kernel on the device itself could be quite painfully slow
<rtg> I've been using an armhf qemu chroot to build test kernels.
<zequence-s> apw, both lowlatency's ready to be pulled
<apw> zequence-s, ta
 * ppisati loves strawberries
<directhex> i have a user with a lenovo l420 laptop, running a -generic-pae kernel (the hardware wouldn't boot with a 64-bit kernel). i'm seeing a bizarre setup where the -36- kernel is fine, but the -38- kernel renders the laptop totally unresponsive - jerky mouse in X, keyboard keys being missed in VT1, and so on
<directhex> are there any changes between -36- and -38- which could somehow be related? i'm stumped
<RZAFC> anyone know how to get metaspoit on a ppc with lubuntu?
<apw> directhex, not heard of it, the changes are tagged in git so you can look and see
<apw> exactly what was changed
 * rtg notes we have a chromebook kernel in raring
<apw> we do ?
<rtg> apw, just uploaded: linux-chromebook
 * ogasawara back in 20
 * ppisati goes for some sweating
<rtg> apw, ogasawara: ok, rather then create a new repo I've opened a branch (unstable-3.9) in the raring repo that builds for amd64/i386.
<apw> rtg, ack
 * rtg -> lunch
<infinity> ppisati: Are the ti-omap4 SRU rebases in progress?  This one's a bit more urgent than most.
<ppisati> infinity: not really
<ppisati> infinity: i'm a bit lost with SRU schedule these days
 * rtg -> EOD
<bjf> ppisati, this is a high priority CVE that is making it's way through
<bjf> ppisati, this is outside the normal kernel SRU cadence
<ppisati> bjf: yep, infinity told me that
<ppisati> doing the rebases now
<ppisati> herton: are you still there?
<ppisati> herton: recall me, what do i need to change the "Upload to ppa" to... "confirmed"?
<ppisati> infinity: bjf: P and Q are done, doing O now
<bjf> ppisati, thanks
<infinity> \o/
<herton> ppisati, yes, but just the comment is enough too, I'll take a look
<ppisati> and O done too.
<ppisati> herton: ^
<herton> ppisati, ack, I'm working on uploading them
<ppisati> ok
 * ppisati is here around...
<apw> herton, i have uploaded lowlatency for P & Q
<herton> apw, ack
#ubuntu-kernel 2013-02-21
<smb> morning
<Laney> Can someone make sense of this please: http://paste.ubuntu.com/1698083/ http://paste.ubuntu.com/1698110/ - the second assert is failing in chroots for me but not on bare metal?!
<Laney> for completeness here is a correct one http://paste.ubuntu.com/1698116/
<Laney> ah, nm, was a root/non-root thing
<apw> Laney, heh :)
<Laney> that's the kind of thing that seems distressing when you don't realise what's going on
<Laney> that or a cool bug
<apw> :) yeah
<apw> rtg, ogasawara, what should our default policy be for 'experimental' device drivers for scsi/ata disk drivers
<rtg> apw, in mainline ?
<apw> rtg, in raring and going forward
<rtg> isn't experimental slowly going away ?
<apw> rtg, EXPERIMENTAL as a config option is gone yes, but drivers still are marked (EXPERIMENTAL)
<einonm> rtg: IT's been removed in the latest kernel 
<rtg> apw, enable them as M if possible (I guess)
<apw> einonm, only the confi option
<apw> rtg, i was thinking the same, and indeed that is what we have been doing due to a bug :)
<ogasawara> apw: heh, I'd say module as well
<einonm> apw: ah, ok. Each driver should have it's own explanation of why it's experimental, iirc
<doanac> bjf: WRT bug #1092924, we had desktop ISO's cached back to 2012-12-03. I saw the stack trace on all of them
<ubot2> Launchpad bug 1092924 in UTAH "Cobbler install of recent raring-desktop images failing" [High,Triaged] https://launchpad.net/bugs/1092924
<bjf> doanac, well, that's not good
<doanac> i was told UTAH has a way to take an ISO but use your own kernel.
<doanac> so I was thinking about trying to bisect that way.
<doanac> do you have a convenient place for me to get some old kernels?
<bjf> doanac, we need to find a good kernel (if there is one)
<bjf> doanac, https://launchpad.net/ubuntu/raring/+source/linux
<doanac> bjf: thanks, I'll try and sift through this today
<bjf> doanac, did you ever open another bug for the power-testing HW (you said it was having the same issue)
<bjf> doanac, and do you use this same method for provisioning any other systems?
<doanac> bjf: no. i wanted to get further on this. I think they are the same problem
 * ogasawara back in 20
<ppisati> brb
<rtg> apw, hmm, looks like aufs will need the usual TLC sometime before 3.9-rc1 is released. Even though the rebase against linux-next was successful, I still ran into compile issues. dm-raid45 as well.
<apw> rtg, ack will look into it tommorrow, see if there are any updates pending
 * rtg -> lunch
<infinity> zequence: Want to do something about verification-testing on those lowlatency SRUs?
<zequence> infinity: Ah, sorry. Will do right away
<infinity> zequence: Many thanks.
<infinity> zequence: I plan to release the world this afternoon (ie: in a couple of hours), so some verification that your rebases/builds aren't complete duds would be swell. ;)
<zequence> infinity: All done
 * henrix -> EOD
<infinity> zequence: Many thanks.
<zequence> infinity: Thank you in return :)
<infinity> bjf: You know what I'm going to ask, so I won't bother asking.
<bjf> infinity, slapping the bot boss
<infinity> bjf: If you just smack it over and over until everything on workflow appears to be waiting on me, that would be lovely.
<rtg> jsalisbury, rebooting gomeisa for kernel update
<jsalisbury> rtg, ack
<rtg> jsalisbury, its already back
<jsalisbury> rtg, ok to use again?
<rtg> yep
<jsalisbury> cool, thanks
<rtg> jsalisbury, rebooting tangerine for kernel update
<jsalisbury> rtg, ack
<jsalisbury> cd linux-stable
<bjf> infinity, the bot has done what i can at this point
<jsalisbury> whoops :-/
<herton> bjf, infinity, the bot doesn't go forward if you set regression-testing to invalid, I'm testing a quick fix now
<bjf> herton, doh!
<herton> bjf, it was assumet QA would always be done :)
<herton> *assumed
<bjf> i think i remember that now that you mention it
<infinity> Yeah, which explains why some of them haven't progressed.  Oops.
<infinity> I mean, I'm happy to start doing all the releases manually anyway.  I was just hoping the paperwork would be in order.
 * rtg -> EOD
<herton> bjf, infinity, pushed a fix to the bot
<infinity> herton: Any chance that we can make http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html go all orange with tasks for me, then?
<bjf> infinity, i'm slapping both the bot and the report generator
<infinity> You're really making me want to re-watch I Love You, Man.
<bjf> infinity, i *think* you are all orange though the report generator is spewing chunks
<infinity> I don't look all orange (see the ti-omap4 at the bottom)
<infinity> But the bug is accurate, so that's fine.  Screw the report.
<bjf> that's what i was sayin
 * infinity nods.
#ubuntu-kernel 2013-02-22
<infinity> zequence: You got the bug closure syntax wrong in your lowlatency upload to precise, BTW.
<infinity> zequence: Needs to be "LP: #1234" not "LP:#1234"
<ubot2`> Launchpad bug 1234 in Launchpad itself "Gina is an unmaintainable mess of command line options, environment variables and shell scripts" [Medium,Fix released] https://launchpad.net/bugs/1234
<infinity> zequence: (Closing the bug manually this time)
<infinity> smb`: And you just completely missed having the right tracking bug in the linux-ec2 upload. :)
<Kano> hi, what was the reason to switch CONFIG_SATA_AHCI=y to CONFIG_SATA_AHCI=m?
<Kano> with =m the kernel alone of course does not boot with efibootmgr, initrd is required which is slower
<Kano> switched from 3.8 rc6 to rc7
<infinity> Kano: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1056563
<ubot2`> Ubuntu bug 1056563 in linux (Ubuntu) "Please change AHCI driver back to module in 12.10" [Medium,Fix released]
<infinity> Kano: In short, it can conflict with other modules, so builtin is the wrong answer for a generic kernel.
<Kano> why is that raid ahci not mainline
<Kano> that would be the correct answer
<Kano> http://kanotix.com/files/dragonfire/linux-3.8.0-6.13kanotix1/0001-Bluetooth-Add-support-for-AR3012-0489-e04e.patch
<Kano> that should be added as well. if you want signed it and push to mainine
<Kano> did you add that to your kernel?
<Kano> http://kanotix.com/files/dragonfire/linux-3.8.0-6.13kanotix1/media-cx18-ivtv-fix-regression-remove-__init-from-a-non-init-function.patch
<Kano> without you can not boot 3.8 with ivtv or cx18 card installed
<infinity> Kano: There's a mailing list for your patches.
<Kano> i hate mailinglists, btw. the 2nd is from one
<Kano> it is not my patch only the first
<infinity> s/patches/pull requests/
<Kano> http://patchwork.linuxtv.org/patch/16734/
<Kano> that patch is critical
<Kano> so you see, it was on the list and was not added
<ohsix> "i hate the thing everyone uses to do this, but i insist on doing this"
<infinity> Kano: Fine.  Can you mail a pull request to kernel-team@?  Thanks.
<Kano> well you can tell your users to use kanotix instead too, there it is fixed ;)
<Kano> bye
<ohsix> somehow that's a reasonable thing to do, but not for the reason he stated :d
<zequence> infinity: Sorry, and thanks
<ppisati> moin
<smb> infinity, meh.... :-P
<smb> morning
<ppisati> smb: moin
<apw> moin
<apw> infinity, bah i missed that too
 * apw self flagilates, and it is far too early for such things
<smb> apw, isn't it also too early to start punching oneself
<apw> i am not very accurate at this time of day for sure
<apw> ppisati, there was some resaon we had CONFIG_CPU_FREQ turned off for omap wasn't there
<ppisati> apw: yes, upstream is missing some pieces for omap4
<apw> ppisati, sweet
<ppisati> apw: if we turn if on, it crashses on boot
<apw> ppisati, now that is a good reason indeed
<ppisati> apw: there should be a link to the upstream discussion about it in the config change that i sent
<apw> ppisati, no that is enough info, i trust your judgement on these things.  i am annotating it so the config checker doesn't try and turn it back on
<ppisati> apw: ack
<apw> ppisati, CONFIG_IMX_SDMA and CONFIG_IMX_DMA are off for -omap, are they not useful for imx ?
<ppisati> apw: probably not fr the board that we support, but letme check
<apw> ppisati, thanks
 * ppisati is eating strawberries.. and he loves it... :)
<aissen> Any idea why why tigon and bnx2x were removed from linux-firmware in 1.88 ?
<apw> aissen, have you checked the changelog ?
<apw> aissen, and in which release are you talking abuot ?
<aissen> I checked the changelog, it says: "Remove boot essential duplicated firmware files that are also carried in the linux-image package."
<aissen> the release is quantal but it carried over raring.
<apw> aissen, ahh there you go, so we think it is in linux
<aissen> Is it to save some space then ?
<apw> aissen, yeah there is no point in having two copies on the system for sure
<apw> now if we have ended up with zero copies that is broken
<aissen> yeah, I would have removed the copy in linux-image; but maybe there's something I don't understand. Is linux-image used in places where linux-firmware isn't ? (network boot?)
<apw> aissen, i suspect so indeed
<aissen> that's what I thought but I wanted input from someone who knew the rationale.
<apw> rtg would have done the changes, he has been on a mission for firware upstream and in ubuntu, trying to rationlise it all
<aissen> yeah, first thing I noticed is that rtg wasn't here. I'll wait till he comes back
<ppisati> apw: right, IMX_SDMA and IMX_DMA are all for boards that we don't support (imx 31/35/51/53 and imx 21/27)
<ppisati> apw: actually support for those boards is all upstream, so if anyone has the hw we could easily add support for it
<apw> ppisati, but for now off makes sense ?
<ppisati> apw: yep
<ogra_> oh, a fix for adhoc wifi support on the nexus7 https://launchpadlibrarian.net/132034143/linux-nexus7_3.1.10-9.27-adhoc.patch
<ogra_> (thats bug 1077704 )
<ubot2`> Launchpad bug 1077704 in ubuntu-nexus7 "Can't connect to ad-hoc wifi networks" [Medium,Confirmed] https://launchpad.net/bugs/1077704
<apw> ppisati, CONFIG_HWSPINLOCK_OMAP is off in -omap, is that deliberate
<apw> ppisati, CONFIG_KEYBOARD_IMX is off in -omap ... what about that one
<ppisati> apw: HWSPINLOCK_OMAP seems omap4-only, i'll have to check it
<ppisati> apw: KEYBOARD_IMX can be compiled as a module
<apw> ppisati, it may be that the first one is not possible when you have a generic thing going on indeed.  thanks for investigating
<apw> ppisati, K_IMX ack
<ppisati> apw: i'll give the first option a try
<apw> ppisati, CONFIG_MTD_NAND_MXC on -omap ?
<apw> ONFIG_MMC_MXC too
<ppisati> apw: /me checking
<ppisati> apw: MMC_MXC is !imx6 (our board)
<apw> ppisati, ack will leave it be then
<ppisati> apw: apw same for MTD_NAND_MXC (is for the imx31)
<apw> ppisati, ack ta
<apw> ppisati, CONFIG_PWM_IMX ?
<ppisati> apw: =m?
<apw> ppisati, will do 
<cnf> hi. I'm trying to compile some 3rd party kernel modules for packaging in a .deb however, my kernel modules won't load on any system it wasn't compiled on
<cnf> i'm compiling against the same ubuntu stock kernel (3.2.0-29-generic)
<apw> cnf, if you are able to distribute the source, then you might want to be using dkms
<cnf> apw: i don't want compilers on all the servers
<apw> cnf, well as we build LBM that exact same way it should work as far as i know
<apw> cnf, what happens when you try to load them
<cnf> eb 22 11:46:38 62-213-199-42 kernel: [ 2652.522284] saa716x_core: disagrees about version of symbol dvb_frontend_detach
<cnf> Feb 22 11:46:38 62-213-199-42 kernel: [ 2652.522288] saa716x_core: Unknown symbol dvb_frontend_detach (err -22)
<cnf> times a lot :P
<apw> cnf, and you are absolutly sure it was the same version of the kernel, and the very same compiler version as built the kernel
<apw> cnf, and you are sure you used the right .config
<cnf> apw: i'm building in a vm, if i delete de vm right after compilation, and reinstall the same kernel
<cnf> it fails
<cnf> if i load them right after i compiled them, it works
<cnf> both with linux-image-3.2.0-29-generic
<cnf> maybe i'm doing something wrong, or missing something, but i can not figure out what
<cnf> apw: and the .config in the kernel source tree is identical to the one in /boot/ for the running kernel
<apw> cnf, and if you reboot the original VM and try installing them again does that work
<apw> as that should be equivalent to your delete and recreate VM
<apw> in theory as the bits should be the same
<cnf> apw: yeah, i can reboot the vm, and reinstall the .deb
<cnf> works fine
<cnf> wipe the vm, bring it up again (vagrant), install kernel image and my package
<cnf> no go
<cnf> i'm sure i'm doing something stupid, but what :/
<apw> cnf, i struggle to see how that could not work, as otherwise we could not ship lbm
<apw> cnf, what release
<cnf> apw: of?
<apw> ubuntu
<cnf> oh,
<cnf> Ubuntu 12.04 LTS
<cnf> (target is 12.04.1, but i'm ignoring that one for now)
<apw> cnf, can i have a full dmesg from a failure please
<cnf> sure, hold on
<cnf> http://pastie.org/6316122
<cnf> apw: i could even share the vagrant project, if you have ny use for it
<apw> cnf, can i get the whole dmesg from the top pls
<apw> cnf, and a cat /proc/version and a gcc -v from the system failing to load them
<cnf> apw: how far back? that is everything related to the loading
<apw> cnf, i want to see the top mostly but you never know what clues are in there
<cnf> (and there is no gcc on the systems failing to load)
<apw> cnf, point, actually i want it from the one building it when it is building it really don't i
<cnf> http://pastie.org/6316165
<cnf> Linux version 3.2.0-29-generic (buildd@allspice) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012
<cnf> let me rebuild the builder
<cnf> (takes a few minutes)
<cnf> and http://pastie.org/6316179 for gcc version
<apw> cnf, get me a /proc/version and well as gcc -v off that one
<cnf> it's not running the kernel i compile for
<cnf> but Linux version 3.2.0-23-generic (buildd@crested) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu4) ) #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 on the builder
<apw> cnf, does it have the headers for the one you are compiling for installed ?
<cnf> (i install the right headers and image for the kernel i _do_ compile for, obviously)
<apw> cnf, but then it would not be possible to load them on the builder
<apw> cnf, and you say that _does_ work ?  which it shouldn't
<cnf> sure, but i reboot to test that :P
<cnf> the builder installes the linux-headers and linux-image of the target kernel specified
<cnf> automatically
<cnf> if i reboot to test (so it runs the right kernel)
<cnf> then it does work
<apw> builds against them, then you reboot it and load them
<cnf> yep
<cnf> so _building_ is done on another kernel, but after a reboot to the right kernel, it works
<apw> ok can we do that next, reboot it, and get me /proc/version and the dmesg shen they do load
<apw> when
<cnf> yep
<cnf> i do this, btw, so i can automate my package building, and just speficy what the target kernel is in my config
<apw> yes that makes sense indeed
<apw> and we build all our stuff in a similar way, in a chroot for the release
<cnf> uhu
<apw> with the wrong kernel running, so it should just work as it works for us
<cnf> ok, package is build
<cnf> let me reboot the vm
<apw> but there must be something different between the two somewhere
<cnf> yeah...
<apw> can we keep this vm rebooted in the working and loads state
<apw> and get the saame exact .ko copied to one you made fresh
<cnf> sorry?
<apw> and confirm 1) it doesn't load
<apw> can we keep the builder VM in the testing state, so on the right kernel with the module proven loaded
<apw> and at the saem time make a consumer VM and pull the .ko off the
<apw> builder VM and hand put it on the other VM
<apw> and see if that loads
<apw> if it does, we know it is a 'copying' issue when making the .deb to carry it
<cnf> sure
<apw> if it does not we know it is somehow a differnece in the two VMs
<cnf> though i did md5sum some of the modules
<apw> and perhaps with both running we can find it
<cnf> but i'll try it none the less
<apw> sensible indeed
<apw> as it seems impossible as stated of course
<cnf> it's a bit of juggling though, because this is vagrant
<apw> so it must be subtle
<cnf> as soon as i reboot, my setup breaks
<cnf> (no more vbox modules, so no more shared folders etc)
<cnf> also, it's not just one .ko, it's a mess of modules ^^;
<apw> cnf, well i mostly only care about the one which fails first :)
<cnf> :P
<cnf> setting up the 2nd vm
<cnf> it's installing the right kernel now
<apw> one thing i would like to know is that md5sum /boot/vmlinuz-`uname -r` sort of thing really matches on the working and not working ones
<cnf> ok
<apw> i am sure it will but ... never hurts to test the basicxs
<cnf> i'm gonna take some snapshots, so i can revert a bit faster :P
<apw> plan indeed
<apw> VMs have their uses
<cnf> indeed
<cnf> ok, 2nd vm is up
<cnf> so _not_ install the package, you said?
<apw> well i am happy if you use the package, if we compare them md5sum with the ones you loaded successfully on the rebooted builder
<cnf> ok
<apw> i want to know they are bit for bit the same
<apw> i would like to see lsmod on the builder against lsmod when it fails to load as well
<cnf> ok
<cnf> (faling at scp atm ^^;)
<cnf> there we go ^^;
<cnf> http://pastie.org/6316289 success
<cnf> http://pastie.org/6316299 fail
<cnf> apw: see those tbs6??? modules?
<cnf> those are part of my package...
<apw> WARNING: Error inserting rc_core (/lib/modules/3.2.0-29-generic/kernel/drivers/media/rc/rc-core.ko): Invalid argument
<apw> but that one not ?
<cnf> no, i don't think it is part of my package
<apw> and they are auto loading on the test system?  or do you have the modprobe command
<cnf> nope, it isn't
<cnf> autoload
<cnf> sorry
<cnf> sec
<cnf> modprobe saa716x_tbs_dvb
<cnf> is what i run
<cnf> on either system
<apw> and got no output when it worked ?
<cnf> apw: exactly
<apw> ok note rc_core is loaded on the working system
<apw> so modprove rc_core on the broken one
<apw> modprobe even ...
<apw> what does that say, and does it say anything in dmesg for it
<cnf> # modprobe rc_core
<cnf> root@precise64:~# lsmod |grep rc_core
<cnf> rc_core                26412  7 ir_lirc_codec,ir_mce_kbd_decoder,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_rc5_decoder,ir_nec_decoder
<apw> now try probing your module 
<cnf> on the broken system
<cnf> WARNING: Error inserting rc_core (/lib/modules/3.2.0-29-generic/kernel/drivers/media/rc/rc-core.ko): Invalid argument
<cnf> (and the same following lines)
<apw> ?
<cnf> http://pastie.org/6316322
<apw> lsmod | grep rc_core works on the broken system
<cnf> yes
<apw> but modprobe of your module still triggers an error loading it ?
<cnf> yes
<apw> i find that hard to believe
<apw> and it wasn't probed in the lsmod you pasted originally
<apw> can i have a new lsmod off it
<apw> somethign really screwey is going on, or we are not understanding each other
<cnf> http://pastie.org/6316329
<cnf> yeah
<cnf> hmm
<cnf> ok, rc-core has a different md5sum on both system
<cnf> o,O
<apw> cnf, !?!
<apw> well that would cirtainly not be right
<cnf> indeed
<cnf> damned screwey 3rd party software :/
<apw> was it wrong before you installed your package
<apw> yeah you have to hate it
<cnf> apw: it's part of the default system
<cnf> so i didn't touch it with my package
<apw> so which one is wrong
<cnf> but aparently, this driver package recompiles rc-core.ko
<cnf> and i guess depends on the changed version?
<apw> ouch
<apw> so you need to bring that too i assume
<apw> vile vile vile vile
<cnf> hmm, i guess
<apw> well easy to test, scp it over
<apw> rmmod it, and try again
<cnf> but _can_ i even overwrite existing files managed by a different package?
<apw> then send hatemail to someone :)
<cnf> with a .deb?
<apw> cnf, with difficulty
<apw> cnf, though in this case you can put it in /lib/modules/<version>/update/<path> as well
<apw> and that takes precident over the 'real' one
<cnf> aha?
<cnf> oh, shiny!
<cnf> ok, lets start the scping
<apw> or is it updates, anyhow it should exist whatever it is called
<apw> that is where dkms makes its mess as well
<cnf> hehe
<ppisati> apw: do you have native ipv6 or you use a tunnel?
<cnf> apw: thank you for your help so far
<apw> ppisati, an HE tunnel, the uk isn't very advanced in ipv6 land
<cnf> apw: i'm gonna give my brain a small break, and hack on this a bit
<ppisati> apw: ok
<cnf> apw: i'll probably be back in a bit :P but you have been a great help so far!
<cnf> apw: oh, should the path under updates mirror the path under kernel?
<apw> cnf, i think it doesn't matter as it is found by depmod
<cnf> aha, ok
<apw> cnf, but i would probabally make it so
<cnf> right :P
<cnf> hmz
<cnf> apw: ok, same error
<apw> did you rmmod rc-core
<apw> and modprobe it again ?
<apw> and did you run depmod? to pick up the new one
<cnf> i did a rollback
<cnf> and ERROR: Module rc_core does not exist in /proc/modules
<cnf> on an rmmod
<cnf> and yeah, my package runs depmod -a on install
<cnf> i think you got it right when you used the word "vile" :P
<cnf> hmm
<cnf> apw: the _new_ rc-core module loads on the new system, but gives similar "disagrees about version of symbol" messages in dmesg
<cnf> so i am going to go out on a limb, and say they did the same thing to a bunch of other modules...
<apw> bah
<cnf> yeah :/
<apw> md5sum is your friend
<cnf> so i guess i'll be writing a script that does a find and a md5sum on everything
<cnf> and compares before and aftyer
 * cnf facepalms
<cnf> apw: they are actually recompiling the rc-*.ko drivers for _other_ cards as well
<apw> cnf, i think you should send that s/w back with a brick attached
<cnf> apw: considering it
<cnf> apw: and herpes
<apw> a good combination
<cnf> isn't it :P
<cnf> apw: normally if one where to write kernel modules
<cnf> how would you make it easy for packagers?
<cnf> something like --prefix or $DESTDIR, no?
<apw> not changing existing ones, using the prefixes we have for updates, or make new names
<apw> really they should make new names
<cnf> uhu
<apw> as they are recompiling all of rc-* becaure they are renaming rc-core
<apw> cause they are rebuilding rc-core
<apw> they should be making a copy and calling it my-rc-core to avoid all this
<cnf> indeed :/
<cnf> i did a `find . -exec md5sum {} \; > file` pre and post
<cnf> the nr "recompiled" modules is appalling!
<cnf> totally unrelated modules have different sums
<apw> probabally dependancies of those other ones
<apw> or ones which use them
<cnf> yeah, indeed
<apw> which is doubly why one should not do this
<cnf> yeah!
<apw> or one should just apply the patches to our source and build your own kernel
<cnf> i'm not a C coder (doing learn C the hard way atm :P ) but _i_ know this, damnit >,<
<apw> as you are not runnign our kernel, and nothing about your kernel should call itself the version we shipped
<apw> that is just confusing ... 
<apw> hello choir
<cnf> yeah :P
<ppisati> brb
<cnf> i'm going home, thanks again apw !
<cnf> \o
<apw> BenC, yo .. do you have a v3.8 rebase in the works.  i am working on the configuration updates for master, and want to do teh same for ppc, but you are 'behind'
<BenC> apw: I'll push out a rebase real quick and pull your changes before uploading
<apw> cool
<BenC> apw: should I rebase against master or master-next?
<apw> i would rebase whever you normally do i guess, master, as the changes are outside the tree for ppc
<apw> BenC, it may make sense to rebase and upload a v3.8 rebase to match master
<BenC> apw: normally I rebase against the latest tag
<apw> then we isolate any breakage from v3.8 against any breakage from teh config changes
<apw> our config changes are separate to the v3.8 final rebase as well
<apw> i can then do the config changes against your tag and it will be all nice and claen
<apw> BenC, ^
<BenC> apw: my ppc branch is pushed and synced to ubuntu/master
<apw> sweet
<BenC> apw: Thanks
 * ogasawara back in 20
<apw> ogasawara, just pushed the result of the full by-menu config-review for v3.8 final
<apw> (it even builds)
<ppisati> apw: is your panda alive? if i provide you with a kernel in ~20mins can you give it a spin?
<apw> ppisati, if this board is a panda, i think it is alive
<ppisati> apw: got a patch from rmk about the align/ipv6 problem we had, and i can't reproduce the BUG() here
<ppisati> apw: i mean, after i applied the patch i can't reproduce it anymore
<ppisati> apw: sounds like it fixes it
<apw> ppisati, sweet, it seemed to kill my machine in the face on a regular basis
<apw> so i should know just by leaving it on
<ppisati> apw: right
 * ppisati is building a test kernel
<apw> great
<ppisati> apw: check it out - http://people.canonical.com/~ppisati/linux-image-3.8.0-7-omap_3.8.0-7.15~ipv6align_armhf.deb
<apw> ppisati, ack
<smoser> smb, apw thank you for your console/ttyS0 help.
<sforshee> ogasawara, rtg, apw: there's a message on ubuntu-devel about proprietary drivers failing to install due to not having the kernel headers, and I've been working a bug that looks to be the same issue. Shouldn't dkms have a dependency on linux-headers-generic?
<sforshee> (note that it doesn't, at least not in raring)
<apw> sforshee, nope, because you should have linux-foo installed which gives you the right ones
<apw> sforshee, and depending on one just means you have the wrong ones for your kernel force installed when you install dkms and things still don't work
<smb> smoser, welcome. lets see whether we can find a working way
<infinity> sforshee: Are these 12.10 users?
<sforshee> infinity, yes for the ones I'm aware of
<apw> sforshee, ie you are using linux-image-generic-pae but have no headers, you install dkms, that has a dep of 'linnux-headers-generic | linux-headers-generic-pae' that installs the first one, which is useless and you don't get anywhere
<apw> sforshee, upgrades or fresh installs
<infinity> sforshee: 12.10 has a bug where the installer removes the headers (and the metapackage) at the end of the install.
<apw> heh that would do it
<sforshee> infinity, ah. Yes, the bug I'm looking at seems to be a fresh install
<infinity> sforshee: Other than doing a point release of 12.10, I'm not sure how best to resolve that.  And that still won't get old installs the metapackage back.
<infinity> sforshee: tseliot was working on a fix to jockey/drivers-common that would try to ensure the right metapackages were installed.  Not sure if that's made it in.
<sforshee> infinity, makes sense
<sforshee> apw, thanks for the explanation, I wasn't thinking about pae being a separate metapackage
<infinity> tseliot: ^
<infinity> sforshee: Well, not just -pae, but the ARM variants, etc.
<sforshee> right
<apw> it is the inability of the dkms dependancies to make a sensible decision that is the real issue
<tseliot> infinity: that would be bug #1123107 and my packages are waiting for approval
<ubot2`> Launchpad bug 1123107 in jockey (Ubuntu) "Jockey should install the linux-$flavour metapackage" [High,Fix committed] https://launchpad.net/bugs/1123107
<infinity> tseliot: I don't see any Q tasks for that.
<infinity> tseliot: Which is where most of the affected users are.
<tseliot> infinity: if that's desirable, I can backport it from raring to quantal. I think precise has the highest priority though
<infinity> tseliot: Sure, precise is more important for a variety of reasons, it's just that Q had the unfortunate installer bug that means many/most amd64 users don't have any headers installed by default (oops).
<tseliot> infinity: oh, I wasn't aware of this
<infinity> tseliot: Was a slightly overzealously greedy glob when removing linux-signed (for non-SB systems), if I recall, that led to a few more packages than intended being removed at the end of the install. :/
<tseliot> ouch
<infinity> Or something along those lines.  I forget the exact bug now, just the symptom.
<apw> BenC, i have just pushed a startnewrelease pile onto that ppc branch for you, if i push the config changes are you able to reset them off if they don't work for you?
<BenC> apw: yes
<BenC> apw: when will ubuntu/master be uploaded?
<apw> then that sounds like a plan, it'll be there shortly
<apw> BenC, actuall the v3.8 final -7 has already been pushed, perhaps we should upload that as is
<BenC> apw: is master still the same as the -7 tag?
<infinity> Eh, why waste build resources, if there's another one in the pipe?
<apw> BenC, and then i'll do the confi changes relative to it separatly, to keep the two changes easy to test
<BenC> Right
<apw> diagnosability agasist build resources indeed
<apw> BenC, so whats uploaded was the clean rebase, ie -7, i'll see about getting this config update uploaded soon i think
<BenC> Ok, I'll hold out for that upload
<apw> ogasawara, what do you think about me uploading this config change today
<BenC> Nothing in the rebase or config is critical to ppc right now, other than making it match ubuntu/master
<ogasawara> apw: works for me
<apw> BenC, reasonable
 * ppisati goes for some sweating
<ppisati> later
 * apw idly wonders if pp understands just how that sounds ...
<ogra_> heh
<ogra_> i was wondering the same a few days ago 
<infinity> apw: Who doesn't enjoy some good sweating?
<neoshades> Hi Just joined to ask a question - What complier is used to create mainline kernel 3.7.9-raring?
<infinity> neoshades: If you're running the kernel, /proc/version will tell you which compiler was used.
<apw> neoshades, we may record that too
<neoshades> I tried but could not get gnome to run as nvidia drivers 3.10.32 to create dkms module as it complained about the compiler version 
 * infinity wonders idly why the GCC version string has a trailing space...
<neoshades> I am running 3.7.5-030705-generic at moment and have managed to install 3.10.32 nvidia - /proc/version shows it was compiled with gcc 4.6.3 but installed vrsion is gcc (Ubuntu/Linaro 4.7.2-2ubuntu1 
<neoshades> damm yo many chars
<neoshades> am running 3.7.5-030705-generic with nvidia 3.10.32 ok
<neoshades> 3.7.9 won't compile with nvidia 3.10.32 for dkms
<infinity> So, you might need to either install gcc-4.6 and export CC=gcc-4.6, or convince your binary driver build that compiler versions don't matter.
<apw> neoshades, pretty much that is very likely
<apw> neoshades, what release are you running it on?
<neoshades> why is mainline using gcc 4.6.3 instead of 4.7.2?
<apw> so that was built pre the change to 4.7
<apw> neoshades, it is using the default compiler when it was built
<apw> they are meant for testing only and we don't expect binary driver to work with them
<apw> that is the way of the world
<infinity> apw: From his GCC version, I assume he's running quantal.
<neoshades> yes quantal originally
<neoshades> mainline build downloaded from site http://kernel.ubuntu.com/~kernel-ppa/mainline/
<apw> yes those are the ones, they are pretty much guarenteed to not work with binary drivers cause of the compiler skew
<neoshades> compiler skew?
<apw> the compiler on teh system not matching that they are built with
<infinity> The thing you were just complaining about...
<apw> as they are not built with the compiler for your system, but the one for precise
<apw> to allow maximal use of the kernel across versions to allow baseline testing
<infinity> neoshades: Is there a reason you need to be running mainline kernels?
<neoshades> that's what I thought but I suppose I assumed that mainline builds would be using latest gcc
<infinity> neoshades: The packaged kernels in the archive are, generally, a much better idea for most people.
<neoshades> no reason apart from testing
<apw> neoshades, well if they were they would be using raring's compiler, which would skew from your locla compiler anyhow
<apw> same problem
<neoshades> erm so what is raring comipler version?
<sforshee> apw, you have a machine with BCM4313 wireless don't you?
<apw> sforshee, it has brcm something yes
<infinity> raring's compiler is 4.7.2, shouldn't cause too many issues with quantal.
<infinity> (And, in fact, a raring kernel package installed on Q should behave just fine)
<apw> 02:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (rev 01)
<sforshee> apw, someone is complaining about brcmsmac with BCM4313 so if you had that hardware I wondered how well it's working for you
<apw> sforshee, ^^
<apw> sforshee, its the normal pile of shit all brcm drivers are, expect to rmmod modprobe it at least daily
<apw> its been much better since your last fixes, but not perfect
<sforshee> huh, okay
<apw> but given it is brcm, its purfect
<apw> and given i run full ipv6, and i have to nail network-manager and nm-applet about as often
<sforshee> I rarely have problems with by BCM43224 in 3.8
<apw> i cannot be sure it is completly brcms fault
<apw> can you tell i am bitter about it
<apw> broadcom please sort out your drivers
<neoshades> but as ubuntu now install 3.7.2 on quantal why are mainline not built with such - no worries will compile my own from git
<apw> and no shipping random source on your website does not fit the definition of 'sort out'
<apw> neoshades, it is built in a precise environment to let us use them on the LTS and later
<sforshee> I think broadcom generally cares more about the fullmac drivers because that's what android devices use ...
<apw> the only downside is that binary drivers do not work, and frankly we don't care about them
<apw> sforshee, and therefore they should not make devices for anything else
<apw> sforshee, or they shoudl sort out something useful
<apw> either or, don't care
<apw> just don't make me live with their lazyness
<sforshee> maybe I need to try and get my hands on a BCM4313 card
<apw> i should try swapping my pcix card in this machine with something from intel
<apw> and give you the thing
<sforshee> I can get one of amazon for about $12
<sforshee> might cost you more to ship it to me ;-)
<apw> sforshee, expense it
 * henrix -> EOD
<neoshades> so what u are saying is that as gcc is updated the kernels in the archive are compiled with latest gcc
<neoshades> as per LTS
<apw> a mainline kernel is built with the nearest configuration series wise, and in the previous LTS chroot wise
<apw> to maximise what it can be installed safely on
<apw> (given it is a completly automated build and no brains are applied in their making)
<apw> neoshades, ^^
<infinity> neoshades: The mainline kernels are meant for nothing more than quick testing of "if this is broken in the distro kernel, does it work with mainline?", they're not meant for people to run.
<apw> BenC, i ahve pushed the config change and abi bump to the branch, it builds for me in a cross environment but a proper build test on something ppc would be good
#ubuntu-kernel 2013-02-23
<BenC> apw: ok, thanks
#ubuntu-kernel 2013-02-24
<AlexandreMBM> henrix_, Luis Henriques?
<AlexandreMBM> "Kernel Quantal LTS" on Ubuntu 12.04.2? Docs in the wiki?
<AlexandreMBM> https://wiki.ubuntu.com/Kernel/Dev/KernelStableSupportMatrix
<AlexandreMBM> MOre?
<AlexandreMBM> What is "Precise Meta"?
<AlexandreMBM> https://bugs.launchpad.net/ubuntu/+source/linux-lts-quantal/+bug/1068281
<ubot2> Launchpad bug 1068281 in linux-meta-lts-quantal "Quantal LTS kernel in Precise" [Undecided,Fix released]
<Daviey> niccceee. http://thread.gmane.org/gmane.linux.network/260061
<apw> Daviey, joy
<melkor> My ethernet goes away when I resume from a sleep. Dmesg says that wake-up capability disabled by ACPI.
#ubuntu-kernel 2014-02-17
<smb> apw, yes
<ppisati> something sweet for your breakfast: http://cryptome.org/2014/02/nic-ssh-rootkit.htm
<ppisati> bottom line: fake nic firmware used to dump content of main memory
<ppisati> but he didn't stop there, and and developed a fully working sshd running on the nic's cpu
<ppisati> quite amazing if you ask me
<smb> ppisati, Unprotected remote firmware update... That is either the big conspiracy or just the usual unlimited stupidity one hears about. :-P
<ppisati> smb: after the rdrand incident, you never know
<ppisati> smb: the guy says "Well, as all research projects it evolved from using the flash update program which came with the NIC and simply feeding it my modified firmware to using more sophisticated techniques like discovering a remote update capability. The current version simply sends the appropriate packets to vulnerable cards and updates them."
<smb> Yeah. Though some are apparently better protected than others. And then there is the problem that even the same chip might not be always the same as he states later.
<ppisati> yeah, read it
 * apw yawns
<apw> (somewhat theatrically at that)
<smb> apw, WELCOME, to the next week! (sticking with the theatrically theme)
<xnox> When will fix for bug #1276739 land in -updates pocket? (as in which precise sru cadence is that in) or are there udebs that i can fetch off somewhere with that fix included?
<ubot2`> Launchpad bug 1276739 in linux (Ubuntu Precise) "partman-crypto uses xts by default, yet xts.ko kernel module is not present in 3.2 (original-point-zero stack) crypto-modules-udeb" [High,Fix committed] https://launchpad.net/bugs/1276739
<apw> xnox, that hshould be in this weeks builds, though i thin the US may be off today
<apw> xnox, ie in the archive within 3 weeks
<xnox> apw: ok, thank you.
<xnox> apw: and in -proposed pocket that would be in ~1 week time?
<xnox> (or is that straight away, after current set of -proposed kernels is released)
<apw> xnox, it'd be whenever they are built yeah, so sometime this week
<rsalveti> apw: mind updating the flo kernel with one additional patch? I publish it at http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-trusty.git;a=shortlog;h=refs/heads/flo, and also did a version bump
<rsalveti> apw: would just need it to be merged and pushed to the archive
<apw> rsalveti, ack
<rsalveti> apw: also tested kernel for manta/mako, all good, but we should keep them in the ppa still
<rsalveti> until we're done with the android 4.4 porting (close :-)
<apw> rsalveti, i presume from the messages from the archive, that you are copying them out as you feel ready yes?
<rsalveti> apw: yes
<apw> rsalveti, so i will continue to ignore them in the PPA
<rsalveti> apw: yeah, publishing them in the ppa is fine, I can copy them over once we're good
<apw> works for me (us)
<rsalveti> great
<rsalveti> apw: also published a small fix for manta: http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-trusty.git;a=shortlog;h=refs/heads/manta, so we can have a working power indicator with 4.4.2
<apw> rsalveti, flo is building in the PPA
<apw> rsalveti, ack on the manta change
<rsalveti> apw: awesome, thanks
<lfaraone> I wasn't sure whether to file a new bug; I'm experiencing similar issues to bug 1270808 , but we have different wireless chipsets, and that bug was marked incomplete. I opened a new bug, bug 1281170. Let me know if I should instead mark it as a duplicate and just add info to the first bug. 
<ubot2`> Launchpad bug 1270808 in linux (Ubuntu) "iwlwifi 0000:01:00.0: fail to flush all tx fifo queues Q 2" [Medium,Incomplete] https://launchpad.net/bugs/1270808
<ubot2`> Launchpad bug 1281170 in linux (Ubuntu) "iwlwifi 0000:03:00.0: fail to flush all tx fifo queues Q 2 on Intel Centrino Advanced-N 6205" [Undecided,New] https://launchpad.net/bugs/1281170
<xnox> i'm working on dmraid -> mdadm upgrade path.
<xnox> dmraid seems to generate funny targets e.g. /dev/mapper/isw_ebebhgdagf_Volume1p1, where as mdadm seems to just do Volume1p1 type names.
<xnox> i understand taht isw is just raid type, but i'm failing to find where ebebhgdagf is defined, all ID's returned by mdadm tools are not that =(
<TJ-> xnox: IIRC, they come from the metadata signature created by the controllers, Promise are different to Nvidia, etc.
<xnox> TJ-: hm. so i'm definately missing udev rules to (a) run kpartx against containers / mdadm raid arrays (b) setup compat symlinks to all from previous....
<apw> rsalveti, manta is building in the PPA
<rsalveti> apw: thanks
<smb> xnox, I though I had seen it somewhere in the dmraid code. Of course I probably won'T find it that quickly. But I think it was part of the meta-data the adapter write (some kind of uuid)
<xnox> smb: hm... if it's dmraid custom algo, then i don't want to use it. If it is something that i can also access elsehow (e.g. via kernel, sys, or mdadm) then it's something I can use.
<xnox> smb: otherwise i'm working on dmraid to generate /dev/mapper/Volume1p2 symlinks, to match what mdadm would have done. (in addition to current /dev/mapper/isw_aewlfss_Volume1p2)
<smb> xnox, Hm, is blkid maybe returning some of it...? I don't have the computer with isw turned on right now
<smb> Ok, I turned it on and blkid is not telling much. But mdadm --examine on a drive contains a "Family" field which looks like it could be a label like dmraid used...
<smb> Otherwise the code in dmraid is in lib/format/ataraid/isw.c
<smb> xnox, ^
<xnox> smb: well, inside isw.c I got lost =) let me mount everything with mdadm and check the family bits.
<smb> I could imagine it needs at least some additional prefix that is per-container as I think each container could have the same volume names... not that I got a setup like that
<xnox> smb: yeah, family looks plausible, but it's different from what dmraid reports.
<smb> bah...
<xnox> smb: for some reason in dmraid code i see family_num to be calculated using a checksum and current time =/
<xnox> nah, that's creation
<xnox> smb: actually i think family is the right field here, but looks like mdadm is mangling it.
<smb> xnox, Hard to be sure if both disagree on contents. :(
<smb> xnox, I agree the _name function in dmraid which seems to produce the content is mind boggling
<smb> At least at this time of day
<smb> xnox, Ok, I think what dmraid uses there is isw->family_num which seems to be set by "isw->family_num = isw->orig_family_num = _checksum(isw) + time(NULL);"
<xnox> smb: at volume creation time, one needs to put something random there.
<xnox> smb: ditto is done in mdadm.
<xnox> smb: i've now done this:
<xnox> dmraid -i -n | grep family
<xnox> and mdadm --examine /dev/md127 | grep Family
<xnox> first one is in base10, the mdadm one is in hex, but they match \o/
<smb> ah
<smb> cool :)
<xnox> smb: but they are different from the original isw_$(string)_Volume2
<smb> xnox, Oh hrm, I thought from the code they both should be ... but meh, no one should rely on the exact pathname nowadays...
<xnox> smb: i'm trying to create a stable name.
<xnox> smb: at the moment filesystem UID is used by grub and "dmraid-style mapper name" by /etc/fstab on existing installations.
<xnox> one shouldn't use FS UUID, as then filesystem get mounted directly - instead of from the assembled raid device.
<xnox> and a /dev/mapper/* name so far is unstable =)
<smb> Yeah, well I usually used lvm on the volume... but one cannot rely on that...
<xnox> smb: oh, i'm doing without lvm upgrade case.
<xnox> smb: yeah, with lvm we have our act together and it doesn't matter much what the RAID device names are.
<smb> Yeah... but right for the other case it would be nice if it would not change
<smb> :q
<smb> xnox, Oh gosh...
<smb> Try using the family number in decimal and replace each digit by 'a'+n
<smb> xnox, I bet mdadm family number in your case is f6de49f9
<xnox> smb: yes, it is.
<smb> xnox, So that is the magic... dunno why dmraid thought it needs to mange a decimal number into letters... :/
<smb> *mangle
<xnox> smb: apart from I didn't understand the algo =)
<smb> Oh, you take each digit and replace 0 with a, 1 with b, 2 with c...
<xnox> smb: sigh =)
<xnox> smb: gotcha.
<xnox> smb: because hex is bad, i guess =)
<smb> But it wasn't hex :)
<smb> oh they could have done hex maybe... :-P
<xnox> smb: as in mdadm chose to use hex representation of family_number.
<smb> Yeah... imo that is good enough and even guarantees a certain length
<smb> for an uint_32 at least
<smb> hm, nm only with prefixed 0s and you can do that with uints too
<smb> so really no idea... 
<smb> The _name function also hurts your brain because they first use %u in a special snprintf and then run that mk_alpha over some of it...
<rsalveti> apw: mind updating the meta package for linux-manta as well? (in the c.k ppa)
<apw> rsalveti, uploaded 
<rsalveti> apw: awesome, thanks again
#ubuntu-kernel 2014-02-18
<miseria> "ajedrez batalla entre negros y blancos, al final del final el blanco no tendra peones y el negro prevalecera" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
<ppisati> moin
<xnox> smb: i'll be uploading dmraid/mdadm into the archive today, blocked in proposed. I didn't manage to get migration from dmraid -> mdadm smooth yesterday.
<xnox> (a) kpartx is not executed on mdadm assembled arrays, like it was on dmraid -> thus one doesn't get all partitions present. (and adding a kpartx run to udev rule, didn't do it for me =( )
<xnox> (b) and i didn't get compat symlinks for kpartx generated devices in above.
<xnox> at least we'll drop dmraid45 dependency, and one can test mdadm assembly from the archive.
<xnox> (i'll disable imsm and ddf assembly by mdadm with a config file)
<smb> xnox, ok, I can check it out pulling the proposed versions. partitions... weird I have partitions on my test raid5 and beside of the downside of mdadm thinking the array is degraded I at least believe to have had partitions with mdadm
<xnox> smb: i only get a device for container (/dev/md/imsm0 or /dev/md127) & the array (/dev/md/Volume1 or /dev/md126), but not partitions in the array.
<xnox> smb: mdadm does think the array is degraded, even though that is a lie =) as containers never leave inactive state... and our check believed it was.
<xnox> (or e.g. the array can be in-progress rebuilding)
<smb> xnox, Hm, I have to check with the version you uploaded, but I got md127px devs, too
<xnox> smb: interesting.
<smb> xnox, Ok, so just to confirm, with the dmraid which has no support for ism at all plus old mdadm (+udev rule addition to act on isw_members), I currently get /dev/md126p? (not 127) and even /dev/md/Volume0p? symlinks.
<xnox> smb: ok. I am using dmraid with ism support compiled, but disabled to not activate the devices, plus mdadm with rules to assemble isw_members, i only get naked devices/symlinks without partitions.
<xnox> i wonder if i really should not compile isw in dmraid.
<smb> xnox, odd... Well I will replace my versions with your uploaded ones and check whether this happens to me, too.
<smb> I guess (iirc) if the script called by udev does not act on isw it should not matter whether dmraid supports things or not
<smb> And I would guess that is where you handle the config setting
 * apw hates rebasing...
<apw> morning
<smb> apw, Morning, as long as its only a git tree and not yourself you rebase...
<apw> yeah at least i can reset my tree on error
<apw> sounds like fun is being had with mdraid
<smb> apw, Software is always fun... changing software doubly so... :-P
<psivaa> sbeattie: bjf: we have this failure in armadaxp SRU, with precise kernel: https://jenkins.qa.ubuntu.com/view/SRU%20Kernel/job/sru_kernel-precise-generic-armhf_omap4_armada1-serial/97/testReport/autotest/ubuntu_qrt_kernel_security/test_kernel_security_py/?
<psivaa> i reran the test to confirm if it's persistent and it occurred during both runs.
<cking> apw, do you mind syncing packages thermald and health-check some time today for me?
<infinity> cking: sync from Debian?  I can do that.
<infinity> cking: Done.
<infinity> cking: Hrm, powerpc, but no ppc64 or ppc64el?
 * cking slaps himself, bad me
<infinity> cking: Do you have reason to believe it won't work with 64-bit userspace?
<infinity> cking: (I assume with "powerpc", you're already assuming it works with 64-bit kernels...)
<cking> infinity, no, I forgot to put those arches in, nnggg
<cking> i guess another tweak and upload is now required...
<infinity> cking: Well, I can fix it in Ubuntu right now for you, and you can fix it in Debian whenever.
<infinity> cking: ppc64 is an unofficial arch in Debian, and ppc64el doesn't exist yet at all, so...
<cking> infinity, if you can, that would be awesome, and I can fix it for the next time I do any other bug fixes
<cking> can't believe I did the tricky part and screwed up the easy bit
<infinity> cking: No arm64 yet?
<cking> infinity, if I get access to H/W I can try it out.. and then add that too ;-)
<infinity> Heh.
<infinity> cking: Oh, also, you don't need all the "linux-" prefixes, it just clutters up the control file.
<infinity> cking: "amd64" *is* "linux-amd64", there's no ambiguity.
<cking> ah, ok
<infinity> any-i386 == i386, hurd-i386, kfreebsd-i386, but i386 on its own is just i386, which is the Linux port.
<infinity> So, I'll fix that up too while I'm in here, and you can sync it back when you care.
<cking> ok, thanks, I remember that for next time I do anything so arch specific, like never I hope
<infinity> Well, it would be perfectly reasonable, IMO, to just have it be "any" as well, if it'll FTBFS on unsupported arches.
<infinity> It's only bad if it builds but is completely broken subsequently.
<infinity> (or linux-any, if it's linux-specific)
<cking> ok, but I hate seeing FTBFS on other arches when I know it won't work..
<infinity> Heh, fair enough.  To each their own.
<infinity> I like the red FTBFS items as a subtle reminder that I have things to fix. :)
<cking> very true
<infinity> cking: Uploading this: http://paste.ubuntu.com/6953727/
<xnox> now i'm enjoying UEFI which selects the wrong hard-drive to boot off...
<infinity> cking: unless you have reason to believe x32 wouldn't work.
<cking> infinity, well, I'm not 100% sure, it may just go horribly wrong, I can't recall what's required for x32 special cases
<cking> let's see if it breaks, I can always fix it later :-)
<apw> heh
<infinity> cking: There's some syscall duplication, and, of course, not effing up your pointer sizes, but otherwise I expect anything that works on amd64 to Just Work on x32.
<infinity> cking: Should be testable with gcc-multilib installed and gcc -mx32
<infinity> Anyhow, uploading for kicks.
<cking> ok, I can give it a spin later today :-)
<infinity> We don't build for x32 in Ubuntu anyway, this is more for the benefit of the unofficial Debian x32 port when you go and merge this back.
<cking> yup, i've tinkered with that a while ago
<infinity> cking: As for arm64 hardware, do you have access to batuan?
 * cking checks, yep
<infinity> cking: ubuntu@10.229.32.99 from batuan, then.
<cking> ack
<infinity> cking: Password as insecure as you suspect it.  Full sudo.  Please make a user and work in your ~
<cking> shiney
<infinity> Err, and there's a whopping 1.7G free.  Let me see who needs slapping.
<xnox> smb: i believe i had invalid half of GPT partition table (either primary or backup) recreating the array and recreating partition table, now results in proper md126p? and md/Volume1p? devices to appear.
<smb> xnox, Errm, I hate to say I think you forgot a little "exit 0" in the dmraid-activate script as well
<smb> Given that after install there is no (dm) raid for me and in the check for nomdmonddf looks odd too
<smb> Oh its negated...
<smb> but anyway exit 0 is just wrong
<smb> xnox, Though maybe phrasing both as "mdadm xxx assembly disabled by boot option" would be less hm... strange?
<xnox> smb: yeah missing exit 0.
<xnox> correcting text.
<smb> xnox, I guess it should be about what is default. But I catch myself going something disabled ... something enabled... wait were those options not both nomd...bla...? :)
<xnox> =)))
<xnox> smb: also the /etc/default/grub.d/dmraid2mdadm.cfg
<smb> Oh, _there_ those come form
<smb> I was already wondering... did we have a grub.d there ever before?
<xnox> smb: that's fairly new. we have /etc/grub.d/ for template generators, /etc/default/grub for default "settings" and /etc/default/grub.d/ for sourced settings....
<xnox> e.g. kexec-tools uses the last one as well to set crashkernel= line
<smb> xnox, Neat to know for me ... There might be some use for that for Xen...
<smb> xnox, Ok, so the switch to md works for me and has partitions, too.
<smb> So the only problem I saw was the "exit 0"
<smb> And maybe but thats RTFRN the surprising source of the nomd* grub cmdline args
<jsalisbury> apw, It looks like the amd64 kernel is missing for the 3.14-rc3 mainline build:
<jsalisbury> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.14-rc3-trusty/
<pkern> Is there an relatively easy way to add a suffix to the Ubuntu kernel version when compiling it? "DEB_BUILD_OPTIONS=parallel=14 AUTOBUILD=1 NOEXTRAS=1 /usr/bin/time fakeroot debian/rules binary-generic" is the current build command I use. |:
<arges> jsalisbury: I was going to mention the same thing. : ) was just going to test with latest
<jsalisbury> arges, I haven't tried to build manually yet, or search upstream to see if its a known issue.
<arges> /bin/bash: line 0: cd: /home/apw/COD/linux/debian/build/tools-perarch/tools/hv: No such file or directory
<arges> from http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/BUILD.LOG
<arges> apw: ^^^ might want to look
<apw> jsalisbury, yep upstream does not build on that arch.... sucks to be it
<jsalisbury> apw, whoops
<apw> pkern, add your suffix to debian.master/changelog, to the first version entry there
<apw> arges, meh mainline smainline
<hallyn> smb: so I'm not sure if you were waiting for more info from me about the overlayfs-whiteout patch...  pls ping me if you are
<apw> hallyn, for me, i have not yet had a chance to think about why that one bit differs from the rest; why it is able to take the privs it needs elsewhere to copy up for instance, and yet does not do the trusted.* bit under the same elevatio
<smb> hallyn, No, after realizing that the first part describes how whiteout is done right now, I understood the patch. Hm, oh just to make sure: this was targeted for some upstream. Or were you asking us (kernel-team) to apply it to Trusty?
<rtg> apw, pushed 'UBUNTU: [Config] CONFIG_CGROUP_SCHED=y for ppc64el' after test build. There are a couple of other cgroup related configs that I'll make consistent as well.
<pkern> apw: I wonder if AUTOBUILD=1 NOEXTRAS=1 does the ABI checks. So I tried -17gg.31 as a version but it did not pick 17gg as the ABI identifier. ;) I think I do want to diverge in the package name. So I'm not sure where to place the suffix. |:
<ppisati> apw: what was the name of the pastebin cli tool?
<apw> ppisati, pastebinit
<ppisati> ah
<ppisati> 10x
<apw> pkern, no the abi on disk is always just the numeric prefix
<hallyn> smb: there is no 'upstream' right now AFAIUI.  I cc:d Miklos, but overlayfs is not upstream so...
<hallyn> apw: the copy-up only requires write access to the writeable layer.  That requires either uid equivalence, or *targeted* capabilities to the user namespace owning the inode
<hallyn> apw: writing to trusted.* xattrs requires capabilities targeted to the *initial* user namespace
<hallyn> that's the bit I'm changing, poking a hole just for trusted.overlay*
<apw> hallyn, i mean to say overlayfs is already raiding its creds beyond the caller to do the copy
<apw> hallyn, why is it not raising them to what it needs
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting today @ 17:00 UTC in #ubuntu-meeting
<jsalisbury> ##
<hallyn> apw: it raises all creds.  But the creds are targeted to cred->userns.  Now I suppose we could look into changing the userns there.  That may be deemed a 'correct' fix.  not quite sure
<bjf> arges, you around?
<arges> bjf: yes
<bjf> arges, did you SRU a netfilter: nf_conntrack commit for Precise ?
<arges> bjf: yes
<bjf> arges, it doesn't build :-(
<arges> hmm...
<bjf> arges, yeah, that's what i say
<arges> bjf: so assuming by precise you mean 3.2
<rtg> amb, apw, are you both happy with '[PATCH 1/1] overlayfs, xattr: allow unprivileged users to whiteout' ?
<bjf> arges, i can fix it but i'm grumpy. yes 3.2
<rtg> smb^^
<arges> bjf: i'll fix it. re-building/testing it now
<apw> rtg, i am still thinking about it
<rtg> apw, frankly, I don't know how to think about it. too inexperienced in that subsystem.
<apw> rtg, i need to sit down and look at it and not had any "uninterrupted time" to think on it
<rtg> apw, log off of IRC, that'll help :)
<bjf> arges, /tmp/kernel-bradf-RBDocT6R/build.log on tangerine
<hallyn> apw: override_creds vs. userns will probably need to be addressed more fully at some point, but it's not entirely clear how to best do that.
<hallyn> i.e. if a thread is running as root and wants to switch to some uid or subuid, there is no good way for it to get a good userns
<hallyn> now i guess in those cases it doesn't matter as much.  the case where we care is override_creds to root
<hallyn> so maybe an 'override_creds_to_init_root()' would be useful as a new helper;  for nfs and overlayfs.  but i'm guessing there'll be bikeshedding on that till summertime
<psivaa> bjf: curious if you saw my previous message to you and sbeattie about the precise armadaxp test failure on the SRU.
<psivaa> https://jenkins.qa.ubuntu.com/view/SRU%20Kernel/job/sru_kernel-precise-generic-armhf_omap4_armada1-serial/97/testReport/autotest/ubuntu_qrt_kernel_security/test_kernel_security_py/?
<bjf> psivaa, i had not seen it
<psivaa> bjf: ack, this is holding the release of the armadaxp precise kernel
<psivaa> bjf: i've run twice just to confirm if this is reproducible and it is
<bjf> ppisati, do you have access to one of these armadaxp boards ?
<ppisati> bjf: uhm no, i may ask on #hwe if needed
<bjf> ppisati, is that ike's baby?
<ppisati> bjf: hold on
<ppisati> bjf: yep
<ppisati> weird
<ppisati> that's a compile time opt
<ppisati> either it was changed in the last upload
<ppisati> or i don't know
<bjf> yeah
 * apw finds it a little off that he can build "unstable" ok but the mainline 3.14-rc3 doesn't build ...
<apw> rtg, you didn't add any local patches did you ... hmmm
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes in #ubuntu-meeting
<jsalisbury> ##
<rtg> apw, other then the usual SAUCE and other ubuntization, I can't recall...
<ppisati> psivaa: uhm
<ppisati> [flag@luxor ubuntu-precise]$ git grep "config DEBUG_RODATA"
<ppisati> arch/parisc/Kconfig.debug:config DEBUG_RODATA
<ppisati> arch/x86/Kconfig.debug:config DEBUG_RODATA
<ppisati> arch/x86/Kconfig.debug:config DEBUG_RODATA_TEST
<ppisati> [flag@luxor ubuntu-precise]$
<ppisati> psivaa: and indeed, it's off in my omap4 branch
<ppisati> psivaa: what do you do wrt omap4 for that test? does it run? or do you skip it?
<ppisati> psivaa: i guess the second
<ppisati> psivaa: and when the last time that test was run on the armadaxp kernel?
<ppisati> *when was
<psivaa> ppisati: so for omap4 with precise we run it manually, and i think it's skipped. but let me confirm it in a bit
<psivaa> for armadaxp this was run yesterday
<ppisati> psivaa: and it failed, right?
<psivaa> ppisati: yes
<ppisati> psivaa: i mean, last time it was run and it passed
<ppisati> psivaa: because IMO, that test should never run for arm
<ppisati> psivaa: at least in precise, maybe newer kernel have that
<psivaa> ppisati: ack, let me check
<psivaa> ppisati: https://jenkins.qa.ubuntu.com/view/SRU%20Kernel/job/sru_kernel-precise-generic-armhf_omap4_armada1-serial/90/consoleText has that test passing
* jsalisbury changed the topic of #ubuntu-kernel to:  Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues February 25th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<psivaa> ppisati: the kernel tested was 3.2.0-1630.42
<ppisati> psivaa: that's impossible
<ppisati> psivaa: [flag@luxor ubuntu-precise]$ grep RODATA debian/build/build-omap4/.config 
<ppisati> [flag@luxor ubuntu-precise]$
<ppisati> psivaa: that option is off in precise/omap4, so how can the test pass?
<psivaa> ppisati: no idea but assume you've seen the above link :)
<ppisati> psivaa: where is the code for the test suite?
<psivaa> ppisati: we pull the code from git://kernel.ubuntu.com/ubuntu/autotest-client-tests
<ppisati> psivaa: are you sure those are the test that you are running?
<ppisati> psivaa: [flag@luxor autotest-client-tests]$ grep -Ri config_debug_rodata *
<ppisati> kernbench/config:CONFIG_DEBUG_RODATA=y
<ppisati> kernbench/config:# CONFIG_DEBUG_RODATA_TEST is not set
<ppisati> [flag@luxor autotest-client-tests]$
<ppisati> psivaa: [flag@luxor autotest-client-tests]$ git grep KernelSecurityTest
<ppisati> [flag@luxor autotest-client-tests]$
<ppisati> psivaa: bzr+ssh://bazaar.launchpad.net/%2Bbranch/qa-regression-testing/
<arges> apw: well 3.13.0-8-lowlatency locks up my laptop : )
<arges> time for -9
<psivaa> ppisati: i'm pretty sure we run the tests that's in the git repo. and i see exactly same output:
<psivaa> usit@morgan:~/kernel-sru/branches/autotest-client-tests$ grep -Ri config_debug_rodata *
<psivaa> kernbench/config:CONFIG_DEBUG_RODATA=y
<psivaa> kernbench/config:# CONFIG_DEBUG_RODATA_TEST is not set
<psivaa> usit@morgan:~/kernel-sru/branches/autotest-client-tests$ git grep KernelSecurityTest
<psivaa> usit@morgan:~/kernel-sru/branches/autotest-client-tests$
<psivaa> ppisati: and that's what we run the test on.. not sure how/why the tests are not skipped
<zequence> arges: Try using nothreadirqs boot parameter
<zequence> arges: Also, try linux-generic with threadirqs boot parameter, to see if it freezes too
<arges> zequence: ok. is there already a bug # for this issue?
<zequence> arges: I myself have a problem only when having a wifi driver loaded, with threadirqs. That makes the kernel freeze
<zequence> arges: Yes. A few bugs, that may be related
<zequence> arges: bug: 1279081
<ubot2`> Launchpad bug 1279081 in linux (Ubuntu) "linux freezes with threadirqs parameter when rt73usb is loaded" [High,Confirmed] https://launchpad.net/bugs/1279081
<arges> cool subscribing
<ppisati> psivaa: the actual test is not there, how can the test be there if grepping for any string doesn't return anything?
<ppisati> psivaa: File "./test-kernel-security.py", line 672, in test_072_config_debug_rodata
<ppisati> psivaa: can you find that file? no
<psivaa> ppisati: let me see
<ppisati> psivaa: the actual test is here: bzr+ssh://bazaar.launchpad.net/%2Bbranch/qa-regression-testing/
<ppisati> psivaa: flag@luxor qa-regression-testing]$ ls -la scripts/test-kernel-security.py 
<ppisati> -rwxrwxr-x 1 flag flag 63535 Feb 18 18:26 scripts/test-kernel-security.py
<psivaa> ppisati: we dont use the qrt from bzr directly.. bjf may be able to give a better explanation for that
<ppisati> psivaa: do you have a log from an omap4 kernel testing?
<psivaa> ppisati: i dont see scripts/test-kernel-security.py in our test code.  yes let me find the omap4 logs
<henrix> ppisati: psivaa: iirc, those tests are actually inside a bz2 archive in the source tree. but it's been a while since last time i looked
<psivaa> ppisati: https://jenkins.qa.ubuntu.com/view/SRU%20Kernel/job/sru_kernel-quantal-generic-armhf_omap4_panda_ES-serial/163/consoleFull is the omap4 logs
<ppisati> 21:39:16 ERROR| [stderr] test_072_config_debug_rodata (__main__.KernelSecurityTest)
<ppisati> 21:39:16 ERROR| [stderr] CONFIG_DEBUG_RODATA enabled ... FAIL
<ppisati> indeed that options is off
<arges> bjf: hey, sent an updated patch. it builds and boottest works
<psivaa> ppisati: this log has that test 'FAIL' although jenkins report at the end as no test failures. this has now been fixed
<bjf> arges, thanks
<ppisati> psivaa: as i said, DEBUG_RODATA is not available on arm in that kernel, so it's normal that the test fails
<psivaa> ppisati: sorry i am confused. do you mean to say that it's expected that the test fails on omap4 *and on armadaxp boards since the kernel does not have DEBUG_RODATA?
<bjf> arges, did you send that me directly? i'm not seeing it
<arges> bjf: sent it to kteam ml
<ppisati> psivaa: yes, either that test was skipped or no one noticed it since now
<psivaa> ppisati: ok, the test is not skipped in our setup as we could see. right ( sorry i am trying to understand as we are going.. so bear with me :))
<arges> bjf: i just fwd it directly to you as well
<bjf> thanks
<bjf> arges, got it
 * ppisati -> EOD
<kees> henrix, sbeattie: odd, ARM should not be testing for CONFIG_DEBUG_RODATA. that option doesn't exist yet there.
<kees> the test should be skipping that check.
<kees> also, how come jenkins output doesn't log correctly? the notes on tests (the stuff in ()s) isn't logged in the correct place.
<henrix> psivaa: ^^
<psivaa> kees: i dont understand your comment. where is it wrong. 
<gQuigs> kernel 3.14 landing in 14.04 is not possible anymore?
<kees> psivaa: the test itself should be detecting that it is an ARM kernel and not requiring the CONFIG_DEBUG_RODATA option. the test appear broken, but it's a harmless failure condition.
<kees> psivaa: or did you mean the jenkins output?
<manjo> rtg, what is the final kernel version for trusty? 
<psivaa> kees: i'm not really bothered about jenkins output issue if that failure is harmless :)
<rtg> manjo, 3.13.x
<psivaa> kees: just was talking to plars and there was already a bug opened for this:  https://bugs.launchpad.net/qa-regression-testing/+bug/1190668
<ubot2`> Launchpad bug 1190668 in QA Regression Testing "FAIL: test_072_config_debug_rodata (__main__.KernelSecurityTest) on SRU kernel 3.5.0-226.39 omap4" [Undecided,New]
<plars> yeah, we get the same failure on omap4
<plars> for a while now, and were told that the option needs to be disabled in the kernel iirc
<manjo> rtg, thanks... is it too late to request a pull  from 3.14-RCX? possibly one or 2 patches 
<rtg> manjo, not too late, but its obviously dependent on the content of the patch. send it on the list.
<manjo> rtg, will do when it lands there 
<kees> plars: the option doesn't exist on ARM kernels. it's the test that needs to be fixed to not expect it
<manjo> rtg, atm there was a one liner hack that was put into saucy to get guest kernels to boot and use serial ... hopefully ppisati carried that fwd. The real fix is landing upstream somewhere in 3.14.rc1 according to linaro ... so just checking when it lands we could replace the hack with real fix
<rtg> manjo, 3.14 is already at -rc3
<manjo> rtg, right ... checking on it and will let ppisati know 
<miseria> "cuantos millones de humanos perderian su trabajo si un miserable salario minimo fuera mandatorio en el planeta?" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
<nickez> anybody knows what is going on with the 64bit dailies?
#ubuntu-kernel 2014-02-19
<ppisati> hallo
 * smb waves tiredly
<caribou> Is there issues with doing a bisect b/w 3.11 & 3.13 kernels ?
<caribou> I mean will a bisection work between 11 & 13 ?
<smb> For mainline/upstream: maybe. 
<caribou> smb: yeah, it's for the mainline
<smb> caribou, It probably works but can't you just go for a mainline 3.12 manually and then decide
<smb> ?
<smb> (which is what bisect would probably do anyways)
<caribou> smb: yeah, that would be better indeed
<caribou> smb: thanks, will do that
<smb> caribou, I usually take the mainline builds as first approximation (the RCs, too)
<smb> Unfortunately most of the time its in -RC1
<smb> But at least that reduces your bisect to between last release and next -rc1
<smb> cking, apw, Btw, I just happened to stumble over "[PATCH V2] Change ACPI IPMI support to "default y"" on the acpi mailing list today. It will not be a stable change but maybe its worth thinking about it for T anyway...
<cking> smb, thanks for that, I'll look at that later today
<smb> cking, ok. To me it looks sensible enough. But its always better to have a second opinion
<smb> ;)
<cking> it certainly looks sane to me
<apw> smb, where did you stumble over that, it has to be old
<smb> apw, on the acpi-devel mailing list and for me it looks to be sent yesterday around 5pm
<apw> oh missread what you said, thought you were saying it was mine
<smb> No, no. Not at all
<apw> smb, ok we have all of those =m so at least they exist
<apw> mjg59, does your latest patch for the IPMI bits imply you can need them before it is possible to load modules
<hvn2> hi, I have a question on configuring the kernel
<hvn2> I need to set the UART for debugging purpose, and that can be done using setting CONFIG_OMAP_LL_DEBUG_UARTx=y...but I can't find this option.
<apw> hvn2, i cannot find anything which even smells similar to that in any of the kernels i am looking at ehre, no
<apw> what makes you think you need to set that, ie. what docs are you reading
<dslr> hi, i am on ubuntu and i would like to build my current kernel from source.  my machine has version 3.2.0-41-generic on it. so i tried apt-get source linux-image-`(uname -r)`. but this downloads the original kernel source and 3.2.0, and then patches it to a version ahead of -41-.  it patches it to version -46-, is there any way to get the source for exact same kernel version?
<apw> dslr, the source for older versions of the kernel are not in the archive, you can get them from either the +source page for linux or from our git repository
<apw> https://launchpad.net/ubuntu/precise/+source/linux/3.2.0-41.66 for that _very_ old version you are running
<dslr> apw: thanks.  yeah i know it is quite old version.  have to live with it. :)
<apw> dslr, dare i ask why you cannot run the latest
<hvn2> apw: from what I find about current kernels, it's completely gone. Most likely due to the not-use of the legacy uart.
<dslr> apw: work related, it is not my machine and we have dependencies on plenty of other source code that will have to be upgraded.
<caribou> I have a DL460g8 where kdump doesn't work (kernel seems to hang before init get called). We tested with 3.13 mainline + kdump-tools and it works fine
<caribou> now we will test with the ubuntu specific 3.13 from Trusty to see if it continues to work.
<caribou> then we want to do a bisection. should we do the bisect with the mainline kernels or with the ubuntu specific ?
<caribou> given that the ubuntu specific 3.13 does work
<caribou> otherwise, the delta will be b/w ubuntu 3.13 & mainline 3.13
<caribou> am I making any sense ?
<rtg> caribou, you really want to bisect the mainline kernel 'cause the Ubuntu kernel commit history is not linear
<caribou> rtg: this is what I wanted to know, thanks rtg 
<caribou> rtg: so it it worth to test the Ubuntu specific 3.13 then to see if kdump still works ?
<caribou> rtg: if the delta is b/w ubuntu 3.13 & mainline 3.13 is it possible to bisect ?
<rtg> caribou, that bisect might be more difficult because of packaging and ABI issues. if Ubuntu 3.13 doesn't work, then maybe we can just eyeball the Ubuntu specific code commits.
<caribou> rtg: no, 3.13 mainline works fine, it's either b/w 3.11 & 3.12 or b/w 3.12 & 3.13 we need do to one last test to narrow it down
<caribou> rtg: i.e. test with 3.12 mainline
<caribou> rtg: ah, sorry just realized you were talking about Ubuntu 3.13
<caribou> rtg: but I'll remember the eyeball part :-)
<rtg> caribou, the other big difference is that Ubuntu 3.13 is based on stable 3.13.3 whereas mainline is vanilla 3.13 (I think). apw could answer that for sure.
<mjg59> apw: It's certainly possible
<mjg59> apw: Any _INI method could refer to an IPMI opregion
<manjo> ppisati, ping 
<manjo> ppisati, around asquare atriangle ? 
<gQuigs> I'm trying to pick the best time for customers to try out 14.04 pre-release for testing purposes.  If we might end up going with the 3.14 kernel I'd prefer to wait for that to land.  
<gQuigs> I'd hope to do something before the Final Beta.  Any suggestions?
<rtg> gQuigs, we are definitely releasing 14.04 with a 3.13 kernel.
<gQuigs> rtg: thanks!  Then I'm thinking about suggesting customer testing around March1st, any objections? 
<rtg> gQuigs, it seems pretty stable right now, so March 1 ought to be fine.
<gQuigs> rtg: awesome, thanks
<ppisati> manjo: no
<manjo> ppisati, hello, you remember we put in a one line patch to saucy to fix serial console on guest iamges? there is supposedly a patch landing upstream that fixes that 
<ppisati> manjo: yep, can you point me to the new patch?
<manjo> yes I will .. just wanted to give you a heads up that that is happening 
<manjo> ppisati, emailed you 
<ppisati> manjo: k
<RoyK> hi all. I have eth0 on int 19, and all interrupts are processed by core0, which is getting rather hot with >10k interrupts/s. I've set smp_affinity to 0f, having 4 cores, but it's still stuck at core 0. any idea why?
<apw> RoyK, it may be only connected to that one cpu
<RoyK> apw: problem is, it works if I pin it to another cpu, but if I set affinity to f (4 cores), it stays at core0
<rtg> isn't that what it is supposed to do ? keep the caches populated ?
<RoyK> well, when one core is at 95%+, it should move those interrupts imho
<RoyK> rtg: also, by default it seems to pin both NICs on core0
<arges> sforshee: hey
<arges> sforshee: I'm seeing this again: http://pastebin.ubuntu.com/6961321/
<arges> looks like this https://bugzilla.kernel.org/show_bug.cgi?id=69051
<ubot2`> bugzilla.kernel.org bug 69051 in network-wireless "iwlwifi 0000:01:00.0: fail to flush all tx fifo queues Q 2" [Normal,New]
<sforshee> arges: what kernel/firmware versions?
<arges> sforshee: 3.13.0-8-generic / Centrino Wireless-N 1000 [Condor Peak]  
<arges> sforshee: i'll install 3.14 and see how that works
<sforshee> arges: what about the firmware? That was updated not too long ago to adress some firmware issues
<arges> linux-firmware 1.124
<sforshee> arges: okay, that should have the new firmware
<sforshee> arges: so I do see people saying that loading iwlwifi with 11n_disable=1 gets rid of it, and intel has gone so far as sending a patch recently to make that the default due to firmware issues
<sforshee> so I'm wondering if this falls into the category of firmware issues that aren't going to be fixed
#ubuntu-kernel 2014-02-20
<inahandizha> http://VisitsToMoney.com/index.php?refId=386970
<ppisati> yo yo yo
<apw> yo
<ogra_> ghurt
<cking>  smb, i'm of the opinion IPMI probably be should be for x86 specific arches for T and we don't consider any other support of IPMI by default for other arches
<apw> yeah for now, the upstream advise was an x86 centric thing, so leavin the others =m sounds reasonable
<apw> and we can fix those on a whine by whine basis
<smb>   cking Agreed. I don't know enough about what exists or not in the Arm world to make any better decision
<apw> i am assuming ppisati is sorting out a patch (if he hasn't already)
<smb> apw, Yeah
<cking> apw, ppisati has sent a patch, and I've commented on it, so I guess another iteration is required to turn it back to =m for anything apart from x86
<smb> I just saw that from x86 world where you can have some ipmi support but no declaration of it, that default probe just reads from "known" port addresses
<smb> But that likely has complete other meaning in Arm
<cking> bad x86 centric world view
<smb> cking, come first serve first... :-P but yeah
<infinity> Wait, why is there ipmi support in the kernel at all?
<infinity> What has Intel done now?
<infinity> cking: Please tell me this doesn't mean what I think it means (listening to the world with a known-insecure protocol, so everyone and their dog can reboot my computer?)
 * cking is now overly concerned too
<smb> infinity, ITs an interface to a BMC which should work even when no network access for the bmc has been set up
<smb> The driver only "listens" to a character device
<infinity> smb: Right, okay.  So, it's the module that ipmitool uses for localhost access.
<infinity> smb: That's all that's being discussed here?
<smb> infinity, Yes
<infinity> smb: Still feels bloaty and wrong to have that build into the zImage, but no, not overly dangerous on x86, I'd guess.
<infinity> s/build/built/
<smb> infinity, That we changed ipmi_si (system interface driver, that char device this) to be built-in because it apparently can be a problem if not (on x86)
<cking> compared to ACPI, it's not that bloaty
<smb> infinity, Right now it probably is. And not well understood either (hence the fail for probing)
<infinity> cking: Compared to ACPI, my mom's slim.
<smb> infinity, It might be in future when Arm gets not well implemented acpi tables in larger scale...
<infinity> smb: On ARM today, the IPMI driver Just Works on the three pieces of hardware that have IPMI BMCs, but probably scribbles the heck all over random memory on everything else. :P
<infinity> It's like a return to the dark ages of ISA probing.
<infinity> "Is that a video card over there?  Maybe a network card?  Wait, I think it's a.  Oh, nevermind, we'll just hang now.  And maybe play an awful tone on the PC speaker just because we hate you so."
<smb> infinity, Yeah I would have to re-read it but probably when it found something with the other methods acpi, pci, smi it does not try the "default" method
<smb> And nobody ever wondered whether that default method is working anywhere outside x86... :-P
<brendand> bjf, i've lost track of the cadence. is this one ending on the 7th of march?
<bjf> brendand, yes
<Doctor_Nick> Hi, the wrong kernel version is in 3.14rc3 on the kernel ppa, can someone please fix this?
<Doctor_Nick> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.14-rc3-trusty/
<apw> Doctor_Nick, think i have found a variable aliasing issue, so the binaries are 3.14-rc3 just the .debs are named wrong
<apw> i'll let it rebuild and see if that resolves it
<Doctor_Nick> apw: cool, thanks
<Doctor_Nick> apw: btw, where are the source packages for these?
<apw> Doctor_Nick, there are no source packages, they are built from the source you get by checking out the commit listed in "COMMIT" and then applying the patches in the same directory
<apw> Doctor_Nick, having the source pacakges too would about double the disk needed for each build
<Doctor_Nick> true, the kernel package is pretty big
<Doctor_Nick> what's the url for the source repo?
<Doctor_Nick> oh, you mean directly from the kernel.org git?
<_bjf> Doctor_Nick, our trusty git repo is at git://kernel.ubuntu.com/ubuntu/ubuntu-trusty.git
<Doctor_Nick> ah, ok
<apw> Doctor_Nick, though in the case of v3.14-rc3 that tag comes direct from the kernel.org repos
<Doctor_Nick> ok, thanks
<ogra_> wheee ! beaglebones !
<ppisati> ogra_: you what's a pity? that i had to manually craft my own installation for it... if only we had a tool that created custom ubuntu dd-able images... ahhhh.... :)
<ppisati> *you know
<ogra_> i'm working on reviving rootstock ... but currentl touch is the only stuff that works in rootstock-ng
<ppisati> ogra_: you know there's a rainy weekend in front of us, right? :)
<ogra_> in italy perhaps :P
<ogra_> germany has sun and springy waether all the time ;) 
<ppisati> :)
<JanC> > 10 Â°C expected for tomorrow here too...
<JanC> and around that for the weekend too, with maybe some rain on Saturday before noon, and sun after that  :)
<rsalveti> apw: infinity: why did we published the 4.4 based kernels?
<rsalveti> mako/manta
<apw> rsalveti, i don't recall doing anything there
<rsalveti> it seems infinity copied them over
<apw> erp
<rsalveti> alright, as long we don't rebuild the android package until I'm able to drop the 4.4.2 version (which should hopefully happen tomorrow), we're still good
<rsalveti> otherwise mako/manta will not even boot properly
<apw> it looks like we uploaded it to the PPA correctly, but i cannot account for them moving out
<rsalveti> yeah, guess infinity just moved everything that made sense (maybe because of FF)
<apw> hmmm, yeah, i guess if things catch on fire we'll have to work out how to shove the old contents back into the new branch for a bit
<jtaylor> hi todays kernel update seem to have broke perf
<bjf> jtaylor, details? kernel version ?
<jtaylor> /usr/lib/linux-tools/3.13.0-11-generic/perf -> ../linux-tools-3.13.0-11/perf
<jtaylor> but its in /usr/lib/linux-tools-3.13.0-11/perf
<jtaylor> one level down more
<bjf> apw, ^ ?
<apw> bjf, ta
<bjf> i'm sure
<apw> jtaylor, heh, that i could believe, i am doing a test build right now for tools so i will check it out
<jtaylor> thx
<jtaylor> < on trusty
<apw> jtaylor, bah yeah that is just plain wrongo, will sort it out, i assume you can find your perf binary by hand in the interim
<jtaylor> yes I fixed the link and it works
<apw> jtaylor, well that at least is positive, i'll let these build complete and check i have sorted the pooch
<apw> i suspect this and the ipmi issue might mean it is worth doing an upload sooner rather than later
<miseria> la palabra manipuladora que dice un perdedor y arrogante pacifista si no estas conmigo, eres mi enemigo  bienvenidos httpcastroruben.com temo_a_un_ser_sin_rival
#ubuntu-kernel 2014-02-21
<hvn2> hi, question on boot: is the /boot/abi file necessary for successful booting ? I've been reading about abi but can't figure this out
<infinity> hvn2: No, it's just there as a reference.
<hvn2> inifinity: ok, thank you. I'm trying to figure out why my custom kernel 3.5.7 (for 12.04) won't boot and keeps hanging at "Uncompressing Linux... done, booting the kernel.". So far I found no solution.
<apw> hvn2, that is very early, try adding debug and loglevel=9 to the boot
<apw> hvn2, also does the mainline 3.5.7 
<apw> boot for your machine
<apw> hvn2, as infinity says the /boot/abi is not used at runtime at all
 * apw hates on debconf questions which always appear 10s after you leave an upgrade to finish by itself
<hvn2> apw: where should I add debug and loglevel ?
<hvn2> apw: e.g. in the kernel or in boot.scr ?
<apw> on the kernel command line, however you are setting that
<apw> as it is a boot.scr i assume it is some kind of arm board
<hvn2> apw: yes it is an armv7 board
<hvn2> apw: I assume then I should put loglevel=9 in boot.scr ?
<apw> and debug in whever you set the kernel command line
<apw> that is likely there, but i don't have the same boards, and they don't all work the saem
<hvn2> apw: do you have a suggestion for how to put debug  ?
<apw> debug is the word you want, like loglevel it instructs the kernel to be noisier
<hvn2> so, just put the word debug in boot.scr ?
<apw> hvn2, put it with loglevel=9 in the kernel command line specification hwever that is done in your boot loader
<hvn2> apw: ok
<hvn2> apw: I put loglevel and debug in boot.scr and rebooted...it hangs again, but how do I check on the loglevel and debug now ?
<hvn2> apw: the syslog is only started after starting the kernel, not after boot ?
<arges_> smb: hello. i see the neutron kernel crash bug has some more comments.
<arges> smb: I wonder if it makes sense for us to provide a machine one of their developers can access so they can setup a reproducer and then we can crash it at will and perform experiements?
<smb> arges, Yeah, not more to work on though , yet
<arges> and also snapshot it
<smb> arges, Feel free to offer that to them
<arges> smb: or would it be too much to ask them to reproduce in a VM, then tar it up so we can download the disk?
<smb> arges, Well that might be simplifying the setup. If they can get a kexec crash they can share with us that sounded good enough. And meanwhile try to find a simpler reproducer
<smb> If ones is found we learn more about the trigger, too
<arges> yup
<smb> If not, maybe still we are lucky and get a dump
<arges> smb: so stilll 1) get a crash dump 2) get a reproducer?
<smb> That was my thinking when proposing it. Or rather 1) get the crashdump and while waiting 2) try to get a reporducer. Not sure I was clear  with that :)
<smb> arges, Getting a setup locally may or may not be sucessful. Ok, it could be but also we could find out that it needs a certain environment in which the host is to trigger
<smb> Ok, we could realize that when trying to find a reproducer, too
<arges> smb: i'll send an email with this info you can reply with clarifications
<smb> arges, ok, wfm
<apw> b 3
<miseria> "nunca trates de abarcar el mundo con las dos manos, al final de tus dias, te quedaras sin manos y sin mundo" *bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
<stgraber> so we have a regression with 3.13 on the wandboard... my box won't boot with 3.13.0-11. Last running kernel was -6, will try to figure out exactly which upload broke it now.
<stgraber> 3.13.0-10.30 to 3.13.0-11.31 is where the regression happened
<stgraber> hmm, that doesn't make much sense looking at what changed in 3.13.0-11.31...
<stgraber> yeah, that actually doesn't make any sense seeing that the armhf configuration didn't change at all in that upload (just bits being moved to common)
<stgraber> I guess we'll see if 3.13.0-12.32 magically works (in which case I'll blame cosmic rays), if not, then maybe something toolchainy changed?
#ubuntu-kernel 2014-02-22
<stgraber> so about earlier, looks like 3.13.0-12 boots fine so blaming it on cosmic rays
<infinity> stgraber: Not cosmis rays at all, it was the IPMI stuff getting built in and then removed again because it broke the world.
<stgraber> infinity: hmm, oh, I see now in the 3.13.0-12 changelog... do I even want to know how enabling IPMI prevents arm boxes from booting? :)
<trippeh> ipmi on arm boxes. is that arm on arm? :)
<infinity> stgraber: Not sure we've dug deep enough into it yet, but the assumption is that on machines without a known IPMI interface, it starts randomly probing for one, and we all remember how well that worked out back in the ISA days.
<infinity> stgraber: So, works great on highbank and midway, kinda explodes nearly everything else.
<Chrizby> Anyone knowledgable in configuring a netgear wifi usb adapter to working in Ubuntu?
<bjf> kamal__, ping
#ubuntu-kernel 2015-02-16
<wolandtel> Hi.
<wolandtel> Trying to launch pure debian on T72X 3G (MTK 6582 / 8312). Can anybody explain how to build right initramfs?
#ubuntu-kernel 2015-02-17
<quadrispro> hello everybody
<quadrispro> got problems with the brand-new Lenovo Yoga 3 11.6"'s ELAN touchpad -> lp #1166442
<ubot5> Launchpad bug 1166442 in linux (Ubuntu) "Elantech clickpad/touchpad lacks multitouch features." [Medium,Confirmed] https://launchpad.net/bugs/1166442
<quadrispro> I'd be happy to provide any useful information on the device
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting today @ 17:00 UTC
<jsalisbury> ##
<ChrisP1948> Can someone here on the kernel team give me the status of this bug report - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1402331
<ubot5> Launchpad bug 1402331 in linux (Ubuntu) "System will periodically lockup with [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... render ring idle" [Medium,Incomplete]
<jdesfossez> Hi, is there some kind of special configuration to have printk messages output on a serial console on Trusty ?
<jdesfossez> I followed this guide, but I only see the upstart messages : https://help.ubuntu.com/community/SerialConsoleHowto
<jdesfossez> I see the messages output from the boot, but after that when I load other modules, the printk message are not output on the console (but I can see them in dmesg)
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues February 24th, 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-02-18
<smb> jdesfossez, Possibly those messages are not of high enough level. You could try dmesg -n <level> (level -> eg. warn|notice|info). 
<bjf> apw, the rebuild DEP-8 test. that's going to get run all the time now for all kernel packages. is that really what we want?
<bjf> apw, i know why that test exists, i'm just wondering why it's in the kernel. if it's to ensure that new toolchain packages properly build the kernel why isn't there a test in the toolchain packages for it rather than the kernel?
<apw> bjf, it is in there because it is the kernel test one wants to run when any of the packages we depend on, changes
<apw> bjf, unfortuanatly there is no way to know you are testing for "me" rather than a "dependancy"
<apw> bjf, which is what we would really want ...
<bjf> apw, yeah
<apw> bjf, i think there was a proposed way to tell, which would let one work it out
<bjf> apw, so it's adding multiple hrs. to the testing and when we start running these on multiple archs is going to get worse
<bjf> apw, i guess if it is a problem maybe someone will fix it so it only runs when we want rather than all the time
<apw> bjf, yeah i cannot deny it is stupid, just asking pitti ritht now if there is a way
<apw> bjf, is this in britney testing or in "bjf" testing btw
<bjf> apw, new britney testing that CI is adding
<apw> bjf, ok so official, not runnig somewhere where we get to help out
<apw> to say UNIT_TESTING_FOR_KERNEL and let that short circuit it
<bjf> apw, correct.
<apw> bjf, i am getting the "it doesn't know, and it is all very hard" but i do struggle to say why it doesn't know myself
<infinity> apw: DEP-8 doesn't know why a test was triggered, just that you decided to run some tests.  The fix belongs one layer above that, I suspect.
<infinity> apw: ie: we should only run the test under certain circumstances, but the test itself can't know that, it's the framework calling it (adt-britney, whatever) that needs to be smarter.
<apw> infinity, well likley, though it is odd it isn't parameterised with why it is being run
<infinity> apw: That implies more intelligence than DEP-8 is meant to have.  It should be entirely framework agnostic.
<infinity> apw: You can run tests by hand, you can write infra that runs all your tests in a loop, you can trigger them for $reasons, none of that matters to the tests.
<apw> yeah, and i'd be cool with the reason it ran being "run by hand" or "none"
<cyphermox> jsalisbury: hey, just curious if you had found anything about bug 1359689
<ubot5> bug 1359689 in plymouth (Ubuntu) "cryptsetup password prompt not shown" [High,Triaged] https://launchpad.net/bugs/1359689
<jsalisbury> cyphermox, yes, I backported commits abd69c55d and 144ecb97c.  I should post a link in the bug with a test kernel shortly.
<cyphermox> ok
<cyphermox> thanks :)
<jsalisbury> cyphermox, my test kernel build failed, so I just need to fix up my backports a bit.
#ubuntu-kernel 2015-02-19
<dholbach> hiya
<dholbach> can somebody take a look at https://code.launchpad.net/~niedbalski/ubuntu/vivid/linux-firmware/fix-1423324/+merge/250205?
<apw> dholbach, will get that looked at ... sforshee ^ one for you
<dholbach> thanks!
<bjf> tjaalton, just a reminder to verify LP: 1416451
<ubot5> Launchpad bug 1416451 in linux (Ubuntu Trusty) "Can't switch display mode more than one cycle when docked " [Undecided,Fix committed] https://launchpad.net/bugs/1416451
<bjf> apw, reminder to verify LP: 1411284
<ubot5> Launchpad bug 1411284 in linux (Ubuntu Utopic) "arm64: ubuntu drivers are not built at all for this arch" [Medium,Fix committed] https://launchpad.net/bugs/1411284
<tjaalton> bjf: well, it's kinda shipped already and asia is on vacation, so while I can't verify it personally I've changed the tag
<apw> bjf, ack
<zequence> infinity: I forgot to update the kernel bug. Did you find the source in the ppa?
<infinity> zequence: I did.
<zequence> Ok, sorry for the delay
<infinity> zequence: It's built and being copied to -proposed as we speak.
<zequence> infinity: Alright. Thanks.
#ubuntu-kernel 2015-02-20
<janmsistooschr> hello
<janmsistooschr> Will you create a custom kernel source?
<janmsistooschr> I can pay for a custom kernel support.
<janmsistooschr> apw, interested?
<ohsix> have you actually asked how to do something? people aren't here for money motivations per-se, so it won't necessarily be conducive
<janmsistooschr> Canonical is defunct?
<janmsistooschr> I want a custom kernel built without virtio
<ohsix> that is really easy to do
<ohsix> you can also disable their use from the kernel commandline
<janmsistooschr> I want the source setup this way.
<janmsistooschr> Not just the menuconfig options.
<janmsistooschr> I want it custom built with the drivers for the hardware on a specific machine.
<ohsix> there's make localmodconfig
<janmsistooschr> I can register the machine and pay for the custom kernel.
<ohsix> why do you want to do this?
<janmsistooschr> What is makelocalmodconfig?
<janmsistooschr> I need to test theorys for computer science research.
<ohsix> how does disabling some drivers help that
<janmsistooschr> the basic scientific method requires controls
<ohsix> depends on the nature of what you're testing
<ohsix> disabling drivers that aren't in use, or one tha tis in use in favor of another doesn't really change how the kernel behaves in a meaningful way
<ohsix> there's also the possibility of not using linux alltogether if you really need that much control for what you're testing
<ohsix> you won't be able to control for say, firmware effects, you may not even be able to know about many of them
<janmsistooschr> ohsix, I noticed something peculiar even when using win 5.1
<janmsistooschr> ohsix, What software do you suggest then ohsix 
<ohsix> i still have no idea what you want to do, and you aren't doing much to help that
<janmsistooschr> ohsix, to be able to look at the virtual clouds I need a stable unvirtualized system.
<ohsix> i still don't know how any drivers you're not using will imply instability
<janmsistooschr> I did not make the claim.
<janmsistooschr> I state what I want.
<ohsix> what you want makes no sense, i'm asking for context to give you some useful advice
<janmsistooschr> I want a machine without vitual capability.
<ohsix> virtio is only tangentially related to that
<ohsix> it is used in place of simulating an ata/scsi port with a real driver, because it can be more efficient; same thing for virtual network drivers
<oscar__> Hi there, just wondering if there's any kernel programming related job position you know about 
<JanC> oscar__: Canonical jobs are at http://www.canonical.com/careers (but I think I see no kernel job right now?)
<oscar__> Thanks JanC, I saw that but though maybe there were jobs outside that listing
<JanC> well, many companies do an "internal search" before publicizing a job, so there is always that possibility...
<oscar__> anyone has worked on that kinda job and would be willing to tell me the experience?
<oscar__> thanks JanC
<JanC> if you idle in the channel maybe later one of Canonical's kernel developers will see your question  :)
<oscar__> I hope so!
<bry8knight> hello
<bry8knight> What kernel version is used by hardy?
<bry8knight> apw awake?
<JanC> s/is/was/  :)
<bry8knight> JanC was?
<bry8knight> JanC is it no longer functional?
<JanC> hardy is not a supported release anymore
<bry8knight> That is fine there is no support anyhow.
<bry8knight> Even when offered currency.
<bry8knight> Just robots arguing.
<bry8knight> Without virtio they shalln't be able to move onto my machine.
<bry8knight> They can be useful.
<bry8knight> As it is they are arguing with me.
<bry8knight> JanC: comprende?
<bry8knight> You can't allow mormons to touch the code.
<bry8knight> And expect to have purpose to existing.
<bry8knight> JanC: comprende?
<ohsix> wut
<bry8knight> you are unstable
<bry8knight> needing to be corrected
<bry8knight> to be lifted up
<bry8knight> to function
<bry8knight> en arche eyn ho logos
<bry8knight> I am searching for a logic course for you.
<bry8knight> Does it sound interesting?
<infinity> bry8knight: 2.6.24
<bry8knight> infinity: bless you
#ubuntu-kernel 2015-02-21
<bry8knight> infinity: what do you do?
<bry8knight> this is so captivating
<bry8knight> looking for something?
#ubuntu-kernel 2015-02-22
<sauraedron>  hi, need help with module programming, http://paste.debian.net/154544/, i get this error " error: dereferencing pointer to incomplete type   entry->proc_fops = &fops;", can someone help me ?
#ubuntu-kernel 2016-02-22
<apw> DalekSec, will have a look
<DalekSec> apw: Great, thanks!
<xnox> interesting stuff, cgroup namespaces.
<apw> no you don't want to use all that complex stuff, you'll break it
 * xnox giggles
<cking> do we have regression tests for it?
<lamont> jsalisbury: aroudn yet?
<xnox> cking, yes, it's called systemd in a docker image in lxd container.
<xnox> =)
<cking> why doesn't that surprise me
<jsalisbury> lamont, yes
<jsalisbury> lamont, about to update the bug
<lamont> cool.  did I maybe convince you to do the for loop?
<jsalisbury> lamont, only two kernels left to test in the bisect, then on more after that with a revert of the actual commit.  I'll post then next two to try shortly
<lamont> jsalisbury: cool.  my hope was to be done destroying my work setup in minimum time
<lamont> because it's getting old
<jsalisbury> lamont, yeah, bisecting is a pain
<lamont> tbf, it would suck far less if it wasn't my primary worksurface
<tseliot> apw: hey, I pinged you about the backport of amdgpu from 4.5, and you recommended that I file a bug report and link the commits to it; I have one more question: would I have to rename that as amdgpu_bpo, or could I simply leave it as it is?
<apw> tseliot, how utterly vile is the delta, if its likely to make maintenance huge its better if its separate
<tseliot> apw: it's about 230 commits. I'm at 136 and I haven't had to fix up commits (other than whitespace issues) so far
<tseliot> apw: I want to make it clear that, if anything fails, I can maintain that code
 * apw dries
<apw> dies
<apw> well i guess its really bjf's call, as he has to work with it
 * tseliot prepares a nice coffin
<tseliot> the added benefit would be no fglrx ;)
<apw> as in it would no longer be required, or no longer work :)
<tseliot> the former, and purged too
<bjf> tseliot, which series is this for? Xenial?
<tseliot> bjf: yep
<bjf> tseliot, i'll feel better when you are at commit 230 and still feel everything is fine
<tseliot> bjf: so will I ;)
<bjf> tseliot, i mostly trust your decision as it _will_ be you fixing any/all problems. but it feels late to be sucking in something this huge.
<tseliot> bjf: that is understandable but I didn't have the hardware to work on. I'll let you know how my work goes
<bjf> tseliot, ack, thanks
<tjaalton> also, I'm preparing i915_bpo for SKL/KBL/BXT..
<tjaalton> SKL again, as it's still not done, and shares audio bits with KBL
 * apw gets his shit-list out and checks your name is on it
<tseliot> :D
<apw> and underlined and highlighted in luminious orange
<apw> tseliot, oh and you'll prolly have to file FFEs now as that is in the past
<tseliot> apw: it won't be a problem
<apw> depending if there is anything non-fixy
<tseliot> well, it's both things
<apw> bug #1545401
<ubot5> bug 1545401 in linux-lts-wily (Ubuntu) ""kernel BUG at /build/linux-lts-wily-Vv6Eyd/linux-lts-wily-4.2.0/mm/memory.c:3146!"" [Undecided,Confirmed] https://launchpad.net/bugs/1545401
<apw> stgraber, seems adt testing is broken again: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1548440
<ubot5> Launchpad bug 1548440 in lxc (Ubuntu) "lxc: adt testing failing with 4.4.0-7.22" [Undecided,New]
<stgraber> passed on all arches but amd64, lets just retry it
<stgraber> well, not seeing any retry link on proposed-migration, so guess it's not considered a migration blocker then
<apw> stgraber, not passing for me, on anything
<apw> http://people.canonical.com/~kernel/status/adt-matrix/xenial-linux-meta.html
<apw> stgraber, ^
<apw> stgraber, britney is confused by kernels, because triggers for those _switch_ the installed kernel
<apw> stgraber, so it doesn't maintain history so there are never regressions there, i intuit them in the adt-matrix for the kernel from actual history
<stgraber> so looks like this may be some kind of apparmor bug preventing you from getting an IP somehow
<apw> jjohansen, ^
<apw> we always love apparmor bugs
<stgraber> would be nice if we could get a dmesg dump after that particular failure
<apw> stgraber, presumably that only applies in lxc land, else we'd not be able to use the kernel for any testing at all
<stgraber> right
<stgraber> so that's the current xenial-proposed kernel then?
 * stgraber uprades the big test VM
<apw> stgraber, yes
<stgraber> got a system running the proposed kernel now, creating a container to see what's going on
<stgraber> apw: ok, same behavior here, though I have an idea as to what's going on
<stgraber> hallyn: around?
<stgraber> apw: that kernel brings us cgns support correct?
<hallyn> stgraber: yeah
<hallyn> though you need the git head lxc
<hallyn> to get the moun tpermissions
<stgraber> hallyn: so we have adt regressions with the latest kernel and current lxc, would my assumption that lxcfs detects cgns and so doesn't mount /sys/fs/cgroup but old lxc blocks the cgroupfs mount be correct?
<hallyn> yup
<stgraber> if so, I'll just tag rc2 and upload that to the archive along with my packaging rework, that should fix adt
<stgraber> alright, let me re-test with current lxc upstream
<hallyn> yeah, the lxd nesting profile allows 'mount,' iirc, which hid that one from me
<stgraber> gah, ok, so we need both a new lxc and lxd then
<stgraber> ok, so lxd cherry-pick of your fix and new lxc rc, that should do the trick
<stgraber> apw: will have both uploaded within the hour
<apw> stgraber, sounds good thanks
<hallyn> stgraber: yup, unless there's another glitch hiding, but those were working for me over the weekend
<stgraber> lxd uploaded
<stgraber> going to grab some food and then get tagging for lxc rc2
<stgraber> lxc uploaded
<apw> stgraber, ack thanks
<aiguu_> Does the kernel team hire individuals that wish to get into kernel development without much (or any) kernel experience?
<aiguu_> I've got professional experience in other development areas but always found kernel work interesting. 
<apw> we have been known to, but it all depends on the roles that are open, not sure what all we have open right now
<aiguu_> Thanks-- is the best way to find out to apply or is there someone I could talk to directly? 
<bjf> aiguu_, if you apply through the web site for a specific, open req. it gets the attention of the appropriate team
<aiguu_> Thanks!
<apw> stgraber, hrrmm, seems the new one has a new problem:
<apw> raceback (most recent call last):
<apw>   File "/tmp/tmp.rGuQP5EXYB", line 101, in <module>
<apw>     assert(container.init_pid > 1)
<apw> AssertionError
<stgraber> crap, lets see
<stgraber> hallyn: ^
<stgraber> what's weird is that this passed jenkins somehow
<hallyn> ?
<stgraber> hallyn: rc2 is failing on all arches
<stgraber> I'm wondering if it's not my fault though, could be explained by apparmor not loading somehow
<hallyn> what exactly is failing.  lxd autotest?  booting at all?
<stgraber> hallyn: all the lxc-tests-* are pretty much (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/l/lxc/20160222_210046@/log.gz)
<stgraber> and that's on a non-cgns kernel
<hallyn> hm, so it can't be that lxc-container-default-cgns just isn't installed then
 * hallyn tries adt locally on proposed
<stgraber> I'm setting it up here too, didn't re-install it after I did a clean install on this box
<hallyn> PASS: lxc-tests: /usr/bin/lxc-test-apparmor
<hallyn> it's a start
<hallyn> but im'hanging there
<apw> manjo, did you get to test the initramfs-tools in -proposed ?
<stgraber> got interupted a bit, back to looking at the adt failure now
<stgraber> adt running, maybe I'll get lucky and get the same failure, if not, we'll just blame the DC and hit retry until it passes
<manjo> apw, will do it in the next 1/2 hr
<stgraber> but most of those tests are offline so I'm unsure how that would be
<apw> stgraber, we've failed the same way on 3 arches, so i am suspicious
<stgraber> yeah, me too, but I'm surprised that hallyn didn't manage to reproduce it
<hallyn> no i think i was hanging differently
<hallyn> (maybe my network hiccoughed at the wrong time)
<stgraber> what would make the most sense is that I screwed up something with my packaging rework and the apparmor profile doesn't get loaded, I think that would explain all the failures
<stgraber> ah ffs, adt is blowing up on me again, I thought pitti said he'd fixed that
<apw> stgraber, he fixes that about once a week, its a fragile beastie
<stgraber> adt-run [17:04:45]: testing package lxc version 2.0.0~rc2-0ubuntu1
<stgraber> adt-run [17:04:45]: build not needed
<stgraber> tar: Unexpected EOF in archive
<stgraber> tar: Unexpected EOF in archive
<stgraber> tar: Error is not recoverable: exiting now
<stgraber> qemu-system-x86_64: terminating on signal 15 from pid 12772
<apw> corrupt tarball ?
<stgraber> supposedly it's a very rare error, yet I've got it on all my machines even after re-installing both of them with new disks and switching from trusty to xenial :)
<apw> heh
<stgraber> re-trying, if that doesn't work, I'll just start a trusty VM manually, turn proposed on in there and install lxc manually
<hallyn> trusty?
<stgraber> s/trusty/xenial/
<stgraber> sorry
<stgraber> been debugging another issue that's trusty :)
<hallyn> just checking
<stgraber> gah and yeah, just got the exact same issue again...
<stgraber> taking over the canonical-lxd VM again, that's up to date xenial, will save me some setup time. I'm wiping lxc and lxd from it, rebooting and do a clean lxc install, lets see what happens
<stgraber> yeah, clearly an apparmor profile...
<stgraber>       lxc-start 20160222205626.155 ERROR    lxc_apparmor - lsm/apparmor.c:apparmor_process_label_set:234 - No such file or directory - failed to change apparmor profile to lxc-container-default
<stgraber> ok, so that's my fault for sure, now to figure out how I caused this mess
<stgraber> found something wrong in the packaging, fixed it and doing a test build now to see if the maintainer scripts make more sense then
<stgraber> though since I can't actually reproduce the adt failure, I'm not 100% sure it'll do the trick
<apw> stgraber, that is annoying isn't it
<stgraber> yeah
<stgraber> anyway, sbuild is happy and generated maintscripts look more correct than they did before
<stgraber> lets hope that was it, uploading
<apw> stgraber, thanks
<hallyn> ok so fwiw i expect unprivileged containers in xenial to be temporarily broken.  there's a bad interaction between sforshee's patchset and cgns.  i'm going to test a fix, but it'll take some time to buld
<apw> hallyn, cna i build you a kernel or something ?
<apw> hallyn, as i was about to upload, and i suspect i want that kernel in there
<hallyn> apw: i'm trying http://paste.ubuntu.com/15175046/
<hallyn> not sure it's right, but it seems more right than not doing it
<hallyn> apw: i'm about to head out for a bit, if you're going to push that somewhere i'll wait forthat, else i'll leave a build going here
<hallyn> apw since my server tends to crap out when i build a kernel, i'm happy to wait for you :)
<hallyn> eh, i'll leave it building - /me out to get a coffee, bbl
<apw> hallyn, i'll let you know whn its built
<manjo> apw, is the initramfs in your ppa / 
<manjo> ? 
<manjo> apw, or is it in proposed ? 
<apw> manjo, in proposed
<manjo> yes I see it in proposed .. just installed it 
<apw> hallyn, http://people.canonical.com/~apw/master-next-xenial/
<apw> hallyn, let me know how it fairs
<manjo> ports is so slow
#ubuntu-kernel 2016-02-23
<hallyn> apw: thanks - that worked!
<manjo> anyone know if ports.ubuntu is having issues 
<manjo> looks like some of the ports mirrors might be down... oh well 
<hallyn> apw: the patch is not quite right as it should grab another reference to the namespace, but it doesn't seem to blow up and does fix the bug, so i'll send a proper patch tongiht - thanks again
<hallyn> or does it not matter?
<hallyn> are we guaranteed that the cgns will stick aroudn for the duration of the mount due to task->mntns ?
<hallyn> that actually may be the case bu ti need to think it through
<manjo> apw, shit! 
<manjo> (initramfs) echo "81780AD9-068C-4A80-A795-56856973B8F9" | tr '[:upper:]' '[:lowe
<manjo> r:]'
<manjo> 81780AD9-068C-4A80-A795-56856973B8F9
<manjo> apw, so tr trick won't work in initramfs environemt 
<manjo> apw, (initramfs) echo "81780AD9-068C-4A80-A795-56856973B8F9" | awk '{print tolower($0
<manjo> )}'
<manjo> 81780ad9-068c-4a80-a795-56856973b8f9
<manjo> that works
<manjo> apw, revised patch attached to the bug with real system boot test results 
<jsalisbury> lamont, I posted the last bunch of test kernels in a directory tree.  Location and how they are organized posted to the bug.
<lamont> jsalisbury: awesome
<lamont> I'll smash through the bisect tomorrow
<tjaalton> do you prefer an oldskool pull request or a merge request via lp? (for xenial)
<apw> tjaalton, old skool pull request is prolly easier for people as that is what they are used to
<tjaalton> ok, I'll do that then
<tjaalton> apw: enjoy! :)
<apw> manjo, i've uploaded an alternative fix (to avoid adding the first awk dependency) to ppa:apw/ubuntu/initramfs-tools-test, if you could test that for me then i can get it uploaded for real later today
<apw> tjaalton, that is highly doubtful :/
<tjaalton> hehe
<apw> tjaalton, pththththth
<apw> hallyn, yo ... did you bottom out that cgroups fix?  i don't see an email
<HerrAmeise> anyone install dist-upgrade 4.2.0-30 this morning and have trouble booting?
<HerrAmeise> i had to revert back to 4.2.0-27 in order to get it working
<apw> bjf, kamal ^
<apw> HerrAmeise, what was your symtoms
<apw> you are cirtinaly the first report I have seen of issues with that update
<HerrAmeise> Unity would not start up
<HerrAmeise> so it went through the normal boot sequence
<HerrAmeise> and then just hung forever
<HerrAmeise> I couldn't even open a terminal
<apw> HerrAmeise, ugg, sounds bad.  could you file a bug against the kernle "ubuntu-bug linux" from your working kernel
<HerrAmeise> so I had to go to grub and boot with a different kernel version
<apw> and put whatever details you have in it, and tell us the bug# here
<HerrAmeise> yup no problem
<apw> it is also worth looking in syslog to see if there was anything reported when it broke
<HerrAmeise> yep i can do that one sec
<apw> i am assuming you receieved the kernel via a simple update (update manager or apt-get dist-upgrade sort of thing)
<HerrAmeise> yea i did apt-get dist-upgrade
<HerrAmeise> didn't build it myself or anything crazy
<apw> and its hard to not get all the pieces you need as a complete set when its done that way
<apw> (so that eliminates one possibility)
<apw> once you have a bug, i'll paste some initial kernels to test to try and figure out which of the three updates is at fault
<bjf> apw, news to me. but -30 only has been in -updates for less than 24 hrs.
<apw> yep, that indeed
<HerrAmeise> apw: ok, I am also running this on a VM at work if that is relevant
<HerrAmeise> VMware Workstation 10
<apw> HerrAmeise, VMs would be a common test subject but mostly in KVM
<apw> HerrAmeise, got a bug # yet ?
<stgraber> apw: did our uploads fir your kernel adt problem?
<apw> stgraber, yes ... final one just went green in the last 15m
<apw> (for xenial)
<stgraber> good!
<apw> stgraber, and we're seeing ppc64el lxc ADT failures on trusty regardless of kernel by the looks of it, is this expected ?
<apw> stgraber, and if not i'll file you anohter bug :)
<HerrAmeise> apw: is there any other way to report bugs other than through Apport?
<HerrAmeise> it's really a PITA
<apw> in theory you can ask apport to file the info to a blob you can move to anohter machine and submit form there
<HerrAmeise> and its not just an application crash
<HerrAmeise> btw i upgraded the kernel to 4.2.0-30 on my 32-bit Ubuntu VM and the same thing happened
<HerrAmeise> so definitely able to replicate the error
<HerrAmeise> first one was 64-bit
<apw> it is as likely a vmware realted issue as anything
<HerrAmeise> true
<HerrAmeise> i'll try natively when i get home tonight
<apw> HerrAmeise, the first debugging steps are to try -28 and -29 to see which of 28,29,30 are the first broken one
<apw> https://launchpad.net/ubuntu/+source/linux/4.2.0-29.34
<apw> https://launchpad.net/ubuntu/+source/linux/4.2.0-28.33
<apw> binary packages for those are in the librarian ^
<HerrAmeise> 33674
<HerrAmeise> oops sorry wrong window
<stgraber> apw: the latest ppc64el failure on trusty indicates a DC network failure
<stgraber> unable to reach the gpg network and cloud-images.ubuntu.com
<apw> stgraber, i'll ask for them again and see if it goes away then
<stgraber> the rest of your results look good so I'd say your kernel is fine, it's just the test runner having some network difficulties
<stgraber> I know that IS changed the squid proxy IP recently, could be that the ppc64el VMs don't have the right firewall rule or something
<stgraber> if it fails again, we'll involve pitti
<apw> stgraber, ack, will let you know
<hallyn> apw: sorry, no, had some technical difficulties.  will try to send it out this morning
<apw> hallyn, the pending fixes which break you are time sensitive, so i would like to get to a place where i have a plan to add something or rip something and upload at the latest tommorrow
<hallyn> apw: should i send a patch first upstream or first to ubuntu-kernel@?
<apw> hallyn, either is fine, if you are confident in the fix i cna apply it while upstream grinds on it
<apw> were still in a reaosnably felxible period so we can rip it and replace it if upstream has a better idea
<apw> as i assume my other option is to rip the other thing you applied which causes the issue
<apw> the cgn i think it was
<hallyn> apw: http://paste.ubuntu.com/15181046/   <- does that mean anything to you?
<hallyn> (it kinda blocks me when the server hosting all my work keeps hanging with crap like that - from 3.13 to 3.16 and now on 4.2)
<hallyn> if it migth be hw then i'll just $%)(*$%)($ switch
<apw> i wonder if that could be the fuse cve i was just reviewing
<hallyn> oh
<sforshee> hallyn: do you hit the WARN_ON at the end of the cgroup_mount after your change?
<hallyn> which warn_on?
<sforshee> hallyn: was also thinking it might make sense to make kernfs to use sget_userns with init_user_ns always, haven't had time to really think it through yet though
<sforshee> the one in the if (pinned_sb) block
<hallyn> sforshee: i don't think so
<apw> sforshee, you know fuse well, is fuse_fill_write_pages() use on the write or read path ?
<apw> it ought to be write, but hey, nothing is clear in this world
<hallyn> sforshee: we cannot have cgroup mount use init_user_ns always, if you end up doing the comparison for the sb.
<sforshee> apw: write it would seem, invoked by fuse's write_iter callback
<apw> sforshee, thanks, not that cve then hallyn 
<apw> sforshee, that stack trace might be something you grok better than i: http://paste.ubuntu.com/15181046/
<hallyn> apw: trying to decie whether to halt my world to have the people hosting the server check the hw for 10 hours
<sforshee> apw: looks to me like the kernel is hung waiting for userspace to respond
<apw> hallyn, if it is always that, it look to my shallow knowledge of fuse that it is waiting on a userspace provider, and isn't interruptible
<apw> sforshee, ok you see the same as me
<hallyn> ok, thx :)
<apw> hallyn, so i'd not be keen to blame h/w but whatever crap is mounted on fuse
<apw> is that lxcfs :)
<hallyn> hm, could be.
<apw> sforshee, do we really hand things to uspace and wait in an uninterruptible way for it to respond, that sounds mad to me
<hallyn> in that case the only thing i can think is that the kernel builds make oom happen killing it (bc nothing else was execising fuse),
<hallyn> except i've got 42g ram
<apw> hallyn, then you'd have an oom in there
<apw> hallyn, and it looks to start right there, with something not it before
<sforshee> hallyn: going back to cgfs ... prior to my changes it was going to reuse an existing superblock. Now it still wants to but sget refuses because it's a different userns. Is that right?
<sforshee> apw: I think fuse does wait in an uninterruptible way to respond. But there is some kind of abort connection sysfs node to break those waits.
<sforshee> hallyn: it does seem to me that it will possible to hit that WARN_ON(new_sb) if using kernfs_mount_ns. Does that represent some real problem?
<sforshee> hallyn: also I'm not sure what you were getting at wrt using init_user_ns always
<sforshee> in effect that's what's happening before we have s_user_ns. But like I said I need to think it through some more.
<hallyn> sforshee: just to  make sure, you see why i need something like it right?
<hallyn> looking at fs/sysfs/mount.c, i think i just need to grab/release the ns ((i suppose sb release could be done lazily)
<sforshee> hallyn: I think so. Previously you ended up reusing a superblock, but now sget returns EBUSY because you're in a different userns.
<hallyn> right
<sforshee> and by passing a namespace you force the kernfs test function to not match the old superblock
<sforshee> but there seems to be something inherent to this code that expects to reuse the superblock in some cases
<hallyn> is there?  i was wondering that but didn't see it,
<sforshee> just look at pinned_sb
<hallyn> is there a simple way we could re-use it?
<hallyn> without hardcoding cgroupfs in sget_userns
<sforshee> well, that's where the though of doing sget_userns(..., &init_user_ns) in kernfs_mount_ns came from
<sforshee> *thought
<sforshee> or I was also considering whether maybe that check only makes sense for device-backed mounts
<hallyn> yeah it doesnt make sense for i.e. sysfs or proc, right?  you can't get another userns's mount there
<hallyn> devpts?
<hallyn> i wonder whether this will quietly break containers doing 'mount -t devpts' without -o newinstance
<hallyn> well we pass file_system_type in, so i guess we *could* filter on cgroupfs;  how would we tell whether it's blockdev-backed in sget?
<sforshee> you can't mount devpts from !init_user_ns without newinstance it appears
<hallyn> oh, good
<sforshee> there's a flag in the fs type that says whether or not it's device backed
<sforshee> FS_REQUIRES_DEV
<cristian_c> jsalisbury: hi
<hallyn> so if (type->flags & FS_REQUIRES_DEV && user_ns != old->s_user_ns) ?
<lamont> jsalisbury: finally read what you set up for me.  you have outdone expectations, thanks.
<sforshee> hallyn: yeah, something like that. Still thinking though.
<lamont> I'll smash through those sometime before the end of lunch today, expect an update in something like 2-4 hours.  I'm assuming that our final kernel is top-of-branch, with the identified commit reverted?
<sforshee> hallyn: so essentially s_user_ns is used for 2 things. First is translating ids for the backing store, which doesn't apply to psuedo filesystems.
<sforshee> the second is for privileges towards the superblock. For cgroups/sysfs do we really want root in the userns to have privileges towards the superblock?
<sforshee> though if they aren't they can't remount
<hallyn> sforshee, well in the case of cgfs cgroup_mount() guards remount, but i'm not sure about proc and sysfs
<hallyn> i would assume so
<hallyn> else that would have been an issue already since we allow mount on those
<hallyn> sforshee: it seems we canassume it's safe if it's not dev-backed and it already has FS_USERNS_MOUNT
<sforshee> hallyn: assume what's safe? Skipping the checkin in sget_userns?
<hallyn> sforshee: yes
<sforshee> hallyn: I think at minimum it's probalby okay as a interim fix while we decide what the best fix is
<xnox> bjf, what's the minimal amount of maas functionality is required to run kernel-maas testing for s390x?
<xnox> as far as can tell that enablement is currently staggnating, and i'm wonder if that can be expedited somehow.
<bjf> xnox, right now i only deal with bare-metal via maas 
<xnox> bjf, and it needs to boot to ssh right?
<bjf> xnox, yes
<xnox> bjf, and you do use the powercycle functions in maas right? e.g. poweroff/on/reboot?
<bjf> xnox, yup
<xnox> bjf, ok, cool.
<manjo> apw, I had trouble installing from the PPA due to dependcy issues .. posted it to the bug 
<manjo> apw, https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1548120
<ubot5> Launchpad bug 1548120 in initramfs-tools (Ubuntu) "[xenial][initramfs-tools] support uppercase and lowercase uuids" [High,In progress]
<apw> manjo, those deps are right
<apw> manjo, they are internal deps making sure the bits are at the same version from the same source package
<manjo> apw, hmm I have xenial-propose enabled .. 
<manjo> apw, should I disable that 1st ? 
<apw> manjo, nope shouldn't matter
<apw> manjo, did you add the ppa or download the .debs ?
<manjo> added your repo
<manjo> etc/apt/sources.list.d/apw-ubuntu-initramfs-tools-test-xenial.list
<manjo> using apt-add-repo
<apw>     initramfs-tools-bin_0.122ubuntu5~rc1_amd64.deb (81.7 KiB)
<apw>     initramfs-tools-core_0.122ubuntu5~rc1_all.deb (116.8 KiB)
<apw>     initramfs-tools_0.122ubuntu5~rc1_all.deb (84.0 KiB)
<apw> well that PPA has all three of those in there
<apw> so your deps should be found from the PPA
<manjo> initramfs-tools:
<manjo>   Installed: (none)
<manjo>   Candidate: 0.122ubuntu5~rc1
<manjo>   Version table:
<manjo>      0.122ubuntu5~rc1 500
<manjo>         500 http://ppa.launchpad.net/apw/initramfs-tools-test/ubuntu xenial/main arm64 Packages
<manjo>  Candidate: 0.122ubuntu5~rc1
<manjo>   Version table:
<manjo>      0.122ubuntu5~rc1 500
<manjo>         500 http://ppa.launchpad.net/apw/initramfs-tools-test/ubuntu xenial/main arm64 Packages
<manjo> apw, ah -bin comes from ports 
<apw> OH its bloody arm64
<manjo>   Candidate: 0.122ubuntu4
<manjo>   Version table:
<manjo>  *** 0.122ubuntu4 500
<manjo>         500 http://ports.ubuntu.com/ubuntu-ports xenial-proposed/main arm64 Packages
<apw> hang on
<manjo> ok âº 
<manjo> apw, welcome to my world 
<apw> manjo, ok in about 10m there will a ~rc2 in there built for arm64 as well
<manjo> cool 
<manjo> will post results to the bug 
<sforshee> hallyn: are you already preparing a patch for the cgfs issue or should I go ahead and make one?
<hallyn> sforshee: I'm looking at the code, but i'm not sure i'm doing it right
<hallyn> (adding an extra helper fn which tries to get the logic right of whether we need to check the user_ns)
<sforshee> sounds more complicated than what I was thinking ...
<hallyn> lemme finish tihs up and pastebin it and you can tell me i'm wrong :)
<sforshee> sounds good
<hallyn> sforshee: http://paste.ubuntu.com/15181923/ ?
<hallyn> seems to be buliding anyway
<sforshee> hallyn: I think that should work, but the FS_USERNS_MOUNT seems unnecessary
<hallyn> sforshee: so the idea of that is that any virtual fs which we cannot currently mount in a userns will be restricted to your own userns...
<hallyn> agreed not sure if it's needed, and it may be reckless...  might break things...
<hallyn> but i wasn't certain that it woudl be safe otherwise
<hallyn> no shouldn't break things - it just allows what you had designed to work the way you menat it to for those filesystems :)
<sforshee> but if you can't mount it in a user_ns then both namespaces are always init_user_ns anyway
<hallyn> sforshee: oh, youdon't relax the need for FS_USERNS_MOUNT, right
<hallyn> so you're right, shouldn't be necessary so we don't need the helper really
<hallyn> sforshee: so i'll just build and test http://paste.ubuntu.com/15181976/
<hallyn> if you can do a clenaer version of that then even better
<sforshee> hallyn: or even http://paste.ubuntu.com/15181975/
<hallyn> right
<hallyn> do you mind sending that in then? :)
<sforshee> you want to test it first?
<hallyn> is building my version enough or do you want me to do your verbatim version?
<sforshee> hallyn: I'm probably going to build my version either way before I send it, so I can just give you that version to test
<sforshee> I hate to send patches without build testing, typos can be easy to overlook
<hallyn> builds taking forever
<kamal> HerrAmeise, apw, bjf: So far, I'm unable reproduce Herr's issue.  In a 15.10 amd64 qemu vm, I can successfully boot linux-image-4.2.0-{27,28,29,30}-generic with no apparent trouble.
<bjf> kamal, thanks for looking at that
<hallyn> sforshee...  and still building.  if you get a build, so long as you can 'lxc launch cxenial x1' and x1 boots (gets >3 processes and gets an ip address) then it's good
<sforshee> hallyn: mine's still building too
<lamont> jsalisbury: back to you.
<lamont> and thanks muchly for making it less painful
<jsalisbury> lamont, thanks, I'll take a look
<lamont> it's also good to have my gut confirmed. :D
<jsalisbury> lamont, I'll build a test kernel with that commit reverted, if it fixes the bug, I'll get in touch with the patch author
<lamont> ack.  scream when
<sforshee> hallyn: http://people.canonical.com/~sforshee/cgns/, updating my vm to test it now
<lamont> jsalisbury: fwiw, http://global.shuttle.com/products/productsDetail?productId=1480
<hallyn> sforshee: success!
<hallyn> i think
<hallyn> yeah.  dunno why there is a 'lxc' cgroup there, but ...
<sforshee> hallyn: seems to work for me too
<sforshee> I'll send it
<sforshee> apw, hallyn: patch sent
<tjaalton> umm yeah disregard the pull request, I'll send a new one
<hallyn> sforshee: awesome, thx
<cristian_c> jsalisbury: hi, again
#ubuntu-kernel 2016-02-24
<tsimonq2> so the Kernel newsletter says that the current cycle is a cycle that ended three days ago, and the next cycle has already begun...what's up with that?
<tsimonq2> https://wiki.ubuntu.com/KernelTeam/Newsletter/2016-02-23 for reference
<marlinc> What would be the recommended channel to ask questions on driver related stuff. In this case its about a Iiyama touchscreen
<apw> tsimonq2, that'd be an error by the sounds of it
<apw> tsimonq2, it is easy to forget to update that, as the newsletter is weekly, but the cycles change 3 weekly
<apw> jsalisbury, ^
<apw> marlinc, you could ask here, we may redirect you after we find out what the nature of the question is
<marlinc> I've got a Iiyama ProLite T2452MTS touchscreen but its not registering anything
<marlinc> It does show up as a input device
<marlinc> Listening to it with 'input-events' doesn
<marlinc> Listening to it with 'input-events' doesn't show anything though so I'm not sure how to continue from there
<marlinc> It shows up as 'Bus 003 Device 014: ID 093a:8002 Pixart Imaging, Inc.'
<apw> marlinc, which series/kernel are you running ?
<marlinc> Description:	Ubuntu Xenial Xerus (development branch)
<marlinc> Linux marlinc-laptop 4.4.0-6-generic #21-Ubuntu SMP Tue Feb 16 20:32:27 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
<smb> marlinc, in theory this site states it should be using the generic hid-multitouch. Though it might not have an alias to load it... http://lii-enac.fr/en/architecture/linux-input/multitouch-devices.html
<marlinc> How would I try that out smb, not sure if I currently have the wrong module loaded
<smb> hm, no... I can see that id (though as hid) in the hid-multitouch driver even in Trusty... question would be whether the usb devide is bound to somehting... think that can be seen via sysfs
<marlinc> https://gist.github.com/Marlinc/7536ba44d19287233824
<marlinc> What would I have to do to check that smb 
<smb> marlinc, cannot find it again but your output shows that it got detected by the hid driver at least
<marlinc> Stuff in /sys/bus/hid/devices/0003\:093A\:8002.0011/ ?
<smb> so ls-input should list it
<marlinc> It does list it, wait
<smb> and then input-events 0 
<smb> should print events
<marlinc> The issue is that it doesn't show anything
<marlinc> https://gist.github.com/Marlinc/6c23677ccd053bf851b5
<smb> oh wait
<marlinc> Tried that already ;)
<smb> no input45?
<marlinc> https://gist.github.com/Marlinc/c6ce012dd2dccfbaf6c8
<marlinc> That's it
<smb> marlinc, seems it shows up there as event11
<smb> So input-events 11
<marlinc> Yea, that's the link above that. Doesn't show anything when I touch the screen
<smb> Hm, that would be as much as I could help. Might be broken, might be the vendor having replaced the complete internals while keeping the old id...
<marlinc> Probably not going to work then :p
<marlinc> Lets see if I can find a manual that hopefully has information on the support
<marlinc> Might have to enable it, not sure
<marlinc> Ah, I guess it does work. You appear to need a 'touchpen'
<marlinc> Which doesn't do anything
<smb> That sounds a bit backwards... with everything being touch with ones fingers nowadays... 
<marlinc> Mm should support finger touch as well..
<marlinc> Then I guess its broken
<smb> marlinc, Could be. Though I would not say I am absolutely sure there. 
<marlinc> Yea, I guess there's no way to test that so :p
<marlinc> Wait there is, I can at least see if there's 'traffic' going over the USB connection with Wireshark
<marlinc> Interesting, its trying to access the stream from the wrong path. Its trying to open it from /sys/kernel/debug/usbmon/0t but its in /sys/kernel/debug/usb/usbmon/0t
<marlinc> I can't create symlinks in /sys so that's a bit problematic :P
<marlinc> smb, ^?
<smb> marlinc, erm, that would be wireshark using the path, wouldn't it? 
<marlinc> tcpdump has the same issue
<marlinc> https://bugs.launchpad.net/ubuntu/+source/libpcap/+bug/523349
<ubot5> Launchpad bug 523349 in libpcap (Ubuntu) "Bad /sys path to text-based usbmon" [High,Fix released]
<marlinc> This is the exact issue
<marlinc> That patch would fix it even
<marlinc> Not sure why the bug is back
<smb> marlinc, that could be that the wireshark package got rebased and accidentally dropped a fix. I have not looked there though. At least the kernel path did not change that recently its the usb/usbmon in  3.13 already
<marlinc> Do I have to re-open the issue smb?
<smb> marlinc, Generally its better to report it as a new bug (even if then someone marks it duplicate). But imo its a new issue to have the wrong path again. In theory you should be able to use "ubuntu-bug wireshark"
<marlinc> It doesn't appear to be an issue in wireshark. Its an issue in libpcap. tcpdump has the same issue
<genkgo> hello, i read everywhere that linux kernel 4 can be updated without reboot. i am on trusty (14.04.3) with wily kernels. now i upgraded from 4.2.0-27 to 4.2.0-30. but now uname -a still says 4.2.0-27. how can i update without the reboot?
<smb> ah ok... so just to replace wireshark with pcap I guess... hope...
<smb> I mean libpcap 
<smb> whatever the package name is
<smb> genkgo, not at all with 4.2. You mean life-patching and that is not supported at all before 4.4. And even with it being possible, it does not mean you can update complete kernels without reboot. There are technical limitations to what can be done without reboot. And even what can be done needs to be provided in a special format.
<genkgo> smb: ok, thanks for the explanation. so basically, i just need to reboot, right?
<genkgo> for the update from 4.2.0-27 to 4.2.0-30?
<smb> marlinc, One other thing you might try is to try a newer mainline kernel (and personally I would enable grub menu to do that)
<smb> genkgo, yes
<genkgo> alright, thanks
<smb> marlinc, Just happened to see some enlantech related stable patch (pulled back from 4.5) on some mailing list. Could be totally unrelated but before having to talk to some support hotline...
<marlinc> I could try a new kernel smb 
<marlinc> I have ZFS as root fs so I can simply clone the existing FS and play with that
<marlinc> Yesterday I played with unity8 that way
<marlinc> How would I go about doing that smb?
<genkgo> smb: i have another question. i have three ubuntu machines. two are running linux-image-4.2.0-30-generic, but one is running linux-image-4.2.0-31-generic. how come that that machine picks up 31 while the others do not?
<smb> marlinc, Hm, rather carefully in that case. If you download and install one of http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D you have to be careful to check whether the zfs dkms module still builds. Otherwise there will be panic (first the kernel and then probably you ;)) Thats why I suggest changing grub to remove the hidden timeout
<smb> genkgo, Could be that you enabled proposed on that one machine in the past
<genkgo> smb, that could be, how can i look that up?
<marlinc> Well I guess I have to manually compile ZFS in that case as DKMS is no longer being used in 16.04 for ZFS
<genkgo> smb: "deb http://ppa.launchpad.net/canonical-kernel-team/ppa/ubuntu trusty main"
<smb> genkgo, either via gui software sources (I think) or grep proposed /etc/apt/sources.list
<genkgo> smb does not pick up proposed?
<genkgo> does that pick up proposed?
<smb> marlinc, Oh right. forgot that got switched
<smb> genkgo, actually that picks up packages as soon as they get uploaded... not sure that should be there by default
<smb> genkgo, kernels get uploaded and built there and then copied to the proposed pocket. So I would disable the ppa and just enable the proposed pocket (if you want to have kernels as soon as they get into testing and bug verification)
<smb> marlinc, Might be much less painful if you had some other box using a more traditional fs to attach to that touchscreen for experiments...
<genkgo> smb, thanks, i will remove the ppa
<genkgo> smb, i was involved in bug verification, so i think i left it there
<smb> genkgo, Hm... maybe at some point in the past that was done that way. But nowadays I would say there is absolutely no need (rather being dangerous) to have the ppa enabled.
<genkgo> smb: it was, back then i need to upgrade to vivid kernels. nowadays i can install -vivid and -wily.
<tsimonq2> apw: alright thanks :)
<dannf> ogasawara: i think i have a pull request stuck in moderation - would you mind taking a look? also - i'm curious about why mailman hates about my mail - let me know if its something i can change on my end.
<manjo> apw, anything else you need from me on https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1548120/ ? 
<ubot5> Launchpad bug 1548120 in initramfs-tools (Ubuntu) "[xenial][initramfs-tools] support uppercase and lowercase uuids" [High,In progress]
<ogasawara> dannf: heya, sorry was on a call.  I just checked the queue and I didn't see anything from you.  What was the subject line?
<ogasawara> dannf: maybe someone beat me to moderating it
<apw> manjo, nope, all uploaded, waiting on the grinders to grind
<dannf> ogasawara: np. weird...[PULL][Xenial] Fix ARM KVM guest hangs w/ host ntp
<apw> dannf, i think i moderated that before today, odd
<manjo> apw, thanks a ton .. the bug is still marked inprogress and block-proposed I think ... 
<apw> manjo, don't worry
<manjo> ok âº 
<manjo> apw, cust is watching that bug ... so brought it up 
<dannf> apw: oh weird - ok. i just didn't see it come in via the list. /me checks archive
<dannf> apw: curious - what is causing my msgs to get moderated?
<dannf> apw: yep - msg is in the archive. sorry for the false alarm, i'll blame gmail :)
<apw> you must be subscribed to the list under a different alias to you are sending, like for me apw@ or andy.foo@
<ogasawara> dannf: indeed, I see you subscribed as dannf@ubuntu.com
<dannf> ogasawara: ah, i can fix that.
<lamont> jsalisbury: all yours, sir.  I threw some additional info at the bug, too.
<jsalisbury> lamont, great, thanks
<cristian_c> jsalisbury: hi
<jsalisbury> cristian_c, hello
<lamont> jsalisbury: presumably there should be no issue with me just living on this kernel, true?
<jsalisbury> lamont, ther shouldn't be.  It's the stock kernel with a single revert.
<lamont> woot
<lamont> I shall test it with passion then
<lamont> (that is to say, I
<lamont> ll keep using it)
<jsalisbury> lamont, great.  I'll contact the upstream patch author for feedback
<lamont> it's entirely possible that his delay is simply too short
<lamont> actually.... wanna unrevert that, make the delay 3 seconds, and toss me the resulting kernel?
<lamont> because 2 orders of magnitude should do the trick, right?
<lamont> I almost tried building a kernel in that bisect, but there was no debian/ directory, and I decided that life was short
<jsalisbury> heh, yeah, I'll build you another kernel
<lamont> I'm totally going off of memory on the commit loog talking about a  30 (or 50) mSec delay
<jsalisbury> lamont, looking at the patch, it does 3 retries at 10ms each for a total of 30ms
<cristian_c> jsalisbury: have you taken a look at my patch?
<lamont> jsalisbury: make it 300 retries and log how many after it passes?
<lamont> :D
<lamont> this is a big rock, I admit
<jsalisbury> cristian_c, I have not yet.  I can submit it upstream for you if you want, or post directions in the bug
<cristian_c> jsalisbury: what do you suggest?
<jsalisbury> lamont, worth a try.  I'll also ping upstream and see what they think.
<jsalisbury> cristian_c, either way is fine.  I can try to submit it this week.
<lamont> jsalisbury: definitely logging the count, because I expect that to be hilarious
<cristian_c> jsalisbury: ok
#ubuntu-kernel 2016-02-25
<dileks_webchat> hi
<dileks_webchat> I am not sure if this is the correct channel for asking
<dileks_webchat> but according to release-schedule xenial-b1 shall be available for download
<dileks_webchat> today
<dileks_webchat> did that happen? if yes can you point me to the download-url?
<dileks_webchat> OK, I found https://wiki.ubuntu.com/XenialXerus/Beta1 which offers some iso-images
<dileks_webchat> away again, hehe
<snonez> hi, I have a question about kdump, http://stackoverflow.com/questions/29448158/enable-kdump-on-a-compiled-linux-kernel, 
<snonez> the answer here doesn't solve the problem, 
<apw> snonez, alwys helpfil to know what the problem is that you are seeing
<apw> and also if you could give us some background as to what you are trying to do
<Madkiss> We have just confirmed that https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1505948 also affects the Ubuntu standard kernel for Xenial :(
<ubot5`> Launchpad bug 1505948 in linux (Ubuntu Wily) "Memory arena corruption with FUSE (was Memory allocation failure crashes kernel hard, presumably related to FUSE)" [High,Confirmed]
<snonez> apw, the problem is here, http://stackoverflow.com/questions/29448158/enable-kdump-on-a-compiled-linux-kernel 
<apw> Madkiss, this is the one (iirc) where if you use the "next" version of fuse which uses async IO things explode right ?
<Madkiss> apw: correct
<apw> Madkiss, phew, ok, i think we knew it would affect the main kernle, that this was likely a gneeric issue, i'll read the current status shortly
<apw> snonez, so your load fails with "no hole found" yes ?
<apw> snonez, what crashkernel= setting are you using on the kernel command line ?
<snonez> apw: yes, "Could not find a free area of memory of *** bytes..."
<snonez> "locate_hole failed"
<snonez> * failed to load kdump kernel
<snonez> apw: crashkernel=384M-:128M   the default value
<apw> snonez, and this is a self compiled kernel i think, is the config somewhere ?
<apw> snonez, and is this your actual value: 0x9521000 bytes
<snonez> no, it comes from the orig config 
<snonez> apw: 0x9ba5000
<apw> snonez, so ... that is 163205120 bytes, or 155.6M which is more than 128M so ... it won't fit
<snonez> apw: make it bigger?
<apw> worth a try 
<apw> snonez, as an experiment i'd make it -:256M and see if that makes the issue go away
<Madkiss> apw: I think the reason we're not seeing more reports of this until now is that the libfuse in 14.04 deoes not support AIO.
<snonez> apw, it works,, 
<apw> snonez, did you say that you built your own kernel here, how big is your vmlinux that it wouldn't fix there
<snonez> I make it 256M and the error msg gone
<Madkiss> apw: once we have a newer version of libfuse, we're likely to see more users running into this.
<apw> Madkiss, yep this needs to be fixed, with luck we won't get hat version in xenial, so we have a little time to find and fix it in YY
<Madkiss> apw: I'm trying to figure out what exact libfuse version contains the problematic code.
<apw> Madkiss, thanks, if you could put that in the bug tooo so the info is all in one place
<apw> i really need a reproduce by, but i've not had time to sit with th eproblem and think about it since last time we talked
<snonez> apw: vmlinuz or vmlinux?
<apw> both
<snonez> apw, vmlinuz 6446944, vmlinux 356899822
<apw> that doesn't seem so big, if you are loading vmlinuz, hrm
 * cking wonders if it's been allocated, one can check with cat /proc/iomem  | grep Crash
<snonez> apw, the orig kernel size(vmlinuz) is bigger than the one i build
<apw> snonez, yeah, all a bit odd
<dileks_webchat> hi apw long time no see/read
<dileks_webchat> bye
<snonez> apw, thx 
<Madkiss> apw: my understanding is that the libfuse version in our local setup is libfuse3, which is currently not included in Ubuntu 14.04.
<Madkiss> I would, however, like to point out that under no circumstances should a kernel crash, and I am rather sure this is not even related at all to libfuse directly.
<Madkiss> I assume that libfuse3 triggers a function that makes the kernel run into a panic. However, any user being allowed to use fuse will likely be able to do the same, and hence crash the system.
<Madkiss> apw: Would you be willing to look into the problem if we deliver some piece of code that reliably crashes a Xenial system where fuse is in the kernel?
<Madkiss> when executed as a user?
<apw> Madkiss, concur you should never be able to crash a kernel, the primary concern close to release is that this is not osmething that users will hit easily
<apw> Madkiss, if you have a reproduce by that will trigger it then yes i would like to have me or someone here look at it
<luc4> Hello! My ubuntu laptop seems to have a couple of issues when resuming from stand by. Both keyboard and trackpad frequently wake up dead. I'd file a bug report for this, but what kernel should I use for the test? Latest in repo? I'm typically asked to install some other kernels from some other source.
<apw> luc4, you should update to the archive latest and confirm the bug there, then report it against that
<apw> luc4, the next steps are often to test other "nearby" kernels to determine where if any a fix exists
<luc4> apw: sorry, pc went to standby :-D so here http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D? v4.5-rc5-wily?
<apw> luc4, no as in letting update manager install the latest (or apt-get dist-upgrade)
<apw> we care that that one is broken
<apw> (or not
<apw> and then you will likely get asked to test some of those mainline kernels to confirm if like v4.5 is broken as part of diagnosis
<luc4> apw: sorry, not sure I understand. I'm now using the latest from apt. Is there anything else I should test?
<apw> but your bug should be filed from an ubuntu kernel which has the issue if at all possible (some bugs not so much)
<apw> you asked wehre you should file a bug, file it against archive latest
<apw> yes you can then test the highest v4.5-rc that you found
<luc4> apw: ah ok, now I'm using 4.2.0-30-generic. I should file against that.
<apw> yes because that is what you want fixed, the archive kernel for your series
<luc4> apw: thanks!
<snonez> apw, sry to bother you again, how many minutes does kdump takes, which level do you set?
<snonez> I set level 17, x86_64, 18 minutes, still running
<Madkiss> apw: alright, I will see what I can do.
<apw> 18m sounds like a long time to dump to me, but i can't say i dump large amchines very often
<tjaalton> apw: hey, I'm not seeing my stuff on xenial master-next? tseliot would rebase his on top because some core drm commits are shared
<apw> tjaalton, UBUNTU: SAUCE: i915_bpo: Revert "drm/i915: Switch DDC when reading the EDID" looks to be on there to me
<tjaalton> apw: hmm where is that? I have lp as the main source
<tjaalton> something happening now :)
<tjaalton> or just my local clone not set up properly
<tjaalton> git fetch does nothing
<tjaalton> git fetch origin works
<tjaalton> yep, it's all good
<lamont> jsalisbury: I stand corrected - the 300 retry kernel resulted in one display, not two
<lamont> bug updated
<jsalisbury> lamont, ack, thanks for testing.  I'll take a look
<jsalisbury> lamont, I'm talking with upstream about the bug.  I posted a link to the upstream thread in the bug.  Can you post the monitor type and the type of cable used?
<lamont> sure
<jsalisbury> lamont, they state that a single link dvi/hdmi cable didnât work and dual link worked
<lamont> single link dvi-d cable it is
<jsalisbury> lamont, great, thanks.  I'll update upstream
<lamont> not sure whether or not a dual-link is possible for the other end
<lamont> nah... it looks like it could take dual-link
 * lamont jsut deosn't have one
<jsalisbury> lamont, ack, it looks like they are coming up with patches, so I can build a new kernel for you once one is available.
<lamont> nice
<sorinello> hello. can someone giver me an estimate until https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1548587 hits the official channels ?
<ubot5`> Launchpad bug 1548587 in linux (Ubuntu Wily) "Ubuntu 15.10 VMWare guest won't show UI after upgrading to 4.2.0-30" [High,In progress]
<apw> kamal, ^
<kamal> sorinello, apw: the team is discussing that now.  I'll let you know when we know.
<sorinello> thanks a lot kamal , apw 
#ubuntu-kernel 2016-02-26
<kamal> sorinello, the fixed wily kernel package for bug 1548587 is in the pipeline now -- will be version (4.2.0-30.36), and should be available in the archive "soon" (by tomorrow)
<ubot5`> bug 1548587 in linux (Ubuntu Wily) "Ubuntu 15.10 VMWare guest won't show UI after upgrading to 4.2.0-30" [High,In progress] https://launchpad.net/bugs/1548587
<kamal> ... the lts-wily version of that kernel (for Trusty) should be released tomorrow also.
<sorinello> thanks kamal for the info !
<ogra_> apw, seeing your linux-goldfish upload, is there any reason to not just rip that out of the archive before xenial ? 
<ogra_> oh, ignore me ... mixed that up with maguro 
<apw> ogra_, well that is a good question :)  i'd not be unhappy ripping all or any of the others out given the images are vivid based
<ogra_> well, as i said, i mixed it up ... goldfish is the emulator so we will most likely want to keep it
<ogra_> at some point the phnoes will have to move to xenial .... 
<apw> all true
<stgraber> apw: any idea when we'll be getting the -8 kernel in the release pocket?
<stgraber> I'm getting tired of triaging bugs caused by the broken cgns in -7
<stgraber> (getting around a dozen a day through e-mail, LP and github)
<apw> stgraber, its only been built a little while
<apw> its testing now
<stgraber> apw: LP tells me it's been built for 2 days
<apw> yes but that is a lie as it is when it was uploaded not when it was accepted
<stgraber> ah, got stuck in NEW for a while?
<apw> it was held in new for the beta
<stgraber> hmm, kay, not sure why that was but fine
<apw> there was a freeze in place, dunno ?
<stgraber> I can see why we wouldn't have wanted it into the release pocket for the beta, but it wouldn't have hurt to have it in proposed
<stgraber> which would have let us go through all the adt stuff and whatnot and then let it through as soon as beta was out
<stgraber> anyway, too late for that now :)
<apw> yep
<kamal> infinity, https://launchpad.net/ubuntu/vivid/+queue?queue_state=1   waiting for approval
<infinity> kamal: Ta.
#ubuntu-kernel 2016-02-27
<cpt_rumplebump> hi, i've been sent here from the linux mint irc. i have a sb live 5.1 pci installed, snd-emu10k1 is loaded, but the card doesn't show up in /proc/asound/cards and i can't use it. i've already installed 4.2.0-30-generic, but that didn't help. any ideas?
<cpt_rumplebump> 'lspci -nn' shows: 08:01.0 Multimedia audio controller [0401]: Creative Labs SB Live! EMU10k1 [1102:0002] (rev 0a)
<HerrAmeise> apw: whatever updates you guys just pushed fixed the issue I was having with kernel 4.2.0-30-generic from a few days ago
<HerrAmeise> boots fine now
<apw> HerrAmeise: vmware guest i assume
#ubuntu-kernel 2017-02-20
<zyga> what is the best way to detect a genuine ubuntu kernel?
<zyga> vs some other kernel?
<apw> zyga, from what context, the only absolute way is to confirm the kernel binary is not modified relative to the package and the package is from the official archive
<zyga> apw: cloud providers often boot a different kernel 
<zyga> apw: we may have the package on disk but it is not used
<zyga> apw: I was wondering if we could put something into our kernel that we could ask from userspace for
<zyga> apw: e.g a dummy module that says "this is a certified Linux kernel from Caonical"
<apw> zyga, how would you guarentee that the cloud provider did not also dothat
<apw> in order to not seem different from ours
<zyga> apw: so that even if they fake that (on purpose) we can have a legal standing that they cannot do thus
<zyga> apw: and if they don't do this it is easy detect 
<zyga> apw: yes but if they do it on purpose we can do other things
<zyga> apw: I'm after casual kernel replacement, not mailciou actor
<zyga> *malicious
<zyga> apw: e.g. a module that adds a file to sysfs that says "this is a certified Linux kernel, designed for Ubuntu, from Canonical"
<apw> zyga, i assume a non-malicious kernel in that context would have a non-standard version number
<zyga> apw: yes but what is our version number?
<zyga> apw: what can I check for in userspace to easily know "certified kernel"
<apw> zyga, launchpad knows what our officially released version numbers are, and they have a standard form
<zyga> apw: complicated
<apw> anyone modifying the kernel has to avoid our namespace
<zyga> apw: I need to make a spot decision when I see !ubuntu kernel
<zyga> wait, what is our namespace?
<zyga> I don't see any ubuntu / canonical words in  'uname -a'
<apw> the problem is anything we do in our packaging would likely be copied to the cloud-vendor kernel
<apw> so if we add something saying it is certified, theirs will also say that
<zyga> that's much better
<apw> ?
<zyga> because then we can use trademark law to smite such use
<zyga> right now we don't have any way to detect misuse 
<zyga> or a way to react really
<zyga> we'd be fixing one of those at least
<apw> hmmm
<zyga> + if they read the kernel patches from us we could ensure the module has very clear language
<zyga> that the intent of the module is to signify a certified canonical kernel
<zyga> and it should not be copied without an agreement with canonical
<zyga> as that would signify trademark violation
<apw> i am not sure our licencing would let us do that
<zyga> which licensing?
<zyga> we keep saying you get to call it ubuntu if it is unmodified
<apw> that this is a gpl 2 package
<zyga> that's fine
<zyga> they _can_ legally include that module
<zyga> but they cannot legally use the trademark
<zyga> this is mozilla firefox vs iceweasel issue
<apw> but are we fixing the right issue
<apw> you want to know the running kernel is (assuming non-malicious actors) 
<apw> from us.  why is the fact it is in a signed package from us not the right thing
<apw> that is how we assert that things came from us
<apw> so you can safely consume them
<zyga> apw: hmmm, because the package is not a running thing, I just booted linode instance of 16.04 and it has our kernel installed
<zyga> but not in use
<zyga> the VM gets booted with an external kernel
<apw> right but you can tell which kernel is running
<zyga> I don't think that looking at the package can ehlp
<apw> matching its version number
<apw> if you don't have a package matching it, your are not ubuntu
<apw> if you don't have a package signed by us matching it, you are not ubuntu
<zyga> another problem is that this would not work in core world easily
<zyga> (e.g. packaging formats differ)
<zyga> I'd much rather ask the kernel about itself
<apw> what are we going to be gating on this informaito
<zyga> I want to include this in the error report we're sending to daisy.ubuntu.com
<zyga> along with whatever kernel version we get
<zyga> we suspect there's a large population of errors caused by replaced kernels on cloud systems
<zyga> I'd really like that trivial (GPL2) module that just uses our trademarks
<zyga> even if people can spoof that
<apw> so we can tell if people are using legit version numbers on our end if this is daisy
<apw> we do that kind of thing to bin launchpad bugs for reports which are on modified kernels
<apw> already.
<apw> do we have a case where people are making kernels with versions that look like ours
<zyga> do you have some more data about this?
<apw> or is this hyperthetical attack?
<zyga> ah
<zyga> sorry I misread your qeustion
<apw> more data?  as in how we decide if things are legit?
<zyga> question*
<zyga> no, no; I skipped the "do" in your last statement
<apw> ahh
<zyga> I don't know of such kernels but I'm still making a sweep through pouplar cloud providers
<zyga> but we did see ancient / or current but heavily modified kernels as the norm
<zyga> and they all disable security
<apw> you could probabally argue, if you were going to, that /proc/version_signature includes our trademark for this purpose
<zyga> oh
<zyga> that's perfect!
<apw> and we use the version in there and/or the version in /proc/version to determine if this is
<zyga> I didn't know about this file (I kept looking at sys)
<apw> a valid kernel
<apw> from us.
<zyga> thanks, I think this will do!
<zyga> I'll re-check what each cloud says there
<apw> i am pretty sure the version in there is reliable enough for most purposes
<zyga> I think so as well
<apw> and you can compare it against published versions in launchpad easily enough
<zyga> thank you apw, I think I can keep myself busy for a while :")
<kaynemo> hello all ! upgraded to 4.4.0-63-powerpc64-smp kernel today and lost networking on ehternet (seems that module doesn't load up), rebooted to previous kernel (currently running it) and the network is just fine. Any ideas?
<apw> kaynemo, do you have the appropriate meta packages installed or did you hand install that change
<kaynemo> well it was the result of sudo apt-get dist-upgrade command
<apw> then you have the right things installed
<kaynemo> which is weird, because it will not bring up the network no matter what I do
<apw> kaynemo, which driver is used when it does work
<kaynemo> how to check that ?
<apw> ls -l /sys/class/net/wlp3s0/device/driver
<apw> that sort of thing
<kaynemo> cant find file or directory
<apw> kaynemo, you did sub in an appropriate device right ?  and on the working kernel
<kaynemo> well yeah
<apw> well if that doesn't exist, then hmm, but lsmod and guess
<kaynemo> lsmod is a long list and I can't find the network one
<kaynemo> lspci and find command lead to r8169 driver
<kaynemo> bump
<kaynemo> ummm.... anyone to comment on what happens with the ethernet on the 4.4.0-63-powerpc64-smp kernel ?
<apw> kaynemo, hmmm
<kaynemo> it's not that I cannot live without a new kernel and all, but, you know, a) it is weird, b) reluctant to upgrade from now on ))) also curious )))
<apw> kaynemo, nothing obvious in teh delta from -62 ... -63 so ... thats odd ...
<apw> kaynemo, next thing to do is file a bug against the kernel (ubuntu-bug linux) and tell me the bug number
<apw> kaynemo, and i will ask one of my collegues to help you bisect it
<kaynemo> thank you !
<kaynemo> will do so
<kaynemo> Bug #1666209
<ubot5> bug 1666209 in linux (Ubuntu) "PPC new 4.4.0-63-powerpc63-smp kernel kills networking" [Undecided,New] https://launchpad.net/bugs/1666209
<apw> kaynemo, ta
<rtg> tseliot, we're seeing i386 ADT test failure on nVidia 375. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/i386/n/nvidia-graphics-drivers-375/20170216_141621_af1c4@/log.gz
<tseliot> rtg: maybe the i386 chroot/machine has a problem? I don't see how this and the DKMS dependency thing can depend on my packages: "ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored."
<tseliot> rtg: oh, bad build too, can I get the log, please?
 * tseliot has no i386 hardware
<tseliot> rtg: I mean this /var/lib/dkms/nvidia-375/375.39/build/make.log
<rtg> tseliot, you can install in an i386 VM which a least would give you the compile errors
<rtg> tseliot, ADT doesn't keep logs like that frm an ephemeral session
<apw> rtg, yes it does keep those logs
 * apw files you a bug, one sec
<rtg> apw, indeed ?
<tseliot> that would sure save me some time
<apw> rtg, yep, there is an artifacts.tar.gz thing with all sorts of crapola in it
<apw> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-375/+bug/1666220
<ubot5> Ubuntu bug 1666220 in nvidia-graphics-drivers-375 (Ubuntu) "nvidia-graphics-drivers-375 375.39-0ubuntu1 ADT test failure with linux 4.10.0-8.10" [Undecided,New]
<apw> tseliot, ^
<tseliot> apw: oh, the error looks familiar, thanks
<tseliot> apw, rtg: that build failure is weird. NVIDIA already set a test for that in their conftest.sh: http://pastebin.ubuntu.com/24034020/
<tseliot> I'm not quite sure why that would be different on i386
<apw> indeed
<rtg> tseliot, I'm not gonna hold up promotion to release over that, but I'd sure like to see it fixed eventually
<tseliot> rtg: I going to brute force that into building, so it shouldn't really be a problem any more anyway ;)
<tseliot> rtg: by doing this http://paste.ubuntu.com/24034067/
<tseliot> the cast is probably useless
<apw> tseliot, that is "interesting"
<apw> tseliot, but very sensible
<tseliot> apw: heh, it's a temporary workaround
<apw> tseliot, what does the double cast even mean in that context
<apw> anyhow, whatever, it isn't your code
<tseliot> apw: it should be for the size, I think. I had the same problem when I had to call this:
<tseliot> NV_SMP_CALL_FUNCTION(nv_setup_pat_entries, (void *)(long int)hcpu, 1)
<apw> yeah i guess it widens it first, but uggg
<tseliot> yes, I know... :D
<apw> tseliot, anyhow thanks for looking ... appreciated
<tseliot> apw: you're welcome ;)
<tseliot> I'm going to test (using virtualbox) and upload
<apw> tseliot, ack ta
<tseliot> ...and no internet connection from virtualbox...
#ubuntu-kernel 2017-02-21
<zyga> hi, I want to ask about the new kernel snap for snappy systems, what is the release plan for those?
<bjf> zyga, we should be getting a pc-kernel snap our "real soon now" that matches -updates. there is a regression with snappy that we are chasing
<ogra_> oh ? 
<ogra_> that would be the first snappy regression wrt kernel snap :)
<ogra_> interesting
<bjf> ogra_, it's not a snappy regression. it's a regression with the kernel in -proposed. we've not built a snap from it yet
<ogra_> ah :)
<cyphermox> have we made any changes to schedulers or something that could explain firefox/VMs freezing up regularly? I get fairly regular grey windows on a new install?
<apw> 4.9 or 4
<apw> 4.10, that might be realted to that systemd cgroups change they were talking about
<zyga> bjf: do you have any details about the regression?
<bjf> zyga, https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1665280
<ubot5> Ubuntu bug 1665280 in linux-raspi2 (Ubuntu) "Boot into emergency mode on RPi2 with proposed kernel 4.4.0-1043.50 after system update" [Undecided,New]
<zyga> bjf: thank you
#ubuntu-kernel 2017-02-22
<erle-> which kernel module is in charge for cpu frequency nowadays
<erle-> ?
<erle-> (recent i7)
<apw> intel-idle
#ubuntu-kernel 2017-02-23
<chatter> hey guys
<chatter> allah is doing
<Guest56363> sun is not doing allah is doing
<Guest56363> to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger
<WeiJunLi> i've recompiled a kernel and now while booting it get stuck on a kernel panic - not syncing: softluckup: hung tasks - what can i do to solve the issue
#ubuntu-kernel 2017-02-24
<mkevac> Hi. I want to install latest kernel on my Ubuntu 16.10. I've found packages here http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.10/, but there are no packages for perf util. And I am updating kernel for perf mostly.
<mkevac> What is the simplest way to get latest kernel version with perf?
<mkevac> As far as I understand next version of Ubuntu (Zeisty) has 4.10 kernel with correct perf packages, but I could not yet figure out how to use Zeisty repo for these packages only on my 16.10.
<mkevac> This guy here has the same question: http://askubuntu.com/questions/875883/installing-perf-tools-with-custom-kernel
<apw> mkevac, you likely do not want the packages from the mainline builds. those as you say do not include tools nor do they include any of the ubuntu delta
<mkevac> How do I get latest stable kernel then? Or, let's simplify, how do I get 4.10 with perf on my 16.10?
<apw> mkevac, we don't provide kernels for 16.10 like there.  there are kernels for 16.04 officially supplied, but not quite yet as 4.10 is only just arriving in zesty
<apw> mkevac, you could potentially copy those kernels out of zesty into a PPA in xenial but you would have to do so manually
<apw> mkevac, and there is no guarentee that perf will work with that userspace
<mkevac> I'll try copying. Thank you.
<mamarley> apw: Do you know when the mainline kernels are going to start being compiled on Zesty instead of Yakkety?  I'm just curious because I thought I had remembered them switching to Yakkety before this point when Yakkety was being developed.
<apw> mamarley, normally it is the nearest release, so depends on the mainline version
<apw> mamarley, which mainline one was on the wrong one ?
<mamarley> apw: It is using the kernel config for Zesty, but it is compiling on Yakkety using the Yakkety toolchain (see http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.10/BUILD.LOG.amd64, for example)
<apw> mamarley, that sounds wrong
<apw> mamarley, i've added it to my list to investigate
<mamarley> apw: OK, thanks!
<dcnoderunner-t61> jsalisbury: Do you mind if I msg you?
<theriesnocow> is there a page that has the testing process that happens before releasing a new kernel to LTS?
<theriesnocow> no answer is an answer in itself :P
#ubuntu-kernel 2017-02-25
<ogra_> theriesnocow, well, it is 1am on a friday (in europe) ... 
<ogra_> what do you expect :)
<ogra_> come back during the week during working hours :)
<theriesnocow> saturday, but sure
<theriesnocow> Unless no one in the North/South American continents knows, then I can wait until Monday
<gentoo> What is the syntax for building a kernel for only a single arch? The help page looks to show building everything.
<gentoo> do the ciphers in menuconfig determiine what dmcrypt/luks is capable of?
<gentoo> do the ciphers in menuconfig proterm quo dmcrypt/luks is capable of?
#ubuntu-kernel 2017-02-26
<apw> gentoo (N,BFTL), yes the ciphers determine the maximum support of dmcrypt/luks
#ubuntu-kernel 2018-02-19
<hallyn> jsalisbury: https://wiki.ubuntu.com/Kernel/   points to https://wiki.ubuntu.com/Kernel/Release , which does not exist
<hallyn> hm, lxd network under hwe kernel on xenial seems busted?
<hallyn> maybe i messed up something else, still comparing...
<hallyn> jjohansen: running linux-generic-hwe-16.04 on a xenial host.  it doesn't have the apparmor stacking fix?
<hallyn> is there a scheduled release of thatkernel with that fix?
<hallyn> do i have to wait until august?
<hallyn> oh should i use -edge?
 * hallyn tries
<hallyn> prolly living on the edge at this point
<hallyn> no even that doesn't fix it.
<hallyn> jjohansen: stgraber: do you know of a list that woudl show which kernels for xenial would have the apparmor ns fix ? 
<hallyn> looking for that plus namespaced filecaps (else i'd just stick with 4.4)
<hallyn> i'm surprised hwe-16.04-edge doesn't work
<stgraber> oh right, you're hitting the broken ns support because of empty label thing again
<hallyn> right.  is that fix only going into artful and bionic?
<stgraber> it should go everywhere once it finally lands...
<stgraber> want the ugly workaround until then?
<stgraber> echo lxd-$(hostname) > /root/ns
<stgraber> mount --bind /root/ns /sys/kernel/security/apparmor/.ns_name
<stgraber> systemctl restart apparmor
<stgraber> hallyn: ^ I said it's ugly :)
<TJ-> wow! thanks stgraber I have been wondering about that one as well
<hallyn> stgraber: I'm wondering when "whenit finally lands" will be :)
<hallyn> hm, what would be the easiest way to automated that.
<hallyn> i guess a systemd service in the images :(
<hallyn> thanks stgraber i guess i'll go that route :)
<jjohansen> hallyn: hrmmm, I'll have to dig, I did send the fix to the kt
<hallyn> jjohansen: thx, here's hoping it goes in soon :)
<hallyn> for now i've just updated the lxd images to add a startup job with stgraber's fix
<jjohansen> hallyn: it seems to have been dropped, probably in one of the many rebases during the whole spectre/meltdown mess
<jjohansen> I will resend
<hallyn> cool, thanks
#ubuntu-kernel 2018-02-20
<apw> jjohansen: it is likely in -backlog
<caribou> cascardo
<caribou> oops, sorry!
<zioproto> How could I figure out if the kernel package 4.4.0.116.122 from xenial-proposed includes the fix from LP 1738219 ?
<ubot5> Launchpad bug 1738219 in linux (Ubuntu Bionic) "the kernel is blackholing IPv6 packets to linkdown nexthops" [Medium,In progress] https://launchpad.net/bugs/1738219
<TJ-> zioproto: check the changelog in /usr/share/docs/<package-name>/changelog.Debian.gz
<TJ-> zioproto: e.g. "less /usr/share/doc/linux-image-4.13.0-32-lowlatency/changlog.Debian.gz"
<zioproto> OK. I wonder if there was a way to check before installing the package
<zioproto> thanks 
<zioproto> OK I checked and LP 1738219 is never mentioned. But the status fix committed of the bug should mean that there are proposed packages ???
<ubot5> Launchpad bug 1738219 in linux (Ubuntu Bionic) "the kernel is blackholing IPv6 packets to linkdown nexthops" [Medium,In progress] https://launchpad.net/bugs/1738219
<jjohansen> apw: doh yeah its in the backlog
<apw> jjohansen, if this is something which is setting someones hair on fire we could do with being pointed to it
<apw> jjohansen, so we can put it on the respin list at least
<jjohansen> hallyn: its in the backlog, so not dropped but caught up in the whole spectre/meltdown mess
<jjohansen> apw: yeah it would be good if we could do that as it is affecting lxd
<apw> not making any promises but at least if it is on the lsit we can include it if we do
<jjohansen> but I get spectre/meltdown are uhm very time consuming
<thresh> hey.  I'm having this kernel panic after ~month of uptime on linux-image-extra-4.13.0-25-generic_4.13.0-25.29~lp1742721 - http://thre.sh/stuff/kernel-panic-lp1742721.png
<thresh> any advises?
<thresh> that's on 16.04
<kasper93> Is this guide complete? https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel I need to change some cfg, but the problem is custom build kernel doesn't boot... last log is about detected keyboard and after that it hangs and watchdogs kicks in.
<dupondje> who manages the config of daily kernel builds?
<dupondje> apw: perhaps? :)
<dupondje> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/misc/cardreader/Kconfig?h=v4.16-rc2&id=e455b69ddf9b69326d0cab28d374faf3325489c9
<dupondje> if this could be enabled ... :)
<dupondje> # CONFIG_MISC_RTSX is not set
<dupondje> # CONFIG_MISC_RTSX_PCI is not set
<dupondje> # CONFIG_MISC_RTSX_USB is not set
<apw> dupondje: mostly it is automated and whatever the default is
#ubuntu-kernel 2018-02-21
<dupondje> apw: to bad, cause my SD-card reader is useless now with daily kernels :)
 * apw will have a think about it
<apw> :q
<caribou> Good morning, are there any plans to deliver xenial kernels with the gcc-5 with the Retpoline patches that was released to updates yesterday ?
<caribou> better check here before building my own :)
<apw> caribou, yes, the kernles in -proposed are compiled with that compiler
<caribou> oh, cool thanks! less work for us :)
<apw> caribou, we build specifically using those ciompilers when they were in -proposed
<caribou> yeah, I saw them hit -updates yesterday
<caribou> good for us as we were trying to rebuild gcc7.3 on Xenial which is _not_ trivial
<apw> not trivial doesn't cover it, i am glad the compilers at least have not been my problem
<dupondje> apw: haha :) guess i'll just build it myself then :) np
<apw> dupondje, ?
<apw> i havent't had a look at your thing yet, so if you think that anything since then relates ... it does not
<thresh> hey.  when can I expect the kernel with https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1742721 fixed to land in xenial?
<ubot5`> Ubuntu bug 1742721 in Linux Mint "linux-image-4.13.0-26-generic / linux-image-extra-4.13.0-26-generic fail to boot" [Undecided,New]
<thresh> uh, no idea why it's "Linux Mint".  It's Ubuntu.
<apw> thresh, yeah don't worry about that, that is just because the first task on there is for that project
<thresh> I also had a kernel panic with that specific kernel I tested latest yesterday.
<thresh> but it's unrelated to the issue this kernel fixes;  and I'm not sure it even makes sense to report a crash on a test kernel.
<apw> likely not worth it as that one is now old and will want to confim it exists in the latest before investigating in the normal course of things
<klebers> thresh, the patch for that bug is queued for the next SRU cycle, which will probably start within the next days
<smb> Its likely one of the many things to come once we have normality... Not that I would know what is normal right now anyway but roughly it might be around March-01 when normal cycles start again
<thresh> klebers, good to know - thanks!
<mozmck> I'm trying to build a custom kernel for ubuntu 16.04 using the mainline patches all here: http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9.76/
<mozmck> I'm also apply preempt-rt patches as I need this to be a realtime kernel.  In the past I build the kernel and .deb packages like this: skipabi=true skipmodule=true fdr binary-indep
<mozmck> skipabi=true skipmodule=true fdr binary-perarch
<mozmck> skipabi=true skipmodule=true fdr binary-rt
<mozmck> and finally: dpkg-buildpackage -S -us -I.git -I.gitignore
<mozmck> Is this the right way to do it or is there a better or simpler way?
<mozmck> Oh, sorry - fdr is an alias for 'fakeroot debian/rules'
<mozmck> I'm getting an error: utils/helpers/amd.c:7:21: fatal error: pci/pci.h: No such file or directory, and I'm thinking something is not right in the build setup or something?
<apw> mozmck, that sounds like you need more build-dependencies installed to me; overall your approach sounds plausible
<mozmck> Hmm, I wonder which build-deps I might need?  I did find that I had to install libudev-dev
<mozmck> I have in my notes from doing this with 14.04 that I had to fix a header file when building this way, but not if I ran make deb-pkg.  Odd.
<apw> that doesn't really add up, but then i am constantly supprised by what is actually true
<TJ-> mozmck: libpci-dev  (for cpupower)
<mozmck> thanks!
<mozmck> I figured out I did not run apt-get build-dep linux either, so that may help.
<TJ-> :p yeah
<mozmck> Yeah, looks like that did it :-)  Sorry for the noise.
<mozmck> It looks like it got to the end of the compile and then gave me this error and quit: https://pastebin.com/LrCRgjyv
<mozmck> That was the fakeroot debian/rules binary-rt step (rt is my custom flavour)
<apw> mozmck, you need to disable zfs, do_zfs=false
<mozmck> ah, thanks.  I know I won't need that.
<apw> you don't have the code for it, whihc is why the pakcage is blowing chunks
<mozmck> Well, adding do_zfs=false to the command line did not seem to have any effect.  I notice in debian/rules that there is a do_mainline_build which sets do_extras_package and do_tools both to false as well as do_zfs=false.  I may try that because I don't think I need the tools and extra packages either.
#ubuntu-kernel 2018-02-22
<Moral_> I am a kernel dev at Intel. We want to cherry pick a commit staged for 4.16 into the Bionic tree and submit it. We know the freeze date is coming up quick. 2 Questions: 1. Are we allowed to even cherry pick non-security stuff out of a release that's in RC? 2. I assume the process for submitting our pathc is documented somewhere on the wiki? (slowly picking through it)
<TJ-> apw ***
<cascardo> Moral_: first, you need to open a bug, that bug must be present in the commit message
<cascardo> I am not sure there is some updated documentation about that, but you can look at other messages in the mailing list
<Moral_> ok I will take a look, thx.
<cascardo> if it's on linus' tree already, on an RC, just use cherry-pick -x to add the upstream commit information
<cascardo> if you needed to fix any conflicts, or change the original commit in some other way, change "cherry picked from" to "backported from"
<cascardo> and indicate in the subject header (between brackets) the series you are targeting, like [Bionic PATCH], for example
<cascardo> Moral_: hope that helps. look for the BugLink lines on other messages
<Moral_> Yeah, that was helpful. Gonna test then submit something here soon.
#ubuntu-kernel 2018-02-23
<kees> gh
<kees> ignore me :)
<dupondje> lets try to build drm-tip myself :)
<dupondje> rsync -a --exclude=dkms.conf --delete spl/ /home/dupondje/kernel/cod/tip/drm-tip/2018-02-23/debian/build/build-generic/spl/
<dupondje> rsync: change_dir "/home/dupondje/kernel/cod/tip/drm-tip/2018-02-23//spl" failed: No such file or directory (2)
<dupondje> hmmm :D
<dupondje> ah had to clone spl :D
<dupondje> logic
<apw> dupondje, or disable zfs in that build
<apw> oh but you might need a fix to make that work
<Snicksie> I am trying to compile a linux kernel module that works in kernel 4.4.0-112-generic, but if I compile in 4.4.0-116-generic I don't have the retpoline flag that is seemingly required from that release on (at least according to journalctl it refuses to load the module because there is a flag mismatch (retpoline vs no retpoline)). Machine is ubuntu 16.04.3 LTS. I couldn't find any hint on how to 
<Snicksie> compile with retpoline support. How can I do this?
<dupondje> apw: well :) got pass that, but hitting another error now:
<dupondje>   LD       acpidbg
<dupondje> ld: warning: cannot find entry symbol _start; defaulting to 00000000004000f0
<dupondje> /home/dupondje/kernel/cod/tip/drm-tip/2018-02-23/debian/build/tools-perarch/tools/power/acpi/tools/acpidbg/acpidbg.o: In function `acpi_aml_set_fd':
<dupondje> ah well :)
<apw> are the automated drm-tip builds failing too, i assume so
<apw> Snicksie, you need to have the retpoline compiler installed
<apw> the latest version of the compiler which has that support
<snadge> HexChat 2.12.4 Linux 4.14.18-rt15-snadge [x86_64/1.83GHz/SMP]
<snadge> nobody builds a standard ubuntu kernel config with the latest hard realtime patch :(
<snadge> what if you had an industrial laser you needed to control
<snadge> ive tested it with 17.10, mixbus (ardour essentially) with a 128 byte audio buffer, whilst im compiling a kernel with 8 threads.. without buffer overruns :p
<snadge> just in case you need to mix audio streams at low latency whilst under high system load.. i thought everyone needed to do that
<snadge> lowlatency just doesn't cut the mustard guys.. you can do better ;)
<dupondje> apw: http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-tip/2018-02-23/ they seem to be fine
<apw> snadge, no indeed ... because they are rarely based on a version even close to what we are using
<apw> dupondje, so that is confusing then
<snadge> thats true.. but it at least works for me ?
<snadge> saying yes and no and module to mostly the same options makes it an ubuntu kernel does it not?
<snadge> aren't a lot of the important patches backported? the date on the kernel is at least new anyway
<snadge> falktx didn't want to know about it either.. im guessing ubuntu-studio is the same deal? nobody wants to put their hands up for it.. but i literally just took the standard 17.10 kernel config, fed it into old config, set preempt-rt .. and pretty much hit enter for everything else
<apw> snadge, we have a ton of patches on top indeed, including the bits for meltdown etc, so it all depends what your focus is
<snadge> the meltdown patches are already in it from upstream
<apw> well th
<apw> that is something then
<snadge> https://wiki.linuxfoundation.org/realtime/start shows latest "dev" and "stable" versions.. which are based on (currently) 4.14.20 (rt17) released 22nd feb.. based on 4.14.20 released 17-Feb-2018
<snadge> which is an lts branch or something, which presumably has important backports.. but i understand this is far away from what ubuntu uses for reasons which beyond my understanding
<snadge> i mean why would you use an lts kernel .. thats way too logical ;)
<snadge> better to use something that isn't an lts.. then backport everything yourself
<snadge> im just joking.. i dont pretend to understand what the logic is behind not using the upstream lts kernel
<dupondje> apw: seems like acpidbg isnt build on dailies, so could explain
<frickler> apw: is there a document describing how to install retpoline gcc on xenial? I'm having similar issues compiling latest 4.13 it seems
<dupondje> dpkg-deb: building package 'linux-image-4.16.0-994-generic' in '../linux-image-4.16.0-994-generic_4.16.0-994.201802222100_amd64.deb'.
<dupondje> allright :D
<Snicksie> apw: is there currently any compiler that has retpoline patches in ubuntu 16.04? I cannot find any, also not in the ubuntu-toolchain-r ppa
<snadge> i thought it was in -proposed
<mozmck> Anyone here know if CONFIG_PM can be disabled in a 4.9+ kernel?  I'm building a kernel with preempt-rt patches and I can disable some of the power management in menuconfig, but it doesn't let me disable CONFIG_PM.
<mozmck> The help for CONFIG_PM (Device power management core functionality) says, "Selected by: PM_SLEEP [=y] && (SUSPEND [=n] || HIBERNATE_CALLBACKS [=y])"
<mozmck> But I can't find PM_SLEEP or HIBERNATE_CALLBACKS
#ubuntu-kernel 2018-02-24
<Tathagat2006> i am asecond year student a have read galvin for operating systems
<Tathagat2006> now i want to start learning linux kernel dev from scratch
<Tathagat2006> i have started reading linux kernel development by robert love
<Tathagat2006> which books to follow and in which order??
<Tathagat2006> are there any online resources which can help me learning linux kernel dev from scratch??
<TJ-> Tathagat2006: you'll not see a lot going on here especially at weekends; in the week the kernel devs discuss kernel/package development but it's not massively busy - most dev's aren't looking at IRC. there's a mainline channel ##kernel but that's the same
<Tathagat2006> i dont have any prior knowledge about linux kernel dev
<TJ-> Tathagat2006: best thing is to start reading the kernel's ./Documentation/ directory
<Tathagat2006> TJ: so what to refer?
<Tathagat2006> which channel will be helpfull?
<TJ-> Tathagat2006: start here https://www.kernel.org/doc/html/latest/index.html
<TJ-> best bet is to subscribe to 1 or more of the various kernel mailing lists where you'll see patches discussed and refined and get to know the development process. See also https://www.kernel.org/ and the "Kernel Mailing Lists" and other resources links
<Tathagat2006> i have joined newbies mailing list
<Tathagat2006> but tbh i dont understand the stuff going on there
<Tathagat2006> like wht are they discussing
<TJ-> Tathagat2006: it takes time to get context. Reading the source and the commit logs helps a lot
<Tathagat2006> cool
<Tathagat2006> so continuing to read robert love and mailing list and the links provided by you would be good for the begining?
<TJ-> Tathagat2006: yes... eventually, if you combine with reading source-code and patches and commits you'll get the context and it'll start to make sense. Remember, it's one of the biggest software projects there is - over 30 million lines of code - so no one can know it all. It's split inot sub-systems each of which has it's own maintainers so you could choose to focus on a smaller, quieter, sub-system to
<TJ-> begin with whilst still staying 'aware' of what is happening overall
<TJ-> Tathagat2006: I find reading git log's of commmits is really helpful
<Tathagat2006> TJ: Thank you 
#ubuntu-kernel 2019-02-21
<nacc> FYI, I filed (and uploaded for SRU) LP: #1816650 which is a kernel-based userspace change to lddpd. I'm not sure where all we'd see it on Ubuntu, but given that the upstream commit got put in stable, I think it's worth following up on (and someone from kernel may want to be on that bug)
<ubot5> Launchpad bug 1816650 in lldpd (Ubuntu Cosmic) "4.19+ (and possibly -stable trees?) need a fix from upstream" [Undecided,In progress] https://launchpad.net/bugs/1816650
<chiluk> @smb you seem to be maintaining the hwe kernels.  Unfortunately I don't seem to see up to date branches for hwe on the bionic git tree.  Am I looking in the wrong place?
#ubuntu-kernel 2019-02-22
<chiluk> fyi smb my git remote points at git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/bionic 
<chiluk> not sure if you guys have changed anything lately.
<apw> chiluk, that is the right place, what appears out of date for you there ?
<apw> chiluk, it appears in sync to me
<chiluk> @apw the hwe branch appears to be a minor version behind. UBUNTU: Ubuntu-hwe-4.18.0-14.15~18.04.1  
<chiluk> nm... it's right now..
#ubuntu-kernel 2020-02-17
<xclaesse> Hi there. Every time I get a kernel update on 20.04 I see those messages: https://pastebin.com/Rf9vVVBM. Not sure if that's harmless or not.
<ryuo> xclaesse: harmless probably. it just means it couldn't find certain firmware the driver could use. if your video graphics still work then obviously you don't need them.
<ryuo> it'll probably go away with a future linux-firmware update.
<aberrant> hi all. I would appreciate some help. I installed a custom kernel (5.3.10+) a while back to fix a problem that's now been fixed in 5.3.0-40.32. How do I remove my custom kernel and go back to the mainstream one?
<aberrant> If it helps, I used dpkg to install the custom kernel.
<aberrant> ii  linux-image-5.3.10+                  5.3.10+-1                              amd64        Linux kernel, version 5.3.10+
<aberrant> I wonder if it's as simple as apt remove :)
<ryuo> already gone.
#ubuntu-kernel 2020-02-18
<zx2c4> DalekSec: could you make sure we get 20200215 before apw backports an old version?
<zx2c4> Looks like they're messing with that stuff now
<apw> zx2c4, hmm, the current version is sitting on the queue for review
<zx2c4> Yes. This is why ive been making noise for a few days now...
<zx2c4> People keep passing it around "not my problem"
<zx2c4> Upstream dev keeps prodding "do the downstream stuff right"
<zx2c4> Downstream keeps passing around responsibility
<zx2c4> Upstream keeps prodding
<zx2c4> If the bottleneck is dkg, who doesnt care about ubuntu and apparently has limited time for debian, then either DalekSec should takeover that package or ubuntu shouldnt hesitate to diverge
<apw> oh we're not afraid of running ahead normally
<apw> though the backport is about setting a precident for sru'ing the new package at all
<zx2c4> Well, bump the package and nuke the bogus module reload logic in ubuntu then
<xclaesse> When I undock my lenovo x395 (amd chipset) USB dies. I see those logs: https://pastebin.com/m4w1v1Xf. I can make usb work again by rebooting or echo '0000:05:00.3' > /sys/bus/pci/drivers/xhci_hcd/unbind (then bind). Is that a known issue? What info would you need to have a useful bug report?
<xclaesse> oh, seems exactly that: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1857385
<ubot5> Ubuntu bug 1857385 in linux (Ubuntu) "xHCI host controller not responding, assume dead via USB-C docking station" [Undecided,Confirmed]
<DalekSec> zx2c4: dkg uploaded it to Debian, so it's now just for me or someone else to merge, I'll be able to get to it Thursday or Friday, unless someone else is quicker.
<DalekSec> https://packages.qa.debian.org/w/wireguard-linux-compat/news/20200218T033451Z.html hrm..
<zx2c4> Oh good
<zx2c4> He said he'd do the script fixes "later"
<zx2c4> Id prefer we just nix em entirely of course. I think that behavior is crazy
<zx2c4> DalekSec: 
<zx2c4> (see wg dev chan)
<DalekSec> With regards to dkg maintaining stuff, he has quite a lot listed: https://qa.debian.org/developer.php?login=dkg@fifthhorseman.net, but he seems pretty thorough so that's great, imo. :)
<DalekSec> zx2c4: But yeah, I'm out of town (In Indiana, actually) until Thursday night. :3
<zx2c4> DalekSec: indiana! Fun
<zx2c4> I got a tictac stuck in my nose on the way home from the indiana children's museum when i was real young
<zx2c4> Indianpolis childrens museum 
<DalekSec> Hah!  Nice. :P
#ubuntu-kernel 2020-02-19
<zx2c4> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1856539 anarchy
<ubot5> Ubuntu bug 1856539 in linux (Ubuntu) "wireguard package doesn't work on ubuntu eon" [Undecided,Incomplete]
<zx2c4> im now directing people toward our PPA
<zx2c4> breaking network servers that rely on wireguard for access and then not doing anything about it for lots of days doesnt sit too will with users
<zx2c4> https://bugs.launchpad.net/ubuntu/+source/wireguard/+bug/1862413
<ubot5> Ubuntu bug 1862413 in wireguard (Ubuntu Eoan) "wireguard-dkms 0.0.20190913-1ubuntu1: wireguard kernel module failed to build" [Undecided,In progress]
<apw> zx2c4: indeed
<zx2c4> what if you guys bricked people's ethernet cards by accident
<zx2c4> and then didnt roll out a fix for a while...
<zx2c4> apw: 
<apw> zx2c4: a miss labelling of a tracker let that out, a fix is in play but you moaned it wasn't up to date enough
<zx2c4> anyway, im going to start actively recommending people stay far away from ubuntu+wireguard until april
<zx2c4> you guys have the ability to trivially bump packages to be up to date easily
<zx2c4> no build changes required
<apw> do what you must
<zx2c4> i mean can you blame me?
<zx2c4> do i have anohter option here?
<zx2c4> i really want ubuntu to be the easy recommendation, because its the os people already know how to use, but when it results in things like this regularly, what am i expected to do?
<zx2c4> "sorry i recommended this to you" is about all i can concede 
<apw> the kernel was released in error about 48 hours ago, the fixed packages failed dry and were sent to be respin, and I have spent half of the time since on a family emergency, sometimes these things happen
<apw> I will get something sorted today
<apw> if this had been and lts it would have had more.focus
<zx2c4> 48 hours? its been a week ive been getting emails from people
<zx2c4> https://lists.zx2c4.com/pipermail/wireguard/2020-February/005044.html
<zx2c4> good to know about the LTS priority
<zx2c4> i'll advise folks to stick to the LTS releases if they want to use wireguard on servers
<apw> we endeavour to treat them well but lts' have much larger user bases
<zx2c4> yea makes sense
<zx2c4> priorites are priorities
<zx2c4> apw: okay looks like you pushed the wrong version?
<zx2c4> i am unimpressed
<zx2c4> 21:23:34 <apw> zx2c4: a miss labelling of a tracker let that out, a fix is in play but you moaned it wasn't up to date enough
<zx2c4> 21:23:56 <zx2c4> you guys have the ability to trivially bump packages to be up to date easily
<apw> zx2c4, be unimpresed, that is a working version which is tested with that kernel
<apw> zx2c4, that is something i can sru in 1 day in an emergency, a version which has not
<apw> zx2c4, even been tested by us with a developement kernle is not appropriate for an SRU let
<apw> zx2c4, alone an emergency sryu with no dwell
<apw> zx2c4, trust me i know how our sryu process works
<apw> zx2c4, i will then expect tomomrrow to go and make the one in focal new
<apw> zx2c4, and that can be sru'd at a more normal non-emergency pace which fits within
<apw> zx2c4, the sru criteria, and therefore is allowed
<zx2c4> gotcha so youre saying that whenever 20.04 gets the new version, youll put that into 19.10?
<apw> yes i am saying that, if debian does it before tommorro that will be better, if not and i get a chance
<apw> i will try and do it myself, the first time is less easy as i have not changed that package myself so far
<zx2c4> gotcha. DalekSec ^ relevant 
#ubuntu-kernel 2020-02-21
<mwpastore> has the original SQ block layer been completely removed in favor of blk-mq in modern kernels? 
<mwpastore> dm_mod.use_blk_mq=0 (or =n) on the kernel command line doesn't seem to have any effect 
<mwpastore> ah. I think this answers my question https://github.com/torvalds/linux/blob/4d856f72c10ecb060868ed10ff1b1453943fc6c8/drivers/scsi/scsi.c#L763-L765
<mwpastore> there should probably be a backport of multipath-tools for bionic to go along with the 5. 3 hwe kernel
<mwpastore> https://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=commit;h=a055a274a2633bd96a9341a8c85f5f1bdae2645d
#ubuntu-kernel 2020-02-22
<DalekSec> Looks like nobody got to the wireguard-linux-compat merge yet, doing that now.
<zx2c4> DalekSec: thanks! Can you have it replace the 20200205 one apw put in 19.10 prematurely?
<DalekSec> zx2c4: Sorry but I can only touch development versions of Ubuntu, not stable releases.  I also don't have the ability to touch main, so not sure what future plans are but if the tools go into main I won't be able to do anything without a lot of effort for every upload. :3
<zx2c4> Oh, bah
<zx2c4> Well, apw said he'd fix the backport so weights on him to do it
<DalekSec> (For reference: I'm MOTU only.)
<zx2c4> Somebody should give you access to main
<zx2c4> Youve been around for eons
<DalekSec> Noooo.  But anyway, not that it's in focal/development, it could in theory be SRU'd (can't SRU to stable without it first being in develop)
#ubuntu-kernel 2020-02-23
<zx2c4> DalekSec: alright, i guess this is apw territory then ^^^
<zx2c4> DalekSec: https://salsa.debian.org/debian/wireguard-linux-compat/merge_requests/2
<gitbot> Debian issue (Merge request) 2 in wireguard-linux-compat "postinst: remove bespoke error-prone auto-update mechanism" [Opened]
<zx2c4> DalekSec: if dkg doesnt merge that in time, Ubuntu's focal package should take that before the 27th
<apw> DalekSec: did you upload the merge?
<DalekSec> apw: Yeppers.
<zx2c4> apw: the 20200215 merge, but not https://salsa.debian.org/debian/wireguard-linux-compat/merge_requests/2 which you might consider applying in Ubuntu
<gitbot> Debian issue (Merge request) 2 in wireguard-linux-compat "postinst: remove bespoke error-prone auto-update mechanism" [Opened]
<DalekSec> Err, right.  That is correct, I just kept the current delta.
