"Read my lips: no more merges" - aka Linux 2.6.14-rc1

[Linus Torvalds]

Ok, it's been two weeks (actually, two weeks and one day) since 2.6.13,
and that means that the merge window is closed. I've released a
2.6.14-rc1, and we're now all supposed to help just clean up and fix
everything, and aim for a really solid 2.6.14 release.

Both the diffstat and the shortlog are so big that I can't post them on
the kernel mailing list without getting the email killed by the size
restrictions, so there's not a lot to say.

alpha, arm, x86, x86-64, ppc, ia64, mips, sparc, um.. Pretty much every
architecture got some updates. And an absolutely _huge_ ACPI diff, largely
because of some re-indentation.

drm, watchdog, hwmon, i2c, infiniband, input layer, md, dvb, v4l, network,
pci, pcmcia, scsi, usb and sound driver updates. People may appreciate
that the most common wireless network drivers got merged - centrino
support is now in the standard kernel.

On the filesystem level, FUSE got merged, and ntfs and xfs got updated. In
the core VFS layer, the "struct files" thing is now handled with RCU and
has less expensive locking.

And networking changes.

In other words, a lot of stuff all over the place. Be nice now, and follow
the rules: put away the new toys, and instead work on making sure the
stuff that got merged is all solid. Ok?

Anybody with git can do the shortlog with

git-rev-list --no-merges --pretty=short v2.6.14-rc1 ^v2.6.13 |
git-shortlog | less -S

which is actually pretty informative.

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/

[Alejandro Bonilla Beeche]

On Mon, 2005-09-12 at 20:34 -0700, Linus Torvalds wrote:

>
> drm, watchdog, hwmon, i2c, infiniband, input layer, md, dvb, v4l, network,
> pci, pcmcia, scsi, usb and sound driver updates. People may appreciate
> that the most common wireless network drivers got merged - centrino
> support is now in the standard kernel.

Kudos for merging IPW in.

>
> git-rev-list --no-merges --pretty=short v2.6.14-rc1 ^v2.6.13 |
> git-shortlog | less -S

I have these 2 "commands" I Run to get the latest git.
debian:~# cat getkernel
#! /bin/bash
git clone
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
linux-2.6
cd linux-2.6
rsync -a --verbose --stats --progress \
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \
git/

getkernel was the first I used to get the whole thing and only used it
once.

debian:~# cat getkernelupdate
#! /bin/bash
cd linux-2.6
git pull
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
git checkout

I use getkernelupdate to "download the updated git with the new patches
sent.

If I do make menuconfig, it still says 2.6.13 instead of 2.6.14-rc1.

Do I have something missing?

I do git commit and git checkout after those scripts above.

Any answers are appreciated!!

Alejandro

[Keith Owens]

On Mon, 12 Sep 2005 21:54:29 -0600,
Alejandro Bonilla Beeche <abon...@linuxwireless.org> wrote:
>If I do make menuconfig, it still says 2.6.13 instead of 2.6.14-rc1.

rsync.kernel.org has not been updated from the master yet. Give it an
hour and try again.

[Alejandro Bonilla Beeche]

On Tue, 2005-09-13 at 13:59 +1000, Keith Owens wrote:
> On Mon, 12 Sep 2005 21:54:29 -0600,
> Alejandro Bonilla Beeche <abon...@linuxwireless.org> wrote:
> >If I do make menuconfig, it still says 2.6.13 instead of 2.6.14-rc1.
>
> rsync.kernel.org has not been updated from the master yet. Give it an
> hour and try again.

Bah, My bad! I always do something wrong so I had to ask. ;-)

Sorry for spam.

Alejandro

[Voluspa]

root:sleipner:/usr/src/testing/linux-2.6.14-rc1# make modules_install
[...]
if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F
System.map 2. 6.14-rc1; fi
WARNING: /lib/modules/2.6.14-rc1/kernel/drivers/char/agp/amd64-agp.ko
needs unknown symbol end_pfn

Mvh
Mats Johannesson
--

[Cal Peake]

Hi,

More fallout from the change mentioned above.

LD .tmp_vmlinux1
arch/i386/kernel/built-in.o(.init.text+0xd3a): In function
`parse_cmdline_early':
: undefined reference to `disable_timer_pin_1'
arch/i386/kernel/built-in.o(.init.text+0xd3f): In function
`parse_cmdline_early':
: undefined reference to `disable_timer_pin_1'
arch/i386/kernel/built-in.o(.init.text+0xd49): In function
`parse_cmdline_early':
: undefined reference to `disable_timer_pin_1'
make: *** [.tmp_vmlinux1] Error 1

This gets the kernel built:

disable_timer_pin_1 needs IO-APIC, not just local APIC.

Signed-off-by: Cal Peake <c...@absolutedigital.net>

--- linux-2.6.14-rc1/arch/i386/kernel/setup.c~ 2005-09-13 01:36:07.000000000 -0400
+++ linux-2.6.14-rc1/arch/i386/kernel/setup.c 2005-09-13 02:23:42.000000000 -0400
@@ -848,9 +848,7 @@
#ifdef CONFIG_X86_IO_APIC
else if (!memcmp(from, "acpi_skip_timer_override", 24))
acpi_skip_timer_override = 1;
-#endif

-#ifdef CONFIG_X86_LOCAL_APIC
if (!memcmp(from, "disable_timer_pin_1", 19))
disable_timer_pin_1 = 1;
if (!memcmp(from, "enable_timer_pin_1", 18))
@@ -859,7 +857,7 @@
/* disable IO-APIC */
else if (!memcmp(from, "noapic", 6))
disable_ioapic_setup();
-#endif /* CONFIG_X86_LOCAL_APIC */
+#endif /* CONFIG_X86_IO_APIC */
#endif /* CONFIG_ACPI */

#ifdef CONFIG_X86_LOCAL_APIC

--
". . . tell 'em we use Linux." -- Dave Chappelle

[Sonny Rao]

On Mon, Sep 12, 2005 at 08:34:17PM -0700, Linus Torvalds wrote:
<snip>

> On the filesystem level, FUSE got merged, and ntfs and xfs got updated. In
> the core VFS layer, the "struct files" thing is now handled with RCU and
> has less expensive locking.

I hope this means that people will be more accepting of multi-threaded
benchmarks (who needs real apps... ;-)) which do open() and close().

Yes, no?

Sonny

[Eric Dumazet]

Sonny Rao a écrit :

> On Mon, Sep 12, 2005 at 08:34:17PM -0700, Linus Torvalds wrote:
> <snip>
>
>>On the filesystem level, FUSE got merged, and ntfs and xfs got update
d. In
>>the core VFS layer, the "struct files" thing is now handled with RCU
and
>>has less expensive locking.
>
>
> I hope this means that people will be more accepting of multi-threade
d
> benchmarks (who needs real apps... ;-)) which do open() and close().
>
>
> Yes, no?

If you look at RCU change, you discover they impact read()/write()/...
(no
more locking), but not open()/dup()/socket() and close() that still tak
e a
spinlock to modify the state.

And if your process has many files opened, the cost (read : latency) of
open()
can be very high, finding a zero bit in a large bit array.

So these RCU changes can help some benchmarks (or real apps... ;-) ), b
ut not
some others :)

I wish a process param could allow open() to take any free fd available
, not
the lowest one. One can always use fcntl(fd, F_DUPFD, slot) to move a f
d on a
specific high slot and always keep the 64 first fd slots free to speedu
p the
kernel part at open()/dup()/socket() time.

