* (unknown),
From: ligiag @ 2012-12-29 6:50 UTC (permalink / raw)
Greetings,
My wife and I want to donate the sum of $500,000 to you. kindly get back
to us for more details.
^ permalink raw reply
* Re: [PATCH] mm: do not sleep in balance_pgdat if there's no i/o congestion
From: Hillf Danton @ 2012-12-29 7:25 UTC (permalink / raw)
To: Zlatko Calusic
Cc: Linus Torvalds, Andrew Morton, Mel Gorman, Hugh Dickins, linux-mm,
Linux Kernel Mailing List
In-Reply-To: <50DC6C6F.6050703@iskon.hr>
On Thu, Dec 27, 2012 at 11:42 PM, Zlatko Calusic
<zlatko.calusic@iskon.hr> wrote:
> On 21.12.2012 12:51, Hillf Danton wrote:
>>
>> On Thu, Dec 20, 2012 at 7:25 AM, Zlatko Calusic <zlatko.calusic@iskon.hr>
>> wrote:
>>>
>>> static unsigned long balance_pgdat(pg_data_t *pgdat, int order,
>>> int
>>> *classzone_idx)
>>> {
>>> - int all_zones_ok;
>>> + struct zone *unbalanced_zone;
>>
>>
>> nit: less hunks if not erase that mark
>>
>> Hillf
>
>
> This one left unanswered and forgotten because I didn't understand what you
> meant. Could you elaborate?
>
Sure, the patch looks simpler(and nicer) if we dont
erase all_zones_ok.
Hillf
^ permalink raw reply
* Re: [PATCH] mm: do not sleep in balance_pgdat if there's no i/o congestion
From: Hillf Danton @ 2012-12-29 7:25 UTC (permalink / raw)
To: Zlatko Calusic
Cc: Linus Torvalds, Andrew Morton, Mel Gorman, Hugh Dickins, linux-mm,
Linux Kernel Mailing List
In-Reply-To: <50DC6C6F.6050703@iskon.hr>
On Thu, Dec 27, 2012 at 11:42 PM, Zlatko Calusic
<zlatko.calusic@iskon.hr> wrote:
> On 21.12.2012 12:51, Hillf Danton wrote:
>>
>> On Thu, Dec 20, 2012 at 7:25 AM, Zlatko Calusic <zlatko.calusic@iskon.hr>
>> wrote:
>>>
>>> static unsigned long balance_pgdat(pg_data_t *pgdat, int order,
>>> int
>>> *classzone_idx)
>>> {
>>> - int all_zones_ok;
>>> + struct zone *unbalanced_zone;
>>
>>
>> nit: less hunks if not erase that mark
>>
>> Hillf
>
>
> This one left unanswered and forgotten because I didn't understand what you
> meant. Could you elaborate?
>
Sure, the patch looks simpler(and nicer) if we dont
erase all_zones_ok.
Hillf
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v2] wt-status: Show ignored files in untracked dirs
From: Jeff King @ 2012-12-29 7:22 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: Junio C Hamano, git
In-Reply-To: <CALWbr2yNR=K3MqBVe=sfSxPaJ+-A8utHBqoiHPHPLxr_9e9SVQ@mail.gmail.com>
On Fri, Dec 28, 2012 at 03:05:30PM +0100, Antoine Pelisse wrote:
> Using the example from Michael's mail, I end up having this:
> $ git status --porcelain --ignored
> ?? .gitignore
> ?? x
> ?? y/
> !! x.ignore-me
> !! y/
>
> y/ is referred as untracked, because it contains untracked files, and
> then as ignored because it
> contains ignored files.
>
> Showing it twice doesn't feel right though, so I guess we should only
> show "?? y/" with untracked=normal,
> and "!! y/foo.ignore-me" when using untracked=all
>
> What do you think ?
Good catch. I agree that showing just "?? y/" in the untracked=normal
case makes sense. It makes the definition of "!!" to mean "all untracked
files in this path are ignored". IOW, showing "??" means there are one
or more untracked, unignored files. There may _also_ be ignored files,
but we do not say (nor we even necessarily need to bother checking).
In retrospect, I think it might have made more sense to use the second
character of an untracked line to represent "ignored". That is, the
output:
?? .gitignore
?? x
?! y/
!! x.ignore-me
would make sense to me. But that would be a backwards-incompatible
change at this point, and I don't think it's worth it.
-Peff
^ permalink raw reply
* Re: kernel BUG at mm/huge_memory.c:1798!
From: Hillf Danton @ 2012-12-29 7:22 UTC (permalink / raw)
To: Alex Xu
Cc: Zhouping Liu, linux-mm, linux-kernel, Ingo Molnar,
Johannes Weiner, mgorman, hughd, Andrea Arcangeli
In-Reply-To: <50DC7287.1080302@yahoo.ca>
On Fri, Dec 28, 2012 at 12:08 AM, Alex Xu <alex_y_xu@yahoo.ca> wrote:
> On 25/12/12 07:05 AM, Hillf Danton wrote:
>> On Tue, Dec 25, 2012 at 12:38 PM, Zhouping Liu <zliu@redhat.com> wrote:
>>> Hello all,
>>>
>>> I found the below kernel bug using latest mainline(637704cbc95),
>>> my hardware has 2 numa nodes, and it's easy to reproduce the issue
>>> using LTP test case: "# ./mmap10 -a -s -c 200":
>>
>> Can you test with 5a505085f0 and 4fc3f1d66b1 reverted?
>>
>> Hillf
>>
>
> (for people from mailing lists, please cc me when replying)
>
> Same thing?
Yes and thank you very much for reporting it.
Hillf
>
> mapcount 0 page_mapcount 1
> ------------[ cut here ]------------
> kernel BUG at mm/huge_memory.c:1798!
^ permalink raw reply
* Re: kernel BUG at mm/huge_memory.c:1798!
From: Hillf Danton @ 2012-12-29 7:22 UTC (permalink / raw)
To: Alex Xu
Cc: Zhouping Liu, linux-mm, linux-kernel, Ingo Molnar,
Johannes Weiner, mgorman, hughd, Andrea Arcangeli
In-Reply-To: <50DC7287.1080302@yahoo.ca>
On Fri, Dec 28, 2012 at 12:08 AM, Alex Xu <alex_y_xu@yahoo.ca> wrote:
> On 25/12/12 07:05 AM, Hillf Danton wrote:
>> On Tue, Dec 25, 2012 at 12:38 PM, Zhouping Liu <zliu@redhat.com> wrote:
>>> Hello all,
>>>
>>> I found the below kernel bug using latest mainline(637704cbc95),
>>> my hardware has 2 numa nodes, and it's easy to reproduce the issue
>>> using LTP test case: "# ./mmap10 -a -s -c 200":
>>
>> Can you test with 5a505085f0 and 4fc3f1d66b1 reverted?
>>
>> Hillf
>>
>
> (for people from mailing lists, please cc me when replying)
>
> Same thing?
Yes and thank you very much for reporting it.
Hillf
>
> mapcount 0 page_mapcount 1
> ------------[ cut here ]------------
> kernel BUG at mm/huge_memory.c:1798!
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] refs: do not use cached refs in repack_without_ref
From: Jeff King @ 2012-12-29 7:16 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, Junio C Hamano
In-Reply-To: <50DAB447.8000101@alum.mit.edu>
On Wed, Dec 26, 2012 at 09:24:39AM +0100, Michael Haggerty wrote:
> I'm sorry to take so long to respond to this patch. Thank you for
> tracking down this bug and for your careful analysis.
>
> I think your patch is correct and should fix the first race condition
> that you described.
Thanks for checking it over. I almost cc'd you, as I know you have been
working on ref caching. But I think that the problem is much older, as
we always cached the packed-refs list in memory.
> But I think the continued existence of the other race conditions is an
> indication of a fundamental problem with the reference locking
> policy--independent of the in-RAM reference cache.
>
> The tacit assumption of the current locking policy is that changes to
> the packed-refs file are not critical for correctness, because loose
> references take precedence over it anyway. This is true for adding and
> modifying references. But it is not true for deleting references,
> because there is no way for a deletion to be represented as a loose
> reference in a way that takes precedence over the packed-refs file
> (i.e., there is no way for a loose reference to say "I am deleted,
> regardless of what packed-refs says"). Thus the race conditions for
> deleting references, whether via delete_ref() or via pack_refs() with
> --prune.
Yeah. It would be much nicer if we could just write the null sha1 or a
similar sentinel into the loose ref for "I am deleted". The problem
(besides backwards compatibility) is the usual D/F conflict. I cannot
delete "refs/heads/foo" and then create "refs/heads/foo/bar" if the old
ref file is in the way.
> There is a problem if two processes try to delete a reference at the
> same time, or if one process tries to delete a reference at the same
> time as another process is trying to pack the references. The reason is
> that there is no "transaction" that spans both the rewriting of the
> packed-refs file and also the deletion of the loose-ref files, and
> therefore it is possible for conflicting changes to be made in the two
> locations.
Just to be clear, are you talking about the races I wrote about in my
other email? Or are there other races? I didn't (and still don't) see
any actual on-disk data loss races. Just ones where a reader may get an
old, packed value (which is still bad, but is less bad than one where a
write is lost).
> I think that all of the problems would be fixed if a lock would be held
> on the packed-refs file during the whole process of deleting any
> reference; i.e., change the algorithms to:
Yeah, I looked at that, too. In fact, before I had correctly analyzed
the problem, I thought that doing so would solve the problem I was
seeing (which I noticed was wrong when it did not pass my tests :) ).
>From your description, I think you realize this, but I want to point out
for other readers: just updating the pack_refs side to call prune_refs
under the lock would create a deadlock with a simultaneous delete (which
takes the individual ref lock first, then the packed-refs lock). Of
course, I do not think git is capable of deadlock, as we typically just
die() instead of blocking on a lock. So maybe it does not matter so
much. :)
> * Delete reference foo:
>
> 1. Acquire the lock $GIT_DIR/packed-refs.lock (regardless of whether
> "foo" is a packed ref)
This suffers from the same problem I mentioned in my earlier email: we
create lock contention on packed-refs.lock when there are two
simultaneous deletes, even when the refs aren't packed. That might be an
acceptable tradeoff, though. It's only for deletion, not for update,
which is presumably rare. And it has to happen anyway when both refs are
packed.
> 2. Write to $GIT_DIR/packed-refs.new a version of the packed-refs
> file that omits "foo"
> [...]
All of the further steps make sense. By deleting from packed-refs first,
we eliminate the read race-condition I mentioned in my earlier email.
The only downside is the possible increased lock contention on
packed-refs.lock. I'm very tempted to go this route. It's better to be
correct and sometimes die on lock contention than to sometimes give the
wrong answer.
> I would appreciate a critique of my analysis. Even if you agree, I
> think it would be OK to apply Peff's patch to fix up the most pressing
> problem, then implement the more complete solution later.
I think your analysis is correct, modulo the issue I mentioned. And I
agree that my patch is a good interim, as it fixes the worst case
(losing writes).
-Peff
^ permalink raw reply
* Re: [dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data
From: Arno Wagner @ 2012-12-29 7:06 UTC (permalink / raw)
To: dm-crypt
In-Reply-To: <50DDF171.1080807@gmail.com>
On Fri, Dec 28, 2012 at 08:22:25PM +0100, Milan Broz wrote:
> On 12/28/2012 04:04 PM, Arno Wagner wrote:
> > I am thinking about a "basic LUKS setup" section for the FAQ
> > that is more in the nature of a mini-howto. Things like blanking
> > a previously used partition before a LUKS install seem to be
> > not obvious to many people. Step-by-step instructions may help.
>
> Wiping (whole) device (with some crypt random way) is still on TODO list.
You can just wipe with zeros on the mapped device. They will be
encrypted after all. That could leak a tiny bit of information
to an attacker that has access to the encrypted container
multiple times, but such an attacker can likely do far worse
things anyways. If that is a concern, just use a different
master key for the zero-wipe, e.g. a one-time key derived in the
same way as the LUKS master key.
> But I believe that common signatures are wiped during LUKS format already
> (we had several bugs related to this already) so it should never
> happen that device contains ext4/swap/whatever signature parallel with
> LUKS. (If so, please let me know, it is a bug.)
Ext2 superblock signatures are all not wiped. Test I ran:
-----
# head -c 100M /dev/zero > test
# losetup /dev/loop0 test
# mke2fs -q /dev/loop0
# hd /dev/loop0 | grep "53 ef"
00000430 8b 7d de 50 00 00 18 00 53 ef 01 00 01 00 00 00 |.}.P....S.......|
00800430 8b 7d de 50 00 00 18 00 53 ef 00 00 01 00 00 00 |.}.P....S.......|
01800430 8b 7d de 50 00 00 18 00 53 ef 00 00 01 00 00 00 |.}.P....S.......|
02800430 8b 7d de 50 00 00 18 00 53 ef 00 00 01 00 00 00 |.}.P....S.......|
03800430 8b 7d de 50 00 00 18 00 53 ef 00 00 01 00 00 00 |.}.P....S.......|
04800430 8b 7d de 50 00 00 18 00 53 ef 00 00 01 00 00 00 |.}.P....S.......|
# cryptsetup luksFormat /dev/loop0
[...]
# hd /dev/loop0 | grep "53 ef"
00009970 53 ef 3d 36 73 85 da 1e 20 cb bc 48 e9 e3 d9 b6 |S.=6s...
# ..H....|
00012c80 a2 f1 f6 53 ef b9 0c 30 75 60 6c c5 14 0b 6a 6b |...S...0u`l...jk|
00800430 bf 7d de 50 00 00 15 00 53 ef 00 00 01 00 00 00 |.}.P....S.......|
01800430 bf 7d de 50 00 00 15 00 53 ef 00 00 01 00 00 00 |.}.P....S.......|
02800430 bf 7d de 50 00 00 15 00 53 ef 00 00 01 00 00 00 |.}.P....S.......|
03800430 bf 7d de 50 00 00 15 00 53 ef 00 00 01 00 00 00 |.}.P....S.......|
04800430 bf 7d de 50 00 00 15 00 53 ef 00 00 01 00 00 00 |.}.P....S.......|
-----
The 5 superblock backups are still there. That should at least make
e2fsck require some kind of override option. However, the primary
superblock is just between the LUKS header and first keyslot. If I
remember correctly, older versions of cryptsetup did not wipe that
area (1.5.1 does). Maybe that is what happened here.
As for the superblock backups, I would say wiping them should be
part of a full device wipe to be done on a previosuly used partition.
I just added a "LUKS Container Setup mini-HOWTO" in the FAQ as item
2.1 that explains this. (That this is a TODO for cryptsetup also
noted.)
> fsck can possibly use blkid and warn user
> "Warning: device seems to contain xyz signature, do you really want...."
> but this is feature for fsck (util-linux), not for cryptsetup.
> (Anyway, I can ask util-linux maintainer later next year:)
That would be nice. Things are pretty safe right now, but
further improvement is always welcome.
Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
----
One of the painful things about our time is that those who feel certainty
are stupid, and those with any imagination and understanding are filled
with doubt and indecision. -- Bertrand Russell
^ permalink raw reply
* [PATCH] arm: dma mapping: export arm iommu functions
From: Olof Johansson @ 2012-12-29 6:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAH=HWYP5r18qjQSc_2121vikbTMpYv6DKOfW=hpOpGB7rUyNRA@mail.gmail.com>
On Fri, Dec 28, 2012 at 09:53:47AM +0530, Prathyush K wrote:
> On Thu, Dec 27, 2012 at 7:45 PM, Marek Szyprowski
> <m.szyprowski@samsung.com>wrote:
>
> > Hello,
> >
> >
> > On 12/27/2012 8:14 AM, Prathyush K wrote:
> >
> >> This patch adds EXPORT_SYMBOL calls to the three arm iommu
> >> functions - arm_iommu_create_mapping, arm_iommu_free_mapping
> >> and arm_iommu_attach_device. These functions can now be called
> >> from dynamic modules.
> >>
> >
> > Could You describe a bit more why those functions might be needed by
> > dynamic modules?
> >
> > Hi Marek,
>
> We are adding iommu support to exynos gsc and s5p-mfc.
> And these two drivers need to be built as modules to improve boot time.
>
> We're calling these three functions from inside these drivers:
> e.g.
> mapping = arm_iommu_create_mapping(&platform_bus_type, 0x20000000, SZ_256M,
> 4);
> arm_iommu_attach_device(mdev, mapping);
The driver shouldn't have to call these low-level functions directly,
something's wrong if you need that.
How is the DMA address management different here from other system/io mmus? is
that 256M window a hardware restriction?
-Olof
^ permalink raw reply
* Re: [PATCH] arm: dma mapping: export arm iommu functions
From: Olof Johansson @ 2012-12-29 6:53 UTC (permalink / raw)
To: Prathyush K
Cc: Marek Szyprowski, Prathyush K, linux-arm-kernel, linaro-mm-sig,
linux-mm
In-Reply-To: <CAH=HWYP5r18qjQSc_2121vikbTMpYv6DKOfW=hpOpGB7rUyNRA@mail.gmail.com>
On Fri, Dec 28, 2012 at 09:53:47AM +0530, Prathyush K wrote:
> On Thu, Dec 27, 2012 at 7:45 PM, Marek Szyprowski
> <m.szyprowski@samsung.com>wrote:
>
> > Hello,
> >
> >
> > On 12/27/2012 8:14 AM, Prathyush K wrote:
> >
> >> This patch adds EXPORT_SYMBOL calls to the three arm iommu
> >> functions - arm_iommu_create_mapping, arm_iommu_free_mapping
> >> and arm_iommu_attach_device. These functions can now be called
> >> from dynamic modules.
> >>
> >
> > Could You describe a bit more why those functions might be needed by
> > dynamic modules?
> >
> > Hi Marek,
>
> We are adding iommu support to exynos gsc and s5p-mfc.
> And these two drivers need to be built as modules to improve boot time.
>
> We're calling these three functions from inside these drivers:
> e.g.
> mapping = arm_iommu_create_mapping(&platform_bus_type, 0x20000000, SZ_256M,
> 4);
> arm_iommu_attach_device(mdev, mapping);
The driver shouldn't have to call these low-level functions directly,
something's wrong if you need that.
How is the DMA address management different here from other system/io mmus? is
that 256M window a hardware restriction?
-Olof
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [Bug 58735] GeForce 680, currently driver works on two, but not three monitors
From: bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ @ 2012-12-29 6:44 UTC (permalink / raw)
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <bug-58735-8800-V0hAGp6uBxMKqLRl/0Ahz6D7qz1kEfGD2LY78lusg7I@public.gmane.org/>
[-- Attachment #1.1: Type: text/plain, Size: 717 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=58735
--- Comment #5 from Aleksi Torhamo <alexerion-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> ---
I can confirm this. Tested with the latest nouveau kernel (commit
73e5cf2d9af6bb32b91f8a2f6d7c44c8e9b4e785) and a GeForce GTX 660 (nve6). All
three screens worked with nouveau on kernel 3.6.11, but on this one, one stays
blank.
If I disable one of the outputs that work by default, the one that didn't work
comes to life instead:
Section "Device"
...
Option "monitor-OUTPUT" "MonitorX"
EndSection
Section "Monitor"
Identifier "MonitorX"
Option "Ignore" "true"
EndSection
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 1566 bytes --]
[-- Attachment #2: Type: text/plain, Size: 181 bytes --]
_______________________________________________
Nouveau mailing list
Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
^ permalink raw reply
* [PATCH] sparc: Hook up finit_module syscall.
From: David Miller @ 2012-12-29 6:39 UTC (permalink / raw)
To: sparclinux
Signed-off-by: David S. Miller <davem@davemloft.net>
---
arch/sparc/include/uapi/asm/unistd.h | 3 ++-
arch/sparc/kernel/systbls_32.S | 2 +-
arch/sparc/kernel/systbls_64.S | 4 ++--
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/sparc/include/uapi/asm/unistd.h b/arch/sparc/include/uapi/asm/unistd.h
index cac719d..62ced58 100644
--- a/arch/sparc/include/uapi/asm/unistd.h
+++ b/arch/sparc/include/uapi/asm/unistd.h
@@ -407,8 +407,9 @@
#define __NR_process_vm_writev 339
#define __NR_kern_features 340
#define __NR_kcmp 341
+#define __NR_finit_module 342
-#define NR_syscalls 342
+#define NR_syscalls 343
/* Bitmask values returned from kern_features system call. */
#define KERN_FEATURE_MIXED_MODE_STACK 0x00000001
diff --git a/arch/sparc/kernel/systbls_32.S b/arch/sparc/kernel/systbls_32.S
index 5147f57..6ac43c3 100644
--- a/arch/sparc/kernel/systbls_32.S
+++ b/arch/sparc/kernel/systbls_32.S
@@ -85,4 +85,4 @@ sys_call_table:
/*325*/ .long sys_pwritev, sys_rt_tgsigqueueinfo, sys_perf_event_open, sys_recvmmsg, sys_fanotify_init
/*330*/ .long sys_fanotify_mark, sys_prlimit64, sys_name_to_handle_at, sys_open_by_handle_at, sys_clock_adjtime
/*335*/ .long sys_syncfs, sys_sendmmsg, sys_setns, sys_process_vm_readv, sys_process_vm_writev
-/*340*/ .long sys_ni_syscall, sys_kcmp
+/*340*/ .long sys_ni_syscall, sys_kcmp, sys_finit_module
diff --git a/arch/sparc/kernel/systbls_64.S b/arch/sparc/kernel/systbls_64.S
index cdbd9b8..1009ecb 100644
--- a/arch/sparc/kernel/systbls_64.S
+++ b/arch/sparc/kernel/systbls_64.S
@@ -86,7 +86,7 @@ sys_call_table32:
.word compat_sys_pwritev, compat_sys_rt_tgsigqueueinfo, sys_perf_event_open, compat_sys_recvmmsg, sys_fanotify_init
/*330*/ .word sys32_fanotify_mark, sys_prlimit64, sys_name_to_handle_at, compat_sys_open_by_handle_at, compat_sys_clock_adjtime
.word sys_syncfs, compat_sys_sendmmsg, sys_setns, compat_sys_process_vm_readv, compat_sys_process_vm_writev
-/*340*/ .word sys_kern_features, sys_kcmp
+/*340*/ .word sys_kern_features, sys_kcmp, sys_finit_module
#endif /* CONFIG_COMPAT */
@@ -164,4 +164,4 @@ sys_call_table:
.word sys_pwritev, sys_rt_tgsigqueueinfo, sys_perf_event_open, sys_recvmmsg, sys_fanotify_init
/*330*/ .word sys_fanotify_mark, sys_prlimit64, sys_name_to_handle_at, sys_open_by_handle_at, sys_clock_adjtime
.word sys_syncfs, sys_sendmmsg, sys_setns, sys_process_vm_readv, sys_process_vm_writev
-/*340*/ .word sys_kern_features, sys_kcmp
+/*340*/ .word sys_kern_features, sys_kcmp, sys_finit_module
--
1.7.10.4
^ permalink raw reply related
* [PATCH 6/9] ARM: dt: tegra114: Add new SoC base, Tegra 114 SoC
From: Olof Johansson @ 2012-12-29 6:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355996654-6579-7-git-send-email-hdoyu@nvidia.com>
On Thu, Dec 20, 2012 at 11:44:04AM +0200, Hiroshi Doyu wrote:
> Initial support for Tegra 114 SoC. This is expected to be included in
> the board DTS files, Tegra 114 SoC based evaluation board family.
>
> Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com>
Hi,
I think it could be a good idea to start documenting the cpu configuration in
the device tree on some of these larger platforms as well, i.e. include a cpus/
hierarchy. Would you mind adding those, please?
It would give you the flexibility of switching over to using device
tree to probe the number of cpus in case the platform grows yet another
way to figure out the number of cores in the future, without having to
update the device-trees at that time. :)
-Olof
^ permalink raw reply
* Re: [PATCH 6/9] ARM: dt: tegra114: Add new SoC base, Tegra 114 SoC
From: Olof Johansson @ 2012-12-29 6:39 UTC (permalink / raw)
To: Hiroshi Doyu
Cc: Andrew Lunn, Russell King, Jason Cooper, John Stultz,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, Thomas Gleixner,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1355996654-6579-7-git-send-email-hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On Thu, Dec 20, 2012 at 11:44:04AM +0200, Hiroshi Doyu wrote:
> Initial support for Tegra 114 SoC. This is expected to be included in
> the board DTS files, Tegra 114 SoC based evaluation board family.
>
> Signed-off-by: Hiroshi Doyu <hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Hi,
I think it could be a good idea to start documenting the cpu configuration in
the device tree on some of these larger platforms as well, i.e. include a cpus/
hierarchy. Would you mind adding those, please?
It would give you the flexibility of switching over to using device
tree to probe the number of cpus in case the platform grows yet another
way to figure out the number of cores in the future, without having to
update the device-trees at that time. :)
-Olof
^ permalink raw reply
* Re: [PATCH 6/9] ARM: dt: tegra114: Add new SoC base, Tegra 114 SoC
From: Olof Johansson @ 2012-12-29 6:39 UTC (permalink / raw)
To: Hiroshi Doyu
Cc: linux-tegra, Grant Likely, Rob Herring, Rob Landley, Russell King,
Stephen Warren, John Stultz, Thomas Gleixner, Jason Cooper,
Shawn Guo, Andrew Lunn, Jean-Christophe PLAGNIOL-VILLARD,
devicetree-discuss, linux-doc, linux-kernel, linux-arm-kernel
In-Reply-To: <1355996654-6579-7-git-send-email-hdoyu@nvidia.com>
On Thu, Dec 20, 2012 at 11:44:04AM +0200, Hiroshi Doyu wrote:
> Initial support for Tegra 114 SoC. This is expected to be included in
> the board DTS files, Tegra 114 SoC based evaluation board family.
>
> Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com>
Hi,
I think it could be a good idea to start documenting the cpu configuration in
the device tree on some of these larger platforms as well, i.e. include a cpus/
hierarchy. Would you mind adding those, please?
It would give you the flexibility of switching over to using device
tree to probe the number of cpus in case the platform grows yet another
way to figure out the number of cores in the future, without having to
update the device-trees at that time. :)
-Olof
^ permalink raw reply
* [Bug 50091] [BISECTED]GeForce 6150SE: system hangs on X-server start with garbled screen
From: bugzilla-daemon @ 2012-12-29 6:33 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-50091-2300@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=50091
Suloev Dmitry <suloevdmitry@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |suloevdmitry@gmail.com
--- Comment #24 from Suloev Dmitry <suloevdmitry@gmail.com> 2012-12-29 06:33:44 ---
You use kexec for reboot or this happen on cold boot?
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 51581] xorg not start after kexec when use nouveau
From: bugzilla-daemon @ 2012-12-29 6:30 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-51581-2300@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=51581
--- Comment #1 from Suloev Dmitry <suloevdmitry@gmail.com> 2012-12-29 06:30:53 ---
Any news?
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled
From: Matthew Garrett @ 2012-12-29 6:17 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Lee, Chun-Yi, matt.fleming@intel.com,
linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org,
Lee, Chun-Yi, Thomas Gleixner, Ingo Molnar, Jan Beulich,
Len Brown, Arjan van de Ven
In-Reply-To: <ed3971f1-8464-4406-bae2-eff914c9c2fc@email.android.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 318 bytes --]
On Fri, 2012-12-28 at 21:19 -0800, H. Peter Anvin wrote:
> Again, we could hack a simulator and try it.
Yeah, shouldn't be too hard to wedge into qemu/ovmf.
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥
^ permalink raw reply
* Re: [PATCH 1/3] rtc-efi: register rtc-efi device when EFI enabled
From: Matthew Garrett @ 2012-12-29 6:17 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Lee, Chun-Yi,
matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Lee, Chun-Yi,
Thomas Gleixner, Ingo Molnar, Jan Beulich, Len Brown,
Arjan van de Ven
In-Reply-To: <ed3971f1-8464-4406-bae2-eff914c9c2fc-2ueSQiBKiTY7tOexoI0I+QC/G2K4zDHf@public.gmane.org>
On Fri, 2012-12-28 at 21:19 -0800, H. Peter Anvin wrote:
> Again, we could hack a simulator and try it.
Yeah, shouldn't be too hard to wedge into qemu/ovmf.
^ permalink raw reply
* [PATCH 4/6] chkconfig: obey sysconfdir, base_libdir
From: Christopher Larson @ 2012-12-29 5:19 UTC (permalink / raw)
To: openembedded-core; +Cc: Christopher Larson
In-Reply-To: <cover.1356758000.git.chris_larson@mentor.com>
From: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
---
meta/recipes-extended/chkconfig/chkconfig_1.3.58.bb | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-extended/chkconfig/chkconfig_1.3.58.bb b/meta/recipes-extended/chkconfig/chkconfig_1.3.58.bb
index 7915594..df9b193 100644
--- a/meta/recipes-extended/chkconfig/chkconfig_1.3.58.bb
+++ b/meta/recipes-extended/chkconfig/chkconfig_1.3.58.bb
@@ -12,7 +12,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=5574c6965ae5f583e55880e397fbb018"
DEPENDS = "libnewt popt"
-PR = "r5"
+PR = "r6"
SRC_URI = "http://fedorahosted.org/releases/c/h/chkconfig/${BPN}-${PV}.tar.bz2"
@@ -31,6 +31,12 @@ EXTRA_OEMAKE = "\
'MANDIR=${mandir}' \
"
+do_unpack[postfuncs] += "obey_variables"
+do_unpack[vardeps] += "obey_variables"
+obey_variables () {
+ sed -i -e 's,/etc,${sysconfdir},; s,/lib/systemd,${base_libdir}/systemd,' leveldb.h
+}
+
do_install() {
oe_runmake 'DESTDIR=${D}' 'INSTALLNLSDIR=${D}${datadir}/locale' install
mkdir -p ${D}${sysconfdir}/chkconfig.d
--
1.8.0
^ permalink raw reply related
* [PATCH 6/6] chkconfig-alternatives-native-1.3.59: add recipe
From: Christopher Larson @ 2012-12-29 5:19 UTC (permalink / raw)
To: openembedded-core; +Cc: Christopher Larson
In-Reply-To: <cover.1356758000.git.chris_larson@mentor.com>
From: Christopher Larson <chris_larson@mentor.com>
This only builds alternatives, so avoids the libnewt and libpopt dependencies.
This uses 1.3.59 sources from git, with a couple commits of mine to add
--sysroot (and OPKG_OFFLINE_ROOT) support.
LIC_FILES_CHKSUM changed from 1.3.58 to 1.3.59, but only due to minor
formatting differences, not content/terms.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
---
.../chkconfig-alternatives-native_1.3.59.bb | 43 ++++++++++++++++++++++
1 file changed, 43 insertions(+)
create mode 100644 meta/recipes-extended/chkconfig/chkconfig-alternatives-native_1.3.59.bb
diff --git a/meta/recipes-extended/chkconfig/chkconfig-alternatives-native_1.3.59.bb b/meta/recipes-extended/chkconfig/chkconfig-alternatives-native_1.3.59.bb
new file mode 100644
index 0000000..4c72410
--- /dev/null
+++ b/meta/recipes-extended/chkconfig/chkconfig-alternatives-native_1.3.59.bb
@@ -0,0 +1,43 @@
+require recipes-extended/chkconfig/chkconfig_1.3.58.bb
+
+SUMMARY = "${SUMMARY_chkconfig-alternatives}"
+DESCRIPTION = "${DESCRIPTION_chkconfig-alternatives}"
+DEPENDS = ""
+PROVIDES = "${PN} virtual/update-alternatives-native"
+LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
+
+# The sysroot branch is 1.3.59 + some git commits from master + --sysroot
+# support for alternatives.
+SRC_URI = "git://github.com/kergoth/chkconfig;branch=sysroot"
+S = "${WORKDIR}/git"
+
+SRCREV = "cd437ecbd8986c894442f8fce1e0061e20f04dee"
+PV = "1.3.59+${SRCPV}"
+
+inherit native
+
+# We want our native recipes to build using the target paths rather than paths
+# into the sysroot, as we may use them to construct the rootfs. As such, we
+# only adjust the paths to match the metadata for the target, not native.
+obey_variables () {
+ sed -i 's,ALTERNATIVES_ROOT,OPKG_OFFLINE_ROOT,' alternatives.c
+}
+
+do_compile () {
+ oe_runmake alternatives
+}
+
+do_install () {
+ install -d ${D}${sysconfdir}/alternatives \
+ ${D}${localstatedir}/lib/alternatives
+
+ install -D -m 0755 alternatives ${D}${bindir}/alternatives
+ install -D -m 0644 alternatives.8 ${D}${mandir}/man8/alternatives.8
+
+ ln -s alternatives ${D}${bindir}/update-alternatives
+ ln -s alternatives.8 ${D}${mandir}/man8/update-alternatives.8
+}
+
+do_install_append_linuxstdbase() {
+ rm -rf ${D}${libdir}/lsb
+}
--
1.8.0
^ permalink raw reply related
* [PATCH 5/6] chkconfig: package the update-alternatives implementation
From: Christopher Larson @ 2012-12-29 5:19 UTC (permalink / raw)
To: openembedded-core; +Cc: Christopher Larson
In-Reply-To: <cover.1356758000.git.chris_larson@mentor.com>
From: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
---
.../recipes-extended/chkconfig/chkconfig_1.3.58.bb | 26 ++++++++++++++++++----
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-extended/chkconfig/chkconfig_1.3.58.bb b/meta/recipes-extended/chkconfig/chkconfig_1.3.58.bb
index df9b193..4c6985f 100644
--- a/meta/recipes-extended/chkconfig/chkconfig_1.3.58.bb
+++ b/meta/recipes-extended/chkconfig/chkconfig_1.3.58.bb
@@ -1,5 +1,4 @@
SUMMARY = "A system tool for maintaining the /etc/rc*.d hierarchy"
-
DESCRIPTION = "Chkconfig is a basic system utility. It updates and queries runlevel \
information for system services. Chkconfig manipulates the numerous \
symbolic links in /etc/rc.d, to relieve system administrators of some \
@@ -11,8 +10,9 @@ LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=5574c6965ae5f583e55880e397fbb018"
DEPENDS = "libnewt popt"
+PROVIDES += "virtual/update-alternatives"
-PR = "r6"
+PR = "r7"
SRC_URI = "http://fedorahosted.org/releases/c/h/chkconfig/${BPN}-${PV}.tar.bz2"
@@ -29,18 +29,22 @@ EXTRA_OEMAKE = "\
'BINDIR=${base_sbindir}' \
'SBINDIR=${sbindir}' \
'MANDIR=${mandir}' \
+ 'ALTDIR=${localstatedir}/lib/alternatives' \
+ 'ALTDATADIR=${sysconfdir}/alternatives' \
"
do_unpack[postfuncs] += "obey_variables"
do_unpack[vardeps] += "obey_variables"
obey_variables () {
sed -i -e 's,/etc,${sysconfdir},; s,/lib/systemd,${base_libdir}/systemd,' leveldb.h
+ sed -i -e 's,/etc/alternatives,${sysconfdir}/alternatives,' \
+ -e 's,/var/lib/alternatives,${localstatedir}/lib/alternatives,' \
+ -e 's,/usr/share/locale,${datadir}/locale,' alternatives.c
}
do_install() {
oe_runmake 'DESTDIR=${D}' 'INSTALLNLSDIR=${D}${datadir}/locale' install
- mkdir -p ${D}${sysconfdir}/chkconfig.d
- rm -f ${D}${sbindir}/update-alternatives
+ install -d ${D}${sysconfdir}/chkconfig.d
}
do_install_append_linuxstdbase() {
@@ -49,4 +53,18 @@ do_install_append_linuxstdbase() {
ln -sf ${base_sbindir}/chkconfig ${D}/${libdir}/lsb/remove_initd
}
+PACKAGES =+ "${PN}-alternatives ${PN}-alternatives-doc"
+SUMMARY_${PN}-alternatives = "Maintain symbolic links determining default commands"
+DESCRIPTION_${PN}-alternatives = "alternatives creates, removes, maintains and displays \
+information about the symbolic links comprising the alternatives system."
+SUMMARY_${PN}-alternatives-doc = "${SUMMARY_${PN}-alternatives} - Documentation files"
+DESCRIPTION_${PN}-alternatives-doc = "${DESCRIPTION_${PN}-alternatives} \
+This package contains documentation."
+RPROVIDES_${PN}-alternatives += "update-alternatives"
+RCONFLICTS_${PN}-alternatives = "update-alternatives-cworth update-alternatives-dpkg"
+FILES_${PN}-alternatives = "${sbindir}/alternatives ${sbindir}/update-alternatives \
+ ${sysconfdir}/alternatives ${localstatedir}/lib/alternatives"
+FILES_${PN}-alternatives-doc = "${mandir}/man8/alternatives.8 \
+ ${mandir}/man8/update-alternatives.8"
+
FILES_${PN}_append_linuxstdbase += "${libdir}/lsb"
--
1.8.0
^ permalink raw reply related
* [PATCH 3/6] chkconfig: don't inherit autotools
From: Christopher Larson @ 2012-12-29 5:19 UTC (permalink / raw)
To: openembedded-core; +Cc: Christopher Larson
In-Reply-To: <cover.1356758000.git.chris_larson@mentor.com>
From: Christopher Larson <chris_larson@mentor.com>
This buildsystem is not autoconf/automake, but make.
While we're at it, also make the install not hardcode the path to
/usr/share/locale.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
---
.../recipes-extended/chkconfig/chkconfig_1.3.58.bb | 24 ++++++++++++++--------
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/meta/recipes-extended/chkconfig/chkconfig_1.3.58.bb b/meta/recipes-extended/chkconfig/chkconfig_1.3.58.bb
index fd7bd1a..7915594 100644
--- a/meta/recipes-extended/chkconfig/chkconfig_1.3.58.bb
+++ b/meta/recipes-extended/chkconfig/chkconfig_1.3.58.bb
@@ -12,23 +12,29 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=5574c6965ae5f583e55880e397fbb018"
DEPENDS = "libnewt popt"
-PR = "r4"
+PR = "r5"
SRC_URI = "http://fedorahosted.org/releases/c/h/chkconfig/${BPN}-${PV}.tar.bz2"
SRC_URI[md5sum] = "c2039ca67f2749fe0c06ef7c6f8ee246"
SRC_URI[sha256sum] = "18b497d25b2cada955c72810e45fcad8280d105f17cf45e2970f18271211de68"
-inherit autotools gettext
+inherit gettext
-# Makefile uses RPM_OPT_fLAGS to construct CFLAGS
+# Makefile uses RPM_OPT_FLAGS to construct CFLAGS
#
-EXTRA_OEMAKE += 'RPM_OPT_FLAGS="${CFLAGS}" MANDIR="${mandir}" \
- BINDIR="${base_sbindir}" SBINDIR="${sbindir}"'
-
-do_install_append() {
- mkdir -p ${D}${sysconfdir}/chkconfig.d
- rm -f ${D}${sbindir}/update-alternatives
+EXTRA_OEMAKE = "\
+ 'RPM_OPT_FLAGS=${CFLAGS}' \
+ 'LDFLAGS=${LDFLAGS}' \
+ 'BINDIR=${base_sbindir}' \
+ 'SBINDIR=${sbindir}' \
+ 'MANDIR=${mandir}' \
+"
+
+do_install() {
+ oe_runmake 'DESTDIR=${D}' 'INSTALLNLSDIR=${D}${datadir}/locale' install
+ mkdir -p ${D}${sysconfdir}/chkconfig.d
+ rm -f ${D}${sbindir}/update-alternatives
}
do_install_append_linuxstdbase() {
--
1.8.0
^ permalink raw reply related
* [PATCH 2/6] opkg-native: obey virtual/update-alternatives-native
From: Christopher Larson @ 2012-12-29 5:19 UTC (permalink / raw)
To: openembedded-core; +Cc: Christopher Larson
In-Reply-To: <cover.1356758000.git.chris_larson@mentor.com>
From: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
---
meta/recipes-devtools/opkg/opkg.inc | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/opkg/opkg.inc b/meta/recipes-devtools/opkg/opkg.inc
index f157188..47458ff 100644
--- a/meta/recipes-devtools/opkg/opkg.inc
+++ b/meta/recipes-devtools/opkg/opkg.inc
@@ -9,7 +9,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
file://src/opkg-cl.c;beginline=1;endline=20;md5=321f658c3f6b6c832e25c8850b5dffba"
PE = "1"
-INC_PR = "r11"
+INC_PR = "r12"
# Werror gives all kinds bounds issuses with gcc 4.3.3
do_configure_prepend() {
@@ -43,11 +43,17 @@ FILES_libopkg-dev = "${libdir}/*.la ${libdir}/*.so"
FILES_libopkg-staticdev = "${libdir}/*.a"
FILES_libopkg = "${libdir}/*.so.* ${localstatedir}/lib/opkg/"
-# We need to create the lock directory
do_install_append() {
+ # We need to create the lock directory
install -d ${D}${localstatedir}/lib/opkg
}
+do_install_append_class-native() {
+ if [ "${PREFERRED_PROVIDER_virtual/update-alternatives-native}" != "${PN}" ]; then
+ rm ${D}${bindir}/update-alternatives
+ fi
+}
+
pkg_postinst_${PN} () {
#!/bin/sh
if [ "x$D" != "x" ]; then
--
1.8.0
^ permalink raw reply related
* [PATCH 1/6] update-alternatives.bbclass: use absolute paths for link targets
From: Christopher Larson @ 2012-12-29 5:19 UTC (permalink / raw)
To: openembedded-core; +Cc: Christopher Larson
In-Reply-To: <cover.1356758000.git.chris_larson@mentor.com>
From: Christopher Larson <chris_larson@mentor.com>
This improves compatibility, as both the debian update-alternatives and the
chkconfig alternatives require absolute paths.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
---
meta/classes/update-alternatives.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/update-alternatives.bbclass b/meta/classes/update-alternatives.bbclass
index a3631ec..556ee7c 100644
--- a/meta/classes/update-alternatives.bbclass
+++ b/meta/classes/update-alternatives.bbclass
@@ -298,7 +298,7 @@ python populate_packages_prepend () {
continue
# Default to generate shell script.. eventually we may want to change this...
- alt_target = os.path.relpath(alt_target, os.path.dirname(alt_link))
+ alt_target = os.path.normpath(alt_target)
alt_setup_links += '\tupdate-alternatives --install %s %s %s %s\n' % (alt_link, alt_name, alt_target, alt_priority)
alt_remove_links += '\tupdate-alternatives --remove %s %s\n' % (alt_name, alt_target)
--
1.8.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.