[05:39] <dileks> hi. good its called arch/arm64 :-)
[05:39] <dileks> http://thread.gmane.org/gmane.linux.kernel/1324121/focus%3D1333603
=== smb` is now known as smb
=== amitk is now known as amitk-afk
[07:32]  * smb decides that having a cup of coffee standing in front of him probably is not enough...
[07:40] <apw> infinity, what was the arch name in debian for arm64 in the end
[07:41] <smb> aaaarch64?
[07:44] <apw> smb, dunno, dileks was just pointing out the kernel looks to be changing to arm64
[07:45] <smb> just being more than an hour ago but yeah
[07:45] <smb> they probably got too many puns for the other name
[07:46] <apw> indeed almost exactly two apparenly ...
[07:46]  * apw bets this means we end up with the same issues with name
[07:47] <apw> between debian and the kernel again ... sigh
[07:48] <smb> Why should they deserve a better fate than amd64/x86_64
[07:49]  * smb still feels more tired than before going to sleep...
[07:52] <infinity> apw: arm64.
[07:52] <infinity> apw: aarch64 is just the GNU triplet, the dpkg arch is arm64.
[07:53] <infinity> apw: You can thank me for that sanity. :P
[07:53] <apw> heh so we managed to get them inconsistenat anyhow
[07:53] <apw> thanks :)
[07:54] <infinity> apw: Yeah, people whined about the triplet/dpkg inconsistency, and I don't care.
[07:54] <infinity> apw: Making the triplet something that isn't arm* means that the tons of tools out there that assume arm* = aarch32 won't explode.
[07:54] <apw> having most of an arch name be arch is pretty uselss as its effectivly a64
[07:55] <apw> which is pretty greedy namespace wise
[07:55] <infinity> apw: Yeahp, but whatever.  Not my concern.  Anything !arm* is fine by me. :P
[07:57] <infinity> apw: Maybe someone will talk ARM into renaming the GNU triplet, but I'm kinda hoping not, as it will mean redoing all their toolchain patches, plus any bootstrap porting they've done.
[07:58] <infinity> apw: (Plus the above conflict, which means having to go over every single build system with a fine-toothed comb)
[08:03] <apw> infinity, its not sounding perfect indeed
[08:14] <dileks> I looked (quickly) over a bit that arm64/aarch64 patchset, so its a bit inconsistent in usage. in terms of "port" they mostly use "arm64", in case of arch(itecture) aarch64 is used. so there should be a clear usage of terms. for linux/arch/arm64/ that is what kernel people have expected
[08:14]  * dileks looked into ia32 below arch/ and naming of files, hmm, yes, what shall I say :-(
[09:21] <henrix> smb: fyi, i'm tagging bug #999755 as verified in oneiric
[09:22] <ubot2> Launchpad bug 999755 in linux "Kernel crash in rb_next doing ohai loops" [Undecided,In progress] https://launchpad.net/bugs/999755
[09:22] <smb> henrix, Ok, cool. Yeah, it is as verified as it will get. Thanks
[09:22] <henrix> smb: :)
=== henrix_ is now known as henrix
[11:21] <apw> warning warning will robinson ... X seems to be in quantal-proposed
[11:43] <smb> Friday sounds like the perfect day for that.
[11:51] <dileks> as Linux v3.6-rc1 is released... <http://www.h-online.com/open/features/Kernel-Log-Development-of-Linux-3-6-under-way-1657742.html>
[11:51] <dileks> apw: you read that "secret announce" about unionmounts in vfs pile #1?
[11:52] <dileks> preliminary support*
[11:52] <dileks> I am surprised noone asked when that will be ready2use
[11:53] <dileks> https://lkml.org/lkml/2012/7/22/17
[11:53] <dileks> to quote: "* preparatory bits from unionmount series (from dhowells)."
[11:54] <apw> oh great more transisions in my future
[11:54] <dileks> apw: just as a note "VFS: Split inode_permission()" (commit by dhowells)
[11:55] <dileks> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=0bdaea9017b9d2b9996e153a71ee03555969b80e
[11:59] <dileks> remembering your work... an export is missing for "fs built as module"?
[11:59] <apw> yeah
=== yofel_ is now known as yofel
[13:12] <smb> apw (and maybe bryceh is interested): bug 1032622
[13:12] <ubot2> Launchpad bug 1032622 in xorg "ctrl+alt+l fail to start screenserver" [Undecided,New] https://launchpad.net/bugs/1032622
[13:12] <smb> (this seems to be related to pulling in the new X stack)
[13:13] <smb> or q-proposed in general
[13:13] <apw> yeah
[13:13] <apw> you should say that if you didn't
[13:13] <smb> I did
[13:13] <apw> great
=== mfisch` is now known as mfisch
=== mfisch is now known as Guest52926
[14:30] <arges> apw, hello. was it you or cking that was the resident acpi expert?
[14:30] <apw> arges, that'd be cking, but he is off for a bit, whats up
[14:30] <rtg> arges, cking, but he's out for 2 weeks
[14:31] <arges> rtg, apw : ah that's what i thought.   just looking at a report regarding apci,  pad.lv/1016617     looks like it works in centos but not in ubuntu. so was wondering if getting /proc/cmdline from the other distro would make sense to compare or if I need to look at something else
[14:32] <apw> bug #1016617
[14:32] <ubot2> Launchpad bug 1016617 in acpi "Dell c6220 Unable to Reboot" [Medium,Confirmed] https://launchpad.net/bugs/1016617
[14:33] <apw> I have found that by rebooting the server via the DRAC web interface will reboot the server correctly.
[14:33] <apw> arges, ^^ any idea what that even means ?
[14:34] <arges> apw, I'm guessing its the dell server management console, but i was going to verify
[14:34] <arges> Dell Remote Access Controller
[14:34] <arges> yes
[14:34] <apw> that may involve poweing the machine off then which we know also fixes the issue
[14:34] <apw> arges, the most likely difference between centos and us is kernel version
[14:34] <arges> apw, yea i'll get the kernel version and ask to try the similar ubuntu version
[14:35] <apw> as there is an indication that nolapic works for them you might look see if there is a quirk for htat, i suspect there is
[14:35] <arges> apw, well looks like it helps with the reboot part, but not the boot up part after software reboot
[14:37] <arges> apw, yea they got it to work using 2.6.18 ... so pretty ancient
[14:39]  * ogasawara back in 20
[14:39] <apw> yeah a million years old
[14:40] <arges> wow it was released march 2012
[14:42] <henrix> fwiw, they use "2.6.18", not 2.6.18 -- its a *really* heavily patched version.
[14:43] <arges> yup
[14:43] <henrix> i had to use centos 2 years ago, and their kernel is very different from the mainline version
[14:43] <mjg59> If it's the standard Dell BIOS issue it'll also go away if you disable x2apic support
[14:44] <apw> mjg59, as in nox2apic on the kernel command line ?
[14:44] <arges> mjg59, ah. is this done via the bios?
[14:45] <henrix> i guess he meant the kernel param nox2apic
[14:45] <henrix> oh, apw had already suggested that :)
[14:45] <ohsix> what's an irq injection attack
[14:46] <arges> henrix, well they tried nolacpi, but i'll suggest nox2apic
[14:46] <arges> mjg59, thanks
[14:48] <mjg59> If that works then it's a BIOS bug
[14:48] <mjg59> And it's not easy for Linux to work around it
=== Guest52926 is now known as mfisch
=== mfisch is now known as Guest6741
[15:44] <rtg> apw, ogasawara: pushed 3.6-rc1 for ubuntu-r. it builds for x86en. have not boot tested yet.
[15:44] <ogasawara> rtg: ack, thanks
[15:45] <rtg> back to firmware patches...
[15:46]  * apw was looking at what was in -rc1 it looks like a huge upheaval especially in VFS we should be wary about moving there as i suspect aufs and overlyafs are going to break hideously
[15:46] <rtg> apw, aufs, overlayfs, and raid4-5 are all disabled for now
[15:47] <apw> rtg, thought they might have to be, there is some union-mounts basis going in there which will collide hideously
[16:08] <apw> ogasawara, ok pushed -- pulled all the commits together so we can squish them next time round
[16:08] <ogasawara> apw: ack
[16:08] <rtg> apw, quantal ?
[16:14] <apw> rtg yep quantal, refreshed aufs and pulled the commits together so we can clean them up and drop them easy depending
[16:38] <jwi> jsalisbury: for bug 1028151, testing on 3.3 is a red herring - 3.3 doesn't have the relaxed dmi check that was cherry-picked to precise. so you're back to a situation where samsung_laptop.ko isn't loaded and can't cause havoc.
[16:38] <ubot2> Launchpad bug 1028151 in linux "Samsung Series 900 Laptop brightness control issue" [High,In progress] https://launchpad.net/bugs/1028151
[16:38] <jsalisbury> jwi, ahh right.  makes sense 
[16:38] <jwi> but f34cd9ca932087 upstream sounds like it could help
[16:40] <jsalisbury> jwi, cool, I'll take a look.  Thanks!
[16:44] <jwi> jsalisbury: and for bug 1021086, e19ebcab01cc130fa is trickling down through 3.5-stable
[16:44] <ubot2> Launchpad bug 1021086 in linux "Kernel Panic when re-enabling wifi via Fn+F2 on Dell XPS 15z" [High,In progress] https://launchpad.net/bugs/1021086
[16:44] <jsalisbury> jwi, great, thanks!
=== Guest6741 is now known as mfisch
[17:25]  * henrix -> EOD
[17:25] <herton> jjohansen, are you maintaining qrt? I just filled a bug for a minor issue I noticed here (bug 1032743)
[17:25] <ubot2> Launchpad bug 1032743 in qa-regression-testing "ptrace-restrictions.sh will fail if LC_MESSAGES or LC_ALL is set to something undesired (non english error messages)" [Undecided,New] https://launchpad.net/bugs/1032743
[17:25] <herton> jjohansen, by qrt, I mean the security tests on it
[17:26] <jjohansen> herton: okay I'll take a look
[17:26] <herton> jjohansen, thanks
[17:32]  * smb -> EOD
[17:42]  * rtg -> lunch
=== mfisch` is now known as mfisch
=== mfisch is now known as Guest80389
=== Guest80389 is now known as mfisch
[19:04]  * apw -> beer
[19:23]  * ogasawara lunch
[20:12] <rtg> ogasawara, we've accumulated quite a stack of patches in quantal master-next. are you thinking about uploading today ?
[20:23]  * rtg -> EOW
[20:23] <ogasawara> rtg: I wasn't planning one for today, but it should be trivial to do.  let me kick off some test builds and then I'll upload.
[20:24] <rtg> ogasawara, ack, I'll watch for build failures over the weekend.
=== kentb is now known as kentb-out