#ubuntu-kernel 2005-11-28
<BenC> and it uses rdtsc(), so it's x86 only
<BenC> mjg59: any idea what a good portable replacement is for rdtsc()?
<BenC> and when it says "work with current 802.11 stack", it means that in the loosest way
<BenC> it's still using local ieee80211 headers, and abusing the real stack
<mjg59> BenC: What fun
<BenC> I'm not sure about including it...my biggest fear is that I'll become so frustrated with it that I'll end up getting an 8180 card and rewrite the whole driver
<mjg59> What's it actually using rdtsc for?
<mjg59> Ha
<BenC> mjg59: filling in some hosttime in a struct
<mjg59> Does it look important, or does it just need a monotonic timer?
<BenC> mjg59: don't laugh, that's how I ended up taking over the ieee1394 stack :)
<mjg59> Oh dear
<BenC> it's something to do with a prism header
<mjg59> Nngh.
<mjg59> BenC: It only seems to be for monitor mode
<mjg59> BenC: Other code just seems to use jiffies
<BenC> it has it commented out to use jiffies near the top of that function
<BenC> guess I'll do that aswell
<mjg59> I'd just go back to that, TBH
<mjg59> It seems to be a fairly standard 802.11 thing
<BenC> wait, that's mac_time
<BenC> oh well, I can use it still
<mjg59> If you dig for hosttime in drivers/net/wireless, there's no shortage of hits
<BenC> sweet
* BenC discovers git-bisect
<BenC> that is the most awesome tool and makes git totally worth using, even if it was the crappiest scm in the world
<Earthpig> benc: would be nice if it could be automated.
<CataEnry> hi all
<CataEnry> cya
<michel> i want to patch ltsp-kernel of ubuntu, howto? 
<fabbione> BenC: is it possible to do firewire back to back?
<fabbione> between 2 controllers i mean
<fabbione> if so do i need a special cable or something?
<CataEnry> hi all
<BenC> fabbione: yeah
<BenC> just a normal cable
<BenC> think of firewire as a network where any device with more than one port is like a hub :)
<BenC> I've had a winxp, macosx, 2 linux boxes, 3 firewire storage devices, firewire camera, all connected on a bus together
<BenC> using IPover1394 between the winxp/macosx/linux boxes too
<fabbione> ah cool
<fabbione> ok
<fabbione> i only have 2 boxes
<fabbione> nothing fancy
<fabbione> curious to try it
<fabbione> probably more
<fabbione> how fast can it go?
<infinity> ~400 Mbps, in theory.
<fabbione> that would be a cheap way to upgrade my 100Mb LAN to a ~ 400Mb
<fabbione> or buy a gigabit switch
<jbailey> fabbione: Do you actually have any disks that can push data that fast?
<fabbione> but the latter is hutterly expensive
<fabbione> jbailey: yes
<jbailey> Handy. =)
<BenC> fabbione: the linux IPover1394 isn't all that stable
<fabbione> BenC: well.. it's a good way to push you to fix it :P
<BenC> fabbione: not my driver :P
<fabbione> still your kernel ;)
<BenC> I just did the initial ethernet-over-1394, the RFC stuff came from someone else
<BenC> the ethernet-over-1394 was really stable, since it was just a firewire packet wrapped around a normal ethernet packet
<BenC> but it was linux-only
<fabbione> yeah  i could guess so
<fabbione> i guess i will switch to GigaEthernet
<fabbione> build a 1394 network as backup
<fabbione> and use the 100Mb for management
<fabbione> or something like that
<BenC> get some S800 firewire cards, and you'll almost be gigabit :)
<fabbione> BenC: i have the cards.. i need the switch
<fabbione> and a good switch is $$$
<kiko> hey there
<kiko> quick question
<BenC> hey kiko
<kiko> what's the difference between linux-image-2.6.10-6-686-smp and linux-image-2.6.10-5-686-smp?
<BenC> kiko: about 4 revisions :)
<fabbione> AHAHAHHAHA
<kiko> really?
<BenC> kiko: you'll need to be more specific than -6 and -5, since it could be -5.10 and -6.99
<kiko> oh. those are just the package names
<BenC> kiko: the functional difference is from -5 to -6, the kernel ABI changes
<kiko> ii  linux-image-2.6.10-5-686-smp                 2.6.10-34.7
<kiko> that's what we have installed
<BenC> oh, I don't know how the revisions worked back then, I only know the current convention for breezy/dapper
<kiko> hum hum
<BenC> Bisecting: 2 revisions left to test after this
* BenC loves git-bisect
<Earthpig> do you have vmware?
<BenC> yes, but not installed right now
<Earthpig> we use vmware 5's snapshots for that kind of iteration testing. 'tis wonderful.
<fabbione> BenC: it's the same convention
<fabbione> kiko: it's an ABI change
<fabbione> you install the new one.. boot in the new one.. you are done
<BenC> fabbione: I know the ABI bump is, but the 34.7 thing isn't :)
<fabbione> oh right
<fabbione> yes
<fabbione> we did add the ABI number to the debian version only in breezy
<BenC> Earthpig: for testing kernel regressions?
<fabbione> the old pkgs have standard numbers
<kiko> fabbione, should I be using the newer kernel or does it not really matter?
<kiko> by newer kernel I mean newer-ABI-kernel
<fabbione> kiko: well it's a security update that covers no less than 10 vulnerabilities
<fabbione> kiko: it's up to you
<fabbione> i suggest to use the new one
<kiko> oh
<kiko> so the -5 kernel was not updated?
<kiko> ah. I think I understand the problem
<kiko> I shouldn't have installed the -X kernel explicitly, right?
<Earthpig> benc: well, we don't do kernels, so no. :)
<BenC> kiko: the security update forced a bump to -6
<kiko> I see
<kiko> that's okay
<kiko> so it won't automatically update?
<kiko> (i.e. JRU does an apt-get update apt-get dist-upgrade and no new kernel)
<BenC> not unless you have linux-image-686-smp installed
<BenC> the meta-packages should pull in the upgrades
<kiko> yeah, that's what I should have.
<BenC> which is the default
<Earthpig> benc: we do use it for automated testing of nightlies though.
<BenC> Earthpig: cool
<BenC> fabbione: I think -4.4 is going to go out today
<BenC> after which I will attempt to get l-r-m built against 2.6.15, and then go for linux-meta
<infinity> BenC : Please don't.
<infinity> BenC : l-r-m will be unuseably broken as soon as the new X finally builds (which will happen in the next day, it looks like), so I need to do more than just "make it build" anyway.
<BenC> infinity: when's your next planned upload of l-r-m?
<fabbione> BenC: ok.. but it's pointless to upload until the gcj thing is sorted
<fabbione> BenC: basically all the archive is unbuildable atm
* BenC sighs
<fabbione> BenC: plus infinity loves to spank l-r-m :)
<infinity> BenC : I'll make l-r-m a priority tomorrow, since I expect to see X build tonight.
<BenC> you people enjoy dashing my hopes don't you? :)
<BenC> infinity: ok, I'll leave it alone, and just get linux-meta ready for when things settle down
<infinity> I'd like to see CDs built with shiny new kernels too, so I'm on your side.  Don't worry. :)
<infinity> Speaking of CDs, I really need to test that 640x400 vga16fb patch and get you to include it ASAP.
<fabbione> BenC: Kamion wants to coordinate with you some udeb reorganization stuff
<infinity> Certainly before we do the next flight CD anyway.
<BenC> fabbione: yeah, I'm in #ubuntu-boot, but so far, I don't know what coordination I need to do
<BenC> I was under the impression that once I got the kernel uploaded, the rest was on him :)
<fabbione> BenC: basically Kamion wants to revert a few changes in the amount of udebs we do build
<fabbione> BenC: yeah well.. he might need your help to setup git and stuff
<BenC> infinity: yeah, I can test that on atleast one system where I know vga16 has always been broken
<fabbione> he knows what needs to touch
<infinity> BenC : Note that Kamion/Keybuk would really rather not see linux-meta updated until we're sure the udev stuff is sorted.
<infinity> BenC : You have such a system?... ROCK THE FUCK ON.  I've been resigned to doing this blind until now. :)
<BenC> infinity: it's an ATI card connected to a TV via svideo, so it's not the normal brokeness, but it is broken
<BenC> I've been using vesa happily
<BenC> fabbione: ok
<fabbione> translating infinity to a more common language: "Dear Ben, given your card is broken, you win! FIX IT! kthxbye!"
<BenC> lol
<infinity> BenC : Hrm, not sure if this fix will fix your case, but bonus if it does.
<BenC> infinity: I have a couple of vgacon "fixes" from -mm that I want to test too...not going into our kernel yet, but I'll let you know
<BenC> rather wait for your patch before I touch vgacon at all
<BenC> hrmm...not sure if I need to mark that last boot as git-bisect bad, or good
<BenC> it booted way past where it normally crashed, but it got a segv in the initrd, and couldn't mount the rootdev
<infinity> BenC : My patch should just be touching the size/timings struct, if you're mucking with stuff outside that, we won't conflict.
<infinity> BenC : I just need to pick the "right" timings, and test the fuck out of them before I go blowing up people's hardware.
<sivang> BenC: Hey Ben, 'sup? I installed 2.6.15 and am now getting "BUG: Soft lockup on CPU#0"
<sivang> BenC: anything I can help to sovle this, or do more testing for you?
<BenC> sivang: backtrace or oops of any kind?
<sivang> BenC: if logs were not rotated, I should be able to give those . let's see
<sivang> BenC: re: oops, machine can't boot past it. not even in "rescue" mode
<sivang> BenC: can't seem to find it in the syslog, where else should I be looking?
<BenC> dmesg
<BenC> when it happens, does the machine lockup?
<sivang> BenC: yes sir :)
<CataEnry> re
<spike> hi there
<BenC> sivang: does Alt+SysRQ work?
<spike> I was trying to get myself acquainted with dapper and thinking of kernel specs for dapper and ubuntu-server
<spike> is selinux/grsec integration planned?
<spike> and what about ELSA/CSA patches?
<spike> or this sort of questions are welcome here?
<spike> arent*
<sivang> BenC: I will have to try. also, I can't seem to find the dmesg logs for that hangup
<sivang> BenC: any tips on that?
<sivang> BenC: (this all mean boot cycles for me)
<BenC> sivang: if it was a lockup, it wont be there
<BenC> you'll need to do a alt+sysrq, and either hand write the trace, or take a photo of it and email that too me
<sivang> BenC: ok, I will give it a try.
<sivang> I'll be bak ;-)
<sivang> BenC: now it locked up, on the corrupted USPlash screen , Alt+SysRq does nothing
<infinity> sivang : If you boot without "splash" you can avoid usplash.
<infinity> sivang : You might at least get some better debugging output then.
<infinity> sivang : And take away "quiet" from the command line too, if you want a bit more verbosity about where it might be dying.
<sivang> infinity: eh right, dumb me, not like I don't know that. (I used to do that when bootsplash just entered, since I am used to see text messages and bootsplash was bit uncomfortable.
<sivang> infinity: anyway, yet-another-boot-cycle
<sivang> ok, couldn't see the "Soft lock" anymore
<sivang> but I did see where it halted, again SysRq helped me none
<sivang> [17179589.808000]  Intel ISA PCIC probe: not found. Before that I got "* /etc/network/options is deprecated"
<sivang> BenC: any idea?
<BenC> did alt+sysrq work?
<BenC> ok, I see, no
<CataEnry> brb
<BenC> sivang: I'm at a loss, try booting with "noapic", "nolapic", etc, to see if that changes anything
<sivang> BenC: ok, will do. Why isn't anything on the kernel that will open and close a log file in an atomic manner, that way if something wrong happens, we would always be able to see the logs?
<BenC> sivang: at that point, the system dies, and likely is so trahed that opening a file would be disastrous
<sivang> BenC: I see. What about doing that before it dies, or is there no possible sane way to know that before it acutally dies ? :)
<BenC> it could die before even being able to access the disk
<sivang> ah right
<sivang> darn
<sivang> oh well, I will try again in a sec
<sivang> BenC: btw, what nolapic does?
<BenC> No Local APIC
<sivang> k, thx
<BenC> which kernel are you using anyway, -386, -686, -k7?
<sivang> BenC: 686, the smp and UP enabled 
<BenC> try doing "smp2up=off" aswell then
<sivang> /boot/vmlinuz-2.6.15-3-686
<sivang> and that tells it to?
<BenC> are you on an SMP machine?
<sivang> yes
<BenC> then it wont do anything, so don't worry about it :)
<sivang> BenC: there a way to know for sure if you're on an SMP machine if you're currently booted with a non smp kernel?
<BenC> cat /proc/cpuinfo should list total cpu's
<Mithrandir> it doesn't if you don't have an SMP kernel, iirc
<Mithrandir> yup, verified on the live cd.
<Mithrandir> doesn't tell me about my second core, just my first one
<Mithrandir> (amd64)
<BenC> probably doesn't parse core's, but it should parse cpu's
<BenC> ncpus_probes should atleast
<BenC> if not, it will be fixed in 2.6.15, since there were some patches for that
<Mithrandir> I don't have a real SMP machine here, so I can't test, but I've seen it not list all the CPUs listed before, at least.
<sivang> Mithrandir: I have a non real SMP machine, and when using an SMP kernel I always see two CPUs
<chuck_> heylo
<mjg59> BenC: It looks like the bcm430x people are moving to using much the same 80211 code as the rtl8180 people
<mjg59> So with luck we'll have one softmac core for all of them
<siretart> BenC: I noticed that iptables in breezy as well as in dapper there are some iptables modules missing, which are in debian's iptable
<siretart> BenC: I filed therefore bugzilla #19978
<siretart> BenC: the most notably difference to debian is that debian uses an own copy of kernel headers. Do you have an idea how to fix this?
<BenC> siretart: doesn't sound like something I can fix from the kernel side
<BenC> everything in the kernel is enabled
<BenC> mjg59: I have a softmac patch in -4.4 that came from the bcm430x ftp site
<siretart> BenC: well, I suspected that iptables source isn't too happy with the headers the kernel does currently provide
<siretart> because the kernel headers are the only difference
<BenC> siretart: is that something that needs to change in the kernel, or just that iptables will need a hacked up copy of the headers for it's own build?
<dilinger> heh
<dilinger> one of my coworkers rebooted their hoary machine today.  i totally forgot about the ABINAME bump
<dilinger> needless to say, openafs didn't work all that well for them, as there was no openafs module compiled for the new kernel
<siretart> BenC: debian seems to ship with a hacked up copy of the headers. fabbione changed the iptables package to use the kernel headers instead
<BenC> probably a good reason for that then
<BenC> but you'd have to ask him about what that reason was :)
<BenC> sounds to me like this is all squarely on the iptables package, so it's probably best to submit it as a bug against that package
<siretart> well, there seems to be no direct maintainer, so I wanted to try to fix it
<BenC> sure, if you fix it, then you can attach a patch to the bug report
<BenC> you can assign it to fabbione since he touched the source, and probably get an explanation from him about it
<BenC> or you can do the upload yourself, but I suggest atleast talking to fabbione first to find out why he switched it
<siretart> I uploaded a merged iptables package today which didn't FTBFS ;)
<siretart> I consider this as an improvement :)
<lamont-away> siretart: an old working version and a new ftbfs version is a completely different situation than a new compiled-but-non-working version
<lamont-away> since in the first case, apt-get dist-upgrade doesn't trash a working system
<siretart> lamont-away: yeah, right
<siretart> lamont-away: but a quick testrun showed my that iptables seems to be functional (I can look at my tables)
<lamont-away> cool
<siretart> but my original problem stands: There is no /lib/iptables/libipt_recent.so being built anymore. the new version from debian didn't bring any change
<BenC> what are the criteria for the package building that module?
<BenC> do you see any reference to it in the sources?
<BenC> also, is it possible that regardless of the kernel headers, it is checking uname and seeing that maybe the kernel doesn't support an obsolete interface?
* siretart rechecks
<CataEnry> bye all
<siretart> something is strange with linux-kernel-headers
<BenC> linux-kernels-headers is an oddity by design
<siretart> somehow all extensions of iptables get disabled when using linux-kernel-headers
<siretart> perhaps thats the reason why iptables ships its own kernel headers
<siretart> the problem is that the package FTBFS with that headers on ubuntu.. hmmm
<BenC> siretart: iptables is probably one of those evil programs that defines __KERNEL__ when building userspace so it can get to some kernel internals
<BenC> as such, linux-kernel-headers wont satisfy what it needs
<kiko> iptables again
<kiko> sign
<siretart> I have an idea, let me try something..
<infinity> iptables does Very Bad Things, yes.
<siretart> I think I got it
<siretart> debian rules sets KERNEL_DIR to /usr/include, it has to be just '/usr' instead
<siretart> interstingly, iptables seems to need the kernel includes only for some extensions, not for all, and not for itself..
<siretart> BenC: are you okay that I upload a package with just corrected KERNEL_DIR? quick check shows iptables works, even with '-m match' parameter
<BenC> what do you mean "corrected KERNEL_DIR"?
<siretart> BenC: http://paste.ubuntulinux.nl/4924
<siretart> thats the debdiff
<BenC> looks good to me
<siretart> ok. uploading
<siretart> this patch should imo go to breezy-updates, too
<siretart> because in breezy, there are no iptable extension modules atm
<jbailey> BenC: Yes, our lkh is designed to make those programs suck with low amounts of sympathy given.
<siretart> well, iptables builds nicely with lkh
<BenC> siretart: then iptables gets a gold star :)
<siretart> :)
<sivang> siretart: lkh are so hard to compile with for something that depends on the kernel?
<siretart> sivang: I didn't touch lkh at all
<zul> aieeeeeeee
<sivang> BenC: ok, I have some leads about the lockup
<sivang> BenC: I have no digicam so that's what I managed to take by hand
<sivang> BenC: pid 5570, comm   modprobe
<sivang> BenC: EIP:0060:[<c02ec3d4>]  CPU:0
<sivang> BenC: EIP is at _spin_lock_irqsave+0x14/0x20
<sivang> BenC: does that help?
<BenC> do you have the first few functions from the stack trace?
<BenC> sounds like it is crashing in a module init
<BenC> need to know which module
<sivang> BenC: how do I produce a stack trace there? I was virtually helpless when reaching that point
<BenC> it didn't spit one out?
<BenC> interesting
<BenC> any idea what the error was above the pid 5570 line?
<sivang> BenC: sure, the one I told you before
<BenC> like "BUG: ..."
<BenC> softlockup, that's right
<sivang> BenC: the first echo was that is started PCMCIA detection stuff
<sivang> BenC: yes
<sivang> BenC: exactly
<sivang> BenC: on CPU#0
<sivang> BenC: I wonder if I can reproduce that on this machine as well
<sivang> I will isntall this kernel here as well
<BenC> ok, -386 kernel works? if so, boot, and somehow disable pcmcia stuff
<sivang> BenC: I can remove it's modules if they are there form /etc/modules ?
<BenC> probably a script in /etc/hotplug/ for it
<BenC> or try mv /lib/modules/(version)/kernel/drivers/pcmcia to somewhere outside of /lib/modules
<sivang> ok, thanks for the tips
<sivang> will try and let you know
<BenC> ok, thanks
<mjg59> BenC: Yeah, I think that's being replaced with a more general solution
<mjg59> BenC: But basic Broadcom functionality seems to be getting fairly close
<BenC> mjg59: well, they need something because ipw2200, bcm430x, prism54-softmac and rtl808x all seem to need it
<BenC> rtl818x
<BenC> and I'm getting tired if custom ieee80211 stacks in all our external wireless drivers :)
<mjg59> ipw2200 should just need the ieee80211 stack
<BenC> it does, but it has internal softmac stuff
<mjg59> bcm430x, prism54-softmac and rtl808x need an extra softmac stack
<mjg59> Oh, does it? Nngh.
<mjg59> I thought it did all that in firmware
<mjg59> Oh well, never mind
<BenC> the softmac patch for ieee80211 was partly based on ipw2200
<BenC> it may not need all the softmac, but it atleast has some functions that softmac needed (subset in ipw2200)
<siretart> not to mention madwifi...
<infinity> madwifi is a whole different kettle of fish.
<mjg59> madwifi needs porting to Linux
<siretart> it has its own ieee80211 stack. Sure, it is fishy because of other reasons, too..
<mjg59> At the moment it's a *BSD driver that's shoehorned into the kernel
<infinity> BenC : Should I assume from your vacation announcement that I have until Monday to spit polish LRM?
<BenC> infinity: yeah, definitely
<BenC> about to upload -4.4, so you can base work off of that
<infinity> Excellent.  And we can shoot for an update -meta on Monday.
<infinity> (Assuming other parties agree, I'll just upload -meta right after lrm builds everywhere)
<infinity> I've decided that, after pulling an all-nighter, my Thursday is going to be a write-off.
<infinity> Go me.
<infinity> Anyhow.  I should go catch some "oh god, the sun's already been up for two hours, eek" shuteye.
<jbailey> BenC: Is -4.4 one I should test for ppc64 love?
<BenC> jbailey: I don't expect it to work, but surely give it a try
<BenC> infinity: heh, get some sleep
<jbailey> BenC: If you're not expecting it to work, I'll just do it when I have time and not rush to it, then.
<jbailey> All good. =)
<BenC> no problem :)
<fabbione> siretart: i have no issued with you working on iptables..
<LaschW> Are there any reports of segmentation fault booting linux-image-2.6.12-10-k7 ?
<siretart> fabbione: a fixed version of iptables should be in dapper now on all arches
<fabbione> LaschW: no. works here. we did score 9/9 successes on the tests
<siretart> fabbione: I think we should upload a fixed version of iptables to breezy-updates
<fabbione> siretart: what is exaclty broken?
<siretart> fabbione: debian/rules sets the variable KERNEL_DIR to /usr/include
<siretart> fabbione: this is wrong. it must be just '/usr'
<fabbione> specially given that nobody did notice up till now
<siretart> fabbione: without the kernel headers, a lot of optional extra modules won't get built
<fabbione> siretart: and problems does that bring?
<siretart> fabbione: extra modules like recent match support and quite a few others
<fabbione> hmmmm
<siretart> I came to it because I wanted to play around with that 'recent' match target as suggested by someone on planet.debian.org
<siretart> and was surprised that this doesn't work on breezy
<fabbione> i think it is a good candidate for -updates
<fabbione> siretart: i am confident you did your homework
<LaschW> fabbione: Is there a way how I may get / collect usefull information why this happens? 
<fabbione> please explain to mdz and coordinate with him
<fabbione> LaschW: it depends what happens
<fabbione> LaschW: segfault what? what does segfault?
<fabbione> you didn't tell me much
<LaschW> fabbione: segfault before usplash started, si IMHO there are no logs in that state of boot, isn't it?
<LaschW> s/si/so/
<fabbione> the kernel doesn't segfault
<fabbione> no there are no logs.. try to boot in recovery mode without usplash
<fabbione> what's on the screen?
<fabbione> can you take a picture?
<siretart> mdz: would you accept a one-line patch to iptabes for breezy-updates? Rationale: due to a wrong variable, iptables fails to find its kernel headers and does not compile nearly all optional modules.
<LaschW> fabbione: I will reproduce it and will see what I can do, give me a 1/4hour...
<fabbione> LaschW: in 1/4 hour i will be asleep
<fabbione> bah ok
<mdz> siretart: yes
<mdz> siretart: send me a debdiff by mail for review
<siretart> mdz: http://paste.ubuntulinux.nl/4924
<siretart> thats what I just uploaded to dapper, I'd upload of course with adjusted version number
<mdz> siretart: go ahead and prepare the package and upload as 1.3.1-2ubuntu1.1
<mdz> to breezy-updates
<siretart> on my way
<LaschW> fabbione: linux-image2.6.12-10-k7 segfault during boot: 
<fabbione> kernel doesn't segfault...
<fabbione> it OOPS
<LaschW> fabbione: Last message isa: uncompressing Linux... OK booting....
<LaschW> fabbione:then 10 lines segmentation fault
<LaschW> fabbione: then a line: 0
<fabbione> LaschW:  -> initramfs
<fabbione> try regenerate the initramfs
<LaschW> fabbione: Ahh!
<dilinger> mm, neat
<dilinger> http://www.selenic.com/linux-tiny/
<LaschW> fabbione: regenerating initramfs for 2.6.12-10-k7 will affect the other kernels? I'm asking because till now I have a running system, using the older kernel images.
<fabbione> no
<fabbione> no if you do it properly
<LaschW> fabbione: properly means: 'sudo dpkg-reconfigure linux-image-$(uname -r)'
<fabbione> yes
<fabbione> that is one
<fabbione> there are other ways
<fabbione> but use that one
<LaschW> fabbione: OK, thanks a lot...
<fabbione> i have the feeling i am going to get pissed soon
<fabbione> there is a user that keeps bombing me of emails in pvt
<BenC> fabbione: bounce them all back to him, maybe he'll stop
<BenC> fabbione: I saw one report that sound stopped working with 2.6.12-10
<fabbione> BenC: i did answer him and CC kernel-team
<fabbione> let see if he gets the clue (again)
<fabbione> BenC: quite impossible.. sound didn't change
<fabbione> bug number?
<BenC> 19969
<zul__> meh...since when did kernel-team ml become support
<BenC> it's very vague
<BenC> like, I think I just gave you all the info in the bug report
<zul__> shoot em
<zul__> how ubuntite of me ;)
<zul__> later anyways
<fabbione> wow
<fabbione> what a bug
<fabbione> BenC: let the bug die there for the next 2/3 weeks and close it with prejudist
<fabbione> bug is pointless. kthxbye
<fabbione> or ask Diziet to do it for you
<fabbione> ;)
<LaschW> fabbione: 'sudo dpkg-reconfigure linux-image-2.6.12-10-k7' didn't change anything. Still segfault messages...
<fabbione> LaschW: works here... ask jbailey how to debug initramfs
<LaschW> fabbione: dpkg-reconfigure says: Not touching initrd symlinks since we are being reinstalled (2.6.12-10.24)
<BenC> lol
<fabbione> the kernel is ok
<BenC> the only way to know for sure is to regen the initramfs for the old kernel and see if that works
<BenC> you could also try the -386 kernel
<fabbione> yeah that's another option too
<fabbione> but i am pretty sure the kernel is fine
<fabbione> specially because my k7 is one of the test machines
<fabbione> oh JEEE
<fabbione> this guy is persistent
<fabbione> CC to kernel-team
<fabbione> he answer back without kernel-team
* fabbione reroutes to /dev/null
<BenC> he's embarassed :)
<fabbione> I AM PISSED
<fabbione> why nobody cares about pissed Developers but only about embarassed (l)users? ;)
* fabbione modprobes overfiend.ko
<fabbione> THEY SHOULD ALL DIE A PAINFUL DEATH!
* fabbione LARTS
* fabbione LARTS
* fabbione rmmod overfiend.ko
<fabbione> ah
<fabbione> steaming down is healty
<LaschW> But how does it come that the 2.6.12-9-k7 works and the -10-k7 not? Just for beeing curious...
<fabbione> LaschW: the kernel works fine. the segfault is not coming from the kernel
<fabbione> the initramfs is probably corrupted or it is not generated properly
<fabbione> otherwise you won't see a segfault
<fabbione> but an OOPS
<fabbione> and it can be anything that breaks the initramfs
<fabbione> really...
<fabbione> LaschW: try booting 2.6.12-10-386
<fabbione> and see if it works
<fabbione> none of the security patches to touch boot
<fabbione> boot process i mean
<fabbione> anyway i am off to bed
<fabbione> good night *
<mdke> hello
<mdke> i had some bugs about acx_pci closed without a comment recently. They are still reproduceable on dapper, how come they were closed, does anyone know?
<jbailey> mdke: Bug number?
<mdke> hmm
<mdke> lemme find them
<mdke> jbailey, i can't find them, i'll have to come back when I have my email with me
* mdke finds an open one
<mdke> perhaps it was just housecleaning, and closing bugs instead of marking them as dups
#ubuntu-kernel 2005-11-29
<gdgani> i really need a new kernel for breezy...2.6.13 at least ...how can i get it ?
<jbailey> gdgani: Newer kernels are not supported on breezy.  Best to pull it from dapper.
<jbailey> If it breaks, though, please upgrade all the way to dapper before reporting bugs.
<gdgani> wich kernel is in dapper
<gdgani> ?
<jbailey> 2.6.12 is the default, but 2.6.15 has been uploaded.
<crimsun> 2.6.15-rc1 + $stuff
<gdgani> i can only get it via apt-get ?
<gdgani> i have an acer turion laptop..and having proble with timer..i think a newer kernel will solve it
<mjg59> Haha
<mjg59> There's almost all the code I need in the kernel already
* mjg59 adds support for calling fb_set_suspend
<ispiked> mjg59: is there anything in the new kernel that would make sata resume from suspend work (better)?
<mjg59> ispiked: What hardware are you on where it doesn't?
<ispiked> mjg59: gimme one sec.
<ispiked> mjg59: what's an easy way to tell the hardware? lspci?
<mjg59> ispiked: Uhm. Is this a desktop or a laptop?
<ispiked> mjg59: dell d610 laptop.
<ispiked> I'm not sure what type of HDD they put in it.
<mjg59> Should work absolutely fine with the stock kernel in Breezy
<mjg59> (My D610 does)
<ispiked> mjg59: when did you get yours?
<mjg59> August
<mjg59> The HDD type shouldn't matter
<ispiked> mjg59: it has an SATA HDD?
<mjg59> No, it's a PATA drive on a SATA bridge
<mjg59> I don't think anyone's actually using SATA drives in laptops yet
<mjg59> What sort of failure are you seeing?
<ispiked> http://ubuntuforums.org/showthread.php?p=515026
<ispiked> bah. that thread, not that post.
<ispiked> it fails when it tries to resume.
<mjg59> Ok, suspend to disk has nothing to do with SATA
<ispiked> really?
<mjg59> Try removing the splash argument from the kernel command line and see if that works
<mjg59> Yeah, the controller is reconfigured by the kernel
<ispiked> brb
<ispiked> mjg59: that did it! who would have ever thought. thanks a bunch. :)
<mjg59> ispiked: Cool
<mjg59> Hurrah. Well, that works.
<ispiked> mjg59: so how does sata not have anything to do with suspend to disk?
<infinity> Why should it?
<infinity> You could be suspending to paper, for all it cares.
<infinity> Print out memory state, reboot, kernel re-inits hardware, you type in old state, life goes on.
<mjg59> BenC: I've just bomed lkml with most of my patches
<michel> morning  i just patch ubuntu ltsp-kernel, make-kpkg, and run  ltsp-update-kernels the client starts but it crash at pivot_root: no such file or directory any idea
<Yagisan> G'day - why is breezys l-r-m loaded on a tmpfs ? Unlike hoary where it was on disk.
<Mithrandir> what's the ETA for changing the default kernel on the live cd?  I need it for the unionfs module
<fabbione> Mithrandir: we need lrm first
<fabbione> and .15-4.4
<Mithrandir> ok, and those happen until BenC is back from his turkey-eating feast, I presume?
<fabbione> Mithrandir: yes right.. we need BenC back
<fabbione> that would be.. next monday i think
<Mithrandir> ok, and we might have lrm and -4.4 mid-next week?
<fabbione> i am not going to make releases out of git yet.. i am not confident enough to do so
<fabbione> yes
<fabbione> i think
<Mithrandir> ok, goodie.
<Mithrandir> just trying to plan a little bit for next week and such.
<doko> Riddell: what is gettext-kde? arts b-d's on it
<doko> sorry
<SatanicA> hello
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-4.4 (2.6.15-rc2-ubuntu1) uploaded
<BenC> happy thanksgiving :)
<jbailey> BenC: Heya Ben, Happy t-day!
<jbailey> (Where "t" is a variable refereing to "turkey" "Thanksgiving" and "take a day off" as suits you) =)
<BenC> hehe
<BenC> I'll take "all of the above" for $1000 Alex
<BenC> fabbione: ping
<jbailey> BenC: missed him by 30.
* BenC rocks
<BenC> pinned down the sparc64 bug with 2.6.15 kernels
<BenC> I have a machine that usually finds brokeness :)
<jbailey> Cool.
<CataEnry> hi all
<zoltan> hi - the #ubuntu-bugs guys suggested I try here with my query (so much for the hug ;-)  )
<zoltan> OK I've got an issue with all the breezy -smp kernels. I have to disable APIC in the BIOS otherwise the boot hangs. It is on an MSI 945g NEOM/B with an Intel dualcore 830 CPU. There are noe BIOS upgrades available from MSI so I'd like to know if anyone else has similar issues.  Oh - disabling APIC (note *NOT* ACPI) means I only run on 1 of the cores
<BenC> where does the boot hang?
<zoltan> Hi Ben - just trying to get a private chat with you - no need. It hangs (IIRC) around the PS/2 keyboard message - and the kyb is dead - I have to hit reset. I'd need to reboot this box to confirm that, though.
<zoltan> BenC: BTW - I replied to your plea at the bottom of bug 2650 - subsequent to that I have tried all of the smp kernels and they hang the same way. I have *not* tried tried to re-install with the AMD64 version of breezy.
<BenC> hmm, ok
<BenC> for shits, can you try booting with noapictimer
<zoltan> BenC: should I stay online or would you like to take this up tomorrow or so? My email is zoltans@geograph.co.za - I'll try the noapictimer now - give me a mo
<lamont-away> BenC: if you're keeping score, 2.6.15-4.4 on hppa: drivers/net/tulip/tulip_core.c:383: error: 'ULI526X' undeclared (first use in this function)
<BenC> shit
<BenC> that probably breaks everywhere
<mgalvin> hey guys, i was wondering i could request trying to get a driver into the kernel b/c breezy does not recognize the sata drives on my laptop?
<BenC> lamont-away: any reason I don't have build logs yet?
<BenC> mgalvin: not in breezy, but try the dapper 2.6.15 kernel and let me know if it works there
<BenC> mgalvin: if not, file a bug report with a "feature request"
<mgalvin> ok, will do, thnx BenC
<lamont-away> arch/x86_64/kernel/io_apic.c:46: error: static declaration of 'disable_timer_pin_1' follows non-static declaration
<lamont-away> include/asm/apic.h:112: error: previous declaration of 'disable_timer_pin_1' was here
<lamont-away> arch/x86_64/kernel/io_apic.c:48: error: non-static declaration of 'disable_timer_pin_1' follows static declaration
<lamont-away> arch/x86_64/kernel/io_apic.c:46: error: previous declaration of 'disable_timer_pin_1' was here
<lamont-away> make[3] : *** [arch/x86_64/kernel/io_apic.o]  Error 1
<lamont-away> that's amd64
* BenC sighs
<BenC> ok, thanks lamont
<BenC> looks like I'll have -4.5 in just a bit
<infinity> BenC : Dude.
<infinity> BenC : Did 4.4 include the move to update-initramfs?
<infinity> BenC : If not, pretty please, with sugar on top, do so for 4.5.
<BenC> update-initramfs has to come from kernel-package, since it installs the post/pre inst scripts
<BenC> I need to do a k-p fix for that
<infinity> Well, true.  Are you not doing kernel-package hacking too, as part of your job description? :)
<BenC> yes, yes I am :)
<infinity> BenC : Well, if you don't get it in -4.5, we'll need to wait for the next ABI bump, so the sooner, the better.
<BenC> well, -4.4 is a total loss, since the tulip patch broke things...that's what I get for adding a last minute patch and not test building
<BenC> I can blame mjg59 for the amd64 breakage :)
<zul> heylo
<infinity> I'm having breezy flashbacks.
<infinity> BenC : Anyhow, tomorrow is LRM day for me and udev day for keybuk, but I don't want to update linux-meta until we're using update-initramfs as well.
<zoltan> BenC: OK - rebooted with BIOS enabled APIC with MPS table v1.4. Boot process hung and kyb was frozen - had to hit reset. Last msg was:  [4294668.946000]  PNP: PS/2 controller [PNP0303:PS2K,PNP0f13:PS2M]  at 0x60,0x64 irq 1,12  -  I've just noticed that I can update to 2.6.12-10-686-smp  -  should I, or only after we've sorted this out?
<infinity> zoltan : You should update anyway for the security fix, but in your case, -10- won't fix anything for you.  Of course, an unbootable machine is the most secure machine of all, so you could see this as the ultimate security fix...
<zoltan> gee thanx
<infinity> (Been up all night, excuse the poor sense of humour)
<zoltan> no hassle - I did have a smile
<zul> then go to bed...:)
<infinity> I'm still trying to get an American to FedEx me a slice of pumpkin pie.  Once that's been secured, I'll go to bed.
<BenC> infinity: consider it done, go to bed :)
<infinity> Woo.
* infinity is gone.
<zoltan> .... but infinity never stops - by definition
<zoltan> BenC : do you want to try a few things now or shall we pick up another day? I'm really available to help try sort this out - Methinks it could be a BIOS bug issue as the M/B is still on its first release of the BIOS, but I wouldn't know how to prove that without your help. Let me know now so I can either pack up or stay - TIA.
<BenC> Monday is probably best
<zoltan> cool by me - thanks (just drop me an email) - cheers for now.
<Earthpig> benc: btw... getting oops from naked (non-mm) arcmsr module on the current breezy amd64 kernel.
<CataEnry> bye all
<zul> ok this might be a stupid question but does anyone here read ubuntu-users ml
<jbailey> Do I get fired if I say no?
<mjg59> Occasionally
<zul> jbailey: yep...but what do i know..
<zul> i guess i could subscribe..
<lamont-away> I wonder what module supports 0000:00:0e.0 IDE interface: National Semiconductor Corporation 87415/87560 IDE (rev 03)
<lamont-away> or rather, why the kernel doesn't find the cdrom on the J7000
<lamont-away> BenC: on the hppa configs, please turn on CONFIG_BLK_DEV_IDEPCI (and then CONFIG_BLK_DEV_NS87415)
<lamont-away> thanks
* lamont-away should really take the time to figure out how to check out the current kernel and such
* BenC points to the topic
<BenC> I'll make those changes for -3.4
<BenC> -4.5 I mean
<BenC> so it builds for hppa otherwise?
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-4.5 (2.6.15-rc2-ubuntu1) uploaded (needs newer kernel-wedge to build)
<zul> BenC: available?
<zul> laster
<ispiked> mjg59: had any problems with the stick and buttons below the space bar not working when you resume from suspend?
<BenC> zul: I am now
<BenC> lamont-away: ping
#ubuntu-kernel 2005-11-30
<mjg59> ispiked: What kernel?
<ispiked> mjg59: the one that ships with breezy (2.6.12-9-386
<ispiked> ).
<ispiked> bah.
<mjg59> ispiked: What sort of machine?
<mjg59> A D610?
<mjg59> I thought we'd fixed that in 2.6.12-9
<ispiked> mjg59: a D610, and it does work normally, it just seems to have busted after I resumed from suspend.
<mjg59> Yeah
<ispiked> mjg59: would seeing the dmesg help?
<mjg59> Nope
<mjg59> I've got a D610 myself :)
<ispiked> any way I could force it to load?
<mjg59> Is this suspend to disk or suspend to RAM?
<ispiked> suspend to disk. I haven't tested it with suspend to RAM.
<mjg59> Ah
<mjg59> I'll give it a go later on and see if I can duplicate it
<ispiked> here are the specs, btw http://www.ispiked.us/tmp/D610.txt
<zul> heylo
<lamont-away> BenC: ack
<lamont-away> sigh
<lamont-away> BenC: you here, or just bouncing?
<CataEnry> hi all :)
<mjg59> Oh ewwwwwwwwwwwwwwww.
* mjg59 looks at the hsf driver again and wishes he hadn't
<zul> hey
<fabbione> hey zul
<zul> hey fabbione how goes it
<fabbione> could go better and you?
<fabbione> how did your aniversary go?
<zul> shitty...at first...i shot my mouth she got upset, we argued...i won..went out to dinner..rented a movie...uhmm...
<fabbione> s/uhmm/we went to sleep and i snored like a bear.. she won/ ?
<Yagisan> zul, lesson 1 - she always wins. lesson 2 - see lesson 1
<chmj> hahahah 
<zul> Yagisan: not necessarily
<zul> i won this time
<zul> fabbione: something like that ;)
<Yagisan> zul: speaking as a married man, I have learned you never truly win. One day when you least expect it, she will bring it up again
<Yagisan> usually when you have forgotten all about it
<dilinger> Yagisan: win the battle, but never the war?
<Yagisan> dilinger: seems that way. Now if only I could harness all that extra storage space of my systems ...
<Yagisan> s/of/for
<zul> Yagisan: oh she does that as well
<zul> she does it real well
<zul> hey BenC how was your thanksgiving
<BenC> good, thanks
<jbailey> The computer says "Sorry.  You're too full of Turkey to use the Internet right now"
<makx> hello jbailey
<infinity> BenC : Eek, the sky is falling, linux-source is FTBFS all over, aieeee!!
<infinity> BenC : Also, "hi".
<jbailey> Heya makx 
* jbailey watches Adam talk to thin air
<zul> he reads the logs..:)
<jbailey> Really?  That's sick.
<makx> jbailey: what do you drink with turkey?
<infinity> Oh, I hadn't noticed he'd left.  I are retarded.
<jbailey> makx: Umm.  Is this a leading question?
<infinity> makx : Turkey blood.
<makx> bleaah
* makx turns away
<jbailey> makx: Adam's probably quite serious.
<makx> even more disgusting jbailey
<infinity> '"And what'll you have to drink, Kowalski?" ... "MEAT!"'
<jbailey> makx: Sitting next to him at a Brazilian restaurant was..  Interesting.
<zul> damn pagans
<zul> :)
<jbailey> zul: Probably.  It's hard to find "saved" pagans. ;)
<zul> hehe..
<infinity> Jesus is so picky.
<makx> probably, i'm scared.
<jbailey> makx: It was the swords with the meat hanging off of them that scared me more, though.
<jbailey> And the imitation Caipirihnas.
<dilinger> jbailey: wait, why would you go to a brazilian restaurant?
<jbailey> We should've gone to the other Brazilian place.
<infinity> dilinger : Closing dinner.
<jbailey> dilinger: I go to the one a couple blocks from here for drinks.
<jbailey> dilinger: But that one was ...
<infinity> dilinger : Not jbailey's choice of venue. :)
<jbailey> What he said.
<dilinger> heh
<infinity> The food was good, the entertainment was... Lacking.
<jbailey> infinity: All told, had they not given me the wrong plate, it would've been fiine.
<infinity> jbailey : Yeah, that was a bit odd, especially after he'd explained to you why you were getting a different colour plate..
<jbailey> infinity: Yup.  The mushrooms and such were actually decently done.
<infinity> jbailey : They looked good.
<infinity> But I was too preoccupied with MEAT to bother asking for any.
<jbailey> Dude.
<jbailey> Clearly.
<jbailey> They were in a bowl in front of you. =)
<infinity> MEAT.
<jbailey> Along with rice and leaves.
<infinity> BLIND RAGE.  KILL, EAT!
<dilinger> mm.  i haven't been to a brazilian place in like 2 years, i should go again.
<jbailey> dilinger: There's a lovely one in Montr'eal, you can stay here.
<infinity> Seriously, I lose all sense of civilisation in a place like that.
<jbailey> I WANT MY COMPOSE KEY BACK, ROAR
<jbailey> infinity: I did notice. =)
* makx wants a vegatarion place :)
<infinity> jbailey : Even jblack was frightened by me that night, which says something.
<jbailey> makx: Come to Montreal, I can recommend several here.
<makx> jbailey: cool :-)
<jbailey> Hmm.  Austria, hm?  Is there reasonably vegan food there?
<zul> there are several in ottawa i walked pass one in the freezing snow
<jbailey> zul: I'm going to one for lunch on Saturday if you'd like to join me. =)
<zul> cant...having people over tomorrow have to clean the house with my wifey
<jbailey> Ah well, and we're leaving early Sunday morning.
<jbailey> I think.
<jbailey> Dunno for sure.
<zul> what are you doing in ottawa?
<jbailey> zul: Housewarming on Saturday night.
<jbailey> So I'm coming up early to get my hair done.
<zul> ah
<zul> well bring a snow shovel
<makx> jbailey: well french food is much better.. ;)
<makx> austrian have nice sweet stuff
<jbailey> zul: It's -12 here this morning with a wind chill of -22.  We got 10cm of snow in the city yesterday.  Is it truly any worse there?
<jbailey> makx: French food is decidely similar to braziliian, dude.
* makx lacks braziliian education.
* infinity gets the wax.
<infinity> (For the record, I prefer french food, and I have hideously hiuge credit card reciepts from Zofia's birthday to prove it)
<infinity> huge, too.
<jbailey> infinity: I did try to convince several people that the french word for hamburger is "grenouille"
<infinity> No one in their right mind would ever take your advice as a tour guide at face value anyway.
<jbailey> Hmm?  I dont' think I got anyone horribly lost, and people generally seemed to enjoy the food I took them to.
<infinity> jbailey : Okay, /I/ would never take your advice at face value, but maybe I'm the only person you feel the urge to be sarcastic and cruel to at every turn. ;P
<jbailey> Well..  It's because you're *there*
<dilinger> great
<dilinger> i have this mental image of infinity w/ a brazilian wax in my head now
<infinity> I wonder if perhaps we should be on topic again.
* dilinger looks around for a sharp implement to dig it out
<dilinger> fabbione: poke
<infinity> dilinger : Dude, no.  I'm not quite as hairry as you, but I'm hairry enough that I'd probably pass out from the procedure.
<dilinger> infinity: i'm only 1/4 hairy, now.  had to shave my chest for halloween :p
<zul> jbailey: its a bit warmer
<zul> but the same snowfall
<infinity> dilinger : !
<jbailey> Ouch, stubble.
<dilinger> infinity: i have pictures, if you think you can stomach it ;p
<jbailey> Of the shaving or of the hallowe'en costume?
<dilinger> the costume
<jbailey> Cool, I'd love to see them. =)
<infinity> Totally, pony up.
<dilinger> http://squishy.cc/pics/2005_halloween/
<dilinger> 004_Will_Crossdress_For_Security_Fixes.jpg
<jbailey> With a pink frilly thong?
<dilinger> oh yea
<dilinger> hehe, poor ari
<dilinger> that's him w/ the thong around his neck
<jbailey> Wherever did you find one that would fit?
<jbailey> Newyork has shops for everything. =)
<dilinger> i stole the entire outfit from my gf and her roommates
<dilinger> and i cut the thong
<dilinger> there was no way i was gonna wear it as-is :p
<infinity> I have no words.
<infinity> Maybe you should have shaved your hands too. ;)
<dilinger> it took long enough to do the chest
<jbailey> infinity: Nah, it's always funny to see a girl with harry palms ;)
<dilinger> i think that was my 2nd best costume.  my costume from 2 years ago was better
<infinity> Nazi synchronised swimmer with downe's syndrome... On speed?
<dilinger> close.  edward scissorhands.  http://squishy.cc/pics/2003_halloween/P9061708.JPG
* dilinger shuts up, now that we're completely off topic..
<infinity> It's all your fault.
* jbailey stops reading the channel so he doesn't burst out laughing while talk to a client.
<jbailey> dilinger: Nice costume, though.
<dilinger> thanks
<zul> did i mention how much i hate sybase
<lamont-away> BenC: -4.5 FTBFS on hppa because gcc-3.4-hppa64 and the kernel source don't agree on the name of the 64-bit cross compiler
<BenC> FTBFS everywhere besides i386 because of the rtl8187 driver defining some stupid floating point functions
<BenC> do you have a patch for the compiler problem?
<lamont-away> BenC: and it appears to be a toolchain issue, not the kernel
<BenC> ok, so I can just leave it up to you? :)
<lamont-away> BenC: actually, find where the hppa arch specific stuff tweaks the compiler name for 64 bit... and change it to hppa64-linux-gnu-gcc
* lamont-away goes digging
<lamont-away> arch/parisc/Makefile
<lamont-away> ifdef CONFIG_64BIT
<lamont-away> CROSS_COMPILE   := hppa64-linux-
<lamont-away> patch needs to change that to 
<lamont-away> CROSS_COMPILE   := hppa64-linux-gnu
<BenC> it's an error
<BenC> it checked for -gnu and then doesn't use it :)
<BenC> oh no, wait, it does
<lamont-away> hrm... the other CROSS_COMPILE assignment there should do likewise.
<lamont-away> parisc makefile is overriding for 64-bit stuff
<BenC> it checks for /usr/bin/hppa64-linux-gnu-gcc, shouldn't that exist?
<lamont-away> that does exist
<lamont-away> but then the makefile forces it to hppa64-linux-gcc, and dies./
<BenC> hmm
<BenC> I don't see where it forces it to CROSS_COMPILE=hppa64-linux- though
<BenC> btw, my i2k is running, and I should have the A500 up later today
* lamont-away is looking at 2.6.12 sources
<BenC> 2.6.12 has it hardcoded to hppa64-linux-
<BenC> and the hppa_cross dpatch made it hppa64-linux-gnu-
<BenC> but I'm not sure why the logic in 2.6.15 doesn't work
<BenC>  can you run that shell snippet from the Makefile and see if it works?
<jbailey> BenC: Do you happen to know off hand if gcc-3.4's __thread and TLS stuff works for sparc64?  It looks like it supports __thread, and the new binutils appears to support TLS.
<jbailey> BenC: I'm doing a build now with the fix to glibc to support it and trying nptl.
<fabbione> dilinger: pong
<CataEnry> bye all :)
<zul> oh that sucks my miyagi is dead
<fabbione> miyagi?
<zul> The japanese guy from the karate kid
<fabbione> yeah
<fabbione> i remember the name
<fabbione> but you said "my"
<fabbione> like if it is a tamagochi
<fabbione> or something
<zul> er...my miyagi
<zul> fuck...
<zul> mr miyagi
<fabbione> ah
<fabbione> ok
<zul> gah...freenode sucketh
<zul> later
<ispiked> mjg59: this time it didn't seem to do it (disable the stick and buttons below it).
#ubuntu-kernel 2005-12-01
<fabbione> BenC: 4.5 failed on sparc. It's a config issue
<fabbione> Support for SUN4 machines (disables SUN4[CDM]  support) (SUN4) [N/y/?]  (NEW) aborted!
<fabbione> Console input is closed. Run 'make oldconfig' to update configuration.
<BenC> fabbione: ok
<BenC> fabbione: that's odd though, it's trying to build sparc32
<BenC> fabbione: I built on my machine without doing "sparc32 dpkg-buildpackage ..."
<BenC> and I'm running 2.6.15-4.5, BTW :)
<BenC> -sparc64-smp
<BenC> why is sparc64 set as KPKG_ARCH=sparc in debian/config/archmap?
<BenC> fabbione: ping
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-4.6 (2.6.15-rc2-ubuntu1) uploaded
<BenC> later
<mjg59> So if I copy the 2.6.12 framebuffer layer into 2.6.15, usplash works again
<lamont-away> BenC: you probably don't want to know that -4.6 is FTBFS on ppc, right?
<lamont-away> kernel-wedge copy-modules 2.6.15-4 powerpc 2.6.15-4-powerpc
<lamont-away> missing module nls_base
* lamont-away points BenC at davis.ubuntu.com
<BenC> lamont-away: yeah, saw that
#ubuntu-kernel 2005-12-02
<xulin> hi .. 
<xulin> is there somebody who know things about tcpa ? 
<raghu> hi, I am developing a packet scheduling policy in Ubuntu Kernel(N/w subsystem), I am struck at a point
<raghu> it would be gr8 if I could get some help
<raghu> I have sprinkled printk(KERN_CRIT,"kernel ... "); in the following functions in ip_input.c
<raghu>  ip_rcv(), ip_rcv_finish(), net_rx_action()
<raghu>  but I do not see the messages in /var/log/messages? any ideas pls
<raghu> ?
<zul> heylo
<fabbione> BenC: please revert af586a17bada5fa8300ff7a33ef961ec4964b312 (sparc -> sparc64 rename)
<fabbione> or pull from me
<fabbione> .15 failed because i forgot an override in sbuild
<fabbione> and the change will make kernel-package cry out loud
<fabbione> BenC: when you have time, please revert the OCFS2 manual commit i did and pull from http://oss.oracle.com/git/ocfs2-dev.git
<fabbione> BenC: it will be easier to maintain in future
<fabbione> i just can't get git to do it properly
<BenC> ok
<fabbione> hey
<fabbione> Trying really trivial in-index merge...
<fabbione> fs/Makefile: needs update
<fabbione> fatal: Entry 'fs/Makefile' not uptodate. Cannot merge.
<fabbione> Nope.
<BenC> fabbione: next weekend my e3k will be available to do buildd and such
<fabbione> this is the error i get from git
<fabbione> basically it can't merge a file
<BenC> but I can't let it be perm, because I need that box for doing debug
<BenC> fs/Makefile must be modified
<BenC> git-status
<fabbione> and i don't understand how the hell i get to see the old, new files
<fabbione> yeah git status was telling me that the file was modified
<BenC> git-checkout -f will overwrite any modifications you have (if they are not valid)
<BenC> git-ls-files -o -t
<BenC> that will show you files that are "new"
<fabbione> hmmm
<fabbione> well basically i do a clone of our tree
<fabbione> revert a commit
<fabbione> pull from oracle
<fabbione> i get that error
<fabbione> i must be able to see the attempt merge to understand what to fix
<fabbione> that's what i can't figure
<BenC> then the revert needed merging to complete
<fabbione> i sort of need to see where the conflict is
<BenC> after the revert, do git-status
<fabbione> the revert goes fine...
<fabbione> git-status tells me nothing needs to be done
<BenC> most likely, you need to open fs/Makefile, and fix any conflicts from the revert
<BenC> doubt it, else it wouldn't do that
<fabbione> i get the error on pull
<fabbione> yeah there is an error in the revert, but i get to fix that and do the commit
<BenC> fs/Makefile wouldn't be modified from the pull though
<BenC> hmm, ok, I'll attempt it
<fabbione> it needs to merge 2 lines
<BenC> yeah, then do "git-commit" and it will finish the merge
<BenC> s/merge/revert/
<fabbione> yup.. i am redoing it right now
<fabbione> git clone ubuntu-2.6/ crap-2.6
<fabbione> defaulting to local storage area
<fabbione> takes a little bit
<fabbione> ok reverting now
<fabbione> git revert b6d1b58933a2eec5bfc4d14bb733686e446e497f
<fabbione> [SNIP}
<fabbione> BenC: yeah it works now! thanks
<fabbione> BenC: you should be able to pull from me
<fabbione> OCFS2 integrated from oracle git repo
<fabbione> dunno if it builds.
<fabbione> but should.. it's the same version from 2 different sources
<CataEnry> hi all
<CataEnry> bye all
<mjg59> So, I've found what broke usplash
<mjg59> infinity: Can you take a look at http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=c465e05a03209651078b95686158648fd7ed84c5;hp=e764a20196f4e1b497a42fdc6e9d254e7ec290f2 and see if you have any idea why it might b0rk vga16fb?
<mjg59> (And, if possible, revert it and see if it fixes things for you)
#ubuntu-kernel 2005-12-03
<BenC> mjg59: I see one thing odd
<BenC> look at the diff to bitblit.c
<BenC> nm
<BenC> I didn't see where it set err = 1
<BenC> I can't see anything that jumps out
<BenC> pretty straight forward
<mjg59> BenC: Reverting it seems to make usplash work
<mjg59> So I'm wondering whether it's changing order of initialisation in some subtle way
<BenC> what's the URL again?
<BenC> nm, got it
<BenC> no, I don't, can you past it again?
<mjg59> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=c465e05a03209651078b95686158648fd7ed84c5;hp=e764a20196f4e1b497a42fdc6e9d254e7ec290f2
<mjg59> I'd prefer it if someone else can verify that it changes the behaviour
<mjg59> I'm not entirely convinced that I haven't buggered up my test system along the way
<BenC> I don't have anything other than the machine that was already broken in breezy to test on
<BenC> nothing changes when softcursor.c got moved (code wise)
<mjg59> Hmm.
<mjg59> Yeah. So now I'm confused.
<mjg59> Hmm.
<mjg59> The usplash script tries to load softcursor.ko
<mjg59> Which is obviously going to fail
<mjg59> I wonder if that's the problem
<BenC> how's it going to fail?
<BenC> did you make the change I submitted in the bug report to fix the loading?
<mjg59> It gets installed in a different location, I think
<mjg59> Uhm. Which bug report?
<mjg59> (Sorry, I've lost track of which ones are on which issues)
<BenC> I filed a bug report on usplash about the module loading order and location
<BenC> softcursor needs to be loaded first, and needs to be changed to video/console/softcursor.ko
<mjg59> I'm actually shifting to modprobe
<mjg59> Just let me get a fresh kernel image and I'll check
<BenC> that'll work, modprobe vga16fb should do the right thing
<mjg59> Ok, modprobe doesn't fix it
<mjg59> Hm. So now I wonder if I was finding the wrong breakage with my bisection
<mjg59> Grr
<mjg59> I may be entirely wrong about that patch, so
<mjg59> Oh ha ha fucking ha
<mjg59> Making sure that fbcon is loaded before vga16fb makes it work
<mjg59> So not a kernel issue at all
<mjg59> PAIN
<infinity> ... Isn't that backwards?
* infinity always assumed fbcon depended on having an fb loaded, not the other way around.
<infinity> Oh well, whatever. :)
<infinity> If you've figured out the magical load order, can you eiher push me a patch, or just make an upload?
<mjg59> I've uploaded
<infinity> Yay.
<mjg59> 0.1-23 should fix
<infinity> BTW, do we have any spare slots in the pallette?
<mjg59> No
<mjg59> It's all taken up with brown
<infinity> Too... Much... Brown.
<mjg59> So, can we have the 640x400 patch? Can we can we can we?
<infinity> I need to push aside a shade of brown for some sort of yellow/warn colour, I think.
<mjg59> Ngh.
<mjg59> I'd also like some artwork that used flat colours rather than trying to anti-alias with a tiny number of them
<mjg59> I think that would be a feature
<infinity> Yeah.  Good luck convincing someone to do that.
<mjg59> How about we kill Jeff and get someone else to spec the artwork next time?
<mjg59> Also:
<mjg59> BenC: Have you dropped the Toshiba acpi key magic patch?
<jbailey> mjg59: Eh?
<jbailey> mjg59: Of what do you accuse me? =)
<infinity> I'm sure I could just scribble "OOBOONTOO" in a red pen in The GIMP and use that.
<mjg59> jbailey: Other Jeff
<jbailey> mjg59: Oh good.
<mjg59> infinity: I'll upload it tomorrow
* infinity goes into his little corner to give mjg59 a working lrm for his ath.
<mjg59> I have an ath?
<mjg59> Oh, yes
<infinity> Someone should send me an atheros card for Christmas, so I can actually test this driver.
<infinity> The only LRM stuff I can test is fglrx and nvidia.
<infinity> (Which is the largest amount of work in the package anyway, so I guess that works)
<mjg59> BenC: Can you add the diff from http://www.codon.org.uk/~mjg59/tmp/fb-sysfs.diff ?
<mjg59> Haha.
<mjg59> So.
<mjg59> The reason for powernow not working on my Turion may have been the fact that I'd disabled it in the BIOS
<mjg59> Oh deary me.
<infinity> *cough*
<mjg59> Which means that the only real thing missing from this machine is the Broadcom wireless
<mjg59> Looks like it just got support for scanning. Hurrah.
<mjg59> Association can't be too far off
<BenC> mjg59: patch will be in -5.7
<mjg59> BenC: Rock, thanks
<BenC> mjg59: what was the url to the softmac stuff?
<mjg59> softmac.sipsolutions.net
<BenC> thanks
<fabbione> hey guys
<fabbione> BenC: sparc fails with oldconfig at kernel-headers otherwise we look good
<fabbione> i think the defconfig in the tree is old
<fabbione> dpkg-deb: building package `linux-headers-2.6.15-4' in `../linux-headers-2.6.15-4_2.6.15-4.6_sparc.deb'.
<BenC> I just did a str8 build and it did fine
<fabbione> that's weird
<fabbione> how do you call the build?
<BenC> not with sparc32
<BenC> just directly
<infinity> Okay, dude, we can be coworkers still ,but we can't be friends anymore.
* infinity mutters about people typing "straight" as "str8"...
<BenC> infinity: I can say str8 if I want to :P
<fabbione> if i use sparc64 in debian/config/archmap and dpkg-buildpackage it farts
<BenC> I'm used to typing that when I play online poker
<BenC> habit
<fabbione> unknown Debian architecture sparc64, you must specify GNU system type, too at /u
<BenC> fabbione: guess I need to test with "sparc32 dpkg-buildpackage ..."
<BenC> see if I can figure out what is going on
<fabbione> well what i did was:
<fabbione> use sparc in archmap
<fabbione> and build using sparc64 dpkg-build...
<BenC> that's what I have now
<fabbione> that builds all the kernel except the old config for -header-
<fabbione> i need to test out of git
<BenC> I didn't call sparc64, but it should be the same
<fabbione> this was 4.6
<BenC> I need to push, have a big changeset
<BenC> (ocfs2, and linus sync)
<fabbione> did you also pull from me?
<fabbione> perfect
<fabbione> if you can push, i can run a build
<infinity> BenC : eta on -5.X?
<BenC> if all goes well, tomorrow night
<infinity> BenC : We really need the update-initramfs change for the -5 ABI bump, and I need to push you the vga16fb patch too, before it's too late.
<BenC> probably a good idea if I make tomorrow a "get everything ready for linux-meta switch to .15" day
<infinity> (Need to build kernels and test on a couple of machines here first, before I decide to inflict it on the world)
<BenC> including fixing k-p
<infinity> Yeah, LRM will be in by then.
<infinity> Updating it for the ABI bump is simple.
<BenC> lamont: !!
<infinity> So that's no big deal, once I've done the hard bits (fixing it to stop sucking and actually build)
<BenC> lamont: I have -5.7 building on hppa and ia64 now :)
<BenC> infinty: good deal
<fabbione> coll
<fabbione> cool
<BenC> I have 5 builds going atm
<infinity> BenC : mdz wants me to give you a quick tour of LRM too, so you're not stuck blocking on me when the world crashes around my ears with other tasks.
<BenC> only reason I don't have amd64 going is I haven't pushed for concordia to pull from yet
<infinity> BenC : But we'll save that until after I've updated all the drivers.
<BenC> infinity: unless there's more than what I already encountered doing a few ABI bumps in breezy, then I'm good
<infinity> BenC : Axcept for the part where I'm changing that mechanism, no.  If you never have to update a driver, LRM should be simple.
<BenC> fabbione: the e3k is my new best friend...I can pump out a quick build in 15 minutes just to see if it compiles ok :)
<infinity> If you find yourself having to update one (especially nvidia or fglrx), you'll hate yourself.  So, it's best not to bother. :)
<fabbione> BenC: ehehe ok
<fabbione> i didn't want to keep you awake
<BenC> infinity: I'll try to stay clear of actually doing work on lrm :)
* infinity looks in wonder at the new word he's created.
<infinity> s/Axcept/Except/
<BenC> infinity: my hillbilly accent rubbin' off on ya'll
<infinity> BenC : Ugh, dude, I was talking like you for days after you left.
<fabbione> BenC: ok, i am going to stop building the kernel for now. Just let me know if i need to build it with sparc32 or sparc64. I can override that in sbuild per source pkg
<BenC> was surprised my wife didn't notice my slight french accent when I got back
<fabbione> lol
<fabbione> Merci
<BenC> I noticed I even spoke broken english a few times, in addition to the accent
<infinity> If it's not buildable with sparc32, you're not doing it right. :)  Period.
<infinity> I sure as heck wouldn't special-case the powerpc buildds to build with linux64 for kernel builds.
<BenC> infinity: yeah, because we all know that it has to build on a 50mhz sun4c :)
<fabbione> ehhehe
<fabbione> infinity: i blame kernel-package
<fabbione> no really..
<infinity> BenC : No, but the buildds themselves run in linux32/sparc32 for pretty valid reasons, and having the kernel builds not fit into my little automated world sucks. :)
<infinity> (doubly-so, if I end up with a sparc buildd in the DC)
<BenC> yeah, before I set the sparc buildd's to use sparc32 way back when, administering it was awful
<fabbione> infinity: that's why lamont did implement an option in sbuild for that :)
<BenC> for what?
<fabbione> $build_env_cmnd{'linux-source-2.6.15'} = '/usr/bin/sparc64';
<fabbione>  <- in .sbuildrc
<BenC> ah
<infinity> Oh, that's just vile.
<fabbione> so you can override the environment per source pkg
<fabbione> infinity: no. it works
<fabbione> BenC: the buildd defaults to sparc32
<fabbione> and you can make exceptions
<infinity> Anyhow, that wasn't lam.
<infinity> lamont, even.
<fabbione> infinity: you?
<fabbione> because the default environment was alredy there
<fabbione> the override per source was lamont
<fabbione> i am pretty sure about that
<fabbione> check the baz changelog
<infinity> Oh, wait.  Yes, that was him.
<infinity> It kinda mucks with how we do the global  linux32 stuff though.  Yay.
<infinity> To be fair, I hacked the latter after he did the former.
<infinity> Specifically to work around the bogus requirement to have sparc32/linux32 in the chroots.
<infinity> Which is painfully dumb.
<fabbione> infinity: after we will get the sparc buildd at the CD
<fabbione> we will see how it works
<fabbione> i really don't care..
<fabbione> just don't break the stuff for older releases
<infinity> I don't plan on breaking anything. :)
<infinity> If you have whacky sbuild configs, though, you'll have to push those to me.
<fabbione> infinity: sure
<fabbione> that's no problem
<fabbione> the line you saw is basically the only custom in that config
<fabbione> well.. for hoary/breezy/dapper atm
<fabbione> we didn't build warty
<infinity> Ahh, so you haven't done these overrides for older linux source stuff?
<fabbione> so that's no issue
<fabbione> yes. only the kernels
<fabbione> $build_env_cmnd{'linux-source-2.6.10'} = '/usr/bin/sparc64';
<fabbione> $build_env_cmnd{'linux-source-2.6.12'} = '/usr/bin/sparc64';
<fabbione> $build_env_cmnd{'linux-source-2.6.15'} = '/usr/bin/sparc64';
<fabbione> that's all the custom love i have there
<infinity> Ahh, three lines then, not one. :)
<infinity> Well, let's see about fixing kernel-package.
<fabbione> + the default to use sparc32
<infinity> If it DTRT on powerpc, surely we can make it do the same for sparc.
<fabbione> oh yeah
<fabbione> specially because we don't care about 32bit kernels
<fabbione> that's where all the mess comes from
<infinity> Well, yes, 32-bit targets on sparc are laughable, but it's technically a bi-arch system with a bi-arch toolchain, and we should treat it as such.
<infinity> Even if the kernels will all be 64-bit.
<infinity> Some day, someone may resurrect sun4 support in 2.6, I'll boot it once, remember how HIDEOUSLY SLOW they were, and never again. :)
<fabbione> errr
* BenC remebers the 28 hour builds for libc6 on his Sparc LX
<fabbione> we already killed support for sparc32 in glibc
<fabbione> there is really no point in sparc32
<fabbione> at all
<BenC> libc is v9 optimized?
<fabbione> if somebody will resurrect it... well they are welcome to patch everything back
<fabbione> BenC: you need ask jbailey but i think they are
<fabbione>       - debian/sysdeps/sparc.mk: Set libc_configure_build=sparcv9-linux
<fabbione>         set sparc64_configure_build=sparc64-linux
<fabbione>     * Drop support for Neanderthal Sparc systems
<fabbione>       - debian/sysdeps/sparc.mk: Drop sparcv9 package
<fabbione>         Default to nptl for main build and sparcv9b
<fabbione>       - debian/control.in/opt: Drop sparcv9 package
<fabbione>       - debian/control: Regenerate
<fabbione> so i think they are optimized
<infinity> Is that true in Debian too?
<fabbione> no
<fabbione> only ubuntu
<infinity> Kay, that makes sense.
<fabbione> sparc is our pet arch.. mmk?
<fabbione> no really we can do stuff in here that Debian can't
<fabbione> let's do i
<fabbione> it
<infinity> <nod>
<infinity> I need to get a reasonably speedy Ultra in my house.
<fabbione> i need to get elmo and znarl to look at buildd prices and get them to the datacenter
<fabbione> so i can finally use my sparc for debugging and testing
<infinity> We should be able to get a set of craptastic Sunfire V240s for next to nothing.
<infinity> Should fit well with the buildds we already have.
<fabbione> i think elmo was looking in something like that
<infinity> The 240 is a lot less crap than the 100/120s I had to work with at my last job, at least.
<CataEnry> hi all
<zul> heylo
<fabbione> hey zul
<jbailey> Heya Chuck!
<jbailey> zul: Ottawa's even pretty in snow, it's kinda sick.
<zul> meh...its ok :)
<zul> hey guys how was your weekend?
<mjg59> infinity: Can't remember if I asked this last night - what's the situation with the 640x400 thingy?
<zul> hmmm...my touchpad is foobared
<mjg59> On 2.6.15?
<mjg59> Known
<zul> yeah i know
<mjg59> I blame Scott
<zul> heh.
<mjg59> Or Marco, or GregKH
<jbailey> zul: <Keybuk> http://people.ubuntu.com/~scott/packages/new-udev
<jbailey> From #ubuntu-boot not too long ago.
<zul> hmmm..
<makx> zul: link to your weblog?
<makx> do you have modular mousedev
<makx> ?
<zul> makx: i dont have a weblog
<makx> ah ok wasn't you that said to respond to davej, zul?
<zul> dont have time to
<mkrufky> zul: you closed bug 15395, and ive been busy -- didnt have enough time to write you back
<mkrufky> anyhow, yes... i confirm that not only is it not an ubuntu bug (it was an upstream bug) it is also fixed now
<mkrufky> the problem was due to missing dvb headers for users trying to install v4l modules from cvs -- it is a moot point now, as we have officially merged dvb and v4l cvs repositories
<mkrufky> side note: we are also merging ivtv and pvrusb2 and usbvision drivers into v4l ... so such problems will be nothing but history soon
<zul> ok cool..
<mkrufky> ya, sorry for the 2-week delay in my response ;-)
<zul> meh...its ok i guess ;0
* netjoined: irc.freenode.net -> brown.freenode.net
<BenC_> lamont: ping
<zul> hmmm...somtimes i can be such a bastard
<BenC> lamont: hey, when can ia64 and/or hppa use initramfs?
<BenC> lamont: btw, I have 2.6.15-5.7 running on my i2k
<makx> BenC: hppa needs an klibc patch.
<makx> haven't uploaded it yet to Debian due to troubles with missing asm symlink in linux-headers
<BenC> what about ia64?
<makx> " inflate code misreads magic number" according to jbailey.
<jbailey> klibc has the patch in Ubuntu.
<makx> aah you added it :)
<makx> need to sync with that badly.
<jbailey> I need to make lkh not suck in Debian badly.
<makx> hehe
<BenC> jbailey: so I can safely switch ia64 to use initramfs, or has it not been tested?
<BenC> if it hasn't been tested, I can surely do it, and make the change to kernel-package with this update-initramfs change I'm about to do
<jbailey> BenC: Well, it doesn't boot. =)
<jbailey> BenC: My initial suspicion is that the READ_BYTE or some such macro isn't right.
<jbailey> I had LaMont add some printk's to give us the value of those bytes, and they were complete whacked.
<jbailey> It's probably easy enough to troubleshoot, but my ia64 isn't local.
<BenC> I might just wait till the weekend and take a look at it then
<BenC> jbailey: -5.7 will be using update-initramfs, fyi
<jbailey> BenC: Nice, thanks!
<fabbione> have a nice evening guys
<fabbione> cya tomorrow
<fabbione> or very late today :)
<crimsun> 'night, fabbione 
<fabbione> night
<janimo> BenC, I don't know if LaptopTesting issues have different priority but here's https://bugzilla.ubuntu.com/show_bug.cgi?id=20085
<janimo> it makes a test laptop boot
<BenC> is that the acpi return value ignore patch?
<janimo> yes
<BenC> if so, it's in -5.7
<janimo> it is confirmed upstream
<janimo> thanks!
<CataEnry> bye all
<BenC> sure thing
<BenC> jbailey: ping
<jbailey> BenC: pong
<BenC> jbailey: update-initramfs has a bug
<BenC> the -d option requires an argument, yet it never sets version to the argument, so it always fails
<jbailey> BenC: It's infinity's package now, but if it's an obvious fix, I'd say just upload it.
<BenC> ok
<jbailey> You're the most important consumer of update-initramfs, so bend it to your needs.
* BenC adds another package to his list of "get the damn thing ready for linux-meta"
<zul> hehe
<BenC> nm, I was just using it wrong
<BenC> the wiki page for the spec said just -d, and it needs to be -d -k <ver>
<makx> BenC: which wiki page?
<BenC> https://wiki.ubuntu.com/InitramfsUpdates
<lamont> jbailey: BenC  - ia64 initramfs problem is an elilo issue, forwarded upstream
<jbailey> lamont: Cool.  Is it just setting the load address too low?
<lamont> nfc
<lamont> which reminds me... need to see what we did for breezy elilo
<zul> BenC: you know those unknown key pressed errors that some people are getting in their dmesg?
<BenC> zul: yeah
<BenC> I get it sometimes too
<BenC> lamont: I've fixed the hppa64-gcc thing (it needed to be hppa64-linux-gnu-gcc-3.4 for my breezy install), however, hppa64 is a nobuild from git right now
<BenC> a lot of missing headers referenced for the compat layer
<BenC> zul: do you have a fix for it?
<zul> BenC: yeah remove the prink that is causing that, its useless
<BenC> hehe, put it in yout git so I can pull it :)
<zul> ill make a patch for you tonight
<jbailey> BenC: From the parisc git, or from Linus?
<BenC> I pulled parisc git hoping to get things working
<BenC> but it seems to only get hppa32 working, and not hppa64 :/
* jbailey pings kyle to tell him.
<BenC> cool, the update-initramfs stuff works...install, upgrade/reinstall, and remove/purge
<BenC> did the reboot-notifier too
* jbailey ^5's BenC 
* zul disklikes the reboot-notifier
<zul> anyways home for me
#ubuntu-kernel 2005-12-04
<jbailey> BenC: Apparently git isn't all setup yet, and CVS should be still considered canonical.
<jbailey> BenC: They'renot expecting to be over on git for at least another week.
<BenC> who's that?
<BenC> parisc?
<zul> BenC: its there now
<jbailey> BenC: Yes, sorry. =)
<zul> doh...mental note...dont put anything in /tmp
<jbailey> It's fine until you reboot. =)
<zul> duh...
<zul> :)
<zul> so when are you coming back?
<jbailey> Back where?
<zul> here
* jbailey looks around.
<jbailey> I *am* here.
<zul> er...ottawa
<jbailey> Oh.  Mmm.
<jbailey> Unlikely to be in 2005.
<zul> ah..
<zul> true...
<jbailey> Maybe in January to hang out with Carlos for a weekend picking his brain on toolchain btis.
<zul> neato
<BenC> finally, running 2.6.15-5.7 on all my machines except the a500
<BenC> even reverted to stable rt2500 for my mame cabinet
<zul> heh
<BenC> infinity: ping
<jbailey> BenC: It's runnig on the ppc64 and the sparc boxes?
<infinity> BenC : pong... I'm doing test builds of the vga16fb change... Can you hold off on 5.7 for a bit?
<infinity> BenC : If you're itching to get it uploaded and go to bed, just do it, and I'll do a 5.8 later when I've tested this stuff more.
<BenC> jbailey: running on my g4, not ppc64 though
<BenC> jbailey: but definitely test it, since there were more ppc64 updates this time around
<BenC> infinity: how soon before you can get the vga16fb patch ready?
<BenC> infinity: also, what's the ETA on lrm?
<BenC> infinity: update-initramfs and notifier changes are in 5.7, btw
<fabbione> mornig guys
<BenC> hey fabbione
<fabbione> hey Ben
<fabbione> still up?
<BenC> yeah, was hoping to catch adam again
<BenC> I'd like to wait for the vga16fb patch before uploading -5.7, but I want to see how long he'll be with it
<fabbione> i think he is out for lunch
<BenC> I've got -5.7 building cleanly on 5 architectures, I need to do an upload before something breaks it :)
<fabbione> aahha
<fabbione> bah crappp!!!!!
<infinity> BenC : Just upload it, then.  I may be up all night. :/
<infinity> I'm having a pretty miserable day of one step forward, two steps back.
<fabbione> so fltk doesn't export opengl stuff on sparc that makes openexr FTBFS that stalls all of KDE
<fabbione> GO KDE!
<BenC> infinity: ok, I'll just do another upload when you get that patch ready
<BenC> infinity: is there anything I can do to help with lrm, so we can get linux-meta updated?
<fabbione> BenC: nah.. 
<fabbione> it's better infinity does LRM and get the blames :)
<BenC> I'm more than willing to put the blame on infinity :)
<BenC> even if I break it :)
<fabbione> ehehhe
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-5.7 uploaded (The "Five Arches" release)
<fabbione> lol
<fabbione> congratulation dude
<BenC> don't congratulate me till the buildd's agree with my assessment :)
<BenC> this time though, I did all my builds through to udeb builds, so I should be good to go
<fabbione> ehhe
<fabbione> ok fltk1.1 fixed
<fabbione> kde will unleash soon
<fabbione> good night ben
<fabbione> cya later
<BenC> good night
<infinity> BenC : No, I just need to figure out some minor details.
<fabbione> dilinger: ping?
<jbailey> BenC: Checked ppc64, it still fails with the same rtc failure even though you've built it in.
<zul> heylo
<oldguy> quick ot ok/
<jbailey> oldguy: Dad?
<jbailey> =)
<oldguy> yeah i m a dad..but got three girls
<jbailey> I have long hair, but that's as close as I get, sorry.
<oldguy> im trying to build a 2/6 kernel for netvista and ltsp-4.2..i built an uncompressed kerenl and catted the initramfs onto it..but  get unsupported file type..
<oldguy> so if vmlinux is unsupported..and vmlinuz is unsupported..what else is there?
<CataEnry> hi all
<chrisle> hi 
<jbailey> BenC, fabbione: What's the word on Xen on Breezy?
<jbailey> oldguy: You can't cat the initramfs onto a kernel.  You have to embed it in the data segment.
<jbailey> oldguy: Or you can pass it in using the initrd mechanism.
<fabbione> jbailey: Xen has some kind of .12 support afaik.. but that's it
<fabbione> jbailey: last time i did try a merge they were at .11
<fabbione> and we were shipping .12
<jbailey> But it's nothing we support natively.
<fabbione> nope
<jbailey> 'kay, thanks,
<BenC> fedora's .14 based kernel has patches
<jbailey> Ah, cool.
<BenC> kick ass, the big three have successful builds for -5.7
<BenC> jbailey: feel free to test -5.7 on ppc64 when you get a chance
<jbailey> It's more someone I have looking for us to support Xen.
<jbailey> BenC: See my comment to you in this channel from a little under 2 hours ago. =)
<BenC> jbailey: I looked into it, but the patches are so big and so invasive, I didn't see the point trying at this point
<BenC> ah
<fabbione> hmm
<BenC> jbailey: let me see if there's a kernel command line option that can disable rtc or something
<fabbione> if we really really want Xen we can pull it in from their development branch
<jbailey> BenC: 'k
<BenC> fabbione: is there a Xen git?
<BenC> IIRC, they are going to try to get it into 2.6.16
<fabbione> BenC: there is an hg tree
<fabbione> the tool that's similar to git
<fabbione> it's also on kernel.org afaik
<BenC> fabbione: -5.7 hit your sparc buildd yet?
<fabbione> http://www.kernel.org/hg/
<fabbione> BenC: it's building as we speak
<BenC> jbailey: can you past the URL to that oops again, please?
<fabbione> http://www.cl.cam.ac.uk/Research/SRG/netos/xen/downloads.html
<fabbione> The public Mercurial repository for Xen, the modified Linux, and the domain control tools is hosted on http://xenbits.xensource.com, where you can browse the source and inspect the
<fabbione> 15 hours ago:  	The device sharing check races when more than one file backed vbd is
<fabbione> author:  	rread@ubuntu.eng.hq.xensource.com
<fabbione> *perhaps* we can try to get in touch with that guy :)
<jbailey> BenC: Hmm, grep isn't turning it up in my logs.
<BenC> let me check firefox history, what host name would it be?
<jbailey> That's what I'm trying to remember. =)
<BenC> lol
<jbailey> Something ending in .nl =)
<jbailey> grep pastebin.ubuntulinux.nl * | grep jbailey
<jbailey> isn't giving me anything.  hmm
<jbailey> No, right!
<jbailey> I didn't put it in there.
<jbailey> I took a picture instead.
<dilinger> fabbione: pong
<jbailey> http://people.ubuntu.com/~jbailey/P1010042.JPG
<BenC> thanks
<jbailey> BenC: If you want I can update it for -5.7
<BenC> yeah, that'd be nice. see if you can get the whole screen aswell
<fabbione> dilinger: hey.. thanks i did manage without :)
<infinity> BenC : Okay, LRM ABI switches are now a one-button affair, much like linux-meta, but MUCH SCARIER under the hood.
<infinity> BenC : So, once this thing &#@$ing builds for me, your minor maintenance tasks with it should be a no-brainer.
<BenC> if I ever have to pop the hood, I'll be sure to take it to the shop(you) rather than work on it myself :)
* infinity kisses hardcoded kernel versoins and annoying *_minor stuff goodbye.
<infinity> Of course, now I have an irritating QT build issue to deal with.
* BenC adds ia64 to the successful builds for -5.7
<infinity> About time.
<BenC> so far everything has built fine
<BenC> I expect sparc to build, but I know hppa will fail
* infinity kicks weddell and screams at it to be faster.
<fabbione> BenC: sparc is at 64-smp (half way)
<BenC> it had been so long since I booted my i2k this weekend, I actually had to smack it on the side of the case to get it to power on
<fabbione> it won't take much much longer
<BenC> fabbione: sweet
<fabbione> i am falling asleep and partman-auto-lvm on ppc is winning 2:0
* fabbione starts to get pissed off
<fabbione> time for coffe and smoking bof
<BenC> opinions...in linux-meta, because {686,k7}-smp are going away, should I make the linux-{image,headers}-{686,k7}-smp meta packages depend on linux-{image,headers}-{686,k7} meta packages or make them depend on the kernel-abi-version packages directly (sans the -smp)?
<infinity> Make them depend on the other meta packages, so we can eventually remove the SMP packages.
<BenC> that's what I was thinking
<infinity> (Assuming we want to down the road)
<BenC> lamont: ia64 built :)
<lamont> BenC: woot!
<lamont> and hppa is still git-ftbfs?
<BenC> yeah
<BenC> if we had 64-bit hppa64 userspace, it wouldn't be a problem :)
<lamont> well, yeah
<jbailey> lamont: willy said to keep using CVS for at least another week.
<lamont> ah, I see.
<BenC> probably take a week to get a decent patch out of CVS anyway :)
<BenC> anyone packaged git 0.99.9x for ubuntu yet, or even debian?
<oldguy> jbailey: thanks..gonna try an experiment
<BenC> debian has it...we should grab that to dapper
<fabbione> BenC: i think we already sync that automatically
<BenC> universe?
<BenC> yep, there it is, thanks
<BenC> jbailey: can you disable the hwclock problem (mv it out of the way, and symlink to /bin/true, e.g.) and see where you get after that?
<jbailey> BenC: You scare me.
<jbailey> But okay. =)
<BenC> disable hwclock program I meant
<jbailey> Is that really the only thing that will cause an rtc event?
<jbailey> Or should I avoid using this system for much after that?
<oldguy> rootcd /opt/lytsp/i386-4.2
<BenC> nothing else should
<jbailey> 'k
* jbailey tries
<BenC> everything else should use the system clock rather than the rtc directly
<infinity> (should)
<BenC> odd that his system seems to oops/freeze on sig 7 from I/O accesses, I would have thought that hw traps would recover from that
<BenC> jbailey: running?
<jbailey> $ uname -a
<jbailey> Linux starshine 2.6.15-5-powerpc64-smp #1 SMP Tue Nov 29 07:20:51 UTC 2005 ppc64 GNU/Linux
<BenC> sweet
<BenC> ready to attempt to crash it? :)
<BenC> cat /proc/drivers/rtc
<jbailey> The only observation so far is that power mgmt is also a bit broken.
<jbailey> The fans are slowly speeding up.
<BenC> odd
<jbailey> Should I be on the console for that? =)
<BenC> yeah
<jbailey> NO such file or directory
<jbailey> mm
<jbailey> driver singular.
<jbailey> BenC: I got an oops, but no crash.
<BenC> well, it's a start
<BenC> can you email me the oops?
<infinity> Did you actually get any output? :)
<BenC> yeah, did any output come out, or did the cat process lockup?
<jbailey> BenC: http://paste.ubuntulinux.nl/5190
<BenC> well, it would have to get to the end of the proc function before the buffer was returned to the user
<BenC> jbailey: thanks
<jbailey> (Recovered from dmesg so I can just paste)
<BenC> that's not what I expected
<BenC> I was expecting to see rtc_get_rtc_time() again
<BenC> heh, that can't be good :)
<BenC> jbailey: thanks, I'll be able to do more with this dmesg now
<BenC> maybe I'll have something you can test later, if you have time
<jbailey> Apparently doing it a second time to see if there was any output crashes the machine. =)
<BenC> at the very least, a little sprinkling of printk's to see where it actually oopses
<jbailey> BenC: Cool.  I'll try to run anything I need long term in screen sessions on other machines. =)
<jbailey> infinity: At some point when you're bored... ;)
<infinity> ?
<infinity> Not that that point is now, but I may want to plan for the future.
<mjg59> Is usplash working for everyone now?
<mjg59> And what magic does it need in its postinst?
<infinity> a) Don't know
<infinity> b) update-initramfs -u
<mjg59> infinity: Is the 640x400 patch submitted yet?
<mjg59> I want to shift to 640x400 artwork in the next usplash upload
<infinity> Too focussed on making LRM work. :/
<infinity> If yo uhave a tested patch, give it to BenC, otherwise I'll do mine tomorrowish.
<jbailey> infinity: I have instruction here on making kdump work to store OOPS information when it happens.
<jbailey> infinity: I collected it at OLS last year, and dug it up a couple days ago.
<infinity> Though, you should be able to switch the artwork anyway, since artwork that's smaller than the fb isn't a problem.
<mjg59> Yeah
<infinity> (As evidenced by the tiny artwork in the middle of my massive vesafb)
<BenC> usplash looks tiny on my readonfb at 1024x768
<infinity> (What will happen with artwork that's bigger than the FB?... For people upgrading?)
<BenC> anyway to scale usplash on higher resolutions? :)
<infinity> BenC : Did you see it on my 1400x1050?
<BenC> nah, hehe
<infinity> Speaking of seeing things on my laptop, did you finally finish watching Family Guy and regain productivity? :)
<BenC> I have about 10 episodes left to watch :)
* mjg59 uploads new usplash
<mjg59> Also: usplash needs to check if the display is capable of 256 colours
<infinity> mjg59 : I don't suppose that one daemonises (and removes the sleep from the init)?
<mjg59> Nope
<mjg59> I'll do that next time
<infinity> Kay.  I'll do that the first time I touch it, then.
<mjg59> Can you file a bug?
<infinity> Unless you're on a warpath. :)
<mjg59> Well, I'm in bed, ill
<infinity> Which, obviously, leads to hacking graphical boot thingees.
<lucasvo> hi
<lucasvo> I would like to make a clustering system with upstream compatible Kernel for terminal server. What do you suggest?
<mjg59> I have found scary ways of helping vesafb survive suspend/resume
<BenC> lucasvo: I don't undetstand your question
<BenC> terminal server and clustering conflict in my brain
<lucasvo> BenC: I would like to develop clustering which may be included by ubuntu
<BenC> what sort of clustering?
<infinity> mjg59 : It always has done for me anyway.
<lucasvo> if one uses powerful ltsp clients, one could use them for clustering
<lucasvo> BenC: like openmosix
<mjg59> infinity: Yeah, it doesn't here
<BenC> mjg59: FYI, the fb-no-write patch is in -5.7
<infinity> BenC : LRM has turned into a mauch larger headache than I'd originally hoped.  I'm going to go catch a 4 hour nap (It's 4am now) and finish up in the morning. :/
<BenC> lucasvo: oh, you lost me, I don't do much with that sort of thing
<mjg59> BenC: Thanks
<lucasvo> BenC: ok
<BenC> infinity: ok
<BenC> lucasvo: but I still don't know what you are asking..."what do you suggest" is very vague :)
<lucasvo> BenC: I need a clustering system which is accepted by ubuntu policy
<BenC> we have ocfs2, but I'm not sure if that suits your needs, since it's only a clustering filesystem
<lucasvo> BenC: exactly, I need RAM/CPU sharing
<fabbione> lucasvo: we don't have that solution yet
<BenC> and "accepted by ubuntu policy" is something you'll have to gain somewhere down the line, it's not something that can be decided before hand
<fabbione> lucasvo: and probably won't
<fabbione> lucasvo: what kind of clustering exactly are you looking for?
<BenC> fabbione: what is the clustering thing that was talked about at UBZ?
<fabbione> lucasvo: something like openmosix or a batch/queue/job scheduler?
<BenC> some IBM thing
<lucasvo> fabbione: yes, I want to make one for ubuntu
<lucasvo> fabbione: yes
<fabbione> lucasvo: yes it's not an answer to what i did ask :).
<BenC> there's another guy wanting to do the same thing
<BenC> and pretty much, he is having to do his work outside of ubuntu, in the hopes that he can prove its viability for dapper+1
<lucasvo> fabbione: hm I didn't see the or
<lucasvo> fabbione: I mean something like openmosix
<fabbione> BenC: i don't remember talkign about IBM solutions really.. but we have something on the boilerplate
<fabbione> lucasvo: no, we won't have openmosix or similar solution for some time
<BenC> fabbione: maybe it was HP
<fabbione> BenC: yeah HP
<fabbione> openssi
<BenC> lucasvo: email -devel about it and see if you can catch the attention of other people (and there are some) looking to do the same
<lucasvo> fabbione: what I would like to do is to include a clustering system into ubuntu which is accepted by upstream
<BenC> yeah, that's it
<lucasvo> BenC: ubuntu-devel?
<fabbione> lucasvo: https://wiki.ubuntu.com/UbuntuClusters
<fabbione> lucasvo: most of solutions like openmosix are for 2.4 kernels only
<BenC> lucasvo: yeah
<fabbione> and we don't support 2.4
<fabbione> porting to 2.6 is on the way but still at a too early stage to be even considered
<lucasvo> fabbione: there is some 2.6 code at openmosix but it is not accepted by Linus 
<BenC> as we discussed at the last Developers Summit, a group will have to develop this outside of ubuntu proper, and then seek inclusion, so I suggest getting on the bandwagon with people who want to do the same to avoid extra work and conflicts
<fabbione> lucasvo: because the userland is broken.
<fabbione> and the patch for 2.6 probably sucks
<fabbione> BenC: exactly
<BenC> lucasvo: accepted by upstream as in linus?
<BenC> don't see that happening with many clustering systems
<lucasvo> I mean this use case: Hospital delta is deploying hundreds of thin clients with Ubuntu and LTSP, and wants complete failover for the terminal services.
<lucasvo> BenC: yes
<BenC> it will get into ubuntu before it gets into kernel proper :)
<fabbione> lucasvo: that's not an openmosix cluster
<BenC> why the criteria for inclusion with linus?
<fabbione> that's a HA cluster
<lucasvo> fabbione: yes
<lucasvo> fabbione: but I actually want HPC
<fabbione> lucasvo: we don't have it and we won't for a while :) same answer as before. ;)
<fabbione> lucasvo: we might be able to provide slurm (job queue scheduler)
<fabbione> but that's it for dapper
<lucasvo> fabbione: I am not talking about dapper more about dapper+ 1 or 2
<lucasvo> fabbione: and I would like to develop it, I don't want out of the box solution
<fabbione> lucasvo: from here to dapper+1 there are at least another 10 months.. perhaps by that time there will be available solution..
<fabbione> who knows..
<zul> hola fabbione 
<fabbione> hey zul
<BenC> yo zul
<zul> hey benco
<BenC> jbailey: ping
<zul> ugh..this is an ugly website
<zul> http://wwwredesign.gentoo.org/
<fabbione> BenC: sparc is at dpkg-deb now :)
<BenC> fabbione: sparc success will finally mean an upload went as planned :)
<fabbione> ehehhe
<BenC> goal for -6 is to disable all the drivers that have missing symbols (mostly smp and 64-bit incompatible drivers)
<fabbione> yeah
<fabbione> i saw a bunch
<BenC> wow, linus tagged 2.6.15-rc3 just a mere 29 minutes after I tagged 2.6.15-5.7
<BenC> my timing is improving :)
<dilinger> heh
<fabbione> ehhe
<zul> slacker
<zul> :)
<zul> BenC: i wrote a patch for the atkbd last night its in my git archive
<fabbione> zul: patch to do what?
<zul> remove that unknown key bullshit
<zul> fabbione: http://zulinux.homelinux.net/cgi-bin/gitweb.cgi?p=ubuntu-2.6.git;a=commit;h=1ec11f9bc0963516a9b944e43fb89fbf5545a27b
<BenC> silly printk, warnings are for developers
<fabbione> bah it's just a warning
<fabbione> linux-source-2.6.15_2.6.15-5.7: successful
<BenC> but it causes uneeded bug reports
* fabbione ^5s BenC
<BenC> sweet
<BenC> cool, latest git has --no-merge for git-pull
<BenC> so you can inspect before merging and committing
<fabbione> eheh
<fabbione> i didn't play with git that much
<fabbione> i rely mostly on what you tell me
<fabbione> + my ppc is down until i can unfuck partman-auto-lvm
<zul> fabbione: i know but a user complained about it and its annoying the fuck out of me on my laptop
<fabbione> BenC: 
<fabbione> fabbione willy: i am cool with that.. ben is merging rc3 and i was wondering when we could pull from you.. i expect lamont wants that ;)
<fabbione> willy fabbione: keep pulling from cvs
<fabbione> ^^ hppa tree
<BenC> fabbione: not only that, but even if we switch it to KERN_INFO, it will still cause uneeded fillage of kern.log (and clearing of the dmesg buffer)
<BenC> fabbione: I'll leave it up to lamont to get me a diff from CVS
<fabbione> BenC: is there actually anything that use that output? iirc we were using it to track kernel -> X -> gnome keyboard issues
<fabbione> BenC: didn't you pull from hppa git once?
<BenC> fabbione: yeah
<fabbione> ok
<lamont> BenC: once they finish the rc3 merge, I'll gen a diff
<BenC> not sure about tracking the keys
<fabbione> lamont: better if you push them to move to git :P
<BenC> yeah, there's a freaking CVS tool fot git anyway :)
<lamont> fabbione: the trick is to help them get the infrastructure git-happy, and then it'll happen... it's not that they don't want to move.
<lamont> BenC: its the autobuild stuff, and such
<BenC> ah
<lamont> bunch of home-grown tools to do thing
<lamont> s
<fabbione> lamont: yeah i understand that...
<BenC> I'm a little leary of taking a cold monolithic patch for hppa, if they will get around to being in git real soon
<fabbione> that's exactly what i was thinking
<BenC> maybe we can do what fabbione and I discussed and just run patch/unpatch for that one diff
<fabbione> but you might endup duplicating the merge work
<BenC> or I might be off by a line or two and cause uneeded deltas in our tree
<fabbione> since they do it and you have to do it to pull in rc3
<fabbione> perhaps talk with them and see how to handle it best?
<lamont> gah. git-core goes through 0.99.9i, and then it's git_0.99.9j - wish they'd make up their mind
<BenC> lamont: apt-get install git-core (from dapper universe)
<BenC> fabbione: bah, git-core is not built for sparc yet! :)
<fabbione> BenC: hmmm probably
<fabbione> git-core:
<fabbione>   Package             : git-core
<fabbione>   Version             : 0.99.9j-1
<fabbione>   State               : Needs-Build
<fabbione> yeah
* BenC tries to remember that Alt+F4 in X will not get him to VT4
<fabbione> ahhahahahah
<fabbione> BenC: the universe buildd is almost at the end of gcc-snapshot
<fabbione> that's probably why it didn't built yet
<fabbione> and i did unleash the kde mess just today
<fabbione> so the main buildd is like utterly busy
<BenC> fabbione: FYI, if you have trouble finding an affordable ultra for the DC, I know where you can get UE 4500's for pretty cheap
<fabbione> BenC: you should tell that to elmo/znarl.. but afaik they are looking into new hw
<fabbione> it needs to be as small as possible (size wise)
<fabbione> because we pay hosting by size
<fabbione> but i am not sure 100%
<fabbione> things keep changing on a daily base
<BenC> yeah, the 4500 isn't small, but it's cheap and powerful
<fabbione> yeah i know
<fabbione> ok time to stop for today
<fabbione> or better
<fabbione> start cooking some real food
* lamont builds -9k on breezy
<lamont> git push ssh://rookery.ubuntu.com/home/lamont/public_html/archives/ubuntu-2.6.git
<lamont> bash: git-receive-pack: command not found
* lamont grunbles
<lamont> and grumbles, too
<lamont> BenC: would you be so kind as to send RT a request to install git on rookery?
<lamont> meanwhile, I've updated ~/.bashrc
<BenC> on rookery, you can point to my git bin's
<lamont> only if .bashrc says to
* lamont has a copy of git in ~/bin
<BenC> lamont: done
<BenC> well, rt ticket sent, not installed yet :)
<lamont> right
<lamont> thanks
<lamont> 'tis better coming from you, and all that.
<CataEnry> bye all
<zul> garrr...i hate batch files
<mjg59> BenC: ACPI sleep support doesn't seem to be getting initialised on i386, for some reason
<BenC> mjg59: ok, I'll look at it in a little bit
<mjg59> BenC: Uhm. CONFIG_ACPI_SLEEP is missing
<mjg59> On -686, at least
<mjg59> BenC: Also, http://lkml.org/lkml/2005/11/29/74
<mjg59> Can we grab that?
<BenC> Kconfig shows "depends ... (!SMP ...)" for ACPI_SLEEP
<BenC> I'll get that patch, sure
<BenC> is suspend/resume not compatible with smp?
<mjg59> I was under the impression it had been fixed
<mjg59> But that may not have been merged yet
<mjg59> BenC: If we can't fix that, then I guess we'll have to go back to UP kernels
<BenC> I can do another pull from acpi git and see
<mjg59> Looks like there were patches in April
<mjg59> They may never have been merged
<mjg59> The acpi git tree doesn't seem to have been updated in months
<BenC> are you checking the right acpi branch?
<mjg59> Hm. Which is the right one?
<BenC> I'm using the "test" branch that -mm uses
<mjg59> Ah
<BenC> lamont: ping
<mjg59> Yeah, last one there seems to be September
<mjg59> The code isn't in -mm now. It was back in 2.6.12 time.
<BenC> -mm is pulling from that test git branch is all
<mjg59> Well, either we forward-port the stuff from 6 months ago, or we go back to shipping UP kernels
<BenC> how large was the "works on smp" stuff?
<BenC> a huge portion of the acpi stuff was already merged, so we can't just apply the acpi dpatch from breezy
<mjg59> I don't know if we had it in Breezy
<mjg59> And I can't find the patches nicely bundled anywhere
<mjg59> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12/2.6.12-mm1/broken-out/ seems to be the latest ones
<mjg59> Various patches from there are needed
<mjg59> But it looks like there's runtime checks /anyway/
<mjg59> So just force the !SMP for now?
<mjg59> Hang on
<mjg59> It looks like there's support for it
<mjg59> BenC: Nngh
<mjg59> BenC: Can you just turn on CONFIG_HOTPLUG_CPU?
<mjg59> That ought to make it work
<BenC> ok
<dilinger> this machine loves to hang for 1/2 a second at random times since upgrading to breezy :/
<BenC> lamont: ping
<zul^> later folks
<BenC> lamont: I got a hppa64-smp vmlinux
<BenC> lamont: most of the breezy hppa patch was in the git, except the compat signal/siginfo stuff, which wasn't that much
<BenC> I'll try to boot it shortly
<lamont> oh, way cool
<BenC> mjg69: enabled hotplug_cpu for amd64 and i386 targets, along with acpi sleep/suspend stuff
<mjg59> BenC: Rock, thanks
<mjg59> BenC: Does that break ABI?
<BenC> doing an abi bump anyway, since I synced a lot from linus
<mjg59> Ok
<mjg59> Any ETA on uploading it?
<BenC> lamont: do you have a breezy palo.conf I can look at?
<BenC> mjg59: 2-3 days, depending on lrm and vga16fb patch
<mjg59> Suspend/resume tends to show breakage at all sorts of inopportune moments, so it'd be good to get as much testing time as possible
<mjg59> BenC: Ok, sounds good
<BenC> just glad we could enable it without a lot of extra patching :)
<lamont> BenC: yeah
<BenC> and /etc/kernel-img.conf if you don't mind
<BenC> my system is just a dist-upgraded woody box (really old)
<lamont> btw, if you're so inclined, please enable BLK_DEV_IDEPCI, BLK_DEV_IDEDMA_PCI, and then BLK_DEV_NS87415 - fabbione and I will thank you
<lamont> all hppa configs, as modules where appropriate
<BenC> ok, I wont need those for my A500, right?
<lamont> no, the NS87415 chipset is a PCI IDE chipset that is used for the J[57] 000 and others.
<lamont> as well as some sparc64 machines.
<lamont> so as it sits, I get to net-install J series boxen
<BenC> sure thing
<BenC> lamont: confs?
<lamont> as in, you want me to make configs that I'm happy with and point you at them, yes?
<BenC> or paste ones you already have :)
<BenC> I'm not sure how to setup palo.conf for initrd and *.old stuff
<lamont> ah, ok. we currently have kernel-package tweaked to default to initrd (instead of initramfs) for hppa/ia64, if that's what you mean
<lamont> cat /etc/palo.conf 
<lamont> --commandline=2/vmlinux root=/dev/sda5 initrd=2/initrd.img HOME=/
<lamont> --recoverykernel=/boot/vmlinux-2.6.12-9-hppa32-smp
<lamont> --init-partitioned=/dev/sda
<lamont> that's what palo.conf looks like for me.
<BenC> ok
<lamont>  cat /etc/kernel-img.conf 
<lamont> do_symlinks = yes
<lamont> relative_links = yes
<lamont> do_bootloader = no
<lamont> do_bootfloppy = no
<lamont> do_initrd = yes
<lamont> link_in_boot = yes
<lamont> both stock install results
<BenC> thanks
<lamont> the list I gave you above of BLK_DEV defines is the dependency chain to turn on NS87415, fwiw
<BenC> yeah, already done in my git
<BenC> so it will be in the next upload
<lamont> thanks
<BenC> lamont: here goes nothing...
<BenC> hippo:~# uname -a
<BenC> Linux hippo 2.6.15-6-hppa64-smp #1 SMP Tue Nov 29 16:26:27 EST 2005 parisc64 GNU/Linux
* BenC does a little dance
<BenC> lamont: you can thank me with a beer at the next dev summit :)
<lamont> YIPPEEE!!!!
#ubuntu-kernel 2006-11-27
<zul__> do do do
<BenC> kylem: If it fixes bugs, then it's definitely a candidate for proposed-updates
<zul> hey BenC 
<BenC> hey zul
<kylem> BenC, the vendor driver is pretty crap...
<zul> BenC: bravo :)
<BenC> zul: for what?
<zul> the posting to the -devel ml
<BenC> heh, I'm getting tired of feeling like everyone's personal fuck toy...
<zul> i can understand
<ajmitch> "why didn't you do this?!? it's *critical*"
<zul_> night..
<ajmitch> seems that vmware module patching wasn't entirely correct, tcpdump is showing a lot of invalid checksums
<ajmitch> needed to be CHECKSUM_PARTIAL, not CHECKSUM_COMPLETE
<fabbione> BenC: gfs1 in .19 is totally busted
<fabbione> i am afraid some of the porting bits you did are not 100% correct
<Mithrandir> BenC: regarding 14908 ; it's marked as "later" which means I need it fixed ASAP; any chance you could get to it soonish?
<AnAnt> BenC: ping
<AnAnt> anyone here ?
<neuralis> AnAnt: what's up?
<AnAnt> the PREEMPT thing
<AnAnt> what is CONFIG_PREEMPT_VOLUNTARY ?
<AnAnt> what's the difference between CONFIG_PREEMPT_VOLUNTARY & CONFIG_PREEMPT ?
<AnAnt> and what has Timer frequency value to do with the PREEMPT option ?
<AnAnt> neuralis: hello ?
<neuralis> these are general questions; you might wish to google around or read the source.
<neuralis> (you're asking questions about standard operating systems theory.)
<AnAnt> what should I search for there ?
<AnAnt> ok, I can turn on KERNEL_PREEMPT at run time ? do I understand correctly ?
<Mithrandir> BenC: shouldn't 65106 be marked as fix released now ?
<AnAnt> how can I find out the KERNEL compile options ?
<AnAnt> I am using the generic kernel
<willvdl> hi folks, does edgy kernel have i2c support by default?
<willvdl> [struggling with lmsensors] 
<AnAnt> you can know from /boot/config-$(uname -a)
<AnAnt> oops sorry
<AnAnt> you can know from /boot/config-$(uname -r)
<AnAnt> in the -generic kernel I2C is compiled as modules
<AnAnt> ie. you can modprobe it
<pradeep> willvdl, ^
<willvdl> one sec
<willvdl> config-2.6.17-10-generic
<willvdl> AnAnt, what should I be modprobing?
<AnAnt> willvdl: dunno
<willvdl> ah, good point. thanks though
<AnAnt> can I turn on KERNEL_PREEMPT at run or boot time ? 
<AnAnt> willvdl: I never used I2C
* Starting logfile irclogs/ubuntu-kernel.log
<BenC> AnAnt: PREEMPT is a compile time option only
<fabbione> BenC: can you please pull from my feisty branch on people in a tree that you can kill and tell me if the commit log is ok?
<fabbione> (there is only one commit to update GFS=
<BenC> fabbione: pulled, looks good
<fabbione> BenC: ok thanks
<fabbione> gfs1 is still fux0red
<fabbione> but i have some gfs2 fixes to push to you soon
<AnAnt> BenC: I saw on some website that it can be configured in run/boot time, was that in earlier 2.6 kernels ?
<kylem> ugh. so much spam.
<zul> meh...feels like im wearing concrete blocks for shoes
* BenC needs coffee
<Mithrandir> BenC: if you could respond to my questions in backlog, that'd be useful.
<BenC> Mithrandir: Looks like userspace stuff
<BenC> Mithrandir: I'll look into it
<Mithrandir> sure, 14908 is userspace stuff; it's kernel packaging.
<BenC> Mithrandir: Ah, I see, the file touching thing
<Mithrandir> BenC: yup, exactly.
<zul> *sigh* they might be replacing the mail server at work exchange..
<JanC> zul: I hope you don't mean "* by Exchange" ?  :-/
<zul> yeah with exchange...i need more coffee
<JanC> well, you will need lots of coffee if they do (for waiting ;) )
<zul> im not touching it
<Keybuk> <kay>  tree /sys/module/usbcore/
<Keybuk> <kay>  /sys/module/usbcore/
<Keybuk> <kay>  |-- drivers
<Keybuk> <kay>  |   |-- hub -> ../../../subsystem/usb/drivers/hub
<Keybuk> <kay>  |   |-- usb -> ../../../subsystem/usb/drivers/usb
<Keybuk> <kay>  |   `-- usbfs -> ../../../subsystem/usb/drivers/usbfs
<Keybuk> <kay>  |-- initstate
<Keybuk> <kay>  |-- parameters
<Keybuk> <kay>  |   |-- blinkenlights
<Keybuk> <kay>  |   |-- multithread_probe
<Keybuk> <kay>  |   |-- nousb
<Keybuk> <kay>  |   |-- old_scheme_first
<Keybuk> <kay>  |   |-- usbfs_snoop
<Keybuk> <kay>  |   `-- use_both_schemes
<Keybuk> <kay>  |-- refcnt
<Keybuk> <kay> i already have that :)
<BenC> infinity: ping
<badock> hello all
<badock> i'd like to know something : if i want to cross-compile kernel for my ubuntu machine, can i do it on another machine, by just 'making' the sources with the .config of my ubuntu machine ?
<kylem> hmm, redhat defaults to HZ=1000
<BenC> kylem: what about preempt
<kylem> same as us
<kylem> voluntary and preempt the bkl
* kylem agrees that HZ=1000 is not appropriate for most lapto pusers though.
<dade`> kylem: I read a pdf where it says that changing hz from 1000 to 100 affects battery life for something like 2%
<JanC> hm, I use my laptops with the AC cable 90% of the time  :)
<JanC> and 2% isn't really significant
<JanC> the applications I use have more impact on battery life than that
<JanC> (if that 2% is correct)
<JanC> e.g. one bug in edgy's nautilus might have like 20-30% impact on battery life...
<BenC> JanC: I think he means it affects 2% of people
<JanC> dade`: can you clarify?  :)
<dade`> wait, i'm not so good in english, i try to find the pdf
<dade`> http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/doc/OLS2006-bltk-paper.pdf
<dade`> is there a way to turn off bluetooth ?
<JanC> it looks like 1000Hz isn't really a problem for laptop users when the system is idle
<dade`> there is something else that wastes power energy
<dade`> HZ seems to be not so important
<dade`> I did some lame test on my macbook, osx consumes 1200/1300 mah, linux does ~1800 idling on  same conditions
<dade`> and on heavy load the difference is even bigger
<JanC> that doesn't compare interrupt frequency on linux though  :)
<JanC> 'I wish the linux test labs funded by the major linux distributions would do such tests...)
<JanC> * and major linux service providers *
<JanC> I mean, what are they doing with all that money from IBM & co. ?   ;-)
<dade`> do you have a laptop ? wich one ?
<dade`> which
<JanC> I have an Intel Core Duo 2300 (Centrino)
<JanC> local brand laptop based on an MSI "barebone"
<dade`> ok
<dade`> i tried to boot without loading ANY bluetooth module
<dade`> and my bluetooth mouse just works
<dade`> funny huh ?
<JanC> dade`: udev ?  :)
<dade`> udev what ?
<JanC> how do you load no bluetooth?
<dade`> if the module is not loaded bluetooth sould be off
<JanC> udev will (should) load all necessary modules when it's needed...
<dade`> when it's needed
<dade`> lsmod showed no bluetooth module loaded
<dade`> isn't this enough ?
<lehaid> hi
<JanC> before or after using the bluetooth mouse?
<lehaid> what the most recommended place to read about compiling my own ubuntu-kernel for 6.06?
<JanC> lehaid: see /topic
<dade`> before
<dade`> i guess
<JanC> dade`: it's possible tha tudev just loaded that driver after that then?
<dade`> no
<dade`> i look at it while using the mouse
<JanC> in that case, i can only imagine some sort of BIOS emulation  :)
<dade`> yes it looks like an usb mouse
<dade`> but i don't care about this, i just wanted to power off bluetooth to save energy !
<dade`> and there is no way
<lehaid> i want to compile an kernel module which packages should i have besides the linux-headers or is it enough ?
<JanC> dade`: remove all bluetooth drivers  :)
<JanC> or maybe you can disable bluetooth fysically
<dade`> i think it works anyway 
<dade`> there is no hw button in macbooks
<lehaid> anybody know what i need besides that?
<lehaid> shouldn't /usr/include/linux hold the kernel headers?
<zul> right im heading home...later..
<ajmitch> bye zul 
<crimsun> BenC: thanks for -lowlatency!
<BenC> crimsun: :)
<tormod> BenC: you confirmed bug #72765, with no comment. Did you reproduce it yourself?
<BenC> tormad: I confirmed it based on your answers...you seemed to be confident that it was only reproducible with 2.6.19 kernels and not 2.6.17
<BenC> tormad: Is my faith in your confidence misplaced? :)
<tormod> benc, of course not (but yout spelling is :) I was just curious if you saw it somewhere else.
<BenC> tormod: ok, I just marked it as such to make sure I keep an eye on it...I have nothing to work with yet, unless you are willing to do a git-bisect to recompile the kernel a bunch of times to nail down the commit that started it
<tormod> benc, I wonder if it has to with the pata transition. Is there a way I kind force the old pata back?
<tormod> s/kind/can (I spell funny today too)
<BenC> if you download the kernel source you should be able to compile just the ide module and try it out
<BenC> you'd have to move it to /lib/modules/`uname -r`/kernel/drivers/ide/pci/,  blacklist the pata module and rerun "sudo update-initramfs"
<tormod> can I not remove some module from the initrd
<BenC> the old ide module is not being built for your chipset if you now have a pata module
<tormod> would that be the ide/pci/via82cxxx.ko module in my case?
<tormod> benc, thanks, I will look into this (but not tonight).
<tormod> benc, just one more question, through which module/src file is the "stop" sent to the drives?
#ubuntu-kernel 2006-11-28
<BenC> tormod: for ide it's in drivers/ide/*.c, for pata it's in the libata module in drivers/ata/
<tormod> thanks and good night
<infinity> BenC: pong?
<BenC> infinity: ia64 kernel images are built, but not available
<zul> hey BenC have you had a chance to look at the spec yet?
<infinity> BenC: Looks like ports.u.c is out of date, drescher is fine.
<BenC> ok, thanks
<BenC> zul: No, I'll try to get to it tonight
<zul> okie dokie..
<infinity> BenC: If you need the generated binaries, you can always yank them from launchpad.
<BenC> infinity: Fortunately the next upload is an abi bump, so no need right now
<BenC> plus I can grab my local build
<fabbione> BenC: mind to git pull git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-2.6-nmw.git ?
<fabbione> BenC: since we are bumping abi is good to have
<fabbione> nmw is stuff for .20 and it fixes a bunch of critical bugs in GFS2
<fabbione> it also requires a config change
<fabbione> to set the default DLM protocol (please use TCP for now)
<BenC> if it's going into .20 I'd rather wait till it's in there to keep the tree clean
<fabbione> BenC: it's rather important to me to test GFS2
<BenC> if I pull from there, and then merge with linus, I'm liable to get a lot of conflicts
<fabbione> without i can't do much
<fabbione> linus is pulling from there...
<BenC> Ok, let me see how this pull looks
<fabbione> there should be no conflict
<fabbione> if both of you pull from the same, the sha are the same
<fabbione> --- a/debian/config/i386/config
<fabbione> +++ b/debian/config/i386/config
<fabbione> @@ -484,6 +484,8 @@ CONFIG_DLCI=m
<fabbione>  CONFIG_DLCI_COUNT=24
<fabbione>  CONFIG_DLCI_MAX=8
<fabbione>  CONFIG_DLM=m
<fabbione> +CONFIG_DLM_TCP=y
<fabbione> +# CONFIG_DLM_SCTP is not set
<fabbione>  # CONFIG_DLM_DEBUG is not set
<fabbione>  CONFIG_DM9102=m
<fabbione>  CONFIG_DMA_ENGINE=y
<fabbione> BenC: this is the config change i had locally.
<fabbione> (for that pull)
<BenC> zul: ping
<fabbione> BenC: did you pull/push the gfs change to kernel.org?
<BenC> fabbione: Not yet, cleaning some other stuff up first
<fabbione> BenC: ok thanks
<fabbione> kylem: you can pull gfs from my branch on people
<fabbione> kylem: ~fabbione/archives/ubuntu-2.6.git
<fabbione> kylem: at least we are looking at the same code :)
<kylem> -ETOOTIRED :\
<fabbione> oh come on
<ajmitch> some users are very demanding
<fabbione> ajmitch: that's a REALLY REALLY REALLY nice statetment to hide: WTF THEY ARE SUCH BITCHES.. but nevermind
<ajmitch> pretty much
<ajmitch> zul: I can't test your kernel on feisty now - udev wants 2.6.19 for it to be able to create an initramfs
<infinity> BenC: Hrm.
<infinity> BenC: The -lowlatency in universe thing will be interesting.
<infinity> BenC: The headers will have to be in main, or LRM won't be buildable.
<BenC> infinity: Hmm...that sucks, but I can do that
<BenC> fabbione: pulling from you now
<fabbione> BenC: thanks
<BenC> $ git-pull people-fabbione
<BenC> Already up-to-date.
<fabbione> BenC: you pulled yesterday.,. i have nothing new there except a local merge of nwm tree
<BenC> ah
<fabbione> but i didn't want to push to you without your eyeballing
<crimsun> BenC: I'm beginning a fairly big push to alsa-git, so you should be able to stop considering quite a few alsa issues soon
<fabbione> tho it would be nice to have
<BenC> I can check your stuff before pulling it in
<fabbione> BenC: ok..
<BenC> crimsun: Would be nice if alsa would get all synced up in 2.6.20
<crimsun> yep, that's my goal
<ajmitch> how far off is 2.6.20 upstream?
<BenC> I think 2.6.19 will be released this week
<BenC> so I'll be moving everything in feisty to 2.6.20 starting next week if all goes well
<BenC> basically it will start out as 2.6.19+git :)
<BenC> 2.6.19 will disappear. Even launcpad bugs will all get changed over to linux-source-2.6.20...it will be the biggest cover up since the Kennedy assassination
<ajmitch> sneaky
<fabbione> ahah
<fabbione> OMG 2.6.20 killed Kenny
<infinity> BenC: Do you plan to do ABI tracking out of the gate?
<infinity> BenC: Cause we'll end up shipping 2.6.20-50 at that rate...
<fabbione> infinity: we can always reset when we switch to .20 for real
<BenC> It'll be reset, and tracked from the start
<tepsipakki> have I understood correctly that there'll be a kernel update for dapper coming this/next week?
<infinity> Probably.
<lehaid> hi, how can i know if a given module in the ubuntu kernel is compiled with a flag or not ?
<dade`> look in /boot/config-`uname -r`
<lehaid> yeah, the flag doesn't exist there
<lehaid> but the part of code i am looking has an #IFDEF for it
<zul> BenC: pong
<lehaid> how come the /boot/.config of the offical ver has no CONFIG_NF_ lines in it ?
<lehaid> (yet there is NF support)
<zul> meh
<lehaid> ?
<lehaid> is the default ubuntu kernel compiled with CONFIG_NF_CONNTRACK_EVENTS ?
<zul> check the config file
<zul> BenC: you ponged?
<zul> right oim off to the dentist back later
<lamont> lehaid: and you'll find that it isn't (at least in dapper and edgy)
<lamont> 686 and generic kernel that is - best to check the config file in the kernel package you actually care about, but I expect that it's probably a universal "no"
<BenC> zul: Did you notice that rusty's paravirt ops patches has xen built-in?
<BenC> for 2.6.19-rc5
* kylem read through the dynticks stuff in -mm last night... hopefully that goes into 2.6.20.
<makx> is the tsc thing solved?
<kylem> no.
<BenC> kylem: 2.6.17.y is updated for -security, and pushed
<BenC> still need to build, but at least we can be on the same repo
<dade`> i want to be a mactel tester
<dade`> \o/
<BenC> \O/ is what it will look like when you're done :)
<BenC> mjg59: ping
<mjg59> BenC: Hi
<BenC> mjg59: Hey, I'm going through these mactel patches
<BenC> mjg59: I have the smc and ir modules in, but some of these patches look like they should only be used in a kernel that is just for mactel...is that the case?
<BenC> things like the usb-storage-zerowait patch
<BenC> piix-ich7 too
<BenC> the s3 one looks a little iffy
<mjg59> BenC: I told you to ignore those ones yesterday :)
<BenC> I remembered that, but wanted to make sure :)
<mjg59> The piix-ich7 one can be ignored - it's irrelevant to non-EFI systems
<mjg59> Basically, drop anything that touches ACPI
<mjg59> And the usb-storage one
<BenC> even the acpi-blacklist one?
<mjg59> Yeah
<mjg59> It's EFI-only
<mjg59> And we're not supporting that
<BenC> So, these: appletouch-geyser4 mouseemu sci_en sigmatel_audio usbhid
<mjg59> No, not sci_en either
<mjg59> That's actually the same as the s3 one, and it's upstream already
<BenC> Ok
<mjg59> I'm a bit concerned about the sigmatel_audio
<mjg59> That's something that should really be run through the alsa guys
<mjg59> The input stuff is all fine
<BenC> so we are only supporting bootcamp?
<mjg59> Yes
<BenC> what's keeping the input stuff from being merged upstream?
<mjg59> No idea
<mjg59> Failure to push it, I suspect
<dade`> there is a page that explains how to set some bytes to make mic in work on macbooks, did you see that ?
<dade`> ..
<dade`> don't know if this fix is included in mactel patches
* dade` does not feel useful
<zul> hey
<zul> BenC: no i didnt.....this isnt the lhype stuff is it?
<tormod> benc, wrt bug #72765, it's the fault of pata - the ide module makes a quiet poweroff. In ide-disk.c I find: drive->gendev.bus->suspend(&drive->gendev, PMSG_SUSPEND); I am looking through libata-core to find something equivalent.
<tormod> benc, I guess that would be in libata-core.c: host->dev->power.power_state = mesg;
<zul> BenC: looks like the basics are there for paravirt but not a full blown paravirt yet
<BenC> zul: Yeah, it appears to be lhype
<zul> basically its rusty's way to prove that paravirt works :)
<zul> http://lists.osdl.org/pipermail/virtualization/2006-November/001794.html
#ubuntu-kernel 2006-11-29
<zul> hell its freaking cold
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/CategoryKernel | 2.6.19-7.10 uploaded - DIE BEAR, DIE. Use it, but there are still a few missing modules.
<kylem> ah, finally the bear gets to die.
<BenC> that's probably the last 2.6.19 kernel for us
<kylem> yeah, word on the street is .19 should been out today.
<BenC> kylem: you can have first dibs on the loin meat if you want
<kylem> haha.
<zul> mmm...meat
<crimsun> thanks, Ben. :)
<zul> yay for 2.6.20
<ajmitch> more breakage, more fun
<zul> paravirt
<ajmitch> hopefully it'll be useful
<zul> BenC: do you want me to test the paravirt crack when we switch over to .20?
<mjg59> The bear, the?
<kylem> ok, this is a good bear.
<kylem> hmm. no, wait, this is a good beer.
<ajmitch> mm, beer
<kylem> ok, that cve is now in upstream so it's probably fine to push
<BenC> mjg59: You really don't want to know about the bear
<zul> i think we all do
<kylem> no, i don't think you do.
<kylem> it's our horrible company secret.
<zul> meh
<BenC> I have nightmares about the bear
<kylem> hehe.
<zul> heh whatever..
<kylem> it was pretty terrifying.
<BenC> zul: Anyway, it would have to be explained in person
<BenC> or via a video
<BenC> there's no way to convey the bear over IRC
<zul> heh ok at the feisty+2 uds you can explain it to me
<kylem> the bear was pure evil.
<BenC> zul: I'm hoping by next UDS that therapy will have helped me to forget about the bear
<zul> BenC: heh i probaly wont be at next uds oh well 
<BenC> you'll be a daddy around that time, wont you?
<zul> yeah i proably wont be going anywhere for a while
<zul> i value my health
<BenC> think twice before buying your kids a teddy bear :)
<zul> lol
<zul> mmm...south park
<zul> night
<BenC> good night
<ajmitch> night zul 
<mjg59> BenC: I'm... familiar with the bear
<BenC> mjg59: you've been tainted?
<mjg59> I know a sufficient number of people who have
<mjg59> I've avoided it myself, thankfully
<BenC> you're so lucky
<kylem> pure. evil. i tell you.
<infinity> I don't know what you guys are on aboutl.
<infinity> The bear kinda got me hot and bothered.
<fabbione> morning
<BenC> hey fabbione
<fabbione> hey ben
<kylem> mornings are evil.
<fabbione> BenC: do you think we can set LC_ALL=C somewhere in debian/rules ?
<fabbione> debian/control* gets mangled by locale sorting otherwise
<fabbione> i remember fixing this once.. 
<BenC> fabbione: Sure
<fabbione> BenC: thanks
<fabbione> BenC: do you have edgy-updates somewhere?
<fabbione> or -security?
<BenC> they are on master
<BenC> master.kernel.org I mean
<fabbione> i have no access to master
<BenC> and should be on people too
<BenC> fabbione: s/master/git/
<fabbione> http://www.kernel.org/git/ doesn't show them for you
<fabbione> just making sure we have the include/asm-sparc64/futex.h fix
<fabbione> it's not in ubuntu-edgy.git
<BenC> fabbione: I pulled 2.6.17.y, so we should have it
<BenC> www.kernel.org is so slow
<kylem> use www2
<fabbione> ubuntu-edgy$ patch -p1 < /home/fabbione/temp/T1000\ CPU\ lockups.eml 
<fabbione> patching file include/asm-sparc64/futex.h
<fabbione> so no
<fabbione> it's not there
* fabbione forward the patch again
<fabbione> kylem: kyle@ubuntu.com ?
<fabbione> or kylem ?
<BenC> I still have the patch
<fabbione> ok cool
<kylem> kyle@, but kernel-team@ would probably be better for such things.
<BenC> fabbione: Can you paste part of the patch?
<fabbione> kylem: why on earth makes you think that i want to spam myself?
<BenC> is it the NRSYSCALLS increment?
<fabbione> nope
<fabbione> futex_atomic_cmpxchg_inatomic
<BenC> fabbione: http://www2.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-edgy.git;a=commit;h=6e57a3a89785692bd8d012d80f5ee210ab8e0b68
<kylem> fabbione, what? so set mailman to not deliver to you when you're the sender:
<fabbione> BenC: yes that one
<fabbione> wtf
<fabbione> BenC: nope.. that's the first implementation
<fabbione> BenC: it needs the fix
<BenC> ok
<fabbione> BenC: i did /msg the patch
<BenC> yeah, I got it :)
<fabbione> yeah it's the one that fixed 68266
<fabbione> now.. i wonder why on earth it's even private that bug
<fabbione> it's a problem that has been discussed publically everyfucking where
<BenC> fabbione: cherry picked and pushed
<fabbione> BenC: thanks
<BenC> fabbione: np
<fabbione> kylem, BenC: did any of you already uploaded 2.6.17-10.34 ?
<fabbione> i guess not
<fabbione> BenC, kylem: please pull from my ubuntu-edgy-updates.git tree on people.u.c. There is a fix for bug #69916
<dade`> 'morning
<fabbione> today git hates me
<fabbione> BenC/kylem: 69916 has patches in attachement
<dade`> dpkg-gencontrol: error: package linux-headers-2.6.19-rc6-ubuntu1 not in control info
<dade`> I always get this while compiling the git kernel
<dade`> but I didn't asked to build kernel headers
<dade`> http://pastebin.ca/261453 -- why ?
<dade`> ..
* kylem goes to make some coffee
<datten> kylem java? *g* 
<BenC> mmm...coffee sounds good
<kylem> :)
<kylem> espresso sounds better though... didn't think far enough in advance.
<zul> caffine in general is good
<dade`> BenC: maybe you have an auto-ignore-on-flood ? 
<dade`> no ok :)
<kylem> BenC, did you cherry pick that sparc64 futex fix?
<BenC> kylem: Yeah, I pushed it to ubuntu-edgy.git
<kylem> ahok
<kylem> not to kernel.org?
<BenC> kylem: It should be on kernel.org too
<BenC> my push-all script pushes to master.k.o and people.u.c
<BenC> kylem: Oh wait, I forgot to push
<BenC> pushing now
<kylem> :)
<BenC> done
<kylem> thanks. did you hear back from elmo?
<BenC> not yet...let me bug him
<kylem> k-o
<thom> k-o? Is your hair getting aggressive again?
<kylem> heh
<dade`> does not sleep
<BenC> intinify: ping
<zul> argh...bored
<dade`> madwifi wlan_scan_sta does not load on .19
<dade`> hmm
<dade`> [   22.528000]  wlan_scan_sta: Unknown symbol preempt_schedule
* kylem goes to purchase some sugary caffeine delivery vector.
<BenC> dade`: That's because you need to sync your modules and kernel
<dade`> sync ? i rebuilt them 
<kylem> mmm mountain dew.
<Mithrandir> your contract is in mountain dews/day, right?
<dade`> BenC: -^
<kylem> Mithrandir, heh
<zul> bleh mountain dew
<zorglu_> q. on which criteria /dev/random is feeding its entropy pool, my /dev/random is blocking very frequently 
<kylem> and there goes .19 :)
* ajmitch cheers
<ajmitch> now you can start breaking things for .20
<kylem> woo. let's get this party started. ;-)
<markedwards> I'm looking into the sky2 driver fix detailed in Bug #68338.  Does anyone have a rough idea when a fix might happen? Just curious what kind of schedule you guys are on.  Thanks!
<kylem> markedwards, i don't think there's a fix in the edgy tree yet, i'll talk to ben about it.
<markedwards> kylem: thanks. is this kind of fix generally pretty low-priority?  I mean, I imagine a kernel update is a pretty complicated matter...
<kylem> i'm working on an update anyways, so it shouldn't be too big a deal.
<markedwards> kylem: thanks!  good to know.
<markedwards> kylem: ethernet hanging is driving me nuts :-)
<kylem> yeah, if it's a common chip on new laptops, we should really try to get it going. :)
#ubuntu-kernel 2006-11-30
<kylem> BenC, woot. i see you bumped to .20 :)
<BenC> kylem: you saw it here first, zero-day linux kernel ;)
<kylem> hehe
<kylem> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.19/+bug/73815
<zul__> BenC: does virt work yet?
<kylem> BenC, ^-- is fixed in newer .19, mind if i reject?
<kylem> (the problem is hda_intel defaulted to enable_msi, which is broken on 99% of machines, it's been fixed upstream since, and you've already pulled it.)
<BenC> kylem: Mark it fix released
<BenC> zul__: The 2.6.20 is just 2.6.19 in disguise
<zul__> BenC: i know :)
<kylem> BenC, k.
<BenC> zul: Sorry, I lost the sarcasm :)
<zul> BenC: heh how about now
<kylem> https://bugs.launchpad.net/distros/ubuntu/+bug/68338
<kylem> BenC, ^-- any objection if i pull in a backported sky2 to -updates?
<BenC> kylem: Nope
<BenC> kylem: BTW, I'm thinking about making a temporary git repo location for us on people
<kylem> BenC, sounds good. i'd like to hopefully get a git.ubuntu.com or something as well for public stuff, kernel.org has been pissing me off...
<ajmitch> another git repo for us to pull?
<zul> that would be nice
* ajmitch is just pulling the current .19/.20 now to play with
<BenC> ajmitch: Not really, another git repo for no one to pull :)
<zul> where us community people can put crack as well would be good
<BenC> zul: There's that too
<BenC> hmm..I could host it on my T1
<BenC> use this 965 box that canonical sent me
<ajmitch> zul: your home cable connection not good enough for you? :)
<jdong> what are the chances that Feisty's shiny 2.6.19 kernels would work on Edgy? :D
<kylem> ajmitch, the problem is we need a place to put things with private security fixes until they are fisclosed.
<ajmitch> kylem: quite true
<zul> ajmitch: uh not really when people like Mirthandir cant access it
<ajmitch> jdong: I hope you're not thinking of backporting it
<kylem> jdong, you need a few other dependencies.
<jdong> ajmitch: for my personal purposes
<jdong> ajmitch: not publicly of course :D
<zul> BenC: that would be good
<zul> then i can try throttling your connection ;)
<zul> in a good way
<jdong> crap, trying to build a kernel in tmpfs was probably bad judgement on my part, huh....
<jdong> cat: /var/cache/prevu/src/24944/linux-source-2.6.19-2.6.19/debian/abi/2.6.19-7.10/abiname: No such file or directory
<jdong> pfft, bogus
<jdong> kylem: what kind of dependencies woudl I need?
<kylem> initramfs-tools and module-init-tools, i think
<jdong> mmm
<zul> have we merged kernel-package yet?
<BenC> jdong: You can just install the feisty kernel deb's on edgy
<BenC> all my machines are still running edgy userspace with feisty kernels
<BenC> jdong: But just to make sure, install the packages kylem mentioned
<jdong> BenC: ok, thanks will do :)
<jdong> BenC: heh restricted modules debs need recompiling... libc, qt, etc libs mismatch :)
<BenC> jdong: You can just do a partial upgrade
<jdong> err
<BenC> set sources.list to feisty, sudo apt-get install linux-generic, then switch sources.list back
<jdong> err ok :)
<jdong> fglrx-control wants to pull in new libc6, and I'm chickening out.... :)
<zul> night
<ajmitch> night zul 
<infinity> BenC: For the next LRM upload, remember to s/restricted/multiverse/ for -lowlatency stuff (I already did so in the archive overrides)
<BenC> I thought I had that right
<infinity> You got it right in linux-meta, not in LRM.
<BenC> ok, I'll get it fixed up
<infinity> Spiff.
<dade`> 'morning
<fabbione> BenC: are we going to enable ext4 in .19/.20 ?
<fabbione> not that i need > 8TB storage
<fabbione> at least i don't quite yet
<jdong> fabbione: ooh, that'd give me a new toy to play with :D
<fabbione> jdong: do you have storage for more than 8TB?
<jdong> fabbione: no, but people say ext4 will do better with large files?
<jdong> and I do have some 20GB video files that ext3 is not exactly spectacular with
<kylem> BenC, are you on vendor-sec?
<infinity> He's not, afaik.
<kylem> one of us probably should be, or fed encrypted copies of kernel problems...
<infinity> You're an upstream kernel guy, no?
<infinity> You should get on kernel-security@k.o, or whatever that list is.
<infinity> Oh, just security@k.o
<kylem> is vendor-sec @lst.de?
<infinity> Yeah.
<kylem> heh. hch.
<fabbione> kylem: we have pitti and kees on vendor-sec anyway
<fabbione> kylem: just coordinate with them.. it's easier and less pain
<BenC> kylem: no
<BenC> as in, no I'm not on vendor-sec
* kylem nods.
<jerom1> Hi all
<jerom1> i have problem when i install HP Proliant DL360 G5 server with PXE and last dapper-updated netboot archive
<jerom1> it append many log in /var/log/syslog and loop :
<jerom1> kernel : hub 5-2:1.0 : USB hub found
<jerom1> 7 ports detected
<jerom1> USB disconnect, address 10
<jerom1> new full speed USB device using uhci_hcd and address 12
<jerom1> input : HP Virtual Keyboard as /class/input/input1522
<jerom1> input : HP Virtual Keyboard as /class/input/input/1523
<jerom1> input : USB HID v1.0.1 Mouse [HP Virtual Keyboard]  on usb-0000:01:04.4.1
<jerom1> USB disconnect, address 11
<jerom1> and loop with another address number
<fabbione> jerom1: please file a bug in launchpad and check if older netboot installs work
<zul> hey
* kylem does a couple test builds pre-push.
<dade`> desert is the only kernel developer that has a macbook ?
<zul> if you want to send me one my way ill be happy to help you out ;)
<zul> muhahha...i dont have to setup ldap for central authenticaion
<kylem> ugh, i was working way too late last night.
<zul> how late?
<kylem> 2am.
<zul> yeah thats pretty late
<kylem> and up at 6.
<zul> ouch
<dade`> zul: you can tell me what to do without having one, i'll be your eyes
<zul> i know nothing about macs
<zul> kylem: heh 11:30 is late for me
<dade`> 8:01 pm here
<jbailey> BenC: Around?
<BenC> jbailey: yeppers
<jbailey> Looking at:
<jbailey>   * debian/firmware: Add qla2xxx firmware.
<jbailey>     - GIT-SHA c980a1cfa2bc6623c9732ebae9d63aae9f0d7e27
<jbailey> I wound up helping a couple Debian folks figure out how to load firmware stuff in the initramfs for their things.
<jbailey> I think we'll inherit patches soon from Debian if it's easier to not explicitely add firmware and just have them on the drive.
<BenC> jbailey: Ah...we need a method for automating that I guess
<jbailey> (so not do Debian-style rip it all out, but don't go out of our way to stuff it in)
<BenC> jbailey: So far qla2xxx is the only one that we provide that needs this, right?
<BenC> jbailey: I could add a small bit to hook-functions to see if qla2xxx driver is loaded, and pull the firmware in explicitly
<jbailey> YEah, and I think that's the one that James Bottomley and Grant Grundler were asking about.
<jbailey> So we might be able to just pull a solution from them.
<BenC> sounds like it should be possible with just 2 lines of code
<BenC> or there abouts
<BenC> jbailey: Oh, btw, vmware modules are going to get a nice overhaul in the next lrm
<jbailey> Nice!
<jbailey> Will that include all the vmware-tools stuff?
<BenC> vmware-{player,server,tools}
* jbailey ^5's Ben!
* BenC acts like he hasn't seen jbailey in 10 years and ^5's him back
<jbailey> Now quick.. The ship is sinking!
<BenC> we need BUTTER!
* fabbione takes the opium and the wine on his boat and lets the other sink with the titanic
<zul> hmmm...ok...weirdos
<jbailey> You go MacGyver. =)
<BenC> fabbione: nice, wine to keep you warm, and opium to make you not care that you are sure to die :)
<zul> mmm...titanic
<fabbione> BenC: hmm no.. that the others are dieing :)
<BenC> hehe
<jbailey> fabbione: You forgot the shotgun.
<jbailey> In case someone wants to make you share. =)
<fabbione> jbailey: aahha
<kylem> should have shot the captain.
<BenC> kylem: You mean the pop-eye looking guy at the front of the room? :)
<kylem> yeah, the village people reject
<kylem> ;-)
<BenC> lol
<fabbione> ROFL
<jbailey> kylem: I think Jamu tried to get people in line with shotguns, and the crew refused to shoot the passengers.
<kylem> so shoot the crew.
<kylem> make 'em learn.
<zul> then who is going to launch the lifeboats
<kylem> hmm should have pulled the
<kylem> "it's a boat full of christians, they're going to a better place"
<zul> hah
<jbailey> "The rest of you get to die of exposure in the middle of the atlantic.  Here's a life vest, jump in."
<dade`> BenC: is there a way I can get useful information for you to find and fix the kernel that prevent macbooks from sleeping ? 
<dade`> s/kernel/kernel module/
<zul> "Have fun"
<BenC> dade`: Sure, start unloading 5 modules at a time from lsmod output, until you get a successful suspend/resume
<dade`> BenC: there are modules i can't unload
<BenC> when you hit a group of 5 that made it work, go through them singly until you find the one that did it
<BenC> dade`: Try the ones you can first
<BenC> dade`: Start with networking and sound
<dade`> I suspect it's something PIIX related, 'cause i get the same problem i solved in 2.6.18 disabling piix.ko
<dade`> but I'll try.
<BenC> it's possible
<BenC> if you feel it's piix, then I'd hold off until I get the fixes in so you don't waste much time on it
<dade`> you have fixes for that '
<dade`> ?
<kylem> bleh sky2.
* kylem fixes sky2
<zul> yay
<zul> do do do..
<kylem> BenC, do you have some trick for testing trees, or should i just tar/scp them to the buildd and give 'em a whirl?
<BenC> fakeroot debian/rules binary-debs
<kylem> i wonder what will be slower... building on my laptop, or scping them. :)
<BenC> you can always do both and see which one finishes first :)
<kylem> haha.
<zul> brb need to reboot
<Mithrandir> kylem: ccache is nice.
<jbailey> Mithrandir: I don't think kernel's ccache well, do they?  I thought linux/version.h was included in everything.
<jbailey> IIRC, the version changes with every git commit..
<kylem> optional
<zul> jbailey: they dont ccache well imho
* kylem goes for lunch.
<BanditD> Hi! I have terrible write performance with the Edgy kernel, about 1 MB/s. Hardware is a Acer laptop, SATA disc, lspci shows 00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE (rev 02) and 0a:09.2 Mass storage controller: Texas Instruments Unknown device 803b. Anyone one idea what I can do? Thanks!
<kylem> is DMA enabled?
<BanditD> I am not sure:
<BanditD> tmm@nbk-wis018:~$ sudo hdparm -d /dev/sda
<BanditD> /dev/sda:
<BanditD> tmm@nbk-wis018:~$
<BanditD> tmm@nbk-wis018:~$ sudo hdparm -d1 /dev/sda
<BanditD> /dev/sda:
<BanditD>  setting using_dma to 1 (on)
<BanditD>  HDIO_SET_DMA failed: Inappropriate ioctl for device
<metres> hi guys, Im trying a recompilation of my kernel, but I have problem..., I just installed Edgy on my amd64, I downloaded the source linux-2.6.19 from kernel.org, unpack but when I try make xconfig, I got this response : "ake[1] : *** Pas de rgle pour fabriquer la cible  scripts/kconfig/.tmp_qtcheck , ncessaire pour  scripts/kconfig/qconf.o . Arrt." Do anyone have a clue ?
<BenC> metres: This channel is specific to the ubuntu kernel, not general kernel questions
<BenC> metres: Your question would be better asked in #ubuntu
<metres> Ok sorry 
<zul> BenC: i figured off an email to jeremy from xensource about paravirt
<kylem> there's pretty good indication kvm will be merged for 2.6.20
<BenC> kylem: Yeah, I saw the patches to lkml
<kylem> BenC, did you see the earlier discussion on that other irc channel? :)
<BenC> no, I missed it
<jbailey> kylem: Is there any indication that either Xen or VmWare will *use* the kvm?
<jbailey> Or is that still too much to hope for? =)
<zul> too much to hope for...they are using paravirt
<zul> er..paravirt-ops
<kylem> from what i can tell, the plan seems to be to evolve kvm.
<jbailey> Great.
<jbailey> Sounds like how pthreads was developped. =)
<kylem> and we all know how that turned out...
<zul> later...im heading home
#ubuntu-kernel 2006-12-01
<bluefoxicy> I'm noticing ubuntu's 2.6.19 kernel...
<bluefoxicy> wtf, I thought ingo's realtime stuff went into 2.6.19, it's not there
<bluefoxicy> ah o.o
<bluefoxicy> why is CONFIG_PREEMPT not set
<bluefoxicy> i.e. milisecond-latency kernel-level preemption
<bluefoxicy> on 2.6.19 feisty
<crimsun> it was discussed for -lowlatency but not for -{386,generic,server*}
<kylem> https://lists.ubuntu.com/archives/ubuntu-devel/2006-November/022755.html
<crimsun> apparently it was not enabled for -lowlatency as of 7.10
<BenC> whoops
<BenC> the PREEMPT portion of my config rewrite didn't take :/
<BenC> fix in git
<crimsun> thanks, BenC, I figured that's what happened (but it afforded an interesting opportunity to test the HZ change independently)
<zul> time for more sp
<BenC> stack pointers?
<zul> er...yeah...stack pointers..
<infinity> shower puffs?
<zul> super powers
<zul> only 2 more seasons to go
<BenC> sweet, gregkh is starting a kernel-packages mailing list
<zul> public?
<kylem> BenC, that's a good idea.
<BenC> yeah, it will be public
<BenC> it may be that subscribers have to be approved, but archives are open
<zul> cool
<kylem> ok, all 4 trees build generic ok.
<fabbione> git pull
<fabbione> fatal: unexpected EOF
<fabbione> Fetch failure: git://git.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git
<fabbione> No changes.
<fabbione> BenC: ^^
<tepsipakki> does the coming kernel release for dapper include the fix for https://launchpad.net/bugs/72696 ?
<tepsipakki> "tg3: doesn't recognize the network device on Fujitsu Esprimo E5915"
<fabbione> tepsipakki: just check in ubuntu-dapper.git
<tepsipakki> hmm, ok
<tepsipakki> syncing u-d.git ...
<tepsipakki> done. Are the pci-id's in the driver header (ie. tg3.h in this case)?
<tepsipakki> can't find 167b in it
<tepsipakki> the changelog is not updated since the previous release so maybe the mergers are yet to be done
<dade`> if i want to change the default git kernel config what should i change ?
<dade`> i tried editing debian/config/i386/config
<dade`> but does not work
<dade`> I set the PM_DEBUG option to yes, but the generated kernel installs a config file in /boot that does not have that option on
<dade`> https://wiki.ubuntu.com/KernelCustomBuild
<dade`> this page say it should
<kylem> be back in 20, need to venture forth into the snowy wasteland to find some coffee.
<BenC> I need give initramfs-tools a good larting
<BenC> it uses hooks script filenames as variable names in shell..so you can't have a script called foo-bar-2.1 for example
<Mithrandir> just do tr - _ on the name.
<BenC> I didn't want to have to change initramfs
<BenC> looks like I have to though, because it's actually a bug, IMO
<kylem> http://cvs.fedora.redhat.com/viewcvs/devel/kernel/linux-2.6-silence-noise.patch?rev=1.2&view=auto
<kylem> BenC, ^-- i see that message in a lot of bug reports, rh seems to feel it's unnecessary enough to hide from users...
<BenC> kylem: Yeah, most of those we have covered...the rest would be nice too
<BenC> I see the PCI resource one on my laptop
<kylem> hmm fedora has signed kernel modules.
<pmjdebruijn> kylem, they have had that for a while
<pmjdebruijn> kylem, RHEL4 has that too
<siretart> kylem: signed kernel modules? how do they do key management?
<kylem> haven't read enough to know.
<siretart> kylem: btw, while I catch you here, do you think you can upload kel's wpasupplicant upload, or shall we better ask someone else for now?
<kylem> ah, i can do that now.
<kylem> gotta upgrade my chroot...
<siretart> cool. thanks!
<elektranox> do I have to build a new kernel for making kernel modules?
<BenC> elektranox: No
<BenC> elektranox: Do this: sudo apt-get install linux-headers-`uname -r`
<BenC> elektranox: That's all you need to compile modules against your running kernel
<elektranox> BenC: But I get the warning, that make doesn't found an modules entry
<BenC> maybe you aren't compiling it right then
<BenC> www.rafb.net/paste/
<elektranox> I use the makefile of the module :/
<BenC> use that to paste the entire out of the build you are trying
<BenC> maybe the module is broken then, or perhaps you have to set the directory for the headers
<elektranox> should I translate the error to english, or are you able to understand german?
<elektranox> BenC: http://www.rafb.net/paste/results/WfmJWX63.html
<BenC> elektranox: Can you do it with "LC_ALL=C make" ?
<BenC> nm, I see the trans
<BenC> elektranox: ls -l /lib/modules/`uname -r`/build
<BenC> show me that please
<elektranox> the dir is empty
<BenC> it shouldn't be a directory, it should be a symlink
<BenC> show me the output of uname -r please
<elektranox> 2.6.17-10-386
<BenC> ls -l /usr/src/
<BenC> and that command
<elektranox> linux-headers-2.6.17-10
<elektranox> linux-headers-2.6.17-10-386
<elektranox> linux-source-2.6.17.tar.bz2
<BenC> ls -l /lib/modules/2.6.17-10-386/
<BenC> ls -l /usr/src/linux-headers-2.6.17-10-386/
<BenC> and both of those
<BenC> put those in pastebin
<BenC> elektranox: Output is too much for channel
<elektranox> ok
<BenC> well, it should be...if it isn't, then there's a problem :)
<elektranox> BenC: http://www.rafb.net/paste/results/lINqxv40.html
<BenC> elektranox: Looks like you've broken something on your system
<BenC> elektranox: /lib/modules/`uname -r`/build is supposed to be a symlink to /usr/src/linux-headers-2.6.17-10-386, but on your system, it's a directory
<elektranox> BenC: why? what's wrong?
<elektranox> I think I created it as dir
<elektranox> because it doesn't exist before
<BenC> that's because the linux-headers package creates it
<BenC> rmdir that directory
<BenC> then do: sudo ln -s /usr/src/linux-headers-2.6.17-10-386 /lib/modules/2.6.17-10-386/build
<BenC> that'll fix it
<elektranox> :) It works now
<zul> throwing up in the dark is fun
#ubuntu-kernel 2006-12-02
<ajmitch> so is hearing of it on irc
<zul> heh..
<kylem> BenC, ping
<BenC> kylem: yo
<kylem> heh, nm. figured it out.
<kylem> just trying to make that ndiswrapper message slightly more informative
<kylem> of course, figuring out what the possible return values of call_usermode_helper are is fun.
<BenC> 2.6.20-1.1 is going to be a huge changelog
<BenC> debian/rules printchanges | wc -l
<BenC> 280
<kylem> yow.
<kylem> could just crop the upstream git section, heh.
* kylem likes the changelog management in ubuntu-2.6.git though.
<fabbione> humpf
<fabbione> git pull
<fabbione> fatal: unexpected EOF
<fabbione> Fetch failure: git://git.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git
<fabbione> No changes.
<fabbione> BenC, kylem: do you know why am I getting this error?
<BenC> fabbione: Is this from an old edgy repo?
<BenC> fabbione: If so, you need to re-clone the ubuntu-2.6 tree
<fabbione> BenC: it's a clone i did 15 days ago.. but ok.. i will reclone. thx
<fabbione> gotta feed the fattosaurus rex now :)
<BenC> lol
<dade`> the linux-source-2.6.19 package which versione of .19 contains ?
<dade`> the "-0" one ?
<mjg59> BenC: pm_prepare_console() has reappeared in kernel/power/*
<mjg59> BenC: What happened to the patch that fixed that?
<BenC> mjg59: There's a config option for it now...I'd have to check for it
<mjg59> BenC: No, that's something different
<BenC> this is the code that disables pm from mucking with the console on suspend/resume, right?
<mjg59> Yes
<BenC> I was sure something was added in mainline kernel for this when I moved to 2.6.19
<mjg59> No, there are two chunks of code
<mjg59> One controls whether messages get sent to the console (which is now a config message)
<mjg59> And one controls whether the kernel does VT switching (which isn't)
<BenC> So I need to re-add my config option for the vt switching
<BenC> I'll try to get that pushed upstream during 2.6.20 too
<mjg59> It would probably be better if it was run-time switchable in some way
<BenC> I can do that too :)
<Mithrandir> that'd be wonderful.
<Mithrandir> I have graphical suspend and resume working, sans that small bug, which you can *cough* work around by sending a SAK.
<makx> nice
<Mithrandir> s/suspend/hibernate/, really.
<mjg59> Mithrandir: Did you make any changes to usplash?
<mjg59> If not, I'm not sure how you handled the password stuff
<Mithrandir> mjg59: I ignored it, but I think I can work around it by writing a shim in uswsusp
<Mithrandir> given that usplash supports input now
<Mithrandir> usplash needs a few more bits exposed in the API too, iirc.
<mjg59> I think it's trivial to do by just refactoring the input code in usplash
<mjg59> I wrote that earlier, I'll push it now
<Mithrandir> ok
<Mithrandir> do we have bzr imports of suspend-cvs?
<mjg59> Dunno
<mjg59> Gah. What's the bzr foo to recover a file I accidently deleted?
<mjg59> Ah, I can just cat it
<Mithrandir> bzr revert foo, I'd think
<mjg59> Ah, yes, that would also work
<mjg59> Mithrandir: Pull latest code, then usplash_get_string
<makx> hmm are there images for netboot.tar.gz?
<makx> s/images/mirrors #uups
<dade`> BenC: are you here ?
<dade`> wow if i change the preempt method the kernel recompiles everything
<BenC> yeah, things like preempt are pretty extensive
#ubuntu-kernel 2006-12-03
<zul> BenC, ping this patch doesnt apply because the function doesnt exist in breezy am i going crazy http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6d381634d213580d40d431e7664dfb45f641b884
<stgraber> Anyone around ?
<stgraber> I just have a small question about the high memory support in Edgy 2.6.17
<stgraber> I'm triaging a bug report that says that 4GB memory isn't detected correctly, is the high memory support for 4GB> enabled ? or only the >1GB one ?
<stgraber> (I'm not using the default Ubuntu kernel so I can't easily check the config file)
<stgraber> ok, someone else answered only the 4GB option is enabled and that's the reason of the bug I think
<stgraber> thank you anyway :)
<zorglu_> hi, i try to compile sysprof module for dapper, from sysprof-module-source.deb but it fails. the makefile try to find a /lib/modules/2.6.15-26-386/build which doesnt exists
<zorglu_> the only directories there are kernel/ and initrd/
<zorglu_> any suggestion on how to compile it ?
<zul> install the kernel-headers
<zorglu_> thanks
<zorglu_> ok it is compiled, loaded and all, but sysprof doesnt show anything and cat /proc/sysprof-trace returns EWOULDBLOCK all the time :)
<zorglu_> i dont ask you to fix the issue 
<zorglu_> i just want to know if you heard that some people already made it work ?
<zorglu_> ok i found somebody who made it work :)
<zorglu_> on edgy tho and i run dapper
<zorglu_> bye :)
<zul> bah...paravirt-ops hasnt been merged yet
#ubuntu-kernel 2007-11-26
<tarsin> hello, my apologies if this isn't appropriate for this channel.  i am trying to apply xenomai and adeos-ipipe patches to the ubuntu kernel. i downloaded the kernel source via: `apt-get source linux-source-2.6.22` when i go to apply the patch to the created directory it seems to fail in a couple of places. so instead i tried extracting the vanilla kernel that was provided from apt-get, then applied my patches. now i'd like to apply the ubuntu patches, 
<tarsin> i am curious if there is a better way to do what i want? or if there is a place i can find the collection of patches that make up linux-source-2.6.22_2.6.22-14.46.diff.gz, as it would be easier to exclude the just those patches that fail to apply
<lamont> tarsin: for working with the (gutsy, 2.6.22) kernel, the ideal starting point is 'git clone git://kernel.ubuntu.com/ubuntu/ubuntu-gutsy.git'
<lamont> and then apply your patch to a new branch vs upstream, and then merge the two branches
<lamont> of course, that's probably not all that clear if you're not already a git user...
<tarsin> no.. i'm not. it sounds like its not something i am gonig to be able to hack together tonight unless i spend the next 4 hours looking at it :)
<tarsin> im familar with version control systems.. but not git
<tomasko> hi
<IntuitiveNipple> But quieter in here for this
<IntuitiveNipple> I'm just looking at the Gutsy code now
<tomasko> oh, cool.
<tomasko> okay, so i cleaned my system of kvm stuff. i apt-get install kvm. it sets everything up and adds the kvm group
<tomasko> now i try modprobe kvm-amd (with lsmod | grep kvm showing nothing) and get: FATAL: Error inserting kvm_amd (/lib/modules/2.6.22-14-generic/kernel/drivers/kvm/kvm-amd.ko): Operation not supported
<IntuitiveNipple> then you do sudo modprobe kvm_amd ?
<tomasko> now lsmod | grep kvm shows: kvm                    64944  0
<tomasko> stock gutsy kernel, i didn't do anything funky with custom kernels, etc.
<IntuitiveNipple> Hmmm, that looks as if kvm-amd doesn't like the CPU
<tomasko> grep svm /proc/cpuinfo | wc -l shows 2
<tomasko> whatever, i uninstalled kvm. i don't want to reboot my computer for something that shouldn't need me rebooting
<tomasko> IntuitiveNipple: if you do figure it out, let me know. i'm off to bed. thanks.
<IntuitiveNipple> I'm checking the source now
<IntuitiveNipple> Was the precise error "Operation not supported" ?
<tomasko> Yes.
<tomasko> gah, i won't get any sleep at this rate :P
<IntuitiveNipple> hmmm, that is a generic error caused by internal issues
<tomasko> meaning...?
<IntuitiveNipple> It is not an error generated specifically by KVM
<tomasko> yeargh
<tomasko> is kvm really worth it? what will i get from that that i wouldn't get from qemu?
<IntuitiveNipple> The error is something like this: ?
<IntuitiveNipple> FATAL: Error inserting kvm_intel (/lib/modules/2.6.20-6-generic/kernel/drivers/kvm/kvm-intel.ko): Operation not supported
<tomasko> i already pasted the exact error
<IntuitiveNipple> It's fantastically faster... I use kvm all the time
<tomasko> even if i'm emulating linux on linux?
<tomasko> (fedora on ubuntu)
<IntuitiveNipple> If you want to do that, use User Mode Linux, but yes, it is faster because KVM doesn't emulate user instructions, it runs them on the native CPU
<tomasko> well, it's actually the olpc image on ubuntu
<tomasko> but since i'll be actually testing it out on my c2d laptop, there's no sense in trying on this desktop very hard
<IntuitiveNipple> I run with KVM, it works well
<tomasko> anyway, goodnight. if i care about this more, i'll help test out in winter break. right now i've got work to do :(
<IntuitiveNipple> I run XO with KVM, is what I meant to type!
<IntuitiveNipple> night
<tomasko> so gotta wake up early to get to it :(
<tomasko> oh, cool. that's good to know, but sad to know won't work on my laptop for sure (which doesn't have intel's vt extensions for sure)
<IntuitiveNipple> You can use user mode linux, that'll be fast
<IntuitiveNipple> One thing I can think to check... has the /dev/kvm device been created and what are its permissions
<IntuitiveNipple> I see:
<IntuitiveNipple> $ ls -l /dev/kvm
<IntuitiveNipple> crw-rw---- 1 root kvm 10, 232 2007-11-21 14:52 /dev/kvm
<asabil> hi all
<soren> Oh, BenC! Just the man I wanted to talk to. :)
<soren> BenC: When do you suppose the first hardy kernels will hit the archive?
<BenC> soren: Going to find out the status this morning
<soren> BenC: Oh, good.
<zdzichuBG> hi guys
<zdzichuBG> I wonder, if Hardy kernel builds are planned soon? I'd like to have SATA link and hda-intel power management features on my laptop.
<zul> zdzichuBG: soon..
<zdzichuBG> cool
<doko> hmm, how do I set the device class of a PCI card?
<kraut> moin
<zul> is there a kernel team meeting this week?
<zdzichuBG> http://guichaz.free.fr/misc/#iotop  is pretty useful, but requires " Linux >= 2.6.20 with I/O accounting support". Could this be enabled in ubuntu?
<zul> oi this is such pain..
<lifeless> bug 88889
<ubotu> Launchpad bug 88889 in ubuntu-iso-tests "20070301: edubuntu i386 desktop" [Undecided,Fix released] https://launchpad.net/bugs/88889
<lifeless> bah
<lifeless> bug 88899
<ubotu> Launchpad bug 88899 in linux-source-2.6.20 "cpufreq locked in slowest speed" [Undecided,Incomplete] https://launchpad.net/bugs/88899
<lifeless> BenC: ^ a user has done a really good analysis of this ancient bug; I think a few minutes from you to point them at the right code location would be effective 
#ubuntu-kernel 2007-11-27
<Kano> hi, are the hardy headers fixed to let other modules compile?
<mjg59> Given that we're still shipping the gutsy kernel, and given that the gutsy headers let other modules compile, I'm not sure what you're referring to
<Kano> well i tested the 2.6.24 kernel
<TheMuso> c
<TheMuso> ugh wront tab
<kraut> moin
<naelr> ok I have a very strange thing happening is anyone ready for a challenge
<naelr> guess not :p
<naelr> did I post that in this channel
<naelr> if I install fiesty on my laptop it will install and boot just fine.. if I apt-get upgrade and it get the next kernel revision it will not boot. end up in busy box.. also have same problem with gutsy
<naelr> what might be the difference between the kernels 
<pwnguin> does iwl3945 support wpa2?
<clever> naelr: you should still be able to pick an older kernel at grub to get arround the problem till a newer one is out
<clever> naelr: also if your getting into busybox then the kernel itself is working
#ubuntu-kernel 2007-11-28
<kraut> moin
<ivoks> hi
<thegodfather> hi ivoks 
<ivoks> is there any chance to include drbd module into ubuntu kernel?
<ivoks> thegodfather: hi :)
<thegodfather> ivoks: i did add a new patch to the bug.. any luck with that one?
<ivoks> thegodfather: i have to wait night to test that patch :)
<thegodfather> ivoks: ok cool. thanks
<thegodfather> ivoks: drbd isn't exactly stable and portable.. last time i checked at least
<ivoks> not stable?
<ivoks> hm... :)
<thegodfather> well it didn't use to be
<thegodfather> and didn't build on many arches
<thegodfather> ivoks: i think i might know why you were not able to reproduce the problem on vmware too
<thegodfather> there is a specific algo to select the source address of an outgoing connection
<ivoks> you do? i was thinking that it could be driver related stuff :/
<thegodfather> when the IP's are all in the same subnet
<thegodfather> it matters only the last octet
<thegodfather> let say:
<thegodfather> node1: x.y.z.101
<thegodfather> node2: x.y.z.102
<thegodfather> node3: x.y.z.103
<thegodfather> etc.
<thegodfather> and you slam the VIP's in the range from 1 to 100
<thegodfather> i don't remember if the lower is privileged
<thegodfather> or the higher is
<thegodfather> so perhaps you want to compare the real ip's on the running cluster
<thegodfather> with the vmware setup
<thegodfather> if you understand what I mean
<thegodfather> perhaps on the running cluster the VIPs are below or up the real IP's
<thegodfather> and in the vmware setup they are inverted
<ivoks> on these nodes i have two addess on every node
<ivoks> one is private and one is public
<ivoks> so, one range is 192.168.0.x, and the other is xx.xx.xx.x
<hytham__> hi every one ...can some one help me in this issue (after compinilng a new kernel i recievd the following error "run-init:nuking initramfs contents:directory not empty" and kernel panics ???
<ivoks> i tried with the same setup on vmware, but all ips were from the private range
<thegodfather> ivoks: right.. that can change a lot
<thegodfather> because of the selection algo
<ivoks> yeah, probably
<thegodfather> do you have a chance to test the exact copy on vmware?
<thegodfather> including real ips?
<ivoks> not really at the moment
<thegodfather> if so.. you might be able to reproduce the issue without a patched kernel
<thegodfather> ok
<ivoks> i'll test the patch on real systems tonight
<thegodfather> ok
<thegodfather> it was just to avoid you any more troubles
<thegodfather> with the production system
<thegodfather> ivoks: otherwise is there a way i can get the real config with real ip's?
<ivoks> well, system is still in alpha stage, so i can get along with it :D
<thegodfather> of course as NDA or something
<thegodfather> that way i can set it up here in my vmware environment
<thegodfather> ok
<thegodfather> that case.. it's all good :) 
<ivoks> it the patch doesn't work, i think we can't talk about providing real config
<ivoks> sorry... can
<ivoks> not can't :)
<thegodfather> ok
<thegodfather> take into account that the new patch sucks in all changes in lowcomms.c that have been done to fix issues up till today
<thegodfather> if this isn't working, we are probably experiencing another bug that we think
<thegodfather> so that will require much more debugging
<ivoks> well, i'll do everything i can to help you out
<thegodfather> i really appreciate
<thegodfather> thanks
<ivoks> it's in my intrest to make it work too 
<thegodfather> yeps..
<ivoks> thegodfather: cross your fingers :)
 * thegodfather crosses his fingers...
<ivoks> i hate rebooting system in testing kernel
<ivoks> specially when they are thousands of kilometers away :)
<ivoks> they're up!
<ivoks> and printk shows stuff gets executed
<ivoks> thegodfather: :* works for me :D
<thegodfather> ivoks: rock on
<thegodfather> ivoks: please report it in the bug report
<ivoks> i'm doing last test just to be sure...
<ivoks> will do, of course...
<ivoks> yes, it works... kudos to thegodfather :)
<thegodfather> perfect
<thegodfather> thanks for testing man
<ivoks> np
<ivoks> thegodfather: funny thing... bringing old kernel back results in oopsing :)
<thegodfather> well no idea.. sorry
<ivoks> dlm_lock crashes on one node, not both... well, never mind, if patched one works, that's all i need :)
#ubuntu-kernel 2007-11-29
<lamont> BenC: email me your ship-to addr, eh?
<lamont> it'll be christmas in december. :)
<BenC> lamont: addy?
 * BenC wants it to be a surprise :)
<BenC> lamont: does lamont@canonical.com still work?
<lamont> lamont@h.c would work
<BenC> ok
<lamont> and that one still works too
<lamont> DC logins --> working canonical.com addr
<lifeless> heh
<kraut> moin
<abogani>  
<abogani>  
<rexbron_> Hey everyone! I was wondering if there has been any decision on enabling the new firewire stack in the kernel?
<amitk> rexbron_: for Hardy?
<rexbron_> amitk: Yes
<rexbron_> IIRC, it was merged into mainline in .23
<amitk> rexbron_: Hmm... I see that CONFIG_FIREWIRE is disabled for some reason. 
<rtg> amitk: just an oversight.
<amitk> rtg: http://wiki.linux1394.org/JujuMigration before we decide to turn it on
<dholbach> heya - is somebody looking at bug 163122 and bug 163120?
<ubotu> Launchpad bug 163122 in ubuntu "add firmware-addon-dell to Ubuntu" [Undecided,In progress] https://launchpad.net/bugs/163122
<ubotu> Launchpad bug 163120 in ubuntu "add firmware-tools to Ubuntu" [Undecided,In progress] https://launchpad.net/bugs/163120
<rtg> amitk: juju bad.
<amitk> rtg, rexbron_: from their own recommendation, the stack isn't ready for primetime. 
<amitk> right
<rtg> dholbach: are just looking for reviewers?
<rtg> s/are/are you/
<dholbach> yeah... I did an initial review, but the packages might still need some love
<rtg> dholbach: ok
<dholbach> I thought you guys probably knew best what's expected from those packages
<zdzichu_> Fedora enables new firewire for two releases now
<rexbron_> I would suggest looking at how they solved any migration problems
<rexbron_> The reason I bring this up is that, under the current situation, users with firewire camcorders and sound cards must change permissions in 40-permissions.rules for raw1394. This creates a rather large security risk, the new stack provides granularity and control for those devices.
<amitk> zdzichu_: rexbron_: For the particular drivers that actually work better with the new stack, I guess enabling it would make sense. But it needs to be co-ordinated with udev and other userspace changes
<rexbron_> amitk: Would that be something that Ubuntu Studio could tackel ourselves, or would it be better to try and coridinate Ubuntu-wide?
<_MMA_> rexbron_: Ubuntu-wide
<amitk> rexbron_: Ubuntu-wide would be nicer. Could you file a bug in launchpad and add udev and kernel and dependencies for now
<rexbron_> bug or spec?
<steady> Hello
<steady> man
<steady> help
#ubuntu-kernel 2007-11-30
<Kano> hi, 2.6.24 seems to use pv_cpu_ops as gpl only, that breaks fglrx
<Kano> i guess paravirt
<Kano> also i need a fix for aufs
<Kano> best add it to lum
<Kano> sed -i 's/CONFIG_PARAVIRT=y/# CONFIG_PARAVIRT is not set/;s/CONFIG_PARAVIRT_GUEST=y/# CONFIG_PARAVIRT_GUEST is not set/' debian/config/i386/config debian/config/amd64/config
<Kano> thats needed when paravirt is not changed
<kraut> moin
<Kano> hi, hardy lum is still on -0, but it should be -1
<Kano> how about disabling paravirt(guest) to let 3d drivers compile?
<rtg> Kano: bug pkl. He's working on it right now.
<Kano> pkl?
<rtg> Philip Lougher
<Kano> nickname
<rtg> hmm, I guess he's not on this channel. hold on...
<amitk> Kano: is this a typical fglrx problem?
<Kano> a typical GPL only problem
<Kano> some functions are exported gpl only
<Kano> when paravirt is enabled
<amitk> paravirt is important for Ubuntu
<amitk> could you list the specific functions that are gpl only?
<Kano> then tell linus to remove gpl only ;)
<amitk> send an email to kernel-team@lists.canonical.com with you proposal so that everybody can track the problem
<Kano> FATAL: modpost: GPL-incompatible module fglrx.ko uses GPL-only symbol 'pv_cpu_ops'
<Kano> i am sure you can compile your own kernel...
<Kano> you dont need a ati card to compile the module
<amitk> and why does fglrx use operations from paravirts?
<Kano> because it is enabled
<Kano> a similar problem was with 2.6.21
<amitk> Kano: to me this looks like a problem with fglrx, not Ubuntu. IMHO, you should be talking to ATI.
<Kano> http://www.nvnews.net/vbulletin/showthread.php?t=102652
<Kano> not only fglrx, also nvidia
<Kano> all non gpl drivers
<amitk> have you tried filing bugs with these drivers?
<Kano> This problem can not be worked around in the NVIDIA Linux graphics driver.
<Kano> can you read this
<amitk> It says in that link that Nvidia will fix their driver in future releases
<amitk> just ask ATI to do the same
<Kano> http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg229455.html
<Kano> maybe it is already fixed,but not in your git tree
<amitk> Kano: rtg is syncing to the latest 2.6.24 tree 2-3 times a week. So we shouldn't be far behind.
<Kano> then he should try to compile one of those modules
<amitk> Kano: We will get to it when we compile LRM. Be patient.
<Kano> i dont use that package
<Kano> i am sure you can get to it faster
<amitk> But we do. And as much as you would like, we don't work to your schedules. Sorry.
<Kano> for me lrm is the biggest crap ever introduced
<Kano> kernel+lum are ok, but not lrm
<maks_> Kano: you are on a old base
<maks_> that paravirt problem got resolved since some time irc
<Kano> maks_: old base?
<Kano> i compiled it this night
<maks_> linux-2.6 ?
<maks_> irc that was a trouble of 2.6.22 or 2.6.21
<Kano> thats a new 2.6.24 regression!
<maks_> cool
<maks_> good news then Kano :)
<amitk> Kano: if it is fixed in 2.6.24, we will pick it up. If it isn't  then ATI will eventually fix their stuff just as Nvidia is. But disabling partvirt is NOT an option.
<Kano> amitk: until you want to use gpl drivers you can not enable it
<amitk> Then we will solve it when we get to that problem
<amitk> *shrug*
<Kano> you are really funny
<Kano> you dont own ati or nv gfx cards=
<maks_> radeonhd works pretty fine on ati
<maks_> well nouveau is kind of stalled..
<maks_> so don't buy nv
<Kano> you have ideas, unbeleaveable
<Kano> radeonhd has no xv support
<Kano> when will be aufs available? there is no aufs or unionfs in lum
<Kano> i would prefer aufs...
<circut> hey all, anyone in?
<circut> well i was just curios if the time information that the ubuntu kernel prints is a  special  kernel patch
<circut> or if its already in the kernel source, just needs to be turned out
<circut> there was something about printing timing info in the kernel hacking secrtion
<circut> but its more like time elapsed, not current time
<circut> hrm
#ubuntu-kernel 2007-12-01
<Kano> hi pkl_ 
<kraut> moin
<pina> why once i upgraded to 2.6 kernel, my mouse wheel (that scrolls) no longer works?
<pina> #59695.
<pina> #59695
<pina> https://launchpad.net/bug59695.html 
<pina> this was one of the bugs that started off my hd failure paranioa
#ubuntu-kernel 2007-12-02
<kraut> moin
<cathyal> hi
<cathyal> IntuitiveNipple: ping
<cathyal> who is awake
<cathyal> pretty quiet
<cathyal> must be the weekend buzz
<SamFisher47> anyone?
#ubuntu-kernel 2008-11-24
<ciberBOB> hey guys just need some link or recommendations for initiatives in the development of the Linux kernel and contribute something to the community
<ciberBOB> not is channel for disscusion for kernel developer ?
 * abogani waves
<abogani> smb_tp: Please remember to pull from my git tree to obtain PREEMPT_RT support update for Hardy.
<smb_tp> abogani, I will do. :) Thanks for the reminder
<abogani> smb_tp: Sorry to bother more and more. :-)
<smb_tp> abogani, Hey, no problem. You had the work with it.
<abogani> Are there some plan to change build system for kernel flavours (obviously generic/server excluded) ? Will it remain "out" (as did in Intrepid) or return to "in" (as did in hardy)?
<abogani> Perhaps BenC know it ^^^
<smb_tp> abogani, I frankly don't know at the moment. Ben might know. Or amitk, did you catch discussions about that ^^^
<amitk> smb_tp: abogani: change build system for what again
<amitk> ?
<smb_tp> amitk, If I understood correctly the question was about -rt flavour
<amitk> smb_tp: -rt flavour integrated into the Ubuntu kernel?
<smb_tp> amitk, Into the build. But I think the intention was there to have a separate tree like lpia and ports. But I am not remembering well
<apw> amitk, just was trying to edit the config lists in the a1 jaunty kernel and got the following error from armel
<apw> About to configure armel config.iop32x
<apw> make[1]: Entering directory `/home/apw/git2/ubuntu-jaunty'
<apw> /home/apw/git2/ubuntu-jaunty/Makefile:449: /home/apw/git2/ubuntu-jaunty/arch/armel/Makefile: No such file or directory
<apw> make[2]: *** No rule to make target `/home/apw/git2/ubuntu-jaunty/arch/armel/Makefile'.  Stop.
<apw> make[1]: *** [sub-make] Error 2
<apw> make[1]: Leaving directory `/home/apw/git2/ubuntu-jaunty'
<apw> make: *** [editconfigs] Error 2
<amitk> apw: this is with 'debian/rules updateconfigs'?
<apw> d/r editconfigs
<amitk> apw: hmm.. not sure if editconfigs can work on a different arch
<amitk> apw: I know why now...
<amitk> it should work... patch coming up
<apw> amitk, cool ... will give it a try
<apw> (when it appears)
<amitk> apw: pushed..
<apw> amitk, got it, seems to work just fine for me ... thanks
<amitk> np
<apw> better warn BenC that the jaunty tree has commits on top of it
<amitk> BenC: ^
<BenC> apw, amitk: Got it, thanks
<BenC> amitk: have you compiled the current tree on armel to make sure things are good?
<amitk> BenC: another trivial change to getabis pushed.
<amitk> BenC: I haven't. I can kickstart a build now.
<BenC> amitk: thanks, I want to upload today and I just need to make sure armel will build
<mkrufky> smb_tp: hello.  I have some additional sms1xxx changesets that I merged into a separate branch.  These changes depend on the ones pending from last week.  Would you prefer that I generate a pull request against the last changeset in my last request, or should I just generate a whole new one with all pending changes altogether?
<mkrufky> ...and yes, I have LP's created, etc... some of the LP's are private bugs for the Belmont project ....  the fixes can go both to Belmont and Hardy
<smb_tp> mkrufky, since I did not get to those yet, I would prefer one new one with everything together. 
<mkrufky> ok, i will send that right now
<mkrufky> thanks in advance :-)
<smb_tp> mkrufky, Ah, ok. Could you probably open dummy ones for the private bugs. I know it is a bit tedious but then the references to those can be publicly be followed
<BenC> A list of modules that I had to disable in jaunty kernel has been sent to kernel-team@ if any gets that forward porting feeling
<apw> smb_tp, just found and interesting work around for my dell studio 15 hang, which fits with your suspicion of cpu concurrency issues
<mkrufky> smb_tp: I can just make the bug public -- there isnt actually any private info in there ....  you should just ignore the pull request to mfrey INSIDE the bug report though
<BenC> If you're not sure what that feeling feels like, it's a cross between a burning and slight tingling in the area of your brain where common sense takes place
<apw> a script to disable all but one cpu for the suspend cycle sort it out
<rtg> apw: https://bugs.launchpad.net/bugs/300159
<smb_tp> mkrufky, Hm, I should be able to ignore that. rtg what do you think of that?
<apw> rtg that one looks 'fun' too, but i think the issue is actually: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/276943/
<mkrufky> i just say to ignore because my belmont pull requests are in separate branches against his git tree
<rtg> smb_tp: if there is nothing proprietary in the bug, then just make it public.
<mkrufky> i been using separate branches for belmont vs hardy mainstream, so that u guys can just pull / merge without any issue
<mkrufky> yeah i will do that
<rtg> apw: I just noticed that other folks have come up with the same work-wround.
<smb_tp> mkrufky, Ok, great. Maybe you could refresh my memory with a mail to kernel-team if you are ready. ;-)
<apw> its alll a bit frightening, stupid userland s/w accessing h/w, ouch
<mkrufky> smb_tp: yes, will send that mail in a few minutes
<smb_tp> mkrufky, Cool, thanks. :)
<rtg> off-lining is actually a normal part of suspend, but its also almost the last thing that happens before calling ACPI to suspend.
<apw> yeah the key seems to be not-onlining them again for 10s
<apw> so that X has woken up and posted the h/w before they arrive
<apw> if this suggested bodge patch is right it may be that we are loading irq handlers and not waiting for all cpu's to get with the program before dri interrupts start raining in ... its possible an rcu grace period wait in the dri driver would fix it
<rtg> apw: sounds like it could be lieb's VT race.
<apw> i thought the bug there was that the switch didn't occur correctly, in that overlapping vt switches could get lost
<apw> this is definatly some kind of parallel hardware init problem
<rtg> apw: I think it can manifest itself in a variety of ways. I assume you can reach your laptop over the network when its gets wedged on resume?
<apw> nope, when it wedges its _hard_ gone
<rtg> apw: well, then that isn't the VT lock.
<apw> by suspending from a text console, i can resume correctly to there, and wait long enough for wireless to come back up
<apw> then login from my 'tv' system, but when i switch to X she dies, and the cpu is pegged
<apw> the network connection then times out
<BenC> apw: even after waiting some time after resume?
<apw> yeah ... its the switch back to X which takes the machine out
<apw> and this workaround seems to demonstrate its lack of smp locking somewhere
<BenC> apw: what xorg driver?
<apw> the bug may well be in X dri drivers, or the real kernel dri drivers, its not clear
<apw> intel xorg driver, i915 dri module
<apw> other people are reporting it in other dri modules, so its likely a systemic failure across the family
<mkrufky> email sent, smb_tp
<smb_tp> mkrufky, ok. got it and put on todo list
<mkrufky> thanks
<apw> rtg this linux backports module (intrepid) seems to crap out if the directory above the build is dirty?  is that reasonable?
<rtg> apw: no, its not reasonable, but it happens. it doesn't match correctly if there are old .deb files from a [previous version.
<apw> at least i am not going mad
<rtg> I've fixed many of the packages.
<rtg> apw: since I'm working on Intrepid LBM today, I'll get that fixed.
<apw> sounds good, thanks
<apw> its the imagelist=$(cat .... bit which seems to die
<rtg> thats the one.
<rtg> rm -f ../*.deb and it should be OK.
<apw> yeah will do that for now, to confirm my lbm patch actually builds
<rtg> apw: I'm about to do a complete update from upstream.
<apw> of the wireless yes?
<rtg> for wireless, are you adding some new driver?
<apw> yeah we talked about it last week, its a backport of some nic driver
<rtg> apw: I had a vague memory of that (which should be OK)
<apw> as its put in there now it would be independant of your changes
<rtg> r8169, right?
<apw> just trying to confirm i did it right by building it which is challenging at best
<apw> yeah thats the one
<amitk> rtg: I think the intrepid kernel has the same problem, IIRC
<amitk> rtg: imagelist one, I mean
<rtg> not too surprising.
<rtg> it goes back as far as dapper
<apw> its taken me sometime to work out what i needed in my chroots to get it building, and then a while to build them
<BenC> apw: in buildscripts git there is a shell script that will create schroot compatible tarballs for chroots, complete with all the build requirements for the kernel
<BenC> apw: if you want to just complete your current chroot's, there's a listing of the extra packages needed in there as well
<apw> nice
<apw> thanks BenC 
<BenC> np
 * BenC needs more coffee
<apw> the markets are up 9.2% ... hmmm
<amitk> apw: for how long?
<amitk> BenC: I got a build failure on ARM. will investigate now. Should I pull in cjwatson's patches as well?
<BenC> amitk: I already pulled them and pushed
<amitk> BenC: ok. I'll rebase and fix configs.
 * amitk is going to setup cross-compilation now. Qemu builds are painful
<BenC> amitk: does qemu take advantage of multicore?
<amitk> BenC: it does have a -smp option. I have it set to 3. It improves things a bit.
<apw> amitk, heh they are closed, so at least until tommorrow morning
<apw> amitk, are we going to have some kind of cross-compile porter?
<amitk> apw: I'll post instructions to setup a cross-compile toolchain. And then we can ask IS to do it on a fast porter machine. Ideally I would like Ubuntu to provide a cross-compiler package so that it is automatic.
<apw> that sound perfect
<BenC> amitk: best bet is to talk to doko...debian used to (may still?) have a cross-compile toolchain package, so it might not be too hard to do
<kirkland> smb_tp: ping, regarding https://bugs.edge.launchpad.net/ubuntu/+source/iscsitarget/+bug/278625
<kirkland> smb_tp: i merged a new iscsitarget package for jaunty, but this problem remains
<kirkland> smb_tp: it seems that the kernel module code contained in the source of the new package fixes the "can't unload modules" problem
<kirkland> smb_tp: is this module code something that can be merged into the kernel modules code?  what's the rules/policy/process for doing so?  can you help?
<smb_tp> kirkland, yeah there was some proc (or sysfs) change
<kirkland> smb_tp: cool, you're on top of it?
<smb_tp> kirkland, I am not that familliar with why it isn't in the kernel. There was a guy involved who is the maintainer of the package. Maybe he is more up to it
<kirkland> smb_tp: so what is in the kernel, iscsitarget wise?
<kirkland> smb_tp: seems we ship an iscsci_trgt.ko
<kirkland> smb_tp: is that from upstream?
<kirkland> smb_tp: do they publish some additional code that's not upstream yet?  (i don't get it)
<smb_tp> kirkland, In Intrepid its in the kernel because lum went in there
<smb_tp> kirkland, I think the kernel itself has nothing of it
<kirkland> smb_tp: so lum includes module code that's not in the kernel.org kernel?
<smb_tp> kirkland, yes
<kirkland> smb_tp: cool, and what's the process for getting that code update?
<kirkland> smb_tp: ie, could we import the "working" iscsi_tgrt code from this package?
<smb_tp> kirkland, For Intrepid that is basically what I did.
<smb_tp> kirkland, There is a BOM file with the location of the original download
<smb_tp> kirkland, IIRC iscsitarget.sf.net
<kirkland> smb_tp: cool, so will you be doing the same for Jaunty, at some point?
<smb_tp> kirkland, since there is a bit stacking on my queue and my memory isn't sometime lacking it would be good to add a pointer via kernel-team mailing list ;-)
<kirkland> smb_tp: okay, cool.  what's that address, please?
<rtg> kirkland: we'll have to for Jaunty since iscsitarget FTBS
<kirkland> rtg: thanks
<smb_tp> rtg, Are you on it
<smb_tp> ?
<kirkland> rtg: right now, package upgrades of iscsitarget will fail too, because it can't unload the modules on the initscript "stop"
<rtg> yeah - we'll get there eventually.
<smb_tp> kirkland, Oh just for general "reminders" kernel-team at lists.ubuntu.com :)
<s0ullight> hi guys
<BenC> just about to boot the jaunty kernel...
<BenC> WARNING: I'm getting ready to do a force push
<smb_tp> BenC, Did you pull the uvcvideo patch?
<BenC> smb_tp: yeah, just did a pull to make sure I have everything
<smb_tp> BenC, Cool. pfew :)
<s0u[]ight> what kernel is this new release using atm?
<NCommander> hey BenC 
<rtg> sconklin: did you get that? My nick isn't registered, so I never know if private chats work
<BenC> NCommander: yo
<NCommander> BenC, how goes 2.6.28?
<sconklin> rtg: yeah, I got it
<calc> BenC: i think you found a perpetual energy machine in your stove :-\
<rtg> smb_tp: speaking of iscsitarget, did you build test the Intrepid commit? http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commit;h=8c09ecb39475e13bc86dc6df3c7fa787abc34aae
<NCommander> calc, BenC's cooking can't be that bad
<smb_tp> rtg, At least I always wanted it. I am not sure anymore... 
<rtg> huh?
<smb_tp> rtg, I might suffer from too many nested interrupts. I thought I had test build it might be just an intention that got dropped
<rtg> smb_tp: well, reverting it allows the compile to continue. I'll figure it out later this afternoon.
<smb_tp> rtg, Hm, found some debs with a matching git with iscsitarget on ronne. 
<smb_tp> rtg, but that was 9.18...
<rtg> smb_tp:  probably some header that changed.
<smb_tp> rtg, maybe. if you don't get to it maybe send me an email with the build log
<rtg> smb_tp: don't sweat it. I'll get it figured out after lunch.
<smb_tp> rtg, no worries. :) enjoy.
<rtg> sconklin: you can work around that build failure by reverting the last commit to ubuntu/iscsitarget
<smb_tp> rtg, I am off after one more mail
<sconklin> rtg: ok, thanks. 
<lamont> how do I get kvm to _NOT_ stop doing stuff when I iconify the window?
<lamont> because I'd like to set the machine to doing a task and then not have the window occupying realestate until I want to go look at it....
<amitk> cross compiling is sooo much more bearable...
<amitk> rtg: I've fixed armel configs and all four flavours compile now. Pushed fixes to jaunty. Could you inform BenC when he gets back?
<rtg> amitk: sure, I'll even do some test building.
<amitk> rtg: thanks. Good night...
#ubuntu-kernel 2008-11-25
<CarlFK> amitk: are you the kernelopps expert?
<CarlFK> http://dpaste.com/93532/  dmesg shows 3 stackdumps 
<amitk> CarlFK: IIRC, you are running kerneloops on a server with no GUI?
<apw> smb_tp, so we have a bug about extending p4-clockmod to include a newer celeron
<apw> although it doesn't generally seem to be expected to be that useful, there are good stats reported
<apw> in the bug for power savings and the like, how do we feel about slurping up something like that
<apw> i get the feeling p4-clockmod is not loaded automatically even if you have such a cpu
<smb_tp> apw, IFAIK no, you have to add it manually. About the savings I know there are different opinions. Normally throttling is rather seen as temperature control as the overall energy savings are not positive
<smb_tp> apw, On the other hand, i the cpu does nothing it can do it half speed without taking longer, I guess
<apw> yeah i saw those arguments, but some of the users seem to report very good savings on overall power from an idle system, whcih could make some sense
<apw> yeah it depends some on how the idling is performed
<apw> if the module is an opt-in thing anyhow it doesn't seem like a bad thing to include support for additional cpus to my mind
<smb_tp> apw, I think if that change is small, we could add it as a SAUCE patch as hw enablement
<apw> its a single line, to add a new processor id to p4-clockmod,
<apw> i am wondering why its not upstream as yet, not managed to find any discussion  on that side
<smb_tp> apw, I have the feeling sometimes, that this is somewhat abandoned due to the savings arguments
<apw> yeah, and yet we have the module at all ... so it clearly does something for someone
<apw> even if it is only for heat, then we should have it for heat (we == linux kernel community more than ubuntu)
<smb_tp> apw, It makes some sense I think. Maybe mjg59 knows a bit more about whether there is some upstream maintenance to that.
<apw> yeah ... have just found the kerneltrap thread on it, so will go read that and see what the outcome was
<apw> this thread is pretty compelling as to why you really don't want it, how it makes things worse only
<smb_tp> apw, What is the reasoning there?
<apw> that the normal state of things is that when the system is idle it enters C2 state, which consumes the same amount of power as being in a skipped cycle due to throttling
<apw> so on average the the overall consumption would be the same
<apw> assuming you don't need more than half the cycles
<apw> which is normal
<apw> if you do need all the cycles, then you are actually worse off, as you run as half+idle cost for 2x the time and that can lead you to consume more power not less
<apw> i think the right thing to do is write a clear and concise summary of this thread and post it in the bug and see what happens
<smb_tp> apw, The strange thing then is only that it seems to have a measurable effect. Do you know whether C states are implemented on centrinos?
<apw> that is an interesting question, this thread inplies so, but perhaps there is a bug elsewhere that prevents their use or something
<gregd> hi guys, just was having some problems with my intel wireless card (was dropping constantly connection). Many people seemed to have similar problems. Found that the newest kernel 2.6.28-rc6 has a fix for it (look for "iwlagn: fix RX skb alignment
<gregd> " in http://kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.28-rc6). I'm really looking forward for the fix to be incorporated into ubuntu-kernel. But in the meantime, should I compile the 2.6.28-rc6 kernel by myself?
<amitk> gregd: a 2.6.28-rc6 kernel should be available for jaunty this week. If you can wait, then you could simply install that kernel.
<gregd> this week seems to more than enough, that would be perfect :)
<amitk> gregd: then just check back here around Thursday. We are shooting for an upload today.
<gregd> great! ok will be back later this week! Thanks guys!
<tjaalton> does hardy have a package to clean up old kernel versions, keeping the current and latest kernel alone?
<amitk> tjaalton: moi! Not that I know of. There was an attempt to get it in Intrepid. But it was removed at the last minute due to some bugs.
<tjaalton> amitk: ah ok, thanks
<tjaalton> I'm using pkgsync anyway, so adding old versions to the maynothave-list works quite well :)
<CarlFK> amitk: it's u-desktop, but kerneloops wasn't installed.  just installed it.
<amitk> CarlFK: is the kerneloops-applet running?
<CarlFK> i just didi sudo apt-get install kerneloops - I don't see anything on the bar - it would be over by the clock, right?
<amitk> CarlFK: no. It doesn't show up in the tray.
<amitk> CarlFK: "ps aux | grep kerneloops"
<CarlFK> yup: /usr/sbin/kerneloops
<amitk> CarlFK: run kerneloops-applet from cmdline
<CarlFK> in case it isn't clear: I just now installed it, after the crash (thought it was installed - you asking made me check...)
<CarlFK> running
<CarlFK> got dialog
<CarlFK> 'always'
<CarlFK> is that it?
<amitk> yup
<CarlFK> neat 
<CarlFK> brb
<amitk> CarlFK: i think when you logout/reboot your computer, the applet should be automatically started.
<apw> rtg if we were considering pulling a newish driver back into intrepid, which was not already there would it go into the main tree or lbm ?
<rtg> apw: it could go main tree 'cause there is little chance of regression. what driver?
<apw> i felt it might, this is a panasonic laptop keys support driver
<rtg> just be sure to evaluate the regression potential.
<apw> no idea yet if its is a trivial backport or not, and yep that needs looking into
<amitk> BenC: rtg: why can't skipabi=true really skip an abi check? The third check in scripts/abi-check is really not necessary in case of a new arch or a quick compile test.
<rtg> amitk: I never use it, so it's never really annoyed me.
<rtg> amitk: besides, for a subsystem quick compile test I use a completely different method.
<amitk> rtg: you never have to do test builds when ABI is not yet updated?
<rtg> rarely.
<BenC> amitk: touch and empty file
<rtg> Try something like this: 'make -C debian/build/build-generic M=`pwd`/drivers/net/wireless'
<amitk> rtg: it isn't a subsystem compile check, I want to compile the whole shebang but not bother about abi.
<BenC> amitk: basically you will need to just create empty ABI files for each flavour...the check fails because we never want to upload without the previous abi files
<amitk> BenC: dpkg-buildpackage doesn't like empty files
<BenC> amitk: then create one fake symbol entry :)
<BenC> amitk: in your case an out-of-tree build usually works well for a compile test
<amitk> BenC: out-of-tree would be ok for compile test. But if I wanted to check for packaging issues, I would need to use a binary-<flavour> target
<BenC> amitk: abi files with one fake symbol is what you will need
<BenC> amitk: either that or just grab the abi files from the initial build(s) as stub's
<BenC> I just nailed down the final changes for the headers packages (the move from include/asm-* to arch/*/include/asm needed to be handled)
<BenC> fglrx dkms build fine with the new header packages, so I think I'm done and ready for an upload
<BenC> amitk: let me know when you have everything in place for armel
<amitk> BenC: armel is all set since last night.
<BenC> amitk: including the abi files?
<amitk> BenC: yes. I already used the stub from a local build as the inital abi
<BenC> I see they exist, so cool
<amitk> BenC: who needs to be informed about EXTRAVERSION change? Have you checked the change?
<BenC> amitk: let me commit the stuff I have and then I'll pull
<BenC> amitk: best bet is ubuntu-devel@
<amitk> BenC: build will fail. http://paste.ubuntu.com/76801/ Need to change some hardcoded paths for new EXTRAVERSION
<BenC> amitk: instead of changing just extraversion, how about we add -ub- to the entire thing, even package name?
<BenC> amitk: linux-meta will take care of upgrades (where we'll keep it flavour package names with no -ub-)
<amitk> BenC: but would that reflect in /proc/version?
<BenC> amitk: well the flavour name gets added to extraversion
<BenC> right now it's $(abi)-$(flavour)...we just need to change it to $(abi)-ub-$(flavour)
<BenC> amitk: I have to prep the audio patches for smagoun...if you could get this -ub- thing squared away, it will help make sure we still get an upload today
<amitk> BenC: ohh right. I think that is a better proposal.
<evand> Looking over bug 92014, I started to wonder if it's feasible to add some hint in /sys/block to discern between SCSI and SATA devices.  Does anyone know if this is possible and whether upstream would accept it?
<amitk> BenC: -ub added to EXTRAVERSION and package names. Compile tested on amd64.
<amitk> BenC: can you take over from here?
 * amitk calls it a day...
#ubuntu-kernel 2008-11-26
<apw> if i am looking at a bug which is current filed against xserver-xorg-whatever, and i also think it may be kernel related, how do i go about adding the kernel task to the top
<apw> is that 'also affects distribution' ?
<smb_tp> apw, yes
<Ng> is the upstream kernel fix for bug 207473 suitable for intrepid-updates? :)
 * apw looks
<smb_tp> apw, hm, wasn't that the patchset you posted on the kernel mailing list?
<apw> yeah i think so, though for another bug ...
 * apw checks
<apw> bah the link to the patch is returning 'kernel.org is sick' messages right now, so i can't be 100% sure
<apw> but ... Ng could you perhaps test the kernels listed in bug #257827, which seem to fix a similar double shift of brigtness and report back against that bug for me
<apw> kernels are here: http://people.ubuntu.com/~apw/lp257827/
<apw> we are looking for testing for those, to justify an SRU
<Ng> apw: I was asking on behalf of someone else, but I'll certainly ask him to test
<apw> thanks
<apw> i have also noted the similarity and request for testing in this new bug
<BenC> Anyone have anything last minute for jaunty kernel?
 * BenC is prepping an upload right now
<Kano> hi, could somebody fix the packageing of jaunty git? the new "ub" addon breaks the kernel-headers, target binary-headers
<BenC> Kano: already working on it
<Kano> btw. whats the correct way to fill in the changelog?
<laga> git commits AFAIK
<Kano> well there is only a placeholder
<Kano> how to fill it with content?
<BenC> Tells you on the wiki
<BenC> but it's debian/rules insertchanges
<Kano> thanks
<_ruben> hmm .. what's the deal with the -virtual flavour having its files in -server? did those 2 flavours merge or smth?
<_ruben> in intrepid that is
<amitk> _ruben: -virtual is derived from -server
<amitk> BenC: did the -ub changes look sane?
<BenC> amitk: yeah, just fixed up linux-headers-x-x-x thought, and all seems good
<_ruben> amitk: ah, so now its just a subset (module-wise) of -server? this a change between hardy and intrepid?
<BenC> _ruben: yes
<_ruben> ic, so -virtual would only give a smaller footprint (disk and possibly memory/security wise) .. wonder if i should just standardize my machines on -server for both physical and virtual machines
<BenC> _ruben: right, -virtual is meant to be -server with a smaller disk footprint (mainly for virtual appliances)
<BenC> _ruben: which for -virtual appliances may even result in a smaller memory footprint on the host side (if the disk is loaded entirely in memory for example)
<BenC> 2.6.28-1.1 is in mid-upload
 * amitk pictures BenC pushing through the last straggling driver bits to the upload server.
<_ruben> BenC: does the same apply to hardy, since on hardy the files are in a -virtual dir, only cosmetic or does that kernel actually differ from the -server one
<BenC> _ruben: it differs
<BenC> _ruben: on hardy, -virtual is compiled from a separate config, on intrepid, -virtual is just built from the -server package
<BenC> _ruben: unless 100Megs of disk really makes that much of a difference to you, I wouldn't even bother with -virtual
<rtg> BenC: you sure what you have checked in for Jaunty is gonna build? I have a bunch of missing modules.
<BenC> rtg: I added a modules.ignore...maybe it doesn't cover the x86 list
<BenC> I only did the x86-64 build
<rtg> well, this is 32 bit
<BenC> rtg: What's the missing ones not accounted for?
<rtg> there were 23 missing
<BenC> rtg: right, but I assume some of them said "(ignored)" next to it
<rtg> ok, there are 22 listed in modules.ignore, so likely its one other in the 32 bit build.
<BenC> rtg: at the top of the module-check output it should list each one, and likely one doesn't have "(ignored)" next to it...do you have that handy?
<rtg> BenC: I'll re-run it. Using screen it had scrolled off the top (and screen's scroll back sucks)
<BenC> ok
<rtg> BenC: looks like snd-cs4231-lib and snd-ad1848-lib. I'll add and verify
<BenC> I canceled the upload, so I'll revert head and repackage the source
<BenC> s/revert/reset/
<rtg> BenC: ok, gimme a minute and I'll push the commit
<BenC> I'll add it to mine, so I can reset the tag and everything
<BenC> if those are the right modules
<rtg> BenC: they seem to be.
<BenC> rtg: Thanks
<rtg> BenC: you should do a full 32 bit test build. kernel-wedge is bitching about missing modules as well, 'missing module dm-raid4-5'
<BenC> damint
<BenC> rtg: ok, a quick grep shows that to be the only one
<rtg> BenC: I didn't dig any further. I'm totally annoyed that iwl4965 can't seem to work with an 802.11n AP.
<BenC> rtg: in jaunty?
<rtg> Intrepid LBM
<rtg> I should force a Jaunty install to see what happens there
<BenC> fixed up d-i and rebuild...I'll start a full 32-bit build now
<BenC> rtg: current jaunty build should work now
<apw> amitk, about?
<apw> rtg isn't 11n some kind of separate compile option?  or is it not yet working?
<rtg> apw: in Intrepif LBM you have to set HT (or something similar). Its short for High Throughput. I wonder what they'll call UWB? Really High Throughput?
<apw> SooperDooperHT
<rtg> perhaps UHT
<rtg> BenC: 32 bit build looks like its gonna complete. its into the packaging phase.
<amitk> apw: yeah?
<BenC> rtg: how do you prep alsa for lum/lbm?
 * BenC forgets the whole process
<rtg> BenC: I'm not sure what you're talking about? Its part of the kernel since Hardy.
<BenC> rtg: I need to update hardy-lum's alsa for lpia (separate tree from standard hardy)
<rtg> BenC: uh, lemme refresh my memory. I think it was a serious pain in the ass.
<BenC> that feeling came to mind when I started this...
<BenC> I can't remember how to get the alsa-driver/alsa-kernel tree's output
<BenC> actually, I see it
<rtg> BenC: I think all you have to do is unpack the ALSA tarball. debian/rules.d/2-binary-arch.mk actually runs the configure phase.
<apw> rtg, there is a bug on our list to fix up the wireless EU thingy ... i am assuming we are basically expecting the release notes to fix people on intrepid, and for jaunty that this is a UDS topic ... 
<rtg> apw: you mean channel 13?
<rtg> or is it 14? I forget
<mkrufky> whats the correct way to signify that a bug filed in launchpad against "linux-ubuntu-modules-2.6.24 (Ubuntu)" also affects the intrepid kernel?
<mkrufky> it looks like im supposed to file as "also affects LINUX" ... but how to signify specifically the intrepid kernel?
<smb_tp> mkrufky, add also affects and then do a nomination for intrepid
<mkrufky> hmm, ok will try this
<apw> rtg, yeah the fact you need to tell the kernel you are on you are in the EU ...
<apw> i am looking to 'resolve' the bug, as 'won't fix' in intrepid as we have a work around, and something that means UDS will fix it
<rtg> apw: what do you know about the new firewire stack?
<apw> heh not a whole heap other than we seem to have both in the kernel
<apw> we have a bug on asking for the new one iirc
<rtg> well, we don't have the new one enabled.
<apw> yeah thats what i meant, that we have he src in the tree, but only the old on
<apw> the bug i think asks for us to enable both and blacklist the new
<rtg> apw: didn't pgraner have a session scheduled to talk about config options? I was gonna make sure it got into the list of notes for that session
<apw> hmmm, yes i think so
<CarlFK> apw: where/what about a firewire bug?  (I have been trying to figure out why cam corders randomly disconnect)
<mkrufky> smb_tp: that worked, but now it has both hardy and intrepid listed under both linux and the LUM package...  how do i make the "linux (ubuntu)" nominate for intrepid, and "linux-ubuntu-modules-2.6.24" only for hardy?   to see what im talkiong about, this is bug #299671
<rtg> mkrufky: https://bugs.launchpad.net/bugs/276463
<smb_tp> mkrufky, open the unwanted one and mark it invalid
<mkrufky> ok
<apw> CarlFK, this was a bug only about asking for both to be enabled
<mkrufky> ...maybe it wont allow me to mark the nominations as invalid while bug status is "new" ?
<mkrufky> ok, well these are bugs that are fixed, and i have pending pull requests to hardy to fix them.....  i am about to push the same fixes into an intrepid branch and issue a similar pull request ...  should i mark them as "in progress" ?
<mkrufky> i apologize for the newbie'isms to bug tracking :-P
<smb_tp> mkrufky, could just be some user restrictions. since ubuntuid is absent, could you paste me the link?
<mkrufky> https://bugs.launchpad.net/belmont/+bug/299671
<mkrufky> yeah its in belmont, but i made the bug public, and it applies to hardy and intrepid as well as belmont
<smb_tp> rtg, actually the nominations have to be approved first... ^^^ 
<mkrufky> ah...  well i have a few other bugs that i need to do this to (add also affects intrepid) ...  should i do the same thing i did here to the remaining bugs?
<smb_tp> mkrufky, which I also am not allowed to do
<mkrufky> understood
<smb_tp> mkrufky, yep would be some process
<mkrufky> so, it is better for me to do this to the remaining bugs, or just leave them as-is without showing "also affects intrepid" ?
<CarlFK> if Juju (new firewire) can be included in jaunty, I can do a bunch of testing next week.  Here is what I have so far: http://spreadsheets.google.com/ccc?key=pIfz0wOzPtW1E6KpNZ_9oUQ&hl=en#
<rtg> smb_tp: done
<mkrufky> oh!  thanks, rtg
<smb_tp> mkrufky, maybe best will be note the facts in a comment and we'll have to sort it out
<BenC> CarlFK: is this a third firewire?
<CarlFK> BenC: um.. I dont think so
<rtg> BenC: Juju is the v2 stuff
<mkrufky> smb_tp:  ok... my intention was to send my "intrepid" pull request in a few minutes ... the commits reference the bug numbers, so i hope thats good enough ... i'll just add comments to the other bugs in text form stating "...also affects the intrepid kernel"
<CarlFK> "new FireWire kernel driver stack (alias Juju)" http://ieee1394.wiki.kernel.org/index.php/Juju_Migration
<rtg> CarlFK: doesn't Juju require a newer library?
<BenC> CarlFK, rtg: Ah, I thought maybe someone rewrote my entire stack...again :)
<smb_tp> mkrufky, Yes, in that case it should be enough to say once in the mail this also affect intrepid and possibly jaunty or whatever
<mkrufky> will jaunty star at 2.6.28?  or is there a chance that might go to 2.6.29?   (i assume its too early to say for sure)
<mkrufky>          ^ staY
<BenC> mkrufky: too early to say
<rtg> mkrufky: your assumption is correct
<BenC> we'll probably do like we did with intrepid and have an ubuntu-next once .28 is released, and go from there
<mkrufky> im hoping to get these patches into 2.6.28 via the -stable kernel series ....  but they will go into 2.6.29 naturally ....   so i will hold off on jaunty updates until it gets closer to release
<CarlFK> rtg: no clue.  just saw the mention of it here.  I have been trying to nail down a dvgrab problem, and so have a bit of a test framwork setup right now.  so testing it will be 'easy' and might solve my problem too
<rtg> CarlFK: looks like libraw1394 v2.0 handles either kernel stack.
<CarlFK> I could probably find the source, build, swap out, test... but would rather that happen outside of my petri dish 
<mkrufky> smb_tp: ...and one more final (small) headache for you .....   in preparing the intrepid patches i noticed three more tiny patches that need to be applied to hardy.  since that tree still hasnt been pulled yet, i'll just ass those 3 patches and send a new request.  On the bright side, I'm going on vacation after today, so no more patches from me for at least a week :-P
<smb_tp> mkrufky, Well I am sorry to say that, but it has been. So those three will have to wait for next upload
<CarlFK> BenC: so you know about the current firewire stack? :)
<BenC> CarlFK: you mean drivers/firewire/ ?
<mkrufky> smb_tp: oh, no problem then.... . thats actually better news .....  
<mkrufky> smb_tp: its three trivial fixes that can wait until the next time i have a functional change ....  only one was important -- a typo in the license headers   (the code says GPLv3 but its actually GPLv2)
<mkrufky> minor issue can wait
<CarlFK> BenC: whatever it is I am using, which is causing random problems, mostly: ieee1394: Node suspended: ID:BUS[0-00:1023]
 * BenC lubes up his internet connection hoping this upload will go faster
<smb_tp> mkrufky, oh good, good. :) I quite happy the package is bundled now. So stack for next time is better for me
<BenC> CarlFK: Ah, that's the standard drivers/ieee1394/ stack, which I do know a bit about
<rtg> BenC: oh yeah - both Jaunty versions built. I'm running the 64bit one on my xps1330
<BenC> rtg: sweet...64-bit booted on this XT with no problems, except for fglrx crashing in xorg
<BenC> rtg: still uploading...
<rtg> oddly enough, 802.11n works with i4965
<BenC> rtg: and the alsa update was easy, just copied alsa-kernel, and then the rest of the source to alsa-driver and make a symlink to alsa-kernel there
<rtg> I remember having a  lot of practive with that one once upon a time
<CarlFK> BenC: 2 or 3 times a month starting in March I have been using dvgrab to record a few hours of user group presentations.  seems like every time I had some sort of problem.  last week I became active on the kino/dvgrab list and started testing.
<CarlFK> I too am leaving for vacation - will be back tuesday.  
<CarlFK> so the tit for tat is: if the v2 stuff is easy for me to test next week, Ill spend a fair amount of time testing it. 
<alex_joni> anyone good with GPL license interpretation around?
<BenC> 2.6.28-1.1 upload done finally
<fransman> BenC: May i thank you !
<fransman> I was again a lot of work
<BenC> fransman: you may
<fransman> Is it gonna get in the cue for PowerPC and Sparc as well
<BenC> fransman: that will be linux-ports...this just coverts x86, x86_64 and armel
<fransman> year , and what version will linux-ports be?
<TheMuso> Linux-ports is following upstream releases, so since 2.6.28 is not officially released, it won't go 2.6.28 just yet.
<TheMuso> At least I think thats what nCommander is doing.
<TheMuso> BenC: Is lpia still going to be a separate kernel tree this cycle?
<BenC> TheMuso: talk to amitk
<TheMuso> BenC: Oh ok, was just curious.
<BenC> Sorry, I don't have a good answer
<BenC> he would know though
<TheMuso> Right.
<fransman> TheMuso:  upstream releases means the released Debian ones?
<TheMuso> fransman: No, upstrea as in kernel.org.
<TheMuso> upstream even.
<fransman> ok that clear
<BenC> fransman: our kernel is not based on debian's
<fransman> i know it's your own git
<fransman> does anyone know when the .28 rc are going into releasing ?
<TheMuso> Whenever its ready I guess.
<fransman> ok that's not so clear
<BenC> fransman: it never is clear for upstream to set a hard date on a release
<CarlFK> BenC: I asked Dean Dennedy (dvgrab author) "should I test Juju" he says "Yes, absolutely! Just make sure you have at least libraw1394 v2.0.0."
<CarlFK> is there anything I can do to help get it into jaunty?
<gregd> hello, is there a repository to use jaunty kernel in intrepid ?
<asac> whats the best way to do a custom (hardy) kernel with just a patch on top ... i want to upload that to a PPA
<fransman> gregd: Are you looking for http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git ?
<gregd> fransman: exactly
<gregd> but now, is there a ready repository to use to get the compiled version of the kernel?
<gregd> or do I have to compile it by myself?
<fransman> gregd: If it's build, it will be ready for install
<gregd> fransman: so is ubuntu-jaunty kernel build?
<fransman> gregd: please check https://launchpad.net/ubuntu/+builds in the next day's !
<gregd> fransman: ok, understand that the kernel is being build, however then, once it is built, where can I find some information on how to install it in my intrepid?
<fransman> gregd: please ask of the guy's here around
<gregd> ok I will have to do it in the next day than, thanks a lot!
#ubuntu-kernel 2008-11-27
<Kano> that new 2.6.28 looks more stable for me than 2.6.27, anybody else tested it?
<laga> "looks"?
<Kano> well at least my system with via+ati did not look up yet, lets see if it stays
<Kano> with 2.6.27 i got curious locks
<Kano> btw. kanotix users test that kernel too, i just removed the -ub marker
<Kano> CPU[AMD Athlon 64 X2 Dual Core 3800+ clocked at 2000.000 Mhz]  Kernel[Linux 2.6.28-1-generic i686]  Up[-54min-]  Mem[-233.7/2015.5MB-]  HDD[-800GB(92%used)-]  Procs[-139-]  Client[Konversation 1.0.1]
<Kano> btw. there is a firmware missing for a new dvb-t device, definitely working with 2.6.28
<Kano> wget -NO dvb-usb-af9015.fw http://jusst.de/manu/fw/AFA/dvb-usb-af9015.fw_a-link
<Kano> this one
<Kano> needed for example for: Bus 004 Device 013: ID 15a4:9016
<laga> Kano: what's the license?
<Kano> no idea
<Kano> but you have lots of dvb firmware already
<Kano32> hi, could somebody use nfs with 2.6.28?
#ubuntu-kernel 2008-11-28
 * abogani waves...
<abogani> Someone know what is timeframe for 2.6.27-10.20? I would want rebase -rt on -generic kernel but i don know if do job against 2.6.27-9.19 or is better wait 2.6.27-10.20...
<smb_tp> abogani, Hm, actually I thought 10.20 is already there...
<smb_tp> abogani, Ah, -proposed
<abogani> smb_tp: You are right but i meant in -updates
<smb_tp> abogani, Normally this should happen soon, given no bigger problems arise...
<abogani> smb_tp: Ok. Thank you.
<gregd> hi guys, I asked already some time ago about using kernel 2.6.28 in my intrepid ubuntu. And I got an answer I should wait for the build to be finished.
<gregd> So I presume, it is finished. What's the easiest way of getting the newer kernel for my ubuntu?
<gregd> hello. How can I make my ubuntu (intrepid) download (and install) the build of kernel 2.6.28?
<amitk> gregd: i386 or amd64?
<gregd> amitk: i386
<amitk> gregd: download this deb and use dpkg -i <deb> to install: http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-image-2.6.28-1-ub-generic_2.6.28-1.1_i386.deb
<gregd> amitk: and than just to edit my bootloader to add this new kernel?
<amitk> gregd: installing the deb should take care of it. But you may cross-check /boot/grub/menu.lst
<amitk> all this will ofcourse become automatic in the coming weeks
<gregd> amitk: perfect! Thanks a lot. I'm gonna try this kernel out today!
<amitk> gregd: please do report problems in launchpad :)
<gregd> I will if I find something!
<Kano> hi
<Kano> did anybody successfully use nfs with 2.6.28?
<apw> Kano, not heard anything negative about NFS for it, you got problems with that kernel?
<Kano> yes, it does not work at all
<Kano> did you use it?
<apw> unable to mount things?  panics all over the place?
<apw> not something i've had to use as yet no
<Kano> the nfs-kernel-server does not work
<apw> is there a lp bug open yet?
<apw> what does it say when it starts?
<Kano> i dont think that kernel is in the repository
<apw> this on intrepid?
<Kano> nope, i do not use intrepid
<apw> we are just switching jaunty to a 2.6.28 based kernel, so if there is an NFS userspace interaction it may occur there too
<apw> what base are you using?
<Kano> i tested it on lenny + etch (with latest backports of portmap+nfs-kernel-server)
<Kano> i compile the kernels from git with small config changes like static vesafb
<Kano> or enabled ath5k
<apw> hmmm ... well i guess the first thing to check is for required version of the nfs userspace tools for the .28 kernel, that should be documented in Documentation/* somewhere
<Kano> well newer as the latest one is somehow stupid ;)
<Kano> another thing, i found yesterday a missing firmware, today the next (both are for 2.6.27 too)
<Kano> http://hpmerkel.com/hpblog/images/dvb-usb-digivox-02.fw.tgz
<Kano> this one is for dvb-t too
<Kano> extracted of course...
<gregd> guys, I've just installed linux-image-2.6.28-1-ub-generic_2.6.28-1.1_i386.deb. Is it enough to migrate to this kernel, or should I install some modules as well?
<gregd> actually it works well
<apw> if you don't have any binary drivers that should be enough
<fransman> gregd: The kernel modules are in the package 
#ubuntu-kernel 2008-11-29
<_ruben> bah .. the link between -server and -virtual on intripid causes mayhem when using module-assistent .. using it on a -virtual kernel, creates packages depending on -server kernel
#ubuntu-kernel 2008-11-30
<NCommander> So now that atheros's kernel HAL is open, can we move that driver from restricted to ubuntu/ on the mianline?
#ubuntu-kernel 2009-11-23
<EruditeHermit> hello, if I build a kernel and then later I change the code for one module in the tree
<EruditeHermit> is it possible to create ubuntu package of the kernel without recompiling the whole tree?
<EruditeHermit> also, whenever I build my own kernel and use the ubuntu packaging method, it always errors out when I try to install the resulting deb package
<FireCrotch> Hello, everyone!  I'm interested in helping with solving a bug (#271706), which requires that a quirk be added to the kernel for this piece of hardware.  I think I know how to solve it, from looking at the relevant source here: http://lxr.linux.no/#linux+v2.6.31/drivers/input/keyboard/atkbd.c
<FireCrotch> The problem is... I have no idea how to apply the change I would make to the Ubuntu kernel source, or anything like that
<FireCrotch> I'm completely new to working with the kernel, but this is a bug that I am very interested in resolving, considering that it affects me.
<FireCrotch> Obviously, my ultimate goal is to have the patch applied to the mainline kernel, since the problem does affect users of other distributions
<jk-> FireCrotch: http://wiki.ubuntu.com/KernelTeam is a good start for reference
<jk-> actually, make that the kernel team knowledge base: https://wiki.ubuntu.com/KernelTeam/KnowledgeBase
<jk-> and https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
<jk-> basically, you can just make the change as required before you do the 'make-kpkg ...'
<FireCrotch> jk-: Thank you very much for you helpfulness.  I will work on my patch, and when I have it completed, I will likely be back, since I am sure I'll have at least some questions
<ghostcube> ok this one is getting a bit stupid
<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> anyone can handle to check this
<ghostcube> its still not working and i need to work with online konferencing in kubuntu
<ghostcube> it just works works not works works not
<ghostcube> and this startet in karmic
<ghostcube> if you cant handle i will change back to jaunty
<EruditeHermit> hey, can anyone help me with installing custom built kernels?
<EruditeHermit> the process always errors out
<_ruben> EruditeHermit: what's the error you get, and which method did you use to build the kernel?
<EruditeHermit> I get error 128
<EruditeHermit> and I used the instructions from this web page
<EruditeHermit> https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
<_ruben> pastebin the complete output of sudo dpkg -i... command 
<EruditeHermit> ok
<EruditeHermit> what the heck
<EruditeHermit> it just worked for the first time ever
<EruditeHermit> i don't know what to say
<_ruben> gotta "love" it when that happens
<EruditeHermit> it just started working
<EruditeHermit> i'll build my next kernel and it won't work again
<EruditeHermit> watch
<EruditeHermit> =p
<EruditeHermit> i'll come back tomorrow if it fails
<EruditeHermit> thanks anyway
<_ruben> ;)
<EruditeHermit> wth I didn't change anything!
<EruditeHermit> =p
<adnc> hello, i've a strange problem with my usb sound for which i use snd-usb-audio. it gets disconnected and reconnected all the time. i could not find any solution till now, has anyone any suggestions for any documentations that could be helpfull debugging this?
<amitk> hmm. My friend switched to a pae kernel, but still doesn't see 4Gb. Any pointers? (dmesg: http://pastebin.ubuntu.com/326113/)
<amitk> apw: ^
 * apw looks
<apw> amitk, that e820 doesn't have memory above 4GB so i'd say start with the BIOS settings
<apw> not all chipsets can lay the memory out to get 4GB even if they let you put it in
<apw> note the last entry in the e820 ends as 100000000 ... ie at 4GB
<apw> looking at my machine which has 4GB in it you see memory about that
<apw> the e820 seems to expose just 3GB of ram, so the kernel can only use that
<ghostcube> some mobos cant remap the things about 3 gig
<ghostcube> like some gigabyte boards
<apw> ghostcube, yep, and thinkpads have that repulation too
<ghostcube> yep
<apw> amitk, this is a thinkpad yes: LENOVO TP-7B
<apw> what sort is it?
<mjg59> apw: That's an X60, so 945. Which has 4GB of physical address space.
<apw> so ... unable to actually take 4GB ever then dispite taking the SIMs ... thanks mjg59 
<amitk> apw: x60s, sorry got distracted
<apw> amitk, classic case of 'supported' meaning "will boot with", rather than "you'll bet benefit from"
<mjg59> The X60s specs claim a maximum of 2GB
<apw> heh ... well at least they don't lie :)
<amitk> well, he does see 3Gb
<apw> yep, you are getting lucky there, with only 4GB of physical bits he won't ever see more than 3.5
<apw> and that would depend on the bios mappings
<amitk> right
<amitk> apw: so the BIOS-e820 lines should support more than 0000000100000000 to do 4Gb?
 * amitk knows little about e820
<apw> the e820 tells you where the memory is mapped physically
<apw> so to see more than 4GB usable you need some of it mapped above 4GB physical
<apw> as we use space in the 3-4gb range for IO and the likel
<amitk> apw: so this limitation will stay even if he upgraded to 64-bit, right?
<apw> taking my laptop as an example:
<apw> [    0.000000]  BIOS-e820: 00000000bd9ff000 - 00000000bda00000 (usable)
<apw> [    0.000000]  BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
<apw> i have a bunch of my ram above 4GB
<apw> amitk, i believe there is only 4GB of physical space on that chipset, so it can't place 4GB of ram and a bunch of IO space together
<apw> in the 4GB of space it has
<apw> you may be able to tease more like 3.5GB out of it ... some bios let you set how big the iospace is and whehter ram can appear around it or not
<amitk> ok, understanding now. I guess the e820 map resides somewhere in the BIOS?
<apw> the bios generates it and passes it over yes
<apw> later chipsets generally map 0-3gb of ram to 0-3 physical, and 3-> to 4->
<apw> leaving a nice window for IO
<amitk> Thanks apw, mjg59 
<amitk> apw: nice explanation of the HW limitations: http://lkml.org/lkml/2007/4/16/144
<amitk> in the .pdf, that is
<apw> yep ... pci express really hurts space wise
<tseliot> apw: here I am
<apw> yo
<apw> tseliot, there is a bug fix for the bcmwl source, which is needed for lucid
<apw> and i hear you are 'maintainer' for it
<tseliot> yes, I was volunteered :-P
 * apw struggles to find the bug #
<apw> whats the source package even called?
<tseliot> bcmwl
<apw> thats not easy to find out ... 
<tseliot> not an easy one to pronouce either ;)
<apw> heheh ...
<apw> arrrgggg where is this bug
<apw> i _HATE_ launchpad
<Appiah> :)
<tseliot> hehe
<apw> tseliot, heh seem you applied it which is why i can't find it :)
<apw> the one from n-commander
<tseliot> apw: right but I forgot to update my bzr branch because launchpad was temporarily down and I ran out of brain memory 
<apw> now it all makes sense
<apw> brain memory is useless
<tseliot> heh
<tseliot> I wish I could upgrade it...
<tseliot> ok, branch updated
<MTecknology> I just did git fetch; git checkout Ubuntu-2.6.31-15.50
<MTecknology> I got this -> warning: refname 'Ubuntu-2.6.31-15.50' is ambiguous.
<MTecknology> Any ideas what I did wrong, or is that just something I didn't notice happening any other time?
<apw> MTecknology, that might imply you have a branch of the same name as the tag?
<MTecknology> apw: isn't that the way to update to the new tag?
<apw> update what to the new tag?
<MTecknology> the git repository
<MTecknology> I'm used to bzr so git kind of confuses me, it's like a massive scary beast
<apw> MTecknology, its pretty much the same 
<apw> but a tag is a tag, and a checkout of that takes you off branch to a floating head
<MTecknology> I do git fetch and it tells me this ->    18fec74..ddbc670  master     -> origin/master   and    * [new tag]         Ubuntu-2.6.31-15.50 -> Ubuntu-2.6.31-15.50
<apw> yep
<MTecknology> I want my head to be Ubuntu-2.6.31-15.50 (the newest)
<MTecknology> so git branch Ubuntu-2.6.31-15.50
<MTecknology> so git checkout Ubuntu-2.6.31-15.50 *
<apw> the git branch command makes a new branch called that pointing to the current head pointer
<apw> now you have two mentions
<apw> and the error message
<apw> to make a new branch pointing to something
<apw> git checkout -b <branch name> <what> 
<apw> does the job
<apw> git checkout -b buildme Ubuntu-2.6.31-15.50
<apw> sort fo thing
<MTecknology> I keep wondering how much I may have screwed up my branch :P
<apw> which branch?
<apw> first git keeps a log of what you did and where it was before, git log -g, shows you a time based history of your current branch
<MTecknology> the ubuntu kernel
<apw> you can't do much harm to it really
<apw> if you just want the current version in a branch you can just checkout the branch and reset it to the new tag
<apw> git checkout buildme
<apw> git reset --hard Ubuntu-xxxx
<apw> NOTE: that this does destroy any local changes
<MTecknology> HEAD is now at fccba66 UBUNTU: Ubuntu-2.6.31-15.50
<MTecknology> I kept a copy of .config separate
<MTecknology> and the rest of changes aren't a big deal to me
<MTecknology> thanks :)
<apw> then you are at the exact equivalent to the tag
<MTecknology> for the future, what's the correct way to get myself here?
<MTecknology> branch or checkout?
<apw> you have local patches on your 'buildme' branch
<apw> and we send you a new base version
<apw> (i am assuming)
<apw> then i would 'git fetch; git rebase Ubuntu-new-tag'
<MTecknology> I haven't been patching anything yet - still jsut playing
<apw> which lifts up your local changes and puts them back on top
<MTecknology> cool :)
<MTecknology> When I do try to start fixing kernel bugs, I might really like how git works
<apw> its a problem if you are a bzr user as its similar enough to be confusing
<apw> though its basically functionally the same as bzr
<MTecknology> It seems like git pulls down everything out there when I do git fetch; but it keeps a single head which is what rebase changes(?)
<apw> it has the concept of local and remote branches
<apw> git branch -r shows you what it is pulling down
<apw> also tags come down which point to places
<apw> but the tags and remote branches represent 'our' things, and your local branches one or more represent 'your' things
<MTecknology> I think I get it
<apw> you can have more than one branch associated with the 'working directory' and switch between them
<MTecknology> I have to run away now :( - end of class
<apw> similar to repository mode in bzr if you have met that
<apw> but its on by default
<MTecknology> I haven't met it yet, but I'm nearing that point
<MTecknology> I'm about to start working on a massive project using bzr so I'll meet it in about 1 month
<MTecknology> thanks again :)
<WeatherGod> greetings from the bug squad...
<WeatherGod> I have a quick question about where to file a particular bug issue
<WeatherGod> I have a report of a nvidia video card that won't turn on its fan while using Karmic, but the fan does work using Windows
<WeatherGod> is this a kernel issue or something else?
<stlsaint> hello all
<WeatherGod> they don't seem to be a chatty bunch...
<stlsaint> yea im starting to notice
<stlsaint> was reading up on wiki page
<stlsaint> lo jMyles 
<jMyles> Hey stlsaint.
<MTecknology> WeatherGod: what's up?
<WeatherGod> hi
<WeatherGod> I was wondering where I should file a particular bug report
<MTecknology> then ask ;)
<MTecknology> apw: why do you hate LP?
<WeatherGod> this reporter has a fan that isn't working when he is in Ubuntu, but does work when he is in Windows
<WeatherGod> note, that this is a GPU fan
<MTecknology> where's the bug report?
<WeatherGod> bug 484875
<ubot3> Malone bug 484875 in nvidia-graphics-drivers-180 "Nvidia GPU overheating on Toshiba P100" [Undecided,Incomplete] https://launchpad.net/bugs/484875
<WeatherGod> I initially moved it to the nvidia drivers package, but the people in the #ubuntu-x room told me that the nvidia driver doesn't control the fan
<WeatherGod> personally, I don't know if that is true... because the changelog for the new nvidia driver mentions fan speed control
<MTecknology> I think that telling him to file a separate bug was a bad idea
<MTecknology> gah... I'll brb
<MTecknology> I need to take a quiz
<WeatherGod> ok
<MTecknology> If it's the same issue, then two different systems but both nvidia geforce can help narrow down the issue
<WeatherGod> note, that this is the only bug report by the OR
<WeatherGod> so, I should leave it with the nvidia package?
<MTecknology> I don't think there's enough information for that
<MTecknology> It can definitely be confirmed though
<WeatherGod> ok, but are you saying that it should be moved to another package?
<MTecknology> I don't know
<WeatherGod> what additional information is needed
<MTecknology> #ubuntu-bugs can help you better
<WeatherGod> I am from there
<WeatherGod> they aren't sure what controls the fan of the gpu
<MTecknology> I'm not the person to ask - maybe somebody else can peak in and answer
<WeatherGod> sorry if I seem a bit... terse... I am just getting bounced around here
<WeatherGod> ok
<MTecknology> -bugs is supposed to handle assigning bugs to packages
<MTecknology> somebody here might know; most people here only worry about the kernel though
<WeatherGod> yeah... I know... I am on the bug squad
<WeatherGod> we know that regular fans for CPU and such are filed against the kernel, but for the GPU, we don't know if the graphics driver controls that or the kernel
<WeatherGod> and it doesn't seem like anyone at #ubuntu-x knows, either
<mjg59> If you're using KMS, it's the kernel. If not, it's the X driver.
<WeatherGod> KMS?
<mjg59> Kernel Modesetting
<mjg59> If you're using the nvidia binary driver, give up
<WeatherGod> heh
<WeatherGod> it is
<WeatherGod> even the brand new one
<mjg59> Well, you get to file a bug against something that only nvidia has the source code to
<WeatherGod> is there even such a way to do that?
<WeatherGod> in the meantime, I have asked him to try out the free/open nvidia drivers
<WeatherGod> we will see if it works
<WeatherGod> also, given that he is using Karmic, is it safe to assume that he is using modesetting?
<mjg59> If he's using nvidia on Ubuntu, he's not using kms
<WeatherGod> ok
<WeatherGod> so, to summarize -- this is strictly a problem with nvidia?
<mjg59> If you're using the binary nvidia driver, the only software that controls the graphics hardware is the binary nvidia driver
<WeatherGod> mjg59, thank you for clarifying my questions
<WeatherGod> I appreciate your help
#ubuntu-kernel 2009-11-24
<Appiah> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/407824 , did you fix get reverted again? :)
<ubot3> Malone bug 407824 in linux "BOTH Network controller: Intel Corporation Wireless WiFi Link 5100 AND Ethernet controller: Marvell Technology Group Ltd. 88E8040T PCI-E Fast Ethernet Controller (rev 12) FAIL TO LOAD!" [Medium,Fix committed] 
<Appiah> your*
<akheron> I followed the instructions on https://wiki.ubuntu.com/KernelTeam/GitKernelBuild and ended up with a 310MB kernel image deb
<akheron> is this normal?
<akheron> I built v2.6.30 and used .config from the ubuntu mainline build of 2.6.30
<smb> akheron, The effect sounds rather like using a config which has debugging enabled. But if you took the git sources (or apt-get source) and used debuild there would be no need to get the configs from the mainline builds
<akheron> I cloned sources from git.kernel.org, git checkout v2.6.30, cp /boot/config-2.6.30-020630-generic, make oldconfig, make-kpkg <args>
<smb> akheron, Our configs normally have the debugging enabled but the build system strips the code before packaging
<smb> *sigh*
<akheron> ah, ok
<akheron> I'm debugging a problem where my system doesn't boot
<smb> I wish the make-kpkg would get eradicated from peoples memory
<akheron> this appears somewhere between 2.6.30 and 2.6.31
<smb> (we should do that from the wiki)
<akheron> so I'd like to bisect the kernel between these versions
<akheron> how to do it properly? :)
<smb> If you have the git sources (which contains the configs in debian/configs) a simple "fakeroot debian/rules binary-generic" would do the generic kernel package
<akheron> does the ubuntu kernel repo follow linus' tree so that I can bisect?
<akheron> and another question: can I build the kernel without cleaning it first? The build takes like an hour and I expect that I'll need to build tens of images
<smb> akheron, Before releasing its a rebase tree, so bisecting gets painful. Its following Linus tree, but maybe a starting point would be to try some of the mainline builds to narrow the thing
<akheron> from what repo are the mainline kernels built?
<smb> Those are Linus tree sources at -rc points
<smb> with the ubuntu config
<akheron> yes, but where do I get debian/configs?
<akheron> for them
<smb> the mainline builds are prebuild debs, so for them you would need no configs seperately
<amitk> smb: +1 about make-kpkg. We should have a bot that tells people that make-kpkg isn't supported
<amitk> I am helping another guy on #ubuntu-mobile with the same problem
<smb> For your own builds you might be able to speed up/shortcut by removing the debian/stamps/build (would need to check the correct name) file
<smb> and then call the build again
<akheron> smb: I've tried mainline builds alread
<smb> or use the ccache package which helps to speed up rebuilds
<akheron> ah ccache is a good idea
<akheron> mainline 2.6.30 works, mainline 2.6.31 doesn't
<akheron> so I'd like to build something in between
<smb> Hm, there should be 2.6.31-rc? ones as well, right?
<akheron> yes
<akheron> .31-rc1 doesn't work
<akheron> .30.9 does work
<smb> so 2.6.31-rc2 is before 2.6.31
<akheron> yes
<akheron> but as -rc1 doesn't work I expect that -rc2 doesn't work either :)
<smb> Correct :)
<akheron> so there are no more mainline builds left to narrow it down
<smb> So you would need to check "only" whats in the first rc
<smb> And the stable kernels seem to be ok too
<akheron> ??
<smb> Right
<akheron> .30 works, .31 and .32-rc* don't
<akheron> so there's a breakage somewhere between .30 and .31-rc1 which haven't been fixed
<smb> Wait 2.6.32-rc?
<akheron> I tested mainline 2.6.32 builds, too, to see if it's already fixed upstream
<smb> ah ok
<akheron> with "somewhere between" I mean that there's (hopefully) one commit in linus' tree before which my system boots and after which it doesn't :)
<smb> Ok, yep. So now you really are down to bisect the changes between .30 and 31-rc1
<akheron> yes
<akheron> and building a kernel with ubuntu configs is my problem
<smb> right, so I would suggest to take a upstream tree, then copy into that the debian/* and ubuntu/* dirs from the 2.6.31 ubuntu repo and try to bisect that
<akheron> altough ubuntu configs may not be needed
<akheron> ok, I'll try that
<akheron> thanks
<smb> If that gives problems, come back and we try to figure out what goes wrong
<^arky^> Hi ogasawara  can please look at bug 464442 , it caused screen reader users and voice chat users lot of pain 
<ubot3> Malone bug 464442 in alsa-driver "alsa-util.c: snd_pcm_delay() returned a value that is exceptionally large: -4496252 bytes (-25488 ms)." [Undecided,New] https://launchpad.net/bugs/464442
<tgpraveen1> is the kernel version for lucid decided? if so what is it?
<mpt_> greetings
* apw changed the topic of #ubuntu-kernel to: "Home: https://wiki.ubuntu.com/KernelTeam/ || Lucid Kernel Version: 2.6.32 || Ubuntu Kernel Team Meeting - Next Meeting after UDS - 17:00 UTC"
<apw> mpt_, hiya
<apw> tgpraveen1, i've updated the topic
<tgpraveen1> apw: thanks
<mpt_> I'm trying to specify the details of a power menu that will include all chargeable items that the kernel knows about
* apw changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/KernelTeam/ || Lucid Kernel Version: 2.6.32 || Ubuntu Kernel Team Meeting - Next Meeting after UDS - 17:00 UTC
<mpt_> https://wiki.ubuntu.com/SystemIndicators?action=AttachFile&do=get&target=power-menu.jpg
<mpt_> So what I'd like to know is: When a notebook has multiple battery slots, what kind of identifier does the kernel have for those slots?
<mpt_> What does the ID look like?
<apw> i thought that they were like BAT0 BAT1
<mpt_> ah, I see
<mpt_> e.g. in http://lkml.indiana.edu/hypermail/linux/kernel/0401.0/1155.html
<apw> seems they also have serial numbers where available
<apw> apw@dm$ cat /sys/class/power_supply/BAT0/serial_number
<apw> 20993
<mpt_> Shame it doesn't say something like "front slot" and "back slot" :-) -- then it might be easier for people wanting to know which one to replace
<mpt_> but I guess even the kernel doesn't know that
<apw> no you seem to even be able to work out its Li-ion etc
<apw> but not where it is
<mpt_> battery type: JUNGLE BEAST
<mpt_> ok, thanks apw
<apw> mpt_, i'll try and not guess what the machine is called if it has a jungle beast battery
<apw> i note that the mains connector is also mentioned in /sys/class/power_supply ... nice
<amitk> apw: the power_supply class has existed since .31 I believe
<amitk> but battery hotplugging doesn't yet work. damn.
<apw> amitk, interesting thanks ... it looks like a more sensible way of naming things
<apw> though what ADP1 means ...
<amitk> I just tried to plugin by second battery to see if there is any way to differentiate the two, so anwer mpt_'s question
<apw> you presumably get BAT0 and BAT1 and thats it?
<amitk> when I _boot_ with both batteries plugged in, yes.
<amitk> but I usually unplug the second one when at home, and hotplugging doesnt work
<apw> oh poop thats useless
<akheron> smb: the build system seems to install modules in /debian/linux-image-2.6.31-16-07a8c6-generic/lib/modules/2.6.31-16-generic/
<akheron> err, debian/linux-image-2.6.31-16-07a8c6-generic/lib/modules/2.6.31-16-generic/
<akheron> altough they should go to debian/linux-image-2.6.31-16-07a8c6-generic/lib/modules/2.6.31-16-07a8c6-generic/
<akheron> my ../.karmic-env has:
<akheron> LOCAL_ENV_CC="ccache gcc"
<akheron> AUTOBUILD=1
<akheron> CONCURRENCY_LEVEL=3
<akheron> hmm, actually this might be because AUTOBUILD was not 1 from the beginning...
<akheron> https://help.ubuntu.com/community/Kernel/Compile is outdated as AUTOBUILD et al are not accepted from command line
<smb> akheron, For the wrong location, there is one option that causes that. Let me check, I always forget the name. The rest of the doc, yes actually the whole thing should be looked over I guess
<smb> akheron, Hm, it usually is caused by having LOCALVERSION_AUTO being set, but that should not be with the ubuntu configs...
<smb> Lemme try to do what I suggested locally and see what happens
<akheron> I guess it's because I set AUTOBUILD=1 on the command line, let it build, and saw some checks fail
<akheron> then found out that AUTOBUILD=1 has to go to ../.karmic-env and just run debian/rules build-generic again
<smb> akheron, there should be no need to set anything for your need
<akheron> oh?
<smb> concurrency normally is #cpus and ccache might be used by having /usr/lib/ccache in the path
<akheron> at least it fails because of missing modules without AUTOBUILD=1
<smb> hm, strange. give me a few mins to see what happens
<akheron> you must have quite a farm of distcc hosts to compile it in "a few mins" :)
<akheron>       read 2664 modules : new(0)  missing(115)
<smb> akheron, Oh so you need skipabi, not autobuild
<akheron> skipabi=true ?
<smb> or was that skipmodules...? too many things
<akheron> :)
<akheron> skipmodule
<smb> probably both "skipabi=true skipmodule=true" before the binary-generic
<smb> so "fakeroot debian/rules skipabi=true skipmodule=true binary-generic"
<akheron> AUTOBUILD=1 sets those and additionally skipdbg=true and abi_suffix=<something
<akheron> >
<akheron> ah
<akheron> dpkg-gencontrol: error: package linux-image-2.6.31-16-07a8c6-generic not in control info
<akheron> a bad property of abi_suffix :F
<smb> akheron, Doh, right so thats where the suffix comes from
 * smb wonders who used AUTOBUILD last
<smb> akheron, Sounds like you will need to do a clean at least once to get the control files right "fakeroot debian/rules clean" not the "make clean"
<akheron> I did that
<smb> akheron, Have you gotten rid of the AUTOBUILD=1 in the env file?
<smb> That will cause the strange suffix to be attached to the version number and the build to fail
<akheron> yes
<akheron> err, no I haven't
<akheron> but yes, I agree that I probably should delete it
<akheron> the only problem is that then all the debs I create have the same name
<akheron> the suffix is derived from git commit id and this is a good thing
<smb> akheron, for the test you can edit the first line in debian.master/changelog and append something like +bisect123
<smb> but that would be manually
<akheron> that's true
<akheron> It doesn't matter
<akheron> I'll try that
<smb> Just to be sure, the same would need to go to debian/changelog (that would normally updated with each clean). So if you do cleans between builds that is not needed
<akheron> is there a way to do it without cleans between builds?
<smb> akheron, With somewhat more pain. Like said you need to update both changelogs in step and then remove the stamp file
<smb> debian/stamps/stamp-build-generic for the generic build
<akheron> ok
<akheron> and then hope that all the kernel isn't built from scratch
<smb> Right, but that depends on how much changes are between the steps. If an important include file was changed you still might end up doing a lot
<akheron> yes
<akheron> I'll see that after I manage to complete the first build
<mozmck> smb: you said earlier you wish make-kpkg would get eradicated from peoples memory, but as far as I can see, if someone does not get the source from your git there is no other way to build kernel packages.  Or is there another package I'm missing that would give us the ubuntu build system?
<smb> mozmck, The ubuntu build system for the kernel is just a chroot of the series (which is described in some related wiki docs) and then either clone the git repo and check out a version tag or do an "apt-get source linux-image-xxx-generic"
<akheron> mozmck: I'm currently building from linus' kernel tree with the ubuntu build system
<mozmck> so an apt-get source will get it?  I tried that the other day but something was wrong with my setup or something.  Thanks for the info
<akheron> I only use the build system from ubuntu tree
<amitk> mozmck: you could also use the source packages for the mainline builds
<amitk> mozmck: that will give your the ubuntu build system and kernel configuration w/o any of the ubuntu patches to linus' tree
<mozmck> I got the linux-source package from the repository and built from that using make-kpkg
<smb> amitk, I would be a bit careful about that. I have seen the kernel-source packages sometimes a bit useless as the miss the configs and some stuff. It could be apw fixed that for the mainline builds but I am not sure
 * amitk sobs about make-kpkg
<mozmck> I don't think the souce from the repository had the debian directory at all.
<amitk> smb: that is just a bug that needs to be fixed if there is enough demand for it. And apw has fixed it AFAIK
<smb> The problem with make-kpkg is that nobody from us uses it and if it works its rather coincidental than expected
<BenC> make-kpkg is a horrid bit of overkill
<amitk> that is the only way we can tell people to compile a mainline tree w/o using untested tools
<amitk> hiya BenC 
<BenC> hey amir
<BenC> *amit
<mozmck> The kernel I built works fine on some computers but won't boot on one that has intel 82845G graphics.
<smb> BenC, Hi2
<amitk> I think debian talked about retiring make-kpkg at plumbers
<BenC> hey smb
<mozmck> weird thing is that it booted fine from the livecd I made with that same kernel, but after installing it won't boot.
<BenC> isn't there a "make deb" in the kernel tree?
<amitk> BenC: it was broken and someone on the debian kernel team pledged to fix it IIRC
<smb> Have never tried that. And even if, the is too often confusion with the kernel-source package (which is not very usefull imo) and the sources you get with git or apt-get source 
<mozmck> I used the source and config from 2.6.31-15.50-generic and added an RTAI patch and changed a few config settings.  The generic kernel will boot if I tell it "nomodesetting"
<mozmck> I'll try building again with the ubuntu build.  Most of the docs I see say to use make-kpkg and to use the kernel-source packages.
<rtg> mozmck, have you read https://wiki.ubuntu.com/KernelTeam/KernelMaintenance ?
<smb> Well yes, there are still too many docs referring to that. 
<rtg> BenC: dude, good to see you online.
<BenC> rtg: hey, thanks
<mozmck> hmm, I don't know...  no I don't think so.  Thanks!
<smb> rtg, It feels we should spent a bit of our plenty time to update some of the other building bits
<rtg> smb, I'm not really interested in supporting non-Ubuntu build methods.
<smb> rtg, I don't want to support then, more saying they are not
<rtg> smb, I'm not fully comprehending your intent.
<smb> rtg, My intend would be to find pages claiming that make-kpkg works and clearly state it does not
<rtg> smb, in our wiki? or in someone elses?
<smb> At least when it seems to come from our own wiki pages
<smb> ubuntu wiki and one link previously told seems to be even in the KernelTeam space
<rtg> sounds like a damn good idea to me. when will you have it done?
<smb> rtg, You know how good we are at finding documents... ;-)
<rtg> smb, maybe we can get pgraner to do it in his copious spare time.
 * BenC wonders why kernel-package is even in main
<smb> rtg, Heh, he likely just waits to be asked.
<rtg> BenC: I think it should have been dropped after dapper.
<rtg> smb, I only find 19 instances of 'make-kpkg' in wiki.ubuntu.com
<soren> drbd8-source recommends it.
<rtg> only one in the kernel team heirarchy
<pgraner> rtg: go to google and try:  site:wiki.ubuntu.com make-kpkg
<pgraner> rtg: google is far better at w.u.c than the wiki search engine
<_maks> mozmck: make deb-pkg
<rtg> pgraner, again, only 19
<pgraner> rtg: wow impressive they match
<_maks> you need >= 2.6.31 to have most of its bugs fixed mozmck, but it is not yet feature complet (saying it yet misses linux-libc-dev, source and headers packages :)
<rtg> pgraner, but there are 2 references in _our_ pages. gotta fix that.
<pgraner> rtg: will be up on Wed, he called and asked if I could wait, the installer had a family issue come up :-/
<pgraner> rtg: I have to run into town today and get a USB serial cable so I can get to the BIOS to redirect the serial console back to the main on the build box
<rtg> pgraner, -EWRONGCHAN
<pgraner> rtg: All my cables are in the travel box enroute to here via FedEx Ground
<BenC> rtg: could you snag my ssh pub key from launchpad and have an account created on zinc, please?
<rtg> BenC: it may still be there. lemme check.
<BenC> rtg: it's not, because mine was an ldap synced canonical account
<rtg> BenC: right, I thought of taht as soon as I said it.
<rtg> BenC: rtg@zinc:/home/bcollins. this'll take a bit.
<BenC> cloning git over http should be a sign of the apocalypse
<rtg> BenC: use git://kernel.ubuntu.com/ubuntu
<amitk> BenC: you have a firewall? :-p
<BenC> ah, forgot git:// was setup
<BenC> amitk: no, it's just plain evil :)
<rtg> BenC: still want a zinc account?
<BenC> rtg: yes, please
<akheron> for some reason, I get empty LINUX_VERSION_CODE
<akheron> in include/linux/version.h
<akheron> smb: ideas?
<smb> no immediate ones. and as I got a bit sidetracked I have not started to try the same in parallel. Try to do now
<BenC> can someone explain the debian.master thing in karmic kernel source?
<akheron> I managed to get v2.6.30 to build, but nothing after that
<akheron> it always fails in a file that tries to use LINUX_VERSION_CODE
<bjf__> ##
<bjf__> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf__> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf__> ##
<gnarl> BenC, debian.master is the common things that go to debian. We used that to make multiple topic trees that rebase simpler
<gnarl> BenC, More ore less its debian.master you look at. When you do a clean, files get generated in debian
<gnarl> BenC, So this gets rid of the generated files in git as well. But you always need a clean before build now
<BenC> so debian/ is completely generated off of debian.master?
<gnarl> BenC, Mostly. A small debian/rules was needed, but most of the rest, yes
<akheron> gnarl: always need a clean?
<gnarl> akheron, One time after getting the sources. Oh darn, did I tell you to copy debian.master (completely) as well?
<akheron> don't know if it was you but someone did
<gnarl> akheron, The one time clean generates some files (as debian/changelog) and abi files (when needed)
<gnarl> akheron, me or smb which is mostly the same :)
<akheron> heh
<akheron> still can't get a value for LINUX_VERSION_CODE
<akheron> I'm basically using debian/, debian.master/ and ubuntu/ from ubuntu-karmic.git
<akheron> on top of linus' tree and have checked out an arbitrary commit
<DamienCassou> I propose 50â¬ to fix a bug with suspend/resume on my macbook (issue #400413)
<DamienCassou> http://www.cofundos.org/project.php?id=178
<gnarl> akheron, Just started of the same. Just with v2.6.31 instead of a random point. Then changed the version number in debian.master/changelog and did "fakeroot debian/rules clean" followed by "fakeroot debian/rules binary-generic", got one config qustion asked and now it builds
<akheron> I did this first for v2.6.30, and it built ok
<akheron> then after checking out v2.6.31-rc2 it didn't build anymore
<akheron> nor did an arbitrary commit
<gnarl> akheron, as bad in time it might be, have you tried a "fakeroot debian/rules clean" in between?
<akheron> yes
<akheron> now I even deleted debian/, debian.master/ and ubuntu/ and copied them all over again
<akheron> but still I get an empty LINUX_VERSION_CODE in include/linux/version.h
<akheron> $ cat debian/build/build-generic/include/linux/version.h 
<akheron> #define LINUX_VERSION_CODE
<akheron> #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
<gnarl> maybe give me the sha of the commit in between you tried. When my build here finished I'll try that
<akheron> v2.6.31-rc2
<akheron> and now I'm at d27eadc7612404b06f99888c02726ab7d5036e0f
<akheron> but this is a build system issue, as the #define has been there forever
<akheron> or is generated there
<gnarl> ok, give me a bit. Some file was, but that define looks like one around for quite a while
<gnarl> Hm, but seems to get generated at some point
<akheron> could the changelog mangling be a reason?
<gnarl> So it is rather an issue of how doing the build. The whole of debian/build/build-generic is generated as an out of tree build source
<akheron> if I don't touch debian/changelog it works
<gnarl> how do you change it (paste before and after of the first line)
<akheron> hmm no
<gnarl> and debian.master/changelog is the master file (when trying to avoid clean you would need to change that and copy it to debian/changelog)
<akheron> now it generates ok
<akheron> I'm confused
<akheron> got no time to debug this anymore today, I'll be back tomorrow
<ricklerre> is there a reason that kernel.shmmax changed from 256MiB to 32MiB between 2.6.31-14 and -15 ?
<ricklerre> I can't find it in any changelogs
<Kano32> SUB_INST checking: sound/drivers/pcsp/snd-pcsp.ko
<Kano32> SUB_INST installing: /lib/modules/2.6.32-5-generic-pae/kernel/sound/drivers/pcsp/snd-pcsp.ko
<Kano32> SUB_INST installing: /lib/modules/2.6.32-5-generic-pae//lib/modules/2.6.32-5-generic-pae/kernel/sound/core/snd-pcm.ko
<Kano32> install: cannot stat `debian/linux-image-2.6.32-5-generic-pae//lib/modules/2.6.32-5-generic-pae//lib/modules/2.6.32-5-generic-pae/kernel/sound/core/snd-pcm.ko': No such file or directory
<Kano32> why is that doubling the path?
<Kano32> it worked with generic
<bjf__> ##
<bjf__> ## Ubuntu Kernel Team Meeting - in 5 minutes - #ubuntu-meeting
<bjf__> ##
#ubuntu-kernel 2009-11-25
<bryce> sconklin, you around?
<bryce> on this resolutions timing bug, we're trying to figure out where we get the edid from.  Is there some kernel code that handles this?
<bryce> looking at the control file for read-edid, it says it uses real-mode x86 instructions on i386 and a a VESA VBE 2 interrupt service routine request
<bryce> sconklin, if you are around, maybe pop in #ubuntu-x ?
<jjohansen> bryce: sconklin is out until monday now
<sconklin> jjohansen: no, they caught me 
<jjohansen> sconklin: ah cool
<dtchen> so, I have some good news and some bad news.
<dtchen> the good news is that I've pinpointed the regression on HDA chipsets for ALSA apps routed through the pulse pcm plugin.
<dtchen> the bad news is that it touches sound/pci/hda/hda*.c
<dtchen> this is reproducible on 2.6.29+, so it hits just about all current desktop distros.
<dtchen> so, out of the fire and back into the frying pan for me
<rtg> dtchen, float the patch through the list. I'm sure it will garner some interest :)
<MTecknology> What module do I need to load to have apparmor running on a system that I don't want to reboot?
<MTecknology> ok - looks like it uses upstart..
<cooloney> yzhao: hello, 
<ghostcube> guys, IMHO karmic is the worsest release ever gone in the wild
<ghostcube> :|
<ghostcube> and this is hard for me to say i luv (k)ubuntu
<ghostcube> i never needed to reinstall any pc after an upgrade 
<ghostcube> now i have to do on 3 machines
<ghostcube> -_-
<ghostcube> i hope lucid will get better
<ghostcube> this is topping the gutsy desaster
<Appiah> :)
<apw> ghostcube, what made you need to reinstall following upgrade
<apw> most of us have upgraded without incident
<Appiah> I was gonna wipe my install and install karmic from fresh
<Appiah> but the kernel fix for wireless+ethernet was not fixed in the newest kernel release
<Appiah> so I'm gonna wait
<apw> Appiah, was that fixed in smb's pre-propposed kerenl?
<Appiah> umm
<Appiah> not quite sure?
 * apw remembers working on your bug, but i can't recall the outcome
<Appiah> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/407824
<ubot3> Malone bug 407824 in linux "BOTH Network controller: Intel Corporation Wireless WiFi Link 5100 AND Ethernet controller: Marvell Technology Group Ltd. 88E8040T PCI-E Fast Ethernet Controller (rev 12) FAIL TO LOAD!" [Medium,Fix committed] 
<smb> Appiah, If you don't know what apw is talking about, probably not :)
<Appiah> several duplicates
<Appiah> smb: :)
<smb> Appiah, If you have not before, you might give this a try: https://launchpad.net/~stefan-bader-canonical/+archive/karmic
<Appiah> I have a working kernel made by apw 
<Appiah> the kernel that ships with karmic , and the update that came yesteday or 2 days ago , did not include this fix
<smb> * pci: increase alignment to make more space for hidden code
<smb>     - LP: #407824, #480144, #474577
<smb> It might be this from upstream stable
<apw> Appiah, yep, if its 'FIX COMMITTED" then its not yet released into updates
<smb> The latest update, does not include it, yet
<apw> smb, yes its that one ... just checked with my test kernel
<Appiah> oh
<apw> Fix Rleased means its hits -updates ...
<Appiah> fix commited =! fix released
<apw> correct
<smb> Appiah, no, just in the repo, but not released
<apw> fix committed == fix on its way
<apw> fix released == fix in your hands
<Appiah> but it says relased on ubuntu
<Appiah> and karmic commited
<apw> yes.  ubuntu == lucid
<apw> are you running lucid?
<smb> == next release
<Appiah> ah ofcourse
<Appiah> nope karmic
<Appiah> so will this never ever come into karmic?
<apw> you get fixes faster in the development release, and pain to go with it of course
<smb> Appiah, It will
<apw> Fix Commited == coming soon
<smb> There are jsut sometimes deleays
<Appiah> I see
<apw> but it has to make it into -proposed, be tested in -proposed, then it gets released
<smb> as apw says
<apw> this blob of updates was waiting for the previous blob to move to -updates which you just saw occur
<apw> now the process starts again ...
<apw> apply any security fixes, release that, apply proposed fixes push to -propose, test, release to -updates
<apw> i'd say it'll be in -proposed within the week ... but thats a guess
 * smb shuts his ears and eyes
<Appiah> One thing that I never bothered with was that bluetooth dont seam to work. Pressing the BT button on my laptop just tries to incresse brightness(?) . Been like this is in Jaunty too, what info should be included in a bug report?
<Appiah> execpt lspci
<apw> report it with ubuntu-bug and it'll add everything under the sun including the kitchen sink
<smb> Appiah, You also might have a look at https://wiki.ubuntu.com/Hotkeys
<Appiah> oki , even though it may include alot of crap you dont need? :)
<Appiah> smb: its not a matter of keyboard mapping
<Appiah> I made sure of that first :D
<apw> smb, i wonder if the general flow there might be better documented ...
<smb> apw, Maybe
<apw> "Life Cycle of a Fix to a Stable Release"
<apw> Appiah, do you have -proposed enabled ... ?
<apw> for instance recommending -proposed to those waiting on a Fix Committed bug etc
<Appiah> I have no idea on what that is apw 
<smb> apw, Oh, you did not mean the hotkeys... Yeah, that too
<Appiah> something on launchpad?
<apw> -proposed is an extra source of packages which gets them before they are released to -updates
<smb> No thats one bullet in your sources when you look at installation sources
<apw> a preview of -updates to come as it were
<Appiah> oh
<Appiah> I do not have that repo
<apw> it is where your fix will go first, and hopefully shortly.  you will be asked to test that, and confirm it fixes you
<apw> as part of the acceptance criteria for the update to move to -updates
<Appiah> I will enbable that then
<smb> Appiah, As soon as the fix goes there, the bug report will get updated and people are generically asked to test and give feedback. If you can reply to that it helps to speed getting things into updates
 * smb looks at his watch: "I'll be late, I'll be lateâ¦"
 * apw is struggling to see smb as a fluffy white rabbit ...
<akheron> smb & gnarl: the include/linux/version.h issue was apparently caused by bad version numbers in debian/changelog entries
<akheron> hmm, gnarl isn't here :(
<akheron> anyway, I have been able to build a few working images and I'm on my way bisecting this bug
<apw> akheron, that happens yes, some characters in there break things
<apw> -'s are bad i think
<akheron> ok, i'll keep that in mind
<akheron> I tried to include git describe output into the version number, but it didn't work
<akheron> now I just have an increasing number to not overwrite old images and have the git describe output in the changelog message
<ghostcube> apw: it just doesnt boot
<ghostcube> all machines hanging on apparmor
<ghostcube> the mac and the server installs
<ghostcube> better the last i see is apparmor and then it starts blinking
<ghostcube> karmic isnt the best release ever :D
<apw> ghostcube, heh for you no it sounds not
<apw> so you don't see a panic on the console if you boot without quiet and usplash
<apw> as flashing sounds like a panic, i assume here you mean flashing capslock ?
<ghostcube> apw: nah the screen keeps flashing on off
<ghostcube> it says loading apparmor
<ghostcube> and just the screen begins to blink
<ghostcube> :|
<apw> apparmor is the last thing we init i think before X starts
<apw> perhaps X is restarting contantly
<ghostcube> yeah seems so
<apw> there was a bug in upstart doing that, a bug in gdm's config
<ghostcube> i think an radeon problem
<ghostcube> all 3 machines on ati cards
<ghostcube> apw: yep this could be the prob
<ghostcube> its an xubuntu install
<apw> what graphics do you have
<ghostcube> 2 times rage 128 pro and one time radeon 9200
<apw> all in the failing machine?
<ghostcube> nah 3 machines failing
<ghostcube> 3 different ones
<ghostcube> all with xubuntu
<apw> all radeon ... hrm
<ghostcube> yep
<apw> i'd expect radon to work if anything, using binary drivers?
<apw> ghostcube, from the symptoms i recon that one needs referring to #ubuntu-x
<ghostcube> i cant do anything i need to load repair console tonight
<ghostcube> i cant access any tty
<ghostcube> :)
<apw> ghostcube, indeed.  they may know how to stop it doing that
<apw> perhaps booting 'single' and disabling the gdm upstart job
<ghostcube> apw: ok thx will tell them if iam back at the machines
<apw> sounds good, if there is a bug, get an xorg task on it
<smb> Wasnt there something like saying "text" on the command line
<smb> akheron, Thanks for the feedback. It really sounded strange why one build works and the next not. I'd probably just automatically avoid the bad chars there.
<akheron> smb: as you probably already know, debian.master/rules.d/0-common-vars.mk expects quite a lot from versions in changelog :)
<smb> ghostcube, Seems anything of "text|-s|s|S|single" should prevent gdm from starting on ubuntu. Might be worth trying...
<ghostcube> ok but i first need to get into it with any console cause i cant access the machine
<ghostcube> if so i had more infos thats the problem
<ghostcube> :D
<smb> akheron, There is a lot of magic in there for sure.
<smb> ghostcube, Well, that was for using at the command line from grub. Or do you have no physical access to them?
<ghostcube> smb: ah ok sorry misunderstood
<ghostcube> sure i can get to the grub manager sorry
<smb> ghostcube, No worries. :) I misunderstand a lot ;-)
<ghostcube> heh
<Keybuk> apw: why has usbfs turned itself back on in our kernels?
<apw> Keybuk, which one
<Keybuk> CONFIG_USB_DEVICEFS=y
<Keybuk> the one I keep saying to set to =n just about every other week :p
<soren> Keybuk: Google for "CONFIG_USB_DEVICEFS launchpad" and you'll see.
<apw> Keybuk, well its on in every release back to intrepid
<Keybuk> soren: yes, and the correct answer to any bug is Won't Fix
<Keybuk> go fix your stupid broken software
<Keybuk> enabling that option *breaks* correct behaviour of udev
<Keybuk> it changes the usb uevents in wrong ways
<Keybuk> and breaks things like firmware loading
<soren> Keybuk: I'm not disagreeing.
<BenC> IIRC, the only thing still using it was vmware
<BenC> did they ever fix themselves?
<Keybuk> yes, finally
<Keybuk> only after we removed it ;)
<Keybuk> apw: in fact, a quick grep through launchpad shows that we have a lot of usb firmware loading regressions again
<BenC> I thought we always had it disabled, but udev had some compatibility layer for it
<Keybuk> looks like amit enabled it again
<soren> Yes. First hit on google for that search I mentioned.
<soren> Bug #417748 
<ubot3> Malone bug 417748 in linux "Please enable CONFIG_USB_DEVICEFS" [Medium,Fix released] https://launchpad.net/bugs/417748
<Keybuk> *sigh*
<soren> Sorry, should have just posted the bug number, I suppose.
<apw> fun ... so Keybuk whats the story with it... why is it bad, why is it good, what does it do
<Keybuk> apw: it's the config option for the old /proc/bus/usb virtual filesystem
<Keybuk> which we don't use
<Keybuk> enabling it changes the usb uevents to refer to that instead of being udev compatible
<Keybuk> we use udev to populate /dev/bus/usb
<Keybuk> so, enabling that option, *breaks* udev
<Keybuk> and because it populates the uevent with /proc/bus/usb paths, it breaks anything else using them
<Keybuk> like firmware loaders
<apw> Keybuk, ok so i am happy to zap it for lucid if that is what we need
<Keybuk> apw: I've asked for it to be zapped every single release since hardy
<BenC> IMO, it's always been needed
<apw> we will get people wanting it i am sure ... sigh
<Keybuk> in fact, maybe even before
<BenC> but random bug reports about ancient proprietary programs keep yanking it back
<BenC> iirc, the only reason we kept it around was because of vmware
<apw> so we can add it to the config checker with a comment on why you don't want to enable it
<BenC> I don't think any other bit of software has enough user base to make that so any longer
<apw> is there some way we can stop it changing udev even when enabled
<Keybuk> no
<Keybuk> not without basically removing all the code that supports it
<apw> BenC, sounds positive at least
<Keybuk> honestly, we don't want it
<Keybuk> it's wrong, broken
<Keybuk> we haven't enabled it since before hardy
<Keybuk> stop turning the option back on!
<apw> well except we have, its enabled in every release i've checked currenlty
<apw> and they all work 
<apw> even hardy has it enabled
<Keybuk> no, I mean the userspace portion is disabled
<apw> Keybuk, so ... the justification is it breaks firmware loading on usb devices in lucid ... right?
<Keybuk> apw: right
<Keybuk> in karmic actually
<apw> ok ... thanks
<apw> la la la :)
<Keybuk> I background remember seeing a whole bunch of bugs near karmic beta and not caring
<apw> so udev in karmic and lucid are affected here.
<apw> sounds like we need a bug then as we'll need to consider sru
<apw> BenC, thanks for the background
<Keybuk> apw: I'd also point out http://markmail.org/message/3mw5yw465qmxgnwp
<Keybuk> it'd be nice if you guys didn't keep turning back on options that I have patches to remove upstream ;)
<apw> Keybuk, if your patches made it into upstream we'd not be able to turn them on !!
<apw> :)
<Keybuk> apw: it did, it's in the "sunset queue"
<Keybuk> to give people enough notice
<apw> what the heck is the sunset queue ...
<apw> Keybuk, ok you filing a bug or am i
<Keybuk> apw:  you do it
<Keybuk> apw: you know, where greg queues things he's going to remove ;)
<Keybuk> he actually did submit the patch for a while
<Keybuk> but poor RH actually use /proc/bus/usb in their initrd :p
<Keybuk> so he backed off to "this is going to be submitted soon, fix it QUICKLY"
<Keybuk> it is marked DEPRECATED still ;)
<Keybuk> with my config text
<apw> Keybuk, the bug in karmic which mentioned it, claims it stops VirtualBox/VMWare from working
<apw> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/417748
<ubot3> Malone bug 417748 in linux "Please enable CONFIG_USB_DEVICEFS" [Medium,Fix released] 
<Keybuk> apw: old versions only afaik
<apw> Keybuk, thanks for that
<Keybuk> we even made a new devices.txt file path for those that *really* wanted it
<Keybuk> /sys/kernel/debug/usb/devices
<Keybuk> (which is one of the reasons we always mount /sys/kernel/debug on boot now)
<Keybuk> apw: hey
<Keybuk> and another thing
<Keybuk> is there a way to turn on/off kernel options like initcall_debug on the fly? :p
<apw> initcall_debug is that not a command line option
<Keybuk> it is
<apw> so on the fly meaning ?
<Keybuk> as in, toggle off again in sysfs
<Keybuk> core_param(initcall_debug, initcall_debug, bool, 0644);
<Keybuk> aha!
<Keybuk> that means it should be in /sys/module/kernel/parameters ;)
<Keybuk> (all those initcall debug messages were adding ~1.5s to the boot after kernel starts)
<Keybuk> since you get them every time you load a module, etc.
<apw> ahh so the thing to measure the kernel makes it slow?
<Keybuk> it makes the boot slower
<Keybuk> which is annoying
<Keybuk> it doesn't add much to the kernel itself, since it's all ring buffer at that point
<Keybuk> but it keeps on debugging after the kernel is init'd and all through user boot and stuff
<Keybuk> those are backed by file, so that *does* slow things down
<apw> ahh ... 
<apw> so it sounds like yu have what you wanted
<Keybuk> yup
<Keybuk> thanks for being an excellent teddy bear
<maco> teddy bears? where?
<Keybuk> http://www.downloadsquad.com/2009/10/16/troubleshooting-with-your-teddy-bear/
<Keybuk> apw: now to try and work out how to turn that off ;)
<apw> Keybuk, heheh thanks
<Keybuk> sed -e "/-t sysfs/a \
<Keybuk> echo 0 > /sys/module/kernel/parameters/initcall_debug
<Keybuk> " /usr/share/initramfs-tools/init
<Keybuk> should do it <g>
<Keybuk> apw: yay, that all worked
<Keybuk> I have initcall debugging for the kernel, but it switches off once the real boot starts
<apw> most excellent
<Keybuk> according to my bug folder, floppy drives aren't working
<Keybuk> there's a lot of mails about it ;)
<Keybuk> DK issue apparently
<bjaglin> hi! is there a reason why the staging drivers are not included in the 2.6.32 packages in the kernel ppa? I am missing rt2870sta in 2.6.32-rc8
<apw> Keybuk, DK ?
<apw> bjaglin, no obvious reason i can think of ... if you mention which thing is missing and email the kernel-team list we'll see what we can figure out
<Keybuk> apw: DeviceKit-Disks
<apw> Keybuk, phew :)  yeah the ones i've looked at seem to have udev and below in place
<Keybuk> yeah
<Keybuk> the problem smells like stuff at the top going "oh, but it doesn't have a filesystem on it" because stuff at the bottom didn't look BECAUSE IT'S A FLOPPY DISK!
<Keybuk> we don't look at floppy disks
<Keybuk> because the ker-chunk-thunk-thunk-cha-cha-cha-thunk during every single boot, and every random package upgrade that calls udevadm trigger, really pisses people off
<Keybuk> (not to mention it's slow)
<Kano> hi, did somebody disable NFS for 2.6.32
<Kano>  * Not starting NFS kernel daemon: no support in current kernel.
<ghostcube> oha
<Kano> rt2860sta seems to have got problems too
#ubuntu-kernel 2009-11-26
<Keybuk> http://people.canonical.com/~scott/daily-bootcharts/
<Keybuk> each day has links to a kernel bootgraph for you
<Kano> hi, does nfs-kernel-server for for anyone with 2.6.32?
<Kano> hmm seems to be just a small problem in the initscript
<Kano> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554508
<ubot3> Debian bug 554508 in nfs-kernel-server "nfs-kernel-server: init script incompatible with kernel 2.6.32" [Important,Open] 
<Kano> [ "$(cat /sys/module/nfsd/initstate 2>/dev/null)" = "live" ]
<Kano> that would do
<researcher> :)Hello everybody
#ubuntu-kernel 2009-11-27
<AceLan> ShapeShifter499: The steps to compile ubuntu kernel is 1. fakeroot debian/rules clean 2. fakeroot debian/rules binary-generic
<ShapeShifter499> my patch tells me to do something else
<AceLan> ShapeShifter499: never use "make" command
<ShapeShifter499> why?
<AceLan> ShapeShifter499: it will delete debian/ directory or pollute the kernel directory
<amitk> ShapeShifter499: the ubuntu build system conflicts with the in-kernel build system
<ShapeShifter499> ok so I apply the patch with the patch command then do the commands you posted?
<AceLan> ShapeShifter499: right
<ShapeShifter499> is that the same with the Linux Unified Kernel patch?
<AceLan> ShapeShifter499: the same
<ShapeShifter499> ok
<ShapeShifter499> thanks for the help
<AceLan> np :)
<ShapeShifter499> I'll stay here in case of errors
<ShapeShifter499> oh is there a faster way of downloading the ubuntu kernel?
<AceLan> ShapeShifter499: are you using git and already downloaded a upstream kernel by git?
<ShapeShifter499> no
<ShapeShifter499> I'm new to this
<AceLan> so, there is no faster way to download the kernel source :p
<ShapeShifter499> whats the upstream kernel?
<AceLan> the linux kernel maintains by community
<ShapeShifter499> oh...
<MTecknology> ShapeShifter499: I'd download it with git - it takes longer the first time but it's much faster in the future
<ShapeShifter499> I know
<ShapeShifter499> you just use the git fetch command right?
<MTecknology> ok - jsut thought i'd mention it
<ShapeShifter499> what happens if they update to a new kernel for my system? do I have to re download the files?
<AceLan> ShapeShifter499: using git: git pull --rebase
<ShapeShifter499> just to be sure that would...
<ShapeShifter499> ...
<ShapeShifter499> do what?
<ShapeShifter499> anyone here?
<kengyu> ShapeShifter499, update your kernel code base.
<akheron> what to do with https://bugs.launchpad.net/ubuntu/+source/linux/+bug/481765 ?
<ubot3> Malone bug 481765 in linux "ACPI: After an upgrade to Karmic, the system hangs on boot" [Undecided,New] 
<akheron> I was able to bisect the problem to one upstream kernel commit, and reverting it fixed the issue
<akheron> How to report this upstream, how to get it fixed in Ubuntu, etc.?
<Appiah> upstream kernel.org ?
<akheron> yes
<akheron> I bisected Linus' kernel tree, found the bad commit, reverted it in karmic kernel source tree, built, and now it works
<Appiah> then use their bug tracker
<Appiah> http://bugzilla.kernel.org/
<akheron> ok, but will it then be fixed in karmic or lucid at all?
<Appiah> if its broken then they will have to fix it right? :)
<akheron> :)
<akheron> I mean, if the fix gets to upstream after 2.6.32, will it ever be backported to ubuntu kernels?
<apw> Keybuk, the daily boot charts are they daily or on ISO generation, and roughly what time do i expect them to pop out if they are done on any particular day?
<Keybuk> they're on ISO generation
<Keybuk> so each one corresponds to a particular ISO on cdimage/daily-live
<Keybuk> (redoing them every day with no ISO change isn't worth the effort)
<Keybuk> currently the push-to-rookery cron is at 2pm
<Keybuk> I'm likely going to move that forwards because there's too much gap in it
<apw> Keybuk, don't mind when it is, just nice to know "oh its after X, if there is a new one i can look now"
<Keybuk> I've just updated the cronjob to be ourly
<Keybuk> (the publish one)
<Keybuk> after verifying it's a no-op if the stuff isn't finished yet
<Keybuk> this should just reduce the gap
<Keybuk> it's still dependant on when the machines wake up
<Keybuk> at a glance, looks like the SSD charts for today are up
<Keybuk> but the HDD ones aren't
<apw> oh yeah and thats what the web site shows now too :)
<apw> and its showing the 5s we lost yesterday have come back ... good
<apw> man these tables are great ... makes me want to slap people i have working on bits of that to hurry up so i can see our bit get smaller
<Keybuk> lol
<Keybuk> if you're not on Firefox, you get little graphs at the top
<Keybuk> which really should be "blame" graphs
<Keybuk> you can see exactly which bit the 8s extra boot time came from
<apw> sadly in firefox
 * apw must sort out having chrome
<Keybuk> add-apt-repository ppa:chromium-daily/ppa
<Keybuk> apt-get update
<Keybuk> apt-get install chromium-browser
<Keybuk> ... the chimes behind me tell me that HDD should be up any second
<apw> Keybuk, hehe :)
<Keybuk> who knows about the rtc wake alarm stuff?
<Keybuk> you used it for your suspend/resume tests I think?
<Keybuk> \o/ I have made a DOS disk
<amitk> Keybuk: we're speed up DOS boots now?
<amitk> *speeding
<Keybuk> I'm trying to update the BIOS on the mini 10s to see whether I can get ACPI wake support working at all
<Keybuk> neither wake-on-lan or RTC wakeup work :(
<amitk> cking is our wakealarm expert but he is out till for a few weeks
<apw> Keybuk, yeah i know some about it
<apw> if you have a recent kernel on there then you need to use some magic to work out the delta
<Keybuk> huh?
<apw> Keybuk, you need to use the files in /sys/class/rtc/rtc0 ... since_epoch tells you the current time in the clock, you work out the time in seconds since the system epoch you want to wake, subtract the current since_epoch value and shove it into wakealarm
<apw> then suspend
<apw> if that makes any sense
<Keybuk> right I do that
<apw> actually no thats not right either
<Keybuk> and checking /proc/driver/rtc says the right time too
<Keybuk> and says it'll wake up
<apw> you work out the time in seconds since system epoch you want to wake up, then adjust that by the current time on the system since system epoch and the since_epoch value
<apw> wake alarm is in the same units as since_epoch and can be offset from the system time
<Keybuk> right
<Keybuk> though only by <1s on this machine
<Keybuk> so that's not the problem
<apw> so you are lucky :)
<apw> so its not waking up for you?  the 10v ?
<Keybuk> yeah
<Keybuk> not at all
<apw> Keybuk, when i try it on here it doesn't say 'alarm_pending: yes' which seems wrong
<Keybuk> according to google, that says "no" for most people
<Keybuk> arlarm_IRQ is the important bit apparently
<Keybuk> in the code, it says you can write +800 to the rtc wakealarm function
<apw> oh nice
<Keybuk> I shall try on my laptop
<amitk> IIRC, cking had found some bugs in the HW that reqd the wake time to be written twice for it to work
<apw> i just shoved  +60 into my 10v and it seemed to set the time accorording to /proc/driver/rtc
<apw> Keybuk, one thing you often have to do is clear it first by writing a 0
<amitk> Keybuk: http://smackerelofopinion.blogspot.com/2009/08/acpi-wake-alarm-bugs.html
<Keybuk> yeah I tried that too
<Keybuk> the fact that wake-on-lan doesn't work either suggests they screwed the bios on these
<apw> Keybuk, man that sucks rocks
<apw> its not like you can even tell them to boot on power enabled i guess
<Keybuk> yeah
<Keybuk> they have numpty bios
<Keybuk> otoh, my latitude just worked perfectly
<apw> does feel that way... cirtainly cannot wake mine
<Keybuk> echo +60 > wakealarm
<Keybuk> pm-suspend
<Keybuk> and it woke up
<Keybuk> and powerwake while it's still asleep ... still wakes it up
<Keybuk> so clearly Linux is working <g>
<apw> powerwake ?
<Keybuk> dustin's tool to send wake-on-lan packets
<Keybuk> ok
<Keybuk> that's freaky
<Keybuk> the Laititude can wake on WLAN
<apw> nnng
 * apw wonders if thats reasonable ... 
<apw> i don't think my AP passes the magic packets across the boundary
<apw> so i ahve to do it from the same side to get it to work
<Keybuk> looks like it just stays associated
<Keybuk> one assumes it has to be unencrypted
<apw> sleep mode for wifi allows remaining associated
<apw> the AP can queue packets and all sorts
<apw> normally doesn't work ... but
<Keybuk> it worked without even trying on this
<Keybuk> (linksys ap running openwrt)
<apw> i assume in your wake on lan testing the sender and recipient were both on the same ethernet switch?
<Keybuk> yes
<apw> i found they needed to be on the same bridged segment and my AP was not passing them over from the WLAN
<apw> ok so they just don't work
<Keybuk> my network is all bridged
<Keybuk> including the connection to the ISP
<Keybuk> which was a bit scary when I found out that's what they did
<Keybuk> but then realised it was a cool idea
 * apw notes the 10v has 'wake on usb' as an option
<apw> dunno if that could be used somehow
<Keybuk> yeah
<Keybuk> no idea
<Keybuk> I always assumed that's a magic usb signal
 * Keybuk flicks through the maplin catalogue
<apw> Keybuk, which bios version do you have on your 10v's i don't seem to have a wake on lan option in the bios
<apw> if you arn't enabling it there, where are you enabling it
<Keybuk> A06
<Keybuk> ethtool says it's enabled
 * apw has A05 ...
<Keybuk> but I also tried A00 and A04
<Keybuk> if I toggle with ethtool
<Keybuk> ethtool -s wol d eth0
<Keybuk> ethtool -s wol g eth0
<Keybuk> poweroff
<Keybuk> then ... the machine promptly powers straight back up again
<Keybuk> so it's clearly toggling *something* in the BIOS :p
<Keybuk> actually with A06 it didn't do that
<Keybuk> it just didn't wake up at all
<apw> Keybuk, ok mine seems to wake up from a suspend at least
<apw> using 'wakeonlan' i can wake it from suspend without changing any settings
<Keybuk> really?
<Keybuk> neither of mine will do that
<apw> i am using the wakeonlan program from wakeonlan package
<apw> there is something about some things only working on AC, so testing iwthout power would be different
<Keybuk> how do you spend?
<apw> spend?
<Keybuk> suspend
<apw> that was from the menu
<apw> won't wake from power off even though the lan claims to be negociated
<Keybuk> mine won't wake from suspend *at all* with A06 bios
<Keybuk> and today's lucid
<apw> even via the power button
<Keybuk> even via that
<Keybuk> which BIOS version do you have again?
<apw> i believe its A05, i'll cheeck next boot
<Keybuk> dmidecode? :p
<apw> i think i just found sudo pm-suspend did not let me wake it
<Keybuk> ah
<Keybuk> I was doing pm-suspend
<apw> not sure how that would differ from the meny
 * apw retests
<apw> i wish these booted faster :-P
<apw> bios A05
<Keybuk> noticeably the suspend light stays on
<apw> i seem to have broken mine now, syspend from the mey isn't working
<Keybuk> rather than pulsating
<apw> the power light  ... same here
<apw> and on A05 and Karmic ... never seen that before
<apw> i am suspicious its cause the network is plugged in ... testing more to confirm
<Keybuk> I'm sure mine were suspending ok earlier :p
<Keybuk> maybe they only suspend before 3pm
<apw> now its ok again ... wtf
<apw> yeah and when i wake it, the only thing you see if the power go solid
<apw> the screen says off till you hit a key
<Keybuk> hmm
<Keybuk> just tested A05 and power light still stays on solid
<Keybuk> and won't wake
<apw> ok try booting without the ethernet plugged in and add it after login
<Keybuk> freaky
<Keybuk> it's almost as if those wakeonlan packets are bouncing around the network somehow :P
<apw> ok the wedging on suspend went away for me
<apw> i cannot get it back now ?!?
<apw> and suspend based wake works fine ... with a karmic kernel
<apw> i'll get a lucid one now
<Keybuk> lol
<Keybuk> huh
<Keybuk> suspend worked fine
<Keybuk> wake on lan made the light come on
<Keybuk> and screen when I pushed a button
<apw> so thats working ... as in working same as me
<apw> i think the normal screen wake occurs cause open lid and the power button are both keys
<Keybuk> yes
 * apw may get dropped shortly ... according to christel
<Keybuk> now both are working
<Keybuk> both on A06
<apw> WTF ?
<Keybuk> let me try powering off with ethernet
<Keybuk> and powering up with ethernet
<Keybuk> the only thing I did differently was not plugging the ethernet in until they were on
<apw> i dnd't get wake from 'off' to work
 * apw does the same experiment
<Keybuk> maybe that's it
<Keybuk> if you send the wol packet while it's off
<apw> ie will suspend/wol work if i power up with ether net in
<Keybuk> it screws suspend until you unplug the network cable
<Keybuk> I've been trying to do wake-from-off
<Keybuk> maybe I should put them in S3
<apw> sounds like wol from suspend is about all thats available
<Keybuk> ok
<Keybuk> just rebooted one through a poweroff/on
<Keybuk> lets see if it suspends normally
<Keybuk> apw: ok, physical power off and human power on - suspend still works
<Keybuk> and it looks like WoL works too
<apw> Keybuk, worked for me
<apw> i think sending wol packets to it when its off is the end of the world
<apw> same experience here
<apw> its clear the machine can take wol packets when powered off, as it keeps the phy up
<apw> but it seems to break its mind too
<Keybuk> yes
<Keybuk> I just tested that
<Keybuk> if you send a WoL packet while they were actually powered off
<apw> something to report to superm1 me thinks
<Keybuk> the world ends
<Keybuk> they have to be just suspended
<apw> well i guess that 5w instead of 40 or whatever
<Keybuk> yeah I can live with that
<apw> its the least of the 50 other things on :)
<apw> oops
<Keybuk> actually I power off my desktop now ;)
<Keybuk> since discovering that it does WoL
<apw> heh yeah my build servers are the same
<Keybuk> so the only thing that stays on is the server
<apw> yeah i have a teensy server which wakes everything the same
<Keybuk> which I deliberately bought as an "efficient" computer
<apw> though it will be this dell 10v will become my master i think
<apw> one interesting thing is in theory the machine can wake on 'arp' too 
<apw> i wonder if that work
<Keybuk> only if you install ethtool ;)
<Keybuk> ok
<Keybuk> so I need a script that
<Keybuk>  1. puts the machine to sleep
<Keybuk>  2. checks for a new cd image
<Keybuk>     - if there is a new image, wipes the MBR and reboots
<Keybuk> if there isn't, we assume we were woken up by user
<Keybuk> so stay on
<apw> nope does support that
<apw> doens't
<Keybuk> apw: lol
<Keybuk> did you set for that with ethtool first?
<apw> ethtool tells you what the machine can do, and it can't to 'a'
<Keybuk> ethtool -s eth0 wol a
<apw> pubmg ... 
<Keybuk> ahh
<Keybuk> my desktop is just pg ;)
<apw> my big dell can only do 'g' which is the wake on lan magic packet
<apw> phy activity ... woh
<apw> ahhh welll so she'll have to be on always
<Keybuk> if you're on a switch that'll be directed activity or broadcast
<Keybuk> which is actually not so bad
<Keybuk> if you have no SMB, etc.
<apw> yeah i guess so
<Keybuk> let's see if this works then
<Keybuk> faked a 27.1 cd
<Keybuk> the machine should install it, then got into a suspend
<apw> Keybuk, fingers crossed
<Keybuk> ooh, first one just suspended
<Keybuk> the other is still installing
<Keybuk> right
<Keybuk> both in suspend now
 * Keybuk fakes a CD update
<Keybuk> ok
<Keybuk> now the SSD one only should wake up
<Keybuk> it woke up, but I can't tell whether it's checking for the image :-(
<Keybuk> oh, wow, it did
<Keybuk> it rebooted and everything
<Keybuk> and now the script won't wake up the HDD one because the SSD one is installing \o/
 * Keybuk watches
<Keybuk> apw: don't suppose you know a way to force the display awake?
<apw> Keybuk, well xset dpms might work
<apw> Keybuk, or xset s ... one of its might so the trick
<apw> xset dpms force on
<apw> perhaps
<Keybuk> doesn't look like it matters
<apw> ?
<Keybuk> just means there's an odd quirk that the display is always off ;)
<Keybuk> X starts just fine with the display off
<Keybuk> I suspect it's just the backlight?
<apw> heh yeah i think xset dpms force on will wake that
<apw> Keybuk, failing that there is a dbus message that the pm stuff sends to tell the display to wake i think
 * Keybuk tosses it in there
<Keybuk> can't hurt after all
<apw> Keybuk, i assume it comes back on when you reboot into the image
<apw> xset dpms isn't working for me
<apw> hrm
<Keybuk> no, doesn't come back on when I reboot :p
<apw> hmmm no dbus msg when it comes on
<Keybuk> dpms didn't work for me :-/
<apw> Keybuk, nor me
<apw> i've not yet found anytinhg which wakes it up, other than a key, very odd imo
<Keybuk> must be a BIOS thing
<Keybuk> it doesn't seem to affect the results any
<Keybuk> so I'm looking at it as a power saving :p
<mjg59> vbetool should be able to force a DPMS transition before you get to X
<mjg59> Or if you're using KMS, it ought to do that anyway
<JanC> anybody seen/heard about a kernel panic like this with the karmic kernel: http://forum.ubuntu-nl.org/installatie/probleem-na-upgrade-ubuntu-9-10-kernel-panic-not-syncing/ (jaunty kernel boots fine) ?
#ubuntu-kernel 2009-11-28
<Cytotoxic> the ubuntu kernel sucks
<Cytotoxic> !ops
<ubot3> Help! lamont, zul, T-Bone, mdz, or jdub
<pace_t_zulu> Cytotoxic, get a life
<JanC> Cytotoxic: don't be stupid
<Cytotoxic> ubuntu sucks
<JanC> Cytotoxic suck
<pace_t_zulu> hey guys, i'm looking for a developer with apple hardware
<pace_t_zulu> more specifically macbook
<Cytotoxic> I am a cytotoxic t cell i protect aginst infections
<pace_t_zulu> JanC, don't lower yourself to his level
<Cytotoxic> ubuntu kernel developers are nothing compared to microsoft enginners
<Cytotoxic> ubuntu kernel developers are nothing compared to microsoft enginners
<Cytotoxic> !ops
<ubot3> Help! lamont, zul, T-Bone, mdz, or jdub
<JanC> Cytotoxic: kindergarten is that way --->
<Cytotoxic> JanC, preschool is that way <-------
<JanC> and if you want anything fixed for you, your chances are about 0 by now
<Cytotoxic> i dont use ubuntu
<Cytotoxic> I use windows 7
<JanC> great
<Cytotoxic> ur right there is no chance of anything getting fixed on ubuntu
<Cytotoxic> Microsoft enginners work real hard unlike ubuntu developers
<JanC> I agree, see, even Linus Torvalds loves Windows 7: http://cache.gawker.com/assets/images/gizmodo/2009/10/torvalds_windows_7.jpg
<Cytotoxic> Linux is open source which means more secuirty vaunrablitys
<JanC> now please go play on microsoft's chat network
<Cytotoxic> they dont have one
<JanC> of course they have
<_maks> JanC: you have great patience :)
<Cytotoxic> where
<Cytotoxic> LISTEN THE BOTTOM LINE IS LINUX SUCKS
<JanC> Cytotoxic: http://download.live.com/messenger/
<LjL> please, don't feed
<Cytotoxic> HEY LJL
<Cytotoxic> BAN ME
<Cytotoxic> !OPS
<ubot3> Help! lamont, zul, T-Bone, mdz, or jdub
<Cytotoxic> THEY WILL
<JanC> Cytotoxic: seems like Microsoft engineers have to fix an issue with lower case characters in the keyboard driver
<Cytotoxic> no my keyboard is fucked up
<Cytotoxic> BAN ME
<Cytotoxic> no my keyboard is fucked up
<Cytotoxic> no my keyboard is fucked up
<Cytotoxic> no my keyboard is fucked up
<Cytotoxic> no my keyboard is fucked up
<Cytotoxic> BAN ME
<Cytotoxic> BAN ME
<Cytotoxic> !ops
<ubot3> Help! lamont, zul, T-Bone, mdz, or jdub
<Cytotoxic> why arnt any of da lazy ops banning me?
<Cytotoxic> Fuck ubuntu
<Cytotoxic> Fuck ubuntu
<Cytotoxic> k-line me mr freenode staffer
<Cytotoxic> !ops
<ubot3> Help! lamont, zul, T-Bone, mdz, or jdub
<CarlFK> gribouille in #ubuntu says "removed grub/grub..  when I update my kernel, dpkg complains because it can't find update-grub"   
<CarlFK> http://packages.ubuntu.com/karmic/linux-image  does not depend on update-grub
<CarlFK> guessing a script should check exist update-grub ?
<tormod> CarlFK, should be in the grub-pc package (on Karmic with grub2)
<CarlFK> tormod: what should?  
<tormod> update-grub
<CarlFK> right - so what happens when you remove that package? (like I guess if you are using lilo )
<tormod> /etc/kernel-img.conf should have the right hooks
<tormod> did he install grub first, then removed it?
<CarlFK> sounds like it - I'll ask... he is kinda cranky :)
<CarlFK> gribouille: you installed from cd with grub, then removed grub? (02:02:32 PM) gribouille: CarlFK, yes
<lifeless> CarlFK: gribouille probably hasn't removed the hooks
<CarlFK> lifeless: I would think if someone is just using apt-get, they shouldn't need to edit files ?
<lifeless> CarlFK: true; so the question is what package adds and removes those hooks.
<CarlFK> ah, so it isn't as coupled to linux-image as I thought 
<CarlFK> lifeless: should I file a bug report against something and dump the chat logs into it?
<shakall69> sall all - can someone tell me how to compile a kernel in lucid ?
#ubuntu-kernel 2009-11-29
<ago> hi people...
<ago> i have note who if I re-compile a custom kernel on ubuntu...if the initrd is not present..the system not start...why?
#ubuntu-kernel 2010-11-29
<Darxus> virtuald: In most cases just initiating a normal shutdown would be great.  
<JanC> ctrl-alt-del still does a normal shutdown when you're in a console AFAIK
<JanC> and doing a normal shutdown with alt+sysrq is impossible
<RAOF> When you're hitting the alt+sysrq keys you're clearly in a situation where userspace isn't able to shutdown cleanly anyway.
<JanC> RAOF: there are still people who use alt+sysrq to "log out"...   ;)
 * RAOF feels safe in declaring them outside the target audience :{
<ohsix> uhhh
<JanC> RAOF: they are mostly people following wrong advice
<JanC> but I agree we don't need to change sysrq behaviour for them  ;)
<Darxus> Why can't the kernel initiate a normal shutdown in response to an alt-sysrq combination?
<ohsix> besides being a key only a kernel hacker should really know about? you can also assign stuff to ctrl-alt-delete
<JanC> Darxus: how would the kernel know what to do to do a normal shutdown?
<MTecknology> In bug 673366, wouldn't the file descriptor limit be per process and not per user?
<ubot2> Launchpad bug 673366 in nginx (Ubuntu) "default settings are dangerous (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/673366
<RAOF> Yes, AFAIK the file descriptor limit is per-process.
<ohsix> nginx should probably get a ratelimit if it can generate messages that fast, regardless of the content
<RAOF> Note that raising the file descriptor limit for nginx may expose vulnerabilities if nginx isn't coded for it.
<ohsix> and only moves the goalposts, the log spamming problem would still exist
<ohsix> /me peanut gallery
<MTecknology> RAOF: the default is 1024 - the reporter was saying that it's too high
<RAOF> No, the reporter was saying that the number of workers spawned is too high.
<MTecknology> oh
<MTecknology> RAOF: the default is 1..
<MTecknology> afaik...
<RAOF> Right.  However, nginx will almost certainly have stdin, stdout, and stderr open which are 3 fds.
<MTecknology> oh- I lied, it's 4
<RAOF> 4 workers by default?
<RAOF> How about worker_connections?
<MTecknology> 1024
<RAOF> Which is probably at least 3 too high.
<MTecknology> 1021?
<RAOF> (stdin, stderr, stdout)
<MTecknology> oh
<RAOF> Possibly; it could be using other things which claim an fd.
<MTecknology> default could maybe just be dropped to something like 1010 or something a tiny bit lower?
<RAOF> It'd probably be worth checking the code.
<RAOF> Also, as ohsix says, it should probably have a ratelimit *regardless*
<MTecknology> I'll do that - and fire an email off to the mailing list
<MTecknology> and mention the rate limit
<MTecknology> thanks :)
<Darxus> Is the kernel not capable of doing the equivalent of "telinit 6"?
<ohsix> it's as capable of doing that as it is spawning init, or the hotplug program
<Darxus> So what's the problem with the kernel starting a normal reboot in respons to an alt-sysrq key sequence?
<ohsix> whats the problem with it doign all sorts of things that are out of the scope of what alt-sysrq exists for
<ohsix> you could use it to turn on a keyboard mode that played an octave of beeps on the pc speaker with the top row of keys
<Darxus> If there was a single alt-sysrq key to do a clean reboot, I would not have had two hard drives crash from power cycling recently.  When ctrl-alt-del wasn't working.
<ohsix> theres no such thing as a clean reboot in the situations alt-sysrq is for, you only hope it can sync drives
<Darxus> It's a hell of a lot cleaner than just shutting power off.
<Darxus> Enough that I wouldn't have lost over 2TB of data.
<ohsix> it's also best effort
<ohsix> best effort isn't a guarantee that your scenario would have turned out any different
<ohsix> its pretty wild to lose a whole volume though
<Darxus> But it is very likely that it would have.
<ohsix> how
<Darxus> Yeah, I did.  I've got the dmesg output showing the hard drive freaking out if you're interested.
<Darxus> What do you mean how?
<Darxus> All processes would've been killed, and the disk would've been unmounted, so the heads wouldn't have been hovering over the platters when power got yanked.
<ohsix> i'm interested
<ohsix> power yanking? yikes
<Darxus> Effectively.  I had to hold the power button in for 4 seconds.
<Darxus> If ctrl-alt-del always worked when alt-sysrq did, that would be great.  But since it doesn't I think there should be a single key sequence the average person can be expected to know when their system hangs.
<ohsix> theres an ideal and controllable situation where ctrl-alt-del can work, and a hairy ugly failure scenario where alt-sysrq might be able to do something for you; it's really not the place for it
<virtuald> you know gnome pulls up the restart dialog when you press ctrl-alt-del and waits 60 seconds before rebooting, so if it's just a gpu hang you might have to wait for that
<ohsix> did the platters get eaten or did it seize? if not, what filesystem; theres so little you can do to prompt losing everything, and testdisk will save you from most of the simple mistakes (changing partition table)
<ohsix> i've only seen one gpu hang, and lots of compositor hangs; either way i could switch to another tty and shutdown normally
<virtuald> i don't think i can tell the difference
<ohsix> only time i've lost data was when some seagate spindles seized on some raid drives, and that sucked (same lot, and they failed within 24 hours of eachother, it was bizarre)
<Darxus> This is the full output from dmesg, when I booted to a rescue disk:
<Darxus> http://www.chaosreigns.com/500gb.2010-11-27.dmesg
<Darxus> The good stuff is toward the end:
<Darxus> [  184.352364] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
<ohsix> virtuald: well, xorg's log will have some info if it knows the gpu hanged, you can look in /proc/`pidof compositor`/wchan and see if a compositor has hung
<Darxus> fsck gave some kind of error after running for a while, asking if I wanted to ignore the fact that it couldn't read anything.
<ohsix> Darxus: ah you ran out of spare sectors
<ohsix> palimpsest can warn you about smart errors, the spare/reallocated sector count is one of the counters
<ohsix> how did 500gb turn into 2tb?
<Darxus> ohsix: It sounds like you should be able to recover some data from that?  That data, fortunately, I had backups of.  It was the other ~1.5tb that was all in one subdirectory that vanished that I didn't have backed up.  Got no errors on that one.
<ohsix> what filesystem?
<Darxus> The 500gb was ext3, the 2tb disk that lost a ~1.5tb directory was ext4.
<ohsix> was that before or after ext4 moved from experimental
<Darxus> It was within the last few days, running ubuntu maverick.
<ohsix> curious
<ohsix> do you still have the volume around?
<Darxus> No.
<virtuald> ohsix: saved, thank you :>
<ohsix> can't recover the stuff then :]
<Darxus> I rann extundelete on it and got nothing.  
<ohsix> virtuald: xorg detecting gpu hangs can miss a real lockup a bunch, you can look at /proc/`pidof X`/wchan and see if X itself is blocked in the driver & hung too
<ohsix> Darxus: any weird mount options? did you have an old fstab that didn't force data=ordered?
<virtuald> ok i'll do that next time
<ohsix> virtuald: the ubuntu (+kernel team) wiki has a bunch of info for troubleshooting stuff like that :]
<Darxus> ohsix: No weird mount options.
<virtuald> ohsix: i always forget about that when it happens
<ohsix> Darxus: there were some data loss things with ext4 and some settings that ubuntu used; i dunno how recently they changed it but it was recent
<Zdra> Morning :)
<Zdra> could someone please reopen that bug? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/662946
<ubot2> Launchpad bug 662946 in linux (Ubuntu Maverick) (and 2 other projects) "linux kernel 2.6.35 slows down the whole system because of kslowdxxx processes (affects: 35) (dups: 2) (heat: 196)" [Medium,Fix released]
<Zdra> no fix was ever released for that, dunno why someone reported he doesn't see the bug anymore, but that's a lie :)
<apw> Zdra, done ... if you are affected can you test the natty kernel which is meant to have the fix so we can progress the issue ?
<Zdra> apw, yep that's on my todo list, but can't promise when I'll be able to test it
<Zdra> apw, thanks :)
<apw> Zdra, good enough, as the bug is incomplete it will expire if noone tests
<apw> http://people.canonical.com/~platform/workitems/natty/u/stefan-bader-canonical-natty-alpha-2.html
<jjohansen> https://wiki.ubuntu.com/LucidReleaseSchedule
<ogra_ac_> apw, hrm
<apw> ogra_ac_, ?
<ogra_ac_> The following packages have unmet dependencies:
<ogra_ac_>  linux-headers-omap : Depends: linux-headers-2.6.35-22-omap but it is not installable
<ogra_ac_> can we do something about that (temporary at least ) for A1 ?
<apw> ogra_ac_, that issue must have been in there since the archive opened for natty
<ogra_ac_> it breaks omap4 builds (sillyness: all armel headers are installed by default on all armel images, we have only subarch matching for removing the unwanted ones at the end of the build)
<ogra_ac_> apw, it hasnt 
<ogra_ac_> its there since the 19th 
<ogra_ac_> not sure why
<apw> archive must have purged the headers at that time
<ogra_ac_> yeah
<ogra_ac_> something along these lines
<apw> some warning might have been nice
<ogra_ac_> also cooloney seem to have started testing linaro kernels on omap3
<apw> ogra_ac_, i asked him to as i wasn't seeing any other testing going on
<ogra_ac_> apw, GrueMaster_ is supposed to do some, but was traveling and on vacation last week
<ogra_ac_> expect some test results this week
<apw> ogra_ac_, i am unsure what i can do about this missing header right now
<apw> the package it was made form is gone
<ogra_ac_> cant you remove it temporary from the meta =
<ogra_ac_> ?
<apw> so its just cause its in meta you are finding it ?
<ogra_ac_> cooloney's comments smelled like linaro kernel wouldnt work so well
<ogra_ac_> meta still tries to pull in a non existing packge
<ogra_ac_> so i would expect that to go away if you drop that dep
<apw> ogra_ac_, so what package are you starting from to pull all these in
<ogra_ac_> headers should be enough to make omap4 build
<apw> as if i drop the package, you'll just have the old one
<apw> ogra_ac_, yeah in fact the meta package doesn't have omap and hasn't for any upload to natty
<ogra_ac_> weird
<ogra_ac_> where does linux-headers-omap come from then ?
<apw> ogra_ac_, how do you find it
<apw> as in how does the scripting find it
<ogra_ac_> it just installs the ubuntu-minimal and ubuntu-netbook tasks 
<ogra_ac_> must come from somewhere in there
<apw> probabally the installer then ?
<apw> no perhaps not
<apw> hrm
<apw> they must be holding the binaries live in the archive
<ogra_ac_> well, the issue is that linux-headers-omap exists 
<ogra_ac_> yeah
<apw> i don't think i have control over that
<ogra_ac_> yeah, i pinged in #ubuntu-devel
<ogra_ac_> theoretically it should be an NBS package
<ogra_ac_> if no source builds it
<apw> not sure it will fix you though as i suspec tthat the dep will just move up one level
<apw> so removing or not removing the package is unlikely to 
<apw> help any
<ogra_ac_> up one level ?
<ogra_ac_> that should be the highest one
<sosaited> Does anyone know if kernel 2.6.37-rc2 for maverick has i/o scheduling improvements over 26.35?
 * apw doesn't know of any specific ones, but has seen better overall balance due to the scheduler magic changes
<smb> But unlikely the magic autogroup patch
<tgardner> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/610597
<ubot2> Launchpad bug 610597 in linux (Ubuntu) "ecryptfs can orphan mounts after host file system is removed (affects: 1) (heat: 30)" [Medium,In progress]
<tgardner> apw, https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/344878
<ubot2> Launchpad bug 344878 in linux (Ubuntu) (and 2 other projects) "file name to long when creating new file (ecryptfs_lookup: lookup_one_len() returned [-36] on lower_dentry) (affects: 48) (dups: 5) (heat: 264)" [Undecided,In progress]
<diwic> smb, black art of in-comprehensive programming book? :-)
<smb> diwic, Definitively! :)
<diwic> smb, well, that's in the zone between quirking and coding
<diwic> smb, what is a DAC node should really be autodetected, but unfortunately, the HDA driver does not work that way, leaving us into quirking every time a new hw shows up
<smb> diwic, I tend to agree. Just looking at a patch that returns 0x25 instead of other numbers and increments an array by one at some other place is hard to put somewhere when looking at it.
<diwic> smb, yeah, without more context than diff -u shows, it doesn't say much really 
<smb> Right, especially the bigger array, as there is nothing in the patch itself that links this to the changed number.
<diwic> smb, so ALC887 has five DACs which does not fit in an array of four
<smb> diwic, Ok, and presumably 0x25 encodes the number of DACs 
<diwic> smb, 0x25 is the index of the fifth DAC node
<diwic> or if it was 0x26
<diwic> one is the mixer node, the other is the DAC node
<smb> diwic, You see my point of the black art book. ;-)
<diwic> smb, yeah, and all these things should be detected, because it is easily detectable
<smb> Just not enough people with enough time to completely rewrite the driver I guess
<diwic> smb, something like that, the hard part is to avoid regressions for broken, now quirked, hardware 
 * smb feel his head spinning
<apw> http://lkml.org/lkml/2010/11/26/329
<andreoli> hi, not sure if this has already been reported; I just downloaded latest Ubuntu kernel from git (the maverick repository) and the last changelog entry seems borked
<andreoli> it says UBUNTU: Ubuntu-2.6.32-23.40; shouldn't it be UBUNTU: Ubuntu-2.6.35-23.40?
<bjf__> andersk, correct
<apw> andreoli, yes it is textually borked in that version, the changelog is correct and later versions are sorted
<andreoli> ah ok
<andreoli> and does this break the debian/rules insertchanges script, anyway? I guess so 
<apw> tgardner, you have one patch which needs review in the ubuntu delta:   1. UBUNTU: Sony laptop: Some Sony Vaia laptops do not enable wwan power by default
<andreoli> can I enter debian/changelogs manually?
<apw> tgardner, wonder if you could cast an eye over it
<tgardner> apw, will do
<bjf> andreoli, yes you can, the script is just for convenience 
<andreoli> thx :-)
<smb> andreoli, if you want a similar layout: "git log <range of commits>|./debian/scripts/misc/git-ubuntu-log" produces it to stdout
<apw> andreoli, yes it breaks insertchanges, but i beleive the latest versions in -proposed is later anyhow isn't it ?
<albatros> Hi all
<apw> amitk, i think it was originally you who asked us to include arjan's patch for powertop.  where did you find those recomendations?  I want to make sure what we are carrying is still relevant
<albatros> I wondered what I can do to get a solution for bug 676644 into the distribution
<ubot2> Launchpad bug 676644 in linux (Ubuntu) "sata-via: read errors, slowdowns with VIA VT6420 (affects: 1) (heat: 469)" [Undecided,New] https://launchpad.net/bugs/676644
<apw> albatros, do you know of a fix for the issue ?
<andreoli> I am actually working on 0bc5a231f5ac5b6081d8f906917a31d9f3643af7 UBUNTU: Ubuntu-2.6.32-23.40
<albatros> I suppose a patch was proposed for the linux kernel https://patchwork.kernel.org/patch/323272/
<andreoli> thx I'll apply it
<albatros> Unfortunately I do not have a lot of experience patching ubuntu-kernels, and I do not have a lot of time, but if I could somehow help...
<apw> albatros, what release are you experienceing this on 
<albatros> 10.10
<albatros> 2.6.35-23-generic-pae #40-Ubuntu
 * apw sees if that patch will apply there
<apw> albatros, could you get an lspci -nnvv attached to the bug please
<albatros> no problem apw, just a minute
<albatros> apw: I have attached the output of lspci -nnvv to the bug
<apw> albatros, thanks
<smb> apw, Looks like some extension of a magic quirk I saw before. Not sure that is already upstream
<apw> smb, an updated version is in linus' tree
<smb> apw, Sounds reasonable then
<apw> albatros, it seems to apply ok, so i'll build you some test kernels
<smb> apw, At least I believe the first part has been on stable
<apw> smb, i expect the other will come that way to othen
<apw> but getting some testing on it is a good thing (tm), and if it passes I'll recommend it there too
<albatros> If I can be of any help testing a kernel, I'll be happy to
<smb> apw, Right, it may need some hinting if it is not already submitted with the cc
<apw> albatros, be about an hourh
<tgardner> apw, that patchworks fix appears to have morphed into b1353e4f40f6179ab26a3bb1b2e1fe29ffe534f5
<apw> tgardner, ack that is the one i cherry-picked
<albatros> Please forgive my ignorance, what are you talking about :P
<apw> albatros, the fix you mentioned from peterz was actually superceeded by a very similar fix from someone else
<apw> albatros, and so we want to test the one which ended up in linus' tree, the one which will be in the next release from him
<albatros> ok, thanks
<andreoli> thx guys, worked like a charm
<albatros> apw: just a question, if I want to test the patched kernel, where can I get it?
<apw> albatros, i'll let you know once it is uploaded, its doing that now
<apw> X crashing on me 4 times in an hour and making me restart the push has not helped the speed of upload, nor my mood
<albatros> OK great apw, will it be in the testing repository or somewhere else?
<apw> i'll shove a URL in the bug as soon as its up
<albatros> too bad apw, don't let it get to you ;)
<albatros> I wish you luck and thank you
<albatros> if the errors i reported disappear i will report it in the bugreport
<apw> albatros, let me know either way if you test it, in the bug
<albatros> yes of course
<apw> tgardner, other than the X issues i am seeing, this natty kernel +200line patch is magnificent
<tgardner> apw, you mean the galbraith SID patch?
<apw> tgardner, indeed, the behaviour of the machine under high disk load is so much better, and i don't really quite get how the patch helps that, but it does
<apw> no more grey windows, no more "getting coffee cause i ran git rebase"
<tgardner> apw, I think it round-robins cgroups, and all processes/threads within a SID are in one cgroup.
<apw> yep, but how that helps with disk use, i don't know
<apw> or are you saying we are getting disk round robin as well
<apw> anyhow, under load the machine is slow, not useless
<tgardner> apw, dunno why I/O is better.
<apw> albatros, ok directions in the bug
<amitk> apw: the patch recommendation was in the powertop git tree. git://gitorious.org/meego-developer-tools/powertop.git
<apw> amitk, thanks
<apw> cnd, hey ... 
<cnd> apw, hey
<apw> cnd, you have a blueprint, with no work items
<cnd> apw, yeah, I saw
<cnd> apw, it's not against the kernel, right?
<cnd> it's against the mt team?
<apw> its owned by you, so i see it
<apw> and you are mine :)
<cnd> heh
<cnd> for better or worse, the MT team hasn't gotten around to setting work items yet
<apw> well how useless is that, we are past feature definition so you cannot add any new ones
<apw> sconklin, i sub'd you to a bug about a disk issue, and cannot find it anymore, can you see it in your email
<sconklin> apw, I cleaned all those out and deleted them this morning
<sconklin> all my subscribed bugs
<sconklin> looking on launchpad
<sconklin> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/682652 this one?
<ubot2> Launchpad bug 682652 in linux (Ubuntu) "linux-image-2.6.32-25-generic-pae upgrade yields ata errors (affects: 1) (heat: 8)" [Undecided,New]
<apw> sconklin, yeah thats the one thanks
<apw> sconklin, so thats not the same as the issue i am poking at, a nice little regression-updates there for you :)
<sconklin> apw: yes, thanks
 * tgardner --> lunch
<jjohansen> apw, smb: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/671103
<ubot2> Launchpad bug 671103 in cloud-init (Ubuntu Lucid) (and 1 other project) "backport grub-legacy-ec2 from maverick to lucid (affects: 2) (heat: 20)" [High,Fix committed]
<apw> jjohansen, ?
<jjohansen> apw: this basically means we need to add lucid-ec2 to mavrick -virtual in the transition table
<apw> jjohansen, didn't i already add that one?
<smb> jjohansen, that means sru a transition for something out...
 * smb thinks its too late to think of that
<jjohansen> apw: I said we could ignore that one because you can't install kernels on lucid ec2
<apw> jjohansen, do you mean to the documentation ?  it is there already
<jjohansen> but it appears the plan is to fix that
<smb> But probably means to have it in place for the l to m update
<smb> I mean P
<jjohansen> apw: yeah
<apw> jjohansen, ok so you mean we might need a real transitional package
<apw> for maverick for that flavour 
<jjohansen> yep
<apw> ok thanks
<apw> jjohansen, actually think we need a bug for that
<jjohansen> apw: okay /me and smoser will take care of it
<apw> jjohansen, if you get me the bug number it is easy work
<smb> apw, To move them from linux-ec2 to linux. But I wonder whether that is applying to maverick...
<apw> to move them from linux-image-ec2 to linux-image-virtual
<smb> apw, yeah, ok 
<apw> yep, for maverick, as you cannot upgrade to natty direct, thats against the law
<smoser> it probably should apply to maverick
<smb> Just not sure that there has been any sru to a transitional package
<smoser> so its not that big of a deal
<smoser> heres why:
<apw> sconklin, you have a bunch of outstanding items for natty-alpha-1 and am wondering if they are going to make it
<smoser> ec2 images have -virtual and -ec2 kernels installed
<apw> smb, i suspect there never has, but i suspect it is demonstrably low risk
<smoser> upgrade from lucid -> maverick -> p* will get the -virtual updated and it will be newer than the -ec2 . legacy-grub-ec2 will select that kernel to boot
<sconklin> apw: looking
<smoser> if someone had purged the -virtual kernel, then they'd not get any updates
<apw> sconklin, note i have done half of 'document officially supported flavours on a per release basis and who is responsible for those (eg ti etc)' specifically the supported flavours bit (see Kernel/Dev/Flavours)
<smb> apw, No I don't think technically there is. I am usually rather surprised by the policy issues in those cases
<sconklin> apw: saw that
<apw> smb, indeed,
<lamont> Nov 29 11:05:52 rover3 kernel: [14054.882140] intel ips 0000:00:1f.6: MCP power or thermal limit exceeded <-- do I care about these?  (new laptop)
<jjohansen> smoser: hrmm, so no transitional package needed unless they have purged -virtual, I think I can live with that
<jjohansen> that is just not having a transitional package
<smoser> but i guess we might as well put a transitional package in place for natty
<apw> lamont, it would depend how often they are coming out
<smb> lamont, Sounds a bit scary. Though as the driver is new I am not sure whether how bad it is
<smoser> that would fix the lucid -> maverick -> natty -> orchid -> plain path
<apw> lamont, that implies either cpu or gpu was allowed to turbo for a little too long
<lamont> 5+ hours, 359 occurances in kern.log
<jjohansen> apw: not necessarilly other components could trip the thermal warning, if the laptop has poor cooling
<lamont> it's not doing any heavy crunching, so I'd expect it to be reasonably quiescent
<jjohansen> lamont: what type of disk?  7200+ laptop drives tend to run hotter and can trip up thermals
<lamont> the fan is nice and quiet, though. :(
<ogasawara> lamont: http://lkml.org/lkml/2010/8/26/471 - I think it's the driver just being overzealous with it's reporting
<lamont> 500GB sata drive
<apw> lamont, i am not sure i would expect it to be out of spec enough to fire the fans
<lamont> how does one find the rotational speed for a drive?
<apw> hdparm i think has it
<apw> sconklin, i am not sure you haven't done some of these, the documentation one for the process for instance
<sconklin> apw: is there a plce I can see all my tasks without drilling through the blueprints?
<apw> http://people.canonical.com/~platform/workitems/natty/canonical-kernel-team-natty-alpha-1.html
<apw> sconklin, ^^ is the natty ones ... search for your launchpad id
<apw> (twice)
<apw> sconklin	todo	hardware-kernel-n-stable-process-review	Essential	boiler plate text for bug closure on failure to verify
<apw> hardware-kernel-n-stable-process-review	Essential	provide a document that describes the process, bug tracking, and which tests are being performed, etc
<apw> hardware-kernel-n-stable-process-review	Essential	process to add the bug to the changelog manually during release process
<apw> hardware-kernel-n-version-and-flavours	Medium	document officially supported flavours on a per release basis and who is responsible for those (eg ti etc)
<apw> oh that worked _so_ well, thanks xchat
<sconklin> yeah found them
<apw> these are alll links from the Kernel BurnDown section
<apw> of https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Natty
<apw> sconklin, ^^
<lamont> ogasawara: interesting thread - thanks for the pointer
<sconklin> apw: well, the documentation is fairly complete and reflects the process as it stands now, but the item calls for "which tests" and that's being provided by cert and QA. I'm comfortable calling that complete if you are, as we're maintaining it in parallel with decision making
<apw> sconklin, works for me
<sconklin> I'll update that one
<sconklin> apw: we've already reverted fixes for failure to verify and updated the bugs, so you could argue that I
<sconklin> I've defined the boilerplate
<sconklin> although it's not recorded except in the bugs
<sconklin> I'm going to flag that Done also
<apw> i say copy that to a wiki page, and call it done
<sconklin> apw: I'll put it in a section on the previously linked wiki page
<apw> sounds good
<apw> albatros, did you test that kernel yet ?
 * smb ducks to avoid the whip cracking all around
<apw> smb, _you_ i can get to tommorrow
<smb> apw, that is what _you_ think :)
<apw> smb, don't delude me now, i might come after you _now_ otherwise
 * smb cannot hear apw
<jdstrand> apw: hi! I'm looking at bug #507148, but you gave maverick kernels for a bug in lucid
<ubot2> Launchpad bug 507148 in xserver-xorg-video-ati (Ubuntu Lucid) (and 4 other projects) "[lucid] desktop runs out of video memory on ATI Radeon Mobility 7500 (affects: 8) (heat: 46)" [High,Invalid] https://launchpad.net/bugs/507148
<albatros> apw: bug 676644 appears to have been fixed
<ubot2> Launchpad bug 676644 in linux (Ubuntu) "sata-via: read errors, slowdowns with VIA VT6420 (affects: 1) (heat: 6)" [High,In progress] https://launchpad.net/bugs/676644
<jdstrand> apw: in other words, mdeslaur and I reported the problem back in the lucid cycle, and I followed up on it a lot and it was fixed in lucid. was the regression on lucid or maverick?
<albatros> I have tested the interface/disk combination, I could not recreate it with the method that had never failed before
<albatros> (reading a few gigabytes at high speed)
<albatros> I will continue to watch it if it really does not reoccur
<jdstrand> apw: based on http://bugs.freedesktop.org/show_bug.cgi?id=26302#c27, it looks like a problem on the lucid kernel. would you mind making lucid kernels available for testing?
<ubot2> Freedesktop bug 26302 in Driver/Radeon "[M7 LW] desktop runs out of video memory on ATI Radeon Mobility 7500" [Major,Resolved: fixed]
<jdstrand> apw: acutally, it seems both lucid and maverick, but a lucid kernel would be most appreciated, and I could confirm whether or not reverting/going with upstream causes a regression on lucid release
<ogasawara> sconklin, bjf: I'm gonna push the 2.6.32.26+drm33.11 stable patch set (plus the 2 additional kvm patches ben mentioned to avoid a regression) to Lucid master-next.
<bjf> ogasawara, wfm
<sconklin> ogasawara: ack +1
<sconklin> apw: I've documented and flagged as DONE all the ones except the flavours item you started
<apw> sconklin, cool
 * jjohansen lunches
<sconklin> apw: your flavours page is NOT this one, correct? https://wiki.ubuntu.com/Kernel/Dev/TopicBranches
<ogasawara> is it me, or is the Karmic ec2 branch showing it hasn't been updated for 5 months?!  that doesn't seem right.
<smb-nx> Not sure. I had to push something...
<sconklin> ogasawara: fetching to look
<ogasawara> it looks like the latest tag was pushed (Ubuntu-2.6.31-307.21), but the branch doesn't seem to match
<smb> ogasawara, Yeah odd
<tgardner> ogasawara, checkout the tag, then push HEAD
<smb> I thought I had that before and had pushed it... Or was that Lucid
 * jdstrand uploaded 2.6.31-307.22/karmic and 2.6.32-310.21/lucid to the secppa a little while ago
<ogasawara> jdstrand: cool, I'll get out git repos to match then.
<jdstrand> ogasawara: they aren't published yet, so if things need to be fixed, we can still do it
<sconklin> ogasawara: what tgardner said
<ogasawara> jdstrand: just trying to get our git repo in order, nothing for you to worry about, proceed with the publishing.
<jdstrand> ogasawara: ack
<ogasawara> sconklin: I'm just gonna wait for the official publication and then fix it up.
<sconklin> that's fine
<smb> ogasawara, Yeah the fix is that. Just wondering what and where I pushed now...
<sconklin> It's all in there, just not on the branch
<smb> ogasawara, You can push to the last published tag
<smb> I mean check it out and push it over ec2
<ogasawara> smb: what you pushed to zinc looks good to me, it's just the official repo that looked off
<smb> ogasawara, Thats the thing. I thought I had pushed something to the official repo. (like it needs now)
<smb> Heck if I would know what
<ogasawara> heh
<smb> It was one of the ec2s
<ogasawara> probably lucid
<smb> Yeah, probably
 * ogasawara lunch
<smoser> smb, so did you want me to separate out the issues in 669496
<smoser> i dont think we ended up creating new ones for what was probably separate issues
 * smb-nx might remember if he knew what bug 669496 was again
<ubot2> Launchpad bug 669496 in linux (Ubuntu) "natty fails ec2 boot on i386 or t1.micro (affects: 1) (heat: 133)" [Critical,Confirmed] https://launchpad.net/bugs/669496
<smb-nx> Smoser
<smoser> nx ? nomachine ?
<smb-nx> Darn. No nexus one
<smb-nx> Meaning I am not really working
<smb-nx> John wanted to try something
<smoser> :) funny.
<smoser> thats fine. i just wanted to make sure you weren't expecting something from me
<smb-nx> smoser: no. Not really for the moment
#ubuntu-kernel 2010-11-30
<chrismsnz> hey guys - just dropping in to ask about a bug
<chrismsnz> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/586897
<ubot2> Launchpad bug 586897 in linux-2.6 (Debian) (and 2 other projects) "stex driver (Promise SuperTrak 8350/4650,etc) produces drastic I/O errors/corruption with 10.04 or later (affects: 3) (heat: 18)" [Unknown,Unknown]
<chrismsnz> there has been a fix committed to the kernel tree apparently - it's a fairly serious bug (as it's a fairly common card) and I'd just like to pass on the fact that it's fix now for possible backport to the lucid kernel and inclusion on new installation media for lucid(10.04.2) and natty
<JFo> chrismsnz, do you have a link to the discussion or a SHA1 I can use?
<chrismsnz> the kernel discussion?
<JFo> where they discussed the issue on the LKML
<chrismsnz> this was in linux-scsi: http://marc.info/?l=linux-scsi&m=129021716922966&w=2
<JFo> or a SHA1 of the fix as it exists in the kernel tree
<chrismsnz> i may have another one, stand by
<chrismsnz> here is lkml: http://www.linux-archive.org/device-mapper-development/459117-data-corruption-stex-promise-hw-raid-driver-device-mapper.html
<chrismsnz> ah, that actually looks like dm-devel D:
<JFo> chrismsnz, looks like that is still an ongoing discussion
<JFo> yeah
<JFo> from the rest of the thread, this is still being discussed
<chrismsnz> sorry JFo: here is the actuall diff: http://marc.info/?l=dm-devel&m=129070330506836&w=2
<JFo> k
<JFo> yeah, that is his proposed change
<JFo> the conversation looks like they are trying still to determine the best way to address the problem
<JFo> hmm
<JFo> wait a sec...
<JFo> nevermind
<JFo> I read the patch wrong
<JFo> :)
 * JFo is tired
 * jjohansen steps away for a bit
<JFo> chrismsnz, let me have a look at this tomorrow and I will see where it stands and talk to the team about its possible inclusion based on the current state
<chrismsnz> i can't see where it was committed :\
<chrismsnz> okidoki - feel free to drop in on/update the bug  there were a couple others watching it too
<JFo> yeah, the last message in the thread seems to indicate it is still in flux
<chrismsnz> when you have some answers, I mean :)
<JFo> http://marc.info/?t=129070303200002&r=1&w=2
<JFo> looking there ^
<JFo> ok
<JFo> will do
<firewave> Hi everybody !
<firewave> I've just received a new kernel update on my server
<firewave> Someone could tell me how to print the changelog in a terminal ?
<firewave> LOL... yeah ok.. aptitude changelog... I'm a bit a looser this night
<firewave> sorry
 * apw marvels at the funny white stuff falling from the sky
<smb> apw, Has it made its way to your place then? :)
 * smb waits for messages of chaos from the island
<apw> smb, yep, i expect we'll be closed before long
<jjohansen> snow again, but they just had some last year
<apw> at least fibre works under water
<apw> jjohansen, this is _settling_ thoug
<smb> apw, The bits could freeze
<apw> heheh
<smb> apw, And did you not have the settling last year too?
<apw> my bits could freeze
<apw> smb, yeah we did, but this is the very first we've seen and its settling
<smb> Ah you mean with an inserted "this year" ;9
<smb> :)
<smb> Though I try to remember when it was that I barely made it there in between strike and snow...
 * smb remembers walking in the snow in London and he usually does not remember that long
 * smb wonders whether cking can hear him through all that snow
<apw> smb, heh yea, /me goes out to see how deep it is
<smb> apw, Hope we see you again
<cking> 1 cm of snow here
<smb> cking, Wasn't it 1 inch a minute ago? :)
<cking> heh, my initial guess was inaccurate and based on defunct non-metric measurements
<smb> cking, Interesting question: do you think metric and convert or the other way round?
<cking> smb, I was educated in metric but I think in both imperial and metric and select the one that gives me best 1 unit measurements, e.g. if it's ~2.5cm, I call it an inch, if it's ~30cm I call it a foot,  but if it's ~3 foot I call it a meter
<RAOF> apw: I'm looking at the kernel delta assigned to me - the nouveau noaccel quirking patches.  We should drop those and see if anything breaks.
<smb> RAOF, He may still have some fun in the snow at the moment
<RAOF> Mmm, snow.
<smb> You know that strange pieces of fluffly frozen water
<RAOF> Not *all* of Australia is tropical or sub-tropical :P
<RAOF> We have such wonders in Tasmania, also.
<cking> smb, http://www.amd64.org/support/microcode.html
<smb> cking, ta
<smb> RAOF, Yeah, probably we always think of AUS as far far south. Must be hot there. :)
<RAOF> Heh.
 * smb looks around for apw
<apw> RAOF, heh, i was going to ask you abut those tosay
<apw> had to pop to pick something up, which took longer than i imagined
<apw> seems its is slippy slidey out there under foot
<smb> apw, We were about to send the rescue team. :-P
<apw> smb, thanks :)
<RAOF> :)
<apw> RAOF, ok those are gone from the next upload
<apw> RAOF, we also have this one: UBUNTU: SAUCE: i915 -- disable powersave by default
<apw> i seem to remember that one was to stop some odd screen quivering we were seeing
<RAOF> Yeah.
<apw> want to think about that one with your X buddies and make a recommendation on it?
<RAOF> Sarvatt knows more about that;  I'll ping him tomorrow.
<apw> RAOF, i have marked your task done for the ubuntu delta :)
<RAOF> Ta.
<smb> apw, Is there any way to get from the generic release status to the personal item summary? I fail to see it if there is
<apw> smb, there is not, i know of now way to get there.  i tend to use the personal _bit_ of the overall burndown myself
<apw> smb, http://people.canonical.com/~platform/workitems/natty/canonical-kernel-team.html
<apw> and scroll down to your name (the second occurance)
<smb> apw, Cool. Actually, couldn't we just add that link to the natty links?
<apw> we might be able to i guess
<smb> apw, I can do that if it is ok with you
<apw> smb, i am not sure there is an overall cycle personal version, which seems wrong
<smb> apw, Oh actually it is there
<apw> smb, hmmm where ?
<smb> Just called "overall burndown chart"
<smb> Under milestonded features
<smb> stoned
<apw> oh that link is there yes, but i pointed you tot 
<apw> to that one earlier ...
<smb> apw, Like a few minutes ago. :) But I could not even guess from the title that this is the team based list. And yes, you seem to have sent me a link to a personal burndown page as well which seems to be produced by the same stuff. now I just need to find how to get there
<apw> there are no links to the u/ prefixes as far as i know yet, i wonder why the names in the main pages do not go there
<apw> i may propose changing those links to that
<smb> Yeah, that would be more helpful than the launchpad blueprint assignment page
<smb> apw, One thing to improve imo would be to include the previous tasks at least in the overall page (which is naturally named ubuntu-11.04 instead of natty *grrr*)
<apw> ubuntu-11.04 is not overall, it is the stuff for the release milestone
<apw> stuff milestoned after the beta
<apw> there seems to be a missing global one under just your name which there in the other views
<apw> the u/ stuff is very new, and a little broken i think
<smb> Ah ok. 
<ogra_ac> apw, i guess you have seen cooloney's mail 
<cooloney> ogra_ac: i've talked with apw already, heh
<ogra_ac> (i dont expect any other outcome from our tests to be honest)
<ogra_ac> ah cool
<ogra_ac> i just want to know whats the way forward now that we have positive results
<cooloney> ogra_ac: i might need a xM machine for testing.
<apw> ogra_ac, indeed
<cooloney> ogra_ac: i just have a beagle c3
<apw> ogra_ac, i really have little idea of the scope of omap3, ie what boards you expect it to work on other than beagle
<ogra_ac> cooloney, i actually expect their kernel to run better on XM 
<apw> ogra_ac, to put it another way i am not sure what our acceptance criteria will be
<ogra_ac> apw, well, we can only put one bootloader into the images by default anyway
<ogra_ac> so i would expect beagle to be the default and for others we might provide u-boot binaries that you can easil exchange on the created SD card
<ogra_ac> apw, i would keep the supported set of boards as narrow as we can, everything you can do additionally through replacing bootloaders would be optional and unsupported (also untested) by us
<apw> ogra_ac, so it is fair to say that 'works on beagle satisfactorly' is the criteria
<ogra_ac> yes
<apw> ogra_ac, ok cool, is someone from your side going to try the swapping in of this kernle into the CD image and give it a test ?
<ogra_ac> there are requirements for IGEP2 boards, buit imho thats really up to linaro (i.e. if it works at release time its fine, i wouldnt do SRUs for them)
<ogra_ac> apw, as soon as we a) have images again and b) gruemaster has his setup ready 
<ogra_ac> i'll bring it up in the arm IRC meeting today
<apw> ogra_ac, excellent, did the meta shenaegens sort you out image wise
<ogra_ac> partially
<ogra_ac> there are other packages blocking atm
<ogra_ac> we have a bunch of dektop packages that depend on kde which currently doesnt build at all on arm 
<ogra_ac> s/depend/build depend/
<ogra_ac> we're sorting that remaining stuff this week
<apw> ogra_ac, thats a little annoying, i wonder why we'd want to install kde requiring apps by default on the gnome images
<apw> ogra_ac, but the kernel is out of your way
<ogra_ac> *build depend* ... we dont install any kde stuff
<ogra_ac> but i.e. transmission builds a kde client from the same source 
<apw> ogra_ac, ahh i see, now that does make sense
<ogra_ac> so it is ftbfs currently because kdelibs doesnt exist
<ogra_ac> i will unseed it from our image for A1
<ogra_ac> similar stuff happens to ubuntuone 
<apw> such is the life of an A1 CD
<ogra_ac> heh, yeah
<tseliot> apw: how can I get the source for this kernel? (the source package is empty): http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32.11-lucid/
<apw> tseliot, that is not easy, back there the source packages were broken, later we have included the patches so you can recreate it more easily
<apw> i may have the branch in the repository though
<apw> the master source for it would be v2.6.32.11 from the stable tree of course
<apw> tseliot, what do you need to use it for, so i can work out what the best way to help you is
<tseliot> apw: a friend of mine needs the sources for that vanilla kernel with the ubuntu packaging scripts
<apw> tseliot, ok i've pushed the patches that are on that branch into the result directory like the later versions
<apw> so he'd need v2.6.32.11 and then apply the 4 patches there
<tseliot> apw: what branch is that?
<apw> tseliot, ignore the branch, the builder leaves some mess arround for debugging which i looked at is all
<apw> i've pushed the delta to the results directory
<tseliot> apw: ah, ok, so he should get the vanilla kernel from upstream and apply those patches. Thanks
<apw> tseliot, yes that is exactly what the build system does, well it generates the patches but you get the idea
<tseliot> apw: I've learnt something new :)
<apw> tseliot, some of the older ones are missing the patches cause we thought the source packages were useful, but they arn't and actually the patches are simpler so we switched over relativly recently
<apw> if i have the build branches i can convert an old result, as i have for this one, but its not worth the effort unless someone whines
<tseliot> apw: yes, I agree
<rsalveti> apw: cooloney: ogra_ac: I have a beagle-xm and can test if everything works fine
<rsalveti> but it should, as it's already being used by linaro's image
<ogra_ac> rsalveti, that would be helpful
<cooloney> rsalveti: great, man
<ogra_ac> we need to know if jasper behaves etc
<rsalveti> if they are merging the ubuntu sauce on top of the tree, it should work basically the way we're expecting 
<ogra_ac> thats a part that cooloney cant test with rootstock images
<cooloney> rsalveti: yeah i think so.
<rsalveti> cooloney: did you change the config or used the default one?
<cooloney> rsalveti: it contains all the ubuntu delta sauce patches
<cooloney> rsalveti: i didn't change any code in there tree.
<cooloney> rsalveti: it just works
<rsalveti> ogra_ac: we can easily test with jasper at the moment we have any image around
<rsalveti> then we can just replace the important pieces and we're ok
<cooloney> rsalveti: you can build it from their source code.
<rsalveti> cooloney: cool
<rsalveti> cooloney: sure
<ogra_ac> rsalveti, there are images from the 19th
<rsalveti> cooloney: would be good to compare the config options with our omap3 debs
<ogra_ac> for jasper testing that should suffice
<ogra_ac> (i think X wont start on these though)
<rsalveti> ogra_ac: cool, if nothing that important changed since then, I think we're ok
<rsalveti> ok, np
<cooloney> rsalveti: yeah, will do it soon. 
<rsalveti> but it should work basically the same way, don't expect much of new features, but new bugs could be around :-)
<rsalveti> they merged most of our omap specific patches and ubuntu sauce
<rsalveti> ogra_ac: and for now let's just produce beagle compatible images, should be enough for most omap 3 boards around
<rsalveti> beagle and beagle xm should work with same kernel and boot loader
<rsalveti> then for igep we just build instructions, should be fine
<ogra_ac> yes
<ogra_ac> thats what i said above
<ogra_ac> with beagle being the QAed and officially supported platform 
<rsalveti> yeah
<ogra_ac> what we need to make sure is that john doesnt cut down the config 
<ogra_ac> (i know he planned to)
<rsalveti> otherwise we need our own config
<ogra_ac> i.e. we want all usb dvb drivers, all usb wlan drivers etc etc
<ogra_ac> everything you could potentially plug in
<Dabian> Darn, channel is logged?  Where is my privacy? :P
<Dabian> OK .. joke aside ...
<Dabian> I'm on Ubuntu GNU/Linux.  Today my updatemanager tells me to upgrade kernel for security reasons. CVE-2010-3848,  CVE-2010-3849 and  CVE-2010-3850 ... but these are only proposed .. and secret (reserved) .. anyone know about those?
<ubot2> Dabian: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3848)
<ubot2> Dabian: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3849)
<ubot2> Dabian: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3850)
<Dabian> ubot2: Thats what I am say'in, d'oh!
<ubot2> Dabian: Error: I am only a bot, please don't think I'm intelligent :)
<Dabian> I dont, lol. :)
<maco> better patched than vulnerable?
<Dabian> maco: Question is .. vunerable to what?
<Dabian> Usually I like to know what kinda patches I'm installing. :)
<maco> you could view the source
<maco> get the current and previous source packages off of launchpad and diff them
<Dabian> Can I apt-source a vunerable package?
<maco> or look at the git trees on kernel.ubuntu.com
<maco> apt-get source package=version
<Dabian> the latter looks more convenient, I guess git trees have diff?
<maco> yep
<Dabian> maco: Do you know where I find the main branch?
<maco> the one thats named ubuntu.maverick or ubuntu.lucid (whatever you're on) would be it
<Dabian> maverick is the perfect ten, right?
<maco> with no developers' names attached
<maco> yeah
<Dabian> There is no developer named "ubuntu"?
<maco> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=summary
<Dabian> right just found it
<Dabian> Leann is also mentioned as the last comitter.
<Dabian> hmm .. bad Leann .. using goto :P
<Dabian> :D
<Dabian> Hmm .. I dont understand why he doesn't make the check earlier in the code?
<maco> he who what?
<Dabian> Leann .. when he patch this.
<Dabian> He might have a good reason, I'm not expirienced kernel developer.
<maco> er..."leann" is a woman's name
<Dabian> In russia?
<maco> no, she's not russian
<Dabian> OH ..  cool, we have female kernel-devs now? B)
<maco> yeah...theyve existed for a long while...
<Dabian> Cool
<maco> im a lady with a patch in the kernel too :P
<Dabian> Neat :)
<Dabian> Ahh .. Mackenzie :)
<Dabian> I think I recognice your name from Ubuntu-Women? :)
<maco> yes
<maco> i imagine she checks it there in order to keep the check near the reason its needed... ie, the fact that saddr is about to show up on the right side of an =
<Dabian> Its been a while since I have been active there.  (As if I were ever active there, but I used to follow the mailing-list some)
<Dabian> maco: Yeah .. the code seems a bit bit complicated though .. I think I'll copy it to emacs to get a better view.
<Dabian> maco: Funni thing is ... there is already a check in the code for saddr.
<Dabian> Oh .. now I get it .. its legal to call this with saddr that is NULL. 
<Dabian> Thats probably why she doesn't check earlier.
<maco> the other time in that struct that saddr shows up to the right of a = is inside a if (saddr == NULL) {} else {  /* right here */ } -- so that one is checked
<maco> s/struct/function/ cant read
<maco> hm though line 506...
<Dabian> yeah
<maco> ogasawara: when you're around, is there a possibility of a null-pointer dereference down at line 506 on [ubuntu/ubuntu-maverick.git] / net / econet / af_econet.c like the one you fixed up above it?
<Dabian> maco: I fear you might be right, if CONFIG_ECONET_NATIVE is not defined, then Leanns check is never passed.
<Dabian> maco: (Otherwise we return in line 414)
<maco> her check takes place inside an if() anyway
<Dabian> Yeah .. if the that if is false, then CONFIG_ECONET_NATIVE wont be defined.
<Dabian> I am babling.
<apw> CONFIG_* comes from outside
<Dabian> Its the if that is deciding, you're right.
<maco> hmm? the define takes place elsewhere
<Dabian> But if the if is false, her check is skipped.
<maco> im referring to this:    if (dev->type == ARPHRD_ECONET)
<Dabian> maco: Exactly .. thats the culpit. :)
<maco> the null pointer dereference she catches is inside that if. there's another case of that pointer being used after the if ends. thats teh one im worried about
<Dabian> maco: just before the #if.
<Dabian> (Which is not significant here)
<Dabian> maco: Right.
<maco> i dont know where youre looking now...
<Dabian> maco: I just confused both of us, I agree with you. :)
<maco> hah ok
<maco> apw: down at line 506...is that one ok?
<maco> apw: or were you just interjecting about the macros without looking at what we are?
<Dabian> maco: He was just pointing out that I was babbling, I think. :)
<Dabian> ze :)
<maco> you got it right this time
<Dabian> lol
<apw> Dabian's statement was that the CONFIG_ would change based on an if, which doesn't sound right, not looked at the code no
<Dabian> I have no idea what ARPHRD is. :)
<maco> apw: oh ok. i think Dabian just mixed up #ifdef and #define
<Dabian> apw: You're right.  I confused the #if with the "if".
<maco> ah
<Dabian> Well, actualy I assumed that both if and #if would act the same, which is even worse, lol.
<Dabian> If the #if is false
<Dabian> ahh never mind.
<Dabian> maco: I think you found a problem, unless we know that if saddr == NULL then udpsock == NULL.
<maco> Dabian: the line im pointing to is not inside an if statement at all
<Dabian> maco .. no
<Dabian> maco but look at line 420
<Dabian> maco: I assume that line has to be passed before you reach line 506
<maco> ah because it returns
<Dabian> :)
<Dabian> But I am not sure we know that udpsock is NULL, if saddr is NULL.
<Dabian> I'm not a kernel developer.
<Dabian> I just find it interesting to look at the code sometimes. :)
<Dabian> maco: In any case, I would probably do something like:
<Dabian>         eb = (struct ec_cb *)&skb->cb;
<Dabian> 	if(saddr == NULL)
<Dabian> 	  kernel_panick("Line 506, af_econet - saddr == NULL");
<Dabian>  
<Dabian> before "eb->cookie = saddr->cookie;", just to be sure.
<Dabian> (Not sure of the syntax for kernel_panic).
<Dabian> maco: To me it looks like udpsock comes from outside the function, so I am guessing you found a real problem.
<Dabian> saddr, on the other hand, comes from "msg->msg_name" which is passed as argument to the function, in line 266.
<apw> sconklin, you might want to review this above conv as it may indicate a further issue with one of our CVEs
<Dabian> apw: Nice that ARM is better secured than other platforms for once though, right? :)
<smb> apw, ogasawara was driving those. But yes, all of those did touch econet
<smb> But no arm release was done
<apw> Dabian, heh yeah by mostly being unbootable on any actual h/w :)
<Dabian> lol
<smb> Dabian, The whole conversation is too big to quickly read. Is what you see on arm or something else?
<Dabian> smb: It was maco that pointed out that line ... (lemme check) might lead to null-pointer problem.
<maco> smb: line 506 on http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=blob;f=net/econet/af_econet.c;h=174c106ec95ac04a0c46a3cf8cf5d499bdfe390a;hb=00a70d00666bbe8e7035f582ac5674827e351870
<Dabian> Thanks :)
<maco> smb: further up at 357 ogasawara checked for null before dereferencing that saddr pointer. at 506 it's dereferenced again without a null check. the first null check took place inside an if though, so may not have been run when 506 is reached
<Dabian> (And 506 is apparently reached, unless udpsock is NULL).
<smb> maco, Sounds about right. I just need a minute to grab the changes to have the whole picture
<Dabian> (udpsock seems to be external)
<smb> I was just wondering about the arm statement
<maco> smb: i think Dabian is watching -meeting
<maco> and my brain refuses to keep the two smb's straight -_-
<smb> There is only one on my side. :)
<Dabian> smb: The first check, which is committed, only concerns platforms with ARM hardware, I guses, according to the "#IF".
<Dabian> What is -meeting?
<maco> different channel
<maco> Dabian: can you use line numbers?
<smb> Dabian, Ah, well arm was those topic branches not released (at least for Lucid, but there is Maverick with at least one arm inside the master)
<Dabian> Sure.
<Dabian> smb: But the problem maco points out, applies to all platforms, as far as I can tell.
<maco> there are 3 places saddr is used. 315, 362, 506
<maco> what makes you think any of them are arm-specific?
<Dabian> maco: Lemme find the line number.  I might be wrong though. :)
<Dabian> line 341: #ifdef CONFIG_ECONET_NATIVE
<Dabian>  
<Dabian> I think only ARM has native econet?
<maco> oh. no idea about that
<Dabian> I am just guessing.
<Dabian> maco: Line 506 is outside that "if" though.
<Dabian> (#if, even)
<maco> yes
<Dabian> So while Leanns fix maybe applies to ARM only, yours is general.
<Dabian> Its inside the line 417: #ifdef CONFIG_ECONET_AUNUDP
<Dabian>  
<smb> Actually I do not really see that line which does not check for NULL getting added. Rather seemed to be there before
<Dabian> smb: 506
<smb> But its a bit hard from the patch and a function that stretches on for miles
<maco> smb: yes it was thre before. she added a check for near line 357, and im worried that she should also have added one to 06
<maco> *506
<Dabian> smb: Yeah .. the code is pretty long, I wonder if the function could be refactored.
<smb> maco, Maybe. I am not that good to understand the flow that quickly. :)
<smb> Give me a minute
<apw> Dabian, not for a backported fix, minimum changes only
<Dabian> smb: Its actually not as hard as you think.  The problem is if the "if" at line 339 is false (dev->type != ARPHRD_ECONET), then code-flow skips Leanns check in line 358, and if udpsock != NULL (checked in line 420), the code will hit line 506, with a possible null-value in saddr.
<Dabian> (Assuming the "#ifdef"'s allow it).
<maco> its just a single C function thats got as many lines as my senior project did of python :P
<Dabian> apw: Right .. but maybe an idea for development branch. :)
<smb> So ok, yes, for that other case /#ifdef it seems missing
<smb> But has so before
<Dabian> smb: Which doesn't make it right, though. :)
<smb> Nope
<smb> The question is just whether it is in the class of security oh my god
<Dabian> I think maco found a new problem, of same natuer.
<smb> or just "normal" it crashes
<maco> smb: from leann's commit message on her change it seems like a normal-it-crashes with unknown security implications
<smb> maco, The thing is that all three were passed down as a bundle of sorts
<Dabian> 3 cve's though?
<smb> maco, You found a true other case of brokeness. I just would avoid a security update for it if possible
<maco> ok
<smb> Which would be required if we broke something new
<maco> so how to handle discovery of brokenness?
<Dabian> smb: When crashing and network is involved .. I'd say we're close to a security issue.  Question is if its remotely exploidable, I guses?
<smb> Dabian, Right. I would not be sure at the moment. 
<smb> On the other hand that econet protocol is not loaded by default and I don't know the use of it either.
<smb> maco, I'd probably go and contact the original author about it
<Dabian> smb: Then again, i guess even if its only locally exploitable, it will still be security issue, unless you need priviledges to call the function.
<smb> Err
<smb> Which was in this case Leann. 
<maco> heh
<smb> Guess she sent that somewhere. So maybe we ask her where
<sconklin> maco, smb: Just wandering in . . . econet is essentially unmaintained, so these patches were arrived at through a group effort
<smb> maco, sconklin Ijust checked Linus upstream.
<smb> Seems that what went there is different and exists early
<smb> Instead of checking for NULL multiple times
<Dabian> Heh .. that was my original idea, to exit early.
<Dabian> But I don't know what the code actually does.
<Dabian> It seems like its possible to do "something" useful, even if saddr is NULL, but I am not sure what.
<Dabian> smb: I guess that explains why the code missed the check later in the code.
<maco> i was guessing it was more to do with the spaghetti...
<smb> Dabian, I think (but I cannot say for sure) that we may have a patch that evolved later before hitting upstream
<Dabian> "a patch that evolved later, before hitting upstream"? (Im not native english, what does this mean?)
<smb> Dabian, It means it changed
<smb> And in Linus tree there is a different change that we have now
<Dabian> smb: As in .. you made a patch, but changed it before shipping it upstream?
<smb> As in we got the patch from someone (at least the other two) and maybe found the issue and told it the other person and on the way to upstream it changed even more but nobody told us
<smb> We just now see it in Linus tree
<Dabian> Ahh ok ... so .. you got Linus.A code .. patched it to Linus.Ap1 .. sending it upstream, when Linus.B code is available, the changes dosen't match the Linus.Ap1 code.
<Dabian> Hmm .. I guess this means we have to check the Linus.B code, to see if it checks correctly?
<Dabian> and if it does, then eventually adopt it?
<smb> As far as I see it is safer as it does the check right at the beginning of the function and immediately returns with an error if saddr is NULL
<smb> So mostly it is checking whether the other two patches are the same as we got or different/better and replace the changes made in our tree whenever needed
<Dabian> smb: Thats safe.  However, if something useful can be done, even if saddr is NULL, maybe Leanns patch is supior (with a check added for line 506)
<smb> Dabian, Maybe, though that sounds like something to discuss with those upstream people working with that as an additional patch. This one mainly targets to prevent an oops
<Dabian> smb: Right. I guess the code is viewable on http://kernel.org ?
<smb> Dabian, Yes. I saw it in the git tree
<Dabian> You don't happen to have the url handy?
<Dabian> Is the change in linux-next, mainline, snapshot or stable?
<smb> Dabian, I mainline. But as I use git I forget the url. A second
<Dabian> aah ok.
<smb> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git
<smb> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fa0e846494792e722d817b9d3d625a4ef4896c96
<smb> Dabian, the second link is the actual commit for that
<Dabian> smb: Right, they just exit if saddr is null, or msg->msg_namelen is short.  if msg or msg->namelen is NULL, they still have a problem though.  Not sure if thats possible. 
<Dabian> I also wonder why they set the mutex before the check.
<Dabian> Why not change line 291 to:
<apw> jdstrand, hiya
<Dabian> if (msg->msg_flags & ~(MSG_DONTWAIT|MSG_CMSG_COMPAT)) || (saddr == NULL || msg->msg_namelen < sizeof(struct sockaddr_ec))
<Dabian> that way they can skip line 300-303
<apw> they have likely gone for clarity over performance, as this is a dead protocol anyhow
<smb> Dabian, Just personal feeling but this does look a bit like more spagetti
<Dabian> change line 288 to: *      Check the flags and verify address.
<jdstrand> hey apw
<apw> was it you who was asking me something something last night?
<Dabian> smb: Well, you could add a line after 292, with a nice comment, and another if. That would look ugly to me, but personal taste differs, and it would be equally good. In both cases, you don't have to lock the mutex.
<Dabian> There might be a reason they lock the mutex first though, but I can't guess what it might be.
<Dabian> smb: At any rate, this GNU patch solves the problem maco spottet.
<smb> I guess the mutex is held for being able to make the changes on success. But right, it will fix that problem. And i am probably lazy there but I'd leave improvements to people actually using that protocol. :-P
<apw> jdstrand, was it you who was asking me something something last night?
<jdstrand> apw: I did. hold on...
<Dabian> I have no idea what the protocol is used for. :)
<jdstrand> 13:52 < jdstrand> apw: hi! I'm looking at bug #507148, but you gave maverick kernels for a bug in lucid
<ubot2> Launchpad bug 507148 in xserver-xorg-video-ati (Ubuntu Lucid) (and 4 other projects) "[lucid] desktop runs out of video memory on ATI Radeon Mobility 7500 (affects: 8) (heat: 46)" [High,Invalid] https://launchpad.net/bugs/507148
<jdstrand> 13:53 < jdstrand> apw: in other words, mdeslaur and I reported the problem back in the lucid cycle, and I followed up on it a lot and it was fixed in lucid. was the regression on lucid or maverick?
<jdstrand> 13:57 < jdstrand> apw: based on http://bugs.freedesktop.org/show_bug.cgi?id=26302#c27, it looks like a problem on the lucid kernel. would you mind making lucid kernels available for testing?
<jdstrand> 14:03 < jdstrand> apw: acutally, it seems both lucid and maverick, but a lucid kernel would be most appreciated, and I could confirm whether or not reverting/going with upstream causes a regression on lucid release
<ubot2> Freedesktop bug 26302 in Driver/Radeon "[M7 LW] desktop runs out of video memory on ATI Radeon Mobility 7500" [Major,Resolved: fixed]
<apw> jdstrand, ok the issue is that the fix as applied has been identified to cause a separate regression and therefore is bad.  in theory there is a 'proper' fix to your issue which should fix you and not introduce this additional regression...
<apw> jdstrand, ahh so you want a lucid kernel.  i'll see about that
 * jdstrand nods
<jdstrand> apw: I care most about not regressing the fix for my wife's laptop, and she runs lucid ;)
<apw> jdstrand, i care about finding out if the replacement fix works for you too :)
<jdstrand> apw: it would be most great if it was on the latest lucid-security kernel that went out yesterday
<apw> as it happens i am building lucid ones for that, so i'll get you a link once they appear
<jdstrand> apw: great, thanks
<apw> the utter slowness of launchpad is a major detrement to the ammount of work i can get done, sigh
<JFo> yep
<cking> +1
<sconklin> apw: I've thought about a browser plugin that will accumulate the time I spend waiting for launchpad page loads
<apw> i would be made very depressed by the results
<JFo> oh please no
<cking> sconklin, charge it to the LP team ;-)
<JFo> that would end up making me a part-time employee ;-P
<JFo> especially on Tuesday when I am gathering metrics for the meeting
<apw> JFo, didn't you already do this: tag bugs 605614, 608429, 612626 and other similar bugs and monitor for new
<ubot2> Launchpad bug 605614 in linux (Ubuntu Maverick) (and 3 other projects) "[ATI] GPU lockup with gfxpayload=keep (affects: 10) (heat: 50)" [Undecided,Won't fix] https://launchpad.net/bugs/605614
<ubot2> Launchpad bug 608429 in linux (Ubuntu) (and 1 other project) "black screen after grub menu (affects: 3) (heat: 32)" [Undecided,Incomplete] https://launchpad.net/bugs/608429
<ubot2> Launchpad bug 612626 in linux (Ubuntu) (and 1 other project) "start in low graphic mode for nvidia card (affects: 1) (heat: 30)" [Undecided,Incomplete] https://launchpad.net/bugs/612626
<apw> yeah thanks ubot2
<JFo> heh
<JFo> apw, I think those were the ones we needed to decide on a tag for
<JFo> so I have not tagged them as yet
<JFo> and I need to write something that will help me find any more 
<JFo> or any new ones
<apw> as i am calling the bug list you are making the 'key bugs' list, how about kernel-key-gfxpayload
<JFo> think that gfxpayload=keep was the search term used
<apw> and kernel-key for our purposes
<JFo> works for me
<JFo> so kernel-key are the bugs on our list?
<JFo> or just these bugs?
<apw> i was thinking kernel-key was our equivalent of pcert as an input to the lsit
<JFo> and we are eliminating the kernel-needs-review, kernel-candidate and kernel-reviewed tags?
<JFo> ok
<apw> JFo, i suspect we will but i have not though about those at all in this context
<JFo> since we are no longer doing the top 50
<JFo> ok
 * apw  notes that your list is now updating regularly ... goood stuf
<JFo> :)
<JFo> cron FTW!
<JFo> tgardner, any thoughts on bug 676245 ?
<ubot2> Launchpad bug 676245 in linux (Ubuntu) "Broadcom NetXtreme II BCM5709 -- no network found on ISO install (affects: 1) (heat: 6)" [High,Triaged] https://launchpad.net/bugs/676245
<JFo> the qa guys tell me that it worked on this box in the past
<JFo> this is for Alpha 1 testing
<tgardner> JFo, looking...
<JFo> sorry, found during rather
<JFo> thank you sir
<apw> jdstrand, ok test kernels are in the bug
<JFo> apw, any more thoughts on bug 670181 ?
<ubot2> Launchpad bug 670181 in linux (Ubuntu) "Dell Precision M6300 SD Card Reader (Ricoh R5C592 memory stick) Will Not Mount After Upgrade To 10.10 (affects: 2) (heat: 12)" [Medium,Triaged] https://launchpad.net/bugs/670181
<JFo> looks like the guy isn't even using an XD card
 * JFo grows old waiting for LP to churn
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<jdstrand> apw: thanks
<smoser> jjohansen, ping here.
<smoser> pv-on-hvm :-(
<jjohansen> yeah
<jjohansen> so if things verify out, it would be no pv-on-hvm in -virtual kernel
<smoser> you think that is not a solvable problem ?
<smoser> because that would basically force us to have separate cluster compute images (as they'll require pv-on-hvm)
<smoser> can we pv-on-hvm as a module ? or is that not possible ?
<jjohansen> it is already a module
<bjf> ##
<bjf> ## Kernel team meeting in 20 minutes
<bjf> ##
<smoser> jjohansen, it is ?
<smoser> i swear i saw 'Y' yesterday
<smoser> grep HVM /mnt/boot/config-2.6.37-5-virtual 
<smoser> CONFIG_XEN_PVHVM=y
<smoser> or is that really just an option to something else that is a module (i only looked at the config)
<JFo> sconklin, great find on that article
<sconklin> I imagine that it made some people frown
<JFo> I imagine so
<apw> o/
<apw> heh missed
<sconklin> http://www.techeye.net/software/nokias-meego-is-doomed
<sconklin> apw: ^^
<apw> sconklin, tgardner, smb, summary in your inbox
<smb> apw so it is
<JFo> <-lunch
<apw> sconklin, tgardner i have realised that when you hard push a branch it reports atomically where it was before in the return
<apw> so you can tell if you could have lost anything when you push ... obvious
<ogasawara> bjf, sconklin: have either of you started rebasing the master-next branches yet?  just want to make sure I don't duplicate effort here.
<apw> sconklin, another good reason for a master-merging or something, a marker that you are doing the rebase
<bjf> ogasawara, i've done a first pass on maverick, we are still discussing
<sconklin> apw: that may not be obvious or visible to people, since they may push without realizing that a new branch has been added
<bjf> apw, i'm not sure what you are suggesting at this point
<ogasawara> bjf: ack, I'll wait till you guys give me the green light.
<albatros> i just wanted to report that bug 676644 has been fixed indeed, have been running tests for about 20 hours now without any errors
<ubot2> Launchpad bug 676644 in linux (Ubuntu Maverick) (and 1 other project) "sata-via: read errors, slowdowns with VIA VT6420 (affects: 1) (heat: 6)" [High,In progress] https://launchpad.net/bugs/676644
<albatros> whereas previously these tests resulted in thousands of errors
<albatros> I just wondered if a fix for that issue in Maverick would be issued for lucid as well
<apw> albatros, indeed i have marked it released for natty
<apw> albatros, i was going to propose it for maverick, not sure about lucid
<apw> albatros, i have not tried to backport that far
<albatros> OK, not critical to me t all, thank you for working to fix things so quickly.
<albatros> I'll just switch to maverick then.
<albatros> bb
<apw> jjohansen, hello
<jjohansen> hey
<apw> jjohansen, this i386 not working thing that might be the pvops on hvm thing
<jjohansen> right
<apw> jjohansen, seem this is a blocker for server
<apw> jjohansen, have we confirmed this option is the issue ?
<tgardner> apw, jjohansen is OTP
<jjohansen> apw: no, I was testing last night, and I need to verify today
<jjohansen> I had one of my tests fail
<jjohansen> but I think that was my mistake
<apw> jjohansen, ok ... we need to make a call in the next hour ish whether to turn it off, as its blocking server for alpha1
<apw> so talk to me when you are done with the phone
<jjohansen> apw: I already talked to smoser about that, the answer is no
<jjohansen> leave it for alpha 1
<apw> jjohansen, so they are happy with the status quo ... i'll feed that back
<jjohansen> apw: I wouldn't say happy, but smoser doesn't want pv-on-hvm disabled either
<apw> jjohansen, yep got you ...
<apw> jjohansen, and thanks
<smoser> apw, well, i'm not happy that i386 and t1.micro do not work
<smoser> but turning off pv-on-hvm is not something i'm going to suggest should happen as it will cause other fallout that i dont want to deal with.
<apw> smoser, a bit of a mess and no mistake
<jjohansen> apw: the hope is that either my testing was bad, or we can work around it
<smoser> well, i dont thin its likely that the honorable jjohansen has bad testing, so i'm crossing fingers for work around
<smb> At least proving that this is the cause gives a better hint to where to search as the "no messages" before
<smoser> and alpha2 having cluster-compute instances (which require hvm) and t1.micro and i386 all from the same -virtual kernel
<apw> jjohansen, ok if we need to make any kernrel changes for alpha-1 it needs to be 'now' as we are already in freeze
<jjohansen> apw: yeah, no requests from me, we will get it fixed for alpha2
<alex88> after committing a change to natty kernel on http://kernel.ubuntu.com/git how much time it would be in the natty daily build?
<apw> alex88, normally withing 24 hours in the pre-proposed builds, a few days in the main archive
<alex88> apw, you've commited that change that i need :) the marvell driver.. btw, pre-proposed builds means those here: http://cdimage.ubuntu.com/daily-live/current/ ?
<alex88> sorry for asking..can you please reply? I have to go in ten minutes..
<apw> alex88, no i mean the ones in the pre-proposed PPA
<apw> we won't be putting that particular fix into a kernel on a CD until after alpha-1
<alex88> oh, and what about  the natty daily? i've tried to change the kernel into the live cd to let me install but i'm having problems with casper
<apw> alex88, its not easy indeed.  the natty daily CDs won't change until after the alpha releases now
<alex88> ok thank you very much..
 * tgardner --> lunch
<bjf> apw, what was that wiki formatting bug that you filed? (the bullet items were all the same level)
<apw> bjf, hrm
<apw> https://bugs.launchpad.net/ubuntu-website/+bug/675611
<ubot2> Launchpad bug 675611 in ubuntu-website "with new ubuntu theme all bullet items are rendered off the left of the pane and at the same indent regardless of list indent (affects: 2) (heat: 17)" [Undecided,Fix released]
<apw> bjf ^^
<bjf> apw, thanks
 * jjohansen -> lunch
<tgardner> apw, re: bug #681727, have you actually pushed patches to the list?
<ubot2> Launchpad bug 681727 in linux-meta (Ubuntu) "linux-backports-modules-wireless-maverick-generic not available for kernel 2.6.35-23 (affects: 2) (heat: 12)" [High,In progress] https://launchpad.net/bugs/681727
<apw> tgardner, in theory at least
<tgardner> apw, hmm, I can't remember them
<tgardner> nothing in patchworks either
<apw> i can't see them in my outbox either ... let me check
<apw> tgardner, i've pushed send again ... got t
<apw> got them now ?
<hallyn_> does anyone here know offhand whether aufs tries to mark fields with a particular poison (i.e. maybe 66010101)?
<apw> hallyn_, is that not 'list poison' ?
<apw> tgardner, too many interruptions it seems
<tgardner> apw, yeah, they are trickling in now
<tgardner> at least [0/2] so dar
<tgardner> far*
<apw> tgardner, dunno if i did it wrong or just didn't get to the actual pressing return ... perhaps it was when i clicked an lost my screen the first time
<tgardner> apw, np, I was just noticing some noise on the wireless mailing list about this bug
<apw> hallyn_, not list poison then ... /me lets grep search for him
<apw> tgardner, thanks for the kick up the ass
 * apw needs to be more methodical
<tgardner> apw, I think your second patch is wrong, you're futzing with alsa:
<tgardner> -Depends: ${misc:Depends}, linux-backports-modules-alsa-${kernel-abi-version}-generic-pae
<tgardner> +Depends: ${misc:Depends}, linux-backports-modules-compat-wireless-2.6.36-RELEASE_NAME-generic-pae (= ${binary:Version})
<apw> tgardner, crap
 * apw goes fix it
<apw> that happened cause i had to redo it following finger trouble
<JFo> ogasawara, got a sec?
<JFo> if not that is cool
<jdstrand> apw: fyi, followed on bug #507148
<ubot2> Launchpad bug 507148 in xserver-xorg-video-ati (Ubuntu Lucid) (and 4 other projects) "[lucid] desktop runs out of video memory on ATI Radeon Mobility 7500 (affects: 8) (heat: 46)" [High,Invalid] https://launchpad.net/bugs/507148
<jdstrand> err
<jdstrand> I followed up on that bug
<ogasawara> JFo: sure, just gimme 5min to finish up a rebase
<JFo> k
<hallyn_> apw: that's the thing, i've grepped for it with no luck, which seems weird :)  but ok, thanks, will keep looking
<apw> tgardner, V2 in the pipe ...
<tgardner> apw, ack
<robbiew> apw: regarding https://bugs.launchpad.net/ubuntu/+source/linux/+bug/669496, is it blocking the use of the i386 ISOs or just all the i386 ec2 instances
<ubot2> Launchpad bug 669496 in linux (Ubuntu Natty) (and 1 other project) "natty fails ec2 boot on i386 or t1.micro (affects: 1) (heat: 12)" [Critical,Confirmed]
<robbiew> from the title and the bug comments, I was assuming just ec2
<apw> i believe the latter, jjohansen ^^
<jjohansen> later just i386 instances on ec2, not uec
<robbiew> jjohansen: thnx
<robbiew> skaet_: ^^^^^ ;)
<skaet_> robbiew, jjohansen,  ack.  :)
 * robbiew returns Server threat level to Defcon 1
 * maco tries to remember whether defcon levels go up or down
<ohsix> can anyone explain the physical sector size discrepancy here: http://paste.ubuntu.com/538409/ ?
<ogasawara> JFo: sorry, taking longer than I expected and have to run to my dr apt.  can I ping ya when I get back in an hour or so?
<JFo> ogasawara, after thinking a bit more, I'll likely send you an e-mail for you to look at when it is convenient :)
<JFo> is that cool?
<ogasawara> JFo: cool, works for me
<JFo> good deal
 * ogasawara back in a bit
<bdmurray> apw: bug 511747 looks fixed to me is that right?
<ubot2> Launchpad bug 511747 in xf86-input-evtouch (Ubuntu Lucid) (and 3 other projects) "support for Acer 1420P (affects: 6) (heat: 40)" [Medium,Triaged] https://launchpad.net/bugs/511747
<jasonlife> I'm trying to upload my patched kernel to my ppa, and it seems uploading kernel to ppa is different than normal packages..  After I changed changelog and ran debuild -S -sa, I noticed .dsc and .diff.gz doesn't have the suffix I used during changelog update..  Anyone has an idea about uploading custom kernel to ppa?
<tgardner> skaet_, bug #676245 won't make it into A1 unless we re-upload the kernel.
<ubot2> Launchpad bug 676245 in linux (Ubuntu Natty) (and 1 other project) "Broadcom NetXtreme II BCM5709 -- no network found on ISO install (affects: 1) (heat: 6)" [High,Fix committed] https://launchpad.net/bugs/676245
<apw> bdmurray, yeah from the testing responces there it is fixed for linux (Ubuntu)
<apw> bdmurray, do feel free to make it Fix Released
<bdmurray> apw: and the evtouch parts?
<apw> bdmurray, that would have to be referred to cnd
<skaet_> tgardner, anything else in the kernel along with it?
<skaet_> s/it/bug 676245 fix/
<tgardner> skaet_, well, the rebase to -rc4
<ubot2> Launchpad bug 676245 in linux (Ubuntu Natty) (and 1 other project) "Broadcom NetXtreme II BCM5709 -- no network found on ISO install (affects: 1) (heat: 6)" [High,Fix committed] https://launchpad.net/bugs/676245
 * apw looks at skaet_ 
 * skaet_ is thinking of what can go wrong vs. getting it fixed...
<tgardner> skaet_, I've smoke tested -rc4 on a server, but thats about it
 * apw hasn't even boot tested it yet
<cnd> bdmurray, the Ubuntu utouch stack will not use xf86-input-evtouch
<cnd> I've never looked at it really
<cnd> so I don't have any more information for you
<tgardner> skaet_, the difference between whats in the archive and the next upload is _only_ a couple hundred patches.
 * apw wonders why bnx2 is so important
<tgardner> dell servers
<cnd> bdmurray, on a cursory glance, I think the bug should be marked as invalid for evtouch
<cnd> it's really an issue that has been fixed in the kernel
<apw> tgardner, and why indeed do the damn names of the files change every week; this must be the 3rd time this particular issue has appered
<skaet_> tgartner, _only_, huh.  
<tgardner> apw, firmware file names seem to be fungib;e
<apw> tgardner, are those ? in our module udeb thingy?
<tgardner> apw, nope, they are firmware file names need in the nic-modules d-i file.
<apw> tgardner, supprised the build doesn't fail when they change name in that case
<tgardner> apw, the names were'nt there in the first place. I had to add them so tha the bnx2 driver could load its firmware
<tgardner> from a udeb
<tgardner> skaet_, glp v2.6.37-rc3..v2.6.37-rc4|wc -l
<tgardner> 393
<apw> tgardner, hrm, didn't we have that issue in lucid too though, so am supprised they arn't there already
<skaet_> tgardner, thnx.
<apw> but ... never mind, an issue for anohter time
<tgardner> apw, I dropped them in the early natty rebase 'cause upstream had build errors wherein they didn't convert the firmware files correctly
<apw> tgardner, ahhh then it makes sense, /me forgets about it
<skaet_> tgardner, any way the fix can just be applied to the kernel that's already uploaded?
<tgardner> apw, I should have filed a bug so I didn't forget about it (as I clearly did)
<tgardner> skaet_, for you we'll do anything :)
<apw> tgardner, as everything is on master-next (right?) we could just slam master to the tag and cherry that one perhaps
<tgardner> apw, my thinking exactly
<apw> tgardner, you or me ?
<tgardner> apw, you're EOD, right?
<apw> tgardner, t'is pretty late yep
<tgardner> apw, I can take care of it. should only take a bit.
<apw> tgardner, ok ... i suspect its not an abi bumper so it should be low impact, but drop me a note if there are any time delay things to do
<skaet_> thanks tgardner, apw!  :)
<apw> skaet_, don't expect it for 7 hours or so!
<tgardner> apw, skaet_: I'll get it uploaded in the next hour or so.
<apw> (as it takes that long to build)
<skaet_> :)
 * skaet_ looking forward to seeing when it shows up now...  
<skaet_> please post in ubuntu-release when its ready ;)
<tgardner> skaet_, how about I post when its uploaded? I'll be in bed when its 'ready'
<skaet_> heh.  fair nuf.  just want a record there so cjwatson knows what's going on, when I'm in bed.  ;)
<apw> skaet_, i assume we are in freeze still, so it'll block on accept ?
<tgardner> apw, soft freeze still
<skaet_> apw soft freeze for alphas
<apw> ahh ok
<skaet_> it should get picked up by the autobuilder for tomorrows images if all goes well. 
 * tgardner is outta here
#ubuntu-kernel 2010-12-01
<jcrigby> anyone here know how to do binutils version specific (assembler actually) flags in kernel build?
<faranda> hi there...
<faranda> I have running a hardy (ubuntu 8.04) with kernel 2.6.36
<faranda> I have problem with apparmor
<faranda> I build a deb package from source apparmor-2.1+1075
<faranda> the problem is in the init script
<faranda> when I run init script, show me the message :    Loading AppArmor profiles - failed, Do you have the correct privileges?:
<faranda> when I run apparmor_status, show me the message :    apparmor module is loaded.  You do not have enough privilege to read the profile set.
<faranda> in kernel 2.6.36, apparmor is not a module
<cactaur> Hi everyone. When upgrading to Maverick, I had a problem with the kernel not being able to find the root filesystem. When I filed a bug on launchpad, one of the triagers told me to test the mainline kernels to see if it's still an issue. I've been following the instructions on the Kernel/MainlineBuild wiki page, but when I try to install the linux-image package, it fails because it  says it can't create initrd. I was wondering if someone coul
<vish> apw: hi, i tested your kernel for Bug #652934 , and it works fine.. no problems
<ubot2> Launchpad bug 652934 in linux (Ubuntu) "[RV515] Guest session causes screen to flicker violently and session is unusable (affects: 2) (heat: 16)" [Medium,Confirmed] https://launchpad.net/bugs/652934
<vish> apw: and thanks..  :)
<tgardner> apw, all is good? or did I manage to wreck the repo for you last night?
<apw> tgardner, you managed to lose a couple of things somehow but they are back now
<apw> tgardner, the version built ok and is being consumed ok
<tgardner> apw, hmm, I was worried about that, but couldn't actually spot them. what did I lose?
<apw> a couple of changes i had made to commentary to categorise patches, nothing i couldn't recover from my local master
<apw> (stuff to make the next fold down easier)
<tgardner> apw, so, they were on master but not on master-next?
<apw> tgardner, that is possible.  i wouldn't worry about it am going to change where i do things to prevent this occuring again
<tgardner> apw, ack
<komputes> JFo: ping
<komputes> JFo: Can you let me know if any other info is needed to triage https://bugs.launchpad.net/ubuntu/+source/linux/+bug/596080
<ubot2> Launchpad bug 596080 in linux (Ubuntu) "dell latitude e6510 screen stays black from suspend (affects: 15) (heat: 80)" [Undecided,Incomplete]
<komputes> JFo: we found a workaround boot parameter, any chance of making it work out of the box when when this hardware is detected?
<ogasawara> bjf, sconklin: either of you started in on the Hardy rebase?  If not, I'll start it.
<sconklin> ogasawara: no
<sconklin> not me
<bjf> ogasawara, i've not, was about to package up maverick
<ogasawara> bjf, sconklin: cool, I'll start hardy then.
<ogasawara> sconklin: want me to also get lucid and karmic packaged up?
<sconklin> ogasawara: sure, why would I turn that down?
<ogasawara> heh
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - December-07 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<tgardner> apw, bug #683775
<ubot2> Launchpad bug 683775 in linux (Ubuntu) "Natty Alpha 1, i915 has blank screen after boot (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/683775
<ogasawara> JFo: did you still need to chat with me?  /me never saw an email.
<JFo> I think my question was a bit premature ogasawara. I am still reading the source on the KernelBugList script before I ask you anything about it :)
<JFo> so I didn't send the email
<ogasawara> JFo: ok cool
<JFo> until I can better phrase it :)
<ogasawara> JFo: I have to admit that script is quite a hack so might be hard to follow
<JFo> heh
<JFo> well, combine that then with my limited python knowledge and you can understand my delay :-D
 * JFo is learning though
<ogasawara> JFo: I could probably try to add some comments to it which might help
<ogasawara> JFo: just point me to the copy you are using
<JFo> nah, this is actually forcing me to learn the way ythings work
<ogasawara> JFo: ok
<JFo> which I think is better for me
<JFo> :)
<JFo> don't worry about it
<JFo> I am getting it 
<ogasawara> bjf: I like that checklist.  we do need to throw it into a wiki or something...
<bjf> ogasawara, i'd really like it to be a web form page with a storage backend (me *HATE* wiki)
<JFo> <-lunch
<JFo> brb
<bjf> ogasawara, you know, someone that is going to take 3 months off with nothing better to do could probably do that in her spare time :-)
<ogasawara> heh
<ogasawara> bjf, sconklin: hardy test builds are underway, am going to start on Dapper in the mean time.
<bjf> ogasawara, cool!
<sconklin> yay
<tgardner> apw, do you still have the Ubuntu-2.6.37-6.17 tag in your tree? It does not appear to be in the repo.
<apw> tgardner, will check
<tgardner> apw, am also thinking the regression is because of the built-in AGP
<apw> tgardner, ok i've pushed
<apw> tgardner, could be
<apw> tgardner, but why does your machine fail and my idneticle one work
<apw> with the same kernel bits
<tgardner> apw, I'm spinning a kernel without CONFIG_AGP=y
<tgardner> apw, um, dunno. but I _do_ think its a race condition.
<apw> tgardner, ok have to move locations ...
<tgardner> apw, you headed home?
<apw> tgardner, let me know how the AGP thing works out
<apw> tgardner, am going out for dinner with the guys here then home
<apw> will check in when i get there
<tgardner> apw, I'll update the bug report
<tgardner> shall I subscribe you?
<apw> please do subscribe me
<apw> tgardner, will scratch my mini to try and reproduce what you have from todays dailies too
<tgardner> apw, done
<apw> jjohansen, get that one reported too, gpu hangs rock
<jjohansen> apw: will do
<JFo> bjf, these examples in the lpltk are great... thanks :-)
<JFo> <- finally had a chance to look at them
<bjf> JFo, cool, my plan is, if i have to explain something to someone, i'm going to explain it in an example
<JFo> definitely works for me
<JFo> I can apply these immediately in my new scripts
<JFo> bjf I just remembered a question I had wanted to ask a while back. Why do we skip processing of regression- bugs in the new-process -new script?
<JFo> you may have told me, but I forgot
<JFo> :-/
<bjf> JFo, don't know
<JFo> oh
<JFo> :)
<JFo> heh
<JFo> ok
<bjf> JFo, that script is full of rules that i don't understand why they are the way they are
<bjf> JFo, remember it predates me
<JFo> right
<JFo> I couldn't remember if that was something we consciously added or not
 * JFo is writing up some items for us to chat about concerning the arsenal scripts.
<JFo> not stuff that you have to do
<bjf> JFo, not that i remember now, though maybe at the time we/i had a reason to do so
<JFo> just things I wanted you and I to talk about before too long
<JFo> heh
<JFo> no problem
 * JFo isn't worried about it
<alex88> hi.. natty live cd in synaptic says that has kernel 2.6.37-5.14 but i've downloaded source and after compiling it says 2.6.37-rc2.. modules will work on livecd kernel?
<tgardner> alex88, cat /proc/version_signature
<alex88> on live cd?
<tgardner> yep, after booting
<alex88> oh.. i don't have it running.. i'm compiling kernel.. i'll try in few secs...
<GrueMaster> apw: I have done some preliminary testing of linux-linaro-omap on my beagleXM and have not seen any major issues.  System boots as normal, no crashes, and no changes in support from what I can see so far.
 * tgardner --> lunch
 * cking --> calling it a day
<JFo> enjoy cking 
<cking> I always enjoy :-)
<JFo> :-D
<alex88> btw, the alpha1 that's near will be rc4?
<alex88> *2.6.37-rc4
<pgraner> JFo, how are we standing on bugs with patches?
<JFo> pgraner, so far I am working out how to handle them appropriately on a case by case basis so that I can document the process (more for me than anything else)
<JFo> I am going through them this week to weed out the ones incorrectly set as having a patch
<JFo> and removing them
<JFo> plus I was just drafting an e-mail for apw with a list of questions that should help the majority of the process
<JFo> I suspect it will take a bit to answer as it involves manipulating the patches themselves
<JFo> magical runes and all
<JFo> I'll CC you on it
<pgraner> JFo, ok, I suspect most are not worthwhile or obsolete at this point. ATM I'm not so much concerned with process as clearing them out, perhaps giving each team member some that they can churn out would get you there faster. Then work out process with a new fresh patch when they start coming in?
<JFo> I agree.
<JFo> ok. I can do that then
<pgraner> JFo, ack
<alex88> tgardner: /proc/version_signature is correct 2.6.37-rc2.. why inserting module from that kernel source gives "disagrees about version of symbol module_layout" ?
<alex88> need to use the same source and running kernel??
<JFo> bjf, what tag are you guys using on your SRU bugs? I want to get them on the list
 * JFo has a moment of clarity and looks on the Tagging page
<bjf> JFo, i just (yesterday) started using "kernel-tracking-bug" and there's one more ...
<JFo> ok
<bjf> JFo, also "stable-reverted-<release>" and "stable-reapply-<release>"
<JFo> ok
<JFo> do you just want the ones from natty on the list for those or whatever is tagged?
<tgardner> alex88, it should say something like 'Ubuntu 2.6.37-7.19-generic'. any modules you're trying to load must have been built against the kernel you have booted.
<JFo> bjf, that was a dumb question
<JFo> let me rephrase
<JFo> will there be a time that there are any of those last two on versions earlier than Maverick?
<JFo> I see 6 reverted for maverick now
<bjf> JFo, Lucid
<JFo> ok
<JFo> so only lucid and maverick for now
<JFo> cool
<alex88> tgardner: it's 2.6.37-5.14 and 2.6.37-rc2.. I've compiled kernel when running maverick kernel, so older, rebuild filesystem.squashfs with included the recompiled modules but it seem that has the old one.. how can i do a think like this? Should i recompile with 2.6.37-rc2 running?
<tgardner> alex88, what is it you're trying to do?
<alex88> tgardner: i have to replace ahci module with recompiled one to add support to my hdd controller and use it
<tgardner> alex88, you're gonna be better off rebuilding the whole kernel after updating the module source.
<alex88> i've extracted the squashfs, and replaced /lib/modules/2.6.37-5-generic/kernel/drivers/ata/ahci.ko with my own
<alex88> i've tried to follow the guide on ubuntu doc but i had errors in initrd.. Btw, i have the whole kernel compiled and debs.. what should i do?
<tgardner> external modules have to be built against the kernel headers using exactly the same version of gcc and binutils
<alex88> oh... otherwise i'll get that error right?
<tgardner> right, your modules won't load
<alex88> but, i've replaced the ahci.ko, why is it loading correctly (but it seems not patched)? and he can't insmod the same file?
<tgardner> I haven't the faintest idea
<alex88> ok :) thanks for helping
 * jjohansen lunch
<JFo> bbiab
<apw> jjohansen, did rtg let you know how his testing went?
<jjohansen> apw: he said the -6 worked for him and he was going to try head with a patch, but I didn't here anything after that
<apw> jjohansen, thanks ;)
<jjohansen> apw: mine is very much a different issue, it seems it almost always a gpu hang being reported
<vish> apw: hi.. did you notice the comment regarding RV515 flickering with the kernel you had prepared?  is there anything else that needs to be done for the bug?
<vish> apw: err, rather the flickering is /fixed/ with your kernel..
<apw> vish that is good information but unless we can square the circle with the original bug and fix that too we are in a hole
<chrismsnz> JFo: Looks like martin peterson has started commiting code for that bug - including backports
<chrismsnz> (the stex scsi corruption bug)
<chrismsnz> i can see it in his working copies: http://git.kernel.org/?p=linux/kernel/git/mkp/linux-2.6-mkp.git;a=summary - see for-stable-2.6.3x.y heads
<JFo> chrismsnz, excellent! :)
<chrismsnz> I've updated the bug with the patches if you want to check it out
<chrismsnz> https://bugs.launchpad.net/linux/+bug/586897
<ubot2> Launchpad bug 586897 in linux-2.6 (Debian) (and 2 other projects) "stex driver (Promise SuperTrak 8350/4650,etc) produces drastic I/O errors/corruption with 10.04 or later (affects: 3) (heat: 18)" [Unknown,Confirmed]
<chrismsnz> unfortunately I can't test it anymore, we put the server into production running 9.10 :-O
<JFo> :-(
#ubuntu-kernel 2010-12-02
<jewsucanuse> ogasawara, will ndiswrapper (with the 2 patches it needs) be included in the alpha 1 kernel or are the bkl calls to prohibitive?
<ogasawara> jewsucanuse: not sure, have been tracking ndiswrapper for natty very closely
<jewsucanuse> there are patches that allow clean compilation on 2.6.37, but there were concerns about how ioctl was being used.
<ogasawara> s/have been/haven't been/
<apw> bug #600453
<ubot2> Launchpad bug 600453 in linux (openSUSE) (and 3 other projects) "[arrandale] [i915] DELL E6510: blank screen on boot (Intel GPU) (affects: 31) (dups: 1) (heat: 206)" [Medium,Confirmed] https://launchpad.net/bugs/600453
<JFo> morning apw
<apw> JFo, morning
<vish> apw: hi, so what should i ask on the older bug, that they test your kernel and check if there are no problems?
<apw> vish i have done so, and not had time today to see if they have taken notice yet
<vish> cool!
 * vish checks as well..
<vish> apw: they dont seem to mention any problems with the kernel [old in Bug #507148 ], but i get those messages as well.. and have not found any noticeable side-effects due to those messages..
<ubot2> Launchpad bug 507148 in xserver-xorg-video-ati (Ubuntu Lucid) (and 4 other projects) "[lucid] desktop runs out of video memory on ATI Radeon Mobility 7500 (affects: 8) (heat: 60)" [High,Invalid] https://launchpad.net/bugs/507148
<apw> vish tnakns
<avinashhm> vinashhm> hi, is any one familiar with lockdep asserting bugs .. I am stuck with a deadlock bug ..i wanted to know if a single task can hold multiple mutexes ???.. error @  @ http://paste.ubuntu.com/539017/ ... any help ???
<apw> avinashhm, yes a process can hold any number of mutexes, obviously if you hold more than one you had really really better know what you are doing, ordering is key
<avinashhm> apw, i am making sure it is in proper order .. last acquired first released .. but still i am having this lockdep error, of "recursive locking" .. i made sure with prints that i amn't acquiring same mutext without releasing .. but still it is cribbing ... :-(
<apw> it seems likely lockdep is right, and its saying you have a lock you are re-taking
<apw> that sort of thing is common when you have the lock but interrupts are enabled and the interrupt handler takes the lock too on the same cpu
<avinashhm> apw, but with prints above here are prints just b4 my mutex_lock and mutex_unlock api's .. so i amn't relocking a mutex which is already locked ... [ end number is the address of the mutext ] ... so i amn't re-taking.. 
<avinashhm> so you mean here .. two processes are holding that lock .. one mine and the other interrupt handler ??
<apw> the protections are based on a cpu
<avinashhm> apw, so what i can do to improve or get unlocked from here ??
<avinashhm> apw, so how is it usually interrupts are disabled when we have the lock ?? please pardon me if my questions are childish .. but i amn't familiar with these ...first bug of this type :-)
<apw> avinashhm, no interrupt handling is manual and separate
<avinashhm> apw, so how are these type of problems solved usually ?? 
<apw> avinashhm, debugging as you have indicated in combination with the lockdep output and reading the code
<apw> its a very hard problem
<avinashhm> apw, to be frank i still didn't understand the problem , is there any place i can look for to understand this lockdep description??? 
<avinashhm> actually the problem is easily reproducible , during bootup .. need to trace ..
<avinashhm> apw, seems like i am too tired of this problem from morning .. i ll debug further and see you tomorrow ..thanks for the help buddy ... 
<JFo> skaet_, do you have bugs for me? :)
<skaet_> have you gone through the ones from the status last week.  :)
<skaet_> other than that,  I won't be taking a pass through the bugs until after alpha 1 goes out today.   Some last minute issues are going to keep me busy today.
<JFo> smb, bug 684304 looks like it may be of interest to you
<ubot2> Launchpad bug 684304 in linux (Ubuntu) "cciss module does not identify resources (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/684304
<JFo> hggdh just pinged me about it
<JFo> failing install so it seems
<smb> JFo, Hm. Yeah, sounds like it needs to interest me. 
<JFo> well, I shall return. I am off to lunch then to a (hopefully warm) coffee shop
<JFo> smb, :)
<JFo> bbiab
<tgardner> sconklin, any interesting status from the SRU test review meeting?
<smb> tgardner, Wasn't there a bug report or some issue with Broadcom NetXtreme of some sort recently?
<apw> tgardner, ok ... this is confirmed a grub graphics mode handoff issue 
<tgardner> apw, is there a known fix yet?
<apw> tgardner, there is a work around, turnign off graphics handoff.  am working on whats wrong now
<apw> i think its an unhandled pipe underrun, but am trying to confirm that
<tgardner> apw, I would have thought removing splash would have corrected it
<apw> tgardner, nope doesn't change how grub hands off the screen
<ogasawara> bjf, sconklin: lucid fsl-imx51 rebased and pushed to my repo for review - git://kernel.ubuntu.com/ogasawara/ubuntu-lucid.git fsl-imx51
<bjf> ogasawara, cool, will look at it in a bit, not to worried about it though
<ogasawara> bjf, sconklin: assuming that looks good, package for review/signing is on zinc in my home dir under proposed-pkgs/lucid/linux-fsl-imx51_2.6.31-608.21_source.changes
<sconklin> ogasawara: both on a call, be with you in a sec
<JFo> skaet_, I am assuming that, due to the alpha 1 release, that there will be no new bugs on the release team radar for kernel. :)
<JFo> for this week, I mean
<skaet_> JFo, don't make assumptions...  ;)   all sorts of interesting results coming up from the alpha.  ;)
<JFo> :-/
 * JFo was only assuming for one day ;-)
<tgardner> skaet_, "interesting" == bad ?
<skaet_> weather I'll be able to summarize or not by the end of the day, is a different matter.
<skaet_> whether, even.
<JFo> heh, ok
<ogra_ac> skaet_, how about we auto-assign them all to JFo then his assumption is true for the rest of us ;)
<skaet_> ogra_ac, lol
<JFo> ogra_ac, :-P
 * JFo closes bugs with extreme prejudice ;)
<ogra_ac> no, with scripts 
<ogra_ac> mind you, i have seen them ;)
<skaet_> tgardner, not sure yet...
<JFo> ogra_ac, :-D
 * ogasawara lunch
 * jjohansen lunch
<manjo> tgardner, Checksum doesn't match for /home/manjo/linux_2.6.35-24.42.dsc
<manjo> tgardner, I did a remote debsign 
<manjo> and dput tells me checksum does not match
<manjo> tgardner, I signed the .changes and .dsc file 
<tgardner> manjo, you only need to sign the changes file, e.g., 'debsign -r tangerine.buildd:*.changes'
<manjo> tgardner, ack ... when I signed .changes I get No signature on /home/manjo/linux_2.6.35-24.42.dsc. so I signed the .dsc as well
<tgardner> how are you packaging? Use the '-us -uc' options so that 'dpkg-buildpackage -S' doen't complain.
<manjo> tgardner, I did dpkg-buildpackage -S -sa  -rfakeroot -I.git -I.gitignore -i'\.git.*'
<tgardner> so, whats changed? You've done this before.
<bjf> sconklin, we've had a lucid linux-mvl-dove in -proposed for a while now, any idea what the plans are w.r.t it? I have a rebased lucid linux-mvl-dove locked and loaded
<sconklin> bjf: I have no idea - I thought that Ike or Eric or someone else was going to handle those
<bjf> sconklin, i went ahead and handled it, all our branches should be very up-to-date at this point (ogasawara did fsl-imx51 earlier)
<sconklin> bjf: great! You and ogasawara have blown this release out (in a good way)
<bjf> sconklin, now i've got an upload and nowhere to go :-)
<manjo> tgardner, VirtFS is a 9P based passthrough filesystem for virtualized guests.
<tgardner> manjo, incidentally, I remembered that you should be using 'dput -u' when remote signing and uploading from a machine that doesn't have your GPG key
<manjo> tgardner, lp dos not allow me to use -u, -u I think says ignore signature  
<lifeless> a friend of mine is seeing this: "Suggestion: Enable the CONFIG_PM_ADVANCED_DEBUG kernel configuration option. This option will allow PowerTOP to collect runtime power management statistics."
<lifeless> from powertop
<RAOF> There's an open bug for that, let me hunt it.
<RAOF> lifeless: bug #632327
<lifeless> RAOF: thanks
<AfC> powertop just told me "Suggestion: Enable the CONFIG_PM_ADVANCED_DEBUG kernel configuration option. This option will allow PowerTOP to collect runtime power management statistics."
<ubot2> Launchpad bug 632327 in linux (Ubuntu) "Powertop suggests CONFIG_PM_ADVANCED_DEBUG kernel option (affects: 18) (heat: 123)" [Wishlist,Triaged] https://launchpad.net/bugs/632327
<AfC> which is a new one on me.
<AfC> ah, you're already on it
<AfC> (was a new on on me. Thanks Robert, Christopher)
<joshhunt> not sure if this is the correct forum, but i've got a question about initrd packaging. does ubuntu put the firmware for bnx2 driver in the initrd or do you wait until root is mounted?
#ubuntu-kernel 2010-12-03
<skaet_> JFo, around?
<kaushal> hi
<kaushal> I installed linux-image-server on 10.10 how do i make it default kernel ?
<LetoThe2nd> kaushal: change the grub defaults. but i guess you would better ask in the generic support channel, as this one is meant for kernel development.
<LetoThe2nd> kaushal: #ubuntu, or #ubuntu-{your language tag}, like #ubuntu-fr - for example.
<kaushal> Thanks LetoThe2nd 
<apw> joshhunt, i think firmware is normally in there
<apw> kaushal, normally the latest kernel installed is the default kernel
<kaushal> apw: ok
<kaushal> apw: http://pastebin.ubuntu.com/539323/
<kaushal> apw: I have rebooted it too
<apw> kaushal, i am confused, you only have one kernel installed according to that, so whatever you are running is the server kernel
<apw> or more specifically 'the kernel for server use'
<apw> which as you are running i386 is the generic-pae kernel
<kaushal> apw: basically I am needing server kernel
<apw> kaushal, needing in what sense?  what is the kernel you have not doing for you
<kaushal> it says --generic and not --server ?
<kaushal> 2.6.24-28-server
<kaushal> for example
<apw> that kernel is still the kernel we recommend for i386 servers, hense you installed linux-image-server and you got the kernel we recommend for that use
<kaushal> ok
<apw> from lucid onwards that is no longer called -server, as it is also used for larger 'desktops' which were not supported
<apw> there is actually not much difference in configuration from -generic to -server for i386 on older releases either
<kaushal> apw: is there a way to know from /proc 
<kaushal> the kernel version
<apw> cat /proc/version and /proc/version_signature
<kaushal> apw: Thanks
<smb> apw, Quick question on the pre-proposed stuff: are you looking at master-next only for the kernel or for lbm and meta as well?
<apw> smb, only for kernel, noone has mentioned changing to master-next for anything else yet
<apw> i don't care if we do change at all if thats less confusing
<smb> apw, Ok, cool. Then I am good. I have no strong preference there. Just was wondering after having added something to a meta package
<apw> no ... am assuming if there is a change somone will tell me
<smb> Likely so
<lamont> Intel Server System SR1600UR  <-- machine has no disks when hardy scans it... is there a driver that didn't come along for this box until lucid/maverick timeframe?
<apw> lamont, there have been some new drivers for sure, or newer firmware for same ... what does lspci say it has
<lamont> apw: let me get back there
<lamont> apw: any options you want to lspci?
<apw> -nnvv to get the pci id's <- lamont 
<lamont> so here I sit in busybox from pxeboot with a 40kb file... suggestions on how to get it off the box?
<apw> lamont, well i only want the pci-ids for the disk controller
<apw> 00:1f.2 SATA controller [0106]: Intel Corporation N10/ICH7 Family SATA AHCI Controller [8086:27c1] (rev 02) (prog-if 01 [AHCI 1.0])
<lamont> 00:1f.2 IDE interface: Intel Corporation 82801JI (ICH10 Family) 4 port SATA IDE Controller
<apw> lamont, like on mine here i have that, the bit in []'s is the bit i want
<lamont> that sort of beast?
<apw> that sounds like it yes
<apw> with -nnvv you'll have a [xxxs:yyy] thingy
<lamont> 00:1f.2 IDE interface [0101]: Intel Corporation 82801JI (ICH10 Family) 4 port SATA IDE Controller [8086:3a20] (prog-if 8f [Master SecP SecO PriP PriO])
<lamont> 	Subsystem: Intel Corporation Unknown device [8086:34de]
<lamont> I think that second line is rather a smoking gun
<apw> that implies the kernel has no mapping for the system itself
<apw> it doesn't know what sort of server it is
<apw> which isn't supprising for hardy
<lamont> to be fair, it's certified for 10.10 and later
<lamont> well, 10.10 only atm
<lamont> since 11.04 certification is kinda hard to claim at alpha1
<lamont> does it matter that it's NUMA
<apw> shouldn't no
<lamont> nm. hardy did just fine figuring out that it was numa and all that
<lamont> it would be most kewl if I could get hardy's xen kernel working on these machines... two more ppas if we do
<apw> from natty> drivers/ata/ata_piix.c: { 0x8086, 0x3a20, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sat
<apw> from hardy >
<lamont> is it likely just a matter of adding the PCI ID?
<apw> lamont, looking now
<lamont> eventually, if it's simple, you know I'm going to ask you to lob something into a ppa for me to grab and test...
<apw> lamont, heh, my ears they seem to have stopped working
<lamont> lol
<lamont> I didn't say lob something tested at it... :)
<apw> lamont, does a test kernel need to be in PPA or can i just give you a .deb
<lamont> actually, I want the pxeboot kernel and initrd from netinst
<apw> lamont, erm, no idea how those are made
<lamont> so if it's modules, it's more complicated
<lamont> debs will do just fine
<apw> does a PPA build of a kernel make something you can consume in that context ?
<apw> phew
<lamont> I might need all the debs, which means ppa, I suspect
<apw> debs or .udebs ?
<apw> lamont, is there a bug associated with this yet ?
<lamont> no
<lamont> rather, not that I know of.
<lamont> and yeah, if you can make it a non-module in the kernel deb you give me, that will simplify my life greatly
<apw> i386 or amd64 ?
<lamont> amd64
<apw> flavour ?
<apw> lamont, ^
<lamont> 2.6.24-24-generic <-- that's what I'm running now...
<lamont> for the final fix, I need 2.6.24-xx-xen
<apw> yep just interested in finding out if there is any hope
<apw> lamont, i'll let you know if it builds ...
<lamont> ta.  I have about 16 other things on my plate today, it may be sometime next week before I actually get to test it
<apw> lamont, sounds familiar
<smb> lamont, apw IIRC there was one guy sending a patch for Hardy to get N10 controllers supported...
<apw> smb, got a pointer to that ?
<smb> Re: Fwd: Dell PowerEdge R410 ICH10 SATA support in Ubuntu Hardy
<smb> On our mailing list
<apw> ok
<smb> We were a bit doubtful that only adding IDs is all thats needed
<smb> Then there was no comment back on that
<smb> Or we got distracted
<smb> One of the three
<apw> his attempt to claim copyright in code which was already upstream and only a backport seemed lame
<apw> anyhow, i've just pulle the upstream commit which added the support back
<smb> That applied cleanly to Hardy?
<apw> the original which applied them yes, they are linked as ich8 , they don't seem to be special ich10 code anywhere
<smb> Hm, ok. So with a simple backport from upstream it is more likely to accept it
<apw> smb, it applied without any fuzz even ...
<apw> and we have the advantage we can get lamont to test it
<smb> true
<apw> most of the recent updates for all the really new ICH stuff has just been id's too
<smb> Sounds simple enough to get those supported as soon as servers turn up using that
<lamont> apw: and if you give me an initrd to go with that kernel, even if I need to boot with break to get reality, that's a bonus
<lamont> meh.  I can do that part easily enough
<apw> lamont, an initrd is harder for sure
<apw> smb, do you have a hardy box ?
 * lamont does
<lamont> I have a whole bucket full
<apw> so we could get the new kernel installed on one to get the initramfs built
<smb> apw, Not normally running Hardy
<smb> apw, Oh wait
<smb> I have the test environment for preventing xen explode again. That is a server install even
<smb> apw, Have you already started a test build for that on one of your machines?
<apw> smb, yes build is done, image is uploading to rookery now
<smb> ok. lamont, if you need me to generate an initrd, let me know
<lamont> smb: if you would, that would spare me abusing a machine that I shouldn't
<smb> lamont, sure
<lamont> esp if this is, as I suspect, the same ABI number as current hardy-security/updates
<apw> smb, ok will let you know when the kernel is up
<smb> apw, ok
<apw> 24-28.83
<smb> apw, Those are the lucky numbers? ;)
<apw> yep you win the lottery if you play those
 * smb wonders how hardly apw would bite into his but is he played and won
<JFo> I'm sure he would charge a nominal fee smb
<JFo> :)
<apw> smb, http://people.canonical.com/~apw/lamont-ich10-hardy/
<JFo> so cking that ATI BIOS issue is a breakage in the BIOS or in GRUB2?
<smb> apw, In my home on people there is a initrd.img-2.6.24-28-generic. Could you add that to your lamont-ich10?
<cking> JFo, dunno
<JFo> k :)
<apw> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/683775
<ubot2> Launchpad bug 683775 in linux (Ubuntu) (and 1 other project) "Natty Alpha 1, i915 has blank screen after boot (affects: 5) (dups: 1) (heat: 32)" [High,In progress]
<apw> smb ^
<JFo> smb, were you the person working that NFS bug we got pinged a bout yesterday?
 * JFo can't remember
<JFo> :)
<smb> JFo, Seems in the end I got myself assigned (stupid!) :)
<JFo> sorry about that :)
<smb> I'll have a look when I can hear myself thinking again. :)
<smb> JFo, Meh, life
<JFo> yeh
<apw> lamont, see http://people.canonical.com/~apw/lamont-ich10-hardy/ for all you initrd desires
<lamont> apw: coolness.  you ok with leaving it there until next week?  (and do you want me to leave it or nuke it when I grab it?
<apw> just leave it, it will expire by iteself over time
<apw> lamont, let me know how it works out
<apw> as i will completely forget about it shortly
<smb> lamont, You will have the honor to open a bug for it...
<JFo> heh
<lamont> nod
<JFo> <- need coffee. brb
<JFo> mmmm, coffee
 * apw slaps Jfo
<JFo> :-(
<JFo> why?
 * JFo cries
<smb> JFo, You mentioned coffee
<smb> without sharing
<apw> we're about to lose about 5 man hours as we all run off to get some :)
<JFo> heh
<JFo> sorry about that
<apw> JFo, HEY
<JFo> apw. yo
<JFo> apw do the 2 old bugs on this list seem to apply to the gfxpayload issue? http://goo.gl/U9BCr
<apw> JFo,  http://people.canonical.com/~platform/workitems/natty/canonical-kernel-team.html
<apw> cking, JFo https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Natty
<JFo> thanks apw
<JFo> <-lunch
<ogasawara> bjf: I'm going to push my Lucid fsl-imx51 branch if that's ok.
<bjf> ogasawara, sorry, yes please!
<bjf> ogasawara, we don't really care about those branches :-)
<ogasawara> heh
<ogasawara> bjf: should I go ahead and upload the package to our PPA?
<bjf> ogasawara, you can if you want, i've not uploaded the mvl-dove one though i have one ready, i'm waiting on the discussion with pitti just to see if there are going to be issues
<ogasawara> bjf: that's a good point, I'll hold off for now.
<bjf> ogasawara, oh, the other thing for mvl-dove is, there is already a build "baking" in -proposed for some time
<bjf> ogasawara, and ... just the fact the branches are "up to date" is better than we've been in a while :-)
<ogasawara> bjf: probably good to holf off on mvl-dove then if there's still one baking in -proposed.
<apw> ogasawara, don't say push too loudly
<ogasawara> hehe
<manjo> smb, emailed you the info I was talking about 
<manjo> apw, you are echoing badly
<manjo> apw, heh
 * apw wanders off to find beer
 * cking wanders off to get a life
 * smb found some
<smb> (beer)
<cking> no life then?
<Sarvatt> anyone have any recommendations on which commits to start reverting from https://lists.ubuntu.com/archives/natty-changes/2010-November/001282.html that might make grub stop loading after a reboot (but works on a cold boot)? 2.6.37-2.10 and earlier work fine, everything later hangs at the grub loading screen after rebooting on my i386 netbook. mainline kernels all work fine
<smb> cking, If there is beer there is life
<cking> smb, the two mutually exclusive then?
<smb> cking, I did not think I said that, did I
<smb> Rather inclusive
<smb> But proabably not strictly
<cking> :-)
<cking> gotta go.. seeya all
<smb> have a good one
<manjo> jjohansen, around ? 
<jjohansen> yep
<jjohansen> manjo: whats up?
<JFo> brb
<JFo> yay  I have heat once again in my house
 * jjohansen lunch
 * charlie-tca really likes heat. It is is very nice to have when it is cold.
<JFo> indeed it is charlie-tca 
 * ogasawara lunch
#ubuntu-kernel 2010-12-04
<manjo> jjohansen, around ? 
<manjo> :)
<jjohansen> manjo: in and out
<jjohansen> now
<manjo> jjohansen, ah you are not mumbling :) 
<manjo> jjohansen, git send-email messed up when I sent to lkml, it did not past the patch but only my text, I had to resend it although I tested it 4 times on my self :(
<jjohansen> hrmm strange if it worked on yourself it should have worked on lkml
<jjohansen> I have had occasional odd mail failures in the past
<jjohansen> ah pulse has muted my audio again
<manjo> heh
<manjo> it is strange that it worked 4 times for me, and my 1st git email to lkml was blank
<jjohansen> did you hit n when it was asking to send an email?
<manjo> no I said why
<jjohansen> ?
<jjohansen> ah silly mumble, I may have to reboot to get audio back
<ohsix> is there a proper place to mark internal things on usb as nonremovable? (not kernel related, but i suspect the people here would know)
<ohsix> i'm looking at ID_DRIVE_DETACHABLE in udisks/udev rules, but i'm wondering if there isn't some place to mark things internal
<pcjc2> If you'll permit me a N00b question, is there any docs anywhere on Ubuntu kernel git policy?
<pcjc2> I've been following kernel development from the git repositories, and notice the master branch is often force-updated, which makes the history quite hard to follow. Is there any documented procedures / patch series tools being used, which would help me understand what is going on?
<pcjc2> ls
<bjf> pcjc2, i'm assuming you are talking about the natty repository?
<pcjc2> yes
<bjf> pcjc2, the reson it gets force-updated is because we are taking changes from linus's -rc releases right now and until natty freezes, it's our normal policy to rebase onto linus's tree and then force push our master branch
<pcjc2> ok, so it is just a rebase
<bjf> pcjc2, yes, it's a rebase and then a force push
<pcjc2> Btw.. not sure if it is in yet, but there are some important patches which cropped up on the ACPI list recently which fixed suspend issues regarding fans sticking on
<bjf> pcjc2, once we freeze/ship we don't do that any more
<bjf> pcjc2, linus's tree and lkml are monitored closely, if it comes out in an -rc release we'll get it soon after
<bjf> pcjc2, we sometimes grab patches before a -rc if it's significant enough
<pcjc2> http://www.kerneltrap.org/mailarchive/linux-kernel/2010/11/24/4650803/thread
<bjf> pcjc2, since we had our alpha1 release this week we may not have the latest -rc applied yet
<pcjc2> ok, how is that all going?
<pcjc2> I'm building natty kernel on maverick so I can more easily backport drm-intel-next
<pcjc2> that is working pretty well for me
<pcjc2> haven't dared install Natty on this yet (it is my day to day machine), even though I do tend to track from early betas onwards
<hrw> hi
<hrw> does someone know how to remap keyboard on text console and x11?
<osmosis> is it possible to create a file from a  /proc/####/fd/#  reference?
#ubuntu-kernel 2010-12-05
<savasci> hi all. Which header file to add in order to use malloc/calloc/realloc in kernel development?
<savasci> hi all. Which header file to add in order to use malloc/calloc/realloc in kernel development?
<Sarvatt_> apw: 2.6.37-8.20's linux-libc-dev seems to be causing build problems - http://launchpadlibrarian.net/60149920/buildlog_ubuntu-maverick-i386.xserver-xorg-video-intel_2%3A2.13.901%2Bgit20101205.c2fac6ca-0ubuntu0sarvatt3~maverick_FAILEDTOBUILD.txt.gz
<Sarvatt_> /usr/include/bits/local_lim.h:39: fatal error: linux/limits.h: No such file or directory
<Sarvatt_> yeah the linux-libc-dev waiting to be NEWed is messed up too, not just the one rebuilt on maverick in the PPA -  https://launchpad.net/ubuntu/+source/linux/2.6.37-8.20/+build/2079397
<apw> Sarvatt_, thanks fir the heads up i'll get it fixed
<ogra_ac__> linux unlimited :)
<trap15> does anyone know the reason that usbfs was removed from the ubuntu kernels?
#ubuntu-kernel 2011-11-28
<ppisati> morning *
<smb> morning
<abogani> morning
 * jk- tips hat
<smb> jk-  is wearing hat in summer? ;)
<iceroot> we have a working patch for this https://bugs.launchpad.net/ubuntu/+source/linux/+bug/869502
<jk-> there are hats for all seasons!
<ubot2> Launchpad bug 869502 in linux "Kernel-Panic with 3.0.0.12-generic on asus eee pcs and msi wind (both using rt2800 wifi chipset)" [High,Confirmed]
<iceroot> what is the common way? wating until it is upstream? or directly patching ubuntu-kernel?
<smb> iceroot, Usually the preferred way is to at least wait until it appears upstream, yes. On critical issues that may be accelerated, if it looks like the maintainer is ok with it.
<iceroot> smb: ok
<smb> If you send an email that points to the patch, gives some background where it comes from and what the upstream status is to kernel-team mailing list (and for what release it is) it is possible to look at it
<iceroot> smb: so kernel-team is normally "only" reacting on mails not on launchpad-bugs?
<iceroot> ubuntu-kernel-team
<smb> iceroot, It is simpler because bug email just floods in. Easy to miss things there
<smb> If there is a single developer already assigned, then its a bit different
<iceroot> smb: thank you for the info, i will send a mail to last list
<smb> iceroot, Thanks
<apw> alexbligh, ahh yes it is possible we moved to linux, following linus
<apw> alexbligh, i must admit my personal linux-linus tree i use for close bases is taken from kernel.org
 * apw yawns
<jk-> ey apw
<apw> jk-, dude
<ppisati> who decides which pkg go into a release? i mean
<ppisati> the preinstalled image for omap4 from friday is stil using the onerici kerne (3.0.0.12)
<ppisati> while P/master has moved to...
<ppisati> 3.2.x
<ppisati> to whom shall i talk?
<ppisati> BTW 3.0.0.x has bug for the beagle xm rev c (and the same bug doesn't show up on latest kernel that's why i would like to use an updated kernel)
<ppisati> and there's no ogra around when you need one...
<ppisati> :)
<apw> smb, yeah we don't have lbm yet, and won't for some time i suspect
<apw> will confirm it is turned off in meta, which it should be, and probabally let leann make it
<smb> apw, Ah ok. Makes sense. 
<jibel> we get bug 894768 during automated iso testing of Precise images. Could one have a look ?
<ubot2> Launchpad bug 894768 in linux "Installation randomly fails with: File "/usr/lib/ubiquity/ubiquity/install_misc.py", line 621, in copy_file targetfh.write(buf) IOError: [Errno 22] Invalid argument " [Undecided,Incomplete] https://launchpad.net/bugs/894768
<smb> jibel, I try to look into it. There are not too many kernel errors on a quick first glance, though. Btw, do you know what xvda2 should be? extended partition?
<jibel> smb, correct, extended partition.
<smb> jibel, ok thanks. Was one message I did see. But that being unknown type for the os prober sounds ok
<brendand> apw - hi
<apw> brendand, HI
<brendand> apw - have you been following : https://lists.ubuntu.com/archives/kernel-team/2011-November/017938.html ?
<apw> brendand, i have seen some of the discussion yes
<brendand> apw - any thoughts on what could be left out of the list?
<apw> brendand, i think the dimensions shown make sense, video, audio, webcam, etc
<apw> brendand, those seem to be the ones we'd have an issue against, perhaps video(ati) video(intel) might be useful
<apw> brendand, beyond that i think you are talking specific devices, and only a full list is of use
<apw> (not sure if that answers what you are asking)
<apw> brendand, the things which seem to be 'x' seem uninteresting in the main, perhaps some of the touchpads are interesting, but again most likely i care about one specific one
<brendand> apw - but is it worth testing all of the different touchpads in general?
<apw> brendand, i read teh email as asking about categories one might with to test against, so "i have a patch which does this can you test it on as many relevant machines"
<brendand> apw - so, the scope of this is that we come up with a list of device categories for which we want at least one system with each device of that category in our testing pool
<apw> is this a pool of machine to automatically test against?
<apw> if so then no input device is relevant i guess
<brendand> apw - best to assume they could also be manually tested
<apw> the problem with both touchpads and wifi, is there are 100s of each, you're not going to cover the whole spectrum
<brendand> apw - no, but we can test all the ones we have in house
<brendand> apw - take a 'Memory controller' for example. would we ever want to be testing each different memory controller?
<apw> brendand, memory controllers are so tied to the CPU type (being built in these days) that you'd more want a range of "platforms", ivybridge, sandybridge, whatever amd calls things
<apw> (and those are all X on the list already)
<Q-FUNK> Could the fix provided in bug #892615 please be merged?
<ubot2> Launchpad bug 892615 in linux "3.2.0-1-generic: completely fails to boot on Geode LX" [High,Confirmed] https://launchpad.net/bugs/892615
<apw> BAH I hate it when people ask things and then go away
<apw> q-funk, we are waiting for someone in the know to ack that the patch is safe for non-geode h/w
<apw> (not that you will see my reply)
<_ruben> can't really blame him for pinging out.. ;-)
<_ruben> well, you can, but might not be fair
 * cking needs to reboot
<ogasawara> apw: thanks for uploading -rc3 and linux-meta
<tgardner> ogasawara, speaking of uploads, whats going on with armhf? 
<ogra_> tgardner, we would like to have the entries in debian/control soon :)
<ogasawara> tgardner: I believe apw was fixing up the control file
 * ogra_ doesnt think any additional stuff is required atm ... we dont have the builders running yet
<tgardner> ogra_, are there functional chroots for armhf yet ?
<ogra_> not sure, last update from infinity i had was friday, saying the chroots should be ready and are pending launchpad enablement 
<ogra_> (which still might take some days)
<tgardner> ogra_, ok, I was just noticing uploads from him referencing armhf
<ogra_> right, we need to make the packages that dont have hf as target arch in debian/control aware of that arch
<ogra_> theye uploads are mainly doing that one line change i guess
<tgardner> ogra_, right, I don't think its too complicated.
<ogra_> well, for kernels this is generated, isnt it ?
<ogra_> i.e. you need to duplicate the config etc
<tgardner> ogra_, yes, but its mostly scripted.
<ogra_> yeah
 * herton -> lunch
<ogra_> but still a bit more than doing s/armel/armel armhf/
<tgardner> indeed
<tgardner> cjwatson, if we switch the kernel to 'Depends: crda (>= 1.1.1-1ubuntu2)', can you deal with the main inclusion carnage ?
<tgardner> p.s. - thanks for fixing the file collision between crda and wireless-regdb
<apw> ogasawara, no problem, best to get it done early
<apw> ogra_, i worked with infinity this am to add the armhf stuff; and to tell him about DEB_STAGE1 which he wasn't using
<apw> tgardner, ^^
<tgardner> apw, ack.
<apw> ogra_, all the config bits were already in it was just the control file change which was missing
<ogra_> ah, cool
<apw> ogra_, in theory we are there, infinity is also going to play with the staged stuff for future
<ogra_> yeah, i'm personally more concerned to get the buildds up, armhf *can* run with armel kernels ... its just for getting a properly named deb in the archive
<Q-FUNK> ogasawara: could the fix to bug #892615 please be merged?
<ubot2> Launchpad bug 892615 in linux "3.2.0-1-generic: completely fails to boot on Geode LX" [High,Confirmed] https://launchpad.net/bugs/892615
<ogasawara> Q-FUNK: I'd like to get more testing on non-geode hw first and I would prefer to see it getting applied upstream as well.
<brendand> sconklin - hi
<sconklin> brendand: good day
<brendand> sconklin - we're looking at an issue with the Lucid -proposed kernel at the moment. afraid we don't have an awful lot of detail right now though
<brendand> sconklin - we have a server system which was certified with 10.04.3 and now it's halting shortly into testing
<jsalisbury> op jsalisbury
<tgardner> brendand, its bjf and herton problem now. have you been able to get a dmesg trace ?
<sconklin> brendand: While I care (really!), bradf is the stable kernel manager as of UDS - I am doing a rotation in QA. herton is also doing a lot of the stable work
<jsalisbury> ogasawara, do you know how I get the permissions to become operator, so I can change the channel topic?
<ogasawara> jsalisbury: hrm, I can't remember the exact process bjf, apw, and I went through to get ops.  let me try and dig for more info.
<jsalisbury> ogasawara, thanks
<apw> hrmmm i think we started out asking is
<brendand> sconklin - ah, i didn't know that
<apw> somehow our channel isn't one of the officially owned ones (an oversight) so it was less straight forward
* ogasawara changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Oneiric Kernel Version: 3.0.0 || Ubuntu Kernel Team Meeting - Tues Nov 29 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<ogasawara> jsalisbury: I've gone ahead and updated the topic for you in the mean time
<jsalisbury> ogasawara, cool, thanks
* ogasawara changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues Nov 29 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<herton> brendand, is it a new issue (are you able to freeze the machine with previous kernel, or only on the new kernel?)
<brendand> herton - as far as we can tell, only with the new kernel. we don't know yet does it happen randomly or whether a test is triggering it
<brendand> herton - unfortunately the system is in taipei and i don't have access so can't do any investigation right now
 * ogasawara back in 20
<herton> brendand, ok, would be good if someone is able to check which test freezes, and if there is some oops or other reason for the freeze. May be a bisect will be needed to check what introduced the problem.
<cjwatson> tgardner: I already dealt with the main inclusion carnage :-)
<tgardner> cjwatson, cools. thanks.
<cjwatson> tgardner: mainly by taking the Gordian-knot approach; it's clearly a one-for-one replacement for wireless-crda, so I just promoted it, in trust that wireless-crda will fall out soon enough
<tgardner> I'll make the change in the ekrnel.
<cjwatson> that should be fine - the Provides should ensure that old and new kernel packages are still coinstallable
<cjwatson> it'll have the effect of forcing everyone over to crda, which is what we want anyway
<tgardner> cjwatson, hmm. this will essentially prohibit running a precise kernel in older user spaces if I make it absolutely dependent on crda.
<tgardner> maybe I'll leave it 'Depends: wireless-crda | crda' for now.
<brendand> herton - ok. we'll do more investigation when our lab engineer returns tomorrow morning and keep things up-to-date. when i have a bug number i'll add it to the tracking bug.
<herton> brendand, ack
<cjwatson> tgardner: you could flip the dependencies round to indicate the current preference
<cjwatson> tgardner: although that probably won't cause apt to replace with the newer code
<tgardner> cjwatson, I was just gonna ask if ordering had an impact.
<tgardner> if we drop wireless-crda from precise, then dpkg should always select crda, correct ?
<cjwatson> tgardner: for new installations, yes; that won't cause apt to remove wireless-crda on upgrades, though
<cjwatson> (it might persuade update-manager to do so)
<ppisati> if i bump the abi, does it fix the missing module case too? i guess it won't...
<tgardner> cjwatson, ok, I'll start a bug against update-manager so we don't forget this. since wireless-crda will no longer be maintained, I'd like for it to get removed on upgreade.
<tgardner> ppisati, nope.
<tgardner> ppisati, add an ignore.modules to the ABI directory
<ppisati> and i bump the abi too, right?
<cjwatson> tgardner: update-manager is the wrong place to fix this - if you want to get rid of it, there needs to be a Conflicts: somewhere
<tgardner> ppisati, thats not necessarily related. you can drop modules without changing the ABI
<ppisati> ok
<cjwatson> it's unfortunate that crda was uninstallable in oneiric
<tgardner> cjwatson, but that affects the ability to run precise kernels in older user spaces.
<cjwatson> I know, but still, fixing it in update-manager is an absolute last resort
<cjwatson> let's not start there
<tgardner> cjwatson, ok, I'll just leave it be for now. if I see a big crda update I'll consider updating wireless-crda
<tgardner> I did swap the order so that crda is preferred
<cjwatson> nothing springs to mind right now, but there may be some tricky way to conflict such that it goes away on precise upgrades but doesn't break older userspaces
<cjwatson> most things are possible somehow :)
<tgardner> yeah, yuo'd think this situation has been encountered before
<cjwatson> we could even SRU wireless-crda to add a crda transitional package or something
<cjwatson> kind of the reverse of the usual transitional package situation
<cjwatson> hm, except that doesn't quite work
<tgardner> cjwatson, perhaps turn the preicse version of wireless-crda into a meta package  that depends on crda ?
<cjwatson> oh, yes, of course, that's the simplest answer isn't it
<tgardner> ok, I can do that
<cjwatson> yeah, I recommend that
<tgardner> ogasawara, can you get that on our list of things to do ?
<ogasawara> tgardner: yep
<cjwatson> maybe crda (>= 1.1.1-1ubuntu2) to make sure we don't get bitten by the uninstallability in oneiric
<tgardner> cjwatson, already done for the kernel. I'll do the same for wireless-crda
<cjwatson> (crda depended on wireless-regdb but they shipped a common file)
<cjwatson> great
<Q-FUNK> ogasawara: there won't be much testing taking place for as long as it's not applied to something that it pushed into the repository...
<ogasawara> Q-FUNK: I'll be testing locally
<Razec> Hi guys...
<Razec> I want to get involved in the Ubuntu Kernel Development. What steps do I take to get involved?
<Q-FUNK> ogasawara: I assume that we're talking about that one-line fix, mentioned in the bug, that applies the feature only to recent AMD hardware?
<apw> ppisati, hey, whats the gen on this omap issue, display driver, we know what needs changing
<apw> ppisati, and is this ti-omap4 ?
<ogasawara> apw: ah, I see he's sent a patch to the ml
<ogasawara> ppisati, ogra_: I assume this need uploading asap
<apw> ogasawara, assuming the release team say yes of course :)
<ogra_> ogasawara, agreed ... its just a one option config change in the arm config though
<apw> ppisati, and we have tested this yes?  we know the kernel with just htat option is GOOD
<apw> ogra_, has anyone tested with the option on, to make sure thats the only change
<ogra_> apw, its not working at all without it 
<apw> ogra_, and if changging it doesn't make it work there is no point in uploading and disrupting all the other architectures
<ogasawara> from ppisati -> "Tested on my Beagle XM."
<apw> so ... has anyone tested it does work
<ogra_> there is a new display driver thats being used by linaro already, we just didnt enable it in our config 
<ogra_> well, we enabled it as module which apparently doesnt work at all ... so it needs =m to become =y
<ogra_> and given the old display driver is gone in favor of the new one ....
<apw> yep new things become =m by default, if they can be, one assumes they work if they say they can do =m, sigh
<ogra_> well, its TI ....
<l3on> Hi all... does someone know why we don't have a linux image 3.2-rc3 in http://kernel.ubuntu.com/~kernel-ppa/mainline/ ?
<apw> ogra_, if this patch is accurate, the issue has existed in all the 3.2-rc kernels, ie been in the archive for weeks how have we missed this till today
<ogra_> apw, not much testing yet i guess
<apw> ogra_, if we don't care enough to test it, why are we spinning for it
<ogra_> apw, we do, but the last weeks were filled with paperwork and vacations
<ogra_> and we are not used to have images before A1 at all
<ppisati> apw: i just noticed this morning, because i was installing the new preinstalled image from 28th
<ogra_> thats a total novum 
<ppisati> apw: the omap images till 25th had a 3.0.x kernel still
<ppisati> friday i tried a nioghtly build, and it still had the 3.0 kernel
<ppisati> the funny thing is that i was looking to fix another bug... :)
<apw> ppisati, hmm, how can that be i wonder, we've had 3.2-rc2 in there for ages
<ppisati> apw: dunno
<ppisati> apw: this morning, in this channel, i asked how the images are built
<ogra_> meta having been stuck somewhere without anyone noticing ?
<ppisati> apw: who decides which pkgs go in evbery image
<ogra_> ppisati, the meta package 
<ogra_> live-build pulls in linux-omap by default for the omap image
 * apw is baffled
<ogra_> so it might be that linux-omap sat in binary new and nobody noticed or that it accidentially went to universe once again and nobody noticed
<ogra_> though i had someone last week on IRC who actually complained about the orange screen you were seeing too, but i was swamped in sorting team specs
<ogra_> so i didnt dig into it 
<apw> ogra_, maybe universe, thats been a common problem recently
<ogra_> yeah, one of the two isuues are the usual ones
<apw> ogra_, yeah so i think the kernel was out, so installs should have gotten it
<apw> i suspect we have another issue in image build
<apw> oh well
<ogra_> well, we'll do better next time 
<GrueMaster> apw: As to testing, it comes down to man power.  AFAIK, I am the only one really doing any image testing on daily armel images.  I am also the only one testing SRU kernels on armel.  I am also the only one doing major armel server test automation.  I need more of me.
<apw> yeah we need more testing power
<GrueMaster> afaik, the testing that linaro does on the kernels is limited to mainly headless automation (I could be wrong, but given the hardware, I doubt it).
<apw> ogasawara, i've added a annotation for the arm DVI thingy
<ogasawara> apw: ack
 * apw wanders to make some food ...
 * tgardner follows suit -> food
<cking> hrm food
<apw> cking, yeah food
<cking> yum
<herton> apt
<apw> tsk
<cking> sigh
<rik_> sforshee: can I ask you a question regarding bug 606238?
<ubot2> Launchpad bug 606238 in linux "synaptic touchpad not recognized on dell latitude e6510 and others" [Undecided,Confirmed] https://launchpad.net/bugs/606238
<sforshee> rik_, sure, go ahead and ask
<rik_> sforshee: you ask for the output from input-events for further debugging. When I run that command it returns
<rik_> protocol version mismatch (expected 65536, got 65537)
<rik_> any idea on how to handle this?
<rik_> Note that I'm running on debian testing with the 3.1 kernel
<rik_> I've patched the psmouse module
<sforshee> rik_, you need a newer version of input-events, or else modify the source yourself to remove that protocol version check
<sforshee> iirc the check was simply removed when this problem surfaced
<sforshee> rik_, http://www.kraxel.org/cgit/input/commit/?id=d99f056745e53cd2518ca169af474f8c45c1436d
<sforshee> that's the patch to remove the check
<rik_> sforshee: thanks, I've patched the code from trunk
<rik_> when I look at xinput list it shows my touchpad as 12 (ps2 mouse) and 13
<rik_> but when I run input-events, it shows for 12 HDA Intel PCH HP Out at Ext Righ
<rik_> ?
<rik_> and something similar for 12
<rik_> 13
<sforshee> rik_, the indexes from xinput aren't the same as input-events uses, use lsinput to get the argument you should pass to input-events
<sforshee> rik_, also note that you need to run input-events from a virtual terminal to get the results. X will prevent you from seeing the events
<rik_> sforshee: thanks for the hint. I ran it in X and it showed input for the ps2 device but not for the alps glidepoint
<rik_> will try from a console
<rik_> doesn't make a difference. only input from the ps2 device :-(
<rik_> sforshee: would it make sense to play with the ALPS_PROTO version field in the driver?
<sforshee> rik_, do you see REL_X and REL_Y events or ABS_X and ABS_Y?
<rik_> REL_X
<sforshee> rik_, then I think it's likely that you're still just getting PS/2 data
<rik_> sforshee: I only get input on the PS2 mouse input device and nothing on the other device
<rik_> what do the fourth and fifth field in the alps_model_info struct mean? for example 0xcf, 0xcf
<sforshee> rik_, you could try changing the ALPS_PROTO field for v3 and v4 and see if it works
<sforshee> rik_, the fourth and fifth fields are used for identifying proprietary-formatted data packets, if you're trying v3 or v4 they should both be 0x8f
<rik_> V3 results in:  unknown response while entering command mode: 73 01 0d
<rik_> what does the second field in the struct mean, for example 0x9b
<rik_> V4 results in the same error message
<sforshee> rik_, the second field is used to differentiate between different v3 and v4 models
<rik_> sforshee: what are valid numbers to try there?
<sforshee> rik_, based on those results I suspect yours isn't a v3 or v4 device. the response looks more like the response for an E7 report
<sforshee> if you want to keep trying, you would need to change the second for your new model to 0x0d
<sforshee> you also need to make alps_enter_command_mode recognize 0x73 and 0x01 as valid for the first two bytes of the response
<sforshee> you can give it a try, but I don't expect it to work
<rik_> sforshee: ok, will focus on V2 then. could PS2_INTERLEAVED make a difference in the events output?
<sforshee> rik_, you might as well try v3 and v4 since it's fairly easy. but you may well be looking at another protocol that no one has deciphered yet.
<rik_> sforshee: nice :-)
<rik_> :-/
<sforshee> rik_, do you or don't you have PS2_INTERLEAVED set currently?
<rik_> currently set
<rik_> but my v3 and v4 attempts did not have this set
<rik_> they had ALPS_PASS set
<sforshee> rik_, my guess is that if you remove it your results will get worse. But there's no harm in trying.
<sforshee> it will be informative at any rate
<rik_> so it should be set (ps2_interleaved) for all attempts (v2, v3...)
<rik_> ?
<sforshee> if your results get worse then it confirms my guess that the driver is just handling PS/2 data when you have it "working"
<sforshee> no, don't set it for v3 and v4
<sforshee> well, really it won't make any difference, the v3 and v4 support don't check that flag
<rik_> if I change the alps_dump_packets int in the alps.c code to 1, will this give me more debug output
<sforshee> possibly, but it will be a flood of data that probably isn't very useful at this point.
<rik_> ok, will skip that then
<rik_> the only way to really debug this is to follow your instructions on building a custom qemu?
<sforshee> hrm, actually removing PS2_INTERLEAVED probably won't prove anything, there's another path for PS/2 data that's probably the one you're actually hitting
<sforshee> and my statement about v3 and v4 ignoring the flag are incorrect now that I look at the driver again, it's in a code path common to all protocol versions
<rik_> with V2 and ps2_interleaved enabled, the driver reports the following when loaded
<rik_> E6 report: 00 00 64
<rik_> E7 report: 73 03 50
<sforshee> if you get to the point where the interleaved flag matters with v3 or v4 you're doing pretty good though :)
<rik_> Status: 10 00 0a
<rik_> sforshee: so it would make sense to try that? will do
<rik_> no difference for v3
<rik_> v4: nodifference
<rik_> the DUALPOINT flag means that there's a touchpad and a stick between the keyboard keys?
<rik_> or does it mean multitouch?
<rik_> and what is a 4 direction button?
<sforshee> rik_, it means a touchpad and a trackstick
<rik_> my system is a dell inspiron 15R, and doesn't have a trackstick
<sforshee> rik_, I don't have experience with the 4 direction button thing, but looks like it's for some hardware that has some extra buttons
<rik_> I guess playing with those won't make a difference anyway?
<sforshee> nope, i don't think you're getting far enough for them to matter
<rik_> so the qemu method is the only way to get any further?
<sforshee> rik_, I'd suggest adding a printout to alps_report_bare_ps2_packet to verify that you're still just seeing plain PS/2 data, if your message is printed it means that you are (which is my suspicion). If that's the case trying to sniff the Windows driver using qemu would be the next step.
<rik_> your patch is for qemu or qemu-kvm?
<sforshee> qemu-kvm
<rik_> correct about the report_bare thing. it's spewing my log out :-)
<rik_> will your patch work with 0.15.1?
<sforshee> rik_, not sure, haven't tried it with 0.15.1
<sforshee> if it applies cleanly there's a good chance it might work :)
<rik_> seems to apply with some fuzzing
<rik_> sforshee: it's building. I'll try the qemu thing when i find the time. Have to install windows inside the vm first. Thanks for your time
<sforshee> rik_, np, let me know if you have more questions. Good luck!
<rik_> sforshee: what timezone are you in?
<sforshee> rik_, US central (UTC-6)
<rik_> sforshee: so it's like 1pm for you?
<sforshee> no, 3pm
<rik_> ah yes
<rik_> ok
<jsalisbury> bjf, herton, possible regression between 3.0.0-12 and 3.0.0-13: bug 894292
<ubot2> Launchpad bug 894292 in linux "Sandybridge suspend/resume regression on 3.0.0-12-generic/3.0.0-13-generic" [Medium,Triaged] https://launchpad.net/bugs/894292
<herton> jsalisbury, we will check that
<jsalisbury> herton, cool, thanks!
<jsalisbury> ogasawara, Do you think this one should be on the hot list?  Installation failures for Precise VMs: bug 894768
<ubot2> Launchpad bug 894768 in linux "Installation randomly fails with: File "/usr/lib/ubiquity/ubiquity/install_misc.py", line 621, in copy_file targetfh.write(buf) IOError: [Errno 22] Invalid argument " [High,Triaged] https://launchpad.net/bugs/894768
<ogasawara> jsalisbury: sure.  probably needs more investigation though.
<jsalisbury> ogasawara, thanks.  I'll request additional investigation to try and find a root cause.
 * tgardner -> EOD
<jibel> jsalisbury, is there any additional information I can provide? It's very easy to reproduce in our testing env and I can try to instrument the iso if it helps.
<jsalisbury> jibel, Do you know if this only happens when installing Precise as a VM?  Have you see this in any of the physical machine installs?
<jibel> jsalisbury, I've never seen it on a physical installation, only Precise VM. I'll try tomorrow on a physical machine.
<jsalisbury> jibel, from the error, it looks like the install.py script is loosing access to a file handle and throwing I/O errors.  
<jsalisbury> jibel, are there any logs on the host that can be added to the bug?
<jibel> jsalisbury, on my report it happens in write() but in duplicates it happens in close(), I've seen the same error with dpkg on an alternate amd64 install.
<jibel> jsalisbury, I haven't found any useful information on the host, no disk or media error but I can attach logs from the host when that happens. Which one do you need ?
<jsalisbury> jibel, hmm.  Maybe just the syslog and any logs specific to KVM.
<jsalisbury> jibel, its interesting the error happens on a write() and close().  It's like it's loosing access to a file it had open.
<jsalisbury> jibel, it would be good to see if it also happens with any other I/O operations in dup reports.
<jibel> jsalisbury, this was the error with dpkg
<jibel> Nov 24 10:01:11 in-target: dpkg: error processing /media/cdrom//pool/main/p/perl/perl-modules_5.14.2-5_all.deb (--unpack):
<jibel> Nov 24 10:01:11 in-target:  failed in write on buffer copy for backend dpkg-deb during `./usr/share/perl/5.14.2/IO/Uncompress/Base.pm': Invalid argument
<jibel> jsalisbury, I'll run the test again and will attach the host logs
<jsalisbury> jibel, cool thanks.  I wonder if you could identify the file being written to when the error happens, and then see if you can get details on it.  Maybe it's getting corrupt?
<jibel> jsalisbury, ubiquity doesn't report the file being copied. I'll see what I can do.
<jsalisbury> jibel, hmm.  I haven't looked at the code yet, but do you think the file should have been copied somewhere, and it was not?
<jibel> jsalisbury, I don't know
<jsalisbury> jibel, ok, I'll take a closer look at the script tomorrow as well.
<jibel> jsalisbury, great. thanks for your help
<jsalisbury> jibel, np
#ubuntu-kernel 2011-11-29
<gema> jsalisbury: it happens on hw as well, patrick tried yesterday
<ikepanhc> bug 897506
<ubot2> Launchpad bug 897506 in linux "USB3.0 host can't detect USB3.0 device" [High,In progress] https://launchpad.net/bugs/897506
<ikepanhc> a simple question, the fix for above bug has been merged into 3.0 stable kernel and in 3.0.11 already. This oneiric SRU cycle goes to 3.0.10 kernel. Shall I post the fix to u-k list or just wait for next oneiric SRU cycle?
<apw> BAH no ie
<apw> ike
<smb> apw, ?
<apw> at 9:16 ike asked something, and now is not here
<smb> ah. could not put the pieces together
<smb> Wondered why you want internet explorer... :-P
<apw> never!
<brendand> anyone knows what this means: "Uhhuh. NMI received for unknown reason 21 on CPU 0."
<cking> brendand, at a guess, NMI reason is being read for port 0x61, and a reason code 0x21 does not indicate a channel or parity check error which I would expect from that kind of error
<cking> I'd expect a reason code >= 64 to indicate some kind of H/W detected error, see: http://wiki.osdev.org/Non_Maskable_Interrupt
<tjaalton> i'm not seeing the new oneiric-proposed kernel image (14.23) on a.u.c, though some other packages seem to be there..
<tjaalton> like linux-doc_3.0.0-14.23, but not linux-image-3.0.0-14-*
<tjaalton> herton: ^
<herton> tjaalton, hmm, some of them went into universe
<herton> (http://archive.ubuntu.com/ubuntu/pool/universe/l/linux/)
<tjaalton> interesting.. though I still can't apt-get it :)
<tjaalton> not that I would, it's enough to know where to wget it from
<herton> tjaalton, do you have universe enabled? well, we have to report to pitti so he can fix it
<tjaalton> herton: yes
<Daviey> Hey!  Has rtl_nic/rt18168d-1.fw been dropped from Precise?  Being asked for it at install time, which seems to be a regression from Oneiric.
<tgardner> Daviey, lemme look
<Daviey> tgardner: thanks
<tgardner> Daviey, its in the linux-firmware package for Precise. 
<tgardner> what does "being asked for it" mean? the installer doesn't prompt for firmware files AFAIK
<Daviey> tgardner: Hmm, okay - thanks.  I'll have to dig into why the installer isn't finding it.. 
<Daviey> tgardner: well it is :)
<Daviey> (d-i, not ubiquity)
<tgardner> huh. /lib/firmware/rtl_nic should be the ultimate location. 
<Daviey> It's asking me to insert media containing that file, Yes / No
 * Daviey looks
<tgardner> Daviey, I'm surprised that d-i is cranking up your wireless connection. perhaps this is new behavior ?
<Daviey> tgardner: hmm.. dmesg - .. r8169 ... eth0: unable to load firmware oatch rtl_nic/rt18168d-1.fw (-2)
<Daviey> interesting it's eth0
<tgardner> Daviey, r8169 is not wireless, its wired.
<tgardner> Daviey, looks like we need firmware in the udeb. Are you sure this installed correctly on Oneiric ?
<Daviey> tgardner: I can double check.
<tgardner> Daviey, from scratch please. I don't think we've changed anything wrt r8169 firmware.
<Daviey> the odd thing is, networking is working
<roadmr> Hey everyone! I need to report a couple upstream bugs on the kernel, but bugzilla.kernel.org is still down :-/ what's a good place to file bugs in the meanwhile? LKML? or the per-subsystem mailing lists? what are other people doing about this?
<Daviey> tgardner: thanks
<arges_> apw, hey, last we discussed some i915  hangcheck issues. I think this is what we're seeing in natty (i have garbled serial output). Was there a set of patches / bug report I should be looking at that covers this?
 * herton -> lunch
<brendand> herton - hi
<apw> arges_, hmmm can't recall off the top of my head
<arges_> apw, ok
<apw> arges_, might be worth asking bryceh he tends to remember better
 * ogasawara back in 20
<herton> brendand, hey, did you get the results about the cert. regression?
<brendand> herton - not yet. it is a very tricky issue.
<bjf> brendand, please explain. you've given us almost no information other that "ther may be an issue" and it's holding up a SRU
<brendand> herton - all the extra info i have now is we saw the message "Uhhuh. NMI received for unknown reason 21 on CPU 0." just before the system halted
<brendand> bjf - i totally appreciate the urgency
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<tgardner> brendand, that sounds kind of hardwarish. Is it a fault from EDAC ? (RAM single bit errors) 
<cking> tgardner, I thought port $61 would report that in bits 6-7 if that was true
<tgardner> cking, by the time the system is halted I don't think we're getting anything out of it
<herton> yeah, looks like this NMI msg may well be something RAM related, likely hardware issue
<brendand> tgardner - by hardwarish you mean it's totally a failing hardware issue? we can't reproduce this halting with the release kernel
<cking> ah, just FWIW, it does sound like a H/W issue to me
<tgardner> brendand, can you run a full cycle of the RAM test ?
<brendand> tgardner - the one in the BIOS?
<tgardner> brendand, no, the one on the CDROM
<tgardner> it should also be in the grub boot menu
<cking> the mem86 test thingy
<brendand> tgardner - at the moment i only have ssh access. there will be lab engineer in early tomorrow
<tgardner> brendand, no KVM access ?
<brendand> tgardner - no, unfortunately
<brendand> tgardner - the lab engineer is in early tomorrow morning
<brendand> (i already said that)
<tgardner> brendand, so wtf do you have equipment in Asia that you can't actually do anything with ?
<bjf> brendan, how many systems has this been tested on and it has passed? how many of those systems were server class systems ?
<brendand> bjf - nearly 100. probably about 60 are servers
<brendand> make that 53
<brendand> are servers
<bjf> brendand, please update the tracking bug with what information you _do_ have right now, I think we are going to suggest publishing this and addressing this possible regression in the next cycle
<brendand> tgardner - the thing that's suspicious is that two systems are doing it, both of the same make.
<arges_> bryceh, looking at some i915 hangchecks on an x220 machine. wondering if there are any open bugs or issues I should be looking at. We're seeing this on a natty kernel
<tgardner> brendand, well, thats kind of an interesting factoid. what bug # is this, and do you have the machine specifics attached to it ?
<brendand> tgardner - haven't been able to gather the machine details because of the halting
<tgardner> brendand, huh? are you saying it won't even boot ?
<brendand> remember i'm working through a lab engineer here, so i'm taking his word for everything
<tgardner> brendand, until you can get us some actual facts to work with, there isn't a hell of a lot we can do
<bjf> skaet, can we continue our discussion here? thanks
<skaet> bjf, sure.
<skaet> Daviey, when the server team meeting is finished, can you look at the backscroll on this?
<skaet> brendand,  can you start a separate bug off to track what you're seeing as symptoms, and get more of the machine specifics in there?
<Daviey> skaet: wilco, have 2 x calls directly following this but will during them
<skaet> Daviey,  thanks. :)
<bjf> brendand, can you give us any information at all about these servers? make, model, etc.?
<Wipster> Good afternoon, I believe I have bumped into a bug in the ata_piix driver on my ICH7-M chipset board, the system is horribly slow and I cant use the harddrive, dmesg is filled with 'failed command: READ DMA EXT'. Did a bit of looking and there was an old bug where UDMA was set to 133 which is above ICH7 spec, but I see that its being backed right down to 33, which is when the system finally unlocks
<bjf> Wipster: can you give us the bug # that you've filed ?
<Wipster> bjf: yet to file thought I'd pop in here first, will do that now
<bjf> Wipster: thanks
<brendand> bjf - i'm just raising an umbrella bug as skaet asked. it's going to be short on hard facts until our engineer gets in, but at least it will have the make and model(s)
<bjf> brendand: anything will help, thanks
<skaet> thanks brendand
<Daviey> brendand: are you able to offer remote access to folks which might be able to help?
<Daviey> ah, seen that in scrollback
<brendand> Daviey - yeah, it's sub-optimal unfortunately
<brendand> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/897773
<ubot2> Launchpad bug 897773 in linux "[Acer AR320 F1 and Acer AR160 F1] Halting shortly after booting with Lucid (2.6.32-36.79) -proposed kernel" [Undecided,New]
<brendand> two Acers
<tgardner> brendand, what was the last kernel version that was certified on these machines ?
<brendand> tgardner - 2.6.32-33.70
<brendand> tgardner - interestingly the server kernel wasn't used then though. just the -generic one
<tgardner> brendand, I thought cert verified every kernel that goes into -updates ? what happened with 2.6.32-35.78 ?
<jsalisbury> ##  
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##  
<Daviey> tgardner: btw, http://pb.daviey.com/KFon/ see the missing firmware error
<brendand> tgardner - that should be the case. sometimes we have to miss systems out for lack of time.
<bjf> skaet, Daviey, thoughts on publishing this lucid kernel and dealing with the possible regression in the next cadence cycle ?
<tgardner> brendand, one thing you could have your tech do in his morning is to start working forward from 2.6.32-33.70 on these 2 machines to see where it begins breaking.
<Wipster> bjf: #897777
<skaet> Daviey,  Any feel for how likely this might be to show up in the field?  How prevalent are the Acer's in question?
<Daviey> skaet: Honestly, i don't know.  I don't know of other deployments that focus on Acer servers, but that is just my experience.
<tgardner> Daviey, it looks like the firmware load was ultimately successful after installing linux-firmware. There are complaints that a couple of firmware files referenced in module aliases don't exist (which is correct)
<Daviey> tgardner: right, so i guess i need to discuss this with cjwatson, regarding ordering of installs?
<Daviey> As in, there was a hard warning for me to skip
<tgardner> Daviey, correct. it seems the installer shouldn't prompt for firmware until after installing linux-firmware
<Daviey> tgardner: thanks
<brendand> oh wow, my wifi just went bonkers
<brendand> Daviey - what's your opinion on this bug then?
<Daviey> brendand: as tgardner said, we don't have access to this class of hardware.. I'm really not sure what more we can do?
<skaet> bjf, concern is how likely will this result in an incident report and cause more perturbation.   Would like to get a bit more data on this one from the machines in question and from the OEM team as to how prevalent they are.   What is impact of waiting a day?
<bjf> skaet: low impact, i just don't want this to drag out. haveing to wait 24hrs. to get a single question answered is going to be a problem
<skaet> brendand,  any way that engineer can join this channel when he comes on shift, and we can get the bug preloaded with questions the experiments for him to run?
<smb> herton, I am not sure there will be a verification for bug 854050 in time, but it was verified in natty and had not the maintainer angered the gods of x86 maintenance it would be upstream. Can we except that from being reverted in Oneiric without explicit verification?
<ubot2> Launchpad bug 854050 in linux "BUG at /build/buildd/linux-2.6.38/mm/swapfile.c:255" [Medium,Confirmed] https://launchpad.net/bugs/854050
<brendand> skaet - he should be online in the late evening US time (taipei is +13??)
<brendand> skeat - 9 or 10pm apparently
<brendand> Eastern
<brendand> ctf
<bjf> brendand, i usually am still around when our taiwan folks start showing up
<brendand> bjf - feel free to add any questions to the bug for him
<herton> smb, hmm since it was ok in natty and tested, I think it could be marked as well, do you have a direct contact with the reporter or only through the bug? would be good to poke him if he can check oneiric, still there are some days left
<jsalisbury> ogasawara, I'll take a look at why the kt-meeting script has not run since the 15th.
<ogasawara> jsalisbury: cool, let me know if you need some help
<jsalisbury> ogasawara, ok, thanks.  The best way to learn something is to fix it when it's broken ;-)
<ogasawara> jsalisbury: I should have caught that last week, seemed to have missed it.
<brendand> bjf - i'll direct him to join this channel and read the bug
<smb> herton, Only contact is through the bug report. I'll put in a note there. Just wanted to speak up before to prevent it from getting suddenly reverted
<jsalisbury> ogasawara, np.  we moved some things over to cranberry from people while in Lexington.  May be related.
<herton> smb, ok, this is verification week for oneiric, we have until friday for it to be tested, lets hope we can get some testing, otherwise we may see what to do
<smb> herton, Ok, I assume you would start reverting next Monday? So we could decide then before doing so?
<herton> smb, yep, if on friday it's still not tested/no feedback on the bug, then we must decide
<bjf> brendand, i've added a comment to the bug and will monitor it. please make it a priority of your engineer
<smb> herton, ok
<brendand> bjf - it's absolutely their first priority
 * smb tries to make a big mental note to remember this on Friday
<ogasawara> tgardner: I see the non-pae discussion has hit the next tech board agenda
<ogasawara> tgardner: https://wiki.ubuntu.com/TechnicalBoardAgenda
<tgardner> I wonder who submitted it ?
<ogasawara> tgardner: I suspect we should wait to drop non-pae until after that meeting
<tgardner> ogasawara, bug #897786 is milestoned for A2. when is taht ?
<ubot2> Launchpad bug 897786 in linux "Kernel is dropping non-PAE flavour" [Undecided,In progress] https://launchpad.net/bugs/897786
<ogasawara> tgardner: Alpha-2 is Feb 2nd.  I think the tech board meeting is Dec 12.
<tgardner> ok, shuold be plenty of time
<smoser> smb, ping
<smoser> bug 897795
<ubot2> Launchpad bug 897795 in linux "-virtual kernel missing rtl8139 drivers" [High,Confirmed] https://launchpad.net/bugs/897795
<smoser> that is bad news.
<tgardner> smoser, in a virt kernel? why does anyone care ?
<tgardner> is it one of the emulated drivers ?
<smoser> "This driver is used in default configuration of openstack and of kvm also."
<smoser> kvm with no parameters gives you a 8139 nic.
<tgardner> smoser, hmm, ok. should be an easy fix.
<smoser> there were other changes there between the 2. i can post a list reqlly quick.
<tgardner> smoser, I assume Oneiric works OK ?
<Daviey> tgardner: Oneiric release did.
<tgardner> nothing has changed wrt 8139 between the 2
<kamal> is the kernel team meeting now, or one hour ago?
<smoser> tgardner, yes.
<smoser> http://paste.ubuntu.com/753890/
<herton> kamal, was one 1 hour
<herton> ago
<kamal> doh!
<smoser> ug. we lost the e1000 driver too
<smoser> and ne2k
<smoser> all of those emulated by kvm.
<tgardner> smoser, ah, they all changed locations in the source tree. 
<Daviey> gah, this happens /every/ release
<tgardner> the ethernet drivers were all reorged according to manufacturer
<smoser> ah. and the whitelists lost them.
<tgardner> smoser, yep. i'll go through and figure it out.
<Daviey> tgardner: is there a test we can add that spots when drivers and firmware gets moved upstream?
<Daviey> we seem to spot stuff accidently at the moment.
<tgardner> well, the inclusion list for virtual should have failed the build.
<Daviey> oh
<tgardner> Daviey, smoser: I'll figure it out.
<tgardner> if I can gert LP to respond
<Daviey> tgardner: good luck with that aspect :)
<Daviey> tgardner: Is it reasonable to expect this to be fixed on the day of A1 release?
<smoser> rephrase that, Daviey.
<Daviey> tgardner: Or rather, possible to squeeze this into A1?
<smoser> is it unreasonable to ask that a new kernel be uploaded in the next few hours?
<tgardner> Daviey, if you can talk ogasawara into an upload.
<Daviey> ogasawara: Hello
<ogasawara> Daviey: going to have to clear it with skaet and the release team.
<smoser> hte best justification i can find for it is that we found this less than 24 hours after the new kernel hit the archive. and the cloud images are DOA with it.
<Daviey> ogasawara: So.. Cloud images are the easiest entry point for our users to try precise at this stage
<Daviey> currently they can't 
<Daviey> ogasawara: I am on the release team, and will pursue that - but i wanted to see if it was viable first.
<Daviey> As in, can you get it all built in time etc.
<smoser> Daviey, wel.... to be fair, EC2 is the easiest.
<smoser> and that works.
<ogasawara> Daviey: arm takes the longest, approx 12hrs, to technically I could get it uploaded and built.  but not sure the additional impacts that has in terms of how long it takes to respin images etc.
<Daviey> ogasawara: Can we have it fixed for day of A1 release?
<smoser> cloud image build process would take 4 hours after archive entry.
<smoser> maybe 5
<ogasawara> Daviey: indeed I could have it queued and upload immediately upon A1's release.
<Daviey> ogasawara: thanks
 * Daviey bumps this to release.
<Daviey> #ubuntu-release
<herton> tgardner, do you remember any specific reason for us to not applying 2.6.35.14 stable to maverick? Otherwise I'll take a look at it
<tgardner> herton, likely just missed it.
<tgardner> 2.6.35 is no longer officially supported by stable, right ?
<herton> hmm I don't know. the last stable we applied was .13, and there were one more release (2.6.35.14)
<apw> ogasawara, whats missing for virtual ?
<tgardner> apw, upstream reorged the location of a bunch of the net drivers.
<apw> tgardner, 3.1 or 3.2 ? ... though even 3.2 was in the archive long before the last upload
<apw> is this just another case of not testing at all until freeze?
<tgardner> apw, I don't think the meta package for 3.2 was uploaded until recently was it ?
<apw> ogasawara, we had 3.2-rc2 up for some time didn't we ?  as the real kernel ?
<apw> i bumped it to -2 on monday yes, but -1 was already in
<ogasawara> apw: yep, although we'd held off uploading linux-meta for a little longer
<tgardner> which is what would have triggered the cloud image issues
<ogasawara> apw: but that did get uploaded last week
<apw> so it was in the archive from the 23rd, so they would have had bad images thursday and friday last week
<apw> so i guess i might let them off, might
<tgardner> apw, hard ass :)
 * apw is a little tired of finding we don't bother testing until its tooo late for us to spin
<bjf> apw, i update daily and i don't think i saw a 3.2 kernel until this weekend
<ogasawara> apw: I think we've at least settled that we won't upload the fix until after Alpha1
<tgardner> apw, I'm build testing a patch to fix the inclusion issues.
<bjf> apw, but i could be off a day
<apw> bjf, na, you arn't allowed
<bryceh> arges_, search against component xserver-xorg-video-intel for bugs tagged 'natty freeze'
<apw> bryceh, tha
<apw> bryceh, thanks
<bryceh> arges_, in fact I probably should move all those to 'linux' since they're all pretty much kernel drm bugs
<apw> yay more bugs we can't fix
<bjf> bring em on! 
<apw> bjf, more bugs to spam :)
<bjf> more karma
 * cking --> calling it a day
 * tgardner -> lunch
<bryceh> :-)
<arges_> bryceh, thanks will take a look
<arges_> still collecting more information at the moment to see if I can correlate with an existing bug first
<bryceh> arges_, I've been fussing with these types of bugs for years; if you give me some more details I may be able to make some analysis suggestions
<arges_> bryceh, sure 
<arges_> bryceh,  <3>[80750.499041] [drm:i915_do_wait_request] *E
<arges_> RROR* i915_do_wait_request returns -11 (awaiting 794226 at 794222, next 794227)
<arges_> <7>[80750.499132] [drm:i915_error_work_func], resetting chip
<arges_> <3>[80750.502624] [drm:init_ring_common] *ERROR* render ring initialization fail
<arges_> seeing this on ubuntu-natty on an x220 lenovo
<arges_> its completely unresponsive, can't use the mouse, can't ssh, can't even log in via serial console etc
<arges_> the person that collected this didn't grab any of the i915 debugfs stuff, so next time I asked that to be collected as well
<bryceh> arges_, wow, ok so not merely a gpu lockup
<arges_> it takes a long time to reproduce and its intermittent
<bryceh> right /sys/kernel/debug/dri/0/i915_error_state is good to collect, although in this case I'm not sure it's going to be relevant
<arges_> so grepping through the code I see that mm.wedged is probably true in i915_do_wait_request
<arges_> to give us the -EAGAIN error
<bryceh> arges_, the "*ERROR* render ring initialization fail" message sounds relatively unusual, it might be possible to search for it on bugs.freedesktop.org
<arges_> bryceh, the next set of tests are trying to turn dpms off and see if we hit, and now trying i915_semaphores=1 to see if we still hit errors
<arges_> ok
<bryceh> arges_, there are also some drm debugging flags that can be set, although they probably wouldn't produce anything interesting in this case.  drm.debug=0x04, etc.
<arges_> bryceh, yea we set drm.debug=0x04 for that log (had to get it via serial console which was a bit painful)
<bryceh> arges_, have you ruled out 3d?  IIRC we had  a slew of gpu issues with 3d paths in natty.
<arges_> bryceh, is there any easy way to turn that off?  
<bryceh> arges_, generally having the user run the 2d environment and not run 3d apps is sufficient, but you can forcibly disable it in X, one sec
<arges_> ok
<bryceh> Section "Extensions"
<bryceh>     Option "Composite" "Disable"
<bryceh> EndSection
<bryceh> in xorg.conf.  that should be sufficient 
<arges_> ok
<arges_> i'll make that suggestion
<bryceh> arges_, I also have a package called xdiagnose which has a set of simple workload scripts, which I find helps speed the system to lockup.  Useful for situations where the bug isn't reproducing very often.
<arges_> bryceh, awesome, is this in a ppa?
<bryceh> arges_, it's in oneiric
<bryceh> arges_, part of the default install
<arges_> ok
<bryceh> arges_, but you can just pull from lp:xdiagnose and run it on natty
<bryceh> indeed I did most of the dev work on natty so it should run without problem
<arges_> bryceh, perfect, I'll give it a shot and see what we can dig up. 
<bryceh> arges_, cool, good luck let me know how it goes
<arges_> bryceh, thanks
<jmais> Im trying to know if there some 'post-resume' uevent generated from kernel?
<jmais> asking because i need to reinitialize some devices (in userspace) after suspend, but since there are several ways suspend can be triggered (short of echo foo > /sys/power/state) there's no common way to do that
<tgardner> ogasawara, pushed a patch for bug #897795
<ubot2> Launchpad bug 897795 in linux "-virtual kernel missing rtl8139 drivers" [High,In progress] https://launchpad.net/bugs/897795
<ogasawara> tgardner: cool thanks.  I'll make sure it's prepped for upload on Thurs.
<jmais> ideas?
<apw> jmais, unsure if there is anything specific, you might run a udev monitor and see if it sees anything useful
* ogasawara changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues Dec 06 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<awsoonn> Hi all, I'm trying my luck at debugging a kernel oops that has been runing my day for about a week now....
<awsoonn> i am assuming I will need to build my own kernel with debugging symbols in order to make any headway? tips and guidance greatly appreacated.
<awsoonn> Is there some documentation I can start chewing on? bug 897883 btw
<ubot2> Launchpad bug 897883 in linux "Kernel Oops" [Undecided,New] https://launchpad.net/bugs/897883
<apw> awsoonn, debugging symbols for all kernels is available at ddeb.ubuntu.com
<apw> awsoonn, are you using alsa-sink ?
<apw> awsoonn, if this started about a week ago you may have had a kernle update in that time, it may be worth going back to an older kernle and seeing if that stops the panics
<apw> awsoonn, you have 3.0.0-13 in your panic string so perhaps 3.0.0-12 which you should still have
<jmaiss_> any comments on bfq vs cfg scheduling?
<jmaiss_> more specifically whether a system would support one and not the other?
<apw> wamty, cfg? cfq ?
<awsoonn> apw I was assuming it had somethign to do with teh update
<apw> awsoonn, yep added some info to to the bug, but basically we need to go back till you find the first stable kernel
<awsoonn> apw, is the 'panic string' you're refering to the "... tanted: P C ..."
<apw> awsoonn, and report the last good and first bad kernel, so we have an area to search in
<apw> i am keying there off the 'IP:' lines, of which there is one per panics
<awsoonn> kk, i'll hop on over... I've got to do some trickery with virtualbox though. I've recently upgraded it and the dkms module is preventing me from booting the old kernel. :(
<awsoonn> btw, thanks for teh help
<awsoonn> I've always wanted to get my hands into the kernel, this seemed like a good chance. :)
<wamty> I made some kernel updates using update manager and I canÂ´t access to ubuntu anymore.. grub screen changed to a black screen and when asking for my login and password does not accept them..Does anyone knows how to solve it? Could you guys help me? Thanks..
#ubuntu-kernel 2011-11-30
<jussi> pgraner: lamont et al, are you happy with jsalisbury being added to the ops team in here?
<apw> jussi, (depending on whether i count as et al) jsalisbury gets my vote
<jussi> apw: you do count :) Ill get it done at some point in the near future. if anyone has an issue with it, PM me. 
<apw> jussi, thanks :)
<stephan> hello.
<stephan> on ubuntu oneiric ocelot with kernel 3.0.0-r13-generic i had kworker issue (cpu load: 80% or more).
<stephan> i installed a kernel 3.2 ... then after installation if rebootet to old kernel 3.0.0-r13. now no problems with kworker.
<stephan> someone knows how to find out?
<jussi> [11:16:22] [ChanServ] Flags +votiA were set on jsalisbury in #ubuntu-kernel.
<jussi> apw: pgraner jsalisbury ^^^
<apw> jussi, thanks, will poke him to test when he is about
<jussi> apw: this is a useful doc if you need it: https://wiki.ubuntu.com/IRC/IrcTeam/OperatorGuide
<jsalisbury> jussi, apw channel op works for me.  Thanks, jussi!
<lamont> jussi: I get no vote here
 * herton -> lunch
<bjf> brendand, bug 897773
<ubot2> Launchpad bug 897773 in linux "[Acer AR320 F1 and Acer AR160 F1] Halting shortly after booting with Lucid (2.6.32-36.79) -proposed kernel" [Undecided,Incomplete] https://launchpad.net/bugs/897773
<bjf> brendand, doesn't look like he did anything i asked him to do, however it now looks like the issue has "gone away", comments ?
<brendand> bjf - well, the issue hasn't 'gone away' but it turns out it does affect the release kernel
<bjf> brendand, i don't see any comments like that on the bug
<bjf> brendand, i see the comment on the tracking bug
<brendand> bjf - sorry, i'll update it in the bug itself
<bjf> brendand, is that system supposed to have been certified for lucid ?
<brendand> bjf - it is
<brendand> bjf - it was certified just fine with 10.04.2
<bjf> brendand, so the regression is between 10.04.2 and 10.04.3 ?
<brendand> bjf - that's what it looks like at the moment. he hasn't got around to trying the 10.04.2 image yet. i'll try and do that today, at least for the release kernel
 * ogasawara back in 20
<bjf> brendand, does that mean you have access to the HW now and can test kernels ?
<brendand> bjf - supposedly. i haven't tried in anger yet
<skaet> ogasawara,  could you tweak and improve the kernel overview comments I put in the https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview?  (when you get back)
<bjf> skaet, you may want to glance over the scrollback (the interaction between myself and brendand)
<arges> bryceh, hello, got a better log from our gpu hangs on the x220 machines here http://paste.ubuntu.com/755004/ this is with a 64-bit kernel, 32-bit seems to behave differently
<ogasawara> skaet: ack, will do
<skaet> thanks ogasawara :)
<stephan> on ubuntu oneiric ocelot with kernel 3.0.0-r13-generic i had kworker issue (cpu load: 80% or more). i installed a kernel 3.2 ... then after installation if rebootet to old kernel 3.0.0-r13. now no problems with kworker.
<stephan> after rebooting the old kernel 3.0.0-r13 there wasnt kworker issue anymore. any suggestions?
<tgardner> meh. 'Sorry, something just went wrong in Launchpad.'
<Razec> Where Can I find kernel's bug from ubuntu 11.10?
<bjf> Razec: all bugs are filed in launchpad
<Razec> bjf, ok, I asked because I not found a specifically option to ubuntu 11.10. But I'll take a look. Thanks so much.
<Razec> bjf, I got it
<Razec> https://launchpad.net/ubuntu/+milestone/ubuntu-11.10
<Razec> tks
<Laibsch> Is bugzilla.kernel.org not going to come back?  It's been more than two months since the outage and there's no information on what the plan is.  I'd like to offload kernel bugs upstream but mailing list? dunno.
<arges> tgardner, howdy. looking at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/769927 . There is a cherry picked patch that fixes this issues for natty, and I found that that patch is already in oneiric. What should I change the status of the Affects linux->Oneriric field? thanks 
<ubot2> Launchpad bug 769927 in linux "Kernel Oops : Dentry still in use (1) [unmount of nfs4 0:1d]" [Undecided,Confirmed]
<tgardner> arges, I set it to fix committed
<arges> tgardner, ok thanks
<tgardner> checking to see if its been released
<tgardner> arges, yep, looks like it came with 3.0
<tgardner> arges, I suppose you'll be wanting a cherry-pick next ?
<arges> tgardner, got the cherry pick, typing up the SRU email
<tgardner> arges, ack
 * tgardner -> lunch
<patrickmw> jsalisbury, hey I updated bug 897866.
<ubot2> Launchpad bug 897866 in linux "NFS install fails with a kernel panic" [High,Confirmed] https://launchpad.net/bugs/897866
<patrickmw> bjf, ^ this bug is stopping me from running boot speed tests
<bjf> tgardner: ^
<tgardner> patrickmw, do you know that the configuration is correct? i.e., does it work with natty or lucid? I would expect it fall back to busybox instead of panicing.
<patrickmw> tgardner, it worked with isos before 20111129.1
<tgardner> patrickmw, thats about the time we uploaded the kernel meta package that would have referenced the 3.2 kernel
 * herton -> eod
<rik_> sforshee: can I bug you about bug 606238 again?
<ubot2> Launchpad bug 606238 in linux "synaptic touchpad not recognized on dell latitude e6510 and others" [Undecided,Confirmed] https://launchpad.net/bugs/606238
<sforshee> rik_, sure
<rik_> I've attached two logs as described on your blog to the bugreport.
<rik_> but I'm not sure they contain what is needed to further debug this
<rik_> what should I do in the vm once the driver is installed? simply move around and try scrolling etc?
 * sforshee looks at the logs
<sforshee> rik_, once you have the windows driver installed in the VM you want to make sure it really is working
<sforshee> so you should try to do whatever works under bare-metal windows -- scrolling, etc
<rik_> I checked the device manager and it said it was a dell touchpad. I was also able to scroll using the right side of the touchpad
<sforshee> good, so the driver works
<rik_> I can also enable more options using a control panel applet, such as two-finger scrolling etc but all the options are disabled in the log
<sforshee> do either of the logs you attached represent a trace from when you know the windows driver is working?
<sforshee> because the data looks like normal PS/2 to me
<rik_> the 'without' is without the drive rinstalled. the 'with' one is with me scrolling
<rik_> hmm
 * rik_ will create another dump
<sforshee> rik_, perhaps the "with" dump is different
<rik_> yes, "with" is with the driver installed
<rik_> "without" is without the driver installed
<sforshee> it actually looks like a 6-byte protocol, I just didn't look close enough
<sforshee> so you've got a good start!
<rik_> I'm making another dump with two finger scrolling options, and rotating enabled
<sforshee> rik_, what you really need from the first dump is the initialization, so what you have is good for a starting point
<rik_> ok
<rik_> my last dump has me two-finger scrolling, two-finger rotating and two-finger zooming
<rik_> I will also upload it 
<rik_> is this enough information to determine what the correct settings for the alps.c file should be?
<rik_> the latest dump is attached
<sforshee> it's certainly enough to get started
<rik_> to be honest I have no idea where to go from here, so I hope you can find some time to have a look at it in the near future
<rik_> the 6-byte protocol is not one of the current V2,3,4 protocols?
<sforshee> i can't tell, but you have to get past the initialization before any of that matters
<rik_> ah ok. I assume the init is in the beginning of the file and are the three values in the alps.c file that should respond in some way?
<sforshee> it's more than that. look at the hw_init functions
<sforshee> it's definitely not the same as v3 or v4
<rik_> you're right, it seems a lot more complex than a few values
<rik_> and out of my field of expertise
<yofel> hey, Is there a way to freeze the system during boot? 3.2.0-2 in precise doesn't boot on my thinkpad t510, and I can't read the error as it's thrown so often that I can't read it
<sforshee> rik_, I don't anticipate being able to spend a lot of time on this in the immediate future. I'll try to look at it deeper when I have some time. If you want to dig in further in the meantime I can give you some assistance
<rik_> sforshee: OK, what can I do?
<sforshee> you might want to start by taking a look at this as an general PS/2 mouse introduction: http://www.computer-engineering.org/ps2mouse/
<arges> yofel, you can boot with a working kernel and read through an older /var/log/dmesg.0,  /var/log/dmesg.1.gz, etc
<yofel> arges: problem is that I would need a mounted rootfs for the logs, but the kernel doesn't get past initrd from what I see
<yofel> I'll try 3.2.0-999.201111300416 for now
<sforshee> rik_, in your dumps, you'll notice blocks that start with the driver sending a reset (ff) and end with it enabling data reporting (f4)
<arges> yofel, you deleted the older kernels? 
<yofel> nope, 3.1.0-2 boots fine
<yofel> but 3.2.0 didn't write anything to the logs
<rik_> sforshee: yes, I scrolled down on the page you sent and noticed the flags in the log
<sforshee> rik_, the parts in between are initializations. it would be good to try to figure out what the initialization is doing, but that's also difficult. you can simply recreate the stream of commands in the alps driver though to get started
<rik_> sforshee: where exactly in the alps file should I do that?
<rik_> sforshee: so I should focus on everything between the ff reset and f4?
<sforshee> rik_, just make your model use a new protocol version, e.g. v5. add a v5 initialization function to send the initialization you need
<sforshee> then I'd make alps_process_byte dump the data and exit
<sforshee> you'll want a USB mouse to use while you're doing this
<rik_> can you elaborate on "make alps_process_byte dump the data and exit"?
<sforshee> if you send the initialization correctly the data you see should look similar to what you see in the dumps you took
<sforshee> are you using the code from the dkms packages I made?
<rik_> I believe it's based on a version 10 
<rik_> is that possible?
<sforshee> yes, that's possible
<sforshee> just a second, let me get that code
<sforshee> so you should see a function named alps_packet_dump, right?
<rik_> sforshee: yes
<sforshee> okay, where that's being called in alps_process_packet -- change alps_packet_dump to be called unconditionally, then return
<sforshee> that will stop the driver from trying to process the data
<yofel> k, 3.2.0-999.201111300416 boots, but has no iwlagn module, 3.2.0-2 fails pretty fast with what seems to be a DRAM error (like 100 errors / sec)
<sforshee> rik_, but you need to be sure that you set psmouse->pktsize to 6
<rik_> in the alps_init function for my V5?
<rik_> sforshee: would you mind adding this info to the bug report and/or blog about it?
<rik_> other can help out as well then
<rik_> I hope my chat client is logging this :-)
<sforshee> rik_, I'll see if I can think of something fairly generic to post, but it's really rather ad-hoc. I'm just making it up as I go :)
<rik_> sforshee: do you have a dump for the v3 and/or v4 you added to the file? That way I can compare how you do the init there?
<rik_> if I change the routines for v3 with the unconditional dump, would that work? v3 has 6 for pktsize?
<rik_> only v4 has 8, or is it the other way around?
<sforshee> rik_, I don't think I have any posted anywhere, but I also don't think they would prove very helpful. Yours looks substantially different
<sforshee> only v4 has 8, so if you add a v5 version it should end up with 6 as it is now
<rik_> sforshee: I would like to see their init and see how you have translated that into code
<rik_> ah ok
<sforshee> rik_, http://people.canonical.com/~sforshee/alps-touchpad/latitude-E6520-sniff.txt
<sforshee> that's a v3
<sforshee> but it will be hard to follow. The driver doesn't just replicate the sequence directly
<rik_> sforshee: ok, I'll have a look at this. But it's getting late now. I'll read the docs you mentioned and will come back here when I find some time to look at this
<rik_> sforshee: thanks for the help so far!
<sforshee> rik_, np. Feel free to ask more questions as the come up.
<rik_> sforshee: don't worry, they will come up
<rik_> sforshee: the file you gave has blocks of sequences that do specific things like set the sensitivity? They are not a simple replay of everything?
<rik_> what does an e6 and e7 do?
<sforshee> rik_, the v3 and v4 initialization uses a register access protocol that involves switching modes, reading and writing to registers
<sforshee> it's fairly convoluted
<rik_> does my dump look like something similar? How can I know/"see" this?
<sforshee> there's a command sequence to enter "command mode" where the registers can be read and written -- ec ec ec e9
<sforshee> then ea exits command mode
<sforshee> in your dump i see it enter and exit command mode, but pretty much everything happens when a v3/v4 touchpad would not be in command mode
<rik_> I guess my last dump is more interesting then, as it has more features enabled?
<sforshee> i can't tell. All i really know is that it's different
<sforshee> most of your initialization doesn't happen in command mode
<rik_> in your dump it always responds with fa to a successfull command?
<sforshee> or else the way to getting to command mode is different, or it doesn't have command mode at all
<sforshee> the fa response is standard ps/2
<rik_> sforshee: I have to go now. Thanks again for your time. If you find time to look at this, please do. I'm sure you'll beat me to it ;-)
#ubuntu-kernel 2011-12-01
<idempotent> I am trying to rebuild the kernel one of the "proper" ways, based on the Kernel/Compile wiki page.  I am stuck when trying to tweak the config.  For example (for no real reason), I removed the BTRFS module.  Now I get an error, "MISS: btrfs" ... "EE: Missing modules (start begging for mercy)"...
<idempotent> (sorry, can't pastebin, as error is on another unconnected computer)
<idempotent> kernel source was installed using "apt-get source --only-source linux", config was edited with debian/rules editconfig (changed the amd64 {generic,preemt,server} configs), and built with "AUTOBUILD=1 debian/rules binary-debs"
<idempotent> what am I doing wrong?
<RAOF> idempotent: The âproperâ way includes a bunch of cheks to ensure that the config matches kernel policy.  If you're breaking policy with your config changes (such as disabling btrfs) then you'll need to skip those checks.
<idempotent> note that a pristine build works (unaltered config)
<idempotent> RAOF: the check-config results at the end of editconfigs came up clean
<idempotent> "21/21 checks passed -- exit 0"
<RAOF> Oh, right.  Of course.
<idempotent> I figured BTRFS would be a module I could remove with little/no dependency effects
<RAOF> Yeah, but it's changed the kernel ABI which has raised the checking flags.
<RAOF> Basically you just want to ignore the ABI checker.  And, in fact, all the checks.
<idempotent> happy with it changing the ABI, and noticing that.  Seems "right" behaviour.  Just need to figure out why things have broken
<bjf> idempotent: are you following https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel ?
<idempotent> so I should try with something like "skipabi=1"?
<RAOF> Yeah.  I forget quite what all the flags are.
<bjf> idempotent: if you are having trouble with abi, look at: https://wiki.ubuntu.com/KernelTeam/KernelMaintenance  and search for "skipabi"
<idempotent> bjf: only just saw that, but, yes, it's pretty much what I'm doing
<bjf> idempotent: the first one i mentioned is pretty straight forward, the second one covers a multitude of issues and isn't very well organized
<idempotent> bjf: thanks, the first one is not working for me.  I do editconfigs and then binary-server, and it fails
<idempotent> bjf: I am trying teh second one now - will try with skipabi=1 first, but I think using dch to change the ABI in the changelog is a better way to go
<bjf> idempotent: which kernel are you trying to build ?
<idempotent> bjf: lucid.  Build machine is a VM rnuning 11.10
<bjf> idempotent: are you building using apt-get source or git clone ?
<idempotent> apt-get source
<bjf> idempotent: do you run into errors early in the build or towards the end ?
<idempotent> towards the end in the sense that it takes maybe 30min to get to the error (though rerunning the command immediately gets me to the error quickly).  As soon as I do editconfigs, then it will be a "long" build time again
<bjf> idempotent: ok, did you try just building the sources before making any changes ?
<idempotent> bjf: yes, a pristine build successfully produces deb files
<idempotent> bjf: I also did a compare on all files in debian.master/config and noted that the changes made sense (after understanding splitconfig.pl and kernelconfig scripts)
<idempotent> "changes made sense" = "changes after debian/rules editconfigs made sense"
<bjf> idempotent: then i guess i'd suggest skipabi=true skipmodule=true  (see the second url i posted)
<idempotent> bjf: diong a build with skipabi now but not skipmodule.  Will try with skipmodule if the Bump ABI process doesn't work
<bjf> idempotent: sounds like you are very close, and it is getting hung up in some of the automated checking that happens towards the end
<idempotent> but, skipabi sounds like a workaround, right?  I shouldn't need to do this
<bjf> idempotent: it depends on what config changes you are making
<bjf> idempotent: i've got to turn in now, there will be some other kernel devs comming on soon
<idempotent> sure.  I'm happy to have the ABI bumped (I think)
<idempotent> so skipabi=1 made no change.
<idempotent> Did dch -i and added some stuff, then redid the debian/rules binary-server - gets the same error immediately
<idempotent> everything gets me the error quickly.  Am doing a clean
<idempotent> still no joy.  Failing any other suggestions, I think I might raise a bug on the kernel?
<idempotent> other clue: my VM is 11.10, but I am chrooting to a debootstrap of lucid, including the lucid-{updates,backports,security} repos
<idempotent> trying it with an oneiric kernel in an oneiric chroot
<idempotent> I am afk for now, back in about 16 hours or so
<idempotent> RAOF: thanks
<idempotent> bjf: thanks
 * smb yawns
 * apw yawns too
 * diwic notices that https://wiki.ubuntu.com/KernelTeam/KernelUpdates and https://wiki.ubuntu.com/Kernel/Dev/StablePatchFormat are not exactly synced...
<smb> diwic, You could change that... ;)
<diwic> smb, of course, if you all will abide to my new rules ;-)
<smb> diwic, I'd rather say that the former seems quite old... 
<diwic> smb, hmm, that's bad, I think I just followed the former 
<smb> diwic, So what did you find was conflicting?
<diwic> smb, take the subject line, for example, one of them specifies things such as "UBUNTU: SAUCE: (pre-stable)" whereas the other does not seem to care
<diwic> smb, one specifies sru justification in the bug, the other in the email
<diwic> or maybe I became confused and did a mix-up
<diwic> of both procedures
<smb> Well the second seems more concerned with the look of the patch itself and we wrote that up later. Mostily to clarify all those different SAUCE or not and UBUNTU or not questions
<smb> The justification should go into the bug report. Both versions should hopefully say that
<smb> Ah I see
<smb> Probably can be clearer. Mainly it should be in the bug report. And having them in there, you may copy it into the description/introduction area of the email
<smb> Just as an additional helper for the person reading the email. To understand the issue, and because you had to write the whole thing in the report already
<smb> The second document is more concerned about the actual patch (not caring that much about anything around it)
<diwic> smb, could you or someone else take an action item on the next kernel team meeting to unify both wiki pages or make one link to the other?
<smb> diwic, No, this is what I try to explain
<smb> Its two things
<smb> But it assumes that when you send an email with a patch for sru review, you got two parts
<smb> 1. some introduction/description which is not part of the patch
<smb> 2. the patch either inlined, attached or sent as a follow up
<diwic> hmm, but does the patch have a subject line in that case?
<smb> diwic, If you export it with git format-patch, yes
<smb> (it is the commit title)
<diwic> that does not make sense either with the current text
<diwic> how could a patch's subject line say [pull request] ?
<smb> I think I see the confusion 
<smb> That should not be for the patch itself, that would be the subject of the whole email (thread)
<smb> Its probably a bit special with pull-request anyway because there you have the patches themselves in a repo
<apw> and actually git am ignores all the crap in [xxx] by default
<apw> so you can add [Oneiric SRU] [PATCH 1/2] and those will not get added to whats committed
 * apw reboots
<smb> apw, Oh well. I thought it only would ignore the [PATCH.*] parts... If it ignores anything in [] it would make the need for slightly different subjects less important...
<apw> smb, pretty sure its evertying in []'s, as i don't tkae special action when applying SRUs
<apw> smb, the manual implies it strips [PATCH <anything>] from the title
<apw> now i can't remember if everything is that form by luck
<smb> apw, Yeah, seems to be more like a any [] at the beginning
<smb> Just tried
<smb> [oneiric] [PATCH] UBUNTU: [bla]
<smb> becomes 
<smb> UBUNTU: [bla]
<apw> so any [] prefix then, fair enough
<cking> was that by design or just luck that we chose to use [] as a prefix then?
<smb> right. but anyway I would be too lazy to add something to the patch subject which goes away when I got the other subject
<apw> cking, no because its a common idiom 
<smb> cking, Maybe luck that it is more. But [PATCH.*] was common before
<cking> ok, just wondering..
<apw> that git am splunges it just makes it handlier
<ogra_> apw, the tech overview page for A1 says "Set CONFIG_PANEL_DVI=y on arm" ... mind if i set that to "on omap" ? "on arm" is pretty unprecise 
<apw> ogra_, seems more correct to me, go ahear
<apw> ahead
<ogra_> thx
<ogra_> done
<apw> ogra_, got a link to the notes so i can review them in general
<ogra_> https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview
<apw> that overview is rather, erm, crap
<ogra_> fix it then :)
<apw> ogra_, yep, will get with ogasawara to do that
<bjf> jsalisbury, there are more than 25 bugs on the hot list
<ogra_> apw, for https://blueprints.launchpad.net/ubuntu/+spec/ubuntu-arm-p-optional-initrd do you have any idea when the kernel team item on this might be ready (i would like to add the WI to a milestone)
<apw> ogra_, stick an A2 on it and then we'll find out :)
<ogra_> will do :)
<bjf> apw, before you start whining (:-D), yes you are getting a double dose of the Morning Bug Report today. This one includes the top 10 bugs from the hot list. 
<apw> bjf, *zip*
 * bjf notes that the top 10 is wrong, it's in fact the bottom 10 from the list
<jsalisbury> bjf, I'll go through the list and reduce it to 25
<jsalisbury> bjf, any bugs with the iso-testing tag automatically get added.  maybe we want to change that?
<bjf> jsalisbury: yes, i think so, they should be automatically added to your, da list, but only the "hot" ones included on the hot list, though maybe iso-testing should push non-iso-testing ones from the list
<bjf> tgardner, apw, ogasawara, ^ what do you think ?
<tgardner> yeah, just 'cause they are ISO testing bugs doesn't make 'em any hotter then bugs found independently.
<apw> tgardner, right unless they are stopping a release, ie just before a milestone
<apw> and i am sure we'll hear about those pretty quickly
<tgardner> apw, as will independently discovered bugs is they are stopping a release. my point is that ISO testing has no bearing on the hotness of a bug. its merely another vehicle for performing some testing.
<bjf> tgardner: i'm not sure that is how others are treating it, though pgraner would know for sure
<pgraner> bjf, iso testing bugs are "hotter" than others, this is due to the fact some (weather automated or manual) has tested specifically for the milestone. We as a team have a requirement to make sure they are triaged within a week of the milestone.
<pgraner> tgardner, jsalisbury: ^^^^
<bjf> pgraner, the hot list is for bugs that are probably already triaged and are ready to be worked for a fix
<bjf> pgraner, i don't think that changes how we will deal with iso-testing bugs
<pgraner> bjf, my point was not what list they lie on per se but they iso-testing bugs are a bit different
<pgraner> s/they/the/
<bjf> pgraner, ack
<pgraner> tgardner, I forgot who the macs go to, can you refresh my memory?
<pgraner> tgardner, I thought one of each was to go the sforshee for enablement and the others?
<tgardner> pgraner, eventually Q/A should get one of each, but I thought we'd try 'em out first to see what kind of bugs we're having. 
<tumbleweed> seeing a lot of ath9k-related kernel panics with the current precise kernel (a couple a day) bug 898658
<ubot2> Launchpad bug 898658 in linux "Lots of ath9k related kernel panics" [Undecided,New] https://launchpad.net/bugs/898658
<tgardner> I'd say send a Pro, air, and mini to Seth initially.
<pgraner> tgardner, ok, I thought we slotted one for cjwatson for mac boot issues
<tgardner> pgraner, do we know there are issues yet ?
<pgraner> tgardner, we hit a few on release week IIRC and that was one of the reasons that prompted us getting them
<tgardner> send me one of each and I can probably work through the issues with cjwatson. he doesn't want anymore HW anyways.
<tgardner> I'll probably end up send one around to cking to do some power profiling.
<cking> tgardner, I'm up for that
<tgardner> as far as I can tell, they are all 3 very different machines.
<jsalisbury> pgraner, bjf, I will make it so the iso-testing bugs are automatically added to the DA hotlist: http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/_kernel_da_hot_.html
<jsalisbury> pgraner, bjf, from there I can move them over to the kernel team hotlist once triaged
<jsalisbury> pgraner, bjf, I check the DA hotlist very frequently
<bjf> jsalisbury, that sounds like a reasonable workflow, note when you are out on holiday or are sick we'll need someone else to monitor that report as well
<jsalisbury> bjf, right.  I'll be sure to clear all time off with the team and ensure there is coverage
<cyphermox> tgardner: you had done a MIR in the past for iw, fyi, I'm writing a new one now (iw is needed by crda)
 * herton -> lunch
<tgardner> cyphermox, yep, I noticed from pitti's dependency graph. isn't iw just recommended by crda ? I haven't looked at the packaging recently.
<cyphermox> tgardner: yeah, it's just a recommends, but iw is a verynicetohave anyway, I think.
<cyphermox> tgardner: I for one would be happy with just iw and ip ;)
<apw> tgardner, recommends have to promoted, suggests not i believe
<apw> we always install recommends iirc
<tgardner> cyphermox, I'm fine with it. iw is well supported upstream and is the preferred tool. it should probably become a depends.
<cyphermox> ok
 * ogasawara back in 20
<cyphermox> tgardner: done, I subscribed you to the bug.
<tgardner> cyphermox, ack
<bjf> apw, you have any insight into whether bugzilla.kernel.org is ever coming back ?
<apw> bjf, that is an interesting question, i have heard nothing about it no
<apw> bjf, i am starting to think that people screaming for it is required
<tgardner> bjf, rumor is that it will reincarnate in some form some day.
<bjf> apw, i wonder if jjohansen or kees would know
<bjf> tgardner, i wonder if they'd like "someone" to host it for them, in the cloud maybe
<tgardner> bjf, I don't think hosting resources is the issue. last I read on LKML its being worked on....
<bjf> tgardner, yes i see an email on the 11th that indicates they are waiting for HW to be put in place
<tgardner> bjf, I agree that the pace is glacial, but you get what you pay for.
<bjf> brendand, do you have a gameplan for bug 897773 ? where is it priority wise for you ?
<ubot2> Launchpad bug 897773 in linux "[Acer AR320 F1 and Acer AR160 F1] Halting shortly after booting with 10.04.3" [High,Incomplete] https://launchpad.net/bugs/897773
<jsalisbury> bjf, herton The following bug prevents the Oneiric server flavour from booting on Dell PE 2950.  The generic flavour boots fine: bug 897243
<ubot2> Launchpad bug 897243 in linux "Dell PowerEdge 2900/2950 crashing with Ubuntu Server 11.10" [High,Triaged] https://launchpad.net/bugs/897243
<brendand> bjf - pretty high. it's what ctf is working on as first priority at the moment. mainly to find out what's going on, since it seems more and more to not be something that is very likely to be triggered in normal use
<bjf> brendand, ok, i'm keeping an eye on the bug. have seen no updates in the last 24hrs
<bjf> brendand, thanks for the info
<brendand> bjf - i'll talk to him about keeping the bug up-to-date properly
<apw> ogasawara, yo ... infinity could really do with the armhf fix uploading as its holding up the bootstrap
<apw> ogasawara, how far from the next upload are we.  if its days then we probabally should do a non-abi upload of the armhf commit
<tgardner> apw, this is thutrsday. I think she was planning an upload as soon as A1 is released.
<ogasawara> apw: I'm planning one today, right after Alpha1 releases
<tgardner> jinx
<ogasawara> heh
<apw> ogasawara, then that should make infinity happy.  i think the freeze may be done
<apw> 12:30:27      pitti | ... lifting freeze, happy uploading!                                                    â AaronMT
<apw> ogasawara, ^^
<herton> jsalisbury, about this bug, I took a look, doesn't make much sense the config difference between generic/server causing the issue, well may be it's a timing issue. They seem to be complaining about controllers not being found, can be some problem in megaraid_sas with 3.0 kernel
<ogasawara> apw: ah, so it is.  I thought it didn't lift until the actual announcement gets sent out
<apw> ogasawara, its cirtainly unclear to me
<ogasawara> apw: where did you see pitti mention that?
<apw> ogasawara, that is on #ubuntu-devel
<ogasawara> apw: just got clarification.  since we won't be respinning anything so it's ok to upload.  but for future reference we should typically wait of the announcement to note the archive is unfrozen.
<apw> ogasawara, that makes little sense.  if #u-d topic says we are unfrozed, what are we
<apw> ogasawara, i am sure we cna wait until the freeze is announced over
<ogasawara> apw: we're unfrozen, even without the announcement having been sent out.  but I this is a one time scenario.
<ogasawara> apw: I've gotta bail here in 10min for the dentist anyways.  I'll just wait till I get back to upload.
<apw> ogasawara, seems reasonable to me
<apw> ogasawara, i'd say have a good one, but its the dentist, so, erm
<ogasawara> heh
<jsalisbury> herton, Yeah, they report the filesystem goes read only when running the server flavour.  I'll see if they can post some logs after the server goes read only.
<herton> jsalisbury, may be it's a kernel and an installer/initramfs issue, they say the kernel installed from the installer doesn't boot, but installed manually boots. Also comment #17 indicates may be personality to report as kernel 2.6.x could be needed, or at least to use some of that OMSA tools, although if they say kernel 3.2.x may I don't know, this may be just noise.
<herton> *s/may/if they say kernel 3.2.x works flawlessly then/
<bjf> herton, we have a PowerEdge 2950 in-house. i'm trying to determine how we can go about getting testing done on it
<herton> ok
 * apw calls it a day, some errands to run
<cking> http://reports.qa.ubuntu.com/reports/boot-speed/
<cking> so my only gripe is that we need multiple runs to just get an idea of the kind of variation we can expect to see 
<cking> and if it's automated that shouldn't be hard to do should it? ;-)
<tgardner> cking, your _only_ gripe? I'll hold you to that :)
<cking> heh
<cking> well, I don't like the colors too
<brendand> which kernel version was just before the one for Alpha1?
<tgardner> brendand, its been a 3.2-rc{12} kernel for a bit
<brendand> tgardner - ok, the webcam has stopped working on my netbook. i'm sure it was yesterdays respin that did it. maybe it's a different package that's the problem
<tgardner> brendand, yeah, there hasn't been anything significant in a week or so
 * cking kicks a machine into a first round of intensive soak tests - back later
<jsalisbury> hggdh, When you have a chance, can you test the 3.2.0-2.5 kernel for bug 894070
<ubot2> Launchpad bug 894070 in linux "IOMMU error loop early in boot" [High,Triaged] https://launchpad.net/bugs/894070
<jsalisbury> hggdh, I'd like to do a bisect, but want to confirm the issue is still in the latest kernel.
<luis_> hi there! i'm needing help regarding how to install the newest kernel in order to solve this bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/898615
<ubot2> Launchpad bug 898615 in linux "[Presario C500] Hibernate command fails and returns to userspace" [Medium,Confirmed]
<luis_> i've downloaded and installed the .deb header from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2-rc3-oneiric/
<luis_> but it doesn't show in the GRUB boot screen
<luis__> hi there! i'm needing help regarding how to install the newest kernel in order to solve this bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/898615
<ubot2> Launchpad bug 898615 in linux "[Presario C500] Hibernate command fails and returns to userspace" [Medium,Confirmed]
<lool> apw: Hey!
<lool> apw: infinity tells me you're working on the linux/armhf FTbFS
<lool> apw: I have this http://paste.ubuntu.com/756182/, but it's untested
<luis__> hi there! i'm needing help regarding how to install the newest kernel in order to solve this bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/898615
<ubot2> Launchpad bug 898615 in linux "[Presario C500] Hibernate command fails and returns to userspace" [Medium,Confirmed]
<dantti> Hi, I'm trying to provide a patch to the upstream kernel but weirdly I'm not being able to install the upstream kernel it does not create the /lib/modules/kernel-version, I did make menuconfig (with .config from /boot), make and make install (even tryied make modules install but afair it wasn't needed), any tips on what I might be missing? 
<dantti> I'm on 11.10 and I have a clone of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git
<dantti> it compiles fine but emits some FATAL saying modules.dep does not exist which is true as /lib/modules/... does not exist..
<bjf> tgardner, wrt bug 790863 will we ever re-enable CONFIG_NET_NS ? or should we "Won't Fix" the bug ?
<ubot2> Launchpad bug 790863 in linux "Unable to start lxc container after update to 2.6.32-32" [Critical,Confirmed] https://launchpad.net/bugs/790863
<tgardner> bjf, checking
<bjf> ogasawara, i'm looking at bug 843892, what does it mean that the linux-lts-backport-natty package has a Oneiric task ?
<ubot2> Launchpad bug 843892 in linux-lts-backport-natty "Repeatable kernel oops on container delete" [Medium,Confirmed] https://launchpad.net/bugs/843892
<ogasawara> bjf: hrm, dunno.  I'll look.
<hggdh> jsalisbury: will test now
<ogasawara> bjf: I'm not sure why that linux-lts-backport-natty task was even added to that bug
<bjf> ogasawara, i'm only asking because you are the one that added the nomination
<bjf> ogasawara, i think both of those tasks should be "Fix Released" anyway, i was just confused
<ogasawara> bjf: I added the nomination for the linux task, which lp then automatically assumes it should open a nomination for all the present tasks
<bjf> ogasawara, how helpful that is
<ogasawara> bjf: yah, just close those out
<bjf> ogasawara: done
 * cking preps 2 more boxes for soak testing overnight and calls it a day..
<bjf> cking, don't you waste a lot of water doing that? or do you spread that on the garden tomorrow after the test?
<cking> lulz
<cking> bjf, I wondered why putting the boxes on the bath caused them to be unreliable...
<bjf> cking, shoddy HW
<hggdh> jsalisbury: fails the same on 3.2.0-5. I do not know if it affects or not, but this is a system with encrypted LVM, multiple filesystems under the encrytped LVM
<vanhoof> herton: should bug 794642 be Fix Commited for natty, and have a verification-needed-natty tag?
<ubot2> Launchpad bug 794642 in linux "[Dell optiplex 390][SFF] Dvd drive not recognized by system" [High,Fix released] https://launchpad.net/bugs/794642
<vanhoof> herton: looks that way from ubuntu-natty.git
<vanhoof> just wanted to confirm
<herton> vanhoof, it was verified for natty, but looking at bug history ming changed manually from fix commited to fix released after verification, it wasn't needed, so just be fix commited yet, once release the janitor automatically sets to fix released
<herton> *so it should be just fix commited yet
<vanhoof> herton: ack, fixed it up
<vanhoof> herton: thanks for the confirmation
 * tgardner -> lunch
<jsalisbury> hggdh, thanks for testing.  We may have a few more test kernels from the bisect.  Did you have the same config(encrypted LVM, etc) when the issue didn't happen in 3.1 and earlier?
<tgardner> jdstrand, what do you think about CVE-2011-2189 wrt bug #790863 ?
<ubot2> Launchpad bug 790863 in linux "Unable to start lxc container after update to 2.6.32-32" [Critical,Confirmed] https://launchpad.net/bugs/790863
<ubot2> tgardner: net/core/net_namespace.c in the Linux kernel 2.6.32 and earlier does not properly handle a high rate of creation and cleanup of network namespaces, which makes it easier for remote attackers to cause a denial of service (memory consumption) via requests to a daemon that requires a separate namespace per connection, as demonstrated by vsftpd. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2189)
<hggdh> jsalisbury: yes indeed, no changes
<bjf> tgardner, any thoughts on that bug i mentioned earlier?
<tgardner> bjf, thats what I just pinged jdstrand about
<bjf> d'oh
<jdstrand> tgardner: what is the question exactly, that this bug is that CVE?
<tgardner> jdstrand, what do you think about applying the fix for it to Lucid vsftpd ?
<jdstrand> tgardner: I feel dense, where is the fix for vsftpd?
<jdstrand> I see kernel commits in the bug...
<tgardner> jdstrand, dunno. Debian applied a fix to vsftpd to check kernel versions before using network name spaces.
<jdstrand> oh
<tgardner> so, I'd like you to consider the same approach.
<jdstrand> this is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629373
<ubot2> Debian bug 629373 in vsftpd "Remote DoS with vsftpd on Linux 2.6.32" [Serious,Fixed]
 * jdstrand pulls the package
<tgardner> looks like it
<tgardner> jdstrand, fixing vsftpd in conjunction with a kernel patch proposed by Tetsuo Handa might ameliorate the OOM killer DOS
<tgardner> smoser, ogasawara just uploaded the fix for the virtual flavour network device inclusion bug.
<jdstrand> tgardner: I am not opposed to it. with slight massaging I can get 10-remote-dos.patch to apply on lucid
<tgardner> jdstrand, cool. If you would drive that, then I'll take care of the kernel side.
<jdstrand> tgardner: do these have to happen in tandem or can we snag this as part of our normal flow?
<tgardner> vsftpd should go up first
<smoser> tgardner, ogasawara thank you. how long till that would appear in archive (ie, how long to build it.)
<tgardner> however, it'll be a week or so before the kernel gets loanded in -updates
<ogasawara> smoser: should only be but a few hours
<jdstrand> ok
<bjf> tgardner, right now it would go up in 6 weeks to -updates
<jdstrand> tgardner: would it be ok if I added a lucid task?
<tgardner> bjf, right, a week "or so"
<tgardner> jdstrand, yep
 * bjf is will be back in a bit, running an errand
<jdstrand> tgardner: so, just so I am clear-- I can upload this for all releases monday (say), but you guys will be handling lucid in your own timeframe. is that accurate?
<tgardner> jdstrand, yes. I think there is _no_ chance that we'll get a kernel in -updates before you get vstpd uploaded.
<jdstrand> tgardner: ok, cool. we were tracking this, but it was 'low'. sounds like it should be 'medium' based on remote DoS nature of the bug. it is on our radar, we will handle it
<tgardner> jdstrand, thanks
<jsalisbury> hggdh, re bug 894070 Can you also confirm that this was not an issue with the Ubuntu 3.1.0-1.3 kernel?  That way we have a starting point for the bisect.
<ubot2> Launchpad bug 894070 in linux "IOMMU error loop early in boot" [High,Triaged] https://launchpad.net/bugs/894070
<jsalisbury> hggdh, actuall 3.1.0-2.3
<jsalisbury> hggdh, I would also like to request two other kernels to be tested.  I'll add the details to the bug.
<hggdh> jsalisbury: no kernel before 3.2 failed
<hggdh> and I installed all precise kernels
<hggdh> jsalisbury: additionally, 3.1.0-2.3 was my fallback kernel when I first booted 3.2
<jsalisbury> hggdh, thanks for the info.  Would it be possible for you to test the mainline 3.2-rc2 kernel?  That will rule out any Ubuntu patches as causing the issue.  
<jsalisbury> hggdh, and also v3.2-rc1.  That will give us a good good spot to start with the least amount of changes.
<jsalisbury> hggdh, Depending on your results. We will either bisect between upstream v3.1 and v3.2-rc1 or between upstream v3.2-rc1 and v3.2-rc2.
<hggdh> jsalisbury: downloading the 3 kernels now
 * hggdh prepares for an orgy of reboots
<jsalisbury> hggdh, great, thanks!  
<hggdh> jsalisbury: thank YOU :-)
<jsalisbury> hggdh, :-)
<hggdh> jsalisbury: both upstream kernels -- 3.2rc1 and 3.2rc2 work when booted without intel_iommu=off
<hggdh> jsalisbury: OTOH, I lose wireless on them
<jsalisbury> hggdh, hmm, that indicates an Ubuntu patch introduced this
<hggdh> yeah, sounds like it
<hggdh> jsalisbury: do you still want me to boot 3.1 mainline?
<jsalisbury> hggdh, you probably don't need to.  I would assume that it works, since both 3.2 release candidates work.
<hggdh> jsalisbury: I agree, but wanted to be sure
<hggdh> anyway, I can install & run the beast later
 * ogasawara lunch
<jsalisbury> hggdh, ok, thanks.  So this issue appears to be an Ubuntu patch applied between 3.1.0-2.3 and 3.2.0-1.1
<jsalisbury> hggdh, can you post your mainline testing results to the bug, so they are tracked.
<jsalisbury> hggdh, Interesting that there is a similar RHEL bug, since this is pointing to an Ubuntu patch.
<hggdh> jsalisbury: already did
<hggdh> jsalisbury: indeed, and I wonder if this was a RH patch also -- reported on 2.32, and now closed
<jsalisbury> hggdh, maybe the same patch we both applied since it was not upstream.  I see 12 SAUCE entries in the change log between 3.1.0-2.3 and 3.2.0-1.1
<Sarvatt> or a config change, mainline kernels were still using older configs if they didn't have wireless
<jsalisbury> Sarvatt, hmm, interesting.
<luis__> hi there! i'm needing help regarding how to install the newest kernel in order to solve this bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/898615
<ubot2> Launchpad bug 898615 in linux "[Presario C500] Hibernate command fails and returns to userspace" [Medium,Confirmed]
<jsalisbury> luis__, can you post the output from the following to the bug: dpkg -l | grep linux-image
<luis__> ok jsalisbury
<luis__> http://paste.ubuntu.com/756449/
<jsalisbury> luis__, Hmm, I don't see the mainline 3.2rc2 kernel listed.  Did you install it with dpkg?
<luis__> at first i made the mistake of installing it via software center
<Sarvatt> CONFIG_MEMSTICK_R592 was enabled which hggdh's device on 04:00.0 is using
<luis__> but the second try i did it via dpkg
<jsalisbury> luis__, Go to http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2-rc2-oneiric/
<jsalisbury> luis__, Download linux-image-3.2.0-030200rc2-generic_3.2.0-030200rc2.201111151435_i386.deb	
<luis__> i've done that!
<jsalisbury> luis__, Run sudo dpkg -i linux-image-3.2.0-030200rc2-generic_3.2.0-030200rc2.201111151435_i386.deb	
<luis__> i've done that too!
<jsalisbury> luis__, did you have any errors while installing?
<luis__> none at all
<luis__> as you can see in the bug, i've posted that it didn't show up un the grub 
<luis__> if I uninstall it now, and re install via dpkg only
<jsalisbury> luis__, And id didn't show up in the dpkg output you posted.
<Sarvatt> jsalisbury, hggdh: http://pkgs.fedoraproject.org/gitweb/?p=kernel.git;a=blob;f=dmar-disable-when-ricoh-multifunction.patch;h=a4528617ecfdc437072e96c47cafbe10b5e5478f;hb=HEAD
<jsalisbury> luis__, can you attach the dpkg.log file to the bug and I'll have a look at it.
<Sarvatt> believe we have a winner there
<luis__> ok
<jsalisbury> Sarvatt, looking
<bjf> luis__ try to install it again and see if it tells you that it is already installed
<luis__> ok, doing that bjf
<bjf> luis__, also, pastebin the output from that attempt
<bjf> luis__, is this a multi-boot system ?
<jsalisbury> Sarvatt, hggdh I see this in commit: fe763ab898670195870b889e145483ce5c8997d5
<luis__> yes bjf
<luis__> have win xp
<luis__> but before the update to oneiric the hibernate worked just fine
<jsalisbury> Sarvatt, hggdh, ogasawara: http://paste.ubuntu.com/756455/
<Sarvatt> jsalisbury: yeah
<luis__> i even got it to hibernate on this version at some attempts, but it were really scarce to isolate what happened those successful times
<Sarvatt> the fact he doesn't have wireless implies it was using the older configs because the wireless problem got fixed up after 3.2-rc2 was uploaded to precise
<Sarvatt> it being the mainline builds
<Sarvatt> aka 3.2-rc1 and 3.2-rc2 mainline builds used the 3.1 kernel configs and the memory stick module wasn't built
<jsalisbury> Sarvatt, awesome.  Thanks for the research!
<luis__> jsalisbury, now i see you told me to instal 3.2rc2, now i see i was trying to install 3.2rc3
<luis__> i'm gonna try now with that image
<jsalisbury> luis__, ahh, yeah I don't know if there is a complete .deb there yet
<luis__> we'll see if it works now jsalisbury
<jsalisbury> luis__, great thanks.  please post your findings to the bug.
<hggdh> darn, I got so many things connected to the system...
<jsalisbury> hggdh, heh, you should be able to connect anything you want ;-)
 * tgardner -> EOD
<hggdh> jsalisbury: roight
<jsalisbury> hggdh, I'll see if I can build a test kernel without that patch/config change and post it to the bug to be tested.
<hggdh> jsalisbury: perfect, thank you.
<Sarvatt> jsalisbury, hggdh: got a kernel building already
<jsalisbury> hggdh, np, thanks for all the testing.  And Sarvatt thanks for your help.
<jsalisbury> Sarvatt, awesome
<Sarvatt> jsalisbury: oh, sorry, I was building one with that patch added, might still want one with the config change reverted?
<jsalisbury> Sarvatt, ahh, ok.  Your building a test kernel with the patch listed on: http://pkgs.fedoraproject.org/gitweb/?p=kernel.git;a=blob;f=dmar-disable-when-ricoh-multifunction.patch;h=a4528617ecfdc437072e96c47cafbe10b5e5478f;hb=HEAD
<Sarvatt> there is a fix, it's just only in fedora/redhat/SUSE
<luis__> bjf jsalisbury, i think it'll work now http://paste.ubuntu.com/756468/
<jsalisbury> luis__, looks like you'll need the linux-headers-3.2.0-030200rc2-generic package too.
<jsalisbury> luis__, its avaiable at that same link.
<luis__> ok
<luis__> jsalisbury, it showed an error http://paste.ubuntu.com/756474/
<hggdh> luis__: you need both the generic and the arch header packages
<luis__> hggdh: you mean i must install linux-headers-3.2.0-030200rc2_3.2.0-030200rc2.201111151435_all.deb too?
<jsalisbury> luis__, so these ones too: linux-headers-3.2.0-030200rc2_3.2.0-030200rc2.201111151435_all.deb
<luis__> got it
<luis__> the order in which i've installed it will alter something?
<luis__> or the order doesn't matter?
<jsalisbury> luis__, I believe the all package needs to be done before the arch one?
<luis__> thanks jsalisbury
<luis__> jsalisbury hggdh  http://paste.ubuntu.com/756488/
<luis__> i'm gonna give it a try
<luis__> booting it anyway... BRB
<SpamapS> Hey guys, working on pushing out the new kernel update to lucid-updates
<SpamapS> just want to make sure I get the packages right
<SpamapS> linux, linux-meta, linux-backport-modules-2.6.32 all are already in lucid-updates
<bjf> SpamapS: checking
<SpamapS> what about linux-firmware ?
<luis_> jsalisbury hggdh, worked! posting to bug. Is this kernel version stable? will I have any problems with it?
<bjf> SpamapS: yes to  linux, linux-meta, linux-backport-modules-2.6.32
<bjf> SpamapS: i think linux-lts-backport-oneiric and linux-lts-backport-maverick are ready as well
<Sarvatt> hggdh: http://kernel.ubuntu.com/~sarvatt/lp894070/
<Sarvatt> you've pretty much already verified it works though by using intel_iommu=off
<bjf> SpamapS: i'm not sure of linux-firmware, i think you should be able to publish it as well
<hggdh> Sarvatt: aye ;-)
<hggdh> Sarvatt: I have to walk the dogs -- it is the time of day they start arfing around me asking for it --; as soon as I am back I will boot it
<jsalisbury> luis_, That is an upstream kernel, so its not the supported Ubuntu kernel.  However, since your bug is fixed upstream, the fix will make it into Precise(12.04) if it hasn't already.  
<SpamapS> bjf: but the lack of the maverick/oneiric backport kernels won't be a problem for users of the normal lucid kernel, right?
<SpamapS> bjf: I'd rather hold off on the backport kernels.
<bjf> SpamapS: that's correct
<jsalisbury> luis_, thanks for your help testing!
<SpamapS> bjf: ok, I'm going to hold off on those two for now. I'd like to have a brief discussion with pitti and then make sure the process is outlined in the right place in the wiki so there's no confusion next time.
<luis_> jsalisbury, I'm the one that thanks you! thank you too hggdh!
<bjf> SpamapS: sorry, my bad, the lts-backport kernels have not finished testing
<bjf> ogasawara, the wireless model mentioned in bug 836250 . were any of those in the collection you got from intel ?
<ubot2> Launchpad bug 836250 in network-manager "[Oneiric] [Regression] Intel Corporation Centrino Ultimate-N 6300 poor networking, packet loss and very slow Lenovo X201 and T500 laptops" [High,Invalid] https://launchpad.net/bugs/836250
<luis_> two more questions jsalisbury, 1) I don't know exactly what an upstream kernel is, where can I get info on that? 2)What is your recommendation in your guts? Should I use this kernel or not?
<jsalisbury> luis_, An upstream kernel, is the vanilla kernel that all Linux distros base their code on.  If you can live with this bug, it's best to go back to the Ubuntu kernel.  Else if you can't live with this bug, it should be OK to run the upstream kernel until Precise(12.04) is released.
<luis_> jsalisbury, that really helped. I think I'm gonna give it a try, take the risks and see how it works. Since my laptop battery is virtually dead, I really need that functionality.
<hggdh> Sarvatt, jsalisbury: test kernel boots successfully, without any DMAR errors being reported
<Sarvatt> those multifunction ricoh's are very popular devices, i'm surprised there aren't more bug reports
<hggdh> I also wonder about that -- but, then, we did not have the module loaded before, and Precise is still at alpha1, so only demented people run it
 * hggdh notes a lot of kernels to test on SRUs...
<bjf> hggdh, how close are we to having deadicated SRU testing resources ?
<hggdh> bjf: rather close, I think. Close-ish is perhaps more correct
<hggdh> bjf: I hope DEADicated was a misstype ;-)
<hggdh> bjf: anyway, I will start on this new crop tomorrow
<bjf> hggdh, you don't want to learn how to spell from me, that's for sure
<ogasawara> bjf: I'd have to check.  I was procrastinating on getting the wifi harness from Intel to ease switching out the cards for testing.
<bjf> ogasawara: the pci cards?, there were 4 in lexington, 1 to tim, 1 to seth and 1 for Qa, 1 left over
<bjf> ogasawara: if you'd like one, i think that can be arranged
 * ogasawara is confused now
<ogasawara> bjf: I thought you were talking about the wifi cards from the last roadmap meeting
<bjf> ogasawara: i was and you were talking about wifi harness so i'm not sure what harness you are referring to
<bjf> ogasawara: i thought you ment pciexpress cards that you could plug the modules into
<ogasawara> bjf: ah. all I know is pete was getting i think 6 kits which would allow easily interchanging the cards so you don't have to go through the hassle of connecting/disconnecting the leads etc.
<ogasawara> bjf: if that's what he had in lexington, then yes I'd like one.
<bjf> ogasawara: yes, that's what i was talking about, maybe it was 6 and not 4
<ogasawara> bjf: regardless if there are extra I could definitely make use of it.  I'll ping pete.
<bjf> ogasawara: there were extras whatever the case
<ogasawara> bjf: some of the labels on the wifi cards are not all that informative (eg "sample").  but the others have slightly more info.  I'll cross check that info with what's in the bug.
<bjf> ogasawara: cool
<ogasawara> bjf: doesn't look like the cards I have match up with those in the bug.  they are n mode capable though.  I'll see if I can get some testing in tomorrow.
<vanhoof> ogasawara: bjf: talking intel?
<ogasawara> vanhoof: yah
<vanhoof> ogasawara: leme send you guys something
#ubuntu-kernel 2011-12-02
<ogasawara> jsalisbury: hey, just saw your email.  if you don't mind, I
<ogasawara> 'll respond in the morning
<ppisati> moin
<alkisg> Hi, is there a backported package that contains /lib/firmware/htc_9271.fw in 10.04? So that linux-image-generic-lts-backport-natty will be able to use that wireless card...
<alkisg> If not, can I install linux-firmware from Oneiric to Lucid?
<alkisg> apt-file search /lib/firmware/htc_9271.fw in Lucid returns nothing... can I install Oneiric's linux-firmware to Lucid?
<ppisati> uhmmm
<ppisati> anyway to workaround the maint-getabis script that tries to download a "non-existing" package?
<ppisati> herton: maint-startnewrelease uses Kernel Team <kernel-team@lists.ubuntu.com> instead of my user when creating a new release
<ppisati> herton: have you heard of it?
<herton> ppisati, did you have DEBEMAIL and DEBFULLNAME set in your invironment, I think it uses that, let me check
<herton> *do you
<ppisati> that's my laptop, i guess i don't have these set
<herton> ppisati, yes, you must have DEBEMAIL="your email" DEBFULLNAME="your name"
<herton> exported
<herton> *environment, sigh
<`-`> #ubuntu ops are nazi fags. please remember to use your brain not that other bit of the anatomy the #ubuntu team appears to think is best.
<herton> ppisati, you forgot to tag the ti-omap4 natty branch
<ppisati> nope
<ppisati> i forgo to push the tags
<ppisati> wait
<ppisati> herton: ok, all done
<herton> ppisati, thanks
<ppisati> btw, since we don't pubblish anymore lucid/dove but i need it for maverick
<ppisati> is there a way to make maint-startnewrelease happy even with a non-existing kernel/package?
<herton> ppisati, lucid is being pushed/uploaded later, so I think you can wait that to happen to prepare the maverick mvl-dove
<ppisati> actually the problem is maint-getabi that tries to download from a repository the package
<ppisati> ah
<ppisati> no wait
<ppisati> i mean lucid/dove, i thought we don't pubblish it anymore
<dholbach> hiya
<dholbach> where is the current linux upstream bug tracker? is http://bugzilla.kernel.org/ still down because of the security issues?
<ppisati> herton: e.g. no maint-getabis look for Ubuntu-2.6.32-220.38 package
<herton> ppisati, yep, but we still push lucid/dove to the repositories, I pushed your last rebase
<ppisati> ah
<ppisati> when?
<ogasawara> tgardner: thanks for doing the rebase
<ppisati> so the .deb should be ready soon
<herton> ppetraki, ah ok, well about the abi, indeed we don't build the kernel now
<herton> ppisati ^
<ppisati> yep
<tgardner> ogasawara, had some idle cycles while waiting for lucid builds
<ppisati> so the only way to make getabis happy, is to hack it i guess
<herton> ppisati, hmm... yes, may be you can build manually somewhere the package, and copy the abi files?
<ppisati> yes
<ppisati> that was the plan
<ppisati> ok
<dholbach> did anyone of you hear anything about some usb modules not being loadable with 3.2 due to 28 - ENOSPC (uvcvideo and snd-usb-caiaq in my case)? sorry for the vague question - but this the only bits I was able to find out up until now
<Razec> good morning
<brendand> dholbach - hey, i got the same problem just yesterday
<brendand> dholbach - well, sounds similar anyway
<dholbach> brendand, I filed bug 899165 and bug 899099 - which modules were it in your case? (usb-storage and my usb scanner, not sure which module that is, work though)
<ubot2> Launchpad bug 899165 in linux "uvcvideo: Failed to submit URB 0 (-28)." [Undecided,Confirmed] https://launchpad.net/bugs/899165
<ubot2> Launchpad bug 899099 in linux "snd-usb-caiaq fails to load" [Undecided,Confirmed] https://launchpad.net/bugs/899099
<brendand> dholbach - my webcam stopped working
<brendand> i saw 
<brendand> ~/.xsession-errors
<brendand>   libv4l2: error turning on stream: No space left on device
<brendand>   ** (cheese:26114): WARNING **: Error starting streaming on device '/dev/video0'.
<brendand>   ** (cheese:26114): WARNING **: Could not negotiate format
<brendand> but didn't check syslog actually
<brendand> dholbach - which model webcam have you got?
 * brendand can check the bug probably
<dholbach> brendand, Lenovo x220 - the camera should be "Bus 001 Device 005: ID 04f2:b217 Chicony Electronics Co., Ltd"
<brendand> dholbach - yeah, saw that just now in lsusb. i have a z-star one, so it must be something more general
<dholbach> apart from these two bugs I'm actually quite happy with 12.04, considering we're at 12.04 :)
<brendand> dholbach - i guess you mean at alpha1
<brendand> :/
<dholbach> errr
<dholbach> yes
<brendand> dholbach - upgrades as usual are a different story though. big regression in Firefox for me, but only with the system i upgraded
<dholbach> it seems I didn't run into this one
<brendand> dholbach - i can't access bug pages in launchpad with javascript turned on
<dholbach> maybe an addon?
 * herton -> lunch
 * ogasawara back in 20
<dholbach> jsalisbury, I tested the new kernel and replied to the two bugs - if there's anything else I can do to test, please let me know
<jsalisbury> dholbach, cool, thanks
<jsalisbury> dholbach, they both appear to be upstream bugs.  Unfortunately bugzilla.kernel.org is still offline, so we can't report it upstream yet :-(
<dholbach> jsalisbury, and I guess there's nothing I can do to further help debug it? could you imagine that the bugs have anything to do with each other? both usb-related, both having error code -28 - or could that be a red herring?
<dholbach> also I don't know if you saw it earlier, but brendand seems to have a similar problem with a z-star webcam (not sure if he filed a bug)
<jsalisbury> dholbach, they could be related.  brendand, it would be great if you could review bugs 899165 and 899099 to see if you have the same or similar issue.
<ubot2> Launchpad bug 899165 in linux "uvcvideo: Failed to submit URB 0 (-28)." [Medium,Triaged] https://launchpad.net/bugs/899165
<ubot2> Launchpad bug 899099 in linux "snd-usb-caiaq fails to load" [Medium,Triaged] https://launchpad.net/bugs/899099
<dholbach> jsalisbury, would it be useful to try older precise kernels?
<jsalisbury> dholbach, yes, that would be.  You could try back to 3.2rc1 or even the later 3.0 kernels.  
 * dholbach nods
<dholbach> I'll let you know
<jsalisbury> dholbach, thanks.  I also noticed this message in your report:  libv4l2: error turning on stream: No space left on device
<dholbach> jsalisbury, that was the user space message in .xsession-errors which came up after "uvcvideo: Failed to submit URB 0 (-28)"
<dholbach> diwic told me earlier:
<dholbach> <diwic> #define ENOSPC      28  /* No space left on device */
<jsalisbury> dholbach, ahh, ok.  misleading message :-)
<dholbach> (as you can imagine, I had no idea)
<dholbach> :)
<jsalisbury> dholbach, It would be great if you could narrow down at what version the bugs happen, and don't happen.
<dholbach> I'll do my best
<jsalisbury> dholbach, thanks!
<brendand> jsalisbury - i definitely have 899165
<jsalisbury> brendand, ok, can you mark that as "affects me too"
<brendand> jsalisbury - think i did
<jsalisbury> brendand, if we can narrow down at what version the kernel breaks, we may be able to do a bisect and create some test kernels.
<brendand> jsalisbury - i asked yesterday if the kernel had changed in precise recently. the response was that it hadn't
<brendand> jsalisbury - nearly certain it was working just a few days ago
<jsalisbury> brendand, did you apply updates recently?  You could always look at your /var/log/dpkg logs to see if your kernel was updated.
<brendand> jsalisbury - well, the laptop in question i use for iso testing. so it's fresh images
<jsalisbury> brendand, ahh, ok.
<brendand> jsalisbury - pretty sure 3.1 worked
<jsalisbury> brendand, Do you have time, or a system to test the 3.1.0-2.3 kernel, and confirm the bug is not there?
<brendand> jsalisbury - point me at the .deb
<jsalisbury> brendand, https://launchpad.net/ubuntu/+source/linux/3.1.0-2.3
<jsalisbury> brendand, from there select your desired arch
<jsalisbury> brendand, Under the "Builds" title
<brendand> jsalisbury - got it now. should just need the generic i386 .deb file, right?
<jsalisbury> brendand, yes
<jsalisbury> brendand, Can you post your results to the bug, so we can keep track of them?
<Sarvatt> jsalisbury: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/899165/comments/4
<ubot2> Launchpad bug 899165 in linux "uvcvideo: Failed to submit URB 0 (-28)." [Medium,Triaged]
<jsalisbury> Sarvatt, your the man ;-)
<jsalisbury> brendand, ^^^^
<ogasawara> jsalisbury: lets tag that 'rls-p-tracking' and milestone it for Alpha-2
<jsalisbury> ogasawara, sounds good. 
<ogasawara> jsalisbury: feel free to assign it to me so I keep track of it
<jsalisbury> ogasawara, will do.  Almost got another chance to bisect ;-)
<ogasawara> jsalisbury: if you want, if there is a patch available, you can try building them a test kernel to use in the mean time
<jsalisbury> ogasawara, not sure if there is a patch, but I can check.
<Sarvatt> jsalisbury: /home/sarvatt/uvcvideo.patch on tangerine.buildd
<jsalisbury> Sarvatt, great, thanks
<brendand> yah, camera works again :)
<cyphermox> anyone know why applying some sysctls don't appear to affect all interfaces? for instance, if I try to change net.ipv4.conf.all.log_martians to 1; only that particular entry is changed, not the values for eth0.log_martians, wlan0.log_martians, etc. the one I'm particularly interested in is net.ipv6.conf.all.use_tempaddr (ipv6 privacy extensions)
<dholbach> Sarvatt, thanks a lot for digging the patch out - I hope it will fix bug 899099 as well
<ubot2> Launchpad bug 899099 in linux "snd-usb-caiaq fails to load" [Medium,Triaged] https://launchpad.net/bugs/899099
<jsalisbury> brendand, dholbach, I'm going to build a test kernel with the patch.  I'll ping you when its ready.
<dholbach> brendand, did you build the test kernel yourself? :)
<brendand> dholbach - i just downloaded the previous one that jsalisbury pointed me to
<jsalisbury> dholbach, brendand tested the  3.1.0-2.3 kernel, which did not have the bug.
<jsalisbury> :-)
<jsalisbury> dholbach, brendand I have a test kernel building now.  Should be ready shortly.
<dholbach> ahhh ok
<dholbach> thank jsalisbury, Sarvatt, ogasawara
<brendand> jsalisbury - ok. let me know
<brendand> thanks kernel folks
<dholbach> if the patch fixes both bugs, I'll mark the other one as dup
<jsalisbury> dholbach, cool, thanks.
 * vanhoof waves
<cking> achooo
<ppisati> cking: got a cold?
<cking> it's the weekend, which means yes. I seem to get one from the kids during the week and it hits me over the weekends
<bjf> apw, about?
<jsalisbury> Sarvatt, Just curious, where did you get the uvcvideo.patch file from?  I see the patch on LKML in the body of am email, but I don't see it in real patch format anywhere like you have.
<dholbach> jsalisbury, http://www.spinics.net/lists/linux-usb/msg54992.html maybe?
<jsalisbury> dholbach, ahh ok. 
<ogasawara> tgardner: I'm gonna upload -rc4 and stefan's kunmap_atomic patch he sent out yesterday.  anything else you want included?
<tgardner> ogasawara, other ten the non-pae patch :) nothing I can think of.
<cyphermox> apw, tgardner: know why applying some sysctls don't appear to affect all interfaces? for instance, if I try to change net.ipv4.conf.all.log_martians to 1; only that particular entry is changed, not the values for eth0.log_martians, wlan0.log_martians, etc. the one I'm particularly interested in is net.ipv6.conf.all.use_tempaddr (ipv6 privacy extensions)
<cyphermox> I was expecting "all" to change the settings for the interfaces too; otherwise it's unclear to me what its use is... I can always open a bug though :)
<jsalisbury> dholbach, brendand, Build is done.  A 64 bit test kernel is available at: http://people.canonical.com/~jsalisbury/lp899165/
<dholbach> thanks jsalisbury
<tgardner> cyphermox, dunno, but I remember something like that plaguing me  in the 2.4 days
<dholbach> I'll report back in a bit
<jsalisbury> brendand, do you need the 32bit kernel?
<brendand> jsalisbury - yes please
<dholbach> jsalisbury, if it works, maybe that should be included in the -rc4 kernel as well? ;-)
<jsalisbury> brendand, ok, I'll put the 32bit kernel in that same directory.
<dholbach> brb
<cyphermox> tgardner: fun. because right now there's this which could help working around the fact that ipv6 privacy extensions aren't turned on by .default. because eth0 is discovered before the sysctls are applied... otherwise maybe it would make sense to make use_tempaddr the default globally everywhere... as a patch?
<tgardner> cyphermox, maybe you should ask the crew on netdev@vger.kernel.org . I haven't worked on that stuff for years. who knows what has changed.
<cyphermox> tgardner: ah, cool, thanks
<dholbach> jsalisbury, no, the situation is unchanged
<jsalisbury> dholbach, so the bug is still there with this test kernel?  Can you run uname -a to ensure its the patched kernel?
<dholbach> daniel@daydream:~$ uname -a; dpkg -l | grep linux-image-3.2.0-3
<dholbach> Linux daydream 3.2.0-3-generic #7 SMP Fri Dec 2 16:44:58 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
<dholbach> ii  linux-image-3.2.0-3-generic            3.2.0-3.7                                  Linux kernel image for version 3.2.0 on x86_64
<dholbach> daniel@daydream:~$ 
<dholbach> jsalisbury, ^
<apw> cyphermox, i think thats a tricky one, if the interface differes from the default is that cause you changed it, or because its the default.  it would be detectable, but i am not supprised if an interface is set before you change it it has the old value.  it wuold not be hard to update all existing interfaces too i presume
<dholbach> either the patch does not fix it, or maybe the patch was not applied during the build?
 * cking kicks of some more tests, takes a break for 4 hrs
<apw> jsalisbury, you should add clear identifiers to the version when you make a test kernel, so its more obvious if they have it
<apw> I typically append ~lpNNNNNvNNNN to mine
<cyphermox> apw: for default, it's indeed what I expect, it would keep the old value.. but I was also expecting "conf.all.*" to propagate the change to all interfaces ;)
<cyphermox> which doesn't appear to work at all, for ipv4 or ipv6
<dholbach> brendand, maybe you can test your i386 kernel: http://people.canonical.com/~jsalisbury/lp899165/ - it seems to be uploaded
<apw> ahh missread, that does sound like something that should override
<jsalisbury> apw, dholbach, right, I added this to the changelog: ~lp899165v1 trying to figure out why its not applied
<brendand> dholbach, jsalisbury - i'll try now
<cyphermox> apw: the only exception I've see as discussed somewhere is all.forwarding which might be working, I haven't tried
<jsalisbury> brendand, hold off one minute.
<cyphermox> apw: otherwise, and now I've just found a netdev email on the subject, I was wondering if it would be crack to make the default be that privacy extensions are enabled
<cyphermox> apw: http://marc.info/?l=linux-netdev&m=130518706601466&w=2
<jsalisbury> dholbach, your kernel version from uname should have ~lp899165v1.  I'm looking into why it does'nt now.
<dholbach> jsalisbury, is fb80a1f805bc9470733a3f830c036cd0 you have as md5sum for the amd64 .deb?
<cyphermox> apw: perhaps this needs a little more testing, which I'll do now. the *value* of eth0/use_tempaddr isn't changed, but I suspect it might still be enabled anyway, if I am to believe the documentation files
<dholbach> jsalisbury, I think I'll call it a day now, but if you update the bug, I'll have a look at it later on again and reply back
<dholbach> I have somebody here who's impatiently waiting for dinner ;-)
<jsalisbury> dholbach, ok, sorry.  I'll have a new build for you later today.  
<dholbach> jsalisbury, you rock
<dholbach> thanks a lot for looking into this
<jsalisbury> dholbach, brendand, I'll post a note to the bug when a new test kernel is ready.
<dholbach> have a great weekend everyone!
<jsalisbury> dholbach, you too
<jsalisbury> dholbach, can you also uninstall the test kernel you just installed.
<cyphermox> apw: totally not
<dholbach> bye :)
<jsalisbury> tgardner, does the ~/kteam-tools/buildscripts/ukb-make-release script require a patch to be git committed to be built?  
<jsalisbury> tgardner, Will it ignore a change to the tree if only the patch command is run?
<apw> cyphermox, indeed
<brendand> jsalisbury - so what happened?
<brendand> jsalisbury - something wrong with the patch?
<jsalisbury> brendand, there was a build problem.  I'll have a new test kernel in a few.
<apw> jsalisbury, most of teh build stuff builds teh top of the tree and not your working dir
<sconklin> is there a list maintained of which drivers are built-in for our kernels?
<tgardner> sconklin, I think apw has it attached to one of our config blueprints
<sconklin> ok I'll look
<Sarvatt> jsalisbury: yeah what dholbach pointed out, sorry I left and just got back. did you get the kernel built?
<Sarvatt> i can whip one up real quick if not
<jsalisbury> Sarvatt, its built now.
<Sarvatt> jsalisbury: i do:  patch -p1 < /home/sarvatt/uvcvideo.patch, fakeroot debian/rules clean, add whatever to the version string in debian/changelog, schroot -c precise-i386, DEB_BUILD_OPTIONS=parallel=64 AUTOBUILD=1 NOEXTRAS=1 skipabi=true fakeroot debian/rules binary-headers binary-generic for these one-off patches
<Sarvatt> oh ok
<jsalisbury> Sarvatt, thanks for finding that patch.
<brendand> jsalisbury - is there a test kernel now?
<jsalisbury> brendand, yes, I'll have it uploaded in just a minute.
<jsalisbury> brendand, There is an amd64 kernel available at: http://people.canonical.com/~jsalisbury/lp899165/
<jsalisbury> brendand, I'm building some 32 bit kernels now as well.
<bjf> brendand, did you get 11.10 installed on that server yesterday ?
<bjf> brendand, that PowerEdge 2950
<brendand> bjf - i never managed to. something wrong with dhcp config. either the nic is busted in Oneiric, or something wrong with the setup
<brendand> bjf - though i tested it recently with Lucid so don't see why that would be the case
<bjf> brendand: ok, thanks for trying. will you try again?
<brendand> bjf - doesn't work with Natty either. It was only certified up to Lucid so we don't usually test it with newer releases
<brendand> bjf - it's been around for about 4 years. what a trooper
<bjf> brendand: it shouldn't have regressed
<brendand> bjf - well, i don't think the NIC is totally busted, but definitely somethings different because DHCP config works in Lucid
 * ogasawara lunch
#ubuntu-kernel 2011-12-03
<bullgard6> When  Update Manger updated the package linux-generic , it displayed: "Bump ABI". I know what ABI is. Bu t what does Â»bumpÂ« mean?
<ohsix> if the abi was numbered, bumping it would be increasing it
<bullgard6> So the word "to" Bump is a synony for "increment the ABI release number"?
<bullgard6> So the word "to  bump" is a synony for "increment the ABI release number"?
<bjf> bullgard6: yes, you have the meaning correct
<bullgard6> bjf: Thank you for confirming.
<Sarvatt> apw:  kernel ppa is stuck uploading repeatedly again
<bjf> Sarvatt: he'll probably notice the email :-)
<Sarvatt> bjf: he has it filtered, had to bug him last time because he didn't see it :P
<bjf> Sarvatt: oh nice!
<apw__> sarvatt thanks, will add something to drop uploads to manual ... lp sucks
<synapse> How do I get the Lucid team to merge my kernel change?
<bjf> synapse: do you have a bug that goes with the change ?
<bjf> synapse: you need one
<bjf> synapse: is it an upstream accepted change or is it one you've crafted yourself ?
<bjf> synapse: https://wiki.ubuntu.com/Kernel/Dev/KernelPatches
<synapse> ok, I didn't know it was through launchpad
<synapse> I'll just submit there
 * bjf will be holding his breath in anticipation
<Sarvatt> apw_: any chance ya could stop the ppa script? it's still been spamming email all day
<apw_> be home shortly ... and will poke it
#ubuntu-kernel 2011-12-04
<beata|coyote> Trying to get Palm serial adapter to work, kernel 2.6.35, autoloaded kl5kusb105 driver shouts into kernel log about "usb 4-2: read status 30 0" and managed to actually crash the machine once.
<beata|coyote> Going to load the generic driver when I have time.
<dupondje> Hi! Somebody around that take care of daily kernel builds ? :)
<dupondje> quite silent :)
<bjf> dupondje, there was a problem with them yesterday, they were put on manual, they will be back tomorrow probably
<dupondje> well thats not really the issue :)
<dupondje> I just want to know if the .config that it uses can be modified a bit ?
<bjf> dupondje: the best think to do is make a request on the mailing list
<psusi> there seem to be a lot of kernel modules in the initrd.. to make the initrd optional, the system would have to determine that none of them are required to boot.  If it is smart enough to figure that out, why not just omit the specific modules that are not required, and use a much smaller initrd rather than none at all?
#ubuntu-kernel 2012-11-26
<myhrlin> Hi, this might be the wrong place to point this out but http://kernel.ubuntu.com/ seems to be down, would that be covered here?
<stgraber> it's known
<stgraber> (from #canonical-sysadmins' topic: Known issues: kernel.ubuntu.com is down)
<myhrlin> ah ok
<myhrlin> thanks
<apw> j #canonical-sysadmins
<njin> hallo guys, we have http://kernel.ubuntu.com/~kernel-ppa/mainline/ broken
<njin> balloons, up and running ?
<njin> can someone tell me who to ask to repair http://kernel.ubuntu.com/~kernel-ppa/mainline/ , thanks
 * ppisati -> reboot
<bjf> njin, the server is dead. the issue is being worked
<njin> bjf, thanks to clarify
<bjf> njin, np
<ppisati> brb
<ogra-cb> cking, do you happen to know if your power fixes were forward ported to the raring nexus7 kernel ?
<ogra-cb> i at most get 2h out of the battery now 
<ogra-cb> and wlan got rather unstable with this kernel
<cking> ogra-cb, there were no ARM specific kernel fixes, most of the issues are in userspace really
<ogra-cb> hmm, k 
<cking> ogra-cb, 2 hours on the nexus 7? what are you doing to it?
<ogra-cb> well, userspace really freaks out now, i see assively jumpy times in the battery applet
<ogra-cb> cking, leaving it idling :P
<cking> ogra-cb, I really would not trust the battery to give you any sane idea of power consumption, it's not very accurate
<ogra-cb> well, i had over 7h with the old kerne;
<cking> ogra-cb, run eventstat to check for stupid wakeup events
<ogra-cb> and definitely no jumpy times displayed
<ogra-cb> it hops from 1h to 17h etc 
<ogra-cb> up and down all the way
<cking> ogra-cb, yeah, so I was getting 12 hours on idle, 7 hours on fully loaded CPUs
<ogra-cb> and afyet 2h it shuts down
<ogra-cb> it also seems to get warmer but that might be a subjective impression
<ogra-cb> s/afyet/after/
<ogra-cb> and when walking through the house it fails to properly roam wlaan APs and goes into re-connects all the time
<cking> ogra-cb, perhaps it's wifi that is sucking all the power. turn it off and see what difference that makes
<ogra-cb> (it reconnects fine though, just didnt do so many reconnects with the former kernel)
<ogra-cb> ah, good idea
<ogra-cb> oh, the power manager battery overview doesnt update properly either btw
<cking> ogra-cb, well, that is surprising, I will have to install the latest images and see what's borked
<ogra-cb> the raring image is a bit tricky to handle but should install fine
<ogra-cb> (massive UI bugs atm)
<cking> sigh
<cking> oh, well, ssh is fine for me
<ogra-cb> well, ctrl-alt-t works to get a terminal and onboard works
<ogra-cb> so you can indeed instal openssh-server
<cking> ogra-cb, that's my modus operandi
<ogra-cb> :)
<ogra-cb> xnox, bug 1080437
<ubot2> Launchpad bug 1080437 in ubiquity (Ubuntu) "no background during the 13.04 daily install" [Undecided,New] https://launchpad.net/bugs/1080437
<cking>   PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND                                                                                               
<cking>  2881 king      20   0 1302m  90m  28m S  31.6  1.6   1:12.71 compiz                                                                                                
<cking>  9228 king      20   0  713m  96m  29m R  19.6  1.7   3:55.91 plugin-containe     
<cking> ouch, my CPU is on fire just rendering
<xnox> ogra-cb: bug 1078226
<ubot2> Launchpad bug 1078226 in nautilus (Ubuntu) "raring daily: background & lightdm look as if they are in 8bit greyscale mode" [Low,Incomplete] https://launchpad.net/bugs/1078226
<xnox> ogra-cb: this is in KVM, not sure about the other bug reporter.
<xnox> will test nexus7 and try to see what's going on.
<ogra-cb> nexus7 shows a clearly distroted wallpaper during install
<ogra-cb> but i assume the framebugger is just not clean at that point, else it would show black
<ogra-cb> heh, funny typo ... framebuffer indeed
<ogra-cb> err, oops, i though i was in -installer with the last bits, sorry for the noise
<asac> http://kernel.ubuntu.com/~kernel-ppa/mainline/ doesnt exist anymore?
<asac> or just temporary outage?
<fmoreau> hello, I'm trying to retrieve the source code of the kernel for N7 device, but it's failing:
<fmoreau> $ LC_ALL=C git clone git://kernel.ubuntu.com/hwe/ubuntu-nexus7.git
<fmoreau> kernel.ubuntu.com[0: 91.189.94.216]: errno=Connection refused
<fmoreau> could anybody help me please ?
<rtg> fmoreau, that server is temporarily down
<fmoreau> rtg: ah... thanks. Is there any alternative ?
<rtg> fmoreau, checking, perhaps github but I'm not sure.
<Kano> hi, whats up with your server?
 * ogra-cb grins
<ogra-cb> Kano, you are the third to ask within 20 min
<rtg> apw, are you cloning the N7 kernel on people.c.c ? I don't have it in the github pile.
<rtg> Kano, server is down.
<Kano> ogra-cb: well then put it into the topic
 * ogra-cb has no such powers
<apw> rtg checking
<apw> rtg, nope, whats your tip commit, so i can see if i at least have the original
<rtg> apw, 7377da8f921463728ee8196186dc5b5a997a9fda UBUNTU: Ubuntu-3.1.10-8.14
<apw> commit 7377da8f921463728ee8196186dc5b5a997a9fda
<apw> nice ... ok so at least i have a valid copy
<Kano> 3.1.10?
<rtg> apw, looks like I was the last uploader, so that should be right
<rtg> Kano, nexus 7 kernel
<apw> rtg and it matches the appropriate version
<fmoreau> rtg: did you find any alternatives on github (sorry if I missed a previous post but I've been disconnected) ?
<rtg> fmoreau, not for the N7 kernel
<Kano> N10 later?
<rtg> Kano, dunno
<apw> fmoreau, ok i think i have managed to push that nexus7 branch to our archive github repo
<apw> fmoreau, https://github.com/Canonical-kernel/Ubuntu-kernel/commits/ubuntu-nexus7-master
 * henrix -> (late) lunch
<fmoreau> apw: thanks !
<arges> sforshee, hey. have you had any issues installing 32-bit quantal on macbook airs? i'm looking at bug 1082059 which involves eficross
<ubot2> Launchpad bug 1082059 in linux (Ubuntu) "default quantal kernel does not boot my macbook air" [Undecided,Confirmed] https://launchpad.net/bugs/1082059
<sforshee> arges, I saw that one. I haven't tried 32-bit in a while, but I'm pretty sure what he's trying to do isn't a supported configuration at this time.
<arges> sforshee, ok how would I find out if it is supported or not? is this unsupported in the firmware?
<sforshee> arges, what I suspect is unsupported is native EFI boot to a 32-bit kernel. I can't swear to it though. Maybe cjwatson would know?
<cking> 32 bit with EFI is not going to fly is it?
<rtg> ogasawara, smb, sconklin, apw, bjf, herton, henrix: I would wait until we know zinc is officially back before attempting any git pushes.
<ogasawara> rtg: ack
<sconklin> ok
<apw> rtg, ack
<henrix> rtg: ack
<bjf> rtg, ack
<herton> rtg, ack
<sforshee> cking, if you look at the bug there's a patch referenced that's trying to fix problems with that use case, so someone seems to be trying to make it work
<rtg> ogasawara, smb, sconklin, apw, bjf, herton, henrix: #is says zinc is officially back, though I'm concerned about the cause.
<arges> sforshee, yea working on a cherry-pick building now
<arges> not too many conflicts
<fmoreau> apw: trying to clone the repository you pointed out: fatal: https://github.com/Canonical-kernel/Ubuntu-kernel/commits/ubuntu-nexus7-master/info/refs not found: did you run git update-server-info on the server?
<apw> fmoreau, i don't think that is a cloneable url, it points to something you get get those from
<apw> fmoreau, i would also not recommend cloning that as it is massive, make an empty repo, add it as a remote, and fetch just that one branch
<fmoreau> apw: stupid me :)
<fmoreau> sorry for the noise
<fmoreau> apw: will use --reference 
<apw> it will still be humungous i am sure
<rtg> about 4.5GB
<apw> thught it would be indded.  just take the one branch, must smaller
<SpamapS> smb`: Nov 24 22:32:43 clint-MacBookAir kernel: [131886.042747] unregister_netdevice: waiting for lo to become free. Usage count = 15
<SpamapS> cking: ^^
<SpamapS> 3.5.0-18.29
<SpamapS> it almost seems *worse* now with 3.5.0-18.29
<cking> bah, that's not good news
<apw> did we commit a fix for that issue, i didn't realise
<cking> it's SRU's
<cking> SRU'd even
<apw> amazing :)
<SpamapS> note, usage count = 15
<SpamapS> previously, it was = 1 or = 2
<cking> SpamapS, that fix is in master-next but not released yet
<apw> rtg, when we made linux-lts-quantal it stopped Provides: linux-image ... is there any good reason for this that you recall
<rtg> apw, no
<apw> rtg, seems we need it to allow that kernel to be the only kernel one has for the CDs... so i'll fix that then
<cking> SpamapS, I believe the ref count badness is due to how fragmented data gets, so it may vary on the unfixed kernel
<rtg> apw, except that it _doesn't_ provide linux-image
<apw> rtg its linux-images-*'s are linux-image's as much as any other?  arn't they ?
<rtg> apw, don't they have lts-quantal in the name ? I can't remember
<apw> rtg, not the final binaries i don't think no
<rtg> apw, go ahead and fix it then
<apw> and whatever they are called, they are 'linux-image' compatible right?  whcih is the point of the provides
<apw> linux-image-3.5.0-19-generic | 3.5.0-19.30 | quantal-proposed | amd64, i386
<apw> linux-lts-quantal | 3.5.0-18.29~precise1 | precise-updates | source
<apw> so either way they are linux-image-*
<rtg> apw, seems right
<apw> something off with rmadison output there
<apw> linux-image-3.5.0-18-generic | 3.5.0-18.29~precise1 | precise-updates | amd64, i386
<apw> linux-image-3.5.0-19-generic | 3.5.0-19.30~precise1 | precise-proposed | amd64, i386
<apw> linux-lts-quantal | 3.5.0-18.29~precise1 | precise-updates | source
<apw> linux-lts-quantal | 3.5.0-19.30~precise1 | precise-proposed | source
<apw> better ...
<apw> ok goood ... will do
<apw> rtg, zinc is still on hold our side rigght ?
<apw> i am asking pinky to check the remote power works while they are there
<apw> modulo everyone still not using it
<rtg> apw, he told me it is officially online, so I assume he's not gonna try power cycling again
<SpamapS> cking: ok, I'll try quantal-proposed
<apw> rtg, just talking to him now, they think it is configued right, but they haven't tested the remote proceedure
<apw> rtg, i think it would be worth doing while they are there in case it is not correct
<rtg> apw, seems like they ought to figure that out while he is there
<fmoreau> apw: I finally ended up to download a zip containing the head of the nexus branch, it's only 120Mo.
<cking> SpamapS, the fix will land after Ubuntu-3.5.0-19.30, so you need to wait a while for the fix 
<apw> rtg, ok they are going to test and confirm now
<SpamapS> cking: :(
<SpamapS> cking: thanks for the info
<cking> SpamapS, but if you are stuck, continue to use that debug version I built for you until the fix is released
<SpamapS> cking: not stuck, just :( for the users.
<rtg> apw, ack
<cking> SpamapS,  /me nods, well, the process takes a while for a release because we need to test to ensure all the fixes don't cause regressions
<SpamapS> cking: +1000 for that
<SpamapS> just :( .. its not a >: at you, or the process. Just a :(
<fmoreau> sigh... unzipping the archive: "symlink error: File name too long"
 * ppisati_ -> gym
<rtg> apw, ogasawara: pushed 3.7-rc7 rebase. still doing build and boot tests
<ogasawara> rtg: ack
<myhrlin> hello, would the kernel packages at http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.7-rc1-quantal/ be decent to use for a production server?
<apw> myhrlin, test kernels for production, and from an -rc1 at that, no
<rtg> myhrlin, emphatically no
<myhrlin> oh, sad day
<myhrlin> ok
<myhrlin> wait, so ubuntu-modified kernel 3.6.7 isn't... oh wait I linked the wrong one
<myhrlin> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6.7-raring/
<apw> all of the kernels in the mainline archive are there for testing and are unsupported
<myhrlin> I was assuming since kernel.org has 3.6.7 as stable that the ubuntu-modified one would also be stable
<Kano> what option would disable the .tar.gz build?
<jwi> myhrlin: "ubuntu-modified"?
<myhrlin> well, isn't it modified when `make menuconfig` has an option for ubuntu specific options?
<myhrlin> I thought that was the case, but I'm basing that off a config from... a few version ago, I don't remember the specific version I used at that time
<myhrlin> oh, my fault.  Just now checked it for 3.2.31, it's just a menu for " Ubuntu Supplied Third-Party Device Drivers"
<myhrlin> I honestly thought ubuntu had a heaviliy modified kernel
<jwi> myhrlin: the /mainline kernels are built from {linus',stable} trees - vanilla, no ubuntu toppings.
<arges> smb`, hello
<arges> just a general xen question... if I boot with a xen dom0 ubuntu kernel, would I expect certain CPU features to be disabled?
<rtg> ogasawara, apw, bjf: test kernels at http://kernel.ubuntu.com/~rtg/3.7-rc7.1
<bjf> rtg, ack
<ogasawara> rtg: ack, I'll throw it on my kit here
<apw> rtg ack
 * rtg -> lunch
 * henrix -> EOD
<infinity> hggdh: I hear you should be unstuck for armadaxp regression testing?
<infinity> arges: That depends on the release, probably.
<arges> infinity, yea trying to verify 979003 and I notice that booting with xen raring kernel avx isn't present (so can't reproduce the bug)
<arges> xen raring dom0 that is
<infinity> On hardware with AVX?
<infinity> That's a mistake, if so...
<infinity> smb`: You around?
<arges> infinity, i think he has the day off
<infinity> Check.  We should bug him later.
<arges> infinity, i'll ping him tomorrow
<infinity> It may be that he hard disabled AVX to work around the glibc issues, but we should be backing that out (from all releases) if we're fixing glibc.
<arges> agreed
<rudimeyer> I'm experiencing a problem with the handling of virtual block devices (Xen) in kernels version 3.0 (Ubuntu 11.10) and 3.2 (Ubuntu 12.04 LTS) - but in Ubuntu 10.04 LTS with kernel 2.6.32 the error is not presentâ¦   How do I go by reporting this the best?
<rudimeyer> Kernel 3.0 and 3.2 does not handle the detachment of a virtual block device that well (hang/freeze)
<jtb1> hi! is there a way to get the linux-tools for the kernels from http://kernel.ubuntu.com/~kernel-ppa/mainline/ ?
<myhrlin> kernel 3.6.8 is out :D
<myhrlin> jtb1: linux-tools?
<jtb1> myhrlin: perf, turbostat, x86_energy_perf_policy etc
<myhrlin> ah ok
<myhrlin> I'll leave that for someone else, I have no idea
<jtb1> k, thx anyway ;)
 * rtg -> EOD
<arges> jsalisbury, hey.
<arges> jsalisbury, if a linux bugtask is fixed in raring by a patch in upstream, should I mark the raring bugtask as 'Fix Released' or something else?
<bjf> arges, is that fix in our currently "released" kernel ?
<bjf> arges, or another way to ask ... which rc is it fixed in?
<arges> bjf, yes assuming it is. that patch is in a released kernel
<arges> bjf, but we didn't actively apply the fix, it was just already in upstream
<bjf> arges, then yes, you can mark it "fix released"
<bjf> arges, that status isn't meant just for bugs we fix
<bjf> arges, it indicates, "this bug has been fixed and is available via a released kernel"
<arges> bjf, that's what I figured, just wanted to make sure
<bjf> ack
<arges> thanks
<bjf> np
#ubuntu-kernel 2012-11-27
<jsalisbury> arges, what bjf said ;-)  I also add the tag: kernel-bug-fixed-upstream
<jsalisbury> arges, I generally marked a bug as "Triaged" if it has a patch/commit available upstream, which has not yet made it into the Ubuntu kernel via a development kernel rebase or stable update.
<rudimeyer> I noticed the kernels for Ubuntu 11.10 (3.0) and Ubuntu 12.04 (3.2), in Amazon EC2 have a defective handling of EBS drives (Xen virtual block devices). Anyone know of this?
<smb> rudimeyer, No, and "defective handling" is not really helpful to provide any better answer.
<rudimeyer> smb: Sorry, I will try to discribe it better. The issue is, then a EBS disk is disconnected, by API or error. The system doesn't handle the disconnect. Fx. in a raid setup (mdadm) , the array "hangs" and never gets to mark the disk as faulty
<rudimeyer> I have tried to explain it here: https://forums.aws.amazon.com/thread.jspa?messageID=402877&#402877
<smb> rudimeyer, You probably should open a bug report on this where logfiles could be attached and so on. Generally the blockfront driver is working (at least those instance types that are PVM)
<smb> rudimeyer, Ah, so it is not only Ubuntu having issues with mdadm but about anything but Redhat images...
<rudimeyer> smb: Yes, what I have testet out, and I'm no expert, is kernel version 3.0+ thats giving the problem. (All tested on EC2)
<rudimeyer> smb: Its not limited to mdadm. Gluster, lvm etc. also has the issue of hanging when disk is pulled.
<rudimeyer> smb: It never "fails", just hanging/waiting forever on the disk
<smb> rudimeyer, Ok, and the detach command is from the ec2 tools/aws web console, right
<rudimeyer> smb: Yes, 'force-detach'
<smb> Hm, so probably removing the drive on xen level (though only Amazon would know what they do). Since there are no error messages it is not so easy to find out what is going wrong. Could be some udev processing or the upstream netfront driver.
<smb> You could probably try to see whether there are suspicious looking processes after detaching 
<smb> And to see whether thing potentially changed in recent kernels, try some mainline kernels
<smb> !mainline
<ubot2> The kernel team supply continuous mainline kernel builds which can be useful for tracking down issues or testing recent changes in the Linux kernel. More information is available at https://wiki.ubuntu.com/Kernel/MainlineBuilds
<rudimeyer> smb: Alot of good input, will get on with that. Thank you very much
<smb> rudimeyer, Your welcome.
<jtb1> hi! is there a way to get the linux-tools for the kernels from http://kernel.ubuntu.com/~kernel-ppa/mainline/ ?
<smb> jtb1, No, I don't think so
<jtb1> is there a way to build it by myself?
<smb> jtb1, That should be possible when you download the same version of upstream code and then apply the patches from the mainline page
<jtb1> is there some way to add this as feature request? ;)
<apw> jtb1, i cannot remember why we do no make them
<apw> jtb1, i suspect originally they wern't buildable, i just cannot remember any more
<rudimeyer> smb: Hope you're still around :) I've tested out a couple of mainline kernels, one according to "Ubuntu to Mainline kernel version mapping" and newest patch release of 3.2 corresponding to the 3.2.x of my precise installation. No luck. Logs show nothing but a entry about a file operation "blocked for more than 120 seconds". Processes related to the disk is in the 'D' state.
<rudimeyer> smb: Is it anyway possible to get a qualified person to maket the same tests i did, gather data and descirbe the issue? My company is willing to pay for a resolution.
<smb> rudimeyer, I am. And yes, the blocked process likely could be related. 
<smb> As for making it more official, not sure you have already support contracts with either Amazon or Canonical, so filing bugs there would be the next steps
<smb> Or the other question would be whether basically pulling out drives from a (virtual) machine is exactly the testcase you want to cover or whether it rather could be errors on the drive
<smb> I think there have been some device-mapper targets that could be used for that.
<smb> From the top of my head I cannot say whether blockfront is supposed to support hot-unplug or not. I agree that it likely should. But it could be some feature yet ot be implemented than a pure bug fix...
<rudimeyer> smb: I've been thinking the same thing, maybe may test is off. But again, it work on 2.6 kernels :|
<smb> rudimeyer, Ah, ok. So if it used to work, then it should still. 
<yf-geek> Do I have to apply manually the ubuntu patches to the kernel even if i "apt-get source linux-image-$(uname -r)" then compiling it?
<ogra_> nope
<ogra_> the ubuntu patches are maintained in git, the tarball the linux-image-* package uses contains the whole git tree (incl. all patches)
<yf-geek> hmm, why i feel that the mouse(actually  a touchpad) is not that snappy anymore after i installed a kernel that is compiled with that, even if it is the same version......
<yf-geek> how do i tell the dkms modules to build after i have installed the kernel image by myself?
<yf-geek> nvm, i already found the solution
<yf-geek> now i really don't understand why i have to press the left mouse click button for a longer time before i can do any kind of dragging actions? i am using kubuntu, wondering that if there is any difference between ubuntu's kernel and kubuntu's
<tyf> hmm, seems like removing a non-dkms driver (alx) solved the mouse drag problem, perhaps the driver will cause the interrupt to work oddly?
<tyf> now reinstalled it and everything works fine
<tyf> usually, PAE kernel or the 64bit kernel is more stable?
<rtg> apw, ogasawara: any objection to uploading today ?
<apw> rtg, give me 2 mins
<apw> just doing some s/r testing on it
<rtg> apw, no rush
<apw> rtg, for next time could you make them ~pre1 or something so we get the official kernels automagically ?
<rtg> apw, I'm not following you. Are you building the raring repo as COD ?
<apw> rtg, no i am testing the binaries you posted yesterday, but they are numbered as official releases
<apw> rtg, i was suggesting slamming a ~pre1 in the version when you build like that
<apw> rtg, nyhow seems to boot ok for me, on both  32 and 64 bit and s/r cycles seem ok
<rtg> apw, hmm, you should get new binaries anyways because they are newer and the MD5 sums don't match.
<apw> rtg, i don't believe that will occur, i believe it will say the version i have is the same and be done
<apw> but when you upload it, we can test that
<rtg> apw, shall we test the theory ?
<rtg> I'll wait to see if ogasawara has anything in the pipeline
<apw> works for me
 * henrix -> lunch
<tyf> any guide for troubleshooting complete lockups? i am using Precise
 * smb suggest big hammer. Does not help the lockup but one feels less troubled afterwards...
<smb> Otherwise maybe https://wiki.ubuntu.com/Kernel/CrashdumpRecipe helps
<tyf> hmm, i will give it a try.
<tyf> I don't have kernel panic/oops, will LKCD works with complete lockups? Why the NMI watchdog doesn't kick in and produces a oops when lockup happens?
<arges> smb, hey, I have a xen question for you
<smb> arges, Yup, wassup? :)
<arges> smb, i've been trying to verify a patch for eglibc for lucid/oneiric domU 
<arges> smb, my machine has avx extensions, but if I boot with the xen dom0 kernel (raring) i don't see that cpu flag after booting
<arges> unfortunately i need that extension to be present to actually reproduce the bug and verify
<smb> arges, What dom0 are you using (and or hypervisor version)
<smb> Oh, so raring dom0?
<arges> yes
<arges> smb, i assume all the patches are in ubuntu-raring.git ? or do I need to look elsewhere
<smb> Unfortunately the xen4.2 packages are still stuck in proposed...
<arges> i could enable proposed and check
<smb> I think passing throught the xsave flags depends on the hypervisor
<smb> arges, Give me a sec to check whether I still got some test builds around
<smb> arges, Youdontwantproposedinraring!
<arges> i thought i had tried xsave=1... trying it again this morning
<rtg> hmm, it seems that the Lucid network manager really doesn't like a 3.7 kernel. dhclient can't create an addrlist socket.
<smb> AFAIK it also requires the hypervisor itself to set osxsave correctly and I am not sure that already was done in xen 4.1.3
<arges> smb, so are the xen packages custom patched kernels? where would i find the git tree for the hypervisor?
<smb> arges, try to wget the packages from https://launchpad.net/ubuntu/raring/+source/xen/4.2.0-1ubuntu2
<smb> arges, No, there is two parts: dom0 is a normal kernel that also works as dom0 kernel
<smb> arges, But the dom0 is just a specially priviliged guest started by the hypervisor 
<smb> Which is the gz file you see booted via multiboot in grub
<arges> so the hypervisor is the OS that has all the (XEN) messages flying by?
<smb> arges, yep
<arges> ok
<smb> arges, which you can recheck with "xm dmesg" as long as we still use the xm stack
<smb> Last time I was looking at xl it said "not implemented" to that
 * smb has slight issues listening to his own thoughts while his neighbours seem to convert a concrete wall into swiss cheese
<arges> installing 4.2 now 
<smb> arges, note that when installing in parallel you will end up with xen-4.1 and xen-4.2 selectable from grub
<arges> smb, yup i'll select that from there. running it on a laptop : ) 
<smb> arges, :) Why not as long as it has virt extensions enabled.
<smb> ...and you got enough memory as that cannot be overcommitted
<arges> it actually heats up the laptop quite a bit
<smb> In theory it should do freq scaling and pm from the hypervisor (though you could check with xenpm)
<smb> But I think it does not use more than c2 for some historic reason
<smb> at least before xen 4.2 again
<smb> So maybe that gets better (or worse) as well
<arges> we'll see! 
<ogasawara> rtg: +1 for an upload today.  want me to prep it or do you?
<rtg> ogasawara, I'm most of the way there. gimme a bit.
<arges> smb, woo hoo 4.2 boots fine and i have the proper cpu flags
<smb> \o/
<arges> smb, thanks
<smb> welcome
<rtg> apw, while I'm doing the upload would you have a look at 'UBUNTU: [Config] install-arch-headers needs a valid config' to make sure I'm not on crack. its always aufs_type.h that breaks the packaging, and having a valid config seems to fix the problem (which sort of makes sense)
<cafetiere> Will do shortly, though the description makes sense enough on its own
<cafetiere> Rtg ^^
<rtg> cafetiere, is there a simpler way to choose a config flavour ?
<cafetiere> Not at my keyboard right now, will c heck when am
<ogra_> janimo, should bug 1073499 and bug 1073840 be reassigned to the kernel team or do you actually work on it ?
<ubot2> Launchpad bug 1073499 in ubuntu-nexus7 "please consider turning on all possible modules for external USB devices" [Medium,Confirmed] https://launchpad.net/bugs/1073499
<ubot2> Launchpad bug 1073840 in ubuntu-nexus7 "Sync kernel configuration with the one from the Ubuntu kernel" [Medium,Triaged] https://launchpad.net/bugs/1073840
<rtg> ogasawara, ^^
<ogasawara> ogra_: janimo is doing the nexus7 config review, so it would seem to me he is the right assignee
<ogra_> k
<ogra_> just going over the buglist :)
<janimo> ogasawara, last I heard apw took a config I pasted him and said he'd do an initial review/merge with the existing tools
<vanhoof> janimo: we'd agreed you do the initial pass, yeah?
<apw> janimo, i was indeed going to get the review tools to work on it, i got sidetracked onto making it produce some update lists for this kind of thing
<janimo> vanhoof, yes and apw asked for a config from me to do it himself last week
<janimo> when I asked what to do re the initial pass
<janimo> apw, no worries as long as we're all on the same page :)
<vanhoof> fair enough :)
<apw> so i believe i am producing a review for that flavour, which someone will then have to apply
<janimo> apw, ok
<apw> but i also hope the new tooling which has come out of this will give us a list of expected values you can just 'shove in'
<apw> rtg, you are using the first flavour yes?
<apw> rtg, there is an incantion for that for the autopkgtest thing in debian/rules
<apw> $(firstword $(flavours))
<apw> you could do that on the rule
<rtg> apw, cool. I'll change to that
<apw> rtg, though i conceptually wonder if you should actuall be deping on the prepare-$(first_flavour) sort of thing
<arges> smb, hmm can't install oneiric domU's onto xen, looks like drivers for disk/networking are missing. who should i file a bug against? 
<apw> rtg, as it clearly works some of the time and not others, so something in parallel must make what it needs in that case
<smb> arges, xen_emul_unplug=never
<arges> smb, is this in a wiki somewhere?
<apw> rtg, but for now if that works, ship it and we can think about it later
<smb> arges, maybe, though not that I would know how to find it... That actually should be in the release notes (if someone ever reads them)
<rtg> apw, dep'ing on the prep stamp delays the header build (though not a lot). I could never figure out why the failure was intermittent.
<arges> smb, and I assume this is a kernel boot option?
<apw> rtg, i worry slightly about having the code to make a config in more than one place
<apw> and if we could share it by using prepare-foo as a dependancy longer term that seems better
<rtg> apw, agreed. lemme figure it out.
<smb> arges, Right, yes, potentially only needed for installation but to be sure you would need to add xen_blkfront to the /etc/modules list
<apw> smb, didn't we build all those in for you so that you didn't have to do that ?
<smb> apw, Don't think for Oneriric and even less so for the install images
<arges> smb, bug 839492 is related
<ubot2> Launchpad bug 839492 in xen-tools (Ubuntu) "xen-blkfront module missing from initramfs, Ubuntu as DomU can't boot" [Undecided,In progress] https://launchpad.net/bugs/839492
<arges> smb, and that single kernel option works fine : )
<arges> on lucid it works without that option btw
<smb> arges, Yes because on Lucid the server kernel had them built in
<apw> smb, why did we unbuild them in if we need them for the boot images .. hmmm
<apw> (assuming they didn't do it to themselves via renaming or something dumb)
<smb> apw, Thinking of it I guess we build them in now for Oneiric and Precise but since O is no LTS the cd images never get updated
<apw> smb, ahhh that would do it
<smb> apw, I think we did not realized soon enough that they miss and either need to go into udebs or be built in
<smb> And when we realized it was too late for IO
<smb> *O
 * herton hopes smb has some hearing protection ear plugs
 * smb has not and is slightly going more insane than usual
 * herton -> lunch
<apw> herton, ok they should be building "now" modulo the rather large queue the zinc outage has caused
<apw> herton, i assume we no longer need the herton/linux-stable stuff built ?
<rtg> apw, please review the top 2 commits on raring master-next
<apw> rtg, will do
<apw> rtg, well it looks a hell of a lot less vile than the mess we had before
<apw> rtg, and i thnk it does what you intend, though testing it would be the only way
<apw> rtg, to know for sure.  which i assume you have done
<rtg> apw, in progress. seems to be building OK
<apw> it looks much more sane by the end there
<apw> rtg, and better yet it won't even break lowlatency
<rtg> apw, well, it does not appear to have completely solved the problem. wtf ?
<rtg> unifdef: can't open /home/rtg/ukb/raring/i386/master-next/ubuntu-raring/debian/tmp-headers/install/include/linux/aufs_type.h.tmp: No such file or directory
<rtg> what is unidef ?
<apw> unifdef is part of the kernel installer, it removes the #ifdef _KERNEL_ bits from headers etc
<rtg> ah, helps if I spell it correctly
<herton> apw, thanks. Keep linux-stable stuff for now, it's the prestable, I have to work on it to move to mainline-build
<apw> herton, well they are being built daily already
<apw> in theory
<herton> apw, yep, that's good, I'll submit more changes to you to enhance it and so I can stop doing the prestable builds myself
<rtg> apw, hmm, I wonder if its $(conc_level) ? why the hell didn't I see that to begin with.
<apw> rtg, i think this is a bug in the kernel rather than us if anything
<apw> rtg, i conjecture it is making the directories in parallel with installing the headers
<rtg> yep, which is why I only see it on raring
<arges> apw, hey looking at bug 1075181 (efi/secureboot for precise). colin says that most of it is in place,  but a few packaging fixes are needed, anything I can help with ? or help test?
<ubot2> Launchpad bug 1075181 in ubuntu-defaults-builder (Ubuntu Precise) "Backport UEFI Secure Boot support for Ubuntu 12.04.2" [High,Fix committed] https://launchpad.net/bugs/1075181
<apw> herton, any idea how close to releasing linux-lts-quantal into -updates -- as once it is there i would like to slip a tiny packaging change in between your cycles
<apw> herton, for secure-boot support
<herton> apw, it's on testing right now, let me look
<apw> herton, thanks
<herton> apw, waiting on QA only, jjohansen already did security signoff, so once QA tests it (this is the testing week), it is good to go for -updates
<apw> herton, ok excellent
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<apw> herton, is the next SRU cycle the last one before 12.04.02 or is there one more do you know
<herton> apw, no, may be bjf knows
<bjf> apw, looking
<bjf> apw, the cycle that starts the week of Dec. 27 is likely to be the 12.04.2 kernel
<bjf> https://wiki.ubuntu.com/RaringRingtail/ReleaseInterlock
<bjf> aps, ^
<bjf> apw, ^
<apw> that was what i thought you would be saying, my counting on that wiki said the same; thanks
<apw> so anything in the tree by next monday ... yeeks
<bjf> apw, no you have two cycles
<bjf> apw, it has to be in the tree before Dec. 27th
<apw> we cannot guarentee that that kernel will hit by the 10th can we ?
<apw> that is only 2 weeks later
<apw> plus we lose what 2 weeks for xmas and the shutdown ?
<ogasawara> yeek, I was going by thee dec 27th kernel source freeze noted in that wiki
<bjf> apw, i still think that kernel will be the one
<apw> bjf, basically i am assuming the nov 27th cycle will release the week with the 20th dec in it, then there will be a gap, and week one will be jan 3rd
<bjf> apw, we've not had a respin in quite some time
<apw> ogasawara, well bjf seems happy we can get things in the next cycle
<apw> so i am going to try and hit this one, and hope we can get another in for the things that miss
<apw> thanks all
<bjf> apw, ogasawara i'll make it happen
<bjf> apw, ogasawara i'm also trying to scare vanhoof .. he seems unflappable right now though
<ogasawara> bjf: heh
<rtg> bjf, vanhoof is still trying to recover from holiday. of course he's unflappable.
<rtg> apw, pushed a couple more on master-next. I think I'll quit obsessing about headers and move on to uploading raring for the precise backport.
<apw> rtg, i am worried about these changes for the headers, these headers now rely on a config (whereas before they used defconfig) but on powerpc we do not have any flavours
<apw> rtg, oh presumably we don't have any headers there either?
<vanhoof> bjf: hey now :)
<rtg> apw, how can it _not_ have flavours ?
<apw> rtg, powerpc in master has no flavours
<vanhoof> rtg: -ETOOMUCHTURKEY
<rtg> apw, well, I don't think it generates headers anyway
<rtg> vanhoof, :)
<apw> rtg, we generate headers for powerpc linux-libc-dev
<vanhoof> ogasawara: we should have some feedback on a couple machines for ya RSN :D
<rtg> apw, but that comes from the master package, right ?
<apw> rtg, which is why it used a defconfig (or did)
<apw> rtg, right i am talking about the master package indeed
<ogasawara> vanhoof: sweet, I'm going down a checklist right now trying to compare my test kernel with a drm-intel-nightly build
<apw> rtg, you have just made the headers depend on a flavour config, right?
<vanhoof> ogasawara: cool, the tree we spoke about last week should be in our hands tomorrow as well
<rtg> apw, ok, since $(conc_level) was the root cause I can switch back to defconfig
<ogasawara> vanhoof: good, I was curious about when we'd see that
<vanhoof> ogasawara: yeah got feedback that its going through testing now and should have it no later than tomorrow
<apw> rtg, 
<apw> headers_dir := $(CURDIR)/debian/linux-libc-dev
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
<rtg> apw, ok, I think you're right that depending on a flavour will break ppc. I'm gonna re-upload with a corrected rule before BenC gets around to rebasing.
<rtg> I also think powerpc will FTBS
<ogra-cb> pessimist
<apw> rtg it should, i thought we uploaded before that change though
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues December 4th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<rtg> apw, nope. '# Pick the first flavour from which to make a valid config'
<apw> rtg, ack
<rtg> apw, damn. no good deed goes unpunished.
<apw> rtg, sadly indeed
<apw> at least we caught it pretty early
<apw> rtg, and if ben rebases on teh bad commit, _his_ upload will be ok
<rtg> apw, true
<apw> rtg, and britney will stop ours leaving -proposed
<apw> as there would be no linux-libc-dev for ppc, so i think we are safe, but it will ftbfs on powerpc surely
<rtg> apw, I'll get infinity to reject -4.10 as soon as I get an upload going. gotta redo -signed, right ?
<apw> rtg, i don't t
<apw> rtg, i don't think you need to reject anything ... the new ones will reject the old ones automatically, or replace them
<apw> rtg, yes -signed is upload number specific
<rtg> apw, ack
<apw> rtg, let me know when you are done and i'll re-rebase lowlatency for sanity
<rtg> apw, will do
<rtg> apw, pushed
<apw> rtg, ta, rebasing and buildtesting now
<rtg> apw, I'm whooping up on tangerine
<apw> heh there will be some howling in that lab
 * rtg -> lunch
<apw> rtg, you will be amused to find that the armhf build of your -4.10 build failed with the same headers failure you have hopefully now fixed
<rtg> apw, saw that. I'm running -4.11 test build on my SabreLite (w -j4)
<ogasawara> bjf: I was going to send the following announcement out -> http://pastebin.ubuntu.com/1392532/
<ogasawara> bjf: however, I noticed some discrepancy between kernel freeze dates noted in https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule vs. https://wiki.ubuntu.com/RaringRingtail/ReleaseSchedule
<bjf> reading
<bjf> ogasawara, i don't think the dates make any difference really. it's which cycle will be the last before the release and that will start the week of the 27th
<ogasawara> bjf: ack
<ogasawara> bjf: if there are any edits you want me to make before sending, let me know
<bjf> ogasawara, pgraner owns the schedules now so I guess he might be interested in the discrepancy (but probably not)
<bjf> ogasawara, it looks good to me
<apw> rtg, your powerpc just ftbfs again
<apw> make: *** No rule to make target `/build/buildd/linux-3.7.0/debian/build/build-/.config', needed by `install-arch-headers'.  Stop.
<rtg> apw, shit
<rtg> apw, I think I'll unwrap the whole mess and start over
<apw> ack
<jsalisbury> kamal, is this a custom or test kernel that you built:
<jsalisbury> ProcVersionSignature: Ubuntu 3.5.0-18.29+kamal11~DellXPS-generic 3.5.7
<jsalisbury> kamal, I noticed that kernel was being used in bug 1075752
<ubot2> Launchpad bug 1075752 in linux (Ubuntu) "My system froze for several minutes" [Medium,Incomplete] https://launchpad.net/bugs/1075752
<kamal> jsalisbury: that is my Sputnik PPA kernel from https://launchpad.net/~canonical-hwe-team/+archive/sputnik-kernel ...
<kamal> jsalisbury: but the backtrace doesn't look related to any of the sputnik changes
<jsalisbury> kamal, ack.  Thanks for taking a look.  
<kamal> jsalisbury: oh, I see the person reports the problem against 3.7-rc7 also.   this looks to me like they've actually got a hardware problem.   bad SSD?
<jsalisbury> kamal, will that model of system always need to get it's kernel from your Sputnik PPA?
<kamal> jsalisbury: no, the machine works fine with a regular kernel too -- the Sputnik PPA kernel just adds the touchpad driver and some backlight fixes
<bjf> apw, Mainline Build announcements on the mailing list; do those announcements come out automatically or do you have to do them by hand?
<bjf> apw, they are going to start triggering testing of those mainline kernels
<kamal> jsalisbury: so yes, testing that machine with mainline kernels or stock ubuntu kernels is a valid thing to do (I do it all the time).   (and I don't see anything like the reported issues).
<jsalisbury> kamal, ok, thanks for the info
<apw> bjf, the ones for specific version tags right?  those are automated by the publication into public_html
<bjf> apw, ack
<bjf> apw, you can see an example here: http://kernel.ubuntu.com/testing/index.html     precise kernel with (Mainline.Builder) after it
<bjf> apw, i should say, precise configuration
<apw> bjf, nice, there are no results udner the name
<bjf> apw, from there i got to: http://kernel.ubuntu.com/beta/testing/test-results/gonzo.2012-11-27_18-24-00/results-index.html
<bjf> apw, did you click the link under the "ran" column?
<apw> bjf, yeah the right hand ones work, its the machine name which not so much
<bjf> apw, that's just supposed to tell you about the system the test was run on
<bjf> apw, i could rethink that
<apw> bjf, np
<apw> bjf, so (Mainline.builder) is a person in this context
<bjf> apw, correct
<apw> bjf, do they expire off this front page?  or will we end up with millions
<bjf> apw, it was the simplest way of distinguishing it from others
<bjf> apw, i'm working on the expiration bit
<bjf> apw, it's easy enough to do by hand right now (for me)
<apw> bjf, looks great, and as always with these things one doesn't know if it works till it runs for a bit
<bjf> apw, yup
<apw> bjf, so you are testing the 'tags' mainline builds build and announce, that sounds good
<bjf> apw, yes, and this same process will be the trigger for automatic kick-off of SRU cycle kernel testing
<bjf> apw, so it will all me auto-magic
<apw> bjf, from hertons emails, or is there an automagic one
<bjf> apw, from herton/henrix emails to the ktml
<apw> bjf, if thats all we have gotten then great, though perhaps we can shankbot to emit a reliable
<apw> relaible email to trigger it
<bjf> apw, henrix and i discussed that and it's on the todo list
<apw> great, though i guess it emiting 'herton/henrix's email mgith kill two birds
<herton> shankbot has or had some email hooks, yes can just be reenabled
 * rtg -> EOD
<phillw> Hi good people, a real quick check... does "init 6" still cause the kernel to restart the computer?
<engla> sforshee: hi, I tested your brcmsmac patch series in the first version
<engla> sforshee: I see on the ML there is a story about a blocked connection after a high bandwidth burst (i.e. youtube); I reproduce this with an Apple air port AP.
#ubuntu-kernel 2012-11-28
<henrix> rtg: have you reached my email about the build failures?
<rtg> henrix, just responded
<henrix> rtg: ack, thanks. i'll check the 3 git trees in a minute
<henrix> rtg: ok, they look fine. thanks
<ogra_> rtg, i belibe that kexec hack stuff is for making the kernel work as second stage kernel for some android kexec boot kernel, i think the guy tries to achieve dual boot (without taking into account that the userspace isnt capable of supporting it and the next kernel upgrade will overwrite the kexec loader)
<ogra_> *belive
<rtg> ogra_, perhaps you should respond thusly on the mailing list.
<ogra_> well, lets see what the submitter says
<ogra_> i'm not thrilled by having to carry an extra patch for a feature we dont support
<rtg> nor am I, hence my questioning of the intent for his patches
<ogra_> the only proper way of dual booting i see is to use the recovery partition for the ubuntu bootimg and properly adjust flash-kernel for that, sadly nobody wants to work on that and poeple coming up witgh dual boot stuff come up with something insane like that one ... 
<ogra_> well, shrug
<herton> rtg, I got a problem with missing firmware when testing the 3.5 stable candidate. The issue is the firmware got removed from linux-firmware, because of being already on our linux-image packages. Not sure if this warrants some change or not for mainline kernels...
<rtg> herton, which one?
<herton> some firmware was missing for bnx2 on "gonzo" (our lab):
<herton> W: Possible missing firmware /lib/firmware/bnx2/bnx2-mips-09-6.2.1b.fw for module bnx2
<herton> W: Possible missing firmware /lib/firmware/bnx2/bnx2-mips-06-6.2.3.fw for module bnx2
<herton> rtg ^
<herton> in my case the missing one was bnx2-mips-09-6.2.1b.fw
<rtg> herton, did one of the stable patches update the firmware version ?
<herton> rtg, nope, kernel doesn't carry this firmware
<apw> herton, but our kernel for Q does ?
<herton> apw, yes
<apw> commit ?
<rtg> apw, herton: its a PXE boot essential file
<herton> apw, 23bae1788f8c6f216f0261adb6260f57debbf419
<apw> rtg, makes sense, does that mean we have a sauce patch pulling it into the kernle
<rtg> apw, likely. I'll have to check
<herton> rtg, yeah, I thought it could be the case, so didn't bother very much
<herton> but just reporting
<pgraner> apw, rtg: any idea about this? http://paste.ubuntu.com/1394421/   hint look around line 1233
<rtg> herton, this is vanille 3.5 stable ?
<rtg> vanilla*
<apw> rtg, seems to be a firware update patch in fact
<herton> rtg, yep, we noticed it on the lab because the machine didn't came up (not network), when testing my 3.5 stable update
<herton> *no
<herton> the dell one which uses bnx2
<rtg> herton, this is _our_ quantal kernel then ? WHat changed, or did it never work ?
<apw> pgraner, looks like we lost the pcie bus ...
<rtg> pgraner, looks kind of bad
<pgraner> apw, not quite the drives are still online just readonly
<herton> rtg, no, it's not the quantal kernel, it is a stock 3.5 kernel, with my stable update on top (3.5.7.1
<pgraner> apw, its a storage cab with 4x 3 TB drives
<rtg> herton, ok, that makes sense. there is a reason we carry bnx2 (and bnx2x) in the kernel package.
<pgraner> apw, and it suddenly flipped to ro
<pgraner> apw, digging around I found that, at the end of the dmesg you'll see where ext4 flipps em
<rtg> pgraner, consistent after power cycle?
<pgraner> rtg, after alot of disk I/O  i.e. moving/deleting files
<pgraner> rtg, its the 2nd time its done it to me
<rtg> pgraner, this is sort of what happened on tyler, e.g., going RO after lots of disk errors.
<sjanc_> hi,  would you consider enabling CONFIG_NFC_LLCP in ubuntu kernel 3.7 ?
<rtg> pgraner, wiggle some cables ?
<apw> pgraner, that seems to show a bunch or recovered error on the pci bus i think, then it stops and times out
<rtg> sjanc_, email it to the kteam list
<pgraner> rtg, I'm going to boot single and fsck the drives and see if the issues go away, if not I guess I'll upgrade to Precise and see how it goes
<sjanc_> rtg: ok
<rtg> pgraner, this is your everyday RAID set, right ?
<pgraner> rtg, yea, it gets pounded heavy, is a md raid0 set
<rtg> pgraner, since its external I'd have a close look at cabling
<herton> rtg, ok, just wanted to confirm that (needed on main kernel due to pxe). I know that also linux-firmware was stripped to save space, and the firmware needed was removed from it. It makes testing not possible on the machine on the lab needing it, since we don't carry anymore the firmware also on linux-firmware. But I can live with one machine not being able to do testing for mainline/stock kernels.
<pgraner> rtg, ack
<rtg> herton, ack
<rtg> ogra_, well, there you have it: https://lists.ubuntu.com/archives/kernel-team/2012-November/023407.html
<ogra_> yeah
 * ogra_ is already looking at the xda thread
<ogra_> "So what does the MultiROM does?
<ogra_> It acts as the boot manager, it manages status of device - what ROM is currently in /data, which boot.img is actually in boot partition. It changes android *.rc files so that they do not mount /system, /data and /cache by themselves."
<ogra_> oh my, i guess they would try to do the same in ubuntu then too
<rtg> ogra_, I assume we'd only do this for raring ? the kernel and user space mods I mean.
<ogra_> its a 14.04 thing
 * henrix_ -> late lunch
<ogra_> but i'm not sure we'll stay with nexus7 for 13.10
<rtg> ogra_, you mean _after_ 13.10, right ?
<ogra_> essentially i would like to leave the images alive as long as we're not short on image builder resources even beyond 14.04
<ogra_> rtg, nope, i mean *for* :)
<ogra_> we might switch to another device for 13.10 
<rtg> ogra_, um, I thought we were committed  to N7 for at _least_ 13.10, but now I realize I'm think 13.04.
<rtg> ok, I get it
<ogra_> we will release 13.04 for the nexus
<rtg> minor dislexia
<ogra_> we might switch to new hw after that
<rtg> agreed
<rtg> ogra_, so the user space hacks to support dual boot will take a bit of work ?
<ogra_> surely a change in how flash-kernel handles kernel updates
<ogra_> (or initrd)
<ogra_> in any case i wouldnt go for that kexec method since it changes userspace from initrd apparently and if they do that on android i would expect that this will have to happen on ubuntu too
<ogra_> "2. Multi-booting ubuntu
<ogra_> This is a bit different. First, ubuntu's boot.img is flashed and device is rebooted. Then, I have to move all folders in /data except "media" somewhere else, and move Ubuntu's root into /data. This is very dangerous and hacky, but I cannot just mount -o bind the ubuntu folder, because it has it's own init and would remount it again."
<ogra_> lovely
<rtg> egads
<ogra_> so lets just skip upstart altogether :P
<rtg> :)
<rtg> ogra_, I might be inclined to carry the kernel patch if it is truly benign, but not until after I get janimo's review. I don't think the user space mods will ever make it.
<ogra_> yeah
<ogra_> adding kexec support surely isnt bad if it doesnt influence any nrmal features
<janimo> rtg, ogra-cb I blame Pan for not sending out my email yesterday as an answer to that patch
<janimo> it was not a review, more like, 'does it depend on user space patches, and why should this be a nexus7 only patch as opposed to other-ARM too or Ubuntu SAUCE"
<ogra_> well, it seems to heavily depend on userspace changes according to the forum
<ogra_> (to use it)
<janimo> ogra_, right that's why I asked
<janimo> but my mail is not sent out
<ogra_> but as long as it not breaks anything 
<ogra_> (when not using it i mean)
<janimo> it's not the asm that looks intimidating, but I don't know the details of very early boot to know what this could endanger
<janimo> but still it looks just fine
<janimo> small non-intrusive
<rtg> janimo, shall I expect to see your email  response soon ?
<janimo> rtg, yes, I'll resend it
<apw> rtg, could it be caught in the approval queue ?
<janimo> apw, if it's the mail you're asking it is likely on my side. I switched to Pan to read newsgroups months ago, but only now had to send one
<rtg> apw, it wasn't there first thing. I'll check again.
<janimo> it briefly popped up some errorish msg which I ignored then but apparently the mail is gone 
<rtg> apw, nope, only one email in the moderator queue
 * ppisati goes out for a bit
<joaquin> Hello everyone! I have an issue with my Laptop when I use Ubuntu, it gets too hot!
<joaquin> I think it's a Kernel issue, but I don't know where to ask, here? or to the Kernel developers?
<apw> joaquin, have you filed a bug with all the details?
<apw> and how hot is "too"
<joaquin> There is a bug a launchpad https://bugs.launchpad.net/ubuntu/+source/linux/+bug/763477 but the bug at bugzila.kernel.org is closed due to inactivity
<ubot2> Launchpad bug 763477 in linux (Ubuntu) "lenovo y560 overheat. no /proc/acpi/fan" [Undecided,Confirmed]
<apw> seems to be open to me
<joaquin> apw, at launchpad is open, but at bugzilla.kernel.org is closed
<apw> joaquin, so the fan interface not appearing does not mean much as the bios is responsible for contorlling it anyhow
<apw> joaquin, just how hot does the machine get
<rtg> apw, Fetching omap(armhf)...extracting linux-image...GCC: (Ubuntu/Linaro 4.7.2-11ubuntu1) 4.7.2...done.
<rtg> Fetching generic(amd64)...extracting linux-image linux-image-extra...GCC: (Ubuntu/Linaro 4.7.2-12ubuntu1) 4.7.2...done.
<rtg> Fetching generic(i386)...extracting linux-image linux-image-extra...GCC: (Ubuntu/Linaro 4.7.2-12ubuntu1) 4.7.2...done.
<rtg> WARNING: inconsistant compiler versions detected
<joaquin> the fun work at full speed all the time, it reaced 78-80 C degrees
<rtg> apw, did we just straddle a compiler change ?
<apw> rtg, oh well, its during devel and not a milestone so ... *shrug*
<apw> looks like it indeed -11 -> -12
<apw> joaquin, so with the fan at full it overheats ... so the bios is controlling the fan
<apw> vanhoof, have we had a lenovo y560 pass through our hands at all ?
<joaquin> apw, what does it mean that the bios is controlling the fun?
<apw> janimo, on which release/kernel version does this behaviour exhibit and which (if any) was it ok
<apw> joaquin, normally linux has no controll over fans, if the fans are changing then the bios is doing something, it is seeing the heat and increasing fan speed to compensate
<joaquin> apw, OK, but the reason it's getting to hot, could it be a Kernel issue?
<apw> janimo, well it could be possible, we could be upsetting something in the bios during initialisation
<herton> apw, I think you can commit that fakeroot fix to mainline-build-one
<apw> joaquin, then again it cuold just be a bios bug, and windows never could drive the machine hard enough to trigger the issue
<apw> herton, did i not ?
<herton> apw, not yet :)
<apw> herton, done
<herton> apw, pulled it's here now, thanks
<joaquin> OK, so what can I do?
<apw> joaquin, well we need to try and eliminate some things.  if the machine has windows on you could see if windows has the same issue
<apw> if so its BIOS and we can do little
<apw> joaquin, if it used to work on an older Ubuntu, working out the latest one it was ok on/first one it is not ok on would help
<apw> joaquin, as we have had lenovos where the heatpipes have dried up and the issue was h/w just age
<joaquin> apw, with windows it works fine, no problem at all
<apw> janimo, and what temperature does it go up to if you run it hard
<apw> (in windows)
<apw> and what temperature when idle
<apw> and the same for ubuntu, and you still have not told me which release you are running even
<joaquin> Sorry, Ubuntu 12.10 64bits
<apw> have you run any older Ubuntu's on this machine
 * apw orders up some teeth to save the effort of pulling them
<joaquin> apw, no, I only used ubuntu 12.10
<apw> jsalisbury, yo ... i think i have a candidate for a 'rough bisect' for you :)
<joaquin> apw, in responde to a previous question, with some games Windows also ges hot, but I do not know the temperature, cos I never meassured
<jsalisbury> apw, cool, I like it rough
<jsalisbury> apw, bisects that is ;-)
<apw> jsalisbury, joaquin here could do with testing out like a P kernel or somethign to see if it this heat problem is new
<apw> joaquin, so is this "getting hot" when the machine is idle in Ubuntu or only when busy
<joaquin> apw, iddle
<apw> jsalisbury, might you be able to help joaquin test an older kernel for me
<cking> apw, that lenovo has Nvidia graphics, I suspect that's why it's getting hot
<joaquin> cking, apw, no NVIDIA, it's an older model with ATI RADEON
<jsalisbury> joaquin, are you the original reporter of bug 763477 ?
<ubot2> Launchpad bug 763477 in linux (Ubuntu) "lenovo y560 overheat. no /proc/acpi/fan" [Undecided,Confirmed] https://launchpad.net/bugs/763477
<joaquin> jsalisbury, no
<apw> cking, ahh could indeed be the GPU not being clocked well .. sigh
<jsalisbury> joaquin, ok.  It's probably best for you to open a new bug, so we have all your hardware details
<sforshee> the open source radeon driver is pretty terrible at power management, so it would likely contribute
<jsalisbury> joaquin, that bug could have similar symptoms, but be completely different if you have different hardware
<jsalisbury> joaquin, if you open a new bug, I can work through this with you in the bug, that way no information is lost and others can search for it.
<joaquin> jsalisbury, OK, I'll open a new bug tonight (I'm at work right now)
<cking> hrm, that bug lists VGA compatible controller [0300]: nVidia Corporation GT216 [GeForce GT 240M] [10de:0a34] (rev a2) (prog-if 00 [VGA controller])
<jsalisbury> joaquin, great.  I review all the new bugs, so I'll keep an eye out for it. 
<joaquin> GREAT thanks!
<jsalisbury> joaquin, np
<apw> joaquin, use 'ubuntu-bug linux' from a terminal window to make sure we get all the basic info
<apw> cking, yeah hense a new bug is appropriate
<joaquin> apw, that command will create a new bug at launchpad?
<apw> joaquin, yep thats the one
<apw> and attack lots of nice h/w info etc
<joaquin> apw, OK, great, I like the simplicity
 * ppisati -> gym
 * rtg skulks off for lunch...
<bjf> rtg, bug 1084192 while testing your rc7 kernel
<ubot2> Launchpad bug 1084192 in linux (Ubuntu) "[regression] symlink and hardlink restrictions default to off" [Undecided,New] https://launchpad.net/bugs/1084192
 * henrix -> EOD
<rtg> bjf, ack
<rtg> I think that was a SAUCE patch that got dropped
<jsalisbury> rtg, bjf, I added that bug to the hot list.
<rtg> kees, so I've reverted 561ec64ae67ef25cac8d72bb9c4bfc955edfd415 in Raring in order to address bug #1084192. Are you good with that ?
<ubot2> Launchpad bug 1084192 in linux (Ubuntu Raring) "[regression] symlink and hardlink restrictions default to off" [High,In progress] https://launchpad.net/bugs/1084192
<kees> rtg: yup! it's exactly the right solution. I hate that we'll have to carry that forever, but I lost a hated battle with linus over it.
<sbeattie> rtg: that's excellent.
<kees> rtg: I tried to get CONFIGs for it :(
<rtg> kees, yeah, I followed that thread, then went on vacation and kind of forgot about it.
<kees> I'm pondering introducing a system upstream for kernel builders to be able to set the defaults for the entire sysctl tree at build-time.
<mdeslaur> kees: oh! nice!
<kees> it'd let us remove all kinds of CONFIGs and satisfy my desires for these kinds of things being definable at build time
<sbeattie> ooh. that would be groovy.
<rtg> kees, it would certainly reduce the crust we carry in procps.
<kees> I have no earthly clue how to actually get it done yet, but it's been bouncing around in my head
<rtg> cruft*
<kees> rtg: well, procps serves a few purposes -- the main things is for people with stock kernels to get the same important behaviors as an ubuntu kernel where possible.
<kees> (and also serves as documentation for many of these settings too)
<rtg> kees, I'd have fixed this in procps, but I also have to think about the LTS backport kernels. I'm too lazy to SRU Precise procps.
<kees> I actually feel that one of the critical times to have link restrictions available is at early boot.
<kees> (i.e. it should be fixed in both places)
<rtg> kees, Linus does pint out that "if you have security problems due to link attacks during your early boot sequence, you have bigger problems"
<rtg> point*
<kees> rtg: I disagree strongly with that, especially when looking at some android vulnerabilities.
<kees> rtg: he's a security absolutist, so can't handle the concept of layered security. why risk it, if it's trivially solvable, imo.
<rtg> kees, well, I was thinking about procps in the initrd. How could anything get in front of that ?
<rtg> obviously taht only applies if you actually _have_ an initrd
<kees> procps doesn't run in initrd and yeah, that too
<rtg> well anyway, its solved the Ubuntu way for now :)
<sbeattie> \o/
<rtg> sbeattie, do you think this is important enough to upload soon? otherwise we likely won't until the next -rc (or final).
<sbeattie> rtg: it can wait, that's fine.
<rtg> sbeattie, ack
 * rtg slinks off to get some book learning on IPv6
<infinity> hggdh: Daily ping, re: backlogged armadaxp verification.
<infinity> hggdh: At this point, maybe we'd be better off skipping the current round and bringing in the next set to proposed?
<infinity> hggdh: Since the ones in the PPA cover a CVE...
<hggdh> infinity: I am currently running (what I hope to be) the first real armada test
<hggdh> infinity: so your daily ping came on time :-)
<hggdh> infinity: now the only thing I do not know is how long it will take. May be from one to 6 hours per run
<infinity> hggdh: Alright.  I'll hold off overwriting those kernels a bit longer, then.
<infinity> hggdh: Just want to get all the flavours caught up, and those two are from the last cadence.
<hggdh> infinity: I know. Sorry for the delay
<hggdh> infinity: I have a problem on the armada. I have quantal-proposed enabled, and apt-get dist-upgrade does not find the kernel version 3.5.0-1605.7, only 3.5.0-1604.6
<infinity> hggdh: That was sort of my point...
<infinity> hggdh: https://bugs.launchpad.net/ubuntu/+source/linux-armadaxp/+bug/1068573
<ubot2> Launchpad bug 1068573 in linux-armadaxp (Ubuntu) "linux-armadaxp: 3.5.0-1604.6 -proposed tracker" [Medium,In progress]
<infinity> hggdh: That's for 3.5.0-1604.6, 3.5.0-1605.7 is still in the PPA because the previous one never got verified/released.
<infinity> hggdh: So, should we just skip the two old ones and push forward with the PPA ones?
<hggdh> infinity: ah, this bug is not showing in the kernel SRU workflow
<hggdh> bjf: ^
<infinity> It shows in http://status.qa.ubuntu.com/reports/kernel-bugs/reports/sru-report.html
<hggdh> but not in http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html
<infinity> And for the out-of-date precise kernel:
<infinity> https://bugs.launchpad.net/ubuntu/+source/linux-armadaxp/+bug/1068733
<ubot2> Launchpad bug 1068733 in linux-armadaxp (Ubuntu Precise) "linux-armadaxp: 3.2.0-1610.15 -proposed tracker" [Undecided,In progress]
<bjf> hggdh, ack
<infinity> hggdh: Oh, the bug there is that ike/jani inverted the precise/quantal bugs by accident, so they're under the wrong heading in your report.
<hggdh> actually, it does appear in the workflow, but it seems quantal and precise are mixed
<hggdh> heh
<infinity> bjf: Not your bug, really.
<bjf> infinity, hggdh lets just drop armadaxp support and that would solve this "problem"
<infinity> :P
<hggdh> bjf: now that I finally got it (almost) in shape? ;-)
<infinity> If we drop x86 support, we'd solve a lot more of our problems.
<bjf> infinity, hggdh we probably own 96% of all the armadaxp boards in existance
<bjf> infinity, but then i'd be out of a job and that would make my wife "sad"
<infinity> bjf: Yeah, but on the bright side, no more tax returns.
<hggdh> there is that
<bjf> infinity, i didn't say I wouldn't be happy
<hggdh> infinity, bjf: well, it is running the correct kernel, then, let's wait a bit and see how it fares
<infinity> hggdh: Fancy.  Do you get two machines to do precise and quantal in parallel, or did they only trust you with one? :)
<hggdh> infinity: I am absolutely untrusted, so there is only one in the lab
<hggdh> infinity: OTOH, I just gave you some kernels to promote (pandas andx86)
<infinity> hggdh: The oneiric ones?  Or more still?
 * infinity is doing oneiric right now.
<hggdh> infinity: pandas -- oneiric, precise and quantal; x86 -- lucid, LTS-oneiric, and precise 
<infinity> The flavour ones won't get copied until master is ready.
<hggdh> ack
<infinity> (But glad they're tested anyway)
<infinity> Oh, and x86/precise still needs cert testing.  But that's not your thing. :)
<hggdh> infinity: sorry, both oneiric and lts-oneiric are done
<infinity> hggdh: Yeah, they're already copied. :)
<hggdh> heh
#ubuntu-kernel 2012-11-29
<jsalisbury> bjf, I added locking to the auto-reports-mako job on people by using flock.  I'll do the same on cranberry.
<hggdh> infinity: quantal armadaxp done, should be ready for you soon
<infinity> hggdh: \o/
<infinity> hggdh: precise tonight too, or will that be tomorrow?
<hggdh> infinity: I am afraid it will be tomorrow, just found there is a race between the test driver code, and the armada boot
<infinity> hggdh: S'ok.  Wasn't pressuring, just looking for a timeline. :)
<hggdh> infinity: I understand, np there. Just giving you a bit more of data
 * infinity nods.
<hggdh> infinity: anyway, for the record, it took ~ 3.5 hours to run
<infinity> That's not too bad, given it only needs to run a few times every three weeks.
<hggdh> I agree there. It is only bad cuz expected end is now around 00:00 CST -- and I will be *very* asleep by then. Or so I hope. Since I have to check the output, this puts a go/no-go for tomorrow 0630 CST
<infinity> hggdh: Yeahp, s'all good.  Fire it off and let me know the results in the morning, and we can move this show along. :)
<infinity> hggdh: And then I'll promote two more kernels for you tomorrow. :P
<infinity> (To proposed, that is, for testing again)
<hggdh> infinity: that's cool, gives me some job security
<infinity> Heh.
<Konstigt> hello.. any packages if I want 3.7 (latest) in 12.10/Quantal avail? Looked at http://kernel.ubuntu.com/~kernel-ppa/mainline but no packages for Quantal including all files..
<apw> Konstigt, "including all files" ?
<apw> Konstigt, (not that we recommend using those kernels for anything other than testing) you should be fine using the v3.7-rc7-raring one; the raring there refers to the config used, and -raring is the right config to use for 3.7 
 * apw pokes smb
<rtg> apw: I've been getting some weird PPA build failures lately. That lib/oid thingy. Restarting typically fixes it.
<apw> rtg, got an example 
 * smb is not listening to apw (at least not before returning)
<rtg> apwhmm, not that I've kept. restart the build wipes out the log.
<apw> rtg, ok next time grab a copy of the log, if you don't have one in Downloads
<apw> and perhaps we can figure out what the heck this thing is
<rtg> apw: we looked at one together awhile ago. neither of us could make sense of it at that time either.
<rtg> I don't think its a timing race.
<rtg> apw: I'm just complaining. not really asking you to do anything :)
<apw> rtg, :)
<rtg> ogra: is it safe to upgrade my N7 to Raring ? Thought I'd do taht before testing the kexec kernel patch.
<ogra_> rtg, well, you lose unity 
<ogra_> the nux patch is still missing so all unity elements are garbled
<ogra_> if you just use it via ssh, go ahead :)
<rtg> ogra_, huh, well maybe I'll just leave it as is for now and test the Raring kernel on Quantal. that should be sufficient.
<ogra_> yeah, effectively you just want to know if it boots
<ogra_> i'm wondering if we could somehow teach kmod to load the wlan module, that way it wouldnt have to be builtin and we wouldnt have to carry a 4MB vmlinuz
<ogra_> (issue is that nothing loads the module if you build it modular, /etc/modules works indeed)
<rtg> ogra_, its not udev triggerable ?
<ogra_> hmm, that might be
<ogra_> though i think it is an SDIO device, not sure if udev sees much of it
<rtg> ogra_, ah, that may be why.
<rtg> I'm not sure there is a platform device for SDIO that emits discovery events
<ogra_> oh, intresting, putting "noinitrd rootwait" on the nexus cmdline lets me end up in the ubuntu initrd :P
<ogra_> but at least i get a shiny splash before that happens
<bjf> brendand, are my Precise and Quantal kernels going to get their testing finished today ?
<brendand> bjf - absolutely
<ogasawara> herton: heya.  bjf and I were chatting yesterday and he said you might be making some improvements to shankbot to automatically send upload announcements to the list
<herton> ogasawara, yep, I can do it, it already sends email sometimes to some of the SRU lists, so it should be straightforward to do it
<bjf> ogasawara, i talked to herton. shank-bot will process any tracking bug regardless of series
<ogasawara> bjf: ah sweet
<ogasawara> herton: so if I just create a tracking bug for our devel kernels, shankbot could handle it
<herton> ogasawara, the bug just needs to be created with create-release-tracker. We may need to tweak the tasks though for dev kernels
<herton> ogasawara, yes, any bug tagged with kernel-release-tracking-bug, create-release-tracker should do it with the tasks
<bjf> herton, did you resolve that firmware issue you were having with your stable kernels on that one test system (gonzo) ?
<ogasawara> herton: I was also curious if for the devel kernels along with sending to our kernel-team mailing list, would it also be possible to CC the ubuntu-installer mailing list as well as some specific QA individuals and BenC?
<herton> bjf, I talked to rtg, the firmware were moved to linux-image for pxe boot, and removed from linux-firmware to save space (on the media I think)
<herton> ogasawara, yes, that's possible
<herton> ogasawara, just send to me the list of who wants the email I'll add
<ogasawara> herton: ack
<bjf> herton, so what does that mean for how we fix that for that particular system? do we need to install another pkg?
<bjf> herton, i think i'm seeing the exact same failure for mainline builds
<herton> bjf, yes, mainline builds will fail with same issue. I think for the moment it could be copied manually from the main kernels if possible
<rtg> bjf, you could install the upstream linux-firmware package. that has all the firmware ever created.
<bjf> rtg, ack
 * rtg restores some armhf config options in Raring
<herton> rtg, were you suggesting bjf install our linux-firmware package?
<rtg> herton, well that won't help 'cause its missing the firmware you need. I'm suggesting you install the debian package which AFAIK hass all the firmware you'll need.
<bjf> rtg, where do i get that from?
<rtg> bjf, hang on, lemme find it.
<rtg> bjf, well, maybe it won't work so well because you'll have conflicts. that, and debian hasn't kept up to date: http://packages.debian.org/search?keywords=firmware-linux-free&searchon=names&suite=stable&section=all . maybe copying manually for stable testing is the best route.
<ogasawara> herton, bjf: just ran create-release-tracker for Raring -> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1084640
<ubot2> Launchpad bug 1084640 in linux (Ubuntu Raring) "linux: 3.7.0-5.13 -proposed tracker" [Medium,In progress]
<ppisati> mumble failing?
<herton> ogasawara, ack, shank just set the prepare-package-* tasks to In Progress, shank bot will monitor the build on c-k-t ppa and set that to fix released when done
<rtg> ppisati, working for everyone else
<herton> s/shank//
<ppisati> ba
<ppisati> h
<ogasawara> herton: do we want to add some checks so that the Kernel SRU Workflow bits aren't added to devel kernel tracking bugs?
<bjf> ppisati, was working fine for us a second ago
<ppisati> yeah, but it keeps disconnecting
<ppisati> maybe it's my network
<bjf> ppisati, seems stable for me
<herton> ogasawara, ah yes, I have to adapt create-release-tracker to stop subscribing SRU team etc., will do
<herton> ogasawara, it's a easy check, just see if it's set as a development kernel or not on ktl/ubuntu.py
<rtg> ogra: uploaded linux-nexus7_3.1.10-8.15 to raring with kexec patches.
<ogasawara> herton: ack.  you also just mentioned shank bot monitors the ckt ppa...we actually don't upload our devel kernels to the ckt ppa.  is that a problem?
<herton> ogasawara, hmm it is, it monitors c-k-t ppa for the builds, but I can change that. It's uploaded directly to -proposed correct?
<ogasawara> herton: yep that's correct
<herton> ok, will fix this
 * rtg -> lunch
<ogasawara> herton: awesome, thanks.  no hurry on this if you have more important things to address
<ogasawara> herton: this is one of those nice to have types of things, but not blocking or high priority by any means
<herton> ogasawara, ack, I think it'll not be too much work, probably today or monday I can have it ready
<bjf> ppisati, maybe it's a sign to call it a day 
<ppisati> ok, killed mumble now
<ppisati> still trying to undestand one thing, can't quit yet :P
<herton> ogasawara, hmm, I think I'll want to create a new "Kernel Workflow" or "Kernel Devel Workflow" project on Launchpad, it'll be similar to Kernel SRU Workflow on tracking bugs. We need a similar set of tasks on the tracking bug
<ogasawara> herton: ack
 * henrix -> EOD
<BenC> infinity: A little heads up next time you go poking around my git trees :)
<BenC> I should enable email notifications for those trees
<rtg> hmm, the current Raring kernel has broken my touchpad. Lenovo x120e
<infinity> BenC: Hrm?  Did I cause you grief somehow?
<infinity> BenC: The general concept of DVCS is that when you try to push, you notice you're out-of-date. :P
<infinity> rtg: You should find someone on the kernel team to look at tha-- waaaait.
<rtg> infinity, actually, I was just about to consult with sforshee :)
<BenC> infinity: I noticed it after I did the uploadâ¦the one time I didn't push before dput
<infinity> BenC: Well done. :P
<BenC> infinity: And I'm used to doing --force on linux-ppc since it's almost always a rebase
<BenC> I'm not sure why github doesn't send email notifications to meâ¦let me check my spam folder
<infinity> BenC: Anyhow.  I can poke you when I commit changed, but I figure if you're maintaining your packages in a DVCS, pushing before upload should just be part of the workflow.
<infinity> s/changed/changes/
<BenC> It usually is, so disregard my grumbling
<BenC> Watch out if you ever mess with linux-ppc though
<infinity> BenC: Also entertaining that the changelog now has the source package name flip-flopping. :)
<sforshee> rtg, what kind of touchpad? synaptics?
<BenC> History must be retained :)
<rtg> sforshee, thats what I'm trying to figure out. any hints ?
<infinity> BenC: Anyhow, I rejected your accidental linux-ppc-meta, s'all good.
<BenC> Thanks
<sforshee> rtg, that's a black art ;)
<infinity> Oh lord, it's firefox security day.
<infinity> Poor buildds.
<sforshee> rtg, check dmesg, if there's nothing there you'll have to boot to a kernel where it works
<rtg> sforshee, searched for 'synap' to no avail
<sforshee> rtg, try searching for 'psmouse'
<rtg> sforshee, will do as soon as this kernel is done installing. tip of master-next
<sforshee> rtg, ack
<rtg> sforshee, hmm, 'mousedev: PS/2 mouse device common for all mice'. Is that bad ?
<sforshee> rtg, I'll have to look to be sure, but I suspect that means it's just falling back to the standard PS/2 mouse protocol
<rtg> sforshee, I have a bunch of older kernels installed. lemme see what they have to say.
<sforshee> rtg, it still doesn't work at all though?
<rtg> sforshee, frozen
<sforshee> rtg, that message is actually completely generic, it will always appear even if you don't have a mouse at all
<rtg_> sforshee, [   19.179331] psmouse serio4: synaptics: Touchpad model: 1, fw: 7.5, id: 0x1e0b1, caps: 0xd000b3/0x340000/0xa0400
<rtg_> [   19.179358] psmouse serio4: synaptics: serio: Synaptics pass-through port at isa0060/serio4/input0
<rtg_> 3.5.0-18-generic
<rtg_> let the bisecting begin
<sforshee> rtg_, so right now all you know is that it broke between 3.5 and 3.7?
<sforshee> rtg, ^
<rtg> sforshee, I'm gonna try and get a little closer. I'm just sure the early 3.7 kernels worked
<sforshee> rtg, virtually nothing has changed in the mouse or serio code since 3.7-rc1
<rtg> sforshee, well, 3.7.0-2 doesn't work, but I'm sure it _used_ to. I would have discovered this issues 3 or 4 weeks ago. Could something in user space be buggered ?
<sforshee> rtg, it _could_ be, but then you said the 3.5 kernels work
<rtg> sforshee, yep
<sforshee> rtg, we don't have the cypress patches in raring?
<rtg> sforshee, I think they clashed and got dropped. lemme chaeck for sure
<sforshee> rtg, the code isn't there
<sforshee> i was just suprised
<sforshee> *surprised
<rtg> sforshee, kamal was working to upstream them, so I though we'd get 'em for 3.8
<sforshee> rtg, there was this one userspace integration issue that the first round of those patches caused, which is why I noticed. But we can rule that out.
<kamal> rtg, sforshee: the cypress driver was indeed dropped from raring
<sforshee> rtg, can you pastebin dmesg from a non-working kernel?
<kamal> one vestige remained (an enum that should have been harmless) but rtg recently rebased that away too
<rtg> sforshee, lemme reboot and get tip of master-next dmesg
<rtg> sforshee, ok, its intermittent. works now with tip of master-next. warm boot. I've also tried cold booting.
<rtg_> sforshee, rtg@x120e:~$ dmesg |egrep -i "synap|mouse"
<rtg_> [    1.800980] mousedev: PS/2 mouse device common for all mice
<rtg_> [   19.457503] psmouse serio4: synaptics: Touchpad model: 1, fw: 7.5, id: 0x1e0b1, caps: 0xd000b3/0x340000/0xa0400, board id: 1403, fw id: 749625
<rtg_> [   19.457528] psmouse serio4: synaptics: serio: Synaptics pass-through port at isa0060/serio4/input0
<rtg_> [   19.501730] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio4/input/input8
<rtg_> [   25.360441] psmouse serio5: trackpoint: IBM TrackPoint firmware: 0x0e, buttons: 3/3
<rtg> sforshee, hmm, I'll have to noodle on this tomorrow. I gotta launch.
<sforshee> rtg, hmm. It may be that after booting a bad kernel you need a cold boot to reset the EC to get it out of a funky state
<rtg> sforshee, possibly. I'll see if I can determine a pattern.
 * rtg -> EOD
<infinity> BenC: Oh, mind if I gimp your linux-ppc upload to the end of the buildd queue?  With firefox appreciation day happening, I'd like to give the buildds some breathing room, and it looks like it was just a rebase against master.
<BenC> infinity: it's unimportant from my end, so no problem
<infinity> BenC: Great, thanks.
<luc4_mac> Hi! I recently noticed that my server seems to have issues with USB. I just noticed a kernel trace in dmesg. Can anyone have a look?
<myhrlin> luc4_mac: go ahead and paste the dmesg output with your paste-site of choice :)
<luc4_mac> myhrlin: http://pastebin.com/t1cF17Ts
<luc4_mac> myhrlin: here I plugged in a usb mouse.
<luc4_mac> myhrlin: now I tried with a usb pen drive and a usb hard disk.
<luc4_mac> myhrlin: nothing seems to be working.
<luc4_mac> myhrlin: now I tired with an older kernel. I get other usb error messages and the mouse is still not working, but it seems after a while an hard disk appeared.
<luc4_mac> myhrkin: this is the output http://pastebin.com/WmiDTbqc
<myhrlin> luc4_mac: I'm sorry but I'm not really sure what to do.  I just said to provide the paste in case someone sees your question and would be able to solve it but they wouldn't have the dmesg output available
<myhrlin> and if they think they can solve it but you're not around to provide the dmesg output or something goes wrong... :) better just paste it
<luc4_mac> myhrlin: ok, thanks for the advice then!
#ubuntu-kernel 2012-11-30
<infinity> hggdh: Two more armadaxp kernels for you to test, enjoy.
<infinity> henrix_ / bjf: shankbot's wrong about components for linux-signed.  See #1078041
<infinity> henrix_ / bjf: (Those packages should be in main, and they are, it wants me to put them in universe)
 * apw yawns
 * ppisati dismembers the haswell box and goes testing leann's kernel
<tjaalton> bah, missed ppisati
<ogra_> he'll come back 
<tjaalton> sure :)
<henrix> infinity: ack, thanks. this is probably a bug in the bot, with recent changes
<infinity> henrix: Great.  Pls fix, so it stops calling me "incomplete".  It hurt my feelings.
<henrix> infinity: heh, will do :)
<t-lo> Hi, what is the differcene between the linux-signed-image and the regular one?
<luc4_mac> Hi! I'm getting these erros when simply connecting a mouse to my Kubuntu: http://pastebin.com/t1cF17Ts, http://pastebin.com/WmiDTbqc. Anyone with an idea of the reason?
<alexbligh1> I get the feeling this is a fantastically stupid question, but all the docs on running a Quantal kernel on Precise point to https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport yet the packge list there does not have any kernel packages (just x-org). Which part of my brain needs rearranging?
<ppisati> brb
<infinity> alexbligh1: The lts-backport kernels are in the archive, not in a PPA.
<alexbligh1> ooh, when did that change? I thought that was targetted for 12.04.2
<infinity> They've always been in the archive.
<infinity> Just not installed by default.
<infinity> apt-get install linux-generic-lts-quantal
<infinity> For instance.
<alexbligh1> I'm pretty sure that must have changed substantially after q was out. OK, that makes things easy ...
<infinity> alexbligh1: Previous LTSes have had lts-backport kernels for years.
<infinity> alexbligh1: precise obviously didn't have one until after Q was final.
<infinity> And linux-generic-lts-raring will exist once R is out.
<alexbligh1> infinity, oh yes I know about previous ones. I had just read somewhere that the first backport target was for 12.04.2 on Jan 31 or something.
<infinity> alexbligh1: Different things.  12.04.2 is the target for putting this whole stack on the install CD by default.
<infinity> alexbligh1: Which we've never done before.
<infinity> alexbligh1: But doesn't have much to do with the archive state.
<tjaalton> yeah they got moved to main after q was released
<tjaalton> s/they/the backport kernel/
<alexbligh1> Ah I got confused by "The official hardware enablement stack will be officially released as part of the 12.04.2 update." on the q-lts-backport page; I assumed that included the kernel
<tjaalton> it does
<tjaalton> but you can use it separately too
<alexbligh1> yep. thanks.
<luc4_mac> Hi! I'm getting these erros when simply connecting a mouse to my Kubuntu: http://pastebin.com/t1cF17Ts, http://pastebin.com/WmiDTbqc. Anyone with an idea of the reason?
<ogra_> rtg, fyi ... from my udev log on the nexus7 ... 
<ogra_> ACTION=add
<ogra_> DEVPATH=/devices/platform/sdhci-tegra.2/mmc_host/mmc1/mmc1:0001/mmc1:0001:2/net/wlan0
<ogra_> DEVTYPE=wlan
<rtg> ogra: you're running a kernel with wlan built in ?
<ogra_> yep
<ogra_> ah, but there also seems to be a platform device
<ogra_> KERNEL[13.120863] add      /devices/platform/bcmdhd_wlan.1 (platform)
<ogra_> DEVPATH=/devices/platform/bcmdhd_wlan.1
<ogra_> DRIVER=bcmdhd_wlan
<rtg> ogra: too many balls in the air. remind me again why you'd prefer that driver to be modularized ?
<ogra_> to get a kernel binary smaller than 4M
<rtg> is that an arbitrary boundary ? what impact will that have ?
<ogra_> so the initrd can grow big enough to carry plymouth 
<ogra_> the bootimg cant be bigger than 8M in total
<ogra_> thats a limitation the bootloader sets with its hardcoded partitioning
<rtg> ogra: so the gain is that the module is compressed in the initrd ?
<ogra_> no, the gain is that when i build with MODULES=list i ahve enough space for plymouth in initrd
<ogra_> i dont need wlan in initrd :)
<rtg> ogra: ah, right. rootfs....
<ogra_> (MODULES=list with no list doesnt pull in any generic modules, only the ones pulled in directly by hooks will appaear)
<rtg> ogra: so you're prolly looking for other candidates besides wlan to modularize as well
<ogra_> well, wlan pulls in the whole stack 
<ogra_> i bet the gain would be above 1M if you just modularize driver and all dependend wlan bits
<rtg> ogra: do you know that a modular wlan and stack will be sufficient savings ?
<ogra_> no, i'll do some test builds over the weekend
<ogra_> overall i would like to see the device booting a lot faster, dropping fat from kernel and initrd is usually my first step for that :)
<rtg> ogra: do we know _why_ wlan is built in ? janimo generated this initial config.
<ogra_> it doesnt autoload
<rtg> ah, so need to figure out why
<ogra_> well, i would guess because the SDIO bus provides it as a subdevice of  the MMC :)
<rtg> ogra: are you cross compiling? just wondering 'cause thats a way faster method for testing kernels.
<ogra_> for testing i do, if i would upload that i would do a native build first
<rtg> ogra: right, me too. but thats kind of a slow build. roughly an hour
<rtg> ogra: ok, I'll take a stab today at figuring out how to get wlan to auto-load.
<ogra_> cool, thanks !
<luc4_mac> Hi! I'm getting these erros when simply connecting a mouse to my Kubuntu: http://pastebin.com/t1cF17Ts, http://pastebin.com/WmiDTbqc. Anyone with an idea of the reason?
<ohsix> looks like you have some irq setup problems with your firmware
<luc4_mac> ohsix: talking to me? This is the normal ubuntu kernel.
<janimo> rtg, I always used cross-compiled the nexus7 kernel
<rtg> ogra: you may not realize as much savings as you think by modularizing bcmdhd. The only part of the WIFI stack that is even being built is CONFIG_CFG80211 which is used for WEXT. it looks like bcmdhd is a full mac driver.
<rtg> incidentally, this driver looks like a port from windoze, e.g., it totally sucks.
<ogra_> rtg, :(
 * henrix -> late lunch
<rtg> ogra: I think I'll hold off figuring out how to get it to auto load until you have some size results, 'cause I don't think it'll be as much as you think.
 * rtg will bbiab
<arges> ogasawara, hi.
<ogasawara> arges: hey
<arges> ogasawara, what does VGA S/R x1 mean?
<arges> start reboot?
<ogasawara> arges: suspend/resume once connected over VGA
<arges> ahh
<arges> that makes more sense
<ogasawara> arges: sorry, it's a bit cryptic
<vanhoof> ogasawara: just sent ya a new mail, he's west coast so may be a bit
<ogasawara> vanhoof: ack, thanks
<tjaalton> ogasawara: btw, you probably didn't backport the hsw changes to drm.ko?
<ogasawara> tjaalton: I tried not to touch drm.ko and keep it restricted to i915
<tjaalton> well, you can't :)
<ogra_> rtg, sniff ... you are right, only 100k
<ogasawara> tjaalton: anything specific patches I need to consider or the whole lot?
<tjaalton> I haven't checked out what the changes were
<ogra_> ogra@anubis:~/Desktop/tmp/linux-nexus7-3.1.10$ ls -lh debian/build/build-nexus7/arch/arm/boot/zImage
<ogra_> -rwxrwxr-x 1 ogra ogra 4,3M Nov 30 15:48 debian/build/build-nexus7/arch/arm/boot/zImage
<ogra_> ogra@nexus7:~$ ls -lh /boot/vmlinuz-3.1.10-8-nexus7
<ogra_> -rw-r--r-- 1 root root 4.4M Nov 29 18:24 /boot/vmlinuz-3.1.10-8-nexus7
<tjaalton> pzanoni wanted to know
<tjaalton> if the kernel had those changes
<ogra_> crap ... and droppind the sound bits to modules fails to build
<ogra_> *dropping
<rtg> ogasawara, how did you get this haswell platform installed ? USB ? Have you figured out how to get it to netboot ?
<ogasawara> tjaalton: I should take that back, slightly.  I did pull back an entirely updated drm_mm.c specifically for hsw
<tjaalton> ogasawara: ah, ok
<ogasawara> rtg: usb and a 12.04.1 iso
<rtg> ogasawara, server, then upgrade to desktop ?
<hggdh> infinity: oh the joy
<infinity> hggdh: :)
<tjaalton> ogasawara: pzanoni is already working on resume with vga
<tjaalton> known to be broken, apparently
<ogasawara> rtg: I believe so, but /me is having a hard time remembering how I originally installed
<ppisati> rtg: i did that - server -> dsktop
<vanhoof> ogasawara: was it from my iso?
<ogasawara> tjaalton: ok thanks, I figured as much but wanted to make sure
<rtg> ogasawara, I remember fighting with this machine weeks ago. 
<ogasawara> vanhoof: no
<rtg> ppisati, thanks
<ppisati> rtg: iirc only vga worked after tweaking the commandline...
<ogasawara> vanhoof: but if you made me a new image with the newer test kernel it would probably work
<rtg> ppisati, what is the command line tweak ?
<vanhoof> ogasawara: is your tree anywhere I could stuff deb in? 
<ppisati> rtg: trying to find what i did... hold on
<vanhoof> assume on tangerine somewhere?
<ogasawara> vanhoof: my debs and tree should still be on gomeisa, see my quantal-amd64 dir
<vanhoof> k
<ogra_> wow, so modularizing the sound bits in the nexus7 kernel makes all USB gadget support fail ... modularizing that as well makes the usb controller code fail. modularizing *that* as well, makes the battery driver fail 
<sforshee> rtg, I'm pretty sure I installed desktop directly on my haswell kit, using native EFI boot
<ogra_> what a mess !
<sforshee> rtg, it used vesa for video I think
<rtg> sforshee, my unit seems to be kind of funky. plugged in a Cruzer and now it won't bring up the boot options menu. trying a diff USB stick now...
<sforshee> rtg, my experience with the firmware is that it's kind of flaky
<ppisati> rtg: nomodeset
<sforshee> ogasawara, fyi the vga on my haswell box isn't working with your kernel
<ppisati> rtg: stock quantal server iso burnt on a usb stick + nomodeset
<ppisati> rtg: after the installation i plugged in an ati card + apt-get install ubunt-desktop
<ogasawara> sforshee: yours is a mobile SDP right?
<sforshee> ogasawara, yep
<sforshee> rtg, for EFI boot I had to burn the USB stick with usb-creator-gtk, dd-ing the image to the stick wouldn't boot
<rtg> sforshee, shit
<vanhoof> ogasawara: tons in here, can I copy over and use make-ksource and i'll pop into a ppa for an iso
<t-lo> Hi all, what is the differcene between the linux-signed-image and the regular one?
<apw> t-lo, the linux-signed-image ... is signed
<apw> signed in an EFI secure boot sense
<t-lo> apw: ah, ok, makes sense :) thx!
<cking> ogasawara, we are meant to be testing 12.04 userspace + your 3.5 kernel?
<ogasawara> cking: yes please
<cking> phew, results sent. getting it installed was fun
<ogasawara> cking: I should have specified that clearly in the email, rather than alluding to it
<cking> ogasawara, it was clear enough. I did a CSM install rather than UEFI. - did you want UEFI tests too?
<sforshee> oh crap, I'm testing 12.10 userspace
<cking> sforshee, that's what makes it so fun to install :-)
<ogasawara> cking: eventually, but I think for the initial feedback I'm wanting, what you've done is great
<sforshee> cking, I was testing what I already had installed because I can't handle too much installation fun ;-)
<cking> installing it on the laptop was more painful than punching one's face, mind you I did have a lose cable SATA connector which didn't help
<ogasawara> cking: I think I've got enough ammunition to at least get this circulated to the list so we can at least  try and get this landing in the next round of SRU and eventually into the daily precise images
 * cking suspects the S3 results may differ, so I can give that a quick spin on the desktop 
 * sforshee _is_ at least testing UEFI boot
<rtg> cking, remind me how to enable CSM. Is that in the 'Secure Boot Configuration' menu ?
<cking> rtg,  CSM is the legacy BIOS mode - it's one of the *many* firmware options. I normally fall back to the UEFI shell, type "exit" and it's one of the options, lemme find it.
<vanhoof> rtg: on SDPs usually in boot options
<vanhoof> rtg: both, csm or uefi only
<ppisati> doh! i was testing Q usrspace too
<cking> unfortunately I've hacked around these options so often I have no idea what the defaults are now
<rtg> hmm, what a pain this machine is
<ogasawara> bjf: I assume you're still out from knitting today?  /me arranges alternate transportation
<bjf> ogasawara, i've not been up long enough to know for sure, so for now you need to assume i'm not
<ogasawara> bjf: ack
<cking> rtg, my clue to successful install is to install on another box, swap drives, boot, run update-grub, done
<rtg> sforshee, so I rebuild my USB with the usb-creator. now it can't find /dev/sr0 after the kernel boots. I assume its wanting to load the squashfs file system.
 * ogasawara back in 20
<rtg> cking, again. what a pain ....
<cking> my usb creator fails on raring too, just to make life so much more enjoyable
<sforshee> rtg, you're installing from a CD then? I haven't tried that.
<sforshee> I'm downloading a 12.04 image right now, so I'll see what happens when I try to boot it this time
<rtg> sforshee, nope, USB stick. I think I'm gonna take cking's suggestion and install on a HD in another system, then transfer it to the SDP
 * cking notes it is a pain
<cking> 5.5 hours for 2 machines - but I did have a dodgy SATA connected
<sforshee> rtg, then what's /dev/sr0 have to do with it? I'm probably exposing my ignorance about the install process here ...
<rtg> isn't that the device that the lice installer wants ? I think the USB gets aliased or something. I don't know for sure eiter
<rtg> live*
<sforshee> could be, I have no idea
<cking> interesting, when I created the USB live image using 12.04 it works, whereas with current raring it was broken. well, at least I can do an UEFI clean install now
<arges> bug 1070182
<ubot2> Launchpad bug 1070182 in linux (Ubuntu) "8086:10f5 Can't connect to the network through a wired connection - Network dialog shows "Wired Cable unplugged"" [Medium,Confirmed] https://launchpad.net/bugs/1070182
<sforshee> cking, I haven't tried raring but so far my 12.04 install is working
<sforshee> I can't use the "try ubuntu" option however
<cking> sforshee, ah, that's the same fail I got earlier.
<koen__> anyone knows what happened with the hifn_795x module (pci crypto accelerator)?
<sforshee> cking, it boots but just drops to a shell
<cking> sforshee, yep, same here
<bjf> ogasawara, i'm feeling pretty good actually .. have you made your alternate plans?
<cking> sforshee, that's why I gave up,  popped the drive in a box that I trusted to work, did the install on that and swapped it back
<apw> koen__, "what happened"
<apw> ?
<sforshee> cking, I'm going through with the 12.04 install so I'll see how it goes
<arges> rtg, http://git.openvz.org/?p=ubuntu-hardy-openvz;a=commit;h=c25a12d6ab08a1a2d79e1a6540c2579780b97d5b
<arges> i think that's it
<rtg> arges, yep
<koen__> apw: the module seems nonexistant; it was there in previous releases.
<ogasawara> bjf: I haven't, what time you want to head in?
<apw> koen__, what are the current and previous in your contenxt
<bjf> ogasawara, i wasn't in a rush, maybe pick you up around 9 ?
<ogasawara> bjf: perfect
<rtg> CRYPTO_DEV_HIFN_795X: depends on !ARCH_DMA_ADDR_T_64BIT
<rtg> apw, koen__: ^^
<rtg> debian.master/config/config.common.ubuntu:CONFIG_ARCH_DMA_ADDR_T_64BIT=y
<koen__> rtg: i run on 32bit
<sforshee> rtg, cking: the 12.04 desktop UEFI install finished fine for me. No desktop but it does boot to a shell. This is on the mobile SDP.
<rtg> koen__, true. seems like it ought to be enabled.
<koen__> rtg: easiest way to compile this in? this is a desktop for the wife that should stay as generic as possible , it's not my toybox...
<rtg> koen__, raring ?
<koen__> rtg: next release? ok, i can live with that? should i file a report for this somewhere?
<rtg> koen__, no, I meant "which release are you currently running ? "
<koen__> quetzal something :) 3.5.0-19-generic
<rtg> koen__, ok, lemme have a look. start a bug and let me know the number
<koen__> rtg: thanks! i use bugs.launchpad.net/ubuntu for this?
<rtg> koen__, just type 'ubuntu-bug linux' from a shell
<koen__> rtg: will do; thank you!
<cking> rtg, I fall into the UEFI shell, then select the drive (usually fs0:) by doing:
<cking> fs0:
<rtg> cking, its the grub booting part tat I'm missing
<cking> the cd into efi
<cking> then cd boot
<cking> and then type: bootx64.efi
<rtg> cking, hmm, what if FS0: isn't showing up  ? All I have are blk* devices
<cking> hrm, maybe it can't see your USB stick for some unknown reason
<rtg> double drat
<sforshee> ogasawara, do I need any X updates for your haswell test kernel? I'm running it with an up-to-date precise install, but X still won't use the intel driver.
<sforshee> ogasawara, I added ubuntu-x-swat/q-lts-backport and updated but get the same results. The kernel driver loads, but X still won't use the intel driver.
<cking> sforshee, I did a 12.04 install and then updated all the packages. I didn't observe any issues
<sforshee> cking, did you verify that X is using the intel driver? I get a desktop, but X is just using the framebuffer.
<sforshee> tjaalton, ^
<tjaalton> sforshee: pastebin dmesg and Xorg.0.log
<tjaalton> hmm
<sforshee> tjaalton, http://paste.ubuntu.com/1400057/
<tjaalton> sforshee: so yeah you probably need updates to -intel at least
<sforshee> http://paste.ubuntu.com/1400059/
<sforshee> tjaalton, beyond what's already in ubuntu-x-swat/q-lts-backport ?
<cking> sforshee, I just checked to see if i915_hsw was loaded and being used
<cking> I didn't do more than that
<tjaalton> sforshee: did you install the stack?
<tjaalton> normal upgrade won't install anything
<sforshee> cking, the kernel module loads and works. X is using inteldrmfb.
<tjaalton> at least you're still using the old xserver, so that would be a no then :)
<sforshee> tjaalton, oh right ...
<sforshee> I just did dist-upgrade
<apw> eep no points
<cking> bum
<vanhoof> de
<cking> sforshee, so does that mean my testing was in vain?!
<sforshee> cking, perhaps your testing on precise
<cking> facepalm
<cking> been one of those days
<cking> so implicit in the testing was the need to use X from a PPA somewhere?
<vanhoof> yeah precise + ubuntu-x-swat/q-lts-backport (dist-upgrade) + kernel
<sforshee> tjaalton, I installed xserver-xorg-lts-quantal, and it now uses the intel driver. Lightdm comes up okay, but trying to log in just generates a blank screen then back to lightdm, with no X log that I can find and nothing in dmesg.
<sforshee> is there something else I need to install?
<cking> http://nooooooooooooooo.com/
<cking> wish that was written in the notes
<vanhoof> sforshee: anything fun in /var/log/lightdm/ ?
<tjaalton> sforshee: dunno, haven't tested that yet
<tjaalton> sforshee: so.. no /var/log/Xorg.0.log.old?
<ogra_> sforshee, ~/.xession-errors ;)
<vanhoof> sforshee: i know Sarvatt pointed me in the right direction on something that sounded familiar but I think that was fixed up in that ppa already
<ogra_> you X obviously is fine, its the session that has issues
<ogra_> (else lightdm wouldnt come up at all)
<ogra_> and there is also /var/log/lightdm/
<sforshee> vanhoof, ogra_: thanks. There's some stuff there, so I'll pastebin it.
<sforshee> tjaalton, .xsession-errors: http://paste.ubuntu.com/1400102/
<vanhoof> Sarvatt: do you know if https://launchpadlibrarian.net/120700234/xorg-server-lts-quantal_2%3A1.13.0-0ubuntu6~precise1~ppa6.4_2%3A1.13.0-0ubuntu6~precise1~ppa6.5.diff.gz made it in the ppa?
<sforshee> tjaalton, /var/log/lightdm/x-0.log: http://paste.ubuntu.com/1400106/
<tjaalton> sforshee: Xorg.0.log.old should have the crash.. ah
<tjaalton> no that's from the running one
<sforshee> tjaalton, /var/log/lightdm/lightdm.log: http://paste.ubuntu.com/1400109/
<sforshee> tjaalton, the only /var/log/Xorg.* I have is Xorg.0.log, which looks to me like it's probably from the lightdm session
<vanhoof> like its going bananas trying to fire up unity2d
<sforshee> everything looks hunky dory in there anyway
<sforshee> hmm ...
<sforshee> oh weird
 * ogra_ would put his money on a bamf issue looking at .xsession-errors
<ogra_> [+280.01s] DEBUG: Failed to load session file /usr/share/xsessions/ubuntu.desktop: No such file or directory
<ogra_> is intresting as well
<sforshee> there don't seem to be any ubuntu sessions at all when I click the little ubuntu icon in lightdm
<vanhoof> sforshee: did you come from server?
<mlankhorst> ..Â¿
<Sarvatt> is ubuntu-desktop installed? :P
<tjaalton> well if the xserver is quitting, whatever the reason, there should be an .old file around..
<sforshee> tjaalton, "ubuntu-desktop : Depends: xorg but it is not going to be installed"
<ogra_> ha !
<mlankhorst> sforshee: did you have the backports ppa installed previously? I had a stale xserver-common there..
<tjaalton> you should have the renamed version which provides xorg
<mlankhorst> and that messed things up
<tjaalton> ah! mlankhorst to the resque :)
<tjaalton> I'll steer clear and write an email to intel, then call it the week :)
 * ppisati -> gym
<sforshee> mlankhorst, do you mean ubuntu-x-swat/q-lts-backport ? I have it installed now ...
<mlankhorst> going to push the entire ddx for a test rebuild, then push it to that repo..
<mlankhorst> sforshee: could try ppa:mlankhorst/ppa 
<mlankhorst> I'm doing a final test build there with updated versions + mechanics
<arges> sforshee, which eth networking driver did you need to copy over to make your kit work?
<sforshee> mlankhorst, I'm explicitly trying to test haswell graphics so I need the backport :) Trying your ppa now.
<sforshee> arges, I didn't copy the driver. I copied over debs for a 3.5 kernel and installed it.
<arges> sforshee, ahh gotcha
<mlankhorst> I hope people will forgive me for swamping the launchpad builders..
<sforshee> mlankhorst, oh yeah I just remembered that I'm supposed to mail you a macbook
 * mlankhorst is going to push the entire stack one more time for a final test rebuild
<mlankhorst> I'll check in on you later, you probably want to do dpkg -r --force all *lts-quantal* and get back to normal precise first..
<sforshee> yeah, I'm trying to work through all of that right now
<hggdh> infinity: Lucid EC2 kernel tests done
<hggdh> infinity: the new armadas did not yet appear on http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html
<infinity> hggdh: Too late, it's Friday.  No releases for you! :)
<hggdh> heh
<infinity> hggdh: Hrm, they've been on http://status.qa.ubuntu.com/reports/kernel-bugs/reports/sru-report.html since I promoted them.
<infinity> Workflow is silly.
<infinity> hggdh: Err, they're on workflow.
<infinity> 3.2.0-1611.16 and 3.5.0-1605.7
<infinity> Your tasks are still "New", but that shouldn't stop you from getting ahead of the game. :)
<hggdh> which I am doing right now :-)
<sforshee> mlankhorst, I managed to get everything to a happy state with your ppa
<mlankhorst> ah good
 * rtg ignores haswell for now and goes back to his touchpad problem
<mlankhorst> sforshee: ok I'm doing 1 more rebuild everything just to spot any potential issues popping up
 * henrix -> EOD
<apw> rtg, ogasawara, bjf, any objections to zinc going down for a RAM upgrade ?
<rtg_> apw, I think that is an outstanding idea. might keep it from swapping all the time.
<apw> they want to do it 'now' if we don't object
<rtg_> I don't image it'll take too long. i'd say just do it.
<rtg_> imagine*
<apw> they say less than an hour, much less if we are lucky
<apw> ack ... will just fetch everything one more time
<apw> and they hand it over
<apw> *** kernel.ubuntu.com is going down for a short maintenance window ... should be less than 1 hour
<ogasawara> apw: wfm
<apw> rtg_, ogasawara, bjf, should be back ...
<rtg_> wow, that didn't take long
<rtg_> apw, 8GB up from 2GB ?
<apw> rtg_, doubled 4 -> 8 apparently
<bjf> wow, what will we do with all that
<apw> wish it was 2x it is i expect
 * rtg_ -> EOD
#ubuntu-kernel 2012-12-01
<Tassadar> Hi, in which package kernel from http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-nexus7.git;a=summary ?
<Tassadar> *in which packages is....
<mlankhorst> I would guess the nexus 7 ppa
<mlankhorst> https://launchpad.net/~ubuntu-nexus7/+archive/ppa
<tuxillo> hi
<tuxillo> I'm experiencing problems with ubuntu 12.10 nfs-client and the dragonflybsd nfs server.
<tuxillo> create, delete and rename operations are not shown up in the client's mount when done from the server
<tuxillo> this problem doesn't occur in ubuntu 11.04
<tyf> does the kernel 3.4 for precise from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-precise/ contains the patch for ureadahead ?
<tyf> seems like i can't find any pack files in the /var/lib/ureadahead when i used this kernel
<tyf> does the kernel 3.4 for precise from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-precise/ contains the patch for ureadahead ?
<Orphis> Hi! I'm having issues with my integrated BT on Ubuntu
<Orphis> I've gone through normal troubleshooting and couldn't make it work properly (it shows in hciconfig but cannot find any device)
<Orphis> After talking with some bluez dev, I've been recommended to use the bluetooth-next branch
<Orphis> Do you know if there is any build from this branch available somewhere that I could use ? 
<Orphis> Also, the integrated bt was working just fine in Archlinux, but never worked on Ubuntu
<Orphis> Any idea what could be the issue then?
<Smx> Hi everyone. I'm experiencing a black screen with latest quantal kernel as well as with latest upstream kernel. I have an MSI R5770 (Radeon HD5000 "Evergreen" Family, GPU codename "Juniper"). I have tryied an old debian 5 dvd, as well as a RipLinux iso from USB (both kernel 2.6) and they boot both fine.
<Smx> Could someone please help me? Thanks in advance
<Smx> The nomodeswet switch doesn't help. The system seems to be running, because if i issue commands (sudo reboot for example) they work
#ubuntu-kernel 2012-12-02
<tyf_> it seems like the kernel 3.4 http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-precise/ doesn't contain patches for the ureadahead. no pack files are generated during boot.
<tyf_> i need to use that kernel, that's the only kernel that won't cause random freezes on the lenovo g580 laptop
<tyf_> any plans to include the patch into that kernel?
<infinity> tyf: Mainline kernels kinda don't have patches by design.  Have you tried the lts-quantal kernel?  (apt-get install linux-generic-lts-quantal)
<yf-geek> hmm, why kernel 3.4 is not in the quantal's repository?
<infinity> tyf: Because quantal uses 3.5
<tyf> does the linux-generic-lts-quantal package contains PAE kernel?
#ubuntu-kernel 2013-11-25
 * apw yawns
 * smb finished his full backup
 * smb grumbles at and into mumble
 * xnox remebers the office manager at the old job. Before going home, she'd do a database backup, burn it on to the CD, take the old CD out of handbag put into archive spindle, and put the new CD into her handbag. Reasoning it with "when this place burns down, at least I will not have to redo all accounting & have accurate stock levels for insurance claim"
<xnox> i thought it was brilliant. For added bonus the dumps were encrypted before burning on to the cd.
<smb> Oh sometimes backups are good even without a fire
 * xnox really should start doing backups.
<smb> Like when md raid had a nasty bug
<xnox> and i don't use raid either yet =) something i plan to start doing on my main desktop this cycle.
<smb> xnox, You still got plenty of other methods to get rid of your data involuntarily. Which you will discover at the most inconvenient time. :-P
<xnox> =))))))))))))))))))) been there, done that.
<ppisati> apw: in case you were going to apply my cpufreq config patch, can you hold on? i'm going to send a v2
<apw> ppisati, ack
 * apw ought to do his archival backups again
<apw> and the one in the firesaf
<apw> firesafe
 * smb should get a firesafe first
 * apw listens out for the telltale spinup of his backup drives
<apw> still there
<smb> Hm, still listening or not broken after?
<ppisati> back in 10
<apw> smb, they are still there ...
<smb> apw, Ah ok, that is a good start then, I suppose
<apw> yeah ... it is ... and and there go the actual archive drives
<apw> xnox, get some backup kit _now_
<ppisati> [    9.738247] systemd-udevd[361]: failed to execute '/lib/udev/socket:/org/xen/xend/udev_event' 'socket:/org/xen/xend/udev_event': No such file or directory
<ppisati> is it good?
<smb> ppisati, not really good though for normal operation not bad
<ppisati> smb: eh
<smb> Just systemd's version of udev not supporting the socket pipe. I should disable the whole thing as its only for the deprecated xend/xm stack and probably only for pci pass-through. Without it working I saw no regression for running normal HVM guests
<henrix> someone should ask this guy to open a bug report: https://lkml.org/lkml/2013/11/24/116
<apw> heh so we can make snide comments?
<xnox>  =/
<ppisati> linux-image-wallpapers...
<apw> lets hope it is a troll
<ppisati> kees: don't know if you saw my comments on friday
<ppisati> kees: anyhow
<ppisati> kees: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1183616
<ubot2> Launchpad bug 1183616 in linux (Ubuntu Precise) "seccomp-bpf missing on ARM in precise" [Medium,Triaged]
<rtg> ppisati, trusty unstable finally has an armhf that compiles. you should give it a whirl on calxeda, etc
<ppisati> rtg: i'll do
<ppisati> rtg: anywhere i can find a precompiled version? or shall i do it by myself?
<rtg> ppisati, no, I've only compiled it locally using the cross toolchain
<ppisati> rtg: ok
<bjf> ppisati, you making any progress with kees on that seccomp bug verification?
<ppisati> bjf: nope, didn't hear back from him since friday
<ppisati> bjf: that's why i updated the bug report
<bjf> ppisati, he has updated the bug since then
<apw> rtg, pushed some bits to unstable to make it compile again on arm64
<ppisati> bjf: ok, i'll do
<rtg> apw, ack
<ppisati> bjf: but i think it's definitely a toolchain+linux-libc-dev issue
<bjf> ppisati, ack
<rtg> apw, shouldn't that top one be a SUACE patch ?
<apw> arse yes for us
<apw> fixed
<rtg> thanks
<apw> even forwarded upstream like a good boy
<ppisati> smb: can i steal m01 for a quick test?
<smb> ppisati, sure
<smb> let me leave
<smb> ppisati, you got it i see
<ppisati> smb: yeah, i tried to see if someone was working on it
<ppisati> smb: i'll delete the test kernel afterward
<ppisati> rtg: both T/unstable armhf -generic and generic-lpae boot on ecx-1000 and ecx-2000
<rtg> ppisati, cool, thanks
<apw> rtg, and whats on unstable now build and boots on the foundation-model arm64
<rtg> apw, it boots on amd64 as well. maybe we should just upload it ?
<rtg> I think I'll give it a try on some other machines first :)
<apw> rtg, to CKT would be ok i think
<rtg> apw, yeah, perhaps later today.
<apw> now we are on a proper -rc
<rtg> actually, we're a bit beyond a proper -rc.
<apw> yeah i noted that too
<rtg> i was kind of waiting on some arm compile fixes that got merged after -rc1
<apw> yeah we normally get -rc2 into the actual archive, so we are on pace for it
<rtg> uploading to ckt would also allow us to get the dkms story in order
<apw> seems like a plan to me
<rtg> bjf, care to install http://kernel.ubuntu.com/~rtg/3.11.0-13/ on some boxen ?
<bjf> rtg, will do
<bjf> rtg, the 3.11 directory with 3.13 kernels in it? :-P
<rtg> bjf, doh! yeah, that one.
<bjf> rtg, boots fine on the 2 mac's i have
<rtg> bjf, I've got it running on my SNB 2 way server. pounding through some compiles right now.
<bjf> rtg, i'll install it on a lab machine or two
<kees> ppisati: yeah, it's something funny with the headers, for sure. I have no idea why those __NR_*s are being eliminated for EABI.
<ppisati> kees: it's either headers or toolchain
<ppisati> kees: which debian release did you use?
<kees> ppisati: I think it's a snap shot of unstable. let me get it running again, one sec...
<kees> man, I hate ARM on KVM. it never works twice :)
<bjf> rtg, boots on a lab system. it's a romley system 
<rtg> bjf, I'm about to upload it to ckt, but without (gasp!) a release tracking number.
<bjf> rtg, is there a reason for no tracker ?
<rtg> well, I think we'll just use this one for dkms testing. I'm not really ready to dump this in the archive. maybe by -rc3 ?
<bjf> rtg, ack
<kees> ppisati: gcc (Debian 4.6.3-11) 4.6.3
<ppisati> gcc -dM -E $anyfile.c | grep EABI
<ppisati> kees: ^
<ppisati> kees: should be 1
<kees> #define __ARM_EABI__ 1
<kees> #define __NR_time 1062
<ppisati> kees: grep __NR_time /usr/include/arm-linux-gnueabihf/asm/unistd.h
<kees> in /usr/include/asm-generic/unistd.h
<ppisati> kees: well, the problem is that later one there's 
<ppisati> #if defined(__ARM_EABI__) && !defined(__KERNEL__)
<ppisati> #undef __NR_time
<ppisati> ...
<kees> kees@debian:~$ grep __NR_time /usr/include/arm-linux-gnueabihf/asm/unistd.h
<kees> grep: /usr/include/arm-linux-gnueabihf/asm/unistd.h: No such file or directory
<kees> $ grep __NR_time /usr/include/arm-linux-gnueabi/asm/unistd.h
<kees> #define __NR_time                       (__NR_SYSCALL_BASE+ 13)
<kees> oddly, I have the undef too
<ppisati> kees: kees is there an #undef somewhere?
<kees> #if defined(__ARM_EABI__) && !defined(__KERNEL__)
<kees> #undef __NR_time
<kees> builds for me, though.
<ppisati> kees: then it shouldn't compile there neither
<ppisati> uhm
<kees> and yet it does :(
 * kees looks
 * kees re-checks out the tree
<kees> oh delightful. what did I have in this tree? now it's broken.
<kees> give me a moment...
<kees> ppisati: okay, can you try pulling from kees/seccomp instead of redpig/seccomp for the tree? It seems I had a stack of fixes from redpig that aren't yet in his repository :(
<ppisati> kees: complete url?
<kees> ppisati: https://github.com/kees/seccomp.git
<ppisati> kees: still FTBFS
<ppisati> kees: hold on
<lfaraone> Can anybody on the kernel team help me push through the SRU of openafs 1.6.5.1-1ubuntu0.12.04.1 which fixes LP bug 1206387 ?  this was brought up in http://mid.gmane.org/alpine.DEB.2.00.1311201505010.18512@dr-wily.mit.edu 
<ubot2> Launchpad bug 1206387 in openafs (Ubuntu Precise) "openafs-modules-dkms 1.6.1-1+ubuntu0.2: module FTBFS on 3.8.0" [High,Confirmed] https://launchpad.net/bugs/1206387
<lfaraone> apw suggested bringing these requests to the kernel team; not sure if it'd be preferred to do so on IRC or elsewhere.
<kees> ppisati: bleh, what's it show?
<kees> the only change I have locally after that commit is to comment out linux/seccomp.h but your headers probably include that.
<ppisati> kees: http://paste.ubuntu.com/6475418/
<ppisati> kees: i commented out your definitions
<ppisati> kees: but now it fails buidling resumption
<kees> ah! yeah. don't worry about anything besides seccomp_bpf_tests.c
<ppisati> kees: ah k
<ppisati> kees: http://paste.ubuntu.com/6475444/
<kees> ppisati: yay! :)
<apw> lfaraone, thanks for the heads up.  it's late here, but i'll see what i can do to help that make its way tomorrow
<kees> ppisati: thanks for helping get this verified. sorry about the hiccup!
<ppisati> kees: any time
<ppisati> bjf: bug 1183616
<ubot2> Launchpad bug 1183616 in linux (Ubuntu Precise) "seccomp-bpf missing on ARM in precise" [Medium,Triaged] https://launchpad.net/bugs/1183616
<ppisati> bjf: verified (if verification-done-precise is the correct tag)
<bjf> ppisati, many thanks
<stgraber> jsalisbury: ping
<stgraber> jsalisbury: http://kernel.ubuntu.com/~jsalisbury/lp1249719/ looks pretty empty to me :)
<Kano> hi, why is there no orig file for 3.12?
<sforshee> rtg: I just added a comment to #1253155. tl;dr, the modules on the generic inclusion list seem to be lacking signatures.
<sforshee> bug #1253155 that is
<ubot2> Launchpad bug 1253155 in linux (Ubuntu) "Failure to validate module signature at boot time" [High,Confirmed] https://launchpad.net/bugs/1253155
<rtg> sforshee, huh
<sforshee> rtg: I just started digging through the build stuff. Possibly they're getting stripped differently?
<rtg> sforshee, I can't remember, I'll have to look. Feel free to dig into it though :)
<rtg> sforshee, so, that would be all modules in the -extra package, right ?
<Kano> rtg: why dont you use .orig for 3.12?
<sforshee> rtg: the ones in -extra are okay. The ones packaged with the kernel aren't signed.
<rtg> Kano, because we are gonna release on 3.13
<Kano> and? you can use .orig for 3.12 as well
<rtg> sforshee, really. all modules are installed to the same place, and then separated into linux-imae or linux-image-extra. I don't think there is any stripping going on.
<rtg> Kano, its devel kernel. its not getting mirrored, so I don't care about orig tarballs.
<sforshee> rtg: something must be happening, because every time I pick a module from the inclusion list I find it isn't signed
<rtg> sforshee, well, there is a depmod call. I wonder if that is doing it.
<sforshee> that would be unexpected
<rtg> sforshee, to say the last...
<rtg> least*
<rtg> debian/scripts/module-inclusion just moves things around
<sforshee> rtg: yeah, I looked at that one and can't find anything fishy
<rtg> sforshee, a quick hack would be to tar up the inclusion list directory before calling depmod, then restore.
<infinity> rtg: The devel kernel gets mirrored...
<infinity> Most mirrors mirror the whole archive.
<rtg> infinity, hrmph
<hallyn_> rtg: hi - there are some netns patches from a month or two ago which havn'et hit trusty yet (i.e. 0bbf87d852d243680ed7074110ccc1dea003b61a).  is that just awaiting a 3.12 merge?
<rtg> hallyn_, do we care about 3.12 ? we're gonna go with 3.13 (which I've uploaded to ckt today.)
<hallyn_> rtg: egads, i see, it went in after 3.12 :(
<hallyn_> ok
<rtg> hallyn_, you can test by getting a trusty kernel from https://launchpad.net/~canonical-kernel-team/+archive/ppa
<hallyn_> rtg: so the patches relate to /proc/sys/net/ipv4/ip_local_port_range in network namespaces.  In our 3.2 precise kernel,
<hallyn_> you can access /proc/sys/net/ipv4/ip_local_port_range frmo a container, and set it, but it's the global values.  so we may want to (which I assume would fall onto me?) backport part or all of that fix
<hallyn_> rtg: will test that thanks
<rtg> hallyn_, yeah, you know the most about backporting (and what)
<infinity> zequence: Are you going to smoketest all your proposed kernels at some point?
 * rtg -> EOD
<hallyn_> yup, https://launchpad.net/~canonical-kernel-team/+archive/ppa fixed it
#ubuntu-kernel 2013-11-26
 * apw yawns
 * smb notes the world is brighter outside today
<smb> Must be that white stuff that suddenly appeared
<apw> heh .. we may have a sunny day here for the first time in at least a month
<smb> We had some of that too until today, which is dry but cold. Soon it is supposed to get warmer again and wet...
 * apw wills the grass to grow
<zequence> infinity: Hi. Will do right away. Been away for a couple of days
<TooLmaN> Hi guys.  I'm building my first Core system.  What 12.04 kernel file should I grab from packages.ubuntu.com/precise/kernel/?  The test unit only has 1GB RAM so I'm guessing 'linux-generic'?  Thanks
<TooLmaN> The kernel file is only a 1.7KB .DEB.  Is that correct?
<TooLmaN> seems way too small
<TooLmaN> ok found a 35MB file that seems the right size.  linux-image-3.2.0-56-generic-pae_i386
<apw> TooLmaN, linux-generic is the meta package not eh kernel itself
<TooLmaN> apw: well that would make sense  lol
<TooLmaN> following https://wiki.ubuntu.com/Core/InstallationExample.  It just says to grab a kernel from packages.ubuntu.com.  Pretty vague to me
<apw> TooLmaN, yeah it makes sense when you know what you are writing, but not to a new person, it is a wiki so if you have better words do change it, or add an example or something
<TooLmaN> apw: I'll get it working before I try to change the wiki.  Thanks for the info.
<apw> TooLmaN, sure, just do fix it if it is confusing, as the next one will glad of it
<TooLmaN> apw, will do.  Trying to revive some older Wyse terminals as minimal Ubu boxes.
 * ppisati disappears for a bit
<sforshee> rtg: I've been messing with this module signing thing some more, and when I build the package the modules are all signed
<rtg> sforshee, thats what I found. I'm just downloading from the archive to check those packages
<sforshee> rtg: I'm pretty sure I did that yesterday and found that they really aren't signed
<rtg> sforshee, well, what extra step does the buildd perform ? I wonder if an sbuilder could reproduce this ?
<apw> sforshee, what not working with signing for you ?
<apw> rtg, ^^
<sforshee> apw: all the modules that come from the kernel package (i.e. not in -extras) are lacking signatures
<apw> if you build it locally?
<sforshee> no, they're there if I build locally
<rtg> apw, and I just confirmed that.
<rtg> how odd
<rtg> apw, is that signed bullshit ?
<rtg> is this*
<sforshee> huh, actually if I download the package and unpack it the signatures are there
<apw> which files are you checking if not hte ones in the package ?
<rtg> sforshee, I'm not finding _any_ signatures in linux-image-3.12.0-4-generic_3.12.0-4.10_amd64.deb
<rtg> dpkg -x linux-image-3.12.0-4-generic_3.12.0-4.10_amd64.deb tmp;find . -name "*.ko"|while read f;do if ! egrep -q "Module signature appended" $f;then echo $f;fi;done
<sforshee> rtg: you're right, I checked the wrong file
<rtg> apw, so, I'll bet this has something to do with the way the signed kernel is built, huh ?
<apw> rtg, i think we have no problem :)
<rtg> apw, explain ?
<infinity> Are you stripping one package differently from the other?
<infinity> Can't see how it would relate to the signed kernel, since that happens in an entirely different package, and is just vmlinux.
<rtg> infinity, well, it doesn't happen with a local build. linux-image from the archive has no signatures. therefore, it seems that it must be something that happens on the builder (like the signing process).
<infinity> The module signing process, perhaps, but not the kernel signing process.
<infinity> It has to be something that happens during the linux build, not any other package.
<infinity> And if it can't be reproduced locally, your local setup might not be as close to a proper package build as you think.
 * infinity grabs the source to test.
<rtg> infinity, all modules are signed the same way regardless of the package they ultimately end up in.
<infinity> rtg: Yes, and then some are being "unsigned".  But that can only be happening during the package build, as we don't touch the packages once the buildd has given us a hash of all the debs it just created. :P
<rtg> infinity, don't you have to touch linux-image in order to sign vmlinuz ?
<infinity> rtg: No, vmlinuz isn't signed in linux-image.
<infinity> rtg: Only in linux-signed-image.  Which pulls a copy of vmlinuz to sign it.  But certainly doesn't do ANYTHING to the original package.
<infinity> (Not that we could even if we wanted to)
<apw> right (sorry had a contractor here)
<apw> module and kernle signing is separate
<apw> you are saying some modules are unsigned, which ones
<rtg> apw, yep, I see that signing _is_ separate
<rtg> apw, so, even on ckt this is happening. linux-image modules are unsigned, whereas linux-image-extra _are_ signed.
<apw> rtg, and yet in the main archive not ?  (i assume it must be the same in the main as well)
<apw> which version are you checking
<rtg> apw, yes, it is the same in the main archive as well
<apw> that seems unexpected as we make the extra package by making the main package as normal
<rtg> apw, I've been looking at trusty in ckt (but I don't think version really matters)
<apw> and hten moving the modules from the install to a new package
<infinity> Version matters, as this is a recently-introduced bug.
<rtg> infinity, actually, its been going on for awhile
<infinity> How far back?
<rtg> at least saucy for sure
<infinity> What's the LP bug again?
<apw> so give me a module which is in main so i can check on my saucy box
<rtg> apw, lib/modules/3.13.0-0-generic/kernel/sound/pci/snd-ens1370.ko
<infinity> apw: dpkg -L linux-image-$(uname -r) | grep modules
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<apw> rtg, and how are we confirming they are unsigned
<sforshee> apw: I'm looking for the string "Module signature appended" at the end
<rtg> apw, find /lib/modules/`uname -r` -name "*.ko"|while read f;do if ! egrep -q "Module signature appended" $f;then echo $f;fi;done
<rtg> apw, make sure you installed from the archive and not some local crack
<sforshee> apw: I've got a saucy install here which seems to have the same results as with trusty
<infinity> So, yeah, definitely unsigned in image and signed in image-extra here on 3.11.0-13-generic
<infinity> Weeeeird.
<infinity> Would be nice to figure out when this started being true.
<apw> so that makes some sense, as extra is the 'left overs' from a proper install
<apw> i can only assume we are stripping them as we move them over
<apw> though i thought we used mv
<rtg> apw, we're not as far as I can tell
<rtg> I mean, we _are_ using mv
<apw> yeah, we are  ... so it is some post processing on linux-image which differs
<apw> the package processing is the same too ?
<rtg> skipdbg ?
<apw> skipbdg ?
<apw> we do run depmod on the ones in the main package
<apw> and not on the ones in the other
<rtg> apw, depmod isn't supposed to update anything.
<apw> right i assume it is not but i was looking for differnces
<apw> for 'skipdbg' we are makgin a separate version
<apw> a separate install out of the kernel tree
<rtg> apw, yeah, we're also doing an objcopy.
<apw> yeah just saw that and yep i bet that is breaking it
<apw> who got us to add that, kamal maybe
<infinity> So, extra is definitely built in a "special" way.  I imagine linux-image is getting stripped, and extra not.
<rtg> lemme build with skipdbg=false
<apw> infinity, no i think this is the objlink thing
<kamal> apw, we're talking about what now?
<rtg> infinity, I think its a post processing step that only happens on the buildds 'cause skipdbg keeps us from locally building a _giant_ debug file
<rtg> kamal, we're pretty sure its your fault
<kamal> rtg, well obviously, but it doesn't ring a bell to me
<kamal> (not that that means much)
<rtg> actually, this may go back a long ways. perhaps feisty.
<kamal> soooo before my time
<rtg> yeah, we're just yanking your chain.
<kamal> yup
<apw> rtg, so if the key has not been wacked when we package you might be able to do this again:
<apw> Makefile:mod_sign_cmd = perl $(srctree)/scripts/sign-file $(CONFIG_MODULE_SIG_HASH) $(MODSECKEY) $(MODPUBKEY)
<rtg> apw, yep, just looking at that file
<apw> if we can resign them then it might be easier
<apw> rather than changing the the main kernel makefiles
<apw> and if it is there we should once we are finished make sure it is wacked
<rtg> apw, yep, that is my thinking
<apw> rtg, great
<rtg> apw, starting a V=1 build with skipdbg=false. it'll take a bit, but I should have sufficient log to figure out the key business.
<apw> yeah sometimes it is just work letting gomeisa take the strain
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 10 minutes
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues December 3rd, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<lfaraone> apw: re 1206387 , the package currently in the queue restores OpenAFS functionality on 3.11 , so we're current through linux-lts-saucy, but that SRU does not contain the fix for trusty's config  (bug 1246675) 
<ubot2> Launchpad bug 1246675 in openafs (Ubuntu) "OpenAFS fails to build on trusty kernel 3.12 [openafs-modules-dkms 1.6.5.1-1: openafs kernel module failed to build]" [High,Fix released] https://launchpad.net/bugs/1246675
<lfaraone> bug 1206387
<ubot2> Launchpad bug 1206387 in openafs (Ubuntu Precise) "openafs-modules-dkms 1.6.1-1+ubuntu0.2: module FTBFS on 3.8.0" [High,Confirmed] https://launchpad.net/bugs/1206387
<lfaraone> apw: Ideally I'd like the current package accepted and we'll just update for trusty's kernel once it gets closer to release. 
<apw> lfaraone, yeah that is an appropriate approach as we won't have 3.12 for very long
<lfaraone> the only reason I bothered to introduce a delta this early in the cycle for openafs is because I'm running trusty on my laptop, and (some of) my email is in AFS maildirs. :P
<apw> heh :)
<apw> lfaraone, am i correct in thinking that we have released all of the versions you have penidng
<apw> lfaraone, that reminds me, if you want to get a preview of the 3.13 kernel we have early (-rc1 ish) kernles in our PPA: https://launchpad.net/~canonical-kernel-team/+archive/ppa/+packages
<lfaraone> apw: no, 1.6.5.1-1ubuntu0.12.04.1 is still waiting to get accepted to precise-proposed 
<apw> lfaraone, /me wonders why queue isn't showing it to him
<lfaraone> sory 1.6.5.1-1~ubuntu0.12.04.1
<apw> ahh there it is, finger fail on my side.  thanks
<lfaraone> I messed up the first upload's version number, so I requested that it be rejected.
<apw> ahh thats what it is
<apw> lfaraone, i assume you are tyring to commonise the version here with that in trusty ?
<lfaraone> apw:  1.6.5.1-1~ubuntu0.12.04.1 is a backport of  1.6.5.1-1 , which is in Saucy.
<apw> lfaraone, is it a backport of 1.6.5.1-1ubuntu1 ?
<lfaraone> apw: No. 
<apw> so i think the number might be a litle odd, i am unsure that the ~ would be neeed, as ubuntu0 is before ubuntu1 but, as long as it is 'before' i assume it is ok
<lfaraone> apw: right, I uploaded the SRU before I uploaded the new verison in trusty.
<apw> but i assume your version isn't newer than 1.6.5.1-1 which is what your currnet number implies, but ... not sure its a problem
<lfaraone> apw: the SRU is the same code as 1.6.5.1-1, but if you upgrade your system should install the 1.6.5.1-1 package replacing the backported version. So, we need to make the SRU less than the version in the development release. 
<lfaraone> 1.6.5.1-1~ubuntu0.12.04.1 is less than 1.6.5.1-1 , the latter of which was previously in trusty. Its also less than 1.6.5.1-1ubuntu1, so upgrades will still work. 
<apw> ahh i see, got you
<apw> lfaraone, there is a heap of change between what is applied in trusty (1.6.5.1-1 not th ubuntuN versions) and what was backported, in debian/rules which i thought i might have seen an upload to undo, but cannot find now
<lfaraone> apw: the debian/rules changes were in Anders' original debdiff as changes needed to build on precise, I believe. 
<apw> hmmm, ok
<lfaraone> apw: in any case, it just moves logic from override_dh_install-arch to override_dh_install
<lfaraone> and removes override_dh_install-arch. Perhaps the disntinction between override_dh_install-arch and override_dh_install-indep didn't exist in precise's debhelper?
<apw> yeah that is believeable
<lfaraone> https://lists.debian.org/debian-devel/2011/12/msg00092.html implies the options were new in Debian in late 2011, so I imagine they may not have made it to precise before DIF / FF
<apw> yeah thanks
<infinity> Could relate to this:
<infinity> debhelper (9.20120608) unstable; urgency=low
<infinity>   * dh: When there's an -indep override target without -arch, or vice versa,
<infinity>     avoid acting on packages covered by the override target when running
<infinity>     the command for packages not covered by it. Closes: #676462
<infinity>  -- Joey Hess <joeyh@debian.org>  Fri, 08 Jun 2012 13:15:48 -0400
<apw> nnng what language is that written in
<infinity> apw: I think it's saying that if you have "foo-indep", "foo" would run for those same packages again, unless you also have a "foo-arch".
<infinity> (In which case, "foo" wouldn't happen at all, just the two overrides)
<infinity> So, the fix could be to simply add an override_dh_install-indep that calls dh_install -i
<infinity> But I haven't looked at the diff, as long as it's sane, I don't care.
<apw> switches to the omre normal overrides
<apw> lfaraone, i asusme this has been tested with at least the P and S kernels as it seems to carry a bump for everything
<apw> lfaraone, i wonder when we went to 3.5 we just plled in the updates for the kernel componet, not the test of it, why are we not doing the same for this one?
<lfaraone> apw: the cherrypick needed would be really bit, ref https://bugs.launchpad.net/ubuntu/+source/openafs/+bug/1206387/comments/2
<ubot2> Launchpad bug 1206387 in openafs (Ubuntu Precise) "openafs-modules-dkms 1.6.1-1+ubuntu0.2: module FTBFS on 3.8.0" [High,Confirmed]
<lfaraone> *big
<lfaraone> apw: this has been in the OpenAFS PPA for a month, and I believe is in use by everyone at MIT running the HWE kernels. I had installed the packages on my system running non-HWE and they worked for me. 
<lfaraone> I believe CMU is also running 1.6.5.1 on Precise via the PPA.
<apw> if my memory of hte main users of afs that might well be pretty much all of them ...
<apw> lfaraone, and i guess we get more change for 3.12 and likely again for 3.13
<infinity> The more important question isn't "does this work on 3.8", but "does it break on 3.2"?
<apw> i think we do need to know it has been tested in all the valid combinations P P+Q P+R P+S
<lfaraone> apw: is P+Q supported, still? 
<apw> lfaraone, not for much longer i suspect indeed
<apw> i do so wish the HWE backports were in per series PPAs and not in the archive
<infinity> All of them are supported until after 14.04 comes out.
<lfaraone> apw: yeahâ¦ me too. 
<infinity> But it seems unlikely that you'd craft a kernel module that works on 3.2 and 3.8 but not 3.5...
<apw> infinity, yeah that
<lfaraone> Anyway, I can install ALL the kernels in a VM and double check.
<apw> lfaraone, that would be great
<stgraber> rtg: ping
<rtg> stgraber, on the phone
<stgraber> rtg: ok. When you're back, can you let me know what package your verification-done-precise applies to in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1205284?
<ubot2> Launchpad bug 1205284 in linux (Ubuntu Precise) "linux-tools naming is not scalable to multiple source packages" [Medium,Fix committed]
<stgraber> rtg: if that's apt, then I'll release it to -updates. The rest will go through the standard kernel SRU process.
<rtg> stgraber, bug apw about that
<apw> stgraber, hi ... which package are you considering the bug for sru wise
<stgraber> apw: apt
<stgraber> apw: the sru report says apt has been in -proposed for long enough and if rtg's verification-done-precise tag applies to it, then I can release it, but due to the high number of sources linked to that bug and lack of comment, I can't know whether the tag was meant for apt or for some of those linux sources...
<bjf> stgraber, i believe rtg was responding to the previous comment from my bug spamming asking for testing/verification
<bjf> stgraber, that would make it (the rtg tag) applicable to the linux package
<apw> i don't expect rtg's does apply there... infinity your apt update for that linux-tools bug was about getting the apt "mark as autoinstalled" stuff right for toosl right ?
<apw> infinity, if so i can veryify that ...
<apw> stgraber, and yeah these tags are uttrely usless on these bugs, can we get them fixed somehow to include the package where there is more than one/
<apw> ?
<rtg> yeah, my change to the tag would have been for linux, not apt
<apw> stgraber, i believe i understnad that apt change and can verify it
<stgraber> apw: I guess we could extend the syntax to be verification-done[-<source name>][-<series name>] which should work for those cases (at least so long as we don't have source package names that match series name ;))
<stgraber> apw: that'd be great!
<stgraber> bdmurray: ^
<bjf> stgraber, does anyone other that the kernel team use those verification tags?
<stgraber> bjf: sure, all SRUs do
<bjf> huh
<bjf> i don't remember using that as an example but I must have
<stgraber> and that usually ends up being a bit of a mess when multiple sources are concerned as we need to differentiate which have been tested and which haven't :)
<infinity> apw, stgraber: I can verify that apt change DTRT... When you have tools installed with the new naming scheme.
<infinity> (Which is only lts-saucy at this point, isn't it?... I don't recall now)
<stgraber> infinity: the bug report lists linux-lts-saucy and linux as affected for precise
<infinity> stgraber: Well, it's not fixed in the current precise-proposed...
<infinity> Looks like the bug ref in the changelog was just about updating the wrappers, not about the packaging.
<infinity> apw: ^
<apw> infinity, linux is affected as it carries the new wrappers for all releases, but does not get switched to that form
<apw> stgraber, ^
<infinity> apw: Did we intent to switch the package names for linux/precise too, or just leave it be?
<infinity> s/intent/intend/
<apw> only linux-lts-saucy is using the new form indeed, so the apt changes only affect there
<apw> i was not intending on changing the older releases unless somone whined no
 * infinity nods.
 * rtg -> lunch
<apw> infinity, so are you or am i, verifying this apt thingy
<apw> infinity, i have a vm availble to do it
<infinity> apw: Go nuts, if you're all set up to verify.
<rtg> ogasawara, re: bug #1255297 - were you gonna send a patch to the list ? Its been at least 15 minutes.
<ubot2> Launchpad bug 1255297 in linux (Ubuntu Saucy) "XPS 15 SD Card Reader Support" [Medium,In progress] https://launchpad.net/bugs/1255297
<ogasawara> rtg: sheesh, I'm about to hit send
<rtg> :)
<bjf> ogasawara, it looks like the next SRU cycles kernels will be the one for 12.04.4
<ogasawara> bjf: ack, I figured it would be
<ogasawara> bjf: can we make sure that patch for 1255297 lands in it
<bjf> ogasawara, i'm thinking this next cycle is going to be kinda long given holidays and release prep
<bjf> ogasawara, as long as it doesn't cause any regressions i don't see why it won't make it
<ogasawara> bjf: ack
<ogasawara> bjf: and ack on making this next cycle a little longer
<bjf> ogasawara, but just for you i can make sure that commit gets in :-)
<ogasawara> bjf: heh, thanks :)
<apw> stgraber, ok i've confired the apt changes (added same to the bug) and vairous other bits
<stgraber> apw: cool, thanks. I'll release the apt SRU then.
<apw> stgraber, wonderful thanks
<apw> rtg, that sign fix turned out nice and simple, and the where of its occurance says why i have never seen it, as i nearly always am running your latest shiney kernel hand compiled
<rtg> apw, yep, though I'm still struggling to get a trusty upload to build so that I can be absolutely sure.
<rtg> FTBS: make[2]: Leaving directory `/build/buildd/linux-3.12.0/debian/build/tools-perarch/tools/lib/traceevent'
<rtg>     LINK perf
<rtg> /usr/bin/ld: cannot find -liberty
<rtg> apw, I think 'UBUNTU: [Config] switch build-depends to libiberty-dev' fixes the FTBS (buils testing as we speak)
<rtg> build*
<apw> ahh i didn't realise he was wacking it from the old place ...
<rtg> yeah, its gone
<apw> that was rather quick :)
<apw> i figured we had as long as it took to get 3.13 in, seems i was wrong
 * rtg -> EOD
#ubuntu-kernel 2013-11-27
<octocpp> So, why should I still trust SElinux since it is made by the NSA?
 * apw yawns
<lfaraone> apw: I have validated that the new openafs-client is able to get tokens and access files on 3.2, 3.5, 3.8, 3.11 as shipped in Precise
<apw> great
<lfaraone> marked as such on the bug
<lfaraone> apw: anything else you need? 
<apw> lfaraone, i think i am as happy as i can be, though the final decision is not mine, but i think you have done your bits
<lfaraone> looking at https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule , by Dec 12 the kernel for the final point release of 12.04.4 will be finalised, and it will be released on Jan 23? 
<apw> lfaraone, yes true
<infinity> lfaraone: I don't suppose there's any chance we could try to make it ready for 3.13 too, so we don't have to do this dance all over again?
<lfaraone> infinity: I don't think anybody has looked at 3.13 yet; ideally I'd like to get out a fix for current users sooner rather than later.
<infinity> lfaraone: Fair enough.
<apw> infinity, i'd also say that the changes for 3.12 (which there is no ponit in releaseing) are more the normal "little patch" on the top jobs
<lfaraone> apw: anyway, https://launchpad.net/~canonical-kernel-team/+archive/ppa says "It IS NOT RECOMMENDED that you subscribe to this PPA.". I assume the kernels there won't cause my disk to explode, or something. Would you recommend running it in a VM anyway, or is on my laptop fine? (just for testing)
<apw> lfaraone, yeah we make no guarentee about installability from there, you can easily get uninstalled from there if yuo arn't vigilent when it says what it is going to do
<apw> but there is a 3.13 in there which you could test against, of course we are only at -rc1 so there is still time for more change to come, though there should not be any
<cking> -rc1 is working quite well for me at the mo
<apw> cking, yeah this is more about there ought not being but maybe being more interface changes inside before 3.13 final
<cking> yep, i guess to expect the usual :-)
<bjf> sbeattie, when you get some time could you take a glance at http://kernel.ubuntu.com/testing/test-results/fozzie__3.12.0-4.10__2013-11-27_15-53-00/ubuntu_qrt_apparmor/results/ubuntu_qrt_apparmor.test-apparmor.py/debug/ubuntu_qrt_apparmor.test-apparmor.py.DEBUG.html
<bjf> sbeattie, it's an apparmor test run on Trusty. i updated the tests so it should be the latest.
<tyhicks> bjf: hi - according to the line number for the assertion, an old version of test-apparmor.py is being ran
<tyhicks> bjf: those two failures are fixed by QRT revno 2029
<tyhicks> sbeattie: ^ (in case you're looking at this already)
<reghat> hello. I have a question if someone could answer it. What is the best way to dump a kernel modules memory or I can only dump the entire kernel memory ?
<bjf> tyhicks, according to my bzr.log i'm at revno: 2057
<bjf> tyhicks, i'm still investigating
<bjf> tyhicks, my test-apparmor.py is revno: 2031
<bjf> tyhicks, still looking
<bjf> tyhicks, just ignore me ... sorry for the noise (i looked at the wrong test results)
<brendand> is integration of the RTL8723AS-VAU driver on the horizon?
#ubuntu-kernel 2013-11-28
 * apw yawns
<apw> ppisati, yo ... do we ahve any arm builds out of the master branch on precise ?
<ppisati> apw: omap4?
<ppisati> apw: and highbank iirc
<apw> oosi we di
<apw> ppisati, so we do ... 
<ppisati> apw: ok, just omap4 for us
<ppisati> apw: highbank&c are hwe kernels
<apw> ppisati, so when this next batch of precise kernels come round we will have some scarey cves in it so we will need to do some proper testing to make sure they boot
<ppisati> apw: ok, just ping when you need tests and i'll take care
<ppisati> *ping me
<apw> ppisati, thanks
<apw> henrix, are you trying to give me a heart attack with these cve patches! :)
<henrix> apw: heh the ARM assembly one? :)
<ppisati> what could go wrong after all? :)
<ppisati> and with that said
 * ppisati goes for some supplies
<henrix> yeah, it is scary... but it seems to be doing something trivial: renaming a macro
<apw> henrix, yeah that one, the second one aint so trivial, but the bug is nasty nasty
<apw> and i think it will either work or not boot being as those are used for everything
<henrix> apw: well, i can't boot test it (but i build tested). anyway, feel free to NACK it and i'll try to get it the 2nd commit backported instead
<apw> henrix, na, i think it is the right thing as it is definatly the same then.  i think i want to say for both "please lets add omre testing for the relevant architecuters to the list"
<henrix> apw: sure, thanks
#ubuntu-kernel 2013-11-29
 * apw yawns
<apw> henrix, moin ... it is going to be a quiet day today
<henrix> apw: morning! yeah, i guess most of the people are off today :)
<apw> you, paolo and myself i think
<Kano> hi,could somebody update the ndiswrapper package with new upstream to support current kernels?
<ogra_> Kano, you might have to ask in #ubuntu-motu ... bug 1076395 looks like it is gone since a while 
<ubot2> Launchpad bug 1076395 in linux (Ubuntu Raring) "ndiswrapper module is not provided any more" [Low,Fix released] https://launchpad.net/bugs/1076395
<janimo> ppisati, hi, do you know which is the latest nexus4 ubuntu kernel tree?
<ppisati> janimo: i bet this one:
<ppisati> janimo: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-saucy.git;a=shortlog;h=refs/heads/mako
<ogra_> thats saucy though
<ppisati> ogra_: i doubt we have a different kernel in T
<ogra_> yeah, there was no upload 
<ppisati> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-trusty.git;a=shortlog;h=refs/heads/mako
<ogra_> (but i assume the branch was moved to trusty when the cycle started)
<ppisati> indeed
<ogra_> yeah :)
<ppisati> same exact one
<janimo> ppisati, thanks. I was confused by the presence of a separate and outdated linux-nexus4 repo
<ogra_> janimo, that was for the desktop image 
<ogra_> oh, no, that was linux-nexus7 actually :P
<apw> yeah we need to wack those old repos and shove them over to archive sometime
 * ppisati goes out for some food
<brendand> if no network controller shows up in lspci, what could be the problem? this is a ideapad yoga 13
<brendand> which i thought was supposed to have a realtek card, but nothing is showing up
<brendand> rfkill shows an ideapad_wlan so there must be something there
<apw> nothing in lspci at all for it?  that is unusual, has this worked ever ?
<brendand> apw, do you think i should boot windows 8 and see if it enables the card?
<brendand> apw, i just got this system now
<apw> i was wondering if it has worked in other releases
<brendand> apw, been trying saucy-live
<brendand> apw, i also tried precise
<apw> ok so likely 'never' worked
<brendand> apw, yeah. like i said above it's *supposed* to have a realtek card
<apw> it would be good to boot something which does recognise it if you can to find out wha tthe heck it actually is, what pci ids it has
<apw> as normally we see things in pci even if we don't know what they are
<brendand> apw, yeah
<apw> though i would conjecture it is the other side of a host bridge that we do not configure right
<apw> so we don't see it, but ... thats unexpected in anything new
<brendand> apw, i'll boot windows 8 and find out the pci-id
<apw> great, and then a buggy for it (if there is a device there)
<apw> brendand, oh one thing, what state is the rfkill in
<apw> as sometimes when devices are rfkill'd by switch they are 'turned off completely' so they don't appear
<brendand> apw, it's not blocked
<brendand> apw, i see ideapad_wlan and soft block and hard block are both 'no'
<apw> ok not that then, though i would try flippnig it in case it is a lie and say inverted
<brendand> apw, good idea!
<Coder27> Hello. I've notices that the system run on a single CPU core after hibernation. Both cores work normally after regular boot. Please help/
<Coder27> There are two messages about the problem in the syslog file: Nov 29 16:56:56 nbook kernel: [ 4140.670554] CPU1: Not responding. Nov 29 16:56:56 nbook kernel: [ 4140.670731] Error taking CPU1 up: -5
<Coder27> The kernel is: 3.2.0-56-generic #86-Ubuntu SMP Wed Oct 23 17:31:43 UTC 2013 i686 athlon i386 GNU/Linux
<Coder27> The hardware is Lenovo IdeaPad S205 (AMD E-350 APU)
<Coder27> Please help me to repot this bug
<brendand> apw, well windows 8 says it's the same realtek card i suspected. still trying to locate the pci id :P
<brendand> (it's been soooooooooooo long since i use windows)
<brendand> not the same pci id though
<brendand> 0bda:1724 seems to be it
<brendand> it's in lsusb :) that's it
<brendand> apw, is that lspci id handled in linux-firmware?
<brendand> apw, i just read that the rtl8723au driver makes it work. isn't that in linux-firmware now?
<apw> brendand, doh of course ... usb ... a common connectivity for wlan these days
<apw> that rings a bell, but that normally menas it is pretty new
<apw> brendand, i dont see the au variant being mentioned in the main driver list as yet
<apw> brendand, though the rtl8192*u drivers seem to mention that model number so hard to say
<apw> what does dmesg say when you click it off and on again in rfkill, that normally disconnects the usb device and reinerts it
<apw> and indeed what does lsusb -nnvv say for that device
<brendand> apw, nothing much happens in dmesg. not sure what i should be looking for in lsusb
<apw> pastebin the whole lsusb -nnvv output, and remind me of the ids you foudn in windows
<brendand> apw, i'll need to get some kind of connectivity first. this is an ultrabook so no ethernet
<apw> brendand, yeah they suck, i have a usb ethernet dongle lying about in my office for this issue
<brendand> apw, https://lkml.org/lkml/2013/4/1/280 seems to be saying that the rtl8723au driver won't be included any time soon
<apw> brendand, yeah, though at least there is progress
<lfaraone> sigh. the openafs backport was rejected, as vorlon would prefer we just backport the module with the old userland, etc. 
<lfaraone> I'm sceptical that is any safer, as nobody has validated the userland tools, PAM module, etc when mixing versions of the project.
<lfaraone> slangasek, rather.
<apw> lfaraone, well i guess that that at least is something we can do automatically, as in just copy that part out of one package into the other
<lfaraone> apw: ah, okay. uh, do you have the rights to request a copy? 
<lfaraone> I didn't think you could copy a binary package between dists easily. 
<apw> lfaraone, ahh no i just meant we can just copy the source component for the kernel parts from the saucy package into the source package you have for P
<hallyn> apw: hey - can you confirm whether my email from serge@hallyn.com (2 of em) this morning it the kernel-team list?
<stgraber> hallyn: I didn't see any mail from you to kernel-team@lists.u.c, maybe stuck in moderation somehow?
<hallyn> grr
<hallyn> ok, thanks
<hallyn> stgraber: now? :)
<stgraber> hallyn: yep, I see two e-mails from you now
<hallyn> thanks
<hallyn> wish i'd thought to check on those in the morning
<apw> hallyn, yes they were in the moderation queue, pushed
<hallyn> apw: sorry.  (i resent from other address)
<apw> oh heh, never mind
#ubuntu-kernel 2014-11-24
<Kano> hi, when will there be 3.18 rc6 in vivid?
<Kano> its rebased but not tagged
<sajan> I was wondering if someone can tell me when the following iwlwifi patch would be pulled in and available in the Ubuntu kernel.  I installed 3.17.1 on a Utopic system and doesn't seem to be there. - http://bit.ly/15f4WIn.  Would it be there in the next 3.17.x build?  If so, when does that happen?  Thanks.
<sforshee> sajan: I'm not sure when that will make it to vivid. It should be in the utopic kernel that was just released, but it won't make it into trusty for several more weeks.
<sajan> sforshee: Thanks.
<infinity> sforshee: If it's in utopic, it's in vivid.
<infinity> Well, vivid-proposed.
<binBASH> Hi tinoco, I saw you assigned yourself https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1318551
<ubot5> Launchpad bug 1318551 in linux (Ubuntu) "Kernel Panic - not syncing: An NMI occurred, please see the Integrated Management Log for details." [High,Confirmed]
<binBASH> If you need more info you can write me :-)
<tinoco> binBASH: hey
<tinoco> i did..  cause i just got a UA bug around this
<tinoco> recommended customer to (workaround) deactivate max cstates 
<tinoco> asked him to update their firmware (using some HP already reported cases)
<tinoco> and im investigating little further now
<tinoco> i got a crash on the idle task :D
<binBASH> The workaround I use is noautogroup kernel boot parameter
<tinoco> binBASH: iÂ´ve seen the bisect. you made it ?
<binBASH> Nope, because I dunno where I should start
<binBASH> I'm not kernel specialist, sorry
<tinoco> binBASH: did it work with you ?
<tinoco> have u tried de-activating c-states ?
<binBASH> Could try it
<tinoco> could you ? and report it back on the public bug ?
<binBASH> If bios allows it. I have the issue on my desktop...
<tinoco> try appending this to kernel cmdline (/etc/default/grub) "intel_idle.max_cstate=0 processor.max_cstate=0"  
<tinoco> and/or disabling it by BIOS
<tinoco> binBASH: what server are u using ?
<tinoco> is it a proliant ? or just your workstation ?
<binBASH> Well, I have it on multiple systems
<tinoco> :\ hum
<binBASH> But the desktop here is Gigabyte board...
<binBASH> Cheap Desktop HW :)
<tinoco> yep. but it might be related to samething
<tinoco> good for us if you can test these and report it on the public bug
<tinoco> its always good to get feedback from other platforms 
<binBASH> I will try it in the next 5 mins :)
<binBASH> Just let me finish eating up my dinner please
<tinoco> great :D . did noautogroup solve the thing for you ?
<binBASH> yup
<binBASH> it did. No issue with it
<tinoco> hum.. it might be related to the way idle_task handles cpu instructions
<tinoco> iÂ´ll check code and see what is modified by using this
<tinoco> binBASH: really appreciate 
<tinoco> let me know any feedback you might have regarding this
<binBASH> When I don't use the param it crash during boot in 99%
<tinoco> binBASH: yep.. iÂ´ve been informed people are getting this randomly with proliant servers
<tinoco> i received a kernel dump with the idle task causing the panic
<tinoco> and found the public bug.. looks like it fits on my case
<binBASH> yeah, it can happen also after boot process randomely. It crashs so bad even Magic-Sysreq doesn't work then
<tinoco> yep.. lets see if c-states being disabled handles the issue
<tinoco> if they do.. iÂ´ll look deeper why
<binBASH> ok, sec. I'll add the params you gave to cmd line
<tinoco> take your time ;) lol
<binBASH> Ok, will reboot now, brb
<binBASH> ok tinoco, I've tested boot now several times, the params don't fix it
<tinoco> binBASH: what about disabling C-states under BIOS ?
<tinoco> do you have that option ?
<binBASH> I can test it as well np
<tinoco> binBASH: please, tks
<binBASH> tinoco: The mainboard I'm using btw. is Gigabyte H77-D3H with Intel i7-3770K cpu
<tinoco> im getting errors with this: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz      
<tinoco> but iÂ´ve seen cases where upgrading bios/firmware solved similar issues for proliant
<binBASH> Do you have EFI system?
<binBASH> Because I'm using EFI boot
<tinoco> binBASH: have u tried upgrading your firmwar e?
<binBASH> Nope
<tinoco> i wonder if we are having the same problem here
<tinoco> cause people informed about not using c-states to fix
<tinoco> and you fixed by changing way scheduler behaves
<tinoco> is it possible for you to generate a crash
<binBASH> I will try to disable C-states in bios
<tinoco> and upload it to the case ?
<tinoco> yep, please
<binBASH> reboot brb... :)
<tinoco> ;)
<binBASH> tinoco: nope, didn't fix it
<tinoco> yep.. i think we might be facing different things
<tinoco> anyway, could you generate a kernel dump
<tinoco> and attach to the public case ?
<tinoco> i can further analyse if is the same case, if they are related or not
<tinoco> binBASH: but i would suggest you a bios update before
<tinoco> just in case
<tinoco> and tks for the tries, anyway :)
<binBASH> np
<binBASH> Will try to find out how to do it :)
<tinoco> binBASH: https://wiki.ubuntu.com/Kernel/CrashdumpRecipe
<binBASH> Yeah, currently reading it, thx
#ubuntu-kernel 2014-11-25
<TJ-> I am modifying the build system to build for MCYRIXIII (no PAE, CMOV, or CX8) which is technically a real i486 build, a variation of the i386 (really i686) arch. Would it make sense to make it a flavour of i386 or create a new arch, as in ./debian.master/config/i486/ ?
<apw> TJ-, its a variation of i386 i assume, so it'd want to use that kernel arch
<apw> TJ-, though will userspace even work on that, given it is also at liberty to assume CMOV etc
<TJ-> apw: The issue I was wondering about is that the i386 flavours all have the 64 bit support flags enabled
<TJ-> apw: So either I'd need an explicit over-ride from =Y to =N or an entirely different arch
<apw> TJ-, the arch there i386 matches the debian arch you are trying to target, not the kernel arch per-se
<apw> TJ-, yes you will make a heap of mess in the config split, but, whatever, thats not your problem
<TJ-> apw: Userspace will be fine; Currently I'm using a Debian install but this is for low power pseudo-embedded devices doing simple network monitoring tasks and I'd like to keep the entire estate on the same ubuntu server release
<TJ-> apw: I thought it did (match the packaging arch) which is why I asked before wasting time :)
<apw> TJ-, i am not sure because debian works, that ubuntu uspace would work with it, unless you are saying you have rammed a debian kernel into our userspace and it did work
<apw> which would be a sensible test
<apw> as we do not necessarily compiler our libraries including libc with the same lower limits
<apw> h/w support wise
<TJ-> apw: Pure Debian for the original test, now using network boot with rpld -> iPXE -> cobbler -> Ubuntu Server i386 with custom kernel alternatives being tested.
<TJ-> apw: Once I can get an Ubuntu kernel to boot, I'll sort out userspace if needed :)
<TJ-> apw: So my challenge is to modify debian.master/config/i386/ to override some of the .common. configs that expect 64-bit (PAE) support
<TJ-> apw: Maybe I should go back in the history to see how the PAE/non-PAE split was done in 12.04 
<apw> TJ-, well first add your own flavour, and say copy config.flavour.generic into it, then start adding the "differences" you want
<apw> to that same file, and running update configs until you have a config which works
<apw> running debian/rules updateconfigs
<apw> TJ-, if the release you are basing on has -lowlatency that shows the places you need to be concious off when making a -i486 or whatever you call it
<TJ-> apw: The adding isn't an issue ... it's the taking-away that I'm wondering about - can't just have commented entries in the new flavour, got to over-ride the incompatible flags. I'll play about with it now I know to stick with the i386 arch - thanks alot :)
<TJ-> apw: Yeah, got/using low-latency (working off 14.04)
<apw> TJ-, "# CONFIG_FOO is not set" is not (contrary to its appearance) a comment, it is the written equivalent of "CONFIG_FOO=n"
<apw> and will override an =y/m to off
<apw> TJ-, additionally as you do this i _strongly_ recommend you keep a copy of the "total overrides" you have added to that file
<TJ-> apw: really? I always thought it was ignored by the build system?
<TJ-> apw: Yeah - it's all committed in git :)
<apw> as when we change the config under you, you can "cat config.flavour.generic my-overrides >config.flavour.i486; debian/rules updateconfigs" to reapply your delta
<apw> TJ-, really yes, the latest entry is taken for any value and that includes the "is not set" specifiers
<apw> thats why you find them in the config fragments at all
<TJ-> apw: aha, that helps! I did read earlier how to use the build scripts to generate the flavour ./.config but can't find it now - is it a simple debian/rules <some-target-name>  or more involved ?
<apw> to find out what the raw configs look like, debian/rules genconfigs and look in CONFIGS/*
<TJ-> apw: Thanks :) the various wiki pages aren't entirely clear on this aspect
<apw> TJ-, to be honest we don't want it to be too easy, as you really want to be knowledgable before you even think about taking on maintenance of a kernel derivative
<apw> TJ-, if you end up doing this as a derivative kernel, there is some support for "derived configs" in the linux-lowlatency kernel which was separate in a couple of releeases, where the rebase act fixes the configs for you in the majority case.
<apw> it is essentially doing what i proposed here, given an accumulated "these must be these values i care not about anything else" being applied relative to generic
<TJ-> apw: I've been doing custom kernel builds/maintenance for 10 years or so, but it's a while since I worked with the Ubuntu build scripts and things have changed a lot there
<apw> kind of thing.  which worked pretty well with things like you are changing, fundamental values which never change
<apw> TJ-, we rarely stay still for long, where is the fun in that
<TJ-> Re-inventing the wheel gets boring :)
<apw> yep derivative kernels are a pain to maintain for sure
<thms_> TCP timestamps enabled on a default Ubuntu server, is a "MEDIUM RISK" according to vulnerability scanners like OpenVAS, because it provides critical info to hackers about the system. But the timestamps provide a lot of very useful features as well, so my question is - Is it possible to enable randomized TCP timestamps in some way? Or should I disable completely? Or ignore the warnings?
<apw> thms_, not sure i know off the top of my head ... jjohansen ^ ?
<jjohansen> thms_, apw: I am not aware of away to do that, personally I would put the TCP timestaps issue as low risk, it allows getting the system uptime and boot time, and disabling it will slow down your tcp connections
<thms_> apw there seem to be a lot of suggestions to simply turn them off - but since it enabled by default in almost all distributions, including firewall distros, there has to be a better way...
<jjohansen> as long as you are keeping your system up to date, you should be okay.  If you aren't rebooting into new security kernels or live patching it becomes more of a problem
<apw> thms_, from what i can see in a very cursory look, is that they are either on or not on
<thms_> right...
<jjohansen> that agrees with what I know
<thms_> I'v found that Sophos, a Linux based firewall distro has timestamps on by default, but it seems to randomize the numbers in some way...
<thms_> Thanks anyways :-)
<jjohansen> thms_: grsecurity is carrying a patch to do that
<apw> jjohansen, and that tells me to stop looking to see if it is possible :)
 * thms_ goes looking at grsecurity
<apw> jjohansen, got a pointer to that patch, purely academic interest, i wonder if it is complex
<jjohansen> and it looks like openbsd
<thms_> I think the 'bsd's all have some implementation of this
<jjohansen> apw: nope grsecurity is one big ugly flat patch, I just found an email referencing it
<apw> oh those people
<jjohansen> actually I'm not sure if they have it, that mail was that have a working proof of concept
<apw> yeah i see the same, though if that description is right, it may be a simple thing to set tsoffset or something to != 0
<thms_> I won't pretend to fully understand every aspect of the timestamping stuff, but the proposed patch here, looks very simple: https://grsecurity.net/~spender/random_timestamp.diff - although, to my knowledge, the "randomness" should probably be set per connection
<thms_> but something like this would probably be a good start - and not causing new problems either (the per connection randomization might be a little more tricky to get right?)
<cking> amitk, how's idlestat progression?  any hints when version 0.4 will land?
<cking> s/progression/progressing/
<apw> thms_, it is not clear you couldn't just load that random number into tsoffset instead of =0, but then i am no expert
<apw> thms_, making it per connection instead ...
<smb> jibel, Did you already change the proxy settings for the dkms test host. Asking because I still see them all failing while they should succeed (and picking a random log still showed the fw download as the issue)
<thms_> apw, oh, there's a tsoffset for the connection initialization code?
<smb> jibel, that is dahdi dkms package
 * thms_ shamefully admits to not having done his homework :-|
<apw> thms_, if i am reading things right, each socket has its own offset, i have no idea what is really used for, but it is thrown into the mix when making the timestamp
<apw> thms_, so it is possible one could use that in some way, perhaps
<apw> thms_, the good thing about a single offset such as in the grc version is that is is more spec friendly for the various optimisations
<jibel> smb, no, I didn't have time to do it yet. I'll let you know once it's done.
<thms_> apw, right; simply generating a random number instead...
<smb> jibel, Ah ok. Yeah, thanks.
<thms_> apw, my thought exactly - although per session seems like the "proper" solution to this
<apw> thms_, just not sure what effect that has, given it is there for something else, for "repair", but ... who knows what that is ... checkpoint restore perhaps
<thms_> right..
<apw> if it is for CPR then, it would be a good candidate
<thms_> CPR?
<apw> check-point-restore
<thms_> Never heard of it but seems handy :-)
<apw> yeah some processes can be potted and reloaded on another system, one of the things they can in theory carry over
<apw> is network connections, and the timestamps would need to be those in use on the original system
<apw> and that would fit well with it being a sockopt which is the only thing which can change it
<apw> as you would make the socket, and fix it, before giving it back to the process image you are loading
<thms_> exactly... sounds cool... what's it used for? loadbalancing processes or debugging?
<smb> live migration of containers
<thms_> of course... nice
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
<amitk>  /quit
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues December 2nd, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!  If the question is should I file a bug for something, likely you can assume yes.
#ubuntu-kernel 2014-11-26
<erle-> are the kernels from kernel-ppa/mainline patched or vanilla?
<kSudo89> If a mainline kernel doesn't contain the bug present in a stable current, should I still bisect the kernel?
<kSudo89> I'm just going to abandon 3.16 kernel. 
#ubuntu-kernel 2014-11-27
<apw> erle- (N,BFTL), they are vanilla almost completely
<apw> henrix, will you likley pick up smb's patches for v3.16 stable or should i review them for application to utopic direct
<henrix> apw: i haven't look yet but i guess i'll pick them for stable
<henrix> apw: actually, i believe one of the commits was already tagged for stable
<henrix> apw: i'll have a look at them this afternoon
<apw> henrix, ahh yes so it is, and the other foundational, ok good.
<apw> henrix, i've reviewed them best i can anyhow, whether they come in via stable or direct makes no odds
<henrix> apw: ack, thanks.  i'll review them as well in a bit (and ACK them)
<apw> jibel, yo ... seems we still have a slew of failures on 3.2.0-73-generic dkms tests, do we have any idea if this is testbed or kernel yet ?
<jibel> apw, hey, no sorry, I'm swamped in phone testing and didn't have time to look at it more than yesterday. I'll try to capture the output of the console.
<apw> henrix, have we had any complaints booting 3.2.0-73-generic kernels at all in VMs ?  we see a lot of the DKMS testing fail during boot, but that might not be anything to do with the kernel
<henrix> apw: not that i'm aware, no
<apw> henrix, me either thanks
<henrix> apw: usually joe ping us when this sort of regressions occur.  and he didn't :)
<apw> heheh yeah i was thinking the same
<dsmythies> In kernel 3.18RC1 this kernel config perameter is: # CONFIG_SCSI_MQ_DEFAULT is not set
<dsmythies> In kernel 3.18RC2 and beyond, the kernel config permeter is: CONFIG_SCSI_MQ_DEFAULT=y
<dsmythies> Resulting in loss of the ability to set the IO scheduler via /sys/block/sda/queue/scheduler
<dsmythies> From the add a CONFIG_SCSI_MQ_DEFAULT option commit message:
<dsmythies> > Add a Kconfig option to enable the blk-mq path for SCSI by default
<dsmythies> > to ease testing and deployment in setups that know they benefit
<dsmythies> > from blk-mq.
<dsmythies> How do we know that all systems benifit from blk-mq?
<dsmythies> It seems complicated to have to re-compile the kernel to get the other IO scheduler options back.
<dsmythies> By the way, my system does seem to benifit from blk-mq, I just didn't understand why I couldn't observe and change the IO scheduler anymore, and so isolated the change.
<apw> dsmythies, hmmm
<apw> dsmythies, could you file a bug against linux for me with details of that, as though it affects no kernels in the wild, it will soon
<apw> dsmythies, and shove the bug # in here
<dsmythies> apw: O.K., but give me some time to do so.
<apw> dsmythies, great, as soon as i have that i can write up my findings and get it changed
<dsmythies> I cann't seem to set "linux" anymore. I think I have in the past. Anyway, bug 1397061 against "Ubuntu"
<ubot5> bug 1397061 in Ubuntu "Kernel Config setting: CONFIG_SCSI_MQ_DEFAULT" [Undecided,New] https://launchpad.net/bugs/1397061
<apw> dsmythies, ack i'll sort it out
<dsmythies> apw: what is the kernel command line option to enable blk-mq?
<apw> dsmythies, something like scsi.use_blk_mq=yes/no
<apw> dsmythies, and it may well switchable at runtime
<apw> /sys/module/scsi_mod/parameters/use_blk_mq
<apw> scsi_mod.use_blk_mq=yes/no perhaps
<dsmythies> apw: thanks
<infinity> zequence: https://bugs.launchpad.net/ubuntu/+source/linux-lowlatency/+bug/1396193 is all you.
<ubot5> Launchpad bug 1396193 in Kernel SRU Workflow "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress]
#ubuntu-kernel 2014-11-28
<apw> jibel, on that precise -proposed DKMS random failures.  I restarted all the failed ones, and they all completed sucessfully.  as we had lost about 50% of them before that, i call those 10 all working indicative of a transient testbed level failure
<apw> henrix, and i think we can stop worrying about that release for this at least
<jibel> these false positives are still really annoying and I'd like to figure out if it's the fault of qemu or the host
<apw> jibel, yeah tehy are, at least i have the power and knewledge to poke them in the short term
<apw> jibel, i don't see the lts U view as yet on public, i assume there is and RT for that somewhere?
<apw> jibel, also i see we have an extra (?) view on public: Trusty Release Kernel-Team-PPA -generic
<zequence> infinity: Thanks
<jibel> apw, RT sent. 
<jibel> I CCed you
<apw> jibel, ack thanks
<apw> jibel, nice optimisation :)  "sync"
<diwic> cking, hi, can I poke your PCI-enabled brain for a second or two? :-)
#ubuntu-kernel 2014-11-30
<Free99> hey all, trying to compile a kernel using make localmodconfig, I can't seem to get the system to boot my LUKS encrypted root volume
<Free99> any points?
<Free99> *pointers
<apw> Free99 (N,BFTL), it would be helpeful to get the error as you see it when it fails
<apw> Free99 (N,BFTL), though commonly it is a lack of config for the root device, or for initramfs itself
#ubuntu-kernel 2015-11-23
<dholbach> hiya
<dholbach> can somebody please respond to https://code.launchpad.net/~hui.wang/ubuntu/vivid/linux-firmware/linux-firmware-vivid-proposed/+merge/277954?
<apw> dholbach, hrm, bzr merges?  sforshee one for your eyes me thinks
<dholbach> apw, I just picked it up from the sponsoring queue
<apw> dholbach, thanks for the heads up
<dholbach> anytime
<sforshee> dholbach: I've already merged the changes from that linux-firmware merge req into our git. I just disapproved the request since we don't use bzr for linux-firmware.
<dholbach> great, thanks
<henrix> sbeattie: re. bug #1518509 -- is it possible that you actually don't have the linux-image-extra package installed?
<ubot5> bug 1518509 in linux (Ubuntu Trusty) "No network, usb keyboard, usb mouse" [Undecided,Confirmed] https://launchpad.net/bugs/1518509
<henrix> sbeattie: sorry, ping'ed the wrong guy ;)
<sbeattie> henrix: no worries.
#ubuntu-kernel 2015-11-24
<gQuigs> so following https://wiki.ubuntu.com/Kernel/Dev/KernelBugFixing but there is no debian/control or changelog file, where do those come from?
<gQuigs> thanks for the response over the w/e :)
<gQuigs> (specifically it fails on test building the patch - or can't edit the changelog because one doesn't exist)
<apw> gQuigs, if that is a git checkout then those files are missing until you clean, the real changelog is in debian.<branch>/changelog, likely master in the normal case
<apw> fakeroot debian/rules clean
<gQuigs> apw: awesome thanks!
<gQuigs> hmm.. for some reason I didn't have kernel-wedge installed which seems important
<apw> gQuigs, yep, you (in theory) need all the build-deps installed to clean it, though in fact for the kernel, kernel-wedge is the only one
<gQuigs> ah, I use doing apt-get build-dep linux-generic.. which is just a meta package.. oops
<jderose> any chance 4.2.0-19 will be released today? :)
<crshman> Hey Guys, looks like the intel nightly's stopped building again. Could someone look into this? http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/current/
<gQuigs> crshman: seems like the same issue as the daily lnet/lustre driver
<gQuigs> hmm.. I see that was talked about here: http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.4-rc2-Spun-For-Ubuntu
<crshman> got it, thanks gQuigs 
<gQuigs> from http://ubuntuforums.org/showthread.php?t=2303120 I found this fix -https://lkml.org/lkml/2015/11/6/987
#ubuntu-kernel 2015-11-25
<apw> crshman, right, they are raw builds, which arn't building, because upstream has yet to apply the fix, sigh
 * xnox doesn't like our kernels
 * xnox goes to fix
<apw> xnox, ?
<xnox> apw, is there a brand new way to checkout ubuntu linux trees? do i need to use launchpad, or can i use kernel.ubuntu.com?
 * xnox did not have the memo
<xnox> apw, just packaging and user-space bits, nothing drastic.
<apw> they are all in the original kernel.ubuntu.com place, though some of the newer ones are master in LP, and they are all available there too
<xnox> apw, oh, and i've built the s390x kernel package... it didn't build me the kernel image / udebs. used 4.2.0-19.23
<apw> xnox, how did you build it
<xnox> apw, dpkg-buildpackage -b
<xnox> it gave me source, doc, headers, tools-common, cloud-tools-common, and linux-libc-dev and that's it =(
<apw> which branch of what repo ?
<xnox> pull-lp-source linux =)
<xnox> hence looking for repositories now ;-)
<xnox> http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/ is out of date, so i need launchpad i guess.
<apw> yep, then you will only get linux-libc-dev, that is a stage1 only build in the archive
<apw> you need the ubuntu-xenial master-next to get anything mroe
<xnox> https://code.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial -> looks fresh
<xnox> ack
<apw> xnox, yes that is the official master for xenial
<xnox> and i don't like the droppage of libunwind8-dev =)
<apw> heh whyso ?
<xnox> we should totally use elfutils which has unwind support on s390x
<xnox> and like switch to it from libunwind throughout, because hipsters =)
<apw> if you have the energy :)  and being you you have a lot of that
<xnox> well, my hands are tied, as llvm is building....
<xnox> and there is one more llvm to build.
 * xnox should have done a shallow clone =( 
<apw> xnox, or a --reference linux-linus clone
<xnox> that would have worked, if i were a kernel developer =)
<apw> all serious developers have linux clone :)
<apw> plus kernel.org's pipe is really fat
<apw> xnox, you will need to touch some abi-ignore files into s390x as there are no s390x builds yet, chicken-egg-chicken
<apw> xnox, echo 1 >debian.master/abi/4.3.0-0.7/ignore; echo 1 >debian.master/abi/4.3.0-0.7/ignore.modules
<apw> else it will barf on you
<apw> ass not that
<apw> xnox, mkdir debian.master/abi/4.3.0-0.7/s390x; echo 1 >debian.master/abi/4.3.0-0.7/s390x/ignore; echo 1 >debian.master/abi/4.3.0-0.7/s390x/ignore.modules
<apw> xnox, that
<xnox> apw, you have access to a devirt ppa to test build things on all arches, right?
<apw> xnox, yes
<xnox> apw, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1519820
<ubot5> Ubuntu bug 1519820 in linux (Ubuntu) "xenial linux master-next FTBFS on s390x" [Undecided,New]
<apw> xnox, you can turn that off in debian.master/rules.d/s390x.mk   do_zfs=false sort of thing
<xnox> apw, tah, let me test that.
 * xnox will submit patches with all changes in the end.
<apw> xnox, the build i did for infinity was against the 4.2 base, so i am not supprised you are seeing issues
<apw> xnox, though it has been test built (other than zfs because that won't cross compile)
<apw> xnox, and thanks
<xnox> apw, in linux-image-extra there are:
<xnox> -rw-r--r-- root/root     24590 2015-11-25 14:26 ./lib/modules/4.3.0-0-generic/kernel/drivers/s390/block/dasd_fba_mod.ko
<xnox> -rw-r--r-- root/root    178446 2015-11-25 14:26 ./lib/modules/4.3.0-0-generic/kernel/drivers/s390/block/dasd_eckd_mod.ko
<xnox> -rw-r--r-- root/root    190646 2015-11-25 14:26 ./lib/modules/4.3.0-0-generic/kernel/drivers/s390/block/dasd_mod.ko
<xnox> -rw-r--r-- root/root     21502 2015-11-25 14:26 ./lib/modules/4.3.0-0-generic/kernel/drivers/s390/block/dasd_diag_mod.ko
<xnox> ..
<xnox> i think these are ought to move to linux-image, rather than stay in extra.
<apw> that looks like it should be in linux-image as that is likley the disks :)
<apw> xnox, concur
<xnox> and i also want dasd-modules and dasd-modules-extra udebs
<xnox> like in debian.
<xnox> in debian they put:
<xnox> -rw-r--r-- root/root    163968 2015-11-10 20:42 ./lib/modules/4.2.0-1-s390x/kernel/drivers/s390/block/dasd_mod.ko
<xnox> -rw-r--r-- root/root     24896 2015-11-10 20:42 ./lib/modules/4.2.0-1-s390x/kernel/drivers/s390/block/dasd_fba_mod.ko
<xnox> -rw-r--r-- root/root    179880 2015-11-10 20:42 ./lib/modules/4.2.0-1-s390x/kernel/drivers/s390/block/dasd_eckd_mod.ko
<xnox> into dasd-modules udeb,
<xnox> and the dasd_diag_mod.ko into dasd-modules-extra udeb.
<xnox> not sure if that's worth the split or not.
<xnox> apw, do you want a bug report for that, or shall I try to implement this udeb bit?
<apw> i am happy to do it, but a bug would be nice
<apw> the bit where an arch deviates from the norm is a bit messy to say the least
<apw> xnox, for the instant i'd suggest adding them to the scsi-modules list and making that Provide: dasd-modules
<apw> and then i can fix it properly slower
<xnox> apw, cool. i kind of pre-emptively uploaded d-i that expects to find dasd-modules =)
<xnox> due to monkey-see debian, monkey-do the same
<xnox> apw, "patch" for disable of zfs -> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1519820/comments/2
<ubot5> Ubuntu bug 1519820 in linux (Ubuntu) "xenial linux master-next FTBFS on s390x" [Undecided,Confirmed]
<xnox> submitted trivial bug fix to upstream to fix spl, but not sure if want to carry that without zfs.
<xnox> linked to from https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1519814
<ubot5> Ubuntu bug 1519814 in linux (Ubuntu) "xenial, linux-master FTBFS on s390x" [Undecided,Incomplete]
<apw> if that makes it build, we should likely get it tested by someone
<apw> i am testing a fix for the udebs now, if you get my bug filed :)
<xnox> apw, well that patch makes the "spl" bits build, but zfs bails out.
<xnox> apw, yes sir.
<apw> xnox, i guess we'll turn it off, and file a bug for someone to turn it back on once we get a machine we can boot
<xnox> apw, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1519833
<ubot5> Ubuntu bug 1519833 in linux (Ubuntu) "xenial master-next needs a different udeb split for x390x" [Undecided,New]
<xnox> apw, let me file a bug with s390x tag. As it will most likely be me again.
 * xnox will check priority on zfs work too.
<xnox> ok, so this is looking lovely. If you give me a patch for udebs to have dasd modules, i should be in a position to spin up a test d-i build.
<apw> xnox, building it again now, looking like it will work ... 
<xnox> \o/ =_
<xnox> \o/ =)
<apw> xnox, i'll push fixes for all of the above to the tree shortly
<xnox> cool.
 * xnox goes to make an egg soup, whilst attempting to poach an egg.
<apw> whoops
<apw> xnox, ok ... i've pushed a quartet of changes to the tip of master-next for your issues
<xnox> tah
 * xnox will finish figuring out how to unbreak xorg-gtk3-mir loop and will get back to that
<xnox> apw, yo. very good it builds in sbuild without a hitch. Some typos though:
<xnox> apw, s/dasd-modules-extra/dasd-extra-modules/ possibly my mistake, sorry about miss-leading you.
<apw> bah
<xnox> apw, and `dasd_mod.ko` ended up in both dasd-modules and the extra variant, that's a conflict.
<apw> no that is normal
<xnox> dasd-extra-modules should have just the dasd_diag_mod, and like depend on dasd-modules i guess.
<xnox> oh, is it?
<apw> hmmm, it may go away if it depends, i'll try that
<apw> it is normal for all of the deps to end up in a module, but it may cope with interdeps
<xnox> yeah it has:  Depends: kernel-image-4.3.0-0-generic-di, storage-core-modules-4.3.0-0-generic-di
<xnox> but needs the dasd-modules dependency too
<apw> the extra is so small i think it might make sense to be merged
<xnox> me too
<xnox> kill the extra, and just stick it all into dasd-modules.
<xnox> and i'm fine to keep this "divergence" from debian.
<apw> i'll confirm the dep helps or not, if not, then i recon i will just wack it
<xnox> cool.
<xnox> it does build natively in a clean sbuild without any problems now. Thanks a lot =)
 * xnox compiles mir
<apw> if i add a Provides: you would be covered anyhow i think
<apw> xnox, ok ... i've forced master-next with the updated udeb names, getting the Depend: right has cleared out the duplicate
<xnox> \o/
<xnox> i will rebuild it again, after getting some chocolate.
<apw> i've also fixed builds for !s390x too :)
#ubuntu-kernel 2015-11-26
<apw> xnox, did that updated branch work ok for you ?
<xnox> apw, i didn't build it yet, been busy with java.
<apw> xnox, np
<xnox> apw, jolly good! =) Status: successful
<xnox> and splits all look correct
<apw> xnox, nice thanks for testing
<xnox> no problem.
<xnox> apw, when is the next upload scheduled for into xenial? is it on a cadance?
<apw> xnox, xenial is free flowing ... we are waiting on some dkms packages gettting fixed right now before we can shift to the 4.3 kernel
<apw> xnox, various 4.2 kernels may appear before then depending how long it takes
<apw> though that said it was pretty close when i last looked, i have just asked for some testing to be redone (adt side) which should let me have a current feel
<xnox> apw, if launchpad gets lit up on monday, i'd want to build images on tuesday, thus i will need /a/ kernel upload by then =) 
<xnox> but it is a big if, if launchpad gets lit up on monday, cause turkey slaughter fest and all that.
<apw> xnox, ok well that pushes us to release it with warts, but that is probabally ok, i'll know today i hope whether the main blockers are cleared up
<apw> xnox, is it turkey day in the US again already ?
<xnox> cool.
<xnox> apw, yeah, i think it is thanksgiving, cause i'm getting spam about pointless black friday sales for tomorrow
<xnox> there is 25% off on champagne at tescos, nothing else good so far.
<apw> heh, 25% off champers is good, i like champers
<xnox> book online delivery or pickup before sunday midnight. it's also discount on wines. but the range is not that great that they have.
<davmor2> xnox: if it is corked instead of screw cap it's top notch ;)
<xnox> davmor2, well, it has to be /cork/ as well, rather than plastic cork ;-)
 * xnox shows his colours
<davmor2> xnox: no, no, that is posh wine not top notch, top notch is corked, and cheap is screw top :D
<davmor2> posh wine == decent
<davmor2> xnox: technically unless you blow 100 years of dust off the bottle it's hopeless, but then you would never open that you just show it off and earn a fortune off it as it gets older :)
<apw> davmor2, best not to open anything that old as it will likely be undrinkable
#ubuntu-kernel 2015-11-27
<hallyn_> apw: hey - has there been any effort to push the overlayfs delta upstream?  Was there resistance?
<apw> hallyn_, not really had a chance to sit down and do that ... i should
<hallyn_> apw: ok.  was just reminded of it while testing upstream kernel and lots of lxc tests break :)
<hallyn_> on the brigh side, cgrou pnamespaces seems to be working pretty well
#ubuntu-kernel 2015-11-28
<michyprima> hello guys
<michyprima> I'm still experiencing bug #1456985 on 15.10 with 4.2.0-18. ext4 fs goes readonly sometimes when server backups. Before filing a new bug, I would love to know if it's me doing something wrong or not :)
<ubot5> bug 1445195 in linux (Ubuntu Wily) "duplicate for #1456985 [Hyper-V] Kernel patches for storvsc" [High,Fix released] https://launchpad.net/bugs/1445195
<apw> michyprima, if it sounds like the same thing and you have the same (or similar symptoms) it is worth filing a new bug and referencing the old in the description as being the same
<michyprima> apw: thing is on #1445195 they claim it was fixed for all supported ubuntu distributions, but you are right, simptoms are exactly the same. What I can read from the bug page is that the fix was merged into the linux 3.x tree, so maybe it isn't available yet in 4.x?
<michyprima> looks like I was wrong, the correct issue is bug #1470250 which is in progress. my bad for misreading :)
<ubot5> bug 1470250 in linux (Ubuntu Wily) "[Hyper-V] Ubuntu 14.04.2 LTS Generation 2 SCSI Errors on VSS Based Backups" [High,In progress] https://launchpad.net/bugs/1470250
<apw> michyprima, there appear to be at least precise test kernels in that bug, if you have an environment you can test
<michyprima> I will, thanks. I need to get a test vm first for obvious reasons :P
<michyprima> just double checking, I just need to install debs which will install udebs by themselves?
<apw> michyprima, udebs are only used by the d-i installer during install time, you only need the .debs to update
<michyprima> both virtual and generic hangs on loading ramdisk
<michyprima> that doesn't look good
<michyprima> I will try installing 3.2.0-23  instead
<michyprima> still hangs. mhh, something is definitely wrong
<goddard> anyone know why a USB device config descriptor would have 38 hex items in an array ... all the documentation I read lists only 8
<goddard> ?
#ubuntu-kernel 2016-11-28
<bjf> jpd, moin
<jpd> hi
<jpd> bjf: 
<cking> jpd, welcome!
<jpd> cking - thanks 
<jderp> hey anyone around
#ubuntu-kernel 2016-11-29
<jderp> https://bugs.launchpad.net/ubuntu/+source/linux-lts-xenial/+bug/1645187
<ubot5`> Ubuntu bug 1645187 in linux-lts-xenial (Ubuntu) "4.4.0-47-generic dm_snapshot random deadlock" [Undecided,New]
<jderp> can reproduce that regression
<smb> jderp, That's bad but thanks for the report and the pointers. Sounds related but also like not yet finally decided which way to go. The patchwork patch might be preferred but also might not work. And the intrusive one appears to help in that case but is feared to cause other issues...
<hallyn> rtg: apw: i don't see any yakkety or z kernel packages for xenial.  are those coming soon?
<hallyn> (i ask bc dobey pointed out the font problem i'm having may be an intel driver issue whcih some have claimed goes away in yakkety)
<rtg> hallyn, ogasawara sent an email out on ubuntu-announce about HWE rolling kernels just yesterday. That might be what you want.
<hallyn> awesome thx
<rtg> hallyn, no Z kernel in Xenial until I figure out the MODVERSIONS mess from upstream
<hallyn> ugh
<hallyn> oh, is that related to the failure to build yakkety kernel locallocallyyocally?
<hallyn> maybe i should just run precise :)
<rtg> hallyn, nope, thats a different problem. I think your bug is related to someone goofing the ABI files. Maybe you should have another look at it now that Yakkety has updated a time or two
<hallyn> yeah, i should.  i'll try to do that this week.
<hallyn> sigh, can't run yakkety bc systemd;  xenial has font problem;  don't really wanna roll my own distro, maybe i can get people intersted in helping with a flavor
<hallyn> is the z kernel pretty stable?
<rtg> hallyn, is there any distro still on upstart ?
<rtg> hallyn, Z is passing most tests, but won't boot i386 'cause MODVERSIONS issues
<hallyn> well i'm running xenial with upstart, it works fine (better than with systemd, power-savings-wise)
<rtg> hallyn, v4.9-rc7 is in Zesty -proposed
<hallyn> if i rolled my own, then since libnih is now officially dead i'd probably just use sinit or something :)  but maybe systemd in z is better than in x, and i should just take the plunge
<hallyn> ok - well i'll revisit the yakkety build bug in a bit - thanks rtg 
<rtg> hallyn, np, for as much help as I was :)
#ubuntu-kernel 2016-12-01
<tjaalton> apw: hi, drm-intel-nightly tree has moved, it's now called https://cgit.freedesktop.org/drm-tip
<tjaalton> currently the same as old nightly
<tjaalton> despite the name
<tjaalton> so the mainline builder needs updating
<smb> tjaalton, hm, depending on time I may have a look into it
<tjaalton> smb: ok cool
<Sarvatt> arges: hey, sorry to bug you, do you have any idea what happened with 7.1.5-1ubuntu2 of the crash package? https://launchpad.net/ubuntu/+source/crash?
#ubuntu-kernel 2016-12-02
<JanC> does the abi-check script that Ubuntu uses depend on modversions?
<JanC> background: https://lwn.net/Articles/707520/
#ubuntu-kernel 2016-12-03
<jil> hi.  Is Linux mint using the same kernel as ubuntu ?
<jil> And if I'm using the recommanded version 3.19.0-32 is there danger to break something if I upgrade to the 4.4 serie ?
<jil> bye
#ubuntu-kernel 2017-11-28
<TJ-> Can someone remind me how to match kernel package versions to upstream versions? I'm sure there was a web-page or similar at one time
<Nafallo> TJ-: easiest by far is probably to check the changelog...
<TJ-> I've got the page but it seems to be slightly behind the times http://people.canonical.com/~kernel/info/kernel-version-map.html
<TJ-> I was looking for the xenial-hwe-edge 4.13.0.16.23 but it only shows 4.13.0-16.19
<Nafallo> TJ-: hmm. not sure what's going on there, but according to https://launchpad.net/ubuntu/+source/linux-hwe-edge/+publishinghistory there's never been a 4.13.0-16.23
<TJ-> There has; I'm doing some debugging and that  (was) the installed version at the time "linux-lowlatency-hwe-16.04-edge/xenial-proposed,now 4.13.0.16.23 amd64 [installed]"
<Nafallo> that's a meta package...
<TJ-> ahhh, good point!
<TJ-> OK, got it from the apt history.log: "inux-lowlatency-hwe-16.04-edge:amd64 (4.13.0.16.23), linux-headers-4.13.0-16-lowlatency:amd64 (4.13.0-16.19~16.04.3, automatic)"
#ubuntu-kernel 2017-11-29
<jbicha> hi, I'm proposing that Ubuntu 18.04 stop installing kerneloops-applet by default. Will that cause y'all any problems?
#ubuntu-kernel 2017-12-01
<tych0> cking: hi, i just ran into https://bugzilla.kernel.org/show_bug.cgi?id=195453
<ubot5> bugzilla.kernel.org bug 195453 in Other "race on fs/exec with fs_struct in_exec flag, introduced in commit 498052bba55ecaff58db6a1436b0e25bfd75a7ff" [High,New]
<tych0> or at least, i think i did
<tych0> i'm on artful's kernel
<tych0> and upgrading to go 1.9 fixed my issue, which has the golang workaround for the bug
<cking> well the golang fix is useful as it was originally doing things in a weird way
<tych0> but i guess the kernel bug is still out there?
<cking> tych0, it should have been fixed in ubuntu kernels
<tych0> huh, ok
<tych0> 4.13.0-16-generic on artful had some issue
<tych0> that an upgrade to go 1.9 fixed for me
<cking> hrm, the fix was in artful, commit 0f589e8640ed6bf377d80f5313fefc6c0ca40f18
<cking> in 4.12.0-7.8
<tych0> hrm
<tych0> so it is.
<tych0> my other problem is that hwen i tried ot make a minimal testcase, it didn't work :)
<cking> tych0, what does "it didn't work" refer to?
<tych0> cking: meaning, my minimal testcase behaved as expected. it's only in my actual code that i hit the race
<tych0> ...but it is pretty reliable
<cking> ugh; well file a new bug and add details of the reproducer and I'll try and get that sorted
<tych0> ok
<cking> it's a horrible race condition :-(
<tych0> yeah :(
<Reporting4Booty> Hello. What version of mainline is you guys' 4.13.0-16 based on? Is it an RC? I read the wiki page on source code, but there doesn't seem to be a corresponding release on kernel.org, only 4.13 and up. What am I missing?
<Reporting4Booty> 4.13.1 and up*, sorry.
#ubuntu-kernel 2019-11-25
<eddyTV> Hi. Is there a way to force the link state of a network interface "UP" when the NIC driver is loaded? When the kernel (5.0.0-36-generic) loads the e1000e driver on boot, link is NOT established. This is preventing NFS root booting from working.
<eddyTV> I can easily reproduce this by doing `rmmod e1000e` and then `modprobe e1000e`. No link LEDs on the PHY. But if I issue `ip link set eno1 up`, about 3 seconds later I get actual connectivity and LEDs come on...
<sarnold> eddyTV: in wild-guess territory, what's loading the module for you? /etc/modules in initramfs? or a udev rule? whatever is doing the load could probably also be configured to do the ip link set up command
#ubuntu-kernel 2019-11-26
<eddyTV> I don't have any udev rules configured, so it's just being automatically configured based on matching a line in lib/modules/5.0.0-36-generic/modules.alias...
<eddyTV> (unless I'm misunderstanding how hardware is discovered and its module get loaded in recent kernels... which is entirely possible)
<eddyTV> I like the idea of adding a custom udev rule though. I'll see if I can add something like ACTION=="add", SUBSYSTEM=="module", KERNEL=="e1000e", RUN+="ip link set eno1 up" and maybe that will work
<fling> Where do I get 5.4 shiftfs patches?
<fling> eoan?
<sforshee> fling: our 5.4 tree is currently git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/unstable, will move to focal once 5.4 is in focal-proposed
<fling> how do I clone it properly if I already have linus tree and eoan tree?
<fling> sforshee: are there only 20 patches needed?
<sforshee> fling: I don't know the exact count
<sforshee> fling: actually unstable is missing a couple that eoan has, so eoan currently has the most up-to-date version
<sforshee> they're probably on the list waiting to be applied
<sforshee> so probably better to get the patches from eoan atm
<fling> ok
<sforshee> fling: upon closer inspeection shiftfs is the same in eoan and unstable, eoan just has a patch and a later revert of that patch which is missing from unstable
<sforshee> so taking shiftfs from either should give you equivalent results
<fling> eoan is missing enable-overlayfs-on-shiftfs.patch
<fling> thanks
<fling> Is it fine to use zfs 0.8.2 with 5.4 ?
<sforshee> fling: not sure which was the first version compatible with 5.4, we've currently got 0.8.2-3ubuntu1 in focal which does work with 5.4
<sforshee> so based on 0.8.2, but it may have extra patches for 5.4 compatibility
<fling> good news!
<fling> sforshee: how can I check which extra patches are applied?
<sforshee> fling: if you download the source package then extra patches should be in debian/patches
<fling> Not sure how to do so, I'm an ubuntu noob
<fling> I'm building things on gentoo, could install ubuntu to a container
<sforshee> if you do that then 'apt-get source zfs-linux' will download the source package, you'll likely have to uncomment the deb-src lines in /etc/apt/sources.list and run 'apt-get update' first though
<fling> ok
<fling> do I need eoan?
<sforshee> you'll want focal, likely eoan's version doesn't work with 5.4
<sforshee> you might just try 0.8.2 first, and if it doesn't work then look at focal's patches
<fling> I believe it works
<fling> I just want to use it properly :P
<fling> sforshee: ubuntu people are trolling me, can't get the package :P
<sforshee> fling: you can always download the files manually, you'll need the .orig.tar.gz, .debian.tar.xz, and .dsc files from https://launchpad.net/ubuntu/+source/zfs-linux/0.8.2-3ubuntu1, then run 'dpkg-source -x *.dsc'
<fling> thanks
<fling> I found nothing related there.
<sub526>  As per https://help.ubuntu.com/lts/serverguide/kernel-crash-dump.html , i understood that a manual intervention is required in order to capture the memory for 'machine exceptions' or âHardware Failuresâ. What exactly âmanual interventionâ means? And how to get the crash dump in case of  'machine exceptions' or âHardware Failuresâ?
#ubuntu-kernel 2019-11-27
<pent1ckel> I'm using Ubuntu18 together with Strongswan and figured out that there is a memoryleak which is solved in mainline kernel already: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=86c6739eda7d2a03f2db30cbee67a5fb81afa8ba
<pent1ckel> my question is: how to get this patch backported to supported Ubuntu18 kernels
<apw> pent1ckel, i assume you mean 18.04
<pent1ckel> I'm sorry. yes I meant 18.04 apw 
<apw> pent1ckel, that sounds like the sort of thing which might come to us via stable; /me looks to see if it is pending
<pent1ckel> so it is very new I would say
<apw> it is a few weeks old, so there is hope
<apw> pent1ckel, no not made it to stable; so to get it into ubuntu more agressivly you should file a bug
<apw> against the kernel (https://bugs.launchpad.net/ubuntu/+source/linux/+filebug)
<apw> and add the detail of the commit which fixes it and which series are affected
<apw> and let us know here the #
<pent1ckel> ok. so I will first verify this agains ubuntu kernel by my self (tested already with vanilla kernel) and created this bug with all information included
<apw> pent1ckel, thanks
<pent1ckel> apw: is there a list where I also could have searched for this patch and the current state?
<apw> pent1ckel, the stable tree is where i looked to see if it was going to be coming soon
<apw> pent1ckel, as it is not, it really is only in linus' tree
<pent1ckel> it is in mainline as well. I've downloaded 5.4.0 and it is there
<pent1ckel> or did I understood you wrong?
<apw> pent1ckel, the bug is present ?
<apw> or the fix is present
<apw> the fix is present in 5.4-rc8 i think i saw
<pent1ckel> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/net/xfrm/xfrm_state.c?id=v5.4&id2=v5.3
<pent1ckel> here it is
<apw> right it is in only in linus' tree at this time; it has not made it to the stables yet
<apw> which is why we are talking about a bug
<pent1ckel> just to understand: https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.4.tar.xz this is not stable? there it is included
<apw> that is not a kernl produced by the upstream stable team
<pent1ckel> ohhh
<apw> it is a final version of the development kernel
<pent1ckel> ok. I'm sorry. this is new to me
<apw> it will be the kernel in our devleopment release soon
<pent1ckel> understand. I will verify and file the bug
<apw> selected fixes from the primary kernel get backportedd and put out as updates to older upstream versions
<apw> and we use those to see fixes for our kernels based on those versions
<pent1ckel> sure ... it is caled mainline ... now I got it. sorry for misunderstanding
<pent1ckel> I'm sorry. I nenver recognized this
<apw> pent1ckel, no need to appologise, it is complex, and the relationships between the kernels produced by distros and upstream even more so
<pent1ckel> apw: thank a lot. also I learned somethign new today
<mcphail> Hello. I've had 2 lock-ups in the past week when using wireguard with ubuntu-mate 19.10. I have .crash files in /var/crash which don't seem to be being sent by apport despite me selecting "report problem". Should I post them somewhere?
<apw> mcphail, there is a wireguard package in ubuntu you could file them against i guess
<mcphail> apw: OK, will do. Wondered if the oops was useful to you guys. I wish I could work out how to trigger it again
<apw> mcphail, the oops will always be key to solving that kind of thing i would think
<mcphail> Ta. Have filed at https://bugs.launchpad.net/ubuntu/+source/wireguard/+bug/1854225 and temporarily marked as "private" due to the info about the null pointer dereference
<ubot5> Error: ubuntu bug 1854225 not found
<apw> mcphail, could you subscribe launchpad user apw to it
<mcphail> apw: done
#ubuntu-kernel 2019-11-28
<pent1ckel> apw: https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/1854315
<ubot5> Ubuntu bug 1854315 in linux-meta (Ubuntu) "IPSec / xfrm memory leak found" [Undecided,New]
<pent1ckel> I filed the report here
<pent1ckel> also I verified it and it solves the memory leak
<apw> klebers: ^
<klebers> apw, looking
#ubuntu-kernel 2019-11-29
<LocutusOfBorg> cascardo, hello you there?
<LocutusOfBorg> I have news wrt LP: #1852435
<ubot5> Launchpad bug 1852435 in linux (Ubuntu) "Boots fine with 5.3.0-19, doesn't boot any more with 5.3.0-22" [Undecided,Confirmed] https://launchpad.net/bugs/1852435
<LocutusOfBorg> a colleague had the very same issue, and disabling TPM in bios worked flawlessly
<LocutusOfBorg> -19 was fine, and -20 was bad
<apw> sforshee, didn't you have something similar ^ ?
<LocutusOfBorg> I asked to test the cascardo drop, after enabling again tpm
<LocutusOfBorg> https://bugzilla.kernel.org/show_bug.cgi?id=204121
<ubot5> bugzilla.kernel.org bug 204121 in Other "tpm_tis - TPM interrupt not working, polling instead" [Normal,New]
<LocutusOfBorg> https://bugzilla.redhat.com/show_bug.cgi?id=1770021
<ubot5> bugzilla.redhat.com bug 1770021 in kernel "TPM interrupt storm makes T490s unusable on Fedora 31" [High,New]
<LocutusOfBorg> looks like know
<LocutusOfBorg> *known
<LocutusOfBorg> cascardo, apw, the fix on the bug report works, I hope you can followup with a proposed upload on next kernel update :)
<apw> LocutusOfBorg, "the fix" ?
<LocutusOfBorg> well, the cascardo's drop
<LocutusOfBorg> we are happy to test a kernel built with a revert of the commit: "tpm_tis_core: Turn on the TPM before probing IRQ's" that will probably fix the issue
<LocutusOfBorg> just to be sure, the code probably never worked, enabling the tpm is just starting some race condition that goes into an endless loop
<apw> ok then i will leave it to cascardo to comment what he had you test etc
<LocutusOfBorg> yep, my colleague is available to test drops, in case you want, but I'm sure also other people will be happy to test
