crimsun | pgraner: hi | 00:21 |
---|---|---|
=== KB1JWQ is now known as PFY | ||
=== PFY is now known as KB1JWQ | ||
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 ? | 02:59 |
imbrandon | ever | 03:00 |
=== emma_ is now known as emma | ||
JFo | imbrandon, what hardware? | 03:55 |
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:18 |
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:21 |
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:22 |
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:24 |
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 | 04:25 |
apw | cooloney, so what missed the cut? how big is it? how well tested is it? | 13:37 |
=== sconklin-away is now known as sconklin | ||
cnd | apw, did the hid configuration get switched to a module? | 14:17 |
apw | cnd, i am considering it now, why? | 14:17 |
cnd | sorry, connection dropped | 14:20 |
cnd | apw, I was mostly just wondering if there was any more thought given to it | 14:20 |
apw | i was considering commiting it if it boots ok | 14:21 |
cnd | I would agree with that | 14:21 |
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:23 |
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:24 |
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:25 |
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:26 |
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:27 |
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:28 |
tgardner | cnd, P.S. since that patch will come post-freeze it'll also have to have an SRU justification. | 14:29 |
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:30 |
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:31 |
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:47 |
JFo | bdmurray, at what 'age' do those patch cases show up in the patch view you showed me? | 14:52 |
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:17 |
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:18 |
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:19 |
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:20 |
bdmurray | okay, thanks I'll look into it later today | 15:21 |
bjf | ** | 15:24 |
bjf | ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting | 15:24 |
bjf | ** | 15:24 |
JFo | bdmurray, np | 15:25 |
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 | 16:16 |
=== fabbione_vac is now known as fabbione | ||
bjf | ## | 17:00 |
bjf | ## Meeting starting now - #ubuntu-meeting | 17:00 |
bjf | ## agenda: https://wiki.ubuntu.com/KernelTeam/Meeting | 17:00 |
bjf | ## | 17:00 |
JFo | bryceh, have you issued a Call for Testing for the DRM stuff that was backported from the .33 kernel? | 17:22 |
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:23 |
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:24 |
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:25 |
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:26 |
manjo | apw, what did you have in mind wrt to suspend resume ? that you think I skipped over ? | 17:27 |
apw | <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:27 |
apw | i was going to say that your patch was in and proving useful | 17:27 |
manjo | ah! thanks | 17:27 |
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:28 |
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:29 |
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:30 |
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:31 |
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:32 |
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:33 |
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:34 |
JFo | will do manjo | 17:35 |
manjo | JFo, thanks a ton | 17:35 |
JFo | my pleasure | 17:35 |
apw | bryceh, what was that tag you added when you needed a kernel fix for a graphics bug? | 17:36 |
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:37 |
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:38 |
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:40 |
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:41 |
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:42 |
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:43 |
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:44 |
bryceh | JFo, sure use your judgment and if in doubt leave the task. I'm pretty aggressive at pruning them though | 17:46 |
JFo | sounds good bryceh | 17:47 |
JFo | thanks | 17:47 |
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:50 |
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 | 17:55 |
=== Hedge|Hog is now known as Hedgehog | ||
=== Hedgehog is now known as Guest22128 | ||
manjo | apw, skype you ? | 18:11 |
apw | sure | 18:11 |
manjo | your offline | 18:12 |
apw | you're | 18:12 |
jono | tgardner, has linux-backports-modules-wireless-lucid-generic now built ready for me to test? | 18:49 |
tgardner | jono, yep | 18:55 |
tgardner | jono, you want linux-backports-modules-2.6.32 (2.6.32-16.7) lucid; urgency=low | 18:56 |
=== kamalmostafa is now known as kamal | ||
cnd | tgardner: is the lbm firmware any different than the linux-image firmware? | 19:23 |
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:25 |
* cnd has a 6050 card, waiting for fw to drop from intel to be able to use it | 19:26 | |
cnd | looks like just 6000 firmware... | 19:29 |
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:30 |
cnd | oh | 19:31 |
cnd | ok | 19:31 |
cnd | let's see, where's the real package... | 19:31 |
cnd | yep, just the 6000 firmware, oh well | 19:32 |
cnd | hmmm... I'm beginning to wonder if cking's arrandale TSC issue isn't arrandale specific... | 20:33 |
tgardner | huh, I have a Radeon Xpress 200M that works pretty well in Lucid | 21:10 |
=== sconklin is now known as sconklin-gone | ||
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:30 |
jjohansen | dyek: what are you trying to load? | 23:32 |
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:34 |
jjohansen | dyek: hrm, i386 or x86_64? | 23:35 |
dyek | jjohansen: CentOS Dom0 is x86_64, but Ubuntu is i386. | 23:36 |
jjohansen | dyek: do you have an initrd, initramfs | 23:36 |
dyek | jjohansen: I know I have initrd -- I copied the entire Ubuntu's /boot directory into Dom0's FS, naming it /boot_ubuntu. | 23:37 |
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:38 |
jjohansen | to be clear this is Dom0 complaining about the 9.10 kernel right? | 23:39 |
dyek | jjohansen: Yes. "xm create" results in the error. | 23:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!