Jenkins build is back to stable : FreeBSD_HEAD-tests2 #741

2015-02-21 Thread jenkins-admin
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/741/

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


Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #740

2015-02-21 Thread Garrett Cooper
On Feb 21, 2015, at 9:32, jenkins-ad...@freebsd.org wrote:

 See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/740/

Jamie,
For some odd reason the last couple of commits you did to jail(8) 
rocked the boat again with the pgrep/pkill -j testcases. I’ll look into making 
them work again, but could you please send patches out to CR so I can look at 
them and test them first. I hate the slew of Jenkins failures emails and I’m 
sure there are others who feel the same.
Thanks!


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #740

2015-02-21 Thread Garrett Cooper
On Feb 21, 2015, at 15:23, Garrett Cooper yaneurab...@gmail.com wrote:

 On Feb 21, 2015, at 9:32, jenkins-ad...@freebsd.org wrote:
 
 See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/740/
 
 Jamie,
   For some odd reason the last couple of commits you did to jail(8) 
 rocked the boat again with the pgrep/pkill -j testcases. I’ll look into 
 making them work again, but could you please send patches out to CR so I can 
 look at them and test them first. I hate the slew of Jenkins failures emails 
 and I’m sure there are others who feel the same.
 Thanks!

Forgot to CC Jamie _...


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #740

