On Mon, 26 Nov 2012 14:27:00 +0100 Karel Zak wrote:
> On Fri, Nov 23, 2012 at 11:23:09AM +1100, NeilBrown wrote:
> > This is a bug in util-linux.
> >
> > If 'blkid' doesn't recognise the filesystem, mount reads /etc/filesystems
> > and tries everythi
> not so easy, but I will try.
I'm fairly confident the above patch will fixes it, and in any case it fixes
a real bug. So if you could just run with it and confirm in a week or so
that the problem hasn't recurred, that might have to do.
Thanks,
NeilBrown
signature.asc
Description: PGP signature
Hi Linus,
another md bugfix ... and it isn't even Friday!
Thanks,
NeilBrown
The following changes since commit 884162df2aadd7414bef4935e1a54976fd4e3988:
md/raid10: decrement correct pending counter when writing to replacement.
(2012-11-22 15:12:42 +1100)
are available in th
On Wed, 28 Nov 2012 14:51:59 + Tvrtko Ursulin
wrote:
> On Tuesday 27 November 2012 12:05:28 NeilBrown wrote:
> > On Sat, 24 Nov 2012 10:18:44 +0100 Torsten Kaiser
> >
> > wrote:
> > > After my system got stuck with 3.7.0-rc2 as reported in
> >
On Thu, 31 Jan 2013 15:25:43 +0200 "ivan.khoronzhuk"
wrote:
> On 01/28/2013 08:51 PM, NeilBrown wrote:
> > On Mon, 28 Jan 2013 18:13:14 +0200 "ivan.khoronzhuk"
> >
> > wrote:
> >
> >> On 01/22/2013 07:24 AM, NeilBrown wrote:
> >>
On Tue, 12 Feb 2013 13:03:36 -0800 Kevin Hilman wrote:
> NeilBrown writes:
>
> > On Mon, 21 Jan 2013 13:38:59 +0200 Igor Grinberg
> > wrote:
> >
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>
> >
The following changes since commit 5f243b9b46a22e5790dbbc36f574c2417af49a41:
Merge tag 'arm64-fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64
(2013-01-04 10:41:54 -0800)
are available in the git repository at:
git://neil.brown.name/md/ tags/md-3.8-fixes
fo
On Mon, 28 Jan 2013 18:13:14 +0200 "ivan.khoronzhuk"
wrote:
> On 01/22/2013 07:24 AM, NeilBrown wrote:
> > On Mon, 21 Jan 2013 15:57:18 -0800 Dmitry Torokhov
> > wrote:
> >
> >> Hi Ivan,
> >>
> >> On Mon, Jan 21, 2013 at 03:15:14PM
re processing (EXPERIMENTAL)"
> > depends on MD_RAID456
> > depends on SMP
> > - depends on EXPERIMENTAL
>
> In this case MULTICORE_RAID456 and the related code should go as
> well... now that there are patches to supersede this implementatio
per_group = 0 /* GCC */;
unsigned copies,d;
which is apparently the new way which I believe is due to be imposed on the
kernel immediately after 3.9-rc1
https://lwn.net/Articles/529954/
NeilBrown
signature.asc
Description: PGP signature
-transfer protocol. If you use NFS/VFAT in that
way it works fine. If you try to use it as a general file access protocol,
that is when you hit problems.
The patch series tries to make inode number stable across reboot. I think
this is not worth the effort as you won't make VFAT access more reliable,
you'll just make it fail differently.
The only real answer to more reliable NFS access to VFAT is the NFSv4 concept
of volatile file handles. Unfortunately NFSv4 hasn't yet specified these
with sufficient precision to actually use them.
So if anyone wants to improve VFAT/NFS, I suggest that the first step is to
work with the NFSV4-WG to get an implementable specification. Good luck with
that.
NeilBrown
signature.asc
Description: PGP signature
), bio_clone_kmalloc()
>
> This series looks good to me now. If someone can ack the dm patch, I
> think it's good to go. Jens, what do you think?
>
> Thanks.
>
I'm very happy with them from the perspective of 'md'. Great work!
Acked-by: NeilBrown
for the few patches which touch drivers/md/md.c
NeilBrown
signature.asc
Description: PGP signature
', then sbio->bi_end_io ==
end_sync_read.
So I suspect you want to add
sbio->bi_end_io = end_sync_read;
somewhere after the 'bio_reset()'.
If you happened to also fix that 'if' that I quoted so that it reads:
if (sbio->bi_end_io != end_sync_read)
On Mon, 10 Sep 2012 17:22:24 -0700 Kent Overstreet
wrote:
> Had to shuffle the code around a bit (where bi_rw and bi_end_io were
> set), but shouldn't really be anything tricky here
>
> Signed-off-by: Kent Overstreet
> CC: Jens Axboe
> CC: NeilBrown
> ---
one before abstracting
> out the bio iterator, I think.
Hi Kent,
this looks pretty good to me. I've only really looked closely at the md
bits, but they all seem to make sense (with the minor issues that I reported
separately).
If/when there is another posting I'll try to allo
his ordering was ever explicitly broken.
While don't deliberately re-order bios just for the fun of it, there is no
real effort to keep the bios "in order" (assuming that even means something
in a multi-processor environment). The old barrier code did impose ordering
but thankfully
he line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
applied, thanks.
NeilBrown
signature.asc
Description: PGP signature
> And please forgive and warn me if this patch has came to the wrong
> place...I get the address from get_maintainer.
Sorry, August was a bad month.
Yes, patch looks good. Shall I include it in my tree, do you want to submit
them altogether through some rcu tree?
Either way is fine by me. If you wa
On Tue, 11 Sep 2012 11:28:25 -0700 Kent Overstreet
wrote:
> On Tue, Sep 11, 2012 at 02:59:13PM +1000, NeilBrown wrote:
> > On Mon, 10 Sep 2012 17:22:23 -0700 Kent Overstreet
> > wrote:
> >
> > > I couldn't figure out what sbio->bi_end_io in process_checks
On Tue, 11 Sep 2012 15:20:53 +0200 (CEST) Thomas Gleixner
wrote:
> On Tue, 11 Sep 2012, NeilBrown wrote:
> > On Mon, 10 Sep 2012 12:28:35 +0200 (CEST) Thomas Gleixner
> > wrote:
> > > You might be looking for a different functionality. Can you explain
> > >
gt; > }
>
>
>
> Anyone can review this patch? I think it is a bug and should be fixed.
I agree there is a bug there but I don't think this is the right fix.
If rdev could be NULL there, then it could also be NULL in
md_error(mddev, conf->mir
let me
> > > know.
> > >
> > > --
> > >
> > > From: NeilBrown
> > >
> > > commit 6dafab6b1383e912cd252fa809570b484eb6e0dc upstream.
> > [...]
> > > This is suitable for -stable as out-of-data metadata could lea
On Fri, 28 Sep 2012 09:23:43 -0700 Kent Overstreet
wrote:
> On Mon, Sep 24, 2012 at 02:56:39PM +1000, NeilBrown wrote:
> >
> > Hi Jens,
> > this patch has been sitting in my -next tree for a little while and I was
> > hoping for it to go in for the next merge wi
g" would not
be straight forward (SIGBUS on first step of access should be easy).
I guess that is up to the app writer, but I have never liked anything about
the signal interface and encouraging further use doesn't feel wise.
That's my 2c worth for now. Keep up the good work,
NeilBrown
signature.asc
Description: PGP signature
On Tue, 2 Oct 2012 14:09:23 -0700 Kent Overstreet
wrote:
> On Tue, Oct 02, 2012 at 04:22:01PM +1000, NeilBrown wrote:
> > On Fri, 28 Sep 2012 09:23:43 -0700 Kent Overstreet
> > wrote:
> >
> > > On Mon, Sep 24, 2012 at 02:56:39PM +1000, NeilBrown wrote:
> >
pth' looks a little odd without a 'i_' prefix. It wouldn't
hurt to have a comment noting that it is for directories.
Thanks,
NeilBrown
signature.asc
Description: PGP signature
; - depends on EXPERIMENTAL
> ---help---
> Enable the raid456 module to dispatch per-stripe raid operations to a
> thread pool.
I'm happy to remove the "depends on EXPERIMENTAL".
I'm not so happy to remove the "(EXPERIMENTAL)" tex
ing can be used.
When it is anything else, it will need to use sector_div().
Could you look into this please?
Thanks,
NeilBrown
signature.asc
Description: PGP signature
1/ if regulator_get fails, return an error. This is important
if it failed with EPROBE_DEFER, as the probe needs to be
deferred.
2/ Don't set .set_power until the regulator has been found, or
the deferred probe will not bother calling omap_hsmmc_reg_get().
Signed-off-by: Neil
Hi Felipe,
have you had a chance to look at this problem in omap2430_mbus_set_vbus yet?
Are you the person responsible?
thanks,
NeilBrown
On Mon, 9 Jul 2012 01:32:33 -0700 Tony Lindgren wrote:
> * NeilBrown [120706 15:44]:
> >
> > Hello `./scripts/get_maintainer.pl -f d
the gpio 'can_sleep', then I need a work-queue to effect the change, and
I currently use the 'qos_work' rather than adding another work handler.
As both the qos_work and the gpio work tasks are idempotent and rare, this
seems reasonable. Is it OK? should I make anothe
To avoid racing with suspend, we need to report wakeup events to the
pm subsystem when they happen.
These two patches do this for gpio_keys and twl4030-pwrbutton.
---
NeilBrown (2):
Input: twl4030-pwrbutton: report a wakeup_event on button press.
Input: gpio_keys: report a
() with no delay is
sufficient as suspend will synchronise with all interrupt delivery.
When the user-space visible event is created later
(gpio_keys_gpio_isr), we need to bracket the event with
pm_stay_awake() and pm_relax().
Signed-off-by: NeilBrown
---
drivers/input/keyboard/gpio_keys.c
As the power button causes a wake from suspend, we need to register
the event with the pm sustem to avoid racing with suspend.
As the input event is reported in the interrupt handler, as simple
pm_wakeup_event() is sufficient.
Signed-off-by: NeilBrown
---
drivers/input/misc/twl4030
pm_stay_awake/pm_relax
pair preventing suspend from the interrupt until the thread completes
its work.
Signed-off-by: NeilBrown
--
This makes the pm_wakeup_event() call in cmos_interrupt unnecessary as it
provides suspend protection for all RTCs that use rtc_update_irq.
I think the pm_stay_awake
On Mon, 30 Jul 2012 10:50:36 +0530 Rajendra Nayak wrote:
> On Monday 30 July 2012 05:42 AM, NeilBrown wrote:
> >
> > 1/ if regulator_get fails, return an error. This is important
> > if it failed with EPROBE_DEFER, as the probe needs to be
> > deferred.
>
On Mon, 30 Jul 2012 12:07:09 +0530 Rajendra Nayak wrote:
> On Monday 30 July 2012 11:54 AM, NeilBrown wrote:
> > On Mon, 30 Jul 2012 10:50:36 +0530 Rajendra Nayak wrote:
> >
> >> On Monday 30 July 2012 05:42 AM, NeilBrown wrote:
> >>>
> >>> 1/ i
sume
that the GPIO doesn't exist.
I would suggest the following. Reasonable?
NeilBrown
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index de0213c..259233b 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1186,13 +1186,14 @@ int gpio_request(unsigned gpio, con
making sure it runs with that group-id.
(ignoring remainder of email as it seems to be more emotional than factual).
NeilBrown
>
> I would have expected, that if anything you would have improved the
> support for pid's and especially for desktop firewalls.
>
> But it see
On Mon, 30 Jul 2012 23:01:49 +0200 "Rafael J. Wysocki" wrote:
> On Monday, July 30, 2012, NeilBrown wrote:
> >
> > If an RTC alarm fires just as suspend is happening, it is possible for
> > suspend to complete and the alarm to be missed.
> >
> > To
anks.
Applied.
Should it go in '-stable' kernels too?
NeilBrown
> ---
> arch/x86/include/asm/xor_avx.h |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/include/asm/xor_avx.h b/arch/x86/include/asm/xor_avx.h
> index 2510d35..
On Mon, 30 Jul 2012 14:36:15 +0100 Mark Brown
wrote:
> On Mon, Jul 30, 2012 at 04:57:33PM +1000, NeilBrown wrote:
>
> > it means that if !gpio_is_valid(gpio), the error returned is EPROBE_DEFER
> > which isn't right (an invalid gpio number will never become valid).
>
7; content, and calls svc_delete_xprt which then calls
svc_deferred_dequeue and that takes ->xpt_lock - does that mean that all
lock/unlock of ->xpt_lock needs to be changed to use the _bh variants?
NeilBrown
>
> And in the past I haven't been good at testing for problems
> he
or would you rather take
it though your 'block' tree?
Thanks,
NeilBrown
From: Shaohua Li
Date: Thu, 20 Sep 2012 09:36:03 +1000
Subject: [PATCH] block: makes bio_split support bio without data
discard bio hasn't data attached. We hit a BUG_ON with such bio. This makes
bio_split
ut total
context.
Is any locking done when writing to the file, or will there only ever be one
writer?
NeilBrown
signature.asc
Description: PGP signature
On Mon, 24 Sep 2012 17:35:34 +0900 Namhyung Kim wrote:
> Hi,
>
> On Mon, 24 Sep 2012 14:56:39 +1000, NeilBrown wrote:
> > Hi Jens,
> > this patch has been sitting in my -next tree for a little while and I was
> > hoping for it to go in for the next merge wi
Hi Jens,
is there any chance this can be in the next merge window? I'm
adding block tracing to md and found I need another export.
Thanks,
NeilBrown
This allows stacked devices (like md/raid5) to provide blktrace
tracing, including unplug events.
Reported-by: Fengguang Wu
Signed-o
resumably caused by commit 14817e9a6dab ("md/raid5: add blktrace calls").
>
> CONFIG_MD_RAID456=m
>
> I have used the md tree from next-20120924 for today.
Thanks.
I requires the following which I have already sent to Jens Axboe.
I might pull my
] filp_close+0x5f/0x90
[634155.004743] [] sys_close+0x97/0x100
[634155.004754] [] system_call_fastpath+0x16/0x1b
[634155.004767] [<7f2a73a0d110>] 0x7f2a73a0d10f
Is this suitable for -stable? It seems like it is just a harmless warning.
NeilBrown
Subject: NFS: avoid warning from nfs_drop
On Mon, 24 Sep 2012 15:34:45 -0700 Kent Overstreet
wrote:
> Signed-off-by: Kent Overstreet
> CC: Jens Axboe
> CC: NeilBrown
> ---
> drivers/md/md.c | 19 +--
> 1 file changed, 5 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/md/md.c b/drivers
On Tue, 25 Sep 2012 14:50:34 +0200 Jens Axboe wrote:
> On 09/25/2012 01:57 AM, NeilBrown wrote:
> >
> > Hi Jens,
> > is there any chance this can be in the next merge window? I'm
> > adding block tracing to md and found I need another export.
>
> No p
than Brassow (1):
MD RAID10: Fix oops when creating RAID10 arrays via dm-raid.c
NeilBrown (2):
Merge tag 'disintegrate-raid-20121009' of
git://git.infradead.org/users/dhowells/linux-headers into for-next
md/raid1: Fix assembling of arrays containing Replacemen
On Thu, 22 Aug 2013 17:09:11 +0200 "H. Peter Anvin" wrote:
> Acked-by: H. Peter Anvin
Applied with the Ack - thanks.
NeilBrown
>
> Max Filippov wrote:
> >-e is a non-standard echo option, echo output is
> >implementation-dependent when it is used. Re
lear_bit(STRIPE_BIT_DELAY, &sh->state);
+ if (conf->worker_cnt_per_group == 0) {
+ list_add_tail(&sh->lru, &conf->handle_list);
+ } else {
+ raid5_wakeup_stripe_thread(sh);
+ return;
+ }
}
md_wakeup_thread(conf->mddev->thread);
??
NeilBrown
signature.asc
Description: PGP signature
> Seems file system related (hdd led is on).
>
> My filesystems are ext4 over raid0 so add some cc
Appears to be "dm" raid0 rather than "md" raid0 - so not my area.
May help to include dm-de...@redhat.com, and maybe include a description of
the dm configuration.
On Mon, 9 Sep 2013 16:49:23 -0700 Linus Torvalds
wrote:
> On Mon, Sep 9, 2013 at 3:42 PM, Kevin Hilman wrote:
> >
> > The main thing of note (or of potential annoyance factor) here is the
> > handful of conflicts in PULL 2/3 coming from platform changes
> > conflicting with driver changes going
NeilBrown (6):
md: don't call md_allow_write in get_bitmap_file.
md: fix safe_mode buglet.
md: Don't test all of mddev->flags at once.
md: avoid deadlock when dirty buffers during md_stop.
md/raid5: use seqcount to protect access to shape in make_request.
uld
have been flushed and there should be no pending writes so nothing to wait
for an unacked bad block.
If you have seen this happen, any details you can give about the exact state
of the RAID5 when it deadlocked, the stack trace of any relevant processes
etc would be very helpful.
Thanks,
NeilBrow
->flags)
> + && !test_bit(R5_ReadNoMerge, &sh->dev[i].flags))
> + retry = 1;
> if (retry)
> if (test_bit(R5_ReadNoMerge, &sh->dev[i].flags)) {
> set_bit(R5_ReadError, &sh->dev[i].flags);
Applied, thanks.
NeilBrown
signature.asc
Description: PGP signature
27;t think it should be needed (I was wrong there). I also don't like
the patch. It isn't at all clear to me that it will do the right thing.
There is a reason that we block until the bad block lists has been updated,
and to just not block because it is inconvenient just doesn'
On Mon, 3 Sep 2012 22:59:06 -0700 "Shilimkar, Santosh"
wrote:
> On Sun, Aug 26, 2012 at 6:29 PM, Shilimkar, Santosh
> wrote:
> > On Sun, Aug 26, 2012 at 3:53 PM, NeilBrown wrote:
> >>
> >> On Sun, 26 Aug 2012 09:47:50 +0530 "Shilimkar, Santosh"
On Thu, 6 Sep 2012 11:18:09 +0530 "Shilimkar, Santosh"
wrote:
> On Thu, Sep 6, 2012 at 8:35 AM, NeilBrown wrote:
> > On Mon, 3 Sep 2012 22:59:06 -0700 "Shilimkar, Santosh"
> > wrote:
> >> After thinking bit more on this, the problem seems to be c
On Thu, 6 Sep 2012 12:57:46 +0530 "Shilimkar, Santosh"
wrote:
> On Thu, Sep 6, 2012 at 12:32 PM, NeilBrown wrote:
> > On Thu, 6 Sep 2012 11:18:09 +0530 "Shilimkar, Santosh"
> > wrote:
> >
> >> On Thu, Sep 6, 2012 at 8:35 AM, NeilBrown wrote:
&
gt; mdadm --create /dev/md0 --level=raid5 --raid-devices=7
> --spare-devices=1 /dev/sd[a-h]3 --assume-clean -z 10485760 -f -R
--assume-clean is not safe with RAID5 unless the array actually is clean.
It is safe with RAID1 and RAID6 due to details of the specific implementation.
So I suspect that
On Fri, 7 Sep 2012 14:30:56 +0800 clplayer wrote:
> > --assume-clean is not safe with RAID5 unless the array actually is clean.
> > It is safe with RAID1 and RAID6 due to details of the specific
> > implementation.
> > So I suspect that is the cause of the corru
things will. though that might depend on your expectations.
NeilBrown
signature.asc
Description: PGP signature
On Fri, 07 Sep 2012 14:37:16 -0700 Kevin Hilman
wrote:
> Hi Neil,
>
> NeilBrown writes:
>
> > On Thu, 6 Sep 2012 11:18:09 +0530 "Shilimkar, Santosh"
> > wrote:
> >
> >> On Thu, Sep 6, 2012 at 8:35 AM, NeilBrown wrote:
> >&g
he interaction with runtime
PM presumably doesn't affect it.
The later ... I don't think will compile. It is only used by pm8921-core.c,
and that requires #include , which doesn't exist in
mainline.
Is anyone able to give a definitive answer on this? Should
IRQCHIP_MASK_ON_SUSPEND be removed?
Thanks,
NeilBrown
signature.asc
Description: PGP signature
On Thu, 6 Sep 2012 16:26:06 +0300 Felipe Balbi wrote:
> Hi,
>
> On Thu, Sep 06, 2012 at 05:02:45PM +1000, NeilBrown wrote:
> > On Thu, 6 Sep 2012 11:18:09 +0530 "Shilimkar, Santosh"
> > wrote:
> >
> > > On Thu, Sep 6, 2012 at 8:35 AM, NeilBro
On Mon, 10 Sep 2012 12:28:35 +0200 (CEST) Thomas Gleixner
wrote:
> On Mon, 10 Sep 2012, NeilBrown wrote:
> >
> > The IRQCHIP_MASK_ON_SUSPEND flag seems to be hard to use correctly, so
> > either
> > I'm understanding it wrongly, or it could be made easier to
s only ever tested for whether it is zero or not.
For that last 'return', nr_shrink will only be zero if the original nr_shrink
is exactly one more than the number of items in nat_entries. If nr_shrink is
more than that, the function will return "-1".
I suspect that is not w
ta_sum_blocks (==3) to the cp_pack_total_block_count (and
later to the start block).
Is that really what you want to do? Leave 3 empty blocks?
I would suggest changing npages_for_summary_flush to return 0 if the number
of blocks needed would be more than three, and set CP_COMPACT_SUM_FLAG only
when data_sum_blocks > 0.
I don't know if you would need to make a corresponding change to the recovery
code, I haven't fully examined that yet.
Regards,
NeilBrown
signature.asc
Description: PGP signature
is_sync, and then write one block with is_sync set.
The expectation seems to be that when that last block is written and so calls
complete(p->wait);
then all the blocks have been written.
I don't think that is a valid assumption in general. Various things can
re-order blocks. Back when we had BIO_BARRIER, a barrier request would force
that semantic, but that was found to be too problematic.
You use WRITE_FLUSH_FUA for the ->is_sync write, but that is not necessarily
enough to keep everything in order. You really should wait for all the
blocks to report that they are complete. Probably have an atomic counter of
pending blocks and each one does
if (atomic_dec_and_test(&counter))
complete(->wait);
Regards,
NeilBrown
signature.asc
Description: PGP signature
then
do it again for 3 other locks (And there is another loop which does it for
the other 3 cursegs).
If you do need some locking here, I think you need to take the lock once per
loop iteration so the 3 values are consistent, not once for each value.
Regards,
NeilBrown
> +
> +static inline
me comments in there pointing out that having a function which does
nothing is very different from not having any function at all?
Thanks,
NeilBrown
>
> ---
> From: Rafael J. Wysocki
> Subject: PM / SDIO: Use empty system suspend/resume callbacks at the bus level
>
> Neil Brown
ycle count for BQ27425, and now does it twice for other chips.
Cc: Saranya Gopal
Signed-off-by: NeilBrown
diff --git a/drivers/power/bq27x00_battery.c b/drivers/power/bq27x00_battery.c
index e2659f1..51d4017 100644
--- a/drivers/power/bq27x00_battery.c
+++ b/drivers/power/bq27x00_battery.c
@@ -44
On Sun, 2 Dec 2012 13:10:33 +0100 Torsten Kaiser
wrote:
> On Tue, Nov 27, 2012 at 8:08 AM, Torsten Kaiser
> wrote:
> > On Tue, Nov 27, 2012 at 2:05 AM, NeilBrown wrote:
> >> Can you test to see if this fixes it?
> >
> > Patch applied, I will try to get i
On Sun, 02 Dec 2012 14:48:50 +0100 "Rafael J. Wysocki" wrote:
> On Sunday, December 02, 2012 07:46:25 PM NeilBrown wrote:
> > On Mon, 26 Mar 2012 00:29:24 +0200 "Rafael J. Wysocki" wrote:
> >
> >
> > > Thanks for the confirmation.
> >
ch didn't get merged. Neil?
>
> Honza
Don't know. Maybe I slipped under Trond's radar some how.
Trond: can you comment on and hopefully apply this patch?
Subject of original email was "WARNING: at fs/inode.c
lides.
> > Thanks,
> >
>
> I had hope that slides will have more detailed description. Maybe it is
> good for Linux Forum. But do you plan to publish more detailed
> description of F2FS architecture, advantages/disadvantages in the form
> of article? It makes sense from my
need to monitor the number of
requests going to the underlying devices - like md does - or monitor the
number of requests coming in to the dm-raid1 target - which is probably
easier with dm.
i.e. only impose the rate limit if there have been any requests for the
dm-raid1 target in the last 'RES
rticular the paragraph containing:
A member of the audience asked why the kernel couldn't just do away with
the existing system and use the HWRNG directly.
Does that answer your question in any way?
NeilBrown
>
> --
> To unsubscribe from this list: send the line "unsubscr
This patch is based on an earlier patch by Grant Erickson
which provided pwm devices using the 'legacy' interface.
This driver instead uses the new framework interface.
Cc: Grant Erickson
Signed-off-by: NeilBrown
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index ed8172
d,
so just call balance_dirty_pages_ratelimited() directly.
Signed-off-by: NeilBrown
diff --git a/drivers/mtd/devices/block2mtd.c b/drivers/mtd/devices/block2mtd.c
index 681e2ee..2c3e8e7 100644
--- a/drivers/mtd/devices/block2mtd.c
+++ b/drivers/mtd/devices/block2mtd.c
@@ -62,6 +62,7 @@ stati
On Wed, 12 Dec 2012 09:58:16 +0100 Ondřej Bílka wrote:
> On Wed, Dec 12, 2012 at 01:08:26PM +1100, NeilBrown wrote:
> > On Wed, 12 Dec 2012 03:03:54 +0100 Ondřej Bílka wrote:
> >
> > > I consider to speed-up /dev/urandom on recent intel processors by
> >
uess I should be able to assume that - surely the patches would not be
posted if it were not true... But I like to avoid assuming when I can.
Thanks,
NeilBrown
>
> Paul Menzel wrote:
>
> >Dear Jim,
> >
> >
> >Am Donnerstag, den 08.11.2012, 13:47 -0800 schrieb Jim
Hi Linus,
Not much for md this time round.
Thanks,
NeilBrown
The following changes since commit 874807a83139abc094f939e93623c5623573d543:
md/raid1{,0}: fix deadlock in bitmap_unplug. (2012-11-27 12:14:40 +1100)
are available in the git repository at:
git://neil.brown.name/md/ tags/md
tch up.
>
> You'll notice that this code is very similar to the SSSE3-optimized
> recovery routines I wrote earlier. This implementation extends that same
> algorithm from 128-bit registers to 256-bit registers.
I might notice that if I actually looked, but it all starts swimming before
my eyes when I try :-)
If both you and hpa like it, then that is good enough for me.
Thanks,
NeilBrown
>
> Thanks.
>
signature.asc
Description: PGP signature
Hi Dan,
could you comment on this please? Would it make sense to arrange for errors
to propagate up? Or should we arrange to do a software-fallback in the dma
engine is a problem? What sort of things can cause error here anyway?
Thanks,
NeilBrown
On Thu, 08 Nov 2012 12:20:55 +0100
On Mon, 19 Nov 2012 05:22:25 + Dan Williams wrote:
>
>
> On 11/18/12 5:06 PM, "NeilBrown" wrote:
>
> >
> >Hi Dan,
> > could you comment on this please? Would it make sense to arrange for
> >errors
> > to propagate up? Or shoul
On Mon, 19 Nov 2012 18:23:57 -0800 Dan Williams wrote:
> On Tue, 2012-11-20 at 09:18 +1100, NeilBrown wrote:
> > On Mon, 19 Nov 2012 05:22:25 + Dan Williams wrote:
> >
> > >
> > >
> > > On 11/18/12 5:06 PM, "NeilBrown" wrote:
> &
ts ignored and data offset still have 8192).
I'll try to make sure that works correctly for the next release.
Thanks for the report.
NeilBrown
>
>
> Thanks!
> --
> Vasiliy Tolstov,
> e-mail: v.tols...@selfip.ru
> jabber: v...@selfip.ru
> --
> To unsubscribe from thi
; left the pull running, and now it got through.
Yes, I had an email from the hosting provider over night saying there was an
incident with network slowness. Your "git pull" must have hit that target :-)
NeilBrown
signature.asc
Description: PGP signature
; >
> > > The patch that converted raid5 to use bio_reset() forgot to initialize
> > > bi_vcnt.
> > >
> > > Signed-off-by: Kent Overstreet
> > > Cc: NeilBrown
> > > Cc: Jens Axboe
> > > Cc: linux-r...@vger.k
On Tue, 11 Jun 2013 21:22:48 -0700 John Stultz wrote:
> From: Minchan Kim
>
> This patch adds new system call sys_vrange.
>
> NAME
> vrange - Mark or unmark range of memory as volatile
>
> SYNOPSIS
> int vrange(unsigned_long start, size_t length, int mode,
>
Mostly just bug fixes.
A couple marked for -stable including one recent bug which causes a RAID10
reshape to complete without moving any data :-(
A couple more bugfixes (at least) to come, but haven't confirmed the right
solution yet.
NeilBrown
The following changes since c
of CONFIG_MULTICORE_RAID456 linger
Several tagged for -stable
Jonathan Brassow (2):
MD RAID5: Avoid accessing gendisk or queue structs when not available
MD: Prevent sysfs operations on uninitialized kobjects
NeilBrown (2):
On Mon, 19 Aug 2013 22:26:32 -0400 Dave Jones wrote:
> Setting a variable to itself probably wasn't the intention here.
Probably not, no.
Applied, thanks.
NeilBrown
>
> Signed-off-by: Dave Jones
>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 9f13e13.
plete a survey which, among other things, asks about
people fear/anxiety response to various situations (it is a fairly standard
instrument I think[1]). Last few times he checked, the situation with the
highest average score was "One person bullying another". Really, it isn'
re rather attached.
Being "polite" without being "nice" is quite possible. It even has a name:
Diplomacy.
NeilBrown
signature.asc
Description: PGP signature
1 - 100 of 2514 matches
Mail list logo
