Re: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]

2017-02-28 Thread Mateusz Guzik 
On Sat, Feb 25, 2017 at 08:31:04PM +0100, Mateusz Guzik wrote:
> On Sat, Feb 25, 2017 at 09:58:39AM -0800, Mark Millard wrote:
> > Thus the PowerMac G5 so-called "Quad Core" is back to
> > -r313254 without your patches. (The "Quad Core" really has
> > two processors, each with 2 cores.)
> > 
> 
> 
> Thanks a lot for testing. I'll have to think what to do with it, worst
> case I'll #ifdef changes with powerpc.
> 

Should be fixed with r314474. Got a real powerpc to test on (60 cores),
was able to lock it up in seconds. Now it is perfectly stablle.

-- 
Mateusz Guzik 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADSUP: after r313194 on freebsd-current, lang/gcc ports require a rebuild

2017-02-28 Thread Mark Linimon 
On Tue, Feb 28, 2017 at 11:24:27PM +0100, Ed Schouten wrote:
> 2017-02-28 21:00 GMT+01:00 Konstantin Belousov :
> > Ideally, ports should stop shipping mangled system includes, or even better,
> > gcc stop doing fixincludes.
> 
> Amen.

Please let me know the magic wand you folks want us to wave to fix up all the
bad usages in ports.

We are barely keeping our heads above water as it is.

mcl
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: invalid bcd xxx

2017-02-28 Thread Michael Gmelin 
On Tue, 28 Feb 2017 17:16:02 -0600
Eric van Gyzen  wrote:

> On 02/28/2017 16:57, Conrad Meyer wrote:
> > On Tue, Feb 28, 2017 at 2:31 PM, Eric van Gyzen
> >  wrote:  
> >> Your system's real-time clock is returning garbage.  r312702 added
> >> some input validation a few weeks ago.  Previously, the kernel was
> >> reading beyond the end of an array and either complaining about
> >> the clock or setting it to the wrong time based on whatever was in
> >> the memory beyond the array.
> >>
> >> The added validation shouldn't be an assertion because it operates
> >> on data beyond the kernel's control.  Try this:
> >>
> >> --- sys/libkern.h   (revision 314424)
> >> +++ sys/libkern.h   (working copy)
> >> @@ -57,8 +57,10 @@
> >>  bcd2bin(int bcd)
> >>  {
> >>
> >> -   KASSERT(bcd >= 0 && bcd < LIBKERN_LEN_BCD2BIN,
> >> -   ("invalid bcd %d", bcd));
> >> +   if (bcd < 0 || bcd >= LIBKERN_LEN_BCD2BIN) {
> >> +   printf("invalid bcd %d\n", bcd);
> >> +   return (0);
> >> +   }
> >> return (bcd2bin_data[bcd]);
> >>  }  
> >
> > I don't think removing this assertion and truncating to zero is the
> > right thing to do.  Adding an error return to this routine is a
> > little much, though.  I think probably the caller should perform
> > input validation between the broken device and this routine.  
> 
> Either of those would be a much better solution.  This was just a
> quick hack to get the memstick to boot.
> 

Thanks for your response.

I'm not in a hurry, so I can wait for a proper solution. Let me know if
I should test anything or can help in some other way.

-m


-- 
Michael Gmelin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: invalid bcd xxx

2017-02-28 Thread Eric van Gyzen 

On 02/28/2017 16:57, Conrad Meyer wrote:

On Tue, Feb 28, 2017 at 2:31 PM, Eric van Gyzen  wrote:

Your system's real-time clock is returning garbage.  r312702 added some
input validation a few weeks ago.  Previously, the kernel was reading beyond
the end of an array and either complaining about the clock or setting it to
the wrong time based on whatever was in the memory beyond the array.

The added validation shouldn't be an assertion because it operates on data
beyond the kernel's control.  Try this:

--- sys/libkern.h   (revision 314424)
+++ sys/libkern.h   (working copy)
@@ -57,8 +57,10 @@
 bcd2bin(int bcd)
 {

-   KASSERT(bcd >= 0 && bcd < LIBKERN_LEN_BCD2BIN,
-   ("invalid bcd %d", bcd));
+   if (bcd < 0 || bcd >= LIBKERN_LEN_BCD2BIN) {
+   printf("invalid bcd %d\n", bcd);
+   return (0);
+   }
return (bcd2bin_data[bcd]);
 }


I don't think removing this assertion and truncating to zero is the
right thing to do.  Adding an error return to this routine is a little
much, though.  I think probably the caller should perform input
validation between the broken device and this routine.


Either of those would be a much better solution.  This was just a quick 
hack to get the memstick to boot.


Eric
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: invalid bcd xxx