2015-02-21 Thread Garrett Cooper
On Feb 21, 2015, at 15:35, James Gritton ja...@freebsd.org wrote:

 On 2015-02-21 16:23, Garrett Cooper wrote:
 On Feb 21, 2015, at 9:32, jenkins-ad...@freebsd.org wrote:
 See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/740/
 Jamie,
  For some odd reason the last couple of commits you did to jail(8) 
 rocked the boat again with the pgrep/pkill -j testcases. I’ll look into 
 making them work again, but could you please send patches out to CR so I can 
 look at them and test them first. I hate the slew of Jenkins failures emails 
 and I’m sure there are others who feel the same.
 Thanks!
 
 I'm as much at a loss as I was before, on how the changes I made could have 
 any impact at all.  The two recent commits to jls(8) (didn't touch jail(8)) 
 only matter if you use jls's -v or -s options, neither of which is used in 
 the pkill test case.
 
 As with the previous cycle of failures regarding jail(8), the problems 
 appears not to be the changes I made, but that mere fact that something was 
 committed to those programs.
 
 - Jamie

Not disguising stderr, here’s what pops up:

$ sudo prove -v pgrep-j_test.sh 
pgrep-j_test.sh .. 
1..3
jls: unknown parameter: allow
jls: unknown parameter: allow
jls: unknown parameter: allow
jls: unknown parameter: allow
jls: unknown parameter: allow
jls: unknown parameter: allow
jls: unknown parameter: allow
jls: unknown parameter: allow
jls: unknown parameter: allow
jls: unknown parameter: allow
jls: unknown parameter: allow
jls: unknown parameter: allow
jls: unknown parameter: allow
jls: unknown parameter: allow
jls: unknown parameter: allow
jls: unknown parameter: allow
jls: unknown parameter: allow
jls: unknown parameter: allow
jls: unknown parameter: allow
jls: unknown parameter: allow
usage: pgrep [-LSfilnoqvx] [-d delim] [-F pidfile] [-G gid] [-M core] [-N 
system]
 [-P ppid] [-U uid] [-c class] [-g pgrp] [-j jid]
 [-s sid] [-t tty] [-u euid] pattern ...
not ok 1 - pgrep -j jid # pgrep output: '', pidfile output: '3704 3706'
ok 2 - pgrep -j any


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: panic on application core dump?

2015-02-21 Thread Sean Bruno
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/21/15 13:17, Konstantin Belousov wrote:
 On Sat, Feb 21, 2015 at 12:27:22PM -0800, Sean Bruno wrote:
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
 
 Well, this is new.  It looks like current panic'd when trying to
 dump a core from a qemu crash?  I can leave this at the debugger
 for now as this is a machine doing mips package builds and is not
 production.
 
 sean
 
 Thu Feb 19 18:50:59 UTC 2015
 
 FreeBSD/amd64 (dirty.ysv.freebsd.org) (ttyu0)
 
 login: Feb 20 08:06:05 dirty sshd[51311]: fatal: Read from
 socket failed: Connection reset by peer [preauth] Feb 20 16:47:29
 dirty su: sbruno to root on /dev/pts/1 Feb 21 02:15:44 dirty
 sshd[95051]: fatal: Read from socket failed: Connection reset by
 peer [preauth]
 
 
 Fatal trap 12: page fault while in kernel mode cpuid = 15; apic
 id = 35 fault virtual address   = 0x380 fault code  =
 supervisor read data, page not present instruction pointer =
 0x20:0x809b2ed1 stack pointer   =
 0x28:0xfe046a3a30f0 frame pointer   =
 0x28:0xfe046a3a3170 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 = 42563 (qemu-mips64) [ thread pid 42563
 tid 100956 ] Stopped at  __mtx_lock_sleep+0xb1:  movl
 0x380(%rax),%ecx db bt Tracing pid 42563 tid 100956 td
 0xf80109a214a0 __mtx_lock_sleep() at
 __mtx_lock_sleep+0xb1/frame 0xfe046a3a3170 vref() at
 vref+0x6d/frame 0xfe046a3a31a0 vn_fullpath1() at
 vn_fullpath1+0x62/frame 0xfe046a3a3200 vn_fullpath_global()
 at vn_fullpath_global+0x6e/frame 0xfe046a3a3240 sigexit() at
 sigexit+0xa22/frame 0xfe046a3a34f0 sendsig() at
 sendsig+0x65e/frame 0xfe046a3a3960 trapsignal() at
 trapsignal+0x2f7/frame 0xfe046a3a39e0 trap() at
 trap+0x3ba/frame 0xfe046a3a3bf0 calltrap() at
 calltrap+0x8/frame 0xfe046a3a3bf0 - --- trap 0xc, rip =
 0x600334bc, rsp = 0x7ffbffe19990, rbp = 0x7ffe4a20 --- db p
 vref+0x6d 80a876cd
 
 Err.  Is it easily reproducable in your setup ? The core file vnode
 is indeed unreferenced before notification is sent.
 

Probably not a deterministic crash, but I will get a dump and try out
this change directly today.

sean


 Try this.
 
 diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c index
 41da3dd..57f66b0 100644 --- a/sys/kern/kern_sig.c +++
 b/sys/kern/kern_sig.c @@ -3310,7 +3310,7 @@ coredump(struct thread
 *td) vattr.va_nlink != 1 || (vp-v_vflag  VV_SYSTEM) != 0) { 
 VOP_UNLOCK(vp, 0); error = EFAULT; -  goto close; +   goto 
 out; }
 
 VOP_UNLOCK(vp, 0); @@ -3347,17 +3347,12 @@ coredump(struct thread
 *td) VOP_ADVLOCK(vp, (caddr_t)p, F_UNLCK, lf, F_FLOCK); } 
 vn_rangelock_unlock(vp, rl_cookie); -close: - error1 = vn_close(vp,
 FWRITE, cred, td); -  if (error == 0) -   error = error1; -   
 else -
 goto out; + /* * Notify the userland helper that a process
 triggered a core dump. * This allows the helper to run an automated
 debugging session. */ -   if (coredump_devctl == 0) + if (error != 0
 || coredump_devctl == 0) goto out; len = MAXPATHLEN * 2 +
 sizeof(comm_name) - 1 + sizeof(' ') + sizeof(core_name) - 1; @@
 -3377,6 +3372,9 @@ close: strlcat(data, fullpath, len); 
 devctl_notify(kernel, signal, coredump, data); out: +   error1
 = vn_close(vp, FWRITE, cred, td); +   if (error == 0) +   error =
 error1; #ifdef AUDIT audit_proc_coredump(td, name, error); #endif
 
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQF8BAEBCgBmBQJU6SdJXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx
MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kZlIH/0usK1j2BfzNT95UFE6KAoUv
0+JqmkJyGiR9hEQvvgcSiL9++NXnTLLz1z5SGbwAqL0hebXYckLXhxusObENBnnK
ZMz12bsFmAI615eXK6ZJjsnZJWzmU/tjQjcY93Rao0M+AUTaGk5PFoR486hjhSM+
7lg4KA+BlD5K991Zy9BzR0ZGSkjRnuZSQBsKbHe1RGbS1SAsf4PyfpvXDt0lhfN9
E/C2uvehYbBJi3vJuJx3pVXg5s+uyutnGLjBRY/sqOuiDOuGfHFdKbdgtApIAc0o
B0/3I2IbAx3q0zy9c/4nuKjKHbr+di2pbFymUAH8beHcBuo5wsNFvfGTOqiX5ro=
=nlAC
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Pluggable frame buffer devices