[Udo A. Steinberg]

On Mon, 12 Sep 2005 20:34:17 -0700 (PDT) Linus Torvalds (LT) wrote:

LT> Ok, it's been two weeks (actually, two weeks and one day) since 2.6.13,
LT> and that means that the merge window is closed. I've released a
LT> 2.6.14-rc1, and we're now all supposed to help just clean up and fix
LT> everything, and aim for a really solid 2.6.14 release.

I'm getting a linker error due to disable_timer_pin_1, which is defined in
io_apic.c as int disable_timer_pin_1 __initdata;

but I'm building with

CONFIG_X86_UP_APIC=y
# CONFIG_X86_UP_IOAPIC is not set
CONFIG_X86_LOCAL_APIC=y

The error is in setup.c, which can't find the variable since io_apic.c isn't
being compiled in.

arch/i386/kernel/built-in.o(.init.text+0xd51): In function `parse_cmdline_early':

: undefined reference to `disable_timer_pin_1'
make: *** [.tmp_vmlinux1] Error 1

-Udo.

[Mathieu Fluhr]

On Mon, 2005-09-12 at 20:34 -0700, Linus Torvalds wrote:

> Ok, it's been two weeks (actually, two weeks and one day) since 2.6.13,
> and that means that the merge window is closed. I've released a
> 2.6.14-rc1, and we're now all supposed to help just clean up and fix
> everything, and aim for a really solid 2.6.14 release.
>

Sorry to bother you again and again with this stuff, but I got no answer
from anyone... DVD burning is broken since 2.6.13-rc1 and I checked this
morning the 2.6.14-rc1: Same status.

To be short, when burning a DVD at 16x with 2.6.12.6, no problem at all.
With 2.6.13-rc1 and upper, lots of buffer underruns. (If someone wants
to help, feel free to ask more details... I would be happy to help
anyone). The only thing that I know is that it is not coming from the
peripheral driver, as I have the same issue when using ide-cd with a
CDROM_SEND_PACKET ioctl or usb-storage+sg with a SG_IO ioctl.

As far as I looked in the source code, it seems to be lots (and lots) of
changes between these 2 versions, specially regarding block devices
drivers. But the ChangeLog is so huge that it is quite impossible to
make a step-by-step upgrade to see _where_ the problem is :-(

[Helge Hafting]

Mathieu Fluhr wrote:

>On Mon, 2005-09-12 at 20:34 -0700, Linus Torvalds wrote:
>
>
>>Ok, it's been two weeks (actually, two weeks and one day) since 2.6.13,
>>and that means that the merge window is closed. I've released a
>>2.6.14-rc1, and we're now all supposed to help just clean up and fix
>>everything, and aim for a really solid 2.6.14 release.
>>
>>
>>
>
>Sorry to bother you again and again with this stuff, but I got no answer
>from anyone... DVD burning is broken since 2.6.13-rc1 and I checked this
>morning the 2.6.14-rc1: Same status.
>
>To be short, when burning a DVD at 16x with 2.6.12.6, no problem at all.
>With 2.6.13-rc1 and upper, lots of buffer underruns. (If someone wants
>to help, feel free to ask more details... I would be happy to help
>anyone). The only thing that I know is that it is not coming from the
>peripheral driver, as I have the same issue when using ide-cd with a
>CDROM_SEND_PACKET ioctl or usb-storage+sg with a SG_IO ioctl.
>
>As far as I looked in the source code, it seems to be lots (and lots) of
>changes between these 2 versions, specially regarding block devices
>drivers. But the ChangeLog is so huge that it is quite impossible to
>make a step-by-step upgrade to see _where_ the problem is :-(
>
>

You can do a bisection search with git, that will pinpoint exactly
which patch that cause trouble. It is much easier to get a
maintainer to fix it if you can point the finger at one particular patch.

The recipe for bisection search is in the mailing list archives,
or send me an email, I've done it once.

Helge Hafting

[Linus Torvalds]

On Mon, 12 Sep 2005, Alejandro Bonilla Beeche wrote:
>
> debian:~# cat getkernelupdate
> #! /bin/bash
> cd linux-2.6
> git pull rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> git checkout
>
>
> I use getkernelupdate to "download the updated git with the new patches
> sent.
>
> If I do make menuconfig, it still says 2.6.13 instead of 2.6.14-rc1.

I suspect that you were just hit by the kernel.org mirroring delay. The
change to the Makefile is the very last thing I do before a release, so
if the mirrors are slow, you won't get that change for about half an hour
or so..

[Linus Torvalds]

On Tue, 13 Sep 2005, Mathieu Fluhr wrote:
>
> DVD burning is broken since 2.6.13-rc1 and I checked this
> morning the 2.6.14-rc1: Same status.
>

> As far as I looked in the source code, it seems to be lots (and lots) of
> changes between these 2 versions, specially regarding block devices
> drivers. But the ChangeLog is so huge that it is quite impossible to
> make a step-by-step upgrade to see _where_ the problem is :-(

Yes, 2.6.12..2.6.13-rc1 was pretty big, However, the IDE driver changes
aren't that big.

None of your bug-reports seem to say even what driver you're using,
though, so it's a bit hard to make any judgement at all.

We at a minimum need to know what driver, and see boot messages (both
working and nonworking), and preferably things like "hdparm -I" output
(again, both working and nonworking) too. Often "lspci -vvx" is useful
too.

[Mathieu Fluhr]

Ok, after having performed a bisection of the kernel tree (took me the
whole afternoon.... 13 compilations needed ;-) I think I am able to give
the faulty patch for these buffer underruns:

--snip----------------------------------------------------------------
de-c-l-097:~/KernelTree/linux-2.6# git bisect bad
59121003721a8fad11ee72e646fd9d3076b5679c is first bad commit
diff-tree 59121003721a8fad11ee72e646fd9d3076b5679c (from
799d19f6ec5ca2102c61122f5219a17f1c4e961a)
Author: Christoph Lameter <chri...@lameter.com>
Date: Thu Jun 23 00:08:25 2005 -0700

[PATCH] i386: Selectable Frequency of the Timer Interrupt

Make the timer frequency selectable. The timer interrupt may cause bus
and memory contention in large NUMA systems since the interrupt occurs
on each processor HZ times per second.

Signed-off-by: Christoph Lameter <chri...@lameter.com>
Signed-off-by: Shai Fultheim <sh...@scalex86.org>
Signed-off-by: Andrew Morton <ak...@osdl.org>
Signed-off-by: Linus Torvalds <torv...@osdl.org>

:040000 040000 c859e995b936a0cfa1e91efdfd6351ca251b4c47
8a2d1f15a40f6e1655b5a1ff00f52cda787d46d9 M arch
:040000 040000 2fb4f01297addda0bd07a066efe0838f043836fb
d82e3d56597b7acd571e604e640d97ea80fc3a15 M include
:040000 040000 25bbac3c3c2d91eb5706e31779936d055897fc95
3282f7f102609c2c6a4731ae6569b34139cf8024 M kernel
de-c-l-097:~/KernelTree/linux-2.6#
--snip----------------------------------------------------------------

So I would say that it is related to somehow some kind of timeout in
SCSI I/O (but really not sure...). As far as I saw, there is now an
option in the kernel config file related to this, so I will try to see
what happens with 1000 Hz and 100 Hz (I left the default value of 250 Hz
for my tests).

Many thanks to all that helped ;-)
Mathieu

[Linus Torvalds]

On Tue, 13 Sep 2005, Mathieu Fluhr wrote:
>

> Ok, after having performed a bisection of the kernel tree (took me the
> whole afternoon.... 13 compilations needed ;-) I think I am able to give
> the faulty patch for these buffer underruns:

Thanks, interesting.

And hey, 13 compilations may sound like a lot, but considering that there
were 2069 commits between 2.6.12 and 2.6.13-rc1, having to do "just" 13
kernels to pinpoint the exact cause is pretty good, I think.

Especially as I don't think anybody would really have expected the one you
found:

> [PATCH] i386: Selectable Frequency of the Timer Interrupt
>

> So I would say that it is related to somehow some kind of timeout in
> SCSI I/O (but really not sure...).

Interesting, and a bit scary. If it worked with 1kHz (old default value),
it's not even any of the old Linux x86 timeouts (that were designed for
100 Hz), so it's some _new_ HZ dependency.

> As far as I saw, there is now an option in the kernel config file
> related to this, so I will try to see what happens with 1000 Hz and 100
> Hz (I left the default value of 250 Hz for my tests).

Yes, that would be interesting.

Btw, what's the exact error message you get? (And is it the kernel or the
burning app that complains?)