2017-02-28 Thread Conrad Meyer 
On Tue, Feb 28, 2017 at 2:31 PM, Eric van Gyzen  wrote:
> Your system's real-time clock is returning garbage.  r312702 added some
> input validation a few weeks ago.  Previously, the kernel was reading beyond
> the end of an array and either complaining about the clock or setting it to
> the wrong time based on whatever was in the memory beyond the array.
>
> The added validation shouldn't be an assertion because it operates on data
> beyond the kernel's control.  Try this:
>
> --- sys/libkern.h   (revision 314424)
> +++ sys/libkern.h   (working copy)
> @@ -57,8 +57,10 @@
>  bcd2bin(int bcd)
>  {
>
> -   KASSERT(bcd >= 0 && bcd < LIBKERN_LEN_BCD2BIN,
> -   ("invalid bcd %d", bcd));
> +   if (bcd < 0 || bcd >= LIBKERN_LEN_BCD2BIN) {
> +   printf("invalid bcd %d\n", bcd);
> +   return (0);
> +   }
> return (bcd2bin_data[bcd]);
>  }

I don't think removing this assertion and truncating to zero is the
right thing to do.  Adding an error return to this routine is a little
much, though.  I think probably the caller should perform input
validation between the broken device and this routine.

Thanks,
Conrad
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: invalid bcd xxx

2017-02-28 Thread Eric van Gyzen 

On 02/28/2017 15:47, Michael Gmelin wrote:

Booting r313561[0] I get the following panic:

mountroot: waiting for device /dev/ufs/FreeBSD_install
panic: invalid bcd 177 (also 254, 255 etc.)
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper...
vpanic()...
kassert_panic()...
atrtc_gettime()...
inittodr()...
vfs_mountroot()...
start_init()...
fork_exit()...
fork_trampoline()...
(copied from a screenshot, hence the ellipsis)

This is on an Acer C720 Chromebook, confirmed on two devices (one with
cyapa touchpad, one with elan touchpad). Same problem happened with a
CURRENT checked out about 10 hours ago. Previous versions of 12-CURRENT
worked ok (last version I tested personally was back in
November/December though).


Your system's real-time clock is returning garbage.  r312702 added some 
input validation a few weeks ago.  Previously, the kernel was reading 
beyond the end of an array and either complaining about the clock or 
setting it to the wrong time based on whatever was in the memory beyond 
the array.


The added validation shouldn't be an assertion because it operates on 
data beyond the kernel's control.  Try this:


--- sys/libkern.h   (revision 314424)
+++ sys/libkern.h   (working copy)
@@ -57,8 +57,10 @@
 bcd2bin(int bcd)
 {

-   KASSERT(bcd >= 0 && bcd < LIBKERN_LEN_BCD2BIN,
-   ("invalid bcd %d", bcd));
+   if (bcd < 0 || bcd >= LIBKERN_LEN_BCD2BIN) {
+   printf("invalid bcd %d\n", bcd);
+   return (0);
+   }
return (bcd2bin_data[bcd]);
 }

Eric
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADSUP: after r313194 on freebsd-current, lang/gcc ports require a rebuild

2017-02-28 Thread Ed Schouten 
2017-02-28 21:00 GMT+01:00 Konstantin Belousov :
> Ideally, ports should stop shipping mangled system includes, or even better,
> gcc stop doing fixincludes.

Amen.

-- 
Ed Schouten 
Nuxi, 's-Hertogenbosch, the Netherlands
KvK-nr.: 62051717
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: invalid bcd xxx

2017-02-28 Thread Konstantin Belousov 
On Tue, Feb 28, 2017 at 10:47:39PM +0100, Michael Gmelin wrote:
> Booting r313561[0] I get the following panic:
> 
> mountroot: waiting for device /dev/ufs/FreeBSD_install
> panic: invalid bcd 177 (also 254, 255 etc.)
> cpuid = 1
> KDB: stack backtrace:
> db_trace_self_wrapper...
> vpanic()...
> kassert_panic()...
> atrtc_gettime()...
> inittodr()...
> vfs_mountroot()...
> start_init()...
> fork_exit()...
> fork_trampoline()...
> (copied from a screenshot, hence the ellipsis)
> 
> This is on an Acer C720 Chromebook, confirmed on two devices (one with
> cyapa touchpad, one with elan touchpad). Same problem happened with a
> CURRENT checked out about 10 hours ago. Previous versions of 12-CURRENT
> worked ok (last version I tested personally was back in
> November/December though).
> 
> -m
> 
> 
> [0]
> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20170210-r313561-memstick.img
> 

This is most likely due to r312702.  But then it means that your RTC
returns garbage.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

panic: invalid bcd xxx

2017-02-28 Thread Michael Gmelin 
Booting r313561[0] I get the following panic:

mountroot: waiting for device /dev/ufs/FreeBSD_install
panic: invalid bcd 177 (also 254, 255 etc.)
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper...
vpanic()...
kassert_panic()...
atrtc_gettime()...
inittodr()...
vfs_mountroot()...
start_init()...
fork_exit()...
fork_trampoline()...
(copied from a screenshot, hence the ellipsis)