2015-02-21 Thread Shawn Webb
On Friday, February 20, 2015 09:29:20 AM Hans Petter Selasky wrote:
 On 02/20/15 02:15, Shawn Webb wrote:
  On Thursday, February 19, 2015 07:04:50 PM Shawn Webb wrote:
  On Sunday, February 15, 2015 11:14:47 PM Hans Petter Selasky wrote:
  Hi,
  
  I've added support for USB display link adapters to FreeBSD-11-current,
  but the kernel panics once vt_fb_attach(info) is called from
  fbd_register(struct fb_info* info) when the USB device is plugged or
  udl.ko is loaded. Is this a known issue?
  
  REF: https://svnweb.freebsd.org/base/head/sys/dev/usb/video/udl.c
  
  --HPS
  
  I just bought a DisplayLink adapter that's compatible. Compiling a new
 
  kernel with device udl brings this error:
 Hi,
 
 You need to also build the sys/modules/videomode and install and kldload.
 
 Does your device need a power supply?
 
 Can you plug the device through an external USB HUB after boot?
 
 Also you need some VT patches, before it will attach to VT which I can
 send you. See attachment.
 
 Beware the unplugging the device is not supported. It will crash / panic
 which needs to be resolved.
 
 --HPS

(FYI: I'm switching email accounts from latt...@gmail.com to 
shawn.w...@hardenedbsd.org)

So I'm a little unsure how to test this. Could you provide some instructions?

I bought this device: http://www.iogear.com/support/dm/driver/GUC2020DW6
It's listed in udl.c as supported: 
https://svnweb.freebsd.org/base/head/sys/dev/usb/video/udl.c?revision=278852view=markup#l151

What kind of setup should I have in my xorg.conf to tell xorg to use that 
instead of the built-in laptop display? Can you provide an example xorg.conf?

-- 
Shawn Webb
HardenedBSD

GPG Key ID:0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE

signature.asc
Description: This is a digitally signed message part.


Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #740

