[00:21] <crimsun> pgraner: hi
[02:59] <imbrandon> ok so i did a bit of googlin but my google-fu dosent seem to work, since my upgrade to 9.10 ( headless server ) my nic seems to goto sleep after a while ( even with activity ) , is there a way to tell the kernel/driver NOT to put the nic to sleep ?
[03:00] <imbrandon> ever
[03:55] <JFo> imbrandon, what hardware?
[04:18] <imbrandon> JFo, via c7 proc ( x86 ) and the network cards are a rtl and a rine-ii
[04:18] <imbrandon> both cards seems to be effected
[04:21] <imbrandon> JFo, here is the output of uname,lspci,and /proc/cpuinfo
[04:21] <imbrandon> root@enterprise:~# uname -a
[04:21] <imbrandon> Linux enterprise 2.6.31-20-generic #57-Ubuntu SMP Mon Feb 8 09:05:19 UTC 2010 i686 GNU/Linux
[04:21] <imbrandon> root@enterprise:~# cat /etc/issue
[04:21] <imbrandon> Ubuntu 9.10 \n \l
[04:21] <imbrandon> root@enterprise:~# cat /proc/cpuinfo 
[04:21] <imbrandon> processor	: 0
[04:21] <imbrandon> vendor_id	: CentaurHauls
[04:21] <imbrandon> cpu family	: 6
[04:21] <imbrandon> model		: 10
[04:21] <imbrandon> model name	: VIA Esther processor 1500MHz
[04:21] <imbrandon> stepping	: 9
[04:21] <imbrandon> cpu MHz		: 1496.425
[04:21] <imbrandon> cache size	: 128 KB
[04:21] <imbrandon> fdiv_bug	: no
[04:21] <imbrandon> hlt_bug		: no
[04:21] <imbrandon> f00f_bug	: no
[04:21] <imbrandon> coma_bug	: no
[04:21] <imbrandon> fpu		: yes
[04:21] <imbrandon> fpu_exception	: yes
[04:21] <imbrandon> cpuid level	: 1
[04:21] <imbrandon> wp		: yes
[04:21] <imbrandon> flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge cmov pat clflush acpi mmx fxsr sse sse2 tm nx up pni rng rng_en ace ace_en ace2 ace2_en phe phe_en pmm pmm_en
[04:21] <imbrandon> bogomips	: 2992.85
[04:21] <imbrandon> clflush size	: 64
[04:21] <imbrandon> power management:
[04:21] <imbrandon> root@enterprise:~# lspci
[04:21] <imbrandon> 00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
[04:22] <imbrandon> 00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
[04:22] <imbrandon> 00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
[04:22] <imbrandon> 00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge
[04:22] <imbrandon> 00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
[04:22] <imbrandon> 00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
[04:22] <imbrandon> 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237/VX700 PCI Bridge
[04:22] <imbrandon> 00:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10)
[04:22] <imbrandon> 00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80)
[04:22] <imbrandon> 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
[04:22] <imbrandon> 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
[04:22] <imbrandon> 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
[04:22] <imbrandon> 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
[04:22] <imbrandon> 00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
[04:22] <imbrandon> 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
[04:22] <imbrandon> 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge 
[04:22] <imbrandon> shut
[04:22] <imbrandon> http://imbrandon.pastebin.com/tFCFMptx
[04:22] <imbrandon> sorry wrong paste
[04:24] <imbrandon> i'm assuming its the nic that goes to sleep because the system cannot be reached via ssh/smb/nfs/http when it happens
[04:24] <imbrandon> but proceses still seem to run
[04:24] <imbrandon> and nothing i can see in dmesg about it
[04:25] <imbrandon> but the nic "wakes" when i pound on a keyboard thats attached, but its headless
[04:25] <imbrandon> and resumes ssh sessions and http sessions etc as is it was never off
[13:37] <apw> cooloney, so what missed the cut?  how big is it?  how well tested is it?
[14:17] <cnd> apw, did the hid configuration get switched to a module?
[14:17] <apw> cnd, i am considering it now, why?
[14:20] <cnd> sorry, connection dropped
[14:20] <cnd> apw, I was mostly just wondering if there was any more thought given to it
[14:21] <apw> i was considering commiting it if it boots ok
[14:21] <cnd> I would agree with that
[14:23] <cnd> apw: also I have that patch to lower the log level of acpi resource conflicts
[14:23] <cnd> I sent it to linux-acpi, it was refined according to what was stated there
[14:23] <apw> thats just logging level change right?
[14:23] <cnd> but I've not heard anything back since
[14:23] <apw> so we can do that after the beta
[14:24] <cnd> apw, at this point it's a log level change + message cleanup
[14:24] <cnd> using %pR instead of [0x%lx-0x%lx]
[14:24] <apw> still minor
[14:25] <cnd> apw, I'm just not too familiar with their process, so I don't know when I'll hear anything back
[14:25] <cnd> so I guess keep it in mind for whenever you feel we need to make a decision on it
[14:25] <apw> if they are happy you may hear nothing
[14:25] <cnd> yeah, but their git tree hasn't been updated either
[14:26] <cnd> it's probably sitting in a queue of patches ready to be applied :)
[14:26] <tgardner> cnd, thats just Len. He takes awhile sometimes.
[14:26] <cnd> tgardner: ok, likely he'll have it applied before we have to make a decision without them?
[14:27] <tgardner> not necessarily, but for something that minor we can make our own decision
[14:27] <cnd> yeah
[14:27] <cnd> just let me know if you need to make a decision basically
[14:27] <cnd> since I'm new to the process I just don't know when that point is for lucid
[14:28] <tgardner> cnd, have we seen the patch on the k-t list yet? I don't recall
[14:28] <cnd> tgardner: no, but I can send it if you'd like
[14:28] <tgardner> cnd, its likely the only way it'll get considered :)
[14:28] <cnd> ok
[14:28] <cnd> will do
[14:29] <tgardner> cnd, P.S. since that patch will come post-freeze it'll also have to have an SRU justification.
[14:30] <cnd> tgardner: ok, so I just need to put an SRU justification note in the bug, right?
[14:30] <cnd> or also in the message sent to k-t?
[14:31] <tgardner> cnd, SRU justifications only exist in the LP report. the SRU team doesn't follow the k-t list
[14:31] <cnd> ok
[14:31] <tgardner> though it doesn't hurt to add it in teh commit log message
[14:47] <cnd> bdmurray: I see the wording of the "patch" checkbox when making an attachment is more clear that it's for solutions only
[14:47] <cnd> thanks :)
[14:52] <JFo> bdmurray, at what 'age' do those patch cases show up in the patch view you showed me?
[15:17] <bdmurray> JFo: it should just show all of them, no age limit required
[15:17] <JFo> bdmurray, it doesn't seem to be
[15:17] <JFo> I only had 2 in the list the other day that were in an open state
[15:17] <JFo> the rest were Fix Released
[15:18] <JFo> it is only giving me 97 items
[15:18] <JFo> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.has_patch=on
[15:19] <JFo> tells me that there are 113 items
[15:19] <JFo> let me look a bit deeper
[15:19] <bdmurray> hrm the 2nd link is just linux bugs and the kernel-bugs one should be more
[15:19] <JFo> yeah, none of these are Fix Released
[15:20] <JFo> bdmurray, I agree
[15:20] <JFo> :)
[15:20] <JFo> just wanted to give you some timely feedback after my initial investigation
[15:20] <JFo> or rather I hope it is timely :)
[15:21] <bdmurray> okay, thanks I'll look into it later today
[15:24] <bjf> **
[15:24] <bjf> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:24] <bjf> **
[15:25] <JFo> bdmurray, np
[16:16] <bjf> ## 
[16:16] <bjf> ## Ubuntu Kernel Team Meeting - in 45 minutes - #ubuntu-meeting
[16:16] <bjf> ##
[16:16] <bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
[17:00] <bjf> ##
[17:00] <bjf> ## Meeting starting now - #ubuntu-meeting
[17:00] <bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
[17:00] <bjf> ##
[17:22] <JFo> bryceh, have you issued a Call for Testing for the DRM stuff that was backported from the .33 kernel?
[17:23] <bryceh> JFo, nope
[17:23] <JFo> do you want me to do that?
[17:23] <bryceh> JFo, however I did do targeted bug spamming around it to specific bug reports on -ati and -intel
[17:23] <bryceh> JFo, yeah go for it
[17:24] <JFo> bryceh, I can include whomever you want if there are any specific lists/etc.
[17:24] <JFo> will do
[17:24] <bryceh> JFo, write your email with care, lest you end up with way more bug reports than you bargained for ;-)
[17:24] <JFo> oh btw bryceh, I am still chugging through that list you provided me of bugs to assign to the kernel task. Just wanted you to know I had not forgotten it
[17:24] <apw> manjo, that reminds me, you skipped suspend/resume so quick that i didn't get to say anything
[17:24] <bryceh> ah great
[17:25] <apw> but ... we did get your patch in, and i am seeing some benefits already ... one bug where the battery is fingered as taking 10s to resume
[17:25] <manjo> apw, only thing that remains is frequency based suspend resume 
[17:25] <bryceh> JFo, I've been bumping a bunch more your way as I run across more drm bugs.  seems quite a few
[17:25] <JFo> bryceh, I noticed a few more were tagged
[17:25] <JFo> yep, I've seen them
[17:25] <JFo> bryceh, I'll keep that page to check periodically
[17:25] <JFo> so that you don't have to ping me on them
[17:25] <manjo> apw, yes I also need to get the arsenal stuff in place so that I can start mass responding to those suspend resume stuff
[17:26] <bryceh> I try to clearly mark ones that look like the new drm will fix them so hopefully those should be pretty straightforward to close
[17:26] <bryceh> JFo, great
[17:26] <JFo> bryceh, sounds good to me
[17:26] <manjo> apw, currently over whelmed with this netbook stuff that seems to be put on high priority 
[17:26] <apw> manjo, k
[17:27] <manjo> apw, what did you have in mind wrt to suspend resume ? that you think I skipped over ? 
 but ... we did get your patch in, and i am seeing some benefits already ... one bug where the battery is fingered as taking 10s to resume
