LinuxLists.cc - Linux 2.6.15-rc6

[permalink] [raw]

Subject: Re: Linux 2.6.15-rc6

Total loss of ACPI C-states (even C1 is unused) has survived from -rc5
to -rc6. See short thread:

[ACPI] Fw: Re: 2.6.15-rc5-mm1
http://marc.theaimsgroup.com/?t=113383872000001&r=1&w=2

The issue seems to be fixed in 2.6.15-rc5-mm3, but no public figure has
explained how or sent any specific patch for it:

[ACPI] Re: 2.6.15-rc5-mm3
http://marc.theaimsgroup.com/?l=acpi4linux&m=113464591421744&w=2

Mvh
Mats Johannesson
--

2005-12-20 13:18:13

[permalink] [raw]

Subject: 2.6.15-rc6: boot failure in saa7134-alsa.c

2.6.15-rc6 doesn't boot on my computer with an Oops that has
drivers/media/video/saa7134/saa7134-alsa.c prominently in it's trace.

A picture of the Oops is at [1] (I won't get a price for the best
picture for it, but it's readable...).

Kernels up to 2.6.14.4 boot fine, 2.6.15-rc1 is the one that introduced
the problem.

I must give saa7134.card=6 at the lilo prompt for getting my card
working.

The saa7134 part of the dmesg in 2.6.14.4:

<-- snip -->

saa7134[0]: found at 0000:00:0e.0, rev: 1, irq: 18, latency: 32, mmio: 0xed800000
saa7134[0]: subsystem: 1131:0000, board: Tevion MD 9717 [card=6,insmod option]
saa7134[0]: board init: gpio is 100a0
saa7134[0]: Huh, no eeprom present (err=-5)?
saa7134[0]: registered device video0 [v4l2]
saa7134[0]: registered device vbi0
saa7134[0]: registered device radio0
tuner 4-0060: chip found @ 0xc0 (saa7134[0])
tuner 4-0060: All bytes are equal. It is not a TEA5767
tuner 4-0060: type set to 5 (Philips PAL_BG (FI1216 and compatibles))

<-- snip -->

cu
Adrian

[1] http://www.fs.tum.de/~bunk/TMP/bootcrash.jpg

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2005-12-20 15:52:29

by Sergey Vlasov

[permalink] [raw]

Subject: Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

On Tue, Dec 20, 2005 at 02:18:10PM +0100, Adrian Bunk wrote:
> 2.6.15-rc6 doesn't boot on my computer with an Oops that has
> drivers/media/video/saa7134/saa7134-alsa.c prominently in it's trace.
>
> A picture of the Oops is at [1] (I won't get a price for the best
> picture for it, but it's readable...).

saa7134-alsa is trying to initialize before the ALSA core has initialized.
Probably no one has tested CONFIG_VIDEO_SAA7134=y.

There is some more brokenness there:

1) With CONFIG_VIDEO_SAA7134=y, both saa7134-alsa.o and saa7134-oss.o will
be built into the kernel, but only the first of them has any chance to be
used - the second will stay as dead code.

2) Both saa7134-alsa and saa7134-oss set dmasound_init and dmasound_exit
function pointers to their functions (for handling of saa7134 cards
hotplugged later), but they do not reset these pointers on unload -
therefore if you load one of these modules, then unload it, then try to
hotplug a saa7134-based card (apparently there are CardBus
implementation), you will get oopses. These assignments in saa7134-alsa
and saa7134-oss also stomp on each other.

> Kernels up to 2.6.14.4 boot fine, 2.6.15-rc1 is the one that introduced
> the problem.
>
> I must give saa7134.card=6 at the lilo prompt for getting my card
> working.

-ECHEAPHARDWARE (sadly, boards without EEPROM are too common).

Attachments:

(No filename) (1.33 kB)
(No filename) (189.00 B)
Download all attachments

2005-12-20 18:28:32

[permalink] [raw]

Subject: Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

On Tue, 20 Dec 2005, Sergey Vlasov wrote:
>
> saa7134-alsa is trying to initialize before the ALSA core has initialized.
> Probably no one has tested CONFIG_VIDEO_SAA7134=y.

Adrian, does it work if you change the "module_init()" in
sound/sound_core.c into a "fs_initcall()"?

That should make sure that the sound core gets to initialize before normal
drivers do.

Linus

2005-12-20 19:14:14

[permalink] [raw]

Subject: Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

On Tue, Dec 20, 2005 at 10:24:55AM -0800, Linus Torvalds wrote:
>
>
> On Tue, 20 Dec 2005, Sergey Vlasov wrote:
> >
> > saa7134-alsa is trying to initialize before the ALSA core has initialized.
> > Probably no one has tested CONFIG_VIDEO_SAA7134=y.
>
> Adrian, does it work if you change the "module_init()" in
> sound/sound_core.c into a "fs_initcall()"?

No, this didn't work.