[Mathieu Fluhr]

On Tue, 2005-09-13 at 10:15 -0700, Linus Torvalds wrote:
>
> On Tue, 13 Sep 2005, Mathieu Fluhr wrote:
> >
> > Ok, after having performed a bisection of the kernel tree (took me the
> > whole afternoon.... 13 compilations needed ;-) I think I am able to give
> > the faulty patch for these buffer underruns:
>
> Thanks, interesting.
>
> And hey, 13 compilations may sound like a lot, but considering that there
> were 2069 commits between 2.6.12 and 2.6.13-rc1, having to do "just" 13
> kernels to pinpoint the exact cause is pretty good, I think.
>
> Especially as I don't think anybody would really have expected the one you
> found:
>

Yes I know. I was just kidding ;-) I would say that I didn't know the
git bisection method at all... but I would say that it is really
smashing!

> > [PATCH] i386: Selectable Frequency of the Timer Interrupt
> >
> > So I would say that it is related to somehow some kind of timeout in
> > SCSI I/O (but really not sure...).
>
> Interesting, and a bit scary. If it worked with 1kHz (old default value),
> it's not even any of the old Linux x86 timeouts (that were designed for
> 100 Hz), so it's some _new_ HZ dependency.
>
> > As far as I saw, there is now an option in the kernel config file
> > related to this, so I will try to see what happens with 1000 Hz and 100
> > Hz (I left the default value of 250 Hz for my tests).
>
> Yes, that would be interesting.
>

Okay, here is the point: I will have these bloody buffer underruns
unless I select a 'Timer frequency' of 1000 Hz in 'Processor type and
features' section of the kernel configuration. That's quite
understandable, as recording a DVD at 16x requires a throughput of 22160
KB/s, which is quite fast.

I will have a deep look in the patch, and maybe write a patched patch
(Ooooo my god what am I writing ?) in the next few days.

> Btw, what's the exact error message you get? (And is it the kernel or the
> burning app that complains?)

I do not get any kernel error message. It is just my burning app that
complains that buffer underruns occured, as if the source media was not
fast enough to deliver 22160 KB/s.

[Roland Dreier]

Sorry for being dense, but can you say what "no more merges" means?

At the kernel summit we talked about no more git merges after the
initial devel period, and I'm wondering if that really is the policy.

As a concrete example, suppose I have a git tree with something like

drivers/infiniband/hw/mthca/mthca_qp.c | 2 +-
drivers/infiniband/ulp/ipoib/ipoib_main.c | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)

ie a couple of really small, simple fixes. Emailing those to Andrew
as patches is fine by me, but it seems like it creates extra work for
Andrew and you. So is email via Andrew what you want, or are "bugfix
only" git pulls OK?

Thanks,
Roland

[Linus Torvalds]

On Tue, 13 Sep 2005, Roland Dreier wrote:
>
> Sorry for being dense, but can you say what "no more merges" means?

It's not so much a technical thing - I'll happily do git merges that fix
bugs. But I don't want to merge big stuff (of course, it turns out that
I'd missed a few before the release, so I did those anyway).

> As a concrete example, suppose I have a git tree with something like
>
> drivers/infiniband/hw/mthca/mthca_qp.c | 2 +-
> drivers/infiniband/ulp/ipoib/ipoib_main.c | 2 ++
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> ie a couple of really small, simple fixes.

I'll happily take them. I'd suggest you include the patches themselves in
the "please pull.." message, just to make it obvious what's going on, but
it would be stupid to avoid using technical means to get the patches in.
So I'll certainly go git merges for these kinds of things.

Linus

[Linus Torvalds]

On Tue, 13 Sep 2005, Mathieu Fluhr wrote:
>
> Okay, here is the point: I will have these bloody buffer underruns
> unless I select a 'Timer frequency' of 1000 Hz in 'Processor type and
> features' section of the kernel configuration. That's quite
> understandable, as recording a DVD at 16x requires a throughput of 22160
> KB/s, which is quite fast.
>
> I will have a deep look in the patch, and maybe write a patched patch
> (Ooooo my god what am I writing ?) in the next few days.

It may just be an application bug too. Too small a buffer, and depending
on 2.6.x with a 1kHz timer having timers that run faster...

[Rafael J. Wysocki]

Hi,

On Tuesday, 13 of September 2005 05:34, Linus Torvalds wrote:
>
> Ok, it's been two weeks (actually, two weeks and one day) since 2.6.13,
> and that means that the merge window is closed. I've released a
> 2.6.14-rc1, and we're now all supposed to help just clean up and fix
> everything, and aim for a really solid 2.6.14 release.
>
> Both the diffstat and the shortlog are so big that I can't post them on
> the kernel mailing list without getting the email killed by the size
> restrictions, so there's not a lot to say.
>
> alpha, arm, x86, x86-64, ppc, ia64, mips, sparc, um.. Pretty much every
> architecture got some updates. And an absolutely _huge_ ACPI diff, largely
> because of some re-indentation.
>
> drm, watchdog, hwmon, i2c, infiniband, input layer, md, dvb, v4l, network,
> pci, pcmcia, scsi, usb and sound driver updates. People may appreciate
> that the most common wireless network drivers got merged - centrino
> support is now in the standard kernel.
>
> On the filesystem level, FUSE got merged, and ntfs and xfs got updated. In
> the core VFS layer, the "struct files" thing is now handled with RCU and
> has less expensive locking.
>
> And networking changes.
>
> In other words, a lot of stuff all over the place. Be nice now, and follow
> the rules: put away the new toys, and instead work on making sure the
> stuff that got merged is all solid. Ok?

My AMD64-based box (Asus L5D) does not resume from disk on battery power
any more, even if booted with init=/bin/bash.

I think this is related to Bug #4959, which remains a mistery, but now it
also does not resume with CONFIG_DEBUG_SLAB unset.

Andi, is it possible that an MCE occurs when the image is copied (ie. while
the code in arch/x86_64/kernel/suspend_asm.S is being executed)?

Greetings,
Rafael

--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"

[Jean Delvare]

Hi all,

