[00:56] <Ng> has anyone else started seeing weird X crashes and kernel panics in karmic?
[00:57] <Ng> my laptop's done it three times this evening, but not before
[00:59] <Ng> nothing makes it to logs, and even though I get dumped to a console, there's no panic output there
[01:17] <bryce> Ng, nope
[01:17] <bryce> Ng, you could check launchpad
[01:24] <Ng> bryce: I had a quick poke and didn't see anything
[01:25] <bryce> -intel has been super sturdy here
[01:25] <bryce> I've got 3 laptops running it with no problems
[01:26] <Ng> it has been for me too until today. I re-installed with RC and I think I've only rebooted once since then, until I shut the laptop down last night, so some of -updates would only really have started running today, but looking at the logs it's all really boring stuff ;)
[01:27] <Ng> it's weird that I get a console and a wedged kernel (flashing capslock) rather than just a hang in X, and there's no oops text
[01:27] <bryce> did you talk with the kernel guys about it?
[01:28] <Ng> not yet, they're my next stop
[01:28] <Ng> and I'm going to check in with jerone/lool/robbiew tomorrow, all of whom have the same laptop as me
[01:28] <bryce> ok
[01:28] <bryce> out of curiousity, what made you check here first and then kernel?
[01:29] <Ng> I think because it seems like X dies
[01:29] <bryce> (a lot of people do this, but since there's more of them than me I'm wondering how to switch things around)
[01:29] <Ng> heh, this is a fair point :)
[01:30] <bryce> yeah as a general rule if you have a kernel failure, start by solving that.  A kernel fault could easily be the cause of X failing
[01:56] <jg> Ng: or you may have DRAM failures, or the like...
[01:58] <Ng> jg: the thought has crossed my mind, I think I'll leave the thing memtesting while I sleep
[01:58] <jg> Ng: diagnostics are first written to prove hardware works....
[01:58] <jg> (I guess I'm jaded on the topic...)
[01:58] <Ng> hah
[01:59] <jg> but certainly, if it shows problems you have problems.
[02:00] <jg> Ng: I had DRAM problems on a microvax II once upon a time: the problem would only occur if the system was idle.
[02:01] <jg> turns out that the DRAM manufacturer had left a wire off the chip; only if you never referenced the chip would it not get refreshed, and you'd see the failure first thing in the morning when you started to use the machine again.
[02:02] <jg> would run diagnostics forever.  Digital had to hold up shipment of Microvax II's several months while this was figured out.
[02:03] <jg> I happened to be the person who figured out that the systems only failed first thing in the morning after being idle all night....
[09:07] <jcristau> bah no tormod.
=== _stink__ is now known as _stink_
=== _stink__ is now known as _stink_
[20:30] <tormod> bryce I am getting there: http://git.debian.org/?p=users/tormod-guest/mesa.git;a=summary
[20:31] <bryce> sweet
[20:32] <tormod> some of the commit diffs are ugly because they include the upgrade of the upstream version
[20:32] <tormod> and others are ugly because there is stuff in the package (tarball I guess) which is not in git (WINDOWS/ etc)
[20:33] <tormod> but just to get up to date, maybe it is good enough
[20:46] <bryce> tormod, maybe it needs a script to handle doing it (does debian have something?)
[20:49] <tormod> bryce, I googled quite a bit before I started on it of course. I tried bzr-fast-export/git-fast-import but it failed, I don't know if
[20:49] <tormod> that would handle upstream merges better
[20:52] <tormod> oh I suddenly understood one reason it failed: git tags are more restricted than bzr tags
[20:52] <bryce> oh?
[20:53] <tormod> can not have "~" in a git tag AFAICS
[20:53] <jcristau> tormod: fwiw, if you still want a review/comment on that thing from yesterday, mail works better.
[20:54] <tormod> jcristau, thanks, yes. just mail me your comments if you want
[20:55] <jcristau> no, i mean send me a mail if you want me to look at something :)
[20:56] <tormod> jcristau, I'll do that the next time :)
[21:25] <jbarnes> bryce: ping
[21:25] <jbarnes> bryce: wanted to make sure you picked up http://lists.freedesktop.org/archives/intel-gfx/2009-November/004762.html
[21:26] <jbarnes> along with the other ironlake fixes Zhenyu sent out (http://lists.freedesktop.org/archives/intel-gfx/2009-November/004758.html)
[21:27] <bryce> jbarnes, thanks
[21:27] <bryce> jbarnes, yeah I'm currently distracted from -intel due to -nvidia bugs, but am adding that to my todo list
[21:27] <jbarnes> my ironlake desktop machine is pretty happy with karmic with those bits
[21:27] <jbarnes> bryce: no problem, just wanted to make sure you saw them
[21:27] <bryce> thanks
[21:28] <bryce> yeah it seems (so far) that we've sped up boot speeds to the point that X can start booting before nvidia.ko has finished building.  whoops.
[21:30] <jbarnes> heh
[21:30] <jbarnes> good problem to have
[21:32] <bryce> heh, not if you're active on ubuntuforums apparently
[21:42] <tormod> bryce, is that why fedora is twice as fast as Ubuntu on nvidia according to Phoronix?
[21:44] <bryce> tormod, with that opengl test?  nfi
[21:44] <jbarnes> nv vs nouveau?
[21:44] <bryce> last time I looked into one of the performance regressions they "found" it ended up being just too crackful to get any useful info out.  No one else had the same trouble.
[21:44] <jbarnes> or nv vs nvidia? :)
[21:45] <tormod> they installed nvidia drivers manually on both systems
[21:45] <tormod> wonder what it would look like if they used jockey instead
[21:49] <bryce> wish they published their tests in a way that was more easily reproducible