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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Brice Goglin
> 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
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.
Well, it didn't happen again after a reboot.
I'll try to see if I can reproduce it.
William Lee Irwin III
> 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
Prakash Punnoor
I am using atxp1 module to change vcore on my NForce2 via userspace daemon
(see punnoor.de). Currently atxp1 module will write to the log on every vcore
change, thus filling up my log - which I don't want. I am no kernel coder, but
I guess, this one-liner will change this behaviour in a wanted way, ie output
will be made for debug purposes only. (Please use the attached patch, if
inlined one got fsked up by TB.)
Cheers,
Prakash
Signed-off-by: Prakash Punnoor <pra...@punnoor.de>
--- drivers/i2c/chips/atxp1.c~ 2005-06-29 13:59:04.000000000 +0200
+++ drivers/i2c/chips/atxp1.c 2005-06-29 13:59:22.164237992 +0200
@@ -144,7 +144,7 @@
if (vid == cvid)
return count;
- dev_info(dev, "Setting VCore to %d mV (0x%02x)\n", vcore, vid);
+ dev_dbg(dev, "Setting VCore to %d mV (0x%02x)\n", vcore, vid);
/* Write every 25 mV step to increase stability */
if (cvid > vid) {
Ronny V. Vindenes
> 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 <s8...@ii.uib.no>
Tomasz Torcz
> Linus Torvalds <torv...@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
Hugh Dickins
> 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 <hu...@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))
Dave Kleikamp
733ad933f62e82ebc92fed988c7f0795e64dea62
This object doesn't appear to be in the git tree.
--
David Kleikamp
IBM Linux Technology Center
Ronny V. Vindenes
> 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 <s8...@ii.uib.no>
-
Jeff Garzik
> $ cat refs/tags/v2.6.13-rc1
> 733ad933f62e82ebc92fed988c7f0795e64dea62
>
> This object doesn't appear to be in the git tree.
ACK, I don't see it either.
Jeff
Linus Torvalds
On Wed, 29 Jun 2005, Dave Kleikamp wrote:
>
> $ cat refs/tags/v2.6.13-rc1
> 733ad933f62e82ebc92fed988c7f0795e64dea62
>
> This object doesn't appear to be in the git tree.
Oh, it is, but I just forgot to push it to the public one ;)
Linus
Jesper Juhl
>
[...]
>
> 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 <jespe...@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
David Weinehall
> On 6/29/05, Linus Torvalds <torv...@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 <t...@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 (/
Bill Davidsen
> 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 (davi...@tmr.com)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me