> More fallout from the change mentioned above.
>
> LD .tmp_vmlinux1
> arch/i386/kernel/built-in.o(.init.text+0xd3a): In function
> `parse_cmdline_early':
> : undefined reference to `disable_timer_pin_1'
> arch/i386/kernel/built-in.o(.init.text+0xd3f): In function
> `parse_cmdline_early':
> : undefined reference to `disable_timer_pin_1'
> arch/i386/kernel/built-in.o(.init.text+0xd49): In function
> `parse_cmdline_early':
> : undefined reference to `disable_timer_pin_1'
> make: *** [.tmp_vmlinux1] Error 1
>
> This gets the kernel built:
>
> disable_timer_pin_1 needs IO-APIC, not just local APIC.
>
> Signed-off-by: Cal Peake <c...@absolutedigital.net>

Just hit the same problem, Cal's works for me. Can it be pushed to into
git?

Thanks,
--
Jean Delvare

[Horst von Brand]

After the big "no more merges" push of stuff into 2.6.14-rc1 on i686 I get:

arch/i386/kernel/built-in.o: In function `parse_cmdline_early':
: undefined reference to `disable_timer_pin_1'
arch/i386/kernel/built-in.o: In function `parse_cmdline_early':
: undefined reference to `disable_timer_pin_1'
arch/i386/kernel/built-in.o: In function `parse_cmdline_early':
: undefined reference to `disable_timer_pin_1'

In io_apic.c there is an:

int disable_timer_pin_1 __initdata;

but that file isn't compiled here, as CONFIG_X86_IO_APIC isn't set; while
the pieces that reference this are protected by CONFIG_X86_LOCAL_APIC. An
option changed name, perhaps?
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513

[Alejandro Bonilla Beeche]

On Tue, 2005-09-13 at 13:59 +1000, Keith Owens wrote:

> On Mon, 12 Sep 2005 21:54:29 -0600,
> Alejandro Bonilla Beeche <abon...@linuxwireless.org> wrote:
> >If I do make menuconfig, it still says 2.6.13 instead of 2.6.14-rc1.
>
> rsync.kernel.org has not been updated from the master yet. Give it an
> hour and try again.

Hi,

Is Linus git tree the one used for the rc's and the final release?

I keep updating and it still says 2.6.13 instead of 2.6.14-rc1. I don't
really care if that is cosmetic, is fine, I just want to make sure that
I'm up to date?

Again, this is what I do:

cd linux-2.6
git pull
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
git checkout

? Anyone

Alejandro

PS: Thanks for kicking in HDAPS into this tree.

[Mathieu Fluhr]

On Tue, 2005-09-13 at 12:11 -0700, Linus Torvalds wrote:
>
> On Tue, 13 Sep 2005, Mathieu Fluhr wrote:
> >
> > Okay, here is the point: I will have these bloody buffer underruns
> > unless I select a 'Timer frequency' of 1000 Hz in 'Processor type and
> > features' section of the kernel configuration. That's quite
> > understandable, as recording a DVD at 16x requires a throughput of 22160
> > KB/s, which is quite fast.
> >
> > I will have a deep look in the patch, and maybe write a patched patch
> > (Ooooo my god what am I writing ?) in the next few days.
>
> It may just be an application bug too. Too small a buffer, and depending
> on 2.6.x with a 1kHz timer having timers that run faster...
>

According to the MMC documentation, you can thoeriticaly send at most
65535 (16 bits int) blocks in one WRITE(10) CDB. This would means
sending a buffer of ~127 MB on case of writing a mode 1 data track (2048
bytes per block)...

Now, practically, it is really not safe to send more than 64 KB per CDB
(Mostly device related). And with such values, you have the following:
- at 100 Hz -> 64 KB * 100 = 6400 KB/s <=> ~4.62x DVD
- at 250 Hz -> 64 KB * 250 = 16000 KB/s <=> ~11.55x DVD
- at 1000 Hz -> 64 KB * 1000 = 64000 KB/s <=> ~46.20x DVD

I would suggest to leave to default value of the timer frequency to 1000
Hz and to add some more comment in the Kconfig.hz file. (Patch attached)

Mathieu

[Andrew Morton]

Mathieu Fluhr <mfl...@nero.com> wrote:
>
> According to the MMC documentation, you can thoeriticaly send at most
> 65535 (16 bits int) blocks in one WRITE(10) CDB. This would means
> sending a buffer of ~127 MB on case of writing a mode 1 data track (2048
> bytes per block)...
>
> Now, practically, it is really not safe to send more than 64 KB per CDB
> (Mostly device related). And with such values, you have the following:
> - at 100 Hz -> 64 KB * 100 = 6400 KB/s <=> ~4.62x DVD
> - at 250 Hz -> 64 KB * 250 = 16000 KB/s <=> ~11.55x DVD
> - at 1000 Hz -> 64 KB * 1000 = 64000 KB/s <=> ~46.20x DVD

But that implies that there's some piece of code somewhere (could be
userspace, could be kernel) which is doing a timer-based sleep() in between
each CDB. It shouldn't do that - it should be using the disk
controller's completion interrupt for synchronisation.

What userspace application are you using to write the DVDs, and is it
possible to test a different one?

[Mathieu Fluhr]

On Wed, 2005-09-14 at 01:30 -0700, Andrew Morton wrote:
> Mathieu Fluhr <mfl...@nero.com> wrote:
> >
> > According to the MMC documentation, you can thoeriticaly send at most
> > 65535 (16 bits int) blocks in one WRITE(10) CDB. This would means
> > sending a buffer of ~127 MB on case of writing a mode 1 data track (2048
> > bytes per block)...
> >
> > Now, practically, it is really not safe to send more than 64 KB per CDB
> > (Mostly device related). And with such values, you have the following:
> > - at 100 Hz -> 64 KB * 100 = 6400 KB/s <=> ~4.62x DVD
> > - at 250 Hz -> 64 KB * 250 = 16000 KB/s <=> ~11.55x DVD
> > - at 1000 Hz -> 64 KB * 1000 = 64000 KB/s <=> ~46.20x DVD
>
> But that implies that there's some piece of code somewhere (could be
> userspace, could be kernel) which is doing a timer-based sleep() in between
> each CDB. It shouldn't do that - it should be using the disk
> controller's completion interrupt for synchronisation.
>

Hummm... you are definitly right. So forget my calculations. I does not
mean anything. Honestly, I was just trying to find an explanation why it
was working with HZ set to 1000 and not with HZ set to 250 or 100.

> What userspace application are you using to write the DVDs, and is it
> possible to test a different one?

I am using NeroLINUX to make my tests. I also tried out
cdrecord/growisofs, but I was not even able to burn at 16x (I get some
error message that max speed is 10x... and nothing more).

But there seems to be somehow some I/O limitation: I configured a pure
2.6.13.1 to have HZ set to 100. I then made a 3 GB compilation with
small files (about 3 to 5 MB each).
- If you burn this directly without creating a temp ISO image in 4x
(5440 KB/s), you will get buffer underruns soon or later... (about 2%)
- If you create an ISO image out of the compilation (using mkisofs or
other tool), and then burn this image, then no buffer underruns occurs.

After that, you speed up your recorder with this image (for example at
8x), you will have these buffer underruns back again.
And as I tell you, no such stuff is happening when HZ is set to 1000.

[Andrew Morton]

OK, so you get underruns with NeroLINUX at 8x, and it should be possible to
test cdrecord at 8x, yes? If that works then it's time to take a look at
what NeroLINUX is doing..

