[00:59] <bryceh> morning RAOF
[00:59] <RAOF> bryceh: Good morning!
[01:04] <bjsnider> it is not the morning
[01:05] <RAOF> Not anymore, no.
[12:51] <jdub> hey gang
[12:51] <jdub> i'm poking around in launchpad to see if a bug is already filed about this
[12:52] <jdub> my i965 isn't getting hardware gl love
[12:52] <jdub> a bit of apparently salient info:
[12:52] <jdub> $ LIBGL_DEBUG=verbose glxinfo 2>&1 | grep error
[12:52] <jdub> libGL error: dlopen /usr/lib/dri/i965_dri.so failed (/usr/lib/dri/i965_dri.so: undefined symbol: _mesa_meta_clear)
[12:52] <jdub> libGL error: unable to load driver: i965_dri.so
[12:52] <jdub> libGL error: driver pointer missing
[12:52] <jdub>  
[12:53] <jdub> hmm
[12:53] <jdub> think i may have figured it out
[12:54] <jdub> yay, looks like i had some evil meta debs from elsewhere installed
[12:55] <jdub> thanks for providing the counselling couch
[12:55] <jdub> ;)
[16:32] <stefanlsd> heys! really appreciate the nouveau drivers in lucid, but need the propietry drivers for some stuff. cant load it since it seems the frame buffer takes ownership of the device and nvidia-current module says no device found. cant find any documentation on how to disable it, any ideas pls?
[16:35] <stefanlsd> best way i've found for now is to boot -15 kernel, which isnt great :)
[16:36] <jcristau> stefanlsd: echo blacklist nouveau > /etc/modprobe.d/nvidia.conf
[16:36] <jcristau> then update-initramfs
[16:38] <stefanlsd> jcristau: thanks. will give it a try!
[16:39] <tseliot> jcristau, stefanlsd: my packages already do that
[16:40] <johanbr> stefanlsd, removing plymouth and/or booting without the "splash" kernel option may also help
[16:41] <stefanlsd> tseliot: is you package new, cause i just noticed i already have it black listed in there, and about 10 minutes ago i just ran the system / hardware drivers and enabled nvidia
[16:41] <stefanlsd> johanbr: removed splash doesnt, help, can try remove plymouth
[16:41] <tseliot> stefanlsd: no, it's not new. Did you reboot?
[16:44] <bjsnider> it was new 2 months ago
[16:44] <stefanlsd> tseliot: yeah, every day :)  relevant part of dmesg in pastebin   http://pastebin.ubuntu.com/393390/
[16:45] <tseliot> stefanlsd: I mean, after installing nvidia
[16:45] <stefanlsd> tseliot: doesnt seem like it removes it in the initrd. but yeah, i've always had nvidia installed. im gonna reboot right now just to confirm, brb
[16:46] <bjsnider> i wonder what jockey says is going on in his case
[16:48] <Sarvatt> yeah it puts all the gpu stuff in the initrd by default just incase its needed, the nvidia package adds a nouveau blacklist but i've seen 2 reports where that blacklist wasn't working for some reason since non-lbm nouveau went in. in one case it was because /usr was on a seperate partition that was getting fscked so it couldn't follow the symlink in /etc/modprobe.d/
[16:48] <Sarvatt> tseliot: i was going to ask you about that, would it be a better idea to just put a versioned .conf in /etc/modprobe.d/ instead of making it an alternative?
[16:49] <tseliot> Sarvatt: what do you mean by "versioned .conf"?
[16:50] <Sarvatt> like nvidia-current.conf nvidia-173.conf nvidia-96.conf
[16:50] <tseliot> also, we could put it somewhere in /lib perhaps?
[16:50] <stefanlsd> tseliot: hi, back, still doesnt work
[16:50] <stefanlsd> tseliot: interesting what you said about above
[16:51] <tseliot> Sarvatt: those files would conflict with each other
[16:51] <tseliot> stefanlsd: do you have /usr on a separate partition?
[16:51] <stefanlsd> tseliot: i have a problem booting, it seems random. 1/2 boots it is unable to mount my /usr partition
[16:51] <stefanlsd> i hard power down my laptop, and power up, and then it finds it
[16:51] <tseliot> hmm..
[16:52] <bjsnider> stefanlsd, so /usr on your system is on its own partition?
[16:52] <stefanlsd> tseliot: yeah, /usr /home /var /tmp / on seperate partitions
[16:52] <tseliot> ok
[16:53] <Sarvatt> just seems racy with the mounts not being available all the time for people with oddball partition layouts
[16:53] <bjsnider> i wonder if there's an open bug regarding not being able to find separate partitions
[16:54] <Sarvatt> ah i was thinking nvidia-173 and such werent parallel installable with nvidia-current
[16:54] <stefanlsd> been wanting to debug why for some reason it doesnt see my /usr partition for a while now. seems like some race issue
[16:54] <tseliot> Sarvatt: using /lib instead of /usr/lib would fix it
[16:54] <Sarvatt> mountall is where you want to look
[16:55] <bjsnider> maybe his fstab is broken
[16:55] <bjsnider> or old or something
[16:56] <Sarvatt> stefanlsd: try changing /etc/init/udev.conf to require local-filesystems to start
[16:58] <Sarvatt> not sure if thats the right way but things are starting too parallel for you with the oddball partition setup, it's expecting a standard layout
[16:59] <stefanlsd> Sarvatt: whats the syntax for the udev.conf file for require?   I just put "require local-filesystems"  under the start line?    hehe, its not that oddball btw :)
[17:00] <bjsnider> sure it is
[17:00] <jcristau> no
[17:00] <jcristau> pretty standard actually
[17:00] <bjsnider> ok
[17:00] <Sarvatt> i dont think its oddball either but theres alot of issues with upstart and non standard layouts
[17:00] <bjsnider> i forgot that's how the ubuntu installer lays things out every time
[17:00] <jcristau> (more so 10 years ago than now, but well)
[17:01] <stefanlsd> but yeah, seems like a few bug reports for things expecting stuff in /usr and /usr not being available (specifically /usr/lib)
[17:01] <Sarvatt> hmm I'm not sure udev would be the place to put it actually stefanlsd..
[17:05] <Sarvatt> try start on virtual-filesystems and local-filesystems though in /etc/init/udev.conf and hopefully that wont wreck your machine :) i believe you need to update-initramfs -u after you change it
[17:07] <Sarvatt> it'll probably add quite a bit of time to your boot time, the racyness is a fallout from all of this boot speed work :(
[17:07] <stefanlsd> Sarvatt: kk. thanks. gonna reboot and check :)
[17:07] <stefanlsd> brb (hopefully)
[17:13] <stefanlsd> mm, back. 
[17:13] <stefanlsd> soo, the blacklisting worked now...
[17:13] <stefanlsd> although the system feels very slow... everything sluggish. not sure if its just me
[17:16] <stefanlsd> what happened to glxinfo
[17:16] <stefanlsd> im pretty sure this isnt accelerated
[17:16] <stefanlsd> aah yeah, /proc/nvidia doesnt exist
[17:18] <stefanlsd> prob X config now. gonna try reconfig. nvidia kernel module is loading
[17:27] <stefanlsd> Sarvatt: ok thanks. its working now
[17:27] <stefanlsd> so i guess for the record, blacklisting with a seperate /usr partition isnt working
[17:56] <tjaalton> just like ureadahead doesn't work with separate /var partition
[17:56] <tjaalton> I'm down to just having /tmp and /boot separate, need to disable /var/tmp somehow so people can't fill root with it
[17:57] <tjaalton> like link it to /tmp
[18:12] <stefanlsd> tjaalton: aah ok. i've seen that ureadahead does give errors on mine also
[18:15] <tseliot> stefanlsd: can you file a bug report about blacklisting while using separate partitions, please?
[18:27] <stefanlsd> tseliot: will do, any suggestions on package?
[18:28] <tseliot> stefanlsd: nvidia-graphics-drivers would be fine
[18:28] <tseliot> thanks
[19:38] <djr13> i'm getting gpu lockups under nouveau with an nv18 card
[19:39] <djr13> ...any ideas/things to check?
[19:41] <djr13> getting gpu lockups/X freezing under multiple kernels, Xorg versions/nouveau versions
[19:48] <Sarvatt> bryceh: sent you an email with a ton of ideas regarding X specific UDS discussion points. basically things such as gallium implementation, extending synaptics device settings that are missing to the GUI (like corner button settings and tap button assignment), xserver 1.8 migration pains like xorg.conf.d and the new abi's, libkms that plymouth will most likely depend on, and issues we've seen with KMS migration such as backlight control
[19:49] <bryceh> Sarvatt, ok great thanks, I'll take a look
[19:49] <tseliot> Sarvatt: "synaptics device settings" - good point, it reminds me of what I haven't had the time to work on, among other things ;)
[19:50]  * bryceh just got retasked to focus on multitouch support for a while
[19:51]  * tseliot whistles
[19:52] <Sarvatt> thats a rough one
[19:54] <Sarvatt> going to need quite a number of kernel patches for starters to handle the touchscreen support for the more common devices (n-trig?)
[19:56] <bryceh> Sarvatt, yep
[19:56] <djr13> anyone: what could i do to find the cause of gpu lockups in nouveau...only happens with nv18...
[19:57] <bryceh> djr13, speak with RAOF
[19:58] <djr13> bryceh: eh? thanks, i'll see what they say
[19:59] <Sarvatt> file a bug for starters, need alot of logs to help you troubleshoot it :)
[20:01] <Sarvatt> ubuntu-bug xorg from a terminal, and subscribe RAOF and Sarvatt to it
[20:01] <diverse_izzue> since kernel -15 i have trouble with radeon kms and external screens. is that known, and that to do about it?
[20:01] <bryceh> diverse_izzue, look in launchpad to see if it's a known issue
[20:01] <djr13> Sarvatt: you mean me? :) yeah I thought of that...i can't quite find it in any log so far....and thanks also...couldn't recall how to file bugs :-/
[20:02] <diverse_izzue> bryceh, i should search for the component "linux"?
[20:02] <bryceh> diverse_izzue, process is file a bug if there isn't one already, see http://wiki.ubuntu.com/X/Troubleshooting for some techniques to debug the type of problem, forward the bug upstream to bugs.freedesktop.org and make a bug link, and work with upstream towards a fix
[20:02] <Sarvatt> gotta work and purposefully leaving the laptop at home this time so I wont be able to look at it until tonight though
[20:02] <bryceh> diverse_izzue, once there's a fix, the patch will need backported to lucid, and then integrated to our packaging
[20:04] <diverse_izzue> bryceh, i had the same issue with the vanilla 2.6.33 kernel, but not the 2.6.32 one
[20:04] <bryceh> diverse_izzue, I don't know if anyone on the developer end of things will have time to help on your bug so the more of that process you can do, the easier it'll make it and more likely it'll be to looked at.  If you think it's an emergency, talk with rickspencer3 to help alter priorities accordingly
[20:04] <bryceh> diverse_izzue, if you're certain it's a kernel bug, you probably should be talking to the kernel team rather than us - see #ubuntu-kernel
[20:04] <diverse_izzue> bryceh, genereally, how much trouble does the new ati stack still make?
[20:05] <djr13> Sarvatt: would "ubuntu-bug xorg" still likely collect the correct info if I switched cards a couple hours ago?
[20:06] <bryceh> djr13, nope
[20:06] <diverse_izzue> bryceh, if you just said sth. please repeat, had an X crash
[20:07] <bjsnider> djr13, there is also a #nouveau channel where the devs lurk
[20:08] <bryceh> diverse_izzue, the way you asked your question it's not possible to answer it
[20:08] <bryceh> diverse_izzue, again see launchpad if you're curious about bugs
[20:09] <djr13> hmm looks like i'm stuck trying to get it running with a half-broken Xorg :)) should be possible though...
[20:09] <diverse_izzue> all right
[20:09] <djr13> bjsnider: yes i've been there...no responses :((
[20:10] <bryceh> diverse_izzue, we'd put out some calls for testing on the stack and no one reported any show stopper type issues, but not many people helped do the testing so it's not really possible to make broad generalizations about it
[20:10] <bryceh> upstream says it should be good to go
[20:11] <diverse_izzue> ok, i just recently tuned into the testing. i do have issues, and will make sure they are reported soon
[20:11] <tjaalton> diverse_izzue: you could also try on #dri-devel, say that .33 has a regression
[20:11] <bjsnider> bryceh, i'd say it is how it is. there aren't many good choices there. it's either radeon or fglrx
[20:12] <diverse_izzue> bjsnider, but there's regression potential. i could use external screens in karmic, and currently my system does either hang on boot with external screen or show an extremely jittery picture
[20:13] <bjsnider> i suppose fglrx doesn't work with the kernel yet
[20:13] <bryceh> bjsnider, tjaalton, btw apw implemented kms blacklisting support in the kernel, so if there are hw-specific issues that are best fixed by making the hw use ums instead, give him pci id's (and make sure there are bug report #'s for tracking)
[20:13] <tjaalton> or the xserver
[20:13] <diverse_izzue> bjsnider, i haven't tried and i won't...
[20:13] <bjsnider> diverse_izzue, it's not much help in any case i suppose
[20:13] <bjsnider> they'll probably patch it the day before lucid is released
[20:14] <tjaalton> bryceh: ok, nice
[20:16] <bryceh> bjsnider, unfortunately ATI NDA prevents us from disclosing when fglrx will be delivered to us
[20:16] <bjsnider> hahhaa whatever
[20:16] <bryceh> but it will be available in lucid
[20:17] <diverse_izzue> sometimes the industry is difficult to understand...
[20:17] <bjsnider> bryceh, why would you sign one of those awful things?
[20:18] <bryceh> bjsnider, well I didn't sign it personally ;-)
[20:18] <apw> bjsnider, tjaalton, bryceh, right ... get me the bug numbers, make sure the device ids are clearly in there and i'll put together a test kernel for them
[20:18] <bryceh> knowing stuff under an nda is almost worse than not knowing :-/
[20:19] <bryceh> if I didn't know, then I could give you educated guesses ;-)
[20:19] <bryceh> anyway, --> lunch.  bbiab
[20:19] <bjsnider> i provided an educated guess based on their past behaviour
[21:48] <bryceh> Sarvatt, you about?
[21:49] <bryceh> Sarvatt, can you bump me up to administrator in xorg-edgers (https://edge.launchpad.net/~xorg-edgers/+members)?
[21:49] <bryceh> Sarvatt, I want to add a ppa for multitouch
[22:19] <Sarvatt> bryceh: only tormod can do that but I created https://edge.launchpad.net/~xorg-edgers/+archive/multitouch
[22:20] <bryceh> Sarvatt, thanks
[22:22]  * bryceh copies in multitouch package
[22:22] <Sarvatt> jcristau: you have experience with xserver 1.8 post xorg.conf.d merge right? when you create xorg.conf.d snippets for input devices and such and they are matched does it handle video device autoconfiguration the same as not having an xorg.conf currently does?
[22:23] <bryceh> apw, mt kernels can be dropped @ https://edge.launchpad.net/~xorg-edgers/+archive/multitouch/+packages
[22:24] <bryceh> feh, we're drowning in these GPU lockup bugs
[22:28] <Sarvatt> hmm, i see some trends in the gpu lockup bugs
[22:31] <Sarvatt> 8xx are all at boot time and justify quirking to UMS, every other one I've looked at so far looks like it was triggered by the plymouth sigquit restarting X deal..?
[22:32] <bryceh> Sarvatt, ooh really?  that's good insight
[22:32] <bryceh> so for 8xx we could just have apw blacklist them all (which we were thinking of doing anyway)
[22:32] <Sarvatt> there's a little issue with libdrm I haven't figured out yet, I get a drm error every time i stop or restart gdm
[22:33] <Sarvatt> digging through my logs to find the exact message
[22:33] <bryceh> for the plymouth ones, I wonder if there's a way we can check for that situation automatically and avoid filing more bug reports in that case?
[22:35] <jcristau> Sarvatt: afaik stuff is handled as if you had the xorg.conf.d contents in xorg.conf
[22:36] <Sarvatt> [drm:i915_gem_madvise_ioctl] *ERROR* Attempted i915_gem_madvise_ioctl() on a pinned object
[22:37] <Sarvatt> I get that switching to a VT and doing a sudo service stop gdm
[22:39] <Sarvatt> i need to file an upstream bug on that one now that i figured out it wasnt plymouth related
[22:42] <Sarvatt> hmm i have an error in my dmesg now when i suspended with the powersave=1 945 black screen hang, that used to just be silent and will trigger the apport script too so I gotta check 945 hang bugs for that
[22:42] <Sarvatt> Mar  8 18:25:13 asuka kernel: [97322.963349] render error detected, EIR: 0x00000010
[22:42] <Sarvatt> Mar  8 18:25:13 asuka kernel: [97322.963369] page table error
[22:42] <Sarvatt> Mar  8 18:25:13 asuka kernel: [97322.963381]   PGTBL_ER: 0x00000010
[23:30] <Sarvatt> bryceh: what devices are you trying to support? if it's n-trig you get multitouch/stylus/touch and eraser support through wacom and just need to extend the udev rules as well as integrate the n-trig kernel module (not to mention the non-redistributable windows firmware it needs..). you will lose everything but touch events using evdev?
[23:31] <bryceh> yeah n-trig is the priority
[23:32] <bryceh> apw's looking into the kernel module (see https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-xorg-multitouch)
[23:32] <bryceh> Sarvatt, I got a patch that adds multitouch support to -evdev which is in the aforementioned ppa now
[23:32] <bryceh> don't have the hw to test it though
[23:36] <superm1> that reminds me, my touchscreen broke on upgrade to lucid, is it expected to be working right now?
[23:36] <superm1> single touch
[23:39] <Sarvatt> a bug report would help alot when you have time, unless it was before wacom 0ubuntu2 was uploaded then it was expected not to work
[23:40] <Sarvatt> -- Timo Aaltonen <tjaalton@ubuntu.com>  Fri, 05 Mar 2010 10:52:11 +0200
[23:41] <Sarvatt> serial tablets were broken until then needing the wacom udev rules update it had
[23:42] <bryceh> superm1, probably due to dropping HAL
[23:42] <Sarvatt> (most tablet pc's having serial digitizers, not sure what device you have)
[23:43] <superm1> i dont have the HW handy right now.  i'll get a bug report together when i ge thome
[23:43] <superm1> i dist-upgraded on sunday, so so i should have that
[23:44] <Sarvatt> yeah that'd be much appreciated, it *should* be working at this point
[23:45] <superm1> Ok, that's what i needed to determine, whether the bug report would do anygood since it was "supposed" to be working
[23:55] <Sarvatt> actually I just noticed we're missing waltop tablets support, and i was under the impression serial wacom devices needed Option "ForceDevice" "ISDV4" in xorg.conf as well