[01:31] <zul> heylo
[03:10] <zul> heylo
[04:44] <fabbione> hi zul
[04:47] <fabbione> BenC: ping?
[04:47] <BenC> hey
[04:47] <fabbione> yo
[04:47] <BenC> responding to pitti now
[04:48] <fabbione> BenC: yes i saw the mail and answered
[04:48] <fabbione> i am going to take off for a week
[04:48] <fabbione> so i can't do it
[04:48] <BenC> ok
[04:49] <BenC> dapper is pretty squared away except for one
[04:50] <fabbione> yeah
[04:50] <fabbione> but it's a good idea to always double check
[04:50] <fabbione> it won't the be first time that something pass unseen
[04:50] <mjg59> BenC: Intel 3945 drivers should be appearing at some point, but probably not until end of Feb/beginning of March
[04:51] <fabbione> or that something that's supposed to be vulnerable is not
[04:53] <BenC> fabbione: I checked dapper source tree for the ones that are supposed to affect it, and the code is patched
[04:53] <BenC> also, the last one that affects hoary/warty may be irrelevant, since it only applies to numa configurations
[04:54] <fabbione> BenC: we still want the source to be patched tho
[04:54] <fabbione> we don't know if somebody is using our sources on NUMA
[04:54] <fabbione> even if i seriously doubt it
[04:55] <dilinger> BenC: so the dapper kernel is pretty much finalized?  time for me to start playing around w/ it on machines for testing purposes?
[04:56] <BenC> dilinger: finalized isn't a good word
[04:56] <BenC> it's stable though
[04:56] <dilinger> ok
[04:56] <BenC> and you should have been testing it all along :)
[04:56] <dilinger> i'll give it a week ro two, then
[04:57] <dilinger> heh.  well, the machines i have to test with, some i would rather not have to recover
[04:57] <BenC> fabbione: oh, I found out that the -server kernel crash is caused by alt-smp...if I disable that, it boots fine...trying to find the cause now
[04:57] <dilinger> like my laptop
[04:57] <fabbione> BenC: ah cool
[04:57] <BenC> so far no one has reported that dapper totally broke their system
[04:57] <BenC> dilinger: I suggest trying a livecd boot, and if that works, upgrade
[04:58] <dilinger> well, i was just going to try the kernel and a few other packages, w/ a breezy system
[04:58] <dilinger> i don't really want to upgrade completely to dapper
[04:59] <dilinger> not until i become a developer and can actually fix broken stuff.. filing bugs that sit in the BTS isn't all that fun
[05:00] <fabbione> dilinger: you will pull in too much
[05:00] <fabbione> better you become a developer and fast :)
[05:00] <dilinger> i have a server running breezy w/ a dapper rc(4?) kernel, plus dapper udev
[05:06] <BenC> fabbione: oh, and I found out that alt-smp wasn't completely enabled on x86_64
[05:07] <fabbione> BenC: is that why my k8 dies on heavy load?
[05:07] <BenC> the lock's were getting nop'd, but the complex smp (spin_lock's) weren't getting nop'd
[05:07] <BenC> is it up and smp?
[05:07] <BenC> up or smp I mean
[05:07] <fabbione> it's up, but it just slows down hell of a lot
[05:08] <fabbione> it takes a bit and resurrect again
[05:08] <fabbione> swap usage is impressive
[05:08] <BenC> could be
[05:08] <fabbione> and i am blaming the kernel for that
[05:08] <fabbione> since .12 works fine :)
[05:08] <BenC> you would :P
[05:08] <fabbione> ahhah
[05:08] <fabbione> BenC: we might be soon able to blame gnome :)
[05:09] <fabbione> http://blogs.gnome.org/view/cneumair/2006/01/10/0
[05:09] <fabbione> there
[05:09] <fabbione> see
[05:09] <fabbione> data loss? i blame gnome!
[05:09] <fabbione> reiserfs4 not working? i blame gnome!
[05:09] <fabbione> WE CAN BLAME GNOME!
[05:09] <fabbione> that's the best part :P
[05:33] <crimsun> BenC: any particular reason we don't enable CONFIG_USB_SUSPEND?
[05:33] <mjg59> crimsun: Because we don't use it anywhere
[05:34] <crimsun> mjg59: ok, I've just read a hint that the ehci-hcd errors post-resume (after a suspend) may be tied to it
[05:35] <mjg59> crimsun: Right now we unload and reload the modules
[05:35] <crimsun> mjg59: it only rears its head post-resume after a suspend, though
[05:36] <crimsun> post-resume after a hibernate doesn't exhibit the problem at all
[05:36] <crimsun> (mm, post/after redundancy)
[05:37] <crimsun> will debug further after lecture
[05:39] <BenC> fabbione: I think I have the -server crash fixed, testing in a minute
[05:39] <fabbione> BenC: cool!
[05:39] <fabbione> BenC: i need to push some cluster changes tomorrow. i would love to have them with the next kernel
[05:52] <zul> heylo
[05:53] <fabbione> hey zul
[05:55] <zul> hey fabbione how is it going?
[05:55] <fabbione> zul: as usual
[05:56] <zul> fun fun
[05:56] <BenC> fabbione: -server crash is fixed
[05:56] <fabbione> BenC: rocking
[05:56] <BenC> which may also fix crashes in amd64 and 686/k7
[05:56] <fabbione> fabbione BenC: i need to push some cluster changes tomorrow. i would love to have them with the next kernel
[05:56] <fabbione> * BenC has quit (Read error: 104 (Connection reset by peer))
[05:56] <fabbione> not sure you got that
[05:56] <fabbione> -4 to conf call
[05:56] <BenC> ok, the sooner the better
[05:57] <BenC> I was ready to do a build/upload, but I can hold off till tomorrow
[05:57] <fabbione> tomorrow i can do it.. i am waiting them to commit to their CVS 3/4 of our patches
[05:57] <fabbione> so we can drop them 
[05:57] <fabbione> specially there is a gfs fix we want in .15 due to some changes upstream
[05:59] <zul> BenC: did you have a look at my patches?
[06:04] <BenC> (conference call, brb)
[06:05] <zul> okie dokie
[07:06] <Zomb> hi
[07:06] <Zomb> do recent linux-image packages still suggest lilo?
[07:08] <zul> grub is more commonly used
[07:08] <zul> and the default
[07:08] <infinity> (base)adconrad@cthulhu:~$ apt-cache show linux-image-2.6.15-11-686 | grep ^Suggests
[07:08] <infinity> Suggests: lilo (>= 19.1) | grub, fdutils, linux-doc-2.6.15 | linux-source-2.6.15
[07:09] <infinity> Yes, they still suggest it, as they always have.
[07:17] <makx> well that can change :)
[07:17] <makx> once we don't loose *all* energy in firmware discussions
[07:19] <dilinger> this firmware thing is going to be a disaster...
[07:20] <zul> hmmm..?
[07:20] <dilinger> zul: nothing..
[07:42] <makx> it is already a disaster dilinger
[08:37] <tomukas> hi everyone, i have a wlan-problem with ipw2200 and syslog is saying: Radio Frequency Kill Switch is On, which means that it can't work at all... any ideas?
[08:38] <zul> so uh we have to use malone now?
[08:41] <mjg59> tomukas: Is there a physical switch on your laptop?
[08:42] <tomukas> yes
[08:43] <tomukas> mjg59: there is one... and there is activity in syslog after having switched it
[08:46] <mjg59> tomukas: Right. If it's in the correct position, then things should work
[08:49] <tomukas> mjg59: probably it's not... it seems that there is not yet a support for that wlan-device yet... but which command should this switch run?
[08:49] <zul> uh yes there is support for ipw2200
[08:49] <mjg59> The switch shouldn't run any command. It just disables or enables the radio.
[08:50] <tomukas> yes - but that doesnt work :-\
[08:54] <tomukas> kthxbye, guys... have to reboot
[11:17] <mdz> BenC: ping