[02:58] <bluefoxicy> Fabulous
[03:00] <bluefoxicy> http://rafb.net/paste/results/Mq64HK84.html  Works on i386, untested on PPC, tested with 2.6.15-23.35 (skipped the patch for arch/x86-64/ files that aren't in that version), built as i686 and tested.
[03:00] <bluefoxicy> Any chance at all I can talk this one into Edgy later?
[03:01] <bluefoxicy> (Dapper's kernel is well past being frozen)
[03:03] <zul> what is it?
[03:04] <jbailey> Heya Chuck!
[03:04] <zul> hey jeff how is it going?
[03:04] <jbailey> bluefoxicy: This is more stsack randomisation stuff?
[03:05] <jbailey> bluefoxicy: What's the upstream status of it?  Is it at least in -mm?
[03:05] <jbailey> zul: Good!
[03:05] <jbailey> I didn't manage to ping you about the lkh stuff last week.
[03:05] <zul> jbailey: good to hear
[03:05] <jbailey> zul: Workin' away as always.
[03:05] <zul> jbailey: i wasnt around much this weekend but im working on it right now
[03:05] <jbailey> Oh, nice!
[03:06] <zul> while watching family guy
[03:08] <bluefoxicy> jbailey:  nowhere near mm, upstream saw the first try (a really ugly and hackish patch) and only arjan has taken me up on principle, nobody else cares.
[03:08] <jbailey> bluefoxicy: Really?  Why not?  Stand randomisation is generally accepted as sane, and this doesn't look like it has high cost.
[03:08] <lifeless> y
[03:09] <bluefoxicy> jbailey:  This patch has (tested) absolutely 0 effect on i386 if you just patch and reboot; and should have (not tested) absolutely 0 effect on any other architecture if you don't touch it.
[03:09] <bluefoxicy> Our current kernel inherits mainline's 8 megs of stack randomization and 1 meg of mmap() base randomization, which has been in since 2.6.12
[03:09] <jbailey> lifeless: Are you agreeing, or just farting?
[03:09] <bluefoxicy> What the patch I wrote does is leaves that in tact, except makes it dependent on a variable that can be adjusted easily -- and throws a knob on the kernel command line
[03:10] <bluefoxicy> I had hoped for mainline to lay the framework for SELinux-controlled randomization entropy
[03:10] <lifeless> jbailey: finger fart
[03:10] <bluefoxicy> For now, if a user so chooses, he can turn stack and mmap() randomization up/down/off with boot time parameters.
[03:10] <jbailey> lifeless: =)
[03:14] <bluefoxicy> jbailey:  I'm going to have to install fedora core 5 here and run paxtest probably to argue with them.  Arjan is claiming 8M and 1M is enough; but I'm pretty sure Fedora Core 5 and RHEL both use 128M (PaX uses 256M, and the code will not let you use more than 1/12 the VMA space-- which is 256M if TASK_SIZE=3G)
[03:20] <bluefoxicy> jbailey:  I'm looking at https://wiki.ubuntu.com/UbuntuDownUnder/BOFs/ProactiveSecurityRoadmap (Disclaimer:  I wrote some of it), I'm pretty sure -Wstack-protector and FORTIFY_SOURCE can make Edgy (gcc 4.1)
[03:21] <jbailey> Cool.
[03:21] <bluefoxicy> yeah.. I was hoping 4.2 would make edgy but eh.
[03:22] <bluefoxicy> I hear the stack protector in 4.1 is semi-broken.
[03:22] <bluefoxicy> FC5 uses it
[03:22] <bluefoxicy> so it can't be that bad
[04:37] <bluefoxicy> http://rafb.net/paste/results/wgUvS593.html  Here we go, with FC5's defaults (12 bits and 19 bits, instead of 10 and 19)
[04:41] <bluefoxicy> wait, the hell
[04:41] <bluefoxicy> since when do they have randomized ET_EXEC base
[10:55] <Mithrandir> BenC: any idea about https://launchpad.net/distros/ubuntu/+source/casper/+bug/34643 ? Doesn't the kernel actually lock the drive when mounting something off it?
[12:13] <fabbione> BenC: so -23- on live keeps freezing...
[12:14] <fabbione> BenC: sometimes when i boot it from hd it works, but switching to console kills the machine
[12:20] <airlied> fabbione: what graphics card?
[12:20] <fabbione> airlied: ati
[12:20] <fabbione> it's a PB g4
[12:21] <fabbione> exactly the same as BenC
[12:21] <fabbione> it works for him but not for me
[12:21] <airlied> fabbione: I assume switching to console is switching from X?
[12:21] <fabbione> yes
[12:21] <fabbione> from X to console
[12:21] <fabbione> it's a hard freeze
[12:21] <airlied> what ati chipset?
[12:22] <fabbione> 0000:00:10.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] 
[12:22] <fabbione> i was just looking at the kernel changelog and stuff to see if there is anything relevant
[12:22] <airlied> well I merged up the drm changes from the latest kernel to dapper..
[12:23] <fabbione> oh
[12:23] <airlied> you mightn't of had DRI enabled on the previous kernel perhaps..
[12:23] <fabbione> i can check
[12:25] <fabbione> old kernel seems to have dri enabled
[12:25] <fabbione> (II) RADEON(0): [DRI]  installation complete
[12:25] <airlied> can you pastebin an old kernel xorg.0.log and a new one?
[12:25] <fabbione> let's check with the new one
[12:25] <fabbione> airlied: sure of course
[12:25] <fabbione> i was just rebooting into the new one
[12:27] <fabbione> how curious
[12:27] <fabbione> now i can ssh into the box but i have no X and keyboard is dead
[12:27] <fabbione> no
[12:27] <fabbione> box is dead
[12:28] <airlied> benh is away as well, I normally punt all ppc to him :-)
[12:28] <fabbione> yeah i know
[12:29] <airlied> I really need to get an M10 out of somewhere..
[12:29] <fabbione> here it is booted fine now
[12:32] <fabbione> HMMMMMMMMMMMMMM
[12:32] <fabbione> grabbing the logs....
[12:35] <fabbione> http://people.ubuntu.com/~fabbione/Xorg.0.log.daltanius.*
[12:36] <fabbione> the new is when it manages to startup with the new kernel
[12:36] <fabbione> i need to modify a bit the boot sequence and see if i can scp the logs of when it crashes before it does so
[12:40] <fabbione> it seems to be DRI/DRM related
[12:40] <fabbione> (II) RADEON(0): AGP card detected
[12:40] <fabbione> drmOpenDevice: node name is /dev/dri/card0
[12:40] <fabbione> drmOpenDevice: open result is -1, (No such device or address)
[12:40] <fabbione> this is the last thing it can write to disks before it dies
[12:40] <fabbione> in the middle of DRI init
[12:40] <fabbione> [  187.896705]  [drm]  Initialized drm 1.0.1 20051102
[12:40] <fabbione> [  187.991213]  [drm]  Initialized radeon 1.24.0 20060225 on minor 0
[12:40] <fabbione> [  189.157702]  agpgart: Putting AGP V2 device at 0000:00:0b.0 into 1x mode
[12:40] <fabbione> [  189.157715]  agpgart: Putting AGP V2 device at 0000:00:10.0 into 1x mode
[12:40] <fabbione> [  189.305909]  [drm]  Setting GART location based on old memory map
[12:40] <fabbione> [  189.305928]  [drm]  Loading R300 Microcode
[12:40] <fabbione> [  189.305987]  [drm]  writeback test succeeded in 1 usecs
[12:41] <fabbione> this is in dmesg
[12:49] <fabbione> disabling dri from xorg.conf does the trick
[12:49] <airlied> hmm I wonder about how well radeonfb works with the new drm memory mapping..
[12:49] <fabbione> apparently not very well.. :)
[12:49] <airlied> I suspect the system is crashing in radeonfb rather than X.org on VT switch..
[12:50] <fabbione> possibily... what do you want me to test?
[12:51] <airlied> hmm can you boot without radeonfb and set usefbdev to off?
[12:51] <fabbione> sure
[12:51] <airlied> I've no idea if that is possible on ppc..
[12:51] <fabbione> i can do all teh tests you want
[12:51] <fabbione> no idea too
[12:51] <fabbione> but we can try :)
[12:51] <fabbione> no actually no.. radeonfb is built-in
[12:52] <fabbione> but i can disable usefbdev and see
[12:52] <airlied> yeah try that at least..
[12:56] <fabbione> this one works too
[12:56] <fabbione> but note this now:
[12:56] <fabbione> drmOpenDevice: node name is /dev/dri/card0
[12:56] <fabbione> drmOpenDevice: open result is 6, (OK)
[12:56] <fabbione> drmOpenDevice: node name is /dev/dri/card0
[12:56] <fabbione> drmOpenDevice: open result is 6, (OK)
[12:56] <fabbione> drmOpenByBusid: Searching for BusID pci:0000:00:10.0
[12:56] <fabbione> drmOpenDevice: node name is /dev/dri/card0
[12:56] <fabbione> drmOpenDevice: open result is 6, (OK)
[12:56] <fabbione> this time it find the devices?
[12:56] <airlied> yeah you get some wierd results with drmOpenDevice..
[12:56] <fabbione> it looks like a very interesting race condition
[12:56] <airlied> no it is just got lots of backwardss comapt..
[12:57] <fabbione> ah ok
[12:58] <fabbione> well either disabling dri or radeonfb seems to work
[12:58] <fabbione> so the two did stop to like eachother
[12:59] <airlied> thats a bit of a problem, as benh is probably the only one that can fix radeonfb..
[01:00] <fabbione> yes it is indeed a problem...
[01:01] <fabbione> given that we have only less than a week to get this stuff sorted
[01:03] <airlied> can you send me a log file with usefbdev off as well?
[01:15] <fabbione> airlied: sure
[01:15] <fabbione> in a second
[01:18] <fabbione> Xorg.0.log.daltanius.nousefb
[01:18] <fabbione> same url as above
[01:42] <airlied> hmm it's hard to decide whether we need to fix radeonfb or the X.org driver using it..
[01:56] <fabbione> airlied: or revert the drm change...
[01:56] <fabbione> at this point in time there is no time to guess.. :/
[01:58] <airlied> fabbione: the drm change fixes a few x86 issues :-)
[01:58] <fabbione> and break my laptop... and i hate x86... 
[01:58] <fabbione> ;)
[01:58] <airlied> I'm thinking usefbdev isn't needed for radeon anyways :-)
[01:58] <airlied> I think benh recommends against it now..
[02:00] <mjg59> We could just drop that from dexconf
[02:00] <mjg59> Or hack the driver so it's the default
[02:00] <airlied> I need benh to take a look at this , he might know a quick fix..
[02:01] <airlied> from what I can see the drm is just picking some wrong values..
[02:02] <fabbione> i think last time we were talking about making it the default since everybody was turning it on anyway
[02:02] <fabbione> iirc
[02:02] <fabbione> but that doesn't change the situation as it is now
[02:04] <airlied> in theory when you use the old mapping code, the drm operatse the same..
[02:21] <airlied> bah the codepaths looks the same, but it is getting the fb size wrong on the new DRM for no good reason..
[02:23] <airlied> I know how to punt the problem if that is anygood :-), we can CHIP_NEW_MEMMAP flag to the drm_pciids.h for all those RV350 chips..
[02:23] <airlied> I think that'll stop DRM from getting enable if usefbdev is on..
[02:23] <airlied> could change the message to say either a new X.org DDX or try not using UseFBDev.
[02:25] <airlied> I might look into it more tomorrow evening, bed time now, g'night
[02:25] <fabbione> airlied: do you have a patch you want me to test?
[02:25] <fabbione> ok
[02:25] <fabbione> good night :)
[02:25] <airlied> fabbione: can you edit kernel sources easy?
[02:25] <fabbione> airlied: generally ...
[02:25] <fabbione> vim usually works fine :P
[02:26] <airlied> in drm_pciids.h just add CHIP_NEW_MEMMAP to the line for your card, 0x1002, 0x4e50 I think..
[02:26] <fabbione> ok
[02:26] <airlied> that should stop DRM from working with fbdev I think..
[02:26] <airlied> let me know if it works... l8r/
[02:26] <fabbione> ok
[02:27] <fabbione> my card is not there at all :)
[02:27] <fabbione> oh never mind
[03:23] <zul> hey
[03:25] <zul> hey fabbione how was the holiday?
[03:25] <fabbione> zul: pretty good thanks
[03:25] <zul> good to hear
[03:53] <fabbione> BenC: the ubuntu-2.6.git on rookery is .17, right?
[03:57] <BenC> right
[03:57] <BenC> ubuntu-dapper.git is the one
[03:58] <fabbione> yup
[04:00] <fabbione> BenC: git pull http://people.ubuntu.com/~fabbione/archives/ubuntu-dapper.git
[04:00] <fabbione> tested
[04:00] <fabbione> it fixes the crashes for me
[04:00] <fabbione> this is a must go in for dapper
[04:00] <fabbione> let me talk to mdz too
[04:01] <BenC> Put it in your tree and push please
[04:01] <BenC> I'll pull and upload
[04:01] <fabbione> already done
[04:01] <fabbione> it's all there
[04:11] <BenC> fabbione: pulling
[04:11] <BenC> fabbione: thanks
[04:11] <fabbione> thanks
[04:11] <fabbione> no problem
[04:28] <zul> BenC: im available later in the week for fatal beatings
[04:28] <BenC> ok
[04:28] <BenC> sry been missing ya, been way too busy
[04:28] <zul> no problems i start the new job tomorrow its a holiday in ontario today
[04:29] <fabbione> BenC: 
[04:29] <fabbione> silo -f
[04:29] <fabbione> /etc/silo.conf appears to be valid
[04:29] <fabbione> Fatal error: File systems other than ext2, ext3, ufs and romfs not yet supported
[04:29] <fabbione>  /dev/mapper/root on / type ext3 (rw,errors=remount-ro)
[04:29] <BenC> what fs is it?
[04:29] <fabbione>  /dev/md0 on /boot type ext3 (rw)
[04:29] <fabbione> ext3
[04:29] <fabbione>  /dev/md0              228M   14M  203M   7% /boot
[04:30] <BenC> md0 for root is probably a bad idea
[04:30] <BenC> s/root/boot/
[04:30] <fabbione> it works fine on a 9GB disk
[04:30] <Mithrandir> BenC: when you have the time: 10:55 < Mithrandir> BenC: any idea about https://launchpad.net/distros/ubuntu/+source/casper/+bug/34643 ? Doesn't the kernel actually lock the drive when mounting something off it?
[04:30] <fabbione> it fails here on the 73G
[04:30] <fabbione> BenC: but the partition is small and at the beginning of the disk
[04:30] <BenC> Mithrandir: ok, checking it
[04:30] <fabbione>    8     0   71687369 sda
[04:30] <fabbione>    8     1       8032 sda1
[04:30] <fabbione>    8     2     249007 sda2
[04:31] <BenC> fabbione: but it's an md device...I've no idea how silo handles that
[04:31] <fabbione> BenC: it works on the 9GB just fine
[04:31] <BenC> as an md device?
[04:31] <fabbione> it's raid1 device that silo claims to support
[04:31] <fabbione> yeps
[04:31] <BenC> not sure then
[04:31] <fabbione> i take a 9Gb disk with 8M empty -> 128MB md -> /boot -> works
[04:33] <fabbione> i am ready to bet that it fails because the partitioner did stop once in the middle of all that mess
[04:33] <fabbione> i know at least one user that did install the same and did work
[04:48] <BenC> mjg59: Is libata-acpi.c needed with 2.6.17-git?
[04:54] <mjg59> BenC: Probably, but I doubt it'll apply right now
[04:54] <BenC> doesn't
[04:54] <BenC> is there a libata git I can pull from safely?
[04:55] <BenC> the libata suspend/resume stuff in current git supercedes the stuff we had in dapper, right?
[04:57] <fabbione> BenC: i think i found the silo bug
[04:58] <mjg59> BenC: There's stuff we have that isn't in git
[04:58] <mjg59> But I'll need to go over everything to figure out what
[04:58] <fabbione>     if (lseek (fd, 1024, 0) != 1024 || read (fd, &sb, sizeof (sb)) != sizeof (sb))
[04:58] <fabbione>         silo_fatal("Cannot read Super Block!");
[04:58] <fabbione>     if (swab16 (sb.s_magic) == EXT2_SUPER_MAGIC) {
[04:58] <fabbione>         if (fstype == unknownfs) fstype = ext2fs;
[04:58] <fabbione>         return 1024 << swab32 (sb.s_log_block_size);
[04:58] <fabbione>     }
[04:58] <BenC> mjg59: For now I've reverted 2.6.17 to stock ata code
[04:58] <fabbione> this looks like not properly alligned to the disk or something
[04:58] <BenC> I've forward ported a couple of things like promise pata support
[04:59] <mjg59> I think we ought to consider jumping to libata pata support
[04:59] <mjg59> It'll be dodgy for a bit, but we'll actually get decent testing of it
[05:00] <BenC> mjg59: Agreed, initrd can handle the change (with a long delay)
[05:01] <BenC> mjg59: are there any IDE drivers that libata pata doesn't replace?
[05:02] <mjg59> Don't think so, no
[05:02] <mjg59> Possibly some ancient ISA stuff
[05:04] <BenC> so we'll just need ide-generic?
[05:07] <mjg59> Guess so
[05:07] <mjg59> Not sure if that's been ported to libata
[05:13] <BenC> Mithrandir: the only way around that is to send an ioctl for the cd device to lock it
[05:14] <BenC> CDROM_LOCKDOOR maybe
[05:15] <BenC> not sure if that overrides the software eject
[05:15] <BenC> it makes it so you can't eject via the button on the drive
[05:56] <rlaager> How is the source for linux-restricted-modules managed? I'm building a modified kernel and I need those modules as well.
[06:25] <rlaager> BenC: Are you the guy to ask about linux-restricted-modules?
[06:25] <BenC> rlaager: it aint easy
[06:25] <BenC> in fact, it's so not easy, I can't really begin to tell you how to do it
[06:25] <rlaager> BenC: I don't care about easy.
[06:26] <rlaager> I'm building a kernel from the git tree....
[06:26] <BenC> like I said, the package really isn't built with custom kernels in mind :)
[06:26] <BenC> are you using a known target?
[06:26] <BenC> and did it produce a linux-headers-x.x.x... package?
[06:26] <rlaager> I'm not sure what you mean by "known target".
[06:27] <BenC> -386, -686, etc.
[06:27] <rlaager> -686 at the moment.
[06:27] <BenC> then install all the linux-headers-2.6.15-23* packages
[06:28] <BenC> install your custom linux-headers package, and rebuild l-r-m just like a normal debian package
[06:28] <rlaager> rebuild l-r-m-2.6.15 ? I get the impression the git tree is 2.6.17, from debian/control.
[06:29] <BenC> oh, you are using the latest git instead of ubuntu-dapper.git?
[06:29] <BenC> then you are out of luck
[06:29] <BenC> much of l-r-m doesn't build against it, as I've already found out
[06:29] <rlaager> BenC: Yes. Ouch. Hmm.
[06:30] <rlaager> Well, in the short term, I just need nvidia and ipw3945.
[06:30] <BenC> what modules do you need?
[06:30] <BenC> ipw3945 is in the kernel
[06:30] <rlaager> but there's a regulatory daemon, though, isn't there?
[06:30] <BenC> you can just link ipw3945d-2.6.17-1 to ipw3945d-2.6.15-23
[06:30] <BenC> same daemon
[06:31] <BenC> should be in /sbin/
[06:31] <rlaager> k, that'll do for now
[06:31] <BenC> nvidia, you can just download their tarball and install
[06:32] <rlaager> Alright. Any idea on how long it'll take for that stuff to be working again? Anything specific that I could do to help?
[06:33] <rlaager> Or perhaps I should ask about my end goal... I'm trying to build a -xen0 kernel package with the eventual goal of coming up with something acceptable for inclusion in Ubuntu.
[07:13] <zul> BenC: should i email mdy for the xen stuff?
[07:27] <jbailey> zul: For the conference?  Yeah.
[07:31] <zul> jbailey: okie dokie
[07:37] <zul> jbailey: done
[07:39] <zyga> hello
[07:39] <jbailey> =)
[07:39] <zyga> I've got pictures of a kernel panic if anyone is interested
[07:39] <zyga> on k7 about 3 days ago
[07:49] <zul> heh...star trek 1 is on
[07:49] <Keybuk> zul: billshatnertastic
[07:50] <zul> Keybuk: exactly..
[07:50] <Keybuk> it suddenly occurs that a duet between Bill Shatner and Tom Jones would be sublime
[07:50] <zul> he was ok in over the hedge
[07:51] <zul> mr tamborine man was awesome..
[07:52] <Keybuk> common people was fantastic
[07:52] <zul> heh..
[08:02] <jbailey> And all that made me think of was William Shatner singing "Major Tom"
[08:12] <bluefoxicy> hmm.
[08:12] <bluefoxicy> pitti is busy, I wanted to ask him his thoughts on Edgy.
[08:12] <bluefoxicy> But right now he's very busy with dapper and in discussion.  :)
[08:14] <Keybuk> Edgy is a banned topic on #ubuntu-devel until June 2
[08:14] <bluefoxicy> mmm.
[08:15] <bluefoxicy> Like I said, he's massively busy anyway
[09:29] <zul>  ooh...muppet show is on
[09:55] <jbailey> Anyone have an amd64 box handy?
[09:55] <zul> not me
[09:59] <cjb> jbailey: Yes.
[10:00] <jbailey> cjb: Mind doing a test for me?
[10:00] <jbailey> #include <stdio.h>
[10:00] <jbailey> #include <unistd.h>
[10:00] <jbailey> #include <errno.h>
[10:00] <jbailey> int
[10:00] <jbailey> main ()
[10:00] <jbailey> {
[10:00] <jbailey>         nice(-2);
[10:00] <jbailey>         printf("%d", errno);
[10:00] <jbailey>         perror(0);
[10:00] <jbailey>         return 0;
[10:00] <jbailey> }
[10:01] <jbailey> cjb: Please compile that and run it as a regular user, tell me what you get.
[10:01] <cjb> havoc:cjb~ % ./a.out
[10:01] <cjb> 13
[10:01] <cjb> Permission denied
[10:01] <cjb> 
[10:02] <jbailey> cjb: Great.  Give me uname -a ?
[10:02] <cjb> (32-bit userland, 2.6.15-22-k7.(
[10:02] <cjb> Linux havoc 2.6.15-22-k7 #1 SMP PREEMPT Sun May 7 17:27:47 UTC 2006 i686 GNU/Linux
[10:02] <jbailey> Ah, I need to test this on the amd64 kernel.
[10:02] <cjb> Hm?  Which?
[10:03] <jbailey> That test.
[10:03] <cjb> I mean, which kernel.  :)
[10:03] <jbailey> jbailey@auzura:~$ uname -a
[10:03] <jbailey> Linux auzura 2.6.15-22-amd64-k8 #1 SMP PREEMPT Sun May 7 16:15:46 UTC 2006 x86_64 GNU/Linux
[10:03] <jbailey> Would be nice.
[10:03] <jbailey> Or -23, I guess is out now.
[10:03] <jbailey> I haven't updated that machine yet,
[10:05] <cjb> 'kay, can upgrade to that.
[10:05] <jbailey> Cool, thanks!
[10:07] <cjb> No, I can't.  :)  I don't see -amd64- kernels available.
[10:07] <cjb> Maybe they require 64bit userland?
[10:09] <cjb> Yeah, I suppose they're only in the amd64 distro, and I'm using i686.  Looks like I can't help; sorry.
[10:09] <jbailey> Ah, dunno.
[10:09] <jbailey> Thanks, though
[10:10] <cjb> Welcome.  At least you have a simple test case, should be able to find someone in one of the other channels.
[10:47] <Mithrandir> BenC: ok, I thought the kernel did that already.
[10:48] <BenC> Mithrandir: It locks the device from unmounting, but that doesn't stop the physical eject with an ioctl, which overrides anything
[10:48] <Mithrandir> BenC: 'k, I guess casper should lock the drive, then
[02:17] <zul> why the hell am im watching opra?
[02:44] <BenC> because you have no life? :)
[02:48] <zul> that must be it
[02:48] <zul> its mesmerizing though
[06:40] <fabbione> BenC: <airlied> fabbione: set if for all rv350 to be safe.. <---
[06:40] <fabbione> BenC: the patch i gave to you yesterday
[12:21] <pips1> hi
[12:21] <pips1> are there any known problems with G5? (yesterday's daily build)
[12:21] <pips1> and if so, what are the symtombs?
[12:21] <pips1> symtoms
[12:21] <pips1> ?
[01:02] <beanz> Where can I find pre-released versions of the ubuntu kernel?
[01:03] <mjg59> https://wiki.ubuntu.com/KernelGitGuide
[01:05] <beanz> Is there not a holding area for the debs before they enter main or updates?
[01:06] <mjg59> No
[01:06] <beanz> damn
[01:06] <beanz> okay
[01:06] <mjg59> The source gets uploaded, autobuilt and goes into the archive
[01:09] <beanz> I see. and the _0 in linux-kernel-di-i386-2.6_0.64ubuntu2.dsc  - does it mean current?
[01:12] <fabbione> i am afraid you are not looking in the right place
[01:13] <beanz> ah. you're right. thanks.
[09:16] <crimsun> BenC: any kernel upload planned prior to final? There are enough HDA ALC* bug reports that I think http://hg-mirror.alsa-project.org/alsa-kernel?cmd=changeset;node=aca7d794a097b9aa64ff7e2d8536586a494c8313;style=gitweb would be worth merging
[09:17] <BenC> not before release
[09:17] <crimsun> ok, thanks.
[09:17] <BenC> mdz is already reaming me for the last one :)
[09:17] <crimsun> heh :)
[09:17] <BenC> I can squish it in with the first security upload though
[09:18] <crimsun> that would be fabulous
[11:29] <zul> heylo
[11:29] <Keybuk> olyeh
[11:29] <zul> hey Keybuk how is it going?
[11:29] <Keybuk> I'm trying to persuade one of my teeth to come loose
[11:30] <zul> thats nice
[11:30] <Keybuk> and Openoffice only builds if run under strace
[11:30] <Mithrandir> Keybuk: you're not supposed to lose teeth at such an early age, are you?
[11:30] <zul> hehe
[11:30] <Keybuk> Mithrandir: it's the one I broke in Kristiansand, if you remember
[11:31] <Mithrandir> I don't, but ok. Then it makes sense, or something
[11:31] <Keybuk> the shoddy repair job came loose over the weekend and fell out today
[11:31] <Keybuk> I should probably just go to the dentist
[11:31] <Mithrandir> can't be that shoddy if it held up for two years.
[11:31] <Keybuk> true
[11:35] <zul> time for din din
[03:04] <desrt> BenC; thanks a bunch :)
[03:05] <BenC> heh, you owe me a beer :)
[04:35] <BenC> infinity: ping
[04:43] <cjb> Can anyone get in touch with any Ubuntu Summer of Code admins?  They're desperately needed to resolve a duplicate with a student being accepted to Ubuntu as well as another org.
[04:46] <BenC> try -devel?
[04:46] <cjb> Don't think we've had any luck there, will try again.
[05:56] <foogle> I got a Kernel panic my install cd wont work anymore  I think it has some thing to do with segmentation
[05:58] <crimsun> foogle: do you have a recent dapper live cd ?
[05:58] <foogle> Is dapper 5.10?
[05:58] <crimsun> no, that's breezy.
[05:59] <crimsun> you probably want to migrate this question back to #ubuntu
[05:59] <foogle> oh ok 
[11:01] <infinity> BenC: pon?
[11:01] <infinity> g
[02:17] <RandolphCarter> is there any chance of reverting the changes made to the sky2 module in 2.6.15-23? (afaik they weren't bugfixes, and they've broken networking here)
[02:30] <zul> heylo
[02:32] <BenC> infinity: Trying to get lrm building with 2.6.17
[02:33] <BenC> infinity: It fails in the ati module build, for some reason it's trying to symlink Makefile.lib.c to scripts/Makefile.lib.c and build Makefile.lib.o in the linux-headers directory...any idea why?
[02:34] <BenC> lamont: in regards to the ia64 acpi crash on boot, my i2k started showing it, so it's a problem that just started showing up
[02:34] <BenC> lamont: good news is, the 2.6.17 kernel boots fine
[02:38] <zul> BenC: do you want to do some training on thursday night?
[02:38] <BenC> RandolphCarter: actually they were bug fixes
[02:38] <BenC> zul: tomorrow night sounds good
[02:39] <zul> cool...because lost is on tonight
[02:39] <RandolphCarter> BenC: ah :/ I've filed a bug (#46326), but they've broken net here, and they were introduced the day the kernel was frozen :/ (doh?)
[02:51] <BenC> RandolphCarter: We had some 10-15 bug reports on sky2 prior to that update...it fixed some of those
[02:51] <BenC> most are still broken
[02:51] <RandolphCarter> ah :/ I'm about to try amd64, failing that, can you point me to any archives that still have the -22 rev?
[02:54] <RandolphCarter> and there it goes :( sorry, if you answered that, could you send it again?
[02:55] <infinity> BenC: No idea, TBH... I don't have the time to look at it.
[02:55] <infinity> BenC: But you're adopting it anyway, right? :)
[02:56] <BenC> yeah, I'm getting it ready for edgy...just wondering if you had seen this failure before :)
[02:57] <BenC> so far I have 2.6.17 building on all 6 arch's, and booting on ia64, amd64, ppc and i386
[02:58] <infinity> Sweet.
[03:02] <infinity> So, we'll have the first 2.6.17 upload on June 2?
[03:04] <infinity> Oh, while you're doing LRM prep, "rm -rf madwifi madwifi-ng && svn co <latest madwifi-ng HEAD> madwifi"
[03:04] <infinity> I can do that on June 2, though. :)
[03:07] <BenC> yeah, it'll be uploaded the day edgyi is opened hopefully
[03:42] <BenC> mjg59: Is something supposed to replace wlan-ng?
[03:42] <BenC> the prism stuff isn't compiling well with 2.6.17 :/
[03:42] <mjg59> No idea
[03:42] <mjg59> It shouldn't be too hard to fix up
[03:45] <BenC> it's actually pretty horrible
[03:46] <BenC> for some reason it has a lot of depency loops for include/prims2/*.h headers...not hard but tedious
[03:46] <BenC> not sure why it's showing up now :/
[03:46] <BenC> *depndency
[03:46] <desrt> BenC; agreed.
[03:46] <BenC> doesn't hostap take care of most of prism2?
[03:54] <mjg59> Not USB
[03:56] <BenC> prims2_pci only had one id that hostap_pci didn't handle
[03:56] <BenC> copied that
[03:56] <BenC> prims2_cs had all the id's commented out, so seems like it was never any use in dapper
[03:57] <BenC> same for plx
[03:57] <BenC> I'll see if I can just enable usb
[04:23] <lamont> BenC: I tracked down which change (pair) caused it, back in the -15 to -16 transition (on zx2000).  Or are you saying that the i2k is still failing even with ACPI_DEBUG turned on?
[04:24] <BenC> lamont: was failing for me
[04:24] <fabbione> lamont: ACPI_DEBUG is good for me
[04:24] <BenC> irq 39: nobody cared (try booting with the "irqpoll" option)
[04:24] <BenC> I still get that on ia64
[04:24] <BenC> wait, I haven't tested if 2.6.15 boots on it now that ACPI_DEBUG is enabled
[04:25] <lamont> BenC: starting with -16 it quit booting unless ACPI_DEBUG is on to mask whatever the real problem is
[04:25] <BenC> ah
[04:37] <BenC> lamont: do you know why hppa would give me a bad reloc entry when it tries to load a kernel module with 2.6.17?
[04:37] <BenC> I reverted all of parisc to stock code
[04:37] <fabbione> BenC: it's probably the 17bit jmp limit?
[04:37] <BenC> it fails to load jbd.ko, which as you can imagine makes things pretty hard to boot
[04:37] <fabbione> that would be a toolchain issue
[04:37] <BenC> didn't have it on 2.6.15
[04:38] <BenC> odd that it would show up now
[04:38] <fabbione> is jbd.ko in .17 bigger?
[04:38] <fabbione> or is it of the same size?
[04:38] <lamont> BenC: there's a, um, feature in ld -r
[04:38] <lamont> it creates unlinkable .o files under some circumstances
[04:39] <BenC> crappy...I've built it 4 times and it's always the same thing in jbd.ko :(
[04:39] <BenC> I need to get the exact failure for you
[04:39] <lamont> if it has the number 17 in the reloc name, that's the bug
[04:40] <BenC> rebooting now...
[04:43] <BenC> Module jbd, symbol journal_destroy_caches is out of range for PCREL22F relocation
[04:43] <fabbione> yeps
[04:43] <BenC> journal_destroy_caches is a static function
[04:44] <fabbione> BenC: it's the 17bit issue
[04:44] <BenC> how can I workaround it?
[04:44] <fabbione> fixing the toolchain
[04:44] <BenC> I want all my machines booting 2.6.17 by the end of the week :)
[04:44] <fabbione> kile has been working on it for a while without success
[02:19] <zul> heylo
[02:48] <zul> BenC__: around?
[02:48] <BenC> yeah
[02:48] <BenC> got your email, 8pm sounds good
[02:48] <zul> goodie..i would have been available last night but you know lost was on..
[02:48] <zul> priorities ;)
[02:49] <BenC> hehe
[03:32] <zul> meh..
[03:53] <Keybuk> BenC: ping
[03:53] <BenC> Keybuk: pong
[03:54] <Keybuk> BenC: so sendfile64 appears busted
[03:54] <Keybuk> on AMD64, doing sendfile() with >2GB returns -EINVAL
[03:55] <BenC> hmm
[03:55] <Keybuk> fwict. sendfile() on AMD64 == sys_sendfile64
[03:58] <infinity> It's been busted for ages on 2.6 kernels, from what I can tell.
[03:58] <infinity> Last time I tested all this was on 2.4
[03:58] <infinity> Silly me.
[03:58] <Keybuk> it's not unique to our kernel either, Debian are busted too
[03:58] <infinity> No, it's upstream.  I found some stuff about it from Linus in the 2.5.x days.
[03:59] <infinity> it was intentionally broken, but was also meant to be reimplemented and fixed.
[03:59] <infinity> I guess the latter part never happened.
[04:02] <BenC> wonder why it's broken on say amd64 and not things like ppc64 and sparc64
[04:02] <BenC> duh, they are 32bit userspace
[04:03] <infinity> Ed zachary.
[04:03] <BenC> still, you would think on 64-bit userspace, sys_sendfile() itself would support > 2G files
[04:03] <infinity> Well, that's not fair, actually.  sendfile64() seems to be universally broken on at least all 64-bit kernels.
[04:04] <infinity> It's not the userspace that matters, afaict from my reading.
[04:04] <infinity> Anyhow, trivial to workaround in the one application where we seem to care.  Just wish this had been noticed a few months ago.
[05:08] <infinity> BenC: Why did my burner decide to statr flaking out with the latest kernel? :)
[05:08] <infinity> sr 1:0:0:0: Device not ready
[05:08] <infinity> (over and over again)
[05:09] <BenC> infinity: murphy :/
[05:09] <infinity> I'll blame him until further evidence makes it your fault. >)
[07:44] <jcole> if someone has time, kernel build help please -> http://pastebin.com/737508
[07:46] <jcole> i don't need the udebs either
[07:46] <jcole> is there a way to disable them?
[07:48] <jcole> i want to bump the ABI version, so the users i'm providing these kernels too, don't accidentally get upgraded to a stock dapper kernel
[07:55] <jcole> :/ nothing useful for me
[08:16] <jcole> got it
[08:17] <jcole> i think i need to change these files -> ./debian/config/amd64/config,./debian/config/hppa/config,./debian/config/i386/config,./debian/config/ia64/config,./debian/config/powerpc/config,./debian/config/sparc/config
[09:24] <crimsun> see the abi hints in debian/rules
[10:29] <zul> BenC: we still ok for tonight?
[10:38] <zul> bbl,,
[12:12] <jcole> crimsun: i don't understand
[12:13] <jcole> crimsun: i'm in debian/rules right now
[12:13] <jcole> crimsun: i want to recompile using a certain .config 
[12:14] <jcole> crimsun: isn't there a maintainers guide/readme/doc/howto for this?
[12:22] <crimsun> jcole: not that I know of. BenC could give you the rundown for bumping the ABI.
[12:24] <jcole> crimsun: i've got the ABI bumped, need to add REGPARM=y to all kernel configs
[12:26] <jcole> crimsun: how does one enable one kernel option?
[12:26] <jcole> crimsun: i have to recompile and provide all kernels with this one flag enabled
[12:27] <jcole> crimsun: i've compile twice and it keeps generating .config files with REGPARM disabled
[12:29] <jcole> crimsun: i tried to add a .config file to the source dir, tried to edit debian/config/i386/config, and tried to edit arch/i386/Kconfig... nothing is working
[12:30] <crimsun> what did you edit in debian/config/i386/config?
[12:30] <crimsun> "CONFIG_REGPARM=y" ?
[12:30] <jcole> crimsun:  CONFIG_REGPARM
[12:31] <jcole> yes
[12:32] <jcole> do i need to run a "special command" or something?
[12:32] <jcole> lol
[12:33] <crimsun> jcole: no idea, ping Ben for that
[12:33] <jcole> maybe a --compile-with-my-damn-config option
[12:36] <jcole> it takes hours and hours to compile all these... this really sucks
[12:37] <jcole> holy mother of gawd
[12:37] <jcole> it's working now
[12:37] <jcole> $ grep REGP ./debian/build/build-386/.config
[12:37] <jcole> CONFIG_REGPARM=y
[12:38] <jcole> *sigh* FINALLY
[12:38] <jcole> :)
[12:39] <jcole> if people really want these kernels, i'm going to make each and everyone install distcc
[12:55] <lifeless> clearly you should embed distcc in the kernel
[12:56] <jcole> lifeless: good point
[01:20] <zul> heylo
[01:58] <zul> BenC: hey
[01:58] <BenC> hey, might have to delay this a bit more
[01:58] <BenC> tracking down this damn squashfs bug
[01:58] <zul> ok no problem
[01:59] <zul> tomorrow same bat channel same bat place?
[02:04] <zul> oh yay...charlie's angel's is on
[03:27] <zul> having fun yet BenC 
[03:28] <BenC> not really
[03:29] <BenC> yeah, tomorrow night should be good
[03:34] <zul> heh ok
[03:39] <zul> that was weird my swap was not acitviated
[03:40] <crimsun> failed resume from hibernation in the past?
[03:53] <zul> nah...it just wasnt formatted or activated
[01:56] <zul> heylo
[03:35] <zul> BenC: i should be home around 8:30 tonight
[03:47] <pips1> Hi, booting dapper rc hangs on a new imac (G5), I tried live cd's of both kubuntu and edubuntu flavors. Have other users reported problems with G5 processors?
[03:48] <fabbione> pips1: afaik the new imac g5 support has been added to the kernel only recently
[03:48] <fabbione> i think it requires at least .16 if not .17
[03:48] <pips1> ic
[03:48] <fabbione> and the backport is not possible.
[03:49] <fabbione> the code has been ported to .16 for a distro and it resulted in a very unstable environment
[03:49] <fabbione> pips1: anyway edgy will open very soon with .17
[03:49] <pips1> right
[03:49] <fabbione> question of 2/3 weeks max
[03:49] <pips1> :)
[03:53] <pips1> fabbione, thanks for info
[03:53] <fabbione> no problem
[04:11] <archis_> Hi - I get fs-related error messages when mounting ext3 partitions via USB in dapper.
[04:11] <archis_> See http://paste.ubuntu-nl.org/14672
[04:11] <archis_> syslog: http://paste.ubuntu-nl.org/14673
[04:14] <fabbione> archis_: did you actually umount them before fsck?
[04:15] <fabbione> May 26 15:38:44 localhost kernel: [4303502.447000]  kjournald starting.  Commit interval 5 seconds
[04:15] <fabbione> May 26 15:38:44 localhost kernel: [4303502.447000]  EXT3 FS on sda2, internal journal
[04:15] <fabbione> May 26 15:38:44 localhost kernel: [4303502.447000]  EXT3-fs: mounted filesystem with ordered data mode.
[04:15] <fabbione> May 26 15:38:44 localhost kernel: [4303502.463000]  kjournald starting.  Commit interval 5 seconds
[04:15] <fabbione> May 26 15:38:44 localhost kernel: [4303502.463000]  EXT3 FS on sda5, internal journal
[04:15] <fabbione> May 26 15:38:44 localhost kernel: [4303502.463000]  EXT3-fs: mounted filesystem with ordered data mode.
[04:15] <fabbione> this clearly shows that the devices have been mounted properly
[04:15] <archis_> fabbione, yes they mount fine but fsck.ext3 complains during boot and drops me into a shell
[04:16] <fabbione> can you show me fstab?
[04:16] <archis_> just a s ec
[04:16] <fabbione> sure
[04:17] <archis_> fabbione, http://paste.ubuntu-nl.org/14674
[04:18] <fabbione> Keybuk: ^^^this is udev/mount race condition i am afraid
[04:18] <fabbione> archis_: thanks.
[04:18] <Keybuk> USB drive not mounted by fstab?
[04:18] <fabbione> yup
[04:18] <archis_> fabbione, welcome
[04:18] <fabbione> and it's not even root
[04:18] <Keybuk> Known, solution "DON'T DO THAT THEN"
[04:19] <fabbione> it's just a media
[04:19] <Keybuk> the edgy solution is to get rid of checkfs/checkroot/mountall entirely, and do all fsck and mount calls from udev rules
[04:20] <archis_> fabbione, Keybuk ..any suggestions?
[04:20] <fabbione> that's going to fail with SAN systems and multipath with hotstandby disks
[04:20] <Keybuk> fabbione: no, it only fails on USB drives that I know of
[04:20] <Keybuk> because they take so damned long to initialise
[04:20] <fabbione> Keybuk: nope.. it will fail also on SAN with multipath
[04:20] <fabbione> i can explain you why
[04:21] <fabbione> Keybuk:  i assume you are familiar with internet routing?
[04:21] <Keybuk> fabbione: I used to work for an ISP
[04:21] <fabbione> to be able to read a traceroute at least
[04:21] <fabbione> ok
[04:21] <fabbione> well just to make sure :)
[04:21] <fabbione> imagine host A and B
[04:21] <fabbione> routers C D E F
[04:21] <fabbione> A is connected to C and D
[04:21] <Keybuk> archis_: echo 'SUBSYSTEM=="block", ACTION=="add", NAME=="sd[a-z] [0-9] *", RUN+="mount %k"' >> /etc/udev/rules.d/88-mount.rules
[04:22] <fabbione> C is connected to E and F
[04:22] <fabbione> D is connected to E F
[04:22] <fabbione> E and F are connected to B
[04:22] <Keybuk> archis_: though that won't give you fsck ... which might be a problem
[04:22] <fabbione> so you have N paths to get there
[04:22] <archis_> Keybuk, thanks :-)
[04:22] <fabbione> now.. in a SAN system...
[04:22] <fabbione> A is the host
[04:22] <fabbione> C and D two FC-HBA controllers
[04:22] <fabbione> E and F 2 SAN controllers
[04:23] <fabbione> B the disk
[04:23] <fabbione> A will see B as sda sdb sdc sdd
[04:23] <fabbione> if you try to fsck them in parallel you will doom the FS on the disk
[04:23] <fabbione> alsp
[04:23] <fabbione> usually 2 paths are active
[04:23] <fabbione> and that's ok acces
[04:23] <archis_> I can boot into USB from second grub located on the USB itself for occasional filechecking, no?
[04:23] <fabbione> access
[04:23] <fabbione> 2 of them are kept hot-stsandby
[04:24] <fabbione> that means if you try to access them you will get errors
[04:24] <fabbione> like real scsi errors
[04:24] <Keybuk> fabbione: I think you've wandered from the point ?
[04:24] <fabbione> if you do the fsck the way you describe it, it will fail the boot and possibly corrupt the FS if it starts in parallel
[04:24] <Keybuk> or I'm not following
[04:24] <Keybuk> fabbione: the SAN doesn't support parallel fsck?
[04:25] <fabbione> the SAN has nothing to do with the FS you run on top :)
[04:25] <Keybuk> ie. simultaneous fsck of different exposed DRIVES ?
[04:25] <Keybuk> sda == a device
[04:25] <fabbione> SAN exports a block device
[04:25] <fabbione> not a FS
[04:25] <Keybuk> this is all besides the point
[04:25] <fabbione> or N block devices.. but one is enough for our example
[04:25] <Keybuk> let's get back to the "will a SAN mount today" issue
[04:26] <fabbione> i am not talking about mounting..
[04:26] <Keybuk> does the SAN driver return from _init before it has discovered and created the block devices in the kernel?
 the edgy solution is to get rid of checkfs/checkroot/mountall entirely, and do all fsck and mount calls from udev rules
[04:26] <Keybuk> what are you talking about then?
[04:26] <fabbione> ^^ i am talking about this for edgy
[04:26] <Keybuk> right, I don't see why that is bad
[04:26] <fabbione> it works in dapper now.. so that's no problem
[04:26] <Keybuk> if you can't fsck the block device, then it won't work today
[04:26] <fabbione> because you can start 2 fsck on the same disk at the same time?
[04:27] <Keybuk> then it won't work today
[04:27] <fabbione> on a SAN you rarely use the sdX devices
[04:27] <fabbione> you slam a multipath tools on top that abstract the sdX to a single device that you mount
[04:27] <Keybuk> in edgy we'll be able to explicitly exclude SAN devices that won't let you do that
[04:27] <Keybuk> so I don't see the problem
[04:27] <fabbione> well you didn't say that before and i got worried :)
[04:28] <Keybuk> if you don't use /dev/sdX then it won't be in /etc/fstab, no? :)
[04:28] <fabbione> also remember that usually SAN devices are recognized by uuid
[04:28] <fabbione> true that too
[04:28] <Keybuk> udev will only be calling fsck + mount for something in /etc/fstab
[04:28] <Keybuk> ie. replacing mountall
[04:28] <fabbione> assuming that your box is fully redundant
[04:28] <fabbione> there are still corner cases where we want to offer the blacklist
[04:28] <Keybuk> yeah, we can blacklist with udev -- is easy
[04:28] <fabbione> perfect
[04:29] <Keybuk> anyway, archis_'s problem is a known one
[04:29] <Keybuk> it's not "solvable" today
[04:32] <archis_> Keybuk, I had no problem with fsck checking sda on breezy - why do I have it now?
[04:32] <Keybuk> archis_: you actually did ... breezy just took longer to boot
[04:33] <Keybuk> oh, wait
[04:33] <Keybuk> no, that's right
[04:33] <Keybuk> breezy took longer to get from S04udev to S30checkfs.sh
[04:34] <Keybuk> (though how /dev/sdaX got created without the modules being loaded by hotplug I have no idea :p)
[04:34] <Keybuk> did you put anything in /etc/modules ?
[04:34] <archis_> nope
[04:35] <archis_> no udev rules either
[04:35] <Keybuk> magic :p
[04:35] <archis_> I have an ancient syslog somewhere that I can paste if you're interested
[04:36] <Keybuk> syslog doesn't help
[04:36] <Keybuk> all this happens wayyy before that daemon is started ;)
[05:02] <dilinger> i go to packages.ubuntu.com/nagios, and get prompted for a username/passwd
[05:03] <fabbione> dilinger: we hate you :P
[05:04] <dilinger> guess i'll have to backport nagios2 to dapper
[07:59] <BenC> infinity: ping
[08:04] <zul> BenC: i should be home around 8:30 tonight we can do it then if you want
[09:29] <doko> BenC: is there an easy way to turn of hyperthreading/smp in the kernels?
[09:40] <BenC> doko: # CONFIG_SMP is not set
[09:41] <BenC> in the debian/config/$arch/config.$flavour of your choice
[09:41] <doko> well, but hyperthreading is turned on
[09:42] <doko> BenC: no boot option to turn these off?
[09:48] <fabbione> doko: ht=on
[09:48] <fabbione> off=
[09:48] <fabbione> ht is disabled by default iirc
[09:49] <fabbione> because of the hw bug
[09:49] <fabbione> SMP ... hmmm 
[09:49] <fabbione> somehting like smppersonality=off
[09:49] <fabbione> or smp=off
[09:51] <BenC> nosmp on the command line
[09:53] <doko> fabbione, BenC: ht is on by default, so ht=off should work ...
[09:53] <BenC> yeah, ht=off nosmp
[09:53] <BenC> that should do it
[09:54] <fabbione> ok
[09:54] <fabbione> i am ogg
[09:54] <fabbione> off
[09:54] <fabbione> good night
[09:55] <BenC> good night fabio
[09:56] <zul> im heading home as well ill talk to you later BenC 
[09:56] <BenC> later zul
[10:00] <doko> BenC, Mithrandir: booting using ht=off, the boot hangs mounting the root file system: IOAPIC[0] : Invalid reference to IRQ 0
[10:01] <BenC> what is this on?
[10:01] <doko> P4 with hyperthreading
[10:01] <BenC> some systems have to have SMP/ioapci enabled, and wont work otherwise
[10:01] <BenC> ioapic
[10:03] <doko> ok, removing nosmp lets the boot succeed
[10:06] <doko> fabbione, BenC: ht=off doesn't work
[10:07] <BenC> I really thought ht was off by default because of a security errata
[10:09] <doko> no, /proc/cpuinfo still shows two CPUs
[10:13] <jcol1> doko: that doesn't work for me neither
[10:13] <BenC>                 else if (!memcmp(from, "ht=on", 5))
[10:13] <BenC>                         disable_ht = 0;
[10:13] <BenC>                 else if (!memcmp(from, "ht=off", 6))
[10:13] <BenC>                         disable_ht = 1;
[10:14] <BenC> should work
[10:14] <BenC> anything in dmesg about ht?
[10:18] <doko> ok, it's disabled, but it still finds two CPU's. strange ...
[10:18] <doko> BenC: ^^^
[10:36] <BenC> I think it always scans all of them when in that mode
[10:36] <BenC> it just may only use the one
[10:43] <doko> $ getconf _NPROCESSORS_ONLN
[10:43] <doko> 1
[10:50] <BenC> sweet
[01:53] <zul> heylo
[02:33] <zul> BenC: yo
[02:40] <BenC> zul: Hey, give me a couple of minutes
[02:40] <zul> sure
[02:55] <zul> firg...my eye hurts..
[02:57] <BenC> zul: email address?
[02:57] <zul> zulcss@gmail.com
[02:58] <zul> *sigh* you dont know it yet? :)
[02:58] <BenC> I'm as bad with email addresses as I am with names
[02:58] <BenC> that's why I like IRC, you see the persons name whenever they speak :)
[02:58] <zul> im worse with names, better with email addresses
[07:39] <infinity> BenC: Pong?
[08:40] <davyd> is there much time for bug fixing before the Dapper release?
[08:40] <davyd> 42258 would be very, very handy
[08:42] <davyd> (oops, wrong button)
[08:42] <fabbione> davyd: no time at all
[08:43] <davyd> fabbione: that's a damned shame, because this bug is going to break every single one of our desktops at work
[08:43] <crimsun> (I'm not sure if infinity asked about newer Nvidia drivers)
[08:43] <davyd> and shoots my attempt at an Ubuntu migration (from Fedora)
[08:44] <fabbione> davyd: it is already proposed as update
[08:44] <fabbione> it might happen shortly after release
[08:44] <davyd> ok
[08:44] <davyd> I've got my kernel packages here on hold
[08:45] <davyd> it doesn't seem to affect you until you start twinview, so I suppose I'll just have to run updates first
[08:45] <davyd> once it lands
[08:54] <infinity> davyd: I'm pushing to get it fixed before release, so the new drivers ar on the CD, but if not, it'll happen shortly after release.
[08:54] <davyd> ok
[08:55] <davyd> that's excellent news
[01:01] <archis_> I see fabbione is not around...
[01:03] <archis_> Just to follow up on Keybuk's udev rule for the udev/mount race condition on my system
[01:04] <archis_> It sort of confuses things - screenshot: http://paste.ubuntu-nl.org/14722
[01:05] <archis_> (fstab here) http://paste.ubuntu-nl.org/14674
[01:06] <archis_> and I'm still being dropped into a shell at boot like so.. http://paste.ubuntu-nl.org/14672
[02:55] <zul> heyl0
[07:20] <zul> BenC: er ping