[01:23] hey so I'm having some real weird problems with either compiz or x, anyone got a minute to help? [02:23] the failure to start and kicking me to a garbled failsafe login is even happening with edgers now on all the kernels, every time i have to fsck it happens === Sarvatt_ is now known as Sarvatt [02:24] gdm exit status 1 message then failsafe starts === Sarvatt_ is now known as Sarvatt [06:33] Sarvatt: What would you think of getting xorg-edgers mesa trunk to build a gallium package that dpkg-divert'ed the necessary bits? [06:35] Because nv40 gallium is sufficient to run compiz at (annoyingly) better than i915-speeds, with only minor visual glitches :) [06:44] what bits need to be diverted? [06:47] As I understand it, libgl mostly. [06:49] I'm moderately sure that the gallium libgl is incompatible with the normal mesa variant. However, Sarvatt is the one who'se looked into it most closely. [06:51] Mmmmmm. Wobbly windows is an excellent example of where nouveau doesn't quite work :) === RAOF_ is now known as RAOF [10:32] tseliot: you are certain that there is no specific driver package for the drm package that can be compiled? [10:32] drm driver [10:32] metellius: I wish there was one :-/ [10:32] it comes with the kernel [10:33] * tseliot nods [10:33] I see [10:33] I guess I'll have to continue the kernel compilation process then... I paused halfway, thinking there might be another way [10:33] * tseliot 's attemps to make a DKMS package to update drm failed miserably [10:35] is it (relatively) easy to do the whole kernel compile on another (also 32bit) karmic pc and copy the result over to my laptop? [10:36] check https://help.ubuntu.com/community/Kernel/Compile [12:11] bryce, hi [12:13] ara: I think he's still asleep ( ~4 AM there) [12:13] tseliot, ok, it was regarding my bug https://launchpad.net/bugs/496497 [12:13] Ubuntu bug 496497 in xserver-xorg-video-nv "[nvidia] After upgrading to Lucid from Karmic, X crashed " [Undecided,New] [12:14] tseliot, I enabled nvidia 185 and it removed xorg-xserver package [12:14] nice [12:14] ara: that's because we don't have an nvidia driver that works with lucid's X yet [12:14] ara: I'm working on it. I've been busy with oem stuff [12:15] I'll upload new drivers this week [12:15] tseliot, nice :) [12:15] tseliot: are you renaming it as well? [12:16] tseliot, can you tell me when you're done, please? [12:16] ara: sure [12:16] tjaalton: we didn't come to an agreement about the new names, did we? [12:16] see pitti's objections in the blueprint [12:18] tjaalton: the blueprint is here: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-xorg-proprietary-drivers [12:18] thanks, reading [12:18] * tseliot -> lunch [12:21] tseliot: well, superm1 has a point, it can be done [12:21] hmm wait, I need to think this over :) [12:42] yeah, I don't think simple package relationships are enough to make it work correctly [12:42] and relying on update-manager isn't enough [12:54] here's an idea; ignore all crash bugs from the blobs, where the stacktrace points to libGL or the driver [13:04] tjaalton: right we'll still need something like nvidia-common in some cases [13:04] tjaalton: what's the purpose of your idea? [13:09] tseliot: we can't do anything about the crashes [13:09] they just clutter up the buglist [13:10] tjaalton: aah, so it wasn't related name schemes in any way [13:10] no :) [13:11] ok, I think it's a good idea then ;) [14:23] bryce_: your totals graph doesn't include private bugs, which means ~150 bugs more :) [14:24] those won't show up on searches either, so they just need to be made public in order to be visible [16:01] RAOF: nice, you can run compiz on nv40? it just freezes here on nv50 :( [16:38] where is the "Dropping master" message that writes over top of the plymouth splash right before X starts coming from? [16:39] hmm havent seen debian/patches/02_silent_master.diff in libdrm before [16:44] Sarvatt: you might want to ask Keybuk about that [16:57] thanks, found it though, its libdrm and that patch thats not in git removes it [16:58] i pushed the 2.4.14-1ubuntu2 release changes to libdrm git [17:33] btw, noticed we're building r600 with mesa now, does that even work with libdrm 2.4.14? [17:37] ah i was remembering the versions wrong, whole bunch of libdrm releases when I wasn't around [17:38] heh, right [17:38] thought 2.4.14 was 2.4.12 [17:40] Sarvatt: 2.4.14 lacks the 3D ioctl support for r6xx/r7xx gpus but otherwise it should work [17:41] wait, I'm confusing it with the kernel drm [17:44] morning [17:44] morning bryce [17:45] wish they didnt sneak in a bunch of buggy intel libdrm changes right before 2.4.16 released :D [17:45] morning bryce! [17:59] hmm control+alt+fx keys arent working from a vt to switch back to X, evdev getting suspended on vt switch with the udev change maybe? [18:00] chvt 7 works fine if i log in [18:02] have you upgraded to 2.3.2? [18:02] yeah but i havent restarted x since then, will try now [18:03] it fixed my booting problems [18:09] control+alt+f7 still doesn't work from a VT [18:10] i get [ 78.329930] (II) "AT Translated Set 2 keyboard": Device reopened after 1 attempts. after i chvt 7 to get back is why i was thinking of the udev stuff [18:14] ok [18:21] oddly, on my -ati system running Karmic, monitor power savings had started working perfectly the last couple months of Karmic, but in the last week or two has not been powering off the monitors anymore [18:21] wonder what'll happen when I go to lucid ;-) [18:24] *boom* [18:24] :) [18:26] yeah most likely [18:47] they are making it so we have to have libdrm headers actually get installed now, intel won't build against linux-libc-dev headers unless they come from a 2.6.33 kernel.. ugh [18:48] edgers, bah :) [18:48] i stopped using it because intel's been so unstable for the past 1.5 months [18:49] but if we pull in 2.10 later... [18:49] there probably will be a 32.x [18:50] its too big to go to stable i believe and its a new feature not a fix :( [18:50] (KMS overlay support) [18:51] then the kernel team will pull it [18:53] wonder what debian is going to do, they cant pull in 2.10rc2 into experimental [18:54] oh they're on a 2.9.1 still, thought they had 2.9.99.901 already [18:56] hyperair: i think its because of the pm-utils 1.30rc1 dropping hal quirks [19:00] 98smart-kernel-video is gone, im not sure how it does things now [19:00] it had add_parameters --quirk-no-chvt in there before though [19:01] i dont get a vt switch suspending though [19:02] ah its in 98-video-quirk-db-handler now, i'm not sure but it looks like it checks the vendor and device id's now though to figure out quirks? [19:04] Sarvatt: the intel-gfx people said that the kernel chvts anyway [19:04] hyperair: try pm-sleep --quirk-no-chvt manually? [19:04] Sarvatt: i checked, pm-utils is't the cause of the chvt [19:05] ah ok [19:05] Sarvatt: when i did echo mem > /sys/power/state, it chvt'd as well [19:06] if i get a chvt i dont even notice it, screen goes off the second the fan and power light go off [19:26] yeah that's how it is for me when i'm on single-head [19:27] ahh gotcha, i've never run multihead on this thing [20:29] bryce, would you mind committing this to git? i can't seem to get to debian git from where i'm at right now behind some proxies. i'm going to upload it shortly to lucid [20:29] http://pastebin.com/f588376f [20:30] superm1, sure [20:30] thanks [20:36] failsafe fails when kms is already in use [20:36] at least on my intel [20:36] fails in what manner? [20:36] same here [20:36] no picture [20:36] garbled screen [20:37] is it because vesa is being loaded? [20:37] I can change the vt to a virtual console, but still nothing on screen. when changing back to the vt where X should be running, I see what the previous vt had [20:37] probably [20:38] dunno if fbdev would work better [20:39] could we detect kms in some fashion, and make it not force vesa in that case? [20:39] btw, why did it go into failsafe mode to begin with? [20:46] tjaalton, I'd tried fbdev early on but found it didn't work right on some cards [20:49] bryce: evdev crashed for some reason, the new version seems to work [20:49] well, intel/ati/nv should not use vesa then :) [20:50] sorry, nouveau [20:52] mm [20:52] tjaalton, could you file a bug against xorg (and marked wishlist) to make failsafe-x use fbdev in these cases, and assign to me so I don't forget? [20:54] yep [20:54] I need to test fbdev first :) [20:55] otherwise I'd just let the server pick, if fbdev doesn't work [20:55] afk-> [21:02] when i change to a vt it goes black, and i cant change from vt to x no matter what here without doing it manually. as for why it goes failsafe at all the only thing i've been able to figure out is it happens when i need to fsck on my own kernels. but with the ubuntu 2.6.32-7 kernel i get failsafe 50% of the time pretty much consistently for no apparent reason.. [21:05] can i just edit /etc/X11/xorg.conf.failsafe to use fbdev to see if it works any better, or is that set somewhere else? [21:05] dont know if i just have old stale files lying around [21:06] Sarvatt, yeah edit it there (or leave Driver blank) [21:06] oh yeah i get a gdm stopped with exit status 1 message before the garbled failsafe starts [21:06] the places to look for error messages are the Xorg.0.log[.old], dmesg, and /var/log/gdm/ [21:07] yeah failsafe-x shuts down gdm when it starts up [21:07] i dont get any logs there during failsafe, looked everywhere i could [21:07] (in the past, if it didn't, gdm would just try to respawn X; dunno if it'd still do that or not) [21:07] its only got the good boots [21:07] hmm weird [21:08] I wonder if gdm has a verbose or debug mode [21:09] failsafe_log=${BPX_LOG:-"/var/log/gdm/failsafe.log"} [21:09] hmm wonder why i dont have one [21:10] serverargs="${serverargs} -br -once -config $xorg_conf_failsafe -logfile /var/log/Xorg.failsafe.log" oh ok theres the xorg log [21:15] this ones using edgers but i got the same problem on both http://paste.ubuntu.com/341434/ [21:15] going to try out fbdev, i'm not using edgers anymore [22:12] thats odd, switching it to fbdev made it load intel with swrast? [22:13] sudo tune2fs -C 34 /dev/sda1 then reboot gives me failsafe 100% of the time on any kernel btw, max mount count before checking for that partition is 34 [22:14] Sarvatt, hmm, and no error messages as to why? [22:14] tjaalton, what's the status on xf86-input-wacom? Does it just need a MIR or is there more to be done? [22:16] i dont see anything at all, plymouth shows the graphic and theres no feedback that a fsck is even happening outside of the hdd light going. i'll try without a splash [22:18] it faded to white for a second then came up with the failsafe X menu though, I picked use low resolution mode for this session and it started up and the logs look normal outside of it using swrast [22:20] well I guess it used xorg.conf for some reason instead of xorg.conf.failsafe, Xorg.0.log says it did at least [ 0.021742] (==) Using config file: "/etc/X11/xorg.conf" [22:21] ah old log even though the timestamp is current.. what the heck [22:22] http://paste.ubuntu.com/341471/ [22:23] (EE) FBDEV(0): FBIOPUTCMAP: Invalid argument [22:23] weird [22:24] maybe an abi mismatch? [22:25] Provides: xserver-xorg-video-6 [22:25] its working great [22:25] way better than vesa ever did and at native resolution [22:28] Hm. If tselliot comes back in, point him at nouveau-kernel-source as a template for using dkms to do drm updates. [22:30] RAOF, maybe drop him an email? [22:31] Let's see if I can find his email address... [22:33] alberto.milone@canonical.com [22:33] switching to vt8 to check on the error messages when your control+alt+f-keys dont work from a vt = bad idea :D [22:33] thats the 8th reboot in a row i've gotten failsafe though forcing a fsck, pretty safe to say its always gonna happen [22:34] Thanks. Thta's easier :) [22:36] Sarvatt, hmm so the fsck is stealing the vt, and gdm is probably crapping that it can't take it to start up X, or some such [22:36] however I would think the gdm logs would mention something about that if this is the case [22:37] http://sarvatt.com/downloads/failsafeX-backup-091214172957.tar [22:40] is failsafe x supposed to start on vt2? [22:40] it shouldn't care what vt its on [22:41] [ 0.000000] (WW) xf86CloseConsole: KDSETMODE failed: Bad file descriptor [22:41] [ 0.000049] (WW) xf86CloseConsole: VT_GETMODE failed: Bad file descriptor [22:41] [ 0.000073] (WW) xf86OpenConsole: VT_GETSTATE failed: Bad file descriptor [22:41] bingo [22:41] Fatal server error: [22:41] Server is already active for display 0 [22:41] ah yeah same log i was looking at [22:41] yeah this is looking like gdm is trying to fire up X on a specific vt and getting a 'bad fd' error [22:41] and crapping itself [22:42] failsafe-x is less fussy about what vt to use, so just picked the first unused one I guess (vt2) [22:42] perhaps the gdm upstart job needs to be given smarts to detect if a fsck is going on, and block on that [22:45] i think there was just a change in the fsck routine at boot in the past few days because i saw Keybuck talking about it in another channel, something about running alot of things in parallel during a fsck and letting the kernel scheduler sort it out and booting faster [22:46] i have no clue though, lemme see if it still happens without plymouth [22:47] nevermind I know it does, didnt have it installed yesterday when i first noticed it [22:59] ooh brief visual corruption there [23:01] oh the failsafe x archive log option doesnt add Xorg.failsafe.log to the tar [23:01] bryce: does upstart have sufficient clue to say "/home is available" whether it's a separate mount or not? If not shouldn't it be waiting for all local filesystems to be mounted? [23:04] in fact shouldn't gdm always start after local mounts are done? [23:11] why local? nfs /home should be there, too, no? [23:13] a fair point, I was only thinking about the fsck case [23:15] Sarvatt, right there should be no point - that's just the log for the failsafe session itself, which by definition is fine if the user was able to get in and generate the tar in the first place ;-) [23:16] ah good point, i was just going to file a bug using the files in there and was thinking of it that way :D [23:16] Ng: beyond my upstart-fu... I assume it ought to be able to either detect if the mounts are there, or test if vt7 can be used, but I really have no clue [23:16] I'd suggest filing a bug report but probably keybuk would just close it as wontfix [23:18] heh [23:19] should xinput stuff be working atm in lucid? [23:20] my trackpoint isn't showing up [23:20] it works though [23:20] I just can't poke at its properties [23:21] xinput should be working afaik [23:25] aha, got it, the trackpoint's properties are on PS/2 Generic Mouse and I just need to include " in some of the names [23:25] no more trackpad \o/ [23:30] bryce: should I file a bug against xorg or gdm or something else even about the fsck thing? [23:30] * Sarvatt doesnt know what the problem is even [23:33] Sarvatt, mm [23:34] Sarvatt, probably the change needs to go to gdm's upstart script [23:36] Sarvatt, oh you know what, this reminds me of a bug I ran across [23:36] Sarvatt, try commenting out the line in gdm.upstart that refers to tty7 [23:36] and tty-device-added KERNEL=tty7 [23:37] maybe you could check if KMS is in use the same way pm-utils does before picking the fallback_driver in /etc/gdm/failsafeXServer? [23:37] or if it is missing try adding it [23:37] how does pm-utils do it? [23:37] using_kms() { grep -q -E '(nouveau|drm)fb' /proc/fb; } [23:38] Sarvatt, would you mind filing a bug against xorg assigned to me, suggesting that? Sounds like it should be straightforward but probably I won't get to it until after the holidays [23:38] cat /proc/fb [23:38] 0 inteldrmfb [23:38] okie [23:43] grep -q -E '(nouveau|drm)fb' /proc/fb && echo "yes" [23:43] yes is what I meant to paste there [23:52] Sarvatt, https://bugs.launchpad.net/bugs/491162 [23:52] Ubuntu bug 491162 in gdm "gdm does not start X unless remove "tty-device-added KERNEL=tty7" from upstart gdm.conf" [High,Fix released] [23:56] ohh [23:58] i heard about that bug but didnt read it, guess it should be worked around when the new mountall is uploaded