Linux 2.6.13-rc1

Linux 2.6.13-rc1

[Linus Torvalds]

Ok, guys,
 there was a lot of stuff pending after 2.6.12, and in the week and a half
since the release, the current diff against it has grown to almost three
megabytes compressed.

Which is actually normal for a -rc1 release judging by the two last ones,
but it usually takes us longer than ten days to get there. Which just
shows that 2.6.12 was brewing for too long, but we can also think
positively and say that perhaps it also seems to imply that this git thing
is working out and not slowing people down.

Anyway, I really don't want to drag out 2.6.13 as long as 2.6.12 took, and
we don't have any reason to anyway, so let's try to see if we can calm
things down again, and people who are thinking about writing new code
might think about spending some quality time looking at the existing code
and patches instead.

Now, that big patch ends up being spread out over 2069 commits, and a
noticeable chunk of it is actually the new xtensa architecture that got
merged, but that still leaves a lot of patches all over the place (things
like a few new console fonts, for example ;). The shortlog is over 100kB
in size, which means that I think linux-kernel won't take it if I include
it here, so I won't.  Similarly, the diffstat is 200kB, partly because of 
the spread out nature of the pacthes.

ARM, x86[-64], ppc, sparc updates, networking, sound, infiniband, input
layer, ISDN, MD, DVB, V4L, network drivers, pcmcia, isofs, jfs, nfs,
xfs, knfsd.. You name it.

Git trees and traditional patches/tar-balls are out there, or at least 
slowly mirroring out. Go wild,

		Linus

Re: Linux 2.6.13-rc1

[Brice Goglin]

Le 29.06.2005 08:30, Linus Torvalds a écrit :
> Ok, guys,
>  there was a lot of stuff pending after 2.6.12, and in the week and a half
> since the release, the current diff against it has grown to almost three
> megabytes compressed.

Hi Linus,

My video and music is played too fast. The ratio seems to be 1,6666.
Note that I'm using HZ=1000. But I'm also using HZ=1000 in -mm for a
while without any problem.
Any idea ?

Brice

Re: Linux 2.6.13-rc1

[Brice Goglin]

Le 29.06.2005 09:46, Brice Goglin a écrit :
> Le 29.06.2005 08:30, Linus Torvalds a écrit :
> 
>>Ok, guys,
>> there was a lot of stuff pending after 2.6.12, and in the week and a half
>>since the release, the current diff against it has grown to almost three
>>megabytes compressed.
> 
> 
> Hi Linus,
> 
> My video and music is played too fast. The ratio seems to be 1,6666.
> Note that I'm using HZ=1000. But I'm also using HZ=1000 in -mm for a
> while without any problem.

Well, it didn't happen again after a reboot.
I'll try to see if I can reproduce it.

Brice

Re: Linux 2.6.13-rc1

[William Lee Irwin III]

On Tue, Jun 28, 2005 at 11:30:54PM -0700, Linus Torvalds wrote:
> Anyway, I really don't want to drag out 2.6.13 as long as 2.6.12 took, and
> we don't have any reason to anyway, so let's try to see if we can calm
> things down again, and people who are thinking about writing new code
> might think about spending some quality time looking at the existing code
> and patches instead.

I would be much obliged if this recommendation were followed, and far
greater care exercised once relaxed.


-- wli

Re: Linux 2.6.13-rc1

[Ronny V. Vindenes]

Linus Torvalds <torvalds@osdl.org> writes:

> ARM, x86[-64], ppc, sparc updates, networking, sound, infiniband, input
> layer, ISDN, MD, DVB, V4L, network drivers, pcmcia, isofs, jfs, nfs,
> xfs, knfsd.. You name it.
> 
> Git trees and traditional patches/tar-balls are out there, or at least 
> slowly mirroring out. Go wild,
> 
> 		Linus

On x86_64 with reiserfs and ext3 on dm (using cfq scheduler) the log
is full of this:

Badness in blk_remove_plug at drivers/block/ll_rw_blk.c:1424

