Cc: Peter Zijlstra <peterz@...>, LKML <linux-kernel@...>, Netdev <netdev@...>, David S. Miller <davem@...>, Rafael J. Wysocki <rjw@...>, Andrew Morton <akpm@...>, Evgeniy Polyakov <johnpol@...>, Patrick McManus <mcmanus@...>
* Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> wrote:
out of the -tip tree :-) The -tip tree has 75+ topic branches at the
moment, but TCP topics are not in its scope - so any TCP change is "out
of tree" for the -tip tree.
People got confused in the past when they saw similar test patches show
up in sched.git and x86.git before, so we wanted to make it very clear
in -tip (with is the successor of sched.git, x86.git and a couple of
other git trees) that these are commits we dont want to push anywhere.
Commits in tip/out-of-tree dont get propagated into the tip/auto-*-next
topic branches that linux-next and -mm picks up, they are purely a
courtesy to help the testing/fixing of bugs in subsystems that are
maintained in other git trees.
See attached below the current shortlog of the tip/out-of-tree topic
branch - it contains changes all around the tree for various things that
we triggered in -tip and are not yet upstream or are in flight somewhere
in another git tree.
a full day of testing on a testsystem with 500 random kernel builds and
bootups (the kernel build done on the testsystem utilizing distcc and
make -j100, so it's rather heavy and parallel TCP traffic per iteration)
with no hang, compared to the same system with your reverts not applied
that hung after an hour with 20-30 iterations.
And that count increased to 1000 successful test iterations since
yesterday.
So i think yes, it seems rather conclusive, given the circumstances ;-)
These random kernel boots found many 'impossible to trigger' bugs and
races in the past. The reason for its race finding capability is the
timing randomness of the resulting random kernel image: the delays
caused by random combination of debugging facilities, build variants,
kernel subsystem variants we have. This -tip qa method - as a
side-effect of its coverage testing - simulates timing variantions that
are otherwise only observable via hardware variations.
I.e. this is not the same kernel booted up a 1000 times - that would be
a very narrow test. This is 1000 _different_ kernels built and booted
up. Each kernel having subtly different timings and ordering. And it's
more than just externally injected random kernel: the test-system itself
builds its "next version" (and uses the network for that as well), so
it's a self-hosting recursive random test in essence.
This method is also amazingly good at finding compiler/linker trouble:
it found 3-4 real gcc bugs so far. (For example i triggered an ancient
bug in gcc 4.0.2 just yesterday. For the record, the testsystem with the
TCP hang utilizes gcc-4.2.2.)
i'll queue it up for testing, but no promises about speedy action here -
the test cycle is really long with this bug.
Ingo
------{ tip/out-of-tree shortlog: }----------->
Alexander van Heukelum (1):
uml: cleanup: use def_bool in Kconfig files
Bjorn Helgaas (1):
PNPACPI: use _CRS IRQ descriptor length for _SRS
Ilpo Järvinen (1):
tcp: revert DEFER_ACCEPT modifications
Ingo Molnar (7):
video/dvb: fix MEDIA_TUNER && FW_LOADER build error
dvb: input layer dependencies fixes
drivers/media/video build fix for modular builds
drivers/watchdog/geodewdt.c: build fix
USB: fix build bug in USB_ISIGHTFW
acpi-acpi_numa_init-build-fix
acpi: fix drivers/acpi/glue.c build error
Michael Krufky (1):
dib7000p: fix dib7000p_attach when !CONFIG_DVB_DIB7000P
Russ Anderson (1):
acpi: fix boot breakage on Altix
Yinghai Lu (2):
net: use numa_node in net_devcice->dev instead of parent
ide: use dev_to_node instead of pcibus_to_node
--
