| lesshaste | hi.. my X restarted again spontaneously with this log http://pastebin.com/f4d283a92 | 14:39 |
|---|---|---|
| lesshaste | I thought i had installed debug symbols.. what can I do to get a better backtrace for next time? | 14:39 |
| lesshaste | I have installed xserver-xorg-core-dbg for example so I am mystified | 14:45 |
| mnemo | there are certain types of bugs where the stack itself gets corrupted (buffer overflows etc) and in those cases you might not be able to reconstruct a backtrace because essentially what you think is return addresses are just random pointers | 14:53 |
| mnemo | i have no idea if that's the case for you though | 14:53 |
| mnemo | lesshaste: there is a better wat to get backtraces, but its a bit more work | 14:54 |
| lesshaste | mnemo: that's very interesting... I am not very good at interpreting backtraces like this one | 14:54 |
| lesshaste | mnemo: what is that | 14:54 |
| lesshaste | ? | 14:54 |
| mnemo | its kind of complicated but basically whenever you run into a CALL instruction in machine code, the CPU will push the address in memory where it is supposed to continue running once that CALL is done | 14:55 |
| lesshaste | oh I see. this involves patching X? | 14:55 |
| mnemo | so basically what gdb does is that it walks through the raw stack memory and then it just figures out which locations hold the actual returns addresses | 14:55 |
| mnemo | no you can get a backtrace much easier | 14:55 |
| lesshaste | ok | 14:56 |
| mnemo | with normal gdb actually | 14:56 |
| lesshaste | so run X in gdb? | 14:56 |
| mnemo | basically you need to attach gdb to X while its running and then keep gdb running in a ssh shell | 14:56 |
| mnemo | yea just start up X normally | 14:56 |
| lesshaste | ok.. how do I do that please :) | 14:56 |
| mnemo | connect to ssh from another computer | 14:56 |
| mnemo | and then you do "sudo gdb -p $(pidof X)" | 14:56 |
| lesshaste | oh I see... a little like a serial console | 14:56 |
| mnemo | this will temporarily freeze your X on that machine | 14:56 |
| mnemo | yea sort of like that | 14:57 |
| mnemo | anyway, once you type "c" inside gdb you will be able to use X again | 14:57 |
| mnemo | and then you just wait until you can trigger the crash again | 14:57 |
| mnemo | at that point gdb will stop again and break into a prompt mode from where you can do all kinds of neat analysis | 14:57 |
| lesshaste | that can't be done from a VT on the same machine? | 14:58 |
| mnemo | no unfortunately not | 14:58 |
| mnemo | if you really want to do it from a single machine I think you can | 14:58 |
| mnemo | i've never done that though | 14:59 |
| lesshaste | why won't it work from a VT? That should be affected by an X crash should it? | 14:59 |
| lesshaste | shouldn't | 14:59 |
| lesshaste | (for the first should :) ) | 14:59 |
| mnemo | the thing is that if you shutdown X and then start like "gdb X" then X won't unset its graphical mode when you break into the SEGV prompt in gdb so I dont think that would work | 14:59 |
| mnemo | hmm im not sure why it won't work on a VT | 15:00 |
| mnemo | i mean try it I guess :) but I suspect it won't work | 15:00 |
| mnemo | heh I tried it now, it didnt work.. I can attach gdb fine but I can get back to X from there | 15:04 |
| lesshaste | mnemo: which xserver-xorg-video-<name> do I need for the fglrx driver? Could it be ati? | 15:04 |
| lesshaste | mnemo: :) thanks | 15:04 |
| mnemo | nah | 15:04 |
| mnemo | fglrx is none of those | 15:04 |
| lesshaste | ah ok | 15:05 |
| mnemo | fglrx is closed source crap | 15:05 |
| mnemo | but xserver-xorg-video-ati usually works pretty well for the same cards | 15:05 |
| lesshaste | but 3d right? | 15:06 |
| mnemo | yeah the open source -ati version has 3d with direct rendering etc | 15:06 |
| mnemo | compiz runs great on it etc | 15:07 |
| lesshaste | oh.. this sounds newish :) | 15:07 |
| lesshaste | I should change to that | 15:07 |
| mnemo | honestly, the best thing with the open source driver is that you can actually analyze the failures, file good bug reports and get stuff to improve | 15:07 |
| lesshaste | sure but I didn't know 3d worked these days :) | 15:08 |
| mnemo | try it and see if it's good enough for you | 15:08 |
| mnemo | and file bugs if it doesnt work | 15:08 |
| lesshaste | thanks | 15:14 |
| lesshaste | will do | 15:14 |
| alex_mayorga | hello, can anyone take a look at Bug #213171 and tell me if is actually the same bug or should I file a new one for my video issues? | 15:15 |
| ubottu | Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/213171/+text) | 15:15 |
| alex_mayorga | ups! | 15:17 |
| alex_mayorga | https://bugs.edge.launchpad.net/bugs/213171 | 15:21 |
| ubottu | Launchpad bug 213171 in xorg "[i830] Unable to install with GUI on Fujitsu Lifebook C7651" [Unknown,In progress] | 15:21 |
| alex_mayorga | anyone aware of i830 isues on the intel driver for 9.04? | 15:47 |
| === jbarnes_ is now known as jbarnes | ||
| alex_mayorga | bryce, you around? | 18:56 |
| bryce | yes | 18:56 |
| alex_mayorga | I'd like to volunteer to get https://bugs.edge.launchpad.net/ubuntu/+bug/213171 fixed | 18:56 |
| ubottu | Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/213171/+text) | 18:56 |
| alex_mayorga | I'll need heaps of guidance though :) | 18:56 |
| bryce | ok, well first step is to test against -intel 2.7 | 18:57 |
| alex_mayorga | is that on the repos? | 18:57 |
| bryce | if you can reproduce the issue on that, then the next step is to file the bug upstream | 18:57 |
| bryce | you can get it from the x-updates ppa | 18:57 |
| alex_mayorga | OK, will start there, thanks | 18:58 |
| bryce | here is a link for filing it upstream - https://bugs.freedesktop.org/enter_bug.cgi?product=xorg | 18:59 |
| bryce | however note that upstream generally does not give much priority to 8xx hardware... still it is worth a try just in case | 18:59 |
| bryce | some additional guidance on analyzing bugs can be found via http://wiki.ubuntu.com/X/ | 19:00 |
| alex_mayorga | is there a way to use the intrepid driver? | 19:00 |
| bryce | yes, someone set up a PPA for that - it's linked to from the IntelPerformance troubleshooting page | 19:04 |
| alex_mayorga | OK thanks that should at least give me my video back | 19:06 |
| tjaalton | howdy ho | 19:07 |
| bryce | heya tjaalton | 19:31 |
| tjaalton | hi bryce | 19:34 |
| bryce | how's the move been going? | 19:34 |
| tjaalton | almost over :) | 19:35 |
| tjaalton | only some stuff left in the old storage room | 19:36 |
| tjaalton | and the final cleanup of the old place | 19:36 |
| tjaalton | how's karmic so far?-) | 19:42 |
| tjaalton | about the intel virtual hack; I think Mirv had it set to 2k*2k, and he was immune to these hangs, so it's looking pretty much like a solved case imho | 19:46 |
| tjaalton | bbl, sauna -> | 19:47 |
| alex_mayorga | bryce, the intel driver at https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-updates didn't help | 19:50 |
| bryce | tjaalton: karmic is ok so far; I've set up my pbuilder and switched tools over to it, and done a few merges, but nothing major yet | 19:51 |
| alex_mayorga | you were saying the intrepid driver is available somewhere, right? | 19:51 |
| bryce | tjaalton: I think before I get into it too much I'm going to work on getting the UXA bugs upstreamed | 19:52 |
| bryce | alex_mayorga: what was your experience with the 2.7 driver exactly? | 19:52 |
| bryce | alex_mayorga: yeah see above | 19:52 |
| alex_mayorga | same thing, the four quarters of the screen are overlaid in the top-left most quearter | 19:53 |
| alex_mayorga | and the whole LCD "shakes" a bit to the left and right, really unusable, want a picture? | 19:53 |
| bryce | put the picture on the bug report, yes | 19:54 |
| bryce | it sounds a lot like a modeline issue | 19:54 |
| alex_mayorga | bryce, sorry my pidgin crashed before I could catch the other PPA | 19:54 |
| bryce | if you connect a different monitor to it, does the issue go away? | 19:54 |
| alex_mayorga | hadn't really tried a secondary monitor | 19:55 |
| bryce | the link is on the IntelPerformance page in wiki | 19:55 |
| bryce | test that next | 19:55 |
| bryce | if it is a modeline issue, switching drivers won't make any difference | 19:55 |
| alex_mayorga | just plug a monitor, that's it? | 19:55 |
| bryce | yeah, plus maybe reboot | 19:55 |
| alex_mayorga | only clue I have is that video was perfect on intrepid | 19:56 |
| alex_mayorga | I seem to have every single one of the WONT work at all video cards | 19:56 |
| bryce | well, go ahead and try the driver if you want, but modelines are calculated in the xserver | 19:56 |
| alex_mayorga | do you remember my geforce go | 19:56 |
| bryce | fwiw, there are ways you can manually program modelines | 19:57 |
| bryce | but try attaching a different monitor first | 19:57 |
| bryce | if that doesn't make the issue go away, then no use bothering with modeline stuff | 19:58 |
| alex_mayorga | OK, let me try to get a monitor from a friend see if that works | 19:58 |
| bryce | alternately, you can try switching to a different resolution | 19:58 |
| bryce | each resolution has a different modeline, so often if you have a modeline bug, it's particular to that one resolution | 19:58 |
| alex_mayorga | I have to edit xorg.conf for that right? | 19:59 |
| bryce | however if it is being caused by the display's edid or ddc data, all the resolutions could be borked | 19:59 |
| bryce | to switch resolutions just use xrandr | 19:59 |
| alex_mayorga | FWIW tty2 is just merry :) | 20:01 |
| alex_mayorga | xrandr: can't open display | 20:02 |
| === Adam is now known as aportier | ||
| aportier | i was wondering if this is the correct place to come with issues with my intel graphics card | 20:09 |
| alex_mayorga | aportier, I feel your pain :) | 20:10 |
| alex_mayorga | but so far I think I'm better of staying on intrepid | 20:10 |
| alex_mayorga | aportier: what card you've got? | 20:10 |
| aportier | i have an intel aspire one with an intel 945 GME | 20:11 |
| aportier | i have gotten the 2.7 drivers off your ppa and still have slowdown in video playback | 20:12 |
| aportier | i have tried exa and uxa modes on the x11.conf | 20:12 |
| aportier | and migrationheuristic greedy | 20:12 |
| aportier | no success so far | 20:12 |
| bryce | aportier: bug id#? | 20:12 |
| aportier | one sec its on the other pc | 20:13 |
| aportier | 314928 | 20:13 |
| aportier | i read something about piping a value into the /proc/mtrr but i couldn't understand the information well enough to apply it | 20:14 |
| bryce | what else have you tried? newer kernel? | 20:15 |
| aportier | havn't messed with the kernel | 20:16 |
| bryce | hmm, don't see 'aportier' on the lp bug, do you go by a different name there? | 20:16 |
| aportier | i think i subscribed to it, maybe not | 20:16 |
| aportier | its effecting all aspire one users afaik | 20:16 |
| bryce | ok, next try 2.6.30-rc3. It has a number of performance fixes, esp. for issues that still occur when uxa is enabled. | 20:16 |
| bryce | you can also see the IntelPerformance troubleshooting guide in wiki | 20:17 |
| aportier | is there a ppa where i can get pre compiled kernels | 20:17 |
| bryce | yeah the kernel team's ppa | 20:17 |
| aportier | i will give that a shot, thank you | 20:18 |
| bryce | no prob, good luck | 20:21 |
| tormod | bryce, there is rc4 out now (both in mainline and karmic) with a bunch of intel fixes | 20:27 |
| mnemo | drm for g41 was fixed in rc4 for example | 20:27 |
| bryce | great | 20:29 |
| bryce | is that now the default kernel? I set up a chroot but it still though 2.6.28 was the default | 20:30 |
| alex_mayorga | bryce, thanks xserver-xorg-video-intel-2.4 gave my LCD back | 20:30 |
| tormod | bryce: I guess the meta packages are not updated yet. I downloaded the deb. | 20:31 |
| bryce | alex_mayorga: wow interesting | 20:31 |
| alex_mayorga | I'm installing flash to check video performance, but looks as good as it was on intrepid | 20:31 |
| bryce | alex_mayorga: if you're still keen on chasing down the fix, now that you have isolated the bug to the video driver, it is possible to do a 'git bisect' to find the exact patch causing the problem | 20:32 |
| bryce | if you do that, then we may be able to get the issue solved in the current version of -intel | 20:32 |
| bryce | otherwise, it's likely that the issue will still be there if you ever want to upgrade | 20:32 |
| bryce | tormod: gotcha | 20:33 |
| bryce | tormod: I've been accumulating a list of -intel bugs we can close once the kernel updates :-) | 20:33 |
| alex_mayorga | bryce, I'll look into it, sounds like a very educational thing to do :) | 20:33 |
| bryce | alex_mayorga: there's a document on how to do it available on wiki.ubuntu.com/X | 20:34 |
| bryce | indeed, it's quite educational ;-) | 20:34 |
| bryce | but with a little stubbornness it's quite effective at isolating problems to their fixes | 20:35 |
| aportier | @bryce: sorry to bother you again, but where would you recommend i get this test kernel? i can't locate it on launchpad | 20:43 |
| bryce | http://kernel.ubuntu.com/~kernel-ppa/mainline | 20:44 |
| alex_mayorga | bryce, video it's a bit slow, but I'm not complaining, it's a really old laptop | 20:46 |
| tjaalton | bryce: ok, sounds like a plan | 21:19 |
| aportier | ok, back, kernel update did not fix the problem | 21:19 |
| bryce | aportier: ok, have you tried the 2.7.0 -intel driver? | 21:21 |
| bryce | available from https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-updates/ | 21:21 |
| aportier | running it right now | 21:21 |
| aportier | one of the first things i tried | 21:21 |
| bryce | oh right | 21:21 |
| bryce | hmm | 21:21 |
| aportier | is there any validity to this /proc/mtrr issue? something you could help me understand a bit better? | 21:22 |
| bryce | ok, now can you file a new bug report with this configuration, using the command 'ubuntu-bug xserver-xorg-video-intel', describe what you're experiencing, and give me the bug ID? | 21:22 |
| bryce | yes there is validity to that, did you try making those changes? | 21:22 |
| aportier | my lspci -vvnn doesn't produce hex addresses for the registers | 21:22 |
| aportier | i get whole numbers | 21:23 |
| aportier | so i don't know what register to update | 21:23 |
| aportier | i tried a-e, no change | 21:23 |
| bryce | ok, file a new bug, and describe what you've attempted with mtrr, and I can forward it upstream | 21:24 |
| bryce | I don't know a lot of particulars about mtrr stuff... it's a bit more of a kernel level thing | 21:25 |
| aportier | ok, i will open a new bug. should i revert the kernel first, and what log files should i post | 21:25 |
| mnemo | i think basically mtrr's describe the characteristics of a set of memory ranges.. for example they can say "for all RAM memory starting at X up Y the CPU cache must never be used" and similar things | 21:28 |
| bryce | aportier: do it on the 2.6.30 kernel (actually probably won't matter). If you file via ubuntu-bug it will attach everything needed for now | 21:29 |
| bryce | upstream may ask for more info later on | 21:30 |
| aportier | ubuntu-bug is a package? | 21:30 |
| mnemo | no its a command | 21:30 |
| bryce | it's a command you run on the command line | 21:30 |
| mnemo | a script that opens launchpad bugs | 21:30 |
| aportier | ok cool never used it before | 21:30 |
| aportier | ill go ahead and do that | 21:30 |
| aportier | thanks for the help | 21:31 |
| aportier | bug 370552 | 21:57 |
| ubottu | Launchpad bug 370552 in xserver-xorg-video-intel "Slow flash video playback on Intel 945gm" [Undecided,New] https://launchpad.net/bugs/370552 | 21:57 |
| aportier | ok im going to continue to pick through this on my own, if you guys see something glaring in there, please let me know | 21:58 |
| aportier | thanks again for the help | 21:58 |
| tjaalton | bryce: so, rtg said that enabling kms "truly wrecks your experience".. do you know what me meant by that? | 22:00 |
| bryce | nope | 22:01 |
| bryce | someone else had tested it and found it doesn't do the plymouth thing but otherwise works | 22:01 |
| bryce | I was going to give it a shot myself and put together a paint-by-numbers guide | 22:01 |
| tjaalton | jaunty is boring, maybe I should just upgrade.. | 22:01 |
| bryce | need to get a handful of UXA bugs upstreamed first | 22:02 |
| bryce | tjaalton: thoughts on updating to newer mesa? | 22:03 |
| * tormod is bored not having -intel hw to crash | 22:03 | |
| tjaalton | bryce: you mean 7.4.1? | 22:04 |
| tjaalton | there should be a 7.5rc next week | 22:04 |
| bryce | tormod, tjaalton: ok well feel free to update us to latest whatever you want | 22:05 |
| bryce | the direction we've got for karmic is to go ultra-bleeding edge this time, to get best support for KMS and boottime prettiness | 22:06 |
| tjaalton | 7.5 it is then?-) | 22:06 |
| bryce | yep | 22:06 |
| mnemo | tjaalton: that reminds me, is it worth for me to prepare a debdiff for this one --> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/368049 (dänzer already pushed that one to 7.4 stable branch) | 22:06 |
| ubottu | Launchpad bug 368049 in mesa "compiz crashes gnome desktop using default ati driver (radeon X600)" [Undecided,Confirmed] | 22:06 |
| tjaalton | not that it's directly kms related, but | 22:06 |
| bryce | tjaalton: we'll have driver dependencies on it | 22:07 |
| tjaalton | mnemo: guess so | 22:07 |
| mnemo | tjaalton: so you wont push 7.4.1 to jaunty then? is that too big/risky maybe? | 22:07 |
| tjaalton | mnemo: it's not my call | 22:07 |
| mnemo | bryce: what do you think? | 22:08 |
| tormod | they already started mesa 7.6-dev, I guess it will have radeon-rewrite soon. | 22:08 |
| bryce | mnemo: if you put together a debdiff, I'll review and sponsor if it looks sane (as I suspect it will) | 22:09 |
| mnemo | ok I will do that then | 22:09 |
| Sarvatt | glad I waited on -intel tormod, they're pushing some big bug fixes right now :D | 22:09 |
| tjaalton | mnemo: we haven't done dot-releases-as-sru's before, so it'd need some discussiong before | 22:10 |
| tjaalton | ..we do it | 22:10 |
| tormod | Sarvatt: nice, hopes it fixes your card | 22:10 |
| bryce | mnemo, tjaalton: oh, right, make sure to pull the specific patch that fixes it, not a point release | 22:10 |
| mnemo | ok | 22:10 |
| bryce | the SRU team never seems to allow putting point releases through | 22:10 |
| tjaalton | right | 22:11 |
| mnemo | we might still look at the git log in 7.4 stable branch and see if fedora escalated some nice fixes from their releases and then we just package those one by one | 22:11 |
| tormod | the SRU team won't accept a line of code that doesn't fix a serious bug on launchpad | 22:11 |
| mnemo | makes sense, _especially_ for mesa/xorg stuff | 22:12 |
| bryce | yeah cherrypicking patches that fix issues that we can reproduce in ubuntu or have a bug reporter who can test it to verify the bug exists, is a requirement of the sru team | 22:12 |
| bryce | hmm, not sure that's a coherent sentence | 22:13 |
| tjaalton | :) | 22:13 |
| bryce | oh also with mesa, I'm especially cautious in considering patches that affect intel, since it seems to be so fragile - too often a fix seems to cause issues elsewhere | 22:14 |
| bryce | ati seems more robust though, so I'm less worried there about mesa patches | 22:14 |
| tjaalton | after reading the blog post by keithp I guess that's going to change | 22:15 |
| mnemo | i hope we can get past all this frailty and be rock solid on UXA for the LTS | 22:17 |
| tormod | tjaalton: before you start on mesa 7.5, you might have a look at Sarvatt's upload to xorg-edgers, egl craps out on amd64 but that's maybe an old issue that was taken care of by a Ubuntu patch | 22:17 |
| bryce | tjaalton: I've got a bunch of sessions planned for UDS to talk on intel issues | 22:17 |
| Sarvatt | ahhh shoot, I missed aportier'squestion | 22:18 |
| Sarvatt | I have an aspire one and you absolutely have to boot with mtrr cleanup and 1 spare reg | 22:18 |
| bryce | (assuming Europe lets us swine-flu-y Usians in) | 22:18 |
| Sarvatt | i have to boot with enable_mtrr_cleanup mtrr_spare_reg_nr=1, aspire one has buggy mtrr's by default | 22:19 |
| bryce | Sarvatt: ah cool - could you mind giving him some guidance on his bug #? | 22:19 |
| bryce | also, is that something we can sort out on the X side of things, or does it require kernel changes to solve properly? | 22:19 |
| Sarvatt | [ 0.000000] original variable MTRRs | 22:19 |
| Sarvatt | [ 0.000000] reg 0, base: 4194176KB, range: 128KB, type WP | 22:19 |
| Sarvatt | [ 0.000000] reg 1, base: 4194048KB, range: 128KB, type UC | 22:19 |
| Sarvatt | [ 0.000000] reg 2, base: 0GB, range: 1GB, type WB | 22:19 |
| Sarvatt | [ 0.000000] reg 3, base: 1GB, range: 512MB, type WB | 22:19 |
| Sarvatt | [ 0.000000] reg 4, base: 1528MB, range: 8MB, type UC | 22:19 |
| Sarvatt | [ 0.000000] reg 5, base: 1526MB, range: 2MB, type UC | 22:19 |
| Sarvatt | [ 0.000000] reg 6, base: 1525MB, range: 1MB, type UC | 22:19 |
| Sarvatt | [ 0.000000] reg 7, base: 0GB, range: 128KB, type UC | 22:19 |
| Sarvatt | [ 0.000000] WARNING: BIOS bug: VAR MTRR 7 contains strange UC entry under 1M, check with your system vendor! | 22:19 |
| tjaalton | bryce: hehe, it would be a pretty lame uds if they wouldn't | 22:19 |
| tormod | bryce: you will have to wear masks :) revenge for taking all our fingerprints | 22:20 |
| Sarvatt | kernel, when I build my kernels I enabled mtrr cleanup and 1 spare to fix it but the command line stuff works | 22:20 |
| Sarvatt | reg00: base=0x000000000 ( 0MB), size= 1024MB, count=1: write-back | 22:20 |
| Sarvatt | reg01: base=0x040000000 ( 1024MB), size= 512MB, count=1: write-back | 22:20 |
| Sarvatt | reg02: base=0x05f500000 ( 1525MB), size= 1MB, count=1: uncachable | 22:20 |
| Sarvatt | reg03: base=0x05f600000 ( 1526MB), size= 2MB, count=1: uncachable | 22:20 |
| Sarvatt | reg04: base=0x05f800000 ( 1528MB), size= 8MB, count=1: uncachable | 22:20 |
| Sarvatt | reg05: base=0x060000000 ( 1536MB), size= 256MB, count=1: write-combining | 22:20 |
| Sarvatt | thats what i get with 1 spare | 22:20 |
| tjaalton | tormod: hmm, pointer? | 22:21 |
| tormod | tjaalton: to what? | 22:22 |
| tjaalton | tormod: to the bug that xorg-edgers would fix | 22:22 |
| Sarvatt | what i was just talking a bout with -intel? it's a big compiz fix if so | 22:23 |
| bryce | tormod, tjaalton: :-) | 22:23 |
| tormod | tjaalton: it is not fixing something in particular, I was just warning about potential amd64 issue, but as I added, it might be fixed in some ubuntu patch | 22:24 |
| tjaalton | tormod: the vblank one? there aren't any other ones that would matter | 22:26 |
| tjaalton | and it's not amd64-only | 22:26 |
| tjaalton | but with uxa/dri2 we don't have vblank anyway | 22:26 |
| tormod | we are talking about different things, sorry :) | 22:26 |
| tjaalton | maybe | 22:27 |
| tormod | tjaalton: maybe you addressed me by mistake to start with :) | 22:27 |
| tjaalton | tormod: dunno, I'm confused regardless :) | 22:28 |
| tjaalton | been away for "too long" (some weeks..) | 22:29 |
| tormod | but now that I read your questions again: Sarvatt dropped a vblank patch in -intel, and the same can be done in mesa I guess. | 22:29 |
| tormod | Sarvatt: right? | 22:29 |
| Sarvatt | I readded it | 22:29 |
| tormod | aha | 22:29 |
| Sarvatt | 2 people had a problem with it | 22:29 |
| tjaalton | grr, I hate these 1pix wide window borders | 22:30 |
| Sarvatt | was just mesa I dropped it from, no vblank patch in -intel | 22:31 |
| tormod | Sarvatt: re your report 21512, you can get an unoptimized build (and see more variables in the backtrace) with: DEBUILD_BUILD_OPTIONS="noopt debug nostrip" debuild -b -us -uc | 22:31 |
| Sarvatt | I was going to do that but anholt said the backtraces were useless with the situation I was having | 22:32 |
| tormod | Sarvatt: ok I mix up things or remember wrong regarding those patches... | 22:32 |
| Sarvatt | lucky because it woulda taken either 2 hours to build locally or 24 hours to build on a ppa to do it :D | 22:32 |
| tormod | Sarvatt: 2 hours to build the -intel driver? | 22:33 |
| Sarvatt | oh sorry was thinking mesa there since we were just talking about it, now both of us are confused :D | 22:34 |
| tjaalton | so what bug is it that using vblank would fix? | 22:34 |
| * tormod goes to bed rather than stir up more confusion | 22:34 | |
| Sarvatt | they're talking about it in intel-gfx right now actually | 22:35 |
| Sarvatt | big paste so I'll PM it | 22:35 |
| tjaalton | pastebin works | 22:36 |
| Sarvatt | it's on G45 though which explains why I had no problems without it | 22:36 |
| tormod | Sarvatt: the mesa amd64 failure: the log shows some files are built with -fPIC and some not, I don't see why when looking at the Makefile, e.g. eglapi.c vs egllog.c | 22:50 |
| Sarvatt | would uploading it with DH_VERBOSE=1 help figure it out? | 22:53 |
| Sarvatt | or is it in the mesa configs | 22:53 |
| Sarvatt | weird, every other one isnt using -fPIC | 22:59 |
| Sarvatt | theres a bunch of new egl stuff in configure.ac, could always disable egl couldn't we? | 23:10 |
| tormod | Sarvatt: yeah just disable it in confflags-common in debian/rules. I don't think it is even shipped in the debian packaging | 23:21 |
| Sarvatt | nope it isnt, nowhere to be found | 23:22 |
| tormod | but I am curious to that fPIC thing... | 23:22 |
| Sarvatt | /bin/bash ../../../bin/mklib -o EGL -linker 'gcc' -ldflags '' \ | 23:23 |
| Sarvatt | -major 1 -minor 0 \ | 23:23 |
| Sarvatt | -install ../../../lib \ | 23:23 |
| Sarvatt | -lX11 -ldl eglapi.o eglconfig.o eglconfigutil.o eglcontext.o egldisplay.o egldriver.o eglglobals.o egllog.o eglhash.o eglmisc.o eglmode.o eglscreen.o eglstring.o eglsurface.o eglx.o | 23:23 |
| Sarvatt | mklib: Making Linux shared library: libEGL.so.1.0 | 23:23 |
| Sarvatt | need to add it to the static lib list in the configs maybe? | 23:24 |
| tormod | but you don't see libEGL in the debian/*.install files | 23:24 |
| Sarvatt | its auto detecting that we have egl and enabling it in the configure stage it looks like | 23:24 |
| Sarvatt | dnl | 23:28 |
| Sarvatt | AC_ARG_ENABLE([egl], | 23:28 |
| Sarvatt | [AS_HELP_STRING([--disable-egl], | 23:28 |
| Sarvatt | [disable EGL library @<:@default=enabled@:>@])], | 23:28 |
| Sarvatt | [enable_egl="$enableval"], | 23:28 |
| Sarvatt | [enable_egl=yes]) | 23:28 |
| Sarvatt | if test "x$enable_egl" = xyes; then | 23:28 |
| Sarvatt | SRC_DIRS="$SRC_DIRS egl" | 23:28 |
| tormod | src/egl/main/Makefile treats all those files the same, the CFLAGS should be the same, yet some have fPIC and some not. | 23:29 |
| tormod | that snippet checks for your --disable-egl in confflags-common | 23:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!