Linux 2.6.13

Linus Torvalds

unread,

Aug 28, 2005, 8:20:08 PM8/28/05

to

There it is.

The most painful part of 2.6.13 is likely to be the fact that we made x86
use the generic PCI bus setup code for assigning unassigned resources.
That uncovered rather a lot of nasty small details, but should also mean
that a lot of laptops in particular should be able to discover PCI devices
behind bridges that the BIOS hasn't set up.

We've hopefully fixed up all the problems that the longish -rc series
showed, and it shouldn't be that painful, but if you have device problems,
please make a report that at a minimum contains the unified diff of the
output of "lspci -vvx" running on 2.6.12 vs 2.6.13. That might give us
some clues.

The changes since -rc7 are pretty small, full shortlog and diffstat of
that appended.

As to the new world order: I'm actually going to be away for most of next
week, but in general we should now try to do all major merges within the
first two weeks of the release. After that, we go into calm-down mode, and
if you have work that didn't make the cut, you get to wait until 2.6.14.

The plan is that this should bring in the time between releases, so that
even stuff that misses the deadline won't have to wait _too_ long for the
next one.

Linus

----
Al Viro:
bogus iounmap() in emac
bogus function type in qdio
late spinlock initialization in ieee1394/ohci
mmaper_kern.c fixes [buffer overruns]

Alexey Dobriyan:
drivers/hwmon/*: kfree() correct pointers
zfcp: fix compilation due to rports changes

Andi Kleen:
x86_64: update defconfig - reenable fusion
x86_64: Tell VM about holes in nodes

Andreas Herrmann:
zfcp: add rports to enable scsi_add_device to work again

Andreas Schwab:
m68k: fix broken macros causing compile errors

Anton Blanchard:
ppc64: Fix issue with gcc 4.0 compiled kernels

Benjamin Herrenschmidt:
ppc64: Export machine_power_off for therm_pm72 module

Deepak Saxena:
arm: fix IXP4xx flash resource range

Eric W. Biederman:
acpi_shutdown: Only prepare for power off on power_off

Heiko Carstens:
zfcp: bugfix and compile fixes

James Bottomley:
Fix oops in sysfs_hash_and_remove_file()

James Morris:
Fix capifs bug in initialization error path.

Jan Blunck:
sg.c: fix a memory leak in devices seq_file implementation

Jean Delvare:
hwmon: Off-by-one error in fscpos driver

Jens Axboe:
cfq-iosched.c: minor fixes

John McCutchan:
Document idr_get_new_above() semantics, update inotify

Keith Owens:
Export pcibios_bus_to_resource

Linus Torvalds:
Only pre-allocate 256 bytes of cardbio IO range
Ignore disabled ROM resources at setup
Merge HEAD from master.kernel.org:/.../davem/net-2.6.git
Merge refs/heads/upstream-fixes from master.kernel.org:/.../jgarzik/netdev-2.6
Linux v2.6.13

Marcelo Tosatti:
ppc32 8xx: fix m8xx_ide_init() #ifdef

Mark M. Hoffman:
I2C hwmon: kfree fixes

Michael Chan:
[TG3]: Fix ethtool loopback test lockup

NeilBrown:
md: create a MODULE_ALIAS for md corresponding to its block major number.
md: clear the 'recovery' flags when starting an md array.

Paolo 'Blaisorblade' Giarrusso:
Fixup symlink function pointers for hppfs [for 2.6.13]
hppfs: fix symlink error path

Patrick Boettcher:
fix for race problem in DVB USB drivers (dibusb)

Patrick McHardy:
[FIB_TRIE]: Don't ignore negative results from fib_semantic_match

Paul Jackson:
cpu_exclusive sched domains build fix
undo partial cpu_exclusive sched domain disabling
completely disable cpu_exclusive sched domain

Paul Mackerras:
Remove race between con_open and con_close

Ralf Baechle:
6pack Timer initialization
Fix 6pack setting of MAC address

Roland Dreier:
IB: fix use-after-free in user verbs cleanup

Steve French:
Fix oops in fs/locks.c on close of file with pending locks

Jesper Juhl

unread,

Aug 28, 2005, 8:50:07 PM8/28/05

to

On 8/29/05, Linus Torvalds <torv...@osdl.org> wrote:
>
> There it is.
>
http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.13 seems to
be the 2.6.13-rc7 -> 2.6.13 final ChangeLog. Any chance we could get
the full 2.6.12 -> 2.6.13 ChangeLog up there?

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

Jerome Pinot

unread,

Aug 28, 2005, 10:40:09 PM8/28/05

to

>On 8/29/05, Linus Torvalds <...> wrote:
>>
>> There it is.
>>
>http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.13 seems to
>be the 2.6.13-rc7 -> 2.6.13 final ChangeLog. Any chance we could get
>the full 2.6.12 -> 2.6.13 ChangeLog up there?

Using git in the linus tree:
$ git-whatchanged v2.6.12..v2.6.13 --pretty=full

You can get this:

ftp://ngc891.blogdns.net/pub/linux/misc/ChangeLog-2.6.12-2.6.13.txt

Be warn, it's about 3.7MB

--
Jerome Pinot
ftp://ngc891.blogdns.net/pub

Linus Torvalds

unread,

Aug 28, 2005, 11:10:07 PM8/28/05

to

On Mon, 29 Aug 2005, Jesper Juhl wrote:
>
> http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.13 seems to
> be the 2.6.13-rc7 -> 2.6.13 final ChangeLog. Any chance we could get
> the full 2.6.12 -> 2.6.13 ChangeLog up there?

Done.

(Well, it's going to take a while to mirror out).

That's 2.3MB of logs (even the shortlog weighs in at 5000+ lines and
201kB, if anybody cares. I didn't upload that, and the kernel mailing list
limits don't allow me to put it here, but git users can do

git-rev-list --pretty=short v2.6.12..v2.6.13 | git-shortlog

to generate it. You might additionally want to add a "--no-merges" if you
don't want to see people doing non-linear merges).

Linus

Linus Torvalds

unread,

Aug 28, 2005, 11:30:09 PM8/28/05

to

On Mon, 29 Aug 2005, Jerome Pinot wrote:
>
> Using git in the linus tree:
> $ git-whatchanged v2.6.12..v2.6.13 --pretty=full

It's really much nicer to just do

git log --no-merges v2.6.12..v2.6.13

which gives you a much more readable result.

git-whatchanged is useful if you also want to see the files that got
changed (especially with the "-p" flag to see the whole diff), or if you
want to limit it to a specific subsystem ("git-whatchanged drivers/usb"),
but if you just want the log, use "git log".

That "--pretty=full" this gives you committer information (and you can do
it for "git log" too), but most people probably don't care. In fact, you'd
more often find yourself using "--pretty=short", which only shows the
first line ("head-line" - the subject line of an email patch) of the
commit message.

Additionally, you can pipe the output of "git log" to "git-shortlog", and
you'll get the shortlog format (ie head-line only, and sorted by author).

Sadly, some commits ended up missing out on the author field (hey, people
were getting started with git), so you have two commits like this:

commit af25e94d4dcfb9608846242fabdd4e6014e5c9f0
Author: <>
Commit: Tony Luck <tony...@intel.com>

[IA64] Make ia64 die() preempt safe

Signed-off-by: Keith Owens <ka...@sgi.com>
Signed-off-by: Tony Luck <tony...@intel.com>

commit af2c80e926ad5335d00a8d507928aff4e8ff1877
Author: ? <?>
Commit: Thomas Gleixner <tg...@mtd.linutronix.de>

[MTD] ms02-nv: Fix 64bit operation

Replace KSEG1ADDR() with CKSEG1ADDR() as the former does not work for
64-bit configurations anymore.

Signed-off-by: Maciej W. Rozycki <ma...@infradead.org>
Signed-off-by: Thomas Gleixner <tg...@linutronix.de>

where the author does show up thanks to the sign-off lines, but the git
author information was left empty, so the git-shortlog thing has two
unattributed changes ;^p

Linus

Steven Rostedt

unread,

Aug 29, 2005, 7:00:54 AM8/29/05

to

On Sun, 2005-08-28 at 17:17 -0700, Linus Torvalds wrote:

>
> Paul Mackerras:
> Remove race between con_open and con_close

Hey, I'm the first to report this with the fix and Paul gets the credit?
I guess I'll crawl back to my little world (RT) where they actually
appreciate me. :-(

;-)

-- Steve

Nigel Cunningham

unread,

Aug 29, 2005, 8:21:02 AM8/29/05

to

Hi.

On Mon, 2005-08-29 at 20:57, Steven Rostedt wrote:
> On Sun, 2005-08-28 at 17:17 -0700, Linus Torvalds wrote:
>
> >
> > Paul Mackerras:
> > Remove race between con_open and con_close
>
> Hey, I'm the first to report this with the fix and Paul gets the credit?
> I guess I'll crawl back to my little world (RT) where they actually
> appreciate me. :-(

Did you report it or fix it? :>

Regards,

Nigel

>
> ;-)
>
> -- Steve
>
>
> -
> 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/

--
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.

Nigel Cunningham

unread,

Aug 29, 2005, 8:30:20 AM8/29/05

to

Hi.

I have a couple of reports of powering off being broken between
2.6.13-rc7 and 2.6.13 :( (One my computer and one a Suspend2 user). I'll
happily test patches.

Regards,

Nigel

--
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.

-

Jörn Engel

unread,

Aug 29, 2005, 8:30:32 AM8/29/05

to

On Mon, 29 August 2005 22:17:30 +1000, Nigel Cunningham wrote:
> On Mon, 2005-08-29 at 20:57, Steven Rostedt wrote:
> > On Sun, 2005-08-28 at 17:17 -0700, Linus Torvalds wrote:
> >
> > >
> > > Paul Mackerras:
> > > Remove race between con_open and con_close
> >
> > Hey, I'm the first to report this with the fix and Paul gets the credit?
> > I guess I'll crawl back to my little world (RT) where they actually
> > appreciate me. :-(
>
> Did you report it or fix it? :>

Doesn't really matter to me. A good bug report is often 90% of the
work, with the actual fix falling into the misc. category. Testers
really deserve some credit. ;)

Ok, many bug reports are also quite useless. Good testers therefore
deserve even more credit.

Jörn

--
The competent programmer is fully aware of the strictly limited size of
his own skull; therefore he approaches the programming task in full
humility, and among other things he avoids clever tricks like the plague.
-- Edsger W. Dijkstra

Nigel Cunningham

unread,

Aug 29, 2005, 8:30:33 AM8/29/05

to

Hi.

On Mon, 2005-08-29 at 22:25, Jörn Engel wrote:
> On Mon, 29 August 2005 22:17:30 +1000, Nigel Cunningham wrote:
> > On Mon, 2005-08-29 at 20:57, Steven Rostedt wrote:
> > > On Sun, 2005-08-28 at 17:17 -0700, Linus Torvalds wrote:
> > >
> > > >
> > > > Paul Mackerras:
> > > > Remove race between con_open and con_close
> > >
> > > Hey, I'm the first to report this with the fix and Paul gets the credit?
> > > I guess I'll crawl back to my little world (RT) where they actually
> > > appreciate me. :-(
> >
> > Did you report it or fix it? :>
>
> Doesn't really matter to me. A good bug report is often 90% of the
> work, with the actual fix falling into the misc. category. Testers
> really deserve some credit. ;)
>
> Ok, many bug reports are also quite useless. Good testers therefore
> deserve even more credit.

That's true. A bug report that tells me exactly what I need to do to
reproduce the issue is better than gold.

Regards,

Nigel

> Jörn

--
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.

-

Roland Dreier

unread,

Aug 29, 2005, 10:30:11 AM8/29/05

to

>>>>> "Nigel" == Nigel Cunningham <ncunn...@cyclades.com> writes:

Nigel> Hi. I have a couple of reports of powering off being
Nigel> broken between 2.6.13-rc7 and 2.6.13 :( (One my computer
Nigel> and one a Suspend2 user). I'll happily test patches.

Well, there aren't many differences between 2.6.13-rc7 and 2.6.13. If
I had to guess, I would bet the commit below is what broke you. I'm
including a patch that reverts it at the end of this email

BTW, I have no knowledge of this area -- I'm just basing this on pure
changelog reading. So if reverting this patch does fix your system, I
have no idea what the correct fix is.

- R.

commit 8dbddf17824861f2298de093549e6493d9844835
Author: Eric W. Biederman <ebie...@xmission.com>
Date: Sat Aug 27 00:56:18 2005 -0600

[PATCH] acpi_shutdown: Only prepare for power off on power_off

When acpi_sleep_prepare was moved into a shutdown method we
started calling it for all shutdowns.

It appears this triggers some systems to power off on reboot.

Avoid this by only calling acpi_sleep_prepare if we are going to power
off the system.

Signed-off-by: Eric W. Biederman <ebie...@xmission.com>
Signed-off-by: Linus Torvalds <torv...@osdl.org>

diff --git a/drivers/acpi/sleep/poweroff.c b/drivers/acpi/sleep/poweroff.c
--- a/drivers/acpi/sleep/poweroff.c
+++ b/drivers/acpi/sleep/poweroff.c
@@ -55,11 +55,7 @@ void acpi_power_off(void)

static int acpi_shutdown(struct sys_device *x)
{
- if (system_state == SYSTEM_POWER_OFF) {
- /* Prepare if we are going to power off the system */
- return acpi_sleep_prepare(ACPI_STATE_S5);
- }
- return 0;
+ return acpi_sleep_prepare(ACPI_STATE_S5);
}

static struct sysdev_class acpi_sysclass = {

Antonino A. Daplas

unread,

Aug 29, 2005, 10:30:16 AM8/29/05

to

Nigel Cunningham wrote:
> Hi.
>
> On Mon, 2005-08-29 at 20:57, Steven Rostedt wrote:
>> On Sun, 2005-08-28 at 17:17 -0700, Linus Torvalds wrote:
>>
>>> Paul Mackerras:
>>> Remove race between con_open and con_close
>> Hey, I'm the first to report this with the fix and Paul gets the credit?
>> I guess I'll crawl back to my little world (RT) where they actually
>> appreciate me. :-(
>
> Did you report it or fix it? :>
>

Both, actually, with exactly the same patch. In the long changelog, both
Steven and Paul are co-signees but only Paul's name appeared in the short
changelog.

Tony

Steven Rostedt

unread,

Aug 29, 2005, 10:50:16 AM8/29/05

to

On Mon, 2005-08-29 at 22:25 +0800, Antonino A. Daplas wrote:
> Nigel Cunningham wrote:
> > Hi.
> >
> > On Mon, 2005-08-29 at 20:57, Steven Rostedt wrote:
> >> On Sun, 2005-08-28 at 17:17 -0700, Linus Torvalds wrote:
> >>
> >>> Paul Mackerras:
> >>> Remove race between con_open and con_close
> >> Hey, I'm the first to report this with the fix and Paul gets the credit?
> >> I guess I'll crawl back to my little world (RT) where they actually
> >> appreciate me. :-(
> >
> > Did you report it or fix it? :>
> >
>
> Both, actually, with exactly the same patch. In the long changelog, both
> Steven and Paul are co-signees but only Paul's name appeared in the short
> changelog.
>
> Tony

Thanks Tony, but I'm not really upset. My main focus _is_ on what
Ingo's doing in the RT world. I just thought it was amusing that the
one who supplied the patch second got the credit. If it was the other
way around, and Paul was the first to supply the patch and my name
appeared, I would have made a crack at that too. :-)

-- Steve

Linus Torvalds

unread,

Aug 29, 2005, 11:00:29 AM8/29/05

to

On Mon, 29 Aug 2005, Antonino A. Daplas wrote:
>
> Both, actually, with exactly the same patch. In the long changelog, both
> Steven and Paul are co-signees but only Paul's name appeared in the short
> changelog.

git only has one author field. That's not really technically fundamental
(git could be extended to have multiple authors), but it's pretty
fundamental to the work-flow, so in 99% of all cases nothing else makes
sense.

IOW, when I got around to applying the patch, I had two emails with the
same patch to apply, and I picked Paul's explanation and added commentary
about Steven doing the exact same thing in the longer log entry.

I _could_ also have applied both (in different branches) and merged the
two, but since that's not only about three times the work, but also
against my normal workflow, and I'm lazy...

Linus

Steven Rostedt

unread,

Aug 29, 2005, 11:50:07 AM8/29/05

to

Linus,

This is the patch I sent earlier, and you said to send it soon after
2.6.13 is released. I just applied it on 2.6.13 and it it applies fine.
Again, I only tested this on the i386 since that is the only computer I
currently have.

If someone else would like to submit this patch too, and take full
credit for it feel free. Keeps the blame from me ;-)

Description:

It has been reported that the way Linux handles NODEFER for signals is
not consistent with the way other Unix boxes handle it. I've written a
program to test the behavior of how this flag affects signals and had
several reports from people who ran this on various Unix boxes,
confirming that Linux seems to be unique on the way this is handled.

The way NODEFER affects signals on other Unix boxes is as follows:

1) If NODEFER is set, other signals in sa_mask are still blocked.