Call Trace:<ffffffff8022e9a2>{blk_remove_plug+49} <ffffffff8022f093>{__generic_unplug_device+21}
       <ffffffff80230da3>{get_request_wait+155} <ffffffff8013e6d0>{autoremove_wake_function+0}
       <ffffffff80231252>{__make_request+789} <ffffffff8022f3e9>{generic_make_request+502}
       <ffffffff8013e6d0>{autoremove_wake_function+0} <ffffffff8016a378>{bio_clone+130}
       <ffffffff8803cadc>{:dm_mod:clone_bio+37} <ffffffff8803cdf5>{:dm_mod:__split_bio+327}
       <ffffffff8803d11e>{:dm_mod:dm_request+171} <ffffffff8022f3e9>{generic_make_request+502}
       <ffffffff8013e6d0>{autoremove_wake_function+0} <ffffffff8014d81c>{mempool_alloc+49}
       <ffffffff8022f4ba>{submit_bio+188} <ffffffff80169dd0>{bio_alloc_bioset+232}
       <ffffffff801674fd>{submit_bh+254} <ffffffff80169158>{__block_write_full_page+419}
       <ffffffff8016c0e1>{blkdev_get_block+0} <ffffffff8018308f>{mpage_writepages+418}
       <ffffffff8016b39b>{blkdev_writepage+0} <ffffffff8013afe6>{worker_thread+0}
       <ffffffff8014ac31>{__filemap_fdatawrite_range+81} <ffffffff881c6752>{:reiserfs:flush_async_commits+103}
       <ffffffff881c66eb>{:reiserfs:flush_async_commits+0}
       <ffffffff8013b13f>{worker_thread+345} <ffffffff8012aef0>{default_wake_function+0}
       <ffffffff8013afe6>{worker_thread+0} <ffffffff8013e533>{kthread+191}
       <ffffffff8013afe6>{worker_thread+0} <ffffffff8010eee7>{child_rip+8}
       <ffffffff8013afe6>{worker_thread+0} <ffffffff8013e358>{keventd_create_kthread+0}
       <ffffffff8013e474>{kthread+0} <ffffffff8010eedf>{child_rip+0}
       

-- 
Ronny V. Vindenes <s864@ii.uib.no>

Re: Linux 2.6.13-rc1

[Tomasz Torcz]

On Wed, Jun 29, 2005 at 04:23:11PM +0200, Ronny V. Vindenes wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
> 
> > ARM, x86[-64], ppc, sparc updates, networking, sound, infiniband, input
> > layer, ISDN, MD, DVB, V4L, network drivers, pcmcia, isofs, jfs, nfs,
> > xfs, knfsd.. You name it.
> > 
> > Git trees and traditional patches/tar-balls are out there, or at least 
> > slowly mirroring out. Go wild,
> > 
> > 		Linus
> 
> On x86_64 with reiserfs and ext3 on dm (using cfq scheduler) the log
> is full of this:
> 
> Badness in blk_remove_plug at drivers/block/ll_rw_blk.c:1424

 Also on x86, Reiserfs on LVM2, cfq, on sata_sil; Preemption set to
Voluntary.

