[03:30] <shtylman> mcgrof: ping
[03:31] <crimsun> maybe on holiday given his client's idle time
[03:31] <shtylman> heh
[03:33] <shtylman> crimsun: same problem with rc1
[03:37] <crimsun> 3945?
[03:38] <shtylman> yea
[03:40] <crimsun> according to bc45a67079c916a9bd0a95b0b879cc0f259bac6e in wireless-testing.git, powersaving on it is broken
[03:40] <shtylman> oh goodie
[03:41] <crimsun> you could try looking in http://bugzilla.intellinuxwireless.org/
[03:42] <shtylman> how did you find that commit
[03:42] <crimsun> (that one is http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2125)
[03:42] <ubot3`> bugzilla.intellinuxwireless.org bug 2125 in firmware error "Microcode SW error: SYSASSERT (#5) Line 947" [Major,Verified: fixed] 
[03:42] <crimsun> I read the commit logs for wireless-testing.git
[03:45] <mcgrof> shtylman: pong
[03:46] <shtylman> mcgrof: we are investigating a wireless bug
[03:46] <shtylman> intel 3945 does not connect to anything
[03:47] <shtylman> crimsun: disabling power mode does not seem to work
[03:47] <shtylman> I don't think I have that specific firmware problem...
[03:47] <crimsun> shtylman: wireless isn't my area, hence my referral to mcgrof 
[03:47] <shtylman> gotcha :)
[03:50] <shtylman> mcgrof: trying to see how best to report this wireless problem
[03:50] <shtylman> or what to do about it in general
[03:50] <shtylman> as currently lucid with intel 3945 is useless on wifi
[03:52] <shtylman> I might have to try a wireless testing kernel
[03:52] <shtylman> any idea on how often those get merged?
[03:55] <RAOF> Um... my intel 3945 chip is happily connecting to my AP.
[03:56] <mcgrof> shtylman: http://wireless.kernel.org/en/users/Documentation/Reporting_bugs
[03:56] <shtylman> RAOF: in lucid?
[03:56] <RAOF> Yes, in Lucid.
[03:57] <shtylman> RAOF: um... how... :)
[03:57] <RAOF> By... not doing anything special?
[03:57] <shtylman> hmm
[03:57] <RAOF> I mean, it hasn't broken for a while :)
[03:58] <shtylman> thats interesting... cause those bug reports would suggest it has
[03:58] <shtylman> and I didn't do anything to mine
[03:58] <shtylman> and it didn't work
[03:58] <shtylman> what kernel version?
[04:02] <RAOF> 2.6.32-9
[04:03] <shtylman> wtf
[04:03] <RAOF> What firmware version is your driver loading?
[04:04] <RAOF> I remember fiddling with that at one point in the past.
[04:04] <shtylman> how can I tell?
[04:04] <RAOF> dmesg | grep iwl will include a "firmware: requesting ..." line.
[04:04] <RAOF> Mine's loading "iwlwifi-3945-2.ucode"
[04:05] <shtylman> same
[04:07] <RAOF> And your problem is that you can't connect to _anything_?  I'm connecting to a wpa2 AP now, but I have recently connected to an open AP as well.
[04:07] <shtylman> yep
[04:07] <shtylman> nothin
[04:08] <shtylman> I have a wpa2 ap .. 
[04:08] <shtylman> can't connect to it
[04:08] <shtylman> and I couldn't connect to an open one recently either
[04:08] <shtylman> wpa supplicant just spin
[04:08] <shtylman> *spins
[04:08] <RAOF> Sucks to be you apparently; mine hasn't had any trouble in Lucid at all.
[04:09] <crimsun> wait, wpa_supplicant or network-manager*?
[04:09] <shtylman> I kill network manager
[04:09] <shtylman> and try supplicant manually
[04:09] <shtylman> but neither one connectes
[04:09] <shtylman> *connects
[04:09] <crimsun> ok, and if you use wireless-tools directly with an open AP?
[04:09] <shtylman> havn't tried that
[04:10] <shtylman> oh wait
[04:10] <shtylman> I think it worked with power off
[04:11] <shtylman> my problem might have been that network manager wasn't fully dead... so with NM dead, I could use wpa supplicant manually
[04:11] <shtylman> with power management off
[04:13] <shtylman> so now... manual works... just no network manager...
[04:13] <shtylman> at this point I guess it ceases to be a kernel problem :)
[04:14] <crimsun> well, if it's ok with pm off, then you may be triggering that bug I mentioned earlier
[04:15] <shtylman> right
[04:15] <shtylman> but I never saw the fw error before turning the power management off
[04:15] <shtylman> oh well
[04:16] <shtylman> tragic that power management doesn't work for it
[04:16] <shtylman> at least wireless works now
[04:16] <shtylman> battery will have to suffer
[04:19] <crimsun> suffer is probably a bit drastic
[04:20] <shtylman> hehe
[04:25] <shtylman> thanks for the help peoples
[07:21] <clickninja> Hi! I'm using Karmic and I've run into the "low memory corruption" bug (324894), but without having to suspend/resume. Does anyone know something about the background of this bug, or any fix for it? I've found this thread on LKML: http://osdir.com/ml/linux-kernel/2009-07/msg02383.html Based on that it seems to be a widespread problem.
[12:26]  * lamont finds it sad that the system doesn't want to let him strace pid 1
[12:27] <hyperair> why wouldn't it?
[12:27] <hyperair> it seems to work for me
[12:28] <lamont> EPERM it says
[12:29] <maxb> I seem to have found an i915 regression in 2.6.32 (bug 492392). What is the proper upstream bug reporting place?
[12:29] <ubot3`> Malone bug 492392 in linux "[lucid, intel] After suspend, flickering screen and then blank screen." [Medium,Triaged] https://launchpad.net/bugs/492392
[13:35] <apw> maxb, normally one creates a bug in the kernel bugzilla
[13:35] <apw> its likley helpful to report it in email to jessie barnes and dave aerlie
[13:35] <apw> maxb, did you manage to bisect for it?
[13:38] <apw> ahh in 2.6.32-rc1
[13:38] <apw> maxb have you tested the latest 2.6.32.2 kernel at all from the mainline builds?
[13:54] <Ng> can I poke apport into reporting a kernel oops that happened when apport wasn't running, but is logged?
[13:55] <Ng> I was rsyncing my laptop to a USB disk and some kind of minor kernel explosion killed X
[14:18] <maxb> apw: I have not yet, though I seem to be having some success with i915 from 2.6.31 backported against a 2.6.32 kernel, so localizing it to that module
[14:20] <apw> coo
[14:20] <apw> cool
[14:22] <maxb> I don't think I have an ironlake, but it's possible "drm/i915: Fix LVDS stability issue on Ironlake" might have some bearing on the problem even so
[14:24] <apw> its a big patch changing generic i915 code, so could affect you
[14:26]  * maxb downloads
[14:33] <apw> maxb, you able to make a kernel with that reverted?
[14:33] <apw> Ng it is meant to do that, pick them up later i believe
[14:33] <Ng> oh, hrm
[15:02] <Ng> apw: I dunno if it would have noticed itself, but enabling apport and kerneloops and then poking kerneloops to read /var/log/syslog at least did enough to get me a .crash I could turn into bug #499858 :)
[15:02] <ubot3`> Malone bug 499858 in linux "kernel oops and X crash while copying data to USB disk" [Undecided,New] https://launchpad.net/bugs/499858
[15:07] <apw> Ng i don't see any oops can you look in the files in /var/log and see if one was captured ...
[15:08] <Ng> huh, I have the dmesg.txt from sshing in while it was in the crashed state, I'll attach that
[15:09] <Ng> apw: done
[15:09] <apw> geat
[15:11] <hyperair> are there any issues that could come out of disabling apic?
[15:12] <apw> disabling apic, means we use differnet routing for interrupts, in theory not a disaster
[15:12] <apw> you shouldn't have to tho
[15:15] <hyperair> i'm considering enabling it and seeing how it goes for my machine
[15:15] <hyperair> i mean disabling apic
[15:16] <hyperair> i got strange cpu-level (presumably) hangs that whacked up a fair number of drivers on my system
[15:16] <hyperair> tg3, and iwlagn in particular
[15:16] <hyperair> then something in acpi started complaining in dmesg
[15:16] <hyperair> and psmouse lost synchronization
[15:16] <Michalxo> hello! is there somewhere around kernel-ppa for karmic? I am getting 404 error with deb http://ppa.launchpad.net/kernel-ppa/ppa/ubuntu karmic main
[15:16] <Michalxo> deb-src http://ppa.launchpad.net/kernel-ppa/ppa/ubuntu karmic main
[15:16] <Michalxo> deb http://kernel.ubuntu.com/~kernel-ppa/mainline/ubuntu karmic main
[15:16] <Michalxo> deb-src http://kernel.ubuntu.com/~kernel-ppa/mainline/ppa/ubuntu karmic main
[15:17] <hyperair> apw: http://pastebin.com/f322a1676
[15:18] <apw> hyperair, what were the few lines before those
[15:18] <rtg> Michalxo, the mainline series have to be installed directly from kernel.ubuntu.com/~kernel-ppa
[15:20] <Michalxo> aha, so do I have a "bug" somewhere in my sources lines?
[15:20] <Michalxo> I will remove "mainline" line
[15:20] <rtg> Michalxo, right, there is no 'mainline' PPA
[15:20] <Michalxo> but this "deb http://ppa.launchpad.net/kernel-ppa/ppa/ubuntu karmic main" should work, right?
[15:21] <rtg> Michalxo, it ought to, but there are no packages there
[15:21] <Michalxo> aha, so how/from where can I get "the latest" kernels?
[15:21] <rtg> Michalxo, https://wiki.ubuntu.com/KernelTeam/MainlineBuilds
[15:23] <Michalxo> oh, so there is only manual isntalling.. no apt-like thing
[15:24] <rtg> Michalxo, that is correct. we did it that way with malice aforethought.
[15:26] <Michalxo> aha.. 
[15:27] <Michalxo> thank you very much :-)
[15:27] <Michalxo> enjoy and have a happy "holidays"
[15:33] <hyperair> apw: http://pastebin.com/f33d3433a
[16:15] <apw> RAOF, about?
[16:15] <apw> hyperair, thats most of it, can you get another 3 lines or so in case it said anything just before
[16:16] <apw> RAOF, your nouveau-scratchpad branch thingy seems to be down
[16:16] <apw> hyperair, what is there looks like a bug to me, and not something apic on or off would necessarily fix
[16:17] <apw> hyperair, get it in a bug too 
[16:49] <hyperair> apw: http://pastebin.com/f3a0db8f4 this would be everything
[16:52] <hyperair> ..weird, why does noapic turn off one of my CPUs?!
[16:53] <rtg> hyperair, I think its because its the APIC subsystem that is responsible for enabling subsequent CPUs
[16:53] <hyperair> ah hell.
[16:53] <hyperair> is there another way to enable my other CPUs?
[16:54] <apw> not that i know of
[16:54] <apw> they would be on if it had detected them
[16:54]  * hyperair sighs
[16:54] <hyperair> this sucks
[16:55] <apw> that trace shows your intel wireless breaking cause it failed to load the firmware, due to a memory allocation failure
[16:55] <hyperair> hmm is that so?
[16:55] <hyperair> but it was working fine before that
[16:55] <apw> at the top there yes
[16:55] <hyperair> there was some SW microcode error
[16:55] <apw> right the card looks to have 'crashed' and the restarted failed as we couldn't get the firmware
[16:56] <hyperair> indeed
[16:56] <hyperair> in fact, everything was crashing one by one
[16:56] <hyperair> including psmouse
[16:56] <hyperair> and tg3
[16:56] <hyperair> tg3 has a very interesting side effect
[16:56] <hyperair> it will be able to receive, but not send
[16:58] <apw> don't see anything about the mouse there
[17:04] <hyperair> hmm weird
[17:12] <hyperair> apw: okay, this time around, with noapic and nolapic, i still get the hangs, but i get these two lines..
[17:13] <hyperair> [ 5245.062585] iwlagn 0000:04:00.0: index 0 already used in uCode key table.
[17:13] <hyperair> [ 5257.876381] iwlagn 0000:04:00.0: Hardware error detected.  Restarting.
[17:13] <apw> thats definatly the card being unhappy
[17:13] <hyperair> indeed
[17:13] <apw> though normally they recover and continue
[17:13] <hyperair> it did recover and continue
[17:13] <hyperair> i'm on a wireless connection now
[17:13] <apw> that is just luck based on how long after boot
[17:14] <hyperair> and i didn't disconnect at all
[17:14] <hyperair> luck?
[17:14] <apw> as the previous one was an allocation order 4 which failed, which is a pretty big allocation
[17:14] <hyperair> ah i see
[17:14] <apw> yeah ... the longer you are up the less likely an order-4 allocation is possible
[17:14] <hyperair> i see.
[17:14] <apw> its not sensible for the driver to rely on it
[17:15] <apw> then again the microcode should not be going pop ever eit
[17:15] <apw> either
[17:15] <hyperair> heh yeah
[17:15] <hyperair> well actually i think it's all related to some other issue..
[17:15] <hyperair> possibly timing or something?
[17:15] <hyperair> when playing 3d games i get these weird spurious hangs that get increasingly frequent
[17:16] <apw> hrm
[17:16] <hyperair> when they get severe enough, everything starts going haywire
[17:16] <hyperair> mouse, tg3, iwlagn
[17:16] <hyperair> those are the most prominent ones
[17:16] <hyperair> in the case of tg3, a suspend/resume fixes it
[17:16] <hyperair> rmmod and modprobe again doesn't work
[17:17]  * hyperair brb. need to reclaim my lost CPU core
[17:25] <hagabaka> I have a few old linux-image and linux-headers packages, and even when I mark them as auto, aptitude won't remove them, because they have "Provides: linux-image/headers". is that how it's supposed to be?
[18:09] <maxb> apw: With what reverted?
[18:09] <apw> the patch you were having trouble with
[18:09] <maxb> I'm running 2.6.32.2 now, we shall see if it breaks
[18:09] <apw> i think .2 has that patch yes
[18:10] <maxb> Oh. Well, my trouble starts after a fairly immense merge from drm-intel-next before 2.6.32-rc1
[18:10] <maxb> Reverting the entirety of i915 back to before that seems to help
[18:11] <maxb> But, that's such a volume of changes, that it doesn't say a huge amount
[18:11] <maxb> I'm getting some flickers with 2.6.32.2
[18:11] <maxb> Different kind of visual artifacts than I was seeing with 2.6.32.1, but still a problem
[18:12] <maxb> I shall continue to run with it to see if the complete blank screen failure case happens.
[18:12] <maxb> Unfortunately I have no way to reproduce it on demand, I just have to use the computer for a few hours
[18:27] <lamont> [  129.431995] [drm:radeon_cp_reset] *ERROR* radeon_cp_reset called without lock held, held  -2147483648 owner ebddd840 ee217600
[18:27] <lamont> meh
[21:32] <RAOF> apw: Hi.  Are you still here?
[21:33] <RAOF> apw: It seems I've got dns problems - http://121.44.54.198/kernel-lucid-nouveau.git/ will get you the branch.
[21:41] <RAOF> apw: dns fixed; http://cooperteam.net/kernel-lucid-nouveau.git should work now.