2) If NODEFER is set and the signal is in sa_mask, then the signal is
still blocked. (Note: this is the behavior of all tested but Linux _and_
NetBSD 2.0 *).

The way NODEFER affects signals on Linux:

1) If NODEFER is set, other signals are _not_ blocked regardless of
sa_mask (Even NetBSD doesn't do this).

2) If NODEFER is set and the signal is in sa_mask, then the signal being
handled is not blocked.

The patch converts signal handling in all current Linux architectures to
the way most Unix boxes work.

Unix boxes that were tested: DU4, AIX 5.2, Irix 6.5, NetBSD 2.0, SFU
3.5 on WinXP, AIX 5.3, Mac OSX, and of course Linux 2.6.13-rcX.

* NetBSD was the only other Unix to behave like Linux on point #2. The
main concern was brought up by point #1 which even NetBSD isn't like
Linux. So with this patch, we leave NetBSD as the lonely one that
behaves differently here with #2.

diff -urp linux-2.6.13-rc6-git4.orig/arch/alpha/kernel/signal.c linux-2.6.13-rc6-git4/arch/alpha/kernel/signal.c
--- linux-2.6.13-rc6-git4.orig/arch/alpha/kernel/signal.c 2005-08-12 21:28:32.000000000 -0400
+++ linux-2.6.13-rc6-git4/arch/alpha/kernel/signal.c 2005-08-12 21:49:55.000000000 -0400
@@ -566,13 +566,12 @@ handle_signal(int sig, struct k_sigactio
if (ka->sa.sa_flags & SA_RESETHAND)
ka->sa.sa_handler = SIG_DFL;

- if (!(ka->sa.sa_flags & SA_NODEFER)) {
- spin_lock_irq(&current->sighand->siglock);
- sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ spin_lock_irq(&current->sighand->siglock);
+ sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ if (!(ka->sa.sa_flags & SA_NODEFER))
sigaddset(&current->blocked,sig);
- recalc_sigpending();
- spin_unlock_irq(&current->sighand->siglock);
- }
+ recalc_sigpending();
+ spin_unlock_irq(&current->sighand->siglock);
}

