Re: 9.2-STABLE: supervisor read data, page not present
On 9/9/13, Konstantin Belousov wrote: > On Mon, Sep 09, 2013 at 05:39:22PM +0200, Oliver Pinter wrote: >> Thanks, this patch fixed the issue. > > Which issue among the two problems you reported ? I assume that cpuctl > panic is gone, but what about proc_reap issue ? > Seems like both issue fixed. The system survived a full build word plus a portupgrade -arR. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.2-STABLE: supervisor read data, page not present
On Mon, Sep 09, 2013 at 05:39:22PM +0200, Oliver Pinter wrote: > Thanks, this patch fixed the issue. Which issue among the two problems you reported ? I assume that cpuctl panic is gone, but what about proc_reap issue ? pgp_2jaDyVSvF.pgp Description: PGP signature
Re: 9.2-STABLE: supervisor read data, page not present
On 9/9/13, Konstantin Belousov wrote:
> On Mon, Sep 09, 2013 at 08:45:21AM +0200, Oliver Pinter wrote:
>> On 9/9/13, Konstantin Belousov wrote:
>> > On Sun, Sep 08, 2013 at 11:40:01PM +0200, Oliver Pinter wrote:
>> >> #6 0x806a2ab3 in cpuctl_ioctl (dev=,
>> >> cmd=, data=, flags=0,
>> >> td=) at /usr/src/sys/dev/cpuctl/cpuctl.c:478
>> >> cpu =
>> >> ret =
>> >
>> > Do you indeed posses VIA CPU ? Was it due to some violence act ?
>>
>> Nope, this is an Intel Q9300.
>>
>> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
>> CPU: Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz (2499.76-MHz K8-class
>> CPU)
>> Origin = "GenuineIntel" Id = 0x10677 Family = 0x6 Model = 0x17
>> Stepping = 7
>>
>> Features=0xbfebfbff
>>
>> Features2=0x8e3fd
>> AMD Features=0x20100800
>> AMD Features2=0x1
>> TSC: P-state invariant, performance statistics
>> real memory = 4294967296 (4096 MB)
>> avail memory = 4103024640 (3912 MB)
>> Event timer "LAPIC" quality 400
>> ACPI APIC Table:
>> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
>> FreeBSD/SMP: 1 package(s) x 4 core(s)
>> cpu0 (BSP): APIC ID: 0
>> cpu1 (AP): APIC ID: 1
>> cpu2 (AP): APIC ID: 2
>> cpu3 (AP): APIC ID: 3
> Intel update code has the same issue. Still, it is weird that the debugger
> reported the line from the update_via().
>
>>
>>
>> >
>> > I am not sure about the first panic, lets fix the malloc/free
>> > corruption
>> > and see. The proc_reap() issue might be a consequence of the memory
>> > corruption from the wrong free().
>> >
>> > There is no public documentation for VIA CPUs, at least I was not
>> > able to find anything when I looked. According to the comment in the
>> > update_via(), all what is needed is that update buffer was 4-bytes
>> > aligned, which is always guaranteed by our malloc(9), at least for the
>> > allocation of size >=4.
>> >
>> > Try this.
>
> Updated patch.
>
> diff --git a/sys/dev/cpuctl/cpuctl.c b/sys/dev/cpuctl/cpuctl.c
> index 4e5abb2..317fc08 100644
> --- a/sys/dev/cpuctl/cpuctl.c
> +++ b/sys/dev/cpuctl/cpuctl.c
> @@ -295,10 +295,10 @@ cpuctl_do_update(int cpu, cpuctl_update_args_t *data,
> struct thread *td)
> static int
> update_intel(int cpu, cpuctl_update_args_t *args, struct thread *td)
> {
> - void *ptr = NULL;
> + void *ptr;
> uint64_t rev0, rev1;
> uint32_t tmp[4];
> - int is_bound = 0;
> + int is_bound;
> int oldcpu;
> int ret;
>
> @@ -312,10 +312,11 @@ update_intel(int cpu, cpuctl_update_args_t *args,
> struct thread *td)
> }
>
> /*
> - * 16 byte alignment required.
> + * 16 byte alignment required. Rely on the fact that
> + * malloc(9) always returns the pointer aligned at least on
> + * the size of the allocation.
>*/
> ptr = malloc(args->size + 16, M_CPUCTL, M_WAITOK);
> - ptr = (void *)(16 + ((intptr_t)ptr & ~0xf));
> if (copyin(args->data, ptr, args->size) != 0) {
> DPRINTF("[cpuctl,%d]: copyin %p->%p of %zd bytes failed",
> __LINE__, args->data, ptr, args->size);
> @@ -408,10 +409,10 @@ fail:
> static int
> update_via(int cpu, cpuctl_update_args_t *args, struct thread *td)
> {
> - void *ptr = NULL;
> + void *ptr;
> uint64_t rev0, rev1, res;
> uint32_t tmp[4];
> - int is_bound = 0;
> + int is_bound;
> int oldcpu;
> int ret;
>
> @@ -427,8 +428,7 @@ update_via(int cpu, cpuctl_update_args_t *args, struct
> thread *td)
> /*
>* 4 byte alignment required.
>*/
> - ptr = malloc(args->size + 16, M_CPUCTL, M_WAITOK);
> - ptr = (void *)(16 + ((intptr_t)ptr & ~0xf));
> + ptr = malloc(args->size, M_CPUCTL, M_WAITOK);
> if (copyin(args->data, ptr, args->size) != 0) {
> DPRINTF("[cpuctl,%d]: copyin %p->%p of %zd bytes failed",
> __LINE__, args->data, ptr, args->size);
>
Thanks, this patch fixed the issue.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.2-STABLE: supervisor read data, page not present
On Mon, Sep 09, 2013 at 08:45:21AM +0200, Oliver Pinter wrote:
> On 9/9/13, Konstantin Belousov wrote:
> > On Sun, Sep 08, 2013 at 11:40:01PM +0200, Oliver Pinter wrote:
> >> #6 0x806a2ab3 in cpuctl_ioctl (dev=,
> >> cmd=, data=, flags=0,
> >> td=) at /usr/src/sys/dev/cpuctl/cpuctl.c:478
> >>cpu =
> >>ret =
> >
> > Do you indeed posses VIA CPU ? Was it due to some violence act ?
>
> Nope, this is an Intel Q9300.
>
> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
> CPU: Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz (2499.76-MHz K8-class
> CPU)
> Origin = "GenuineIntel" Id = 0x10677 Family = 0x6 Model = 0x17
> Stepping = 7
>
> Features=0xbfebfbff
>
> Features2=0x8e3fd
> AMD Features=0x20100800
> AMD Features2=0x1
> TSC: P-state invariant, performance statistics
> real memory = 4294967296 (4096 MB)
> avail memory = 4103024640 (3912 MB)
> Event timer "LAPIC" quality 400
> ACPI APIC Table:
> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
> FreeBSD/SMP: 1 package(s) x 4 core(s)
> cpu0 (BSP): APIC ID: 0
> cpu1 (AP): APIC ID: 1
> cpu2 (AP): APIC ID: 2
> cpu3 (AP): APIC ID: 3
Intel update code has the same issue. Still, it is weird that the debugger
reported the line from the update_via().
>
>
> >
> > I am not sure about the first panic, lets fix the malloc/free corruption
> > and see. The proc_reap() issue might be a consequence of the memory
> > corruption from the wrong free().
> >
> > There is no public documentation for VIA CPUs, at least I was not
> > able to find anything when I looked. According to the comment in the
> > update_via(), all what is needed is that update buffer was 4-bytes
> > aligned, which is always guaranteed by our malloc(9), at least for the
> > allocation of size >=4.
> >
> > Try this.
Updated patch.
diff --git a/sys/dev/cpuctl/cpuctl.c b/sys/dev/cpuctl/cpuctl.c
index 4e5abb2..317fc08 100644
--- a/sys/dev/cpuctl/cpuctl.c
+++ b/sys/dev/cpuctl/cpuctl.c
@@ -295,10 +295,10 @@ cpuctl_do_update(int cpu, cpuctl_update_args_t *data,
struct thread *td)
static int
update_intel(int cpu, cpuctl_update_args_t *args, struct thread *td)
{
- void *ptr = NULL;
+ void *ptr;
uint64_t rev0, rev1;
uint32_t tmp[4];
- int is_bound = 0;
+ int is_bound;
int oldcpu;
int ret;
@@ -312,10 +312,11 @@ update_intel(int cpu, cpuctl_update_args_t *args, struct
thread *td)
}
/*
-* 16 byte alignment required.
+* 16 byte alignment required. Rely on the fact that
+* malloc(9) always returns the pointer aligned at least on
+* the size of the allocation.
*/
ptr = malloc(args->size + 16, M_CPUCTL, M_WAITOK);
- ptr = (void *)(16 + ((intptr_t)ptr & ~0xf));
if (copyin(args->data, ptr, args->size) != 0) {
DPRINTF("[cpuctl,%d]: copyin %p->%p of %zd bytes failed",
__LINE__, args->data, ptr, args->size);
@@ -408,10 +409,10 @@ fail:
static int
update_via(int cpu, cpuctl_update_args_t *args, struct thread *td)
{
- void *ptr = NULL;
+ void *ptr;
uint64_t rev0, rev1, res;
uint32_t tmp[4];
- int is_bound = 0;
+ int is_bound;
int oldcpu;
int ret;
@@ -427,8 +428,7 @@ update_via(int cpu, cpuctl_update_args_t *args, struct
thread *td)
/*
* 4 byte alignment required.
*/
- ptr = malloc(args->size + 16, M_CPUCTL, M_WAITOK);
- ptr = (void *)(16 + ((intptr_t)ptr & ~0xf));
+ ptr = malloc(args->size, M_CPUCTL, M_WAITOK);
if (copyin(args->data, ptr, args->size) != 0) {
DPRINTF("[cpuctl,%d]: copyin %p->%p of %zd bytes failed",
__LINE__, args->data, ptr, args->size);
pgph7c93n0jYn.pgp
Description: PGP signature
Re: 9.2-STABLE: supervisor read data, page not present
On 9/9/13, Konstantin Belousov wrote:
> On Sun, Sep 08, 2013 at 11:40:01PM +0200, Oliver Pinter wrote:
>> #6 0x806a2ab3 in cpuctl_ioctl (dev=,
>> cmd=, data=, flags=0,
>> td=) at /usr/src/sys/dev/cpuctl/cpuctl.c:478
>> cpu =
>> ret =
>
> Do you indeed posses VIA CPU ? Was it due to some violence act ?
Nope, this is an Intel Q9300.
FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
CPU: Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz (2499.76-MHz K8-class CPU)
Origin = "GenuineIntel" Id = 0x10677 Family = 0x6 Model = 0x17
Stepping = 7
Features=0xbfebfbff
Features2=0x8e3fd
AMD Features=0x20100800
AMD Features2=0x1
TSC: P-state invariant, performance statistics
real memory = 4294967296 (4096 MB)
avail memory = 4103024640 (3912 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table:
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 4 core(s)
cpu0 (BSP): APIC ID: 0
cpu1 (AP): APIC ID: 1
cpu2 (AP): APIC ID: 2
cpu3 (AP): APIC ID: 3
>
> I am not sure about the first panic, lets fix the malloc/free corruption
> and see. The proc_reap() issue might be a consequence of the memory
> corruption from the wrong free().
>
> There is no public documentation for VIA CPUs, at least I was not
> able to find anything when I looked. According to the comment in the
> update_via(), all what is needed is that update buffer was 4-bytes
> aligned, which is always guaranteed by our malloc(9), at least for the
> allocation of size >=4.
>
> Try this.
>
> diff --git a/sys/dev/cpuctl/cpuctl.c b/sys/dev/cpuctl/cpuctl.c
> index 4e5abb2..ca5ed56 100644
> --- a/sys/dev/cpuctl/cpuctl.c
> +++ b/sys/dev/cpuctl/cpuctl.c
> @@ -408,10 +408,10 @@ fail:
> static int
> update_via(int cpu, cpuctl_update_args_t *args, struct thread *td)
> {
> - void *ptr = NULL;
> + void *ptr;
> uint64_t rev0, rev1, res;
> uint32_t tmp[4];
> - int is_bound = 0;
> + int is_bound;
> int oldcpu;
> int ret;
>
> @@ -427,8 +427,7 @@ update_via(int cpu, cpuctl_update_args_t *args, struct
> thread *td)
> /*
>* 4 byte alignment required.
>*/
> - ptr = malloc(args->size + 16, M_CPUCTL, M_WAITOK);
> - ptr = (void *)(16 + ((intptr_t)ptr & ~0xf));
> + ptr = malloc(args->size, M_CPUCTL, M_WAITOK);
> if (copyin(args->data, ptr, args->size) != 0) {
> DPRINTF("[cpuctl,%d]: copyin %p->%p of %zd bytes failed",
> __LINE__, args->data, ptr, args->size);
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.2-STABLE: supervisor read data, page not present
On Sun, Sep 08, 2013 at 11:40:01PM +0200, Oliver Pinter wrote:
> #6 0x806a2ab3 in cpuctl_ioctl (dev=,
> cmd=, data=, flags=0,
> td=) at /usr/src/sys/dev/cpuctl/cpuctl.c:478
> cpu =
> ret =
Do you indeed posses VIA CPU ? Was it due to some violence act ?
I am not sure about the first panic, lets fix the malloc/free corruption
and see. The proc_reap() issue might be a consequence of the memory
corruption from the wrong free().
There is no public documentation for VIA CPUs, at least I was not
able to find anything when I looked. According to the comment in the
update_via(), all what is needed is that update buffer was 4-bytes
aligned, which is always guaranteed by our malloc(9), at least for the
allocation of size >=4.
Try this.
diff --git a/sys/dev/cpuctl/cpuctl.c b/sys/dev/cpuctl/cpuctl.c
index 4e5abb2..ca5ed56 100644
--- a/sys/dev/cpuctl/cpuctl.c
+++ b/sys/dev/cpuctl/cpuctl.c
@@ -408,10 +408,10 @@ fail:
static int
update_via(int cpu, cpuctl_update_args_t *args, struct thread *td)
{
- void *ptr = NULL;
+ void *ptr;
uint64_t rev0, rev1, res;
uint32_t tmp[4];
- int is_bound = 0;
+ int is_bound;
int oldcpu;
int ret;
@@ -427,8 +427,7 @@ update_via(int cpu, cpuctl_update_args_t *args, struct
thread *td)
/*
* 4 byte alignment required.
*/
- ptr = malloc(args->size + 16, M_CPUCTL, M_WAITOK);
- ptr = (void *)(16 + ((intptr_t)ptr & ~0xf));
+ ptr = malloc(args->size, M_CPUCTL, M_WAITOK);
if (copyin(args->data, ptr, args->size) != 0) {
DPRINTF("[cpuctl,%d]: copyin %p->%p of %zd bytes failed",
__LINE__, args->data, ptr, args->size);
pgp3xfweHRNN_.pgp
Description: PGP signature
Re: 9.2-STABLE: supervisor read data, page not present
On 9/8/13, Oliver Pinter wrote: > Hi! > > I got this panic on recent 9-STABLE (amd64): > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > <118>Sep 8 20:22:34 pandora-d syslogd: exiting on signal 15 > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x78 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0x80482a05 > stack pointer = 0x28:0xff800024e7d0 > frame pointer = 0x28:0xff800024e800 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 1 (init) > trap number = 12 > panic: page fault > cpuid = 0 > KDB: stack backtrace: > #0 0x804cd660 at kdb_backtrace+0x60 > #1 0x8049797e at panic+0x1fe > #2 0x8069e3da at trap_fatal+0x37a > #3 0x8069e64b at trap_pfault+0x25b > #4 0x8069dd74 at trap+0x454 > #5 0x80688543 at calltrap+0x8 > #6 0x8046893b at proc_reap+0x4bb > #7 0x80468d51 at proc_to_reap+0x361 > #8 0x80467ddb at kern_wait6+0x22b > #9 0x804679b6 at sys_wait4+0x76 > #10 0x8069eb9d at amd64_syscall+0x29d > #11 0x8068882b at Xfast_syscall+0xfb > Uptime: 34m20s > Dumping 367 out of 4084 > MB:..5%..14%..22%..31%..44%..53%..62%..75%..83%..92% > > This is fully reproducible. > > The HEAD stay on : > > commit aba57138f98f1a98e4b7c7c61511daefb0542524 > Author: des > Date: Sun Sep 8 10:04:26 2013 + > > Make libldns and libssh private. > > Approved by:re (blanket) > > Notes: > svn path=/head/; revision=255386 > > The panic first appeared on likely between august 8 and 17. > > When you need more info, the ping me. > after recompiling the kernel with INVARIANTS: zone: 4096(0xfe00cff68380) slab 0xfe00059af470 freed address 0xfe00059b2010 unaligned. panic: should be 0xfe00059b2000 cpuid = 0 KDB: stack backtrace: #0 0x804c7790 at kdb_backtrace+0x60 #1 0x80494c8e at panic+0x1fe #2 0x8066062c at uma_dbg_free+0x10c #3 0x8065dbe5 at uma_zfree_arg+0x75 #4 0x8047f1f7 at free+0x97 #5 0x806a2ab3 at cpuctl_ioctl+0x4b3 #6 0x80401640 at devfs_ioctl_f+0xf0 #7 0x804db190 at kern_ioctl+0x1b0 #8 0x804daf92 at sys_ioctl+0x142 #9 0x806989c1 at amd64_syscall+0x211 #10 0x80681ecb at Xfast_syscall+0xfb Uptime: 28s Dumping 264 out of 4084 MB:..7%..13%..25%..31%..43%..55%..61%..73%..85%..91% Script started on Sun Sep 8 23:31:25 2013 [1mroot[m@[4mpandora-d[24m ~# kgdb /boot/ker kernel.old/ kernel/ [1mroot[m@[4mpandora-d[24m ~# kgdb /boot/kernel kernel.old/ kernel/ [1mroot[m@[4mpandora-d[24m ~# kgdb /boot/kernel/ker kernel* kernel.symbols* [1mroot[m@[4mpandora-d[24m ~# kgdb /boot/kernel/kernel /var/crash/vmco vmcore.0 vmcore.1 vmcore.2 vmcore.3 vmcore.4 vmcore.5 [1mroot[m@[4mpandora-d[24m ~# kgdb /boot/kernel/kernel /var/crash/vmcore.4 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: <118>nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful <118>Starting nginx. <118>Updating cpucodes... <118>/usr/local/share/cpucontrol/m101067770A.fw: updating cpu /dev/cpuctl0 from rev 0x705 to rev 0x70a... zone: 4096(0xfe00cff68380) slab 0xfe00059af470 freed address 0xfe00059b2010 unaligned. panic: should be 0xfe00059b2000 cpuid = 0 KDB: stack backtrace: #0 0x804c7790 at kdb_backtrace+0x60 #1 0x80494c8e at panic+0x1fe #2 0x8066062c at uma_dbg_free+0x10c #3 0x8065dbe5 at uma_zfree_arg+0x75 #4 0x8047f1f7 at free+0x97 #5 0x806a2ab3 at cpuctl_ioctl+0x4b3 #6 0x80401640 at devfs_ioctl_f+0xf0 #7 0x804db190 at kern_ioctl+0x1b0 #8 0x804daf92 at sys_ioctl+0x142 #9 0x806989c1 at amd64_syscall+0x211 #10 0x80681ecb at Xfast_syscall+0xfb Uptime: 28s Dumping 264 out of 4084 MB:..7%..13%..25%..31%..43%..55%..61%..73%..85%..91% Reading symbols from /bo
9.2-STABLE: supervisor read data, page not present
Hi! I got this panic on recent 9-STABLE (amd64): GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: <118>Sep 8 20:22:34 pandora-d syslogd: exiting on signal 15 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x78 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80482a05 stack pointer = 0x28:0xff800024e7d0 frame pointer = 0x28:0xff800024e800 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1 (init) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0x804cd660 at kdb_backtrace+0x60 #1 0x8049797e at panic+0x1fe #2 0x8069e3da at trap_fatal+0x37a #3 0x8069e64b at trap_pfault+0x25b #4 0x8069dd74 at trap+0x454 #5 0x80688543 at calltrap+0x8 #6 0x8046893b at proc_reap+0x4bb #7 0x80468d51 at proc_to_reap+0x361 #8 0x80467ddb at kern_wait6+0x22b #9 0x804679b6 at sys_wait4+0x76 #10 0x8069eb9d at amd64_syscall+0x29d #11 0x8068882b at Xfast_syscall+0xfb Uptime: 34m20s Dumping 367 out of 4084 MB:..5%..14%..22%..31%..44%..53%..62%..75%..83%..92% This is fully reproducible. The HEAD stay on : commit aba57138f98f1a98e4b7c7c61511daefb0542524 Author: des Date: Sun Sep 8 10:04:26 2013 + Make libldns and libssh private. Approved by:re (blanket) Notes: svn path=/head/; revision=255386 The panic first appeared on likely between august 8 and 17. When you need more info, the ping me. STABLE Description: Binary data kgdb.script Description: Binary data ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
