[05:06] <mdomsch> superm1, around?
[05:15] <superm1> mdomsch, yeah
[05:15] <superm1> whats up?
[05:16] <mdomsch> nothing major, just noting the last dkms commit wasn't quite complete; you need to update Makefile too, as that's what's generating .orig.tar.gz
[05:16] <mdomsch> (I think)
[05:17] <superm1> mdomsch, you mean http://linux.dell.com/git/?p=dkms.git;a=blobdiff;f=Makefile;h=68d1ba0c000da1ac3a1fc5ecdee2ddf3e43079e9;hp=6f082bc43115d2c5765d9b20a3cf0102c0364dd3;hb=055aa92dd408938e284c7559fb0b3691f68b124a;hpb=d6b4e7f6199b741e7d236195dedb1095d76088e2 ?
[05:18] <mdomsch> no. the permalink is still named .orig.tar.gz
[05:18] <mdomsch> but the git commit says it's not .orig
[05:19] <superm1> oh both are being generated actually
[05:19] <superm1> they should realistically be symlinks of one another, but that's a build bug
[05:19] <mdomsch> ah.
[05:20] <mdomsch> the .orig is the only one in the permalink/ dir
[05:20] <superm1> nope, they're both there
[05:20] <superm1> http://linux.dell.com/dkms/permalink/dkms-2.1.0.1.tar.gz
[05:20] <mdomsch> ugh; sure enough.  bad eyes.
[05:21] <mdomsch> dashes and underscores
[05:21] <superm1> yeah, it's easy to miss
[05:21] <mdomsch> sorry for the noise then
=== hzhang__ is now known as panda|phenom
[08:00] <cooloney_> ericm_, can access the kernel team page on wiki.ubuntu.com?
[08:04] <ericm_> cooloney_, wait
[08:10] <mvo> has anyone had a hang on "pci 000:00:00.0: Found enabled HT MSI Mapping" on a amd64 at boot? I get this regularly (the line is repeated 10 times
[08:11] <ericm_> cooloney_, I can access the page
[08:16] <cooloney_> ericm_, thanks, i can now, it is very slow
[09:13] <Kano> hi, when will the tree be rebased on .31 final?
[09:24] <ogra> before kernel freeze :P
[09:24] <Kano> i am waiting for it
[09:25] <apw> Kano, when its tested as always !
[09:25] <ogra> so wait a little more then ... 
[09:25] <Kano> apw: i tested vanilla kernel, it fixes my intel problems
[09:25] <apw> what intel problems you seeing?  
[09:26] <Kano> without kms it crashed on vt switch or X shutdown. well in the kernel log it is shown as suspend fix, as this was triggered then too even when kms was used
[09:26] <Kano> just before the .31 release
[09:27] <ogra> whats the bug # ?
[09:27] <Kano> ogra: i use a slightly different kernel config with those KMS entries not set
[09:27] <apw> Kano, ahh gpu hangs on suspend/resume perhaps?
[09:28] <Kano> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e6890f6f3dc2d9024a08b1a149d9bd5208eea350
[09:29] <apw> that could well be my 'gpu hang' on attempting to suspend then
=== Ng_ is now known as Ng
[09:37] <cooloney_> apw, if a config option depends on CONFIG_BROKEN, does that mean the config option is broken?
[09:37] <apw> it means that they don't believe that that support works yes
[09:38] <cooloney_> apw, if i want to enable that config option, where can i enable CONFIG_BROKEN firstly?
[09:38] <apw> i don't think you can, i think you'd have to patch it to not have that
[09:39] <cooloney_> apw, yeah, thanks, i did the dirty things just remove the dependence of BROKEN. and build the kernel for some testing
[09:40] <apw> yeah pretty sure you'd not want to turn on BROKEN it would likely turn on a lot of stuff
[09:42] <cooloney_> apw, for boardcom BCM4312 wifi device, i found we have 2 drivers
[09:43] <cooloney_> apw, one is open source b43 driver but it needs to enable to support low power phy on my platform
[09:44] <cooloney_> apw, and the other is BCM STA driver which is close source, it also has some problem.
[09:44] <cooloney_> apw, do you know which is more popular? i don't think I can debug the STA driver 
[09:46] <apw> yeah have no idea.   a problem indeed.  the open source one is easier to fix clearly as we can see it
[09:46] <apw> but BROKEN is not encouraging
[09:46] <Kano> cooloney_: many kanotix users use the sta with a little dkms script
[09:46] <Kano> patched to work up to .31 using gentoo patches
[09:47] <Kano> cooloney_: http://kanotix.com/files/fix/dkms/broadcom-wl-dkms.sh
[09:47] <cooloney_> Kano, thanks, since i have 2 candidate to test, I will try the b43 driver firstly. 
[09:47] <Kano> try if you like
[09:47] <cooloney_> Kano, thanks a lot
[09:47] <cooloney_> Kano, i will try that
[09:47] <Kano> well the wl driver is needed for some devices which are not supported by the other one
[13:12] <rtg> apw, did you get a chance to repro the suspend failure with -10 on your mini-10?
[13:12] <apw> seems to work on my -10 ...
[13:12] <rtg> drat
[13:12] <apw> rtg though i think i know which fix fixes the issue, and i think its in linus v2.6.31
[13:13] <apw> am test building the rebase now, its so minor its not even an abi bump
[13:13] <rtg> are all of the suspend failure machines based on Intel graphics?
[13:13] <apw> i cannot tell as yet, i have asked in the bug
[13:13] <rtg> apw, ok, thanks.
[13:14] <apw> should have a kernel for testing pretty soon, and if i've done it right ready to upload too
[13:14] <apw> rtg i presume our .orig files are simply linus' tarball from www.kernel.org
[13:15] <rtg> apw, yep
[13:15] <apw> cool
[13:17] <apw> rtg, can i confirm that the virtual image should be happy with grub-pc as a bootloader same as all the other images
[13:17] <apw> seems it got missed in the conversion
[13:20] <rtg> apw, I think we should ask zul
[13:36] <apw> rtg damn he isn't about, and its in my tree rght now... hrm to pull it or not to pull it
[13:38] <Kano> apw: when do you commit the new kernel?
[13:39] <apw> likely today sometime ...
[13:39] <Kano> will you add ati r600 kms/3d patches later
[13:40] <apw> not sure we know as yet what if any ati patches we need
[13:41] <Kano> well in #radeon they told me tomorrow or so they will update em again
[13:41] <Kano> for fedora
[13:42] <Kano> airlied of course
[13:42] <apw> indeed so
[13:42] <apw> i rely on our X peeps for guidance on that side
[13:43] <Kano> https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/392039
[13:43] <ubot3> Malone bug 392039 in fglrx-installer "initramfs scripts hard-coded to load i915; blocks loading fglrx" [Undecided,Confirmed] 
[13:43] <Kano> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/380138
[13:43] <ubot3> Malone bug 380138 in linux "Do NOT disable HPA by default -> leads to data loss" [Medium,In progress] 
[13:43] <Kano> whats the status on that
[13:44] <apw> why would loading i915 block loading of fglrx
[13:44] <apw> regardless of it being stupid
[13:44] <Kano> well older drivers are blocked, not that 9.10 driver, but olders are
[13:45] <Kano> basically you could check for the /sys entry for drm if kms is used
[13:46] <apw> as far as i know that is being worked on
[13:46] <apw> i think its completely redundant
[13:46] <Kano> yes, the modprobe too because thats a think of udev
[13:46] <Kano> udev loads it anyway
[13:49] <Kano> why was the hpa setting not reverted? if it is stored in the hd you just have to tell the ppl to use hdparm
[13:50] <Kano> the -N option can set it temporary or permanently
[13:50] <Kano> if you use -N pSECTORCOUNT then it is permanent
[13:51] <Kano> if somebody has a 32 gbyte limit he should  just check the jumpers on the hd
[13:51] <Kano> absolutely pointless to remove hpa by default
[13:52] <Kano>  max sectors   = 1953525168/1953525168, HPA is disabled
[13:52] <Kano> when you check with -N
[13:52] <Kano> and then set a lower number than the max then HPA is enabled
[13:53] <Kano> maybe add a little wiki page and point those few users to that
[13:53] <Kano> for all others it is critical to remove it as they could overwrite data which is overwritten by the bios
[13:54] <Kano> and especially raid systems will fail when it is removed till full poweroff
[14:01] <apw> we decided on a hybrid approach, but its not yet there, slipped thorugh the net
[14:04] <apw> rtg, ok the general feeling on #u-server is that grub2 is completely reasonable addition...
[14:17] <apw> Kano, the initrd stuff is ongoing, still on target for karmic
[14:25] <Kano> you dont need  hybrid appoach, just teach your users how to get rid of hpa
[14:32] <rtg> apw, looks good so far as I can tell. upload it
[14:32] <apw> ack
[14:35] <apw> rtg, do we announce non-abi bumping uploads?
[14:35] <rtg> apw, not normally, but you could still announce that this is the last rebase, blah, blah...
[14:36] <apw> fair point will do
=== zul_ is now known as zul
[16:01] <jjohansen> time for the UEC/EC2 kernel status update
[16:01] <rtg> jjohansen, what do we know since yesterday?
[16:01] <jjohansen> we have some testing from a couple users
[16:02] <jjohansen> Eric Hammond is one of them
[16:02] <jjohansen> I repushed the aki, and ari's last night with more descriptive image names
[16:02] <jjohansen> as Eric suggested
[16:03] <rtg> has he had any success or failures?
[16:03] <jjohansen> yes, the kernel has been reported as booting
[16:04] <jjohansen> there have been failures with modules, but that is expected as the ppa needs to be installed to get the new modules for the kernel
[16:04] <rtg> how about runtime stress? there are huge changes in the VM core for Xen wrt 2.6.31
[16:05] <jjohansen> There has not been any run time stress testing that I am aware of yet.
[16:05] <rtg> jjohansen, so what does Eric need from us in order to facilitate his test efforts?
[16:06] <jjohansen> He has asked for more descriptive AKI, ARI names (done)
[16:06] <jjohansen> and PPA so he can install modules
[16:06] <jjohansen> both are available
[16:07] <rtg> jjohansen, assuming the ec2 source package gets uploaded soon, then he can likely use that?
[16:07] <jjohansen> yes
[16:07] <rtg> from the main archive, I mean
[16:07] <jjohansen> right, he just needs a source for modules
[16:07] <rtg> ok, anything else worthy of note?
[16:08] <jjohansen> not that I am aware of
[16:08] <rtg> jjohansen, maybe we should be having this on #ubuntu-server 'cause there are more folks in that channel that might care about ec2
[16:09] <jjohansen> rtg: I will run that past smoser, zul and if they agree post out a mail
[16:09] <rtg> jjohansen, good, meeting adjourned?
[16:10] <jjohansen> yes, I think so
[16:10]  * smoser reads backscroll
[16:11] <smoser> soryr i wasn't here earlier, i mistook GMT and UTC
[16:11] <jjohansen> smoser: you agree with moving this little meeting to #ubuntu-server
[16:12] <smoser> sure
[16:12] <jjohansen> smoser: heh, sorry my bad should have sent out as UTC
[16:12] <smoser> so, above you brought up 2 things
[16:12] <jjohansen> smoser: would an hour later be better for you
[16:12] <smoser> i say move to #server tomorrow
[16:12] <smoser> doesn't matter this is fine. just didn't translate.
[16:12] <smoser> anyway
[16:13] <smoser> so 2 things
[16:13] <smoser> 1. modules
[16:13] <smoser> the one issue that people had there was with CONFIG_LOOP=m. it is solvable, and i posted how to solve it to the bug.
[16:13] <smoser> but i think we want the configs as much as possible to model the normal server configs
[16:13] <jjohansen> right, I saw that. thanks
[16:14] <smoser> (maybe that is the case with the server, but my -generic shows CONFIG_LOOP=y)
[16:14] <rtg> smoser, since the ec2 kernel is a separate source package we can make the config options different then the master branch kernel.
[16:14] <smoser> i'd just like to have 'ubuntu-on-ec2' as much as possible "just like" ubuntu-server
[16:15] <smoser> rtg, i'm saying that even if we can, i think in general we should not
[16:15] <jjohansen> smoser: okay will look at the configs and see what else jumps out
[16:15] <rtg> smoser, no problem here.
[16:15] <smoser> jjohansen, kexec i know of... but that is just a personal interest as i'd love to try kexec updating my kernel :)
[16:16] <smoser> so, lets try to make the configs as similar as we reasonably can
[16:16] <smoser> 2.) second thing is naming on ec2
[16:16] <smoser> i'm wanting to put together a doc on how we should name things what buckets to use.  in the past we've been wildly inconsistent.
[16:17] <smoser> one thing that stinks is that its a global namespace, and if we say we're going to use 'canonical-kernels' and someone jumps in and takes that bucket name we get screwed :)
[16:17] <rtg> smoser, will this affect the source package name? or is this an Amazon thing
[16:18] <smoser> i think amazon thing only
[16:18] <rtg> smoser, before I write the MIR, do you want to change the name from ec2 to uec?
[16:18] <smoser> thats not really a problem with the single name, but if there are limits to the contents of a bucket (apparently at least there were size/number-of-files limits) and we used canonical-kernels-XX, someone could grab future names.
[16:18] <zul> traditionally everything has been uploaded to canonical-cloud-{us,eu}
[16:19] <smoser> zul, possibly its just an issue with different people (you, soren, me) (probably mostly me) doing it
[16:19] <smoser> but i just would like to have consistent naming everywhere.
[16:19] <zul> and traditionally ive called them vmlinuz-2.6.xx-yy-<arch>
[16:19] <smoser> rtg, this is a 'ec2' kernel. not related to uec (well, unless they're doing uec on xen...and very old xen, but i dont think that is likely supported)
[16:20] <smoser> zul, ill make sure that i look at what you've used in the past
[16:20] <jjohansen> rtg: we should consult with mdz on the name
[16:21] <smoser> sure, thats fine. but it really is an ec2 kernel.  the uec kernels people will use will likely be -server based (or -virtual)
[16:21] <rtg> jjohansen, why? did he have a strong opinion? Its not like this kernel is gonna work anywhere other then Amazon or CenOS 5.0
[16:22] <jjohansen> rtg: there was some strong opinions expressed a few weeks ago
[16:22] <jjohansen> rtg: just want to double check before we commit
[16:22] <smoser> well, using uec here would be confusing
[16:23] <smoser> as most uec would be kvm (full virt) and this thing wouldn't boot
[16:23] <zul> rtg: no necessarily the xen hypervisor is backwards compatible
[16:24] <rtg> zul, hmm. I'll ask the question of the key players in email
[16:25] <zul> rtg: sure
[20:56] <Q-FUNK> re
[20:59] <Q-FUNK> ogasawara: is there anything else I can do with bug #396286 ?
[20:59] <ubot3> Malone bug 396286 in linux "2.6.31-generic: kernel panic near the end of initramfs" [High,In progress] https://launchpad.net/bugs/396286
=== bjf is now known as bjf-afk