Badness in blk_remove_plug at drivers/block/ll_rw_blk.c:1424
 [<c027adf1>] blk_remove_plug+0x61/0x70
 [<c027ae14>] __generic_unplug_device+0x14/0x30
 [<c027b6d5>] get_request_wait+0xd5/0x100
 [<c01322f0>] autoremove_wake_function+0x0/0x50
 [<c01322f0>] autoremove_wake_function+0x0/0x50
 [<c02837f0>] cfq_merge+0x0/0xc0
 [<c027bf03>] __make_request+0x93/0x470
 [<c027c617>] generic_make_request+0x107/0x1f0
 [<c027b61b>] get_request_wait+0x1b/0x100
 [<c01322f0>] autoremove_wake_function+0x0/0x50
 [<c01322f0>] autoremove_wake_function+0x0/0x50
 [<c01615bc>] bio_clone+0xcc/0xe0
 [<c02ca72c>] __map_bio+0x3c/0x100
 [<c02cab0b>] __clone_and_map+0x22b/0x240
 [<c02cabb7>] __split_bio+0x97/0x100
 [<c02cac7f>] dm_request+0x5f/0x90
 [<c027c617>] generic_make_request+0x107/0x1f0
 [<c01322f0>] autoremove_wake_function+0x0/0x50
 [<c01322f0>] autoremove_wake_function+0x0/0x50
 [<c027c74b>] submit_bio+0x4b/0xe0
 [<c01612c1>] bio_alloc_bioset+0x181/0x200
 [<c0160bba>] submit_bh+0xda/0x130
 [<c01b0369>] write_ordered_chunk+0x29/0x50
 [<c01b03cb>] add_to_chunk+0x3b/0x40
 [<c01b0673>] write_ordered_buffers+0xb3/0x1a0
 [<c01b0340>] write_ordered_chunk+0x0/0x50
 [<c01b0c2c>] flush_commit_list+0x37c/0x460
 [<c01b5469>] do_journal_end+0x8d9/0x930
 [<c01477c0>] pdflush+0x0/0x20
 [<c01b425c>] journal_end_sync+0x4c/0xb0
 [<c01a2e55>] reiserfs_sync_fs+0x45/0x60
 [<c01629cb>] sync_supers+0xbb/0xd0
 [<c0146e85>] wb_kupdate+0x25/0x120
 [<c0387eea>] schedule+0x2fa/0x5d0
 [<c01477c0>] pdflush+0x0/0x20
 [<c01476e6>] __pdflush+0x96/0x170
 [<c01477da>] pdflush+0x1a/0x20
 [<c0146e60>] wb_kupdate+0x0/0x120
 [<c01477c0>] pdflush+0x0/0x20
 [<c0131f05>] kthread+0x95/0xd0
 [<c0131e70>] kthread+0x0/0xd0
 [<c010134d>] kernel_thread_helper+0x5/0x18

-- 
Tomasz Torcz                "Funeral in the morning, IDE hacking
zdzichu@irc.-nie.spam-.pl    in the afternoon and evening." - Alan Cox

Re: Linux 2.6.13-rc1

[Hugh Dickins]

On Wed, 29 Jun 2005, Tomasz Torcz wrote:
> On Wed, Jun 29, 2005 at 04:23:11PM +0200, Ronny V. Vindenes wrote:
> > 
> > On x86_64 with reiserfs and ext3 on dm (using cfq scheduler) the log
> > is full of this:
> > 
> > Badness in blk_remove_plug at drivers/block/ll_rw_blk.c:1424
> 
>  Also on x86, Reiserfs on LVM2, cfq, on sata_sil; Preemption set to
> Voluntary.

You should find the patch I posted just a little earlier fixes all that...

get_request is now expected to be holding on to queue_lock, with interrupts
disabled, when it returns NULL; but one path forgot that, causing all kinds
of nastiness under swap load - badness backtraces, strange failures, BUGs.

Signed-off-by: Hugh Dickins <hugh@veritas.com>

--- 2.6.13-rc1/drivers/block/ll_rw_blk.c	2005-06-29 11:54:08.000000000 +0100
+++ linux/drivers/block/ll_rw_blk.c	2005-06-29 14:41:04.000000000 +0100
@@ -1917,10 +1917,9 @@ get_rq:
 	 * limit of requests, otherwise we could have thousands of requests
 	 * allocated with any setting of ->nr_requests
 	 */
-	if (rl->count[rw] >= (3 * q->nr_requests / 2)) {
-		spin_unlock_irq(q->queue_lock);
+	if (rl->count[rw] >= (3 * q->nr_requests / 2))
 		goto out;
-	}
+
 	rl->count[rw]++;
 	rl->starved[rw] = 0;
 	if (rl->count[rw] >= queue_congestion_on_threshold(q))