2015-02-21 Thread Garrett Cooper
On Feb 21, 2015, at 15:38, Garrett Cooper yaneurab...@gmail.com wrote:

 On Feb 21, 2015, at 15:35, James Gritton ja...@freebsd.org wrote:
 
 On 2015-02-21 16:23, Garrett Cooper wrote:
 On Feb 21, 2015, at 9:32, jenkins-ad...@freebsd.org wrote:
 See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/740/
 Jamie,
 For some odd reason the last couple of commits you did to jail(8) 
 rocked the boat again with the pgrep/pkill -j testcases. I’ll look into 
 making them work again, but could you please send patches out to CR so I 
 can look at them and test them first. I hate the slew of Jenkins failures 
 emails and I’m sure there are others who feel the same.
 Thanks!
 
 I'm as much at a loss as I was before, on how the changes I made could have 
 any impact at all.  The two recent commits to jls(8) (didn't touch jail(8)) 
 only matter if you use jls's -v or -s options, neither of which is used in 
 the pkill test case.
 
 As with the previous cycle of failures regarding jail(8), the problems 
 appears not to be the changes I made, but that mere fact that something was 
 committed to those programs.
 
 - Jamie
 
 Not disguising stderr, here’s what pops up:
 
 $ sudo prove -v pgrep-j_test.sh 
 pgrep-j_test.sh .. 
 1..3
 jls: unknown parameter: allow
 jls: unknown parameter: allow
 jls: unknown parameter: allow
 jls: unknown parameter: allow
 jls: unknown parameter: allow
 jls: unknown parameter: allow
 jls: unknown parameter: allow
 jls: unknown parameter: allow
 jls: unknown parameter: allow
 jls: unknown parameter: allow
 jls: unknown parameter: allow
 jls: unknown parameter: allow
 jls: unknown parameter: allow
 jls: unknown parameter: allow
 jls: unknown parameter: allow
 jls: unknown parameter: allow
 jls: unknown parameter: allow
 jls: unknown parameter: allow
 jls: unknown parameter: allow
 jls: unknown parameter: allow
 usage: pgrep [-LSfilnoqvx] [-d delim] [-F pidfile] [-G gid] [-M core] [-N 
 system]
 [-P ppid] [-U uid] [-c class] [-g pgrp] [-j jid]
 [-s sid] [-t tty] [-u euid] pattern ...
 not ok 1 - pgrep -j jid # pgrep output: '', pidfile output: '3704 3706'
 ok 2 - pgrep -j any

You broke parsing dotted parameters in r279083.
Thanks,



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: [CFT] Remove NIS

2015-02-21 Thread Kevin Oberman
On Sat, Feb 21, 2015 at 10:30 AM, Pedro Giffuni p...@freebsd.org wrote:

 Eh ...

 No, I am not planning to remove NIS, au contraire, but now
 that I got your attention ...


Darn! Got my hopes up and dashed them! :-)
--
Kevin Oberman, Network Engineer, Retired
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


msk0 watchdog timeout Marvel 88E8071

2015-02-21 Thread Roosevelt Littleton
My msk0 is not even functional and my wifi is my only usable connection to
the internet.
 I have this in my loader.conf: hw.msk.msi_disable=1 hw.pci.enable_msix=0
and this in my sysctl.conf net.inet.tcp.tso=0

vmstat -i
interrupt  total   rate
irq1: atkbd0 552  1
irq9: acpi0 2561  3
irq12: psm0 2322  3
irq16: mskc0 2104711   2572
irq20: hpet0 uhci0*   133497163
irq256: vgapci0  970  1
irq257: hdac0   7680  9
irq259: ahci0:ch0526  1
irq260: ahci0:ch1 100128122
irq264: ahci0:ch5   1739  2
Total2354686   2878



dmesg
Copyright (c) 1992-2015 The FreeBSD Project.
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 11.0-CURRENT #0 r279013: Thu Feb 19 22:30:02 EST 2015
root@Mizraim:/usr/obj/usr/src/sys/ZENNLA amd64
FreeBSD clang version 3.5.1 (tags/RELEASE_351/final 225668) 20150115
VT: running with driver vga.
module_register: module pci/mskc already exists!
Module pci/mskc failed to register: 17
module_register: module mskc/msk already exists!
Module mskc/msk failed to register: 17
module_register: module msk/miibus already exists!
Module msk/miibus failed to register: 17
CPU: Intel(R) Core(TM)2 Duo CPU P8400  @ 2.26GHz (2261.05-MHz K8-class
CPU)
  Origin=GenuineIntel  Id=0x10676  Family=0x6  Model=0x17  Stepping=6

Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE

Features2=0x8e3fdSSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1
  AMD Features=0x20100800SYSCALL,NX,LM
  AMD Features2=0x1LAHF
  VT-x: HLT,PAUSE
  TSC: P-state invariant, performance statistics
