[12:16] <mjg59> zul: The stuff in drivers/ata is just stuff that used to be in drivers/scsi
[12:16] <mjg59> Do we have an lspci for the systems in question?
[12:19] <mjg59> I suspect we need http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=15e0c694367332d7e7114c7c73044bc5fed9ee48
[12:29] <zul> ill push a patch tonight
[01:04] <desrt> BenC; poke.
[01:04] <BenC> desrt: peek
[01:04] <desrt> BenC; -8 fixes my laptop's ability to wake from sleep
[01:04] <desrt> but it also breaks its ability to sleep most of the time
[01:05] <BenC> anything in dmesg as to why it fails?
[01:05] <desrt> gets stuck at the 'Switching to UP code' message from smp alternatives
[01:05] <desrt> nothing past that
[01:05] <desrt> the system is almost entirely useable at this point, though
[01:05] <desrt> like, i can still do stuff....
[01:05] <desrt> it's like it gets stuck at something in the middle of bringing itself down
[01:06] <desrt> and the echo 3 > /proc/acpi/sleep D-states
[01:06] <desrt> it works sometimes . doesn't work others.  not sure what it is
[01:07] <desrt> basically just wondering if you have a guess before i start sticking printk's everywhere
[01:07] <desrt> also: do you know a way to figure out what address a process in-kernel is currently executing at?
[01:08] <mjg59> desrt: alt+sysrq+t should still dump kernel threads
[01:08] <desrt> i figure since the 'echo' is getting wedged in D-state the kernel must handling the shutdown in context of that process.... so wherever that process is executing in the kernel is probably a good guess
[01:08] <desrt> mjg59; no sysrq key here :)
[01:08] <desrt> mjg59; and it's not a kernel thread
[01:09] <mjg59> Oh, I see what you mean
[01:09] <desrt> kernel executing on behalf of a normal process
[01:09] <mjg59> Erm. I /think/ alt+sysrq+t will still do what you want
[01:09] <mjg59> And I think there's somewhere in /proc where you can set the keycode
[01:09] <desrt> is there any way to key that on a system without sysrq?
[01:09] <desrt> cool
[01:09] <desrt> i'd like to avoid the recompile if possible :)
[01:10] <mjg59> Hm. Maybe not.
[01:10] <mjg59> You might need the recompile.
[01:10] <desrt> bah
[01:10] <desrt> btw... do you know why capslock has stopped working?
[01:10] <mjg59> Nope
[01:10] <mjg59> Could be the new keymap stuff
[01:11] <desrt> without vbestate hitting capslock was the only way to tell the diff between a working-but-invisible system and a crashed one
[01:12] <desrt> you know
[01:12] <desrt> i wonder if this is another incorrect-lpj symptom.....
[01:12] <mjg59> Could be
[01:12] <mjg59> Worth giving it a go
[01:12] <desrt> it's not happening anymore
[01:13] <mjg59> The failure?
[01:13] <desrt> heh
[01:13] <desrt> take that back
[01:13] <desrt> it just happened again
[01:13] <desrt> k.  the shellscript is in state D+
[01:14] <mjg59> My suspicion is that it's just stuck in the refrigerator
[01:14] <mjg59> That'll loop several times before it gives up
[01:14] <desrt> i wonder if i can mine the data that i need from proc
[01:14] <desrt> what is the fridge?
[01:14] <desrt> process-freezer?
[01:14] <mjg59> Yeah
[01:15] <desrt> i may just be impatient... but i think it gets stuck here for good
[01:15] <mjg59> What does dmesg have?
[01:15] <desrt> gets stuck at the 'Switching to UP code' message from smp alternatives
[01:15] <desrt> nothing past that
[01:15] <desrt> before that i have only:
[01:15] <desrt> Freezing cpus...
[01:15] <desrt> CPU 1 is now offline
[01:16] <desrt> so it certainly makes sense that it's proably trying to freeze processes next
[01:16] <desrt> this is interesting
[01:16] <desrt> i have two kernel threads called [kstopmachine] 
[01:16] <desrt> one is sleeping anti-nice
[01:16] <desrt> the other is an anti-nice zombie
[01:17] <desrt> (the worst kind of zombie you could encounter, really)
[01:30] <desrt> so many damned modules
[01:50] <mjg59> BenC: Have we lost the PCI express stuff for bcm43xx again?
[01:50] <BenC> mjg59: Nope, I checked it today
[01:51] <mjg59> BenC: Hm.
[01:51] <mjg59> We don't have the PCI IDs
[01:51] <BenC> that's the CORE_NEW stuff, right?
[01:51] <mjg59> Yeah
[01:52] <mjg59> "Unsupported 80211 core revision 10"
[01:53] <mjg59> So bits of it are gone, at least
[01:54] <BenC> -       { PCI_VENDOR_ID_BROADCOM, 0x4312, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
[01:54] <BenC> I think that's the one
[01:55] <BenC> Fixed now
[01:56] <mjg59> No, it's not just the IDs
[01:58] <BenC> the COMMON_NEW bits are still there, maybe I missed something else
[02:05] <BenC> mjg59: I have the PCIE changeset, and am cherry-picking it back into head
[02:05] <mjg59> BenC: Which PCIE changeset?
[02:06] <mjg59> I'm just testing the one that's going upstream
[02:06] <mjg59> Rather than my slightly hacky one
[02:07] <BenC> commit 8ffedd7b606cc085fbfb11019f2794c8a94bb5e9
[02:07] <BenC> Author: Matthew Garrett <mjg59@srcf.ucam.org>
[02:07] <BenC> Date:   Wed Mar 8 09:43:00 2006 +0000
[02:07] <BenC>     [PATCH]  Broadcom wireless patch, PCIE/Mactel support
[02:07] <mjg59> Yeah
[02:07] <mjg59> Drop that one
[02:07] <mjg59> Hang on a couple of minutes
[02:08] <desrt> neat fact: a system that fails to sleep won't shutdown anymore
[02:12] <BenC> mjg59: damnit, I already cherry-picked it :)
[02:12] <BenC> curse the fast and convenient source control system
[02:13] <mjg59> Heh
[02:13] <mjg59> Revert it, then :)
[02:16] <BenC> done, just email me your patch and I'll get it in tonight for the 1am upload :)
[02:17] <mjg59> Hm.
[02:17] <mjg59> So the one I've got doesn't quite seem to work...
[02:18] <zul> 1am upload?
[02:18] <zul> ick..
[02:28] <mjg59> Hm. No interrupts
[02:29] <mjg59> I'm /sure/ I've fixed this before
[02:29] <desrt> i hate my macbook
[02:29] <desrt> it's as if inserting the printks fixed the problem
[02:34] <mjg59> Whereas mine works
[02:34] <mjg59> Hm
[02:35] <desrt> your macbook?
[02:36] <mjg59> I don't have a macbook
[02:36] <mjg59> Sorry, my bcm patch
[02:36] <desrt> lucky bastard.
[02:37] <desrt> whatever
[02:37] <mjg59> BenC: Oh, bugger it
[02:37] <mjg59> BenC: Ignore me, merge my patch again, it has the advantage of working :)
[02:37] <desrt> next time it screws up i'll at least have the debugging there
[02:37] <mjg59> BenC: But can you add 0x4311 as well as 0x4312?
[02:38] <BenC> yeah
[02:39] <mjg59> No idea why this doesn't work, but the upstream one just never gets any interrupts
[02:39] <mjg59> Mine's incorrect in places, but does work
[02:42] <BenC> mjg59: all done
[02:44] <mjg59> BenC: I didn't see the patch from #53910?
[02:45] <BenC> it's in git
[02:46] <BenC> should be, I know I grabbed it
[02:46] <mjg59> Can't see it on gitweb
[02:46] <BenC> put it in dapper too
[02:46] <mjg59> Ah
[02:47] <mjg59> It's under "update configs"
[02:47] <mjg59> Your commit messages suck :)
[02:49] <BenC> oh, that's right
[02:49] <BenC> I did a git-update-index on it, forgetting I had a huge update under debian/*
[03:00] <BenC> mjg59: I added a patch to bcm43xx that sets signal stats in iwconfig (and NetManager)
[03:00] <BenC> works on my powerbook
[03:00] <mjg59> BenC: Cool
[03:09] <johanbr> BenC: Did you hack that up yourself, or did you backport the patch that was just added to upstream bcm43xx?
[03:10] <mjg59> johanbr: That's something I wrote a while ago
[03:10] <mjg59> Oh, you mean the stats stuff?
[03:11] <johanbr> mjg59: Yep.
[03:22] <BenC> johanbr: someone emailed it to me from upstream
[05:20] <zul> BenC: how would i revert the smp-alt stuff it seems to be getting in the way
[06:45] <BenC> zul: smp-alt is in stock 2.6.17, so it's not a patch I did (except the amd64 support)
[06:46] <fabbione> hey BenC 
[06:46] <fabbione> no new kernel yet?
[06:46] <BenC> working on it
[06:46] <fabbione> ok :)
[06:46] <BenC> need to fix a agp build failure
[06:47] <fabbione> time to get ready to start my hw maintainance
[06:47] <fabbione> i have to move a few hd arounds and put the rest of the machines under UPS
[07:26] <BenC> #61448: [Edgy]  Kernel 2.6.18 Released
[07:26] <ajmitch> heh
[07:26] <ajmitch> you know you'll get asked to put in 2.6.19 when it's there
[07:27] <BenC> 2.6.19 wont be released before edgy, so no worries there :)
[07:27] <BenC> they were even nice enough to put a link to kernel.org, like I wouldn't know where to find the kernel source
[07:27] <ajmitch> how thoughtful
[01:37] <zul> someone say my name? it went past the scrollback 
[01:41] <tonfa> 06:45 < BenC> zul: smp-alt is in stock 2.6.17, so it's not a patch I did (except the amd64 support)
[01:41] <zul> thanks..
[02:48] <AnAnt> I'm not sure if that is the proper place to discuss it but here it is anyways: if I am on an amd64 using 32-bit Ubuntu, will I be able to run 64-bit applications ?
[02:49] <Mithrandir> AnAnt: no, not unless you use a 64 bit kernel, which is an unsupported configuration
[02:50] <AnAnt> Mithrandir: what does "unsupported configuration" mean ?
[02:51] <AnAnt> Mithrandir: does it mean that it is impossible to do ? or that Ubuntu would do it ?
[02:51] <Mithrandir> AnAnt: that if it breaks or you get unexpected problems you might not get your bugs fixed.
[02:53] <AnAnt> mithrandir: ok, did you mean that it is not supported by Ubuntu, or that it is not supported by the kernel ?
[02:55] <Mithrandir> unsupported by ubuntu
[02:55] <AnAnt> Mithrandir: do you know wether they plan to support it in the future ?
[02:56] <AnAnt> edgy+1 or so ?
[02:57] <Mithrandir> I'm not sure, but I don't think so
[02:58] <AnAnt> btw, this is the proper place for my question, right ?
[02:58] <gnomefreak> mjg59: you around?
[04:35] <zul> BenC: ping
[04:36] <BenC> zul: pong
[04:36] <zul> i saw your note last night about the smp-alt stuff i just checked the stable tree in git for 2.6.17 and there is no reference about it
[04:38] <Mithrandir> hi zul
[04:38] <zul> hi Mithrandir 
[04:38] <BenC> zul: That's funny, because after hearing what fabbione said, I checked current 2.6.18, and smp-alt is in there still
[04:38] <zul> smp_alternative?
[04:38] <BenC> rgrep alternatives_smp_switch arch/i386
[04:39] <zul> ah ok..
[04:39] <zul> then how the hell im going to to do this (rhetorical question)
[04:40] <mjg59> BenC: Ha. So while the PCI-E broadcom stuff /works/, I'm getting 20K/sec
[04:42] <BenC> mjg59: nasty, even I get 500-600k/sec and it seems crappy :)
[04:42] <mjg59> BenC: On a Broadcom?
[04:48] <BenC> mjg59: Yeah, powerbook
[04:49] <BenC> it's weird, I get less than half the distance under linux than I do under macosx
[04:49] <mjg59> BenC: Yeah, it seems to be PCI-E specific
[04:49] <BenC> the signal strength sucks
[04:49] <mjg59> Oh, the txpower stuff?
[04:49] <mjg59> Yes, that's still not properly implemented
[04:49] <BenC> how can I bump the txpower?
[04:49] <mjg59> Help complete the specs?
[04:49] <BenC> heh
[04:50] <zul> BenC: interesting http://svn.debian.org/wsvn/kernel/?rev=0&sc=1 (based off of 2.6.18)
[05:13] <zul> BenC: got it without the xen smp-alts crack from 2.6.16
[05:59] <`ph8> hey BenC
[05:59] <`ph8> thanks for getting back about that bug so promptly
[05:59] <BenC> hello
[05:59] <BenC> hoping that this last changeset I pulled fixes the problem
[06:09] <ivoks> BenC: will that patch get ported to dapper?
[06:09] <BenC> ivoks: maybe
[06:10] <ivoks> ok
[06:10] <`ph8> will let you know tomorrow hopefully Ben
[06:10] <`ph8> i'm actually out tomorrow night so it might not be until Saturday :/
[06:11] <ivoks> i'll try it tomorrow
[06:11] <`ph8> unless i negotiate a day to work at home *g* - we'll know shortly
[06:11] <ivoks> i have same problem :/
[06:12] <zul> heh...i tried..
[06:12] <BenC> mjg59: You know, it sucks, I used to have a broadcom docsafe account, in which I could have gotten the bcm43xx specs, but the account is no longer active
[06:12] <ivoks> zul: and?
[06:12] <zul> ivoks: meh...didnt work
[06:13] <ivoks> ok :)
[06:13] <ivoks> well, then i'll prepare 2.6.18 image to solve this problem :)
[06:15] <mjg59> BenC: I've got the driver for the iSight on the Apples sorted
[06:21] <`ph8> BenC: do Windows know about all these things because Asus told them years in advance for fear of angering them?
[06:21] <`ph8> then we linux-ers have to wait until release to sort out compatibility?
[06:21] <BenC> ph8: no idea
[06:22] <`ph8> i have a suspicion that's the case. We need to get a couple of lottery winners on board to start a nice investment fund to run Ubuntu off forever more :D
[06:27] <ivoks> `ph8: vendors provide their own windows drivers
[06:28] <`ph8> i dont' think it's right that Asus claim this board works with gentoo/bsd/linux on their website then don't provide some clever linux drivers
[06:28] <`ph8> unless they provided it to the kernel when they shipped the product i suppose
[06:28] <`ph8> s/kernel/kernel team
[06:35] <`ph8> muwahaha
[06:35] <`ph8> tomorrow working from home, i'll be around at about 10am gmt to try it out ben :)
[06:35] <`ph8> looking forward to it
[06:35] <`ph8> hopefully this will fix my sata and my ide issues
[06:36] <`ph8> as if I know anything though, they might even by symptoms of the same problem
[08:17] <zul> bleah...i feel like shit
[09:24] <svu_tv> BenC, thanks for fixing G5. Will the fix be in the tomorrow's .ISO images? what was the problem?
[09:26] <BenC> svu_tv: Hopefully
[09:26] <BenC> was a bug in libata where it thought that irq==0 was a bad thing, when it isn't
[09:26] <svu_tv> nice. ok, i will try tomorrow and report
[09:26] <BenC> cruft from libpata patch
[09:27] <zul> i dont care about ia64 do i?
[09:27] <BenC> svu_tv: I know it works, since I had the same problem on my G5, and now it's booting and running edgy fine
[09:27] <BenC> so look forward to it :)
[09:27] <svu_tv> sweet, I just cannot believe till I see it myself:)
[09:27] <BenC> feh, no faith :P
[09:28] <svu_tv> :)
[10:09] <zul_> right...later
[11:27] <jbailey> BenC: Still around?  I have an amusing one. =)