[00:25] <ObsidianX> whats the actual binary that is the Power Manager app
[00:25] <ObsidianX> i can't find it for the life of me
[00:26] <ObsidianX> and i can't stand it
[02:48]  * lamont grumbles.  I want -jDNAT for ipv6
[03:05] <clever> lamont: but why?:P
[03:06] <clever> with ipv6 you should be able to get a public ip for every system behind the 'router'
[03:19] <lamont> clever: because I want to divert traffic bound for (say) $WEBSERVER to a local copy, or ditto for other traffic
[03:19] <lamont> DNAT has nothing to do with SNAT
[03:20] <clever> ah
[03:20] <clever> i mainly use dnat for port forwarding
[03:20] <clever> trafic from the web coming in geting directed to lan ip's
[03:20] <lamont> that too.
[03:21] <lamont> DNAT lets me have simpler firewall rules..
[03:28] <lamont> mind you, before we get ipv6 DNAT, ip6tables needs to believe in -t nat...
[03:33] <RAOF> Is there anything more I info can do for bug #184712?  Losing ACPI is annoying :(
[03:33] <ubotu> Launchpad bug 184712 in linux "[regression] Asus F3Jm fails to work correctly without acpi=off" [Undecided,New] https://launchpad.net/bugs/184712
[03:36] <mjg59> RAOF: Looks like it's stopping in acpi_early_init
[03:37] <RAOF> mjg59: Ok.  What sort of extra info would be useful here?  PArticularly since this seems to affect previously-working kernels, which has me perplexed.
[03:38] <mjg59> Yeah, nothing springs to mind
[03:38] <RAOF> There wasn't a recent initramfs-tools update?  Could that even cause this problem?
[03:39] <mjg59> Oh, hm. No, it's getting into timer setup.
[03:40] <mjg59> Or possibly not
[03:40] <mjg59> I'm afraid it's a bit hard to figure out where it's actually dying
[03:41] <RAOF> The kernel doesn't happen to have an excesively_verbose option? :)
[03:41] <mjg59> Are you able to build your own kernels?
[03:41] <RAOF> I'm not set up for it, but I could.  I've done it before.
[03:41] <mjg59> Ok
[03:41] <mjg59> If you could grab the source and add something like
[03:41] <RAOF> Oh, except the kernel building process has changed since then, I think.  I'll see :)
[03:42] <mjg59> printk("Successfully enabled ACPI\n"); to drivers/acpi/bus.c in acpi_early_init after the acpi_enable_subsystem line, that would be great
[03:42] <mjg59> Then we'll know whether it got out of ACPI or not
[03:43] <RAOF> Ok.
[03:49] <RAOF> Would you like me to build from Ubuntu git, or from the linux-source package?
[03:50] <mjg59> git's probably a better bet
[03:50] <RAOF> Right.
[04:27] <RAOF> Man it takes a long time to git clone the kernel!
[04:29] <lamont> RAOF: depends on how fast your link is... 200+MB takes a while
[04:30] <RAOF> Well, it's clearly not saturating my local connection.  On the other hand, kernel.ubuntu.com is unlikely to be in .au
[04:43] <lamont> rather
[04:44] <lamont> san francisco from my trace
[04:48] <RAOF> Well, it's done.  Now I can spin my CPU building it instead.
=== reynaldo1 is now known as reynaldo
[07:24] <Kred> Hi, I want to supply more details of a ACPI related bug that is already reported on Launchpad. Wiki tells me to supply tarball of /proc/acpi/ but fails to explain what commands to issue.
[07:27] <Kred> When I try to tar it I get device busy
[07:28] <Kano> hi
[07:31] <RAOF> mjg59: Well, that took longer than I expected.  Also, nothing extra got printed out; it looks like it's hanging before it's hanging before acpi_enable_subsystem returns in acpi_early_init.
[07:31]  * RAOF goes to update the bug.
[07:42] <Kano> why are still iwl modules not in lum?
[07:43] <RAOF> Kano: They are in my l-u-m-2.6.24-4-generic?
[07:44] <Kano> they are diabled in kernel config and not in lum
[07:44] <RAOF> Ah, sorry.  No they're not.  The firmware is there, and the modules are in linux-image-2.6.24-4-generic
[07:45] <Kano> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=a07606c45a19754bfd05e0cc2abff32207c5736c
[07:45] <Kano> UBUNTU: Disabled iwlwifi preperatory to moving it to l-u-m.
[07:45] <Kano> but they never arrived in lum
[07:45] <tjaalton> ugh
[07:45] <tjaalton> that's not released yet
[07:45] <Kano> nad
[07:47] <Kano> you can never release when you dont do that
[07:48] <Mithrandir> Kano: whining about not-released source not being in sync is not helpful.  It'll be moved into lum before the next upload.
[07:48] <Kano> that changes was made 6 days ago, i dont get what you are waiting for
[07:48] <tjaalton> I'm pretty sure they know what they are using
[07:48] <tjaalton> uh, doing
[07:49] <Mithrandir> if you're building stuff from git and it's a problem for you, don't pull that commit.
[07:52] <RAOF> In the unlikely event that someone's searching 'round for a bug to investigate with someone on the other end, I'm available for testing anything anyone can think of for bug #184712.
[07:52] <ubotu> Launchpad bug 184712 in linux "[regression] Asus F3Jm fails to work correctly without acpi=off" [Undecided,New] https://launchpad.net/bugs/184712
[07:52] <Kano> and no changes in bcm43xx and prism54 yet
[08:22] <mjg59> RAOF: In that case, it sounds like it's hanging while enabling ACPI. Which is bizarre.
[08:23] <mjg59> RAOF: You can prove that by sticking another printk just before the acpi_enable_susbsystem line
[08:23] <RAOF> About as bizzare as the fact that it's affecting older kernels that used to work fine?
[08:24] <Kano> i would let him try thorhammer rc7 with a kernel without config-ide
[08:25] <RAOF> I'll stick that extra printk in.  And wait for the kernel to build.
[08:27] <mjg59> Kano: ...
[08:27] <mjg59> Kano: Have you actually *read* the bug?
[08:27] <RAOF> mjg59: Any other printk's you'd like smattered around?  It takes me some time to build the kernel :)
[08:27] <Kano> mjg59: standard kernels often stop with that message
[08:27] <mjg59> RAOF: I'm pretty certain it's in there. If you want, you can spread some through acpi_enable_subsystem.
[08:28] <mjg59> Kano: This is before any code affected by #ifdef CONFIG_IDE has been executed
[08:28] <mjg59> Kano: We're still in init/main.c
[08:28] <Mithrandir> RAOF: use ccache; that helps at least.
[08:29] <mjg59> RAOF: TBH, I'd suspect BIOS weirdness at this point more than anthing else - can you try resetting that to defaults?
[08:29] <RAOF> mjg59: As a part of a futile attempt to flash the bios, I already have.
[08:29] <mjg59> RAOF: Hm
[08:29] <mjg59> RAOF: Is the machine Ubuntu-only?
[08:29] <RAOF> Yup.
[08:30] <mjg59> Really, really weird.
[08:30] <RAOF> Otherwise I could've flashed in Windows rather than wrestling with the "ez-updater" thing which apparently doesn't do anything at all.
[08:40] <RAOF> I could possibly find some sort of windows rescue disk if it'd be useful.
[09:58] <RAOF> mjg59: Right.  For those playing at home, my laptop locks up at the very start of acpi_enable_subsystem, and I've now flashed the bios to the latest version and it *still* happens.
[10:03] <Toma-> https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/184788
[10:03] <ubotu> Launchpad bug 184788 in linux-ubuntu-modules-2.6.24 "rtl8180 and rtl818x disabled in kernel Makefile" [Undecided,Confirmed] 
[10:04] <Toma-> any chance of seeing those in Hardy?
[10:09] <RAOF> Right.  For my final check, I'll try adding a DSDT file from the internest.
[10:14] <rtg> Toma-: the rtl wireless drivers are enabled in the Hardy kernel.
[10:14] <Toma-> rtl818x?
[10:15] <Toma-> its in the source, but blocked by the makefile
[10:15] <rtg> Toma-: CONFIG_RTL8187=m
[10:16] <Toma-> yes indeed.
[10:16] <Toma-> and rtl8180 and 818x?
[10:16] <Toma-> its in linux-ubuntu-modules
[10:17] <rtg> Toma-: Since the RTL family is upstream in 2.6.24, I do not intend to put them in lum.
[10:17] <Toma-> 0_o
[10:17] <rtg> Toma-: unless I end up backporting 'cause the upstream drivers don't work.
[10:18] <Toma-> ok 
[10:21] <RAOF> And for those playing at home, a custom dsdt from the internet fails to make any difference.
=== \sh_away is now known as \sh
=== \sh is now known as \sh_away
=== \sh_away is now known as \sh
=== clever_ is now known as clever
=== clever is now known as clever[rev]
=== clever[rev] is now known as clever
=== \sh is now known as \sh_away
=== Traxer is now known as Traxer|on
=== Traxer|on is now known as Traxer
=== johanbr_ is now known as johanbr