Include typo fix; white space shooting; mistake correction.
Signed-off-by: Cao jin
---
Documentation/PCI/pci-error-recovery.txt | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/PCI/pci-error-recovery.txt
b/Documentation/PCI/pci-error-recovery.txt
in
Em Wed, 7 Dec 2016 12:39:24 -0700
Jonathan Corbet escreveu:
> On Wed, 7 Dec 2016 16:42:58 +0100
> Daniel Vetter wrote:
>
> > We already had a super-short blurb, but worth extending it I think:
> > We're still pretty far away from anything like a consensus, but
> > there's clearly a lot of peop
Hi Niklas
On 12/07/2016 03:20 PM, Niklas Cassel wrote:
From: Niklas Cassel
GMAC and newer supports independent programmable burst lengths for
DMA tx/rx. Add new optional devicetree properties representing this.
To be backwards compatible, snps,pbl will still be valid, but
snps,txpbl/snps,rxpb
Hi Niklas,
On 12/07/2016 03:20 PM, Niklas Cassel wrote:
From: Niklas Cassel
The driver currently always sets the PBLx8/PBLx4 bit, which means that
the pbl values configured via the pbl/txpbl/rxpbl DT properties are
always multiplied by 8/4 in the hardware.
In order to allow the DT to configur
On Thu, 2016-11-24 at 11:56 -0800, Guenter Roeck wrote:
> On 11/15/2016 07:21 PM, Hui Chun Ong wrote:
> >
> > Add support for the watchdog timer on PXI Embedded Controller.
> >
> > Signed-off-by: Hui Chun Ong
> > ---
> > v1: Remove non-standard attributes.
> > Change from acpi_driver to plat
On Wed, Dec 07, 2016 at 09:40:13PM +0100, Arnd Bergmann wrote:
> On Wednesday, December 7, 2016 4:59:13 PM CET Catalin Marinas wrote:
> > On Tue, Dec 06, 2016 at 11:55:08AM +0530, Yury Norov wrote:
> > > On Mon, Dec 05, 2016 at 04:34:23PM +, Catalin Marinas wrote:
> > > > On Fri, Oct 21, 2016 a
Hi,
In subject: s/smmac/stmmac/
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@v
On Thu, 8 Dec 2016 16:16:14 +0800
Cao jin wrote:
> The platform resets the link, and then calls the link_reset() callback
> on all affected device drivers. This is a PCI-Express specific state
> -and is done whenever a non-fatal error has been detected that can be
> +and is done whenever a fat
On 12/08/2016 10:05 PM, Jonathan Corbet wrote:
> On Thu, 8 Dec 2016 16:16:14 +0800
> Cao jin wrote:
>
>> The platform resets the link, and then calls the link_reset() callback
>> on all affected device drivers. This is a PCI-Express specific state
>> -and is done whenever a non-fatal error h
On 12/08/2016 01:19 AM, Hui Chun Ong wrote:
On Thu, 2016-11-24 at 11:56 -0800, Guenter Roeck wrote:
On 11/15/2016 07:21 PM, Hui Chun Ong wrote:
Add support for the watchdog timer on PXI Embedded Controller.
Signed-off-by: Hui Chun Ong
---
v1: Remove non-standard attributes.
Change from a
From: Alexandre Torgue
Date: Thu, 8 Dec 2016 11:42:56 +0100
> Thanks for this patch, you can add my Acked-by.
Please simply state:
Acked-by: Alexandre Torgue
in your reply and it will automatically appear when the patch is
applied. You don't have to ask the patch submitter or the person who
From: Niklas Cassel
Date: Wed, 7 Dec 2016 15:20:02 +0100
> Make DMA programmable burst length more configurable in the stmmac driver.
>
> This is done by adding support for independent pbl for tx/rx through DT.
> More fine grained tuning of pbl is possible thanks to a DT property saying
> that w
is the case for filesystem drivers.
These patches are available on my linux-next git-tree on my branch
20161208-kmod-test-driver-try2 [0], which is based on linux-next tag
next-20161208. Patches are also available based on v4.9-rc8 [1] for
those looking for a bit more stable tree given x86_64 on linux-n
This adds a new stress test driver for kmod: the kernel module loader.
The new stress test driver, test_kmod, is only enabled as a module right
now. It should be possible to load this as built-in and load tests early
(refer to the force_init_test module parameter), however since a lot of
test can g
While looking for early possible module loading failures I was
able to reproduce a memory leak possible with kmemleak. There
are a few rare ways to trigger a failure:
o we've run into a failure while processing kernel parameters
(parse_args() returns an error)
o mod_sysfs_setup() fails
o
kmod_concurrent is used as an atomic counter for enabling
the allowed limit of modprobe calls, provide wrappers for it
to enable this to be expanded on more easily. This will be done
later.
Signed-off-by: Luis R. Rodriguez
---
kernel/kmod.c | 27 +--
1 file changed, 21 in
We currently statically limit the number of modprobe threads which
we allow to run concurrently to 50. As per Keith Owens, this was a
completely arbitrary value, and it was set in the 2.3.38 days [0]
over 16 years ago in year 2000.
Although we haven't yet hit our lower limits, experimentation [1]
Running out of our modprobe limit is not a memory limit but
a system specific established limitation set to avoid a possible
recursive issue with modprobe. This gives userspace a better idea
of what happened if we can't load a module, it could use this to
wait and try again.
Signed-off-by: Luis R.
Only decrement *iff* we're possitive. Warn if we've hit
a situation where the counter is already 0 after we're done
with a modprobe call, this would tell us we have an unaccounted
counter access -- this in theory should not be possible as
only one routine controls the counter, however preemption is
kmod has an optimization in place whereby if a some kernel code
uses request_module() on a module already loaded we never bother
userspace as the module already is loaded. This is not true for
get_fs_type() though as it uses aliases.
Additionally kmod <= v19 was broken -- it returns 0 to modprobe
Commit e7d316a02f6838 ("sysctl: handle error writing UINT_MAX to u32 fields")
added proc_douintvec() to start help adding support for unsigned int,
this however was only half the work needed, all these issues are present
with the current implementation:
o Printing the values shows a negative val
This adds helpers for getting access to the kmod count and limit from
userspace. While at it, this also lets userspace fine tune the kmod
limit after boot, it uses the shiny new proc_douintvec_minmax().
These knobs should help userspace more gracefully and deterministically
handle module loading.
Just use the simplified rate limit printk when the max modprobe
limit is reached, while at it throw out a bone should the error
be triggered.
Signed-off-by: Luis R. Rodriguez
---
kernel/kmod.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/kernel/kmod.c b/kernel/k
On Thu, Dec 8, 2016 at 10:47 AM, Luis R. Rodriguez wrote:
> This adds a new stress test driver for kmod: the kernel module loader.
> The new stress test driver, test_kmod, is only enabled as a module right
> now. It should be possible to load this as built-in and load tests early
> (refer to the f
On Thu, Dec 8, 2016 at 11:48 AM, Luis R. Rodriguez wrote:
> We currently statically limit the number of modprobe threads which
> we allow to run concurrently to 50. As per Keith Owens, this was a
> completely arbitrary value, and it was set in the 2.3.38 days [0]
> over 16 years ago in year 2000.
On Thu, Dec 8, 2016 at 11:48 AM, Luis R. Rodriguez wrote:
> kmod_concurrent is used as an atomic counter for enabling
> the allowed limit of modprobe calls, provide wrappers for it
> to enable this to be expanded on more easily. This will be done
> later.
>
> Signed-off-by: Luis R. Rodriguez
> --
On Thu, Dec 8, 2016 at 11:48 AM, Luis R. Rodriguez wrote:
> While looking for early possible module loading failures I was
> able to reproduce a memory leak possible with kmemleak. There
> are a few rare ways to trigger a failure:
>
> o we've run into a failure while processing kernel parameters
On Thu, Dec 08, 2016 at 12:28:07PM -0800, Kees Cook wrote:
> On Thu, Dec 8, 2016 at 11:48 AM, Luis R. Rodriguez wrote:
> > diff --git a/kernel/kmod.c b/kernel/kmod.c
> > index 0277d1216f80..cb6f7ca7b8a5 100644
> > --- a/kernel/kmod.c
> > +++ b/kernel/kmod.c
> > @@ -44,6 +44,9 @@
> > @@ -186,6 +174
On Thu, Dec 08, 2016 at 12:29:42PM -0800, Kees Cook wrote:
> On Thu, Dec 8, 2016 at 11:48 AM, Luis R. Rodriguez wrote:
> > kmod_concurrent is used as an atomic counter for enabling
> > the allowed limit of modprobe calls, provide wrappers for it
> > to enable this to be expanded on more easily. Th
On Thu, Dec 8, 2016 at 2:30 PM, Kees Cook wrote:
> On Thu, Dec 8, 2016 at 11:48 AM, Luis R. Rodriguez wrote:
>> While looking for early possible module loading failures I was
>> able to reproduce a memory leak possible with kmemleak. There
>> are a few rare ways to trigger a failure:
>>
>> o we
On Thu, Dec 8, 2016 at 1:10 PM, Luis R. Rodriguez wrote:
> On Thu, Dec 8, 2016 at 2:30 PM, Kees Cook wrote:
>> On Thu, Dec 8, 2016 at 11:48 AM, Luis R. Rodriguez wrote:
>>> While looking for early possible module loading failures I was
>>> able to reproduce a memory leak possible with kmemleak.
On Thu, Dec 8, 2016 at 10:10 AM, Mauro Carvalho Chehab
wrote:
> Em Wed, 7 Dec 2016 12:39:24 -0700
> Jonathan Corbet escreveu:
>
>> On Wed, 7 Dec 2016 16:42:58 +0100
>> Daniel Vetter wrote:
>>
>> > We already had a super-short blurb, but worth extending it I think:
>> > We're still pretty far aw
On Thu, 2016-12-08 at 06:15 -0800, Guenter Roeck wrote:
> On 12/08/2016 01:19 AM, Hui Chun Ong wrote:
> >
> > On Thu, 2016-11-24 at 11:56 -0800, Guenter Roeck wrote:
> > >
> > > On 11/15/2016 07:21 PM, Hui Chun Ong wrote:
> > > >
> > > >
> > > > Add support for the watchdog timer on PXI Embedde
On 12/08/2016 08:07 PM, Hui Chun Ong wrote:
On Thu, 2016-12-08 at 06:15 -0800, Guenter Roeck wrote:
On 12/08/2016 01:19 AM, Hui Chun Ong wrote:
On Thu, 2016-11-24 at 11:56 -0800, Guenter Roeck wrote:
On 11/15/2016 07:21 PM, Hui Chun Ong wrote:
Add support for the watchdog timer on PXI Emb
I suppose I'm confused, but I recall that link resets are non-fatal.
Fatal errors typically require that the the pci adapter be completely
reset, any adapter firmware to be reloaded from scratch, the device
driver has to kill all device state and start from scratch. Its huge.
If the fatal error is
On Fri, Dec 9, 2016 at 2:37 PM, Cao jin wrote:
>
>
> On 12/09/2016 02:24 PM, Linas Vepstas wrote:
>> I suppose I'm confused, but I recall that link resets are non-fatal.
>> Fatal errors typically require that the the pci adapter be completely
>> reset, any adapter firmware to be reloaded from scra
On 09/12/16 17:24, Linas Vepstas wrote:
I suppose I'm confused, but I recall that link resets are non-fatal.
Fatal errors typically require that the the pci adapter be completely
reset, any adapter firmware to be reloaded from scratch, the device
driver has to kill all device state and start from
On 12/09/2016 02:24 PM, Linas Vepstas wrote:
> I suppose I'm confused, but I recall that link resets are non-fatal.
> Fatal errors typically require that the the pci adapter be completely
> reset, any adapter firmware to be reloaded from scratch, the device
> driver has to kill all device state a
On 12/09/2016 02:44 PM, Linas Vepstas wrote:
> On Fri, Dec 9, 2016 at 2:37 PM, Cao jin wrote:
>>
>>
>> On 12/09/2016 02:24 PM, Linas Vepstas wrote:
>>> I suppose I'm confused, but I recall that link resets are non-fatal.
>>> Fatal errors typically require that the the pci adapter be completely
>
39 matches
Mail list logo
