[00:00] Er... Now it's at i915_suspend+0x7e [00:01] unable to handle kernel paging request at virtual address dfddc040 [00:01] soren: and what's in eax? [00:02] dfdd6000 [00:03] http://people.ubuntu.com/~soren/i915-new.disassembled.txt by the way [00:04] yeah [00:04] just seems to be happening at random spots while we read registers [00:07] mjg59: are you preparing a multiple suspend fix patch? [00:07] jbarnes: I /think/ it's filed [00:08] soren: can you take out the calls to pci_disable_device and pci_set_power_state and see if that helps? [00:08] Sure. [00:11] You're saying this code gets called twice during hibernation? [00:11] yeah [00:13] I can blacklist a module from the kernel commandline, right? [00:14] you can rmmod it first, sure [00:21] Man, this stuff is tedious. patch, compile, boot faulty laptop, copy module, reboot, hibernate. [00:25] Well, if this is a bug due to calling the suspend code twice, it won't fix my suspend problem, I suppose. :( [00:26] (Assuming the double call to the suspend code is not done when it's "just" suspending) [00:26] right, suspend just calls it once [00:27] you see it during suspend too though? [00:27] Now it fails at i915_suspend+0x21d (unable to handle paging request at dfe3501c) [00:27] jbarnes: Nope. [00:27] jbarnes: suspend just fails silently. [00:27] are you using any fb modules? [00:28] like intelfb, uvesafb, vesafb? [00:29] I can't spot any in the list of modules in the oops output. [00:29] ls /sys/modules/fb? [00:29] err /sys/module [00:29] Well, it's hanged right now. [00:29] heh oh yeah [00:30] Do you need more info from the oops output? [00:30] nope [00:30] If not, I can just reboot and look. [00:30] rebooting [00:34] *fb* only matches fbcon [00:35] oh you have fbcon? [00:35] that must mean some other fb stuff is builtin to your kernel [00:35] which kernel are you running? [00:35] The ubuntu one. [00:35] 2.6.24-12-generic [00:35] can you try upstream? 2.6.25-rc7 or so? [00:35] and/or try disabling CONFIG_FB in your current kernel [00:37] soren: also, can you post your lspci -v somewhere? [00:37] jbarnes: I did that an hour ago or thereabouts. [00:37] where? [00:37] 23:41:01 < soren> http://pastebin.ca/958866 [00:37] oops missed it sorry [00:38] No worries. [00:41] jbarnes: I think our i915_drv.c matches current upstream.. [00:41] jbarnes: Or do you mean the entire kernel? [00:42] I meant the entire kernel... it sounds like your i915 is missing a little according to mjg59 [00:42] but mainly I wanted to get the fb stuff out of the equation, you can do that with your current kernel [00:43] if that doesn't work, then upstream would be worth trying, just to isolate it against any ubuntu patches [00:43] Isn't the a kernel command line option to disable fb altogether? [00:43] Like fbcon=no,thankyou? [00:43] dunno how to disable it at runtime [00:43] would be best to rebuild with CONFIG_FB unset [00:45] If I'm using git correctly, our i915_drv.c is identical to Linus's except for a an inb(st01) call in the restore code. [00:45] hm ok [00:46] It's getting late. My debugging skills are starting to fail me :( [00:46] Everything was fine in gutsy, which predates the suspend/resume code in the kernel, afair. [00:46] I should be getting a 855 laptop soon, hopefully I can reproduce & fix [00:47] jbarnes: I have another 855 laptop that doesn't do it. [00:47] soren: yeah, lemme dig up a link [00:47] My Thinkpad X40 suspends/resumes just fine.... I'm not sure if I tried hibernation on it. I forget. [00:48] you could try this patch on your 855 [00:48] http://marc.info/?l=linux-kernel&m=120657458816261&w=2 [00:48] there are enough weird issues with 855 at this point that it's probably best to disable the suspend/resume code in 2.6.25 for them [00:48] Heh.. Yeah, that'll certainly fix it. [00:49] The X40 even hibernates just fine (with unpatched i915.ko) [00:49] cool [00:49] it's nice when it works :) [00:49] It's just the other laptop. It's spethial. [00:49] but something weird is going on with this... it's like the iomap for the registers is disappearing [00:49] My mom says it's ok to be special. I'm not so sure. [00:50] At random times. [00:50] but iounamp breakage should show up elsewhere too [00:51] Well, if the fb suspend code and the i915 suspend code runs at about the same time, that would explain why it happens at seemingly random times (it fails when the fb code unmaps the registers or whatever). [00:52] yeah [00:52] they shouldn't be happening in parallel though [00:52] anyway, if you get a chance to test w/o fb and it works I'd like to hear about it :) [00:52] otherwise I'll try to reproduce when I get my 855 [00:53] Which machine is it? [00:53] it's a dell latitude d500 [00:54] Mine's a uniwill something-something (Taiwanese or Korean thing). [00:54] jbarnes: No idea why fbcon is getting loaded, but there's no fb stuff in the kernel [00:54] And vesafb and intelfb won't bind unless vga= is passed [00:54] ok [00:55] $ grep CONFIG_FB_.*=y /boot/config-2.6.24-12-generic | wc -l [00:55] 32 [00:55] ? [00:55] Some core FB stuff is built in, but none of the actual drivers [00:55] well another thing to try is doing iounmap(dev_priv->mmio_map->handle) at the top of suspend somewhere [00:55] if that bugs & gives you a backtrace it means it was already unmapped which would be bad [00:55] The patch in http://marc.info/?l=linux-kernel&m=120657458816261&w=2 sounds like a good idea to me. [00:56] soren: Yeah, we need that merged. I /thought/ it was in a bug somewhere [01:01] I'll take it for a quick spin, just to be sure. [01:02] soren: please reply to lkml with your results... [01:02] jbarnes: Sure. [01:02] thanks [01:02] mjg59: Oh.. [01:02] mjg59: This box was originally a hoary install. [01:03] soren: Shouldn't matter [01:03] upgraded breezy-> dapper->etc. [01:03] Maybe fbcon is in /etc/modules from ancient times? [01:03] I'll check when it's done booting. [01:03] Ah, yeah, could be [01:03] But fbcon won;t be used unless a driver is loaded [01:03] So it's harmless [01:03] Oh, ok. [01:04] soren: Oops, sorry, was looking at wrong patch. While I agree we want that one, we also want the "avoid double suspend on hibernation" one. Which I'm sure was in a bug. [01:04] Someone here was testing it [01:04] mjg59: tjaalton perhaps? [01:04] Could have been [01:04] Gah... [01:05] Setting irssi's timestamps to UTC is good for having a common reference when looking in my irclogs, but it's not very good for making sure I get some sleep (at least once in a while). [01:05] I thought it was only 1 AM. [01:05] soren: Ha. Sleep :) [01:06] overrated [01:06] <- @ GMT+2 [01:08] mjg59: suspend now works as expected. [01:08] Blimey! Resume does too. [01:09] grep -irl fbcon /etc gives no results, by the way. I've no clue why it gets loaded. [01:09] refcount is 0. [01:09] no aliases. Weird. [01:11] soren: With the disablement patch? Ok, cool. Please push that to Ben for now. [01:12] I suspect we're not going to rescue it sanely in time [01:12] mjg59: Could you do it? power management patches simply look more correct coming from you :) [01:12] soren: Ok. sure [01:12] Thanks. [01:14] soren: #207496 [01:15] This laptop is really asking to be replaced. It's started doing stuff like http://people.ubuntu.com/~soren/borken.jpg recently, too. [01:15] Spontaneously. While still running gutsy, which worked fine for months and months. [01:16] I blame Korean sweat shops. [01:16] jbarnes: I don't suppose you have a patch for aging hardware, too? :( [01:20] soren: yeah, I regularly patch my hw up to the latest circuits [01:20] BenC: #201086 is also helpful [01:20] soren: ^ [01:21] keeps me running smooth since I can fix hw *and* sw bugs :) [01:21] mjg59: That's not the same issue, I think. [01:21] soren: No, but we want it anyway [01:21] mjg59: Oh, right. [01:21] soren: Since you're seeing failure on suspend as well as hibernate, I'm pretty sure it's unrelated [01:21] soren: yeah that's werid [01:21] mjg59: YEah, and mine does't go into an infinite loop. [01:21] weird... looks like the display base is getting hosed [01:21] mjg59: Trust me.. With the fan in that thing, I'd know. [01:22] have you run memtest86 recently? [01:22] jbarnes: Yep. [01:22] soren: I suspect it's not actually an infinite loop [01:22] mjg59: The code is: [01:22] while (1); [01:22] AFAIR [01:22] mjg59: Let me find another bug about it... [01:22] soren: Heh [01:23] I was thinking about this one: [01:23] https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/197064 [01:23] Launchpad bug 197064 in linux "Hibernate fails on Centrino-laptop" [Medium,Triaged] [01:24] specifically https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/197064/comments/12 [01:24] soren: Ah, no, that's a misdiagnosis [01:24] What? There's something on the internet that's not true? I'm shocked! [01:25] jbarnes: memtest didn't find anything. [01:25] Why is dealing with duplicates in Launchpad so hard? [01:26] jbarnes: The machines still works fine. If I hibernate it, it comes up with the desktop as I left it. If I connect to vino, I can work with the desktop etc., etc.. [01:26] I want to say a is a duplicate of b, and c (which is a duplicate of a) should therefore be changed to being a duplicate of c [01:26] Ugh. Can't be bothered at this time of night [01:27] *shrug* [01:27] jbarnes: I totally blame hardware. [01:27] yeah, maybe cpu is overheating or there are some faulting traces now [01:28] jbarnes: I considered heating problems for a while, but sometimes it could be *Really* hot and not do it, and other times it could be just luke warm and do it. [01:29] *shrug* It's served my wife well for a couple of years now and myself for a year before that. It belongs on a shelf. [01:32] jbarnes: Thanks for all your help today. Much appreciated. I'm sure my wife will be thankful, too, seeing as it's her laptop :) [01:37] hello, some people I know were asking if this 2-year-old bug will finally be fixed in hardy: https://bugs.launchpad.net/ubuntu/+source/bluez-utils/+bug/32415 ;) [01:37] Launchpad bug 32415 in bluez-utils "Bluetooth Mouse and Keyboard Broken in Dapper/Edgy/Feisty" [Medium,Confirmed] [01:42] seems like a catch-22 is occuring with hid2hci ;) [01:59] soren: np, hopefully we can fix that bug right soon === Traxer is now known as Traxer|off === Traxer|off is now known as Traxer [08:04] ogasawara_, ping [08:10] ogasawara_, dholbach said i should speak with you about the open kernel bugs, does it helps if somebody has the reporter of the bug if this happens also with a newer kernel? there are a lot of bugs against the dapper kernel and the edgy kernel that nobody touched until now [08:12] juliux: ogasawara_ won't be online for a few hours, she is on the US west coast [08:13] amitk, thxs, i will wait;) [08:14] juliux: bugs against dapper that are still seen in hardy should be marked such - use the "also affects project" in launchpad [08:15] amitk, the problem is atm nobody knows if they also affekt an other kernel version [08:15] amitk, the bugs are not yet touched or triggered [08:15] juliux: in that case you better wait for ogasawara_ to guide you on handling them :) [08:15] ok === \sh_away is now known as \sh [09:01] BenC: Please ping me when you'll be online. About Bug #177895 and Bug #200057 [09:01] Launchpad bug 177895 in linux "Kernel 2.6.24-2 causing ~1000 wakeups by "Rescheduling Interrupts"" [Medium,In progress] https://launchpad.net/bugs/177895 [09:01] Launchpad bug 200057 in linux "HP / Compaq laptops crash with port 0x80 delay write" [Medium,Triaged] https://launchpad.net/bugs/200057 === asac_ is now known as asac [11:28] abogani: I'm here [11:32] JanC: It's not filed against the kernel? [11:35] BenC: Good morning Ben. [11:35] BenC: 200057 Seems to be simple as doing cherry-pick of two commits. Seems also that these commits change something about KVM related stuff so IMHO we should cherry-picked KVM related fix also. [11:35] BenC: 177895 An other cherry-pick fix (is constitued by two revert commits). Already checked and it works on my laptop. Only one problem is that this change /kernel/sched* files a lot. [11:35] BenC: In both cases I don't idea if this is compatible with kernel freeze policy :-( [11:36] abogani: From just reading the basic description, they sound very important [11:37] abogani: Would you be willing to put these fixes into a tree we can pull from? [11:38] BenC: Ok. [11:38] Ok Now it's lunch time! [11:38] abogani: thx [11:39] * BenC gives abogani a Big Mac [12:12] ewww [12:12] abogani: Hi there, looking at bug 177895, which cherry pick fix is there for this? [12:12] Launchpad bug 177895 in linux "Kernel 2.6.24-2 causing ~1000 wakeups by "Rescheduling Interrupts"" [Medium,In progress] https://launchpad.net/bugs/177895 [12:16] BenC: I'm seeing a user report of "[ubuntu lacks] the mpt scsi driver in the boot/install kit" - any chance of getting that fixed for hardy? [12:18] $ gunzip -c /boot/initrd.img-2.6.24-12-generic | cpio -t | grep mpt [12:18] lib/modules/2.6.24-12-generic/kernel/drivers/message/fusion/mptfc.ko [12:18] lib/modules/2.6.24-12-generic/kernel/drivers/message/fusion/mptsas.ko [12:18] lib/modules/2.6.24-12-generic/kernel/drivers/message/fusion/mptspi.ko [12:18] lib/modules/2.6.24-12-generic/kernel/drivers/message/fusion/mptscsih.ko [12:18] lib/modules/2.6.24-12-generic/kernel/drivers/message/fusion/mptbase.ko [12:18] lamont: ^^ [12:19] lamont: that should be the case for anything as far back as edgy (and now 6.06.2 as well) [12:20] that's what I kind of thought... [12:24] cking: I have a one line fix in lum for that btsco problem, good catch [12:24] BenC: great, what is it? [12:25] cking: CFLAGS_snd-bt-sco += $(srctree)/sound/alsa-kernel/include [12:25] in ubuntu/Makefile [12:25] *CFLAGS_snd-bt-sco.o [12:25] BenC: Do you want me to put it in and give it a thorough test [12:26] Yeah, I added it just after the snd-bt-sco-objs line [12:27] BenC: Thanks for the rune, I was unsure if that kind of include path hack was OK. [12:27] cking: We're going to revisit all this junk in prague, but for now, it's perfect [12:28] BenC: Makes sense for now. OK, I will put the change in and see if there are any other hidden issues. [13:10] BenC: Seems to me that $(srctree) point to KSRC DIR and $(src) to SRC DIR of itself sources. Or not? === \sh is now known as \sh_away [13:11] cking: Are you around? [13:12] abogani: you may be right [13:13] but ubuntu/sound/ uses $(srctree) already to point to those headers, so I assume it's correct [13:13] could be unneeded in that usage though === \sh_away is now known as \sh [13:19] I suppose that this is a problem. If $(srctree) point to KSRC when you compile gcc will use pcm.h in /usr/src/linux-headers-2.6.24-12/ that are different by pcm.h in LUM-DIR/ubuntu/sound/alsa-kernel/include/pcm.h [13:20] Or i misunderstand something? :-) [13:27] I said a silly thing? :-) [13:28] I've seen much talk about dkms, but haven't looked into the details of it. Is it much different than what we could accomplish with a kernel-img.conf postinst_hook call to module-assistant? [13:33] I realise that calling m-a from a postinst won't work, but I'm sure something could be put together to make it fly. [13:33] hi [13:33] has there been a new kernel released for hardy? [13:35] adinc: https://launchpad.net/ubuntu/+source/linux is the current release. [13:37] rtg: You're back? [13:37] soren: its my ghost typing :) [13:37] * soren hides [13:38] rtg: Welcome ghost of Tim. :) [13:38] Have any of you guys looked into dkms? [13:43] soren: dkms has been on my todo list for months. I know its well supported by mdomsch et al. [13:46] rtg: How does it compare to module-assistant? [13:47] soren: I've never used m-a, so I could not venture an informed opinion. [13:47] Ah. [13:49] Well, e.g. kvm provides a kvm-source package that contains the source for the kvm modules. m-a can do all of downloading that package, downloading the kernel headers for your kernel, compile the modules against said kernel headers, generate a .deb with the modules, and finally install it. When its working as expected (which it usually does, actually), it's a simple matter of calling "sudo m-a a-i kvm". [13:49] rtg: thank you very much, can i also find out which modules are the latest released? [13:50] rtg: Is that about the same as what dkms offers? [13:50] adinc: https://launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24 [13:50] soren: dkms (as I understand it) will rebuild itself against current headers each time the kernel is updated. [13:51] rtg: So adding a call to m-a whenever a new kernel is installed makes it about equal? [13:51] soren: in my uninformed opinion, yes. [13:52] good morning [13:52] rtg: Wonderful. Thanks. (I'll keep your disclaimer in mind. Don't worry) [13:52] soren: it would be nice to have _one_ way of doing these kind of updates. [13:52] I never got the hang of using m-a [13:52] rtg: Since you are just back to ask. ;-) But maybe BenC and amitk could have a look, too. I had a look into bug 134660 and I had the feel that it might be better to stay with the rt2x00 driver in the kernel. Gutsy had it in lum and not any legacy ones. So I prepared a patch that would update the driver to latest upstream code (seehttp://kernel.ubuntu.com/git?p=smb/ubuntu-hardy.git;a=summary) [13:52] I spent days trying to get a package built that m-a cound consume [13:52] Launchpad bug 134660 in linux-ubuntu-modules-2.6.24 "Ralink rt2400 / rt2500 / rt2570 / rt61 / rt73 do not work out of the box in Gutsy/Hardy" [High,Confirmed] https://launchpad.net/bugs/134660 [13:52] and gave up and just ported dkms into Ubuntu/Deb [13:53] mdomsch: Heh.. There are quite a few useful examples out there. kvm and open-vm-tools to name a few that I've had the pleasure of dealing with. [13:53] soren, see how dkms drops files into /etc/kernel/postinst.d/ to be executed as a trigger when the kernel is updated [13:53] m-a could do likewise [13:53] Precisely. [13:53] fedora does this now too, yea! [13:54] mdomsch: dkms keeps an entire kernel tree somewhere, correct? [13:54] no [13:54] Ok. [13:54] soren: it's basically m-a but portable [13:54] dkms presumes you have kernel-source installed visible at /lib/modules/$kernelversion/build [13:54] So twice in one day, I've found something on the internet, that's not true. I'm *shocked*! [13:54] rtg: welcome back, you survived! :) [13:54] rtg: does this mean you will be on the call in 5 minutes? :) [13:54] BenC: "portable" as in distro agnostic? [13:54] soren, dkms keeps a tree of the source to the modules it's managing [13:54] soren: right [13:55] smb: the rt drivers from the serial monkey website should go into lbm since they conflict with PCI/USB IDs. [13:55] BenC: its too early for the kernel call isn't it? [13:55] rtg: we have lum setup in module-init-tools to override the kernel ones, right? [13:55] mdomsch: Ok. [13:55] They sound pointlessly similar :) [13:55] rtg: well I moved it because it conflicted with another call that actually got canceled this morning [13:56] rtg: not knowing you would be able to make it [13:56] BenC: oh, can do. [13:56] BenC: the usual numbers? [13:56] rtg: welcome back, btw [13:56] rtg: yeah [13:56] rtg: I have a few patches for alsa that need to be applied (agenda for the call) [13:57] BenC: you cannot believe how much email I accumulated. [13:57] rtg: Oh, I can...if I were away for 3 weeks, I'd have to just delete everything and start fresh [13:57] BenC: is that a kernel call for team or something else? [13:57] would be roughly 10k new emails in that time [13:57] smb: vendor call [13:58] BenC: ah ok [13:59] i've installed my custom kernel for testing, now i removed it again and apt gives errors when i try to install any other package, it says cannot find /lib/modules/2.6.25-rc6-custom which was the modules for the kernel i build. how can i fix this quickly? [14:00] mdomsch: How do you handle the need to have the kernel headers installed at the kernel image's postinst time? [14:00] rtg: welcome back [14:00] adinc: no idea...this is a better question for #ubuntu [14:00] zul: thanks [14:00] soren: the trigger is on the kernel-headers install, not the kernel image [14:00] rtg: Yeah, welcome back, Tim! Great to have you back! [14:00] soren: so it will build modules for any headers you have installed, rather than any kernel [14:01] rtg: The thing I am not sure is whether the legacy drivers from serial monkey are the way to go since the rt2x00 stuff in kernel and from serial monkey seem to be the same and the one that is more developed. But maybe I am just conused... [14:01] BenC: Wow..That was embarassingly obvious. [14:01] :) [14:01] soren, it's a nasty hack in ubuntu I admit [14:01] the same hook is invoked twice - once after linux-image is installed, and once after linux-headers is installed [14:02] because I can't know the ordering [14:02] in Fedora, I do it in an rpm %posttrans hook, which runs after all the packages in the transaction are finished being installed [14:02] You can dpkg-trigger your way out of that. [14:03] oh? [14:04] Yeah. Each of the postinst will call a trigger, and this trigger will do the actual stuff at the end. [14:04] See e.g. /sbin/ldconfig (it's shell script these days) [14:05] hi, how will you call the kernel with 2.6.24.4 base? [14:05] -13? [14:06] mdomsch: Each will call "dpkg-trigger --no-await somerandomname" or something. dkms will "register its interest" in this trigger and thus be called after all packages are done being configured. [14:07] mdomsch: /var/lib/dpkg/info/libc6.triggers has "interest ldconfig". It means that whenever dpkg-trigger ldconfig has been called, libc6's postinst will be invoked as "$0 triggered" (iirc). [14:07] ah yes [14:08] I looked into those [14:09] I forget if I had problems or if I just got sidetracked [14:09] probably the latter [14:10] Heh. [14:10] so: when will be a new kernel based on 2.6.24.4 and how will it be called? [14:11] Kano: Dude... Calm down. [14:13] hi juliank [14:14] Kano: hi [14:19] Kano: It will be called -13 if it changes ABI. Otherwise it won't be. [14:20] well it will change anyway as you disabled 2 ide drivers, didnt you [14:20] at least the ones which are really needed [14:21] No, that doesn't change ABI [15:13] * The update-modules command is deprecated and should not be used! [15:13] go nvidia-kernel-common! [15:19] smb: the serialmonkey code used to be legacy only, but I see they've updated the web site to indicate that rt2x00 is mainstream. Perhaps we should evaluate dumping them in lum if they are demonstrably better then whats in the kernel. [15:26] rtg: I had the impression that they now do a lot in the kernel as well. But maybe I have a closer look at the rt2x00 code on serialmonkey to see [15:27] smb: it looks like the web site code is a superset of the kernel code, e.g., enhanced with bug fixes (at least that is according to the web site comments) [15:28] rtg: Definitely right as far as 2.6.24 is concerned. There were ~60 patches to it in the meantime [15:29] smb: so, are you thinking about spinning a version of lum with these drivers? [15:33] rtg: That was the point I became unsure. Is it better to have the latest serialmonkey stuff in lum (or lbm) or pull the latest kernel code. With the latest kernel code we would be closer to upstream but might get ABI problems so maybe it is better to do it in lum/lbm [15:34] smb: I would do it in lum so as to continue a maintain a relatively virgin kernel source code base. [15:35] rtg: hm, right. and i guess updates there are simpler to handle than in the kernel [15:36] smb: indeed [15:37] * smb starts the lum patchwork [16:08] BenC: a handy site posted by jgarzik: http://linux-ata.org [16:08] rtg: Do you have an Intel-graphics M1330? [16:09] mjg59: the only one we had (or BenC had) was sent back for repair. [16:09] mjg59: we have other Intel-graphics based laptops. [16:10] rtg: Hm. No, got a complaint specific to the M1330. [16:10] mjg59: mine is nv based. [16:10] Yeah, so is Ben's [16:10] Anyway, thanks! [16:11] mjg59: np [16:24] * lamont grumbles at hardy vs nvidia [16:25] how do I get the good screen resolution back again? [16:25] lamont: is it actually using nv or vesa? [16:26] Driver "nv" [16:28] you could try the package here https://edge.launchpad.net/~tjaalton/+archive [16:28] there's a patch from fedora which could help === \sh is now known as \sh_away [16:33] tjaalton: I imagine a server restart is required for that, yes? [16:33] right [16:34] ok. brb [16:36] tjaalton: the heart of the issue is that the preferences/screen resolution widgit doesn't even show 1680x1050.. [16:37] lamont: What does it have? [16:37] all the way up to 1280x1024 :( [16:37] lamont: also, what's the output of xrandr ? [16:38] 02:0b.0 VGA compatible controller: nVidia Corporation NV34GL [Quadro NVS 280 PCI] (rev a1) [16:38] lamont: Yeah, so nv is picking the wrong set of modes [16:38] xrandr stops at 1280x1024 as well [16:39] lamont: is it a toshiba? [16:39] HP workstation [16:40] ok.. [16:50] lamont: did it work in gutsy? [16:50] yes [16:50] hrm [16:50] I just upgraded and my screen is now very crowded-feeling... [16:50] time to blame the server it seems.. [16:58] and no changes in /etc/X11/xorg.conf [17:38] mjg59: ogasawara_ asked me to apply http://launchpadlibrarian.net/12911605/disable_pre_915_drm_pm.diff, but it looks garbled. [17:52] lamont: hum, you could try fedora9 beta livecd to see if the new xserver gets the correct resolution :) [17:52] actually, I'm not sure that gutsy did either, now that I think about it more [17:53] I'll see if I get where I have enough bandwidth to make fetching fedora9 live worthwhile === mjg59` is now known as mjg59 [17:57] rtg: Hm. What do you think's up with that patch? [17:58] lamont: at least F9b got a better resolution (12x10, hardy does 8x6) with vesa on a GF7050PV [17:59] mjg59: a line is missing, there is bogus line feed, etc. I could do it by hand, but we ought to have the right bits attached to the LP report. [17:59] rtg: It's certainly the right patch [17:59] And that's what hit lkml [18:00] mjg59: I agree the code looks right. [18:00] but the diff attached to the LP report is malformed, thats all. [18:01] rtg: What's the bug number again? [18:01] Bug #207496 [18:01] Launchpad bug 207496 in linux "Disable DRM suspend/resume on pre-915 Intel chips" [Medium,Triaged] https://launchpad.net/bugs/207496 [18:02] rtg: http://launchpadlibrarian.net/12923810/disable_pre_915_drm_pm.diff [18:03] mjg59: http://launchpadlibrarian.net/12911605/disable_pre_915_drm_pm.diff is what I'm looking at. [18:04] are the paths relative to the user login? [18:04] rtg: No, I just uploaded a new diff [18:04] mjg59: oh, duh. [18:04] :) [18:07] mjg59: applied. [18:10] rtg: Thanks [18:40] mjg59: Hi Matthew, I saw the diffs for Tim and just got notified of bug 207615. Is there a chance this is a very similar problem? [18:40] Launchpad bug 207615 in linux "[hardy] beta can not hibernate successfully with 965GM" [Medium,Triaged] https://launchpad.net/bugs/207615 [18:45] smb: No - that's the issue where the suspend methods are called twice on hibernation [18:46] smb: I think there's already a patch filed for that [18:47] mjg59: in drm or the driver? The only patch in drm I am aware of since then is "drm: Fix race that can lockup the kernel" [18:48] smb: #201086 [18:48]