* Re: 2.5.74-mm3
2003-07-09 5:35 2.5.74-mm3 Andrew Morton
@ 2003-07-09 9:05 ` Thomas Schlichter
2003-07-09 9:18 ` 2.5.74-mm3 Andrew Morton
2003-07-09 9:24 ` 2.5.74-mm3 Matt Mackall
2003-07-10 18:21 ` 2.5.74-mm3 Valdis.Kletnieks
2 siblings, 1 reply; 30+ messages in thread
From: Thomas Schlichter @ 2003-07-09 9:05 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
[-- Attachment #1: Type: text/plain, Size: 576 bytes --]
> -cpumask_t-1.patch
> -gcc-bug-workaround.patch
> -sparse-apic-fix.patch
> -nuke-cpumask_arith.patch
> -p4-clockmod-cpumask-fix.patch
>
> Folded into cpumask_t-1.patch
This gives following compile error when compiling the kernel with APM support
for UP:
arch/i386/kernel/apm.c: In function `apm_bios_call':
arch/i386/kernel/apm.c:600: error: incompatible types in assignment
arch/i386/kernel/apm.c: In function `apm_bios_call_simple':
arch/i386/kernel/apm.c:643: error: incompatible types in assignment
The attached patch fixes this...
Best regards
Thomas Schlichter
[-- Attachment #2: fix_up_apm.diff --]
[-- Type: text/x-diff, Size: 1328 bytes --]
--- linux-2.5.74-mm3/arch/i386/kernel/apm.c.orig Wed Jul 9 10:25:46 2003
+++ linux-2.5.74-mm3/arch/i386/kernel/apm.c Wed Jul 9 10:40:42 2003
@@ -508,13 +508,12 @@
#ifdef CONFIG_SMP
-static cpumask_t apm_save_cpus(void)
+static inline void apm_save_cpus(cpumask_t *mask)
{
- cpumask_t x = current->cpus_allowed;
+ *mask = current->cpus_allowed;
/* Some bioses don't like being called from CPU != 0 */
set_cpus_allowed(current, cpumask_of_cpu(0));
BUG_ON(smp_processor_id() != 0);
- return x;
}
static inline void apm_restore_cpus(cpumask_t mask)
@@ -528,7 +527,7 @@
* No CPU lockdown needed on a uniprocessor
*/
-#define apm_save_cpus() 0
+#define apm_save_cpus(x) (void)(x)
#define apm_restore_cpus(x) (void)(x)
#endif
@@ -597,7 +596,7 @@
int cpu;
struct desc_struct save_desc_40;
- cpus = apm_save_cpus();
+ apm_save_cpus(&cpus);
cpu = get_cpu();
save_desc_40 = cpu_gdt_table[cpu][0x40 / 8];
@@ -640,7 +639,7 @@
struct desc_struct save_desc_40;
- cpus = apm_save_cpus();
+ apm_save_cpus(&cpus);
cpu = get_cpu();
save_desc_40 = cpu_gdt_table[cpu][0x40 / 8];
@@ -918,7 +917,8 @@
#endif
if (apm_info.realmode_power_off)
{
- (void)apm_save_cpus();
+ cpumask_t dummy;
+ apm_save_cpus(&dummy);
machine_real_restart(po_bios_call, sizeof(po_bios_call));
}
else
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: 2.5.74-mm3
2003-07-09 9:05 ` 2.5.74-mm3 Thomas Schlichter
@ 2003-07-09 9:18 ` Andrew Morton
2003-07-09 9:25 ` 2.5.74-mm3 Thomas Schlichter
` (2 more replies)
0 siblings, 3 replies; 30+ messages in thread
From: Andrew Morton @ 2003-07-09 9:18 UTC (permalink / raw)
To: Thomas Schlichter; +Cc: linux-kernel, linux-mm
Thomas Schlichter <schlicht@uni-mannheim.de> wrote:
>
> This gives following compile error when compiling the kernel with APM support
> for UP:
>
> arch/i386/kernel/apm.c: In function `apm_bios_call':
> arch/i386/kernel/apm.c:600: error: incompatible types in assignment
> arch/i386/kernel/apm.c: In function `apm_bios_call_simple':
> arch/i386/kernel/apm.c:643: error: incompatible types in assignment
>
> The attached patch fixes this...
Seems complex. I just have this:
diff -puN arch/i386/kernel/apm.c~cpumask-apm-fix-2 arch/i386/kernel/apm.c
--- 25/arch/i386/kernel/apm.c~cpumask-apm-fix-2 2003-07-08 23:09:23.000000000 -0700
+++ 25-akpm/arch/i386/kernel/apm.c 2003-07-08 23:28:50.000000000 -0700
@@ -528,7 +528,7 @@ static inline void apm_restore_cpus(cpum
* No CPU lockdown needed on a uniprocessor
*/
-#define apm_save_cpus() 0
+#define apm_save_cpus() CPU_MASK_NONE
#define apm_restore_cpus(x) (void)(x)
#endif
_
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: 2.5.74-mm3
2003-07-09 9:18 ` 2.5.74-mm3 Andrew Morton
@ 2003-07-09 9:25 ` Thomas Schlichter
2003-07-09 9:38 ` 2.5.74-mm3 Marc-Christian Petersen
2003-07-10 5:44 ` 2.5.74-mm3 - apm_save_cpus() Macro still bombs out Piet Delaney
2 siblings, 0 replies; 30+ messages in thread
From: Thomas Schlichter @ 2003-07-09 9:25 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
On Wednesday 09 July 2003 11:18, Andrew Morton wrote:
> Thomas Schlichter <schlicht@uni-mannheim.de> wrote:
> > This gives following compile error when compiling the kernel with APM
> > support for UP:
> >
> > arch/i386/kernel/apm.c: In function `apm_bios_call':
> > arch/i386/kernel/apm.c:600: error: incompatible types in assignment
> > arch/i386/kernel/apm.c: In function `apm_bios_call_simple':
> > arch/i386/kernel/apm.c:643: error: incompatible types in assignment
> >
> > The attached patch fixes this...
>
> Seems complex. I just have this:
>
>
> diff -puN arch/i386/kernel/apm.c~cpumask-apm-fix-2 arch/i386/kernel/apm.c
> --- 25/arch/i386/kernel/apm.c~cpumask-apm-fix-2 2003-07-08
> 23:09:23.000000000 -0700 +++ 25-akpm/arch/i386/kernel/apm.c 2003-07-08
> 23:28:50.000000000 -0700 @@ -528,7 +528,7 @@ static inline void
> apm_restore_cpus(cpum
> * No CPU lockdown needed on a uniprocessor
> */
>
> -#define apm_save_cpus() 0
> +#define apm_save_cpus() CPU_MASK_NONE
> #define apm_restore_cpus(x) (void)(x)
>
> #endif
I thought about this one, too, but I wasn't sure if gcc is able to optimize
away the assignment and the local cpumask_t variable with this oneliner...
But for me it is OK, too...
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 2.5.74-mm3
2003-07-09 9:18 ` 2.5.74-mm3 Andrew Morton
2003-07-09 9:25 ` 2.5.74-mm3 Thomas Schlichter
@ 2003-07-09 9:38 ` Marc-Christian Petersen
2003-07-09 11:23 ` 2.5.74-mm3 Jan De Luyck
2003-07-09 13:23 ` 2.5.74-mm3 Ramón Rey Vicente
2003-07-10 5:44 ` 2.5.74-mm3 - apm_save_cpus() Macro still bombs out Piet Delaney
2 siblings, 2 replies; 30+ messages in thread
From: Marc-Christian Petersen @ 2003-07-09 9:38 UTC (permalink / raw)
To: Andrew Morton, Thomas Schlichter; +Cc: linux-kernel, linux-mm
[-- Attachment #1: Type: text/plain, Size: 939 bytes --]
On Wednesday 09 July 2003 11:18, Andrew Morton wrote:
Hi Andrew,
> > arch/i386/kernel/apm.c: In function `apm_bios_call':
> > arch/i386/kernel/apm.c:600: error: incompatible types in assignment
> > arch/i386/kernel/apm.c: In function `apm_bios_call_simple':
> > arch/i386/kernel/apm.c:643: error: incompatible types in assignment
> > The attached patch fixes this...
> Seems complex. I just have this:
>
>
> diff -puN arch/i386/kernel/apm.c~cpumask-apm-fix-2 arch/i386/kernel/apm.c
> --- 25/arch/i386/kernel/apm.c~cpumask-apm-fix-2 2003-07-08
> 23:09:23.000000000 -0700 +++ 25-akpm/arch/i386/kernel/apm.c 2003-07-08
> 23:28:50.000000000 -0700 @@ -528,7 +528,7 @@ static inline void
> apm_restore_cpus(cpum
> * No CPU lockdown needed on a uniprocessor
> */
>
> -#define apm_save_cpus() 0
> +#define apm_save_cpus() CPU_MASK_NONE
> #define apm_restore_cpus(x) (void)(x)
>
> #endif
>
better use the attached one ;)
ciao, Marc
[-- Attachment #2: 15_fixup-apm-small.patch --]
[-- Type: text/x-diff, Size: 640 bytes --]
diff -puN arch/i386/kernel/apm.c~cpumask-apm-fix-2 arch/i386/kernel/apm.c
--- 25/arch/i386/kernel/apm.c~cpumask-apm-fix-2 2003-07-08 23:09:23.000000000 -0700
+++ 25-akpm/arch/i386/kernel/apm.c 2003-07-08 23:28:50.000000000 -0700
@@ -222,6 +222,7 @@
#include <linux/kernel.h>
#include <linux/smp.h>
#include <linux/smp_lock.h>
+#include <linux/cpumask.h>
#include <asm/system.h>
#include <asm/uaccess.h>
@@ -528,7 +529,7 @@ static inline void apm_restore_cpus(cpum
* No CPU lockdown needed on a uniprocessor
*/
-#define apm_save_cpus() 0
+#define apm_save_cpus() CPU_MASK_NONE
#define apm_restore_cpus(x) (void)(x)
#endif
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 2.5.74-mm3
2003-07-09 9:38 ` 2.5.74-mm3 Marc-Christian Petersen
@ 2003-07-09 11:23 ` Jan De Luyck
2003-07-09 13:23 ` 2.5.74-mm3 Ramón Rey Vicente
1 sibling, 0 replies; 30+ messages in thread
From: Jan De Luyck @ 2003-07-09 11:23 UTC (permalink / raw)
To: Marc-Christian Petersen, Andrew Morton, Thomas Schlichter
Cc: linux-kernel, linux-mm
On Wednesday 09 July 2003 11:38, Marc-Christian Petersen wrote:
>
> better use the attached one ;)
>
> ciao, Marc
Still bombs out:
CC [M] arch/i386/kernel/apm.o
arch/i386/kernel/apm.c: In function `apm_bios_call':
arch/i386/kernel/apm.c:601: error: syntax error before '{' token
arch/i386/kernel/apm.c:595: warning: unused variable `saved_fs'
arch/i386/kernel/apm.c:595: warning: unused variable `saved_gs'
arch/i386/kernel/apm.c:596: warning: unused variable `flags'
arch/i386/kernel/apm.c:598: warning: unused variable `cpu'
arch/i386/kernel/apm.c:599: warning: unused variable `save_desc_40'
arch/i386/kernel/apm.c: At top level:
arch/i386/kernel/apm.c:603: warning: type defaults to `int' in declaration of
`cpu'
arch/i386/kernel/apm.c:603: error: braced-group within expression allowed only
inside a function
arch/i386/kernel/apm.c:603: error: syntax error before ')' token
arch/i386/kernel/apm.c:604: warning: type defaults to `int' in declaration of
`save_desc_40'
arch/i386/kernel/apm.c:604: error: incompatible types in initialization
arch/i386/kernel/apm.c:604: error: initializer element is not constant
arch/i386/kernel/apm.c:604: warning: data definition has no type or storage
class
arch/i386/kernel/apm.c:605: warning: type defaults to `int' in declaration of
`cpu_gdt_table'
arch/i386/kernel/apm.c:605: error: variable-size type declared outside of any
function
arch/i386/kernel/apm.c:605: error: variable-sized object may not be
initialized
arch/i386/kernel/apm.c:605: error: conflicting types for `cpu_gdt_table'
include/asm/desc.h:14: error: previous declaration of `cpu_gdt_table'
arch/i386/kernel/apm.c:605: warning: data definition has no type or storage
class
arch/i386/kernel/apm.c:607: error: syntax error before "do"
arch/i386/kernel/apm.c:607: error: `flags' undeclared here (not in a function)
arch/i386/kernel/apm.c:607: warning: type defaults to `int' in declaration of
`__dummy2'
arch/i386/kernel/apm.c:607: error: syntax error before "void"
arch/i386/kernel/apm.c:609: error: syntax error before "volatile"
arch/i386/kernel/apm.c:610: warning: type defaults to `int' in declaration of
`apm_bios_call_asm'
arch/i386/kernel/apm.c:610: warning: parameter names (without types) in
function declaration
arch/i386/kernel/apm.c:610: error: conflicting types for `apm_bios_call_asm'
include/asm-i386/mach-default/apm.h:31: error: previous declaration of
`apm_bios_call_asm'
arch/i386/kernel/apm.c:610: warning: data definition has no type or storage
class
arch/i386/kernel/apm.c:611: error: syntax error before "volatile"
arch/i386/kernel/apm.c:612: error: `flags' undeclared here (not in a function)
arch/i386/kernel/apm.c:612: warning: type defaults to `int' in declaration of
`__dummy2'
arch/i386/kernel/apm.c:612: error: syntax error before "void"
arch/i386/kernel/apm.c:613: warning: type defaults to `int' in declaration of
`cpu_gdt_table'
arch/i386/kernel/apm.c:613: error: variable-size type declared outside of any
function
arch/i386/kernel/apm.c:613: error: variable-sized object may not be
initialized
arch/i386/kernel/apm.c:613: warning: data definition has no type or storage
class
arch/i386/kernel/apm.c:614: error: syntax error before "do"
arch/i386/kernel/apm.c: In function `apm_bios_call_simple':
arch/i386/kernel/apm.c:644: error: syntax error before '{' token
arch/i386/kernel/apm.c:636: warning: unused variable `error'
arch/i386/kernel/apm.c:637: warning: unused variable `saved_fs'
arch/i386/kernel/apm.c:637: warning: unused variable `saved_gs'
arch/i386/kernel/apm.c:638: warning: unused variable `flags'
arch/i386/kernel/apm.c:640: warning: unused variable `cpu'
arch/i386/kernel/apm.c:641: warning: unused variable `save_desc_40'
arch/i386/kernel/apm.c: At top level:
arch/i386/kernel/apm.c:646: warning: type defaults to `int' in declaration of
`cpu'
arch/i386/kernel/apm.c:646: error: redefinition of `cpu'
arch/i386/kernel/apm.c:603: error: `cpu' previously defined here
arch/i386/kernel/apm.c:646: error: braced-group within expression allowed only
inside a function
arch/i386/kernel/apm.c:646: error: syntax error before ')' token
arch/i386/kernel/apm.c:647: warning: type defaults to `int' in declaration of
`save_desc_40'
arch/i386/kernel/apm.c:647: error: redefinition of `save_desc_40'
arch/i386/kernel/apm.c:604: error: `save_desc_40' previously defined here
arch/i386/kernel/apm.c:647: error: initializer element is not constant
arch/i386/kernel/apm.c:647: warning: data definition has no type or storage
class
arch/i386/kernel/apm.c:648: warning: type defaults to `int' in declaration of
`cpu_gdt_table'
arch/i386/kernel/apm.c:648: error: variable-size type declared outside of any
function
arch/i386/kernel/apm.c:648: error: variable-sized object may not be
initialized
arch/i386/kernel/apm.c:648: warning: data definition has no type or storage
class
arch/i386/kernel/apm.c:650: error: syntax error before "do"
arch/i386/kernel/apm.c:650: error: `flags' undeclared here (not in a function)
arch/i386/kernel/apm.c:650: warning: type defaults to `int' in declaration of
`__dummy2'
arch/i386/kernel/apm.c:650: error: syntax error before "void"
arch/i386/kernel/apm.c:652: error: syntax error before "volatile"
arch/i386/kernel/apm.c:653: warning: type defaults to `int' in declaration of
`error'
arch/i386/kernel/apm.c:653: error: `func' undeclared here (not in a function)
arch/i386/kernel/apm.c:653: error: `ebx_in' undeclared here (not in a
function)
arch/i386/kernel/apm.c:653: error: `ecx_in' undeclared here (not in a
function)
arch/i386/kernel/apm.c:653: error: `eax' undeclared here (not in a function)
arch/i386/kernel/apm.c:653: error: initializer element is not constant
arch/i386/kernel/apm.c:653: warning: data definition has no type or storage
class
arch/i386/kernel/apm.c:654: error: syntax error before "volatile"
arch/i386/kernel/apm.c:655: error: `flags' undeclared here (not in a function)
arch/i386/kernel/apm.c:655: warning: type defaults to `int' in declaration of
`__dummy2'
arch/i386/kernel/apm.c:655: error: syntax error before "void"
arch/i386/kernel/apm.c:656: warning: type defaults to `int' in declaration of
`cpu_gdt_table'
arch/i386/kernel/apm.c:656: error: conflicting types for `cpu_gdt_table'
arch/i386/kernel/apm.c:648: error: previous declaration of `cpu_gdt_table'
arch/i386/kernel/apm.c:656: warning: data definition has no type or storage
class
arch/i386/kernel/apm.c:657: error: syntax error before "do"
arch/i386/kernel/apm.c: In function `apm_power_off':
arch/i386/kernel/apm.c:922: warning: braces around scalar initializer
arch/i386/kernel/apm.c:922: warning: (near initialization for `(anonymous)')
arch/i386/kernel/apm.c:922: error: array index in non-array initializer
arch/i386/kernel/apm.c:922: error: (near initialization for `(anonymous)')
arch/i386/kernel/apm.c:922: error: invalid initializer
arch/i386/kernel/apm.c:922: error: (near initialization for `(anonymous)')
{standard input}: Assembler messages:
{standard input}:502: Error: symbol `cpu' is already defined
{standard input}:508: Error: symbol `save_desc_40' is already defined
make[2]: *** [arch/i386/kernel/apm.o] Error 1
make[1]: *** [arch/i386/kernel] Error 2
make[1]: Leaving directory `/usr/src/linux'
make: *** [stamp-build] Error 2
laptop:/usr/src/linux# '
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: 2.5.74-mm3
2003-07-09 9:38 ` 2.5.74-mm3 Marc-Christian Petersen
2003-07-09 11:23 ` 2.5.74-mm3 Jan De Luyck
@ 2003-07-09 13:23 ` Ramón Rey Vicente
1 sibling, 0 replies; 30+ messages in thread
From: Ramón Rey Vicente @ 2003-07-09 13:23 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 581 bytes --]
El mi? 09-07-2003 a las 11:38, Marc-Christian Petersen escribió:
> better use the attached one ;)
Still not build
--
/================================================\
| Ramón Rey Vicente <ramon.rey at hispalinux.es> |
| |
| Jabber ID <rreylinux at jabber.org> |
| |
| Public GPG Key http://pgp.escomposlinux.org |
| |
| GLiSa http://glisa.hispalinux.es |
\================================================/
[-- Attachment #2: LOG --]
[-- Type: text/plain, Size: 7099 bytes --]
arch/i386/kernel/apm.c: En la función `apm_bios_call':
arch/i386/kernel/apm.c:601: error: error sintáctico before '{' token
arch/i386/kernel/apm.c:595: aviso: unused variable `saved_fs'
arch/i386/kernel/apm.c:595: aviso: unused variable `saved_gs'
arch/i386/kernel/apm.c:596: aviso: unused variable `flags'
arch/i386/kernel/apm.c:598: aviso: unused variable `cpu'
arch/i386/kernel/apm.c:599: aviso: unused variable `save_desc_40'
arch/i386/kernel/apm.c: En el nivel principal:
arch/i386/kernel/apm.c:603: aviso: type defaults to `int' in declaration of `cpu'
arch/i386/kernel/apm.c:603: error: braced-group within expression allowed only inside a function
arch/i386/kernel/apm.c:603: error: error sintáctico before ')' token
arch/i386/kernel/apm.c:604: aviso: type defaults to `int' in declaration of `save_desc_40'
arch/i386/kernel/apm.c:604: error: incompatible types in inicialización
arch/i386/kernel/apm.c:604: error: el elemento inicializador no es constante
arch/i386/kernel/apm.c:604: aviso: data definition has no type or storage class
arch/i386/kernel/apm.c:605: aviso: type defaults to `int' in declaration of `cpu_gdt_table'
arch/i386/kernel/apm.c:605: error: variable-size type declared outside of any function
arch/i386/kernel/apm.c:605: error: variable-sized object may not be initialized
arch/i386/kernel/apm.c:605: error: conflicting types for `cpu_gdt_table'
include/asm/desc.h:14: error: previous declaration of `cpu_gdt_table'
arch/i386/kernel/apm.c:605: aviso: data definition has no type or storage class
arch/i386/kernel/apm.c:607: error: error sintáctico before "do"
arch/i386/kernel/apm.c:607: error: `flags' undeclared here (not in a function)
arch/i386/kernel/apm.c:607: aviso: type defaults to `int' in declaration of `__dummy2'
arch/i386/kernel/apm.c:607: error: error sintáctico before "void"
arch/i386/kernel/apm.c:609: error: error sintáctico before "volatile"
arch/i386/kernel/apm.c:610: aviso: type defaults to `int' in declaration of `apm_bios_call_asm'
arch/i386/kernel/apm.c:610: aviso: nombres de parámetros (sin tipos) en la declaración de la función
arch/i386/kernel/apm.c:610: error: conflicting types for `apm_bios_call_asm'
include/asm-i386/mach-default/apm.h:31: error: previous declaration of `apm_bios_call_asm'
arch/i386/kernel/apm.c:610: aviso: data definition has no type or storage class
arch/i386/kernel/apm.c:611: error: error sintáctico before "volatile"
arch/i386/kernel/apm.c:612: error: `flags' undeclared here (not in a function)
arch/i386/kernel/apm.c:612: aviso: type defaults to `int' in declaration of `__dummy2'
arch/i386/kernel/apm.c:612: error: error sintáctico before "void"
arch/i386/kernel/apm.c:613: aviso: type defaults to `int' in declaration of `cpu_gdt_table'
arch/i386/kernel/apm.c:613: error: variable-size type declared outside of any function
arch/i386/kernel/apm.c:613: error: variable-sized object may not be initialized
arch/i386/kernel/apm.c:613: aviso: data definition has no type or storage class
arch/i386/kernel/apm.c:614: error: error sintáctico before "do"
arch/i386/kernel/apm.c: En la función `apm_bios_call_simple':
arch/i386/kernel/apm.c:644: error: error sintáctico before '{' token
arch/i386/kernel/apm.c:636: aviso: unused variable `error'
arch/i386/kernel/apm.c:637: aviso: unused variable `saved_fs'
arch/i386/kernel/apm.c:637: aviso: unused variable `saved_gs'
arch/i386/kernel/apm.c:638: aviso: unused variable `flags'
arch/i386/kernel/apm.c:640: aviso: unused variable `cpu'
arch/i386/kernel/apm.c:641: aviso: unused variable `save_desc_40'
arch/i386/kernel/apm.c: En el nivel principal:
arch/i386/kernel/apm.c:646: aviso: type defaults to `int' in declaration of `cpu'
arch/i386/kernel/apm.c:646: error: redefinition of `cpu'
arch/i386/kernel/apm.c:603: error: `cpu' previously defined here
arch/i386/kernel/apm.c:646: error: braced-group within expression allowed only inside a function
arch/i386/kernel/apm.c:646: error: error sintáctico before ')' token
arch/i386/kernel/apm.c:647: aviso: type defaults to `int' in declaration of `save_desc_40'
arch/i386/kernel/apm.c:647: error: redefinition of `save_desc_40'
arch/i386/kernel/apm.c:604: error: `save_desc_40' previously defined here
arch/i386/kernel/apm.c:647: error: el elemento inicializador no es constante
arch/i386/kernel/apm.c:647: aviso: data definition has no type or storage class
arch/i386/kernel/apm.c:648: aviso: type defaults to `int' in declaration of `cpu_gdt_table'
arch/i386/kernel/apm.c:648: error: variable-size type declared outside of any function
arch/i386/kernel/apm.c:648: error: variable-sized object may not be initialized
arch/i386/kernel/apm.c:648: aviso: data definition has no type or storage class
arch/i386/kernel/apm.c:650: error: error sintáctico before "do"
arch/i386/kernel/apm.c:650: error: `flags' undeclared here (not in a function)
arch/i386/kernel/apm.c:650: aviso: type defaults to `int' in declaration of `__dummy2'
arch/i386/kernel/apm.c:650: error: error sintáctico before "void"
arch/i386/kernel/apm.c:652: error: error sintáctico before "volatile"
arch/i386/kernel/apm.c:653: aviso: type defaults to `int' in declaration of `error'
arch/i386/kernel/apm.c:653: error: `func' undeclared here (not in a function)
arch/i386/kernel/apm.c:653: error: `ebx_in' undeclared here (not in a function)
arch/i386/kernel/apm.c:653: error: `ecx_in' undeclared here (not in a function)
arch/i386/kernel/apm.c:653: error: `eax' undeclared here (not in a function)
arch/i386/kernel/apm.c:653: error: el elemento inicializador no es constante
arch/i386/kernel/apm.c:653: aviso: data definition has no type or storage class
arch/i386/kernel/apm.c:654: error: error sintáctico before "volatile"
arch/i386/kernel/apm.c:655: error: `flags' undeclared here (not in a function)
arch/i386/kernel/apm.c:655: aviso: type defaults to `int' in declaration of `__dummy2'
arch/i386/kernel/apm.c:655: error: error sintáctico before "void"
arch/i386/kernel/apm.c:656: aviso: type defaults to `int' in declaration of `cpu_gdt_table'
arch/i386/kernel/apm.c:656: error: conflicting types for `cpu_gdt_table'
arch/i386/kernel/apm.c:648: error: previous declaration of `cpu_gdt_table'
arch/i386/kernel/apm.c:656: aviso: data definition has no type or storage class
arch/i386/kernel/apm.c:657: error: error sintáctico before "do"
arch/i386/kernel/apm.c: En la función `apm_power_off':
arch/i386/kernel/apm.c:922: aviso: llaves alrededor del inicializador escalar
arch/i386/kernel/apm.c:922: aviso: (near initialization for `(anonymous)')
arch/i386/kernel/apm.c:922: error: índice de matriz en el inicializador que no es matriz
arch/i386/kernel/apm.c:922: error: (near initialization for `(anonymous)')
arch/i386/kernel/apm.c:922: error: inicializador inválido
arch/i386/kernel/apm.c:922: error: (near initialization for `(anonymous)')
{entrada estándar}: Mensajes del ensamblador:
{entrada estándar}:371: Error: el símbolo `cpu' ya está definido
{entrada estándar}:377: Error: el símbolo `save_desc_40' ya está definido
make[2]: *** [arch/i386/kernel/apm.o] Error 1
make[1]: *** [arch/i386/kernel] Error 2
make: *** [stamp-build] Error 2
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 2.5.74-mm3 - apm_save_cpus() Macro still bombs out
2003-07-09 9:18 ` 2.5.74-mm3 Andrew Morton
2003-07-09 9:25 ` 2.5.74-mm3 Thomas Schlichter
2003-07-09 9:38 ` 2.5.74-mm3 Marc-Christian Petersen
@ 2003-07-10 5:44 ` Piet Delaney
2003-07-10 6:08 ` William Lee Irwin III
2003-07-10 9:22 ` 2.5.74-mm3 - apm_save_cpus() Macro still bombs out Thomas Schlichter
2 siblings, 2 replies; 30+ messages in thread
From: Piet Delaney @ 2003-07-10 5:44 UTC (permalink / raw)
To: Andrew Morton; +Cc: Thomas Schlichter, linux-kernel, linux-mm
On Wed, 2003-07-09 at 02:18, Andrew Morton wrote:
> Thomas Schlichter <schlicht@uni-mannheim.de> wrote:
.
.
.
> Seems complex. I just have this:
>
>
> diff -puN arch/i386/kernel/apm.c~cpumask-apm-fix-2 arch/i386/kernel/apm.c
> --- 25/arch/i386/kernel/apm.c~cpumask-apm-fix-2 2003-07-08 23:09:23.000000000 -0700
> +++ 25-akpm/arch/i386/kernel/apm.c 2003-07-08 23:28:50.000000000 -0700
> @@ -528,7 +528,7 @@ static inline void apm_restore_cpus(cpum
> * No CPU lockdown needed on a uniprocessor
> */
>
> -#define apm_save_cpus() 0
> +#define apm_save_cpus() CPU_MASK_NONE
> #define apm_restore_cpus(x) (void)(x)
I tried this and got a parse error. So I assumed perhaps I
needed to upgrade to the latest C compiler to be able
to handle the assignment of a inline static initializer:
#define CPU_MASK_NONE { {[0 ... CPU_ARRAY_SIZE-1] = 0UL} }
I was disappointed that using gcc 3.3 didn't fix the problem:
----------------------------------------------------------------------
CC arch/i386/kernel/apm.o
arch/i386/kernel/apm.c: In function `apm_bios_call':
arch/i386/kernel/apm.c:599: error: parse error before '{' token
arch/i386/kernel/apm.c: In function `apm_bios_call_simple':
arch/i386/kernel/apm.c:642: error: parse error before '{' token
arch/i386/kernel/apm.c: In function `apm_power_off':
arch/i386/kernel/apm.c:920: warning: braces around scalar initializer
arch/i386/kernel/apm.c:920: warning: (near initialization for
`(anonymous)')
arch/i386/kernel/apm.c:920: error: array index in non-array initializer
arch/i386/kernel/apm.c:920: error: (near initialization for
`(anonymous)')
arch/i386/kernel/apm.c:920: error: invalid initializer
arch/i386/kernel/apm.c:920: error: (near initialization for
`(anonymous)')
------------------------------------------------------------------------------
I'll settle for Matt Mackall <mpm@selenic.com> fix for now:
+#define apm_save_cpus() (current->cpus_allowed)
I wonder why other, like Thomas Schlichter <schlicht@uni-mannheim.de>,
had no problem with the CPU_MASK_NONE fix.
I tried adding the #include <linux/cpumask.h> that Marc-Christian
Petersen <m.c.p@wolk-project.de> sugested but it didn't help. Looks
like Jan De Luyck <lkml@kcore.org> had a similar result.
-piet
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
--
piet@www.piet.net
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: 2.5.74-mm3 - apm_save_cpus() Macro still bombs out
2003-07-10 5:44 ` 2.5.74-mm3 - apm_save_cpus() Macro still bombs out Piet Delaney
@ 2003-07-10 6:08 ` William Lee Irwin III
2003-07-10 7:10 ` William Lee Irwin III
2003-07-10 9:22 ` 2.5.74-mm3 - apm_save_cpus() Macro still bombs out Thomas Schlichter
1 sibling, 1 reply; 30+ messages in thread
From: William Lee Irwin III @ 2003-07-10 6:08 UTC (permalink / raw)
To: Piet Delaney; +Cc: Andrew Morton, Thomas Schlichter, linux-kernel, linux-mm
On Wed, Jul 09, 2003 at 10:44:50PM -0700, Piet Delaney wrote:
> I'll settle for Matt Mackall <mpm@selenic.com> fix for now:
> +#define apm_save_cpus() (current->cpus_allowed)
> I wonder why other, like Thomas Schlichter <schlicht@uni-mannheim.de>,
> had no problem with the CPU_MASK_NONE fix.
> I tried adding the #include <linux/cpumask.h> that Marc-Christian
> Petersen <m.c.p@wolk-project.de> sugested but it didn't help. Looks
> like Jan De Luyck <lkml@kcore.org> had a similar result.
Ugh. Fixing.
-- wli
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 2.5.74-mm3 - apm_save_cpus() Macro still bombs out
2003-07-10 6:08 ` William Lee Irwin III
@ 2003-07-10 7:10 ` William Lee Irwin III
2003-07-10 7:18 ` Andrew Morton
0 siblings, 1 reply; 30+ messages in thread
From: William Lee Irwin III @ 2003-07-10 7:10 UTC (permalink / raw)
To: Piet Delaney, Andrew Morton, Thomas Schlichter, linux-kernel, linux-mm
On Wed, Jul 09, 2003 at 10:44:50PM -0700, Piet Delaney wrote:
>> I'll settle for Matt Mackall <mpm@selenic.com> fix for now:
>> +#define apm_save_cpus() (current->cpus_allowed)
>> I wonder why other, like Thomas Schlichter <schlicht@uni-mannheim.de>,
>> had no problem with the CPU_MASK_NONE fix.
>> I tried adding the #include <linux/cpumask.h> that Marc-Christian
>> Petersen <m.c.p@wolk-project.de> sugested but it didn't help. Looks
>> like Jan De Luyck <lkml@kcore.org> had a similar result.
On Wed, Jul 09, 2003 at 11:08:41PM -0700, William Lee Irwin III wrote:
> Ugh. Fixing.
diff -prauN mm3-2.5.74-1/arch/i386/kernel/apm.c mm3-2.5.74-apm-1/arch/i386/kernel/apm.c
--- mm3-2.5.74-1/arch/i386/kernel/apm.c 2003-07-09 00:03:25.000000000 -0700
+++ mm3-2.5.74-apm-1/arch/i386/kernel/apm.c 2003-07-10 00:03:31.000000000 -0700
@@ -528,7 +528,7 @@ static inline void apm_restore_cpus(cpum
* No CPU lockdown needed on a uniprocessor
*/
-#define apm_save_cpus() 0
+#define apm_save_cpus() ({ cpumask_t __mask__ = CPU_MASK_NONE; __mask__; })
#define apm_restore_cpus(x) (void)(x)
#endif
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: 2.5.74-mm3 - apm_save_cpus() Macro still bombs out
2003-07-10 7:10 ` William Lee Irwin III
@ 2003-07-10 7:18 ` Andrew Morton
2003-07-10 7:59 ` William Lee Irwin III
` (2 more replies)
0 siblings, 3 replies; 30+ messages in thread
From: Andrew Morton @ 2003-07-10 7:18 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: piet, schlicht, linux-kernel, linux-mm
William Lee Irwin III <wli@holomorphy.com> wrote:
>
> -#define apm_save_cpus() 0
> +#define apm_save_cpus() ({ cpumask_t __mask__ = CPU_MASK_NONE; __mask__; })
Taking a look at what the APM code is actually doing, I think using
current->cpus_allowed just more sense in here.
Not that it matters at all.
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: 2.5.74-mm3 - apm_save_cpus() Macro still bombs out
2003-07-10 7:18 ` Andrew Morton
@ 2003-07-10 7:59 ` William Lee Irwin III
2003-07-10 4:09 ` hptraid.o -- No array found? Seth Chromick
2003-07-10 8:15 ` 2.5.74-mm3 - module-init-tools: necessary to replace root copies? Piet Delaney
2003-07-10 8:15 ` Piet Delaney
2 siblings, 1 reply; 30+ messages in thread
From: William Lee Irwin III @ 2003-07-10 7:59 UTC (permalink / raw)
To: Andrew Morton; +Cc: piet, schlicht, linux-kernel, linux-mm
William Lee Irwin III <wli@holomorphy.com> wrote:
>> -#define apm_save_cpus() 0
>> +#define apm_save_cpus() ({ cpumask_t __mask__ = CPU_MASK_NONE; __mask__; })
On Thu, Jul 10, 2003 at 12:18:53AM -0700, Andrew Morton wrote:
> Taking a look at what the APM code is actually doing, I think using
> current->cpus_allowed just more sense in here.
> Not that it matters at all.
Going beyond pure substitution:
diff -prauN mm3-2.5.74-1/arch/i386/kernel/apm.c mm3-2.5.74-apm-1/arch/i386/kernel/apm.c
--- mm3-2.5.74-1/arch/i386/kernel/apm.c 2003-07-09 00:03:25.000000000 -0700
+++ mm3-2.5.74-apm-1/arch/i386/kernel/apm.c 2003-07-10 00:53:51.000000000 -0700
@@ -506,8 +506,6 @@ static void apm_error(char *str, int err
* Lock APM functionality to physical CPU 0
*/
-#ifdef CONFIG_SMP
-
static cpumask_t apm_save_cpus(void)
{
cpumask_t x = current->cpus_allowed;
@@ -522,17 +520,6 @@ static inline void apm_restore_cpus(cpum
set_cpus_allowed(current, mask);
}
-#else
-
-/*
- * No CPU lockdown needed on a uniprocessor
- */
-
-#define apm_save_cpus() 0
-#define apm_restore_cpus(x) (void)(x)
-
-#endif
-
/*
* These are the actual BIOS calls. Depending on APM_ZERO_SEGS and
* apm_info.allow_ints, we are being really paranoid here! Not only
^ permalink raw reply [flat|nested] 30+ messages in thread* hptraid.o -- No array found?
2003-07-10 7:59 ` William Lee Irwin III
@ 2003-07-10 4:09 ` Seth Chromick
2003-07-10 12:20 ` Alan Cox
0 siblings, 1 reply; 30+ messages in thread
From: Seth Chromick @ 2003-07-10 4:09 UTC (permalink / raw)
To: linux-kernel
I have XP and Gentoo linux installed. In XP, my IDE RAID0 config can be
seen and used flawlessly (highpoint). In linux, modprobe ataraid works
fine, but modprobing hptraid gives me "Raid array not found" a few times
and stops. Any ideas? I've googled around to no avail...
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: hptraid.o -- No array found?
2003-07-10 4:09 ` hptraid.o -- No array found? Seth Chromick
@ 2003-07-10 12:20 ` Alan Cox
0 siblings, 0 replies; 30+ messages in thread
From: Alan Cox @ 2003-07-10 12:20 UTC (permalink / raw)
To: seth.chromick; +Cc: Linux Kernel Mailing List
On Iau, 2003-07-10 at 05:09, Seth Chromick wrote:
> I have XP and Gentoo linux installed. In XP, my IDE RAID0 config can be
> seen and used flawlessly (highpoint). In linux, modprobe ataraid works
> fine, but modprobing hptraid gives me "Raid array not found" a few times
> and stops. Any ideas? I've googled around to no avail...
hptraid only understands a small subset of the disk layouts so not all
forms are known. Wilfried has done some really good work on this so more
formats are known by the later drivers.
Unfortunately HPT don't seem keen to document their disk layout.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 2.5.74-mm3 - module-init-tools: necessary to replace root copies?
2003-07-10 7:18 ` Andrew Morton
2003-07-10 7:59 ` William Lee Irwin III
@ 2003-07-10 8:15 ` Piet Delaney
2003-07-10 8:15 ` Piet Delaney
2 siblings, 0 replies; 30+ messages in thread
From: Piet Delaney @ 2003-07-10 8:15 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
I followed your suggestion of installing the module-init-tools
to get around the "make modules_install" problem. I modified
the kernel Makefile to point to /usr/local:
#DEPMOD = /sbin/depmod
DEPMOD = /usr/local/sbin/depmod
I expect it's likely necessary to copy the /usr/local
copies over the / copies so that they are available to
the boot code; Perhaps not.
I thought I check to see how you and/or others did
to for using the newer module-init-tools.
Also, do you think it's better to enable the use
frame pointer when using kgdb. In the past I thought
I had problems with modules due to my enabling the
frame pointer being used.
-piet
--
piet@www.piet.net
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 2.5.74-mm3 - module-init-tools: necessary to replace root copies?
2003-07-10 7:18 ` Andrew Morton
2003-07-10 7:59 ` William Lee Irwin III
2003-07-10 8:15 ` 2.5.74-mm3 - module-init-tools: necessary to replace root copies? Piet Delaney
@ 2003-07-10 8:15 ` Piet Delaney
2003-07-10 8:23 ` Andrew Morton
2 siblings, 1 reply; 30+ messages in thread
From: Piet Delaney @ 2003-07-10 8:15 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
I followed your suggestion of installing the module-init-tools
to get around the "make modules_install" problem. I modified
the kernel Makefile to point to /usr/local:
#DEPMOD = /sbin/depmod
DEPMOD = /usr/local/sbin/depmod
I expect it's likely necessary to copy the /usr/local
copies over the / copies so that they are available to
the boot code; Perhaps not.
I thought I check to see how you and/or others did
to for using the newer module-init-tools.
Also, do you think it's better to enable the use
frame pointer when using kgdb. In the past I thought
I had problems with modules due to my enabling the
frame pointer being used.
-piet
--
piet@www.piet.net
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 2.5.74-mm3 - module-init-tools: necessary to replace root copies?
2003-07-10 8:15 ` Piet Delaney
@ 2003-07-10 8:23 ` Andrew Morton
0 siblings, 0 replies; 30+ messages in thread
From: Andrew Morton @ 2003-07-10 8:23 UTC (permalink / raw)
To: Piet Delaney; +Cc: linux-kernel, linux-mm
Piet Delaney <piet@www.piet.net> wrote:
>
> Also, do you think it's better to enable the use
> frame pointer when using kgdb.
Enabled, definitely.
> In the past I thought
> I had problems with modules due to my enabling the
> frame pointer being used.
No, there are no such problems.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 2.5.74-mm3 - apm_save_cpus() Macro still bombs out
2003-07-10 5:44 ` 2.5.74-mm3 - apm_save_cpus() Macro still bombs out Piet Delaney
2003-07-10 6:08 ` William Lee Irwin III
@ 2003-07-10 9:22 ` Thomas Schlichter
2003-07-10 9:27 ` William Lee Irwin III
1 sibling, 1 reply; 30+ messages in thread
From: Thomas Schlichter @ 2003-07-10 9:22 UTC (permalink / raw)
To: Piet Delaney, Andrew Morton; +Cc: linux-kernel, linux-mm
On Thursday 10 July 2003 07:44, Piet Delaney wrote:
> On Wed, 2003-07-09 at 02:18, Andrew Morton wrote:
> > Thomas Schlichter <schlicht@uni-mannheim.de> wrote:
>
> .
> .
> .
>
> > Seems complex. I just have this:
~~snip~~
> I'll settle for Matt Mackall <mpm@selenic.com> fix for now:
>
> +#define apm_save_cpus() (current->cpus_allowed)
>
> I wonder why other, like Thomas Schlichter <schlicht@uni-mannheim.de>,
> had no problem with the CPU_MASK_NONE fix.
Well, I didn't try the CPU_MASK_NONE fix. I am using my fix attached to my
first mail, but Andrew ment it was too complex (your quoting from above). So
he proposed the simpler fix, wich simply looked good to me...
> I tried adding the #include <linux/cpumask.h> that Marc-Christian
> Petersen <m.c.p@wolk-project.de> sugested but it didn't help. Looks
> like Jan De Luyck <lkml@kcore.org> had a similar result.
>
> -piet
Thomas
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 2.5.74-mm3 - apm_save_cpus() Macro still bombs out
2003-07-10 9:22 ` 2.5.74-mm3 - apm_save_cpus() Macro still bombs out Thomas Schlichter
@ 2003-07-10 9:27 ` William Lee Irwin III
2003-07-10 9:42 ` Thomas Schlichter
0 siblings, 1 reply; 30+ messages in thread
From: William Lee Irwin III @ 2003-07-10 9:27 UTC (permalink / raw)
To: Thomas Schlichter; +Cc: Piet Delaney, Andrew Morton, linux-kernel, linux-mm
On Thu, Jul 10, 2003 at 11:22:56AM +0200, Thomas Schlichter wrote:
> Well, I didn't try the CPU_MASK_NONE fix. I am using my fix attached to my
> first mail, but Andrew ment it was too complex (your quoting from above). So
> he proposed the simpler fix, wich simply looked good to me...
Could you try the following?
diff -prauN mm3-2.5.74-1/arch/i386/kernel/apm.c mm3-2.5.74-apm-1/arch/i386/kernel/apm.c
--- mm3-2.5.74-1/arch/i386/kernel/apm.c 2003-07-09 00:03:25.000000000 -0700
+++ mm3-2.5.74-apm-1/arch/i386/kernel/apm.c 2003-07-10 00:53:51.000000000 -0700
@@ -506,8 +506,6 @@ static void apm_error(char *str, int err
* Lock APM functionality to physical CPU 0
*/
-#ifdef CONFIG_SMP
-
static cpumask_t apm_save_cpus(void)
{
cpumask_t x = current->cpus_allowed;
@@ -522,17 +520,6 @@ static inline void apm_restore_cpus(cpum
set_cpus_allowed(current, mask);
}
-#else
-
-/*
- * No CPU lockdown needed on a uniprocessor
- */
-
-#define apm_save_cpus() 0
-#define apm_restore_cpus(x) (void)(x)
-
-#endif
-
/*
* These are the actual BIOS calls. Depending on APM_ZERO_SEGS and
* apm_info.allow_ints, we are being really paranoid here! Not only
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: 2.5.74-mm3 - apm_save_cpus() Macro still bombs out
2003-07-10 9:27 ` William Lee Irwin III
@ 2003-07-10 9:42 ` Thomas Schlichter
2003-07-10 9:48 ` William Lee Irwin III
0 siblings, 1 reply; 30+ messages in thread
From: Thomas Schlichter @ 2003-07-10 9:42 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: Piet Delaney, Andrew Morton, linux-kernel, linux-mm
On Thursday 10 July 2003 11:27, William Lee Irwin III wrote:
> On Thu, Jul 10, 2003 at 11:22:56AM +0200, Thomas Schlichter wrote:
> > Well, I didn't try the CPU_MASK_NONE fix. I am using my fix attached to
> > my first mail, but Andrew ment it was too complex (your quoting from
> > above). So he proposed the simpler fix, wich simply looked good to me...
>
> Could you try the following?
OK, I tried it. For me it compiles!
But the size of the resulting objectfile's text section is about 64bytes
larger than with my patch. So it seems that gcc3.3 wasn't able to optimize
away all the unneeded stuff...
And I don't think my patch is that ugly, but hey, it's your decision...
Best regards
Thomas Schlichter
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 2.5.74-mm3 - apm_save_cpus() Macro still bombs out
2003-07-10 9:42 ` Thomas Schlichter
@ 2003-07-10 9:48 ` William Lee Irwin III
2003-07-10 9:59 ` Thomas Schlichter
0 siblings, 1 reply; 30+ messages in thread
From: William Lee Irwin III @ 2003-07-10 9:48 UTC (permalink / raw)
To: Thomas Schlichter; +Cc: Piet Delaney, Andrew Morton, linux-kernel, linux-mm
On Thursday 10 July 2003 11:27, William Lee Irwin III wrote:
>> Could you try the following?
On Thu, Jul 10, 2003 at 11:42:35AM +0200, Thomas Schlichter wrote:
> OK, I tried it. For me it compiles!
> But the size of the resulting objectfile's text section is about 64bytes
> larger than with my patch. So it seems that gcc3.3 wasn't able to optimize
> away all the unneeded stuff...
> And I don't think my patch is that ugly, but hey, it's your decision...
64B? Why do you care?
-- wli
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 2.5.74-mm3 - apm_save_cpus() Macro still bombs out
2003-07-10 9:48 ` William Lee Irwin III
@ 2003-07-10 9:59 ` Thomas Schlichter
2003-07-10 10:30 ` William Lee Irwin III
0 siblings, 1 reply; 30+ messages in thread
From: Thomas Schlichter @ 2003-07-10 9:59 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: Piet Delaney, Andrew Morton, linux-kernel, linux-mm
On Thursday 10 July 2003 11:48, William Lee Irwin III wrote:
> On Thursday 10 July 2003 11:27, William Lee Irwin III wrote:
> >> Could you try the following?
>
> On Thu, Jul 10, 2003 at 11:42:35AM +0200, Thomas Schlichter wrote:
> > OK, I tried it. For me it compiles!
> > But the size of the resulting objectfile's text section is about 64bytes
> > larger than with my patch. So it seems that gcc3.3 wasn't able to
> > optimize away all the unneeded stuff...
> > And I don't think my patch is that ugly, but hey, it's your decision...
>
> 64B? Why do you care?
It's not the 64B...
I care about the unneeded but executed code!
But I'm a hopeless perfectionist caring about such nits...
And I don't know why everybody hates my patches... ;-(
Thomas
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 2.5.74-mm3 - apm_save_cpus() Macro still bombs out
2003-07-10 9:59 ` Thomas Schlichter
@ 2003-07-10 10:30 ` William Lee Irwin III
2003-07-10 10:49 ` Thomas Schlichter
2003-07-11 14:56 ` Matt Mackall
0 siblings, 2 replies; 30+ messages in thread
From: William Lee Irwin III @ 2003-07-10 10:30 UTC (permalink / raw)
To: Thomas Schlichter; +Cc: Piet Delaney, Andrew Morton, linux-kernel, linux-mm
On Thursday 10 July 2003 11:48, William Lee Irwin III wrote:
> It's not the 64B...
> I care about the unneeded but executed code!
> But I'm a hopeless perfectionist caring about such nits...
On Thu, Jul 10, 2003 at 11:59:49AM +0200, Thomas Schlichter wrote:
> And I don't know why everybody hates my patches... ;-(
It's not that anyone hates them, it's that
pass 1: the semantics (0 == empty cpu set) needed preserving
pass 2: remove code instead of changing redundant stuff
NFI YTF gcc doesn't optimize out the whole shebang.
At any rate, if we're pounding APM BIOS calls or apm_power_off()
like wild monkeys there's something far more disturbing going wrong
than 64B of code gcc couldn't optimize (it's probably due to some
jump target being aligned to death or some such nonsense).
-- wli
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 2.5.74-mm3 - apm_save_cpus() Macro still bombs out
2003-07-10 10:30 ` William Lee Irwin III
@ 2003-07-10 10:49 ` Thomas Schlichter
2003-07-11 14:56 ` Matt Mackall
1 sibling, 0 replies; 30+ messages in thread
From: Thomas Schlichter @ 2003-07-10 10:49 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: Piet Delaney, Andrew Morton, linux-kernel, linux-mm
On Thursday 10 July 2003 12:30, William Lee Irwin III wrote:
> On Thu, Jul 10, 2003 at 11:59:49AM +0200, Thomas Schlichter wrote:
> > And I don't know why everybody hates my patches... ;-(
That was just fun, but OK, I forgot the 'fun' tags... ;-)
> It's not that anyone hates them, it's that
> pass 1: the semantics (0 == empty cpu set) needed preserving
Well the original code already had 2 different semantics:
In the MP case it returned the mask of currently allowed CPUs which should
have been 1 for UP but was 0...
So as the value returned by apm_save_cpus() was only used for apm_restore_cpus
() I optimized it away. Which was just an other change of the semantics...ACK
> pass 2: remove code instead of changing redundant stuff
ACK
> NFI YTF gcc doesn't optimize out the whole shebang.
>
> At any rate, if we're pounding APM BIOS calls or apm_power_off()
> like wild monkeys there's something far more disturbing going wrong
> than 64B of code gcc couldn't optimize (it's probably due to some
> jump target being aligned to death or some such nonsense).
OK, I see you're right and your actual patch looks better to me because it
makes the semantics consistent! So come on and let's take it into the
tree...!
Thomas
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 2.5.74-mm3 - apm_save_cpus() Macro still bombs out
2003-07-10 10:30 ` William Lee Irwin III
2003-07-10 10:49 ` Thomas Schlichter
@ 2003-07-11 14:56 ` Matt Mackall
1 sibling, 0 replies; 30+ messages in thread
From: Matt Mackall @ 2003-07-11 14:56 UTC (permalink / raw)
To: William Lee Irwin III, Thomas Schlichter, Piet Delaney,
Andrew Morton, linux-kernel, linux-mm
On Thu, Jul 10, 2003 at 03:30:22AM -0700, William Lee Irwin III wrote:
> On Thursday 10 July 2003 11:48, William Lee Irwin III wrote:
> > It's not the 64B...
> > I care about the unneeded but executed code!
> > But I'm a hopeless perfectionist caring about such nits...
>
> On Thu, Jul 10, 2003 at 11:59:49AM +0200, Thomas Schlichter wrote:
> > And I don't know why everybody hates my patches... ;-(
>
> It's not that anyone hates them, it's that
> pass 1: the semantics (0 == empty cpu set) needed preserving
> pass 2: remove code instead of changing redundant stuff
>
> NFI YTF gcc doesn't optimize out the whole shebang.
Probably would if inline were added to the function spec?
If we're going to worry about space, we'd start by worrying about the
existence of current->cpus_allowed in the UP case.
> At any rate, if we're pounding APM BIOS calls or apm_power_off()
> like wild monkeys there's something far more disturbing going wrong
> than 64B of code gcc couldn't optimize (it's probably due to some
> jump target being aligned to death or some such nonsense).
I much prefer the removal of #ifdef approach - would have prevented
the bug getting out in the first place.
--
Matt Mackall : http://www.selenic.com : of or relating to the moon
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 2.5.74-mm3
2003-07-09 5:35 2.5.74-mm3 Andrew Morton
2003-07-09 9:05 ` 2.5.74-mm3 Thomas Schlichter
@ 2003-07-09 9:24 ` Matt Mackall
2003-07-09 9:29 ` 2.5.74-mm3 William Lee Irwin III
2003-07-10 18:21 ` 2.5.74-mm3 Valdis.Kletnieks
2 siblings, 1 reply; 30+ messages in thread
From: Matt Mackall @ 2003-07-09 9:24 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
On Tue, Jul 08, 2003 at 10:35:48PM -0700, Andrew Morton wrote:
> Merged
>
> -cpumask_t-1.patch
> -gcc-bug-workaround.patch
> -sparse-apic-fix.patch
> -nuke-cpumask_arith.patch
> -p4-clockmod-cpumask-fix.patch
>
> Folded into cpumask_t-1.patch
>
> +cpumask_t-s390-fix.patch
> +kgdb-cpumask_t.patch
> +cpumask_t-x86_64-fix.patch
> +sparc64-cpumask_t-fix.patch
>
> cpumask_t fixes
UP APM has broken since -mm2, looks like something like this is
needed (compiles, untested):
diff -urN -x genksyms -x '*.ver' -x '.patch*' -x '*.orig' orig/arch/i386/kernel/apm.c patched/arch/i386/kernel/apm.c
--- orig/arch/i386/kernel/apm.c 2003-07-09 04:07:06.000000000 -0500
+++ patched/arch/i386/kernel/apm.c 2003-07-09 04:19:52.000000000 -0500
@@ -528,7 +528,7 @@
* No CPU lockdown needed on a uniprocessor
*/
-#define apm_save_cpus() 0
+#define apm_save_cpus() (current->cpus_allowed)
#define apm_restore_cpus(x) (void)(x)
#endif
--
Matt Mackall : http://www.selenic.com : of or relating to the moon
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 2.5.74-mm3
2003-07-09 9:24 ` 2.5.74-mm3 Matt Mackall
@ 2003-07-09 9:29 ` William Lee Irwin III
0 siblings, 0 replies; 30+ messages in thread
From: William Lee Irwin III @ 2003-07-09 9:29 UTC (permalink / raw)
To: Matt Mackall; +Cc: Andrew Morton, linux-kernel, linux-mm
On Wed, Jul 09, 2003 at 04:24:33AM -0500, Matt Mackall wrote:
> -#define apm_save_cpus() 0
> +#define apm_save_cpus() (current->cpus_allowed)
> #define apm_restore_cpus(x) (void)(x)
It's trying to describe an empty set of cpus. This is denoted by
CPU_MASK_NONE in the cpumask_t bits.
-- wli
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 2.5.74-mm3
2003-07-09 5:35 2.5.74-mm3 Andrew Morton
2003-07-09 9:05 ` 2.5.74-mm3 Thomas Schlichter
2003-07-09 9:24 ` 2.5.74-mm3 Matt Mackall
@ 2003-07-10 18:21 ` Valdis.Kletnieks
2003-07-11 8:25 ` 2.5.74-mm3 Joe Thornber
2 siblings, 1 reply; 30+ messages in thread
From: Valdis.Kletnieks @ 2003-07-10 18:21 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
[-- Attachment #1: Type: text/plain, Size: 887 bytes --]
On Tue, 08 Jul 2003 22:35:48 PDT, Andrew Morton <akpm@osdl.org> said:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.74/2.5.74-mm3/
OK, I'm finally getting around to actually commenting, this has been a niggling issue for
a while...
> All 113 patches:
> 64-bit-dev_t-kdev_t.patch
> 64-bit dev_t and kdev_t
Yes, this patch says "not ready for prime time, it breaks things".
In particular, this gives the device-mapper userspace indigestion, because the
ioctl passes something other than a 64-bit kdev_t in from libdevmapper. Upshot
is that the LVM2 'vgchange -ay' fails gloriously.
Workaround: Compile the devmapper/LVM stuff with a private copy of include/
linux/kdev_t.h that matches the one the kernel uses. No, I didn't actually get
that to work, so I backed out the 64-bit patch...
(And no, the recent devmapper/LVM2 stuff posted doesn't fix this).
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 2.5.74-mm3
2003-07-10 18:21 ` 2.5.74-mm3 Valdis.Kletnieks
@ 2003-07-11 8:25 ` Joe Thornber
2003-07-11 16:02 ` 2.5.74-mm3 Anton Blanchard
0 siblings, 1 reply; 30+ messages in thread
From: Joe Thornber @ 2003-07-11 8:25 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: Andrew Morton, linux-kernel, linux-mm
On Thu, Jul 10, 2003 at 02:21:08PM -0400, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 08 Jul 2003 22:35:48 PDT, Andrew Morton <akpm@osdl.org> said:
>
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.74/2.5.74-mm3/
>
> OK, I'm finally getting around to actually commenting, this has been a niggling issue for
> a while...
>
> > All 113 patches:
>
> > 64-bit-dev_t-kdev_t.patch
> > 64-bit dev_t and kdev_t
>
> Yes, this patch says "not ready for prime time, it breaks things".
>
> In particular, this gives the device-mapper userspace indigestion, because the
> ioctl passes something other than a 64-bit kdev_t in from libdevmapper. Upshot
> is that the LVM2 'vgchange -ay' fails gloriously.
>
> Workaround: Compile the devmapper/LVM stuff with a private copy of include/
> linux/kdev_t.h that matches the one the kernel uses. No, I didn't actually get
> that to work, so I backed out the 64-bit patch...
>
> (And no, the recent devmapper/LVM2 stuff posted doesn't fix this).
The v1 ioctl interface passes the dev in as a __kernel_dev_t, so
unfortunately if you change the size of __kernel_dev_t you will have
to rebuild the tools.
The v4 ioctl interface just uses a __u64 which I hope will be future
proof.
- Joe
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 2.5.74-mm3
2003-07-11 8:25 ` 2.5.74-mm3 Joe Thornber
@ 2003-07-11 16:02 ` Anton Blanchard
0 siblings, 0 replies; 30+ messages in thread
From: Anton Blanchard @ 2003-07-11 16:02 UTC (permalink / raw)
To: Joe Thornber; +Cc: Valdis.Kletnieks, Andrew Morton, linux-kernel, linux-mm
> The v1 ioctl interface passes the dev in as a __kernel_dev_t, so
> unfortunately if you change the size of __kernel_dev_t you will have
> to rebuild the tools.
>
> The v4 ioctl interface just uses a __u64 which I hope will be future
> proof.
This was the only thing that made the 32bit ioctls different to the 64bit
ones on ppc64, so changing it to __u64 is a good thing.
Anton
^ permalink raw reply [flat|nested] 30+ messages in thread