* Question about UFS/UFS2
2003-12-17 9:43 2.6.0-test11-mm1 Andrew Morton
@ 2003-12-17 10:13 ` Niraj Kumar
2003-12-17 10:37 ` 2.6.0-test11-mm1 Andrew Walrond
` (6 subsequent siblings)
7 siblings, 0 replies; 20+ messages in thread
From: Niraj Kumar @ 2003-12-17 10:13 UTC (permalink / raw)
To: linux-kernel
Hi,
Is anybody working on/planning to support UFS2 filesystem
( of FreeBSD 5.x ) in Linux ?
As far as I understand , even ufs support is read only (not quite stable ).
Anybody working in this area ? Or should I try to get my hands dirty ?
Niraj
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: 2.6.0-test11-mm1
2003-12-17 9:43 2.6.0-test11-mm1 Andrew Morton
2003-12-17 10:13 ` Question about UFS/UFS2 Niraj Kumar
@ 2003-12-17 10:37 ` Andrew Walrond
2003-12-17 11:11 ` 2.6.0-test11-mm1 Christian Axelsson
2003-12-17 11:52 ` 2.6.0-test11-mm1 Andrew Morton
` (5 subsequent siblings)
7 siblings, 1 reply; 20+ messages in thread
From: Andrew Walrond @ 2003-12-17 10:37 UTC (permalink / raw)
To: linux-kernel
On Wednesday 17 Dec 2003 9:43 am, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test11/
>2.6.0-test11-mm1/
>
Hi Andrew
What are your intentions with -mm when you take over 2.6? Is any of -mm
getting into 2.6 before 2.6.0 release? Is it mainly queued for 2.6.1?
Andrew Walrond
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: 2.6.0-test11-mm1
2003-12-17 10:37 ` 2.6.0-test11-mm1 Andrew Walrond
@ 2003-12-17 11:11 ` Christian Axelsson
2003-12-17 11:51 ` 2.6.0-test11-mm1 Andrew Morton
0 siblings, 1 reply; 20+ messages in thread
From: Christian Axelsson @ 2003-12-17 11:11 UTC (permalink / raw)
To: Andrew Walrond; +Cc: linux-kernel
Andrew Walrond wrote:
> On Wednesday 17 Dec 2003 9:43 am, Andrew Morton wrote:
> What are your intentions with -mm when you take over 2.6? Is any of -mm
> getting into 2.6 before 2.6.0 release? Is it mainly queued for 2.6.1?
I would like to know aswell :)
Will you be "bleeding edge" maintainer aswell or will that be handed
over to someone else?
--
Christan Axelsson
smiler@lanil.mine.nu
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.6.0-test11-mm1
2003-12-17 11:11 ` 2.6.0-test11-mm1 Christian Axelsson
@ 2003-12-17 11:51 ` Andrew Morton
2003-12-18 3:24 ` 2.6.0-test11-mm1 Thomas Molina
0 siblings, 1 reply; 20+ messages in thread
From: Andrew Morton @ 2003-12-17 11:51 UTC (permalink / raw)
To: Christian Axelsson; +Cc: andrew, linux-kernel
Christian Axelsson <smiler@lanil.mine.nu> wrote:
>
> Andrew Walrond wrote:
> > On Wednesday 17 Dec 2003 9:43 am, Andrew Morton wrote:
>
> > What are your intentions with -mm when you take over 2.6? Is any of -mm
> > getting into 2.6 before 2.6.0 release? Is it mainly queued for 2.6.1?
We'll start merging it up after 2.6.0. It'll be quite a lot of work,
actually - a lot of things have been parked in -mm for some time and may
not have had sufficiently wide testing, especially on non-i386. I need to
ask the originators and others to re-review and retest some things.
> I would like to know aswell :)
> Will you be "bleeding edge" maintainer aswell or will that be handed
> over to someone else?
I guess I'll keep -mm going until there's a reason not to.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.6.0-test11-mm1
2003-12-17 11:51 ` 2.6.0-test11-mm1 Andrew Morton
@ 2003-12-18 3:24 ` Thomas Molina
2003-12-18 3:36 ` 2.6.0-test11-mm1 Andrew Morton
0 siblings, 1 reply; 20+ messages in thread
From: Thomas Molina @ 2003-12-18 3:24 UTC (permalink / raw)
To: Andrew Morton; +Cc: Christian Axelsson, andrew, linux-kernel
On Wed, 17 Dec 2003, Andrew Morton wrote:
> Christian Axelsson <smiler@lanil.mine.nu> wrote:
> >
> > Andrew Walrond wrote:
> > > On Wednesday 17 Dec 2003 9:43 am, Andrew Morton wrote:
> >
> > > What are your intentions with -mm when you take over 2.6? Is any of -mm
> > > getting into 2.6 before 2.6.0 release? Is it mainly queued for 2.6.1?
>
> We'll start merging it up after 2.6.0. It'll be quite a lot of work,
> actually - a lot of things have been parked in -mm for some time and may
> not have had sufficiently wide testing, especially on non-i386. I need to
> ask the originators and others to re-review and retest some things.
>
> > I would like to know aswell :)
> > Will you be "bleeding edge" maintainer aswell or will that be handed
> > over to someone else?
>
> I guess I'll keep -mm going until there's a reason not to.
Quite frankly I am becoming concerned about the number of patches that are
queued for post 2.6.0. It is beginning to look like 2.6.0 might be nice
and quiet while 2.6.1+ are going to be quite messy as all the things "on
hold" get put in.
I'm going to do my part by pounding heavily on -mm kernels since that
appears where all this is ending up.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.6.0-test11-mm1
2003-12-18 3:24 ` 2.6.0-test11-mm1 Thomas Molina
@ 2003-12-18 3:36 ` Andrew Morton
2003-12-19 18:21 ` 2.6.0-test11-mm1 Jens Axboe
0 siblings, 1 reply; 20+ messages in thread
From: Andrew Morton @ 2003-12-18 3:36 UTC (permalink / raw)
To: Thomas Molina; +Cc: smiler, andrew, linux-kernel
Thomas Molina <tmolina@cablespeed.com> wrote:
>
> Quite frankly I am becoming concerned about the number of patches that are
> queued for post 2.6.0. It is beginning to look like 2.6.0 might be nice
> and quiet while 2.6.1+ are going to be quite messy as all the things "on
> hold" get put in.
Well, most of these things do address real problems. It's a matter of
feeding them in at an appropriate rate and with a higher level of testing.
> I'm going to do my part by pounding heavily on -mm kernels since that
> appears where all this is ending up.
That would be useful. Testing on non-ia32 platforms remains a concern. I
test on ia64 and ppc64, but I'm not aware of anyone regularly testing -mm
things on other architectures.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.6.0-test11-mm1
2003-12-18 3:36 ` 2.6.0-test11-mm1 Andrew Morton
@ 2003-12-19 18:21 ` Jens Axboe
0 siblings, 0 replies; 20+ messages in thread
From: Jens Axboe @ 2003-12-19 18:21 UTC (permalink / raw)
To: Andrew Morton; +Cc: Thomas Molina, smiler, andrew, linux-kernel
On Wed, Dec 17 2003, Andrew Morton wrote:
> > I'm going to do my part by pounding heavily on -mm kernels since that
> > appears where all this is ending up.
>
> That would be useful. Testing on non-ia32 platforms remains a concern. I
> test on ia64 and ppc64, but I'm not aware of anyone regularly testing -mm
> things on other architectures.
I've tested regularly on x86_64 (which I think is more important than
both ia64 (who cares) and ppc64). I'll start doing that again.
--
Jens Axboe
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.6.0-test11-mm1
2003-12-17 9:43 2.6.0-test11-mm1 Andrew Morton
2003-12-17 10:13 ` Question about UFS/UFS2 Niraj Kumar
2003-12-17 10:37 ` 2.6.0-test11-mm1 Andrew Walrond
@ 2003-12-17 11:52 ` Andrew Morton
2003-12-17 13:30 ` 2.6.0-test11-mm1 Felipe Alfaro Solana
2003-12-17 11:57 ` UP build broken (Re: 2.6.0-test11-mm1) Dagfinn Ilmari Mannsåker
` (4 subsequent siblings)
7 siblings, 1 reply; 20+ messages in thread
From: Andrew Morton @ 2003-12-17 11:52 UTC (permalink / raw)
To: linux-kernel, linux-mm
Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test11/2.6.0-test11-mm1/
>
>
> A fair number of new fixes
And new breakage too!
In file included from arch/i386/kernel/cpu/intel.c:14:
include/asm-i386/mach-default/mach_apic.h:8: error: syntax error before "target_cpus"
include/asm-i386/mach-default/mach_apic.h:9: warning: return type defaults to `int'
Fix:
diff -puN arch/i386/kernel/cpu/intel.c~cpu_sibling_map-fixes-fix arch/i386/kernel/cpu/intel.c
--- 25/arch/i386/kernel/cpu/intel.c~cpu_sibling_map-fixes-fix 2003-12-17 03:31:56.000000000 -0800
+++ 25-akpm/arch/i386/kernel/cpu/intel.c 2003-12-17 03:46:25.000000000 -0800
@@ -8,9 +8,11 @@
#include <asm/processor.h>
#include <asm/msr.h>
#include <asm/uaccess.h>
+#include <asm/mpspec.h>
+#include <asm/apic.h>
#include "cpu.h"
-#include "mach_apic.h"
+#include <mach_apic.h>
extern int trap_init_f00f_bug(void);
_
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: 2.6.0-test11-mm1
2003-12-17 11:52 ` 2.6.0-test11-mm1 Andrew Morton
@ 2003-12-17 13:30 ` Felipe Alfaro Solana
0 siblings, 0 replies; 20+ messages in thread
From: Felipe Alfaro Solana @ 2003-12-17 13:30 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linux Kernel Mailinglist, linux-mm
[-- Attachment #1: Type: text/plain, Size: 681 bytes --]
On Wed, 2003-12-17 at 12:52, Andrew Morton wrote:
> And new breakage too!
> Fix:
>
>
> diff -puN arch/i386/kernel/cpu/intel.c~cpu_sibling_map-fixes-fix arch/i386/kernel/cpu/intel.c
> --- 25/arch/i386/kernel/cpu/intel.c~cpu_sibling_map-fixes-fix 2003-12-17 03:31:56.000000000 -0800
> +++ 25-akpm/arch/i386/kernel/cpu/intel.c 2003-12-17 03:46:25.000000000 -0800
> @@ -8,9 +8,11 @@
> #include <asm/processor.h>
> #include <asm/msr.h>
> #include <asm/uaccess.h>
> +#include <asm/mpspec.h>
> +#include <asm/apic.h>
>
> #include "cpu.h"
> -#include "mach_apic.h"
> +#include <mach_apic.h>
>
> extern int trap_init_f00f_bug(void);
Does not apply cleanly, but this one does.
[-- Attachment #2: intel.c~cpu_sibling_map-fixes-fix --]
[-- Type: text/x-patch, Size: 534 bytes --]
diff -uNr linux-2.6.0-test11/arch/i386/kernel/cpu/intel.c linux-2.6.0-test11-mm1/arch/i386/kernel/cpu/intel.c
--- linux-2.6.0-test11/arch/i386/kernel/cpu/intel.c 2003-12-17 14:21:29.060115753 +0100
+++ linux-2.6.0-test11-mm1/arch/i386/kernel/cpu/intel.c 2003-12-17 14:10:39.886919748 +0100
@@ -9,9 +9,11 @@
#include <asm/msr.h>
#include <asm/uaccess.h>
#include <asm/desc.h>
+#include <asm/mpspec.h>
+#include <asm/apic.h>
#include "cpu.h"
-#include "mach_apic.h"
+#include <mach_apic.h>
#ifdef CONFIG_X86_INTEL_USERCOPY
/*
^ permalink raw reply [flat|nested] 20+ messages in thread
* UP build broken (Re: 2.6.0-test11-mm1)
2003-12-17 9:43 2.6.0-test11-mm1 Andrew Morton
` (2 preceding siblings ...)
2003-12-17 11:52 ` 2.6.0-test11-mm1 Andrew Morton
@ 2003-12-17 11:57 ` Dagfinn Ilmari Mannsåker
2003-12-17 11:55 ` Luiz Fernando Capitulino
2003-12-17 13:56 ` 2.6.0-test11-mm1 Zwane Mwaikambo
` (3 subsequent siblings)
7 siblings, 1 reply; 20+ messages in thread
From: Dagfinn Ilmari Mannsåker @ 2003-12-17 11:57 UTC (permalink / raw)
To: linux-kernel
Hi
Without CONFIG_SMP (regardless of CONFIG_X86_UP_(IO)APIC) I get the
following build error:
CC arch/i386/kernel/cpu/intel.o
In file included from arch/i386/kernel/cpu/intel.c:14:
include/asm-i386/mach-default/mach_apic.h:8: error: syntax error before "target_cpus"
include/asm-i386/mach-default/mach_apic.h:9: warning: return type defaults to `int'
include/asm-i386/mach-default/mach_apic.h: In function `target_cpus':
include/asm-i386/mach-default/mach_apic.h:13: warning: implicit declaration of function `mk_cpumask_const'
include/asm-i386/mach-default/mach_apic.h:13: warning: implicit declaration of function `cpumask_of_cpu'
include/asm-i386/mach-default/mach_apic.h: At top level:
include/asm-i386/mach-default/mach_apic.h:32: error: syntax error before "bitmap"
include/asm-i386/mach-default/mach_apic.h:33: warning: function declaration isn't a prototype
include/asm-i386/mach-default/mach_apic.h: In function `check_apicid_used':
include/asm-i386/mach-default/mach_apic.h:34: warning: implicit declaration of function `physid_isset'
include/asm-i386/mach-default/mach_apic.h:34: error: `apicid' undeclared (first use in this function)
include/asm-i386/mach-default/mach_apic.h:34: error: (Each undeclared identifier is reported only once
include/asm-i386/mach-default/mach_apic.h:34: error: for each function it appears in.)
include/asm-i386/mach-default/mach_apic.h:34: error: `bitmap' undeclared (first use in this function)
include/asm-i386/mach-default/mach_apic.h: In function `check_apicid_present':
include/asm-i386/mach-default/mach_apic.h:39: error: `phys_cpu_present_map' undeclared (first use in this function)
include/asm-i386/mach-default/mach_apic.h: In function `init_apic_ldr':
include/asm-i386/mach-default/mach_apic.h:53: warning: implicit declaration of function `apic_write_around'
include/asm-i386/mach-default/mach_apic.h:53: error: `APIC_DFR' undeclared (first use in this function)
include/asm-i386/mach-default/mach_apic.h:53: error: `APIC_DFR_FLAT' undeclared (first use in this function)
include/asm-i386/mach-default/mach_apic.h:54: warning: implicit declaration of function `apic_read'
include/asm-i386/mach-default/mach_apic.h:54: error: `APIC_LDR' undeclared (first use in this function)
include/asm-i386/mach-default/mach_apic.h:54: error: `APIC_LDR_MASK' undeclared (first use in this function)
include/asm-i386/mach-default/mach_apic.h:55: warning: implicit declaration of function `SET_APIC_LOGICAL_ID'
include/asm-i386/mach-default/mach_apic.h: At top level:
include/asm-i386/mach-default/mach_apic.h:59: error: syntax error before "ioapic_phys_id_map"
include/asm-i386/mach-default/mach_apic.h:59: error: syntax error before "phys_map"
include/asm-i386/mach-default/mach_apic.h:60: warning: return type defaults to `int'
include/asm-i386/mach-default/mach_apic.h:60: warning: function declaration isn't a prototype
include/asm-i386/mach-default/mach_apic.h: In function `ioapic_phys_id_map':
include/asm-i386/mach-default/mach_apic.h:61: error: `phys_map' undeclared (first use in this function)
include/asm-i386/mach-default/mach_apic.h: In function `clustered_apic_check':
include/asm-i386/mach-default/mach_apic.h:67: error: `nr_ioapics' undeclared (first use in this function)
include/asm-i386/mach-default/mach_apic.h: At top level:
include/asm-i386/mach-default/mach_apic.h:91: error: syntax error before "apicid_to_cpu_present"
include/asm-i386/mach-default/mach_apic.h:92: warning: return type defaults to `int'
include/asm-i386/mach-default/mach_apic.h: In function `apicid_to_cpu_present':
include/asm-i386/mach-default/mach_apic.h:93: warning: implicit declaration of function `physid_mask_of_physid'
include/asm-i386/mach-default/mach_apic.h: At top level:
include/asm-i386/mach-default/mach_apic.h:97: warning: `struct mpc_config_translation' declared inside parameter list
include/asm-i386/mach-default/mach_apic.h:97: warning: its scope is only this definition or declaration, which is probably not what you want
include/asm-i386/mach-default/mach_apic.h:97: warning: `struct mpc_config_processor' declared inside parameter list
include/asm-i386/mach-default/mach_apic.h: In function `mpc_apic_id':
include/asm-i386/mach-default/mach_apic.h:100: error: dereferencing pointer to incomplete type
include/asm-i386/mach-default/mach_apic.h:101: error: dereferencing pointer to incomplete type
include/asm-i386/mach-default/mach_apic.h:101: error: `CPU_FAMILY_MASK' undeclared (first use in this function)
include/asm-i386/mach-default/mach_apic.h:102: error: dereferencing pointer to incomplete type
include/asm-i386/mach-default/mach_apic.h:102: error: `CPU_MODEL_MASK' undeclared (first use in this function)
include/asm-i386/mach-default/mach_apic.h:103: error: dereferencing pointer to incomplete type
include/asm-i386/mach-default/mach_apic.h:104: error: dereferencing pointer to incomplete type
include/asm-i386/mach-default/mach_apic.h: In function `check_phys_apicid_present':
include/asm-i386/mach-default/mach_apic.h:113: error: `phys_cpu_present_map' undeclared (first use in this function)
include/asm-i386/mach-default/mach_apic.h: In function `apic_id_registered':
include/asm-i386/mach-default/mach_apic.h:118: error: `APIC_ID' undeclared (first use in this function)
include/asm-i386/mach-default/mach_apic.h:118: error: `phys_cpu_present_map' undeclared (first use in this function)
include/asm-i386/mach-default/mach_apic.h: At top level:
include/asm-i386/mach-default/mach_apic.h:121: error: syntax error before "cpumask"
include/asm-i386/mach-default/mach_apic.h:122: warning: function declaration isn't a prototype
include/asm-i386/mach-default/mach_apic.h: In function `cpu_mask_to_apicid':
include/asm-i386/mach-default/mach_apic.h:123: warning: implicit declaration of function `cpus_coerce_const'
include/asm-i386/mach-default/mach_apic.h:123: error: `cpumask' undeclared (first use in this function)
make[1]: *** [arch/i386/kernel/cpu/intel.o] Error 1
make: *** [arch/i386/kernel/cpu/intel.o] Error 2
--
ilmari
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: UP build broken (Re: 2.6.0-test11-mm1)
2003-12-17 11:57 ` UP build broken (Re: 2.6.0-test11-mm1) Dagfinn Ilmari Mannsåker
@ 2003-12-17 11:55 ` Luiz Fernando Capitulino
0 siblings, 0 replies; 20+ messages in thread
From: Luiz Fernando Capitulino @ 2003-12-17 11:55 UTC (permalink / raw)
To: Dagfinn Ilmari Mannsåker; +Cc: linux-kernel, akpm
Em Qua, 2003-12-17 às 09:57, Dagfinn Ilmari Mannsåker escreveu:
> Hi
>
> Without CONFIG_SMP (regardless of CONFIG_X86_UP_(IO)APIC) I get the
> following build error:
>
> CC arch/i386/kernel/cpu/intel.o
> In file included from arch/i386/kernel/cpu/intel.c:14:
> include/asm-i386/mach-default/mach_apic.h:8: error: syntax error before "target_cpus"
I'm getting the some thing. I think the file
asm-generic/cpu_mask_const_value.h is not included (this file have the
definitions).
--
Luiz Fernando N. Capitulino
<lcapitulino@prefeitura.sp.gov.br>
<http://www.telecentros.sp.gov.br>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2.6.0-test11-mm1
2003-12-17 9:43 2.6.0-test11-mm1 Andrew Morton
` (3 preceding siblings ...)
2003-12-17 11:57 ` UP build broken (Re: 2.6.0-test11-mm1) Dagfinn Ilmari Mannsåker
@ 2003-12-17 13:56 ` Zwane Mwaikambo
2003-12-17 18:22 ` 2.6.0-test11-mm1 Diego Calleja García
` (2 subsequent siblings)
7 siblings, 0 replies; 20+ messages in thread
From: Zwane Mwaikambo @ 2003-12-17 13:56 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linux Kernel, linux-mm
Hullo Andrew,
I believe this was the intention;
On Wed, 17 Dec 2003, Andrew Morton wrote:
> mpparse_es7000.patch
> mpparse: fix IRQ breakage from the es7000 merge
For ES7000 add an offset of 16 to the irq in order to setup a mapping where
ISA/legacy interrupts are in the 0-15 range and PCI 16 and above. This was
a cleanup fix in order to facilitate easy differentiating between legacy
and non legacy interrupt setup.
===
The ES7000 merge added a bit of code of offset the IRQ numbers. We're not
too sure why; it wasn't changelogged.
But it broke other systems, so this patch arranges for that code to only be
activated on es7000 machines.
arch/i386/kernel/dmi_scan.c | 1 +
arch/i386/kernel/mpparse.c | 7 +++++--
arch/i386/mach-es7000/es7000.c | 2 --
include/asm-i386/system.h | 1 +
4 files changed, 7 insertions(+), 4 deletions(-)
diff -puN arch/i386/kernel/dmi_scan.c~mpparse_es7000 arch/i386/kernel/dmi_scan.c
--- 25/arch/i386/kernel/dmi_scan.c~mpparse_es7000 2003-11-21 01:30:11.000000000 -0800
+++ 25-akpm/arch/i386/kernel/dmi_scan.c 2003-11-21 01:30:11.000000000 -0800
@@ -16,6 +16,7 @@ EXPORT_SYMBOL(dmi_broken);
int is_sony_vaio_laptop;
int is_unsafe_smbus;
+int es7000_plat = 0;
struct dmi_header
{
diff -puN arch/i386/kernel/mpparse.c~mpparse_es7000 arch/i386/kernel/mpparse.c
--- 25/arch/i386/kernel/mpparse.c~mpparse_es7000 2003-11-21 01:30:11.000000000 -0800
+++ 25-akpm/arch/i386/kernel/mpparse.c 2003-11-21 01:30:11.000000000 -0800
@@ -1129,8 +1129,11 @@ void __init mp_parse_prt (void)
continue;
ioapic_pin = irq - mp_ioapic_routing[ioapic].irq_start;
- if (!ioapic && (irq < 16))
- irq += 16;
+ if (es7000_plat) {
+ if (!ioapic && (irq < 16))
+ irq += 16;
+ }
+
/*
* Avoid pin reprogramming. PRTs typically include entries
* with redundant pin->irq mappings (but unique PCI devices);
diff -puN arch/i386/mach-es7000/es7000.c~mpparse_es7000 arch/i386/mach-es7000/es7000.c
--- 25/arch/i386/mach-es7000/es7000.c~mpparse_es7000 2003-11-21 01:30:11.000000000 -0800
+++ 25-akpm/arch/i386/mach-es7000/es7000.c 2003-11-21 01:30:11.000000000 -0800
@@ -51,8 +51,6 @@ struct mip_reg *host_reg;
int mip_port;
unsigned long mip_addr, host_addr;
-static int es7000_plat;
-
/*
* Parse the OEM Table
*/
diff -puN include/asm-i386/system.h~mpparse_es7000 include/asm-i386/system.h
--- 25/include/asm-i386/system.h~mpparse_es7000 2003-11-21 01:30:11.000000000 -0800
+++ 25-akpm/include/asm-i386/system.h 2003-11-21 01:30:11.000000000 -0800
@@ -470,6 +470,7 @@ void enable_hlt(void);
extern unsigned long dmi_broken;
extern int is_sony_vaio_laptop;
+extern int es7000_plat;
#define BROKEN_ACPI_Sx 0x0001
#define BROKEN_INIT_AFTER_S1 0x0002
_
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: 2.6.0-test11-mm1
2003-12-17 9:43 2.6.0-test11-mm1 Andrew Morton
` (4 preceding siblings ...)
2003-12-17 13:56 ` 2.6.0-test11-mm1 Zwane Mwaikambo
@ 2003-12-17 18:22 ` Diego Calleja García
2003-12-17 22:01 ` 2.6.0-test11-mm1 Andrew Morton
2003-12-19 16:58 ` [patch] 2.6.0-test11-mm1: isdn/eicon/eicon_mod.c doesn't compile Adrian Bunk
2003-12-26 18:22 ` SUCCESS Re: 2.6.0-test11-mm1 Matthias Urlichs
7 siblings, 1 reply; 20+ messages in thread
From: Diego Calleja García @ 2003-12-17 18:22 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
El Wed, 17 Dec 2003 01:43:50 -0800 Andrew Morton <akpm@osdl.org> escribió:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test11/2.6.0-test11-mm1/
I got this oops while disconnecting and connecting my (normal, AT 105 keys) keyboard (the keyboard behaviour
was/is strange, it feels like it has "latency"). Full dmesg attached.
NVS)
BIOS-e820: 000000001fff3000 - 0000000020000000 (ACPI data)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
511MB LOWMEM available.
found SMP MP-table at 000f64e0
hm, page 000f6000 reserved twice.
hm, page 000f7000 reserved twice.
hm, page 000f1000 reserved twice.
hm, page 000f2000 reserved twice.
On node 0 totalpages: 131056
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 126960 pages, LIFO batch:16
HighMem zone: 0 pages, LIFO batch:1
DMI 2.2 present.
ACPI: RSDP (v000 VIA694 ) @ 0x000f7e10
ACPI: RSDT (v001 VIA694 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff3000
ACPI: FADT (v001 VIA694 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff3040
ACPI: MADT (v001 VIA694 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff5b80
ACPI: DSDT (v001 VIA694 AWRDACPI 0x00001000 MSFT 0x0100000c) @ 0x00000000
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 6:8 APIC version 17
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1 6:8 APIC version 17
Using ACPI for processor (LAPIC) configuration information
Intel MultiProcessor Specification v1.4
Virtual Wire compatibility mode.
OEM ID: OEM00000 Product ID: PROD00000000 APIC at: 0xFEE00000
I/O APIC #2 Version 17 at 0xFEC00000.
Enabling APIC mode: Flat. Using 1 I/O APICs
Processors: 2
Building zonelist for node : 0
Kernel command line: profile=2 nmi_watchdog=1 ro root=/dev/hda2 vga=0x30a noirqbalance debug
kernel profiling enabled
current: c0312ba0
current->thread_info: c0356000
Initializing CPU#0
PID hash table entries: 2048 (order 11: 16384 bytes)
Detected 803.113 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 132x43
Memory: 513576k/524224k available (1834k kernel code, 9864k reserved, 555k data, 196k init, 0k highmem)
Calibrating delay loop... 1581.05 BogoMIPS
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: 0383fbff 00000000 00000000 00000000
CPU: After vendor identify, caps: 0383fbff 00000000 00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU: After all inits, caps: 0383fbff 00000000 00000000 00000040
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
CPU0: Intel Pentium III (Coppermine) stepping 06
per-CPU timeslice cutoff: 731.26 usecs.
task migration cache decay timeout: 1 msecs.
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Booting processor 1/1 eip 2000
Initializing CPU#1
masked ExtINT on CPU#1
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Calibrating delay loop... 1601.53 BogoMIPS
CPU: After generic identify, caps: 0383fbff 00000000 00000000 00000000
CPU: After vendor identify, caps: 0383fbff 00000000 00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU: After all inits, caps: 0383fbff 00000000 00000000 00000040
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel Pentium III (Coppermine) stepping 06
Total of 2 processors activated (3182.59 BogoMIPS).
ENABLING IO-APIC IRQs
Setting 2 in the phys_id_present_map
...changing IO-APIC physical APIC ID to 2 ... ok.
init IO_APIC IRQs
IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected.
..TIMER: vector=0x31 pin1=2 pin2=0
activating NMI Watchdog ... done.
testing NMI watchdog ... OK.
number of MP IRQ sources: 18.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................
IO APIC #2......
.... register #00: 02000000
....... : physical APIC id: 02
....... : Delivery Type: 0
....... : LTS : 0
.... register #01: 00178011
....... : max redirection entries: 0017
....... : PRQ implemented: 1
....... : IO APIC version: 0011
.... register #02: 00000000
....... : arbitration: 00
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 000 00 1 0 0 0 0 0 0 00
01 001 01 0 0 0 0 0 1 1 39
02 001 01 0 0 0 0 0 1 1 31
03 001 01 0 0 0 0 0 1 1 41
04 001 01 0 0 0 0 0 1 1 49
05 001 01 0 0 0 0 0 1 1 51
06 001 01 0 0 0 0 0 1 1 59
07 001 01 0 0 0 0 0 1 1 61
08 001 01 0 0 0 0 0 1 1 69
09 001 01 1 1 0 1 0 1 1 71
0a 001 01 1 1 0 1 0 1 1 79
0b 001 01 1 1 0 1 0 1 1 81
0c 001 01 1 1 0 1 0 1 1 89
0d 001 01 0 0 0 0 0 1 1 91
0e 001 01 0 0 0 0 0 1 1 99
0f 001 01 0 0 0 0 0 1 1 A1
10 000 00 1 0 0 0 0 0 0 00
11 000 00 1 0 0 0 0 0 0 00
12 000 00 1 0 0 0 0 0 0 00
13 000 00 1 0 0 0 0 0 0 00
14 000 00 1 0 0 0 0 0 0 00
15 000 00 1 0 0 0 0 0 0 00
16 000 00 1 0 0 0 0 0 0 00
17 000 00 1 0 0 0 0 0 0 00
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ5 -> 0:5
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
IRQ25 -> 0:9
IRQ26 -> 0:10
IRQ27 -> 0:11
IRQ28 -> 0:12
.................................... done.
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 802.0779 MHz.
..... host bus clock speed is 133.0796 MHz.
checking TSC synchronization across 2 CPUs: passed.
Starting migration thread for cpu 0
Bringing up 1
CPU 1 IS NOW UP!
Starting migration thread for cpu 1
CPUS done 2
zapping low mappings.
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfb250, last bus=1
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
mtrr: your CPUs had inconsistent variable MTRR settings
mtrr: probably your BIOS does not setup all CPUs.
mtrr: corrected configuration.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: the driver 'system' has been registered
PnPBIOS: Scanning system for PnP BIOS support...
PnPBIOS: Found PnP BIOS installation structure at 0xc00fbcc0
PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0xbcf0, dseg 0xf0000
pnp: match found with the PnP device '00:07' and the driver 'system'
pnp: match found with the PnP device '00:08' and the driver 'system'
PnPBIOS: 14 nodes reported by PnP BIOS; 14 recorded by driver
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Using IRQ router VIA [1106/0686] at 0000:00:07.0
PCI->APIC IRQ transform: (B0,I7,P3) -> 113
PCI->APIC IRQ transform: (B0,I7,P3) -> 113
PCI->APIC IRQ transform: (B0,I7,P2) -> 137
PCI->APIC IRQ transform: (B0,I13,P0) -> 129
PCI->APIC IRQ transform: (B1,I0,P0) -> 121
IA-32 Microcode Update Driver: v1.13 <tigran@veritas.com>
ikconfig 0.7 with /proc/config*
PCI: Enabling Via external APIC routing
PCI: Via IRQ fixup for 0000:00:07.2, from 9 to 1
PCI: Via IRQ fixup for 0000:00:07.3, from 9 to 1
PCI: Via IRQ fixup for 0000:00:07.5, from 12 to 9
pty: 256 Unix98 ptys configured
request_module: failed /sbin/modprobe -- parport_lowlevel. error = -16
lp: driver loaded but no devices found
Real Time Clock Driver v1.12
Non-volatile memory driver v1.2
ppdev: user-space parallel port driver
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected VIA Apollo Pro 133 chipset
agpgart: Maximum main memory to use for agp memory: 439M
agpgart: AGP aperture is 256M @ 0xc0000000
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
pnp: the driver 'serial' has been registered
pnp: match found with the PnP device '00:0d' and the driver 'serial'
pnp: match found with the PnP device '00:0e' and the driver 'serial'
pnp: the driver 'parport_pc' has been registered
pnp: match found with the PnP device '00:10' and the driver 'parport_pc'
parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE]
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
lp0: using parport0 (polling).
lp0: console ready
parport_pc: Via 686A parallel port: io=0x378
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
0000:00:0d.0: 3Com PCI 3c905C Tornado at 0xec00. Vers LK1.1.19
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot 0000:00:07.1
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci0000:00:07.1
ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA
hda: Maxtor 6Y060L0, ATA DISK drive
Using anticipatory io scheduler
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: HL-DT-ST GCE-8520B, ATAPI CD/DVD-ROM drive
hdd: LG CD-ROM CRD-8522B, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 120103200 sectors (61492 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
hda: hda1 < hda5 hda6 hda7 hda8 > hda2 hda3
mice: PS/2 mouse device common for all mice
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
i2c /dev entries driver
Advanced Linux Sound Architecture Driver Version 0.9.7 (Thu Sep 25 19:16:36 2003 UTC).
request_module: failed /sbin/modprobe -- snd-card-0. error = -16
PCI: Setting latency timer of device 0000:00:07.5 to 64
ALSA device list:
#0: VIA 82C686A/B rev50 at 0xdc00, irq 137
NET: Registered protocol family 2
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
NET: Registered protocol family 1
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 196k freed
Adding 500400k swap on /dev/hda5. Priority:-1 extents:1
EXT3 FS on hda2, internal journal
ip_tables: (C) 2000-2002 Netfilter core team
ip_conntrack version 2.1 (4095 buckets, 32760 max) - 304 bytes per conntrack
input: AT Translated Set 2 keyboard on isa0060/serio0
CSLIP: code copyright 1989 Regents of the University of California
PPP generic driver version 2.4.2
[drm] Initialized tdfx 1.0.0 20010216 on minor 0
atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
PPP BSD Compression module registered
PPP Deflate Compression module registered
NET: Registered protocol family 17
atkbd.c: Keyboard on isa0060/serio0 reports too many keys pressed.
local_bh_enable() was called in hard irq context. This is probably a bug
Call Trace:
[<c0127b96>] local_bh_enable+0x96/0xa0
[<e08fc4d8>] ppp_asynctty_receive+0x78/0xd0 [ppp_async]
[<c01cec6c>] flush_to_ldisc+0xdc/0x130
[<c01ecc17>] receive_chars+0x227/0x240
[<c01eccd5>] transmit_chars+0xa5/0xe0
[<c01ecf7c>] serial8250_interrupt+0x12c/0x130
[<c010c9f9>] handle_IRQ_event+0x49/0x80
[<c010cdc8>] do_IRQ+0xb8/0x180
[<c02ca760>] common_interrupt+0x18/0x20
[<c0116429>] delay_tsc+0x9/0x20
[<c01bb492>] __delay+0x12/0x20
[<c022408c>] atkbd_command+0x8c/0x1e0
[<c0224516>] atkbd_probe+0x36/0xe0
[<c02288c8>] serio_open+0x18/0x40
[<c0224bdc>] atkbd_connect+0x36c/0x400
[<c022825a>] serio_find_dev+0x6a/0x70
[<c0228356>] serio_handle_events+0xa6/0x100
[<c0228405>] serio_thread+0x55/0x150
[<c011ec70>] default_wake_function+0x0/0x20
[<c02283b0>] serio_thread+0x0/0x150
[<c0108f99>] kernel_thread_helper+0x5/0xc
local_bh_enable() was called in hard irq context. This is probably a bug
Call Trace:
[<c0127b96>] local_bh_enable+0x96/0xa0
[<e08f6f86>] ppp_input_error+0x116/0x150 [ppp_generic]
[<e08fcfd6>] ppp_async_input+0x156/0x5b0 [ppp_async]
[<c0134006>] queue_delayed_work+0x86/0xa0
[<e08fc4c1>] ppp_asynctty_receive+0x61/0xd0 [ppp_async]
[<c01cec6c>] flush_to_ldisc+0xdc/0x130
[<c01ecc17>] receive_chars+0x227/0x240
[<c01eccd5>] transmit_chars+0xa5/0xe0
[<c01ecf7c>] serial8250_interrupt+0x12c/0x130
[<c010c9f9>] handle_IRQ_event+0x49/0x80
[<c010cdc8>] do_IRQ+0xb8/0x180
[<c02ca760>] common_interrupt+0x18/0x20
[<c0116436>] delay_tsc+0x16/0x20
[<c01bb492>] __delay+0x12/0x20
[<c0223fbc>] atkbd_sendbyte+0x4c/0x90
[<c02241d6>] atkbd_command+0x1d6/0x1e0
[<c0224790>] atkbd_enable+0x50/0xb0
[<c0224c15>] atkbd_connect+0x3a5/0x400
[<c022825a>] serio_find_dev+0x6a/0x70
[<c0228356>] serio_handle_events+0xa6/0x100
[<c0228405>] serio_thread+0x55/0x150
[<c011ec70>] default_wake_function+0x0/0x20
[<c02283b0>] serio_thread+0x0/0x150
[<c0108f99>] kernel_thread_helper+0x5/0xc
local_bh_enable() was called in hard irq context. This is probably a bug
Call Trace:
[<c0127b96>] local_bh_enable+0x96/0xa0
[<e08fcfd6>] ppp_async_input+0x156/0x5b0 [ppp_async]
[<c0134006>] queue_delayed_work+0x86/0xa0
[<e08fc4c1>] ppp_asynctty_receive+0x61/0xd0 [ppp_async]
[<c01cec6c>] flush_to_ldisc+0xdc/0x130
[<c01ecc17>] receive_chars+0x227/0x240
[<c01eccd5>] transmit_chars+0xa5/0xe0
[<c01ecf7c>] serial8250_interrupt+0x12c/0x130
[<c010c9f9>] handle_IRQ_event+0x49/0x80
[<c010cdc8>] do_IRQ+0xb8/0x180
[<c02ca760>] common_interrupt+0x18/0x20
[<c0116436>] delay_tsc+0x16/0x20
[<c01bb492>] __delay+0x12/0x20
[<c0223fbc>] atkbd_sendbyte+0x4c/0x90
[<c02241d6>] atkbd_command+0x1d6/0x1e0
[<c0224790>] atkbd_enable+0x50/0xb0
[<c0224c15>] atkbd_connect+0x3a5/0x400
[<c022825a>] serio_find_dev+0x6a/0x70
[<c0228356>] serio_handle_events+0xa6/0x100
[<c0228405>] serio_thread+0x55/0x150
[<c011ec70>] default_wake_function+0x0/0x20
[<c02283b0>] serio_thread+0x0/0x150
[<c0108f99>] kernel_thread_helper+0x5/0xc
local_bh_enable() was called in hard irq context. This is probably a bug
Call Trace:
[<c0127b96>] local_bh_enable+0x96/0xa0
[<e08fc4d8>] ppp_asynctty_receive+0x78/0xd0 [ppp_async]
[<c01cec6c>] flush_to_ldisc+0xdc/0x130
[<c01ecc17>] receive_chars+0x227/0x240
[<c01eccd5>] transmit_chars+0xa5/0xe0
[<c01ecf7c>] serial8250_interrupt+0x12c/0x130
[<c010c9f9>] handle_IRQ_event+0x49/0x80
[<c010cdc8>] do_IRQ+0xb8/0x180
[<c02ca760>] common_interrupt+0x18/0x20
[<c0116436>] delay_tsc+0x16/0x20
[<c01bb492>] __delay+0x12/0x20
[<c0223fbc>] atkbd_sendbyte+0x4c/0x90
[<c02241d6>] atkbd_command+0x1d6/0x1e0
[<c0224790>] atkbd_enable+0x50/0xb0
[<c0224c15>] atkbd_connect+0x3a5/0x400
[<c022825a>] serio_find_dev+0x6a/0x70
[<c0228356>] serio_handle_events+0xa6/0x100
[<c0228405>] serio_thread+0x55/0x150
[<c011ec70>] default_wake_function+0x0/0x20
[<c02283b0>] serio_thread+0x0/0x150
[<c0108f99>] kernel_thread_helper+0x5/0xc
input: AT Translated Set 2 keyboard on isa0060/serio0
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: 2.6.0-test11-mm1
2003-12-17 18:22 ` 2.6.0-test11-mm1 Diego Calleja García
@ 2003-12-17 22:01 ` Andrew Morton
2003-12-17 23:59 ` 2.6.0-test11-mm1 Paul Mackerras
0 siblings, 1 reply; 20+ messages in thread
From: Andrew Morton @ 2003-12-17 22:01 UTC (permalink / raw)
To: Diego Calleja García; +Cc: linux-kernel, Paul Mackerras
Diego Calleja García <aradorlinux@yahoo.es> wrote:
>
> local_bh_enable() was called in hard irq context. This is probably a bug
> Call Trace:
> [<c0127b96>] local_bh_enable+0x96/0xa0
> [<e08fc4d8>] ppp_asynctty_receive+0x78/0xd0 [ppp_async]
> [<c01cec6c>] flush_to_ldisc+0xdc/0x130
> [<c01ecc17>] receive_chars+0x227/0x240
> [<c01eccd5>] transmit_chars+0xa5/0xe0
> [<c01ecf7c>] serial8250_interrupt+0x12c/0x130
> [<c010c9f9>] handle_IRQ_event+0x49/0x80
> [<c010cdc8>] do_IRQ+0xb8/0x180
> [<c02ca760>] common_interrupt+0x18/0x20
ppp_asynctty_receive() is called from hard IRQ context and hence may not use
spin_unlock_bh(). The patch converts ppp to use an IRQ-safe spinlock.
25-akpm/drivers/net/ppp_async.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff -puN drivers/net/ppp_async.c~ppp-locking-fix drivers/net/ppp_async.c
--- 25/drivers/net/ppp_async.c~ppp-locking-fix Wed Dec 17 13:57:33 2003
+++ 25-akpm/drivers/net/ppp_async.c Wed Dec 17 13:58:27 2003
@@ -321,12 +321,13 @@ ppp_asynctty_receive(struct tty_struct *
char *flags, int count)
{
struct asyncppp *ap = ap_get(tty);
+ unsigned long flags;
if (ap == 0)
return;
- spin_lock_bh(&ap->recv_lock);
+ spin_lock_irqsave(&ap->recv_lock, flags);
ppp_async_input(ap, buf, flags, count);
- spin_unlock_bh(&ap->recv_lock);
+ spin_unlock_irqrestore(&ap->recv_lock, flags);
ap_put(ap);
if (test_and_clear_bit(TTY_THROTTLED, &tty->flags)
&& tty->driver->unthrottle)
@@ -396,9 +397,9 @@ ppp_async_ioctl(struct ppp_channel *chan
if (get_user(val, (int *) arg))
break;
ap->flags = val & ~SC_RCV_BITS;
- spin_lock_bh(&ap->recv_lock);
+ spin_lock_irq(&ap->recv_lock);
ap->rbits = val & SC_RCV_BITS;
- spin_unlock_bh(&ap->recv_lock);
+ spin_unlock_irq(&ap->recv_lock);
err = 0;
break;
_
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: 2.6.0-test11-mm1
2003-12-17 22:01 ` 2.6.0-test11-mm1 Andrew Morton
@ 2003-12-17 23:59 ` Paul Mackerras
0 siblings, 0 replies; 20+ messages in thread
From: Paul Mackerras @ 2003-12-17 23:59 UTC (permalink / raw)
To: Andrew Morton; +Cc: Diego Calleja García, linux-kernel
Andrew Morton writes:
> Diego Calleja García <aradorlinux@yahoo.es> wrote:
>
> > local_bh_enable() was called in hard irq context. This is probably a bug
> > Call Trace:
> > [<c0127b96>] local_bh_enable+0x96/0xa0
> > [<e08fc4d8>] ppp_asynctty_receive+0x78/0xd0 [ppp_async]
> > [<c01cec6c>] flush_to_ldisc+0xdc/0x130
> > [<c01ecc17>] receive_chars+0x227/0x240
> > [<c01eccd5>] transmit_chars+0xa5/0xe0
> > [<c01ecf7c>] serial8250_interrupt+0x12c/0x130
> > [<c010c9f9>] handle_IRQ_event+0x49/0x80
> > [<c010cdc8>] do_IRQ+0xb8/0x180
> > [<c02ca760>] common_interrupt+0x18/0x20
>
>
> ppp_asynctty_receive() is called from hard IRQ context and hence may not use
> spin_unlock_bh(). The patch converts ppp to use an IRQ-safe spinlock.
... which only pushes the problem down one level, since
ppp_async_input eventually calls ppp_input with interrupts disabled,
which is not allowed. The reason that it isn't allowed is that it
would mean that the ppp_generic code would have to disable interrupts
in its critical sections, which would be very bad for interrupt
latency, particularly if you are using compression or encryption on
the link.
Given the number of serial drivers that want to call the line
discipline receive_chars routine with interrupts hard-disabled, I
would consider a patch to ppp_async.c to make it use a tasklet so that
it calls ppp_input from softirq level. But the currently proposed
patch is buggy.
Regards,
Paul.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [patch] 2.6.0-test11-mm1: isdn/eicon/eicon_mod.c doesn't compile
2003-12-17 9:43 2.6.0-test11-mm1 Andrew Morton
` (5 preceding siblings ...)
2003-12-17 18:22 ` 2.6.0-test11-mm1 Diego Calleja García
@ 2003-12-19 16:58 ` Adrian Bunk
2003-12-26 18:22 ` SUCCESS Re: 2.6.0-test11-mm1 Matthias Urlichs
7 siblings, 0 replies; 20+ messages in thread
From: Adrian Bunk @ 2003-12-19 16:58 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, mac, isdn4linux, kkeil, kai.germaschewski
Hi Andrew,
I got the following compile error in 2.6.0-test11-mm1:
<-- snip -->
...
CC [M] drivers/isdn/eicon/eicon_mod.o
drivers/isdn/eicon/eicon_mod.c: In function `eicon_exit':
drivers/isdn/eicon/eicon_mod.c:1362: warning: implicit declaration of
function `mca_mark_as_unused'
drivers/isdn/eicon/eicon_mod.c: In function `eicon_mca_find_card':
drivers/isdn/eicon/eicon_mod.c:1500: warning: implicit declaration of
function `mca_find_unused_adapter'
drivers/isdn/eicon/eicon_mod.c:1502: `MCA_NOTFOUND' undeclared (first
use in this function)
drivers/isdn/eicon/eicon_mod.c:1502: (Each undeclared identifier is
reported only once
drivers/isdn/eicon/eicon_mod.c:1502: for each function it appears in.)
drivers/isdn/eicon/eicon_mod.c: In function `eicon_mca_probe':
drivers/isdn/eicon/eicon_mod.c:1558: warning: implicit declaration of
function `mca_read_stored_pos'
drivers/isdn/eicon/eicon_mod.c:1619: warning: implicit declaration of
function `mca_set_adapter_name'
drivers/isdn/eicon/eicon_mod.c:1622: warning: implicit declaration of
function `mca_mark_as_used'
make[3]: *** [drivers/isdn/eicon/eicon_mod.o] Error 1
<-- snip -->
The fix is simple:
--- linux-2.6.0-test11-mm1-modular-no-smp/drivers/isdn/eicon/eicon_mod.c.old 2003-12-19 17:26:56.000000000 +0100
+++ linux-2.6.0-test11-mm1-modular-no-smp/drivers/isdn/eicon/eicon_mod.c 2003-12-19 17:28:29.000000000 +0100
@@ -29,6 +29,7 @@
#include <linux/init.h>
#ifdef CONFIG_MCA
#include <linux/mca.h>
+#include <linux/mca-legacy.h>
#endif /* CONFIG_MCA */
#include "eicon.h"
Please apply
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 20+ messages in thread* SUCCESS Re: 2.6.0-test11-mm1
2003-12-17 9:43 2.6.0-test11-mm1 Andrew Morton
` (6 preceding siblings ...)
2003-12-19 16:58 ` [patch] 2.6.0-test11-mm1: isdn/eicon/eicon_mod.c doesn't compile Adrian Bunk
@ 2003-12-26 18:22 ` Matthias Urlichs
2003-12-26 19:15 ` Linus Torvalds
7 siblings, 1 reply; 20+ messages in thread
From: Matthias Urlichs @ 2003-12-26 18:22 UTC (permalink / raw)
To: linux-kernel
Hi, Andrew Morton wrote:
> [ 2.6.0-mm1 ]
"User" report: I've had lost of stability problems with 2.6-test*,
including 2.6.0-no_test, on my laptop. Stuff like misplaced characters
in Galeon, crashing Konsole, inexplicable delays in pan, et al., which
never happened with 2.4.
For what it's worth, these seem to be gone for good since I rebooted into
-mm1 this morning. So, thanks to whoever's responsible for the patch that
actually fixed the problem.
If somebody _really_ needs to know, I can try to binary-search for the
patch that's responsible, but it'd take a month to find out anything
conclusive -- ten reboots, two days of stress testing each in order to
eliminate false positives, and a few days of no-computer-please,
I-need-a-holiday time. Thus, I'd rather not.
I've stored a Bitkeeper archive of the -mm1 patches (one changeset per
patch) to bk://smurf.bkbits.net/linux-2.6-mm, for those (like me ;-)
who don't like to work with patches. I'll keep that up-to-date so that
there's a clean upgrade path.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Murray's Rule:
Any country with "democratic" in the title isn't.
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: SUCCESS Re: 2.6.0-test11-mm1
2003-12-26 18:22 ` SUCCESS Re: 2.6.0-test11-mm1 Matthias Urlichs
@ 2003-12-26 19:15 ` Linus Torvalds
2003-12-28 21:59 ` Matthias Urlichs
0 siblings, 1 reply; 20+ messages in thread
From: Linus Torvalds @ 2003-12-26 19:15 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: linux-kernel
On Fri, 26 Dec 2003, Matthias Urlichs wrote:
>
> If somebody _really_ needs to know, I can try to binary-search for the
> patch that's responsible, but it'd take a month to find out anything
> conclusive -- ten reboots, two days of stress testing each in order to
> eliminate false positives, and a few days of no-computer-please,
> I-need-a-holiday time. Thus, I'd rather not.
It would be good to even get a "good hint", even if it won't be
conclusive. Even if it starts out as just a list of "this patch can't
matter, because it's not active in my configuration", and perhaps then
specified a bit better afterwards..
Linus
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: SUCCESS Re: 2.6.0-test11-mm1
2003-12-26 19:15 ` Linus Torvalds
@ 2003-12-28 21:59 ` Matthias Urlichs
0 siblings, 0 replies; 20+ messages in thread
From: Matthias Urlichs @ 2003-12-28 21:59 UTC (permalink / raw)
To: linux-kernel
Hi, Linus Torvalds wrote:
> Matthias Urlichs:
>> [ -mm1 success story ]
>> If somebody _really_ needs to know, I can try to binary-search for the
>> patch that's responsible, but it'd take a month to find out anything
>> conclusive
>
> It would be good to even get a "good hint", even if it won't be
> conclusive.
I'll try to narrow it down somewhat. Unfortunately, the nature of binary
search is so that even if I manage to declare half of the patches as
irrelevant, that doesn't help much.
[ time passes while I forgot to send this message ]
Oh happiness. :-/ At least part of the bug (galeon misplaces text) still
exists, as it turns out, though it's a lot harder to trigger with
2.6.0-mm1. Since the galeon thing was usually the first Special Effect to
show up, this may well be two different bugs -- and I'm not ruling out an
application problem.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
It isn't easy being a Friday kind of person in a Monday kind of world.
^ permalink raw reply [flat|nested] 20+ messages in thread