Kernel: 2.4.2 - latest (2.4.3-ac12)
Platform: x86 on mangled Slack7.1
Hardware: MSI 694D Pro-AR
( http://www.msicomputer.com/products/detail.asp?ProductID=150 )
Problem: USB devices timeout on address assignment. Course thats with the
non JE driver, with the JE driver the bus doesnt even say tha
> On Mon, Apr 23, 2001, josh <[EMAIL PROTECTED]> wrote:
> > Kernel: 2.4.2 - latest (2.4.3-ac12)
> > Platform: x86 on mangled Slack7.1
> > Hardware: MSI 694D Pro-AR
> > ( http://www.msicomputer.com/products/detail.asp?ProductID=150 )
> >
> > Probl
Kernel Version: 2.4.0-test11 - 2.4.0-prerelease
Platform: ix86 (PIII)
Problem Hardware: Kodac DC280, firmware 1.01
Ever since test10 or after, removing my dc280 from the usb
bus causes khubd to crash. I have tried both UHCI drivers
and they produce the same effect.
dmesg, syslog, messages, an
I have a tyan s2510 with a single pIII 800Mhz cpu and 1GB of RAM.
I have been having problems with this system from the get go and
cant seem to narrow down what the problem is. I have tried running
2.4.6, but the system usually doesnt last more than a day. With
2.4.2 i get a variety of kernel
On Fri, 6 Jul 2001, Alan Cox wrote:
> > gcc never gets all the way through a make... it will die with a
> > sig11, misc asm errors, or random crap.
>
> If its doing that at random then suspect hardaware
Thats what I thought at first, but after going through three different
brands of memory and
Kernel: 2.4.4
Well, for all those people getting "audio drain" messages
when trying to play audio with your via82cxxx driver try
passing the "noapic" option to your kernel on bootup to
see if it works.
I did manage to get mine to work, but only with xmms. When I
try to use other programs, li
find the increase in data/bss and thus overall size in 4.9 concerning.
Any idea what that comes from?
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/
CONFIG_NET
or similar. We're talking about the userspace interfaces. If you
aren't running any userspace bits that open /dev/*random or that call
getrandom, forcing the existence of those devices will not magically
make the system more secure. Not all userspaces actually need
randomnes
gt; Would this make sense? It could look like:
>
> int epoll_mod_and_pwait(int epfd,
> struct epoll_event *events, int maxevents,
> struct epoll_command *commands, int ncommands,
> const sigset_t *sigmask);
That's a complicated syscall. (And it also doesn't have
7;d be entirely in favor of consolidating many of these
"miscellaneous character device" options into a couple of Kconfig
options. It doesn't seem critical to *individually* control each of
these files in /dev.
Personally, I'm hoping that we eventually end up with a disableable
CONF
SIGNAL) && (clone_flags && CLONE_AUTOREAP))
> return -EINVAL;
>
> so that we still can change this behaviour later.
I'm fine with that, as it would handle the particular use case we care
about.
However, the reset-signal-on-reparent thing might still mak
e new thing". So, for instance, if you want to
receive SIGSTOP/SIGCONT messages for child processes through this
descriptor, we could add a flag for that.
- Josh Triplett
--
To unsubscribe from this list: send the 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/
On Thu, May 28, 2015 at 04:35:27PM -0400, Dan Streetman wrote:
> Add list_last_or_null_rcu(), to simplify getting the last entry from a
> rcu-protected list. The standard list_last_entry() can't be used as it
> is not rcu-protected; the list may be modified concurrently. And the
> ->prev pointer
it inline, let me send
> > an updated patch.
>
> ha, as soon as i sent that email, i realized it can't be an inline
> function, because the return value is (type *), not a predefined
> value. Of course it could return void*, but unless there's a benefit
>
the same or similar
functions to another module. (This would help catch mistakes, not just
intentional malice.)
- Josh Triplett
On Fri, Jul 31, 2020 at 05:00:12PM +0200, Arnd Bergmann wrote:
> The majority of the code in the kernel deals with hardware that was made
> a long time ago, and we are regularly discussing which of those bits are
> still needed. In some cases (e.g. 20+ year old RISC workstation support),
> there ar
On Mon, Feb 24, 2014 at 03:38:16PM -0500, Tom Rini wrote:
> While there are valid reasons to use __packed, often the answer is that
> you should be doing something else here instead.
>
> Cc: Andrew Morton
> Cc: Joe Perches
> Cc: Josh Triplett
> Signed-off-by: Tom R
g in cpufreq.c:
> > drivers/cpufreq/cpufreq.c:355:9: warning: no previous prototype for
> > ‘show_boost’ [-Wmissing-prototypes]
> >
> > Signed-off-by: Rashika Kheria
>
> v2 has been Reviewed-by: Josh already, right?
Feel free to forward-propagate to v3 as well, if tha
last ternary test may be quieted in the future.
>
> Modify the deparenthesize function to only strip balanced
> leading and trailing parentheses.
>
> Signed-off-by: Joe Perches
I'd suggest dropping the warning for parenthesized ternaries as well,
but in any case:
Reviewed-by
gt; This eliminates the following warning in kernel/trace/ftrace.c:
> > kernel/trace/ftrace.c:4914:5: warning: no previous prototype for
> > ‘ftrace_graph_entry_stub’ [-Wmissing-prototypes]
> >
> > Signed-off-by: Rashika Kheria
> > Reviewed-by: Josh Triplett
>
On Thu, Feb 27, 2014 at 08:23:35PM +0100, Peter Zijlstra wrote:
> On Thu, Feb 27, 2014 at 07:51:50AM -0800, Josh Triplett wrote:
> > On Thu, Feb 27, 2014 at 12:54:14PM +0100, Peter Zijlstra wrote:
> > > On Thu, Feb 27, 2014 at 05:02:48PM +0530, Rashika Kheria wrote:
>
On Thu, Feb 27, 2014 at 08:24:35PM +0100, Peter Zijlstra wrote:
> On Thu, Feb 27, 2014 at 08:03:22AM -0800, Josh Triplett wrote:
> > Did you perhaps check, and notice that there are *zero* uses of this
> > function in the kernel? Nothing overrides this weak symbol; it is no
&g
On Tue, Feb 18, 2014 at 01:31:47PM -0800, Paul E. McKenney wrote:
> On Mon, Feb 17, 2014 at 04:23:01PM -0800, Josh Triplett wrote:
> > On Mon, Feb 17, 2014 at 02:12:21PM -0800, Paul E. McKenney wrote:
> > > From: "Paul E. McKenney"
> > >
> > >
On Tue, Feb 18, 2014 at 01:36:11PM -0800, Paul E. McKenney wrote:
> On Mon, Feb 17, 2014 at 04:34:02PM -0800, Josh Triplett wrote:
> > On Mon, Feb 17, 2014 at 02:12:41PM -0800, Paul E. McKenney wrote:
> > > From: "Paul E. McKenney"
> > >
> > > Cre
On Thu, Jul 31, 2014 at 11:31:10AM +0100, Matt Fleming wrote:
> On Wed, 30 Jul, at 12:23:32PM, Josh Triplett wrote:
> > @@ -61,14 +81,18 @@ void __init efi_bgrt_init(void)
> > early_iounmap(image, sizeof(bmp_header));
> > bgrt_image_size = bmp_header.size;
>
this should remain entirely optional; nothing in the core
kernel should depend on it.
- Josh Triplett
--
To unsubscribe from this list: send the 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/
for ftrace :-)
Which can be compiled out. :)
- Josh Triplett
--
To unsubscribe from this list: send the 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/
t; Signed-off-by: Paul E. McKenney
Reviewed-by: Josh Triplett
Should this remain a separate patch, or go into the patch that creates
these APIs?
> kernel/rcu/update.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
> index c8
On Wed, Jul 30, 2014 at 05:39:35PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney"
>
> It turns out to be easier to add the synchronous grace-period waiting
> functions to RCU-tasks than to work around their absense in rcutorture,
> so this commit adds them. The key point is that the e
McKenney
Seems reasonable; however, you could also set .cb_barrier =
synchronize_rcu_tasks and drop rcu_barrier_tasks.
Either way:
Reviewed-by: Josh Triplett
> include/linux/rcupdate.h | 1 +
> kernel/rcu/rcutorture.c | 40 +++-
> 2 files
ngs.
So, if you have to wait for the existing set of callbacks to go away
before adding more, that seems fine. And you could then ditch polling
entirely.
> > Also, ideally this should remain entirely optional; nothing in the core
> > kernel should depend on it.
>
> Agreed, the
t in response to Peter
> Zijlstra's concerns about adding overhead to the scheduler's fastpaths.
>
> Therefore, although the flags are sometimes cleared externally from the
> scheduling-clock interrupt (for usermode execution), it is quite possible
> that a given task might
On Tue, Sep 23, 2014 at 08:34:42AM +1000, Stephen Rothwell wrote:
> Hi Josh,
>
> On Mon, 22 Sep 2014 10:53:04 -0700 Josh Triplett
> wrote:
> >
> > Can you please add the tiny tree, branch tiny/next of
> > https://git.kernel.org/pub/scm/linux/kernel/git/josh
nel?
If not:
Reviewed-by: Josh Triplett
> include/linux/rcupdate.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index a4a819f..a033d8b 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
>
On Thu, Sep 25, 2014 at 01:21:13PM -0400, Johannes Weiner wrote:
> On Mon, Sep 22, 2014 at 09:11:16AM -0700, Josh Triplett wrote:
> > @@ -3,7 +3,7 @@
> > #
> >
> > mmu-y := nommu.o
> > -mmu-$(CONFIG_MMU) := fremap.o gup.o highmem.o
old new delta
sys_fadvise64 57 - -57
sys_fadvise64_64 691 --691
sys_madvise 1502 - -1502
Signed-off-by: Josh Triplett
---
v2: Don't make fadvise depend on CONFI
ompilers to specifically *not* complain about empty
initializers even when otherwise complaining about missing fields.
Initializing a structure to 0 is completely sensible.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo
checks that
check for indentations of 8 or more spaces. Similarly, mixed tab/space
indentations would get caught by those same checks. I don't think
checkpatch needs to check those.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
The specified lock is held on function entry and exit.
>
> __acquires - The specified lock is held on function exit, but not entry.
>
> __releases - The specified lock is held on function entry, but not exit.
>
> So __acquires and __releases look mutually exclusive, but i
Omar Sandoval
One nit: shouldn't the returned rcu_string pointer have an __rcu
address space annotation?
With that fixed:
Reviewed-by: Josh Triplett
> fs/btrfs/check-integrity.c | 6 +--
> fs/btrfs/dev-replace.c | 19 +-
> fs/btrfs/disk-io.c | 6 +--
erator at
the start of the line will produce a better result. (I'd actually
suggest that in *most* cases.)
> Also, using perl, it's hard to distinguish between a
> logical "&" and the address-of "&" as well as the
> multiplication "*" and indi
On Tue, May 13, 2014 at 12:25:54PM -0700, Paul E. McKenney wrote:
> On Sat, May 10, 2014 at 12:34:12PM -0700, Josh Triplett wrote:
> > On Fri, May 09, 2014 at 05:48:38PM -0700, Paul E. McKenney wrote:
> > > On Wed, May 07, 2014 at 03:11:39PM -0700, j...@joshtriplett.org wrote:
&
On Tue, May 13, 2014 at 03:10:59PM -0700, H. Peter Anvin wrote:
> On 05/09/2014 03:38 PM, Josh Triplett wrote:
> > On Fri, May 09, 2014 at 02:20:45PM -0700, H. Peter Anvin wrote:
> >> On 05/09/2014 02:12 PM, Arnd Bergmann wrote:
> >>>
> >>>> Howe
e, so his @intel.com address
won't work anymore. I don't know his preferred new address. (Hopefully
he plans to switch to something company-independent now.)
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to major
ike
syscalls, and have all the infrastructure go away all the way down.
So, with LTO merged, the next time you see a patch to add yet another
Kconfig symbol to compile out some low-level kernel infrastructure when
not needed, you can say "no, I don't want to add more configuration
complexity; com
Modify the definition of BUG_ON() accordingly such that the
> > behavior of BUG_ON(1) is identical to that of BUG().
> >
> > Signed-off-by: Bart Van Assche
> > Cc: Arnd Bergmann
> > Cc: Josh Triplett
> > Cc: Andrew Morton
> > ---
> > i
uld continue to compile to nothing if CONFIG_BUG=n, or
> > CONFIG_BUG=n has no reason to exist.
>
> Hello Josh,
>
> I wasn't aware that the current behavior of BUG_ON() with CONFIG_BUG=n
> was intentional. The reason I started looking into this is because
> different
man
> CC: Himangi Saraogi
> CC: Josh Triplett
> CC: Vitaly Osipov
> CC: de...@driverdev.osuosl.org
> CC: linux-kernel@vger.kernel.org
Reviewed-by: Josh Triplett
> drivers/staging/wlan-ng/prism2mgmt.c | 26 ++
> 1 file changed, 10 insertions(+), 16
C: Greg Kroah-Hartman
> CC: Josh Triplett
> CC: Himangi Saraogi
> CC: Vitaly Osipov
> CC: de...@driverdev.osuosl.org
> CC: linux-kernel@vger.kernel.org
This is one case where I think checkpatch is just wrong; this doesn't
make the code any more (or less) readable.
Meh-by: J
On Thu, Jun 19, 2014 at 09:20:16PM +0200, Johannes Stadlinger wrote:
> This patch fixes a warning of checkpatch about string splitting.
>
> Signed-off-by: Johannes Stadlinger
> Signed-off-by: Maximilian Eschenbacher
> CC: linux-ker...@i4.cs.fau.de
> CC: Greg Kroah-Hartman
&
emaining.
>
> Signed-off-by: Johannes Stadlinger
> Signed-off-by: Maximilian Eschenbacher
> CC: linux-ker...@i4.cs.fau.de
> CC: Greg Kroah-Hartman
> CC: Josh Triplett
> CC: Vitaly Osipov
> CC: Himangi Saraogi
> CC: de...@driverdev.osuosl.org
> CC: linux-
> movq1000(%rdi), %rax# rsp_9(D)->rda, __ptr
> movq24(%rdx,%rax), %r12# _15->mynode, rnp_old
>
> x86_64 __this_cpu_read():
>
> movq%rdi, %r13# rsp, rsp
> movq1000(%rdi), %rax# rsp_9(D)->rda, rsp_9(D)->rda
> movq %gs:24(%r
g Kroah-Hartman
> CC: Tugce Sirin
> CC: Josh Triplett
> CC: Neil Armstrong
> CC: Paul Gortmaker
> CC: Vitaly Osipov
> CC: de...@driverdev.osuosl.org
> CC: linux-kernel@vger.kernel.org
Most of these look fine, but...
> @@ -1271,7 +1275,8 @@ void prism2sta
> CC: Tugce Sirin
> CC: Josh Triplett
> CC: Vitaly Osipov
> CC: Neil Armstrong
> CC: Paul Gortmaker
> CC: de...@driverdev.osuosl.org
> CC: linux-kernel@vger.kernel.org
Reviewed-by: Josh Triplett
> drivers/staging/wlan-ng/prism2sta.c | 3 +--
> 1 file changed, 1 i
_addr_copy' instead of 'memcpy'
> remaining.
>
> Signed-off-by: Johannes Stadlinger
> Signed-off-by: Maximilian Eschenbacher
> CC: linux-ker...@i4.cs.fau.de
> CC: Greg Kroah-Hartman
> CC: Tugce Sirin
> CC: Josh Triplett
> CC: Himangi Saraogi
&
On Thu, Jun 19, 2014 at 04:16:34PM -0500, Christoph Lameter wrote:
> This looks very much like the CONFIG_PREEMPT problem in not so
> extreme form. Maybe we need to add another config option:
>
> CONFIG_REALLY_REALLY_NO_PREEMPT
>
> to get the fastest code possible and those cond_rescheds removed
RCU_COND_RESCHED_QS.
>
> 5.Provides a boot/sysfs rcutree.jiffies_till_cond_resched_qs
> parameter to replace the magic "7".
For all five patches:
Reviewed-by: Josh Triplett
Glad to see this doesn't add any overhead to rcutiny.
- Josh Triplett
--
To unsubscribe from this lis
etting the fqs logic poke
un-quiesced kernel code as needed? That way, rather than having
cond_resched do any work, you have the fqs logic recognize that a
particular CPU has gone too long without quiescing, without disturbing
that CPU at all if it hasn't gone too long.
- Josh Triplett
--
2.When RCU recognizes that a particular CPU has gone too long,
> exactly what are you suggesting that RCU do about it? When
> formulating your answer, please give due consideration to the
> implications of that CPU being a NO_HZ_FULL CPU. ;-)
Send it an IPI that either
mmediately if currently quiesced or causes it to quiesce at the next
> > opportunity if not.
>
> OK. But if we are in a !PREEMPT kernel,
That's not the case I was suggesting. *If* the kernel is fully
preemptible, then it makes little sense to put any code in cond_resched,
when inste
Usage lines to drop the shell entirely and just
invoke the program directly?
> Signed-off-by: Pranith Kumar
With the above changed (perhaps in a separate patch):
Reviewed-by: Josh Triplett
> tools/testing/selftests/rcutorture/bin/config2frag.sh | 4 ++--
> tools/testing/selftests/
; hubert feurstein
> "hung hing lun, mike"
> ian campbell
> ian molton
> ion badulescu
> ishizaki kou
> ivan kokshaysky
> jakub schmidtke
> "james e.j. bottomley"
> "james e.j. bottomley"
> "james e.j. bottomley"
> ja
set of maintainers
or reviewers, it doesn't seem excessive to split it into a separate
MAINTAINERS entry. For instance, if you want kernel/sched/rt.c to have
an additional set of maintainers/reviewers, just add a MAINTAINERS entry
for "SCHEDULER - REALTIME" with an appropria
On Tue, Jul 15, 2014 at 06:31:47PM -0400, Pranith Kumar wrote:
> This commit updates the references to rcutree.c which is now rcu/tree.c
>
> Signed-off-by: Pranith Kumar
Reviewed-by: Josh Triplett
> kernel/rcu/tiny.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
hy
the comment is stale. Was code removed without removing the
corresponding comment, or was code changed such that the comment no
longer applies, or...?
- Josh Triplett
> kernel/rcu/tree.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
&g
uld use this variable
> instead of NUM_RCU_NODES.
>
> This commit changes all such uses of NUM_RCU_NODES to rcu_num_nodes.
>
> Signed-off-by: Pranith Kumar
Reviewed-by: Josh Triplett
(On a separate note, these names really need to provide clearer
explanations of the difference, gr
.c which was left out when some
> code was moved around previously.
>
> For reference, the following updated comment exists a few lines below this
> which
> means the same.
>
> /* Remove the outgoing CPU from the masks in the rcu_node hierarchy. */
>
> Signed-off-by: Pranit
On Wed, Jun 11, 2014 at 04:39:42PM -0400, Pranith Kumar wrote:
> kernel/rcu/tree.c:3435:21: warning: incorrect type in argument 1 (different
> modifiers)
> kernel/rcu/tree.c:3435:21:expected int ( *threadfn )( ... )
> kernel/rcu/tree.c:3435:21:got int ( static [toplevel] [noreturn]
> * )(
ned-off-by: Pranith Kumar
Please preserve the comment alignment (by deleting a tab). With that
fixed:
Reviewed-by: Josh Triplett
> kernel/rcu/rcutorture.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
>
On Thu, Jun 12, 2014 at 10:12:57AM -0700, Randy Dunlap wrote:
> From: Randy Dunlap
>
> Note that I don't maintain Documentation/ABI/,
> Documentation/devicetree/, or the language translation files.
>
> Signed-off-by: Randy Dunlap
One comment below.
> MAINTAINERS |2 +-
> 1 file changed,
> > Documentation/ko_KR/
> > Documentation/zh_CN/
> >
> > and it's easy to add any other directory you don't
> > want to cc'd on.
>
> Thanks, I'll modify it to that syntax.
> That should satisfy Josh's comment also.
I'd forgotten a
xing or
silencing. At most, it might be helpful to add annotations like GCC's
"nonnull", if that helps the checker and the compiler generate more
useful warnings.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mess
concern. It's likely possible
to address those concerns while still producing a usable minimal version
of the networking stack, if you'd be willing to provide feedback and
support iteration of patches like these.
Would you be interested in discussing this at Kernel Summit, perhaps?
Would th
how much cache low-end processors have, and imagine running
entirely out of *that*. Let's not surrender that entire class of
devices to VxWorks, FreeRTOS, and other painfully non-Linux systems,
when we already know it's possible to run Linux on them successfully.
- Josh Triplett
--
To u
l.
Ideally, that kind of process would support eliminating kernel config
options that just select userspace-visible interfaces, leaving only the
kernel config options that change how those interfaces behave
(size/performance/feature tradeoffs).
- Josh Triplett
--
To unsubscribe from this list: sen
do and
> > don't need, feeding that information into the kernel build process, and
> > automatically dropping unused bits of the kernel.
>
> Please make sure I'm not on the list of people who see reports for
> bugs reported in that setup.
>
> Thanks :-)
Fine b
the kernel ?
Too much. That's potentially fixable, but not if we start with the
premise that it's impossible.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
, but lucky for you I hear there are lots of those around.
Why would I want to run one of those when I can run Linux?
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
ven have a PID 2.
> >*That's* the kind of "embedded" we're talking about, not the
> >supercomputers we carry around in our pockets.
>
> Would this be some sort of "Internet of Things" system?
That's one of many buzzwords being used for this kind
On Tue, May 06, 2014 at 11:58:38AM -0700, Tom Herbert wrote:
> On Tue, May 6, 2014 at 11:32 AM, Andi Kleen wrote:
> >> We simply can not compete with user space, as a programmer is free to
> >> keep what he really wants/needs.
> >
> > Not true.
> >
> > With my patches and LTO Linux can be competiv
-tree patches". But that
only works if the responses to patch submissions are either "No, because
you need to fix X, Y, and Z", or "No, because your use case is better
served by this existing mechanism already in the kernel", rather than
"No, your use case is not valid".
- Josh Triplett
--
To unsubscribe from this list: send the 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/
ber of sockets using the venerable and slow BSD socket api.
>
> I was objecting to the "crazy things like LWIP" comment from Josh, not
> to your patches in general.
My primary statement was that it's crazy to use something like LWIP just
because you want a *tiny* system.
3.15+, not least of
which drivers for current hardware.
- Josh Triplett
--
To unsubscribe from this list: send the 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/
st of
> > which drivers for current hardware.
>
> So you're saying that the 2.4.x -stable maintainer did a shitty job and
> his work is worthless?
There's a difference between maintaining 2.4.x for all the existing
users who can't or won't upgrade, and introduci
pointer in the torture-test structure to report a stall?
- Josh Triplett
> include/linux/rcupdate.h | 19 +++
> kernel/rcu/rcutorture.c | 37 +
> kernel/rcu/tree.c| 18 ++
> 3 files changed, 74 insertion
On Mon, Apr 28, 2014 at 05:24:54PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney"
>
> The current lock_torture_writer() spends too much time sleeping and not
> enough time hammering locks, as in an eight-CPU test will often only be
> utilizing a CPU or two. This commit therefore makes
On Mon, Apr 28, 2014 at 05:24:55PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney"
>
> Some environments require some variation on "make defconfig" to initialize
> the .config file. This commit therefore adds a --defconfig argument to
> allow this to be specified. The default value is
With that change:
> Signed-off-by: Paul E. McKenney
Reviewed-by: Josh Triplett
> ---
> tools/testing/selftests/rcutorture/bin/kvm-build.sh | 2 +-
> tools/testing/selftests/rcutorture/bin/kvm.sh | 6 +++---
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --gi
On Mon, Apr 28, 2014 at 05:24:58PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney"
>
> This commit makes the torture scripts a bit more RCU-independent.
And removes unnecessary exports; please document that. With that
change:
> Signed-off-by: Paul E. McKen
On Mon, Apr 28, 2014 at 05:24:59PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney"
>
> This commit makes the torture scripts a bit more RCU-independent.
>
> Signed-off-by: Paul E. McKenney
Bug below; with that fixed,
Reviewed-by: Josh Triplett
> -
gt; echo -net nic -net user
Not related to this patch, but: qemu defaults to -net nic -net user, so
you don't need to specify it.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kern
On Mon, Apr 28, 2014 at 05:25:00PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney"
>
> This commit makes the torture scripts a bit more RCU-independent.
>
> Signed-off-by: Paul E. McKenney
One comment below; with or without that change:
Reviewed-by: Josh
one nit below.
> Signed-off-by: Paul E. McKenney
With the commit message fixed:
Reviewed-by: Josh Triplett
> ---
> tools/testing/selftests/rcutorture/bin/kvm-build.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/rcutorture/bin
g to warrant a loop over a list of environment variables, or possibly
a loop over all environment variable starting with TORTURE_* .
> Signed-off-by: Paul E. McKenney
Reviewed-by: Josh Triplett
> ---
> tools/testing/selftests/rcutorture/bin/kvm.sh | 28
> ---
>
This commit therefore prints this array with a
> signed format in order to improve readability of the rcutorture output.
>
> Signed-off-by: Paul E. McKenney
Nit below; with that:
Reviewed-by: Josh Triplett
> kernel/rcu/rcutorture.c | 7 ---
> 1 file changed, 4 insertions(+)
On Mon, Apr 28, 2014 at 05:25:08PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney"
>
> Currently, torture_kthread_stopping() prints only the name of the
> kthread that is stopping, which can be unedifying. This commit therefore
> adds "Stopping" to make things more evident.
>
> Signed
On Mon, Apr 28, 2014 at 05:25:09PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney"
>
> The current script does record qemu diagnostics, but the user has to
> know where to look for them. This commit therefore puts them into the
> Warnings file so that kvm-recheck.sh will display them.
that selects the correct bzImage location
> relative to the top of the Linux source tree. This commit also adds a
> --bootimage argument that allows selecting some other file, for example,
> "vmlinux".
>
> Signed-off-by: Paul E. McKenney
Two issues below; with those fi
Signed-off-by: Paul E. McKenney
Should something reset gp_state after fqs finishes?
Reviewed-by: Josh Triplett
> include/linux/rcutiny.h | 4
> include/linux/rcutree.h | 1 +
> kernel/rcu/rcutorture.c | 1 +
> kernel/rcu/tree.c | 17 +
> kernel/rcu/tre
On Mon, Apr 28, 2014 at 05:25:20PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney"
>
> The reaction of kvm-recheck.sh is obscure at best, and easy to miss
> completely. This commit therefore prints "BUG: Build failed" in the
> summary at the end of a run.
This commit also changes a do
1 - 100 of 4244 matches
Mail list logo
