| superm1 | hmm radeon KMS appears to not let my second monitor work | 03:16 |
|---|---|---|
| superm1 | that's a bit annoying | 03:17 |
| tjaalton | superm1: check the new kernel (-16) once it's built | 06:38 |
| tjaalton | and pushed out of NEW | 06:39 |
| superm1 | tjaalton, okay will do | 06:40 |
| tjaalton | it has the drm backport, so that ought to help | 06:47 |
| tjaalton | maybe together with -ati 6.12.191 | 06:47 |
| Sarvatt | yay blob broken once again - FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol 'rcu_lock_map' | 07:04 |
| Sarvatt | they like locking nvidia out some new way every new merge window :) | 07:06 |
| libv | and all they do is alienate nvidia users more | 07:44 |
| superm1 | tseliot, i wanted to ask you what the plan for how remixs/derivatives should be supporting a plymouth theme. the artsy folks for mythbuntu need to have some sort of idea what they should be targeting | 09:12 |
| superm1 | it seems silly to produce a whole new theme with all that logic you have in the .script, so just dropping a logo in place seems more ideal | 09:13 |
| tseliot | superm1: the idea is to make some packages which will introduce a new logo (and maybe change the writings colour and the background colour) and use alternatives to select the theme | 09:14 |
| tseliot | the plan is, of course, to reuse the .script file | 09:14 |
| superm1 | tseliot, ah yeah, that would work swell. so target the same resolution as the logo you ship then currently and things should work fine | 09:15 |
| * tseliot nods | 09:15 | |
| superm1 | okay i'll feed that back to them, thanks! | 09:15 |
| === marienz_ is now known as marienz | ||
| tseliot | np | 09:16 |
| mvo | tjaalton: hi, I just finished debugging a odd upgrade issue from a hardy->lucid upgrade and it turns out that xorg read a really old XCF86Config-4 that wants to load i810. should u-m on upgrade remove/move XF86Config-4 ? | 11:18 |
| tjaalton | mvo: oh yes | 11:23 |
| mvo | :) | 11:24 |
| mvo | ok | 11:24 |
| * mvo will add code after lunch | 11:24 | |
| tjaalton | though it's strange that it would read it, can't find any reference to it | 11:26 |
| tjaalton | from the code | 11:26 |
| tjaalton | hmm ok, found it | 11:31 |
| tjaalton | mvo: or maybe append the name with .obsolete or something | 11:37 |
| tjaalton | instead of removing | 11:37 |
| mvo | tjaalton: ok, I will do that | 11:37 |
| mvo | tjaalton: should I file bugreport about i830 and kernel mode setting failing horrible? or is that HW considered just outdated | 11:38 |
| tjaalton | mvo: I think the plan is to make the kernel use !kms on those | 11:38 |
| tjaalton | while the driver still supports it | 11:38 |
| tjaalton | so the problem should be known already | 11:39 |
| tjaalton | apw: ^^ | 11:39 |
| mvo | tjaalton, apw: ok, thanks. let me know if you need a bugreport about it, i830+kms = blank screen. along the same lines, should "nofb" imply "nomodeset" ? I tried nofb to get a a terminal, but no luck until I discovered nomodeset | 11:40 |
| apw | mvo, i assume that you have this issue with the drm33 backport? | 11:41 |
| mvo | (otherwise I'm pretty happy that the "intel" supports my old i830 chip again with a reasonable speed) | 11:41 |
| apw | and if so then yes we would want a bug on that | 11:41 |
| tjaalton | oh the meta was updated | 11:41 |
| apw | tjaalton, litttery just now | 11:42 |
| tjaalton | yeah :) | 11:42 |
| mvo | apw: this is with whatever is in lucid currently (2.6.32.15.16) | 11:43 |
| tjaalton | so it's still the .32 drm, try with -16 which should be available now | 11:43 |
| mvo | ok | 11:44 |
| * mvo updates | 11:44 | |
| tjaalton | you probably need to install the new kernel manually until the new linux-meta has been published | 11:46 |
| apw | mvo let me know when you have that test result, as if we need to blacklist you you'd be a good test case for the blacklisting support | 12:29 |
| bjsnider | Sarvatt, what is that error supposed to mean? | 12:57 |
| mvo | apw: ok, so: Linux version 2.6.32-16-generic (buildd@rothera) ; fb0: inteldrmfb frame buffer device ; fb1: VGA16 VGA frame buffer device - blank screen both console and X. so -16 does not fix it for me | 13:11 |
| jcristau | ugh. that's wrong. | 13:11 |
| mvo | intel8x0: clocking to 48000 | 13:11 |
| mvo | Console: switching to colour frame buffer device 128x48 | 13:11 |
| jcristau | although maybe fb1 doesn't matter.. | 13:12 |
| mvo | (rebooting with nofb:) nofb is not honored: "fb0: inteldrmfb frame buffer device" | 13:13 |
| mvo | nomodeset makes it happy again | 13:15 |
| apw | mvo does blacklisting vga16fb help any? | 13:19 |
| mvo | apw: give me a minute | 13:19 |
| mvo | bug #534375 - vga16fb I try next, I just did it, but for some reason it loaded it anyway, maybe wrong blacklist file | 13:23 |
| ubottu | Launchpad bug 534375 in linux "blank screen with 2.6.32-16 on intel i830 vga" [Undecided,New] https://launchpad.net/bugs/534375 | 13:23 |
| mvo | apw: no change with blacklisted vga16fb | 14:08 |
| tjaalton | it's probably using a wrong output | 14:08 |
| apw | mvo, thanks ... | 14:08 |
| mvo | tjaalton: interssting, what can I do to control that? | 14:08 |
| tjaalton | if X loads and you can hear the login sound | 14:09 |
| tjaalton | I'm not sure if you can :) | 14:09 |
| mvo | heh :) | 14:09 |
| mvo | ok | 14:09 |
| apw | sounds like we need a bug ... | 14:09 |
| mvo | when i pass "nomodeset" all is fine | 14:09 |
| tjaalton | bug 534375 | 14:09 |
| ubottu | Launchpad bug 534375 in linux "blank screen with 2.6.32-16 on intel i830 vga" [Undecided,New] https://launchpad.net/bugs/534375 | 14:09 |
| * mvo boots again now to run apport-collect | 14:09 | |
| tjaalton | well maybe it just needs a quirk like the ddx driver | 14:10 |
| tjaalton | though you'd think those were ported over | 14:10 |
| mvo | tjaalton: the xf85EdidModes.c stuff in xserver-xorg-core? | 14:18 |
| tjaalton | mvo: no, the ones in -intel | 14:18 |
| tjaalton | I believe there are some for 830 chips | 14:19 |
| Sarvatt | mvo: http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commit;h=7b9c5abee98c54f85bcc04bd4d7ec8d5094c73f4 | 14:20 |
| Sarvatt | its just not in linus' tree yet | 14:20 |
| tjaalton | heh, that's likely the cause | 14:21 |
| Sarvatt | mvo: the symptom in the log is likely the cause he meant, that commit is the fix :) | 14:27 |
| tjaalton | right :) | 14:31 |
| bjsnider | tseliot, what does jockey mean by saying that nvidia-current is activated but not in use? | 14:35 |
| tseliot | bjsnider: maybe that the module is not loaded but the package is installed | 14:36 |
| bjsnider | the nvidia driver is loaded | 14:38 |
| bjsnider | this guy's system is seriously pooched | 14:38 |
| bjsnider | nouveau and vesa are not loaded | 14:38 |
| Sarvatt | probably no nvidia xorg.conf in that state | 14:40 |
| Sarvatt | if its like my machine when i get in that state :) | 14:41 |
| bjsnider | we'll see | 14:41 |
| tjaalton | I need to find out why nvidia dkms fails to build here ("make[1]: Makefile: No such file or directory") | 14:41 |
| Sarvatt | bjsnider: that error from earlier was because they exported a symbol as GPL only in the 2.6.34 kernel so the nvidia module cant use it, sorry missed the question | 14:42 |
| bjsnider | Sarvatt, i don't even know how to respond to that | 14:43 |
| bjsnider | what possible justification could there be for doing such a thing? how could that possibly help anything? | 14:47 |
| tjaalton | Sarvatt: where did you get that error? | 14:50 |
| tjaalton | this thread? http://www.nvnews.net/vbulletin/showthread.php?p=2203489 | 14:50 |
| mvo | Sarvatt: thanksf for the git link, I'm building a updated kernel now to see if that fixes the problem (will take a while, this is a old machine :) | 14:52 |
| Sarvatt | yeah and it was this commit http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f5f654096487c6d526c47bb66308f9de81f091cf | 14:52 |
| bjsnider | whose code is it? | 14:53 |
| Sarvatt | actually, ya can try a drm-intel-next kernel from the mainline-ppa | 14:53 |
| Sarvatt | that commit should be in this one mvo - http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/current/ | 14:54 |
| mvo | Sarvatt: cool, downloading now | 14:56 |
| Sarvatt | i've made 6 bad lid state quirks this past week for people, getting to be a really common problem and I think I convinced the intel guys to add the ignore acpi lid state module option patch upstream eventually so things are at least usable without recompiling a kernel when UMS userland isn't around | 15:00 |
| Sarvatt | we're sticking with 2.9.1 it looks like but we still have it set to KMS only with a configure flag at build time | 15:00 |
| Sarvatt | probably better off using vesa any which is what happens with nomodeset anyway on that 830 though :) | 15:01 |
| mvo | Sarvatt: no change (with the intrl-drm-next) kernel. well, right. I don't mind how the problem is fixed, I just don't like the regression on lts->lts upgrade, especially since even "recovery mode" will result in this blank screen so a normal (even a technical) user will have a hard time with the bug | 15:05 |
| mvo | (also of course this hardware is pretty dated by now) | 15:06 |
| zniavre | good afternoon im alwais experienced some nvidia-173 worrie with nvidia-settings it works but there some bugs quite annoying, am i to the good place to ask ? | 15:09 |
| zniavre | http://dl.dropbox.com/u/187396/screenshot4.png | 15:09 |
| zniavre | always* | 15:10 |
| zniavre | i filed a bug report few weeks ago about the same bug , i did what the mainteners ask but it did not solved the nvidia-settings bug | 15:11 |
| zniavre | what should i do ? | 15:11 |
| Alice_32 | hi does anyone know if is there any chance to get ati card work in lucid>? at the moment im using open source driver and the problem is that it use 50% of my cpu and the catalyst driver doesnt work at all any advice, help? | 15:51 |
| Sarvatt | Alice_32: try adding radeon.modeset=0 to your kernel command line | 16:05 |
| diverse_izzue | i have trouble with external screens on lucid since kernel -15. kernel -15 didn't boot at all with an external screen connected, kernel -16 boots, but i have a very jittery image. i had seen the same behaviour under karmic if i ran it with a 2.6.33 kernel. | 16:06 |
| Sarvatt | hmm so nvidia-settings isn't really backwards compatable at the moment? | 16:13 |
| Sarvatt | perhaps that calls for a nvidia-settings-173 and such | 16:13 |
| diverse_izzue | Sarvatt, ^^, any idea how to debug? | 16:14 |
| tseliot | there is only one nvidia-settings in Ubuntu | 16:22 |
| Sarvatt | yeah it doesnt work with 173 apparently from zniavre's comments earlier | 16:23 |
| Sarvatt | if it fails to query some extensions the older driver doesnt support its not showing the configuration panel for that section at all it looks like | 16:24 |
| Sarvatt | I wonder if we're hitting this in any of our nvidia bugs - http://www.nvnews.net/vbulletin/showthread.php?t=148652 | 16:27 |
| tseliot | Sarvatt: do we have a bug report about it? | 16:28 |
| Sarvatt | especially now that we just reenabled RENDER | 16:29 |
| Sarvatt | i dont know, its the type of bug you need to manually check the xorg log to see if an extension was silently not getting enabled | 16:29 |
| tjaalton | n-s is open source, so it's fixable | 16:31 |
| apw | is it possible to tell under X whether you are running using the emergency fallback X server? | 16:51 |
| tseliot | apw: maybe gdm keeps track of this in its logs? | 16:52 |
| tseliot | bryceh should know more about this | 16:53 |
| apw | tseliot, it seems like something we should get reported by apport if we can tell | 16:53 |
| cnd | bryceh: what's the plan for nvidia 195 drivers? | 17:04 |
| tseliot | apw: that's a good idea | 17:04 |
| tseliot | cnd: we're waiting for news from Nvidia | 17:04 |
| cnd | there's a suspend/resume bug that is present in 195, but not 190 | 17:05 |
| cnd | tseliot: is there an eta on that? | 17:06 |
| tseliot | cnd: are you sure that it doesn't depend on the combination kernel/driver? | 17:06 |
| cnd | tseliot: the resume bug occurs on the new .33 drm kernel with 195 | 17:07 |
| cnd | I think any other combo is ok | 17:07 |
| tjaalton | the blob doesn't use drm at all | 17:09 |
| cnd | tjaalton: yes, but it still seems to cause issues | 17:13 |
| tjaalton | cnd: what about mainline 2.6.33? | 17:23 |
| tjaalton | cnd: what about mainline 2.6.33? | 17:26 |
| Sarvatt | cnd: so it works fine with -15 and not with -16, you're sure of that and can reproduce it? | 17:45 |
| bryceh | apw, well it's invoked with an option to use xorg.conf.failsafe and Xorg.failsafe.log, so easy thing would be to look at ps and see if a command with those options is present | 17:46 |
| === artir_ is now known as artir | ||
| cnd | I just installed the nvidia-current package, but xorg.conf wasn't generated | 18:10 |
| cnd | how can I generate it? | 18:10 |
| cnd | (this is on lucid) | 18:10 |
| jcristau | $EDITOR | 18:12 |
| cnd | jcristau: ummm... yeah, I've already done that route, but I don't know what the values should be now | 18:13 |
| cnd | is driver still nvidia or nvidia-current | 18:13 |
| cnd | neither seems to work for me | 18:13 |
| bjsnider | jockey will generate it for you | 18:13 |
| cnd | bjsnider: is there a way to invoke that from tty? | 18:14 |
| cnd | or do I need to use vesa to get into X to start jockey? | 18:14 |
| bjsnider | vesa i assume | 18:14 |
| cnd | ahhh, looks like jockey-text may work | 18:14 |
| cnd | yep, jockey-text -e xorg:nvidia_current did the trick | 18:16 |
| === radoe_ is now known as radoe | ||
| Sarvatt | ack, tickets to brussels for UDS are crazy | 18:30 |
| Sarvatt | http://sourceforge.net/mailarchive/forum.php?thread_name=1268030255-13422-1-git-send-email-airlied@gmail.com&forum_name=dri-devel \o/ \o/ | 18:31 |
| apw | bryceh, thanks | 18:53 |
| Sarvatt | hmm, thinking about redoing ppa-purge as a graphical utility, anyone have any recommendations on where a good place to hook it into an existing package would be instead of making it a standalone app? | 19:11 |
| bryceh | Sarvatt, yeah in fact I was thinking of this yesterday | 19:11 |
| bryceh | there exists a utility add-apt-repository (installed by default I think??) | 19:12 |
| bryceh | I was thinking, "Sarvatt's ppa-purge is sort of like rm-apt-repository - I wish it was included in whatever provides a-a-r" | 19:12 |
| Sarvatt | hmmm | 19:17 |
| Sarvatt | checking out software-properties now | 19:18 |
| Sarvatt | if anyone is using nouveau on edgers - I'm uploading a lbm-nouveau and it needed alot of work readding nouveau back to it, can ya tell me if it works with the -16 kernel? keep in mind you'll need to blacklist nouveau manually at the moment until I fix that | 20:10 |
| mvo | bryceh: that sounds like a good idea (to include rm-apt-repository) | 20:33 |
| mvo | Sarvatt: you have a working script for this already (purge-ppa?) | 20:33 |
| bryceh | mvo, yeah we've been using it in xorg-edgers for some time now (but it should work well with any arbitrary repo) | 20:33 |
| mvo | cool | 20:34 |
| mvo | where can I find it? | 20:34 |
| mvo | oh, I have it already | 20:34 |
| * mvo looks closer | 20:34 | |
| bryceh | yeah... https://edge.launchpad.net/~xorg-edgers/+archive/ppa/+files/ppa-purge_0.2.6.dsc | 20:35 |
| Sarvatt | https://edge.launchpad.net/ppa-purge | 20:35 |
| mvo | nice (and a nice idea) | 20:35 |
| mvo | I put it on my todo list, I'm about to leave for today (but couldn't resist looking at it :) | 20:35 |
| bryceh | :-) | 20:36 |
| * mvo waves | 20:38 | |
| RAOF | bryceh: In ubuntu-x? | 21:44 |
| bryceh | sure | 21:44 |
| RAOF | Would seem a little bit more on-topic :) | 21:44 |
| bryceh | the kernel freeze is coming up thursday | 21:44 |
| bryceh | apw is uploading the kernel for that tomorrow morning his time | 21:44 |
| bryceh | he wanted to know what to do about the nouveau api bump this go around | 21:44 |
| RAOF | I think we sit on the current api. | 21:45 |
| tjaalton | upstream is going to stabilize it during the next two months, and call the result 1.0.0 | 21:46 |
| RAOF | Right, that too. | 21:46 |
| bryceh | by current api do you mean not the new api? | 21:46 |
| RAOF | And by “stabilize” they mean “break it again until they're reasonably happy with it”. | 21:46 |
| RAOF | By current api I mean the api we have in lucid at the moment; the 0.0.15 api. | 21:46 |
| bryceh | ok good | 21:46 |
| RAOF | 0.0.16 looks like it'll be broken within 2 months anyway. | 21:47 |
| bryceh | for lack of better info, that's essentially what apw and I decided to do for now | 21:47 |
| bryceh | if we wish to change it, it could be changed post-beta1, given archive admin blessing | 21:47 |
| RAOF | I don't think we'll want to, but good to know. | 21:48 |
| Sarvatt | pretty much guaranteed to be at least 2 api breaks between now and what alot of the devs want to be in 1.0.0, seems pretty solid that they need more than 0.0.16 for 1.0.0 because they are working out how to stabilize it in a way thats compatable with the memory manager rewrite in the ~1 year from now timeframe | 21:52 |
| bjsnider | Sarvatt, you're talking about nouveau? | 21:55 |
| Sarvatt | theres also the issue of them putting nouveau_class.h into libdrm for some reason but thats not that big of a deal since lucid wont have mesa support. | 21:55 |
| Sarvatt | yep | 21:56 |
| bjsnider | linus ain't gonna like that | 21:56 |
| Sarvatt | nope :) | 21:56 |
| Sarvatt | but it looks like by then there will be a generic KMS fallback to guard against these things so you can at least get into X | 21:57 |
| RAOF | Well, you can do that now, can't you? We should be falling back on fbdev to get to X. | 21:57 |
| RAOF | (And it worked for me, last time I tried it) | 21:58 |
| bryceh | ok yeah this all sounds good to me. obviously we can't chase upstream forever so if the 16 api isn't likely to be The One, let's not knock ourselves out trying to get it. | 22:00 |
| bryceh | if that limits our backporting abilities, well such is life | 22:00 |
| apw | bryceh, ... that sounds like a sound position | 22:00 |
| bryceh | apw, right on cue :-) | 22:00 |
| bryceh | ok sounds like we're decided then | 22:01 |
| Landswellsong | Guys, sorry for storming in, does anybody knows if Xorg ubuntu's team accept part time job applications? | 22:01 |
| tjaalton | Sarvatt: what do I need to get just the nouveau gallium for lucid? rebuild mesa 7.8 from edgers? | 22:03 |
| bryceh | Landswellsong, if you mean canonical, no not to my knowledge | 22:03 |
| Landswellsong | bryceh: yep them. so it's fulltime-only? | 22:04 |
| bryceh | Landswellsong, *nod* | 22:04 |
| Sarvatt | RAOF: afaik if you boot with 0.0.16 api, have libdrm 0.0.15, have nouveau installed compiled against 0.0.15, nouveau is going to try to claim it and fail because of the drm vs things just working in slow mode in the future | 22:04 |
| bryceh | Landswellsong, ask canonical hr for a definitive answer; probably depends a bit on the role in question | 22:05 |
| Sarvatt | tjaalton: ya need libdrm nouveau a .34 kernel *and* mesa | 22:05 |
| Landswellsong | bryceh: are they present on IRC? | 22:05 |
| bryceh | Landswellsong, don't think so | 22:06 |
| tjaalton | Sarvatt: oh, because of the api bump? | 22:06 |
| Sarvatt | yup | 22:06 |
| tjaalton | duh | 22:06 |
| Landswellsong | bryceh: thanks a lot | 22:06 |
| Sarvatt | i put lbm-nouveau with the api bump in the PPA, for now you can just manually blacklist nouveau/rebuild initramfs | 22:06 |
| Sarvatt | need to update the ddx in edgers now and add a modprobe conf to blacklist nouveau to it | 22:07 |
| Sarvatt | hmm wonder if i should blacklist drm/ttm/drm_kms_helper too | 22:10 |
| Sarvatt | naah shouldn't need to, lbm-nouveau should only load the lbm- renamed ones | 22:10 |
| BUGabundo | o/ | 22:13 |
| === rye is now known as rye[fixing-x] | ||
| rye[fixing-x] | hello | 22:21 |
| BUGabundo | hey rye[fixing-x] | 22:21 |
| rye[fixing-x] | after the latest update I am unable to start my X | 22:22 |
| rye[fixing-x] | here's the dmesg - http://paste.ubuntu.com/391310/ | 22:22 |
| rye[fixing-x] | the first item is that plymouth does not start, afterwards the X session looks extremely strange - green bars only | 22:23 |
| rye[fixing-x] | as I understand, there was some change to make nouveau driver the default | 22:24 |
| rye[fixing-x] | so I went forward and purged my nvidia modules to make it as clean as possible, and moved xorg.conf to a backup file | 22:25 |
| rye[fixing-x] | after this I can see the green bars (previously the screen was shutting down along with the backlight) | 22:26 |
| * rye[fixing-x] finished my sad story | 22:26 | |
| rye[fixing-x] | BUGabundo, are there some related reports of this? | 22:26 |
| BUGabundo | rye[fixing-x]: what distro, version , gpu, and drivers? | 22:27 |
| BUGabundo | cause if it is lucid with nvidia, just purge plymouth | 22:27 |
| rye[fixing-x] | BUGabundo, lucid, nvidia, nouveau drivers (I believe) | 22:29 |
| rye[fixing-x] | BUGabundo, so I need to purge plymouth or I can remove splash from boot params? | 22:29 |
| BUGabundo | purge it | 22:31 |
| Sarvatt | RAOF: this look right? http://pastebin.com/eiA2GkC2 | 22:32 |
| Sarvatt | and http://pastebin.com/drMm5vVs | 22:33 |
| Sarvatt | -16 kernel is in btw, dont we have to remove the lbm dep on the ddx now? | 22:36 |
| Sarvatt | going to just have a hard dep on the versioned lbm in edgers I guess | 22:37 |
| rye[fixing-x] | no compiz in nouveau, right? | 22:42 |
| rye[fixing-x] | BUGabundo, btw, thanks. Removed plymouth and got X back | 22:42 |
| BUGabundo | cool | 22:42 |
| BUGabundo | you can have 3D with nouveau | 22:42 |
| BUGabundo | with the version in xodger ppa | 22:42 |
| === rickspencer3__ is now known as rickspencer3 | ||
| RAOF | Sarvatt: Yeah, once the -16 kernel is in, pointed at by linux-meta, and mirrored we can drop the lbm dep. | 22:49 |
| Sarvatt | its in already, i got it this morning | 22:53 |
| Sarvatt | unless that was a new ppa one and i didnt notice.. | 22:53 |
| Sarvatt | oops, postrm had an error in it, silly mistake | 22:54 |
| Sarvatt | ok new ddx uploaded to edgers with the blacklist changes and such | 22:54 |
| Sarvatt | both of my nvidia laptops are in use so i cant test any of this out :( | 22:56 |
| Sarvatt | btw it might be good to get the word out about the ignorelid module option on nouveau for people having black screen after boot problems | 22:59 |
| Sarvatt | on laptops | 23:00 |
| BUGabundo | like me ? | 23:01 |
| Sarvatt | if you're having that problem with nouveau yeah | 23:02 |
| rye[fixing-x] | Sarvatt, and me | 23:03 |
| Sarvatt | boot with nouveau.ignorelid=1 with the 2.6.32-16 kernel, or lbm-nouveau.ignorelid=1 with xorg-edgers PPA | 23:03 |
| rye[fixing-x] | Sarvatt, additionally, the VTs were unusable so if I had no other laptop then it would take a while to understand what to blame... | 23:03 |
| Sarvatt | if it fixes it for you file a bug with dmesg and dmidecode output, subscribe me to it and i'll upstream a quirk for your machine | 23:04 |
| rye[fixing-x] | Sarvatt, I got X back when I purged the plymouth, as BUGabundo suggested | 23:06 |
| Sarvatt | alrighty, that wasnt the problem then | 23:06 |
| rye[fixing-x] | Sarvatt, are lid detection and plymouth connected? | 23:06 |
| Sarvatt | nah plymouth has lots of issues right now and its not strange to have it boot up to a blank screen sometimes :D | 23:07 |
| rye[fixing-x] | Sarvatt, are there any public announcement that will make sure people with nVidia hw will know that they will not have 3d in Lucid ? | 23:08 |
| rye[fixing-x] | including compiz? | 23:08 |
| Sarvatt | darnit, looks like I screwed up the lbm-nouveau packaging | 23:09 |
| RAOF | rye[fixing-x]: No, but that's because it's the status-quo. | 23:09 |
| Sarvatt | ahhh darnit, control.stub.in overwrote the control.stub | 23:10 |
| RAOF | rye[fixing-x]: We're expecting users who want 3D to install the proprietary nvidia drivers, just like they do today. Nouveau is being used as a better -nv. | 23:10 |
| Sarvatt | no nouveau for edgers till tomorrow, dont have time to rewrite the control a third time | 23:10 |
| rye[fixing-x] | RAOF, so if I got my X broken with the latest upgrades then it was not really intended? | 23:11 |
| RAOF | If you got your X broken with the lates upgrades, I'd like you to file a bug! | 23:12 |
| rye[fixing-x] | RAOF, here's what I got after reboot- http://paste.ubuntu.com/391310/ | 23:13 |
| Sarvatt | hmm, not sure what i need to do to make sure the nouveau stuff i add to control and control.stub persists after building the source package.. | 23:13 |
| rye[fixing-x] | omg... ACPI Warning: _BQC returned an invalid level (20090903/video-631) - not again.... regression in kernel.. | 23:13 |
| RAOF | Sarvatt: You're after control.stub.in and control.d/flavour-something-or-other | 23:14 |
| Sarvatt | your bios is screwed up, probably designed for windows only like most HP's | 23:14 |
| rye[fixing-x] | Sarvatt, no, I had this fixed in Karmic, there was a bug in the kernel leading to missing backlight support | 23:15 |
| Sarvatt | do you have a platform driver to handle backlight for your machine? | 23:16 |
| rye[fixing-x] | Sarvatt, but backlight is working now... | 23:16 |
| rye[fixing-x] | omg. | 23:16 |
| Sarvatt | like thinkpad-acpi or something | 23:17 |
| rye[fixing-x] | Ok, I will try to restore my system to previous state, reproduce the actual failure with nvidia drivers and report if that is reproducible | 23:17 |
| Sarvatt | its just a warning, if you have a platform driver handling backlight controls anyway it should be fine | 23:17 |
| Sarvatt | RAOF: hmm control.stub.in only has 2 packages in it | 23:19 |
| rye[fixing-x] | Sarvatt, frankly speaking, i don't remember the details - bug 428910. Ok, restoring proprietary nvidia drivers | 23:20 |
| ubottu | Launchpad bug 428910 in linux "Acer Aspire 5520 has backlight broken in Karmic Koala" [Medium,Fix released] https://launchpad.net/bugs/428910 | 23:20 |
| Sarvatt | ahah control.d/flavour-control.stub | 23:20 |
| Sarvatt | comment #5 in that bug explains the problem pretty clearly | 23:21 |
| Sarvatt | hmm did tseliot remove the nouveau blacklist from nvidia-current and replace it with lbm-nouveau? | 23:23 |
| RAOF | I thought both were blacklisted. | 23:25 |
| RAOF | That could cause some consternation if so! | 23:25 |
| Sarvatt | hmm I see it in /etc/modprobe.d/nvidia-graphics-drivers.conf | 23:26 |
| Sarvatt | https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/534469 | 23:26 |
| ubottu | Launchpad bug 534469 in nvidia-graphics-drivers "Failed To Load NVIDIA 195.36.08 Kernel modules" [Undecided,New] | 23:26 |
| Sarvatt | its not blacklisted for that person | 23:26 |
| rye[fixing-x] | Sarvatt, are you talking about my case? | 23:29 |
| Sarvatt | no | 23:29 |
| rye[fixing-x] | Sarvatt, i see that something cannot open nvidia-graphics-drivers.conf on boot, btw | 23:30 |
| Sarvatt | really? | 23:31 |
| rye[fixing-x] | Sarvatt, yes, but the symlink is actually present | 23:31 |
| Sarvatt | ugh, dont tell me that update-initramfs doesn't pack .conf's that are links in the initrd | 23:31 |
| rye[fixing-x] | Sarvatt, will unpack the initrd now... | 23:32 |
| Sarvatt | that'd mean all blob users are broken with the -16 kernel right now | 23:32 |
| RAOF | Sarvatt: Yeah. Are you investigating, or shall I? | 23:33 |
| RAOF | Sarvatt: That's the sort of OMG bug that warrants a bit of attention :) | 23:33 |
| Sarvatt | it's in my 2.6.32-15 initrd | 23:34 |
| Sarvatt | so thats not the problem at least | 23:34 |
| rye[fixing-x] | Sarvatt, nvidia-graphics-drivers is a symlink to /etc/alternatives symlink that links to /usr/lib/nvidia-current/modprobe.conf | 23:35 |
| * rye[fixing-x] is decompressing my initrd... | 23:36 | |
| Sarvatt | yep, i was just worried it wasn't packing symlinks into the initrd but it is | 23:36 |
| rye[fixing-x] | Sarvatt, but is it going that deep ? | 23:36 |
| Sarvatt | its not a symlink in the initrd | 23:37 |
| rye[fixing-x] | true | 23:38 |
| Sarvatt | upgrading this machine to -16 now to see if theres anything screwy there | 23:39 |
| rye[fixing-x] | Sarvatt, I get 'Failed to open config file nvidia-graphics-drivers.conf: No such file or directory' | 23:43 |
| Sarvatt | where? | 23:43 |
| rye[fixing-x] | don't see the path though :-/ | 23:43 |
| Sarvatt | you get that during boot? | 23:44 |
| rye[fixing-x] | during the boot procedure right after fsck finishes checking the drives | 23:44 |
| rye[fixing-x] | hm... actually during fsck checks the drives... | 23:44 |
| Sarvatt | ok thats not good.. | 23:45 |
| RAOF | Sing out if you'd like some help. | 23:45 |
| bjsnider | RAOF is just itching to get in on this one | 23:46 |
| rye[fixing-x] | I might have not noticed it earlier because there were no nouveau drivers that could grab the hw w/o the blacklist rules, right? | 23:47 |
| * RAOF will be very happy to let Sarvatt handle it while RAOF fixes f-spot mem leaks. | 23:47 | |
| Sarvatt | there was though, lbm-nouveau but it wasn't in the same directory as the other drivers so it probably got checked to load | 23:47 |
| Sarvatt | I don't know whats up RAOF | 23:47 |
| Sarvatt | my nvidia box didn't survive a reboot and i'm not at home with it :( | 23:48 |
| rye[fixing-x] | Sarvatt, sorry about that :( | 23:49 |
| Sarvatt | checked to load after it tried to load nvidia | 23:49 |
| Sarvatt | I meant* | 23:49 |
| RAOF | Ok. I'll have a look. | 23:50 |
| rye[fixing-x] | hm, if that is in initrd... no, fsck is not finished, so ... | 23:50 |
| rye[fixing-x] | hm | 23:51 |
| rye[fixing-x] | I have /usr on a separate partition. Assuming that / gets mounted early, with /etc having modprobe symlink pointing to not-yet-existing /usr... | 23:52 |
| Sarvatt | changing nvidia-* to install seperate .conf's instead of an alternative is probably what needs to be done | 23:52 |
| RAOF | rye[fixing-x]: That's a good thought; we (try to) support /usr on a separate partition, but it's not exactly a common configuration. | 23:54 |
| rye[fixing-x] | Sarvatt, let me remove the symlink and make it a proper file... | 23:54 |
| Sarvatt | rye[fixing-x]: when you extract your initrd the etc/modprobe.d/nvidia-whatever.conf has the right contents in it? | 23:54 |
| Sarvatt | gzip -dc < /boot/initrd.img-2.6.32-16-generic | cpio -i | 23:55 |
| rye[fixing-x] | Sarvatt, yes, the initrd has a regular file, not a symlink | 23:55 |
| Sarvatt | will extract it to the current directory | 23:55 |
| * rye[fixing-x] reboots the nVidia box with symlink on the root fs replaced with a normal file | 23:57 | |
| rye[fixing-x] | Sarvatt, and it workeds | 23:57 |
| Sarvatt | you should be able to just manually add a /etc/modprobe.d/blacklist-nouveau.conf with blacklist nouveau in it, sudo update-initramfs -u then reboot to see if that works where the symlink doesnt | 23:57 |
| rye[fixing-x] | *worked | 23:57 |
| Sarvatt | ah | 23:58 |
| rye[fixing-x] | Sarvatt, so that means that everyone with /usr on a separate partition will have such issue with -16 | 23:58 |
| rye[fixing-x] | Sarvatt, but I still can't understand why it uses the live /, not initrd one :-/ | 23:58 |
| Sarvatt | possibly even without /usr seperate which is the worrying thing :( | 23:58 |
| Sarvatt | if /usr is on / and / is getting fscked.. | 23:59 |
| RAOF | I'm rebooting now to check. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