erp, it's payware. strace, maybe?

[Alessandro Suardi]

Data point... recent 2.6.13 (possibly after 2.6.13-final) allow
my puny K7-800 256MB RAM to burn DVDs with growisofs
at 8x, whereas earlier releases would peak at 8x then step
back to 4x. Currently burn starts at 5x and goes up steadily
to 8x in a couple of minutes, then stays there until the DVD
is done. I never tested 16x - actually I haven't yet owned a
16x capable DVD disc... but I doubt my system could burn
that fast - 8x is already a blessing ;)

--alessandro

"All it takes is one decision
A lot of guts, a little vision to wave
Your worries, and cares goodbye"

(Placebo - "Slave To The Wage")

[Bill Davidsen]

Linus Torvalds wrote:
>
> On Tue, 13 Sep 2005, Mathieu Fluhr wrote:
>
>>Okay, here is the point: I will have these bloody buffer underruns
>>unless I select a 'Timer frequency' of 1000 Hz in 'Processor type and
>>features' section of the kernel configuration. That's quite
>>understandable, as recording a DVD at 16x requires a throughput of 22160
>>KB/s, which is quite fast.
>>
>>I will have a deep look in the patch, and maybe write a patched patch
>>(Ooooo my god what am I writing ?) in the next few days.
>
>
> It may just be an application bug too. Too small a buffer, and depending
> on 2.6.x with a 1kHz timer having timers that run faster...

With cdrecord I can set the FIFO buffer size up to 20MB or so, which is
locked in memory when running as root. The issue seems to be moving the
data from the application buffer to the device buffer. Something in the
kernel would appear to only do that data transfer on a timer tick. It
may be that the dispatch latency is just too high, and that the thread
pushing the data to the device is just not getting the CPU in time, even
with the application buffer locked and the application running at RT
priority.

I generally build my kernels with voluntary preempt, I think I tried a
real preempt kernel without improvement, but I can't swear to it. If the
O.P. doesn't mind a 14th build that might be a decent data point.

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

[Bill Davidsen]

Linus Torvalds wrote:
> Ok, it's been two weeks (actually, two weeks and one day) since 2.6.13,
> and that means that the merge window is closed. I've released a
> 2.6.14-rc1, and we're now all supposed to help just clean up and fix
> everything, and aim for a really solid 2.6.14 release.
>
> Both the diffstat and the shortlog are so big that I can't post them on
> the kernel mailing list without getting the email killed by the size
> restrictions, so there's not a lot to say.
>
> alpha, arm, x86, x86-64, ppc, ia64, mips, sparc, um.. Pretty much every
> architecture got some updates. And an absolutely _huge_ ACPI diff, largely
> because of some re-indentation.
>
> drm, watchdog, hwmon, i2c, infiniband, input layer, md, dvb, v4l, network,
> pci, pcmcia, scsi, usb and sound driver updates. People may appreciate
> that the most common wireless network drivers got merged - centrino
> support is now in the standard kernel.

Was there some problems with the current version of the ipw2200 driver
(1.0.6) which required using the 1.0.0 version from several years ago?

And is the Centrino "modem" now working? Or just the wireless?

Good to see all this work, but I suspect it will be a long debug cycle
as people shake it out. I will probably build it tonight, try it tomorrow.

[Jeff Garzik]

Alejandro Bonilla Beeche wrote:
> Is Linus git tree the one used for the rc's and the final release?

Yes.

> I keep updating and it still says 2.6.13 instead of 2.6.14-rc1. I don't
> really care if that is cosmetic, is fine, I just want to make sure that
> I'm up to date?

Is your git up to date?

> git checkout

Try 'git checkout -f'

Jeff

[Alejandro Bonilla]

> Alejandro Bonilla Beeche wrote:
> > Is Linus git tree the one used for the rc's and the
> final release?
>
> Yes.