real memory  = 4294967296 (4096 MB)
avail memory = 4076457984 (3887 MB)
Event timer LAPIC quality 400
ACPI APIC Table: PTLTD   APIC  
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ioapic0 Version 2.0 irqs 0-23 on motherboard
random: entropy device infrastructure driver
random: selecting highest priority adaptor Dummy
kbd1 at kbdmux0
module_register_init: MOD_LOAD (vesa, 0x80e77bc0, 0) error 19
netmap: loaded module
random: SOFT: yarrow init()
random: selecting highest priority adaptor Yarrow
vtvga0: VT VGA driver on motherboard
acpi0: GATEWA SYSTEM on motherboard
acpi0: Power Button (fixed)
Timecounter HPET frequency 14318180 Hz quality 950
Event timer HPET frequency 14318180 Hz quality 450
Event timer HPET1 frequency 14318180 Hz quality 440
Event timer HPET2 frequency 14318180 Hz quality 440
Event timer HPET3 frequency 14318180 Hz quality 440
cpu0: ACPI CPU on acpi0
cpu1: ACPI CPU on acpi0
atrtc0: AT realtime clock port 0x70-0x77 irq 8 on acpi0
atrtc0: Warning: Couldn't map I/O.
Event timer RTC frequency 32768 Hz quality 0
attimer0: AT timer port 0x40-0x43,0x50-0x53 irq 0 on acpi0
Timecounter i8254 frequency 1193182 Hz quality 0
Event timer i8254 frequency 1193182 Hz quality 100
Timecounter ACPI-fast frequency 3579545 Hz quality 900
acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0
acpi_ec0: Embedded Controller: GPE 0x17 port 0x62,0x66 on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pcib1: ACPI PCI-PCI bridge irq 16 at device 1.0 on pci0
pci1: ACPI PCI bus on pcib1
vgapci0: VGA-compatible display port 0x2000-0x207f mem
0xf200-0xf2ff,0xd000-0xdfff,0xf000-0xf1ff irq 16 at
device 0.0 on pci1
nvidia0: GeForce 9800M GTS on vgapci0
vgapci0: child nvidia0 requested pci_enable_io
vgapci0: child nvidia0 requested pci_enable_io
vgapci0: Boot video device
uhci0: Intel 82801I (ICH9) USB controller port 0x1800-0x181f irq 20 at
device 26.0 on pci0
usbus0 on uhci0
uhci1: Intel 82801I (ICH9) USB controller port 0x1820-0x183f irq 20 at
device 26.1 on pci0
usbus1 on uhci1
uhci2: Intel 82801I (ICH9) USB controller port 0x1840-0x185f irq 20 at
device 26.2 on pci0
usbus2 on uhci2
ehci0: Intel 82801I (ICH9) USB 2.0 controller mem 0xf3504800-0xf3504bff
irq 20 at device 26.7 on pci0
usbus3: EHCI version 1.0
usbus3 on ehci0
hdac0: Intel 82801I HDA Controller mem 0xf350-0xf3503fff irq 21 at
device 27.0 on pci0
pcib2: ACPI PCI-PCI bridge irq 16 at device 28.0 on pci0
pci2: ACPI PCI bus on pcib2
mskc0: Marvell Yukon 88E8071 Gigabit Ethernet port 0x3000-0x30ff mem
0xf300-0xf3003fff irq 16 at device 0.0 on pci2
msk0: Marvell Technology Group Ltd. Yukon EX Id 0xb5 Rev 0x02 on mskc0
msk0: Using defaults for TSO: 65518/35/2048
msk0: Ethernet address: 00:1d:72:ed:56:80
miibus0: MII bus on msk0

Jenkins build is still unstable: FreeBSD_HEAD-tests2 #739

2015-02-21 Thread jenkins-admin
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/739/

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


CFT: New ASLR Patch

2015-02-21 Thread Shawn Webb
Hey All,

It has been a long time since we sent out a call for testing request for our 
ASLR patch. We've been hard at work making our ASLR implementation as robust 
as possible. We'd like to invite all adventurous souls to test our ASLR 
implementation. Put it through the ringer.

Since the patch is much too large to attach to an email, you can find our 
latest patch on FreeBSD's Phabricator:

https://reviews.freebsd.org/D473

Or download the raw version of the patch:
https://reviews.freebsd.org/D473?download=true