Re: Linux 2.6.13-rc1

[Ronny V. Vindenes]

ons, 29,.06.2005 kl. 16.07 +0100, skrev Hugh Dickins:
> On Wed, 29 Jun 2005, Tomasz Torcz wrote:
> > On Wed, Jun 29, 2005 at 04:23:11PM +0200, Ronny V. Vindenes wrote:
> > > 
> > > On x86_64 with reiserfs and ext3 on dm (using cfq scheduler) the log
> > > is full of this:
> > > 
> > > Badness in blk_remove_plug at drivers/block/ll_rw_blk.c:1424
> > 
> >  Also on x86, Reiserfs on LVM2, cfq, on sata_sil; Preemption set to
> > Voluntary.
> 
> You should find the patch I posted just a little earlier fixes all that...

Confirmed.

-- 
Ronny V. Vindenes <s864@ii.uib.no>

Re: Linux 2.6.13-rc1

[Jesper Juhl]

On 6/29/05, Linus Torvalds <torvalds@osdl.org> wrote:
> 
[...]
> 
> Anyway, I really don't want to drag out 2.6.13 as long as 2.6.12 took, and
> we don't have any reason to anyway, so let's try to see if we can calm
> things down again, and people who are thinking about writing new code
> might think about spending some quality time looking at the existing code
> and patches instead.
> 
[...]
> 

That sounds like a really good idea. If 2.6.13 could get out the door
fairly quickly and be the result of everyone saying "let's make this a
rock solid kernel and shake all the bugs out" that would be great..  A
sort of 2.6.12 on stabilizers ;)
I know I'll be doing my bit to fix some of the minor bits.


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: Linux 2.6.13-rc1

[David Weinehall]

On Wed, Jun 29, 2005 at 09:31:53PM +0200, Jesper Juhl wrote:
> On 6/29/05, Linus Torvalds <torvalds@osdl.org> wrote:
> > 
> [...]
> > 
> > Anyway, I really don't want to drag out 2.6.13 as long as 2.6.12 took, and
> > we don't have any reason to anyway, so let's try to see if we can calm
> > things down again, and people who are thinking about writing new code
> > might think about spending some quality time looking at the existing code
> > and patches instead.
> > 
> [...]
> > 
> 
> That sounds like a really good idea. If 2.6.13 could get out the door
> fairly quickly and be the result of everyone saying "let's make this a
> rock solid kernel and shake all the bugs out" that would be great..  A
> sort of 2.6.12 on stabilizers ;)
> I know I'll be doing my bit to fix some of the minor bits.

I don't think the combination of an almost 3MB diff vs 2.6.12 and
a fairly quick release is going to end up being a rock solid kernel. =)

But I hope I'm wrong.


Regards: David
-- 
 /) David Weinehall <tao@acc.umu.se> /) Northern lights wander      (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/    (/   Full colour fire           (/

Re: Linux 2.6.13-rc1

[Bill Davidsen]

Linus Torvalds wrote:
> Ok, guys,
>  there was a lot of stuff pending after 2.6.12, and in the week and a half
> since the release, the current diff against it has grown to almost three
> megabytes compressed.
> 
> Which is actually normal for a -rc1 release judging by the two last ones,
> but it usually takes us longer than ten days to get there. Which just
> shows that 2.6.12 was brewing for too long, but we can also think
> positively and say that perhaps it also seems to imply that this git thing
> is working out and not slowing people down.
> 
> Anyway, I really don't want to drag out 2.6.13 as long as 2.6.12 took, and
> we don't have any reason to anyway, so let's try to see if we can calm
> things down again, and people who are thinking about writing new code
> might think about spending some quality time looking at the existing code
> and patches instead.

Can't comment on git slowing things down, but I have to think that the 
time it took, and was ALLOWED to take, is a result of the -stable fixes 
working very well indeed. The fact that the 2.6.11.X was available to 
take the presure off to get something out of the door.

My big thank you to the stable folks, I personally think this idea is 
working as intended.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me