Actually that's either a mistake or I don't know what you guys call "a
stable version".
Since 2.6.24 there're serious regressions in all the following
"stable" releases. Both my own experience + http://www.kerneloops.org/
proves that.
Just to bring in some examples:
-- using 2.6.25.x I started to notice "oops"es in dmesg (what hadn't
been happening for a long time).
-- since 2.6.26 mine desktop system can't go suspend or hibernate. It
tries, but immediately returns from that trying.
-- Copying several rather big files (~ 25--45 GiB) from XFS on LVM-2
on MDraid partition to another one, I had the system rebooted both
with 2.6.28 and 2.6.27.10 (accomplished using 2.6.24.7-rt(sic!)25). As
you probably understand, that's the case you even can't trace where's
the problem, at least on a desktop with GUI, not on server with plain
text display. Although, I'm afraid even text display wouldn't had a
chance to show anything, tracing that problem.
So, I don't feel Linux is stable since 2.6.24. Do you?
(I'm not subscribed to the list, please cc:)
--
End of message. Next message?
On Mon, Dec 29, 2008 at 12:39:55PM +0700, Igor Podlesny wrote:
> Actually that's either a mistake or I don't know what you guys call "a
> stable version".
>
> Since 2.6.24 there're serious regressions in all the following
> "stable" releases. Both my own experience + http://www.kerneloops.org/
> proves that.
>
> Just to bring in some examples:
>
> -- using 2.6.25.x I started to notice "oops"es in dmesg (what hadn't
> been happening for a long time).
>
> -- since 2.6.26 mine desktop system can't go suspend or hibernate. It
> tries, but immediately returns from that trying.
>
> -- Copying several rather big files (~ 25--45 GiB) from XFS on LVM-2
> on MDraid partition to another one, I had the system rebooted both
> with 2.6.28 and 2.6.27.10 (accomplished using 2.6.24.7-rt(sic!)25). As
> you probably understand, that's the case you even can't trace where's
> the problem, at least on a desktop with GUI, not on server with plain
> text display. Although, I'm afraid even text display wouldn't had a
> chance to show anything, tracing that problem.
>
> So, I don't feel Linux is stable since 2.6.24. Do you?
Well, I won't say that I find them 100% rock solid, but you seem to be
able to reproduce a lot of serious issues. Have you filed bug reports
to get them fixed ? You cannot expect people to fix bugs they're not
aware of !
Also it would be a good idea to get all those issues fixed soon, because
2.6.27-stable will be maintained for a long time.
Willy
On Mon, Dec 29, 2008 at 12:39:55PM +0700, Igor Podlesny wrote:
> -- Copying several rather big files (~ 25--45 GiB) from XFS on LVM-2
> on MDraid partition to another one, I had the system rebooted both
> with 2.6.28 and 2.6.27.10 (accomplished using 2.6.24.7-rt(sic!)25). As
> you probably understand, that's the case you even can't trace where's
> the problem, at least on a desktop with GUI, not on server with plain
> text display. Although, I'm afraid even text display wouldn't had a
> chance to show anything, tracing that problem.
You don't have 4K_STACKs enabled by default, do you?
And instead of these rants bug reports would be more useful.
2008/12/29 Christoph Hellwig <[email protected]>:
> On Mon, Dec 29, 2008 at 12:39:55PM +0700, Igor Podlesny wrote:
>> -- Copying several rather big files (~ 25--45 GiB) from XFS on LVM-2
>> on MDraid partition to another one, I had the system rebooted both
>> with 2.6.28 and 2.6.27.10 (accomplished using 2.6.24.7-rt(sic!)25). As
>> you probably understand, that's the case you even can't trace where's
>> the problem, at least on a desktop with GUI, not on server with plain
>> text display. Although, I'm afraid even text display wouldn't had a
>> chance to show anything, tracing that problem.
>
> You don't have 4K_STACKs enabled by default, do you?
x86_64, so it's not applicable.
I see you've included XFS guys, but that's hard to guess which
sub-system is related to that crash, cause it's a stacked construction
XFS/LVM-2/Linux Software RAID/sata_nv. Also, I've found there were
some complaints bout netfilter's ipt_recent, which I was using, so
I've decided to turn it off and see.
>
> And instead of these rants bug reports would be more useful.
>
Yeah, I'll try to get backtraces, using null-modem cable, but alas, I
don't have it yet. Nowadays it's not a thing easy to buy at a computer
store. Also, my message (feedback) was written due to concerns bout
quality degradation I saw. May be I was mistaken or not, but I felt
it's better to talk about it to people who really cared and knew.
--
End of message. Next message?
2008/12/29 Sitsofe Wheeler <[email protected]>:
> Igor Podlesny wrote:
>>
>> Yeah, I'll try to get backtraces, using null-modem cable, but alas,
>> I
>
> Have you tried compiling your kernel with extended checks
> (CONFIG_DEBUG_KERNEL in the Kernel hacking menu)? There are debug poisoning
> options too. Sometimes this can flush out problems before they become
> fatal...
>
2.6.28's:
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_DEBUG_FS is not set
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_SHIRQ=y
# CONFIG_DEBUG_OBJECTS is not set
CONFIG_DEBUG_PREEMPT=y
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_VIRTUAL is not set
# CONFIG_DEBUG_WRITECOUNT is not set
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_DEBUG_LIST=y
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
CONFIG_DEBUG_STACKOVERFLOW=y
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_DEBUG_PER_CPU_MAPS is not set
CONFIG_DEBUG_RODATA=y
# CONFIG_DEBUG_RODATA_TEST is not set
# CONFIG_DEBUG_NX_TEST is not set
-- Nothing in dmesg; when it freezes or reboots, even if there're
some messages on console, they wouldn't be seen in graphics mode. As I
said, now my suspicion is netfilter's ipt_recent; I've turned it off
and now waiting. Another kernel I'm using now (2.6.24-ovz-006.5+) is
built with stack usage reporting; that's the latest stack depth
report:
[ 54.312696] modprobe used greatest stack depth: 3904 bytes left
Dunno whether it's rather low or ok.
--
End of message. Next message?
Igor Podlesny schreef:
> Actually that's either a mistake or I don't know what you guys call "a
> stable version".
[removing all the part which needs bug report numbers]
I agree with you that the website is not very clear for someone not
accustomed to the Linux kernel development. There are actually more
stable versions available but they are not advertised. Maybe there
should be more trees displayed, something like this:
The latest stable version of the Linux kernel is: 2.6.28
The previous stable version of the Linux kernel is: 2.6.27.10
The latest longtime version of the Linux kernel is: 2.6.16.62
:
They correspond respectively to Linus'/stable team's tree, the stable
team's tree of the previous version (which keeps being updated even
after the latest Linus' stable release) and Adrian Bunk's tree.
Eric
On Mon, Dec 29, 2008 at 11:50 AM, ?ric Piel <[email protected]> wrote:
> stable versions available but they are not advertised. Maybe there
> should be more trees displayed, something like this:
> The latest stable version of the Linux kernel is: 2.6.28
> The previous stable version of the Linux kernel is: 2.6.27.10
> The latest longtime version of the Linux kernel is: 2.6.16.62
The latest version known to run OK on poige's hardware is: ....
(sorry). :)
--
This message represents the official view of the voices in my head
2008/12/29 Paul Komkoff <[email protected]>:> On Mon, Dec 29, 2008 at 11:50 AM, Éric Piel <[email protected]> wrote:>> stable versions available but they are not advertised. Maybe there>> should be more trees displayed, something like this:>> The latest stable version of the Linux kernel is: 2.6.28>> The previous stable version of the Linux kernel is: 2.6.27.10>> The latest longtime version of the Linux kernel is: 2.6.16.62>> The latest version known to run OK on poige's hardware is: ....> That what http://poige.livejournal.com/tag/kernel is for :-)
> (sorry). :)
-- End of message. Next message?????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
Christoph Hellwig wrote:
> instead of these rants bug reports would be more useful.
Igor didn't rant, not even a little bit, and it reflects poorly on you
that you engage in hyperbole rather than hear his story. In fact, or at
least in my opinion as a computer programmer with 30 years experience,
he's right: A newly stable kernel is not stable. He might even be right
about regressions since 2.6.24.
It's a sorry day when somebody making a simple, reasonable and accurate
feedback is criticised for not providing bug reports. But don't let him
(or me) stop you guys from toasting your fine success. You believe it's
stable; what more could anyone want?