[00:01] <RAOF> Perth's pretty nice, too. Although it's suffering somewhat from the house-requires-firstborn-child now.
[00:03] <lifeless> RAOF: what?
[00:04] <RAOF> Perth house prices are moderately nutty now, what with the (continuing) resource boom.
[00:04] <lifeless> yes
[00:04] <lifeless> but how does the firstborn come into it? or are you just saying expensive ? :)
[00:05] <RAOF> I'm just saying expensive.
[00:05] <RAOF> Perhaps in an overly roundabout way.
[10:59] <apw> smb, any sign of a .33.y appearing yet?
[10:59] <smb> Apart from the tree which is there?
[11:00] <smb> Nothing in GKH s repo
[11:04] <smb> Q-FUNK, I saw your comments/updates on the bugs. Though I don't think not having a initramfs is a real workaround as it still seems to cause issues. Just not fatal.
[11:05] <smb> Q-FUNK, Though as we had some issues with Atom based CPUs, you might try the following option "mem=nopentium"
[11:05] <Q-FUNK> smb: correct.  it makes the bug non-fatal, but it also deprives users from the initramfs functionalities.
[11:06] <smb> Q-FUNK, I know yours is a Geode, but who knows, whether those share something
[11:06] <Q-FUNK> smb: I was mostly currious about instructions on how to figure out exactly what part of the initramfs payload is the culprit that messes with sysfs in a fatal way, whenever an initramfs image is used.
[11:07] <Q-FUNK> smb: well, geode technically is a i586, but sure, I can try that cmdline option.
[11:07] <smb> Q-FUNK, I don't think anything specific, the chances are high that it too changes timings. And having one less fs mounted also changes the chances of hitting a weird behavior in fs code
[11:08] <smb> Q-FUNK, The option will cause it not to use large (4M) pages but only 4K ones.
[11:10] <smb> But the weird behavior there always could not really be associated to code in the fs. Actually the fact that reading values just put into variables back made the error go away completely very much points to something with processor caches. 
[11:12] <smb> Q-FUNK, I will be away for a bit, but please let us know if that option helps. It would give a bit more ideas on what to look for.
[11:13] <Q-FUNK> smb: I'm about to reboot the host with that option now.
[12:11] <Q-FUNK> smb: I'm not sure if these results are conclusive, but please see my additional comments.
[13:18]  * apw is curious as to the bug number
[13:22] <smb> ug 396286
[13:22] <smb> bug 396286
[13:23] <ubot3> Malone bug 396286 in linux "[Geode LX] [OLPC] 2.6.31-generic: kernel panic near the end of initramfs" [High,In progress] https://launchpad.net/bugs/396286
[13:24] <smb> apw, ^
[13:24] <apw> ta
[13:51] <Q-FUNK> apw: any ideas on how to solve this bug 396286 ?
[13:51] <ubot3> Malone bug 396286 in linux "[Geode LX] [OLPC] 2.6.31-generic: kernel panic near the end of initramfs" [High,In progress] https://launchpad.net/bugs/396286
[13:51] <apw> Q-FUNK, nothing other than what has been suggested
[13:52] <apw> Q-FUNK, in the bug you say 'noraid' helped but don't indicate in what way it helped
[13:52] <Q-FUNK> apw: I did. it made the error messages go away.
[13:53] <apw> your text says "without initramfs" to my reading it doesn't say if just the noraid is a work around with no other change
[13:58] <mozmck> I get four errors like this trying to compile the karmic kernel from git:
[13:58] <mozmck> drivers/usb/core/hcd.c:144: error: expected expression before '>>' token
[13:59] <mozmck> I'm using tag Ubuntu-2.6.31-20.57
[13:59] <mozmck> any idea why?
[13:59] <abogani> mozmck: Try git reset --hard origin
[14:00] <mozmck> bleh, I installed a patch, will it undo that?  I'm pretty sure my patch didn't touch that file...
[14:01] <abogani> mozmck: Yes it'll do it.
[14:02] <smb> Q-FUNK, apw My guess is that using noraid just avoids disk access because it does not need to scan for signatures...
[14:03] <Q-FUNK> smb: that sounds plausible.
[14:07] <Q-FUNK> smb: I really thought that this nopentium was gonna be it, since what it reports is a paging error.  apparently wasn't.
[14:09] <apw> so at least we have some knd of work around with noraid right
[14:09] <smb> Q-FUNK, It was worth a try. As it prevents the need to split large pages it would help if the Geode had issues there. Not that the CPU could have other issues. But I must say that I don't know how to proceed from here
[14:09] <Q-FUNK> it feels that way, although it baffles me as to why.  
[14:09] <smb> apw, If I understood correctly this is only without having a initrd as well
[14:10] <apw> smb, that is not what i was just told iiuc
[14:10] <Q-FUNK> right. it didn't seem to affect operation with an initrd.
[14:10] <apw> ok does that mean that with an initrd it was still broken or not?
[14:10] <Q-FUNK> still borken with an initrd.
[14:11] <Q-FUNK> it only made the errors disappear when running without initrd.
[14:14] <smb> It feels a bit like disk activity at early boot -> problem. Maybe bad DMA? But why does it work when getting past that stage? And why does it help to read back a value that got written to a struct (is it really read or from a cache)?
[14:14] <Q-FUNK> from cache.
[14:14] <Q-FUNK> the errors appeared with 2.6.31, when ACL caching was added to all filesystem types.
[14:15] <smb> Q-FUNK, I meant a cpu cache. The ACL caching just happens to be some structure that really has bad effects when being wrong
[14:15] <Q-FUNK> ah
[14:16] <apw> one has to be suspicious that this cpu has a flaw
[14:16] <Q-FUNK> I doubt it, since kernels up to 2.6.30 run flawlessly.
[14:17] <Q-FUNK> there's really something shady that was done starting with 2.6.31 that buggers.
[14:18] <smb> Q-FUNK, This can just be something that was flawed before, but with the other changes now takes place
[14:18] <Q-FUNK> then again, a similar change happened with 2.6.23 that already killed support for older geodes.  that time, it was a known change and easy to spot.  not so this time.
[14:19] <Q-FUNK> apw had tried to help me inviestigate that older bug.  it turns out it was a complete rewrite of how some interupts are handled.
[14:25] <Q-FUNK> and there was no turning back on that change.  support for older geodes is factually gone (unless someone is willing to figure out what's wrong with the new implementation for that interrupt handler).
[14:25] <smb> Q-FUNK, Well the code change that triggers your problems this time has showed no bad parts on its own. Make a structure a bit bigger to add two pointers. Set those pointers to -1 (all bits set) and take that value as unset. Checking access functions to these pointers they are not accessed after init. But still some bits get cleared. But not if you read back the pointers directly after you written the values to the structure.
[14:29] <Q-FUNK> I'm wondering if what we're not seeing might be in some new include that implements the ACL caching's core functions or a mere copy/paste error.
[14:46] <tgardner> apw, what are the odds that a karmic->lucid upgrade will wreck my life? nVidia dual head being the salient issue.
[14:46] <apw> do both your heads work now?
[14:46] <apw> there are also hints that suspend/resume does not work so well with nvidia
[14:47] <apw> i would be concerned, and recommend you take a usb stick and test it before committing
[14:47] <apw> tgardner, ^
[14:47] <tgardner> apw, yep. both heads work. I never suspend/resume this box anyways.
[14:48] <tgardner> apw, any reports of neauvou (sp?) working with 2 heads?
[14:49] <apw> nouveau, i think the only report i have had was from smb who had poor experience with his external
[14:49] <tgardner> apw, thats different then a dual display
[14:49] <tgardner> dual DVI
[14:50] <smb> Right, its only single VGA
[14:50] <smb> (but behind monitor switch)
[14:50] <apw> point, then i think you'd be the first.  i'd be interested to know how it worked out but have no bacjground
[14:50]  * tgardner is not often a first adopter :)
[14:58] <apw> tgardner, what does msm stand for in our new branch
[15:00] <tgardner> apw, mobile station modem
[15:09] <apw> tgardner, i assume i should be treating this like any other distro arm kernel and making it work with our userspace
[15:09] <tgardner> apw, yep, did I miss some config options?
[15:10] <apw> no but there is a bunch of recent backports to handle lucid userspace
[15:10] <apw> amd pulling them over now
[15:11] <tgardner> apw, ppoll et al?
[15:11] <apw> devtmpfs, modules.builtin async_populatefs, kmsg permissions and ppoll
[15:12] <tgardner> egads, I missed a bunch of stuff
[15:12] <apw> nothing major, will take 10 mins i hope
[15:13] <tgardner> apw, just rebase that branch instead of starting a new release. 
[15:13] <apw> tgardner, will do
[15:18] <apw> tgardner, how are we going to keep this branch in sync with other development?
[15:19] <tgardner> apw, other development? do you mean the chromeos tree?
[15:20] <apw> yeah i assume its going to be developed in a way that we have this lucid delta
[15:20] <apw> and need to maintain that on top
[15:21] <tgardner> apw, we _should_ be able to just cherrypick from the msm Qualcomm 2.6.21.12 branch. However, I don't expect that they'll be making many more changes.
[15:21] <tgardner> 2.6.31.12*
[15:21] <apw> tgardner, ok cool, i guess we'll need to get that documented, where the master tree is sort of thing
[15:22] <tgardner> apw, I created a README*
[15:22] <apw> ahh good
[15:23] <tgardner> apw, this may not be cast in stone yet. Martin is pushing to cut over to 2.6.32 sometime in March.
[15:23] <apw> so we may have a replacement branch at .32 anyhow
[15:23] <tgardner> apw, possibly.
[15:26] <apw> tgardner, ok am bulding the 'final' branch now ...
[15:27] <tgardner> apw, ah, at least those patches just slid in. I can't remember if the config checks ended up in the karmic tree, from whence this originated
[15:27] <apw> heh no they arn't there yet, the backport will pull those over, one more thing on my todo which is nearly done
[15:29] <apw> tgardner, you using anything special to build test this branch?
[15:29] <apw> /home/apw/build/lucid/ubuntu-lucid/arch/arm/mach-msm/avs_hw.S: Assembler messages:
[15:29] <apw> /home/apw/build/lucid/ubuntu-lucid/arch/arm/mach-msm/avs_hw.S:36: Error: selected processor does not support `fmrx r3,fpexc'
[15:30] <manjo> tgardner, I saw you ans to the firmware question I had, the fw is not in any of the linux-firmware or linux-firmware-nonfree tree but it is part of the tarball source package 
[15:30] <tgardner> apw, different cross-compile tools then I'm using?
[15:30] <apw> i am using the 2009q3 toolchains from code-sourcery, what you got?
[15:32] <tgardner> manjo, thats not really relevant. there must be a license for the firmware.
[15:32] <tgardner> apw, arm-2008q3, so I'm down-rev
[15:32] <apw> hrm
[15:32] <apw> tgardner, then i am suspicious its not toolchain
[15:32] <tgardner> apw, push your changes and I'm upgrade and get it sorted.
[15:32] <apw> can you pastebin your incantation to build it
[15:33] <apw> i suspect its me
[15:33] <tgardner> apw, hang on...
[15:33]  * apw holds everything and looks pensive
[15:33] <tgardner> apw, :) 'debuild --set-envvar=CONCURRENCY_LEVEL=1 --set-envvar=CROSS_COMPILE=arm-none-linux-gnueabi- --prepend-path=$(CROSSTOOLS_ROOT)/bin -b -nc -aarmel -us -uc'
[15:34] <tgardner> apw, nothing special really
[15:35] <apw> tgardner, ok branch pushed ... see if that builds for you
[15:35] <tgardner> apw, ack
[15:37] <manjo> tgardner, where should I be looking for a firmware license?
[15:37] <tgardner> manjo, I assume in that tarball.
[15:38] <tgardner> manjo, work with cnd. He's well versed in the issues.
[15:38] <manjo> cnd, ^^
[15:38] <cnd> manjo, give me a minute, writing up a bug report comment
[15:40] <apw> tgardner, same when invoked direct like you did ... oddness
[15:41] <tgardner> apw, building, it'll be done in a couple minutes
[15:41] <apw> its breaks right a the start for me, you using the old or new toolchaings
[15:41] <tgardner> the old one
[15:41] <tgardner> 2008q3
[15:41] <apw> yep, a good test
[15:42] <apw> thats a royal pain in the bottom
[15:42] <Sarvatt> has anyone seen any bugs around where 2.6.32-rc2+ need MMC/SDHC built into the kernel instead of as modules to get around hangs on suspend if a SD card has ever been mounted?
[15:42] <tgardner> apw, looks like its gonna finish
[15:43] <apw> Sarvatt, i think there was a few issues with mmc, i remember not being able to get them auto mounted, not sure i remember that specific error thoug
[15:43] <tgardner> apw, suppose there is a compiler flag that we need? I'll get the 2009q3 version and mess with it.
[15:43] <apw> tgardner, so the only question is why the tool chain is pissed off, is that a port issue
[15:43] <apw> i could upload it and see if it builds i guess
[15:44] <apw> would make testing hard and annoying tho
[15:44] <cnd> manjo, have you found the license in the tarball?
[15:44] <tgardner> apw, yeah, lets try and sort it before creating archive carnage
[15:44] <apw> tgardner, works for me
[15:44] <manjo> cnd, no there is no such file
[15:44] <Sarvatt> i built a kernel with SDHC/MMC built in and unsafe resume enabled and I'm able to suspend, but with the ubuntu kernels where they are modules it hangs when I try to suspend if I've ever mounted the sd and suspends fine even with a sd in the slot as long as I've never mounted it
[15:44] <Sarvatt> so strange
[15:44] <apw> tgardner, i am suspecting we need to get on the mir bandwagon too before we could upload it
[15:45] <cnd> manjo, does it seem to be an oversight on their part (i.e. it looks like it should be redistributable, but they don't have a license file)?
[15:45] <apw> Sarvatt, i suspend routinely with SDHC cards in my mini 10v
[15:45] <cnd> manjo: if so, I suggest emailing them to let them know
[15:45] <smb> Sarvatt, apw I think I tried to suspend on 2.6.32 but failed when a mmc card was mounted. But I have not tested lately...
[15:45] <cnd> manjo: for now though, we'll need to put it in linux-firmware-nonfree
[15:45] <manjo> cnd, I am emailing them now to find out 
[15:45] <Sarvatt> it doesnt work on a mini9, you're lucky apw :D 
[15:45] <smb> apw, Is yours the one attached to a usb controller...
[15:45] <manjo> cnd, is linux-firmware-nonfree part of our repos ? 
[15:45] <apw> manjo, is there no licence on the whole tarball?
[15:46] <cnd> manjo: for -nonfree you have to use apt-get source
[15:46] <cnd> manjo: there's no git tree
[15:46] <apw> if not its not obvious we can take the driver either
[15:46] <cnd> manjo: it should be fairly obvious how it builds in debian/rules
[15:46] <manjo> cnd, wait I am confused 
[15:47] <tgardner> apw, nah, I think this can be a universe package for the time being.
[15:47] <Sarvatt> smb: did it hang with the screen still on when you tried it?
[15:47] <manjo> cnd, there are is no repo for linux-firmware-nonfree, then where do I add the fw to ? 
[15:47] <apw> tgardner, is there any hoop jumping for uploading a new package to universe?
[15:48] <cnd> manjo: there's no git tree, the process is just 1. take the latest package source 2. update it 3. upload the new source to somewhere rtg can get to 4. tell him to upload it into lucid
[15:48] <tgardner> apw, nope, you only have to be a core-dev, or have rights to linux source package (AFAIK)
[15:48] <smb> Sarvatt, backlight, yes (but blank/black screen) Seems to be the same right now
[15:48] <manjo> cnd, you are suggesting a dkms package ? 
[15:48] <manjo> for the fw ? 
[15:48] <apw> good enough you'll be able to shove it in then, i won't as i suspect i can't ask for upload rights to it till you have uploaded it once
[15:48] <cnd> manjo: no, a dkms package is only meant for kernel modules
[15:49] <cnd> manjo: this is like typical debian packaging
[15:49] <Sarvatt> ah my screen still shows what was on it when i suspended here, it definitely does most of the suspend because i hear the acerhdf module unloading and fan spinning up and when i reboot the network is still disabled
[15:49] <cnd> manjo: dkms is a package you install that builds a new kernel module from source for every kernel you subsequently install, so it's a special type of debian package
[15:49] <cnd> manjo: most debian packages are already built in binary form, so they just install files to the filesystem
[15:50] <manjo> cnd, I know what debian packages are 
[15:50] <smb> Sarvatt, This is an Acer Aspire One as well?
[15:50] <manjo> I still don't get it 
[15:50] <Sarvatt> yeah acer aspire one AOA150
[15:50] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/477106/comments/6
[15:50] <ubot3> Malone bug 477106 in linux "[regression] lucid alpha-2 and earlier freeze upon suspend with sd card plugged in with some hardware" [Undecided,Confirmed] 
[15:50] <cnd> manjo: where's the disconnect?
[15:50] <smb> Sarvatt, Mine is AOA110
[15:50] <apw> manjo, the package is only in the archive, you get the source with apt-get source <foo>
[15:51] <apw> change it and upload that againt, it exists nowhere else but the archive
[15:51] <manjo> apw, ah! so don't add to /ubuntu 
[15:51] <Sarvatt> same thing then but mines the HDD model
[15:51] <apw> this is just for the firmware ...
[15:51] <apw> manjo, does this driver have any licence at all?  where did you get it?
[15:51] <cnd> apw, manjo, it's just for firmware-nonfree
[15:52] <cnd> linux-firmware is kept in git
[15:52] <apw> cnd, right
[15:52] <apw> i meant in his case we were talking about just the firmware
[15:52] <cnd> yeah
[15:52] <smb> Sarvatt, Yes, so mine fades the screen to dark, fan is spinning to, then stays there as well. I see some disk activity before which stops at some point
[15:53] <smb> Sarvatt, I believe apw's sd slot is a USB device while the aoa is a pci/jmicron
[15:53] <apw> smb, yes could be
[15:53] <apw> please don't tell me there are more issues, thanks a lot
[15:53]  * Sarvatt nods
[15:55] <smb> apw, I can tell you not if you prefer. :-P
[15:55] <Sarvatt> i'll have to try just building mmc/sdhci/sdhci-pci into the kernel and not enabling unsafe resume to see if that also fixes it
[15:56] <apw> Sarvatt, sounds good, get a bug filed and let us know the number
[15:56] <apw> i'll need to find someone who can reproduce it to try and fix it ... :)
[15:57] <bjf> ##
[15:57] <bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:57] <bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
[15:57] <bjf> ##
[15:59] <smb> Sarvatt, Yes, that would provide a better pointer. With unsafe suspend the card will not get ejected on suspend. iirc. And that might be the difference that counts
[16:00] <apw> smb, yeah mine get bounced every time i suspend i think
[16:01] <smb> apw, Though probably through a different mechanism. Just guessing, but usb probably has eject code in the core, while mmc does something similar somewhere else
[16:01] <apw> i think my big latop has an mmc, but that machine is broken for suspend already
[16:02]  * bjf just noticed the team meeting date in the topic
[16:02] <smb> bjf, But we cannot change it
[16:03] <smb> Sarvatt, In my tests I can suspend even after having had mounted the SD card. It just must not be mounted on suspend
[16:03] <apw> indeed one needs to be an op to do that
[16:03] <Sarvatt> apw: there's a bug here - https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/477106 building a kernel with just the sd stuff built in and no unsafe resume now to see if that also works. i always enable unsafe resume on the kernels I build because its a pain remounting every resume when I usually have files open on the SD at suspend time :D
[16:03] <ubot3> Malone bug 477106 in linux "[regression] lucid alpha-2 and earlier freeze upon suspend with sd card plugged in with some hardware" [Undecided,Confirmed] 
[16:04] <Sarvatt> smb: odd, here if I have ever mounted it even if its unmounted at suspend time it still hangs
[16:04] <Sarvatt> smb: are you using the left SD slot?
[16:05] <smb> Sarvatt, Yes, the right one only work(ed)s when I have a card in on boot 
[16:05] <apw> Keybuk, hey ... i have a preliminary patch for this readahead tracking, and wondered if you fancy testing it
[16:06] <Keybuk> apw: hey, could you mail me the details and stuff
[16:06] <Keybuk> I'm in the middle of Plymouth at the moment and can't really drop state since this does need to be working by β1
[16:07] <apw> Keybuk, will do
[16:17] <Sarvatt> btw smb, you might want to add enable_mtrr_cleanup mtrr_spare_reg_nr=1 to the kernel command line on your aspire one since they have screwy mtrr's
[16:18] <smb> Sarvatt, Heh, I know. I have enable_mtrr_cleanup alone. 
[16:18] <Sarvatt> any particular reason we dont enable pcie aspm in the kernel config?
[16:18] <smb> Sarvatt, Because its marked experimental and "in doubt say no"?
[16:20] <Sarvatt> i could have sworn experimental got removed a few releases ago but I just looked and you're right
[16:21] <bjf> smb, did you want to change the topic?
[16:23] <smb> bjf, Yes, tried it before
[16:23] <apw> you nneed to be an op, 
[16:24] <bjf> smb, I'm in #ubuntu-ops asking
[16:24] <johanbr> Sarvatt, https://bugs.launchpad.net/ubuntu/+source/pm-utils/+bug/342096 seems related and has some useful information
[16:24] <ubot3> Malone bug 342096 in pm-utils "SD Card containing /home corrupted on resume" [Undecided,Confirmed] 
[16:25] <Sarvatt>  /home on sd needs unsafe resume enabled in the kernel config, need to build your own kernel for that
[16:26]  * smb wonders whether that was his bug filed for Karmic
[16:27] <Sarvatt> that should probably be wontfix since i doubt you guys are ever going to enable unsafe resume by default :D
[16:28] <Sarvatt> oh looks like you did in hardy
[16:29] <smb> Sarvatt, Somehow it feels like unsafe might be safer than safe
[16:31] <Sarvatt> ohh nice
[16:31] <smb> Sarvatt, would unsafe resume work for you also when built as a module? Won't promise anything but it might help on a decision
[16:31] <Sarvatt> This option sets a default which can be overridden by the module parameter "removable=0" or "removable=1".                   
[16:31] <Sarvatt> can test that without rebuilding the kernel now
[16:36] <Sarvatt> unsafe resume depends on MMC being built in and not a module unfortunately
[16:37] <Sarvatt> ah nevermind CONFIG_MMC=y is what it needs and thats already there
[16:38] <Sarvatt> so booting with mmc.removable=1 should work, lets see
[16:42] <smb> Sarvatt, I am not sure were you exactly get that option from. The code looks to me like completely changing functions when UNSAFE_RESUME gets set
[16:46] <apw> jjohansen, hiya, i've been playing with rebasing the -ec2 kernel, as there are lots of interactions i have created ... there were two conflicts in the early patches is just correcting those the righ way forward
[16:46] <apw> jjohansen, will have some images from those for potential testing shortly
[16:46] <jjohansen> apw: okay
[16:46] <apw> am i correct to just fix conflicts or is there a magic way
[16:47] <jjohansen> apw: just fix them
[16:47] <apw> cool
[16:47] <jjohansen> and pray it doesn't break
[16:47] <jjohansen> :)
[16:48] <jjohansen> apw: I am running slightly behind (sleep caught up with me) will finish pam_apparmor today
[16:48] <bjf> ##
[16:48] <bjf> ## Kernel team meeting in 10 minutes
[16:48] <bjf> ##
[16:49] <apw> jjohansen, heh yeah thanks ...
[16:58] <bjf> ##
[16:58] <bjf> ## Meeting starting now
[16:58] <bjf> ##
[17:11] <apw> jjohansen, those new lucid ec2 kernels are here: http://people.canonical.com/~apw/ec2-lucid/
[17:12] <jjohansen> apw: thanks
[17:15] <apw> we don't get much in the way of interactivity in our meeting ... hrm
[17:15] <smb> apw, At least we get it done quick
[17:15] <cnd> apw, fyi I'm working on a patch against the alsa driver to prevent a warning message from polluting the boot splash screen (it's level is KERN_ERR, which upstream has acknowledged is too high)
[17:15] <cnd> oops, against acpi
[17:16] <cnd> not alsa
[17:16] <apw> cnd sounds ok, that would be a minor change, and a bug fix so i am sure we can get that past the ack process after freeze if its not ready in time
[17:16] <apw> smb, ^^
[17:16] <smb> cnd, That is a bug fix
[17:16] <smb> yeah
[17:16] <apw> cnd, but bringing it up is the right thing
[17:43] <Sarvatt> smb: i pasted that from the kernel config option, but its in drivers/mmc/core.c
[17:47] <smb> Sarvatt, Seems to be upstream but not Lucid. If I am not looking at the wrong version
[17:47] <Sarvatt> smb: booting with mmc.removable=0 (aka enabling unsafe resume) changed it so the screen goes black but the backlight is still on like you were saying you get
[17:48] <Sarvatt> well thats odd, i did it with the lucid kernel and it changed what happens when i suspend
[17:53] <smb> Sarvatt, That option was added in 2.6.33 and I do not remember it being in stable. Basically you know have the same behavior as I do without anything specially set.
[17:53] <smb> But the option should have no effect other than being ignored
[18:02] <tgardner> apw, if I was going to be able to enable 2 monitors, then one would expect they'd both be detected in 'Monitor Preferences", right?
[18:03] <apw> i would expect so, but i would also  run xrandr to see what happens when you do, and also to see what it says you have
[18:08] <tgardner> apw, hmm, it sorta thinks I _might_ have 2 displays. I think I'm gonna install to an external HD first and do some experimenting lest I totally wreck my dev box.
[18:09] <apw> tgardner, very sensible
[18:12] <Sarvatt> smb: without mmc.removable=0 and a SD mounted suspend freezes with the screen contents still on the screen, with the option I get a vt switch and the backlight is still on and the screen is blank. I just reproduced it 4 times with each method even though mmc.removable=0 doesn't do anything on 2.6.32-15. very confusing
[18:14] <Sarvatt> i still have the kernel where all the mmc stuff was built in though and I can just boot that with mmc.removable=1 to test if disabling unsafe resume with the modules built in works on .33 at least
[18:16] <smb> Sarvatt, That is indeed beyond my understanding. Yes, in .33 it should (in theory work that way)
[18:18] <Sarvatt> 2.6.33-rc8 + mmc.removable=1 (aka disabled unsafe resume config option) + mmc/sdhc modules built in works
[18:33] <manjo> cnd, apw sorry I had to drop off I had an emergency
[18:34] <cnd> manjo: how far did you get with the firmware stuff?
[18:34] <manjo> cnd, I will get together with you in 2 hrs or so and sort this firmaware stuff out 
[18:34] <cnd> manjo: ok
[18:34] <manjo> cnd, I still need to be away for a little bit.
[18:34] <cnd> manjo: if you have pressing, more important issues I can do the firmware work for you
[18:35] <manjo> cnd, you mean I just give you the fw files and you magically make them appear in /lib/firmaware/RTL8192SE/ ?
[18:35] <cnd> manjo: I mean I take the bug and work it and get it uploaded for you
[18:36] <manjo> cnd can I skype you quickly ?
[18:36] <cnd> sure, one sec
[18:36] <cnd> need to get headset
[18:37] <cnd> manjo: ready
[18:37] <manjo> I don't think I have you on my list
[18:38] <manjo> cnd, what skype id ? 
[18:38] <cnd> manjo: corp186
[18:38] <cnd> I'm not keen on providing my details in the skype directory :)
[18:51] <cnd> anyone familiar with hotplug?
[18:51] <cnd> I've read the README in Documentation, it says the kernel somehow calls "hotplug" in userspace to do stuff, and there's a sample hotplug script
[18:52] <cnd> but I don't know of any hotplug user space script or executable
[18:52] <smb> cnd, That sounds like old cruft, when there was a callout to a hotplug script
[18:52] <cnd> smb, do you know how it's done now?
[18:53] <cnd> is it all in-kernel through vfs?
[18:53] <smb> cnd, But that has been all replaced by netlink(?) messages. And udev reads those messages
[18:53] <cnd> hmmm
[18:56] <cnd> smb, looks like udev now handles hotplug events, but the mechanism is still the same
[18:56] <cnd> it's just that the hotplug script is now part of udev
[18:56] <cnd> I've found it in /lib/udev/firmware.sh
[18:59] <smb> cnd, The method is uevent, not netlink. Too late here. But its a bit more than that.
[18:59] <cnd> smb, I'm most interested in the firmware loading part, not the event propagation part, so I think I've found what I need
[19:00] <cnd> thanks
[19:00] <smb> cnd, ok.
[19:20] <Sarvatt> hmm wasn't this upstream in the 2.6.29 timeframe? UBUNTU: Disable 4MB page tables for Atom, work around errata AAE44 - http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=97684193e8c6fea095adcc4928f389b090559fc6
[19:21] <Sarvatt> aka shouldnt be needed to be backported to karmic-lucid
[19:23] <jjohansen> apw: your EC2 kernels are as good as the last set (ie. doesn't fix outstanding bug but doesn't introduce any new ones that I can see)
[19:24] <Sarvatt> yeah the fix is already there at line 535 - http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=blob;f=arch/x86/mm/pageattr.c;h=dd38bfbefd1fa1972f47403fa6b35e20663e3590;hb=97684193e8c6fea095adcc4928f389b090559fc6
[19:26] <Sarvatt> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=211b3d03c7400f48a781977a50104c9d12f4e229
[19:30] <Sarvatt> I put a note on https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/523112 about how its already in the kernel for lucid apw
[19:30] <ubot3> Malone bug 523112 in linux "Intel Atom CPU can oops because of bug listed in Intel errata AAH41 and AAE44" [Medium,Fix committed] 
[19:36] <cnd> is there anything that can be done about an rfkill hard blocked device?
[19:37] <cnd> the external switch is set to on, so I'm guessing it's something that's either in the bios or set in some windows driver?
[20:45] <cnd> bdmurray: I'm removing your patch tag on bug 530348 because the patch is diagnostic in nature, not a "fix"
[20:45] <ubot3> Malone bug 530348 in linux-firmware "e100: eth0: e100_request_firmware: Failed to load firmware "e100/d101m_ucode.bin" [Undecided,Incomplete] https://launchpad.net/bugs/530348
[20:46] <bdmurray> cnd: then maybe the attachment shouldn't be flagged as a patch?
[20:47] <cnd> bdmurray: it's still technically a patch
[20:47] <bdmurray> but not a patch that fixes the bug which is what the flag should be used for
[20:47] <ogasawara> bdmurray, cnd: yah, I'd vote to not flag the attachment as a patch
[20:47] <cnd> bdmurray: ok, bugzilla land is different
[20:48] <cnd> you flag things that are patches in bugzilla land so that the attachment viewer handles them correctly
[20:48] <cnd> maybe the flag should be called patch-fix?
[22:07] <manjo> cnd, I added the firmware to the linux-firware-nonfree package, and it build and works fine, how do I modifiy the changelog ? 
[22:07] <manjo> since this is not a git package 
[22:07] <manjo> or git tree
[22:07] <cnd> manjo: dch -i starts a new changelog template and opens it in your $EDITOR
[22:08] <manjo> duh! ok 
[22:09] <manjo> thought there was some other magic to it 
[22:17] <cnd> manjo: nope, pretty simle
[22:17] <cnd> the magic comes when you're using a git tree
[22:17] <manjo> cnd, after I do that just tar up the direcotry and upload to zinc ? 
[22:17] <cnd> manjo: so you've been building by running debuild right?
[22:17] <manjo> yes
[22:18] <akgraner> bjf, ping
[22:18] <cnd> so, first delete everything debuild created in .. (this will make it easier to figure out what's created in the next step)
[22:18] <cnd> manjo: then run debuild -S
[22:18] <cnd> that should create a source.changes file, .dsc file, and tarball file
[22:18] <manjo> ok
[22:18] <manjo> it did 
[22:19] <bjf> akgraner, yo!
[22:19] <cnd> then upload it somewhere, like I did at kernel.ubuntu.com/~cndougla/linux-firmware-nonfree
[22:20] <cnd> and then yell at rtg :)
[22:20] <manjo> cnd, why did mine get renamed to linux-firmware-nonfree-1.6ubuntu1 ?
[22:20] <cnd> manjo: ahhh, dch -i be default appends a new ubuntu release version (maybe there's a better option than -i?)
[22:21] <cnd> so in your changelog you should change that to -1.7
[22:21] <cnd> manjo: looks like dch -v 1.7 would have been the best route
[22:21] <manjo> ok I will redo
[22:22] <cnd> manjo: you don't really need to undo what you did though
[22:22] <cnd> just modify the changelog 
[22:29] <manjo> cnd, thanks a ton 
[22:29] <manjo> its done 
[22:30] <cnd> manjo: np, you got it uploaded some where?
[22:30] <manjo> cnd, sorry I had to step out a few times during the day... so get interrupted getting this done 
[22:30] <cnd> manjo: that's fine, I hope the therapy helped with whatever issues you had
[22:31] <manjo> yep its on my people page ... http://people.canonical.com/~manjo/lp530275-lucid/firmware-nonfree/
[22:31] <cnd> manjo: btw, you don't need the .build file
[22:31] <cnd> that's just a log of the build process
[22:31] <manjo> yeah I did an scp * so that got in as well
[22:31] <cnd> which for a source package build is even less useful :)
[22:32] <cnd> manjo: what did rtg say about the format of directories in the package?
[22:33] <manjo> cnd, I did not talk to him yet... I am shipping the firmware to lib/firmware and that is where the driver is picking it up from
[22:33] <manjo> cnd, but looks like its really a simple change to the rules script to do it 
[22:33] <manjo> right 
[22:33] <cnd> ok
[22:34] <manjo> cnd, too late in the cycle to mess with it now 
[22:35] <cnd> heh