| Darxus | Looks like my radeon, which works great in Oneric, does not work with the radeon drivers in Precise. | 00:23 |
|---|---|---|
| Darxus | Normal mode, it boots to a dark purple flickering screen, entirely unusable, using the radeon driver. Safe mode, it boots with the vesa driver: | 00:23 |
| Darxus | < (II) [KMS] drm report modesetting isn't supported. | 00:23 |
| Darxus | < (II) GPU only supported with KMS, using vesa instead. | 00:24 |
| Darxus | Fresh precise beta 2 install, doing a dist-upgrade now to see if that helps. | 00:24 |
| RAOF | Darxus: Got a dmesg? | 00:24 |
| Darxus | Sure, I'm booted into save graphics mode now, that good? | 00:25 |
| Darxus | http://www.chaosreigns.com/tmp/precise.safemode.dmesg.txt | 00:27 |
| RAOF | You'd need to boot without nomodeset to get a useful dmesg. | 00:32 |
| Darxus | Okay. | 00:32 |
| Darxus | What are you looking for in dmesg? | 00:32 |
| RAOF | Anything drm related; adding “drm.debug=0xe” to the kernel command line would be useful. | 00:33 |
| Darxus | Okay. | 00:33 |
| Darxus | So add "nomodeset drm.debug=0xe" to the end of the kernel args? | 00:34 |
| RAOF | Yeah. | 00:35 |
| RAOF | Another thing to check would be the grub→drm handoff; you'd want to remove the “set gfxpayload=$STUFF” stuff when booting. | 00:36 |
| Darxus | Still waiting for the dist-upgrade. | 00:37 |
| Darxus | Okay. | 00:38 |
| Darxus | Rebooting. | 00:42 |
| Darxus | Doesn't look like it includes what you're looking for: http://www.chaosreigns.com/tmp/precise.dmesg.txt | 00:46 |
| Darxus | ah, I typed the drm.debug part wrong, trying again. | 00:46 |
| Darxus | Uploaded over the last one, http://www.chaosreigns.com/tmp/precise.dmesg.txt | 00:49 |
| Darxus | Still doesn't look useful. | 00:49 |
| Darxus | X is still using the vesa driver. | 00:49 |
| Darxus | X log still says | 00:50 |
| Darxus | [ 15.733] (II) [KMS] drm report modesetting isn't supported. | 00:50 |
| Darxus | [ 15.733] (II) GPU only supported with KMS, using vesa instead. | 00:50 |
| RAOF | You've kept “nomodeset” in the kernel command line. | 00:51 |
| RAOF | Which, indeed, will disable kms, which will mean that nothing interesting happens. | 00:51 |
| Darxus | I guess I misunderstood what you wanted me to do. What should I do? | 00:52 |
| RAOF | Remove the “nomodeset” from the kernel command line, add the “drm.debug=0xe” bit, and boot. | 00:55 |
| RAOF | That will, presumably, fail to work correctly, and the dmesg should give an idea as to why. | 00:55 |
| RAOF | Then, try the same thing, but removing the “set_gfxpayload” bit from the grub entry (you can do this from the grub menu) | 00:56 |
| Darxus | Okay, thanks. | 00:56 |
| Darxus | fglrx looks like it works, which is nice. But not useful with wayland. | 00:56 |
| RAOF | Indeed :) | 00:57 |
| Darxus | I neglected to mention when this fails I can't get any usable console :/ | 01:03 |
| Darxus | dmesg isn't written to a file anywhere by default, right? So, init script or something to run it? | 01:03 |
| RAOF | dmesg is sent to /var/log/kern.log | 01:04 |
| RAOF | Well, and also syslog. | 01:04 |
| RAOF | And probably a couple of other places :) | 01:04 |
| Darxus | Ah, okay. | 01:04 |
| Darxus | So just giving you a copy of /var/log/kern.log from a boot where the graphics fails would be good? | 01:05 |
| RAOF | That'd be good. | 01:06 |
| Darxus | Okay. | 01:07 |
| Darxus | http://www.chaosreigns.com/tmp/kern.log | 01:11 |
| Darxus | That's only the boot with the graphics failing. Booted to oneric, renamed that log, booted to precise with drm.debug=0xe, rebooted back to oneric... | 01:11 |
| RAOF | EPERM | 01:12 |
| RAOF | Or, translated through perror: I don't have permissions to view that :) | 01:12 |
| Darxus | Fixed, sorry. | 01:13 |
| Darxus | Apr 1 21:08:55 dancer kernel: [ 10.663848] [drm:radeon_process_aux_ch], dp_aux_ch flags not zero | 01:13 |
| Darxus | Apr 1 21:08:55 dancer kernel: [ 10.663849] [drm:radeon_dp_i2c_aux_ch], aux i2c too many retries, giving up | 01:13 |
| Darxus | I guess that shouldn't cause this problem. | 01:14 |
| RAOF | Yeah. | 01:16 |
| RAOF | radeon thinks it's brought up 1600x1200 on your VGA output. | 01:16 |
| Darxus | And no useful errors? :/ | 01:17 |
| RAOF | The *other* option might be that X is starting too soon - do you have a corresponding Xorg.0.log | 01:17 |
| Darxus | Sure. | 01:17 |
| RAOF | I'm less familiar with how radeon looks when stuff goes wrong than intel, but I can't see anything obvious there. | 01:17 |
| Darxus | http://www.chaosreigns.com/tmp/Xorg.0.log | 01:18 |
| RAOF | Oh. | 01:18 |
| RAOF | And *X* thinks everything worked, too. | 01:19 |
| Darxus | I swear it's a horribly flickering dark purple mess :/ | 01:19 |
| RAOF | I'm sure it is, but it seems that neither the kernel nor X is aware that anything's wrong. | 01:20 |
| RAOF | Did you try dropping the gfxmode bit in grub? | 01:20 |
| Darxus | No. | 01:20 |
| RAOF | Give that a whirl; the framebuffer handoff can confuse things, and may well be the cause here. | 01:21 |
| Darxus | With everything else as defaults? | 01:21 |
| Darxus | Radeon driver version isn't in the Xorg log? | 01:21 |
| RAOF | With everything else as defaults (assuming that your defaults don't include nomodeset) | 01:22 |
| Darxus | Right. | 01:22 |
| RAOF | The version is in the log - 6.14.99 | 01:22 |
| RAOF | Not that that's particularly useful, as we habitually take git snapshots of the ati DDX, since it's (a) usually stable, and (b) has a slow release cycle. | 01:23 |
| Darxus | Worked! | 01:24 |
| Darxus | I just removed the setgfxpayload... line. | 01:24 |
| RAOF | Sweet. | 01:24 |
| RAOF | Please file a bug with “ubuntu-bug linux”. We may need to add your card to the blacklist. | 01:24 |
| Darxus | A blacklist of cards to effectively skip the setgfxpayload stuff? | 01:25 |
| RAOF | Yup. | 01:25 |
| Darxus | Nice. | 01:25 |
| Darxus | What info do I need to provide on the card, just "lspci | grep -i vga" output? Should I attach the kernel log and X log? | 01:26 |
| Darxus | And what should I title the bug? What do you call that blacklisting? | 01:26 |
| RAOF | If you use “ubuntu-bug linux” it'll attach all the relevant information. | 01:26 |
| RAOF | Title the bug something like “graphics fails with setgfxpayload=keep” | 01:27 |
| Darxus | Thanks. | 01:27 |
| Darxus | Then I can finally test out the wayland packages in precise, and attempt to run some stuff that's built against gtk3 with it :) | 01:27 |
| Darxus | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/971204 | 01:30 |
| ubottu | Launchpad bug 971204 in linux (Ubuntu) "graphics fails with setgfxpayload=keep, AMD Radeon" [Undecided,New] | 01:30 |
| RAOF | Darxus: Excellent; I'll ensure that gets looked at by the kernel team. | 01:35 |
| Darxus | Great, thanks. | 01:35 |
| Darxus | I'll be happy to test a fix. | 01:36 |
| RAOF | Oooh, I see you've got a system built by the well-respected “System manufacturer System Product Name”. Second only to that great paragon of computing, “To Be Filled In By OEM”. | 01:36 |
| Darxus | Haha. | 01:37 |
| Darxus | You got something against people putting their own machines together? :P | 01:37 |
| Darxus | http://www.chaosreigns.com/dancer/ <- more detail than you could possibly care about. | 01:37 |
| Darxus | Except pictures :/ Need to fix that. | 01:38 |
| === himcesjf1 is now known as himcesjf | ||
| joumetal | xorg-edgers radeondrigetversion failed because of version mismatch. required 1.17.0 but kernel reports 2.12.0. known issue? | 12:40 |
| jcristau | means you need to load radeon.ko sooner | 12:40 |
| mlankhorst | noon | 13:29 |
| Darxus | I just had a hang where my monitor went off and alt-sysrq reisub didn't work :( I suspect there are more substantial problems between my video card and the radeon driver in precise. | 13:36 |
| Darxus | Just using eog triggered it. | 13:36 |
| === yofel_ is now known as yofel | ||
| alex_mayorga | bryceh: ping | 18:23 |
| alex_mayorga | anyone here that could help fix https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/551668 before 12.04 ships? | 18:24 |
| ubottu | Launchpad bug 551668 in nvidia-graphics-drivers (Ubuntu) "Fn+F5 and Fn+F6 don't modify brightness on Sony VAIO VPCCW (GT 230M)" [Undecided,Confirmed] | 18:24 |
| tjaalton | alex_mayorga: aiui you need to quirk it in the xorg.conf | 18:31 |
| alex_mayorga | tjaalton: Can you dumb down that a bit for me please? | 18:41 |
| tjaalton | alex_mayorga: you need a driver option in xorg.conf | 18:44 |
| tjaalton | don't ask which one | 18:44 |
| mlankhorst | blob? | 18:46 |
| mlankhorst | Option "EnableACPIBrightnessHotkeys" "boolean" | 18:47 |
| mlankhorst | http://us.download.nvidia.com/XFree86/Linux-x86/295.20/README/xconfigoptions.html | 18:47 |
| tjaalton | yeah | 18:48 |
| alex_mayorga | would that work with nouveau? | 18:48 |
| alex_mayorga | I'm using nouveau now | 18:48 |
| mlankhorst | nvidia-graphics-drivers is nvidia blob right? | 18:48 |
| jcristau | mlankhorst: yes | 18:48 |
| jcristau | alex_mayorga: then why are you linking to a blob bug? | 18:49 |
| bryceh | jcristau, the bug he linked to was open against both -nvidia and -nouveau | 18:49 |
| alex_mayorga | jcristau: I put it affects both | 18:50 |
| jcristau | ah. | 18:50 |
| jcristau | so it's just the url being confusing. fair enough, sorry. | 18:50 |
| alex_mayorga | sorry, don't know how to get the nouveau link | 18:50 |
| tjaalton | the nouveau upstream ug was marked as fixed | 18:50 |
| mlankhorst | https://bugs.freedesktop.org/show_bug.cgi?id=31920 | 18:51 |
| ubottu | Freedesktop bug 31920 in Driver/nouveau "Brightness control is erratic (/sys/class/backlight/nv_backlight/max_brightness is wrong)" [Normal,Resolved: fixed] | 18:51 |
| alex_mayorga | I think it's https://bugs.freedesktop.org/show_bug.cgi?id=23023 instead | 18:51 |
| ubottu | Freedesktop bug 23023 in Driver/nouveau "no backlight support in /sys or /proc ; xbacklight not working" [Normal,Reopened: ] | 18:51 |
| alex_mayorga | the other one worked for the original reporter but not much else | 18:51 |
| alex_mayorga | anyhow, thought I could stop by in case any more detail is needed | 18:52 |
| alex_mayorga | the fact is, backlight levels do not work on this laptop | 18:52 |
| alex_mayorga | even if the display shows =( | 18:53 |
| bryceh | related to 819002 maybe? | 18:53 |
| alex_mayorga | bug 819002 | 18:59 |
| ubottu | Launchpad bug 819002 in Linux "Brightness level control is not working properly on Sony Vaio" [Medium,Incomplete] https://launchpad.net/bugs/819002 | 18:59 |
| bryceh | the patch for that bug appears to come from http://code.google.com/p/vaio-f11-linux/wiki/KernelSupport | 19:00 |
| alex_mayorga | bryceh: Looks very similar | 19:02 |
| alex_mayorga | mine is another model though | 19:02 |
| alex_mayorga | bryceh: Got powers on https://bugzilla.kernel.org/show_bug.cgi?id=41652 ? | 19:05 |
| ubottu | bugzilla.kernel.org bug 41652 in Power-Other "Brightness control keys not working" [Normal,Needinfo] | 19:05 |
| bryceh | patchset proposed on platform-driver-x86 via http://www.mail-archive.com/platform-driver-x86@vger.kernel.org/msg02399.html | 19:07 |
| alex_mayorga | How come the keys are caught, OSD shows, but in the end nothing happens? | 19:07 |
| alex_mayorga | Guess kernel devs don't care as long as their mac book pros work, right? ;-P | 19:10 |
| hyperair | maybe kernel hackers just don't buy vaios. | 19:11 |
| mlankhorst | pretty much.. | 19:11 |
| * hyperair wouldn't either. | 19:11 | |
| * alex_mayorga doesn't have much sayin on what he gets for "saturnalia" | 19:12 | |
| bryceh | http://www.mail-archive.com/platform-driver-x86@vger.kernel.org/msg01975.html | 19:13 |
| bryceh | Added support for handle 0x0143 (Vaio SA/SB/SC, CA/CB). Minor corrections included. | 19:13 |
| bryceh | guess that doesn't fix vaoi vpccw though | 19:13 |
| alex_mayorga | bryceh: the patched were never taken, were they? | 19:17 |
| alex_mayorga | The guy seems to have a Launchpad account https://bugs.launchpad.net/~marco-absence | 19:18 |
| bryceh | alex_mayorga, doesn't appear so to me | 19:18 |
| alex_mayorga | What is there to do then? Upstream doesn't seem to care =( | 19:24 |
| mlankhorst | it's not cc'd to lkml.. | 19:25 |
| bryceh | mlankhorst, yeah, presumably because he wanted to finish the v2 set of patches first? I'm not really familiar with the platform-driver-x86 list. | 19:26 |
| bryceh | alex_mayorga, as far as next steps, some random ideas... | 19:28 |
| mlankhorst | reading that mail-archive, there were some technical problems with that patch anyhow.. | 19:28 |
| bryceh | alex_mayorga, 1. contact the patch author, Marco Chiappero, to get an update about the patch and if he plans to re-propose it. (And if he can update it to include your model). | 19:30 |
| bryceh | alex_mayorga, 2. try sweet talking the ubuntu kernel team into building a kernel with that patchset for you to test. This might not be possible though, if there's problems with the kernel or if it's hard to figure out how to apply it to a mainline kernel. | 19:31 |
| bryceh | alex_mayorga, 3. If you feel like hacking on some C code, see if you can figure out which chunk from all those patches provide the backlight fix, extract it and revise it to work with the current kernel, and then verify that bit alone fixes it for you. If so, then propose inclusion of that into the kernel. | 19:32 |
| bryceh | that last one could be rather labor intensive | 19:32 |
| bryceh | alex_mayorga, 4. join the platform-driver-x86 mailing list, and post an email asking for an update on the status of Marco's vaio patchset | 19:34 |
| bryceh | alex_mayorga, meanwhile, I've added my findings to the bug reports and tagged them to get some attention from our kernel team. However I think they'll be more likely to take action if one of the above steps is taken. | 19:34 |
| alex_mayorga | bryceh: Thanks! I'll put those in my to-do | 19:35 |
| cnd | bryceh, RAOF, Sarvatt: the only other input option breakage I was aware of was bug 969495 | 19:48 |
| ubottu | Launchpad bug 969495 in xserver-xorg-input-evdev (Ubuntu) "evdev stopped remapping events" [Medium,Invalid] https://launchpad.net/bugs/969495 | 19:48 |
| cnd | which is invalid, the user was using someone else's evdev and now is using the Ubuntu version | 19:48 |
| cnd | so I think we're ok | 19:49 |
| Sarvatt | cnd: still can't close my lid due to https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/948697 but ya guys touched on that in #ubuntu-kernel earlier | 19:54 |
| ubottu | Launchpad bug 948697 in xorg-server (Ubuntu) "[bcm5974] Xorg crashed with SIGSEGV in valuator_mask_set_double()" [High,Confirmed] | 19:54 |
| cnd | Sarvatt, oh, it causes X to crash? | 19:54 |
| cnd | or is that just an old title | 19:54 |
| Sarvatt | yeah it crashes X | 19:54 |
| Sarvatt | but i have suspend on lid closed disabled, sforshee has suspend enabled | 19:54 |
| Sarvatt | it crashes it after about 8 hours with the lid shut with it sending constant streams of input crap :) | 19:55 |
| cnd | yeah, I see | 19:55 |
| cnd | that's quite the stress test :) | 19:55 |
| cnd | Sarvatt, do you think we should lower the priority of that bug? | 19:56 |
| cnd | I guess it's a normal configuration though... | 19:57 |
| Sarvatt | cnd: done | 19:57 |
| Sarvatt | yeah its specific to this model macbook air with the non default lid close change from what i can see | 19:58 |
| cnd | Sarvatt, a full stack trace with symbols would help too | 19:58 |
| cnd | even better if synaptics and the server are built with noopt | 19:58 |
| cnd | but it's still low priority since we really need a fix for the lid closure issue | 19:59 |
| cnd | and the bug likely won't show up once that's fixed | 19:59 |
| Sarvatt | all the dupes of this one are getting duped to https://bugs.launchpad.net/bugs/933504 which is completely unrelated | 20:02 |
| ubottu | Launchpad bug 933504 in xorg-server (Ubuntu Precise) "Xorg crashed with SIGABRT in __libc_message()" [High,Confirmed] | 20:02 |
| Sarvatt | hey someone with a macbook pro 5,1 hitting it https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/967286 | 20:03 |
| ubottu | Launchpad bug 933504 in xorg-server (Ubuntu Precise) "duplicate for #967286 Xorg crashed with SIGABRT in __libc_message()" [High,Confirmed] | 20:03 |
| Sarvatt | sucks the retracer is removing good info when it dupes to the unrelated bug | 20:04 |
| bryceh | Sarvatt, yeah I hate that | 20:06 |
| Sarvatt | uhoh test rebuild going, libxaw is going to fail with new xutils-dev | 20:08 |
| Sarvatt | oh cjwatson fixed it already | 20:08 |
| bryceh | Sarvatt, it's probably not a huge concern though; looking at the dupes I think we already have independent bug reports for each of those (with better stacktraces) | 20:11 |
| bryceh | Sarvatt, as long as I've worked on X I don't recall ever seeing these types of "double free or corruption" bugs. Certainly never to this volume. Something has to be screwed up in our stack. | 20:16 |
| bryceh | a lot seem to occur in the input layer, and most of those seem to occur in some sort of input deletion | 20:17 |
| bryceh | makes me wonder if the 1.12 input code might be freeing memory already freed by the 1.11 side of the server? | 20:18 |
| === stgraber_ is now known as stgrber | ||
| === stgrber is now known as stgraber | ||
| === Daviey_ is now known as Daviey | ||
| pzanoni | I just love Launchpad´s feature of posting freedesktop bug comments to launchpad | 20:33 |
| cnd | bryceh, hard to say | 20:50 |
| cnd | you mentioned there are dupes with good stack traces? | 20:51 |
| bryceh | cnd, yes a handful | 20:52 |
| bryceh | cnd, want me to sub you to ones that look relevant and have good traces? | 20:52 |
| cnd | bryceh, my subscriber folder is a bit large :( | 20:53 |
| cnd | if you could just paste a one or two here I can take a look | 20:53 |
| bryceh | cnd, alright | 20:53 |
| bryceh | https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/971182 | 20:55 |
| ubottu | Error: launchpad bug 971182 not found | 20:55 |
| bryceh | https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/950162 | 20:58 |
| ubottu | Launchpad bug 950162 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT: double free or corruption, ErrorF (f=0xc69 <Address 0xc69 out of bounds>) at ../../os/log.c:604" [High,Confirmed] | 20:58 |
| bryceh | https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/943880 | 20:59 |
| ubottu | Launchpad bug 943880 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT in __libc_message() from XIDestroyDeviceProperty" [High,Confirmed] | 20:59 |
| bryceh | cnd, ^^ that one has many dupes | 20:59 |
| bryceh | https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/933504 | 20:59 |
| ubottu | Launchpad bug 933504 in xorg-server (Ubuntu Precise) "Xorg crashed with SIGABRT "double free or corruption (out)" from DeleteInputDeviceRequest" [High,Triaged] | 20:59 |
| mlankhorst | fun | 20:59 |
| cnd | bryceh, do we know if any of these still exist after the fix in -0ubuntu6 (or 7, can't remember)? | 21:00 |
| bryceh | cnd, check dates on final comments | 21:01 |
| cnd | yeah, I see now | 21:01 |
| cnd | odd | 21:01 |
| cnd | bryceh, have you seen any good reproduction scenarios | 21:02 |
| cnd | running the X server under valgrind would be very enlightening | 21:02 |
| bryceh | cnd, no the ones we had good repro on I sent your way already | 21:03 |
| cnd | ok | 21:03 |
| bryceh | cnd, here's one that repro's pretty easily and has a good trace, but it's a different bug I think - https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/948587 | 21:04 |
| ubottu | Launchpad bug 948587 in xorg-server (Ubuntu) "hid-wiimote driver causes Xorg crash in GetPointerEvents" [High,Confirmed] | 21:04 |
| cnd | yeah, that looks different | 21:07 |
| cnd | I'm going to run X under valgrind here | 21:07 |
| cnd | just to see if anything obvious shows up | 21:07 |
| cnd | maybe it doesn't crash all the time, but it always attempts to do something bad | 21:07 |
| bryceh | sounds good | 21:08 |
| bryceh | meanwhile, I'll check if any have not tested against latest and prompt them to do so | 21:10 |
| Sarvatt | oh goodie, more SRU paperwork to file https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/968218 | 21:13 |
| ubottu | Launchpad bug 968218 in xorg-server (Ubuntu) "ssh x11 forwarding precise to oneiric causes glibc malloc(): memory corruption" [High,Incomplete] | 21:13 |
| bryceh | Sarvatt, yeah was looking at that last week. is there a fix identified? | 21:14 |
| Sarvatt | yup superm1 says what i put in the ppa fixed it | 21:14 |
| bryceh | great | 21:16 |
| bryceh | Sarvatt, you going to take care of the sru, or shall I? | 21:16 |
| Sarvatt | http://cgit.freedesktop.org/xorg/lib/libXi/commit/?h=libXi-1.4-branch&id=22e9ace88d57803ecda95db7c9355a614db1902a was the fix, i had to extend it to XITouchClass and XITouchValuatorClass because of 1_xi2.1.patch | 21:17 |
| Sarvatt | bryceh: I'm completely bugged out for the day here, will do it tomorrow unless you want to get it in | 21:17 |
| cnd | bryceh, har har, got a segfault while running under valgrind and disconnecting my magic trackpad :) | 21:19 |
| bryceh | cnd, 8-D | 21:19 |
| bryceh | Sarvatt, ok, I might have time later today | 21:20 |
| cnd | we (I) really need to get the build conflict on libxtst-dev removed from synaptics | 21:22 |
| cnd | every time I switch from building synaptics to the x server I have to install/remove it | 21:22 |
| cnd | bryceh, when I run Xorg under valgrind, I get a segfault when a device is disconnected, the mtdev has returned an error from attempting to read an event from the event node, and then we try to log the error | 22:03 |
| cnd | the actual segfault occurs in this line: | 22:03 |
| cnd | sprintf(tmpBuffer, "[%10.3f] ", GetTimeInMillis() / 1000.0); | 22:03 |
| cnd | there is nothing wrong with that, AFAICS | 22:03 |
| cnd | I fear there's some corruption in SIGIO | 22:03 |
| cnd | specifically, when an input event node returns an error from read() | 22:04 |
| bryceh | mmm | 22:08 |
| bryceh | yeah unless tmpBuffer is an invalid chunk of memory | 22:09 |
| cnd | tmpBuffer is: static char tmpBuffer[1024] | 22:10 |
| cnd | so it should be fine | 22:10 |
| bryceh | hmm yeah | 22:11 |
| cnd | I can't see anything that would cause an issue with sigio in mtdev_get though | 22:11 |
| cnd | when it errors out, it mainly just returns the error code directly from read() | 22:11 |
| bryceh | https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/971767 also has a stacktrace passing through GetTimeInMillis() | 22:14 |
| ubottu | Error: launchpad bug 971767 not found | 22:14 |
| bryceh | although I think the problem would have started from CreateCallbackList() in that one | 22:14 |
| cnd | when I remove the error message in synaptics, valgrind no longer gets a segfault | 22:15 |
| bryceh | ar_ptr = <error reading variable ar_ptr (Asked for position 0 of stack, stack only has 0 elements on it.)> | 22:15 |
| cnd | but it doesn't complain about anything else either | 22:15 |
| bryceh | weird | 22:15 |
| cnd | so I can't reproduce the issue | 22:15 |
| bryceh | what about an error message without the GetTimInMillis() call in it? | 22:16 |
| cnd | I'll try it, but it's really just a red herring | 22:17 |
| bryceh | yeah | 22:19 |
| bryceh | bug 971767 looks like it might be a bug deeper down than X | 22:22 |
| ubottu | Error: Launchpad bug 971767 could not be found | 22:22 |
| cnd | bryceh, it doesn't appear to have anything to do with GetTimeInMillis() | 22:32 |
| cnd | I replaced it with "0", which is confirmed when I look at the Xorg.log file | 22:32 |
| cnd | but it still died | 22:32 |
| cnd | so the bug is being hit from within sprintf, where it is given completely valid data | 22:33 |
| bryceh | intriguing | 22:33 |
| cnd | argh, I wasn't looking closely enough at the backtrace | 22:33 |
| bryceh | oh? | 22:34 |
| cnd | http://paste.ubuntu.com/912157/ | 22:34 |
| cnd | I don't think sprintf is signal safe :) | 22:34 |
| cnd | it's not listed as being signal safe in man signal (7) | 22:34 |
| cnd | so we're calling sprintf | 22:38 |
| cnd | then that somehow generates a bad signal | 22:38 |
| cnd | so we are now in OsSigHandler printing a backtrace | 22:38 |
| cnd | which then itself fails | 22:38 |
| bryceh | hmm, grepping for 'signal' in our patches shows only 100_rethrow_signals.patch | 22:39 |
| cnd | I'm going to have to leave it for now though | 22:47 |
| cnd | more important bugs to work on | 22:47 |
| bryceh | can you update the bug report with your findings/theories? | 22:48 |
| cnd | I don't have any :( | 22:48 |
| cnd | I never saw a bug using valgrind that would give me any idea | 22:49 |
| cnd | I just saw the weird bug when it was trying to print a message | 22:49 |
| bryceh | cnd, well, that'd be a finding... | 22:49 |
| cnd | true | 22:49 |
| cnd | bryceh, fwiw, in bug 943880 the stack trace from *after* we fixed the synaptics corruption is from when the server is shutting down | 22:53 |
| ubottu | Launchpad bug 943880 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT in __libc_message() from XIDestroyDeviceProperty" [High,Confirmed] https://launchpad.net/bugs/943880 | 22:53 |
| cnd | while it's not cool, it's also not terrible | 22:53 |
| bryceh | ok | 22:54 |
| bryceh | yeah I figure once apport is turned off a lot of these bugs will "disappear" | 22:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!