Jeff, Thanks for answering. ;-) I think Linus has me in his spam List ;(.

dunno.

>
>
> > I keep updating and it still says 2.6.13 instead of
> 2.6.14-rc1. I don't
> > really care if that is cosmetic, is fine, I just want to
> make sure that
> > I'm up to date?
>
> Is your git up to date?

I don't know. How can I tell? I did run those commands, which BTW are from
your How-To.

I think it is up to date, but it still doesn't say 2.6.14-rc1. That's the
only confusing part.

>
> > git checkout
>
> Try 'git checkout -f'

Will do. Thanks again.

Alejandro

[Linus Torvalds]

On Tue, 13 Sep 2005, Alejandro Bonilla Beeche wrote:
>
> Again, this is what I do:
>
> cd linux-2.6
> git pull rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> git checkout

What does "git log" state? Do you have recent state there? (ie it should
have dates in the "Sep 12" kind of timeframe)

Also, if you have done something earlier that updated your HEAD file
_without_ actually updating your checked out status, then "git checkout"
may decide that it has nothing to do. You can try "git checkout -f" in
that case.

Linus

[Alejandro Bonilla]

> On Tue, 13 Sep 2005, Alejandro Bonilla Beeche wrote:
> What does "git log" state? Do you have recent state there?
> (ie it should
> have dates in the "Sep 12" kind of timeframe)
>
> Also, if you have done something earlier that updated your HEAD file
> _without_ actually updating your checked out status, then
> "git checkout"
> may decide that it has nothing to do. You can try "git
> checkout -f" in
> that case.

Linus,

Thanks for the reply. I'm almost sure I did all the above following Jeff's
document.

I will do it again to make sure. Additionaly, thanks for the git log tip. I
didn't know how to check how new the git tree was.

Alejandro

[Steve Lee]

Just an FYI,

NeroLINUX is also broken. I can't successfully burn a DVD.

Steve

Linus Torvalds wrote:
>
> On Tue, 13 Sep 2005, Mathieu Fluhr wrote:
>
>>Okay, here is the point: I will have these bloody buffer underruns
>>unless I select a 'Timer frequency' of 1000 Hz in 'Processor type and
>>features' section of the kernel configuration. That's quite
>>understandable, as recording a DVD at 16x requires a throughput of
22160
>>KB/s, which is quite fast.
>>
>>I will have a deep look in the patch, and maybe write a patched patch
>>(Ooooo my god what am I writing ?) in the next few days.
>
>
> It may just be an application bug too. Too small a buffer, and
depending
> on 2.6.x with a 1kHz timer having timers that run faster...

With cdrecord I can set the FIFO buffer size up to 20MB or so, which is
locked in memory when running as root. The issue seems to be moving the
data from the application buffer to the device buffer. Something in the
kernel would appear to only do that data transfer on a timer tick. It
may be that the dispatch latency is just too high, and that the thread
pushing the data to the device is just not getting the CPU in time, even

with the application buffer locked and the application running at RT
priority.

I generally build my kernels with voluntary preempt, I think I tried a
real preempt kernel without improvement, but I can't swear to it. If the

O.P. doesn't mind a 14th build that might be a decent data point.

--

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

[Bill Davidsen]

Linus Torvalds wrote:
> Ok, it's been two weeks (actually, two weeks and one day) since 2.6.13,
> and that means that the merge window is closed. I've released a
> 2.6.14-rc1, and we're now all supposed to help just clean up and fix
> everything, and aim for a really solid 2.6.14 release.

I can bore the list with a config, but this seems pretty common over x86
configs, similar happened on desktop (this one), laptop, and server builds.
========================

CHK include/linux/compile.h
UPD include/linux/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
arch/i386/kernel/built-in.o(.init.text+0xe5e): In function

`parse_cmdline_early':
: undefined reference to `disable_timer_pin_1'

arch/i386/kernel/built-in.o(.init.text+0xe7e): In function

`parse_cmdline_early':
: undefined reference to `disable_timer_pin_1'

make[2]: *** [.tmp_vmlinux1] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.82653 (%build)

RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.82653 (%build)
make[1]: *** [rpm] Error 1
make: *** [rpm] Error 2

[Bill Davidsen]

Bill Davidsen wrote:
> Linus Torvalds wrote:
>
>> Ok, it's been two weeks (actually, two weeks and one day) since
>> 2.6.13, and that means that the merge window is closed. I've released
>> a 2.6.14-rc1, and we're now all supposed to help just clean up and fix
>> everything, and aim for a really solid 2.6.14 release.
>
>
> I can bore the list with a config, but this seems pretty common over x86
> configs, similar happened on desktop (this one), laptop, and server builds.

Ah, I see it, config needs to note that IOAPIC is now required. That's
probably not desirable, there are systems with broken ioapic which
should not be used.

> ========================
>
> CHK include/linux/compile.h
> UPD include/linux/compile.h
> CC init/version.o
> LD init/built-in.o
> LD .tmp_vmlinux1
> arch/i386/kernel/built-in.o(.init.text+0xe5e): In function
> `parse_cmdline_early':
> : undefined reference to `disable_timer_pin_1'
> arch/i386/kernel/built-in.o(.init.text+0xe7e): In function
> `parse_cmdline_early':
> : undefined reference to `disable_timer_pin_1'
> make[2]: *** [.tmp_vmlinux1] Error 1
> error: Bad exit status from /var/tmp/rpm-tmp.82653 (%build)
>
>
> RPM build errors:
> Bad exit status from /var/tmp/rpm-tmp.82653 (%build)
> make[1]: *** [rpm] Error 1
> make: *** [rpm] Error 2
>
>

-

[Henrik Persson]

Linus Torvalds wrote:
> Ok, it's been two weeks (actually, two weeks and one day) since 2.6.13,
> and that means that the merge window is closed. I've released a
> 2.6.14-rc1, and we're now all supposed to help just clean up and fix
> everything, and aim for a really solid 2.6.14 release.

My cardbus is acting funny. When I insert my netgear wg511 (prism54) the
first time after booting 2.6.14-rc1 nothing happens. Nothing in dmesg,
nothing nowhere. I remove it. Still nothing. Oh well. Inserting again.
THEN it initializes and is working like it usually does.

2.6.13+Ivan's PCI resource patch worked allright.

I can live with this, but this is a regression.. I remember having
exactly the same problem with some 2.4 kernel a few years back..

Any patch I should try backing out? Or some patch I should try?

--
Henrik Persson

[Peter Osterlund]

Linus Torvalds <torv...@osdl.org> writes:

> In other words, a lot of stuff all over the place. Be nice now, and follow
> the rules: put away the new toys, and instead work on making sure the
> stuff that got merged is all solid. Ok?

My Compaq Presario R3057EA hangs during ACPI initialization. The last
message is "Executing all Device _STA and _INI methods". git bisect
told me that:

66759a01adbfe8828dd063e32cf5ed3f46696181 is first bad commit
diff-tree 66759a01adbfe8828dd063e32cf5ed3f46696181 (from 049cdefe19f95b67b06b70915cd8e4ae7173337a)
Author: Chuck Ebbert <76306...@compuserve.com>
Date: Mon Sep 12 18:49:25 2005 +0200

[PATCH] x86-64: i386/x86-64: Fix time going twice as fast problem on ATI Xpress chipsets

Original patch from Bertro Simul

This is probably still not quite correct, but seems to be
the best solution so far.

Signed-off-by: Linus Torvalds <torv...@osdl.org>

Passing enable_timer_pin_1 as a kernel boot parameter doesn't help,
but this patch does:

diff --git a/arch/i386/kernel/io_apic.c b/arch/i386/kernel/io_apic.c
--- a/arch/i386/kernel/io_apic.c
+++ b/arch/i386/kernel/io_apic.c
@@ -2213,8 +2213,6 @@ static inline void check_timer(void)
setup_nmi();
enable_8259A_irq(0);
}
- if (disable_timer_pin_1 > 0)
- clear_IO_APIC_pin(0, pin1);
return;
}
clear_IO_APIC_pin(0, pin1);

But doing that is equivalent to reverting the whole patch, so it's
probably not the right solution. My computer has an Intel P4 CPU, ie
it's not x86_64.

lspci output:

00:00.0 Host bridge: ATI Technologies Inc Radeon 9100 IGP Host Bridge (rev 02)
00:01.0 PCI bridge: ATI Technologies Inc Radeon 9100 IGP AGP Bridge
00:13.0 USB Controller: ATI Technologies Inc OHCI USB Controller #1 (rev 01)
00:13.1 USB Controller: ATI Technologies Inc OHCI USB Controller #2 (rev 01)
00:14.0 SMBus: ATI Technologies Inc ATI SMBus (rev 16)
00:14.1 IDE interface: ATI Technologies Inc ATI Dual Channel Bus Master PCI IDE Controller
00:14.3 ISA bridge: ATI Technologies Inc: Unknown device 434c
00:14.4 PCI bridge: ATI Technologies Inc: Unknown device 4342
00:14.5 Multimedia audio controller: ATI Technologies Inc IXP150 AC'97 Audio Controller
00:14.6 Modem: ATI Technologies Inc IXP AC'97 Modem (rev 01)
01:05.0 VGA compatible controller: ATI Technologies Inc M9+ 5C61 [Radeon Mobility 9200 (AGP)] (rev 01)
02:00.0 FireWire (IEEE 1394): Texas Instruments TSB43AB21 IEEE-1394a-2000 Controller (PHY/Link)
02:02.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03)
02:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
02:04.0 CardBus bridge: Texas Instruments PCI1620 PC Card Controller (rev 01)
02:04.1 CardBus bridge: Texas Instruments PCI1620 PC Card Controller (rev 01)
02:04.2 System peripheral: Texas Instruments PCI1620 Firmware Loading Function (rev 01)
02:07.0 USB Controller: NEC Corporation USB (rev 43)
02:07.1 USB Controller: NEC Corporation USB (rev 43)
02:07.2 USB Controller: NEC Corporation USB 2.0 (rev 04)

--
Peter Osterlund - pet...@telia.com
http://web.telia.com/~u89404340

[Linus Torvalds]

On Wed, 15 Sep 2005, Peter Osterlund wrote:
>
> My Compaq Presario R3057EA hangs during ACPI initialization. The last
> message is "Executing all Device _STA and _INI methods". git bisect
> told me that:
>
> 66759a01adbfe8828dd063e32cf5ed3f46696181 is first bad commit
> diff-tree 66759a01adbfe8828dd063e32cf5ed3f46696181 (from 049cdefe19f95b67b06b70915cd8e4ae7173337a)
> Author: Chuck Ebbert <76306...@compuserve.com>
> Date: Mon Sep 12 18:49:25 2005 +0200
>
> [PATCH] x86-64: i386/x86-64: Fix time going twice as fast problem on ATI Xpress chipsets
>

> Passing enable_timer_pin_1 as a kernel boot parameter doesn't help,
> but this patch does:

