FYI: Going from head -r313864 to -r313999 I had to rebuild virtualbox-ose-additions 5.1.14

2017-02-20 Thread Mark Millard 
For amd64 I run FreeBSD under VirtualBox on macOS. So I use
emulators/virtualbox-ose-additions in the FreeBSD instance.

I've been using virtualbox-ose-additions-5.1.14 for some time
under -r313864 (and some prior versions), no problems, no
need to rebuild virtualbox-ose-additions-5.1.14 along the way
to -r313864.

On updating to -r313999 the boot got the following shortly
before it would have given the login prompt normally. . .

> # kgdb kernel.debug /var/crash/vmcore.0
> 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>Starting vboxservice.
> <118>VBoxService 5.1.14 r112924 (verbosity: 0) freebsd.amd64 (Jan 20 2017 
> 18:37:45) release log
> <118>00:00:00.000120 main Log opened 2017-02-20T22:38:46.34808Z
> <118>00:00:00.000162 main OS Product: FreeBSD
> <118>00:00:00.000171 main OS Release: 12.0-CURRENT
> <118>00:00:00.000180 main OS Version: FreeBSD 12.0-CURRENT  r313999M
> <118>00:00:00.000192 main Executable: /usr/local/sbin/VBoxService
> <118>00:00:00.000194 main Process ID: 609
> <118>00:00:00.000196 main Package type: BSD_64BITS_GENERIC (OSE)
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 2; apic id = 02
> fault virtual address   = 0xd6
> fault code  = supervisor read data, page not present
> instruction pointer = 0x20:0x80d4ebaf
> stack pointer   = 0x28:0xfe0122e2bef0
> frame pointer   = 0x28:0xfe0122e2bf00
> 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 = 609 (VBoxService)
> 
> Reading symbols from /boot/kernel/zfs.ko...Reading symbols from 
> /usr/lib/debug//boot/kernel/zfs.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/zfs.ko
> Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from 
> /usr/lib/debug//boot/kernel/opensolaris.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/opensolaris.ko
> Reading symbols from /boot/modules/vboxguest.ko...done.
> Loaded symbols for /boot/modules/vboxguest.ko
> #0  doadump (textdump=0) at pcpu.h:232
> 232 __asm("movq %%gs:%1,%0" : "=r" (td)
> (kgdb) bt
> #0  doadump (textdump=0) at pcpu.h:232
> #1  0x8039dd0b in db_dump (dummy=, dummy2= optimized out>, dummy3=, dummy4=) 
> at /usr/src/sys/ddb/db_command.c:546
> #2  0x8039db0f in db_command (cmd_table=) at 
> /usr/src/sys/ddb/db_command.c:453
> #3  0x8039d884 in db_command_loop () at 
> /usr/src/sys/ddb/db_command.c:506
> #4  0x803a0814 in db_trap (type=, code= optimized out>) at /usr/src/sys/ddb/db_main.c:254
> #5  0x80a9c0c3 in kdb_trap (type=, code= optimized out>, tf=) at /usr/src/sys/kern/subr_kdb.c:654
> #6  0x80ed25d2 in trap_fatal (frame=0xfe0122e2be30, eva=214) at 
> /usr/src/sys/amd64/amd64/trap.c:796
> #7  0x80ed27dc in trap_pfault (frame=0xfe0122e2be30, usermode=0) 
> at /usr/src/sys/amd64/amd64/trap.c:658
> #8  0x80ed1e90 in trap (frame=0xfe0122e2be30) at 
> /usr/src/sys/amd64/amd64/trap.c:421
> #9  0x80eb6be1 in calltrap () at 
> /usr/src/sys/amd64/amd64/exception.S:236
> #10 0x80d4ebaf in _vm_map_lock (map=0x1, file=0x0, line=0) at 
> /usr/src/sys/vm/vm_map.c:501
> #11 0x80d51ea2 in vm_map_wire (map=, 
> start=4534272, end=4538368, flags=1) at /usr/src/sys/vm/vm_map.c:2534
> #12 0x8265291c in rtR0MemObjNativeLockInMap () from 
> /boot/modules/vboxguest.ko
> #13 0x82652881 in rtR0MemObjNativeLockUser () from 
> /boot/modules/vboxguest.ko
> #14 0x8264ec01 in RTR0MemObjLockUserTag () from 
> /boot/modules/vboxguest.ko
> #15 0x82624afd in vbglR0HGCMInternalPreprocessCall () from 
> /boot/modules/vboxguest.ko
> #16 0x8262411a in VbglR0HGCMInternalCall () from 
> /boot/modules/vboxguest.ko
> #17 0x8261ec4f in vgdrvIoCtl_HGCMCall () from 
> /boot/modules/vboxguest.ko
> #18 0x8261d221 in VGDrvCommonIoCtl () from /boot/modules/vboxguest.ko
> #19 0x8262327d in vgdrvFreeBSDIOCtl () from /boot/modules/vboxguest.ko
> #20 0x8092976e in devfs_ioctl (ap=) at 
> /usr/src/sys/fs/devfs/devfs_vnops.c:805
> #21 0x8103ef58 in VOP_IOCTL_APV (vop=, a= optimized out>) at vnode_if.c:1067
> #22 0x80b29431 in vn_ioctl (fp=0xf80006d37730, com= optimized out>, data=0xfe0122e2c870, active_cred=0xf80006495a00, 
> td=) at vnode_if.h:448
> #23 0x80929d5f in devfs_ioctl_f (fp=, com= optimized out>, data=,

Re: weird panic at mount

