* Re: [PATCH v2 1/7] clk: Add a generic clock infrastructure
From: Turquette, Mike @ 2011-10-23 16:49 UTC (permalink / raw)
To: Shawn Guo
Cc: linux-kernel, linux-arm-kernel, jeremy.kerr, broonie, tglx,
linus.walleij, amit.kucheria, dsaxena, patches, linaro-dev, paul,
grant.likely, sboyd, skannan, magnus.damm, arnd.bergmann, linux,
eric.miao, richard.zhao
In-Reply-To: <20111023125555.GD1401@S2100-06.ap.freescale.net>
On Sun, Oct 23, 2011 at 5:55 AM, Shawn Guo <shawn.guo@freescale.com> wrote:
> Hi Mike,
>
> Some random comments/nits ...
Thanks for reviewing Shawn. Will roll changes into V3.
Regards,
Mike
^ permalink raw reply
* [PATCH v2 1/7] clk: Add a generic clock infrastructure
From: Turquette, Mike @ 2011-10-23 16:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111023125555.GD1401@S2100-06.ap.freescale.net>
On Sun, Oct 23, 2011 at 5:55 AM, Shawn Guo <shawn.guo@freescale.com> wrote:
> Hi Mike,
>
> Some random comments/nits ...
Thanks for reviewing Shawn. Will roll changes into V3.
Regards,
Mike
^ permalink raw reply
* Re: [Qemu-devel] [Spice-devel] Possible SPICE/QEMU deadlock on fast client reconnect
From: Alon Levy @ 2011-10-23 16:42 UTC (permalink / raw)
To: Yonit Halperin; +Cc: spice-devel, qemu-devel
In-Reply-To: <4EA3C457.2060500@redhat.com>
On Sun, Oct 23, 2011 at 09:37:59AM +0200, Yonit Halperin wrote:
> Hi,
>
> Sounds like https://bugzilla.redhat.com/show_bug.cgi?id=746950 and
> https://bugs.freedesktop.org/show_bug.cgi?id=41858
> Alon's patch:
> http://lists.freedesktop.org/archives/spice-devel/2011-September
> /005369.html
> Should solve it.
>
Could you add comments about reproducing to the RH bug? the QE wants to
know if it is user triggerable. Thanks.
> Cheers,
> Yonit.
> On 10/21/2011 05:26 PM, Daniel P. Berrange wrote:
> >In testing my patches for 'add_client' support with SPICE, I noticed
> >deadlock in the QEMU/SPICE code. It only happens if I close a SPICE
> >client and then immediately reconnect within about 1 second. If I
> >wait a couple of seconds before reconnecting the SPICE client I don't
> >see the deadlock.
> >
> >I'm using QEMU& SPICE git master, and GDB has this to say
> >
> >(gdb) thread apply all bt
> >
> >Thread 3 (Thread 0x7f269e142700 (LWP 17233)):
> >#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:165
> >#1 0x00000000004e80e9 in qemu_cond_wait (cond=<optimized out>, mutex=<optimized out>)
> > at qemu-thread-posix.c:113
> >#2 0x0000000000556469 in qemu_kvm_wait_io_event (env=<optimized out>)
> > at /home/berrange/src/virt/qemu/cpus.c:626
> >#3 qemu_kvm_cpu_thread_fn (arg=0x29217a0) at /home/berrange/src/virt/qemu/cpus.c:661
> >#4 0x0000003a83207b31 in start_thread (arg=0x7f269e142700) at pthread_create.c:305
> >#5 0x0000003a82edfd2d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> >
> >Thread 2 (Thread 0x7f26822fc700 (LWP 17234)):
> >#0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:140
> >#1 0x0000003a83209ad6 in _L_lock_752 () from /lib64/libpthread.so.0
> >#2 0x0000003a832099d7 in __pthread_mutex_lock (mutex=0x1182f60) at pthread_mutex_lock.c:65
> >#3 0x00000000004e7ec9 in qemu_mutex_lock (mutex=<optimized out>) at qemu-thread-posix.c:54
> >#4 0x0000000000507df5 in channel_event (event=3, info=0x2a3c610) at ui/spice-core.c:234
> >#5 0x00007f269f77be87 in reds_stream_free (s=0x2a3c590) at reds.c:4073
> >#6 0x00007f269f75b64f in red_channel_client_disconnect (rcc=0x7f267c069ec0) at red_channel.c:961
> >#7 0x00007f269f75a131 in red_peer_handle_incoming (handler=0x7f267c06a5a0, stream=0x2a3c590)
> > at red_channel.c:150
> >#8 red_channel_client_receive (rcc=0x7f267c069ec0) at red_channel.c:158
> >#9 0x00007f269f761fbc in handle_channel_events (in_listener=0x7f267c06a5f8, events=<optimized out>)
> > at red_worker.c:9566
> >#10 0x00007f269f776672 in red_worker_main (arg=<optimized out>) at red_worker.c:10813
> >#11 0x0000003a83207b31 in start_thread (arg=0x7f26822fc700) at pthread_create.c:305
> >#12 0x0000003a82edfd2d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> >
> >Thread 1 (Thread 0x7f269f72e9c0 (LWP 17232)):
> >#0 0x0000003a8320e01d in read () at ../sysdeps/unix/syscall-template.S:82
> >#1 0x00007f269f75daaa in receive_data (n=4, in_buf=0x7fffe7a5a02c, fd=18) at red_worker.h:150
> >#2 read_message (message=0x7fffe7a5a02c, fd=18) at red_worker.h:163
> >#3 red_dispatcher_disconnect_cursor_peer (rcc=0x7f267c0c0f60) at red_dispatcher.c:157
> >#4 0x00007f269f75c20d in red_client_destroy (client=0x2a35400) at red_channel.c:1189
> >#5 0x00007f269f778335 in reds_client_disconnect (client=0x2a35400) at reds.c:624
> >---Type<return> to continue, or q<return> to quit---
> >#6 0x00007f269f75a131 in red_peer_handle_incoming (handler=0x2a35b50, stream=0x2b037d0) at red_channel.c:150
> >#7 red_channel_client_receive (rcc=0x2a35470) at red_channel.c:158
> >#8 0x00007f269f75b1e8 in red_channel_client_event (fd=<optimized out>, event=<optimized out>,
> > data=<optimized out>) at red_channel.c:774
> >#9 0x000000000045e561 in fd_trampoline (chan=<optimized out>, cond=<optimized out>, opaque=<optimized out>)
> > at iohandler.c:97
> >#10 0x0000003a84e427ed in g_main_dispatch (context=0x27fc510) at gmain.c:2441
> >#11 g_main_context_dispatch (context=0x27fc510) at gmain.c:3014
> >#12 0x00000000004c3da3 in glib_select_poll (err=false, xfds=0x7fffe7a5a2e0, wfds=0x7fffe7a5a260, rfds=
> > 0x7fffe7a5a1e0) at /home/berrange/src/virt/qemu/vl.c:1495
> >#13 main_loop_wait (nonblocking=<optimized out>) at /home/berrange/src/virt/qemu/vl.c:1541
> >#14 0x000000000040fdd1 in main_loop () at /home/berrange/src/virt/qemu/vl.c:1570
> >#15 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>)
> > at /home/berrange/src/virt/qemu/vl.c:3563
> >(gdb)
> >
> >
>
> _______________________________________________
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
^ permalink raw reply
* Re: [PATCH 06/14] ARM : SAMSUNG : S3C2416 Added io mapping for Static memory controller.
From: Paul Schilling @ 2011-10-23 16:44 UTC (permalink / raw)
To: Heiko Stübner
Cc: Kukjin Kim, Russell King, Yauhen Kharuzhy, Rafael J. Wysocki,
Greg Kroah-Hartman, linux-arm-kernel, linux-kernel
In-Reply-To: <201110222343.24141.heiko@sntech.de>
Why did I add disabled code. I didn't want to enable it if no one is
using it at the moment.
But, I took me long enough to figure out how to enable the Static
memory Controller in the
MMU with out any hints to begin with.
Also the EBI portion is present in a vendor kernel version 2.6.21.
The Static Memory Controller peripheral needs to be set when ethernet
chips like the dm9000 is attached to the
samsung ARM S3C2416. The Boardcon board is a good example.
On Sat, Oct 22, 2011 at 4:43 PM, Heiko Stübner <heiko@sntech.de> wrote:
> Am Samstag 22 Oktober 2011, 06:21:41 schrieb Paul Schilling:
>> Added MMU access to the Static Memory Controller.
>>
>> Signed-off-by: Paul Schilling <paul.s.schilling@gmail.com>
>> ---
>> arch/arm/mach-s3c2416/s3c2416.c | 12 ++++++++++++
>> 1 files changed, 12 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-s3c2416/s3c2416.c
>> b/arch/arm/mach-s3c2416/s3c2416.c index 494ce91..823a034 100644
>> --- a/arch/arm/mach-s3c2416/s3c2416.c
>> +++ b/arch/arm/mach-s3c2416/s3c2416.c
>> @@ -65,6 +65,18 @@ static struct map_desc s3c2416_iodesc[] __initdata = {
>> IODESC_ENT(WATCHDOG),
>> IODESC_ENT(CLKPWR),
>> IODESC_ENT(TIMER),
>> + {
>> + .virtual = (u32)S3C2412_VA_SSMC,
>> + .pfn = __phys_to_pfn(S3C2412_PA_SSMC),
>> + .length = SZ_1M,
>> + .type = MT_DEVICE,
>> + },
>> + /*{
>> + .virtual = (u32)S3C2412_VA_EBI,
>> + .pfn = __phys_to_pfn(S3C2412_PA_EBI),
>> + .length = SZ_1M,
>> + .type = MT_DEVICE,
>> + },*/
>> };
> why are you adding disabled code?
>
> Btw. it seems your posts got mangled somehow... only your patches 2,5 and 6 of
> 14 made it to linux-kernel and linux-arm-kernel.
>
> Heiko
>
^ permalink raw reply
* [PATCH 06/14] ARM : SAMSUNG : S3C2416 Added io mapping for Static memory controller.
From: Paul Schilling @ 2011-10-23 16:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201110222343.24141.heiko@sntech.de>
Why did I add disabled code. I didn't want to enable it if no one is
using it at the moment.
But, I took me long enough to figure out how to enable the Static
memory Controller in the
MMU with out any hints to begin with.
Also the EBI portion is present in a vendor kernel version 2.6.21.
The Static Memory Controller peripheral needs to be set when ethernet
chips like the dm9000 is attached to the
samsung ARM S3C2416. The Boardcon board is a good example.
On Sat, Oct 22, 2011 at 4:43 PM, Heiko St?bner <heiko@sntech.de> wrote:
> Am Samstag 22 Oktober 2011, 06:21:41 schrieb Paul Schilling:
>> Added MMU access to the Static Memory Controller.
>>
>> Signed-off-by: Paul Schilling <paul.s.schilling@gmail.com>
>> ---
>> ?arch/arm/mach-s3c2416/s3c2416.c | ? 12 ++++++++++++
>> ?1 files changed, 12 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-s3c2416/s3c2416.c
>> b/arch/arm/mach-s3c2416/s3c2416.c index 494ce91..823a034 100644
>> --- a/arch/arm/mach-s3c2416/s3c2416.c
>> +++ b/arch/arm/mach-s3c2416/s3c2416.c
>> @@ -65,6 +65,18 @@ static struct map_desc s3c2416_iodesc[] __initdata = {
>> ? ? ? IODESC_ENT(WATCHDOG),
>> ? ? ? IODESC_ENT(CLKPWR),
>> ? ? ? IODESC_ENT(TIMER),
>> + ? ? {
>> + ? ? ? ? ? ? .virtual ? ? ? ?= (u32)S3C2412_VA_SSMC,
>> + ? ? ? ? ? ? .pfn ? ? ? ? ? ?= __phys_to_pfn(S3C2412_PA_SSMC),
>> + ? ? ? ? ? ? .length ? ? ? ? = SZ_1M,
>> + ? ? ? ? ? ? .type ? ? ? ? ? = MT_DEVICE,
>> + ? ? },
>> + ? ? /*{
>> + ? ? ? ? ? ? .virtual ? ? ? ?= (u32)S3C2412_VA_EBI,
>> + ? ? ? ? ? ? .pfn ? ? ? ? ? ?= __phys_to_pfn(S3C2412_PA_EBI),
>> + ? ? ? ? ? ? .length ? ? ? ? = SZ_1M,
>> + ? ? ? ? ? ? .type ? ? ? ? ? = MT_DEVICE,
>> + ? ? },*/
>> ?};
> why are you adding disabled code?
>
> Btw. it seems your posts got mangled somehow... only your patches 2,5 and 6 of
> 14 made it to linux-kernel and linux-arm-kernel.
>
> Heiko
>
^ permalink raw reply
* Re: how stable are snapshots at the block level?
From: Mathijs Kwik @ 2011-10-23 16:41 UTC (permalink / raw)
To: Chris Mason, Mathijs Kwik, linux-btrfs
In-Reply-To: <20111023160535.GA11547@shiny.Mikenopa.local>
On Sun, Oct 23, 2011 at 6:05 PM, Chris Mason <chris.mason@oracle.com> w=
rote:
> On Sun, Oct 23, 2011 at 09:45:10AM +0200, Mathijs Kwik wrote:
>> Hi all,
>>
>> I'm currently doing backups by doing a btrfs snapshot, then rsync th=
e
>> snapshot to my backup location.
>> As I have a lot of small files and quite some changes between
>> snapshots, this process is taking more and more time.
>> I looked at "btrfs find-new", which is promissing, but I need
>> something to track deletes and modifications too.
>> Also, while this will help the initial comparison phase, most time i=
s
>> still spent on the syncing itself, as a lot of overhead is caused by
>> the tiny files.
>>
>> After finding some discussion about it here:
>> http://www.backupcentral.com/phpBB2/two-way-mirrors-of-external-mail=
ing-lists-3/backuppc-21/using-rsync-for-blockdevice-level-synchronisati=
on-of-backupp-100438
>>
>> I found that the official rsync-patches tarball includes the patch
>> that allows syncing full block devices.
>> After the initial backup, I found that this indeed speeds up my back=
ups a lot.
>> Ofcourse this is meant for syncing unmounted filesystems (or other
>> things that are "stable" at the block level, like LVM snapshot
>> volumes).
>>
>> I tested backing up a live btrfs filesystem by making a btrfs
>> snapshot, and this (very simple, non-thorough) turned out to work ok=
=2E
>> My root subvolume contains the "current" subvolume (which I mount) a=
nd
>> several backup subvolumes.
>> Ofcourse I understand that the "current" subvolume on the backup
>> destination is broken/inconsistent, as I change it during the rsync
>> run. But when I mounted the backup disk and compared the subvolumes
>> using normal file-by-file rsync, they were identical.
>>
>> Can someone with knowledge about the on-disk structure please
>> confirm/reject that subvolumes (created before starting rsync on the
>> block device) should be safe and never move by themselves? Or was I
>> just lucky?
>> Are there any things that might break the backup when performed duri=
ng rsync?
>> Like creating/deleting other subvolumes, probably defrag isn't a goo=
d
>> idea either :)
>
> The short answer is that you were lucky ;)
That's why I only try this at home :)
>
> The big risk is the extent allocation tree is changing, and the tree =
of
> tree roots is changing and so the result of the rsync isn't going to =
be
> a fully consistent filesystem.
Nope, I understand it's not fully consistent, but I'm hoping for
consistency for all subvols that weren't in use during the sync/dd.
>
> With that said, as long as you can mount it the actual files in the
> snapshot are going to be valid. =C2=A0The only exceptions are if you'=
ve run a
> filesystem balance or removed a drive during the rsync.
Do I understand correctly that as long as I don't defrag/balance or
add/remove drives (my example is just about 1 drive though), there's a
chance the result isn't mountable, but if it _is_ mountable, all
subvolumes that weren't touched during the rsync/dd should be fine?
Or is there a chance that some files/dirs (in a snapshot volume) are
fine, but others are broken?
In other words: do I only need to check the destination to be
mountable afterwards or does that by itself mean not enough.
You mentioned 2 important trees
- tree of tree roots
- extent allocation tree
My root subvolume contains only subvolumes (no dirs/files), 1 of which
is mounted with -o subvol, the rest are snapshots.
Am I correct to assume the tree of tree roots doesn't change as long
as I don't create/remove subvols?
And for the extent allocation tree, can I assume that all changes to
extent allocation will be related to files/dirs changing on the
currently in-use subvolume? All extents that contain files in any of
the snapshots will still be there as changes to those files in
"current" will be COWed to new extents. So the risk is not that
extents are marked "free" when they aren't, but I might end up with
extents that are marked in-use while they are free.
As I expect "current" to become corrupt in the destination, I will
remove the subvolume there. Will that take care of the extent
allocation tree? Or will there still be extents marked "in use"
without any subvolume/dir/file pointing at it? If so, this is probably
something that the future fsck can deal with?
>
> -chris
Thanks,
Mathijs
>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHSET v3.1 0/7] data integrity: Stabilize pages during writeback for various fses
From: Andy Lutomirski @ 2011-10-23 16:38 UTC (permalink / raw)
To: Jan Kara
Cc: OGAWA Hirofumi, Darrick J. Wong, Theodore Tso, Alexander Viro,
Jens Axboe, Martin K. Petersen, Jeff Layton, Dave Chinner,
linux-kernel, Dave Hansen, Christoph Hellwig, linux-mm,
Chris Mason, Joel Becker, linux-scsi, linux-fsdevel, linux-ext4,
Mingming Cao
In-Reply-To: <20110510162237.GM4402@quack.suse.cz>
On 05/10/2011 09:22 AM, Jan Kara wrote:
> On Wed 11-05-11 01:12:13, OGAWA Hirofumi wrote:
>> Jan Kara<jack@suse.cz> writes:
>>
>>>> Did you already consider, to copy only if page was writeback (like
>>>> copy-on-write)? I.e. if page is on I/O, copy, then switch the page for
>>>> writing new data.
>>> Yes, that was considered as well. We'd have to essentially migrate the
>>> page that is under writeback and should be written to. You are going to pay
>>> the cost of page allocation, copy, increased memory& cache pressure.
>>> Depending on your backing storage and workload this may or may not be better
>>> than waiting for IO...
>>
>> Maybe possible, but you really think on usual case just blocking is
>> better?
> Define usual case... As Christoph noted, we don't currently have a real
> practical case where blocking would matter (since frequent rewrites are
> rather rare). So defining what is usual when we don't have a single real
> case is kind of tough ;)
>
I'm a bit late to the party, but I have such a use case. I have a
real-time program that generates logs. There's a thread that makes sure
that there are always mlocked, MAP_SHARED, writable pages for the logs,
and under normal (or even very heavy) load, the mlocked pages always
stay far ahead of the logs. On 2.6.39, it works great [1]. On 3.0,
it's unusable -- latencies of 30-100 ms are very common.
In this case, neither throughput nor available memory matter at all --
I'm not stressing either. So copying the pages (especially if they're
mlocked) would be more than a small percentage win -- it would be the
difference between great performance and unusability.
I wonder if we want a stronger version of mlock that says "this page
must not be swapped out and, in addition, ptes must always be mapped
with all appropriate permission bits set". (This is only possible with
hardware dirty and accessed bits, but we could come close even without
them.)
[1] file_update_time is a problem. patches coming.
--Andy
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCHSET v3.1 0/7] data integrity: Stabilize pages during writeback for various fses
From: Andy Lutomirski @ 2011-10-23 16:38 UTC (permalink / raw)
To: Jan Kara
Cc: OGAWA Hirofumi, Darrick J. Wong, Theodore Tso, Alexander Viro,
Jens Axboe, Martin K. Petersen, Jeff Layton, Dave Chinner,
linux-kernel, Dave Hansen, Christoph Hellwig, linux-mm,
Chris Mason, Joel Becker, linux-scsi, linux-fsdevel, linux-ext4,
Mingming Cao
In-Reply-To: <20110510162237.GM4402@quack.suse.cz>
On 05/10/2011 09:22 AM, Jan Kara wrote:
> On Wed 11-05-11 01:12:13, OGAWA Hirofumi wrote:
>> Jan Kara<jack@suse.cz> writes:
>>
>>>> Did you already consider, to copy only if page was writeback (like
>>>> copy-on-write)? I.e. if page is on I/O, copy, then switch the page for
>>>> writing new data.
>>> Yes, that was considered as well. We'd have to essentially migrate the
>>> page that is under writeback and should be written to. You are going to pay
>>> the cost of page allocation, copy, increased memory& cache pressure.
>>> Depending on your backing storage and workload this may or may not be better
>>> than waiting for IO...
>>
>> Maybe possible, but you really think on usual case just blocking is
>> better?
> Define usual case... As Christoph noted, we don't currently have a real
> practical case where blocking would matter (since frequent rewrites are
> rather rare). So defining what is usual when we don't have a single real
> case is kind of tough ;)
>
I'm a bit late to the party, but I have such a use case. I have a
real-time program that generates logs. There's a thread that makes sure
that there are always mlocked, MAP_SHARED, writable pages for the logs,
and under normal (or even very heavy) load, the mlocked pages always
stay far ahead of the logs. On 2.6.39, it works great [1]. On 3.0,
it's unusable -- latencies of 30-100 ms are very common.
In this case, neither throughput nor available memory matter at all --
I'm not stressing either. So copying the pages (especially if they're
mlocked) would be more than a small percentage win -- it would be the
difference between great performance and unusability.
I wonder if we want a stronger version of mlock that says "this page
must not be swapped out and, in addition, ptes must always be mapped
with all appropriate permission bits set". (This is only possible with
hardware dirty and accessed bits, but we could come close even without
them.)
[1] file_update_time is a problem. patches coming.
--Andy
^ permalink raw reply
* [ath9k-devel] Can't associate with a particular AP
From: Julien Valroff @ 2011-10-23 16:34 UTC (permalink / raw)
To: ath9k-devel
In-Reply-To: <20111023150240.882.qmail@stuge.se>
Le dimanche 23 oct. 2011 ? 17:02:40 (+0200 CEST), Peter Stuge a ?crit?:
> Julien Valroff wrote:
> > I have tried and captured the association process from my 2 other laptops
> > using wireshark, but unfortunately, I am unable to capture packets in
> > monitoring mode: in Wireshark, the box is not greyed out, but I cannot tick
> > it.
>
> I think it is important to iwconfig eth1 mode monitor before you run
> ip link set dev eth1 up, and once you have done that it does not
> matter what settings wireshark does or does not do, the mode can't be
> changed when the interface is up, so just starting the capture should
> work.
I couldn't capture anything this way from the other laptops.
As explained, I have been able to setup a mon0 interface on the laptop with
the ath9k module.
> > When the association succeeds, I notice the MAC address of the AP
> > changes:
> ..
> > Before the association:
> > Cell 01 - Address: BA:F4:8A:C6:C8:44
> ..
> > After the succeeded association:
> > Cell 04 - Address: C6:6E:27:A6:BE:A4
>
> Which is the actual correct address of your AP? I would expect
> c6-6e-27, but the IEEE OUI listing does not have a match for it!
I would also say that, given what I can see from the other laptops.
> > How is this possible?
>
> I guess some fundamental data corruption problem in ath9k. I'm not
> surprised at all, although developers claim that by now the code
> quality is good. This is a total BS error. I could rant for forever.
Are you sure it could not be a problem with the AP? Or an incompatibility
between both, as I have no problem with the same AP with other
laptops/smartphones.
> > Please continue and CC me as I am not subscribed to the list.
>
> I would try FreeBSD on that machine. I believe the driver there is
> more reliable, and using it can allow you to get more concrete help
> from Adrian in case the problem is seen also there.
I will try something like a livecd, I do not want to install FreeBSD.
Or it could be a good opportunity to test Debian GNU/kFreeBSD ;)
Cheers,
Julien
--
.''`. Julien Valroff ~ <julien@kirya.net> ~ <julien@debian.org>
: :' : Debian Developer & Free software contributor
`. `'` http://www.kirya.net/
`- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1
^ permalink raw reply
* [PATCH] staging:mei: wd_ops and wd_info should be static
From: Oren Weil @ 2011-10-23 16:30 UTC (permalink / raw)
To: gregkh; +Cc: devel, linux-kernel, tomas.winkler, Oren Weil
From: Tomas Winkler <tomas.winkler@intel.com>
wd_ops and wd_info structures are local to wd.c so mark them static
Cc: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
drivers/staging/mei/wd.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/mei/wd.c b/drivers/staging/mei/wd.c
index ffca7ca..cb3f92d 100644
--- a/drivers/staging/mei/wd.c
+++ b/drivers/staging/mei/wd.c
@@ -331,14 +331,14 @@ static int mei_wd_ops_set_timeout(struct watchdog_device *wd_dev, unsigned int t
/*
* Watchdog Device structs
*/
-const struct watchdog_ops wd_ops = {
+static const struct watchdog_ops wd_ops = {
.owner = THIS_MODULE,
.start = mei_wd_ops_start,
.stop = mei_wd_ops_stop,
.ping = mei_wd_ops_ping,
.set_timeout = mei_wd_ops_set_timeout,
};
-const struct watchdog_info wd_info = {
+static const struct watchdog_info wd_info = {
.identity = INTEL_AMT_WATCHDOG_ID,
.options = WDIOF_KEEPALIVEPING,
};
--
1.7.5.4
^ permalink raw reply related
* Re: a bug when execute "git status" in git version 1.7.7.431.g89633
From: Jeff King @ 2011-10-23 16:29 UTC (permalink / raw)
To: René Scharfe; +Cc: John Hsing, Matthieu Moy, git
In-Reply-To: <4EA415BD.1040109@lsrfire.ath.cx>
On Sun, Oct 23, 2011 at 03:25:17PM +0200, René Scharfe wrote:
> I can reproduce the malloc crash on Ubuntu 11.10 with these simple steps:
> [...]
> Bisect points to 2548183ba, "fix phantom untracked files when
> core.ignorecase is set" from Jeff (cc:d). If I revert that patch from
> master (8963314c), git status works fine.
Hmm. Interesting. I can't reproduce here. And I've been running with
this patch for over a year, and never seen that. Given your fix, I guess
it's related to pointer size. Are you on a 32-bit machine, by any
chance?
-Peff
^ permalink raw reply
* Is there a tool which can generate a small and simple source tree after config?
From: jiangtao.jit @ 2011-10-23 16:29 UTC (permalink / raw)
To: kernelnewbies
Hi:
While reading the kernel code
1. the huge amount of files make me scared
there are too many alike functions in different files
sometimes I can't figure out which one was really compiled
2. too many macros in the definition of a struct or functions declaration
confused me a lot
I tried to follow the generated file autoconf.h to guess the final face
but it's really a difficult thing
Is there a tool which can generate a small and simple source tree after config?
not pre-processor
just generate a small source tree contains the files and dirs which really will be compiled
and no macros like CONFIG_SMP etc.
according to the configuration
or some other way to understand the architecture of the final working source tree?
Thanks.
--
2011-10-23
jiangtao.jit
^ permalink raw reply
* Re: [PATCH 02/15] ATA : vortex86 : fix vortex86dx/sx hardware CRC bug.
From: Paul Schilling @ 2011-10-23 16:26 UTC (permalink / raw)
To: Rolf Eike Beer
Cc: Jeff Garzik, David S. Miller, Jesse Barnes, linux-ide,
linux-kernel, linux-pci
In-Reply-To: <1732355.g0uNX7XlKI@donald.sf-tec.de>
Thanks, That was a good catch. I had that extra struct for another
revision of the RDC peripheral integrated into the
Vortex86DX. I removed it when I moved it to the pata_rdc.c driver but
forgot the struct. The it821x driver works
for the RDC drivers when DMA is turned off. But the RDC driver is the
more logical choice.
I will make the fix and send out the new patch.
I accidentally sent this through the gmail interface with html on,
Some of you may get this email twice.
Thanks,
Paul Schilling
On Sun, Oct 23, 2011 at 3:20 AM, Rolf Eike Beer <eike-kernel@sf-tec.de> wrote:
>
> Paul Schilling wrote:
> > This fixes a DMA issue related to a CRC bug on
> > the RDC pata peripherial found on the vortex86sx and vortex86dx.
> >
> > Signed-off-by: Paul Schilling <paul.s.schilling@gmail.com>
> > ---
> > drivers/ata/pata_it821x.c | 22 ++++++++++++++++++----
> > drivers/ata/pata_rdc.c | 29 ++++++++++++++++++++++++-----
> > drivers/ide/it821x.c | 9 +++++++--
> > include/linux/pci_ids.h | 2 ++
> > 4 files changed, 51 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/ata/pata_it821x.c b/drivers/ata/pata_it821x.c
> > index c5532b9..5f8a54a 100644
> > --- a/drivers/ata/pata_it821x.c
> > +++ b/drivers/ata/pata_it821x.c
> > @@ -897,7 +897,16 @@ static int it821x_init_one(struct pci_dev *pdev, const
> > struct pci_device_id *id) static const struct ata_port_info info_rdc_11 = {
> > .flags = ATA_FLAG_SLAVE_POSS,
> > .pio_mask = ATA_PIO4,
> > - .mwdma_mask = ATA_MWDMA2,
> > + .mwdma_mask = 0,
> > + .udma_mask = 0,
> > + /* No UDMA */
> > + .port_ops = &it821x_rdc_port_ops
> > + };
> > + static const struct ata_port_info info_rdc_01 = {
> > + .flags = ATA_FLAG_SLAVE_POSS,
> > + .pio_mask = ATA_PIO4,
> > + .mwdma_mask = 0,
> > + .udma_mask = 0,
> > /* No UDMA */
> > .port_ops = &it821x_rdc_port_ops
> > };
>
> Why do you define this if it is never used?
>
> Eike
^ permalink raw reply
* [ath9k-devel] Can't associate with a particular AP
From: Julien Valroff @ 2011-10-23 16:25 UTC (permalink / raw)
To: ath9k-devel
In-Reply-To: <CAJ-VmoknKUc5u1CUeM2mc352pyPnmVhpF1TEZF-e93a=FdACNg@mail.gmail.com>
Le dimanche 23 oct. 2011 ? 17:54:07 (+0200 CEST), Adrian Chadd a ?crit?:
> I'm kind of surprised that you're seeing different AP MACs, where did
> you take that capture from?
^ permalink raw reply
* [PATCH] DaVinci: only poll EPCPR on DM644x and DM355
From: Nori, Sekhar @ 2011-10-23 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4EA40BDE.40606@mvista.com>
On Sun, Oct 23, 2011 at 18:13:10, Sergei Shtylyov wrote:
> On 23-10-2011 15:10, Nori, Sekhar wrote:
[...]
> > OMAP-L137 and OMAP-L138 have additional power domains for DSP
> > and Shared RAM, but do not support powering them down.
>
> I haven't found such words in either OMAP-L137 or OMAP-L138 datasheets.
> What they say is:
>
> <<
> - On PSC0 PD1/PD_DSP Domain: Controls the sleep state for DSP L1 and L2 Memories
> - On PSC1 PD1/PD_SHRAM Domain: Controls the sleep state for the 128K Shared RAM
> >>
>
> Although "OMAP-L137 Application Processor System Reference Guide" indeed
> said that powering off domain 1 is not supported.
Right. There is a statement put in for shared ram as well.
"
Currently powering down the RAMs via the pseudo/RAM power domain is not
supported; therefore, these domains and the RAM should be left in their
default power on state.
"
BTW, it looks like a separate "System Reference Guide" doesn't exist
anymore and all the OMAP-L1x user guides have been consolidated to a
single "Technical Reference Manual".
> Actually, I was able to power down DSP/shared RAM domains on DA830 (at
> least the state transition completed); although the domains were on, at least
> after U-Boot. That's how I checked that the code powering up these domains
> actually locks up on this SoC.
Okay. Surely there must have been some corner case issues found
which probably led the chip design team to make this feature
unsupported.
> > So, looks like the only SoC where PDSTAT might indicate a powered
> > down domain is DM644x and existing code to looks alright for
> > that SoC.
>
> > At this time, it would be better to leave the code as-is and
> > revisit it if/when a new SoC with programmable power domain
> > support comes along.
>
> At least on DA830 power domains appear to be programmable. So I'd still
> like the patch to be applied (I could drop DM355 check though).
The problem would be that power domain state transition procedure isn't
documented for any SoC other than DM644x. So, we can never be sure
that just avoiding EPCR poll is sufficient for DA830. Software attempting
this would be operating out of spec.
So, how about allowing a power domain transition for DM644x and bailing
out with a warning if a power domain on any other SoC is found to be off?
This way users attempting this will be warned and fix their boot loader.
Thanks,
Sekhar
^ permalink raw reply
* Re: lsusd - The Linux SUSpend Daemon
From: Alan Stern @ 2011-10-23 16:17 UTC (permalink / raw)
To: NeilBrown; +Cc: John Stultz, Rafael J. Wysocki, mark gross, Linux PM list, LKML
In-Reply-To: <20111023192147.49413485@notabene.brown>
On Sun, 23 Oct 2011, NeilBrown wrote:
> > There shouldn't be any trouble about making wakeup_count pollable. It
> > also would need to respect nonblocking reads, which it currently does
> > not do.
>
> Hmm.. you are correct. I wonder why I thought it did support non-blocking
> reads...
> I guess it was the code for handling an interrupted system call.
>
> I feel a bit uncomfortable with the idea of sysfs files that block but I
> don't think I can convincingly argue against it.
> A non-blocking flag could be passed in, but it would be a very messy change -
> lots of function call signatures changing needlessly: we would need a flag
> to the 'show' method ... or add a 'show_nonblock' method which would also be
> ugly.
Right. Sysfs is pretty inflexible.
> But I think there is a need to block - if there is an in-progress event then
> it must be possible to wait for it to complete as it may not be visible to
> userspace until then.
> We could easily enable 'poll' for wakeup_count and then make it always
> non-blocking, but I'm not really sure I want to require programs to use poll,
> only to allow them. And without using poll there is no way to wait.
>
> As wakeup_count really has to be single-access we could possibly fudge
> something by remembering the last value read (like we remember the last value
> written).
A simpler approach would be to add a nonblocking variant:
/sys/power/wakeup_count_nb. It would make sense to support poll for
this file; poll isn't very useful for the wakeup_count file.
Alan Stern
^ permalink raw reply
* git gui: adding bare remotes on local filesystem reports error
From: Peter Oberndorfer @ 2011-10-23 16:14 UTC (permalink / raw)
To: git; +Cc: Giuseppe Bilotta, Shawn O. Pearce
Hi,
i just tried using git gui to add a remote on the local file system
and push to it.
(set Location to /tmp/blah.git, select "Initialize Remote Repository and Push")
but git gui reported:
fatal: GIT_WORK_TREE (or --work-tree=<directory>) not allowed without specifying GIT_DIR (or --git-dir=<directory>)
I bisected the error to
a9fa11fe5bd5978bb175b3b5663f6477a345d428 git-gui: set GIT_DIR and GIT_WORK_TREE after setup
I guess it is necessary to unset the GIT_DIR and GIT_WORKTREE env vars before calling
git --git-dir=$location init --bare
On a side note i am wondering why it is necessary to call mkdir -p?
And why it is not using git init --bare <path>
During some tests it created all leading directories.
Thanks,
Greetings Peter
^ permalink raw reply
* Re: Proposed memcg meeting at October Kernel Summit/European LinuxCon in Prague
From: James Bottomley @ 2011-10-23 16:12 UTC (permalink / raw)
To: Glauber Costa
Cc: Kir Kolyshkin, Pavel Emelianov, GregThelen, pjt@google.com,
Tim Hockin, Ying Han, KAMEZAWA Hiroyuki, Johannes Weiner,
Dave Hansen, Paul Menage, linux-mm@kvack.org
In-Reply-To: <1316693805.10571.25.camel@dabdike>
Just a note that we'll have three ours on Wednesday. We'll be in the
Quadrant Room on the 3rd floor of the Clarion Hotel from 13:00-16:00 on
Wednesday 26 October.
I think current items on the agenda are
Isolated Memory Cgroups
accounting of shared resources
Further discussion of kernel memory accounting
We'll run it as sort of an unconference, so topics will be gathered as
we arrive at 13:00.
James
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 00/22] Refactor to accept NUL in commit messages
From: Jeff King @ 2011-10-23 16:09 UTC (permalink / raw)
To: Robin Rosenberg
Cc: Nguyễn Thái Ngọc Duy, git, Junio C Hamano,
Ævar Arnfjörð
In-Reply-To: <4EA3F00E.9040006@gmail.com>
On Sun, Oct 23, 2011 at 12:44:30PM +0200, Robin Rosenberg wrote:
> Jeff King skrev 2011-10-22 21.09:
> >On Sat, Oct 22, 2011 at 09:04:19PM +1100, Nguyen Thai Ngoc Duy wrote:
> >
> >>This series helps pass commit message size up to output functions,
> >>though it does not change any output functions to print ^@.
> >Can we take a step back for a second and discuss what git _should_ do
> >with commits that contain NUL?
> Yes please. I don't think allowing NUL makes sense, but it makes sense
> to state how NUL should be handled when anyone attempt it, so there
> might be things to fix even if NUL is banned.
>
> Are there any such commits in the wild?
Adding an arbitrary NUL, no, I don't think I've ever seen it outside of
people (myself included) trying to break git in interesting ways.
But utf16 may contains NUL bytes, so I expect configuring your editor to
output utf16 and running "git commit" would give you the most likely
example.
-Peff
^ permalink raw reply
* Re: [PATCH 00/22] Refactor to accept NUL in commit messages
From: Jeff King @ 2011-10-23 16:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, git, Ævar Arnfjörð
In-Reply-To: <7vehy459bg.fsf@alter.siamese.dyndns.org>
On Sun, Oct 23, 2011 at 02:46:59AM -0700, Junio C Hamano wrote:
> > But when it comes to "Git" Porcelains (e.g. the log family of commands),
> > we do assume people do not store random binary byte sequences in commits,
> > and we do take advantage of that assumption by splitting each "line" at
> > LF, indenting them with 4 spaces, etc. In other words, a commit log in the
> > Git context _is_ pretty much text and not arbitrary byte sequence.
>
> Think what would cutting at a byte whose value is 012 and adding four
> bytes whose values are 040 to each of "lines" that formed with such
> cutting do to UTF-16 goo, even if it does not contain any NUL byte. As far
> as Git Porcelains are concerned, it is no different from random binary
> byte sequences.
But as Duy mentions, we have an encoding header. Shouldn't we treat it
like binary goo until we do reencode_log_message, and _then_ we can
break it into lines?
-Peff
^ permalink raw reply
* Re: build errors in openssl-native
From: MartinC @ 2011-10-23 7:11 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <loom.20111022T231054-510@post.gmane.org>
Pierluigi Passaro <pierluigi.passaro <at> phoenixsoftware.it> writes:
>
> Hi Wilder,
> try dropping libdeps-first.patch in openssl-native recipe.
> It does not allow openssl-native build on ubuntu 11.10.
>
> Regards
> Pierlugi
>
This worked.
I had the same issue (while doing a 'bitbake helloworld-image' for beagleboard
angstrom under Ubuntu 11.10 'oneiric'), with bitbake 1.12.0 and openembedded
2011.03 (from git).
I edited $OEBASE/oe/openembedded/recipes/openssl/openssl-native_1.0.0d.bb and
removed the reference to libdeps-first.patch in the SRC_URI section.
Many thanks for the help - getting started with OE/bitbake can be a bit
intimidating for the uninitiated!
Krgds, M
^ permalink raw reply
* LVM2 ./WHATS_NEW lib/format_text/import_vsn1.c
From: zkabelac @ 2011-10-23 16:05 UTC (permalink / raw)
To: lvm-devel
CVSROOT: /cvs/lvm2
Module name: LVM2
Changes by: zkabelac at sourceware.org 2011-10-23 16:05:45
Modified files:
. : WHATS_NEW
lib/format_text: import_vsn1.c
Log message:
Drop mempool parameter from read functions
Use implicit vgmem pool.
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/WHATS_NEW.diff?cvsroot=lvm2&r1=1.2169&r2=1.2170
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/lib/format_text/import_vsn1.c.diff?cvsroot=lvm2&r1=1.94&r2=1.95
--- LVM2/WHATS_NEW 2011/10/23 16:02:01 1.2169
+++ LVM2/WHATS_NEW 2011/10/23 16:05:45 1.2170
@@ -1,5 +1,6 @@
Version 2.02.89 -
==================================
+ Use vg memory pool implicitely for vg read.
Always use vg memory pool for allocated lv segment.
Remove extra 4kB buffer allocated on stack in print_log().
Make move_lv_segment non-static function and use dm_list function.
--- LVM2/lib/format_text/import_vsn1.c 2011/10/23 16:02:02 1.94
+++ LVM2/lib/format_text/import_vsn1.c 2011/10/23 16:05:45 1.95
@@ -25,7 +25,7 @@
#include "text_import.h"
#include "defaults.h"
-typedef int (*section_fn) (struct format_instance * fid, struct dm_pool * mem,
+typedef int (*section_fn) (struct format_instance * fid,
struct volume_group * vg, const struct dm_config_node * pvn,
const struct dm_config_node * vgn,
struct dm_hash_table * pv_hash,
@@ -148,7 +148,7 @@
return 1;
}
-static int _read_pv(struct format_instance *fid, struct dm_pool *mem,
+static int _read_pv(struct format_instance *fid,
struct volume_group *vg, const struct dm_config_node *pvn,
const struct dm_config_node *vgn __attribute__((unused)),
struct dm_hash_table *pv_hash,
@@ -156,6 +156,7 @@
unsigned *scan_done_once,
unsigned report_missing_devices)
{
+ struct dm_pool *mem = vg->vgmem;
struct physical_volume *pv;
struct pv_list *pvl;
const struct dm_config_value *cv;
@@ -285,10 +286,10 @@
dm_list_add(&lv->segments, &seg->list);
}
-static int _read_segment(struct dm_pool *mem, struct volume_group *vg,
- struct logical_volume *lv, const struct dm_config_node *sn,
+static int _read_segment(struct logical_volume *lv, const struct dm_config_node *sn,
struct dm_hash_table *pv_hash)
{
+ struct dm_pool *mem = lv->vg->vgmem;
uint32_t area_count = 0u;
struct lv_segment *seg;
const struct dm_config_node *sn_child = sn->child;
@@ -321,7 +322,7 @@
return 0;
}
- if (!(segtype = get_segtype_from_string(vg->cmd, segtype_str)))
+ if (!(segtype = get_segtype_from_string(lv->vg->cmd, segtype_str)))
return_0;
if (segtype->ops->text_import_area_count &&
@@ -343,7 +344,7 @@
if (dm_config_get_list(sn_child, "tags", &cv) &&
!(read_tags(mem, &seg->tags, cv))) {
log_error("Couldn't read tags for a segment of %s/%s.",
- vg->name, lv->name);
+ lv->vg->name, lv->name);
return 0;
}
@@ -430,8 +431,7 @@
return 1;
}
-static int _read_segments(struct dm_pool *mem, struct volume_group *vg,
- struct logical_volume *lv, const struct dm_config_node *lvn,
+static int _read_segments(struct logical_volume *lv, const struct dm_config_node *lvn,
struct dm_hash_table *pv_hash)
{
const struct dm_config_node *sn;
@@ -443,7 +443,7 @@
* All sub-sections are assumed to be segments.
*/
if (!sn->v) {
- if (!_read_segment(mem, vg, lv, sn, pv_hash))
+ if (!_read_segment(lv, sn, pv_hash))
return_0;
count++;
@@ -483,7 +483,6 @@
}
static int _read_lvnames(struct format_instance *fid __attribute__((unused)),
- struct dm_pool *mem,
struct volume_group *vg, const struct dm_config_node *lvn,
const struct dm_config_node *vgn __attribute__((unused)),
struct dm_hash_table *pv_hash __attribute__((unused)),
@@ -491,6 +490,7 @@
unsigned *scan_done_once __attribute__((unused)),
unsigned report_missing_devices __attribute__((unused)))
{
+ struct dm_pool *mem = vg->vgmem;
struct logical_volume *lv;
const char *lv_alloc;
const struct dm_config_value *cv;
@@ -552,7 +552,6 @@
}
static int _read_lvsegs(struct format_instance *fid __attribute__((unused)),
- struct dm_pool *mem,
struct volume_group *vg, const struct dm_config_node *lvn,
const struct dm_config_node *vgn __attribute__((unused)),
struct dm_hash_table *pv_hash,
@@ -581,7 +580,7 @@
memcpy(&lv->lvid.id[0], &lv->vg->id, sizeof(lv->lvid.id[0]));
- if (!_read_segments(mem, vg, lv, lvn, pv_hash))
+ if (!_read_segments(lv, lvn, pv_hash))
return_0;
lv->size = (uint64_t) lv->le_count * (uint64_t) vg->extent_size;
@@ -606,7 +605,6 @@
static int _read_sections(struct format_instance *fid,
const char *section, section_fn fn,
- struct dm_pool *mem,
struct volume_group *vg, const struct dm_config_node *vgn,
struct dm_hash_table *pv_hash,
struct dm_hash_table *lv_hash,
@@ -627,7 +625,7 @@
}
for (n = n->child; n; n = n->sib) {
- if (!fn(fid, mem, vg, n, vgn, pv_hash, lv_hash,
+ if (!fn(fid, vg, n, vgn, pv_hash, lv_hash,
scan_done_once, report_missing_devices))
return_0;
}
@@ -728,7 +726,7 @@
goto bad;
}
- if (!_read_sections(fid, "physical_volumes", _read_pv, vg->vgmem, vg,
+ if (!_read_sections(fid, "physical_volumes", _read_pv, vg,
vgn, pv_hash, lv_hash, 0, &scan_done_once)) {
log_error("Couldn't find all physical volumes for volume "
"group %s.", vg->name);
@@ -751,15 +749,15 @@
goto bad;
}
- if (!_read_sections(fid, "logical_volumes", _read_lvnames, vg->vgmem,
- vg, vgn, pv_hash, lv_hash, 1, NULL)) {
+ if (!_read_sections(fid, "logical_volumes", _read_lvnames, vg,
+ vgn, pv_hash, lv_hash, 1, NULL)) {
log_error("Couldn't read all logical volume names for volume "
"group %s.", vg->name);
goto bad;
}
- if (!_read_sections(fid, "logical_volumes", _read_lvsegs, vg->vgmem,
- vg, vgn, pv_hash, lv_hash, 1, NULL)) {
+ if (!_read_sections(fid, "logical_volumes", _read_lvsegs, vg,
+ vgn, pv_hash, lv_hash, 1, NULL)) {
log_error("Couldn't read all logical volumes for "
"volume group %s.", vg->name);
goto bad;
^ permalink raw reply
* Re: how stable are snapshots at the block level?
From: Chris Mason @ 2011-10-23 16:05 UTC (permalink / raw)
To: Mathijs Kwik; +Cc: linux-btrfs
In-Reply-To: <CAKvOHKABup6D2pwbiZpCfxoHt7Obv6sHAZqcPp=ce9ZcJ8-vuw@mail.gmail.com>
On Sun, Oct 23, 2011 at 09:45:10AM +0200, Mathijs Kwik wrote:
> Hi all,
>
> I'm currently doing backups by doing a btrfs snapshot, then rsync the
> snapshot to my backup location.
> As I have a lot of small files and quite some changes between
> snapshots, this process is taking more and more time.
> I looked at "btrfs find-new", which is promissing, but I need
> something to track deletes and modifications too.
> Also, while this will help the initial comparison phase, most time is
> still spent on the syncing itself, as a lot of overhead is caused by
> the tiny files.
>
> After finding some discussion about it here:
> http://www.backupcentral.com/phpBB2/two-way-mirrors-of-external-mailing-lists-3/backuppc-21/using-rsync-for-blockdevice-level-synchronisation-of-backupp-100438
>
> I found that the official rsync-patches tarball includes the patch
> that allows syncing full block devices.
> After the initial backup, I found that this indeed speeds up my backups a lot.
> Ofcourse this is meant for syncing unmounted filesystems (or other
> things that are "stable" at the block level, like LVM snapshot
> volumes).
>
> I tested backing up a live btrfs filesystem by making a btrfs
> snapshot, and this (very simple, non-thorough) turned out to work ok.
> My root subvolume contains the "current" subvolume (which I mount) and
> several backup subvolumes.
> Ofcourse I understand that the "current" subvolume on the backup
> destination is broken/inconsistent, as I change it during the rsync
> run. But when I mounted the backup disk and compared the subvolumes
> using normal file-by-file rsync, they were identical.
>
> Can someone with knowledge about the on-disk structure please
> confirm/reject that subvolumes (created before starting rsync on the
> block device) should be safe and never move by themselves? Or was I
> just lucky?
> Are there any things that might break the backup when performed during rsync?
> Like creating/deleting other subvolumes, probably defrag isn't a good
> idea either :)
The short answer is that you were lucky ;)
The big risk is the extent allocation tree is changing, and the tree of
tree roots is changing and so the result of the rsync isn't going to be
a fully consistent filesystem.
With that said, as long as you can mount it the actual files in the
snapshot are going to be valid. The only exceptions are if you've run a
filesystem balance or removed a drive during the rsync.
-chris
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 1/1] Introduce a new bus "ICC" to connect APIC
From: Jan Kiszka @ 2011-10-23 16:00 UTC (permalink / raw)
To: Blue Swirl; +Cc: aliguori, pingfank, qemu-devel
In-Reply-To: <CAAu8pHsLcgRCgr3t-0NDfoM=buZMbboRtAPKqeLz-_di-4ft=A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 661 bytes --]
On 2011-10-23 17:54, Blue Swirl wrote:
> On Sun, Oct 23, 2011 at 15:45, Jan Kiszka <jan.kiszka@web.de> wrote:
>> On 2011-10-23 14:40, Blue Swirl wrote:
>>> I'm not sure that a full bus is needed for now, even if it could match
>>> real HW better, since the memory API already provides the separation
>>> needed. Perhaps this would be needed later to make IRQs per-CPU also,
>>> or to put IOAPIC also to the bus?
>>
>> The ICC interconnects LAPICs and IOAPICs.
>
> But not between CPU core and its LAPIC?
Nope, that link is core-internal and has nothing to do with the ICC. See
e.g. Figure 2-2 of Intel's "MultiProcessor Specification".
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* LVM2 ./WHATS_NEW lib/format1/import-extents.c ...
From: zkabelac @ 2011-10-23 16:02 UTC (permalink / raw)
To: lvm-devel
CVSROOT: /cvs/lvm2
Module name: LVM2
Changes by: zkabelac at sourceware.org 2011-10-23 16:02:02
Modified files:
. : WHATS_NEW
lib/format1 : import-extents.c
lib/format_pool: import_export.c
lib/format_text: import_vsn1.c
lib/metadata : lv_alloc.h lv_manip.c merge.c
Log message:
Always use vg memory pool for allocated lv segment
Remove mem pool parameter from alloc_lv_segment()
Since we should always allocate LV segment from the vg mempool.
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/WHATS_NEW.diff?cvsroot=lvm2&r1=1.2168&r2=1.2169
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/lib/format1/import-extents.c.diff?cvsroot=lvm2&r1=1.41&r2=1.42
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/lib/format_pool/import_export.c.diff?cvsroot=lvm2&r1=1.34&r2=1.35
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/lib/format_text/import_vsn1.c.diff?cvsroot=lvm2&r1=1.93&r2=1.94
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/lib/metadata/lv_alloc.h.diff?cvsroot=lvm2&r1=1.30&r2=1.31
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/lib/metadata/lv_manip.c.diff?cvsroot=lvm2&r1=1.303&r2=1.304
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/lib/metadata/merge.c.diff?cvsroot=lvm2&r1=1.53&r2=1.54
--- LVM2/WHATS_NEW 2011/10/22 16:52:00 1.2168
+++ LVM2/WHATS_NEW 2011/10/23 16:02:01 1.2169
@@ -1,5 +1,6 @@
Version 2.02.89 -
==================================
+ Always use vg memory pool for allocated lv segment.
Remove extra 4kB buffer allocated on stack in print_log().
Make move_lv_segment non-static function and use dm_list function.
Pass exclusive LV locks to all nodes in the cluster.
--- LVM2/lib/format1/import-extents.c 2011/09/06 00:26:42 1.41
+++ LVM2/lib/format1/import-extents.c 2011/10/23 16:02:01 1.42
@@ -222,8 +222,8 @@
while (le < lvm->lv->le_count) {
len = _area_length(lvm, le);
- if (!(seg = alloc_lv_segment(cmd->mem, segtype, lvm->lv, le,
- len, 0, 0, NULL, NULL, 1, len, 0, 0, 0, NULL))) {
+ if (!(seg = alloc_lv_segment(segtype, lvm->lv, le, len, 0, 0,
+ NULL, NULL, 1, len, 0, 0, 0, NULL))) {
log_error("Failed to allocate linear segment.");
return 0;
}
@@ -292,7 +292,7 @@
area_len, first_area_le, total_area_len))
area_len++;
- if (!(seg = alloc_lv_segment(cmd->mem, segtype, lvm->lv,
+ if (!(seg = alloc_lv_segment(segtype, lvm->lv,
lvm->stripes * first_area_le,
lvm->stripes * area_len,
0, lvm->stripe_size, NULL, NULL,
--- LVM2/lib/format_pool/import_export.c 2011/09/06 00:26:42 1.34
+++ LVM2/lib/format_pool/import_export.c 2011/10/23 16:02:01 1.35
@@ -193,7 +193,7 @@
"striped")))
return_0;
- if (!(seg = alloc_lv_segment(mem, segtype, lv, *le_cur,
+ if (!(seg = alloc_lv_segment(segtype, lv, *le_cur,
area_len * usp->num_devs, 0,
usp->striping, NULL, NULL, usp->num_devs,
area_len, 0, 0, 0, NULL))) {
@@ -233,7 +233,7 @@
for (j = 0; j < usp->num_devs; j++) {
area_len = (usp->devs[j].blocks) / POOL_PE_SIZE;
- if (!(seg = alloc_lv_segment(mem, segtype, lv, *le_cur,
+ if (!(seg = alloc_lv_segment(segtype, lv, *le_cur,
area_len, 0, usp->striping,
NULL, NULL, 1, area_len,
POOL_PE_SIZE, 0, 0, NULL))) {
--- LVM2/lib/format_text/import_vsn1.c 2011/09/06 00:26:43 1.93
+++ LVM2/lib/format_text/import_vsn1.c 2011/10/23 16:02:02 1.94
@@ -328,7 +328,7 @@
!segtype->ops->text_import_area_count(sn_child, &area_count))
return_0;
- if (!(seg = alloc_lv_segment(mem, segtype, lv, start_extent,
+ if (!(seg = alloc_lv_segment(segtype, lv, start_extent,
extent_count, 0, 0, NULL, NULL, area_count,
extent_count, 0, 0, 0, NULL))) {
log_error("Segment allocation failed");
--- LVM2/lib/metadata/lv_alloc.h 2011/09/06 00:26:43 1.30
+++ LVM2/lib/metadata/lv_alloc.h 2011/10/23 16:02:02 1.31
@@ -15,8 +15,7 @@
#ifndef _LVM_LV_ALLOC_H
-struct lv_segment *alloc_lv_segment(struct dm_pool *mem,
- const struct segment_type *segtype,
+struct lv_segment *alloc_lv_segment(const struct segment_type *segtype,
struct logical_volume *lv,
uint32_t le, uint32_t len,
uint64_t status,
--- LVM2/lib/metadata/lv_manip.c 2011/10/22 16:48:59 1.303
+++ LVM2/lib/metadata/lv_manip.c 2011/10/23 16:02:02 1.304
@@ -201,8 +201,7 @@
/*
* All lv_segments get created here.
*/
-struct lv_segment *alloc_lv_segment(struct dm_pool *mem,
- const struct segment_type *segtype,
+struct lv_segment *alloc_lv_segment(const struct segment_type *segtype,
struct logical_volume *lv,
uint32_t le, uint32_t len,
uint64_t status,
@@ -217,6 +216,7 @@
struct lv_segment *pvmove_source_seg)
{
struct lv_segment *seg;
+ struct dm_pool *mem = lv->vg->vgmem;
uint32_t areas_sz = area_count * sizeof(*seg->areas);
if (!segtype) {
@@ -277,7 +277,7 @@
return NULL;
}
- if (!(seg = alloc_lv_segment(lv->vg->cmd->mem, segtype, lv, old_le_count,
+ if (!(seg = alloc_lv_segment(segtype, lv, old_le_count,
lv->le_count - old_le_count, status, 0,
NULL, NULL, 0, lv->le_count - old_le_count,
0, 0, 0, NULL))) {
@@ -954,8 +954,7 @@
area_multiple = _calc_area_multiple(segtype, area_count, 0);
- if (!(seg = alloc_lv_segment(lv->vg->cmd->mem, segtype, lv,
- lv->le_count,
+ if (!(seg = alloc_lv_segment(segtype, lv, lv->le_count,
aa[0].len * area_multiple,
status, stripe_size, NULL, NULL,
area_count,
@@ -2044,9 +2043,9 @@
thin_pool_lv = lvl->lv;
}
- if (!(seg = alloc_lv_segment(lv->vg->cmd->mem, segtype, lv,
- lv->le_count, extents, status, 0,
- NULL, thin_pool_lv, 0, extents, 0, 0, 0, NULL))) {
+ if (!(seg = alloc_lv_segment(segtype, lv, lv->le_count, extents,
+ status, 0, NULL, thin_pool_lv, 0,
+ extents, 0, 0, 0, NULL))) {
log_error("Couldn't allocate new zero segment.");
return 0;
}
@@ -2178,8 +2177,7 @@
return NULL;
}
- if (!(newseg = alloc_lv_segment(seg->lv->vg->cmd->mem,
- get_segtype_from_string(seg->lv->vg->cmd, "mirror"),
+ if (!(newseg = alloc_lv_segment(get_segtype_from_string(seg->lv->vg->cmd, "mirror"),
seg->lv, seg->le, seg->len,
seg->status, seg->stripe_size,
log_lv, NULL,
@@ -2375,8 +2373,8 @@
/*
* First, create our top-level segment for our top-level LV
*/
- if (!(mapseg = alloc_lv_segment(lv->vg->cmd->mem, segtype,
- lv, 0, 0, lv->status, stripe_size, NULL, NULL,
+ if (!(mapseg = alloc_lv_segment(segtype, lv, 0, 0, lv->status,
+ stripe_size, NULL, NULL,
devices, 0, 0, region_size, 0, NULL))) {
log_error("Failed to create mapping segment for %s", lv->name);
return 0;
@@ -3593,8 +3591,7 @@
return_NULL;
/* allocate a new linear segment */
- if (!(mapseg = alloc_lv_segment(cmd->mem, segtype,
- lv_where, 0, layer_lv->le_count,
+ if (!(mapseg = alloc_lv_segment(segtype, lv_where, 0, layer_lv->le_count,
status, 0, NULL, NULL, 1, layer_lv->le_count,
0, 0, 0, NULL)))
return_NULL;
@@ -3636,8 +3633,7 @@
seg->lv->vg->name, seg->lv->name);
/* allocate a new segment */
- if (!(mapseg = alloc_lv_segment(layer_lv->vg->cmd->mem, segtype,
- layer_lv, layer_lv->le_count,
+ if (!(mapseg = alloc_lv_segment(segtype, layer_lv, layer_lv->le_count,
seg->area_len, status, 0,
NULL, NULL, 1, seg->area_len, 0, 0, 0, seg)))
return_0;
--- LVM2/lib/metadata/merge.c 2011/10/20 10:28:41 1.53
+++ LVM2/lib/metadata/merge.c 2011/10/23 16:02:02 1.54
@@ -433,7 +433,7 @@
}
/* Clone the existing segment */
- if (!(split_seg = alloc_lv_segment(lv->vg->vgmem, seg->segtype,
+ if (!(split_seg = alloc_lv_segment(seg->segtype,
seg->lv, seg->le, seg->len,
seg->status, seg->stripe_size,
seg->log_lv, seg->pool_lv,
^ permalink raw reply
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.