[01:05] <hed> quit
[01:59] <lifeless> BenC: are you aware of cpufreq problems ? mine has stopped frequing
[02:23] <BenC> lifeless: I know of an issue, yes
[02:24] <BenC> I thought acpi-cpufreq took over all the CPU's the centrino-speedstep took care of, but it doesn't
[02:24] <BenC> so I need to re-enable it
[02:28] <zul> hey
[02:29] <BenC> hey
[02:30] <zul> heheh...crystal ball..
[02:34] <zul> hey fabbione 
[02:34] <fabbione> hi zul 
[03:40] <bubbasucks> fabbione: yo
[03:48] <fabbione> bubbasucks: hey
[03:50] <bubbasucks> BenC: anything i should try? 
[04:00] <fabbione> bubbasucks: i dunno...
[04:00] <fabbione> bubbasucks: i think ben is the only one that can help now
[05:25] <zul> sweet kqemu has been released under the gpl
[05:26] <pmjdebruijn> indeed, very cool
[05:40] <jwest--> sweet
[06:39] <cjwatson> ioctl(5, FBIOPUT_VSCREENINFO, 0x7fffe749a670) = -1 ENOMEM (Cannot allocate memory)
[06:40] <cjwatson> Any idea why that might be happening? I've been tracing through the fb_ioctl code path and can't find anywhere that could return ENOMEM
[06:40] <cjwatson> FWIW the fb backend in use is vga16fb
[06:44] <mjg59> cjwatson: I suspect the check_var function
[06:44] <cjwatson> oh, hmm, I was looking at upstream source rather than ours
[06:44] <cjwatson> mjg59: yeah, upstream check_var doesn't seem to ever return ENOMEM, but ours can
[06:44] <mjg59> Hm. I'm sure I didn't write that.
[06:45] <cjwatson> looks like making sure xres_virtual == xres and yres_virtual == yres would fix it
[06:45] <mjg59> What are you actually trying to do?
[06:46] <cjwatson> fix a usplash crash
[06:46] <mjg59> Ah
[06:46] <mjg59> Though we don't use vga16 for anything usplashy now
[06:48] <cjwatson> we still do on amd64
[06:48] <cjwatson> and yes, I know I'm getting rid of that
[06:48] <cjwatson> but I'm trying to fix everything I come across before I make it go away
[06:48] <mjg59> Heh. Ok.
[06:48] <cjwatson> in case it bites us sometime in the future
[06:49] <Keybuk> random question; do people run i386 or amd64 on Core 2?
[06:50] <mjg59> I run amd64
[06:50] <mjg59> I know some people run i386
[06:50] <cjwatson> hmm, no, that doesn't fix it
[06:50] <cjwatson> I guess vga16fb just can't do big resolutions
[06:50] <cjwatson> which would make a certain amount of sense
[06:50] <mjg59> cjwatson: That check is upstream
[06:50] <mjg59> What codebase are you looking at?
[06:50] <cjwatson> oh, my linux-2.6.git is out of date then
[06:50] <mjg59> And yeah, vga16fb can't do anything other than 640x400/640x480
[06:51] <mjg59> You can conceivably force it into lower resolutions, but certainly not really anything higher
[06:51] <cjwatson> the maxmem it sets is a heck of a lot smaller than that
[06:51] <cjwatson> it's at most 65536, and requires xres * yres < maxmem
[06:51] <mjg59> In 16 colours only
[06:52] <cjwatson> <=
[06:52] <cjwatson> 256 too, in the tree I've got ...
[06:52] <mjg59> No, that doesn't work
[06:52] <mjg59> Not in any sane way, anyway
[06:52] <cjwatson> ok, but I mean the check would apply to that if it worked
[06:52] <mjg59> I don't think we've ever expected modesetting to work with vga16fb
[06:53] <mjg59> But it comes up in 640x480x16
[06:53] <cjwatson> maybe usplash should behave more gracefully if it can't do the mode-set
[06:53] <mjg59> I thought it was supposed to handle that already?
[06:54] <mjg59> That's why it returns the mode it set, rather than just assuming it got hte right one
[06:54] <cjwatson> this is probably code I added
[06:54] <cjwatson> it worked better elsewhere :-/
[06:55] <cjwatson> I think it was part of teaching the bogl backend how to set resolution
[06:55] <mjg59> Ah
[06:55] <mjg59> Right
[06:55] <cjwatson> I didn't realise that that would fail on some fb backends
[06:56] <mjg59> Well, vesafb is an obvious example
[06:56] <mjg59> You can't set modes at all
[06:59] <cjwatson> perfect, usplash/amd64 resurrected
[06:59] <cjwatson> will upload the bits llater
[06:59] <cjwatson> later
[07:07] <kylem> argh, muppets.
[07:07] <zul> hmm?
[08:32] <kylem> people are such god damned muppets. can they not understand the word ATTACH
[08:34] <zul> hehe
[08:42] <BenC> kylem: I asked lp to maybe do something like "You are trying to create a 9000 line comment...create attachment instead?"
[08:42] <kylem> haha.
[08:42] <kylem> Fuckwit Detector 9000
[08:43] <BenC> the lack of monospace alone makes dmesg in comment crappy
[08:43] <kylem> indeed.
[08:44] <BenC> and don't get me started on lspci in comments :/
[08:44] <kylem> BenC, this one was lspci -vvxxx and -vvvv
[08:44] <BenC> ugly
[08:59] <fabbione> BenC: i know you asked an email.. but can you pull from the gfs2 nmw tree please? pretty please?
[09:00] <BenC> hehe
[09:00] <BenC> what's the gfs2 repo URL?
[09:01] <BenC> fabbione: ^^
[09:01] <fabbione> http://hera.kernel.org/git/?p=linux/kernel/git/steve/gfs2-2.6-nmw.git;a=summary
[09:04] <BenC> fabbione: Pulled
[09:04] <fabbione> BenC: great.. thanks
[09:04] <fabbione> BenC: i will give you GFS1 sometimes next week
[09:04] <fabbione> so i can test both of them properly
[09:05] <fabbione> be aware tho that GFS2 is getting tons of bug fixes because they are in a hurry to release with RHEL 5
[09:05] <fabbione> so we might have to pull from them again
[09:42] <lifeless> BenC: please let me know when cpufreq is back ... this machine is sooo sllooow pinned at 600Mhz
[09:43] <BenC> ok
[09:49] <lifeless> OTOH my battery life on the flight was awesome ;)
[10:13] <bubbasucks> BenC: can i bug you some more?  just wondering what your ID search came up with
[10:36] <jwest--> anything new
[10:36] <jwest--> :D
[10:36] <jwest--> so things are solid with 2.6.20-6.11?
[10:36] <jwest--> :P
[10:48] <lamont> why does 2.6.17-10-server hate my AIC-7902 U320 so much?
[10:49] <lamont> about once a month, scsi goes belly up, and disk I/O starts getting EIO
[10:49] <lamont> recovery is to reboot
[10:49] <jwest--> linux I/O scalability issues again?
[10:49] <lamont> dunno