[00:11] <shtylman> kernel team!
[00:11] <shtylman> bug #398059
[00:11] <ubot3> Malone bug 398059 in linux "system does not boot due to device-mapper error" [Undecided,Confirmed] https://launchpad.net/bugs/398059
[00:11] <shtylman> can someone bring that into our  kernel line?? (patch with last post)
[00:11] <shtylman> this is a major showstopper for some people...
[00:11] <shtylman> or at least update us on the status... :)
[00:11] <shtylman> much appreciated
[00:56] <dtchen> shtylman: i have to run another build anyhow, so i'm happy to merge that into my tree if you'd like to test it
[00:57] <dtchen> shtylman: i suspect it hasn't been merged into ubuntu-karmic.git due to it not appearing in linux-2.6.git, either
[00:57] <shtylman> dtchen: will gladly test it :)
[00:57] <shtylman> just point me to the right ppa or whatnot and I will try it
[01:18] <dtchen> shtylman: will be ~90 minutes
[01:18] <shtylman> sounds good
[01:19] <dtchen> shtylman: my target arch is amd64, so i hope you're running amd64 ;-)
[01:19] <shtylman> indeed i am ;)
[02:23] <Brent_Roth> excuse me, is anyone available to aid me with part of /usr/src/linux/arch/x86/kernel/entry_64.S ??
[02:24] <dtchen> you might have better luck in #kernelnewies on irc.oftc.net
[02:24] <Brent_Roth> dtchen ok, thank you
[02:24] <dtchen> err, ..newbies
[02:24] <Brent_Roth> sorry for coming to wrong channel
[03:41] <dtchen> shtylman: http://kernel.ubuntu.com/~dtchen/test-kernels/lp398059/
[03:42] <shtylman> pull and install all 3?
[03:42] <dtchen> shtylman: yes (source is http://kernel.ubuntu.com/git?p=dtchen/ubuntu-karmic.git;a=shortlog;h=refs/heads/lp398059)
[03:43] <shtylman> cool
[03:43] <shtylman> alright ... lemme give it a go
[03:43] <shtylman> damn...I love my download speed
[03:47] <shtylman> dtchen: installed...will reboot (crosses fingers)
[03:50] <shtylman> dtchen: uname: Linux namlyths 2.6.31-4-generic #22~crimsun1lp398059 SMP Fri Jul 24 00:17:51 UTC 2009 x86_64 GNU/Linux
[03:50] <shtylman> :)
[03:50] <dtchen> excellent
[03:50] <shtylman> nice...glad to see the patch worked...
[03:50] <shtylman> now to get it into mainline :)
[03:50] <dtchen> shtylman: please comment in the bug report
[03:50] <shtylman> will do
[05:07] <albertico> hi... I am having a problem with the kacpid process consuming 80% of my processor... is there a way to fix this?
[05:07] <albertico> I am running ubuntu 9.04 with 2.6.28-13 kernel
[13:08] <rtg_> apw, -meta uploaded
[13:08] <apw> thank you sir
[13:11] <apw> smb, how are your sd cards on your AA ?  i am finding on my 10v that they are only detected on first insertion
[13:12] <smb> apw, In/out works. Just the slightly strange fact that the right slot needs a card in on boot to work
[13:13] <smb> apw, At least it _did_ work like that. I have not been actively using them for a few releases
[13:14] <smb> apw, looks still the same
[13:21] <rtg_> apw, pushed newrelease
[13:21] <apw> rtg thanks
[13:25] <rtg_> apw, there are a lot of CONFIG_CAN modules.
[13:26] <amitk> rtg_: apw: can I expect the configs to remains stable today?
[13:26] <rtg_> amitk, I'm wanting to commit CONFIG_CAN in the worst way :)
[13:27] <rtg_> but I'll wait.
[13:27] <amitk> :)
[13:27] <amitk> good, I want this patchset committed before another config upheaval
[13:27] <apw> i have no plans to chage the config
[13:29] <apw> anyone know how one rescans a usb channel after ejecting something on it?
[13:30] <amitk> apw: at the bus level?
[13:31] <apw> yeah you know if you 'eject' a usb key it sort of goes away and you unplug replug it to return it to life
[13:32] <apw> is there a way to trigger that without removing/reinserting?
[13:33] <amitk> ohh, don't know how to do it w/o reinserting
[13:34] <apw> just figured out why my sd slot stops working on the mini 10v, basically its a usb connected card reader slot
[13:34] <apw> so when you 'eject' it in nautilus, that ejects the usb card reader device which i cannot then unplug and replug as its inside
[13:39] <hyperair> so just unmount?
[13:39] <amitk> hmm.. This patch is causing rebase issues... "UBUNTU: SAUCE: hotkey quirks for various Zeptro Znote and Fujitsu Amilo laptops"
[13:40] <amitk> apw: did you see this when you rebased to rc4?
[13:41] <apw> no this is normal for this dell
[13:41] <apw> i think its problem that would always be seen on any version from the nature of it
[13:44] <amitk> apw: did you see a problem when you rebased to rc4?
[13:44] <apw> amitk, asking about my eject issue, or the rebase in general
[13:45] <apw> the eject issue i had before on the -3 kernel too
[13:45] <amitk> apw: rebase to rc4. I am seeing a problem with an old SAUCE patch (^^^) when I try to rebase
[13:45] <amitk> not talking about eject here...
[13:46] <apw> amitk, is it one of your patches?
[13:46] <apw> are you just doing a git rebase origin/master ?
[13:46] <amitk> nope, an old patch
[13:46] <apw> ok then i think you are doing the rebase wrong, as we have rebased the tree underneath you
[13:46] <apw> you would want to do a git rebase --onto origin/master <sha1 of the commit before the first patch you want to move>
[13:47] <apw> as you are not interested in rebaseing the patches below those
[13:47] <apw> as i already did them
[13:47] <apw> make any sense?
[13:47] <amitk> i think, yes
[13:48] <apw> basically git rebase thinks all of the patches since linus is to be rebased by default which is not what you care about
[13:49] <amitk> yup, rebase of a rebase. Works now, thanks.
[14:39] <amitk> rtg_: apw: git://kernel.ubuntu.com/amitk/ubuntu-fsl-2.6.31.git has the rebased tree. I'll send email to the list now.
[14:39] <apw> ta
[15:07] <rtg_> amitk, do you think its OK to ignore ARM ABI changes with this patch set?
[15:09] <amitk> rtg_: yes please. The old flavour was a dud.
[15:10] <rtg_> amitk, will do
[15:11] <amitk> manjo: I've pushed the initial rebase to my git tree. I still have to do some more adding of mx51 conditionals. But this kernel boots and stays alive on the device for now. So I'm asking for a merge to enable -mobile to start building images.
[15:11] <amitk> manjo: IOW, be gentle :)
[15:12] <manjo> amitk, :) will take a look 
[15:12] <EagleScreen> hi
[15:12] <EagleScreen> dvb-usb-af9015 is not working in karmic
[15:13] <EagleScreen> it shows some crash by dmesg
[15:17] <manjo> amitk, your email says pls pull... but from where ? 
[15:18] <rtg_> manjo, I've got it covered
[15:18] <rtg_> git://kernel.ubuntu.com/amitk/ubuntu-fsl-2.6.31.git master
[15:18] <amitk> manjo: it points to the git repo later in the email
[15:18] <manjo> rtg_, I just wanted to take a look... 
[15:19] <amitk> manjo: http://kernel.ubuntu.com/git?p=amitk/ubuntu-fsl-2.6.31.git;a=summary
[15:19] <manjo> amitk, yeah i see .. it came as an attachment "request-pull"
[15:20]  * amitk disappears for a while
[15:23] <manjo> amitk, so you did not fix ./arch/arm/plat-mxc/gpio.c ? 
[15:34] <amitk> manjo: i have a patch in my tree. I'll push it as part of cleanup after the initial kernel is available to the mobile team
[15:39] <maks_> hello have asked for initramfs-tools merge, will stick around so if any questions arise..
[15:39] <rtg_> maks_, its not really a question for the kernel team. you should be bugging the platform team, e.g., Keybuk
[15:41] <Keybuk> maks_: I mailed you a while back about the direction you were taking initramfs-tools
[15:42] <Keybuk> you didn't reply
[16:20] <maks_> Keybuk: Message-Id: <1244716927.4532.34.camel@quest>
[16:20] <maks_> sure i read it.
[16:21] <maks_> it's still lying in my inbox, didn't know what to say..
[16:21] <maks_> anyway you added kms module too.
[16:21] <Keybuk> no, Colin did
[16:21] <Keybuk> my plan with initramfs is to strip it right back down to its bare essentials
[16:21] <Keybuk> it should only mount the root filesystem
[16:21] <maks_> rtg_: afaik it is a kernel team question as the last merge was done by the kernel team
[16:22] <Keybuk> no other fancy stuff
[16:22] <Keybuk> I'm considering switching to dracut for better alignment with other distros as well
[16:22] <maks_> well MODULES=dep provides you in most cases with a small initramfs
[16:22] <rtg_> maks_, only by accident :)
[16:22] <Keybuk> maks_: that's not what I mean
[16:23] <maks_> Keybuk: speaking of you as the ubuntu version
[16:23] <maks_> dracut is interesting a agree
[16:23] <maks_> and klibc is dommed to failure
[16:23] <maks_> as hpa has no time for it.
[16:23] <Keybuk> MODULES=dep vs. MODULES=most is not the same as "stick everything in the initramfs just because it's there"
[16:24]  * maks_ neither since some time, my phd needs work :)
[16:24] <maks_> and klibc needs massive uplifting
[16:24] <maks_> the plan was to wait for util-linux to hit sid
[16:24] <maks_> and then to use the generic utilities
[16:25] <maks_> people already complain about busybox.
[16:25] <maks_> Keybuk: please be more specific.
[16:26] <Keybuk> I have been specific
[16:26] <maks_> afais from your kernel config that was quite strange you had old ide build in.
[16:26] <Keybuk> the initramfs should only mount the root filesystem
[16:26] <maks_> so you wouldn't need initramfs in most cases.
[16:27] <Keybuk> err, what?
[16:27] <maks_> Keybuk: that would axe what?
[16:27] <Keybuk> maks_: there's no need to set up console fonts, keymaps, locales, kms, splash screens, etc.
[16:28] <maks_> Keybuk: keymaps are needed for encrypted root
[16:29] <maks_> don't think i have them right now in, if you haven't cryptestup installed.
[16:29] <maks_> locales shouldn't be either
[16:29] <Keybuk> encrypted root need not be enabled by default
[16:29] <Keybuk> if someone wants it, they should turn it on, and then rebuild their initramfs
[16:31] <maks_> so you want a turn from "Put everything on initramfs as user might need it"
[16:31] <Keybuk> yes
[16:32] <Keybuk> indeed, we've never done that
[16:32] <maks_> in debian that would put most work on the hook maintainer
[16:32] <maks_> aka lvm mdadm cryptsetup maintainer
[16:32] <Keybuk> the entire reason Jeff wrote initramfs-tools to be modular was so that it could be extended by installing additional packages
[16:32] <maks_> known
[16:35] <maks_> so what?
[16:35] <Keybuk> ?
[16:36] <Keybuk> so you've gone a different direction with initramfs-tools in Debian and made it do everything out of the box by default in the initramfs-tools package
[16:36] <Keybuk> rather than making other packages ship their own hooks
[16:36] <Keybuk> so I haven't merged it
[16:36] <maks_> woow
[16:36] <maks_> you are insuniating things
[16:36] <Keybuk> no... I'm reading diffs and changelogs
[16:37] <Keybuk> and when I asked you about it, you didn't bother to reply to my mail
[16:38] <maks_> your mail didn't leave much room to a reply afais
[16:38] <Keybuk> I thought it was a good start for a dialogue about what we wanted from initramfs-tools
[16:38] <Keybuk> how we could make it more modular and configurable
[16:38] <Keybuk> etc.
[16:40] <maks_> well that thought wasn't how i read the mail.
[16:41] <maks_> anyway thanks for pointer and you'll get a reply.
[16:41] <Keybuk> thanks
[16:41] <maks_> over and out, back to work.
[16:41] <Keybuk> anyway, technical disagreements aside
[16:41] <Keybuk> we're after merge window closure now
[16:41] <Keybuk> so the next merge would be for karmic+1
[16:41] <Keybuk> and will be competing with "use dracut instead"
[16:42] <maks_> no trouble with dracut they have it booting on debian itself afaik
[16:42] <maks_> not that it is a slim initramfs afaik
[16:43] <Keybuk> it's much simpler
[16:43] <Keybuk> and has "I want these bits" built in from the start
[16:45]  * Ng wonders if -4 fixes rfkill :D
[16:45] <rtg_> Ng, nope, but I'm working on it
[16:45] <Ng> ah
[16:47] <rtg_> Ng, I have the OK to upload wireless-tools from slangasek and Keybuk with the rfkill application from sipsolutions.org (the guy that rewrote rfkill)
[16:47] <Ng> :)
[16:47] <rtg_> Ng, I wast just waiting on A3 to clear the decks, so I should be able to finish it up today.
[17:20] <nduthoit> I'm having a problem setting acpi temperature trip_points: 'echo -n "65:0:55:60:0" > /proc/acpi/thermal_zone/THRM/trip_points' returns "-bash: echo: write error: Input/output error" anyone know a different/new way to set trip_points? Thanks
[17:22] <nduthoit> wrong channel?
[18:23] <rtg_> apw, karmic pushed
[18:23] <apw> anything exciting?
[18:23] <rtg_> apw, mostly armel stuff, misc other patches.
[18:24] <rtg_> I'm tempted to squash the IMX51 stuff into one giant patch
[18:24] <apw> ahh ok ... so a biggy
[18:24] <apw> i say lets see how we get through a rebase before that
[18:24] <apw> its likely to be a world of pain either way i guess
[18:25] <rtg_> apw, yeah. I'm thinking about uploading this afternoon (no ABI bump)
[18:25] <apw> presumably the arm is a bumper but as noone is using it as it doens't work it should be ok
[18:26] <rtg_> apw, I added ignores after consulting with amitk
[18:26] <apw> yeah the previous amx51 wasn't so noone could be running it so ... it seems safe to me 
[18:27] <rtg_> one can get away with murder during the dev cycle :)
[18:27] <bjf> rtg_, my thoughts on a big squash are it's easier to find a single buggy commit with a bisect if it's multiples
[18:28] <rtg_> bjf, that would normally be my approach, but there are several in that pile that are not bi-sectable
[18:28] <rtg_> e.g., won't compile if you reset HEAD back to the right spot
[18:29] <bjf> rtg_ that's true
[18:31] <rtg_> bjf, while I'm developing something I'll have lots of small commits. When I'm at a point where the series works I'll usually squash them into logical, bi-sectable patches.
[18:32] <bjf> rtg_ that makes sense for things you are developing
[18:33] <bjf> rtg_, but for things like the FSL patches, I was trying to keep my mods separate from the FSL changes
[18:34] <bjf> rtg_, also, if i needed to communicate with FSL on something I could give them a sha1 for the individual change
[18:35] <bjf> rtg_, if it's one commit, it can be more difficult
[18:35] <bjf> rtg_, just my thinking, don't claim it's right :-)
[18:35] <rtg_> bjf, A lot of the Karmic patches appear to be fix-ups that amitk did after the FSL patches were applied. Those are the patches that I'd consider squashing.
[18:36] <bjf> rtg_, that makes sense
[18:36] <bjf> rtg_, it's the next batch that I'm thinking of
[19:01] <apw> fraken-kernel
[19:02] <rtg_> apw, passowrd ?
[19:03] <apw> heh no a description of the melange 
[22:53] <billybigrigger> anyone alive?
[23:07] <jjohansen> billybigrigger: its friday afternoon so no