What did work was to leave sound/sound_core.c alone and make the
module_init() in drivers/media/video/saa7134/saa7134-alsa.c a
late_initcall() (plus disabling building of saa7134-oss.o because
otherwise saa7134-alsa.o wouldn't do anything).

> That should make sure that the sound core gets to initialize before normal
> drivers do.
>
> Linus

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2005-12-20 19:23:52

[permalink] [raw]

Subject: Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

Em Ter, 2005-12-20 ?s 20:14 +0100, Adrian Bunk escreveu:
> On Tue, Dec 20, 2005 at 10:24:55AM -0800, Linus Torvalds wrote:
> >

> What did work was to leave sound/sound_core.c alone and make the
> module_init() in drivers/media/video/saa7134/saa7134-alsa.c a
> late_initcall() (plus disabling building of saa7134-oss.o because
> otherwise saa7134-alsa.o wouldn't do anything).
We have already a patch to solve -oss and -alsa conflict against
v4l-dvb tree. I'll prepare it against -git and submit in a few minutes
to ML for you to test.

> > That should make sure that the sound core gets to initialize before normal
> > drivers do.
> >
> > Linus
>
> cu
> Adrian
>
Cheers,
Mauro.

2005-12-20 20:02:53

[permalink] [raw]

Subject: Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

On Tue, 20 Dec 2005, Adrian Bunk wrote:
>
> > Adrian, does it work if you change the "module_init()" in
> > sound/sound_core.c into a "fs_initcall()"?
>
> No, this didn't work.
>
> What did work was to leave sound/sound_core.c alone

Can you do try the other way again, with sound/core/sound.c fixed too?

A regular driver really _should_ use the regular "module_init()" sequence
(it is indeed just a compatibility define for "driver_init()").

The "late_init()" stuff is meant for stuff that literally runs after
everything else is up and running, it might want all drivers functional
(now, nobody really cares about a sound driver, so in that sense it would
be ok..)

Thanks,

Linus

2005-12-20 20:23:27

[permalink] [raw]

Subject: Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

On Tue, Dec 20, 2005 at 11:59:20AM -0800, Linus Torvalds wrote:
>
>
> On Tue, 20 Dec 2005, Adrian Bunk wrote:
> >
> > > Adrian, does it work if you change the "module_init()" in
> > > sound/sound_core.c into a "fs_initcall()"?
> >
> > No, this didn't work.
> >
> > What did work was to leave sound/sound_core.c alone
>
> Can you do try the other way again, with sound/core/sound.c fixed too?
>...

This works in the sense that the kernel boots and my saa7134 TV card is
giving both audio and video output.

But the non-saa7134 access to my soundcard (e.g. rexima or xmms) is no
longer working.

> Thanks,
>
> Linus

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2005-12-20 20:36:00

by James Courtier-Dutton

[permalink] [raw]

Subject: Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

Linus Torvalds wrote:
>
> On Tue, 20 Dec 2005, Adrian Bunk wrote:
>
>>>Adrian, does it work if you change the "module_init()" in
>>>sound/sound_core.c into a "fs_initcall()"?
>>
>>No, this didn't work.
>>
>>What did work was to leave sound/sound_core.c alone
>
>
> Can you do try the other way again, with sound/core/sound.c fixed too?
>
> A regular driver really _should_ use the regular "module_init()" sequence
> (it is indeed just a compatibility define for "driver_init()").
>
> The "late_init()" stuff is meant for stuff that literally runs after
> everything else is up and running, it might want all drivers functional
> (now, nobody really cares about a sound driver, so in that sense it would
> be ok..)
>
> Thanks,
>
> Linus
>

This is an interesting problem actually.
alsa consists of a number of different modules.
They all load in the correct order if they are modules. The problem
comes when one compiles them into the kernel. They then load in the
wrong order and bad things happen, resulting in the recommendation that
alsa should always be modules.
In this basis, we should not have to change the code in alsa at all, but
instead change the kernel to understand the load order, even if compiled
into the kernel and not as modules.

I have no idea how to get the kernel to do this though. Any pointers?

James

2005-12-20 20:35:40

[permalink] [raw]

Subject: Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

Em Ter, 2005-12-20 ?s 20:14 +0100, Adrian Bunk escreveu:
> (plus disabling building of saa7134-oss.o because
> otherwise saa7134-alsa.o wouldn't do anything).

This patch should fix alsa-oss incompatibilities when both are linked
as module. It will also require either -oss or -alsa if it is statically
linked.

It doesn't address the OOPS because of sound late init.

Adrian,

Please test and give us some feedback.

Cheers,
Mauro.

Attachments:

v4l_dvb_3200_fix_saa7134_alsa_oss_collisions.patch (5.37 kB)

2005-12-20 20:45:25

[permalink] [raw]

Subject: Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

On Tue, 20 Dec 2005, Adrian Bunk wrote:
>
> But the non-saa7134 access to my soundcard (e.g. rexima or xmms) is no
> longer working.

Ahh. I assume it's the sequencer init etc that is missing.

Maybe we'll just have to do the late_init thing for at least the 2.6.15
timeframe.

Linus

2005-12-20 20:47:12

by James Courtier-Dutton

[permalink] [raw]

Subject: Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

Linus Torvalds wrote:
>
> On Tue, 20 Dec 2005, Adrian Bunk wrote:
>
>>But the non-saa7134 access to my soundcard (e.g. rexima or xmms) is no
>>longer working.
>
>
> Ahh. I assume it's the sequencer init etc that is missing.
>
> Maybe we'll just have to do the late_init thing for at least the 2.6.15
> timeframe.
>
> Linus
>

But that's not really a useable fix. The problem is with almost all ALSA
sound cards.

2005-12-20 21:07:23

[permalink] [raw]

Subject: Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

On Tue, 20 Dec 2005, James Courtier-Dutton wrote:
>
> They all load in the correct order if they are modules. The problem comes when
> one compiles them into the kernel. They then load in the wrong order and bad
> things happen, resulting in the recommendation that alsa should always be
> modules.

Which, as a recommendation, is pure and utter crap.

> In this basis, we should not have to change the code in alsa at all, but
> instead change the kernel to understand the load order, even if compiled into
> the kernel and not as modules.

NO.

The kernel does support this (and has supported for a long time).

First off, load order matters, even in the kernel. Within one "class" of
initializers, you can just specify the right order in the Makefile, and it
will honor them. Of course, that ends up often being hard to do across
different directories, which is why there's another facility:

The kernel has several different classes of ordering. Anybody who thinks
that "module_init()" is it, just hasn't looked at <linux/init.h>. There's
seven different levels:

#define core_initcall(fn) __define_initcall("1",fn)
#define postcore_initcall(fn) __define_initcall("2",fn)
#define arch_initcall(fn) __define_initcall("3",fn)
#define subsys_initcall(fn) __define_initcall("4",fn)
#define fs_initcall(fn) __define_initcall("5",fn)
#define device_initcall(fn) __define_initcall("6",fn)
#define late_initcall(fn) __define_initcall("7",fn)

where the next-to-last one is the regular "device_initcall()" (and this is
what a "module_init()" in a compiled-in driver will use).

Now, something like the basic sound subsystem initialization should
obviously NOT be a "device initcall". It's not a device. It's a subsystem
that serves devices, and thus the basic sound initialization should
probably use "subsys_initcall()" instead.

Now, if it's built as a module, that "subsys_initcall()" ends up doing
exactly the same thing as a plain "module_init()", and you'll never see
any difference. But when it's built into the kernel, it means that it gets
initialized with the other subsystems.

Now, one thing to look out for is that if your "core sound initialization"
depends on PCI probing having completed (ie it's not a pure subsystem with
no dependencies on anything else), the common hack for that is to just use
the "fs_initicall()" instead. But a truly independent subsystem (which
sound hopefully is) should just use subsys_initcall(), and then, if that
subsystem internally has more complex ordering, just use the link order in
the Makefiles to indicate that.

> I have no idea how to get the kernel to do this though. Any pointers?

The above should hopefully make the kernel support for this obvious.

I thought more people knew about all this. Forcing (or even just
encouraging) people to use loadable modules is just horrible. I personally
run a kernel with no modules at all: it makes for a simpler bootup, and in
some situations (embedded) it has both security and size advantages.

Linus

2005-12-20 21:10:37

[permalink] [raw]

Subject: Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

On Tue, 20 Dec 2005, James Courtier-Dutton wrote:

> Linus Torvalds wrote:
> >
> > On Tue, 20 Dec 2005, Adrian Bunk wrote:
> >
> > > But the non-saa7134 access to my soundcard (e.g. rexima or xmms) is no
> > > longer working.
> >
> >
> > Ahh. I assume it's the sequencer init etc that is missing.
> >
> > Maybe we'll just have to do the late_init thing for at least the 2.6.15
> > timeframe.
>
> But that's not really a useable fix. The problem is with almost all ALSA sound
> cards.

Right. Which is why the _correct_ fix is certainly to just initialize the
core functionality early.

So the fix is certainly _usable_ (and simple, and guaranteed to not break
anything, which is why it's fine 2.6.15 material), but I certainly agree
that a much better fix would be for a sound core person to walk through
the subsystem initializers, and just mark _those_ early instead.

Hint hint ;)

Linus

2005-12-20 21:14:04

[permalink] [raw]

Subject: [RFC: 2.6 patch] Makefile: sound/ must come before drivers/

On Tue, Dec 20, 2005 at 08:47:09PM +0000, James Courtier-Dutton wrote:
> Linus Torvalds wrote:
> >
> >On Tue, 20 Dec 2005, Adrian Bunk wrote:
> >
> >>But the non-saa7134 access to my soundcard (e.g. rexima or xmms) is no
> >>longer working.
> >
> >
> >Ahh. I assume it's the sequencer init etc that is missing.
> >
> >Maybe we'll just have to do the late_init thing for at least the 2.6.15
> >timeframe.
> >
> > Linus
> >
>
> But that's not really a useable fix. The problem is with almost all ALSA
> sound cards.

No, inside sound/ it's working due to the link order.

Thinking about this, what about the patch below?

I don't know whether this might break anything else, but it fixes my
problem.

cu
Adrian

<-- snip -->

drivers might require an already initialized sound subsystem.

Fix the link order for a static sound subsystem.

Signed-off-by: Adrian Bunk <[email protected]>

--- linux-2.6.15-rc6/Makefile.old 2005-12-20 21:53:26.000000000 +0100
+++ linux-2.6.15-rc6/Makefile 2005-12-20 21:53:42.000000000 +0100
@@ -470,7 +470,7 @@

# Objects we will link into vmlinux / subdirs we need to visit
init-y := init/
-drivers-y := drivers/ sound/
+drivers-y := sound/ drivers/
net-y := net/
libs-y := lib/
core-y := usr/

2005-12-20 21:24:09

by Jaroslav Kysela

[permalink] [raw]

Subject: Re: [Alsa-devel] [RFC: 2.6 patch] Makefile: sound/ must come before drivers/

On Tue, 20 Dec 2005, Adrian Bunk wrote:

> On Tue, Dec 20, 2005 at 08:47:09PM +0000, James Courtier-Dutton wrote:
> > Linus Torvalds wrote:
> > >
> > >On Tue, 20 Dec 2005, Adrian Bunk wrote:
> > >
> > >>But the non-saa7134 access to my soundcard (e.g. rexima or xmms) is no
> > >>longer working.
> > >
> > >
> > >Ahh. I assume it's the sequencer init etc that is missing.
> > >
> > >Maybe we'll just have to do the late_init thing for at least the 2.6.15
> > >timeframe.
> > >
> > > Linus
> > >
> >
> > But that's not really a useable fix. The problem is with almost all ALSA
> > sound cards.
>
> No, inside sound/ it's working due to the link order.
>
> Thinking about this, what about the patch below?
>
> -drivers-y := drivers/ sound/
> +drivers-y := sound/ drivers/

It might break the "video" subsystem, because we have a lowlevel code
for radio tuners in our code.

Basically, everything from /sound/core tree should be initialized at first
before any lowlevel driver is loaded, except /sound/core/oss and
/sound/core/seq/oss subtrees.

Jaroslav

-----
Jaroslav Kysela <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs

2005-12-20 22:13:09

[permalink] [raw]

Subject: Re: [RFC: 2.6 patch] Makefile: sound/ must come before drivers/

On Tue, 20 Dec 2005, Adrian Bunk wrote:
>
> Thinking about this, what about the patch below?
>
> I don't know whether this might break anything else, but it fixes my
> problem.

I'd be much more worried about this than about your patch that just
modifies one driver.

Basically, this would make _all_ sound drivers initialize before the other
drivers, and that just makes me suspect you'll have a lot of new bugs that
get uncovered by the fact that the configuration changed radically.

So I'd much rather either fix one single sound driver (that can't mess up
anything else), or fix the sound _core_ to just initialize in the right
place. Moving _all_ sound drivers earlier sounds risky as hell, for no
good reason.

Linus

2005-12-20 22:14:05

by Lee Revell

[permalink] [raw]

Subject: Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

On Tue, 2005-12-20 at 13:03 -0800, Linus Torvalds wrote:
> Forcing (or even just encouraging) people to use loadable modules is
> just horrible. I personally run a kernel with no modules at all: it
> makes for a simpler bootup, and in some situations (embedded) it has
> both security and size advantages.

With modules it's possible to test a new ALSA version without
recompiling the kernel or even rebooting. Encouraging people to build
it into the kernel would create a problematic barrier to entry for
debugging. With the amount of poorly documented hardware we support,
it's essential for preventing driver regressions for users to be able to
easily test the latest ALSA version.

Lee

2005-12-21 01:33:12

[permalink] [raw]

Subject: Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

On Tue, 20 Dec 2005, Lee Revell wrote:
>
> With modules it's possible to test a new ALSA version without
> recompiling the kernel or even rebooting

That's TOTALLY irrelevant.

Kernel modules work fine for developers. I'm not saying that _you_
shouldn't use modules.

I'm saying that you have absolutely no business telling others not to
compile these things in. Statically compiled drivers have advantages.

Linus

2005-12-21 04:21:12

[permalink] [raw]

Subject: Re: Linux 2.6.15-rc6

I know that C1 isn't much of a power save, but that's what my amd64
notebook provides, and it get used in 2.6.14:

loke@sleipner:~$ cat /proc/acpi/processor/CPU0/power
active state: C1
max_cstate: C8
bus master activity: 00000000
states:
*C1: type[C1] promotion[--] demotion[--] latency[000] usage[01399981]

Not so in 2.6.15-rc2 to -rc6 (report http://marc.theaimsgroup.com/?l=linux-kernel&m=113498252000221&w=2 )
Culprit is the following commit that I humbly ask to be removed/rewritten:

root@sleipner:/home/git/linux-2.6# git bisect bad
2203d6ed448ff3b777ee6bb614a53e686b483e5b is first bad commit
diff-tree 2203d6ed448ff3b777ee6bb614a53e686b483e5b (from 2656c076e31a3ce3ab2a987a578e7122dc2af51d)
Author: Linus Torvalds <[email protected]>
Date: Fri Nov 18 07:29:51 2005 -0800

Fix ACPI processor power block initialization

Properly clear the memory, and set "pr->flags.power" only if a C2 or
deeper state is valid (to make the code match both the comment and
previous behaviour).

This fixes a boot-time lockup reported by Maneesh Soni when using
"maxcpus=1".

Acked-by: Maneesh Soni <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

:040000 040000 52be621b960ae192b36acf778c966d78ff5edbe2 04c183ce141dab8cdff049c1dae379104b637ed4 M drivers

Mvh
Mats Johannesson
--

2005-12-21 05:33:32

[permalink] [raw]

Subject: Re: Linux 2.6.15-rc6

On Wed, 21 Dec 2005, Voluspa wrote:
>
> Not so in 2.6.15-rc2 to -rc6 (report http://marc.theaimsgroup.com/?l=linux-kernel&m=113498252000221&w=2 )
> Culprit is the following commit that I humbly ask to be removed/rewritten:
>
> 2203d6ed448ff3b777ee6bb614a53e686b483e5b:
>
> Fix ACPI processor power block initialization

I'd love to have it fixed, but quite frankly, if the choice is between a
boot-time lockup and not using ACPI C1 sleep states, I'll take the
non-working sleep states.

The code in question had comments that didn't match what it was doing, and
apparently the ACPI guys couldn't say what was wrong..

But it might make sense to open a bugzilla entry so that it doesn't get
lost.

Linus

2005-12-21 05:45:29

[permalink] [raw]

Subject: Re: Linux 2.6.15-rc6

On Tue, 20 Dec 2005 21:33:28 -0800 (PST) Linus Torvalds wrote:
[...]
> > 2203d6ed448ff3b777ee6bb614a53e686b483e5b:
> >
> > Fix ACPI processor power block initialization
>
> I'd love to have it fixed, but quite frankly, if the choice is between a
> boot-time lockup and not using ACPI C1 sleep states, I'll take the
> non-working sleep states.
>
> The code in question had comments that didn't match what it was doing, and
> apparently the ACPI guys couldn't say what was wrong..
>
> But it might make sense to open a bugzilla entry so that it doesn't get
> lost.

No sweat, it's easy to revert locally. I'll open a report once I've registered
at the bugzilla.

God Jul (och se upp med revbenen!)
Mats Johannesson
--

2005-12-21 13:33:57

by Stephen Clark

[permalink] [raw]

Subject: Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

Lee Revell wrote:

>On Tue, 2005-12-20 at 13:03 -0800, Linus Torvalds wrote:
>
>
>>Forcing (or even just encouraging) people to use loadable modules is
>>just horrible. I personally run a kernel with no modules at all: it
>>makes for a simpler bootup, and in some situations (embedded) it has
>>both security and size advantages.
>>
>>
>
>With modules it's possible to test a new ALSA version without
>recompiling the kernel or even rebooting. Encouraging people to build
>it into the kernel would create a problematic barrier to entry for
>debugging. With the amount of poorly documented hardware we support,
>it's essential for preventing driver regressions for users to be able to
>easily test the latest ALSA version.
>
>Lee
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
Users don't want to be testers when they report problems and no on
responds to the problem
report!

My $.02
Steve

2005-12-21 13:52:11

[permalink] [raw]

Subject: Re: Linux 2.6.15-rc6

On Tue, 20 Dec 2005 21:33:28 -0800 (PST) Linus Torvalds wrote:
[...]
> But it might make sense to open a bugzilla entry so that it doesn't get
> lost.

http://bugzilla.kernel.org/show_bug.cgi?id=5767

For anyone stumbling into this problem, lacking git experience, here's
a 1/10-revert patch that gives me back the former functionality. It
behaves exactly as in 2.6.14 with regards to C1 usage and thermal_zone
temperatures etc.

diff -Nur linux-2.6.15-rc6-clean/drivers/acpi/processor_idle.c linux-2.6.15-rc6-c1fix/drivers/acpi/processor_idle.c
--- linux-2.6.15-rc6-clean/drivers/acpi/processor_idle.c 2005-12-21 13:29:12.000000000 +0100
+++ linux-2.6.15-rc6-c1fix/drivers/acpi/processor_idle.c 2005-12-21 13:39:04.000000000 +0100
@@ -893,7 +893,7 @@
for (i = 1; i < ACPI_PROCESSOR_MAX_POWER; i++) {
if (pr->power.states[i].valid) {
pr->power.count = i;
- if (pr->power.states[i].type >= ACPI_STATE_C2)
+ if (pr->power.states[i].type >= ACPI_STATE_C1)
pr->flags.power = 1;
}
}

Mvh
Mats Johannesson
--

2005-12-21 14:18:13

[permalink] [raw]

Subject: Re: [RFC: 2.6 patch] Makefile: sound/ must come before drivers/

At Tue, 20 Dec 2005 14:09:03 -0800 (PST),
Linus Torvalds wrote:
>
>
>
> On Tue, 20 Dec 2005, Adrian Bunk wrote:
> >
> > Thinking about this, what about the patch below?
> >
> > I don't know whether this might break anything else, but it fixes my
> > problem.
>
> I'd be much more worried about this than about your patch that just
> modifies one driver.
>
> Basically, this would make _all_ sound drivers initialize before the other
> drivers, and that just makes me suspect you'll have a lot of new bugs that
> get uncovered by the fact that the configuration changed radically.
>
> So I'd much rather either fix one single sound driver (that can't mess up
> anything else), or fix the sound _core_ to just initialize in the right
> place. Moving _all_ sound drivers earlier sounds risky as hell, for no
> good reason.

Agreed, it looks too radical at this stage.

Another workaround is to move the relevant module to sound/* directory
in order to get a sane initialization order. It's nothing but a
workaround, though.

Takashi

2005-12-21 14:20:05

[permalink] [raw]

Subject: Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

At Tue, 20 Dec 2005 21:23:25 +0100,
Adrian Bunk wrote:
>
> On Tue, Dec 20, 2005 at 11:59:20AM -0800, Linus Torvalds wrote:
> >
> >
> > On Tue, 20 Dec 2005, Adrian Bunk wrote:
> > >
> > > > Adrian, does it work if you change the "module_init()" in
> > > > sound/sound_core.c into a "fs_initcall()"?
> > >
> > > No, this didn't work.
> > >
> > > What did work was to leave sound/sound_core.c alone
> >
> > Can you do try the other way again, with sound/core/sound.c fixed too?
> >...
>
> This works in the sense that the kernel boots and my saa7134 TV card is
> giving both audio and video output.
>
> But the non-saa7134 access to my soundcard (e.g. rexima or xmms) is no
> longer working.

What is missing there? No sound card entry in /proc/asound/cards?
I thought the sequencer stuff Linus pointed out should be harmless as
long as you use only PCM or mixer.

Takashi

2005-12-21 14:36:28

[permalink] [raw]

Subject: Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

At Tue, 20 Dec 2005 13:03:10 -0800 (PST),
Linus Torvalds wrote:
>
>
>
> On Tue, 20 Dec 2005, James Courtier-Dutton wrote:
> >
> > They all load in the correct order if they are modules. The problem comes when
> > one compiles them into the kernel. They then load in the wrong order and bad
> > things happen, resulting in the recommendation that alsa should always be
> > modules.
>
> Which, as a recommendation, is pure and utter crap.
>
> > In this basis, we should not have to change the code in alsa at all, but
> > instead change the kernel to understand the load order, even if compiled into
> > the kernel and not as modules.
>
> NO.
>
> The kernel does support this (and has supported for a long time).
>
> First off, load order matters, even in the kernel. Within one "class" of
> initializers, you can just specify the right order in the Makefile, and it
> will honor them. Of course, that ends up often being hard to do across
> different directories, which is why there's another facility:
>
> The kernel has several different classes of ordering. Anybody who thinks
> that "module_init()" is it, just hasn't looked at <linux/init.h>. There's
> seven different levels:
>
> #define core_initcall(fn) __define_initcall("1",fn)
> #define postcore_initcall(fn) __define_initcall("2",fn)
> #define arch_initcall(fn) __define_initcall("3",fn)
> #define subsys_initcall(fn) __define_initcall("4",fn)
> #define fs_initcall(fn) __define_initcall("5",fn)
> #define device_initcall(fn) __define_initcall("6",fn)
> #define late_initcall(fn) __define_initcall("7",fn)
>
> where the next-to-last one is the regular "device_initcall()" (and this is
> what a "module_init()" in a compiled-in driver will use).
>
> Now, something like the basic sound subsystem initialization should
> obviously NOT be a "device initcall". It's not a device. It's a subsystem
> that serves devices, and thus the basic sound initialization should
> probably use "subsys_initcall()" instead.
>
> Now, if it's built as a module, that "subsys_initcall()" ends up doing
> exactly the same thing as a plain "module_init()", and you'll never see
> any difference. But when it's built into the kernel, it means that it gets
> initialized with the other subsystems.
>
> Now, one thing to look out for is that if your "core sound initialization"
> depends on PCI probing having completed (ie it's not a pure subsystem with
> no dependencies on anything else), the common hack for that is to just use
> the "fs_initicall()" instead. But a truly independent subsystem (which
> sound hopefully is) should just use subsys_initcall(), and then, if that
> subsystem internally has more complex ordering, just use the link order in
> the Makefiles to indicate that.

As far as looking at the codes, it's OK for PCI. PCI is initialized
in postcore, and the only device_initcall is for pci_init(), which
calls fixup for each PCI device. This is no problem because fixup is
called in pci_enable(), too.

But for other subsystems like ISA PnP, it may be broken since some
codes are still using module_init().
(And, interestingly, fs_initcall() is rarely used in the whole fs/
codes! "grep -r fs_initcall linux/fs" hits only one file.)

So, a "safe" solution for the time being appears to be either
- to look through the whole codes and adjust *_initcall() levels,
- to force to build saa7134-alsa as a module, or
- to move saa7134-alsa.c to sound/ directory.

> > I have no idea how to get the kernel to do this though. Any pointers?
>
> The above should hopefully make the kernel support for this obvious.
>
> I thought more people knew about all this. Forcing (or even just
> encouraging) people to use loadable modules is just horrible. I personally
> run a kernel with no modules at all: it makes for a simpler bootup, and in
> some situations (embedded) it has both security and size advantages.

Yep. The driver must work both for modules and built-in. If it
doesn't work, it's called a bug, as we all know :)

Takashi

2005-12-21 16:59:00

by Steve deRosier

[permalink] [raw]

Subject: Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

Linus Torvalds wrote:
>
> I thought more people knew about all this. Forcing (or even just
> encouraging) people to use loadable modules is just horrible. I personally
> run a kernel with no modules at all: it makes for a simpler bootup, and in
> some situations (embedded) it has both security and size advantages.
>

Linus,

I'm glad you said that and I have to second that opinion.

On our current product, we compile everything we need into the kernel; we don't use Alsa as modules at all. Our system is "embedded" as far as the user is concerned (though in many ways is just a general purpose computer running a custom stripped down distribution), and the monolithic kernel is critical to our boot speed (under 1 minute till all services are running) and filesystem size.

In addition, it makes maintenance and porting much easier: Step 1 - reconfigure and recompile the kernel; Step 2 - put bzImage in our update tarball. Easy. I can't imagine what a pain it would be to have to "install" the modules in our filesystem image.

Thankfully, we've never had to deal with this sort of failure; all of our Alsa drivers and services have been well behaved (mostly).

- Steve

2005-12-21 18:22:17

[permalink] [raw]

Subject: Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

On Wed, Dec 21, 2005 at 03:23:09PM +0100, Takashi Iwai wrote:
> At Tue, 20 Dec 2005 21:23:25 +0100,
> Adrian Bunk wrote:
> >
> > On Tue, Dec 20, 2005 at 11:59:20AM -0800, Linus Torvalds wrote:
> > >
> > >
> > > On Tue, 20 Dec 2005, Adrian Bunk wrote:
> > > >
> > > > > Adrian, does it work if you change the "module_init()" in
> > > > > sound/sound_core.c into a "fs_initcall()"?
> > > >
> > > > No, this didn't work.
> > > >
> > > > What did work was to leave sound/sound_core.c alone
> > >
> > > Can you do try the other way again, with sound/core/sound.c fixed too?
> > >...
> >
> > This works in the sense that the kernel boots and my saa7134 TV card is
> > giving both audio and video output.
> >
> > But the non-saa7134 access to my soundcard (e.g. rexima or xmms) is no
> > longer working.
>
> What is missing there? No sound card entry in /proc/asound/cards?
>...

<-- snip -->

0 [SAA7134 ]: SAA7134 - SAA7134
saa7134[0] at 0xed800000 irq 18
1 [V8237 ]: VIA8237 - VIA 8237
VIA 8237 with AD1888 at 0xe000, irq 21

<-- snip -->

What changed compared to the working setup (if the bug is really here)
is the order of the two.

> Takashi

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2005-12-21 18:35:36

[permalink] [raw]

Subject: Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

At Wed, 21 Dec 2005 19:22:14 +0100,
Adrian Bunk wrote:
>
> On Wed, Dec 21, 2005 at 03:23:09PM +0100, Takashi Iwai wrote:
> > At Tue, 20 Dec 2005 21:23:25 +0100,
> > Adrian Bunk wrote:
> > >
> > > On Tue, Dec 20, 2005 at 11:59:20AM -0800, Linus Torvalds wrote:
> > > >
> > > >
> > > > On Tue, 20 Dec 2005, Adrian Bunk wrote:
> > > > >
> > > > > > Adrian, does it work if you change the "module_init()" in
> > > > > > sound/sound_core.c into a "fs_initcall()"?
> > > > >
> > > > > No, this didn't work.
> > > > >
> > > > > What did work was to leave sound/sound_core.c alone
> > > >
> > > > Can you do try the other way again, with sound/core/sound.c fixed too?
> > > >...
> > >
> > > This works in the sense that the kernel boots and my saa7134 TV card is
> > > giving both audio and video output.
> > >
> > > But the non-saa7134 access to my soundcard (e.g. rexima or xmms) is no
> > > longer working.
> >
> > What is missing there? No sound card entry in /proc/asound/cards?
> >...
>
> <-- snip -->
>
> 0 [SAA7134 ]: SAA7134 - SAA7134
> saa7134[0] at 0xed800000 irq 18
> 1 [V8237 ]: VIA8237 - VIA 8237
> VIA 8237 with AD1888 at 0xe000, irq 21
>
> <-- snip -->
>
> What changed compared to the working setup (if the bug is really here)
> is the order of the two.

Well, that's not anyway guaranteed unless you pass the proper index
options.

In the case above, snd_via82xx.index=0 saa7134.index=1 should work.
Or you may tune with udev, too.

Takashi

2005-12-21 18:36:33

[permalink] [raw]

Subject: Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

On Wed, 21 Dec 2005, Steve deRosier wrote:
>
> Thankfully, we've never had to deal with this sort of failure; all of our Alsa
> drivers and services have been well behaved (mostly).

Yes, I think the common case is that built-in _does_ work. I certainly
have used sound that way. This one case is a bit special just because it's
not under the sound/ directory, but I suspect that may be true of some USB
sound"cards" too.

Now, hot-plug devices tend to have a stronger case for being built as
modules, although even there I personally actually end up just building in
the devices I have (whether cardbus cards or things like the USB
printer/mouse/keyboard).

So I don't think sound is terminally broken here, just a few small details
that it gets wrong that causes some odder drivers to not like being built
in.

Linus

2005-12-21 18:37:22

[permalink] [raw]

Subject: Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

On Wed, 21 Dec 2005, Takashi Iwai wrote:
>
> (And, interestingly, fs_initcall() is rarely used in the whole fs/
> codes! "grep -r fs_initcall linux/fs" hits only one file.)

Yes. That thing was probably mis-named. It's much more commonly used for a
"helper subsystem", ie things like pcmcia (that want PCI to be fully
initialized and probed, but want to run before the actual device drivers
start probing).

> So, a "safe" solution for the time being appears to be either
> - to look through the whole codes and adjust *_initcall() levels,
> - to force to build saa7134-alsa as a module, or
> - to move saa7134-alsa.c to sound/ directory.

Well, you dropped the easiest: make saa7134 just use "late_initcall()".

It's not "correct", but it's certainly no less correct than just forcing a
driver to be moved for link order reasons.

Linus

2005-12-21 18:38:08

[permalink] [raw]

Subject: Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

At Wed, 21 Dec 2005 10:32:05 -0800 (PST),
Linus Torvalds wrote:
>
> On Wed, 21 Dec 2005, Steve deRosier wrote:
> >
> > Thankfully, we've never had to deal with this sort of failure; all of our Alsa
> > drivers and services have been well behaved (mostly).
>
> Yes, I think the common case is that built-in _does_ work. I certainly
> have used sound that way. This one case is a bit special just because it's
> not under the sound/ directory, but I suspect that may be true of some USB
> sound"cards" too.

Don't worry, the usb audio/midi drivers are in sound/usb :)
drivers/usb/class/audio and usb-midi are OSS-only and deprecated.

Takashi

2005-12-21 18:48:52

[permalink] [raw]

Subject: Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

At Wed, 21 Dec 2005 10:32:41 -0800 (PST),
Linus Torvalds wrote:
>
> On Wed, 21 Dec 2005, Takashi Iwai wrote:
> >
> > (And, interestingly, fs_initcall() is rarely used in the whole fs/
> > codes! "grep -r fs_initcall linux/fs" hits only one file.)
>
> Yes. That thing was probably mis-named. It's much more commonly used for a
> "helper subsystem", ie things like pcmcia (that want PCI to be fully
> initialized and probed, but want to run before the actual device drivers
> start probing).

I see. Thanks for clarification.

> > So, a "safe" solution for the time being appears to be either
> > - to look through the whole codes and adjust *_initcall() levels,
> > - to force to build saa7134-alsa as a module, or
> > - to move saa7134-alsa.c to sound/ directory.
>
> Well, you dropped the easiest: make saa7134 just use "late_initcall()".
>
> It's not "correct", but it's certainly no less correct than just forcing a
> driver to be moved for link order reasons.

Yep, that's obviously the easiest one. I'd vote for this, at least
for 2.6.15, once after it's confirmed to work.

Takashi

2005-12-21 20:49:21

[permalink] [raw]

Subject: Re: [RFC: 2.6 patch] Makefile: sound/ must come before drivers/

Em Qua, 2005-12-21 ?s 15:21 +0100, Takashi Iwai escreveu:
> > So I'd much rather either fix one single sound driver (that can't
> mess up
> > anything else), or fix the sound _core_ to just initialize in the
> right
> > place. Moving _all_ sound drivers earlier sounds risky as hell, for
> no
> > good reason.
>
> Agreed, it looks too radical at this stage
Agreed.
>
> Another workaround is to move the relevant module to sound/* directory
> in order to get a sane initialization order. It's nothing but a
> workaround, though.
hmmm... this may break saa7134 code, since alsa stuff is dependent of
saa7134.ko.

Cheers,
Mauro.

2005-12-21 22:40:59

[permalink] [raw]

Subject: Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

On Wed, Dec 21, 2005 at 07:38:39PM +0100, Takashi Iwai wrote:
> At Wed, 21 Dec 2005 19:22:14 +0100,
> Adrian Bunk wrote:
> >
> > On Wed, Dec 21, 2005 at 03:23:09PM +0100, Takashi Iwai wrote:
> > > At Tue, 20 Dec 2005 21:23:25 +0100,
> > > Adrian Bunk wrote:
> > > >
> > > > On Tue, Dec 20, 2005 at 11:59:20AM -0800, Linus Torvalds wrote:
> > > > >
> > > > >
> > > > > On Tue, 20 Dec 2005, Adrian Bunk wrote:
> > > > > >
> > > > > > > Adrian, does it work if you change the "module_init()" in
> > > > > > > sound/sound_core.c into a "fs_initcall()"?
> > > > > >
> > > > > > No, this didn't work.
> > > > > >
> > > > > > What did work was to leave sound/sound_core.c alone
> > > > >
> > > > > Can you do try the other way again, with sound/core/sound.c fixed too?
> > > > >...
> > > >
> > > > This works in the sense that the kernel boots and my saa7134 TV card is
> > > > giving both audio and video output.
> > > >
> > > > But the non-saa7134 access to my soundcard (e.g. rexima or xmms) is no
> > > > longer working.
> > >
> > > What is missing there? No sound card entry in /proc/asound/cards?
> > >...
> >
> > <-- snip -->
> >
> > 0 [SAA7134 ]: SAA7134 - SAA7134
> > saa7134[0] at 0xed800000 irq 18
> > 1 [V8237 ]: VIA8237 - VIA 8237
> > VIA 8237 with AD1888 at 0xe000, irq 21
> >
> > <-- snip -->
> >
> > What changed compared to the working setup (if the bug is really here)
> > is the order of the two.
>
> Well, that's not anyway guaranteed unless you pass the proper index
> options.

I'm not sure whether this is really related to my problem:

No matter how they are ordered, shouldn't my soundcard still be
accessible from xmms or rexima?

> In the case above, snd_via82xx.index=0 saa7134.index=1 should work.

This results in my soundcard being no longer available:

<-- snip -->

...
Unknown boot option `saa7134.index=1': ignoring
...
cannot find the slot for index 0 (range 0-0)
VIA 82xx Audio: probe of 0000:00:11.5 failed with error -12
ALSA device list:
#0: saa7134[0] at 0xed800000 irq 18
NET: Registered protocol family 2
...

<-- snip -->

But as said above, I don't suspect the order of the devices being the
problem.

> Or you may tune with udev, too.

-ENOUDEV

> Takashi

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2005-12-21 22:42:30

[permalink] [raw]

Subject: Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

On Wed, Dec 21, 2005 at 07:52:02PM +0100, Takashi Iwai wrote:
> At Wed, 21 Dec 2005 10:32:41 -0800 (PST),
> Linus Torvalds wrote:
>...
> > > So, a "safe" solution for the time being appears to be either
> > > - to look through the whole codes and adjust *_initcall() levels,
> > > - to force to build saa7134-alsa as a module, or
> > > - to move saa7134-alsa.c to sound/ directory.
> >
> > Well, you dropped the easiest: make saa7134 just use "late_initcall()".
> >
> > It's not "correct", but it's certainly no less correct than just forcing a
> > driver to be moved for link order reasons.
>
> Yep, that's obviously the easiest one. I'd vote for this, at least
> for 2.6.15, once after it's confirmed to work.

I've already stated somewhere in this thread that this did fix it for
me.

> Takashi

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2005-12-21 22:51:18

by Ricardo Cerqueira

[permalink] [raw]

Subject: Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

Hi all;

On Wed, 2005-12-21 at 19:52 +0100, Takashi Iwai wrote:
> >
> > Well, you dropped the easiest: make saa7134 just use "late_initcall()".
> >
> > It's not "correct", but it's certainly no less correct than just forcing a
> > driver to be moved for link order reasons.
>
> Yep, that's obviously the easiest one. I'd vote for this, at least
> for 2.6.15, once after it's confirmed to work.
>

I've just confirmed it works with rc6-git2. The driver activates
properly and works as expected.
I've just commited the changes to v4l, Mauro should send them upstream
later.

--
RC

2005-12-22 00:59:44

[permalink] [raw]

Subject: Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

On Tue, Dec 20, 2005 at 06:35:30PM -0200, Mauro Carvalho Chehab wrote:
> Em Ter, 2005-12-20 ?s 20:14 +0100, Adrian Bunk escreveu:
> > (plus disabling building of saa7134-oss.o because
> > otherwise saa7134-alsa.o wouldn't do anything).
>
> This patch should fix alsa-oss incompatibilities when both are linked
> as module. It will also require either -oss or -alsa if it is statically
> linked.
>
> It doesn't address the OOPS because of sound late init.
>
> Adrian,
>
> Please test and give us some feedback.

It works and looks good.

Can we get this patch into 2.6.15?

> Cheers,
> Mauro.

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2005-12-22 01:13:23

[permalink] [raw]

Subject: 2.6.15-rc6: known regressions in the kernel Bugzilla

The following bugs in the kernel Bugzilla [1] contain regressions in
2.6.15-rc compared to 2.6.14 with patches:
- #5632 forcedeth driver occasionally hangs
- #5758 x86_64: PANIC: early exception

The following bug in the kernel Bugzilla contains a regressions in
2.6.15-rc without a patch:
- #5760 No sound with snd_intel8x0 & ALi M5455 chipset
(kobject_register failed)

If we want people to test -rc kernels, we should also try hard to fix
the regressions they report (even more if there are already patches
for them)...

I've Cc'ed all people who might be able comment on one or more of these
issues.

cu
Adrian

[1] http://bugzilla.kernel.org/

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2005-12-22 07:17:37

by Greg KH

[permalink] [raw]

Subject: Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

On Thu, Dec 22, 2005 at 02:13:20AM +0100, Adrian Bunk wrote:
> The following bug in the kernel Bugzilla contains a regressions in
> 2.6.15-rc without a patch:
> - #5760 No sound with snd_intel8x0 & ALi M5455 chipset
> (kobject_register failed)

We put code in the kobjet to report when callers fail, due to problems
in them, and the kobject code is blamed...

Looks like a sound driver issue, nothing has changed in the kobject
code.

thanks,

greg k-h

2005-12-22 08:56:28

by Andrew Morton

[permalink] [raw]

Subject: Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

Adrian Bunk <[email protected]> wrote:
>
> The following bugs in the kernel Bugzilla [1] contain regressions in
> 2.6.15-rc compared to 2.6.14 with patches:

Thanks for tracking this. Although I fear it won't come to much.

non-bugzilla post-2.6.14 bugs which I've squirelled away include:

From: Brice Goglin <[email protected]>
Subject: Linux 2.6.14: Badness in as-iosched

From: Charles-Edouard Ruault <[email protected]>
Subject: [BUG] kernel 2.6.14.2 breaks IPSEC

From: Michael Madore <[email protected]>
Subject: USB handoff, irq 193: nobody cared!

From: Wu Fengguang <[email protected]>
Subject: BUG: spinlock recursion on 2.6.14-mm2 when oprofiling

From: Miles Lane <[email protected]>
Subject: 2.6.15-rc2-git6 + ipw2200 1.0.8 -- Slab corruption

From: "Gottfried Haider" <[email protected]>
Subject: [2.6.15-rc2] 8139too probe fails (pci related?)

From: Steve Work <[email protected]>
Subject: Multi-thread corefiles broken since April

From: Diego Calleja <[email protected]>
Subject: Oops with w9968cf

From: John Reiser <[email protected]>
Subject: control placement of vDSO page

From: "P. Christeas" <[email protected]>
Subject: No sound from CX23880 tuner w. 2.6.15-rc5

Subject: x86_64 timekeeping buglets
From: Jim Houston <[email protected]>

2005-12-22 11:15:59

[permalink] [raw]

Subject: Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

Em Qui, 2005-12-22 ?s 01:59 +0100, Adrian Bunk escreveu:

> > This patch should fix alsa-oss incompatibilities when both are linked
> > as module. It will also require either -oss or -alsa if it is statically
> > linked.
> >
> > It doesn't address the OOPS because of sound late init.
> >
> > Adrian,
> >
> > Please test and give us some feedback.
>
> It works and looks good.
>
> Can we get this patch into 2.6.15?
I've sent today to Linus for him to pull for 2.6.15.

Cheers,
Mauro.

2005-12-22 11:35:53

[permalink] [raw]

Subject: Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

At Wed, 21 Dec 2005 23:40:25 +0100,
Adrian Bunk wrote:
>
> On Wed, Dec 21, 2005 at 07:38:39PM +0100, Takashi Iwai wrote:
> > At Wed, 21 Dec 2005 19:22:14 +0100,
> > Adrian Bunk wrote:
> > >
> > > On Wed, Dec 21, 2005 at 03:23:09PM +0100, Takashi Iwai wrote:
> > > > At Tue, 20 Dec 2005 21:23:25 +0100,
> > > > Adrian Bunk wrote:
> > > > >
> > > > > On Tue, Dec 20, 2005 at 11:59:20AM -0800, Linus Torvalds wrote:
> > > > > >
> > > > > >
> > > > > > On Tue, 20 Dec 2005, Adrian Bunk wrote:
> > > > > > >
> > > > > > > > Adrian, does it work if you change the "module_init()" in
> > > > > > > > sound/sound_core.c into a "fs_initcall()"?
> > > > > > >
> > > > > > > No, this didn't work.
> > > > > > >
> > > > > > > What did work was to leave sound/sound_core.c alone
> > > > > >
> > > > > > Can you do try the other way again, with sound/core/sound.c fixed too?
> > > > > >...
> > > > >
> > > > > This works in the sense that the kernel boots and my saa7134 TV card is
> > > > > giving both audio and video output.
> > > > >
> > > > > But the non-saa7134 access to my soundcard (e.g. rexima or xmms) is no
> > > > > longer working.
> > > >
> > > > What is missing there? No sound card entry in /proc/asound/cards?
> > > >...
> > >
> > > <-- snip -->
> > >
> > > 0 [SAA7134 ]: SAA7134 - SAA7134
> > > saa7134[0] at 0xed800000 irq 18
> > > 1 [V8237 ]: VIA8237 - VIA 8237
> > > VIA 8237 with AD1888 at 0xe000, irq 21
> > >
> > > <-- snip -->
> > >
> > > What changed compared to the working setup (if the bug is really here)
> > > is the order of the two.
> >
> > Well, that's not anyway guaranteed unless you pass the proper index
> > options.
>
> I'm not sure whether this is really related to my problem:
>
> No matter how they are ordered, shouldn't my soundcard still be
> accessible from xmms or rexima?

Yes, it is. You could have accessed to the secondary card from audio
apps. In the case of ALSA, it's accessed via "default:1". For OSS,
via /dev/dsp1.

> > In the case above, snd_via82xx.index=0 saa7134.index=1 should work.
>
> This results in my soundcard being no longer available:
>
> <-- snip -->
>
> ...
> Unknown boot option `saa7134.index=1': ignoring

Sorry, it should be "saa7134_alsa.index=1", of course.

> ...
> cannot find the slot for index 0 (range 0-0)
> VIA 82xx Audio: probe of 0000:00:11.5 failed with error -12
> ALSA device list:
> #0: saa7134[0] at 0xed800000 irq 18
> NET: Registered protocol family 2
> ...
>
> <-- snip -->
>
> But as said above, I don't suspect the order of the devices being the
> problem.

I'm sure it is. The above shows simply confliction of indices.

> > Or you may tune with udev, too.
>
> -ENOUDEV

Still you can remap the device files manually as you like :)

Takashi

2005-12-22 12:01:10

[permalink] [raw]

Subject: Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

At Wed, 21 Dec 2005 23:15:57 -0800,
Greg KH wrote:
>
> On Thu, Dec 22, 2005 at 02:13:20AM +0100, Adrian Bunk wrote:
> > The following bug in the kernel Bugzilla contains a regressions in
> > 2.6.15-rc without a patch:
> > - #5760 No sound with snd_intel8x0 & ALi M5455 chipset
> > (kobject_register failed)
>
> We put code in the kobjet to report when callers fail, due to problems
> in them, and the kobject code is blamed...
>
> Looks like a sound driver issue, nothing has changed in the kobject
> code.

But there is no relevant change in sound stuff between 2.6.15-rc4 and
rc6 (except for minor fix of OSS drivers). If it really worked with
2.6.15-rc4, something else got broken.

Takashi

2005-12-22 13:57:20

[permalink] [raw]

Subject: Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

On Thu, Dec 22, 2005 at 12:52:09AM -0800, Andrew Morton wrote:
> Adrian Bunk <[email protected]> wrote:
> >
> > The following bugs in the kernel Bugzilla [1] contain regressions in
> > 2.6.15-rc compared to 2.6.14 with patches:
>
> Thanks for tracking this. Although I fear it won't come to much.

People had been complaining about a lack of testing prior to the final
release of a kernel.

If this was meant serious, we should try hard to fix all regressions
reported by people who do test -rc and -git kernels.

> non-bugzilla post-2.6.14 bugs which I've squirelled away include:
>
>
> From: Brice Goglin <[email protected]>
> Subject: Linux 2.6.14: Badness in as-iosched

As the subject says, this is not a post-2.6.14 regression.

Besides this, Jens (Cc'ed) sent a patch for it:
http://lkml.org/lkml/2005/11/20/119

Was there a reason why it wasn't applied?

> From: Charles-Edouard Ruault <[email protected]>
> Subject: [BUG] kernel 2.6.14.2 breaks IPSEC

As the subject says, this is not a post-2.6.14 regression.

And reading the discussion on netdev, it seems this wasn't ever expected
to work without additional netfilter patches.

> From: Michael Madore <[email protected]>
> Subject: USB handoff, irq 193: nobody cared!

If this is still present, David should look into it:
http://www.ussg.iu.edu/hypermail/linux/kernel/0511.1/2243.html

> From: Wu Fengguang <[email protected]>
> Subject: BUG: spinlock recursion on 2.6.14-mm2 when oprofiling

If this affects Linus' tree, a patch for it is in -mm.

> From: Miles Lane <[email protected]>
> Subject: 2.6.15-rc2-git6 + ipw2200 1.0.8 -- Slab corruption

As the subject says, this is a problem when using an external version of
this driver.

> From: "Gottfried Haider" <[email protected]>
> Subject: [2.6.15-rc2] 8139too probe fails (pci related?)

According to the report perhaps not a post-2.6.14 regression.

But anyways, this should be better debugged.

@Gottfried:
Does it work with kernel 2.6.14.4?
Does it work with kernel 2.6.15-rc6?
If it stil fails, can you send a complete dmesg for 2.6.15-rc6?

> From: Steve Work <[email protected]>
> Subject: Multi-thread corefiles broken since April

As the subject says, this is not a post-2.6.14 regression.

> From: Diego Calleja <[email protected]>
> Subject: Oops with w9968cf

@Luca, Greg:
http://lkml.org/lkml/2005/12/12/91

> From: John Reiser <[email protected]>
> Subject: control placement of vDSO page

This is not a post-2.6.14 regression.

> From: "P. Christeas" <[email protected]>
> Subject: No sound from CX23880 tuner w. 2.6.15-rc5

No answer by the submitter when being asked for more information.

> Subject: x86_64 timekeeping buglets
> From: Jim Houston <[email protected]>

Reported against 2.6.13, therefore not a post-2.6.14 regression.

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2005-12-22 14:12:43

by Andrew Morton

[permalink] [raw]

Subject: Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

Adrian Bunk <[email protected]> wrote:
>
> not a post-2.6.14 regression
>

Well yeah. But that doesn't mean thse things have lower priority that
post-2.6.14 regressions.

I understand what you're doing here, but we should in general concentrate
upon the most severe bugs rather than upon the most recent..

2005-12-22 15:17:15

by David Miller

[permalink] [raw]

Subject: Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

From: Andrew Morton <[email protected]>
Date: Thu, 22 Dec 2005 00:52:09 -0800

> From: Charles-Edouard Ruault <[email protected]>
> Subject: [BUG] kernel 2.6.14.2 breaks IPSEC

Herbert's reply at the end of the thread explains that what the user
is doing, applying SNAT to IPSEC, has undefined results currently.

Using netfilter with IPSEC is known to be broken since the beginning
of our IPSEC implementation, and we plan to cure it in 2.6.16 with
some excellent work done by Patrick McHardy and Herbert Xu.

So just remove that from your list please, thanks.

2005-12-22 15:29:30

[permalink] [raw]

Subject: Re: [RFC: 2.6 patch] Makefile: sound/ must come before drivers/

At Wed, 21 Dec 2005 18:49:00 -0200,
Mauro Carvalho Chehab wrote:
>
> > Another workaround is to move the relevant module to sound/* directory
> > in order to get a sane initialization order. It's nothing but a
> > workaround, though.
> hmmm... this may break saa7134 code, since alsa stuff is dependent of
> saa7134.ko.

If I understand correctly, it must be OK. Suppose that saa7134-alsa
is moved to sound (only saa7134-alsa, other saa7134 stuff remains in
drivers/media/video), the initialization order will be:
saa7134 -> sound core -> saa7134-alsa.

Or am I missing something else?

Takashi

2005-12-22 16:07:15

[permalink] [raw]

Subject: Re: [RFC: 2.6 patch] Makefile: sound/ must come before drivers/

Em Qui, 2005-12-22 ?s 16:32 +0100, Takashi Iwai escreveu:
> At Wed, 21 Dec 2005 18:49:00 -0200,
> Mauro Carvalho Chehab wrote:
> >
> > > Another workaround is to move the relevant module to sound/* directory
> > > in order to get a sane initialization order. It's nothing but a
> > > workaround, though.
> > hmmm... this may break saa7134 code, since alsa stuff is dependent of
> > saa7134.ko.
>
> If I understand correctly, it must be OK. Suppose that saa7134-alsa
> is moved to sound (only saa7134-alsa, other saa7134 stuff remains in
> drivers/media/video), the initialization order will be:
> saa7134 -> sound core -> saa7134-alsa.
>
> Or am I missing something else?
saa7134-oss.
>
>
> Takashi
>
Cheers,
Mauro.

2005-12-22 16:14:00

[permalink] [raw]

Subject: Re: [RFC: 2.6 patch] Makefile: sound/ must come before drivers/

At Thu, 22 Dec 2005 14:06:57 -0200,
Mauro Carvalho Chehab wrote:
>
> Em Qui, 2005-12-22 ?s 16:32 +0100, Takashi Iwai escreveu:
> > At Wed, 21 Dec 2005 18:49:00 -0200,
> > Mauro Carvalho Chehab wrote:
> > >
> > > > Another workaround is to move the relevant module to sound/* directory
> > > > in order to get a sane initialization order. It's nothing but a
> > > > workaround, though.
> > > hmmm... this may break saa7134 code, since alsa stuff is dependent of
> > > saa7134.ko.
> >
> > If I understand correctly, it must be OK. Suppose that saa7134-alsa
> > is moved to sound (only saa7134-alsa, other saa7134 stuff remains in
> > drivers/media/video), the initialization order will be:
> > saa7134 -> sound core -> saa7134-alsa.
> >
> > Or am I missing something else?
> saa7134-oss.

It's obsolete to me ;)

Takashi

2005-12-22 16:38:39

[permalink] [raw]

Subject: Re: [RFC: 2.6 patch] Makefile: sound/ must come before drivers/

Em Qui, 2005-12-22 ?s 17:17 +0100, Takashi Iwai escreveu:
> > > If I understand correctly, it must be OK. Suppose that
> saa7134-alsa
> > > is moved to sound (only saa7134-alsa, other saa7134 stuff remains
> in
> > > drivers/media/video), the initialization order will be:
> > > saa7134 -> sound core -> saa7134-alsa.
> > >
> > > Or am I missing something else?
> > saa7134-oss.
>
> It's obsolete to me ;)
He hope it will became obsolete soon, but saa-alsa needs more time to
became more mature :) 2.6.15 will be the first mainstream with this
module. People still uses -oss...
>
Cheers,
Mauro.

2005-12-22 17:35:36

by Brice Goglin

[permalink] [raw]

Subject: Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

Adrian Bunk wrote:

>>non-bugzilla post-2.6.14 bugs which I've squirelled away include:
>>
>>
>>From: Brice Goglin <[email protected]>
>>Subject: Linux 2.6.14: Badness in as-iosched
>>
>>
>
>As the subject says, this is not a post-2.6.14 regression.
>
>Besides this, Jens (Cc'ed) sent a patch for it:
> http://lkml.org/lkml/2005/11/20/119
>
>Was there a reason why it wasn't applied?
>
>
Jens also posted a different patch on
http://lkml.org/lkml/2005/11/21/111 addressing my issue. It was supposed
to go in -stable. But, from I see in changelogs, nothing went into
-stable while something similar has been merged into rc3:
http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;h=43fa2049568883d6b5c07cc304b77c93d3091abf;hp=fbe050124ec514431c19091d395fa9065b2398a4;hb=8ad9ebb391e4cd75837ee608b9c33fcaceda0bc2;f=block/as-iosched.c

Anyway, I did not reproduce my problem with the first patch that Jens
sent (applied on top of 2.6.14). 2.6.15-rcX look fine too, but I am not
sure I have stressed those kernels as much as 2.6.14.

Brice

2005-12-22 22:57:16

by Michael Ira Krufky

[permalink] [raw]

Subject: Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

Mauro Carvalho Chehab wrote:

>Em Qui, 2005-12-22 ?s 21:52 +0200, P. Christeas escreveu:
>
>
>>On Thursday 22 December 2005 3:57 pm, you wrote:
>>
>>
>>The two important tags are:
>>v2.6.13 0da688d20078783b23f99b232b272b027d6c3f59
>>v2.6.14-rc1 1f9d1e3248d4eb96b229eecf0e5d9445d3529e85
>>
>>
>Christeas,
>
> Between 2,6,13 and 2.6.14-rc1 we had about 220 v4l patches. It would
>help more if you get v4l CVS tree and try to identify the broken patch.
>there weren't so many patches for cx2388x. I suspect it might be some
>changes at tda9887, cx88-cards or cx88-tvaudio (the latest is the more
>likely).
>
>
Actually, a -git bisection test is even easier, less work involved, and
will point you to the exact patch that caused the regression.

http://www.kernel.org/pub/software/scm/git/docs/howto/isolate-bugs-with-bisect.txt

Cheers,
Michael Krufky

P.S.: I apologize if any cc's got dropped.... I tried to add those that
I know should be here, but the V4L mailing list hosted by RedHat adds a
Reply-To: and drops all the cc's ... I've been flamed about it in the
past, and I complained about it on V4L list-- Alan Cox says this was
intended, and nobody agrees with me that it should be fixed. :-( (this
is my last word on the issue)

2005-12-22 23:12:17

[permalink] [raw]

Subject: Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

On Thu, Dec 22, 2005 at 06:08:27AM -0800, Andrew Morton wrote:
> Adrian Bunk <[email protected]> wrote:
> >
> > not a post-2.6.14 regression
> >
>
> Well yeah. But that doesn't mean thse things have lower priority that
> post-2.6.14 regressions.
>
> I understand what you're doing here, but we should in general concentrate
> upon the most severe bugs rather than upon the most recent..

Regressions are worse than other bugs since they break working setups
after a kernel upgrade, and should therefore be fixed before 2.6.15
gets released.

This should in no way imply that other severe bugs shouldn't be fixed.

One thing why I'm currently pointing to such regressions is that I can't
stand people whining noone would test -rc kernels while we aren't even
able to handle all the regressions reported by people who actually do
test our -rc kernels.

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2005-12-23 01:07:42

by Michael Krufky

[permalink] [raw]

Subject: Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

P. Christeas wrote:

>On Friday 23 December 2005 12:55 am, you wrote:
>
>
>>>Christeas,
>>>
>>> Between 2,6,13 and 2.6.14-rc1 we had about 220 v4l patches. It would
>>>help more if you get v4l CVS tree and try to identify the broken patch.
>>>there weren't so many patches for cx2388x. I suspect it might be some
>>>changes at tda9887, cx88-cards or cx88-tvaudio (the latest is the more
>>>likely).
>>>
>>>
>>Actually, a -git bisection test is even easier, less work involved, and
>>will point you to the exact patch that caused the regression.
>>
>>http://www.kernel.org/pub/software/scm/git/docs/howto/isolate-bugs-with-bis
>>ect.txt
>>
>>Cheers,
>>Michael Krufky
>>
>>
>>
>I just discovered 'bisect', too, and are using it.
>
>Andrew, it would be nice to have a 'limited' bisect when whe know which
>subsystem we are narrowing to:
>git bisect start drivers/media/video/cx88/
>Theoretically speaking, I shouldn't even rebuild but the module alone..
>
>
No, you're incorrect. In many cases, modules from a given subsystem can
break due to a change elsewhere in the kernel.

Did you drop the list cc's on purpose? (re-added)

Regards,

Mike Krufky

2005-12-23 11:50:23

by Gottfried Haider

[permalink] [raw]

Subject: Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

>> From: "Gottfried Haider" <[email protected]>
>> Subject: [2.6.15-rc2] 8139too probe fails (pci related?)
> According to the report perhaps not a post-2.6.14 regression.
> But anyways, this should be better debugged.
>
> @Gottfried:
> Does it work with kernel 2.6.14.4?
> Does it work with kernel 2.6.15-rc6?
> If it stil fails, can you send a complete dmesg for 2.6.15-rc6?
I recently played around with this particular system, and it turned out that
moving the 8139b-card to another PCI slot fixed it. (works now in both
2.6.15-rc2 and rc6-git2)
So I guess it's just a particular oddity of this system, as noone else seems
to hit this?

the original lines in kern.log were
-- snip --
PCI quirk: region e400-e47f claimed by ICH4 ACPI/GPIO/TCO
PCI quirk: region ec00-ec3f claimed by ICH4 GPIO
PCI: Unable to handle 64-bit address for device 0000:01:0c.0
PCI: Transparent bridge - 0000:00:1e.0
(..)
PCI: Cannot allocate resource region 0 of device 0000:01:0c.0
PCI: Cannot allocate resource region 3 of device 0000:01:0c.0
pnp: 00:03: ioport range 0xe400-0xe47f could not be reserved
pnp: 00:03: ioport range 0xec00-0xec3f has been reserved
PCI: Ignore bogus resource 6 [0:0] of 0000:00:02.0
PCI: Error while updating region 0000:01:0c.0/3 (fa800800 != 00000810)
PCI: Error while updating region 0000:01:0c.0/0 (0000d001 != 813910fc)
PCI: Bridge: 0000:00:1e.0
(..)
8139too Fast Ethernet driver 0.9.27
PCI: Device 0000:01:0c.0 not available because of resource collisions
Trying to free nonexistent resource <0000d000-0000d003>
Trying to free nonexistent resource <fa800800-fa80080f>
8139too: probe of 0000:01:0c.0 failed with error -22
-- snip --
.. on a ASUS CUSL2 (i815E) motherboard that was, no change when using
pci=routeirq or pci=noacpi.

Gottfried Haider

2005-12-23 15:27:49

by Bill Davidsen

[permalink] [raw]

Subject: Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

Andrew Morton wrote:
> Adrian Bunk <[email protected]> wrote:
>
>>not a post-2.6.14 regression
>>
>
>
> Well yeah. But that doesn't mean thse things have lower priority that
> post-2.6.14 regressions.
>
> I understand what you're doing here, but we should in general concentrate
> upon the most severe bugs rather than upon the most recent..

Hypocratic oath: "First, do no harm."

If a new kernel version can't make things *better*, at least it
shouldn't make them *worse*. New features are good, performance
improvements are good, breaking working systems with an update is not good.

I'm with Adrian on this, if you want people to test and report with -rc
kernels, then there should be some urgency to addressing the reported
problems.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me

2005-12-23 17:33:04

by Michael Krufky

[permalink] [raw]

Subject: Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

On 12/23/05, Bill Davidsen <[email protected]> wrote:
> Andrew Morton wrote:
> > Adrian Bunk <[email protected]> wrote:
> >
> >>not a post-2.6.14 regression
> >>
> >
> >
> > Well yeah. But that doesn't mean thse things have lower priority that
> > post-2.6.14 regressions.
> >
> > I understand what you're doing here, but we should in general concentrate
> > upon the most severe bugs rather than upon the most recent..
>
> Hypocratic oath: "First, do no harm."
>
> If a new kernel version can't make things *better*, at least it
> shouldn't make them *worse*. New features are good, performance
> improvements are good, breaking working systems with an update is not good.
>
> I'm with Adrian on this, if you want people to test and report with -rc
> kernels, then there should be some urgency to addressing the reported
> problems.

I agree. Quite frankly, I am extremely surprised that this matter is
even up for discussion. Is it really so important to release 2.6.15
before the end of 2005 that we dont even have the time to fix
regressions that have already been reported in older kernels?
ESPECIALLY given that patches are said to be available?

IMHO, I agree that new regressions are most important to fix, but I
feel that old regressions are extremely important to fix as well. If
we know of more regressions that CAN be fixed before a kernel release,
why not do it?

Why should there be any rush to release the next mainline version? To
make it in time for Christmas? A better Christmas gift to the world
would be a new release without regressions, be it a month late, who
cares? (I know -- not likely, but at least we should try)

...and that's my opinion.

-Michael Krufky

2005-12-24 03:55:53

by Andrew Morton

[permalink] [raw]

Subject: Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

Michael Krufky <[email protected]> wrote:
>
> On 12/23/05, Bill Davidsen <[email protected]> wrote:
> > Andrew Morton wrote:
> > > Adrian Bunk <[email protected]> wrote:
> > >
> > >>not a post-2.6.14 regression
> > >>
> > >
> > >
> > > Well yeah. But that doesn't mean thse things have lower priority that
> > > post-2.6.14 regressions.
> > >
> > > I understand what you're doing here, but we should in general concentrate
> > > upon the most severe bugs rather than upon the most recent..
> >
> > Hypocratic oath: "First, do no harm."
> >
> > If a new kernel version can't make things *better*, at least it
> > shouldn't make them *worse*. New features are good, performance
> > improvements are good, breaking working systems with an update is not good.
> >
> > I'm with Adrian on this, if you want people to test and report with -rc
> > kernels, then there should be some urgency to addressing the reported
> > problems.
>
> I agree. Quite frankly, I am extremely surprised that this matter is
> even up for discussion. Is it really so important to release 2.6.15
> before the end of 2005 that we dont even have the time to fix
> regressions that have already been reported in older kernels?

No, the release dates aren't critical at all.

The problem is that if we allow the release to be stalled by bugs it allows
one sluggish maintainer to block the entire kernel. At some point in time
we do need to just give up and hope that the bug will get fixed in 2.6.x.y
or that it'll just magically fix itself later on (this happens, for various
reasons).

We get in the situation where lots of people are sitting there with arms
folded, complaining about lack of a new kernel release while nobody is
actually working on the bugs. Nobody knows why this happens.

> ESPECIALLY given that patches are said to be available?

Things get lost. If there's a patch which needs applying and we've missed
it, please please please rediff it, add your Signed-off-by and loudly mail
the thing out daily.

> IMHO, I agree that new regressions are most important to fix, but I
> feel that old regressions are extremely important to fix as well. If
> we know of more regressions that CAN be fixed before a kernel release,
> why not do it?

Fixing many of these things is not trivial, as I'm sure you know from
personal experience. The great majority are in drivers and, almost
axiomatically, the guy who added the regression cannot reproduce it on his
hardware (otherwise he wouldn't have shipped the diff). So the debugging
process involves drawn out to-and-fro with the reporter. And it requires
quite a bit of work by and help from the original reporter. Depressingly,
developers often just don't bother entering into this process in the first
place and we shed another batch of mainline testers/users.

> Why should there be any rush to release the next mainline version? To
> make it in time for Christmas? A better Christmas gift to the world
> would be a new release without regressions, be it a month late, who
> cares? (I know -- not likely, but at least we should try)

We'll regularly hold up a release due to an identified set of bugs. But if
we do this we need to be very clear on what those bugs are and we need to
be assured that there's a developer actively working on each bug and that
the reporter is responding. Without all of that in place, the whole
release process would get stalled for arbitrary amounts of time.

We need someone who does nothing but track and report upon bugs. It would
be a full-time job. We don't have asuch a person. We hope that individual
maintainers and subsystem maintainers will track the bugs in their area of
responsibility so that such a person is not necessary. But the maintainers
don't do this. You see the result.

2005-12-25 20:23:06

by Bill Davidsen

[permalink] [raw]

Subject: Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

Andrew Morton wrote:

>Michael Krufky <[email protected]> wrote:
>
>
>>On 12/23/05, Bill Davidsen <[email protected]> wrote:
>>
>>
>>>Andrew Morton wrote:
>>>
>>>
>>>>Adrian Bunk <[email protected]> wrote:
>>>>
>>>>
>>>>
>>>>>not a post-2.6.14 regression
>>>>>
>>>>>
>>>>>
>>>>Well yeah. But that doesn't mean thse things have lower priority that
>>>>post-2.6.14 regressions.
>>>>
>>>>I understand what you're doing here, but we should in general concentrate
>>>>upon the most severe bugs rather than upon the most recent..
>>>>
>>>>
>>>Hypocratic oath: "First, do no harm."
>>>
>>>If a new kernel version can't make things *better*, at least it
>>>shouldn't make them *worse*. New features are good, performance
>>>improvements are good, breaking working systems with an update is not good.
>>>
>>>I'm with Adrian on this, if you want people to test and report with -rc
>>>kernels, then there should be some urgency to addressing the reported
>>>problems.
>>>
>>>
>>I agree. Quite frankly, I am extremely surprised that this matter is
>>even up for discussion. Is it really so important to release 2.6.15
>>before the end of 2005 that we dont even have the time to fix
>>regressions that have already been reported in older kernels?
>>
>>
>
>No, the release dates aren't critical at all.
>
>The problem is that if we allow the release to be stalled by bugs it allows
>one sluggish maintainer to block the entire kernel. At some point in time
>we do need to just give up and hope that the bug will get fixed in 2.6.x.y
>or that it'll just magically fix itself later on (this happens, for various
>reasons).
>
>We get in the situation where lots of people are sitting there with arms
>folded, complaining about lack of a new kernel release while nobody is
>actually working on the bugs. Nobody knows why this happens.
>
>
>
>>ESPECIALLY given that patches are said to be available?
>>
>>
>
>Things get lost. If there's a patch which needs applying and we've missed
>it, please please please rediff it, add your Signed-off-by and loudly mail
>the thing out daily.
>
>
>
>>IMHO, I agree that new regressions are most important to fix, but I
>>feel that old regressions are extremely important to fix as well. If
>>we know of more regressions that CAN be fixed before a kernel release,
>>why not do it?
>>
>>
>
>Fixing many of these things is not trivial, as I'm sure you know from
>personal experience. The great majority are in drivers and, almost
>axiomatically, the guy who added the regression cannot reproduce it on his
>hardware (otherwise he wouldn't have shipped the diff). So the debugging
>process involves drawn out to-and-fro with the reporter. And it requires
>quite a bit of work by and help from the original reporter. Depressingly,
>developers often just don't bother entering into this process in the first
>place and we shed another batch of mainline testers/users.
>
>
>
>>Why should there be any rush to release the next mainline version? To
>>make it in time for Christmas? A better Christmas gift to the world
>>would be a new release without regressions, be it a month late, who
>>cares? (I know -- not likely, but at least we should try)
>>
>>
>
>We'll regularly hold up a release due to an identified set of bugs. But if
>we do this we need to be very clear on what those bugs are and we need to
>be assured that there's a developer actively working on each bug and that
>the reporter is responding. Without all of that in place, the whole
>release process would get stalled for arbitrary amounts of time.
>
>
Or after some period of time the code causing the regression gets rolled
back and the patch gets delayed until the regression is fixed or at
least understood. Other than a fix for an exploitable security issue
there are few things added in any mailline release which couldn't wail
until the next mainline or -stable comes out.

Historically patches have been rejected because they were "not the right
way to fix the problem," even though they did work (some of mine during
early SMP days, for example). I would hope that introducing a regression
also qualifies as "not the right way to fix the problem," and
particularly not the right way to introduce some new feature or
performance enhancement.

I suspect that the developer of a patch would be more likely to work on
the regression if it were preventing the fix from going in.

>We need someone who does nothing but track and report upon bugs. It would
>be a full-time job. We don't have asuch a person. We hope that individual
>maintainers and subsystem maintainers will track the bugs in their area of
>responsibility so that such a person is not necessary. But the maintainers
>don't do this. You see the result.
>
>
>
Good luck. Someone qualified to do that job would also be qualified to
do more interesting things...

--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979

2005-12-26 01:59:55

by Michael Krufky

[permalink] [raw]

Subject: Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

On 12/23/05, Andrew Morton <[email protected]> wrote:
> Michael Krufky <[email protected]> wrote:
> >
> > On 12/23/05, Bill Davidsen <[email protected]> wrote:
> > > Andrew Morton wrote:
> > > > Adrian Bunk <[email protected]> wrote:
> > > >
> > > >>not a post-2.6.14 regression
> > > >>
> > > >
> > > >
> > > > Well yeah. But that doesn't mean thse things have lower priority that
> > > > post-2.6.14 regressions.
> > > >
> > > > I understand what you're doing here, but we should in general concentrate
> > > > upon the most severe bugs rather than upon the most recent..
> > >
> > > Hypocratic oath: "First, do no harm."
> > >
> > > If a new kernel version can't make things *better*, at least it
> > > shouldn't make them *worse*. New features are good, performance
> > > improvements are good, breaking working systems with an update is not good.
> > >
> > > I'm with Adrian on this, if you want people to test and report with -rc
> > > kernels, then there should be some urgency to addressing the reported
> > > problems.
> >
> > I agree. Quite frankly, I am extremely surprised that this matter is
> > even up for discussion. Is it really so important to release 2.6.15
> > before the end of 2005 that we dont even have the time to fix
> > regressions that have already been reported in older kernels?
>
> No, the release dates aren't critical at all.
>
> The problem is that if we allow the release to be stalled by bugs it allows
> one sluggish maintainer to block the entire kernel. At some point in time
> we do need to just give up and hope that the bug will get fixed in 2.6.x.y
> or that it'll just magically fix itself later on (this happens, for various
> reasons).
>
> We get in the situation where lots of people are sitting there with arms
> folded, complaining about lack of a new kernel release while nobody is
> actually working on the bugs. Nobody knows why this happens.
>
> > ESPECIALLY given that patches are said to be available?
>
> Things get lost. If there's a patch which needs applying and we've missed
> it, please please please rediff it, add your Signed-off-by and loudly mail
> the thing out daily.
>
> > IMHO, I agree that new regressions are most important to fix, but I
> > feel that old regressions are extremely important to fix as well. If
> > we know of more regressions that CAN be fixed before a kernel release,
> > why not do it?
>
> Fixing many of these things is not trivial, as I'm sure you know from
> personal experience. The great majority are in drivers and, almost
> axiomatically, the guy who added the regression cannot reproduce it on his
> hardware (otherwise he wouldn't have shipped the diff). So the debugging
> process involves drawn out to-and-fro with the reporter. And it requires
> quite a bit of work by and help from the original reporter. Depressingly,
> developers often just don't bother entering into this process in the first
> place and we shed another batch of mainline testers/users.
>
> > Why should there be any rush to release the next mainline version? To
> > make it in time for Christmas? A better Christmas gift to the world
> > would be a new release without regressions, be it a month late, who
> > cares? (I know -- not likely, but at least we should try)
>
> We'll regularly hold up a release due to an identified set of bugs. But if
> we do this we need to be very clear on what those bugs are and we need to
> be assured that there's a developer actively working on each bug and that
> the reporter is responding. Without all of that in place, the whole
> release process would get stalled for arbitrary amounts of time.
>
> We need someone who does nothing but track and report upon bugs. It would
> be a full-time job. We don't have asuch a person. We hope that individual
> maintainers and subsystem maintainers will track the bugs in their area of
> responsibility so that such a person is not necessary. But the maintainers
> don't do this. You see the result.

Fair enough... (not much else I can say to that -- you're right)

... btw, I tested -rc7 and it's smooth as butter...

-MiKE

2005-12-26 02:16:21

by Lee Revell

[permalink] [raw]

Subject: Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

On Fri, 2005-12-23 at 19:54 -0800, Andrew Morton wrote:
> We need someone who does nothing but track and report upon bugs. It
> would be a full-time job. We don't have asuch a person. We hope that
> individual maintainers and subsystem maintainers will track the bugs
> in their area of responsibility so that such a person is not
> necessary. But the maintainers don't do this. You see the result.

I can't believe that of all the vendors and distributors with
Linux-centric business models and multimillion dollar investments in
Linux that someone didn't hire someone to do this years ago. Are they
all hoping that some "weekend hacker" will come along and do it all for
free?

Lee

2005-12-29 13:23:57

[permalink] [raw]

Subject: Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

On Thu, Dec 22, 2005 at 01:04:23PM +0100, Takashi Iwai wrote:
> At Wed, 21 Dec 2005 23:15:57 -0800,
> Greg KH wrote:
> >
> > On Thu, Dec 22, 2005 at 02:13:20AM +0100, Adrian Bunk wrote:
> > > The following bug in the kernel Bugzilla contains a regressions in
> > > 2.6.15-rc without a patch:
> > > - #5760 No sound with snd_intel8x0 & ALi M5455 chipset
> > > (kobject_register failed)
> >
> > We put code in the kobjet to report when callers fail, due to problems
> > in them, and the kobject code is blamed...
> >
> > Looks like a sound driver issue, nothing has changed in the kobject
> > code.
>
> But there is no relevant change in sound stuff between 2.6.15-rc4 and
> rc6 (except for minor fix of OSS drivers). If it really worked with
> 2.6.15-rc4, something else got broken.

I don't know whether this is related to the problem, but the code giving
the "AC'97 1 does not respond - RESET" warning that is present in both
the working and the non-working cases for the submitter looks a bit
fragile.

> Takashi

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2005-12-30 19:32:04

by Lee Revell

[permalink] [raw]

Subject: Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

On Thu, 2005-12-29 at 14:23 +0100, Adrian Bunk wrote:
> On Thu, Dec 22, 2005 at 01:04:23PM +0100, Takashi Iwai wrote:
> > At Wed, 21 Dec 2005 23:15:57 -0800,
> > Greg KH wrote:
> > >
> > > On Thu, Dec 22, 2005 at 02:13:20AM +0100, Adrian Bunk wrote:
> > > > The following bug in the kernel Bugzilla contains a regressions in
> > > > 2.6.15-rc without a patch:
> > > > - #5760 No sound with snd_intel8x0 & ALi M5455 chipset
> > > > (kobject_register failed)
> > >
> > > We put code in the kobjet to report when callers fail, due to problems
> > > in them, and the kobject code is blamed...
> > >
> > > Looks like a sound driver issue, nothing has changed in the kobject
> > > code.
> >
> > But there is no relevant change in sound stuff between 2.6.15-rc4 and
> > rc6 (except for minor fix of OSS drivers). If it really worked with
> > 2.6.15-rc4, something else got broken.
>
> I don't know whether this is related to the problem, but the code giving
> the "AC'97 1 does not respond - RESET" warning that is present in both
> the working and the non-working cases for the submitter looks a bit
> fragile.
>
> > Takashi

Two more post 2.6.14 ALSA regressions that IMHO need to be fixed for
2.6.15:

https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1585
http://music.columbia.edu/pipermail/linux-audio-dev/2005-December/014269.html

Lee

2006-01-02 16:00:32