This is on an Acer C720 Chromebook, confirmed on two devices (one with
cyapa touchpad, one with elan touchpad). Same problem happened with a
CURRENT checked out about 10 hours ago. Previous versions of 12-CURRENT
worked ok (last version I tested personally was back in
November/December though).

-m


[0]
https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20170210-r313561-memstick.img

-- 
Michael Gmelin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADSUP: after r313194 on freebsd-current, lang/gcc ports require a rebuild

2017-02-28 Thread Konstantin Belousov 
On Tue, Feb 28, 2017 at 11:42:48AM -0800, Steve Kargl wrote:
> r313194 defined vm_ooffset_t and vm_pindex_t in sys/types.h.
> I believe that forces a recompile of lang/gcc ports, and
> probably anything built with the lang/gcc port to avoid 
> dependency issue.  Neither "pkg audit -q" nor "pkg version -vl '<'"
> pick up this issue.
> 
> % make 
> gcc6 -o hex -O2 -pipe -static -Wall -fno-builtin -I/usr/local/include -I../mp 
> -I../libm/msun/src -I../libm/libc/include -I../libm/libc/i386 hex.c -lm
> In file included from 
> /usr/local/lib/gcc6/gcc/x86_64-portbld-freebsd12.0/6.3.0/include-fixed/unistd.h:46:0,
>  from hex.c:6:
> /usr/local/lib/gcc6/gcc/x86_64-portbld-freebsd12.0/6.3.0/include-fixed/sys/types.h:266:9:
>  error: unknown type name '__vm_ooffset_t'
>  typedef __vm_ooffset_t vm_ooffset_t;
>  ^~
> /usr/local/lib/gcc6/gcc/x86_64-portbld-freebsd12.0/6.3.0/include-fixed/sys/types.h:268:9:
>  error: unknown type name '__vm_pindex_t'
>  typedef __vm_pindex_t vm_pindex_t;
>  ^
> *** Error code 1
> 
> % uname -a
> FreeBSD troutmask.apl.washington.edu 12.0-CURRENT FreeBSD 12.0-CURRENT #0 
> r312992: Mon Jan 30 13:00:38 PST 2017 
> ka...@troutmask.apl.washington.edu:/data/obj/usr/src/sys/SPEW  amd64
> 
> % ll /usr/local/bin/gcc6
> -r-xr-xr-x  3 root  wheel  - 936640 Jan  2 14:21 /usr/local/bin/gcc6*
> 

Or do something along the following:
mv /usr/local/lib/gcc6/gcc/x86_64-portbld-freebsd12.0/6.3.0/include-fixed/ \
  
/usr/local/lib/gcc6/gcc/x86_64-portbld-freebsd12.0/6.3.0/include-fixed.not-needed/

Ideally, ports should stop shipping mangled system includes, or even better,
gcc stop doing fixincludes.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

HEADSUP: after r313194 on freebsd-current, lang/gcc ports require a rebuild

2017-02-28 Thread Steve Kargl 
r313194 defined vm_ooffset_t and vm_pindex_t in sys/types.h.
I believe that forces a recompile of lang/gcc ports, and
probably anything built with the lang/gcc port to avoid 
dependency issue.  Neither "pkg audit -q" nor "pkg version -vl '<'"
pick up this issue.

% make 
gcc6 -o hex -O2 -pipe -static -Wall -fno-builtin -I/usr/local/include -I../mp 
-I../libm/msun/src -I../libm/libc/include -I../libm/libc/i386 hex.c -lm
In file included from 
/usr/local/lib/gcc6/gcc/x86_64-portbld-freebsd12.0/6.3.0/include-fixed/unistd.h:46:0,
 from hex.c:6:
/usr/local/lib/gcc6/gcc/x86_64-portbld-freebsd12.0/6.3.0/include-fixed/sys/types.h:266:9:
 error: unknown type name '__vm_ooffset_t'
 typedef __vm_ooffset_t vm_ooffset_t;
 ^~
/usr/local/lib/gcc6/gcc/x86_64-portbld-freebsd12.0/6.3.0/include-fixed/sys/types.h:268:9:
 error: unknown type name '__vm_pindex_t'
 typedef __vm_pindex_t vm_pindex_t;
 ^
*** Error code 1

% uname -a
FreeBSD troutmask.apl.washington.edu 12.0-CURRENT FreeBSD 12.0-CURRENT #0 
r312992: Mon Jan 30 13:00:38 PST 2017 
ka...@troutmask.apl.washington.edu:/data/obj/usr/src/sys/SPEW  amd64

% ll /usr/local/bin/gcc6
-r-xr-xr-x  3 root  wheel  - 936640 Jan  2 14:21 /usr/local/bin/gcc6*

-- 
Steve
20161221 https://www.youtube.com/watch?v=IbCHE-hONow
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"