Please let me know if you find any issues.

Thanks,

Shawn Webb
HardenedBSD

signature.asc
Description: This is a digitally signed message part.


Jenkins build is still unstable: FreeBSD_HEAD-tests2 #740

2015-02-21 Thread jenkins-admin
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/740/

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


[CFT] Remove NIS

2015-02-21 Thread Pedro Giffuni

Eh ...

No, I am not planning to remove NIS, au contraire, but now
that I got your attention ...

We have a couple of long standing (2001) NIS-related issues
with patches and I am willing to do something about it.
Please test:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=26486
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=31981

Thanks in advance,

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


Re: panic on application core dump?

2015-02-21 Thread Konstantin Belousov
On Sat, Feb 21, 2015 at 12:27:22PM -0800, Sean Bruno wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 Well, this is new.  It looks like current panic'd when trying to dump a
 core from a qemu crash?  I can leave this at the debugger for now as
 this is a machine doing mips package builds and is not production.
 
 sean
 
 Thu Feb 19 18:50:59 UTC 2015
 
 FreeBSD/amd64 (dirty.ysv.freebsd.org) (ttyu0)
 
 login: Feb 20 08:06:05 dirty sshd[51311]: fatal: Read from socket
 failed: Connection reset by peer [preauth]
 Feb 20 16:47:29 dirty su: sbruno to root on /dev/pts/1
 Feb 21 02:15:44 dirty sshd[95051]: fatal: Read from socket failed:
 Connection reset by peer [preauth]
 
 
 Fatal trap 12: page fault while in kernel mode
 cpuid = 15; apic id = 35
 fault virtual address   = 0x380
 fault code  = supervisor read data, page not present
 instruction pointer = 0x20:0x809b2ed1
 stack pointer   = 0x28:0xfe046a3a30f0
 frame pointer   = 0x28:0xfe046a3a3170
 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 = 42563 (qemu-mips64)
 [ thread pid 42563 tid 100956 ]
 Stopped at  __mtx_lock_sleep+0xb1:  movl0x380(%rax),%ecx
 db bt
 Tracing pid 42563 tid 100956 td 0xf80109a214a0
 __mtx_lock_sleep() at __mtx_lock_sleep+0xb1/frame 0xfe046a3a3170
 vref() at vref+0x6d/frame 0xfe046a3a31a0
 vn_fullpath1() at vn_fullpath1+0x62/frame 0xfe046a3a3200
 vn_fullpath_global() at vn_fullpath_global+0x6e/frame 0xfe046a3a3240
 sigexit() at sigexit+0xa22/frame 0xfe046a3a34f0
 sendsig() at sendsig+0x65e/frame 0xfe046a3a3960
 trapsignal() at trapsignal+0x2f7/frame 0xfe046a3a39e0
 trap() at trap+0x3ba/frame 0xfe046a3a3bf0
 calltrap() at calltrap+0x8/frame 0xfe046a3a3bf0
 - --- trap 0xc, rip = 0x600334bc, rsp = 0x7ffbffe19990, rbp =
 0x7ffe4a20 ---
 db p vref+0x6d
 80a876cd

Err.  Is it easily reproducable in your setup ?
The core file vnode is indeed unreferenced before notification is sent.

Try this.

diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c
index 41da3dd..57f66b0 100644
--- a/sys/kern/kern_sig.c
+++ b/sys/kern/kern_sig.c
@@ -3310,7 +3310,7 @@ coredump(struct thread *td)
vattr.va_nlink != 1 || (vp-v_vflag  VV_SYSTEM) != 0) {
VOP_UNLOCK(vp, 0);
error = EFAULT;
-   goto close;
+   goto out;
}
 
VOP_UNLOCK(vp, 0);
@@ -3347,17 +3347,12 @@ coredump(struct thread *td)
VOP_ADVLOCK(vp, (caddr_t)p, F_UNLCK, lf, F_FLOCK);
}
vn_rangelock_unlock(vp, rl_cookie);
-close:
-   error1 = vn_close(vp, FWRITE, cred, td);
-   if (error == 0)
-   error = error1;
-   else
-   goto out;
+
/*
 * Notify the userland helper that a process triggered a core dump.
 * This allows the helper to run an automated debugging session.
 */