[17:27] <apw> i was going to say that your patch was in and proving useful
[17:27] <manjo> ah! thanks 
[17:28] <apw> jfo is the arsenal running at least the basic things automatically yet
[17:28] <JFo> bryceh, I'll CC you on the Call for Testing so that it hits your radar
[17:28] <apw> like the linux-meta retarget thing ...
[17:28] <manjo> I would like some arsanel edu from JFo 
[17:28] <JFo> apw, it is running in dry run. I am looking over its results daily for those that it should be catching
[17:28] <JFo> I should have the basics running real mode by the end of tomorrow
[17:29] <JFo> they are on my list
[17:29] <apw> JFo, is it failing often enough that at least that one test can't go live?
[17:29] <JFo> I just hadn't gotten to them yet
[17:29] <bjf> apw, manjo, I can add that to the meeting minutes anyway
[17:29] <apw> JFo, ok
[17:29] <JFo> apw, no, it seems to be solid
[17:29] <apw> bjf, thanks
[17:29] <bryceh> JFo, oh cc ubuntu-x@ - we've got a lot of X oriented folks there who might participate
[17:29] <JFo> just wanted to wait until I could focus on it and be sure that the changes I put in do not break them
[17:29] <JFo> bryceh, will do
[17:30] <manjo> apw, wonder if we could drop frequency based suspend resume from the blueprint 
[17:30] <manjo> and move it to M+
[17:30] <apw> manjo, if we arn't going to get to it we can postpone it
[17:30] <apw> and it'll go yellow
[17:30] <apw> (on the graph)
[17:30] <manjo> apw, is that bad ? 
[17:31] <manjo> or how bad is it on us ? 
[17:31] <apw> its not sounding that important, and we'll be turning off apport before release ... so not the end of the world
[17:31] <manjo> apw, coz I rather get real issues fixed instead 
[17:31] <apw> yep, fine with me
[17:32] <apw> push it POSTPONED 
[17:32] <manjo> ok
[17:32] <bryceh> JFo, btw I don't know if you saw my email to the platform team list but I've been auto-tagging bugs 'lucid' to differentiate out bugs that definitely affect lucid from those that might just be reports against old releases
[17:32] <manjo> JFo, can we get some skype time together this week or so and talk about arsenal ? 
[17:32] <bryceh> JFo, this has really helped me in narrowing down on the bugs I have to worry about
[17:32] <JFo> yep, I saw it. Great stuff... just like what I am trying to do for kernel
[17:32] <manjo> JFo, I need some schooling 
[17:33] <JFo> manjo, sure
[17:33] <bryceh> JFo, am thinking that approach could help you guys out too
[17:33] <JFo> bryceh, every bit helps :)
[17:33] <JFo> absolutely
[17:33] <apw> bryceh, iwe have an arsenal script for that too :)
[17:33] <apw> most of our bugs are already tagged as apport now does it
[17:33] <JFo> bryceh, we started implementing, but I admit I got distracted
[17:33] <bryceh> apw, awesome :-)
[17:33] <manjo> JFo, just setup a time you are free ... sit on the porch with a cigar and team me ... 
[17:33] <JFo> manjo, ok
[17:33] <apw> JFo, we already have it
[17:33] <JFo> apw, I know
[17:34] <JFo> but I haven't been doing it manually like I needed to :)
[17:34]  * apw looks confused for a second, then moves on
[17:34] <manjo> JFo, send out a mail so that if anyone wants to listen in can... 
[17:35] <JFo> will do manjo 
[17:35] <manjo> JFo, thanks a ton 
[17:35] <JFo> my pleasure
[17:36] <apw> bryceh, what was that tag you added when you needed a kernel fix for a graphics bug?
[17:37] <manjo> apw, JFo there was an idea to opensource the kernel-qa & reporting scripts that we have so that the locos can have their on testing workshop etc ... 
[17:37] <bryceh> apw, it is 'xorg-needs-kernel-fix'
[17:37] <manjo> apw, JFo something we can talk about at UDS or some place we meet 
[17:37] <bryceh> apw, which I've sort of regretted picking because it takes way too much typing ;-)
[17:37] <JFo> and 'resolution'
[17:37] <bryceh> apw, but it's in finger-muscle memory now so not too bad
[17:38] <JFo> manjo, yep
[17:38] <JFo> bryceh, heh
[17:38] <manjo> JFo, something you can add to your track at UDS
[17:38] <bryceh> other tags we use for X are docced at https://wiki.ubuntu.com/X/Tagging
[17:38] <JFo> manjo, sounds good
[17:40] <bryceh> the tags 'freeze', 'edid', 'tv-out', 'font-size', 'resolution' and maybe 'black-screen' are ones likely to be drm bugs for drivers using KMS
[17:41] <bryceh> so those possibly might be worthwhile tags to consider adding to the kernel bug tags list
[17:41] <JFo> I've seen some ones tagged edid
[17:42] <JFo> with kernel tasks
[17:42] <JFo> bryceh, I guess the big issue is making sure I don't Invalidate the xorg task on ones that should retain it
[17:42] <bryceh> JFo, be aggressive
[17:43] <JFo> heh
[17:43] <JFo> ok, will do
[17:43] <bryceh> JFo, generally from what I've seen when a bug is identified as needing a drm fix, it'll just need a kernel patch to fix, and there's not work to be done on the x side
[17:43] <bryceh> if it turns out there is, someone can always reopen the X task later when the work is clear
[17:44] <JFo> bryceh, cool, I thought so, but that seemed like additional work
[17:44] <JFo> :)
[17:44] <JFo> <-trying to be a bit more efficient if possible
[17:46] <bryceh> JFo, sure use your judgment and if in doubt leave the task.  I'm pretty aggressive at pruning them though
[17:47] <JFo> sounds good bryceh 
[17:47] <JFo> thanks
[17:50] <apw> manjo, whats going on with bug #491210
[17:50] <ubot3> Malone bug 491210 in linux "[i865G] Monitor Resolution limited to 800x600" [High,Confirmed] https://launchpad.net/bugs/491210
[17:50] <apw> manjo, sorry missed, bug #507148
[17:50] <ubot3> Malone bug 507148 in linux "[lucid] desktop runs out of video memory on ATI Radeon Mobility 7500" [High,Confirmed] https://launchpad.net/bugs/507148
[17:50] <manjo> just a sec
[17:55] <JFo> bryceh, I just subscribed to the X ML, I wasn't aware that I wasn't already subscribed. :)
[17:55] <JFo> sorry about that
[17:55] <JFo> will resend in a bit
[17:55] <bryceh> JFo, kewl.  it's pretty low traffic
[17:55] <manjo> apw, talking to jdstrand .. give me a few mts 
[18:11] <manjo> apw, skype you ?
[18:11] <apw> sure
[18:12] <manjo> your offline 
[18:12] <apw> you're
[18:49] <jono> tgardner, has linux-backports-modules-wireless-lucid-generic now built ready for me to test?
[18:55] <tgardner> jono, yep
[18:56] <tgardner> jono, you want linux-backports-modules-2.6.32 (2.6.32-16.7) lucid; urgency=low
[19:23] <cnd> tgardner: is the lbm firmware any different than the linux-image firmware?
[19:25] <tgardner> cnd, the files that exist there are no different, but the 6K firmware is new, and they may change during the Lucid life cycle
[19:25] <cnd> tgardner: 6k firmware?
[19:25] <cnd> 6050 by any chance?
[19:26]  * cnd has a 6050 card, waiting for fw to drop from intel to be able to use it
[19:29] <cnd> looks like just 6000 firmware...
[19:30] <cnd> tgardner: I just looked at http://packages.ubuntu.com/lucid/linux-backports-modules-wireless-lucid-generic, but it doesn't list any files in the package
[19:30] <cnd> is this the package you are pointing jono at?
[19:30] <tgardner> cnd, thats a meta package
[19:31] <cnd> oh
[19:31] <cnd> ok
[19:31] <cnd> let's see, where's the real package...
[19:32] <cnd> yep, just the 6000 firmware, oh well
[20:33] <cnd> hmmm... I'm beginning to wonder if cking's arrandale TSC issue isn't arrandale specific...
[21:10] <tgardner> huh, I have a Radeon Xpress 200M that works pretty well in Lucid
[23:30] <dyek> Hi! Any idea why using Ubuntu 9.10's vmlinuz-2.6.31-16-generic as DomU causes this Xen error? Error: (2, 'Invalid kernel', 'elf_xen_note_check: ERROR: Will only load images built for the generic loader or Linux images') What is not generic loader about Ubuntu 9.10's -generic kernel?
[23:32] <jjohansen> dyek: what are you trying to load?
[23:34] <dyek> jjohansen: I'm currently using CentOS 5.4 as Dom0 (with a recent Xen hypervisor package -- Xen 3.4.2) and attempting to boot Ubuntu 9.10's kernel as DomU (I copied Ubuntu's kernel to Dom0's FS manually.)
[23:35] <jjohansen> dyek: hrm, i386 or x86_64?
[23:36] <dyek> jjohansen: CentOS Dom0 is x86_64, but Ubuntu is i386.
[23:36] <jjohansen> dyek: do you have an initrd, initramfs
[23:37] <dyek> jjohansen: I know I have initrd -- I copied the entire Ubuntu's /boot directory into Dom0's FS, naming it /boot_ubuntu.
[23:38] <dyek> jjohansen: Not sure about initramfs.
[23:38] <jjohansen> dyek: initramfs is just a replacement for initrd
[23:38] <jjohansen> okay you should be good there then
[23:39] <jjohansen> to be clear this is Dom0 complaining about the 9.10 kernel right?
[23:40] <dyek> jjohansen: Yes. "xm create" results in the error.