Ok. That patch has been one big pain, and was clearly totally half-baked.
I think I'll disable the automated checks, since they are clearly wrong.
You can still enable it manually with a kernel command line.

So something like this.. I assume this works for you?

Linus

----
diff --git a/arch/i386/kernel/acpi/earlyquirk.c b/arch/i386/kernel/acpi/earlyquirk.c
--- a/arch/i386/kernel/acpi/earlyquirk.c
+++ b/arch/i386/kernel/acpi/earlyquirk.c
@@ -7,7 +7,6 @@
#include <linux/pci.h>
#include <asm/pci-direct.h>
#include <asm/acpi.h>
-#include <asm/apic.h>

static int __init check_bridge(int vendor, int device)
{
@@ -16,15 +15,6 @@ static int __init check_bridge(int vendo
if (vendor == PCI_VENDOR_ID_NVIDIA) {
acpi_skip_timer_override = 1;
}
-#ifdef CONFIG_X86_LOCAL_APIC
- /*
- * ATI IXP chipsets get double timer interrupts.
- * For now just do this for all ATI chipsets.
- * FIXME: this needs to be checked for the non ACPI case too.
- */
- if (vendor == PCI_VENDOR_ID_ATI)
- disable_timer_pin_1 = 1;
-#endif
return 0;
}

diff --git a/arch/x86_64/kernel/io_apic.c b/arch/x86_64/kernel/io_apic.c
--- a/arch/x86_64/kernel/io_apic.c
+++ b/arch/x86_64/kernel/io_apic.c
@@ -299,15 +299,6 @@ void __init check_ioapic(void)
#endif
/* RED-PEN skip them on mptables too? */
return;
- case PCI_VENDOR_ID_ATI:
- /* All timer interrupts on atiixp
- are doubled. Disable one. */
- if (disable_timer_pin_1 == 0) {
- disable_timer_pin_1 = 1;
- printk(KERN_INFO
- "ATI board detected. Disabling timer pin 1.\n");
- }
- return;
}

/* No multi-function device? */

[Peter Osterlund]

Linus Torvalds <torv...@osdl.org> writes:

> On Wed, 15 Sep 2005, Peter Osterlund wrote:
> >
> > My Compaq Presario R3057EA hangs during ACPI initialization. The last
> > message is "Executing all Device _STA and _INI methods". git bisect
> > told me that:
> >
> > 66759a01adbfe8828dd063e32cf5ed3f46696181 is first bad commit
> > diff-tree 66759a01adbfe8828dd063e32cf5ed3f46696181 (from 049cdefe19f95b67b06b70915cd8e4ae7173337a)
> > Author: Chuck Ebbert <76306...@compuserve.com>
> > Date: Mon Sep 12 18:49:25 2005 +0200
> >
> > [PATCH] x86-64: i386/x86-64: Fix time going twice as fast problem on ATI Xpress chipsets
> >
> > Passing enable_timer_pin_1 as a kernel boot parameter doesn't help,
> > but this patch does:
>
> Ok. That patch has been one big pain, and was clearly totally half-baked.
> I think I'll disable the automated checks, since they are clearly wrong.
> You can still enable it manually with a kernel command line.
>
> So something like this.. I assume this works for you?

Yes it does.

--
Peter Osterlund - pet...@telia.com
http://web.telia.com/~u89404340

[Matthew Garrett]

Bill Davidsen <davi...@tmr.com> wrote:

> And is the Centrino "modem" now working? Or just the wireless?

There is no Centrino modem, as such. Vendors can put a variety of codecs
on the board. Most of them are supported with the snd-intel8x0m driver
and the (closed) slmodem userspace binary, but Conexant ones (as used by
IBM) require binary drivers from Linuxant.

--
Matthew Garrett | mjg59-chiark.mail.l...@srcf.ucam.org

[Jesper Juhl]

Somebody who's familliar with the code (as opposed to me) might be
able to point to a specific patch, but you could also try doing a
bisection search with git bisect to try and find the patch between
2.6.13 and 2.6.14-rc1 that broke it for you. A few handfuls of kernel
compiles/boots usually does the trick.
Search the archives for details, it's been described numerous times.

--
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

[Redeeman]

On Mon, 2005-09-12 at 20:34 -0700, Linus Torvalds wrote:
<snip>
i just wanna say, that i really really like this, merge everything
within two weeks, and i think it will help make faster, and more stable
releases,

[Redeeman]

On Tue, 2005-09-13 at 12:40 +0200, Mathieu Fluhr wrote:
<snip>
i have burning problems too, but have had with dvd's for.. well.. since
i got my burner, i think it was 2.6.10 or something, perhaps 2.6.9, but
it has gotten more frequent with 2.6.13, yes.

my problem is that i get input/output error, we have discussed this
earlier on this list, but people kept saying it was bad media, but if
that is so, every media is bad, and all the cases where i have bad media
is when i choose to burn in linux..

i use i have cdrecord and growisofs, i k3b, which uses those..

my lspci info:
redeeman@redeeman $ /sbin/lspci
~
0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8385 [K8T800 AGP]
Host Bridge (rev 01)
0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge
[K8T800/K8T890 South]
0000:00:07.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host
Controller (rev 80)
0000:00:0a.0 Ethernet controller: 3Com Corporation 3c940
10/100/1000Base-T [Marvell] (rev 12)
0000:00:0e.0 Multimedia controller: Philips Semiconductors SAA7134 Video
Broadcast Decoder (rev 01)
0000:00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA
RAID Controller (rev 80)
0000:00:0f.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
0000:00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB
1.1 Controller (rev 81)
0000:00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB
1.1 Controller (rev 81)
0000:00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB
1.1 Controller (rev 81)
0000:00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB
1.1 Controller (rev 81)
0000:00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
0000:00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge
[KT600/K8T800/K8T890 South]
0000:00:11.5 Multimedia audio controller: VIA Technologies, Inc.
VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
0000:00:18.0 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] HyperTransport Technology Configuration
0000:00:18.1 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Address Map
0000:00:18.2 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] DRAM Controller
0000:00:18.3 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Miscellaneous Control
0000:01:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce
6600/GeForce 6600 GT] (rev a2)
------
i dont have an example dmesg error message now, but there is nothing to
it, its just a standard, hda input/output error..

one thing though, with kernels <2.6.13 i am able to simply cancel, and
burn again, with >2.6.13-rc* it freezes completely, and i gotta reboot
before i can get the dvd out.

i use the via ide driver in the kernel.

another thing, it happens at ~95-99% of the burning process in nearly
all cases, with one exception of half way through, and one case where it
was like 70%.

i hope this can help.

[Alejandro Bonilla Beeche]

On Tue, 2005-09-13 at 23:16 -0600, Alejandro Bonilla Beeche wrote:
> On Tue, 2005-09-13 at 13:59 +1000, Keith Owens wrote:
> > On Mon, 12 Sep 2005 21:54:29 -0600,
> > Alejandro Bonilla Beeche <abon...@linuxwireless.org> wrote:
> > >If I do make menuconfig, it still says 2.6.13 instead of 2.6.14-rc1.
> >
> > rsync.kernel.org has not been updated from the master yet. Give it an
> > hour and try again.

Linus,

Thanks for the tip. git checkout -f did it. I dunno but I always run
it, anyway, it worked now that you mentioned it. ;-)

Additionally,

debian:~# cd linux-2.6/
debian:~/linux-2.6# git log
/usr/local/bin/git-log-script: line 4: less: command not found