-   if (coredump_devctl == 0)
+   if (error != 0 || coredump_devctl == 0)
goto out;
len = MAXPATHLEN * 2 + sizeof(comm_name) - 1 +
sizeof(' ') + sizeof(core_name) - 1;
@@ -3377,6 +3372,9 @@ close:
strlcat(data, fullpath, len);
devctl_notify(kernel, signal, coredump, data);
 out:
+   error1 = vn_close(vp, FWRITE, cred, td);
+   if (error == 0)
+   error = error1;
 #ifdef AUDIT
audit_proc_coredump(td, name, error);
 #endif
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


panic on application core dump?

2015-02-21 Thread Sean Bruno

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Well, this is new.  It looks like current panic'd when trying to dump a
core from a qemu crash?  I can leave this at the debugger for now as
this is a machine doing mips package builds and is not production.

sean

Thu Feb 19 18:50:59 UTC 2015

FreeBSD/amd64 (dirty.ysv.freebsd.org) (ttyu0)

login: Feb 20 08:06:05 dirty sshd[51311]: fatal: Read from socket
failed: Connection reset by peer [preauth]
Feb 20 16:47:29 dirty su: sbruno to root on /dev/pts/1
Feb 21 02:15:44 dirty sshd[95051]: fatal: Read from socket failed:
Connection reset by peer [preauth]


Fatal trap 12: page fault while in kernel mode
cpuid = 15; apic id = 35
fault virtual address   = 0x380
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x809b2ed1
stack pointer   = 0x28:0xfe046a3a30f0
frame pointer   = 0x28:0xfe046a3a3170
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 = 42563 (qemu-mips64)
[ thread pid 42563 tid 100956 ]
Stopped at  __mtx_lock_sleep+0xb1:  movl0x380(%rax),%ecx
db bt
Tracing pid 42563 tid 100956 td 0xf80109a214a0
__mtx_lock_sleep() at __mtx_lock_sleep+0xb1/frame 0xfe046a3a3170
vref() at vref+0x6d/frame 0xfe046a3a31a0
vn_fullpath1() at vn_fullpath1+0x62/frame 0xfe046a3a3200
vn_fullpath_global() at vn_fullpath_global+0x6e/frame 0xfe046a3a3240
sigexit() at sigexit+0xa22/frame 0xfe046a3a34f0
sendsig() at sendsig+0x65e/frame 0xfe046a3a3960
trapsignal() at trapsignal+0x2f7/frame 0xfe046a3a39e0
trap() at trap+0x3ba/frame 0xfe046a3a3bf0
calltrap() at calltrap+0x8/frame 0xfe046a3a3bf0
- --- trap 0xc, rip = 0x600334bc, rsp = 0x7ffbffe19990, rbp =
0x7ffe4a20 ---
db p vref+0x6d
80a876cd

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQF8BAEBCgBmBQJU6OonXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx
MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5k/d8IANC2xfQm9xp/g/sa2R5alFs3
MHBFfk/QyyZCfKShX8aBkfKBUOIB/VJAR3QHoU1EXpBmL9xRZcTWvZFB3Tvt/hZS
S6EJJqW51CjAHVry20yd3lObjQ2ltMtpQ+UhMnNO43wzzLXaGeyPBghLqsPrrYpT
qTlRnOdxP610eDSy/PuziSn/1foohvw1IgdbU4NljA0PRCtj4SPybNuznWYKrcZF
6Lbphw+yRp6KBTYsm3nZMZVVR8j/232cX/Hqc3Ptay9yI8BJTb3tDji0XwxPRm6k
aTQFN86/Yc1gMeg57igj1kq6+xS7hALuhaT/3ZdagTCjiAcP0OOUceeyqOoBofk=
=ni1d
-END PGP SIGNATURE-

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