Hello,

Got that on imac g3.

CC kernel/kgdb.o
kernel/kgdb.c: In function 'kgdb_handle_exception':
kernel/kgdb.c:940: error: invalid lvalue in unary '&'
kernel/kgdb.c:940: warning: type defaults to 'int' in declaration of '_o_'
kernel/kgdb.c:940: error: invalid lvalue in unary '&'
kernel/kgdb.c:940: warning: type defaults to 'int' in declaration of '_n_'
kernel/kgdb.c:940: error: invalid lvalue in unary '&'
kernel/kgdb.c:940: error: invalid lvalue in unary '&'
kernel/kgdb.c:940: error: invalid lvalue in unary '&'
kernel/kgdb.c:940: warning: type defaults to 'int' in declaration of 'type name'
make[1]: *** [kernel/kgdb.o] Blad 1
make: *** [kernel] Blad 2

Regards,

Mariusz

Attachments:

(No filename) (692.00 B)
.config (73.94 kB)
Download all attachments

2007-08-22 19:16:44

Signed-off-by: Jason Wessel <[email protected]>

---
kernel/kgdb.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)

--- a/kernel/kgdb.c
+++ b/kernel/kgdb.c
@@ -121,6 +121,7 @@ struct task_struct *kgdb_usethread, *kgd

int debugger_step;
atomic_t debugger_active;
+static atomic_t kgdb_sync = ATOMIC_INIT(-1);