Anyway! I can see how it is updated now.

Thanks!

Alejandro

[David S. Miller]

From: Eric Dumazet <da...@cosmosbay.com>
Date: Tue, 13 Sep 2005 09:04:32 +0200

> And if your process has many files opened, the cost (read : latency)
> of open() can be very high, finding a zero bit in a large bit array.
...
> I wish a process param could allow open() to take any free fd
> available, not > the lowest one. One can always use fcntl(fd, F_DUPFD,
> slot) to move a fd on a > specific high slot and always keep the 64
> first fd slots free to speedup the > kernel part at
> open()/dup()/socket() time.

Why not just remember the lowest available free slot and start each
bitmap search there? This is a quite common technique.

[Linus Torvalds]

On Wed, 14 Sep 2005, David S. Miller wrote:
>
> Why not just remember the lowest available free slot and start each
> bitmap search there? This is a quite common technique.

Ehh. That's what "files->next_fd" is (well, now it's in the fdt
structure).

Linus

[Benjamin LaHaise]

On Tue, Sep 13, 2005 at 09:04:32AM +0200, Eric Dumazet wrote:
> I wish a process param could allow open() to take any free fd available,
> not the lowest one. One can always use fcntl(fd, F_DUPFD, slot) to move a
> fd on a specific high slot and always keep the 64 first fd slots free to
> speedup the kernel part at open()/dup()/socket() time.

The overhead is easy to avoid by making use of dup2() and close() to keep
the lowest file descriptors in the table free, allowing open() and socket()
to always return 3 or 4.

Alternatively, the kernel could track available file descriptors using a
tree to efficiently insert freed slots into an ordered list of free
regions (something similar to the avl tree used in vmas). Is it worth
doing?

-ben
--
"Time is what keeps everything from happening all at once." -- John Wheeler

[Linus Torvalds]

On Thu, 15 Sep 2005, Benjamin LaHaise wrote:
>
> Alternatively, the kernel could track available file descriptors using a
> tree to efficiently insert freed slots into an ordered list of free
> regions (something similar to the avl tree used in vmas). Is it worth
> doing?

For file descriptors, even a few hundred is considered a _lot_ in almost
all settings. Yes, you can certainly have more, but it's unusual.

And we keep track of the fd reservations with a bitmap _and_ a "lowest
possible" count. So we can check 32 fd's in one go (64 on modern setups),
starting from the last one we allocated.

In other words, no. It's not worth doing anything more than we already do.

I bet all the expense in this area tends under heavy load to be the
cacheline bouncing of the updates. Keeping the lock close to the bitmap is
probably advantageous, since the bitmap tends to be looked at only when we
need to change them (and we hold the lock).

Linus

[Eric Dumazet]

Benjamin LaHaise a écrit :

> On Tue, Sep 13, 2005 at 09:04:32AM +0200, Eric Dumazet wrote:
>
>>I wish a process param could allow open() to take any free fd available,
>>not the lowest one. One can always use fcntl(fd, F_DUPFD, slot) to move a
>>fd on a specific high slot and always keep the 64 first fd slots free to
>>speedup the kernel part at open()/dup()/socket() time.
>
>
> The overhead is easy to avoid by making use of dup2() and close() to keep
> the lowest file descriptors in the table free, allowing open() and socket()
> to always return 3 or 4.

Yes, this is what I described :) Maybe this was not clear.

>
> Alternatively, the kernel could track available file descriptors using a
> tree to efficiently insert freed slots into an ordered list of free
> regions (something similar to the avl tree used in vmas). Is it worth
> doing?

Well no, since a user app can manage itself this part if it happens to be
performance critical.

Sample of a user land lib : Each time a new fd is returned by
open()/socket()/pipe()/accept()... the thread should call

fd = fdcache_dupfd(fd);

And close the file using fdcache_closefd(fd) instead of close(fd);

Eric

[Eric Dumazet]

Linus Torvalds a écrit :

>
> On Thu, 15 Sep 2005, Benjamin LaHaise wrote:
>
>>Alternatively, the kernel could track available file descriptors using a
>>tree to efficiently insert freed slots into an ordered list of free
>>regions (something similar to the avl tree used in vmas). Is it worth
>>doing?
>
>
> For file descriptors, even a few hundred is considered a _lot_ in almost
> all settings. Yes, you can certainly have more, but it's unusual.
>
> And we keep track of the fd reservations with a bitmap _and_ a "lowest
> possible" count. So we can check 32 fd's in one go (64 on modern setups),
> starting from the last one we allocated.
>
> In other words, no. It's not worth doing anything more than we already do.
>
> I bet all the expense in this area tends under heavy load to be the
> cacheline bouncing of the updates. Keeping the lock close to the bitmap is
> probably advantageous, since the bitmap tends to be looked at only when we
> need to change them (and we hold the lock).

Absolutely :)

Here is the patch I use to :

- place modified bits (file_lock & next_fd) in a separate cache line, reducing
cacheline bouncing for multi threaded apps.
- Reduce the size of struct (files_struct), using small embedded fd_sets
matching fd_array[NR_OPEN_DEFAULT] (ie one long per 'fd_set' instead of 128 bytes)
- 10 % gain on a benchmark ran on a dual HT Xeon 2GHz, one thread per logical CPU.

Eric

Signed-off-by: Eric Dumazet <da...@cosmosbay.com>

[Tomasz Torcz]

On Mon, Sep 12, 2005 at 08:34:17PM -0700, Linus Torvalds wrote:

Linking failure:

LC_ALL=C nice make bzImage modules
CHK include/linux/version.h
CHK include/linux/compile.h
CHK usr/initramfs_list
GEN .version

CHK include/linux/compile.h
UPD include/linux/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1

net/built-in.o(.text+0x53b1a): In function `ip_ct_port_tuple_to_nfattr':
: undefined reference to `__nfa_fill'
net/built-in.o(.text+0x53b5a): In function `ip_ct_port_tuple_to_nfattr':
: undefined reference to `__nfa_fill'
net/built-in.o(.text+0x541cf): In function `tcp_to_nfattr':
: undefined reference to `__nfa_fill'
net/built-in.o(.text+0x55d52): In function `icmp_tuple_to_nfattr':
: undefined reference to `__nfa_fill'
net/built-in.o(.text+0x55d81): In function `icmp_tuple_to_nfattr':
: undefined reference to `__nfa_fill'
net/built-in.o(.text+0x55db0): more undefined references to `__nfa_fill'
follow
make: *** [.tmp_vmlinux1] Error 1

.config attached

--
Tomasz Torcz Morality must always be based on practicality.
zdzichu@irc.-nie.spam-.pl -- Baron Vladimir Harkonnen

[Henrik Persson]

Jesper Juhl wrote:
>>My cardbus is acting funny. When I insert my netgear wg511 (prism54) the
>>first time after booting 2.6.14-rc1 nothing happens. Nothing in dmesg,
>>nothing nowhere. I remove it. Still nothing. Oh well. Inserting again.
>>THEN it initializes and is working like it usually does.
>>
>>2.6.13+Ivan's PCI resource patch worked allright.

Whops. I lied. 2.6.13+Ivan's patch behaves just the same.. Too bad I
didn't test that BEFORE I bisected and recompiled the kernel 12 times. ;/

So..I guess this has something to do with the PCI update in 2.6.13.. Any
pointers to where I should start bisecting this time?

--
Henrik Persson