2017-02-20 Thread Chagin Dmitry 
On Tue, Feb 21, 2017 at 07:58:23AM +0100, Mateusz Guzik wrote:
> On Tue, Feb 21, 2017 at 09:51:25AM +0300, Chagin Dmitry wrote:
> > 2527 * Remove a prison reference.  If that was the last reference, 
> > remove the
> > (kgdb) p *cred->cr_prison
> > Cannot access memory at address 0x100fe
> > (kgdb) p *cred
> > $1 = {cr_ref = 0x0, cr_uid = 0x0, cr_ruid = 0x816f9500, cr_svuid = 
> > 0x, cr_ngroups = 0x80de6efd, 
> >   cr_rgid = 0x, cr_svgid = 0x14fb, cr_uidinfo = 0xf80003a3ef10, 
> > cr_ruidinfo = 0x80e75cef, 
> >   cr_prison = 0x100fe, cr_loginclass = 0xf800073ff420, cr_flags 
> > = 0x80e55a4b, cr_pspare2 = {
> > 0x101be, 0xf8000777e098}, cr_label = 0x80e55a4b, 
> > cr_audit = {ai_auid = 0x1ba, ai_mask = {
> >   am_success = 0x1, am_failure = 0x81a59e00}, ai_termid = {at_port 
> > = 0x, at_type = 0x80ecb56d, 
> >   at_addr = {0x, 0x4c9, 0x1, 0x0}}, ai_asid = 0x0, ai_flags 
> > = 0x0}, cr_groups = 0xf80007870800, 
> >   cr_agroups = 0x80ec4b1b, cr_smallgroups = {0x, 0x578, 0x1, 
> > 0x819c8580, 0x, 0x80ec4b1b, 
> > 0x, 0x353a, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}
> > 
> 
> Did you recompile your modules? Several fields seem off by a multiply of
> 8 bytes, which coincidently fits r313992.
>

Reading symbols from /boot/kernel/drm2.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/drm2.ko.debug...done.
^
Reading symbols from /boot/modules/fdescfs.ko...Reading symbols from 
/usr/lib/debug//boot/modules/fdescfs.ko.debug...done.
   ^^^ looks like fdescfs module was old


thanks!
___
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: weird panic at mount

2017-02-20 Thread Mateusz Guzik 
On Tue, Feb 21, 2017 at 09:51:25AM +0300, Chagin Dmitry wrote:
> 2527   * Remove a prison reference.  If that was the last reference, remove 
> the
> (kgdb) p *cred->cr_prison
> Cannot access memory at address 0x100fe
> (kgdb) p *cred
> $1 = {cr_ref = 0x0, cr_uid = 0x0, cr_ruid = 0x816f9500, cr_svuid = 
> 0x, cr_ngroups = 0x80de6efd, 
>   cr_rgid = 0x, cr_svgid = 0x14fb, cr_uidinfo = 0xf80003a3ef10, 
> cr_ruidinfo = 0x80e75cef, 
>   cr_prison = 0x100fe, cr_loginclass = 0xf800073ff420, cr_flags = 
> 0x80e55a4b, cr_pspare2 = {
> 0x101be, 0xf8000777e098}, cr_label = 0x80e55a4b, 
> cr_audit = {ai_auid = 0x1ba, ai_mask = {
>   am_success = 0x1, am_failure = 0x81a59e00}, ai_termid = {at_port = 
> 0x, at_type = 0x80ecb56d, 
>   at_addr = {0x, 0x4c9, 0x1, 0x0}}, ai_asid = 0x0, ai_flags = 
> 0x0}, cr_groups = 0xf80007870800, 
>   cr_agroups = 0x80ec4b1b, cr_smallgroups = {0x, 0x578, 0x1, 
> 0x819c8580, 0x, 0x80ec4b1b, 
> 0x, 0x353a, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}
> 

Did you recompile your modules? Several fields seem off by a multiply of
8 bytes, which coincidently fits r313992.

-- 
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"

weird panic at mount

2017-02-20 Thread Chagin Dmitry 

Trying to mount root from ufs:/dev/gpt/rootfs [rw]...
<118>Setting hostuuid: 6e6fa481-535f-11cb-9756-be6694d54790.
<118>Setting hostid: 0xa94c64a9.
<118>Starting file system checks:
<118>/dev/gpt/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS
<118>/dev/gpt/rootfs: clean, 1877279 free (13871 frags, 232926 blocks, 0.4% 
fragmentation)
<118>/dev/gpt/homefs: FILE SYSTEM CLEAN; SKIPPING CHECKS
<118>/dev/gpt/homefs: clean, 116318576 free (1184592 frags, 14391748 blocks, 
0.5% fragmentation)
<118>/dev/gpt/varfs: FILE SYSTEM CLEAN; SKIPPING CHECKS
<118>/dev/gpt/varfs: clean, 5448483 free (1267 frags, 680902 blocks, 0.0% 
fragmentation)
<118>Mounting local filesystems:


Fatal trap 9: general protection fault while in kernel mode
cpuid = 7; apic id = 07
instruction pointer = 0x20:0x8073cea7
stack pointer   = 0x28:0xfe033db0b250
frame pointer   = 0x28:0xfe033db0b260
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 = 72 (mount)

Reading symbols from /boot/kernel/drm2.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/drm2.ko.debug...done.
done.
Reading symbols from /boot/modules/fdescfs.ko...Reading symbols from 
/usr/lib/debug//boot/modules/fdescfs.ko.debug...done.
done.
doadump (textdump=1034988016) at /home/git/head/sys/kern/kern_shutdown.c:318
318 dumptid = curthread->td_tid;
(kgdb) #0  doadump (textdump=1034988016)
at /home/git/head/sys/kern/kern_shutdown.c:318
#1  0x803fc015 in db_fncall_generic (addr=-2139568144, 
rv=0xfe033db0a9a0, nargs=0, args=0xfe033db0a9b0)
at /home/git/head/sys/ddb/db_command.c:581
#2  0x803fb5d4 in db_fncall (dummy1=-2185103365408, dummy2=false, 
dummy3=0, dummy4=0xfe033db0aae0 "")
at /home/git/head/sys/ddb/db_command.c:629
#3  0x803faf3e in db_command (
last_cmdp=0x8170af40 , cmd_table=0x0, dopager=1)
at /home/git/head/sys/ddb/db_command.c:453
#4  0x803faad9 in db_command_loop ()
at /home/git/head/sys/ddb/db_command.c:506
#5  0x803ff92a in db_trap (type=9, code=0)
at /home/git/head/sys/ddb/db_main.c:248
#6  0x807f7361 in kdb_trap (type=9, code=0, tf=0xfe033db0b190)
at /home/git/head/sys/kern/subr_kdb.c:654
#7  0x80ceb7bc in trap_fatal (frame=0xfe033db0b190, eva=0)
at /home/git/head/sys/amd64/amd64/trap.c:819
#8  0x80ceabf1 in trap (frame=0xfe033db0b190)
at /home/git/head/sys/amd64/amd64/trap.c:553
#9  0x80cec2ca in trap_check (frame=0xfe033db0b190)
at /home/git/head/sys/amd64/amd64/trap.c:625
#10 
#11 0x8073cea7 in prison_allow (
cred=0x819620f8 , flag=4096)
at /home/git/head/sys/kern/kern_jail.c:2523
#12 0x81e2102c in fdesc_mount (mp=0xf8000771e6d0)
at /home/git/head/sys/modules/fdescfs/../../fs/fdescfs/fdesc_vfsops.c:85
#13 0x808b8bf8 in vfs_domount_first (td=0xf800075fca80, 
vfsp=0x81e221f8 , 
fspath=0xf800073ca780 "/dev/fd", vp=0xf8000777e000, fsflags=0, 
optlist=0xfe033db0b798) at /home/git/head/sys/kern/vfs_mount.c:825
#14 0x808b4fa5 in vfs_domount (td=0xf800075fca80, 
fstype=0xf80007279f20 "fdescfs", fspath=0xf80007279f00 "/dev/fd", 
fsflags=0, optlist=0xfe033db0b798)
at /home/git/head/sys/kern/vfs_mount.c:1114
#15 0x808b4088 in vfs_donmount (td=0xf800075fca80, fsflags=0, 
fsoptions=0xf8000736) at /home/git/head/sys/kern/vfs_mount.c:675
#16 0x808b37c4 in sys_nmount (td=0xf800075fca80, 
uap=0xfe033db0ba58) at /home/git/head/sys/kern/vfs_mount.c:420
#17 0x80cece75 in syscallenter (td=0xf800075fca80, 
sa=0xfe033db0ba48)
at /home/git/head/sys/amd64/amd64/../../kern/subr_syscall.c:135
#18 0x80cec67a in amd64_syscall (td=0xf800075fca80, traced=0)
at /home/git/head/sys/amd64/amd64/trap.c:925
#19 
#20 0x000800a8394a in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffdce8
(kgdb) 
(kgdb) up 11
#11 0x8073cea7 in prison_allow (cred=0x819620f8 
, flag=0x1000)
at /home/git/head/sys/kern/kern_jail.c:2523
2523return (cred->cr_prison->pr_allow & flag);
(kgdb) l
2518int
2519prison_allow(struct ucred *cred, unsigned flag)
2520{
2521
2522/* This is an atomic read, so no locking is necessary. */
2523return (cred->cr_prison->pr_allow & flag);
2524}
2525
2526/*
2527 * Remove a prison reference.  If that was the last reference, remove 
the
(kgdb) p *cred->cr_prison
Cannot access memory at address 0x100fe
(kgdb) p *cred
$1 = {cr_ref = 0x0, cr_uid = 0x0, cr_ruid = 0x816f9500, cr_svuid = 0x, 
cr_ngroups = 0x80de6efd, 
  cr_rgid = 0x, cr_svgid = 0x14fb,

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-20 Thread Mateusz Guzik 
On Mon, Feb 20, 2017 at 09:39:32PM -0800, Mark Millard wrote:
> Looks like some kernel binary interface (as seen by
> emulators/virtualbox-ose-addition ) has changed:
> rebuilding emulators/virtualbox-ose-addition removed
> the booting crash but uname -apKU still lists 1200021
> and 2100021 for the kernel and world for -r313999,
> just like for -r313864.
> 

I think this is r313992.

I don't see why __FreeBSD_version would be modified for this. You are
expected to always recompilel your modules while tracking -current.

-- 
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: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]

2017-02-20 Thread Mark Millard 
On 2017-Feb-20, at 6:36 PM, Mark Millard  wrote:

> On 2017-Feb-20, at 3:35 PM, Mateusz Guzik  wrote:
> 
>> On Mon, Feb 20, 2017 at 03:10:44PM -0800, Mark Millard wrote:
>>> On 2017-Feb-20, at 2:58 PM, Mark Millard  wrote:
>>> 
 On 2017-Feb-20, at 11:10 AM, Mateusz Guzik  wrote:
 
> On Sat, Feb 18, 2017 at 04:18:05AM -0800, Mark Millard wrote:
>> [Note: I experiment with clang based powerpc64 builds,
>> reporting problems that I find. Justin is familiar
>> with this, as is Nathan.]
>> 
>> I tried to update the PowerMac G5 (a so-called "Quad Core")
>> that I have access to from head -r312761 to -r313864 and
>> ended up with random panics and hang ups in fairly short
>> order after booting.
>> 
>> Some approximate bisecting for the kernel lead to:
>> (sometimes getting part way into a buildkernel attempt
>> for a different version before a failure happens)
>> 
>> -r313266: works (just before use of atomic_fcmpset)
>> vs.
>> -r313271: fails (last of the "use atomic_fcmpset" check-ins)
>> 
>> (I did not try -r313268 through -r313270 as the use was
>> gradually added.)
>> 
>> So I'm currently running a -r313864 world with a -r313266
>> kernel.
>> 
>> No kernel that I tried that was from before -r313266 had the
>> problems.
>> 
>> Any kernel that I tried that was from after -r313271 had the
>> problems.
>> 
>> Of course I did not try them all in other direction. :)
>> 
> 
> I found that spin mutexes were not properly handling this, fixed in
> r313996.
> 
> Locally I added a if (cpu_tick() % 2) return (0); snipped to amd64
> fcmpset to simulate failures. Everything works, while it would easily
> fail without the patch.
> 
> That said, I hope this concludes the 'missing check for not-reread value
> of failed fcmpset' saga.
> 
> -- 
> Mateusz Guzik 
 
 I tried to update from -r313864 to -r313999 in my amd64 context
 (a VirtualBox machine under macOS) but it now crashes late in
 the boot sequence (after it processes a dump if I make one but
 before I can log in).
 
 This update was via my usual explicit svnlite update; buildworld
 buildkernel; etc. production style build of world and kernel,
 including use of MALLOC_PRODUCTION.
 
 The window shows:
 
 _vm_map_lock+0xf
 vm_map_wire+0x32
 rtROMemObjNativeLockInMap+0x8c
 rtROMemObjNativeLockUser+0x51
 RTR0MemObjLockUserTag+0x231
 vbglR0HGCMInternalPreprocessCall+0x65d
 vbglR0HGCMInternalCall+0x17c
 vgdrvIoCtl_HGCMCall+0x43f
 VGDrvCommonIoCtl+0x261
 vgdrvFreeBSDIOCtl+0x2cd
 devfs_ioctl+0xae
 VOP_IOCTL_APV+0x88
 vn_ioctl+0x161
 devfs_ioctl_f+0x1f
 kern_ioctl+0x280
 sys_ioctl+0x13f
 amd64_syscall+0x397
 Xfast_syscall+0xfb
>>> 
>>> More detail from booting with the -r313864 kernel.old
>>> and using kgdb on what the dump produced:
>>> 
>>> # kgdb kernel.debug /var/crash/vmcore.
>>> /var/crash/vmcore.0/var/crash/vmcore.last
>>> # kgdb kernel.debug /var/crash/vmcore.0
>>> 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>Starting vboxservice.
>>> <118>VBoxService 5.1.14 r112924 (verbosity: 0) freebsd.amd64 (Jan 20 2017 
>>> 18:37:45) release log
>>> <118>00:00:00.000120 main Log opened 2017-02-20T22:38:46.34808Z
>>> <118>00:00:00.000162 main OS Product: FreeBSD
>>> <118>00:00:00.000171 main OS Release: 12.0-CURRENT
>>> <118>00:00:00.000180 main OS Version: FreeBSD 12.0-CURRENT  r313999M
>>> <118>00:00:00.000192 main Executable: /usr/local/sbin/VBoxService
>>> <118>00:00:00.000194 main Process ID: 609
>>> <118>00:00:00.000196 main Package type: BSD_64BITS_GENERIC (OSE)
>>> 
>>> 
>>> Fatal trap 12: page fault while in kernel mode
>>> cpuid = 2; apic id = 02
>>> fault virtual address   = 0xd6
>>> fault code  = supervisor read data, page not present
>>> instruction pointer = 0x20:0x80d4ebaf
>>> stack pointer   = 0x28:0xfe0122e2bef0
>>> frame pointer   = 0x28:0xfe0122e2bf00
>>> 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 = 609 (VBoxService)
>>> 
>> 
>> 
>> 
>>> #9  0x80eb6be1 in calltrap () at 
>>> /usr/src/sys/amd64/amd64/exception.S:236
>>> #10 0x80d4ebaf in _vm_map_lock

Re: drm2, i915kms cause instant lock-up

2017-02-20 Thread Steve Kargl 
On Tue, Feb 21, 2017 at 01:50:30AM +0100, Mateusz Guzik wrote:
> On Mon, Feb 20, 2017 at 04:43:40PM -0800, Steve Kargl wrote:
> > On Tue, Feb 21, 2017 at 12:58:07AM +0100, Mateusz Guzik wrote:
> > > On Mon, Feb 20, 2017 at 03:52:24PM -0800, Steve Kargl wrote:
> > > > With a kernel and world from r313943 sources (circa
> > > > Feb 19, 2017), kldload of either drm2.ko or i915kms.ko
> > > > will lock up the system.  There is no keyboard response,
> > > > screen output, or panic.  Just a locked up system.
> > > > 
> > > > A kernel from r313027 and its modules boots fine.
> > > > 'kldload drm2.ko' yields the following in /var/log/messages:
> > > > 
> > > 
> > > There were quite a few invasive changes in this timeframe. Can you
> > > please:
> > > 
> > > 1. switch to 313254 and ensure it works
> > > 2. apply https://people.freebsd.org/~mjg/patches/complete-locks.diff and
> > > check if it breaks
> > > 
> > > If it does not break, revert the patch and bisect the kernel please.
> > > Otherwise I'll devise smaller diffs to narrow this down.
> > > 
> > 
> > With 1. and 2. the system boots and I can kldload both drm2
> > and i915kms.  I revert the patch and start bisecting the kernel.
> > Thanks for the quick response.
> > 
> 
> Thanks for testing. Note you may encounter some turbulences along the
> road as there were fixups and fixups to fixups to the combined above
> patch.
> 

Well, the good news seems to be that r313254 and older are 'ok'.
So, something between r313943 and r313254 is triggering a the
problem.  I'm still bisecting, but it might take a day or two.

-- 
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"

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-20 Thread Mark Millard 
On 2017-Feb-20, at 3:35 PM, Mateusz Guzik  wrote:

> On Mon, Feb 20, 2017 at 03:10:44PM -0800, Mark Millard wrote:
>> On 2017-Feb-20, at 2:58 PM, Mark Millard  wrote:
>> 
>>> On 2017-Feb-20, at 11:10 AM, Mateusz Guzik  wrote:
>>> 
 On Sat, Feb 18, 2017 at 04:18:05AM -0800, Mark Millard wrote:
> [Note: I experiment with clang based powerpc64 builds,
> reporting problems that I find. Justin is familiar
> with this, as is Nathan.]
> 
> I tried to update the PowerMac G5 (a so-called "Quad Core")
> that I have access to from head -r312761 to -r313864 and
> ended up with random panics and hang ups in fairly short
> order after booting.
> 
> Some approximate bisecting for the kernel lead to:
> (sometimes getting part way into a buildkernel attempt
> for a different version before a failure happens)
> 
> -r313266: works (just before use of atomic_fcmpset)
> vs.
> -r313271: fails (last of the "use atomic_fcmpset" check-ins)
> 
> (I did not try -r313268 through -r313270 as the use was
> gradually added.)
> 
> So I'm currently running a -r313864 world with a -r313266
> kernel.
> 
> No kernel that I tried that was from before -r313266 had the
> problems.
> 
> Any kernel that I tried that was from after -r313271 had the
> problems.
> 
> Of course I did not try them all in other direction. :)
> 
 
 I found that spin mutexes were not properly handling this, fixed in
 r313996.
 
 Locally I added a if (cpu_tick() % 2) return (0); snipped to amd64
 fcmpset to simulate failures. Everything works, while it would easily
 fail without the patch.
 
 That said, I hope this concludes the 'missing check for not-reread value
 of failed fcmpset' saga.
 
 -- 
 Mateusz Guzik 
>>> 
>>> I tried to update from -r313864 to -r313999 in my amd64 context
>>> (a VirtualBox machine under macOS) but it now crashes late in
>>> the boot sequence (after it processes a dump if I make one but
>>> before I can log in).
>>> 
>>> This update was via my usual explicit svnlite update; buildworld
>>> buildkernel; etc. production style build of world and kernel,
>>> including use of MALLOC_PRODUCTION.
>>> 
>>> The window shows:
>>> 
>>> _vm_map_lock+0xf
>>> vm_map_wire+0x32
>>> rtROMemObjNativeLockInMap+0x8c
>>> rtROMemObjNativeLockUser+0x51
>>> RTR0MemObjLockUserTag+0x231
>>> vbglR0HGCMInternalPreprocessCall+0x65d
>>> vbglR0HGCMInternalCall+0x17c
>>> vgdrvIoCtl_HGCMCall+0x43f
>>> VGDrvCommonIoCtl+0x261
>>> vgdrvFreeBSDIOCtl+0x2cd
>>> devfs_ioctl+0xae
>>> VOP_IOCTL_APV+0x88
>>> vn_ioctl+0x161
>>> devfs_ioctl_f+0x1f
>>> kern_ioctl+0x280
>>> sys_ioctl+0x13f
>>> amd64_syscall+0x397
>>> Xfast_syscall+0xfb
>> 
>> More detail from booting with the -r313864 kernel.old
>> and using kgdb on what the dump produced:
>> 
>> # kgdb kernel.debug /var/crash/vmcore.
>> /var/crash/vmcore.0/var/crash/vmcore.last
>> # kgdb kernel.debug /var/crash/vmcore.0
>> 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>Starting vboxservice.
>> <118>VBoxService 5.1.14 r112924 (verbosity: 0) freebsd.amd64 (Jan 20 2017 
>> 18:37:45) release log
>> <118>00:00:00.000120 main Log opened 2017-02-20T22:38:46.34808Z
>> <118>00:00:00.000162 main OS Product: FreeBSD
>> <118>00:00:00.000171 main OS Release: 12.0-CURRENT
>> <118>00:00:00.000180 main OS Version: FreeBSD 12.0-CURRENT  r313999M
>> <118>00:00:00.000192 main Executable: /usr/local/sbin/VBoxService
>> <118>00:00:00.000194 main Process ID: 609
>> <118>00:00:00.000196 main Package type: BSD_64BITS_GENERIC (OSE)
>> 
>> 
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 2; apic id = 02
>> fault virtual address   = 0xd6
>> fault code  = supervisor read data, page not present
>> instruction pointer = 0x20:0x80d4ebaf
>> stack pointer   = 0x28:0xfe0122e2bef0
>> frame pointer   = 0x28:0xfe0122e2bf00
>> 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 = 609 (VBoxService)
>> 
> 
> 
> 
>> #9  0x80eb6be1 in calltrap () at 
>> /usr/src/sys/amd64/amd64/exception.S:236
>> #10 0x80d4ebaf in _vm_map_lock (map=0x1, file=0x0, line=0) at 
>> /usr/src/sys/vm/vm_map.c:501
> 
> The function is:
> void
> _vm_map_lock(vm_map_t map, const char *file, int line)
> {
> 
>if

Re: drm2, i915kms cause instant lock-up

2017-02-20 Thread Mateusz Guzik 
On Mon, Feb 20, 2017 at 04:43:40PM -0800, Steve Kargl wrote:
> On Tue, Feb 21, 2017 at 12:58:07AM +0100, Mateusz Guzik wrote:
> > On Mon, Feb 20, 2017 at 03:52:24PM -0800, Steve Kargl wrote:
> > > With a kernel and world from r313943 sources (circa
> > > Feb 19, 2017), kldload of either drm2.ko or i915kms.ko
> > > will lock up the system.  There is no keyboard response,
> > > screen output, or panic.  Just a locked up system.
> > > 
> > > A kernel from r313027 and its modules boots fine.
> > > 'kldload drm2.ko' yields the following in /var/log/messages:
> > > 
> > 
> > There were quite a few invasive changes in this timeframe. Can you
> > please:
> > 
> > 1. switch to 313254 and ensure it works
> > 2. apply https://people.freebsd.org/~mjg/patches/complete-locks.diff and
> > check if it breaks
> > 
> > If it does not break, revert the patch and bisect the kernel please.
> > Otherwise I'll devise smaller diffs to narrow this down.
> > 
> 
> With 1. and 2. the system boots and I can kldload both drm2
> and i915kms.  I revert the patch and start bisecting the kernel.
> Thanks for the quick response.
> 

Thanks for testing. Note you may encounter some turbulences along the
road as there were fixups and fixups to fixups to the combined above
patch.

Good luck.

-- 
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: drm2, i915kms cause instant lock-up

2017-02-20 Thread Steve Kargl 
On Tue, Feb 21, 2017 at 12:58:07AM +0100, Mateusz Guzik wrote:
> On Mon, Feb 20, 2017 at 03:52:24PM -0800, Steve Kargl wrote:
> > With a kernel and world from r313943 sources (circa
> > Feb 19, 2017), kldload of either drm2.ko or i915kms.ko
> > will lock up the system.  There is no keyboard response,
> > screen output, or panic.  Just a locked up system.
> > 
> > A kernel from r313027 and its modules boots fine.
> > 'kldload drm2.ko' yields the following in /var/log/messages:
> > 
> 
> There were quite a few invasive changes in this timeframe. Can you
> please:
> 
> 1. switch to 313254 and ensure it works
> 2. apply https://people.freebsd.org/~mjg/patches/complete-locks.diff and
> check if it breaks
> 
> If it does not break, revert the patch and bisect the kernel please.
> Otherwise I'll devise smaller diffs to narrow this down.
> 

With 1. and 2. the system boots and I can kldload both drm2
and i915kms.  I revert the patch and start bisecting the kernel.
Thanks for the quick response.

-- 
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"

Re: drm2, i915kms cause instant lock-up

2017-02-20 Thread Steve Kargl 
On Tue, Feb 21, 2017 at 12:58:07AM +0100, Mateusz Guzik wrote:
> On Mon, Feb 20, 2017 at 03:52:24PM -0800, Steve Kargl wrote:
> > With a kernel and world from r313943 sources (circa
> > Feb 19, 2017), kldload of either drm2.ko or i915kms.ko
> > will lock up the system.  There is no keyboard response,
> > screen output, or panic.  Just a locked up system.
> > 
> > A kernel from r313027 and its modules boots fine.
> > 'kldload drm2.ko' yields the following in /var/log/messages:
> > 
> 
> There were quite a few invasive changes in this timeframe. Can you
> please:
> 
> 1. switch to 313254 and ensure it works
> 2. apply https://people.freebsd.org/~mjg/patches/complete-locks.diff and
> check if it breaks
> 

I'll give it a shot.  It takes 30 to 60 minutes to build kernel
and modules on my system.  I'll post results when available.

-- 
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"

Re: drm2, i915kms cause instant lock-up

2017-02-20 Thread Mateusz Guzik 
On Mon, Feb 20, 2017 at 03:52:24PM -0800, Steve Kargl wrote:
> With a kernel and world from r313943 sources (circa
> Feb 19, 2017), kldload of either drm2.ko or i915kms.ko
> will lock up the system.  There is no keyboard response,
> screen output, or panic.  Just a locked up system.
> 
> A kernel from r313027 and its modules boots fine.
> 'kldload drm2.ko' yields the following in /var/log/messages:
> 

There were quite a few invasive changes in this timeframe. Can you
please:

1. switch to 313254 and ensure it works
2. apply https://people.freebsd.org/~mjg/patches/complete-locks.diff and
check if it breaks

If it does not break, revert the patch and bisect the kernel please.
Otherwise I'll devise smaller diffs to narrow this down.

-- 
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"

drm2, i915kms cause instant lock-up

2017-02-20 Thread Steve Kargl 
With a kernel and world from r313943 sources (circa
Feb 19, 2017), kldload of either drm2.ko or i915kms.ko
will lock up the system.  There is no keyboard response,
screen output, or panic.  Just a locked up system.

A kernel from r313027 and its modules boots fine.
'kldload drm2.ko' yields the following in /var/log/messages:

agp0:  on vgapci0
agp0: aperture size is 256M, detected 7676k stolen memory
info: [drm] Initialized drm 1.1.0 20060810

'kldload drm2.ko' yields the following in /var/log/messages:
drmn0:  on vgapci0
intel_iicbb0 on drmn0
iicbus0:  on iicbb0 addr 0xf2
iic0:  on iicbus0
iicbus1:  on intel_gmbus0
iic1:  on iicbus1
intel_iicbb1 on drmn0
iicbus2:  on iicbb1 addr 0xf2
iic2:  on iicbus2
iicbus3:  on intel_gmbus1
iic3:  on iicbus3
intel_iicbb2 on drmn0
iicbus4:  on iicbb2 addr 0xf2
iic4:  on iicbus4
iicbus5:  on intel_gmbus2
iic5:  on iicbus5
intel_iicbb3 on drmn0
iicbus6:  on iicbb3 addr 0xf2
iic6:  on iicbus6
iicbus7:  on intel_gmbus3
iic7:  on iicbus7
intel_iicbb4 on drmn0
iicbus8:  on iicbb4 addr 0xf2
iic8:  on iicbus8
iicbus9:  on intel_gmbus4
iic9:  on iicbus9
intel_iicbb5 on drmn0
iicbus10:  on iicbb5 addr 0xf2
iic10:  on iicbus10
iicbus11:  on intel_gmbus5
iic11:  on iicbus11
info: [drm] MSI enabled 1 message(s)
info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
info: [drm] Driver supports precise vblank timestamp query.
composite sync not supported
intel_sdvo_ddc_proxy397632 on drmn0
intel_sdvo_ddc_proxy397632: detached
intel_sdvo_ddc_proxy397664 on drmn0
intel_sdvo_ddc_proxy397664: detached
drmn0: taking over the fictitious range 0xe000-0xf000
info: [drm] initialized overlay support
info: [drm] Connector LVDS-1: get mode from tunables:
info: [drm]   - kern.vt.fb.modes.LVDS-1
info: [drm]   - kern.vt.fb.default_mode
info: [drm] Connector VGA-1: get mode from tunables:
info: [drm]   - kern.vt.fb.modes.VGA-1
info: [drm]   - kern.vt.fb.default_mode
info: [drm] Connector SVIDEO-1: get mode from tunables:
info: [drm]   - kern.vt.fb.modes.SVIDEO-1
info: [drm]   - kern.vt.fb.default_mode
composite sync not supported
fbd0 on drmn0
VT: Replacing driver "vga" with new "fb".
info: [drm] Initialized i915 1.6.0 20080730 for drmn0 on minor 0
 
A diff of dmesg.boot for the good kernel and bad kernel shows

--- /root/dmesg.good2017-02-20 13:30:06.707702000 -0800
+++ /root/dmesg.bad 2017-02-20 13:42:10.271942000 -0800
@@ -2,11 +2,11 @@
 Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
 FreeBSD is a registered trademark of The FreeBSD Foundation.
-FreeBSD 12.0-CURRENT #3 r313027: Mon Feb 20 11:59:15 PST 2017
+FreeBSD 12.0-CURRENT #1 r313943: Sun Feb 19 09:18:03 PST 2017
 root@laptop-kargl:/mnt/obj/mnt/src/sys/MOBILE i386
 FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based on LLVM 
3.9.1)
 VT(vga): text 80x25
-CPU: Intel(R) Core(TM)2 Duo CPU T7250  @ 2.00GHz (1995.05-MHz 686-class 
CPU)
+CPU: Intel(R) Core(TM)2 Duo CPU T7250  @ 2.00GHz (1995.04-MHz 686-class 
CPU)
   Origin="GenuineIntel"  Id=0x6fd  Family=0x6  Model=0xf  Stepping=13
   
Features=0xbfebfbff
   Features2=0xe3bd
@@ -15,7 +15,7 @@
   VT-x: (disabled in BIOS) HLT,PAUSE
   TSC: P-state invariant, performance statistics
 real memory  = 4294967296 (4096 MB)
-avail memory = 3663994880 (3494 MB)
+avail memory = 3665018880 (3495 MB)
 Event timer "LAPIC" quality 100
 ACPI APIC Table: 
 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
@@ -24,7 +24,7 @@
 ioapic0  irqs 0-23 on motherboard
 random: entropy device external interface
 kbd1 at kbdmux0
-module_register_init: MOD_LOAD (vesa, 0xc0bf7440, 0) error 19
+module_register_init: MOD_LOAD (vesa, 0xc0ae6db0, 0) error 19
 nexus0
 vtvga0:  on motherboard
 acpi0:  on motherboard
@@ -42,7 +42,7 @@
 attimer0:  port 0x40-0x43,0x50-0x53 irq 2 on acpi0
 Timecounter "i8254" frequency 1193182 Hz quality 0
 Event timer "i8254" frequency 1193182 Hz quality 100
-Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
+Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
 pcib0:  on acpi0
 pcib0: failed to parse resources: AE_AML_NO_RESOURCE_END_TAG

The module_register_init difference seems suspicious.

-- 
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"

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-20 Thread Mateusz Guzik 
On Mon, Feb 20, 2017 at 03:10:44PM -0800, Mark Millard wrote:
> On 2017-Feb-20, at 2:58 PM, Mark Millard  wrote:
> 
> > On 2017-Feb-20, at 11:10 AM, Mateusz Guzik  wrote:
> > 
> >> On Sat, Feb 18, 2017 at 04:18:05AM -0800, Mark Millard wrote:
> >>> [Note: I experiment with clang based powerpc64 builds,
> >>> reporting problems that I find. Justin is familiar
> >>> with this, as is Nathan.]
> >>> 
> >>> I tried to update the PowerMac G5 (a so-called "Quad Core")
> >>> that I have access to from head -r312761 to -r313864 and
> >>> ended up with random panics and hang ups in fairly short
> >>> order after booting.
> >>> 
> >>> Some approximate bisecting for the kernel lead to:
> >>> (sometimes getting part way into a buildkernel attempt
> >>> for a different version before a failure happens)
> >>> 
> >>> -r313266: works (just before use of atomic_fcmpset)
> >>> vs.
> >>> -r313271: fails (last of the "use atomic_fcmpset" check-ins)
> >>> 
> >>> (I did not try -r313268 through -r313270 as the use was
> >>> gradually added.)
> >>> 
> >>> So I'm currently running a -r313864 world with a -r313266
> >>> kernel.
> >>> 
> >>> No kernel that I tried that was from before -r313266 had the
> >>> problems.
> >>> 
> >>> Any kernel that I tried that was from after -r313271 had the
> >>> problems.
> >>> 
> >>> Of course I did not try them all in other direction. :)
> >>> 
> >> 
> >> I found that spin mutexes were not properly handling this, fixed in
> >> r313996.
> >> 
> >> Locally I added a if (cpu_tick() % 2) return (0); snipped to amd64
> >> fcmpset to simulate failures. Everything works, while it would easily
> >> fail without the patch.
> >> 
> >> That said, I hope this concludes the 'missing check for not-reread value
> >> of failed fcmpset' saga.
> >> 
> >> -- 
> >> Mateusz Guzik 
> > 
> > I tried to update from -r313864 to -r313999 in my amd64 context
> > (a VirtualBox machine under macOS) but it now crashes late in
> > the boot sequence (after it processes a dump if I make one but
> > before I can log in).
> > 
> > This update was via my usual explicit svnlite update; buildworld
> > buildkernel; etc. production style build of world and kernel,
> > including use of MALLOC_PRODUCTION.
> > 
> > The window shows:
> > 
> > _vm_map_lock+0xf
> > vm_map_wire+0x32
> > rtROMemObjNativeLockInMap+0x8c
> > rtROMemObjNativeLockUser+0x51
> > RTR0MemObjLockUserTag+0x231
> > vbglR0HGCMInternalPreprocessCall+0x65d
> > vbglR0HGCMInternalCall+0x17c
> > vgdrvIoCtl_HGCMCall+0x43f
> > VGDrvCommonIoCtl+0x261
> > vgdrvFreeBSDIOCtl+0x2cd
> > devfs_ioctl+0xae
> > VOP_IOCTL_APV+0x88
> > vn_ioctl+0x161
> > devfs_ioctl_f+0x1f
> > kern_ioctl+0x280
> > sys_ioctl+0x13f
> > amd64_syscall+0x397
> > Xfast_syscall+0xfb
> 
> More detail from booting with the -r313864 kernel.old
> and using kgdb on what the dump produced:
> 
> # kgdb kernel.debug /var/crash/vmcore.
> /var/crash/vmcore.0/var/crash/vmcore.last
> # kgdb kernel.debug /var/crash/vmcore.0
> 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>Starting vboxservice.
> <118>VBoxService 5.1.14 r112924 (verbosity: 0) freebsd.amd64 (Jan 20 2017 
> 18:37:45) release log
> <118>00:00:00.000120 main Log opened 2017-02-20T22:38:46.34808Z
> <118>00:00:00.000162 main OS Product: FreeBSD
> <118>00:00:00.000171 main OS Release: 12.0-CURRENT
> <118>00:00:00.000180 main OS Version: FreeBSD 12.0-CURRENT  r313999M
> <118>00:00:00.000192 main Executable: /usr/local/sbin/VBoxService
> <118>00:00:00.000194 main Process ID: 609
> <118>00:00:00.000196 main Package type: BSD_64BITS_GENERIC (OSE)
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 2; apic id = 02
> fault virtual address   = 0xd6
> fault code  = supervisor read data, page not present
> instruction pointer = 0x20:0x80d4ebaf
> stack pointer   = 0x28:0xfe0122e2bef0
> frame pointer   = 0x28:0xfe0122e2bf00
> 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 = 609 (VBoxService)
> 



> #9  0x80eb6be1 in calltrap () at 
> /usr/src/sys/amd64/amd64/exception.S:236
> #10 0x80d4ebaf in _vm_map_lock (map=0x1, file=0x0, line=0) at 
> /usr/src/sys/vm/vm_map.c:501

The function is:
void
_vm_map_lock(vm_map_t map, const char *file, int line)
{

if (map->system_map)
mtx_lock_flags_(>system_mtx, 0, file, line);
else

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-20 Thread Mark Millard 
On 2017-Feb-20, at 2:58 PM, Mark Millard  wrote:

> On 2017-Feb-20, at 11:10 AM, Mateusz Guzik  wrote:
> 
>> On Sat, Feb 18, 2017 at 04:18:05AM -0800, Mark Millard wrote:
>>> [Note: I experiment with clang based powerpc64 builds,
>>> reporting problems that I find. Justin is familiar
>>> with this, as is Nathan.]
>>> 
>>> I tried to update the PowerMac G5 (a so-called "Quad Core")
>>> that I have access to from head -r312761 to -r313864 and
>>> ended up with random panics and hang ups in fairly short
>>> order after booting.
>>> 
>>> Some approximate bisecting for the kernel lead to:
>>> (sometimes getting part way into a buildkernel attempt
>>> for a different version before a failure happens)
>>> 
>>> -r313266: works (just before use of atomic_fcmpset)
>>> vs.
>>> -r313271: fails (last of the "use atomic_fcmpset" check-ins)
>>> 
>>> (I did not try -r313268 through -r313270 as the use was
>>> gradually added.)
>>> 
>>> So I'm currently running a -r313864 world with a -r313266
>>> kernel.
>>> 
>>> No kernel that I tried that was from before -r313266 had the
>>> problems.
>>> 
>>> Any kernel that I tried that was from after -r313271 had the
>>> problems.
>>> 
>>> Of course I did not try them all in other direction. :)
>>> 
>> 
>> I found that spin mutexes were not properly handling this, fixed in
>> r313996.
>> 
>> Locally I added a if (cpu_tick() % 2) return (0); snipped to amd64
>> fcmpset to simulate failures. Everything works, while it would easily
>> fail without the patch.
>> 
>> That said, I hope this concludes the 'missing check for not-reread value
>> of failed fcmpset' saga.
>> 
>> -- 
>> Mateusz Guzik 
> 
> I tried to update from -r313864 to -r313999 in my amd64 context
> (a VirtualBox machine under macOS) but it now crashes late in
> the boot sequence (after it processes a dump if I make one but
> before I can log in).
> 
> This update was via my usual explicit svnlite update; buildworld
> buildkernel; etc. production style build of world and kernel,
> including use of MALLOC_PRODUCTION.
> 
> The window shows:
> 
> _vm_map_lock+0xf
> vm_map_wire+0x32
> rtROMemObjNativeLockInMap+0x8c
> rtROMemObjNativeLockUser+0x51
> RTR0MemObjLockUserTag+0x231
> vbglR0HGCMInternalPreprocessCall+0x65d
> vbglR0HGCMInternalCall+0x17c
> vgdrvIoCtl_HGCMCall+0x43f
> VGDrvCommonIoCtl+0x261
> vgdrvFreeBSDIOCtl+0x2cd
> devfs_ioctl+0xae
> VOP_IOCTL_APV+0x88
> vn_ioctl+0x161
> devfs_ioctl_f+0x1f
> kern_ioctl+0x280
> sys_ioctl+0x13f
> amd64_syscall+0x397
> Xfast_syscall+0xfb

More detail from booting with the -r313864 kernel.old
and using kgdb on what the dump produced:

# kgdb kernel.debug /var/crash/vmcore.
/var/crash/vmcore.0/var/crash/vmcore.last
# kgdb kernel.debug /var/crash/vmcore.0
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>Starting vboxservice.
<118>VBoxService 5.1.14 r112924 (verbosity: 0) freebsd.amd64 (Jan 20 2017 
18:37:45) release log
<118>00:00:00.000120 main Log opened 2017-02-20T22:38:46.34808Z
<118>00:00:00.000162 main OS Product: FreeBSD
<118>00:00:00.000171 main OS Release: 12.0-CURRENT
<118>00:00:00.000180 main OS Version: FreeBSD 12.0-CURRENT  r313999M
<118>00:00:00.000192 main Executable: /usr/local/sbin/VBoxService
<118>00:00:00.000194 main Process ID: 609
<118>00:00:00.000196 main Package type: BSD_64BITS_GENERIC (OSE)


Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address   = 0xd6
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80d4ebaf
stack pointer   = 0x28:0xfe0122e2bef0
frame pointer   = 0x28:0xfe0122e2bf00
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 = 609 (VBoxService)

Reading symbols from /boot/kernel/zfs.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/zfs.ko.debug...done.
done.
Loaded symbols for /boot/kernel/zfs.ko
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/opensolaris.ko.debug...done.
done.
Loaded symbols for /boot/kernel/opensolaris.ko
Reading symbols from /boot/modules/vboxguest.ko...done.
Loaded symbols for /boot/modules/vboxguest.ko
#0  doadump (textdump=0) at pcpu.h:232
232 __asm("movq %%gs:%1,%0" : "=r" (td)
(kgdb) bt
#0  doadump (textdump=0) at pcpu.h:232
#1  0x8039dd0b in db_dump (dummy=, dummy2=, dummy3=, dummy4=) at 
/usr/src/sys/ddb/db_command.c:546
#2

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-20 Thread Mark Millard 
On 2017-Feb-20, at 11:10 AM, Mateusz Guzik  wrote:

> On Sat, Feb 18, 2017 at 04:18:05AM -0800, Mark Millard wrote:
>> [Note: I experiment with clang based powerpc64 builds,
>> reporting problems that I find. Justin is familiar
>> with this, as is Nathan.]
>> 
>> I tried to update the PowerMac G5 (a so-called "Quad Core")
>> that I have access to from head -r312761 to -r313864 and
>> ended up with random panics and hang ups in fairly short
>> order after booting.
>> 
>> Some approximate bisecting for the kernel lead to:
>> (sometimes getting part way into a buildkernel attempt
>> for a different version before a failure happens)
>> 
>> -r313266: works (just before use of atomic_fcmpset)
>> vs.
>> -r313271: fails (last of the "use atomic_fcmpset" check-ins)
>> 
>> (I did not try -r313268 through -r313270 as the use was
>> gradually added.)
>> 
>> So I'm currently running a -r313864 world with a -r313266
>> kernel.
>> 
>> No kernel that I tried that was from before -r313266 had the
>> problems.
>> 
>> Any kernel that I tried that was from after -r313271 had the
>> problems.
>> 
>> Of course I did not try them all in other direction. :)
>> 
> 
> I found that spin mutexes were not properly handling this, fixed in
> r313996.
> 
> Locally I added a if (cpu_tick() % 2) return (0); snipped to amd64
> fcmpset to simulate failures. Everything works, while it would easily
> fail without the patch.
> 
> That said, I hope this concludes the 'missing check for not-reread value
> of failed fcmpset' saga.
> 
> -- 
> Mateusz Guzik 

I tried to update from -r313864 to -r313999 in my amd64 context
(a VirtualBox machine under macOS) but it now crashes late in
the boot sequence (after it processes a dump if I make one but
before I can log in).

This update was via my usual explicit svnlite update; buildworld
buildkernel; etc. production style build of world and kernel,
including use of MALLOC_PRODUCTION.

The window shows:

_vm_map_lock+0xf
vm_map_wire+0x32
rtROMemObjNativeLockInMap+0x8c
rtROMemObjNativeLockUser+0x51
RTR0MemObjLockUserTag+0x231
vbglR0HGCMInternalPreprocessCall+0x65d
vbglR0HGCMInternalCall+0x17c
vgdrvIoCtl_HGCMCall+0x43f
VGDrvCommonIoCtl+0x261
vgdrvFreeBSDIOCtl+0x2cd
devfs_ioctl+0xae
VOP_IOCTL_APV+0x88
vn_ioctl+0x161
devfs_ioctl_f+0x1f
kern_ioctl+0x280
sys_ioctl+0x13f
amd64_syscall+0x397
Xfast_syscall+0xfb


===
Mark Millard
markmi at dsl-only.net

___
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: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]

2017-02-20 Thread Mateusz Guzik 
On Sat, Feb 18, 2017 at 04:18:05AM -0800, Mark Millard wrote:
> [Note: I experiment with clang based powerpc64 builds,
> reporting problems that I find. Justin is familiar
> with this, as is Nathan.]
> 
> I tried to update the PowerMac G5 (a so-called "Quad Core")
> that I have access to from head -r312761 to -r313864 and
> ended up with random panics and hang ups in fairly short
> order after booting.
> 
> Some approximate bisecting for the kernel lead to:
> (sometimes getting part way into a buildkernel attempt
> for a different version before a failure happens)
> 
> -r313266: works (just before use of atomic_fcmpset)
> vs.
> -r313271: fails (last of the "use atomic_fcmpset" check-ins)
> 
> (I did not try -r313268 through -r313270 as the use was
> gradually added.)
> 
> So I'm currently running a -r313864 world with a -r313266
> kernel.
> 
> No kernel that I tried that was from before -r313266 had the
> problems.
> 
> Any kernel that I tried that was from after -r313271 had the
> problems.
> 
> Of course I did not try them all in other direction. :)
> 

I found that spin mutexes were not properly handling this, fixed in
r313996.

Locally I added a if (cpu_tick() % 2) return (0); snipped to amd64
fcmpset to simulate failures. Everything works, while it would easily
fail without the patch.

That said, I hope this concludes the 'missing check for not-reread value
of failed fcmpset' saga.

-- 
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"

Problem compiling akonadi

2017-02-20 Thread Filippo Moretti 
While trying to compile akonadi I get the following error:
===> Installing for qtchooser-39===> Checking if qtchooser already 
installed===> Registering installation for qtchooser-39 as automaticInstalling 
qtchooser-39...pkg-static: qtchooser-39 conflicts with qt4-dbus-4.8.7 (installs 
files into the same place). Problematic file: /usr/local/bin/qdbus*** Error 
code 70 
Stop.make[5]: stopped in /usr/ports/misc/qtchooser*** Error code 1Stop.make[4]: 
stopped in /usr/ports/devel/qt4-qmake*** Error code 1Stop.make[3]: stopped in 
/usr/ports/devel/qt4-moc*** Error code 1Stop.make[2]: stopped in 
/usr/ports/devel/automoc4*** Error code 1Stop.make[1]: stopped in 
/usr/ports/databases/akonadi*** Error code 1Stop.make: stopped in 
/usr/ports/databases/akonadi 
sincerelyFilippo
___
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: elf_load_section problem

2017-02-20 Thread Steve Kargl 
On Mon, Feb 20, 2017 at 09:04:35AM +0100, Dimitry Andric wrote:
> On 19 Feb 2017, at 21:30, Steve Kargl  
> wrote:
> > ===>  Building for help2man-1.47.4
> > elf_load_section: truncated ELF file
> > Abort trap
> 
> but this looks like a half-written or empty file.  Did you do a full
> fsck, and did you already try cleaning out your work directory?
> 

Yes, I did.  It seems that the perl5.24 port was damaged
during one of the black screens of death events.  Removing
perl5.24 and re-installing seems to have fixed the help2man
problem.

I can 'kldload joy.ko'.  If I try to load any of drm.ko,
drm2.ko, or i915kms.ko.  Instant lock-up.  I have no 
idea how to get any more information about the lock-up.

This laptop, Dell Latitude D530, has worked very well with
FreeBSD with sources from Jan 31th and earlier.  Something
in the last month has been broken.

-- 
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"

Re: major code change for .zfs

2017-02-20 Thread Andriy Gapon 
On 23/08/2016 11:43, Andriy Gapon wrote:
> 
> Please review and test a change to .zfs code that is intended to make the code
> aligned with FreeBSD VFS and, as such, more stable:
> https://reviews.freebsd.org/D7421
> 
> The change removes two features.
> .zfs/shares is gone because it was unused on FreeBSD anyway.  We can restore
> that when we need it.
> An ability to take a snapshot by creating a directory under .zfs/snapshot is
> removed.  I hope that you didn't use it.  Please do not start using it now :-)
> Again, this feature can be restored with some work.
> The reason I removed it is that its companion features of destroying and
> renaming snapshots were already missing on FreeBSD, and properly implementing
> the feature required some more work.

This is a heads-up that I am going to commit the change.
If you have objections or concerns please speak up.
Thanks!

-- 
Andriy Gapon
___
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: elf_load_section problem

2017-02-20 Thread Dimitry Andric 
On 19 Feb 2017, at 21:30, Steve Kargl  wrote:
> 
> Looks like I picked the wrong time to update a month old.
> 
> Problem #1: 'kldload -v i915kms.ko' locks up the system.  No
> panic.  No messages logged.  No keyboard response.  Black
> screen of death.
> 
> Problem #2: 'kldload -v drm2.ko' locks up the system. No panic.
> No messages logged.  No keyboard response.  Black screen of death.
> 
> Problem #3: #1 and #2 along with an update of xorg to 1.18.4
> prevents X from firing up.
> 
> Problem #4: Ok. I re-install everything that X uses and their
> dependencies from source.

I can't help you with these...


> ===>  Building for help2man-1.47.4
> elf_load_section: truncated ELF file
> Abort trap

but this looks like a half-written or empty file.  Did you do a full
fsck, and did you already try cleaning out your work directory?

-Dimitry



signature.asc
Description: Message signed with OpenPGP