static inline void
diff -urp linux-2.6.13-rc6-git4.orig/arch/arm/kernel/signal.c linux-2.6.13-rc6-git4/arch/arm/kernel/signal.c
--- linux-2.6.13-rc6-git4.orig/arch/arm/kernel/signal.c 2005-08-12 21:28:32.000000000 -0400
+++ linux-2.6.13-rc6-git4/arch/arm/kernel/signal.c 2005-08-12 21:50:46.000000000 -0400
@@ -658,11 +658,12 @@ handle_signal(unsigned long sig, struct
/*
* Block the signal if we were unsuccessful.
*/
- if (ret != 0 || !(ka->sa.sa_flags & SA_NODEFER)) {
+ if (ret != 0) {
spin_lock_irq(&tsk->sighand->siglock);
sigorsets(&tsk->blocked, &tsk->blocked,
&ka->sa.sa_mask);
- sigaddset(&tsk->blocked, sig);
+ if (!(ka->sa.sa_flags & SA_NODEFER))
+ sigaddset(&tsk->blocked, sig);
recalc_sigpending();
spin_unlock_irq(&tsk->sighand->siglock);
}
diff -urp linux-2.6.13-rc6-git4.orig/arch/arm26/kernel/signal.c linux-2.6.13-rc6-git4/arch/arm26/kernel/signal.c
--- linux-2.6.13-rc6-git4.orig/arch/arm26/kernel/signal.c 2005-08-12 21:28:32.000000000 -0400
+++ linux-2.6.13-rc6-git4/arch/arm26/kernel/signal.c 2005-08-12 22:08:56.000000000 -0400
@@ -454,14 +454,13 @@ handle_signal(unsigned long sig, siginfo
if (ka->sa.sa_flags & SA_ONESHOT)
ka->sa.sa_handler = SIG_DFL;

- if (!(ka->sa.sa_flags & SA_NODEFER)) {
- spin_lock_irq(&tsk->sighand->siglock);
- sigorsets(&tsk->blocked, &tsk->blocked,
- &ka->sa.sa_mask);
+ spin_lock_irq(&tsk->sighand->siglock);
+ sigorsets(&tsk->blocked, &tsk->blocked,
+ &ka->sa.sa_mask);
+ if (!(ka->sa.sa_flags & SA_NODEFER))
sigaddset(&tsk->blocked, sig);
- recalc_sigpending();
- spin_unlock_irq(&tsk->sighand->siglock);
- }
+ recalc_sigpending();
+ spin_unlock_irq(&tsk->sighand->siglock);
return;
}

diff -urp linux-2.6.13-rc6-git4.orig/arch/cris/arch-v10/kernel/signal.c linux-2.6.13-rc6-git4/arch/cris/arch-v10/kernel/signal.c
--- linux-2.6.13-rc6-git4.orig/arch/cris/arch-v10/kernel/signal.c 2005-08-12 21:28:32.000000000 -0400
+++ linux-2.6.13-rc6-git4/arch/cris/arch-v10/kernel/signal.c 2005-08-12 21:51:53.000000000 -0400
@@ -517,13 +517,12 @@ handle_signal(int canrestart, unsigned l
if (ka->sa.sa_flags & SA_ONESHOT)
ka->sa.sa_handler = SIG_DFL;

- if (!(ka->sa.sa_flags & SA_NODEFER)) {
- spin_lock_irq(&current->sighand->siglock);
- sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ spin_lock_irq(&current->sighand->siglock);
+ sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ if (!(ka->sa.sa_flags & SA_NODEFER))
sigaddset(&current->blocked,sig);
- recalc_sigpending();
- spin_unlock_irq(&current->sighand->siglock);
- }
+ recalc_sigpending();
+ spin_unlock_irq(&current->sighand->siglock);
}

/*
diff -urp linux-2.6.13-rc6-git4.orig/arch/cris/arch-v32/kernel/signal.c linux-2.6.13-rc6-git4/arch/cris/arch-v32/kernel/signal.c
--- linux-2.6.13-rc6-git4.orig/arch/cris/arch-v32/kernel/signal.c 2005-08-12 21:28:32.000000000 -0400
+++ linux-2.6.13-rc6-git4/arch/cris/arch-v32/kernel/signal.c 2005-08-12 21:53:01.000000000 -0400
@@ -568,13 +568,12 @@ handle_signal(int canrestart, unsigned l
if (ka->sa.sa_flags & SA_ONESHOT)
ka->sa.sa_handler = SIG_DFL;

- if (!(ka->sa.sa_flags & SA_NODEFER)) {
- spin_lock_irq(&current->sighand->siglock);
- sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ spin_lock_irq(&current->sighand->siglock);
+ sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ if (!(ka->sa.sa_flags & SA_NODEFER))
sigaddset(&current->blocked,sig);
- recalc_sigpending();
- spin_unlock_irq(&current->sighand->siglock);
- }
+ recalc_sigpending();
+ spin_unlock_irq(&current->sighand->siglock);
}

/*
diff -urp linux-2.6.13-rc6-git4.orig/arch/frv/kernel/signal.c linux-2.6.13-rc6-git4/arch/frv/kernel/signal.c
--- linux-2.6.13-rc6-git4.orig/arch/frv/kernel/signal.c 2005-08-12 21:28:32.000000000 -0400
+++ linux-2.6.13-rc6-git4/arch/frv/kernel/signal.c 2005-08-12 21:53:19.000000000 -0400
@@ -506,13 +506,12 @@ static void handle_signal(unsigned long
else
setup_frame(sig, ka, oldset, regs);

- if (!(ka->sa.sa_flags & SA_NODEFER)) {
- spin_lock_irq(&current->sighand->siglock);
- sigorsets(&current->blocked, &current->blocked, &ka->sa.sa_mask);
+ spin_lock_irq(&current->sighand->siglock);
+ sigorsets(&current->blocked, &current->blocked, &ka->sa.sa_mask);
+ if (!(ka->sa.sa_flags & SA_NODEFER))
sigaddset(&current->blocked, sig);
- recalc_sigpending();
- spin_unlock_irq(&current->sighand->siglock);
- }
+ recalc_sigpending();
+ spin_unlock_irq(&current->sighand->siglock);
} /* end handle_signal() */

/*****************************************************************************/
diff -urp linux-2.6.13-rc6-git4.orig/arch/h8300/kernel/signal.c linux-2.6.13-rc6-git4/arch/h8300/kernel/signal.c
--- linux-2.6.13-rc6-git4.orig/arch/h8300/kernel/signal.c 2005-08-12 21:28:32.000000000 -0400
+++ linux-2.6.13-rc6-git4/arch/h8300/kernel/signal.c 2005-08-12 21:53:43.000000000 -0400
@@ -488,13 +488,12 @@ handle_signal(unsigned long sig, siginfo
else
setup_frame(sig, ka, oldset, regs);

- if (!(ka->sa.sa_flags & SA_NODEFER)) {
- spin_lock_irq(&current->sighand->siglock);
- sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ spin_lock_irq(&current->sighand->siglock);
+ sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ if (!(ka->sa.sa_flags & SA_NODEFER))
sigaddset(&current->blocked,sig);
- recalc_sigpending();
- spin_unlock_irq(&current->sighand->siglock);
- }
+ recalc_sigpending();
+ spin_unlock_irq(&current->sighand->siglock);
}

/*
diff -urp linux-2.6.13-rc6-git4.orig/arch/i386/kernel/signal.c linux-2.6.13-rc6-git4/arch/i386/kernel/signal.c
--- linux-2.6.13-rc6-git4.orig/arch/i386/kernel/signal.c 2005-08-12 21:28:32.000000000 -0400
+++ linux-2.6.13-rc6-git4/arch/i386/kernel/signal.c 2005-08-12 21:55:22.000000000 -0400
@@ -577,10 +577,11 @@ handle_signal(unsigned long sig, siginfo
else
ret = setup_frame(sig, ka, oldset, regs);

- if (ret && !(ka->sa.sa_flags & SA_NODEFER)) {
+ if (ret) {
spin_lock_irq(&current->sighand->siglock);
sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
- sigaddset(&current->blocked,sig);
+ if (!(ka->sa.sa_flags & SA_NODEFER))
+ sigaddset(&current->blocked,sig);
recalc_sigpending();
spin_unlock_irq(&current->sighand->siglock);
}
diff -urp linux-2.6.13-rc6-git4.orig/arch/ia64/kernel/signal.c linux-2.6.13-rc6-git4/arch/ia64/kernel/signal.c
--- linux-2.6.13-rc6-git4.orig/arch/ia64/kernel/signal.c 2005-08-12 21:28:32.000000000 -0400
+++ linux-2.6.13-rc6-git4/arch/ia64/kernel/signal.c 2005-08-12 21:56:20.000000000 -0400
@@ -467,15 +467,12 @@ handle_signal (unsigned long sig, struct
if (!setup_frame(sig, ka, info, oldset, scr))
return 0;

- if (!(ka->sa.sa_flags & SA_NODEFER)) {
- spin_lock_irq(&current->sighand->siglock);
- {
- sigorsets(&current->blocked, &current->blocked, &ka->sa.sa_mask);
- sigaddset(&current->blocked, sig);
- recalc_sigpending();
- }
- spin_unlock_irq(&current->sighand->siglock);
- }
+ spin_lock_irq(&current->sighand->siglock);
+ sigorsets(&current->blocked, &current->blocked, &ka->sa.sa_mask);
+ if (!(ka->sa.sa_flags & SA_NODEFER))
+ sigaddset(&current->blocked, sig);
+ recalc_sigpending();
+ spin_unlock_irq(&current->sighand->siglock);
return 1;
}

diff -urp linux-2.6.13-rc6-git4.orig/arch/m32r/kernel/signal.c linux-2.6.13-rc6-git4/arch/m32r/kernel/signal.c
--- linux-2.6.13-rc6-git4.orig/arch/m32r/kernel/signal.c 2005-08-12 21:28:32.000000000 -0400
+++ linux-2.6.13-rc6-git4/arch/m32r/kernel/signal.c 2005-08-12 21:56:35.000000000 -0400
@@ -341,13 +341,12 @@ handle_signal(unsigned long sig, struct
/* Set up the stack frame */
setup_rt_frame(sig, ka, info, oldset, regs);

- if (!(ka->sa.sa_flags & SA_NODEFER)) {
- spin_lock_irq(&current->sighand->siglock);
- sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ spin_lock_irq(&current->sighand->siglock);
+ sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ if (!(ka->sa.sa_flags & SA_NODEFER))
sigaddset(&current->blocked,sig);
- recalc_sigpending();
- spin_unlock_irq(&current->sighand->siglock);
- }
+ recalc_sigpending();
+ spin_unlock_irq(&current->sighand->siglock);
}

/*
diff -urp linux-2.6.13-rc6-git4.orig/arch/m68knommu/kernel/signal.c linux-2.6.13-rc6-git4/arch/m68knommu/kernel/signal.c
--- linux-2.6.13-rc6-git4.orig/arch/m68knommu/kernel/signal.c 2005-08-12 21:28:32.000000000 -0400
+++ linux-2.6.13-rc6-git4/arch/m68knommu/kernel/signal.c 2005-08-12 21:59:41.000000000 -0400
@@ -732,13 +732,12 @@ handle_signal(int sig, struct k_sigactio
if (ka->sa.sa_flags & SA_ONESHOT)
ka->sa.sa_handler = SIG_DFL;

- if (!(ka->sa.sa_flags & SA_NODEFER)) {
- spin_lock_irq(&current->sighand->siglock);
- sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ spin_lock_irq(&current->sighand->siglock);
+ sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ if (!(ka->sa.sa_flags & SA_NODEFER))
sigaddset(&current->blocked,sig);
- recalc_sigpending();
- spin_unlock_irq(&current->sighand->siglock);
- }
+ recalc_sigpending();
+ spin_unlock_irq(&current->sighand->siglock);
}

/*
diff -urp linux-2.6.13-rc6-git4.orig/arch/mips/kernel/irixsig.c linux-2.6.13-rc6-git4/arch/mips/kernel/irixsig.c
--- linux-2.6.13-rc6-git4.orig/arch/mips/kernel/irixsig.c 2005-08-12 21:28:32.000000000 -0400
+++ linux-2.6.13-rc6-git4/arch/mips/kernel/irixsig.c 2005-08-12 22:00:09.000000000 -0400
@@ -155,13 +155,12 @@ static inline void handle_signal(unsigne
else
setup_irix_frame(ka, regs, sig, oldset);

- if (!(ka->sa.sa_flags & SA_NODEFER)) {
- spin_lock_irq(&current->sighand->siglock);
- sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ spin_lock_irq(&current->sighand->siglock);
+ sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ if (!(ka->sa.sa_flags & SA_NODEFER))
sigaddset(&current->blocked,sig);
- recalc_sigpending();
- spin_unlock_irq(&current->sighand->siglock);
- }
+ recalc_sigpending();
+ spin_unlock_irq(&current->sighand->siglock);
}

asmlinkage int do_irix_signal(sigset_t *oldset, struct pt_regs *regs)
diff -urp linux-2.6.13-rc6-git4.orig/arch/mips/kernel/signal32.c linux-2.6.13-rc6-git4/arch/mips/kernel/signal32.c
--- linux-2.6.13-rc6-git4.orig/arch/mips/kernel/signal32.c 2005-08-12 21:28:32.000000000 -0400
+++ linux-2.6.13-rc6-git4/arch/mips/kernel/signal32.c 2005-08-12 22:00:40.000000000 -0400
@@ -751,13 +751,12 @@ static inline void handle_signal(unsigne
else
setup_frame(ka, regs, sig, oldset);

- if (!(ka->sa.sa_flags & SA_NODEFER)) {
- spin_lock_irq(&current->sighand->siglock);
- sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ spin_lock_irq(&current->sighand->siglock);
+ sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ if (!(ka->sa.sa_flags & SA_NODEFER))
sigaddset(&current->blocked,sig);
- recalc_sigpending();
- spin_unlock_irq(&current->sighand->siglock);
- }
+ recalc_sigpending();
+ spin_unlock_irq(&current->sighand->siglock);
}

int do_signal32(sigset_t *oldset, struct pt_regs *regs)
diff -urp linux-2.6.13-rc6-git4.orig/arch/mips/kernel/signal.c linux-2.6.13-rc6-git4/arch/mips/kernel/signal.c
--- linux-2.6.13-rc6-git4.orig/arch/mips/kernel/signal.c 2005-08-12 21:28:32.000000000 -0400
+++ linux-2.6.13-rc6-git4/arch/mips/kernel/signal.c 2005-08-12 22:00:23.000000000 -0400
@@ -425,13 +425,12 @@ static inline void handle_signal(unsigne
setup_frame(ka, regs, sig, oldset);
#endif

- if (!(ka->sa.sa_flags & SA_NODEFER)) {
- spin_lock_irq(&current->sighand->siglock);
- sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ spin_lock_irq(&current->sighand->siglock);
+ sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ if (!(ka->sa.sa_flags & SA_NODEFER))
sigaddset(&current->blocked,sig);
- recalc_sigpending();
- spin_unlock_irq(&current->sighand->siglock);
- }
+ recalc_sigpending();
+ spin_unlock_irq(&current->sighand->siglock);
}

extern int do_signal32(sigset_t *oldset, struct pt_regs *regs);
diff -urp linux-2.6.13-rc6-git4.orig/arch/parisc/kernel/signal.c linux-2.6.13-rc6-git4/arch/parisc/kernel/signal.c
--- linux-2.6.13-rc6-git4.orig/arch/parisc/kernel/signal.c 2005-08-12 21:28:32.000000000 -0400
+++ linux-2.6.13-rc6-git4/arch/parisc/kernel/signal.c 2005-08-12 22:01:00.000000000 -0400
@@ -517,13 +517,12 @@ handle_signal(unsigned long sig, siginfo
if (!setup_rt_frame(sig, ka, info, oldset, regs, in_syscall))
return 0;

- if (!(ka->sa.sa_flags & SA_NODEFER)) {
- spin_lock_irq(&current->sighand->siglock);
- sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ spin_lock_irq(&current->sighand->siglock);
+ sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ if (!(ka->sa.sa_flags & SA_NODEFER))
sigaddset(&current->blocked,sig);
- recalc_sigpending();
- spin_unlock_irq(&current->sighand->siglock);
- }
+ recalc_sigpending();
+ spin_unlock_irq(&current->sighand->siglock);
return 1;
}

diff -urp linux-2.6.13-rc6-git4.orig/arch/ppc/kernel/signal.c linux-2.6.13-rc6-git4/arch/ppc/kernel/signal.c
--- linux-2.6.13-rc6-git4.orig/arch/ppc/kernel/signal.c 2005-08-12 21:28:32.000000000 -0400
+++ linux-2.6.13-rc6-git4/arch/ppc/kernel/signal.c 2005-08-12 22:01:23.000000000 -0400
@@ -759,13 +759,12 @@ int do_signal(sigset_t *oldset, struct p
else
handle_signal(signr, &ka, &info, oldset, regs, newsp);

- if (!(ka.sa.sa_flags & SA_NODEFER)) {
- spin_lock_irq(&current->sighand->siglock);
- sigorsets(&current->blocked,&current->blocked,&ka.sa.sa_mask);
+ spin_lock_irq(&current->sighand->siglock);
+ sigorsets(&current->blocked,&current->blocked,&ka.sa.sa_mask);
+ if (!(ka.sa.sa_flags & SA_NODEFER))
sigaddset(&current->blocked, signr);
- recalc_sigpending();
- spin_unlock_irq(&current->sighand->siglock);
- }
+ recalc_sigpending();
+ spin_unlock_irq(&current->sighand->siglock);

return 1;
}
diff -urp linux-2.6.13-rc6-git4.orig/arch/ppc64/kernel/signal32.c linux-2.6.13-rc6-git4/arch/ppc64/kernel/signal32.c
--- linux-2.6.13-rc6-git4.orig/arch/ppc64/kernel/signal32.c 2005-08-12 21:28:32.000000000 -0400
+++ linux-2.6.13-rc6-git4/arch/ppc64/kernel/signal32.c 2005-08-12 22:02:45.000000000 -0400
@@ -976,11 +976,12 @@ int do_signal32(sigset_t *oldset, struct
else
ret = handle_signal32(signr, &ka, &info, oldset, regs, newsp);

- if (ret && !(ka.sa.sa_flags & SA_NODEFER)) {
+ if (ret) {
spin_lock_irq(&current->sighand->siglock);
sigorsets(&current->blocked, &current->blocked,
&ka.sa.sa_mask);
- sigaddset(&current->blocked, signr);
+ if (!(ka.sa.sa_flags & SA_NODEFER))
+ sigaddset(&current->blocked, signr);
recalc_sigpending();
spin_unlock_irq(&current->sighand->siglock);
}
diff -urp linux-2.6.13-rc6-git4.orig/arch/ppc64/kernel/signal.c linux-2.6.13-rc6-git4/arch/ppc64/kernel/signal.c
--- linux-2.6.13-rc6-git4.orig/arch/ppc64/kernel/signal.c 2005-08-12 21:28:32.000000000 -0400
+++ linux-2.6.13-rc6-git4/arch/ppc64/kernel/signal.c 2005-08-12 22:02:13.000000000 -0400
@@ -481,10 +481,11 @@ static int handle_signal(unsigned long s
/* Set up Signal Frame */
ret = setup_rt_frame(sig, ka, info, oldset, regs);

- if (ret && !(ka->sa.sa_flags & SA_NODEFER)) {
+ if (ret) {
spin_lock_irq(&current->sighand->siglock);
sigorsets(&current->blocked, &current->blocked, &ka->sa.sa_mask);
- sigaddset(&current->blocked,sig);
+ if (!(ka->sa.sa_flags & SA_NODEFER))
+ sigaddset(&current->blocked,sig);
recalc_sigpending();
spin_unlock_irq(&current->sighand->siglock);
}
diff -urp linux-2.6.13-rc6-git4.orig/arch/s390/kernel/compat_signal.c linux-2.6.13-rc6-git4/arch/s390/kernel/compat_signal.c
--- linux-2.6.13-rc6-git4.orig/arch/s390/kernel/compat_signal.c 2005-08-12 21:28:32.000000000 -0400
+++ linux-2.6.13-rc6-git4/arch/s390/kernel/compat_signal.c 2005-08-12 22:03:42.000000000 -0400
@@ -637,12 +637,11 @@ handle_signal32(unsigned long sig, struc
else
setup_frame32(sig, ka, oldset, regs);

- if (!(ka->sa.sa_flags & SA_NODEFER)) {
- spin_lock_irq(&current->sighand->siglock);
- sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ spin_lock_irq(&current->sighand->siglock);
+ sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ if (!(ka->sa.sa_flags & SA_NODEFER))
sigaddset(&current->blocked,sig);
- recalc_sigpending();
- spin_unlock_irq(&current->sighand->siglock);
- }
+ recalc_sigpending();
+ spin_unlock_irq(&current->sighand->siglock);
}

diff -urp linux-2.6.13-rc6-git4.orig/arch/s390/kernel/signal.c linux-2.6.13-rc6-git4/arch/s390/kernel/signal.c
--- linux-2.6.13-rc6-git4.orig/arch/s390/kernel/signal.c 2005-08-12 21:28:32.000000000 -0400
+++ linux-2.6.13-rc6-git4/arch/s390/kernel/signal.c 2005-08-12 22:03:59.000000000 -0400
@@ -429,13 +429,12 @@ handle_signal(unsigned long sig, struct
else
setup_frame(sig, ka, oldset, regs);

- if (!(ka->sa.sa_flags & SA_NODEFER)) {
- spin_lock_irq(&current->sighand->siglock);
- sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ spin_lock_irq(&current->sighand->siglock);
+ sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ if (!(ka->sa.sa_flags & SA_NODEFER))
sigaddset(&current->blocked,sig);
- recalc_sigpending();
- spin_unlock_irq(&current->sighand->siglock);
- }
+ recalc_sigpending();
+ spin_unlock_irq(&current->sighand->siglock);
}

/*
diff -urp linux-2.6.13-rc6-git4.orig/arch/sh/kernel/signal.c linux-2.6.13-rc6-git4/arch/sh/kernel/signal.c
--- linux-2.6.13-rc6-git4.orig/arch/sh/kernel/signal.c 2005-08-12 21:28:32.000000000 -0400
+++ linux-2.6.13-rc6-git4/arch/sh/kernel/signal.c 2005-08-12 22:04:10.000000000 -0400
@@ -546,13 +546,12 @@ handle_signal(unsigned long sig, struct
if (ka->sa.sa_flags & SA_ONESHOT)
ka->sa.sa_handler = SIG_DFL;

- if (!(ka->sa.sa_flags & SA_NODEFER)) {
- spin_lock_irq(&current->sighand->siglock);
- sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ spin_lock_irq(&current->sighand->siglock);
+ sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ if (!(ka->sa.sa_flags & SA_NODEFER))
sigaddset(&current->blocked,sig);
- recalc_sigpending();
- spin_unlock_irq(&current->sighand->siglock);
- }
+ recalc_sigpending();
+ spin_unlock_irq(&current->sighand->siglock);
}

/*
diff -urp linux-2.6.13-rc6-git4.orig/arch/sh64/kernel/signal.c linux-2.6.13-rc6-git4/arch/sh64/kernel/signal.c
--- linux-2.6.13-rc6-git4.orig/arch/sh64/kernel/signal.c 2005-08-12 21:28:32.000000000 -0400
+++ linux-2.6.13-rc6-git4/arch/sh64/kernel/signal.c 2005-08-12 22:04:47.000000000 -0400
@@ -664,13 +664,12 @@ handle_signal(unsigned long sig, siginfo
else
setup_frame(sig, ka, oldset, regs);

- if (!(ka->sa.sa_flags & SA_NODEFER)) {
- spin_lock_irq(&current->sighand->siglock);
- sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ spin_lock_irq(&current->sighand->siglock);
+ sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ if (!(ka->sa.sa_flags & SA_NODEFER))
sigaddset(&current->blocked,sig);
- recalc_sigpending();
- spin_unlock_irq(&current->sighand->siglock);
- }
+ recalc_sigpending();
+ spin_unlock_irq(&current->sighand->siglock);
}

/*
diff -urp linux-2.6.13-rc6-git4.orig/arch/sparc/kernel/signal.c linux-2.6.13-rc6-git4/arch/sparc/kernel/signal.c
--- linux-2.6.13-rc6-git4.orig/arch/sparc/kernel/signal.c 2005-08-12 21:28:32.000000000 -0400
+++ linux-2.6.13-rc6-git4/arch/sparc/kernel/signal.c 2005-08-12 22:04:59.000000000 -0400
@@ -1034,13 +1034,12 @@ handle_signal(unsigned long signr, struc
else
setup_frame(&ka->sa, regs, signr, oldset, info);
}
- if (!(ka->sa.sa_flags & SA_NOMASK)) {
- spin_lock_irq(&current->sighand->siglock);
- sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ spin_lock_irq(&current->sighand->siglock);
+ sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ if (!(ka->sa.sa_flags & SA_NOMASK))
sigaddset(&current->blocked, signr);
- recalc_sigpending();
- spin_unlock_irq(&current->sighand->siglock);
- }
+ recalc_sigpending();
+ spin_unlock_irq(&current->sighand->siglock);
}

static inline void syscall_restart(unsigned long orig_i0, struct pt_regs *regs,
diff -urp linux-2.6.13-rc6-git4.orig/arch/sparc64/kernel/signal32.c linux-2.6.13-rc6-git4/arch/sparc64/kernel/signal32.c
--- linux-2.6.13-rc6-git4.orig/arch/sparc64/kernel/signal32.c 2005-08-12 21:28:32.000000000 -0400
+++ linux-2.6.13-rc6-git4/arch/sparc64/kernel/signal32.c 2005-08-12 22:05:28.000000000 -0400
@@ -1325,13 +1325,12 @@ static inline void handle_signal32(unsig
else
setup_frame32(&ka->sa, regs, signr, oldset, info);
}
- if (!(ka->sa.sa_flags & SA_NOMASK)) {
- spin_lock_irq(&current->sighand->siglock);
- sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ spin_lock_irq(&current->sighand->siglock);
+ sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ if (!(ka->sa.sa_flags & SA_NOMASK))
sigaddset(&current->blocked,signr);
- recalc_sigpending();
- spin_unlock_irq(&current->sighand->siglock);
- }
+ recalc_sigpending();
+ spin_unlock_irq(&current->sighand->siglock);
}

static inline void syscall_restart32(unsigned long orig_i0, struct pt_regs *regs,
diff -urp linux-2.6.13-rc6-git4.orig/arch/sparc64/kernel/signal.c linux-2.6.13-rc6-git4/arch/sparc64/kernel/signal.c
--- linux-2.6.13-rc6-git4.orig/arch/sparc64/kernel/signal.c 2005-08-12 21:28:32.000000000 -0400
+++ linux-2.6.13-rc6-git4/arch/sparc64/kernel/signal.c 2005-08-12 22:05:10.000000000 -0400
@@ -574,13 +574,12 @@ static inline void handle_signal(unsigne
{
setup_rt_frame(ka, regs, signr, oldset,
(ka->sa.sa_flags & SA_SIGINFO) ? info : NULL);
- if (!(ka->sa.sa_flags & SA_NOMASK)) {
- spin_lock_irq(&current->sighand->siglock);
- sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ spin_lock_irq(&current->sighand->siglock);
+ sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ if (!(ka->sa.sa_flags & SA_NOMASK))
sigaddset(&current->blocked,signr);
- recalc_sigpending();
- spin_unlock_irq(&current->sighand->siglock);
- }
+ recalc_sigpending();
+ spin_unlock_irq(&current->sighand->siglock);
}

static inline void syscall_restart(unsigned long orig_i0, struct pt_regs *regs,
diff -urp linux-2.6.13-rc6-git4.orig/arch/um/kernel/signal_kern.c linux-2.6.13-rc6-git4/arch/um/kernel/signal_kern.c
--- linux-2.6.13-rc6-git4.orig/arch/um/kernel/signal_kern.c 2005-08-12 21:28:32.000000000 -0400
+++ linux-2.6.13-rc6-git4/arch/um/kernel/signal_kern.c 2005-08-12 22:06:31.000000000 -0400
@@ -87,12 +87,12 @@ static int handle_signal(struct pt_regs
recalc_sigpending();
spin_unlock_irq(&current->sighand->siglock);
force_sigsegv(signr, current);
- }
- else if(!(ka->sa.sa_flags & SA_NODEFER)){
+ } else {
spin_lock_irq(&current->sighand->siglock);
sigorsets(&current->blocked, &current->blocked,
&ka->sa.sa_mask);
- sigaddset(&current->blocked, signr);
+ if(!(ka->sa.sa_flags & SA_NODEFER))
+ sigaddset(&current->blocked, signr);
recalc_sigpending();
spin_unlock_irq(&current->sighand->siglock);
}
diff -urp linux-2.6.13-rc6-git4.orig/arch/v850/kernel/signal.c linux-2.6.13-rc6-git4/arch/v850/kernel/signal.c
--- linux-2.6.13-rc6-git4.orig/arch/v850/kernel/signal.c 2005-08-12 21:28:32.000000000 -0400
+++ linux-2.6.13-rc6-git4/arch/v850/kernel/signal.c 2005-08-12 22:06:47.000000000 -0400
@@ -462,13 +462,12 @@ handle_signal(unsigned long sig, siginfo
else
setup_frame(sig, ka, oldset, regs);

- if (!(ka->sa.sa_flags & SA_NODEFER)) {
- spin_lock_irq(&current->sighand->siglock);
- sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ spin_lock_irq(&current->sighand->siglock);
+ sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
+ if (!(ka->sa.sa_flags & SA_NODEFER))
sigaddset(&current->blocked,sig);
- recalc_sigpending();
- spin_unlock_irq(&current->sighand->siglock);
- }
+ recalc_sigpending();
+ spin_unlock_irq(&current->sighand->siglock);
}

/*
diff -urp linux-2.6.13-rc6-git4.orig/arch/x86_64/kernel/signal.c linux-2.6.13-rc6-git4/arch/x86_64/kernel/signal.c
--- linux-2.6.13-rc6-git4.orig/arch/x86_64/kernel/signal.c 2005-08-12 21:28:32.000000000 -0400
+++ linux-2.6.13-rc6-git4/arch/x86_64/kernel/signal.c 2005-08-12 22:07:44.000000000 -0400
@@ -394,10 +394,11 @@ handle_signal(unsigned long sig, siginfo
#endif
ret = setup_rt_frame(sig, ka, info, oldset, regs);

- if (ret && !(ka->sa.sa_flags & SA_NODEFER)) {
+ if (ret) {
spin_lock_irq(&current->sighand->siglock);
sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
- sigaddset(&current->blocked,sig);
+ if (!(ka->sa.sa_flags & SA_NODEFER))
+ sigaddset(&current->blocked,sig);
recalc_sigpending();
spin_unlock_irq(&current->sighand->siglock);
}
diff -urp linux-2.6.13-rc6-git4.orig/arch/xtensa/kernel/signal.c linux-2.6.13-rc6-git4/arch/xtensa/kernel/signal.c
--- linux-2.6.13-rc6-git4.orig/arch/xtensa/kernel/signal.c 2005-08-12 21:28:32.000000000 -0400
+++ linux-2.6.13-rc6-git4/arch/xtensa/kernel/signal.c 2005-08-12 22:08:02.000000000 -0400
@@ -702,12 +702,11 @@ int do_signal(struct pt_regs *regs, sigs
if (ka.sa.sa_flags & SA_ONESHOT)
ka.sa.sa_handler = SIG_DFL;

- if (!(ka.sa.sa_flags & SA_NODEFER)) {
- spin_lock_irq(&current->sighand->siglock);
- sigorsets(&current->blocked, &current->blocked, &ka.sa.sa_mask);
+ spin_lock_irq(&current->sighand->siglock);
+ sigorsets(&current->blocked, &current->blocked, &ka.sa.sa_mask);
+ if (!(ka.sa.sa_flags & SA_NODEFER))
sigaddset(&current->blocked, signr);
- recalc_sigpending();
- spin_unlock_irq(&current->sighand->siglock);
- }
+ recalc_sigpending();
+ spin_unlock_irq(&current->sighand->siglock);
return 1;

Steven Rostedt

unread,

Aug 29, 2005, 2:10:16 PM8/29/05

to

[Sorry for the repost, I forgot those magic words above the patch]

Linus,

Description:

-- Steve

Signed-off-by: Steven Rostedt <ros...@goodmis.org>

Masoud Sharbiani

unread,

Aug 29, 2005, 2:30:14 PM8/29/05

to

Sadly, with 2.6.13 (as in with 2.6.13-rc7), it crashes on boot, on a
dual P3 machine
It works just fine when compiled UP.
This bug did NOT exist on 2.6.13-rc6 version.
Through a serial console I captured the following:
---
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing
disabled
at virtual address
00000000
printing
eip:
00000000

*pde =
00000000
Oops: 0000
[#1]
SMP

Modules linked
in:
CPU:
1
EIP: 0060:[<00000000>] Not tainted
VLI
EFLAGS: 00010282
(2.6.13)
EIP is at
stext+0x3feffd68/0x8
eax: 00000000 ebx: ffffe000 ecx: c160e2e0 edx:
effa0000
esi: efc4b874 edi: efc4b800 ebp: c0537300 esp:
effa1f6c
ds: 007b es: 007b ss:
0068
Process swapper (pid: 0, threadinfo=effa0000
task=effd2520)
Stack: c0238c9a efc4b800 efc4b874 c0537300 effa1f90 ffffe000 effa0000
c160e2e0
00000000 c160e2e0 c160e2e0 ffffe000 effa0000 c0537380 c0537300
c0100e10
00000002 00000000 00000000 00000000 00000000 00000000 00000000
00000000
Call
Trace:
[<c0238c9a>]
acpi_processor_idle+0x104/0x2aa
[<c0100e10>]
cpu_idle+0x70/0x80
Code: Bad EIP
value.
<0>Kernel panic - not syncing: Attempted to kill the idle task!
After checking the disassembled vmlinux image, it turns out to be either
at A) Line 279/280 of linux/drivers/acpi_processor_idle.c or B) lines
417 and 418 of the same file.
---

ver_linux output on UP kernel:
Linux dual 2.6.13 #4 Mon Aug 29 12:42:31 EDT 2005 i686 GNU/Linux

Gnu C 3.3.5
Gnu make 3.80
binutils 2.15
util-linux 2.12p
mount 2.12p
module-init-tools 3.1
e2fsprogs 1.35
jfsutils 1.1.6
reiserfsprogs 3.6.19
reiser4progs 1.0.3
xfsprogs 2.6.20
PPP 2.4.2
Linux C Library 2.3.2
Dynamic linker (ldd) 2.3.2
Procps 3.2.4
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 5.2.1
udev 050
Modules Loaded sym53c8xx scsi_transport_spi
--
lspci -vvx diff between 2.6.13 UP kernel and 2.6.12.5 SMP shows nothing
serious:

--- pci-2.6.12 2005-08-29 13:20:43.000000000 -0400
+++ pci-2.6.13 2005-08-29 13:49:10.000000000 -0400
@@ -104,10 +104,11 @@
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 72 (4250ns min, 16000ns max), Cache Line Size: 0x08 (32 bytes)
- Interrupt: pin A routed to IRQ 16
+ Interrupt: pin A routed to IRQ 17
Region 0: I/O ports at e000 [size=256]
Region 1: Memory at d7020000 (32-bit, non-prefetchable) [size=256]
Region 2: Memory at d7021000 (32-bit, non-prefetchable) [size=4K]
+ Expansion ROM at 30000000 [disabled] [size=128K]
Capabilities: [40] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
@@ -121,16 +122,17 @@
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (750ns min, 2000ns max), Cache Line Size: 0x08 (32 bytes)
- Interrupt: pin A routed to IRQ 17
+ Interrupt: pin A routed to IRQ 16
Region 0: I/O ports at e400 [size=256]
Region 1: Memory at d7022000 (32-bit, non-prefetchable) [size=256]
+ Expansion ROM at 30020000 [disabled] [size=64K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable+ DSel=0 DScale=0 PME-
00: 06 11 65 30 07 00 10 02 43 00 00 02 08 20 00 00
10: 01 e4 00 00 00 20 02 d7 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 11 00 14
-30: 00 00 00 00 40 00 00 00 00 00 00 00 01 01 03 08
+30: 00 00 00 00 40 00 00 00 00 00 00 00 00 01 03 08

0000:01:00.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo Banshee (rev 03) (prog-if 00 [VGA])
Subsystem: Diamond Multimedia Systems Monster Fusion AGP
@@ -140,6 +142,7 @@
Region 0: Memory at d0000000 (32-bit, non-prefetchable) [size=32M]
Region 1: Memory at d4000000 (32-bit, prefetchable) [size=32M]
Region 2: I/O ports at a000 [size=256]
+ Expansion ROM at d2000000 [disabled] [size=64K]
Capabilities: [54] AGP version 1.0
Status: RQ=8 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit+ FW- AGP3- Rate=x1
Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none>

Kernel config is as follows:

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.13
# Mon Aug 29 13:53:07 2005
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
# CONFIG_IKCONFIG is not set
# CONFIG_CPUSETS is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0

#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODULE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
CONFIG_MPENTIUM4=y
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_HPET_TIMER is not set
CONFIG_SMP=y
CONFIG_NR_CPUS=8
# CONFIG_SCHED_SMT is not set
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_BKL=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
# CONFIG_X86_MCE_P4THERMAL is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_IRQBALANCE=y
CONFIG_HAVE_DEC_LOCK=y
# CONFIG_REGPARM is not set
CONFIG_SECCOMP=y
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_PHYSICAL_START=0x100000
# CONFIG_KEXEC is not set

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
CONFIG_SOFTWARE_SUSPEND=y
CONFIG_PM_STD_PARTITION=""

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=m
# CONFIG_ACPI_HOTKEY is not set
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
CONFIG_ACPI_IBM=m
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_X86_PM_TIMER is not set
# CONFIG_ACPI_CONTAINER is not set

#
# APM (Advanced Power Management) BIOS Support
#
# CONFIG_APM is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
# CONFIG_PCIEPORTBUS is not set
# CONFIG_PCI_MSI is not set
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=y
CONFIG_ISA_DMA_API=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
# CONFIG_HOTPLUG_CPU is not set

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_IP_TCPDIAG=y
# CONFIG_IP_TCPDIAG_IPV6 is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_BIC=y

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=y
# CONFIG_IP_NF_CT_ACCT is not set
# CONFIG_IP_NF_CONNTRACK_MARK is not set
# CONFIG_IP_NF_CT_PROTO_SCTP is not set
# CONFIG_IP_NF_FTP is not set
# CONFIG_IP_NF_IRC is not set
# CONFIG_IP_NF_TFTP is not set
# CONFIG_IP_NF_AMANDA is not set
CONFIG_IP_NF_QUEUE=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_LIMIT=y
CONFIG_IP_NF_MATCH_IPRANGE=y
CONFIG_IP_NF_MATCH_MAC=y
CONFIG_IP_NF_MATCH_PKTTYPE=y
CONFIG_IP_NF_MATCH_MARK=y
CONFIG_IP_NF_MATCH_MULTIPORT=y
CONFIG_IP_NF_MATCH_TOS=y
CONFIG_IP_NF_MATCH_RECENT=y
CONFIG_IP_NF_MATCH_ECN=y
CONFIG_IP_NF_MATCH_DSCP=y
CONFIG_IP_NF_MATCH_AH_ESP=y
CONFIG_IP_NF_MATCH_LENGTH=y
CONFIG_IP_NF_MATCH_TTL=y
CONFIG_IP_NF_MATCH_TCPMSS=y
CONFIG_IP_NF_MATCH_HELPER=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_MATCH_CONNTRACK=y
CONFIG_IP_NF_MATCH_OWNER=y
# CONFIG_IP_NF_MATCH_ADDRTYPE is not set
# CONFIG_IP_NF_MATCH_REALM is not set
# CONFIG_IP_NF_MATCH_SCTP is not set
# CONFIG_IP_NF_MATCH_COMMENT is not set
# CONFIG_IP_NF_MATCH_HASHLIMIT is not set
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y
CONFIG_IP_NF_TARGET_TCPMSS=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_TARGET_NETMAP=y
CONFIG_IP_NF_TARGET_SAME=y
# CONFIG_IP_NF_NAT_SNMP_BASIC is not set
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_TOS=y
CONFIG_IP_NF_TARGET_ECN=y
CONFIG_IP_NF_TARGET_DSCP=y
CONFIG_IP_NF_TARGET_MARK=y
CONFIG_IP_NF_TARGET_CLASSIFY=y
CONFIG_IP_NF_RAW=m
CONFIG_IP_NF_TARGET_NOTRACK=m
CONFIG_IP_NF_ARPTABLES=y
CONFIG_IP_NF_ARPFILTER=y
CONFIG_IP_NF_ARP_MANGLE=y

#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_SCHED is not set
# CONFIG_NET_CLS_ROUTE is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
# CONFIG_PARPORT_SERIAL is not set
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_1284 is not set

#
# Plug and Play support
#
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set

#
# Protocols
#
# CONFIG_ISAPNP is not set
# CONFIG_PNPBIOS is not set
CONFIG_PNPACPI=y

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
# CONFIG_BLK_DEV_RAM is not set
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_INITRAMFS_SOURCE=""
CONFIG_LBD=y
# CONFIG_CDROM_PKTCDVD is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_ATA_OVER_ETH is not set

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_IDE_TASK_IOCTL is not set

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_CMD640=y
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
# CONFIG_BLK_DEV_IDEPNP is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_SC1200 is not set
CONFIG_BLK_DEV_PIIX=y
# CONFIG_BLK_DEV_IT821X is not set
# CONFIG_BLK_DEV_NS87415 is not set
CONFIG_BLK_DEV_PDC202XX_OLD=y
CONFIG_PDC202XX_BURST=y
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
CONFIG_BLK_DEV_VIA82CXXX=y
# CONFIG_IDE_ARM is not set
# CONFIG_IDE_CHIPSETS is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
CONFIG_SCSI=y
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
CONFIG_CHR_DEV_SG=y
# CONFIG_CHR_DEV_SCH is not set

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set

#
# SCSI Transport Attributes
#
CONFIG_SCSI_SPI_ATTRS=m
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set

#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
CONFIG_SCSI_DPT_I2O=m
# CONFIG_SCSI_IN2000 is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
CONFIG_SCSI_SATA=y
CONFIG_SCSI_SATA_AHCI=m
CONFIG_SCSI_SATA_SVW=m
CONFIG_SCSI_ATA_PIIX=m
CONFIG_SCSI_SATA_NV=m
CONFIG_SCSI_SATA_PROMISE=m
CONFIG_SCSI_SATA_QSTOR=m
CONFIG_SCSI_SATA_SX4=m
CONFIG_SCSI_SATA_SIL=m
CONFIG_SCSI_SATA_SIS=m
CONFIG_SCSI_SATA_ULI=m
CONFIG_SCSI_SATA_VIA=m
CONFIG_SCSI_SATA_VITESSE=m
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_PPA is not set
# CONFIG_SCSI_IMM is not set
# CONFIG_SCSI_NCR53C406A is not set
CONFIG_SCSI_SYM53C8XX_2=m
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
# CONFIG_SCSI_SYM53C8XX_IOMAPPED is not set
CONFIG_SCSI_IPR=m
# CONFIG_SCSI_IPR_TRACE is not set
# CONFIG_SCSI_IPR_DUMP is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
CONFIG_SCSI_QLA2XXX=y
# CONFIG_SCSI_QLA21XX is not set
# CONFIG_SCSI_QLA22XX is not set
# CONFIG_SCSI_QLA2300 is not set
# CONFIG_SCSI_QLA2322 is not set
# CONFIG_SCSI_QLA6312 is not set
# CONFIG_SCSI_QLA24XX is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
# CONFIG_FUSION_SPI is not set
# CONFIG_FUSION_FC is not set

#
# IEEE 1394 (FireWire) support
#
CONFIG_IEEE1394=y

#
# Subsystem Options
#
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
# CONFIG_IEEE1394_OUI_DB is not set
# CONFIG_IEEE1394_EXTRA_CONFIG_ROMS is not set
# CONFIG_IEEE1394_EXPORT_FULL_API is not set

#
# Device Drivers
#

#
# Texas Instruments PCILynx requires I2C
#
CONFIG_IEEE1394_OHCI1394=y

#
# Protocol Drivers
#
# CONFIG_IEEE1394_VIDEO1394 is not set
# CONFIG_IEEE1394_SBP2 is not set
# CONFIG_IEEE1394_ETH1394 is not set
# CONFIG_IEEE1394_DV1394 is not set
CONFIG_IEEE1394_RAWIO=y
# CONFIG_IEEE1394_CMP is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Network device support
#
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_NET_SB1000 is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_CS89x0 is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
CONFIG_VIA_RHINE=y
CONFIG_VIA_RHINE_MMIO=y
# CONFIG_NET_POCKET is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SKGE is not set
# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
CONFIG_S2IO=m
# CONFIG_S2IO_NAPI is not set
# CONFIG_2BUFF_MODE is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
# CONFIG_SERIAL_8250_ACPI is not set
CONFIG_SERIAL_8250_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
CONFIG_PRINTER=y
# CONFIG_LP_CONSOLE is not set
# CONFIG_PPDEV is not set
# CONFIG_TIPAR is not set

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
# CONFIG_RTC is not set
# CONFIG_GEN_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# Ftape, the floppy tape device driver
#
CONFIG_AGP=y
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
CONFIG_AGP_INTEL=y
# CONFIG_AGP_NVIDIA is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_EFFICEON is not set
CONFIG_DRM=y
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_I810 is not set
CONFIG_DRM_I830=y
# CONFIG_DRM_I915 is not set
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
# CONFIG_HANGCHECK_TIMER is not set

#
# TPM devices
#
# CONFIG_TCG_TPM is not set

#
# I2C support
#
# CONFIG_I2C is not set
# CONFIG_I2C_SENSOR is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Hardware Monitoring support
#
CONFIG_HWMON=y
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
# CONFIG_FB is not set
# CONFIG_VIDEO_SELECT is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
CONFIG_SOUND=y

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
CONFIG_SND_SEQUENCER=y
# CONFIG_SND_SEQ_DUMMY is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_SEQUENCER_OSS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set

#
# ISA devices
#
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_ES1688 is not set
# CONFIG_SND_ES18XX is not set
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_INTERWAVE is not set
# CONFIG_SND_INTERWAVE_STB is not set
# CONFIG_SND_OPTI92X_AD1848 is not set
# CONFIG_SND_OPTI92X_CS4231 is not set
# CONFIG_SND_OPTI93X is not set
# CONFIG_SND_SB8 is not set
# CONFIG_SND_SB16 is not set
# CONFIG_SND_SBAWE is not set
# CONFIG_SND_WAVEFRONT is not set
# CONFIG_SND_CMI8330 is not set
# CONFIG_SND_OPL3SA2 is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set

#
# PCI devices
#
CONFIG_SND_AC97_CODEC=y
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
CONFIG_SND_INTEL8X0=y
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_HDA_INTEL is not set

#
# USB devices
#
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_USX2Y is not set

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_SUSPEND is not set
# CONFIG_USB_OTG is not set

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=y
# CONFIG_USB_EHCI_SPLIT_ISO is not set
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
CONFIG_USB_UHCI_HCD=y
# CONFIG_USB_SL811_HCD is not set

#
# USB Device Class drivers
#
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_BLUETOOTH_TTY is not set
# CONFIG_USB_MIDI is not set
# CONFIG_USB_ACM is not set
CONFIG_USB_PRINTER=y

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set

#
# USB Input Devices
#
CONFIG_USB_HID=y
CONFIG_USB_HIDINPUT=y
# CONFIG_HID_FF is not set
# CONFIG_USB_HIDDEV is not set
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_ACECAD is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_MTOUCH is not set
# CONFIG_USB_ITMTOUCH is not set
CONFIG_USB_EGALAX=m
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set
# CONFIG_USB_KEYSPAN_REMOTE is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set

#
# USB Multimedia devices
#
# CONFIG_USB_DABUSB is not set

#
# Video4Linux support is needed for USB Multimedia device support
#

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
CONFIG_USB_MON=y

#
# USB port drivers
#
# CONFIG_USB_USS720 is not set

#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
CONFIG_USB_CYTHERM=m
# CONFIG_USB_PHIDGETKIT is not set
CONFIG_USB_PHIDGETSERVO=m
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TEST is not set

#
# USB DSL modem support
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set

#
# SN Devices
#

#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_FS_POSIX_ACL is not set

#
# XFS support
#
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_INOTIFY=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVPTS_FS_XATTR is not set
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
CONFIG_NFS_FS=y
# CONFIG_NFS_V3 is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
CONFIG_NFSD=y
# CONFIG_NFSD_V3 is not set
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=y
CONFIG_EXPORTFS=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y

#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set

#
# Profiling support
#
CONFIG_PROFILING=y
CONFIG_OPROFILE=y

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
# CONFIG_DEBUG_KERNEL is not set
CONFIG_LOG_BUF_SHIFT=15
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_EARLY_PRINTK=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
# CONFIG_CRYPTO is not set

#
# Hardware crypto devices
#

#
# Library routines
#
# CONFIG_CRC_CCITT is not set
CONFIG_CRC32=y
CONFIG_LIBCRC32C=m
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_PC=y
--

cheers,
Masoud

Lee Revell

unread,

Aug 29, 2005, 4:20:15 PM8/29/05

to

On Mon, 2005-08-29 at 14:23 -0400, Masoud Sharbiani wrote:
> Sadly, with 2.6.13 (as in with 2.6.13-rc7), it crashes on boot, on a
> dual P3 machine
> It works just fine when compiled UP.
> This bug did NOT exist on 2.6.13-rc6 version.

Did you discover this bug with 2.6.13-rc7 before 2.6.13 was released?

Lee

Ricardo Galli

unread,

Aug 29, 2005, 8:00:17 PM8/29/05

to

> There it is.

2.6.13 does not boot in my PPC (iBook, 500 MHz), it hangs just at the very
begining and the machines is automatically rebooted after a couple of
minutes.

The on-screen messages finishes with a few "openpic" messages:
http://mnm.uib.es/gallir/tmp/linux-13-ppc.jpg

I used the same 2.5.12's .config that works fine
(http://mnm.uib.es/gallir/tmp/config-2.6.13-ppc.txt). During "make oldconfig"
I selected the default options, with the exception of the "hardware monitor"
which I first enabled and then disabled because was the first suspicious.

Can I do any further test? Or is it a stupid mistake?

Cheers.

--
ricardo galli GPG id C8114D34
http://mnm.uib.es/gallir/

Masoud Sharbiani

unread,

Aug 29, 2005, 11:50:07 PM8/29/05

to

Yes. I did also report it (see http://lkml.org/lkml/2005/8/26/252)
cheers,
Masoud Sharbiani

Henrik Persson

unread,

Aug 30, 2005, 6:50:13 PM8/30/05

to

Linus Torvalds wrote:
> There it is.
>
> The most painful part of 2.6.13 is likely to be the fact that we made x86
> use the generic PCI bus setup code for assigning unassigned resources.
> That uncovered rather a lot of nasty small details, but should also mean
> that a lot of laptops in particular should be able to discover PCI devices
> behind bridges that the BIOS hasn't set up.
>
> We've hopefully fixed up all the problems that the longish -rc series
> showed, and it shouldn't be that painful, but if you have device problems,
> please make a report that at a minimum contains the unified diff of the
> output of "lspci -vvx" running on 2.6.12 vs 2.6.13. That might give us
> some clues.

Well. 2.6.13 won't boot if I have my Netgear WG511 in the cardbus slot.
It boots just fine if it isn't inserted, though. If I insert it later
on, the computer will freeze and won't respond, just like it does on boot.

2.6.12.5 works just fine, and I just did make oldconfig and used the
defaults (except for the hardware monitoring).

Suggestions, anyone?

diff -u of lspci -vvx + lspci output attached.

It's an Acer Aspire 1302XV.

--
Henrik Persson

diff-lspci

lspci-2.6.12.5

lspci-2.6.13

Alexandre Buisse

unread,

Aug 31, 2005, 9:50:07 AM8/31/05

to

Hi,

the description of PCI_NAMES is conflicting with its default option (now
N/y/? instead of Y/n/?). Here is a small patch that should remove the
confusion in drivers/pci/Kconfig.

Regards,
Alexandre

Signed-off-by : Alexandre Buisse <Alexandr...@ens-lyon.fr>

pci_names_desc_update.patch

Greg KH

unread,

Aug 31, 2005, 10:40:05 PM8/31/05

to

Can you try the patch posted to lkml at:
http://marc.theaimsgroup.com/?l=linux-kernel&m=112541348008047&w=2
from Ivan to see if that helps this?

thanks,

greg k-h

Meelis Roos

unread,

Sep 1, 2005, 2:30:09 AM9/1/05

to

RD> Well, there aren't many differences between 2.6.13-rc7 and 2.6.13. If
RD> I had to guess, I would bet the commit below is what broke you. I'm
RD> including a patch that reverts it at the end of this email

Nigel, have you tried reverting the patch Roland pointed out? It
probably helps you.

I am also interested in this but in another way - the fix fixed reboot
for me (and at least one more person) and just plain reverting it will
break it again. Some better fix will probably be needed.

--
Meelis Roos

Nigel Cunningham

unread,

Sep 1, 2005, 3:00:16 AM9/1/05

to

Hi.

On Thu, 2005-09-01 at 16:24, Meelis Roos wrote:
> RD> Well, there aren't many differences between 2.6.13-rc7 and 2.6.13. If
> RD> I had to guess, I would bet the commit below is what broke you. I'm
> RD> including a patch that reverts it at the end of this email
>
> Nigel, have you tried reverting the patch Roland pointed out? It
> probably helps you.
>
> I am also interested in this but in another way - the fix fixed reboot
> for me (and at least one more person) and just plain reverting it will
> break it again. Some better fix will probably be needed.

I've since found that in the suspend2 code, I was working around this
problem before by not calling the prepare method. I've just today
modified the Suspend code so that it calls prepare for all of the
powerdown methods and everything is working fine without reverting the
patch. I guess this is your better fix if you're a suspend2 user. If
not, are there other circumstances in which you're seeing the computer
fail to powerdown?

Regards,

Nigel

--
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.

-

Meelis Roos

unread,

Sep 1, 2005, 3:40:24 AM9/1/05

to

> I've since found that in the suspend2 code, I was working around this
> problem before by not calling the prepare method. I've just today
> modified the Suspend code so that it calls prepare for all of the
> powerdown methods and everything is working fine without reverting the
> patch. I guess this is your better fix if you're a suspend2 user. If
> not, are there other circumstances in which you're seeing the computer
> fail to powerdown?

It's OK then - I'm not using any suspend and I had a problem that my
machine powered down instead of reboot. The patch that went into 2.6.13
after rc7 fixed it for me. So the current tree is OK for me and if it's
OK for you too after suspend2 changes then this case can probably be
closed.

--
Meelis Roos (mr...@linux.ee)

Pierre Ossman

unread,

Sep 1, 2005, 8:40:35 AM9/1/05

to

Meelis Roos wrote:
>
> It's OK then - I'm not using any suspend and I had a problem that my
> machine powered down instead of reboot. The patch that went into 2.6.13
> after rc7 fixed it for me. So the current tree is OK for me and if it's
> OK for you too after suspend2 changes then this case can probably be
> closed.
>

I'm still having problems with this patch. Both swsusp and swsusp2 are
affected. Perhaps the fix Nigel did needs to be done to swsusp aswell?

Bugzilla entry:

http://bugme.osdl.org/show_bug.cgi?id=4320

Rgds
Pierre

Nigel Cunningham

unread,

Sep 1, 2005, 9:00:13 AM9/1/05

to

On Thu, 2005-09-01 at 22:32, Pierre Ossman wrote:
> Meelis Roos wrote:
> >
> > It's OK then - I'm not using any suspend and I had a problem that my
> > machine powered down instead of reboot. The patch that went into 2.6.13
> > after rc7 fixed it for me. So the current tree is OK for me and if it's
> > OK for you too after suspend2 changes then this case can probably be
> > closed.
> >
>
> I'm still having problems with this patch. Both swsusp and swsusp2 are
> affected. Perhaps the fix Nigel did needs to be done to swsusp aswell?

Yes, it does need modifying. I'll leave it to Pavel to do that though as
he's more familiar with the intricacies of that code than I am.

Regards,

Nigel

> Bugzilla entry:
>
> http://bugme.osdl.org/show_bug.cgi?id=4320
>
> Rgds
> Pierre
> -
> 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/

--
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.

-

Eric W. Biederman

unread,

Sep 1, 2005, 11:20:14 AM9/1/05

to

Nigel Cunningham <ncunn...@cyclades.com> writes:

> On Thu, 2005-09-01 at 22:32, Pierre Ossman wrote:
>> Meelis Roos wrote:
>> >
>> > It's OK then - I'm not using any suspend and I had a problem that my
>> > machine powered down instead of reboot. The patch that went into 2.6.13
>> > after rc7 fixed it for me. So the current tree is OK for me and if it's
>> > OK for you too after suspend2 changes then this case can probably be
>> > closed.
>> >
>>
>> I'm still having problems with this patch. Both swsusp and swsusp2 are
>> affected. Perhaps the fix Nigel did needs to be done to swsusp aswell?
>
> Yes, it does need modifying. I'll leave it to Pavel to do that though as
> he's more familiar with the intricacies of that code than I am.

Are suspend and suspend2 not calling kernel_power_off()?

I am not certain about that code path but I worked hard in the lead
up to 2.6.13 to get everyone on the same page so we did not have
strange reboot issues on one code path and not on another.

It is possible that the code path in suspend is so strange I did not
recognize it. How do you initiate a S4 power off?

I can understand suspend2 having problems as it isn't merged but suspend
is merged isn't it?

Hmm. Looking at that bug report it specifies 2.6.11. Does this
problem really happen in 2.6.13?

Eric

Pierre Ossman

unread,

Sep 1, 2005, 11:30:16 AM9/1/05

to

Eric W. Biederman wrote:

>Hmm. Looking at that bug report it specifies 2.6.11. Does this
>problem really happen in 2.6.13?
>
>
>

I first noticed it in 2.6.11. It was fixed sometime during 2.6.13-rc
only to be killed of again in 2.6.13-rc7. The bugzilla now has a patch
for 2.6.13 which fixes the problem again.

Rgds
Pierre

Eric W. Biederman

unread,

Sep 1, 2005, 1:10:10 PM9/1/05

to

Pierre Ossman <drzeu...@drzeus.cx> writes:

> Eric W. Biederman wrote:
>
>>Hmm. Looking at that bug report it specifies 2.6.11. Does this
>>problem really happen in 2.6.13?
>>
>>
>>
>
> I first noticed it in 2.6.11. It was fixed sometime during 2.6.13-rc
> only to be killed of again in 2.6.13-rc7. The bugzilla now has a patch
> for 2.6.13 which fixes the problem again.

Thanks.

This is clearly a code path I missed when I was fixing things.

When I made the final acpi change I checked for any other users
of device_suspend and it seems I was blind and missed this one.
Looking again...

The patch in the bug report looks correct. However it is still
a little incomplete. In particular the reboot notifier is not
being called, and since not everything has been converted into
using shutdown methods that could lead to some other inconsistent
behavior.

Does anyone have any problems with the patch below?
If not I will send this off to Linus..

Eric

---

include/linux/reboot.h | 1 +
kernel/power/disk.c | 7 ++-----
kernel/sys.c | 10 ++++++++++
3 files changed, 13 insertions(+), 5 deletions(-)

6afa3b66c6b3b135442886b80913e80f10ae886d
diff --git a/include/linux/reboot.h b/include/linux/reboot.h
--- a/include/linux/reboot.h
+++ b/include/linux/reboot.h
@@ -63,6 +63,7 @@ extern void kernel_restart(char *cmd);
extern void kernel_halt(void);
extern void kernel_power_off(void);
extern void kernel_kexec(void);
+extern int kernel_suspend(void);

/*
* Emergency restart, callable from an interrupt handler.
diff --git a/kernel/power/disk.c b/kernel/power/disk.c
--- a/kernel/power/disk.c
+++ b/kernel/power/disk.c
@@ -17,12 +17,12 @@
#include <linux/delay.h>
#include <linux/fs.h>
#include <linux/mount.h>
+#include <linux/pm.h>

#include "power.h"

extern suspend_disk_method_t pm_disk_mode;
-extern struct pm_ops * pm_ops;

extern int swsusp_suspend(void);
extern int swsusp_write(void);
@@ -49,14 +49,11 @@ dev_t swsusp_resume_device;

static void power_down(suspend_disk_method_t mode)
{
- unsigned long flags;
int error = 0;

- local_irq_save(flags);
switch(mode) {
case PM_DISK_PLATFORM:
- device_shutdown();
- error = pm_ops->enter(PM_SUSPEND_DISK);
+ error = kernel_suspend();
break;
case PM_DISK_SHUTDOWN:
kernel_power_off();
diff --git a/kernel/sys.c b/kernel/sys.c
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -28,6 +28,7 @@
#include <linux/suspend.h>
#include <linux/tty.h>
#include <linux/signal.h>
+#include <linux/pm.h>

#include <linux/compat.h>
#include <linux/syscalls.h>
@@ -420,6 +421,15 @@ void kernel_power_off(void)
}
EXPORT_SYMBOL_GPL(kernel_power_off);

+int kernel_suspend(void)
+{
+ notifier_call_chain(&reboot_notifier_list, SYS_POWER_OFF, NULL);
+ system_state = SYSTEM_POWER_OFF;
+ device_shutdown();
+ return pm_ops->enter(PM_SUSPEND_DISK);
+}
+EXPORT_SYMBOL_GPL(kernel_suspend);
+
/*
* Reboot system call: for obvious reasons only root may call it,
* and even root needs to set up some magic numbers in the registers

Eric W. Biederman

unread,

Sep 1, 2005, 2:30:13 PM9/1/05

to

Pierre Ossman <drzeu...@drzeus.cx> writes:
>
> Patch tested and works fine here. You should probably make a note in the
> bugzilla so we don't get a conflicting merge from the ACPI folks.

Thanks.

If I can figure out bugzilla...

> I suppose Nigel should use this function in swsusp2 aswell?

If he is doing the same thing yes.

Eric

Brown, Len

unread,

Sep 1, 2005, 2:30:17 PM9/1/05

to

>Patch tested and works fine here. You should probably make a
>note in the bugzilla so we don't get a conflicting merge
>from the ACPI folks.

One might also consider that it would be a good idea to
send patches that break ACPI files to the ACPI maintainer
and acpi-...@lists.sourceforge.net before sending them
to Linus...

-Len

Pierre Ossman

unread,

Sep 1, 2005, 2:30:27 PM9/1/05

to

Eric W. Biederman wrote:

>Thanks.
>
>This is clearly a code path I missed when I was fixing things.
>
>When I made the final acpi change I checked for any other users
>of device_suspend and it seems I was blind and missed this one.
>Looking again...
>
>The patch in the bug report looks correct. However it is still
>a little incomplete. In particular the reboot notifier is not
>being called, and since not everything has been converted into
>using shutdown methods that could lead to some other inconsistent
>behavior.
>
>Does anyone have any problems with the patch below?
>If not I will send this off to Linus..
>
>
>

Patch tested and works fine here. You should probably make a note in the

bugzilla so we don't get a conflicting merge from the ACPI folks.

I suppose Nigel should use this function in swsusp2 aswell?

Rgds
Pierre

Pavel Machek

unread,

Sep 1, 2005, 4:30:18 PM9/1/05

to

Hi!

> >>Hmm. Looking at that bug report it specifies 2.6.11. Does this
> >>problem really happen in 2.6.13?
> >>
> >>
> >>
> >
> > I first noticed it in 2.6.11. It was fixed sometime during 2.6.13-rc
> > only to be killed of again in 2.6.13-rc7. The bugzilla now has a patch
> > for 2.6.13 which fixes the problem again.
>
> Thanks.
>
> This is clearly a code path I missed when I was fixing things.
>
> When I made the final acpi change I checked for any other users
> of device_suspend and it seems I was blind and missed this one.
> Looking again...
>
> The patch in the bug report looks correct. However it is still
> a little incomplete. In particular the reboot notifier is not
> being called, and since not everything has been converted into
> using shutdown methods that could lead to some other inconsistent
> behavior.
>
> Does anyone have any problems with the patch below?
> If not I will send this off to Linus..

Yes. kernel_suspend is *way* too generic name. kernel_suspend_off? kernel_powe_off_suspend?

> @@ -420,6 +421,15 @@ void kernel_power_off(void)
> }
> EXPORT_SYMBOL_GPL(kernel_power_off);
>
> +int kernel_suspend(void)
> +{
> + notifier_call_chain(&reboot_notifier_list, SYS_POWER_OFF, NULL);
> + system_state = SYSTEM_POWER_OFF;
> + device_shutdown();
> + return pm_ops->enter(PM_SUSPEND_DISK);
> +}
> +EXPORT_SYMBOL_GPL(kernel_suspend);
> +

Are you sure pm_ops exists in !CONFIG_PM case?
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms

Nigel Cunningham

unread,

Sep 1, 2005, 5:20:08 PM9/1/05

to

Hi.

On Fri, 2005-09-02 at 01:15, Eric W. Biederman wrote:
> Nigel Cunningham <ncunn...@cyclades.com> writes:
>
> > On Thu, 2005-09-01 at 22:32, Pierre Ossman wrote:
> >> Meelis Roos wrote:
> >> >
> >> > It's OK then - I'm not using any suspend and I had a problem that my
> >> > machine powered down instead of reboot. The patch that went into 2.6.13
> >> > after rc7 fixed it for me. So the current tree is OK for me and if it's
> >> > OK for you too after suspend2 changes then this case can probably be
> >> > closed.
> >> >
> >>
> >> I'm still having problems with this patch. Both swsusp and swsusp2 are
> >> affected. Perhaps the fix Nigel did needs to be done to swsusp aswell?
> >
> > Yes, it does need modifying. I'll leave it to Pavel to do that though as
> > he's more familiar with the intricacies of that code than I am.
>
> Are suspend and suspend2 not calling kernel_power_off()?

They are/weren't calling pm_ops->prepare if we're using poweroff or
reboot rather than entering S3 or S4.

> I am not certain about that code path but I worked hard in the lead
> up to 2.6.13 to get everyone on the same page so we did not have
> strange reboot issues on one code path and not on another.
>
> It is possible that the code path in suspend is so strange I did not
> recognize it. How do you initiate a S4 power off?
>
> I can understand suspend2 having problems as it isn't merged but suspend
> is merged isn't it?

You're fine. It's just that we were both working around the problem
before, and don't need to now.

Regards,

Nigel

> Hmm. Looking at that bug report it specifies 2.6.11. Does this
> problem really happen in 2.6.13?
>
> Eric

--
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.

-

Nigel Cunningham

unread,

Sep 1, 2005, 5:20:10 PM9/1/05

to

Hi.

On Fri, 2005-09-02 at 04:23, Eric W. Biederman wrote:
> Pierre Ossman <drzeu...@drzeus.cx> writes:
> >
> > Patch tested and works fine here. You should probably make a note in the
> > bugzilla so we don't get a conflicting merge from the ACPI folks.
>
> Thanks.
>
> If I can figure out bugzilla...
>
> > I suppose Nigel should use this function in swsusp2 aswell?

All I did was start calling pm_ops->prepare, ->enter and ->finish
regardless of the powerdown method, instead of only for S3 or S4. It
seems to be working fine. If, however, we should be doing things
differently, I'm happy to comply. What's the authoritative word?

Regards,

Nigel

> If he is doing the same thing yes.
>
> Eric

--
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.

-

Eric W. Biederman

unread,

Sep 2, 2005, 12:40:06 AM9/2/05

to

Pavel Machek <pa...@ucw.cz> writes:

> Hi!

>>
>> Thanks.
>>
>> This is clearly a code path I missed when I was fixing things.
>>
>> When I made the final acpi change I checked for any other users
>> of device_suspend and it seems I was blind and missed this one.
>> Looking again...
>>
>> The patch in the bug report looks correct. However it is still
>> a little incomplete. In particular the reboot notifier is not
>> being called, and since not everything has been converted into
>> using shutdown methods that could lead to some other inconsistent
>> behavior.
>>
>> Does anyone have any problems with the patch below?
>> If not I will send this off to Linus..
>
> Yes. kernel_suspend is *way* too generic name. kernel_suspend_off?
> kernel_powe_off_suspend?

Darn. You have a point there.

>> @@ -420,6 +421,15 @@ void kernel_power_off(void)
>> }
>> EXPORT_SYMBOL_GPL(kernel_power_off);
>>
>> +int kernel_suspend(void)
>> +{
>> + notifier_call_chain(&reboot_notifier_list, SYS_POWER_OFF, NULL);
>> + system_state = SYSTEM_POWER_OFF;
>> + device_shutdown();
>> + return pm_ops->enter(PM_SUSPEND_DISK);
>> +}
>> +EXPORT_SYMBOL_GPL(kernel_suspend);
>> +
>
> Are you sure pm_ops exists in !CONFIG_PM case?

Hmm. Good point. I hadn't considered that. I am now certain
it only exists when CONFIG_PM is set.

Thinking about it more I probably want to simply have a
kernel_power_off_shutdown(); common factor and call
that instead of device_shutdown().

Ok some sleep and then I will see if I can better version of this
cleanup.

Eric

Eric W. Biederman

unread,

Sep 2, 2005, 12:50:05 AM9/2/05

to

Nigel Cunningham <ncunn...@cyclades.com> writes:

>
> All I did was start calling pm_ops->prepare, ->enter and ->finish
> regardless of the powerdown method, instead of only for S3 or S4. It
> seems to be working fine. If, however, we should be doing things
> differently, I'm happy to comply. What's the authoritative word?

Not certain. I am only authoritative on device_suspend() and the
reboot_notifiers, in this context. Largely I read and think about
the code to see what is going on.

Eric

Eric W. Biederman

unread,

Sep 2, 2005, 12:50:06 AM9/2/05

to

"Brown, Len" <len....@intel.com> writes:

>
>>Patch tested and works fine here. You should probably make a
>>note in the bugzilla so we don't get a conflicting merge
>>from the ACPI folks.
>
> One might also consider that it would be a good idea to
> send patches that break ACPI files to the ACPI maintainer
> and acpi-...@lists.sourceforge.net before sending them
> to Linus...

My apologies, for bug fixes that are not complete and simply move
where the bug is. My apologies also for not cc'ing you, I didn't
intend to omit you but it never occurred to me. The patch was
also 2 lines and obviously correct.

For this round I knew you were on the CC list and deliberately included
you.

My goal for the reboot/halt/suspend/kexec path is to fix it so the
generic code is correct and consistent. Something it hasn't been for
years creating the affect that a correct bug fix in one place would
break something else.

Until the reboot paths are correct and consistent things will continue
to break, in weird and unpredictable ways, that will keep us all
hunting weird strange bugs for a long time. I think the S4 suspend
case is the last code path that needs to be fixed. It is certainly
the last one I am aware of.

Eric

Henrik Persson

unread,

Sep 3, 2005, 5:30:14 AM9/3/05

to

Greg KH wrote:
> On Wed, Aug 31, 2005 at 12:41:03AM +0200, Henrik Persson wrote:
>
>>Linus Torvalds wrote:
>>
>>>There it is.
>>>
>>>The most painful part of 2.6.13 is likely to be the fact that we made x86
>>>use the generic PCI bus setup code for assigning unassigned resources.
>>>That uncovered rather a lot of nasty small details, but should also mean
>>>that a lot of laptops in particular should be able to discover PCI devices
>>>behind bridges that the BIOS hasn't set up.
>>>
>>>We've hopefully fixed up all the problems that the longish -rc series
>>>showed, and it shouldn't be that painful, but if you have device problems,
>>>please make a report that at a minimum contains the unified diff of the
>>>output of "lspci -vvx" running on 2.6.12 vs 2.6.13. That might give us
>>>some clues.
>>
>>Well. 2.6.13 won't boot if I have my Netgear WG511 in the cardbus slot.
>>It boots just fine if it isn't inserted, though. If I insert it later
>>on, the computer will freeze and won't respond, just like it does on boot.
>>
>>2.6.12.5 works just fine, and I just did make oldconfig and used the
>>defaults (except for the hardware monitoring).
>>
>>Suggestions, anyone?
>
>
> Can you try the patch posted to lkml at:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=112541348008047&w=2
> from Ivan to see if that helps this?

Indeed. 2.6.13 now booting without any problems at all (well, no
problems yet anyway..) :)

--
Henrik Persson

signature.asc

Alexey Dobriyan

unread,

Sep 3, 2005, 12:10:07 PM9/3/05

to

On Tue, Aug 30, 2005 at 01:57:27AM +0200, Ricardo Galli wrote:
> 2.6.13 does not boot in my PPC (iBook, 500 MHz), it hangs just at the very
> begining and the machines is automatically rebooted after a couple of
> minutes.

I've filed a bug at kernel bugzilla so your report won't be lost. See
http://bugme.osdl.org/show_bug.cgi?id=5180

Please, register at http://bugme.osdl.org/createaccount.cgi and add
yourself to CC list.

Eric W. Biederman

unread,

Sep 10, 2005, 5:10:17 PM9/10/05

to

"Brown, Len" <len....@intel.com> writes:

>
>>Patch tested and works fine here. You should probably make a
>>note in the bugzilla so we don't get a conflicting merge
>>from the ACPI folks.
>
> One might also consider that it would be a good idea to
> send patches that break ACPI files to the ACPI maintainer
> and acpi-...@lists.sourceforge.net before sending them
> to Linus...

OK hopefully this is my final version of this bug fix.

Eric

diff --git a/include/linux/reboot.h b/include/linux/reboot.h
--- a/include/linux/reboot.h
+++ b/include/linux/reboot.h

@@ -59,6 +59,10 @@ extern void machine_crash_shutdown(struc
* Architecture independent implemenations of sys_reboot commands.
*/

+extern void kernel_restart_prepare(char *cmd);
+extern void kernel_halt_prepare(void);
+extern void kernel_power_off_prepare(void);
+

extern void kernel_restart(char *cmd);
extern void kernel_halt(void);
extern void kernel_power_off(void);

diff --git a/kernel/power/disk.c b/kernel/power/disk.c
--- a/kernel/power/disk.c
+++ b/kernel/power/disk.c
@@ -17,12 +17,12 @@
#include <linux/delay.h>
#include <linux/fs.h>
#include <linux/mount.h>
+#include <linux/pm.h>

#include "power.h"

extern suspend_disk_method_t pm_disk_mode;
-extern struct pm_ops * pm_ops;

extern int swsusp_suspend(void);
extern int swsusp_write(void);

@@ -49,13 +49,11 @@ dev_t swsusp_resume_device;

static void power_down(suspend_disk_method_t mode)
{
- unsigned long flags;
int error = 0;

- local_irq_save(flags);
switch(mode) {
case PM_DISK_PLATFORM:
- device_shutdown();

+ kernel_power_off_prepare();
error = pm_ops->enter(PM_SUSPEND_DISK);
break;
case PM_DISK_SHUTDOWN:

diff --git a/kernel/sys.c b/kernel/sys.c
--- a/kernel/sys.c
+++ b/kernel/sys.c

@@ -361,17 +361,35 @@ out_unlock:
return retval;
}

+/**
+ * emergency_restart - reboot the system
+ *
+ * Without shutting down any hardware or taking any locks
+ * reboot the system. This is called when we know we are in
+ * trouble so this is our best effort to reboot. This is
+ * safe to call in interrupt context.
+ */
void emergency_restart(void)
{
machine_emergency_restart();
}
EXPORT_SYMBOL_GPL(emergency_restart);

-void kernel_restart(char *cmd)
+/**
+ * kernel_restart - reboot the system
+ *
+ * Shutdown everything and perform a clean reboot.
+ * This is not safe to call in interrupt context.
+ */
+void kernel_restart_prepare(char *cmd)
{
notifier_call_chain(&reboot_notifier_list, SYS_RESTART, cmd);
system_state = SYSTEM_RESTART;
device_shutdown();
+}
+void kernel_restart(char *cmd)
+{
+ kernel_restart_prepare(cmd);
if (!cmd) {
printk(KERN_EMERG "Restarting system.\n");
} else {
@@ -382,6 +400,12 @@ void kernel_restart(char *cmd)
}
EXPORT_SYMBOL_GPL(kernel_restart);

+/**
+ * kernel_kexec - reboot the system
+ *
+ * Move into place and start executing a preloaded standalone
+ * executable. If nothing was preloaded return an error.
+ */
void kernel_kexec(void)
{
#ifdef CONFIG_KEXEC
@@ -390,9 +414,7 @@ void kernel_kexec(void)
if (!image) {
return;
}
- notifier_call_chain(&reboot_notifier_list, SYS_RESTART, NULL);
- system_state = SYSTEM_RESTART;
- device_shutdown();
+ kernel_restart_prepare(NULL);
printk(KERN_EMERG "Starting new kernel\n");
machine_shutdown();
machine_kexec(image);
@@ -400,21 +422,39 @@ void kernel_kexec(void)
}
EXPORT_SYMBOL_GPL(kernel_kexec);

-void kernel_halt(void)
+/**
+ * kernel_halt - halt the system
+ *
+ * Shutdown everything and perform a clean system halt.
+ */
+void kernel_halt_prepare(void)
{
notifier_call_chain(&reboot_notifier_list, SYS_HALT, NULL);
system_state = SYSTEM_HALT;
device_shutdown();
+}
+void kernel_halt(void)
+{
+ kernel_halt_prepare();
printk(KERN_EMERG "System halted.\n");
machine_halt();
}
EXPORT_SYMBOL_GPL(kernel_halt);

-void kernel_power_off(void)
+/**
+ * kernel_power_off - power_off the system
+ *
+ * Shutdown everything and perform a clean system power_off.
+ */
+void kernel_power_off_prepare(void)
{
notifier_call_chain(&reboot_notifier_list, SYS_POWER_OFF, NULL);
system_state = SYSTEM_POWER_OFF;
device_shutdown();
+}
+void kernel_power_off(void)
+{
+ kernel_power_off_prepare();
printk(KERN_EMERG "Power down.\n");
machine_power_off();

Meelis Roos

unread,

Sep 11, 2005, 4:50:07 AM9/11/05

to

> OK hopefully this is my final version of this bug fix.

I'm not in the position to test threse patches any more because the
mainboard in question died last week when I installed some more RAM into
it. Masoud Sharbiani <mas...@masoud.ir> added to CC: since he
experienced the same problem.

--
Meelis Roos (mr...@linux.ee)

Eric W. Biederman

unread,

Sep 11, 2005, 5:00:10 AM9/11/05

to

Meelis Roos <mr...@linux.ee> writes:

>> OK hopefully this is my final version of this bug fix.
>
> I'm not in the position to test threse patches any more because the mainboard in
> question died last week when I installed some more RAM into it. Masoud Sharbiani
> <mas...@masoud.ir> added to CC: since he experienced the same problem.

Thanks for looking.

At this point I am less worried about fixing the bug. Then I am
worried about the form of the bug fix. (i.e. do weird compile
options break it).

But any testing or review is appreciated.

Eric

Eric W. Biederman

unread,

Sep 20, 2005, 1:50:24 PM9/20/05

to

In the lead up to 2.6.13 I fixed a large number of reboot
problems by making the calling conventions consistent. Despite
checking and double checking my work it appears I missed an
obvious one.

This first patch simply refactors the reboot routines
so all of the preparation for various kinds of reboots
are in their own functions. Making it very hard to
get the various kinds of reboot out of sync.

Signed-off-by: Eric W. Biederman <ebie...@xmission.com>

---

include/linux/reboot.h | 4 ++++
kernel/sys.c | 52 ++++++++++++++++++++++++++++++++++++++++++------
2 files changed, 50 insertions(+), 6 deletions(-)

bc95b88c85ec3e7a0525f73f6c3ae19fa9640fbd

diff --git a/include/linux/reboot.h b/include/linux/reboot.h
--- a/include/linux/reboot.h
+++ b/include/linux/reboot.h
@@ -59,6 +59,10 @@ extern void machine_crash_shutdown(struc
* Architecture independent implemenations of sys_reboot commands.
*/

+extern void kernel_restart_prepare(char *cmd);
+extern void kernel_halt_prepare(void);
+extern void kernel_power_off_prepare(void);
+
extern void kernel_restart(char *cmd);
extern void kernel_halt(void);
extern void kernel_power_off(void);

Eric W. Biederman

unread,

Sep 20, 2005, 2:00:26 PM9/20/05

to

In the lead up to 2.6.13 I fixed a large number of reboot
problems by making the calling conventions consistent. Despite
checking and double checking my work it appears I missed an
obvious one.

The S4 suspend code for PM_DISK_PLATFORM was also calling
device_shutdown without setting system_state, and was
not calling the appropriate reboot_notifier.

This patch fixes the bug by replacing the call of device_suspend with
kernel_poweroff_prepare.

Various forms of this failure have been fixed and tracked for a while.

Thanks for tracking this down go to: Alexey Starikovskiy,
Meelis Roos <mr...@linux.ee>, Nigel Cunningham <ncunn...@cyclades.com>,
Pierre Ossman <drzeu...@drzeus.cx>

History of this bug is at:
http://bugme.osdl.org/show_bug.cgi?id=4320

Signed-off-by: Eric W. Biederman <ebie...@xmission.com>

---

kernel/power/disk.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)

2c72ba7b1126a7ccf3e8fc032f041a223e39aa97

Pavel Machek

unread,

Sep 20, 2005, 5:20:16 PM9/20/05

to

Hi!

> In the lead up to 2.6.13 I fixed a large number of reboot
> problems by making the calling conventions consistent. Despite
> checking and double checking my work it appears I missed an
> obvious one.
>
> The S4 suspend code for PM_DISK_PLATFORM was also calling
> device_shutdown without setting system_state, and was
> not calling the appropriate reboot_notifier.

ACK on both. But should not you submit patch via -mm, so it gets at
least some testing there?
Pavel
--
if you have sharp zaurus hardware you don't need... you know my address

Eric W. Biederman

unread,

Sep 20, 2005, 10:20:14 PM9/20/05

to

Pavel Machek <pa...@ucw.cz> writes:

> Hi!
>
>> In the lead up to 2.6.13 I fixed a large number of reboot
>> problems by making the calling conventions consistent. Despite
>> checking and double checking my work it appears I missed an
>> obvious one.
>>
>> The S4 suspend code for PM_DISK_PLATFORM was also calling
>> device_shutdown without setting system_state, and was
>> not calling the appropriate reboot_notifier.
>
> ACK on both. But should not you submit patch via -mm, so it gets at
> least some testing there?

The code is obviously correct, and the people with the problem
have reported that this approach solves it.

If this bit of functionality is to even work we need to do
something like this.

So I don't see what benefit putting this in -mm would give. If
I was aggressive I would say that this needs to be in 2.6.13.N.
If I'm not following some procedure I don't have a problem
changing though.

This is the final fix I know of to get a consistent set of semantics
for the everything in the ``reboot path''.

From a practical standpoint I am very tardy in getting this out.

Eric

Pavel Machek

unread,

Sep 21, 2005, 6:20:45 AM9/21/05

to

Hi!

> >> The S4 suspend code for PM_DISK_PLATFORM was also calling
> >> device_shutdown without setting system_state, and was
> >> not calling the appropriate reboot_notifier.
> >
> > ACK on both. But should not you submit patch via -mm, so it gets at
> > least some testing there?
>
> The code is obviously correct, and the people with the problem
> have reported that this approach solves it.
>
> If this bit of functionality is to even work we need to do
> something like this.
>
> So I don't see what benefit putting this in -mm would give. If
> I was aggressive I would say that this needs to be in 2.6.13.N.
> If I'm not following some procedure I don't have a problem
> changing though.

I think you are not following the proper procedure. All the patches
should go through akpm.
Pavel
--
Boycott Kodak -- for their patent abuse against Java.

Eric W. Biederman

unread,

Sep 21, 2005, 10:01:01 AM9/21/05

to

Pavel Machek <pa...@suse.cz> writes:

> I think you are not following the proper procedure. All the patches
> should go through akpm.

Ok. I must have missed the most recent procedure change.

Anyway. Andrew has picked these patches up so all looks good.

Eric

Linus Torvalds

unread,

Sep 21, 2005, 12:40:11 PM9/21/05

to

On Wed, 21 Sep 2005, Pavel Machek wrote:
>
> I think you are not following the proper procedure. All the patches
> should go through akpm.

One issue is that I actually worry that Andrew will at some point be where
I was a couple of years ago - overworked and stressed out by just tons and
tons of patches.

Yes, he's written/modified tons of patch-tracking tools, and the git
merging hopefully avoids some of the pressures, but it still worries me.
If Andrew burns out, we'll all suffer hugely.

I'm wondering what we can do to offset those kinds of issues. I _do_ like
having -mm as a staging area and catching some problems there, so going
through andrew is wonderful in that sense, but it has downsides.

Andrew?

Linus

Eric W. Biederman

unread,

Sep 21, 2005, 1:40:15 PM9/21/05

to

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

> On Wed, 21 Sep 2005, Pavel Machek wrote:
>>
>> I think you are not following the proper procedure. All the patches
>> should go through akpm.

Ok. I thought it was fine to send simple and obviously correct bug
fixes to Linus.

> One issue is that I actually worry that Andrew will at some point be where
> I was a couple of years ago - overworked and stressed out by just tons and
> tons of patches.
>
> Yes, he's written/modified tons of patch-tracking tools, and the git
> merging hopefully avoids some of the pressures, but it still worries me.
> If Andrew burns out, we'll all suffer hugely.
>
> I'm wondering what we can do to offset those kinds of issues. I _do_ like
> having -mm as a staging area and catching some problems there, so going
> through andrew is wonderful in that sense, but it has downsides.

It is especially challenging for people like me who typically work on
parts of the kernel without a maintainer. So there frequently isn't
an intermediate I can submit my patches to.

Eric

Andrew Morton

unread,

Sep 21, 2005, 1:50:13 PM9/21/05

to

Linus Torvalds <torv...@osdl.org> wrote:
>
>
>
> On Wed, 21 Sep 2005, Pavel Machek wrote:
> >
> > I think you are not following the proper procedure. All the patches
> > should go through akpm.
>
> One issue is that I actually worry that Andrew will at some point be where
> I was a couple of years ago - overworked and stressed out by just tons and
> tons of patches.

Patches are very low overhead, really. It's patches which don't work which
take lots of time - a single dud patch can take hours and can make me think
rude thoughts about its originator.

> Yes, he's written/modified tons of patch-tracking tools, and the git
> merging hopefully avoids some of the pressures, but it still worries me.
> If Andrew burns out, we'll all suffer hugely.
>
> I'm wondering what we can do to offset those kinds of issues. I _do_ like
> having -mm as a staging area and catching some problems there, so going
> through andrew is wonderful in that sense, but it has downsides.
>
> Andrew?
>

I'm doin OK.

Patch volume isn't a problem wrt the simple mechanics of handling them.
The problem we have at present is lack of patch reviewing bandwidth. I'll
be tightening things up in that area. Relatively few developers seem to
have the stomach to do a line-by-line through large patches, and it would
be nice to refocus people a bit on that. Christoph's work is hugely
appreciated, thanks.

Famous last words, but the actual patch volume _has_ to drop off one day.
In fact there doesn't seem to much happening out there wrt 2.6.15.

Bugs are a big problem - it takes 4 hours minimum to get a -mm out the door
and a single bug can cause it to slip to the next day in which case I have
to start again. A couple of times it has taken over two days just to get
together a tree which boots on four architectures and compiles on seven.

I'm spending more and more time on bugs now. We have hundreds of bugs
which people have taken the time to report, which the relevant developers
know about and NOTHING IS HAPPENING. "I can't reproduce it" is not an
adequate reason when there are nice testers out there who are available to
work through the diagnosis process. We have hundreds of machines out there
which we are known to have broken and developers just need to reapportion
some of their time to getting these things fixed.

The -mm tree does prevent a large amount of crap from hitting mainline -
I'd guess the bug leakthrough rate is ~10%, although that 90% tends to be
the easy stuff - often compile errors. I'd like to release -mm's more
often and I'd like -mm to have less of a wild-and-crappy reputation. Both
of these would happen if originators were to test ther stuff more
carefully.

Alexander Nyberg

unread,

Sep 21, 2005, 1:50:15 PM9/21/05

to

On Wed, Sep 21, 2005 at 09:35:20AM -0700 Linus Torvalds wrote:

>
>
> On Wed, 21 Sep 2005, Pavel Machek wrote:
> >
> > I think you are not following the proper procedure. All the patches
> > should go through akpm.
>
> One issue is that I actually worry that Andrew will at some point be where
> I was a couple of years ago - overworked and stressed out by just tons and
> tons of patches.
>
> Yes, he's written/modified tons of patch-tracking tools, and the git
> merging hopefully avoids some of the pressures, but it still worries me.
> If Andrew burns out, we'll all suffer hugely.
>
> I'm wondering what we can do to offset those kinds of issues. I _do_ like
> having -mm as a staging area and catching some problems there, so going
> through andrew is wonderful in that sense, but it has downsides.
>

Morever bugme.osdl.org is severely underworked (acpi being a noteable
exception) and Andrew has stepped in alot there too. Alot of bugs
reported on the mailing list are only followed up by Andrew.

I think he really should receive much more help than he currently does.

Andrew Morton

unread,

Sep 21, 2005, 2:10:23 PM9/21/05

to

ebie...@xmission.com (Eric W. Biederman) wrote:
>
> Linus Torvalds <torv...@osdl.org> writes:
>
> > On Wed, 21 Sep 2005, Pavel Machek wrote:
> >>
> >> I think you are not following the proper procedure. All the patches
> >> should go through akpm.
>
> Ok. I thought it was fine to send simple and obviously correct bug
> fixes to Linus.

I habitually scoop up patches and will get them into Linus (preferably
after 1-2 -mm cycles) if he ducks them.

> > One issue is that I actually worry that Andrew will at some point be where
> > I was a couple of years ago - overworked and stressed out by just tons and
> > tons of patches.
> >
> > Yes, he's written/modified tons of patch-tracking tools, and the git
> > merging hopefully avoids some of the pressures, but it still worries me.
> > If Andrew burns out, we'll all suffer hugely.
> >
> > I'm wondering what we can do to offset those kinds of issues. I _do_ like
> > having -mm as a staging area and catching some problems there, so going
> > through andrew is wonderful in that sense, but it has downsides.
>
> It is especially challenging for people like me who typically work on
> parts of the kernel without a maintainer. So there frequently isn't
> an intermediate I can submit my patches to.

Yup. And MAINTAINERS has quite a few omissions. I generally know who
should be poked and if there's nobody obvious I have 26000 patches to grep
through to find out who might know a bit about that code. Low-level x86 is
a bit of a problem really because it has many cooks and no obvious chef.

Individual maintainers have differing response times, differing
attentiveness and differing patchloss ratios.

There's also confusion once I've cc'ed a maintainer on a patch over whether
I'll be sending it to Linus or whether I want them to.

If a maintainer has a tree in -mm then I'll autodrop the patch if they
merge it, so there's no confusion there.

If the maintainer says "thanks, merged" and I don't have their tree in -mm
then I'll tend to hang onto the patch indefinitely until it finally hits
-linus. Or I'll eventually forget and merge it up anyway ;)

If the maintainer just acks the patch I'll send it in to Linus.

If the maintainer nacks the patch I'll either drop it or I'll mark it
not-for-merging and hang onto it anwyay, as a reminder that we have some
bug which needs fixing.

If the maintainer has a tree in -mm and doesn't merge the patch I'll hang
onto it and periodically resend to the maintainer until some definite
response comes back.

Eric W. Biederman

unread,

Sep 21, 2005, 2:20:14 PM9/21/05

to

Andrew Morton <ak...@osdl.org> writes:

> I'm doin OK.

Good to hear.

> Patch volume isn't a problem wrt the simple mechanics of handling them.
> The problem we have at present is lack of patch reviewing bandwidth. I'll
> be tightening things up in that area. Relatively few developers seem to
> have the stomach to do a line-by-line through large patches, and it would
> be nice to refocus people a bit on that. Christoph's work is hugely
> appreciated, thanks.
>
> Famous last words, but the actual patch volume _has_ to drop off one day.
> In fact there doesn't seem to much happening out there wrt 2.6.15.

Due to changes coming through git or that there will simply be fewer
things that need to be patched?

As for 2.6.15 I know I have patches in the queue that I intend to send
out later this week, which probably count. I wonder if other developers
are similar.

Eric

Andrew Morton

unread,

Sep 21, 2005, 2:20:17 PM9/21/05

to

Alexander Nyberg <al...@telia.com> wrote:
>
> On Wed, Sep 21, 2005 at 09:35:20AM -0700 Linus Torvalds wrote:
>
> >
> >
> > On Wed, 21 Sep 2005, Pavel Machek wrote:
> > >
> > > I think you are not following the proper procedure. All the patches
> > > should go through akpm.
> >
> > One issue is that I actually worry that Andrew will at some point be where
> > I was a couple of years ago - overworked and stressed out by just tons and
> > tons of patches.
> >
> > Yes, he's written/modified tons of patch-tracking tools, and the git
> > merging hopefully avoids some of the pressures, but it still worries me.
> > If Andrew burns out, we'll all suffer hugely.
> >
> > I'm wondering what we can do to offset those kinds of issues. I _do_ like
> > having -mm as a staging area and catching some problems there, so going
> > through andrew is wonderful in that sense, but it has downsides.
> >
>
> Morever bugme.osdl.org is severely underworked (acpi being a noteable
> exception) and Andrew has stepped in alot there too. Alot of bugs
> reported on the mailing list are only followed up by Andrew.
>
> I think he really should receive much more help than he currently does.

Yes, kernel bugmeister is a completely separate function from
patchmonkeying. It is something which a separate person can and should do.

My current thinking is that I'll develop the processes, find out what works
and then look to hand it off to some other sucker. I wouldn't claim that
this is going very well at present, perhaps because I'm just not putting
enough time into the bugmeistering to be able to demonstrate what works and
what does not.

I wouldn't say that bugmeister is a fulltime job, but it'll be a
lot-of-time job. It needs someone who isn't shy and who has a good
understanding of the kernel code-wise, of the processes (hah) and of the
people.

The ability to maintain an overall view of where we're at, which bugs are
serious and which aren't. The ability to succinctly communicate that
overview to everyone else. Able to tell Linus "you can't release a kernel
until bugs A, B and C are fixed". The skills and gut-feel to know when a
patch is some once-off which can be ignored unless it reoccurs, etc. It's
one of those things which can consume as much effort as one is able to put
into it.

Kernel development is more professional than we like to pretend nowadays,
and developers will react well to someone who is doing this for us. It's
pretty boring tho.

Andrew Morton

unread,

Sep 21, 2005, 2:30:14 PM9/21/05

to

ebie...@xmission.com (Eric W. Biederman) wrote:
>

> > Famous last words, but the actual patch volume _has_ to drop off one day.
> > In fact there doesn't seem to much happening out there wrt 2.6.15.
>
> Due to changes coming through git or that there will simply be fewer
> things that need to be patched?

We're at -rc2 and I only have only maybe 100 patches tagged for 2.6.15 at
this time. The number of actual major features lined up for 2.6.15 looks
relatively small too.

As I said, famous last words. But we have to finish this thing one day ;)

> As for 2.6.15 I know I have patches in the queue that I intend to send
> out later this week, which probably count. I wonder if other developers
> are similar.

Possibly. Quite a few of the git trees are looking pretty fat. I need to
get another kernel-status thingy out soon, but that takes many hours of
bugzilla-poking.

Diego Calleja

unread,

Sep 21, 2005, 2:40:13 PM9/21/05

to

El Wed, 21 Sep 2005 19:36:30 +0200,
Alexander Nyberg <al...@telia.com> escribió:

> Morever bugme.osdl.org is severely underworked (acpi being a noteable
> exception) and Andrew has stepped in alot there too. Alot of bugs
> reported on the mailing list are only followed up by Andrew.

One of the things I'm _really_ missing from OSDL's bugzilla setup is a mailing
list (if there's one I've never heard about it) where all changes/new bugs/
random crap are posted. Something like:

http://lists.freedesktop.org/archives/xorg-bugzilla-noise/2005-April/thread.html

Andrew Morton

unread,

Sep 21, 2005, 3:00:23 PM9/21/05

to

Diego Calleja <die...@gmail.com> wrote:
>
> El Wed, 21 Sep 2005 19:36:30 +0200,
> Alexander Nyberg <al...@telia.com> escribió:
>
> > Morever bugme.osdl.org is severely underworked (acpi being a noteable
> > exception) and Andrew has stepped in alot there too. Alot of bugs
> > reported on the mailing list are only followed up by Andrew.
>
> One of the things I'm _really_ missing from OSDL's bugzilla setup is a mailing
> list (if there's one I've never heard about it) where all changes/new bugs/
> random crap are posted.

There is such a list - it's a great way to depress yourself while still
half asleep.

bugm...@lists.osdl.org, but I'm not sure how one subscribes. It doesn't
appear at http://lists.osdl.org/mailman/listinfo/. Martin?

Russell King

unread,

Sep 21, 2005, 3:50:15 PM9/21/05

to

On Wed, Sep 21, 2005 at 07:36:30PM +0200, Alexander Nyberg wrote:
> Morever bugme.osdl.org is severely underworked (acpi being a noteable
> exception) and Andrew has stepped in alot there too. Alot of bugs
> reported on the mailing list are only followed up by Andrew.

That depends on your point of view. One of the biggest problems
bugme has is that not enough of the kernel developers are on it.

I originally signed up to bugme to be able to use it as a service
for those folk who want to report a bug against the new code I look
after, but (for me) it's turned into a bug reporting system for all
serial drivers and seemingly its my responsibility to fix them all
(because I can't assign them to anyone else - I don't even know
who else is signed up to bugme to be able to give them away.)

And as a direct result of this, I tend to end up rejecting bug
reports for random serial drivers that I have absolutely no idea
about just because I can't shift them. I don't like doing this
because it means as a whole we're losing valuable bug reports,
but if I don't take this drastic action, I'd end up with pages
of unprocessable bugs.

So, before trying to get the "underworked" bug system used more,
please try to get more developers signed up to it so that we have
the necessary folk behind the bug system to handle the increased
work load.

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core

Hugh Dickins

unread,

Sep 21, 2005, 3:50:16 PM9/21/05

to

On Wed, 21 Sep 2005, Andrew Morton wrote:
>
> I wouldn't say that bugmeister is a fulltime job, but it'll be a
> lot-of-time job. It needs someone who isn't shy and who has a good
> understanding of the kernel code-wise, of the processes (hah) and of the
> people.
>
> The ability to maintain an overall view of where we're at, which bugs are
> serious and which aren't. The ability to succinctly communicate that
> overview to everyone else. Able to tell Linus "you can't release a kernel
> until bugs A, B and C are fixed". The skills and gut-feel to know when a
> patch is some once-off which can be ignored unless it reoccurs, etc. It's
> one of those things which can consume as much effort as one is able to put
> into it.

I recognize this description: sorry, Andrew, can we please clone you?

Hugh

Martin J. Bligh

unread,

Sep 21, 2005, 4:00:17 PM9/21/05

to

>> > Morever bugme.osdl.org is severely underworked (acpi being a noteable
>> > exception) and Andrew has stepped in alot there too. Alot of bugs
>> > reported on the mailing list are only followed up by Andrew.
>>
>> One of the things I'm _really_ missing from OSDL's bugzilla setup is a mailing
>> list (if there's one I've never heard about it) where all changes/new bugs/
>> random crap are posted.
>
> There is such a list - it's a great way to depress yourself while still
> half asleep.
>
> bugm...@lists.osdl.org, but I'm not sure how one subscribes. It doesn't
> appear at http://lists.osdl.org/mailman/listinfo/. Martin?

http://lists.osdl.org/mailman/listinfo/bugme-new

But it's not "all changes/new bugs/random crap", it's "new bugs".
And it's all categories, but there's handy-dandy X- header fields
to filter on.

M.

Diego Calleja

unread,

Sep 21, 2005, 4:20:07 PM9/21/05

to

El Wed, 21 Sep 2005 11:49:48 -0700,
Andrew Morton <ak...@osdl.org> escribió:

> There is such a list - it's a great way to depress yourself while still
> half asleep.

Thanks. While we are at it, what do people thinks about this
very humble wiki page? (ie, does it have sense or I'd better remove it?):

http://wiki.kernelnewbies.org/wiki/LinuxChanges

I'm trying to do something useful, ie like:
http://wiki.dragonflybsd.org/index.php/DragonFly_Status

(yes, I also hate wikis, but if people knows of a better "colaborative
environment" crap which works even with lynx and using it is as easy
*cough* as writing text in a text form in lynx I'm all ears.
http://gcc.gnu.org/wiki/ is also a great example of why kernel could benefit
from using a wiki)

Andrew Morton

unread,

Sep 21, 2005, 4:20:15 PM9/21/05

to

Russell King <rmk+...@arm.linux.org.uk> wrote:
>
> So, before trying to get the "underworked" bug system used more,
> please try to get more developers signed up to it so that we have
> the necessary folk behind the bug system to handle the increased
> work load.

They don't actually need to be signed up to bugzilla. Just cc
bugme-...@kernel-bugs.osdl.org on the email trail and anything with
'[Bug NNNN]' in Subject: gets filed appropriately.

So all you need to do forward the email to the relevant culprit and cc
bugme-...@kernel-bugs.osdl.org. Unfotunately some of the emails which
bugzilla sends (the [bugme-new] ones) don't actually have
bugme-...@kernel-bugs.osdl.org on the To: or Cc: lines, so you need to
add that by hand the first time.

On problem with all this is that once the discussion has gone to email, it
kinda has to stay that way - if someone goes in and updates the bug via the
web interface, those people who were getting the info only via direct email
don't get to see the new info. Generally that works out OK.

It would be nice if

a) we could add non-bugzilla-account-holders to a bug's cc list and

b) Once bugzilla sees any person either sending or receiving emails or
web entries, it autoadds that person to the bug's cc list, so they get
email for all further activity. Could be a bit irritating, but tough
luck ;) We need to fix bugs.

Pierre Ossman

unread,

Sep 22, 2005, 3:20:07 AM9/22/05

to

Russell King wrote:

>So, before trying to get the "underworked" bug system used more,
>please try to get more developers signed up to it so that we have
>the necessary folk behind the bug system to handle the increased
>work load.
>
>
>

What we probably need then is an official policy that maintainers need
to have an account in the bugzilla. Start with the subsystem maintainers
and leave it to them to get each driver maintainer in line. Having only
a handful of parts of the kernel in the bugzilla is just confusing.

Personally I think the mailing lists are a great way for general
discussion. But once we have a confirmed bug (or difficult new feature)
it is better off being tracked in bugzilla. And this is my opinion both
as a user and as a developer. Bugzilla is the de facto standard of
reporting bugs so some users might find it troublesome dealing with
mailing lists such as LKML.

Rgds
Pierre

Rafael J. Wysocki

unread,

Sep 22, 2005, 4:20:13 AM9/22/05

to

Hi,

On Thursday, 22 of September 2005 09:15, Pierre Ossman wrote:
> Russell King wrote:
>
> >So, before trying to get the "underworked" bug system used more,
> >please try to get more developers signed up to it so that we have
> >the necessary folk behind the bug system to handle the increased
> >work load.
> >
> >
> >
>
> What we probably need then is an official policy that maintainers need
> to have an account in the bugzilla. Start with the subsystem maintainers
> and leave it to them to get each driver maintainer in line. Having only
> a handful of parts of the kernel in the bugzilla is just confusing.
>
> Personally I think the mailing lists are a great way for general
> discussion. But once we have a confirmed bug (or difficult new feature)
> it is better off being tracked in bugzilla. And this is my opinion both
> as a user and as a developer. Bugzilla is the de facto standard of
> reporting bugs so some users might find it troublesome dealing with
> mailing lists such as LKML.

Generally, I think, all bugs fall into one of two categories. Namely, there
are bugs that get fixed immediately as soon as someone with a clue sees
the report, compilation problems and the like, and there are bugs that
require much time to be handled. IMHO, it doesn't make sense to litter
bugzilla with bugs of the first kind, but all bugs of the second kind
should be tracked in it, at least for the record.

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"

Eric W. Biederman

unread,

Sep 22, 2005, 5:40:05 AM9/22/05

to

Pierre Ossman <drzeu...@drzeus.cx> writes:

> What we probably need then is an official policy that maintainers need
> to have an account in the bugzilla. Start with the subsystem maintainers
> and leave it to them to get each driver maintainer in line. Having only
> a handful of parts of the kernel in the bugzilla is just confusing.

But the definition of a maintainer is whoever takes responsibility for
part X. The are many pieces of the kernel that don't easily break
up into the taxonomy of subsystem and driver. There are many people
to reluctantly take responsibility because there is no one else,
and so aren't even mentioned in MAINTAINERS much less the rest of it.

> Personally I think the mailing lists are a great way for general
> discussion. But once we have a confirmed bug (or difficult new feature)
> it is better off being tracked in bugzilla. And this is my opinion both
> as a user and as a developer. Bugzilla is the de facto standard of
> reporting bugs so some users might find it troublesome dealing with
> mailing lists such as LKML.

One problem I have with a system like bugzilla is that frequently bug
reports are not complete, and bugzilla sets the expectation that
once you file a bug the reporters part is complete. Frequently it takes
several round trips via email to even understand the bug that is being
reported.

So either we need a two level bug tracking system where there
is a place to capture bugs that users see, and a place to track
bugs that developers understand. Or we need something that is
much more interactive than bugzilla.

I like Andrews idea of a short term mailing lists for each bug. Where
filing the bug creates the mailing list and the mailing list exists
until the bug is closed sounds like something that might even get
used, as it can be easy for everyone.

Eric

Russell King

unread,

Sep 22, 2005, 5:50:07 AM9/22/05

to

On Thu, Sep 22, 2005 at 03:30:21AM -0600, Eric W. Biederman wrote:
> One problem I have with a system like bugzilla is that frequently bug
> reports are not complete, and bugzilla sets the expectation that
> once you file a bug the reporters part is complete. Frequently it takes
> several round trips via email to even understand the bug that is being
> reported.

What it needs is something like the Red Hat bugzilla front end,
where reporters are guided through the information they need to
submit. Maybe that would help with bugme if we had such a front
end?

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core

Pierre Ossman

unread,

Sep 22, 2005, 7:00:09 AM9/22/05

to

Eric W. Biederman wrote:

>But the definition of a maintainer is whoever takes responsibility for
>part X. The are many pieces of the kernel that don't easily break
>up into the taxonomy of subsystem and driver. There are many people
>to reluctantly take responsibility because there is no one else,
>and so aren't even mentioned in MAINTAINERS much less the rest of it.
>
>
>

Setting up an account for a mailing list and linking unmaintained parts
to it would be a solution to that. Either set up a specific list for
this or use when of the current ones (like LKML). The big problem I see
at the moment is that not all parts of the kernel are represented in the
bugzilla.

>One problem I have with a system like bugzilla is that frequently bug
>reports are not complete, and bugzilla sets the expectation that
>once you file a bug the reporters part is complete. Frequently it takes
>several round trips via email to even understand the bug that is being
>reported.
>
>

I agree that most bug reports are incomplete. But I still think that a
bugzilla is the way to go. We need to educate the users in filing bug
reports no matter which forum is used. Russell's point about having a
wizard would probably help a lot. A bugzilla also gives the option of
marking bugs with NEEDINFO, INVALID and similar, clearly expressing to
the user how the maintainer sees this bug.

>So either we need a two level bug tracking system where there
>is a place to capture bugs that users see, and a place to track
>bugs that developers understand. Or we need something that is
>much more interactive than bugzilla.
>
>
>

I think that the categories NEW/ASSIGNED/CONFIRMED suffices. Although
discussions on mailing lists are more natural for the people here I
don't agree that bugzilla is less interactive than lists.

Rgds
Pierre

Diego Calleja

unread,

Sep 26, 2005, 8:10:08 AM9/26/05

to

El Wed, 21 Sep 2005 12:54:58 -0700,
"Martin J. Bligh" <mbl...@mbligh.org> escribió:

> http://lists.osdl.org/mailman/listinfo/bugme-new
>
> But it's not "all changes/new bugs/random crap", it's "new bugs".
> And it's all categories, but there's handy-dandy X- header fields
> to filter on.

I discovered this other ml: http://lists.osdl.org/mailman/listinfo/bugme-janitors

So, http://lists.osdl.org/mailman/listinfo/bugme-new is just for new bugs
and http://lists.osdl.org/mailman/listinfo/bugme-janitors for everything else,
or bugme-janitors is non-functional? (I tried to subscribe to check it myself but
subscription requires "moderator approval")

If so, can we have the bugme-janitors and bugme-new archives opened for
everyone (so google can index it?)

Martin J. Bligh

unread,

Sep 26, 2005, 9:50:14 AM9/26/05

to

--Diego Calleja <die...@gmail.com> wrote (on Monday, September 26, 2005 14:09:00 +0200):

> El Wed, 21 Sep 2005 12:54:58 -0700,
> "Martin J. Bligh" <mbl...@mbligh.org> escribió:
>
>> http://lists.osdl.org/mailman/listinfo/bugme-new
>>
>> But it's not "all changes/new bugs/random crap", it's "new bugs".
>> And it's all categories, but there's handy-dandy X- header fields
>> to filter on.
>
> I discovered this other ml: http://lists.osdl.org/mailman/listinfo/bugme-janitors
>
> So, http://lists.osdl.org/mailman/listinfo/bugme-new is just for new bugs
> and http://lists.osdl.org/mailman/listinfo/bugme-janitors for everything else,
> or bugme-janitors is non-functional? (I tried to subscribe to check it myself but
> subscription requires "moderator approval")

Ooops. shouldn't do. will fix.

> If so, can we have the bugme-janitors and bugme-new archives opened for
> everyone (so google can index it?)

Yeah, sounds fair enough (though I think google will index bugzilla too)

M.