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