Jenkins build is still unstable: FreeBSD_HEAD-tests2 #238
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/238/ ___ 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
Jenkins build is still unstable: FreeBSD_HEAD-tests2 #239
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/239/ ___ 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
USB locks up system -- WAS Re: shutdown or acpi problem
On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: I have a kernel/world from r274273 sources, which is exhibiting a new issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' work. I get to the end of shutdown and see for example All buffers synced Uptime: 4h23m15s and then the laptop just sits there. It does not power off with the -p option nor does it reboot with the -r. Has anyone else seen this behavior? The problem appears to be related to a recent change in the USB stack. If I have the following drive plugged into a usb port, the above behavior is observed on shutdown. ugen6.2: Western Digital at usbus6 umass0: MSC Bulk-Only Transport on usbus6 da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: WD My Passport 0748 1019 Fixed Direct Access SCSI-6 device da0: Serial Number 57584B314537324445595A31 da0: 40.000MB/s transfers da0: 1907697MB (3906963456 512 byte sectors: 255H 63S/T 243197C) da0: quirks=0x2NO_6_BYTE ses1 at umass-sim0 bus 0 scbus4 target 0 lun 1 ses1: WD SES Device 1019 Fixed Enclosure Services SCSI-6 device ses1: Serial Number 57584B314537324445595A31 ses1: 40.000MB/s transfers ses1: SCSI-3 ENC Device If this drive was never plugged into a usb port, 'shutdown -r now' and 'shutdown -p now' work as expected. If drive is plugged into a usb port, and I then unplug the drive the laptop is turned into a brick. In a vt(4) console, there is no keyboard and no output is displayed to the console. Logging into the laptop with ssh works. With the laptop in a brick state, issuing 'usbconfig' yields a wedged process with no output to the terminal and 'usbconfig' is unkillable. ^T yields load: 0.30 cmd: usbconfig 1068 [USB config SX lock] 441.15r 0.00u 0.00s 1884k. Unfortunately, a 'gdb -p 1068' yields a core dump for gdb. :( Logging into the laptop again with ssh works. Issuing the command 'camcontrol rescan all' yields Re-scan of bus 4 returned error 0xa Re-scan of bus 0 was successful Re-scan of bus 1 was successful Re-scan of bus 2 was successful Re-scan of bus 3 was successful dmesg follows my sig. -- Steve Copyright (c) 1992-2014 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 r274456: Thu Nov 13 07:45:01 PST 2014 ka...@laptop-kargl.apl.washington.edu:/usr/obj/usr/src/sys/MOBILE i386 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 VT: running with driver vga. 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=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=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x2000LM AMD Features2=0x1LAHF VT-x: (disabled in BIOS) HLT,PAUSE TSC: P-state invariant, performance statistics real memory = 3221225472 (3072 MB) avail memory = 3136098304 (2990 MB) Event timer LAPIC quality 400 ACPI APIC Table: DELL M08 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: Changing APIC ID to 2 ioapic0 Version 2.0 irqs 0-23 on motherboard random: entropy device infrastructure driver random: selecting highest priority adaptor Dummy kbd1 at kbdmux0 random: SOFT: yarrow init() random: selecting highest priority adaptor Yarrow module_register_init: MOD_LOAD (vesa, 0xc0b3a4e0, 0) error 19 acpi0: DELL M08 on motherboard hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 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 acpi0: reservation of 0, 9f000 (3) failed acpi0: reservation of 10, bf5c0400 (3) failed cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 atrtc0: AT realtime clock port 0x70-0x71,0x72-0x77 irq 8 on acpi0 Event timer RTC frequency 32768 Hz quality 0 attimer0: AT timer 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-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 vgapci0: VGA-compatible display port 0xeff8-0xefff mem 0xfea0-0xfeaf,0xe000-0xefff irq 16 at device 2.0 on pci0 vgapci0: Boot video device vgapci1: VGA-compatible display mem 0xfeb0-0xfebf at device 2.1 on pci0 uhci0: Intel 82801H (ICH8) USB controller USB-D port 0x6f20-0x6f3f irq 20 at device 26.0 on pci0 usbus0 on uhci0 uhci1:
[patch] Wrong assertion in kern_umtx.c
There is a [practically] tautological assertion in kern_umtx.c. I have
not even compile-tested the following patch. I'll test it when I have
time. I'd be grateful if someone beats me to it.
Eric
diff --git a/sys/kern/kern_umtx.c b/sys/kern/kern_umtx.c
index 33fdf71..c6b42c0 100644
--- a/sys/kern/kern_umtx.c
+++ b/sys/kern/kern_umtx.c
@@ -169,7 +169,7 @@ struct umtxq_chain {
};
#defineUMTXQ_LOCKED_ASSERT(uc)
mtx_assert((uc)-uc_lock, MA_OWNED)
-#defineUMTXQ_BUSY_ASSERT(uc) KASSERT((uc)-uc_busy, (umtx
chain is not busy))
+#defineUMTXQ_BUSY_ASSERT(uc) KASSERT((uc)-uc_busy, (umtx
chain is not busy))
/*
* Don't propagate time-sharing priority, there is a security reason,
___
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: USB locks up system -- WAS Re: shutdown or acpi problem
CCing hps and mav.. On Nov 13, 2014, at 09:25, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: I have a kernel/world from r274273 sources, which is exhibiting a new issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' work. I get to the end of shutdown and see for example All buffers synced Uptime: 4h23m15s and then the laptop just sits there. It does not power off with the -p option nor does it reboot with the -r. Has anyone else seen this behavior? The problem appears to be related to a recent change in the USB stack. If I have the following drive plugged into a usb port, the above behavior is observed on shutdown. ugen6.2: Western Digital at usbus6 umass0: MSC Bulk-Only Transport on usbus6 da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: WD My Passport 0748 1019 Fixed Direct Access SCSI-6 device da0: Serial Number 57584B314537324445595A31 da0: 40.000MB/s transfers da0: 1907697MB (3906963456 512 byte sectors: 255H 63S/T 243197C) da0: quirks=0x2NO_6_BYTE ses1 at umass-sim0 bus 0 scbus4 target 0 lun 1 ses1: WD SES Device 1019 Fixed Enclosure Services SCSI-6 device ses1: Serial Number 57584B314537324445595A31 ses1: 40.000MB/s transfers ses1: SCSI-3 ENC Device If this drive was never plugged into a usb port, 'shutdown -r now' and 'shutdown -p now' work as expected. If drive is plugged into a usb port, and I then unplug the drive the laptop is turned into a brick. In a vt(4) console, there is no keyboard and no output is displayed to the console. Logging into the laptop with ssh works. With the laptop in a brick state, issuing 'usbconfig' yields a wedged process with no output to the terminal and 'usbconfig' is unkillable. ^T yields load: 0.30 cmd: usbconfig 1068 [USB config SX lock] 441.15r 0.00u 0.00s 1884k. Unfortunately, a 'gdb -p 1068' yields a core dump for gdb. :( Logging into the laptop again with ssh works. Issuing the command 'camcontrol rescan all' yields Re-scan of bus 4 returned error 0xa Re-scan of bus 0 was successful Re-scan of bus 1 was successful Re-scan of bus 2 was successful Re-scan of bus 3 was successful dmesg follows my sig. -- Steve Copyright (c) 1992-2014 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 r274456: Thu Nov 13 07:45:01 PST 2014 ka...@laptop-kargl.apl.washington.edu:/usr/obj/usr/src/sys/MOBILE i386 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 VT: running with driver vga. 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=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=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x2000LM AMD Features2=0x1LAHF VT-x: (disabled in BIOS) HLT,PAUSE TSC: P-state invariant, performance statistics real memory = 3221225472 (3072 MB) avail memory = 3136098304 (2990 MB) Event timer LAPIC quality 400 ACPI APIC Table: DELL M08 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: Changing APIC ID to 2 ioapic0 Version 2.0 irqs 0-23 on motherboard random: entropy device infrastructure driver random: selecting highest priority adaptor Dummy kbd1 at kbdmux0 random: SOFT: yarrow init() random: selecting highest priority adaptor Yarrow module_register_init: MOD_LOAD (vesa, 0xc0b3a4e0, 0) error 19 acpi0: DELL M08 on motherboard hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 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 acpi0: reservation of 0, 9f000 (3) failed acpi0: reservation of 10, bf5c0400 (3) failed cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 atrtc0: AT realtime clock port 0x70-0x71,0x72-0x77 irq 8 on acpi0 Event timer RTC frequency 32768 Hz quality 0 attimer0: AT timer 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-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 vgapci0: VGA-compatible display port 0xeff8-0xefff mem 0xfea0-0xfeaf,0xe000-0xefff irq 16 at device 2.0 on pci0 vgapci0: Boot video device
Jenkins build is still unstable: FreeBSD_HEAD-tests2 #240
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/240/ ___ 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: USB locks up system -- WAS Re: shutdown or acpi problem
On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote: On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: I have a kernel/world from r274273 sources, which is exhibiting a new issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' work. I get to the end of shutdown and see for example All buffers synced Uptime: 4h23m15s and then the laptop just sits there. It does not power off with the -p option nor does it reboot with the -r. Has anyone else seen this behavior? The problem appears to be related to a recent change in the USB stack. If I have the following drive plugged into a usb port, the above behavior is observed on shutdown. ugen6.2: Western Digital at usbus6 umass0: MSC Bulk-Only Transport on usbus6 da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: WD My Passport 0748 1019 Fixed Direct Access SCSI-6 device da0: Serial Number 57584B314537324445595A31 da0: 40.000MB/s transfers da0: 1907697MB (3906963456 512 byte sectors: 255H 63S/T 243197C) da0: quirks=0x2NO_6_BYTE ses1 at umass-sim0 bus 0 scbus4 target 0 lun 1 ses1: WD SES Device 1019 Fixed Enclosure Services SCSI-6 device ses1: Serial Number 57584B314537324445595A31 ses1: 40.000MB/s transfers ses1: SCSI-3 ENC Device The problem is not restricted to hte WD My Passport drive. The memstick ugen6.2: USBest Technology at usbus6 umass0: USBest Technology USB Mass Storage Device, class 0/0, rev 2.00/1.00, addr 2 on usbus6 da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: 0.00 Removable Direct Access SCSI-2 device da0: Serial Number 08102201c42413 da0: 40.000MB/s transfers da0: 963MB (1974271 512 byte sectors: 64H 32S/T 963C) da0: quirks=0x2NO_6_BYTE will also cause the system to wedge when removed. I failed to report that /dev/da0, /dev/da0s1, /dev/da0s1a, etc were not destroyed when the WD My Passport was removed. -- Steve ___ 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
gcc48-4.8.4.s20141030.txz: Forbidden?!
OK. I'm on 11 (r274393 amd64, custom kernel. fresh world) svn info /usr/ports -- r372460 src, and make.conf were both empty. While building a port, lang/gcc48, and lang/gcc-ecj45 were sucked in as dependency. During the building of one of them (ecj45?) I noticed a (core dumped). I was unable to capture the context of the event. But decided to make deinstall both. Followed by a pkg install of both. The ecj45 installed w/o issue. But gcc48 failed with gcc48-4.8.4.s20141030.txz: Forbidden. Why? Thank you for all your time, and consideration. --Chris ___ 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: USB locks up system -- WAS Re: shutdown or acpi problem
On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote: On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote: On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: I have a kernel/world from r274273 sources, which is exhibiting a new issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' work. I get to the end of shutdown and see for example All buffers synced Uptime: 4h23m15s and then the laptop just sits there. It does not power off with the -p option nor does it reboot with the -r. Has anyone else seen this behavior? The problem appears to be related to a recent change in the USB stack. If I have the following drive plugged into a usb port, the above behavior is observed on shutdown. Adding hw.usb.no_shutdown_wait: 1 to /boot/loader.conf appears to work around the 'shutdown -p now' and 'shutdown -r now' issue. Unfortunately, the bricking of the laptop is not affected by this sysctl. Once a device is plugged into a usb, it must remain plugged in. -- Steve ___ 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: Minor bug in SCSI definition
On 13.11.2014 05:44, NGie Cooper wrote: On Wed, Nov 12, 2014 at 7:30 PM, Rang, Anton anton.r...@isilon.com wrote: Coverity found an issue in this area which I tracked down to the incorrect definition patched below. The SID_QUAL macro is (((inq_data)-device 0xE0) 5) which extracts the peripheral qualifier. Per SCSI-2 (draft 10L) table 46, the vendor-specific values are 1XXb. This probably affects almost nobody, but it will clear up a couple of Coverity warnings. Anton Index: sys/cam/scsi/scsi_all.h === --- sys/cam/scsi/scsi_all.h (revision 274352) +++ sys/cam/scsi/scsi_all.h (working copy) @@ -1817,7 +1817,7 @@ * reserved for this peripheral * qualifier. */ -#define SID_QUAL_IS_VENDOR_UNIQUE(inq_data) ((SID_QUAL(inq_data) 0x08) != 0) +#define SID_QUAL_IS_VENDOR_UNIQUE(inq_data) ((SID_QUAL(inq_data) 0x04) != 0) u_int8_t dev_qual2; #define SID_QUAL2 0x7F #define SID_LU_CONG0x40 CCing ken@/mav@/scottl@ -- thanks! Looks good to me. Committed it to head at r274477. Thank you! -- Alexander Motin ___ 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: [patch] Wrong assertion in kern_umtx.c
On Thu, Nov 13, 2014 at 12:39:40PM -0500, Eric van Gyzen wrote:
There is a [practically] tautological assertion in kern_umtx.c. I have
not even compile-tested the following patch. I'll test it when I have
time. I'd be grateful if someone beats me to it.
Eric
diff --git a/sys/kern/kern_umtx.c b/sys/kern/kern_umtx.c
index 33fdf71..c6b42c0 100644
--- a/sys/kern/kern_umtx.c
+++ b/sys/kern/kern_umtx.c
@@ -169,7 +169,7 @@ struct umtxq_chain {
};
#defineUMTXQ_LOCKED_ASSERT(uc)
mtx_assert((uc)-uc_lock, MA_OWNED)
-#defineUMTXQ_BUSY_ASSERT(uc) KASSERT((uc)-uc_busy, (umtx
chain is not busy))
+#defineUMTXQ_BUSY_ASSERT(uc) KASSERT((uc)-uc_busy, (umtx
chain is not busy))
/*
* Don't propagate time-sharing priority, there is a security reason,
Yes, I tested it, thanks for the submission.
I committed r274478, and I decided to remove macro used in single place,
at all. There is one more place, which I added several weeks ago, but
I really do not see much point in using the macro, it obfuscates the code.
___
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: gcc48-4.8.4.s20141030.txz: Forbidden?!
On 11/13/2014 12:04 PM, Chris H wrote: OK. I'm on 11 (r274393 amd64, custom kernel. fresh world) svn info /usr/ports -- r372460 src, and make.conf were both empty. While building a port, lang/gcc48, and lang/gcc-ecj45 were sucked in as dependency. During the building of one of them (ecj45?) I noticed a (core dumped). I was unable to capture the context of the event. But decided to make deinstall both. Followed by a pkg install of both. The ecj45 installed w/o issue. But gcc48 failed with gcc48-4.8.4.s20141030.txz: Forbidden. Why? Thank you for all your time, and consideration. Was this error from 'pkg install' during the fetch phase? I'd suggest just trying again, the mirror may have been updating at the time. 'pkg update -f' and try again. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: gcc48-4.8.4.s20141030.txz: Forbidden?!
On Thu, 13 Nov 2014 13:15:26 -0600 Bryan Drewery bdrew...@freebsd.org wrote On 11/13/2014 12:04 PM, Chris H wrote: OK. I'm on 11 (r274393 amd64, custom kernel. fresh world) svn info /usr/ports -- r372460 src, and make.conf were both empty. While building a port, lang/gcc48, and lang/gcc-ecj45 were sucked in as dependency. During the building of one of them (ecj45?) I noticed a (core dumped). I was unable to capture the context of the event. But decided to make deinstall both. Followed by a pkg install of both. The ecj45 installed w/o issue. But gcc48 failed with gcc48-4.8.4.s20141030.txz: Forbidden. Why? Thank you for all your time, and consideration. Was this error from 'pkg install' during the fetch phase? I'd suggest just trying again, the mirror may have been updating at the time. 'pkg update -f' and try again. Yes. This was via pkg install lang/gcc48 Probably during a fetch. Funny though. I got impatient, and decided to try a cd /usr/ports/lang/gcc48; make which resulted in the first 6 servers fetch attempted, replying Forbidden. I know clang is the preferred method. But isn't this going a bit too far. ;) The 7th server succeeded, and it seems to be building fine. Thanks for taking the time to reply, Bryan. --Chris -- Regards, Bryan Drewery ___ 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: USB locks up system -- WAS Re: shutdown or acpi problem
On 11/13/14 19:15, Steve Kargl wrote: On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote: On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote: On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: I have a kernel/world from r274273 sources, which is exhibiting a new issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' work. I get to the end of shutdown and see for example All buffers synced Uptime: 4h23m15s and then the laptop just sits there. It does not power off with the -p option nor does it reboot with the -r. Has anyone else seen this behavior? The problem appears to be related to a recent change in the USB stack. If I have the following drive plugged into a usb port, the above behavior is observed on shutdown. Adding hw.usb.no_shutdown_wait: 1 to /boot/loader.conf appears to work around the 'shutdown -p now' and 'shutdown -r now' issue. Unfortunately, the bricking of the laptop is not affected by this sysctl. Once a device is plugged into a usb, it must remain plugged in. Hi, Is using this sysctl/tunable a suitable solution for you? --HPS ___ 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
Jenkins build is still unstable: FreeBSD_HEAD-tests2 #241
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/241/ ___ 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: USB locks up system -- WAS Re: shutdown or acpi problem
On Thu, Nov 13, 2014 at 09:34:07PM +0100, Hans Petter Selasky wrote: On 11/13/14 19:15, Steve Kargl wrote: On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote: On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote: On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: I have a kernel/world from r274273 sources, which is exhibiting a new issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' work. I get to the end of shutdown and see for example All buffers synced Uptime: 4h23m15s and then the laptop just sits there. It does not power off with the -p option nor does it reboot with the -r. Has anyone else seen this behavior? The problem appears to be related to a recent change in the USB stack. If I have the following drive plugged into a usb port, the above behavior is observed on shutdown. Adding hw.usb.no_shutdown_wait: 1 to /boot/loader.conf appears to work around the 'shutdown -p now' and 'shutdown -r now' issue. Unfortunately, the bricking of the laptop is not affected by this sysctl. Once a device is plugged into a usb, it must remain plugged in. Hi, Is using this sysctl/tunable a suitable solution for you? The sysctl is a suitable solution for the shutdown issues. It is not suitable solution for the general use of using a memory stick to for example quickly transfer files. Once the memory stick is plugged into the usb port, it must remain there unless one wants to reboot the system. I rebuilt the kernel with USB_DEBUG and CAMDEBUG enabled. I need to wade through a rather large /var/log/messages to see if anything appears unusual. -- Steve ___ 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
Build failed in Jenkins: FreeBSD_HEAD #1835
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/1835/changes Changes: [dim] The fix imported into llvm in r274442 contains some C++11 constructs, which gcc in base cannot handle. Replace these with C++98 equivalents. While here, add the patch for the adapted fix. Reported by:bz, kib Pointy hat to: dim MFC after: 1 week X-MFC-With: r274442 [mjg] filedesc: fixup fdinit to lock fdp and preapare files conditinally Not all consumers providing fdp to copy from want files. Perhaps these functions should be reorganized to better express the outcome. This fixes up panics after r273895 . Reported by:markj [jhb] Drop mention of ISA cards. Note that I have no idea what to cull from the supported hardware list. Judging by the PCI driver attachment, dpt_pci.c only supports a single adapter rather than the various PCI adapters listed. The list of EISA adapters listed somewhat overlaps with the device IDs in dpt_eisa.c. It's not clear which devices are ISA-only devices. [jhb] Remove dpt_isa.c and commented out references to it. It was never connected to the build in either sys/conf/files* or sys/modules/dpt/Makefile. Also, it was denoted as doesn't quite work yet when the file was initially added (which may account for it never having been hooked up to the build). [jhb] Remove reference to sys/dev/dpt/dpt_control.c. It was removed back in 2001 after having never been updated for CAM changes in 1998. [kib] Fix assertion, uc-uc_busy is never zero, the intent is to test the uc_busy value, and not its address [1]. Remove the single use of the macro, write KASSERT() explicitely in the code of umtxq_sleep_pi(). Submitted by: Eric van Gyzen e...@vangyzen.net [1] MFC after: 1 week -- [...truncated 281713 lines...] ctfconvert -L VERSION -g bus_if.o --- md.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/contrib/altq -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/dev/md/md.c --- virtio_if.o --- ctfconvert -L VERSION -g virtio_if.o --- usb_dev.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/contrib/altq -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/dev/usb/usb_dev.c --- acpi_wmi_if.o --- ctfconvert -L VERSION -g acpi_wmi_if.o --- evtchn_dev.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/contrib/altq -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/dev/xen/evtchn/evtchn_dev.c ctfconvert -L VERSION -g
Re: Build failed in Jenkins: FreeBSD_HEAD #1835
On Thu, Nov 13, 2014 at 10:40:48PM +, jenkins-ad...@freebsd.org wrote: --- imgact_shell.o --- ctfconvert -L VERSION -g imgact_shell.o --- init_main.o --- https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/kern/init_main.c:530:25: error: too many arguments to function call, expected single argument 'fdp', have 2 arguments p-p_fd = fdinit(NULL, false); ~~ ^ https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/sys/types.h:272:15: note: expanded from macro 'false' #define false 0 ^ https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/sys/filedesc.h:161:1: note: 'fdinit' declared here struct filedesc *fdinit(struct filedesc *fdp); ^ That's my fault, fixed in https://svnweb.freebsd.org/changeset/base/274485 -- Mateusz Guzik mjguzik gmail.com ___ 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: CFR: AES-GCM and OpenCrypto work review
On 08.11.2014 07:23, John-Mark Gurney wrote: Hello, Over the last few months, I've been working on a project to add support for AES-GCM and AES-CTR modes to our OpenCrypto framework. The work is sponsored by The FreeBSD Foundation and Netgate. I plan on committing these patches early next week. If you need more time for review, please email me privately and I will make delay. The code has already been reviewed by Watson Ladd (the software crypto implementations) and Trevor Perrin (the aesni module part) and I have integrated these changes into the patch. There are two patches, one is the changes for OpenCrypto and the test framework. The other is the data files used by the test framework. The data is from NIST's CAVP program, and is about 20MB worth of test vectors. (I just realized, should we look at compressing these on disk?) Main patch (192KB): https://www.funkthat.com/~jmg/patches/aes.ipsec.5.patch Data files (~20MB): https://www.funkthat.com/~jmg/patches/aes.ipsec.5.testing.patch A list of notable changes in the patch: - Replacing crypto(4) w/ NetBSD's version + updates - Lots of man page updates, including CIOCFINDDEV and crypto(7) which adds specifics about restrictions on the modes. - Allow sane useage of both _HARDWARE and _SOFTWARE flags. - Add a timing safe bcmp for MAC comparision. - Add a software implementation of GCM that uses a four bit lookup table with parallelization. This algorithm is possibly vulnerable to timing attacks, but best known mitigation methods are used. Using a timing safe version is many times slower. - Added a CRYPTDEB macro that defaults to off. - Bring in some of OpenBSD's improvements to the OpenCrypto framework. - If an mbuf passed to the aesni module is only one segment, don't do a copy. This needs to be improved to support segmented buffers. - Remove the CRYPTO_F_REL flag. It was meaningless. It was used but did not change any behavior. - Add function crypto_mbuftoiov to convert an mbuf to an iov. This also converts the software crypto to only use iov's even for a simple linear buffer, and so simplifies the processing. - Add a dtrace probe for errors from the ioctl. - Add the CIOCCRYPTAEAD ioctl that allows userland processing (testing) of AES-GCM and future AEAD modes. Future improvements: - Support IV's longer than 12 bytes for GCM. - Make AES-NI support segmented buffers (iov or mbuf) so multisegmented inputs don't have to be copied. I know there are more fixes and future improvements, but can't think of them now. I tried your patch with my IPv4 forwarding test. When aesni module is loaded and aes-cbc is used I see growing of `invalid outbound packets` counter in `netstat -sp ipsec` output. And no packets are forwarded. Also while testing I got a panic in aesni_encrypt_cbc(). atal trap 9: general protection fault while in kernel mode cpuid = 4; apic id = 04 instruction pointer = 0x20:0x80d05c43 stack pointer = 0x28:0xfe3f7e70 frame pointer = 0x28:0xfe3f7eb0 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 = 12 (irq286: ix0:que 4) The backtrace: #0 doadump (textdump=276160512) at pcpu.h:219 #1 0x80355525 in db_fncall (dummy1=value optimized out, dummy2=value optimized out, dummy3=value optimized out, dummy4=value optimized out) at /usr/src/sys/ddb/db_command.c:568 #2 0x8035520d in db_command (cmd_table=0x0) at /usr/src/sys/ddb/db_command.c:440 #3 0x80354f84 in db_command_loop () at /usr/src/sys/ddb/db_command.c:493 #4 0x80357980 in db_trap (type=value optimized out, code=0) at /usr/src/sys/ddb/db_main.c:251 #5 0x8095c641 in kdb_trap (type=9, code=0, tf=value optimized out) at /usr/src/sys/kern/subr_kdb.c:654 #6 0x80d1edcc in trap_fatal (frame=0xfe3f7dc0, eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:861 #7 0x80d1ea6e in trap (frame=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:201 #8 0x80d04092 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #9 0x80d05c43 in fpudna () at /usr/src/sys/amd64/amd64/fpu.c:85 #10 0x80d1e7ae in trap (frame=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:432 #11 0x80d04092 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #12 0x8202f96e in aesni_encrypt_cbc (rounds=10, key_schedule=0xf8005603d400, len=3, from=0xf8013b0de65a E, to=0xf8013b0de65a E, iv=0xf8005603d6d0 �#��8�:n�\r��\f���\v) at /usr/src/sys/modules/aesni/../../crypto/aesni/aesni_wrap.c:63 #13 0x820318d0 in aesni_process (dev=value optimized out, crp=0xf80109f7bc08, hint=value optimized out) at /usr/src/sys/modules/aesni/../../crypto/aesni/aesni.c:535 #14
Re: FreeBSD + Google Code-In 2014 = we need ideas.
On Mon, Nov 10, 2014 at 01:56:27PM -0700, Alan Somers wrote: On Sun, Nov 9, 2014 at 8:59 PM, Wojciech A. Koszek wkos...@freebsd.org wrote: Hello, BTW, FYI: We didn't make it this year. Judging by the GSoC 2014 Reunion, there is a lot of seasoned Orgs which treat GCIN very seriously, so I think if we plan to participate, it'll be a lot of effort to compete with them Anyway: thanks for the tasks which were submitted. I will put them in Wiki for the reference, Wojciech This year we'd like to participate in the Google Code-In 2014. This is Google Summer of Code, but for younger people: age range is 13--17. If you're one of them, we highly encourage you to apply! ***This year coding tasks are possible, so feel free to add those*** To submit idea which you'd like to see done in GCI, visit: http://bit.ly/FreeBSD_GCIN2014 Regardless of who you are, please use the form to submit ideas. Don't add stuff via Wiki, since this year we'll do direct import of all ideas from Google Forms. To see tasks from previous year that are yet to be copied to Google Forms: https://wiki.freebsd.org/GoogleCodeIn/2014Tasks Thanks to GCI in the previous years, we gained one more FreeBSD developer. We'd like to partcipate this year too. We need: 1) ideas. How about converting various utility functions to use libxo? I think that's within the grasp of a high-schooler. 2) mentors 3) participants. Just like in previous years we'll decide whether we're ready. Deadlines: --- November 12, 2014 - The 10-12 Mentoring organizations are announced for Google Code-in 2014 and the orgs can start entering their tasks into the Google system (the tasks will not be viewable to students until the contest opens on Dec 1). December 1, 2014 17:00 UTC - Google Code-in 2014 contest opens for students January 19, 2015 17:00 UTC - Google Code-in 2014 student work ends --- MORE INFO: [0] http://www.google-melange.com/gci/homepage/google/gci2014 [1] gci-ment...@googlegroups.com [2] https://developers.google.com/open-source/gci/resources/mentor-and-orgadmin-info -- Wojciech A. Koszek wkos...@freebsd.czest.pl http://FreeBSD.czest.pl/~wkoszek/ ___ 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 -- Wojciech A. Koszek wkos...@freebsd.czest.pl http://FreeBSD.czest.pl/~wkoszek/ ___ 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
comments on code-in tasks for FreeBSD (Re: FreeBSD + Google Code-In 2014 = we need ideas.)
On Thu, Nov 13, 2014 at 5:06 PM, Wojciech A. Koszek wkos...@freebsd.org wrote: On Mon, Nov 10, 2014 at 01:56:27PM -0700, Alan Somers wrote: On Sun, Nov 9, 2014 at 8:59 PM, Wojciech A. Koszek wkos...@freebsd.org wrote: Hello, BTW, FYI: We didn't make it this year. Judging by the GSoC 2014 Reunion, there is a lot of seasoned Orgs which treat GCIN very seriously, so I think if we plan to participate, it'll be a lot of effort to compete with them Anyway: thanks for the tasks which were submitted. I will put them in Wiki for the reference, hi, i meant to send this email before but given the outcome this seems a good time to prepare for next year. I have been looking at tasks to submit (especially coding, but not just those) and looking at other organisations who participated in past years, i believe that FreeBSD (with its C- and kernel- centric environment) is a poor match for code-in, specifically due to the young age and predictable lack of expertise of most of the participants, and the small size of the tasks. In my view, most of the documentation tasks listed in the wiki https://wiki.freebsd.org/GoogleCodeIn/2014Tasks are not approachable by students -- they require experience and knowledge of compilers, subsystems and development techniques that are unlikely to exist for teenagers. When it comes to programming tasks, again the list has entries simply beyond the ability of the students. First three tasks: static analysis for kernel locking, static analysis of kernel conventions, profile libc++. These are important tasks, but they just do not belong here. As a rule of thumb i would say that anything that is in the list should not take more than 2-3 hours/half a day to an experienced developer, be accompanied by a detailed description on what to do and how, and by a commitment from the mentor to review it. Also, if we want to suggest some coding task, it is important that we can give students a preloaded OS image with all the tools and repos they may need for their work, otherwise they end up spending a lot of time setting up the environment and possibly making mistakes in the process that prevent a correct completion of the work. Sure we ship with compilers and make, but we miss svn/git, an embedded snapshot of source and ports tree, and now that we can, also a bhyve or qemu example to help them testing kernels. Finally, we should shift the approach from something we need to something can be a useful exercise for the students even if it replicates features that already exist in the OS. That might perhaps lead to smaller, better and easier to define tasks with a better chance to be completed. Lacking any better idea (which I don't have because as i said i think FreeBSD just is not a good match for this competition), we could take some specific bug reports, and provide details and hints for solutions. But please nuke the current list -- it is completely inadequate for the code-in candidates and misleading for whoever wants to suggest new tasks. Again i am not saying that the projects suggested there are not important, just belong somewhere else e.g. gsoc. cheers luigi Wojciech This year we'd like to participate in the Google Code-In 2014. This is Google Summer of Code, but for younger people: age range is 13--17. If you're one of them, we highly encourage you to apply! ***This year coding tasks are possible, so feel free to add those*** To submit idea which you'd like to see done in GCI, visit: http://bit.ly/FreeBSD_GCIN2014 Regardless of who you are, please use the form to submit ideas. Don't add stuff via Wiki, since this year we'll do direct import of all ideas from Google Forms. To see tasks from previous year that are yet to be copied to Google Forms: https://wiki.freebsd.org/GoogleCodeIn/2014Tasks Thanks to GCI in the previous years, we gained one more FreeBSD developer. We'd like to partcipate this year too. We need: 1) ideas. How about converting various utility functions to use libxo? I think that's within the grasp of a high-schooler. 2) mentors 3) participants. Just like in previous years we'll decide whether we're ready. Deadlines: --- November 12, 2014 - The 10-12 Mentoring organizations are announced for Google Code-in 2014 and the orgs can start entering their tasks into the Google system (the tasks will not be viewable to students until the contest opens on Dec 1). December 1, 2014 17:00 UTC - Google Code-in 2014 contest opens for students January 19, 2015 17:00 UTC - Google Code-in 2014 student work ends --- MORE INFO: [0] http://www.google-melange.com/gci/homepage/google/gci2014 [1] gci-ment...@googlegroups.com [2]
How do I get someone to look at / comment on
this bug? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194770 It's to stop a constant stream of noise on my 11-CURRENT box. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 ___ 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: How do I get someone to look at / comment on
On 11/13/2014 21:07, Larry Rosenman wrote: this bug? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194770 It's to stop a constant stream of noise on my 11-CURRENT box. Doesn't r273962 take care of this? ___ 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: How do I get someone to look at / comment on
On 2014-11-13 20:23, Adam McDougall wrote:
On 11/13/2014 21:07, Larry Rosenman wrote:
this bug?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194770
It's to stop a constant stream of noise on my 11-CURRENT box.
Doesn't r273962 take care of this?
___
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
It misses this block:
Index: sys/dev/drm2/radeon/radeon_connectors.c
@@ -954,7 +954,7 @@
radeon_connector-edid = drm_get_edid(radeon_connector-base,
radeon_connector-ddc_bus-adapter);
if (!radeon_connector-edid) {
- DRM_ERROR(%s: probed a monitor but no|invalid EDID\n,
+ DRM_DEBUG_KMS(%s: probed a monitor but no|invalid
EDID\n,
drm_get_connector_name(connector));
/* rs690 seems to have a problem with connectors not existing and
always
* return a block of 0's. If we see this just stop polling on this
output */
Which is one of the messages I was getting...
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 108 Turvey Cove, Hutto, TX 78634-5688
___
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
Jenkins build is back to stable : FreeBSD_HEAD-tests2 #242
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/242/ ___ 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
Jenkins build is back to normal : FreeBSD_HEAD #1836
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/1836/changes ___ 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: building stable/10 on -current
On Wed, Nov 12, 2014 at 3:53 PM, Russell L. Carter rcar...@pinyon.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On current r273808, make buildworld in a stable/10 tree fails with: building shared library libc.so.7 /usr/bin/ld: _umtx_unlock.So: relocation R_X86_64_32 against `SYS__umtx_unlock' can not be used when making a shared object; recompile with -fPIC _umtx_unlock.So: could not read symbols: Bad value However, poudriere can build it just fine in its jail. I am curious why that is. I've not tried recently so no clue. Can a -current host be made to build stable/10, or is that impossible? iirc, it should. If it doesn't, something is broken and should be fixed. cheers, Hiren ___ 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
