* per-cpu related?
@ 2008-07-13 8:16 Yinghai Lu
2008-07-13 9:26 ` Ingo Molnar
2008-07-13 11:55 ` Vegard Nossum
0 siblings, 2 replies; 9+ messages in thread
From: Yinghai Lu @ 2008-07-13 8:16 UTC (permalink / raw)
To: Ingo Molnar, LKML, Mike Travis
calling pcie_portdrv_init+0x0/0x77
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
IP: [<ffffffff802557de>] hrtick_start_fair+0x8e/0x178
PGD 0
Oops: 0000 [1] SMP
CPU 4
Modules linked in:
Pid: 103, comm: events/4 Not tainted 2.6.26-rc9-tip-01834-g99e624f-dirty #354
RIP: 0010:[<ffffffff802557de>] [<ffffffff802557de>]
hrtick_start_fair+0x8e/0x178
RSP: 0018:ffff88082486dbd0 EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff880824870000 RCX: 0000000000000006
RDX: ffff88084423e700 RSI: ffff880824870000 RDI: ffff88084423e700
RBP: ffff88082486dc00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff88084423e700
R13: ffff880844239700 R14: ffff880824870000 R15: 0000000000000c18
FS: 0000000000000000(0000) GS:ffff881024c3a600(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000000201000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process events/4 (pid: 103, threadinfo ffff88082486c000, task ffff880824864230)
Stack: ffff880844248118 0000000060ce4c84 ffff880844239700 ffff880824955878
ffff88084423e700 0000000000000000 ffff88082486dc40 ffffffff80258339
ffff88082486dc30 ffffffff805196dd 0000000060ce4c84 ffff880824955840
Call Trace:
[<ffffffff80258339>] dequeue_task_fair+0x64/0x83
[<ffffffff805196dd>] ? __first_cpu+0x26/0x49
[<ffffffff80254387>] dequeue_task+0xd3/0xf5
[<ffffffff80254434>] deactivate_task+0x36/0x55
[<ffffffff802547b0>] pull_task+0x31/0x7d
[<ffffffff8025691b>] load_balance_fair+0x192/0x27c
[<ffffffff80a4daf3>] schedule+0x3e0/0x96d
[<ffffffff802c3303>] ? vmstat_update+0x0/0x5e
[<ffffffff8027a965>] ? schedule_delayed_work+0x31/0x48
[<ffffffff80279b8a>] worker_thread+0xbb/0x114
[<ffffffff8027e788>] ? autoremove_wake_function+0x0/0x63
[<ffffffff80279acf>] ? worker_thread+0x0/0x114
[<ffffffff8027e2e3>] kthread+0x61/0xa4
[<ffffffff802634ee>] ? schedule_tail+0x3b/0x8a
[<ffffffff8022b589>] child_rip+0xa/0x11
[<ffffffff8027e282>] ? kthread+0x0/0xa4
[<ffffffff8022b57f>] ? child_rip+0x0/0x11
Code: c3 80 e8 38 09 01 00 80 3d 3f 86 c0 00 00 0f 89 e1 00 00 00 41
f6 84 24 70 08 00 00 04 0f 85 d2 00 00 00 49 8b 84 24 a8 08 00 00 <48>
8b 00 83 b8 c0 00 00 00 00 0f 84 ba 00 00 00 49 83 7d 10 01
RIP [<ffffffff802557de>] hrtick_start_fair+0x8e/0x178
RSP <ffff88082486dbd0>
CR2: 0000000000000000
---[ end trace 52609fe2a2756609 ]---
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: per-cpu related?
2008-07-13 8:16 per-cpu related? Yinghai Lu
@ 2008-07-13 9:26 ` Ingo Molnar
2008-07-13 10:46 ` Vegard Nossum
2008-07-13 11:55 ` Vegard Nossum
1 sibling, 1 reply; 9+ messages in thread
From: Ingo Molnar @ 2008-07-13 9:26 UTC (permalink / raw)
To: Yinghai Lu; +Cc: LKML, Mike Travis
* Yinghai Lu <yhlu.kernel@gmail.com> wrote:
> calling pcie_portdrv_init+0x0/0x77
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
> IP: [<ffffffff802557de>] hrtick_start_fair+0x8e/0x178
> PGD 0
> Oops: 0000 [1] SMP
> CPU 4
> Modules linked in:
> Pid: 103, comm: events/4 Not tainted 2.6.26-rc9-tip-01834-g99e624f-dirty #354
> RIP: 0010:[<ffffffff802557de>] [<ffffffff802557de>]
> hrtick_start_fair+0x8e/0x178
> RSP: 0018:ffff88082486dbd0 EFLAGS: 00010046
> RAX: 0000000000000000 RBX: ffff880824870000 RCX: 0000000000000006
> RDX: ffff88084423e700 RSI: ffff880824870000 RDI: ffff88084423e700
> RBP: ffff88082486dc00 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: ffff88084423e700
> R13: ffff880844239700 R14: ffff880824870000 R15: 0000000000000c18
> FS: 0000000000000000(0000) GS:ffff881024c3a600(0000) knlGS:0000000000000000
> CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> CR2: 0000000000000000 CR3: 0000000000201000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process events/4 (pid: 103, threadinfo ffff88082486c000, task ffff880824864230)
> Stack: ffff880844248118 0000000060ce4c84 ffff880844239700 ffff880824955878
> ffff88084423e700 0000000000000000 ffff88082486dc40 ffffffff80258339
> ffff88082486dc30 ffffffff805196dd 0000000060ce4c84 ffff880824955840
> Call Trace:
> [<ffffffff80258339>] dequeue_task_fair+0x64/0x83
> [<ffffffff805196dd>] ? __first_cpu+0x26/0x49
> [<ffffffff80254387>] dequeue_task+0xd3/0xf5
> [<ffffffff80254434>] deactivate_task+0x36/0x55
> [<ffffffff802547b0>] pull_task+0x31/0x7d
> [<ffffffff8025691b>] load_balance_fair+0x192/0x27c
> [<ffffffff80a4daf3>] schedule+0x3e0/0x96d
> [<ffffffff802c3303>] ? vmstat_update+0x0/0x5e
> [<ffffffff8027a965>] ? schedule_delayed_work+0x31/0x48
> [<ffffffff80279b8a>] worker_thread+0xbb/0x114
> [<ffffffff8027e788>] ? autoremove_wake_function+0x0/0x63
> [<ffffffff80279acf>] ? worker_thread+0x0/0x114
> [<ffffffff8027e2e3>] kthread+0x61/0xa4
> [<ffffffff802634ee>] ? schedule_tail+0x3b/0x8a
> [<ffffffff8022b589>] child_rip+0xa/0x11
> [<ffffffff8027e282>] ? kthread+0x0/0xa4
i've triggered a similar crash yesterday - see it below.
Ingo
[ 9.230000] initcall ahci_init+0x0/0x47 returned 0 after 0 msecs
[ 9.240000] calling piix_init+0x0/0x55
[ 9.240000] ata_piix 0000:00:1f.1: version 2.12
[ 9.240000] IOAPIC[0]: Set routing entry (2-18 -> 0x59 -> IRQ 18 Mode:1 Active:1)
[ 9.250000] ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 18
[ 9.260000] PCI: Setting latency timer of device 0000:00:1f.1 to 64
[ 9.270000] BUG: unable to handle kernel paging request at ffff88080101c1f8
[ 9.270000] IP: [<ffffffff80230576>] dequeue_task+0x73/0xf0
[ 9.270000] PGD 202063 PUD 0
[ 9.270000] Thread overran stack, or stack corrupted
[ 9.270000] Oops: 0000 [1] SMP
[ 9.270000] CPU 0
[ 9.270000] Modules linked in:
[ 9.270000] Pid: 1, comm: swapper Tainted: G M 2.6.26-rc9-01344-gfa93e3e-dirty #13956
[ 9.270000] RIP: 0010:[<ffffffff80230576>] [<ffffffff80230576>] dequeue_task+0x73/0xf0
[ 9.270000] RSP: 0018:ffff88003f9b7420 EFLAGS: 00010046
[ 9.270000] RAX: ffff88000101c200 RBX: ffff88003f9b4000 RCX: ffffffff80db5d40
[ 9.270000] RDX: 00000000ffffffff RSI: ffff88003f9b6000 RDI: ffff880001026d40
[ 9.270000] RBP: ffff88003f9b7440 R08: 0000000000000000 R09: 0000000000000001
[ 9.270000] R10: 00000000ffff8e6e R11: 0000000000000000 R12: 0000000000000000
[ 9.270000] R13: ffff880001026d40 R14: 0000000000000002 R15: ffff88003f9b76c0
[ 9.270000] FS: 0000000000000000(0000) GS:ffffffff80c56640(0000) knlGS:0000000000000000
[ 9.270000] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
[ 9.270000] CR2: ffff88080101c1f8 CR3: 0000000000201000 CR4: 00000000000006e0
[ 9.270000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 9.270000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 9.270000] Process swapper (pid: 1, threadinfo ffff88003f9b6000, task ffff88003f9b4000)
[ 9.270000] Stack: 0000000076a041aa 0000000000000046 0000000076a041aa ffff880001026d40
[ 9.270000] ffff88003f9b7470 ffffffff80230674 0000000000000000 ffffffff8088c020
[ 9.270000] 0000000076a041aa 7fffffffffffffff ffff88003f9b7570 ffffffff80889898
[ 9.270000] Call Trace:
[ 9.270000] [<ffffffff80230674>] deactivate_task+0x31/0x50
[ 9.270000] [<ffffffff8088c020>] ? _spin_lock+0xd/0x4c
[ 9.270000] [<ffffffff80889898>] schedule+0x20a/0x6af
[ 9.270000] [<ffffffff80233d68>] ? __enqueue_entity+0x9d/0xb3
[ 9.270000] [<ffffffff80233f43>] ? enqueue_entity+0x1c5/0x1e6
[ 9.270000] [<ffffffff8088a2bf>] schedule_timeout+0x36/0xf7
[ 9.270000] [<ffffffff8088a02e>] wait_for_common+0xee/0x17a
[ 9.270000] [<ffffffff802398fe>] ? default_wake_function+0x0/0x36
[ 9.270000] [<ffffffff8088a1f3>] wait_for_completion+0x2b/0x41
[ 9.270000] [<ffffffff80259c92>] kthread_create+0xc7/0x14d
[ 9.270000] [<ffffffff805f5798>] ? scsi_error_handler+0x0/0x552
[ 9.270000] [<ffffffff80425490>] ? snprintf+0x70/0x89
[ 9.270000] [<ffffffff80420998>] ? kref_init+0xd/0x3b
[ 9.270000] [<ffffffff8041f676>] ? kobject_init+0x5b/0xb1
[ 9.270000] [<ffffffff80856245>] ? klist_init+0xd/0x4c
[ 9.270000] [<ffffffff804a760d>] ? device_initialize+0x57/0xf5
[ 9.270000] [<ffffffff8025c791>] ? __mutex_init+0xd/0x4b
[ 9.270000] [<ffffffff805f20c7>] scsi_host_alloc+0x2e6/0x343
[ 9.270000] [<ffffffff80666dcf>] ata_scsi_add_hosts+0x4e/0x130
[ 9.270000] [<ffffffff80663eba>] ata_host_register+0xb0/0x296
[ 9.270000] [<ffffffff804acf4a>] ? devres_open_group+0xb1/0xd5
[ 9.270000] [<ffffffff8066bc36>] ata_pci_sff_activate_host+0x1af/0x1f0
[ 9.270000] [<ffffffff8066dfc2>] ? ata_sff_interrupt+0x0/0x26a
[ 9.270000] [<ffffffff808790ab>] piix_init_one+0x69e/0x6cb
[ 9.270000] [<ffffffff80438790>] pci_call_probe+0x92/0xdf
[ 9.270000] [<ffffffff8043894a>] pci_device_probe+0x69/0xa9
[ 9.270000] [<ffffffff804aa7be>] driver_probe_device+0xb3/0x178
[ 9.270000] [<ffffffff8025df56>] ? down+0x4b/0x68
[ 9.270000] [<ffffffff804aa8e6>] __driver_attach+0x63/0xa4
[ 9.270000] [<ffffffff804aa883>] ? __driver_attach+0x0/0xa4
[ 9.270000] [<ffffffff804a9de4>] bus_for_each_dev+0x63/0xb1
[ 9.270000] [<ffffffff804aa5a9>] driver_attach+0x34/0x4a
[ 9.270000] [<ffffffff804a9594>] bus_add_driver+0xcc/0x22c
[ 9.270000] [<ffffffff8041f9e0>] ? kset_find_obj+0x4c/0x97
[ 9.270000] [<ffffffff804aac0a>] driver_register+0xbc/0x153
[ 9.270000] [<ffffffff80438c41>] __pci_register_driver+0x67/0xb6
[ 9.270000] [<ffffffff80ccf3f6>] ? piix_init+0x0/0x55
[ 9.270000] [<ffffffff80ccf427>] piix_init+0x31/0x55
[ 9.270000] [<ffffffff80ca296d>] kernel_init+0x1c6/0x333
[ 9.270000] [<ffffffff8023cb86>] ? finish_task_switch+0x41/0xe0
[ 9.270000] [<ffffffff8020d4d9>] child_rip+0xa/0x11
[ 9.270000] [<ffffffff8020cb7c>] ? restore_args+0x0/0x30
[ 9.270000] [<ffffffff80ca27a7>] ? kernel_init+0x0/0x333
[ 9.270000] [<ffffffff8020d4cf>] ? child_rip+0x0/0x11
[ 9.270000]
[ 9.270000]
[ 9.270000] Code: 29 c8 48 29 d0 48 c1 f8 03 48 01 d0 48 89 86 a0 00 00 00 48 8b 73 08 48 8b 05 9f 66 a2 00 48 c7 c1 40 5d db 80 45 31 c0 8b 56 1c <48> 8b 04 d0 48 8b 93 10 04 00 00 48 8b 40 08 48 8b 84 01 10 08
[ 9.270000] RIP [<ffffffff80230576>] dequeue_task+0x73/0xf0
[ 9.270000] RSP <ffff88003f9b7420>
[ 9.270000] CR2: ffff88080101c1f8
[ 9.270000] Kernel panic - not syncing: Fatal exception
Press any key to enter the menu
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: per-cpu related?
2008-07-13 9:26 ` Ingo Molnar
@ 2008-07-13 10:46 ` Vegard Nossum
0 siblings, 0 replies; 9+ messages in thread
From: Vegard Nossum @ 2008-07-13 10:46 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Yinghai Lu, LKML, Mike Travis
On Sun, Jul 13, 2008 at 11:26 AM, Ingo Molnar <mingo@elte.hu> wrote:
> [ 9.270000] BUG: unable to handle kernel paging request at ffff88080101c1f8
> [ 9.270000] IP: [<ffffffff80230576>] dequeue_task+0x73/0xf0
[...]
> [ 9.270000] RIP: 0010:[<ffffffff80230576>] [<ffffffff80230576>] dequeue_task+0x73/0xf0
> [ 9.270000] RSP: 0018:ffff88003f9b7420 EFLAGS: 00010046
> [ 9.270000] RAX: ffff88000101c200 RBX: ffff88003f9b4000 RCX: ffffffff80db5d40
> [ 9.270000] RDX: 00000000ffffffff RSI: ffff88003f9b6000 RDI: ffff880001026d40
I don't think this is per-cpu related.
It seems that task_thread_info(p)->cpu returns -1. This is the number
that is loaded into %rdx:
mov 0x1c(%rsi),%edx
mov (%rax,%rdx,8),%rax <-- faulting instruction
You also had this:
[ 9.270000] Thread overran stack, or stack corrupted
so it seems likely that your thread_info was corrupted as well.
Vegard
--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: per-cpu related?
2008-07-13 8:16 per-cpu related? Yinghai Lu
2008-07-13 9:26 ` Ingo Molnar
@ 2008-07-13 11:55 ` Vegard Nossum
2008-07-13 18:34 ` Yinghai Lu
1 sibling, 1 reply; 9+ messages in thread
From: Vegard Nossum @ 2008-07-13 11:55 UTC (permalink / raw)
To: Yinghai Lu
Cc: Ingo Molnar, LKML, Mike Travis, Thomas Gleixner, Steven Rostedt
Hi,
On Sun, Jul 13, 2008 at 10:16 AM, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
> calling pcie_portdrv_init+0x0/0x77
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
> IP: [<ffffffff802557de>] hrtick_start_fair+0x8e/0x178
> PGD 0
> Oops: 0000 [1] SMP
> CPU 4
> Modules linked in:
> Pid: 103, comm: events/4 Not tainted 2.6.26-rc9-tip-01834-g99e624f-dirty #354
> RIP: 0010:[<ffffffff802557de>] [<ffffffff802557de>]
> hrtick_start_fair+0x8e/0x178
I find that this corresponds to timer->base being NULL:
static inline int hrtimer_is_hres_active(struct hrtimer *timer)
{
return timer->base->cpu_base->hres_active;
}
Apparently timer->base can legitimately be NULL in some cases:
/*
* [...]
* When the timer's base is locked, and the timer removed from list, it is
* possible to set timer->base = NULL and drop the lock: the timer remains
* locked.
*/
I don't know any more than this yet, I hope I didn't waste your time.
Vegard
--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: per-cpu related?
2008-07-13 11:55 ` Vegard Nossum
@ 2008-07-13 18:34 ` Yinghai Lu
2008-07-13 18:55 ` Ingo Molnar
0 siblings, 1 reply; 9+ messages in thread
From: Yinghai Lu @ 2008-07-13 18:34 UTC (permalink / raw)
To: Vegard Nossum
Cc: Ingo Molnar, LKML, Mike Travis, Thomas Gleixner, Steven Rostedt
On Sun, Jul 13, 2008 at 4:55 AM, Vegard Nossum <vegard.nossum@gmail.com> wrote:
> Hi,
>
> On Sun, Jul 13, 2008 at 10:16 AM, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
>> calling pcie_portdrv_init+0x0/0x77
>> BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
>> IP: [<ffffffff802557de>] hrtick_start_fair+0x8e/0x178
>> PGD 0
>> Oops: 0000 [1] SMP
>> CPU 4
>> Modules linked in:
>> Pid: 103, comm: events/4 Not tainted 2.6.26-rc9-tip-01834-g99e624f-dirty #354
>> RIP: 0010:[<ffffffff802557de>] [<ffffffff802557de>]
>> hrtick_start_fair+0x8e/0x178
>
> I find that this corresponds to timer->base being NULL:
>
> static inline int hrtimer_is_hres_active(struct hrtimer *timer)
> {
> return timer->base->cpu_base->hres_active;
> }
>
> Apparently timer->base can legitimately be NULL in some cases:
thanks
could be caused by max_low_pfn_mapped patch...because hpet still use
fixmap address that is cleared by others.
will check that.
YH
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: per-cpu related?
2008-07-13 18:34 ` Yinghai Lu
@ 2008-07-13 18:55 ` Ingo Molnar
2008-07-13 21:01 ` Yinghai Lu
0 siblings, 1 reply; 9+ messages in thread
From: Ingo Molnar @ 2008-07-13 18:55 UTC (permalink / raw)
To: Yinghai Lu
Cc: Vegard Nossum, LKML, Mike Travis, Thomas Gleixner, Steven Rostedt
* Yinghai Lu <yhlu.kernel@gmail.com> wrote:
> thanks
>
> could be caused by max_low_pfn_mapped patch...because hpet still use
> fixmap address that is cleared by others.
>
> will check that.
got another weird crash:
[ 12.431572] device: 'sda1': device_add
[ 12.435498] PM: Adding info for No Bus:sda1
[ 12.439795] device: 'sda2': device_add
[ 12.443606] PM: Adding info for No Bus:sda2
[ 12.447945] ------------[ cut here ]------------
[ 12.452585] WARNING: at kernel/mutex.c:134 mutex_lock_nested+0x327/0x350()
[ 12.459481] Modules linked in:
[ 12.462597] Pid: 1, comm: swapper Not tainted 2.6.26-rc9-tip #14453
[ 12.468884]
[ 12.468885] Call Trace:
[ 12.472882] [<ffffffff802522b3>] warn_on_slowpath+0x73/0xc0
[ 12.478565] [<ffffffff80280520>] ? trace_hardirqs_on+0x20/0x40
[ 12.484509] [<ffffffff804505d8>] ? debug_locks_off+0x8/0x70
[ 12.490190] [<ffffffff802acb03>] ? ftrace_record_ip+0x193/0x2b0
[ 12.496220] [<ffffffff80280520>] ? trace_hardirqs_on+0x20/0x40
[ 12.502159] [<ffffffff8020c9f4>] ? mcount_call+0x5/0x31
[ 12.507494] [<ffffffff8069b7fd>] ? scsi_disk_put+0x3d/0x80
[ 12.513089] [<ffffffff808a55f7>] mutex_lock_nested+0x327/0x350
[ 12.519030] [<ffffffff8069b7fd>] ? scsi_disk_put+0x3d/0x80
[ 12.524624] [<ffffffff8069b7fd>] scsi_disk_put+0x3d/0x80
[ 12.530044] [<ffffffff8069c5db>] sd_release+0x5b/0xa0
[ 12.535207] [<ffffffff8032e708>] __blkdev_put+0x1d8/0x200
[ 12.540713] [<ffffffff8020c9f4>] ? mcount_call+0x5/0x31
[ 12.546047] [<ffffffff8032e753>] blkdev_put+0x23/0x40
[ 12.551209] [<ffffffff803576c5>] register_disk+0x1a5/0x1c0
[ 12.556806] [<ffffffff80441c2a>] add_disk+0x5a/0xc0
[ 12.561794] [<ffffffff8069c004>] sd_probe+0x2e4/0x440
[ 12.566955] [<ffffffff8050a644>] driver_probe_device+0x104/0x260
[ 12.573068] [<ffffffff8050a860>] ? __device_attach+0x0/0x40
[ 12.578750] [<ffffffff8050a881>] __device_attach+0x21/0x40
[ 12.584347] [<ffffffff805095bb>] bus_for_each_drv+0x7b/0xc0
[ 12.590027] [<ffffffff8050a9a9>] device_attach+0xa9/0xc0
[ 12.595450] [<ffffffff805092f5>] bus_attach_device+0x75/0xa0
[ 12.601216] [<ffffffff80507619>] device_add+0x599/0x670
[ 12.606550] [<ffffffff8020c9f4>] ? mcount_call+0x5/0x31
[ 12.611884] [<ffffffff806277e5>] scsi_sysfs_add_sdev+0x75/0x2a0
[ 12.617914] [<ffffffff8062461b>] scsi_probe_and_add_lun+0xbbb/0xc70
[ 12.624289] [<ffffffff8062586a>] __scsi_add_device+0x13a/0x150
[ 12.630229] [<ffffffff806ada2b>] ata_scsi_scan_host+0xeb/0x330
[ 12.636171] [<ffffffff806aa376>] ata_host_register+0x286/0x310
[ 12.642111] [<ffffffff8050e150>] ? devres_open_group+0xc0/0xf0
[ 12.648053] [<ffffffff806b7380>] ? ata_sff_interrupt+0x0/0x2c0
[ 12.653995] [<ffffffff806b478f>] ata_pci_sff_activate_host+0x12f/0x240
[ 12.660628] [<ffffffff80892af4>] piix_init_one+0x334/0x7f0
[ 12.666225] [<ffffffff804660c3>] pci_call_probe+0xa3/0x100
[ 12.671817] [<ffffffff804662d9>] pci_device_probe+0x99/0xd0
[ 12.677499] [<ffffffff8050a644>] driver_probe_device+0x104/0x260
[ 12.683615] [<ffffffff8050a84b>] __driver_attach+0xab/0xc0
[ 12.689208] [<ffffffff8050a7a0>] ? __driver_attach+0x0/0xc0
[ 12.694891] [<ffffffff80509a4b>] bus_for_each_dev+0x7b/0xc0
[ 12.700570] [<ffffffff8050a324>] driver_attach+0x34/0x50
[ 12.705991] [<ffffffff80508f96>] bus_add_driver+0x116/0x2a0
[ 12.711670] [<ffffffff8050ab67>] driver_register+0x87/0x1a0
[ 12.717353] [<ffffffff80454ff7>] ? __spin_lock_init+0x47/0x90
[ 12.723206] [<ffffffff80deda70>] ? piix_init+0x0/0x60
[ 12.728368] [<ffffffff804665ee>] __pci_register_driver+0x7e/0xe0
[ 12.734483] [<ffffffff80dedaa1>] piix_init+0x31/0x60
[ 12.739558] [<ffffffff80dbbaac>] kernel_init+0x26f/0x39c
[ 12.744981] [<ffffffff808a79af>] ? _spin_unlock_irq+0x3f/0x70
[ 12.750834] [<ffffffff808a7313>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 12.757297] [<ffffffff80280499>] ? trace_hardirqs_on_caller+0x169/0x1d0
[ 12.764019] [<ffffffff8020e0c9>] child_rip+0xa/0x11
[ 12.769006] [<ffffffff8020d3de>] ? restore_args+0x0/0x30
[ 12.774429] [<ffffffff80dbb83d>] ? kernel_init+0x0/0x39c
[ 12.779850] [<ffffffff8020e0bf>] ? child_rip+0x0/0x11
[ 12.785012]
[ 12.786538] ---[ end trace 0361c3a3643346eb ]---
[ 12.791214] BUG: scheduling while atomic: swapper/1/0x92899fb1
[ 12.797072] INFO: lockdep is turned off.
[ 12.801020] Modules linked in:
task structure got corrupted here too - the preempt count is 0x92899fb1.
Ingo
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: per-cpu related?
2008-07-13 18:55 ` Ingo Molnar
@ 2008-07-13 21:01 ` Yinghai Lu
2008-07-13 21:04 ` Ingo Molnar
0 siblings, 1 reply; 9+ messages in thread
From: Yinghai Lu @ 2008-07-13 21:01 UTC (permalink / raw)
To: Ingo Molnar
Cc: Vegard Nossum, LKML, Mike Travis, Thomas Gleixner, Steven Rostedt
On Sun, Jul 13, 2008 at 11:55 AM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Yinghai Lu <yhlu.kernel@gmail.com> wrote:
>
>> thanks
>>
>> could be caused by max_low_pfn_mapped patch...because hpet still use
>> fixmap address that is cleared by others.
still got
calling __stack_chk_test+0x0/0x89
Testing -fstack-protector-all feature
-fstack-protector-all test failed
------------[ cut here ]------------
WARNING: at kernel/panic.c:393 __stack_chk_test+0x61/0x89()
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.26-rc9-tip-01873-ga9827e7-dirty #359
Call Trace:
[<ffffffff8026615e>] warn_on_slowpath+0x6c/0xa7
[<ffffffff80266199>] ? __stack_chk_test+0x0/0x89
[<ffffffff80266199>] ? __stack_chk_test+0x0/0x89
[<ffffffff8022a4f4>] ? mcount_call+0x5/0x31
[<ffffffff80266199>] ? __stack_chk_test+0x0/0x89
[<ffffffff802661fa>] __stack_chk_test+0x61/0x89
[<ffffffff80e729e4>] kernel_init+0x1de/0x346
[<ffffffff8022a4f4>] ? mcount_call+0x5/0x31
[<ffffffff80262df7>] ? finish_task_switch+0x14/0xe3
[<ffffffff8022b589>] child_rip+0xa/0x11
[<ffffffff80e72806>] ? kernel_init+0x0/0x346
[<ffffffff8022b57f>] ? child_rip+0x0/0x11
---[ end trace 0f276ea63a4e83de ]---
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: per-cpu related?
2008-07-13 21:01 ` Yinghai Lu
@ 2008-07-13 21:04 ` Ingo Molnar
2008-07-13 22:20 ` Yinghai Lu
0 siblings, 1 reply; 9+ messages in thread
From: Ingo Molnar @ 2008-07-13 21:04 UTC (permalink / raw)
To: Yinghai Lu
Cc: Vegard Nossum, LKML, Mike Travis, Thomas Gleixner, Steven Rostedt
* Yinghai Lu <yhlu.kernel@gmail.com> wrote:
> On Sun, Jul 13, 2008 at 11:55 AM, Ingo Molnar <mingo@elte.hu> wrote:
> >
> > * Yinghai Lu <yhlu.kernel@gmail.com> wrote:
> >
> >> thanks
> >>
> >> could be caused by max_low_pfn_mapped patch...because hpet still use
> >> fixmap address that is cleared by others.
>
> still got
>
> calling __stack_chk_test+0x0/0x89
> Testing -fstack-protector-all feature
> -fstack-protector-all test failed
> ------------[ cut here ]------------
> WARNING: at kernel/panic.c:393 __stack_chk_test+0x61/0x89()
> Modules linked in:
> Pid: 1, comm: swapper Not tainted 2.6.26-rc9-tip-01873-ga9827e7-dirty #359
>
> Call Trace:
> [<ffffffff8026615e>] warn_on_slowpath+0x6c/0xa7
> [<ffffffff80266199>] ? __stack_chk_test+0x0/0x89
> [<ffffffff80266199>] ? __stack_chk_test+0x0/0x89
> [<ffffffff8022a4f4>] ? mcount_call+0x5/0x31
> [<ffffffff80266199>] ? __stack_chk_test+0x0/0x89
> [<ffffffff802661fa>] __stack_chk_test+0x61/0x89
> [<ffffffff80e729e4>] kernel_init+0x1de/0x346
> [<ffffffff8022a4f4>] ? mcount_call+0x5/0x31
> [<ffffffff80262df7>] ? finish_task_switch+0x14/0xe3
> [<ffffffff8022b589>] child_rip+0xa/0x11
> [<ffffffff80e72806>] ? kernel_init+0x0/0x346
> [<ffffffff8022b57f>] ? child_rip+0x0/0x11
>
> ---[ end trace 0f276ea63a4e83de ]---
please try latest tip/master - the self-test had to be removed. (gcc
will treat the stackprotector-failure function as ((noreturn)) attribute
and will optimize out the return path, making a reliable self-test
impossible in the way we tried to)
Ingo
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: per-cpu related?
2008-07-13 21:04 ` Ingo Molnar
@ 2008-07-13 22:20 ` Yinghai Lu
0 siblings, 0 replies; 9+ messages in thread
From: Yinghai Lu @ 2008-07-13 22:20 UTC (permalink / raw)
To: Ingo Molnar
Cc: Vegard Nossum, LKML, Mike Travis, Thomas Gleixner, Steven Rostedt
On Sun, Jul 13, 2008 at 2:04 PM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Yinghai Lu <yhlu.kernel@gmail.com> wrote:
>
>> On Sun, Jul 13, 2008 at 11:55 AM, Ingo Molnar <mingo@elte.hu> wrote:
>> >
>> > * Yinghai Lu <yhlu.kernel@gmail.com> wrote:
>> >
>> >> thanks
>> >>
>> >> could be caused by max_low_pfn_mapped patch...because hpet still use
>> >> fixmap address that is cleared by others.
>>
>> still got
>>
>> calling __stack_chk_test+0x0/0x89
>> Testing -fstack-protector-all feature
>> -fstack-protector-all test failed
>> ------------[ cut here ]------------
>> WARNING: at kernel/panic.c:393 __stack_chk_test+0x61/0x89()
>> Modules linked in:
>> Pid: 1, comm: swapper Not tainted 2.6.26-rc9-tip-01873-ga9827e7-dirty #359
>>
>> Call Trace:
>> [<ffffffff8026615e>] warn_on_slowpath+0x6c/0xa7
>> [<ffffffff80266199>] ? __stack_chk_test+0x0/0x89
>> [<ffffffff80266199>] ? __stack_chk_test+0x0/0x89
>> [<ffffffff8022a4f4>] ? mcount_call+0x5/0x31
>> [<ffffffff80266199>] ? __stack_chk_test+0x0/0x89
>> [<ffffffff802661fa>] __stack_chk_test+0x61/0x89
>> [<ffffffff80e729e4>] kernel_init+0x1de/0x346
>> [<ffffffff8022a4f4>] ? mcount_call+0x5/0x31
>> [<ffffffff80262df7>] ? finish_task_switch+0x14/0xe3
>> [<ffffffff8022b589>] child_rip+0xa/0x11
>> [<ffffffff80e72806>] ? kernel_init+0x0/0x346
>> [<ffffffff8022b57f>] ? child_rip+0x0/0x11
>>
>> ---[ end trace 0f276ea63a4e83de ]---
>
> please try latest tip/master - the self-test had to be removed. (gcc
> will treat the stackprotector-failure function as ((noreturn)) attribute
> and will optimize out the return path, making a reliable self-test
> impossible in the way we tried to)
>
ok, you fixed it...
that warning is gone.
YH
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2008-07-13 22:20 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-07-13 8:16 per-cpu related? Yinghai Lu
2008-07-13 9:26 ` Ingo Molnar
2008-07-13 10:46 ` Vegard Nossum
2008-07-13 11:55 ` Vegard Nossum
2008-07-13 18:34 ` Yinghai Lu
2008-07-13 18:55 ` Ingo Molnar
2008-07-13 21:01 ` Yinghai Lu
2008-07-13 21:04 ` Ingo Molnar
2008-07-13 22:20 ` Yinghai Lu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®