From: Avi Kivity on
On 07/07/2010 03:47 PM, Peter Palfrader wrote:
> Hey,
>
> Greg KH schrieb am Donnerstag, dem 01. Juli 2010:
>
>
>> 2.6.32-stable review patch. If anyone has any objections, please let us know.
>>
> 2.6.32.16 fails to boot on my KVM domains using qemu-kvm 0.11.1.
>
> Bisecting between 2.6.32.14 which worked and .16 turned up this commit
> as the first culprit[0].
>
> The host is still running 2.6.32.14 and has 8 cores on 2 CPUs. The
> single-cpu KVM domain hangs just after printing 'Write protecting the
> kernel read-only data: 9492k'[1]. On a successful boot this line would
> usually be followed by 'INIT: version 2.86 booting'.
>
> A 2.6.32.16 with this patch reverted boots fine.
>
> If there's any info you need please just ask.
>

I'm unable to reproduce.

Can you provide the stack trace where this hangs? Add
CONFIG_DEBUG_INFO, and then

- copy vmlinux somewhere on the host filesystem
- start the guest
- when it hangs, type 'gdbserver' in the qemu monitor
- on the host, the 'gdb /path/to/vmlinux'
- 'target remote :1234'
- 'backtrace'

--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on
On 07/13/2010 01:23 PM, Peter Palfrader wrote:
> Sorry for the delay.
>

A good trace is worth it.

> [<ffffffff810373c0>] ? child_rip+0x0/0x20
> Code: 78 4f 44 89 e1 48 d3 e0 44 89 f2 48 f7 e2 48 0f ac d0 20 4a 8d 0c 38 44 39 03 75 a4 48 8b 15 15 df 6b 00 48 39 ca 77 17 48 89 d0<f0> 48 0f b1 0d 04 df 6b 00 48 39 c1 48 89 c2 75 e7 48 89 ca 48
> RIP [<ffffffff81054f73>] pvclock_clocksource_read+0x83/0xc0
> RSP<ffff88007fb47880>
> CR2: ffffffff81712e80
> ---[ end trace 38f25e02ae34d4c1 ]---
> BUG: unable to handle kernel paging request at ffffffff81712e80
> IP: [<ffffffff81054f73>] pvclock_clocksource_read+0x83/0xc0
> PGD 1003067 PUD 1007063 PMD 7e8b1063 PTE 8000000001712161
>

Read-only pte

> Oops: 0003 [#2] SMP
>

Write fault.

> Code: 78 4f 44 89 e1 48 d3 e0 44 89 f2 48 f7 e2 48 0f ac d0 20 4a 8d 0c 38 44 39 03 75 a4 48 8b 15 15 df 6b 00 48 39 ca 77 17 48 89 d0<f0> 48 0f b1 0d 04 df 6b 00 48 39 c1 48 89 c2 75 e7 48 89 ca 48
> RIP [<ffffffff81054f73>] pvclock_clocksource_read+0x83/0xc0
>

--> lock cmpxchg %rcx,0x6bdf04(%rip)

> static atomic64_t last_value = ATOMIC64_INIT(0);
>
> cycle_t pvclock_clocksource_read(struct pvclock_vcpu_time_info *src)
> {
>

[...]

> last = atomic64_read(&last_value);
> do {
> if (ret < last)
> return last;
> last = atomic64_cmpxchg(&last_value, last, ret);
> } while (unlikely(last != ret));
>
> return ret;
> }

So it looks like last_value was placed in a read only section. Please
post your System.map somewhere.

--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on
On 07/13/2010 05:19 PM, Peter Palfrader wrote:
>
>> So it looks like last_value was placed in a read only section. Please
>> post your System.map somewhere.
>>
> weasel(a)intrepid:~$ publish System.map
> http://asteria.noreply.org/~weasel/volatile/2010-07-13-mbm2xEdd8Q4/System.map
> weasel(a)intrepid:~$ grep -i last_value System.map
> ffffffff81712e80 r last_value
> ffffffff81b05240 b last_value.26163
>

"r" = "read only"

How does it look in 'nm arch/x86/kernel/pvclock.o'?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on
On 07/13/2010 07:22 PM, Peter Palfrader wrote:
>>>
>>> weasel(a)intrepid:~$ publish System.map
>>> http://asteria.noreply.org/~weasel/volatile/2010-07-13-mbm2xEdd8Q4/System.map
>>> weasel(a)intrepid:~$ grep -i last_value System.map
>>> ffffffff81712e80 r last_value
>>> ffffffff81b05240 b last_value.26163
>>>
>>>
>> "r" = "read only"
>>
>> How does it look in 'nm arch/x86/kernel/pvclock.o'?
>>
> The same:
>
> [git|v2.6.32.16] weasel(a)thelma:/scratch/kernel/2.6.32.16$ nm arch/x86/kernel/pvclock.o
> 0000000000000000 r last_value
> U native_read_tsc
> 0000000000000040 T pvclock_clocksource_read
> 0000000000000100 T pvclock_read_wallclock
> 0000000000000000 T pvclock_tsc_khz
> U set_normalized_timespec
>

But it's

>
> static atomic64_t last_value = ATOMIC64_INIT(0);
>

Doesn't make any sense.

Let's try to see if the toolchain is confused:

- rename last_value to some random name
- drop the 'static' qualifier
- drop the '= ATOMIC64_INIT(0)'
- all of the above

(better start with the last).

No need to rebuild everything, just look at the output of nm pvclock.o.

My bet is that dropping 'static' will fix it. We may have the wrong
constraints on atomic64_cmpxchg64(), so the compiler thinks we never
change last_value.

--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on
On 07/13/2010 07:40 PM, Avi Kivity wrote:
> On 07/13/2010 07:34 PM, Avi Kivity wrote:
>>
>> My bet is that dropping 'static' will fix it. We may have the wrong
>> constraints on atomic64_cmpxchg64(), so the compiler thinks we never
>> change last_value.
>>
>
> The constraints are there, but maybe the toolchain is confused.
>

No they aren't, as Linus just pointed out. His patch should fix the
problem.

--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/