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