/* Our I/O buffers. */
static char remcom_in_buffer[BUFMAX];
@@ -638,8 +639,14 @@ static void kgdb_wait(struct pt_regs *re
kgdb_info[processor].task = current;
atomic_set(&procindebug[processor], 1);

+ /* The master processor must be active to enter here, but this is
+ * gaurd in case the master processor had not been selected if
+ * this was an entry via nmi.
+ */
+ while (!atomic_read(&debugger_active));
+
/* Wait till master processor goes completely into the debugger.
- * FIXME: this looks racy */
+ */
while (!atomic_read(&procindebug[atomic_read(&debugger_active) - 1])) {
int i = 10; /* an arbitrary number */

@@ -973,8 +980,13 @@ int kgdb_handle_exception(int ex_vector,
/* Hold debugger_active */
procid = raw_smp_processor_id();

- while (cmpxchg(&atomic_read(&debugger_active), 0, (procid + 1)) != 0) {
+ while (1) {
int i = 25; /* an arbitrary number */
+ if (atomic_read(&kgdb_sync) < 0 &&
+ atomic_inc_and_test(&kgdb_sync)) {
+ atomic_set(&debugger_active, procid + 1);
+ break;
+ }

while (--i)
cpu_relax();
@@ -991,6 +1003,7 @@ int kgdb_handle_exception(int ex_vector,
if (atomic_read(&cpu_doing_single_step) != -1 &&
atomic_read(&cpu_doing_single_step) != procid) {
atomic_set(&debugger_active, 0);
+ atomic_set(&kgdb_sync, -1);
clocksource_touch_watchdog();
kgdb_softlock_skip[procid] = 1;
local_irq_restore(flags);
@@ -1557,6 +1570,7 @@ int kgdb_handle_exception(int ex_vector,
kgdb_restore:
/* Free debugger_active */
atomic_set(&debugger_active, 0);
+ atomic_set(&kgdb_sync, -1);
clocksource_touch_watchdog();
kgdb_softlock_skip[processor] = 1;
local_irq_restore(flags);

Attachments:

kgdb_enter_atomic.patch (1.98 kB)

2007-08-22 23:32:17

by Gabriel C

[permalink] [raw]

Subject: drivers/char/nozomi.c - compile error ( Re: 2.6.23-rc3-mm1 )

config : http://194.231.229.228/kernel/mm/2.6.23-rc3-mm1/r/randconfig-18

...

drivers/char/nozomi.c:2204: error: expected expression before '__attribute__'
make[2]: *** [drivers/char/nozomi.o] Error 1
make[1]: *** [drivers/char] Error 2
make: *** [drivers] Error 2
make: *** Waiting for unfinished jobs....

...

2007-08-22 23:36:21

by Gabriel C

[permalink] [raw]

Subject: fs/xfs/xfs_bmap_btree.c - compile error (Re: 2.6.23-rc3-mm1)

config : http://194.231.229.228/kernel/mm/2.6.23-rc3-mm1/r/randconfig-18

...

fs/xfs/xfs_bmap_btree.c: In function 'xfs_bmbt_set_allf':
fs/xfs/xfs_bmap_btree.c:2312: error: 'b' undeclared (first use in this function)
fs/xfs/xfs_bmap_btree.c:2312: error: (Each undeclared identifier is reported only once
fs/xfs/xfs_bmap_btree.c:2312: error: for each function it appears in.)
fs/xfs/xfs_bmap_btree.c: In function 'xfs_bmbt_disk_set_allf':
fs/xfs/xfs_bmap_btree.c:2372: error: 'b' undeclared (first use in this function)
make[2]: *** [fs/xfs/xfs_bmap_btree.o] Error 1
make[2]: *** Waiting for unfinished jobs....
CC fs/reiser4/safe_link.o
CC fs/reiser4/plugin/plugin.o
make[1]: *** [fs/xfs] Error 2
make[1]: *** Waiting for unfinished jobs....

...

2007-08-22 23:54:23

by Andrew Morton

[permalink] [raw]

Subject: Re: [Kgdb-bugreport] 2.6.23-rc3-mm1: kgdb build failure on powerpc

On Wed, 22 Aug 2007 17:44:12 -0500
Jason Wessel <[email protected]> wrote:

> Perhaps there is a cleaner way to do the same thing and avoid the
> cmpxchg all together. I used the attached patch to eliminate the
> cmpxchg operation.
>
>
> Jason.
>
>
> [kgdb_enter_atomic.patch text/plain (2.0KB)]
> Signed-off-by: Jason Wessel <[email protected]>
>
> ---
> kernel/kgdb.c | 18 ++++++++++++++++--
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> --- a/kernel/kgdb.c
> +++ b/kernel/kgdb.c
> @@ -121,6 +121,7 @@ struct task_struct *kgdb_usethread, *kgd
>
> int debugger_step;
> atomic_t debugger_active;
> +static atomic_t kgdb_sync = ATOMIC_INIT(-1);
>
> /* Our I/O buffers. */
> static char remcom_in_buffer[BUFMAX];
> @@ -638,8 +639,14 @@ static void kgdb_wait(struct pt_regs *re
> kgdb_info[processor].task = current;
> atomic_set(&procindebug[processor], 1);
>
> + /* The master processor must be active to enter here, but this is
> + * gaurd in case the master processor had not been selected if
> + * this was an entry via nmi.
> + */
> + while (!atomic_read(&debugger_active));

eek. We're in the process of hunting down and eliminating exactly this
construct. There have been cases where the compiler cached the
atomic_read() result in a register, turning the above into an infinite
loop.

Plus we should never add power-burners like that into the kernel anyway.
That loop should have a cpu_relax() in it. Which will also fix the
compiler problem described above.

Thirdly, please always add a newline when coding statements like that:

while (expr())
;

2007-08-23 02:17:01

On Wed, 22 Aug 2007 02:06:48 PDT, Andrew Morton said:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/

OK, so I don't actually *use* the irDA on my laptop for much, but I figure if
I have the hardware, I should at least make sure the driver comes up.

23-rc3-mm1 causes massive spewage, apparently at least partially as a fall-out
of the sysctl rework. Not sure if those caused the 'unknown symbol' issues or
not. The 'cannot allocate memory' is somewhat odd too, I can't believe it was
*really* out of memory while still in /etc/rc5.d when I have 2G of ram...

kernel: [ 247.804000] NET: Registered protocol family 23
kernel: [ 247.804000] sysctl table check failed: /net/irda .3.412 Unknown sysctl binary path
kernel: [ 247.804000] sysctl table check failed: /net/irda/discovery .3.412.1 Unknown sysctl binary path
kernel: [ 247.804000] sysctl table check failed: /net/irda/devname .3.412.2 Unknown sysctl binary path
kernel: [ 247.804000] sysctl table check failed: /net/irda/debug .3.412.3 Unknown sysctl binary path
kernel: [ 247.804000] sysctl table check failed: /net/irda/fast_poll_increase .3.412.4 Unknown sysctl binary path
kernel: [ 247.804000] sysctl table check failed: /net/irda/discovery_slots .3.412.5 Unknown sysctl binary path
kernel: [ 247.804000] sysctl table check failed: /net/irda/discovery_timeout .3.412.6 Unknown sysctl binary path
kernel: [ 247.804000] sysctl table check failed: /net/irda/slot_timeout .3.412.7 Unknown sysctl binary path
kernel: [ 247.804000] sysctl table check failed: /net/irda/max_baud_rate .3.412.8 Unknown sysctl binary path
kernel: [ 247.804000] sysctl table check failed: /net/irda/min_tx_turn_time .3.412.9 Unknown sysctl binary path
kernel: [ 247.804000] sysctl table check failed: /net/irda/max_tx_data_size .3.412.10 Unknown sysctl binary path
kernel: [ 247.804000] sysctl table check failed: /net/irda/max_tx_window .3.412.11 Unknown sysctl binary path
kernel: [ 247.804000] sysctl table check failed: /net/irda/max_noreply_time .3.412.12 Unknown sysctl binary path
kernel: [ 247.804000] sysctl table check failed: /net/irda/warn_noreply_time .3.412.13 Unknown sysctl binary path
kernel: [ 247.804000] sysctl table check failed: /net/irda/lap_keepalive_time .3.412.14 Unknown sysctl binary path
kernel: [ 247.816000] NET: Unregistered protocol family 23
kernel: [ 247.826000] ircomm: Unknown symbol hashbin_insert
kernel: [ 247.826000] ircomm: Unknown symbol irttp_flow_request
kernel: [ 247.826000] ircomm: Unknown symbol hashbin_lock_find
kernel: [ 247.826000] ircomm: Unknown symbol irttp_open_tsap
kernel: [ 247.826000] ircomm: Unknown symbol irlmp_connect_request
kernel: [ 247.826000] ircomm: Unknown symbol irda_notify_init
kernel: [ 247.826000] ircomm: Unknown symbol hashbin_get_first
kernel: [ 247.826000] ircomm: Unknown symbol irttp_connect_response
kernel: [ 247.827000] ircomm: Unknown symbol irda_debug
kernel: [ 247.827000] ircomm: Unknown symbol hashbin_get_next
kernel: [ 247.827000] ircomm: Unknown symbol hashbin_remove
kernel: [ 247.827000] ircomm: Unknown symbol hashbin_delete
kernel: [ 247.827000] ircomm: Unknown symbol hashbin_new
kernel: [ 247.827000] ircomm: Unknown symbol irttp_disconnect_request
kernel: [ 247.827000] ircomm: Unknown symbol irlmp_disconnect_request
kernel: [ 247.827000] ircomm: Unknown symbol irlmp_connect_response
kernel: [ 247.827000] ircomm: Unknown symbol irttp_data_request
kernel: [ 247.827000] ircomm: Unknown symbol irttp_connect_request
kernel: [ 247.827000] ircomm: Unknown symbol irlmp_close_lsap
kernel: [ 247.827000] ircomm: Unknown symbol irttp_close_tsap
kernel: [ 247.827000] ircomm: Unknown symbol proc_irda
kernel: [ 247.827000] ircomm: Unknown symbol irlmp_open_lsap
kernel: [ 247.827000] ircomm: Unknown symbol irlmp_data_request
kernel: [ 247.829000] ircomm_tty: Unknown symbol irda_param_insert
kernel: [ 247.829000] ircomm_tty: Unknown symbol hashbin_insert
kernel: [ 247.829000] ircomm_tty: Unknown symbol irlmp_service_to_hint
kernel: [ 247.829000] ircomm_tty: Unknown symbol ircomm_data_request
kernel: [ 247.829000] ircomm_tty: Unknown symbol ircomm_flow_request
kernel: [ 247.829000] ircomm_tty: Unknown symbol irias_new_object
kernel: [ 247.829000] ircomm_tty: Unknown symbol irlmp_unregister_service
kernel: [ 247.829000] ircomm_tty: Unknown symbol hashbin_lock_find
kernel: [ 247.829000] ircomm_tty: Unknown symbol ircomm_open
kernel: [ 247.829000] ircomm_tty: Unknown symbol ircomm_close
kernel: [ 247.829000] ircomm_tty: Unknown symbol iriap_open
kernel: [ 247.829000] ircomm_tty: Unknown symbol ircomm_control_request
kernel: [ 247.829000] ircomm_tty: Unknown symbol irias_add_octseq_attrib
kernel: [ 247.829000] ircomm_tty: Unknown symbol irda_notify_init
kernel: [ 247.829000] ircomm_tty: Unknown symbol irlmp_discovery_request
kernel: [ 247.829000] ircomm_tty: Unknown symbol iriap_close
kernel: [ 247.829000] ircomm_tty: Unknown symbol hashbin_get_first
kernel: [ 247.829000] ircomm_tty: Unknown symbol irias_add_integer_attrib
kernel: [ 247.829000] ircomm_tty: Unknown symbol ircomm_connect_request
kernel: [ 247.829000] ircomm_tty: Unknown symbol irda_debug
kernel: [ 247.830000] ircomm_tty: Unknown symbol irlmp_register_service
kernel: [ 247.830000] ircomm_tty: Unknown symbol irda_param_extract_all
kernel: [ 247.830000] ircomm_tty: Unknown symbol hashbin_get_next
kernel: [ 247.830000] ircomm_tty: Unknown symbol ircomm_disconnect_request
kernel: [ 247.830000] ircomm_tty: Unknown symbol hashbin_delete
kernel: [ 247.830000] ircomm_tty: Unknown symbol hashbin_new
kernel: [ 247.830000] ircomm_tty: Unknown symbol irlmp_register_client
kernel: [ 247.830000] ircomm_tty: Unknown symbol iriap_getvaluebyclass_request
kernel: [ 247.830000] ircomm_tty: Unknown symbol irias_insert_object
kernel: [ 247.830000] ircomm_tty: Unknown symbol ircomm_connect_response
kernel: [ 247.830000] ircomm_tty: Unknown symbol irias_delete_object
kernel: [ 247.830000] ircomm_tty: Unknown symbol irlmp_unregister_client
kernel: [ 247.830000] ircomm_tty: Unknown symbol irda_param_pack
kernel: [ 247.830000] ircomm_tty: Unknown symbol irias_delete_value
kernel: [ 247.850000] NET: Registered protocol family 23
kernel: [ 247.850000] sysctl table check failed: /net/irda .3.412 Unknown sysctl binary path
kernel: [ 247.850000] sysctl table check failed: /net/irda/discovery .3.412.1 Unknown sysctl binary path
kernel: [ 247.850000] sysctl table check failed: /net/irda/devname .3.412.2 Unknown sysctl binary path
kernel: [ 247.850000] sysctl table check failed: /net/irda/debug .3.412.3 Unknown sysctl binary path
kernel: [ 247.850000] sysctl table check failed: /net/irda/fast_poll_increase .3.412.4 Unknown sysctl binary path
kernel: [ 247.850000] sysctl table check failed: /net/irda/discovery_slots .3.412.5 Unknown sysctl binary path
kernel: [ 247.850000] sysctl table check failed: /net/irda/discovery_timeout .3.412.6 Unknown sysctl binary path
kernel: [ 247.851000] sysctl table check failed: /net/irda/slot_timeout .3.412.7 Unknown sysctl binary path
kernel: [ 247.851000] sysctl table check failed: /net/irda/max_baud_rate .3.412.8 Unknown sysctl binary path
kernel: [ 247.851000] sysctl table check failed: /net/irda/min_tx_turn_time .3.412.9 Unknown sysctl binary path
kernel: [ 247.851000] sysctl table check failed: /net/irda/max_tx_data_size .3.412.10 Unknown sysctl binary path
kernel: [ 247.851000] sysctl table check failed: /net/irda/max_tx_window .3.412.11 Unknown sysctl binary path
kernel: [ 247.851000] sysctl table check failed: /net/irda/max_noreply_time .3.412.12 Unknown sysctl binary path
kernel: [ 247.851000] sysctl table check failed: /net/irda/warn_noreply_time .3.412.13 Unknown sysctl binary path
kernel: [ 247.851000] sysctl table check failed: /net/irda/lap_keepalive_time .3.412.14 Unknown sysctl binary path
kernel: [ 247.862000] NET: Unregistered protocol family 23
kernel: [ 247.867000] sir_dev: Unknown symbol alloc_irdadev
kernel: [ 247.867000] sir_dev: Unknown symbol irlap_open
kernel: [ 247.868000] sir_dev: Unknown symbol irda_qos_bits_to_value
kernel: [ 247.868000] sir_dev: Unknown symbol irda_debug
kernel: [ 247.868000] sir_dev: Unknown symbol async_unwrap_char
kernel: [ 247.868000] sir_dev: Unknown symbol irlap_close
kernel: [ 247.868000] sir_dev: Unknown symbol irda_device_set_media_busy
kernel: [ 247.868000] sir_dev: Unknown symbol async_wrap_skb
kernel: [ 247.868000] sir_dev: Unknown symbol irda_init_max_qos_capabilies
kernel: [ 247.870000] irtty_sir: Unknown symbol sirdev_set_dongle
kernel: [ 247.871000] irtty_sir: Unknown symbol irda_debug
kernel: [ 247.871000] irtty_sir: Unknown symbol sirdev_write_complete
kernel: [ 247.871000] irtty_sir: Unknown symbol sirdev_put_instance
kernel: [ 247.871000] irtty_sir: Unknown symbol sirdev_receive
kernel: [ 247.871000] irtty_sir: Unknown symbol sirdev_get_instance
kernel: [ 247.882000] PPP generic driver version 2.4.2
kernel: [ 247.900000] NET: Registered protocol family 23
kernel: [ 247.900000] sysctl table check failed: /net/irda .3.412 Unknown sysctl binary path
kernel: [ 247.900000] sysctl table check failed: /net/irda/discovery .3.412.1 Unknown sysctl binary path
kernel: [ 247.900000] sysctl table check failed: /net/irda/devname .3.412.2 Unknown sysctl binary path
kernel: [ 247.900000] sysctl table check failed: /net/irda/debug .3.412.3 Unknown sysctl binary path
kernel: [ 247.900000] sysctl table check failed: /net/irda/fast_poll_increase .3.412.4 Unknown sysctl binary path
kernel: [ 247.900000] sysctl table check failed: /net/irda/discovery_slots .3.412.5 Unknown sysctl binary path
kernel: [ 247.900000] sysctl table check failed: /net/irda/discovery_timeout .3.412.6 Unknown sysctl binary path
kernel: [ 247.900000] sysctl table check failed: /net/irda/slot_timeout .3.412.7 Unknown sysctl binary path
kernel: [ 247.900000] sysctl table check failed: /net/irda/max_baud_rate .3.412.8 Unknown sysctl binary path
kernel: [ 247.900000] sysctl table check failed: /net/irda/min_tx_turn_time .3.412.9 Unknown sysctl binary path
kernel: [ 247.900000] sysctl table check failed: /net/irda/max_tx_data_size .3.412.10 Unknown sysctl binary path
kernel: [ 247.900000] sysctl table check failed: /net/irda/max_tx_window .3.412.11 Unknown sysctl binary path
kernel: [ 247.900000] sysctl table check failed: /net/irda/max_noreply_time .3.412.12 Unknown sysctl binary path
kernel: [ 247.900000] sysctl table check failed: /net/irda/warn_noreply_time .3.412.13 Unknown sysctl binary path
kernel: [ 247.900000] sysctl table check failed: /net/irda/lap_keepalive_time .3.412.14 Unknown sysctl binary path
kernel: [ 247.911000] NET: Unregistered protocol family 23
kernel: [ 247.917000] irnet: Unknown symbol hashbin_insert
kernel: [ 247.917000] irnet: Unknown symbol irlmp_service_to_hint
kernel: [ 247.917000] irnet: Unknown symbol hashbin_remove_this
kernel: [ 247.917000] irnet: Unknown symbol irias_new_object
kernel: [ 247.917000] irnet: Unknown symbol irlmp_unregister_service
kernel: [ 247.918000] irnet: Unknown symbol irlmp_update_client
kernel: [ 247.918000] irnet: Unknown symbol irttp_open_tsap
kernel: [ 247.918000] irnet: Unknown symbol iriap_open
kernel: [ 247.918000] irnet: Unknown symbol irda_notify_init
kernel: [ 247.918000] irnet: Unknown symbol iriap_close
kernel: [ 247.918000] irnet: Unknown symbol hashbin_get_first
kernel: [ 247.919000] irnet: Unknown symbol irias_add_integer_attrib
kernel: [ 247.919000] irnet: Unknown symbol irttp_dup
kernel: [ 247.919000] irnet: Unknown symbol irttp_connect_response
kernel: [ 247.919000] irnet: Unknown symbol irlmp_register_service
kernel: [ 247.919000] irnet: Unknown symbol hashbin_get_next
kernel: [ 247.919000] irnet: Unknown symbol hashbin_delete
kernel: [ 247.920000] irnet: Unknown symbol hashbin_new
kernel: [ 247.920000] irnet: Unknown symbol irttp_disconnect_request
kernel: [ 247.920000] irnet: Unknown symbol hashbin_find
kernel: [ 247.920000] irnet: Unknown symbol irlmp_register_client
kernel: [ 247.920000] irnet: Unknown symbol iriap_getvaluebyclass_request
kernel: [ 247.920000] irnet: Unknown symbol irias_insert_object
kernel: [ 247.921000] irnet: Unknown symbol irias_delete_object
kernel: [ 247.921000] irnet: Unknown symbol irttp_data_request
kernel: [ 247.921000] irnet: Unknown symbol irttp_connect_request
kernel: [ 247.921000] irnet: Unknown symbol irttp_close_tsap
kernel: [ 247.921000] irnet: Unknown symbol proc_irda
kernel: [ 247.921000] irnet: Unknown symbol irlmp_unregister_client
kernel: [ 247.922000] irnet: Unknown symbol irias_delete_value
kernel: [ 247.922000] irnet: Unknown symbol irlmp_get_discoveries
irattach: tcgetattr: Input/output error
irattach: Stopping device /dev/ttyS2
kernel: [ 247.972000] NET: Registered protocol family 23
kernel: [ 247.972000] sysctl table check failed: /net/irda .3.412 Unknown sysctl binary path
kernel: [ 247.972000] sysctl table check failed: /net/irda/discovery .3.412.1 Unknown sysctl binary path
kernel: [ 247.973000] sysctl table check failed: /net/irda/devname .3.412.2 Unknown sysctl binary path
kernel: [ 247.973000] sysctl table check failed: /net/irda/debug .3.412.3 Unknown sysctl binary path
kernel: [ 247.973000] sysctl table check failed: /net/irda/fast_poll_increase .3.412.4 Unknown sysctl binary path
kernel: [ 247.973000] sysctl table check failed: /net/irda/discovery_slots .3.412.5 Unknown sysctl binary path
kernel: [ 247.973000] sysctl table check failed: /net/irda/discovery_timeout .3.412.6 Unknown sysctl binary path
kernel: [ 247.973000] sysctl table check failed: /net/irda/slot_timeout .3.412.7 Unknown sysctl binary path
kernel: [ 247.973000] sysctl table check failed: /net/irda/max_baud_rate .3.412.8 Unknown sysctl binary path
kernel: [ 247.974000] sysctl table check failed: /net/irda/min_tx_turn_time .3.412.9 Unknown sysctl binary path
kernel: [ 247.974000] sysctl table check failed: /net/irda/max_tx_data_size .3.412.10 Unknown sysctl binary path
kernel: [ 247.974000] sysctl table check failed: /net/irda/max_tx_window .3.412.11 Unknown sysctl binary path
kernel: [ 247.974000] sysctl table check failed: /net/irda/max_noreply_time .3.412.12 Unknown sysctl binary path
kernel: [ 247.974000] sysctl table check failed: /net/irda/warn_noreply_time .3.412.13 Unknown sysctl binary path
kernel: [ 247.974000] sysctl table check failed: /net/irda/lap_keepalive_time .3.412.14 Unknown sysctl binary path
kernel: [ 247.984000] NET: Unregistered protocol family 23
modprobe: FATAL: Error inserting irda (/lib/modules/2.6.23-rc3-mm1/kernel/net/irda/irda.ko): Cannot allocate memory
irattach: socket(AF_IRDA): Address family not supported by protocol
irattach: exiting ...

Attachments:

(No filename) (226.00 B)

2007-08-23 14:23:20

by Sam Ravnborg

[permalink] [raw]

Subject: Re: 2.6.23-rc3-mm1

On Thu, Aug 23, 2007 at 02:28:25PM +0200, Sam Ravnborg wrote:
>
> Something like this then:
> [PATCH] x86_64: fix preferred-stack-boundary check

OK - Andi decided to do this in a bit more invasive way but it looks OK.
So disregard my patch.

Sam

2007-08-23 16:26:08

by mel

[permalink] [raw]

Subject: Re: 2.6.23-rc3-mm1

On (23/08/07 14:07), Andi Kleen didst pronounce:
> On Wed, Aug 22, 2007 at 11:10:29AM -0700, Andrew Morton wrote:
> > x86_64-mm-less-stack-alignment.patch has
> >
> > cflags-y += $(call cc-option,-mpreferred-stack-boundary=3)
> >
> > So we _should_ have detected that gcc didn't like =3, so it
> > should not have been used.
>
> The flag actually needs a recent gcc 4.3 snapshot (it's
> a new feature the gcc developers added especially for the
> kernel :), so if this didn't work it would fail on the vast
> majority of systems.
>
> Somehow it doesn't? At least here it compiles fine.
>
> I notice the final comma is missing, Mel does it work
> when you change the line to
>
> cflags-y += $(call cc-option,-mpreferred-stack-boundary=3,)
>

No but that is hardly a suprise as it's looking like -m64 is the way
forward.

> If not please run
> gcc -O2 -mpreferred-stack-boundary=2 -S -xc /dev/null -o x.o
> echo $?
>
> What does the echo output?
>

Repeating really but;

elm3b6:~# gcc -O2 -mpreferred-stack-boundary=2 -S -xc /dev/null -o x.o ; echo $?
0
elm3b6:~# gcc -m64 -O2 -mpreferred-stack-boundary=2 -S -xc /dev/null -o x.o ; echo $?
/dev/null:1: error: -mpreferred-stack-boundary=2 is not between 4 and 12
1

--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab

2007-08-23 17:32:52

On Thu, 23 Aug 2007 21:53:53 MDT, Eric W. Biederman said:
>
> Grumble. These numbers should have been in sysctl.h from the
> beginning if we ever expected anyone to use them. Oh well put
> them there now so we can find them and make maintenance easier.
>
> Signed-off-by: Eric W. Biederman <[email protected]>

Applied both patches, and now all I get from irda at boot time now is this:

[ 292.062000] irda_init()
[ 292.063000] NET: Registered protocol family 23
[ 292.069000] IrCOMM protocol (Dag Brattli)
[ 292.221000] PPP generic driver version 2.4.2

in other words, business as usual. Thanks.

Feel free to stick this on both patches:

Tested-By: Valdis Kletnieks <[email protected]>

Attachments:

(No filename) (226.00 B)

2007-08-25 12:08:24

by Rusty Russell

[permalink] [raw]

Subject: Re: [-mm patch] enforce noreplace-smp in alternative_instructions()

On Fri, 2007-08-24 at 10:22 +0200, Frederik Deweerdt wrote:
> [Added Gerd Hoffman and Rusty Russel to cc]
> On Thu, Aug 23, 2007 at 11:46:52PM -0700, Jeremy Fitzhardinge wrote:
> > Frederik Deweerdt wrote:
> > > That means that even when you specify noreplace_smp, some replacing
> > > takes place anyway. One of the consequences, besides noreplace_smp not
> > > working as expected, is that lguest crashes when you feed it an SMP kernel
> > > (I suspect that you can not replace alternatives for smp _and_ paravirt).
> > >
> >
> > No, that should be fine. Why does lguest crash?
> It dies with:
> [ 0.131000] SMP alternatives: switching to UP code
> lguest: bad stack page 0xc057a000

How odd! This means that the guest set the kernel to a stack which it
hadn't mapped writable (or perhaps not mapped at all). I always run SMP
kernels, and that seems a very strange side effect of a patching
problem...

Nonetheless, I did have a previous problem with a bug in the patching
code which didn't show up native and did show up under lguest.

Can you send your config? Do you need noreplace-smp even on 2.6.23-rc3,
or only 2.6.23-rc3-mm1?

Thanks,
Rusty.

2007-08-25 12:28:00

by Frederik Deweerdt

[permalink] [raw]

Subject: Re: [-mm patch] enforce noreplace-smp in alternative_instructions()

On Sat, Aug 25, 2007 at 10:07:29PM +1000, Rusty Russell wrote:
> On Fri, 2007-08-24 at 10:22 +0200, Frederik Deweerdt wrote:
> > [Added Gerd Hoffman and Rusty Russel to cc]
> > On Thu, Aug 23, 2007 at 11:46:52PM -0700, Jeremy Fitzhardinge wrote:
> > > Frederik Deweerdt wrote:
> > > > That means that even when you specify noreplace_smp, some replacing
> > > > takes place anyway. One of the consequences, besides noreplace_smp not
> > > > working as expected, is that lguest crashes when you feed it an SMP kernel
> > > > (I suspect that you can not replace alternatives for smp _and_ paravirt).
> > > >
> > >
> > > No, that should be fine. Why does lguest crash?
> > It dies with:
> > [ 0.131000] SMP alternatives: switching to UP code
> > lguest: bad stack page 0xc057a000
Hello Rusty,
>
> How odd! This means that the guest set the kernel to a stack which it
> hadn't mapped writable (or perhaps not mapped at all). I always run SMP

I had time to investigate this a little further, it appears that in fact
0xc057a000 is the beginning of the __smp_locks section.

The crash responsible function call is in alternative_instructions():
free_init_pages("SMP alternatives",
(unsigned long)__smp_locks,
(unsigned long)__smp_locks_end);

Ie, if I comment this out, I can boot lguest without passing
noreplace_smp.

BTW, to make things clear: the patch I sent does _not_ fix the
lguest/alternatives problem. It just makes noreplace_smp functional
again and hence allows working around the lguest/alternatives bug.

> kernels, and that seems a very strange side effect of a patching
> problem...
>
> Nonetheless, I did have a previous problem with a bug in the patching
> code which didn't show up native and did show up under lguest.
>
> Can you send your config?
Here it is:
http://fdeweerdt.free.fr/lguest_smp/dot_config

> Do you need noreplace-smp even on 2.6.23-rc3,
> or only 2.6.23-rc3-mm1?
I'll try ASAP.

Thanks,
Frederik

2007-08-25 13:00:24

by Eric W. Biederman

[permalink] [raw]

Subject: Re: [PATCH 1/2] sysctl: Properly register the irda binary sysctl numbers.

[email protected] writes:

> On Thu, 23 Aug 2007 21:53:53 MDT, Eric W. Biederman said:
>>
>> Grumble. These numbers should have been in sysctl.h from the
>> beginning if we ever expected anyone to use them. Oh well put
>> them there now so we can find them and make maintenance easier.
>>
>> Signed-off-by: Eric W. Biederman <[email protected]>
>
> Applied both patches, and now all I get from irda at boot time now is this:
>
> [ 292.062000] irda_init()
> [ 292.063000] NET: Registered protocol family 23
> [ 292.069000] IrCOMM protocol (Dag Brattli)
> [ 292.221000] PPP generic driver version 2.4.2
>
> in other words, business as usual. Thanks.
>
> Feel free to stick this on both patches:
>
> Tested-By: Valdis Kletnieks <[email protected]>

Thanks.

It's good to have confirmation that my sysctl_check routine
didn't find something else wrong.

Eric

2007-08-25 14:08:12

Am 25.08.2007 02:21 schrieb john stultz:

>> Tilman Schmidt <[email protected]> wrote:

>>> - on console early during boot, also in SuSE's /var/log/boot.msg:
>>>
>>> your system time is not correct:
>>> Wed Jul 13 13:15:31 UTC 1910
>>> setting system time to:
>>> Tue Jul 24 00:00:00 UTC 2007
>
> Hrmm. I'm not super familiar w/ SuSE's init scripts, but I'm guessing
> that's the ntpdate call.

Nope. The ntpdate call comes much later, and finally sets the system clock
correctly so that there are no lasting effects of all this.

> And "Tuesday Jul 24th"? Sounds about a month
> off, is this just stale info?

I have no idea where that might come from.

>>> /dev/system/root: Superblock last mount time is in the future. FIXED.
>>> /dev/system/root: Superblock last write time is in the future. FIXED.
>
> Does this show up before or after the above date stuff?

After the "your system time is not correct" messages, and before the
regular "Try to get initial date and time via NTP" message accompanying
the ntpdate call.

> Does the issue go away using an older kernel (I want to eliminate easy
> stuff like CMOS batteries giving up)?

It does. Booting 2.6.23-rc3 after that, the system comes up with none
of these messages.

> Also you're not using Linus' CMOS corrupting suspend/resume debugging
> trick, right (I'm forgetting the CONFIG name).

PM_TRACE? No. The entire PM_DEBUG branch is turned off.

--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)

Attachments:

signature.asc (253.00 B)
OpenPGP digital signature

2007-08-25 23:26:32

by Tilman Schmidt

[permalink] [raw]

Subject: Re: 2.6.23-rc3-mm1

Am 25.08.2007 02:38 schrieb Pallipadi, Venkatesh:
>>
>>>> FATAL: Error inserting processor (/lib/modules/2.6.23-rc3-mm1-testing/kernel/drivers/acpi/processor.ko): Input/output error
>>>> WARNING: Error inserting processor (/lib/modules/2.6.23-rc3-mm1-testing/kernel/drivers/acpi/processor.ko): Input/output error
>
> This is indeed related to CPUIDLE.
>
> Tilman: Can you configure CONFIG_CPU_IDLE in your config (under Power
> Management option) and double check that the frequency part works after
> that.

Strangely enough, I do not see that option in "make xconfig".
The "Power Management" subtree ends with "CPU Frequency scaling".
In "make menuconfig" the option is there, though.
After activating it, these two errors are indeed gone, and the
"thermal: Unknown symbol acpi_processor_set_thermal_limit" one
as well.

HTH
T.

--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)

Attachments:

signature.asc (253.00 B)
OpenPGP digital signature

2007-08-25 23:36:55

[permalink] [raw]

Subject: Re: [PATCH 1/2] sysctl: Properly register the irda binary sysctl numbers.

On Sat, 25 Aug 2007 11:59:53 MDT, Eric W. Biederman said:

> It looks like you don't have CONFIG_SYSCTL_SYSCALL defined, and it
> appears utsname_syscall and ipcdata_syscall both become NULL pointers
> if they aren't needed. So the complaint is a false positive.

Yep. Nothing I actually use needs SYSCTL_SYSCALL, so I turned it off to
see what breaks...

Attachments:

(No filename) (226.00 B)

2007-08-28 18:44:46

On Wed, 22 Aug 2007 02:06:48 PDT, Andrew Morton said:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/

Sorry for not catching this one sooner, but AFAICT, Fedora didn't ship a glibc
that trips over this (2.6.90-12) until Saturday and I installed it yesterday.
-22-rc6-mm1 demonstrated the same issue as well.

The issue: vdso and gettimeofday seem to be having a quarrel.

At boot, the system clock is just fine. Right when it hits the 5-minute
uptime mark (and suspiciously close to the jiffie rollover), the date suddenly
shoots forward 4096 seconds.

Dumb test script:

#!/bin/bash
log="uptime.`uname -r`"
touch /root/$log
tail -f /root/$log &
while /bin/true;
do
uptime >> /root/$log
date >> /root/$log
sleep 1
done

Exerpt from runtime:

19:57:55 up 1 min, 0 users, load average: 0.09, 0.05, 0.01
Tue Aug 28 19:57:55 EDT 2007
19:57:56 up 1 min, 0 users, load average: 0.09, 0.05, 0.01
Tue Aug 28 19:57:56 EDT 2007
19:57:57 up 2 min, 0 users, load average: 0.08, 0.05, 0.01
Tue Aug 28 19:57:57 EDT 2007
19:57:58 up 2 min, 0 users, load average: 0.08, 0.05, 0.01
...
20:00:55 up 4 min, 0 users, load average: 0.01, 0.03, 0.00
Tue Aug 28 20:00:55 EDT 2007
20:00:56 up 4 min, 0 users, load average: 0.01, 0.03, 0.00
Tue Aug 28 20:00:56 EDT 2007
20:00:57 up 5 min, 0 users, load average: 0.01, 0.03, 0.00
Tue Aug 28 21:09:15 EDT 2007
20:00:58 up 5 min, 0 users, load average: 0.01, 0.03, 0.00
Tue Aug 28 21:09:16 EDT 2007
20:00:59 up 5 min, 0 users, load average: 0.01, 0.03, 0.00
Tue Aug 28 21:09:17 EDT 2007

uptime keeps reporting the right time, date goes flying ahead. Once we
get into this state, I can issue a 'date' command to set the *right* time,
and then it will immediately reset back. Doing a 'touch foo; ls -l foo'
shows the correct time.

Booting with vdso=0 makes the time/date run normally.

Ideas?

Attachments:

(No filename) (226.00 B)

2007-08-29 17:37:52

Am 25.08.2007 05:30 schrieb Andrew Morton:
> On Sat, 25 Aug 2007 02:47:59 +0200 Tilman Schmidt <[email protected]> wrote:

>>>> - on console early during boot, also in SuSE's /var/log/boot.msg:
>>>>
>>>> your system time is not correct:
>>>> Wed Jul 13 13:15:31 UTC 1910
>>>> setting system time to:
>>>> Tue Jul 24 00:00:00 UTC 2007

With 2.6.23-rc4-mm1 this doesn't happen anymore,
so whatever it was seems to be fixed.

>> --- /tmp/bootmsg-2.6.23-rc3 2007-08-25 02:25:54.000000000 +0200
>> +++ /tmp/bootmsg-2.6.23-rc3-mm1 2007-08-25 02:26:08.000000000 +0200
[...]
>> <6>..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
>> -<6>checking TSC synchronization [CPU#0 -> CPU#1]: passed.
>> +<6>checking TSC synchronization [CPU#0 -> CPU#1]:
>> +<4>Measured 32 cycles TSC warp between CPUs, turning off TSC clock.
>> +<4>Marking TSC unstable due to: check_tsc_sync_source failed.

This still happens identically with 2.6.23-rc4-mm1.
Mainline kernels like my TSC, -mm kernels don't.

>> -<7>hpet_resources: 0xfed00000 is busy
>> +<4>hpet_acpi_add: no address or irqs in _CRS
>
> oh boy

2.6.23-rc4-mm1 reverts to mainline behaviour here.
(ie. "busy" instead of "no address or irqs")
Dunno if that's good or bad.

>> +<4>thermal: Unknown symbol acpi_processor_set_thermal_limit
>
> I think there are acpi fixes in Len's latest tree which will fix this.

Gone in 2.6.23-rc4-mm1.

HTH
Tilman

--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)

Attachments:

signature.asc (253.00 B)
OpenPGP digital signature

2007-09-07 19:39:42

by Chuck Ebbert

[permalink] [raw]

Subject: Re: 2.6.23-rc3-mm1 - vdso and gettimeofday issues with glibc

On 09/01/2007 06:07 AM, Andi Kleen wrote:
>> write_seqlock_irqsave(&vsyscall_gtod_data.lock, flags);
>> /* copy vsyscall data */
>> vsyscall_gtod_data.clock.vread = clock->vread;
>> vsyscall_gtod_data.clock.cycle_last = clock->cycle_last;
>> vsyscall_gtod_data.clock.mask = clock->mask;
>> vsyscall_gtod_data.clock.mult = clock->mult;
>> vsyscall_gtod_data.clock.shift = clock->shift;
>> vsyscall_gtod_data.wall_time_sec = wall_time->tv_sec;
>> vsyscall_gtod_data.wall_time_nsec = wall_time->tv_nsec; <===
>> vsyscall_gtod_data.sys_tz = sys_tz;
>> vsyscall_gtod_data.wall_time_nsec = wall_time->tv_nsec; <===
>
> Must have been a (harmless) merging mistake, but I bet gcc optimizes it out
> anyways.
>

I did find this after some digging:

In the vdso code:

static inline long vgetns(void)
{
cycles_t (*vread)(void);
vread = gtod->clock.vread;
return ((vread() - gtod->clock.cycle_last) * gtod->clock.mult) >>
gtod->clock.shift;
}

Looks like an open-coded version of this in the kernel timekeeping code:

static inline s64 __get_nsec_offset(void)
{
cycle_t cycle_now, cycle_delta;
s64 ns_offset;

/* read clocksource: */
cycle_now = clocksource_read(clock);

/* calculate the delta since the last update_wall_time: */
cycle_delta = (cycle_now - clock->cycle_last) & clock->mask;

/* convert to nanoseconds: */
ns_offset = cyc2ns(clock, cycle_delta);

return ns_offset;
}

But the vdso version isn't doing any masking. And the mask is different for
different clocksources, so it has to track the underlying kernel's clocksource
when it gets changed.

2007-09-08 08:58:09

by Andi Kleen

[permalink] [raw]

Subject: Re: 2.6.23-rc3-mm1 - vdso and gettimeofday issues with glibc

> In the vdso code:
>
> static inline long vgetns(void)
> {
> cycles_t (*vread)(void);
> vread = gtod->clock.vread;
> return ((vread() - gtod->clock.cycle_last) * gtod->clock.mult) >>
> gtod->clock.shift;
> }
>
>
> Looks like an open-coded version of this in the kernel timekeeping code:

vdso code needs to be all inlined because the vdso runs in ring 3 and cannot
access other kernel code.

It was opencoded it to have more control over the code (vdso requirements
are a bit peculiar).

> But the vdso version isn't doing any masking. And the mask is different for
> different clocksources, so it has to track the underlying kernel's clocksource
> when it gets changed.

vdso effectively only supports TSC and HPET (the other clock sources are not accessible
from ring 3)

TSC doesn't need a mask, but many HPETs need a 32bit mask; good point.

Does adding the mask to vgetns make the clock problems go away?

-Andi

2007-09-09 00:24:26

by Valdis Klētnieks

[permalink] [raw]

Subject: Re: 2.6.23-rc3-mm1 - vdso and gettimeofday issues with glibc

On Thu, 30 Aug 2007 12:27:10 EDT, Chuck Ebbert said:
> On 08/29/2007 07:15 PM, Andrew Morton wrote:
> >>> The issue: vdso and gettimeofday seem to be having a quarrel.
> >> This is also open as a Fedora bug:
> >> https://bugzilla.redhat.com/show_bug.cgi?id=262481
> >>
> >
> > So it's an interaction between the x86_64 vdso patches in Andi's tree and
> > newer glibc, and we don't know which one is getting it wrong yet?
> >
> > If I ever get another -mm out the door (have been without electricity for
> > several days) I'll drop the vdso changes until this is sorted out.
> > -
>
> Problem is present in stock 2.6.23-rc too. Still don't know whether it is
> the new glibc code or the vdso that's causing it, though.

Updating on this issue: Both myself and another person have reported on
the RedHat bugzilla that it's a clocksource issue - if you are using the
hpet clocksource, the time warps, but booting with clocksource=acpi_pm works.

This ring any bells?

Attachments:

(No filename) (226.00 B)

2007-09-09 03:21:18

On Sun, 09 Sep 2007 09:27:06 +0200, Andi Kleen said:
> > Updating on this issue: Both myself and another person have reported on
> > the RedHat bugzilla that it's a clocksource issue - if you are using the
> > hpet clocksource, the time warps, but booting with clocksource=acpi_pm works.
> >
> > This ring any bells?
>
> Does this patch fix it?
> -Andi
>
> Add missing mask operation to vdso
>
> vdso vgetns() didn't mask the time source offset calculation, which could
> lead to time problems with 32bit HPET. Add the masking.
>
> Thanks to Chuck Ebbert for tracking down.
>
> Signed-off-by: Andi Kleen <[email protected]>

Confirming that does indeed fix it - booted with hpet clocksource and vdso=1,
and the time didn't warp at the 5-minute mark.

Tested-By: Valdis Kletnieks <[email protected]>

Attachments:

(No filename) (226.00 B)

2007-09-11 15:18:18

by Dave Airlie

[permalink] [raw]

Subject: Re: X freezes kernel during exit [Re: 2.6.23-rc3-mm1]

>
> What other info needed?

I'm seeing this on my 965gm chipset with Andi's clflush patches on x86
32-bit, it looks like an interaction with the agp code which does a big
bunch of change page attr to allocate the AGP aperture backed memory..

I think the code might have worked in a previous iteration on my 64-bit
965G machine at home but I'm on the road and won't be back anytime soon..

I'll see what I can figure out from my laptop...

Dave.

2007-09-17 11:09:36

by Jiri Slaby

[permalink] [raw]

Subject: Re: X freezes kernel during exit [Re: 2.6.23-rc3-mm1]

On 09/09/2007 04:43 PM, Jiri Slaby wrote:
> On 09/09/2007 04:33 PM, Andi Kleen wrote:
>> On Sun, Sep 09, 2007 at 04:26:22PM +0200, Jiri Slaby wrote:
>>> BTW it is reproducible for me on two different machines (i386-x86_64,
>>> radeon-intel), don't you have the problem too?
>> No problems here with a radeon, no.
>>
>> Does your CPU have clflush or not in /proc/cpuinfo?
>
> BTW this is how my flush_kernel_map looks like:
>
> static void flush_kernel_map(void *arg)
> {
> struct flush_arg *a = (struct flush_arg *)arg;
> struct page *pg;
> unsigned int xx = 0;
>
> /* When clflush is available use it because it is
> much cheaper than WBINVD. */
> printk("%s: 1\n", __func__);
> if (a->full_flush || !cpu_has_clflush)
> asm volatile("wbinvd" ::: "memory");
> else list_for_each_entry(pg, &a->l, lru) {
> printk("%s: %10u 1a\n", __func__, xx++);
> if (PageFlush(pg))
> clflush_cache_range(page_address(pg), PAGE_SIZE);
> }
> printk("%s: 2\n", __func__);
> __flush_tlb_all();
> printk("%s: 3\n", __func__);
> }
>
> It outputs 1a in the infinite loop with incrementing xx. But only in this case,
> some global_flush_tlb are OK. e.g.:
> Sep 10 01:39:19 localhost kernel: agpgart: Detected an Intel G33 Chipset.
> Sep 10 01:39:19 localhost kernel: global_flush_tlb: 1
> Sep 10 01:39:19 localhost kernel: flush_kernel_map: 1
> Sep 10 01:39:19 localhost kernel: flush_kernel_map: 0 1a
> Sep 10 01:39:19 localhost kernel: flush_kernel_map: 1 1a
> Sep 10 01:39:19 localhost kernel: flush_kernel_map: 2
> Sep 10 01:39:19 localhost kernel: flush_kernel_map: 3
> Sep 10 01:39:19 localhost kernel: flush_kernel_map: 1
> Sep 10 01:39:19 localhost kernel: flush_kernel_map: 0 1a
> Sep 10 01:39:19 localhost kernel: flush_kernel_map: 1 1a
> Sep 10 01:39:19 localhost kernel: flush_kernel_map: 2
> Sep 10 01:39:19 localhost kernel: flush_kernel_map: 3
> Sep 10 01:39:19 localhost kernel: global_flush_tlb: 2
> Sep 10 01:39:19 localhost kernel: global_flush_tlb: 3
> Sep 10 01:39:19 localhost kernel: agpgart: Detected 6140K stolen memory.
>
> It seems, that the list is broken only on X shutdown. How can be deferred-pages
> list inited in some bad manner, when list_replace_init is called on it? Weird.

Ok, here comes a BUG with trace:
set status page addr 0x00033000
list_add corruption. next->prev should be prev (ffffffff8068ae70), but was
ffffffff80697a50. (next=ffff81000117fbd0).
------------[ cut here ]------------
kernel BUG at /home/l/latest/xxx/lib/list_debug.c:27!
invalid opcode: 0000 [1] SMP
last sysfs file: /devices/pci0000:00/0000:00:02.0/enable
CPU 0
Modules linked in: ipv6 floppy sr_mod rtc_cmos rtc_core cdrom ehci_hcd rtc_lib
usbhid
Pid: 1639, comm: X Not tainted 2.6.23-rc4-mm1_64 #23
RIP: 0010:[<ffffffff80332f49>] [<ffffffff80332f49>] __list_add+0x39/0x60
RSP: 0018:ffff81000547bd48 EFLAGS: 00010296
RAX: 0000000000000079 RBX: ffff81000117a380 RCX: ffffffff8068b450
RDX: ffff81000317d6a0 RSI: 0000000000000001 RDI: ffffffff8068b420
RBP: ffff81000547bd48 R08: 0000000000000000 R09: 0000000000000001
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000006da2
R13: ffff810006c10d10 R14: ffff810006da2000 R15: 8000000000000163
FS: 00007f7a05258710(0000) GS:ffffffff806d1000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000a33040 CR3: 0000000004a43000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process X (pid: 1639, threadinfo ffff81000547a000, task ffff81000317d6a0)
Stack: ffff81000547bd58 ffffffff80332f7c ffff81000547bdc8 ffffffff80225c56
ffffffff80225cb5 8000000000000163 ffffffff806830e8 ffffffff806830a0
ffffffff806830a0 ffff810006da2000 ffff81000547bda8 0000000000006da2
Call Trace:
[<ffffffff80332f7c>] list_add+0xc/0x10
[<ffffffff80225c56>] __change_page_attr+0x376/0x390
[<ffffffff80225cb5>] change_page_attr_addr+0x45/0x140
[<ffffffff80225d16>] change_page_attr_addr+0xa6/0x140
[<ffffffff80225de3>] change_page_attr+0x33/0x40
[<ffffffff80387b64>] agp_generic_destroy_page+0x44/0x70
[<ffffffff80388645>] agp_free_memory+0x65/0xd0
[<ffffffff80386d49>] agp_free_memory_wrap+0x39/0x60
[<ffffffff803873fb>] agp_release+0xdb/0x1c0
[<ffffffff80299551>] __fput+0xd1/0x1b0
[<ffffffff802996b6>] fput+0x16/0x20
[<ffffffff802964e6>] filp_close+0x56/0x90
[<ffffffff80297bed>] sys_close+0xad/0x110
[<ffffffff8020bd0e>] system_call+0x7e/0x83

INFO: lockdep is turned off.

Code: 0f 0b eb fe 0f 1f 00 48 89 f1 4c 89 c2 48 89 c6 48 c7 c7 e8
RIP [<ffffffff80332f49>] __list_add+0x39/0x60
RSP <ffff81000547bd48>

regards,
--
Jiri Slaby ([email protected])
Faculty of Informatics, Masaryk University