Re: System hangs at boot in xhci0
On Fri, Dec 09, 2016 at 11:58:21PM +0100, Hans Petter Selasky wrote: > On 12/09/16 22:09, Steve Kargl wrote: > > I updated my system to > > > > % svn info /usr/src > > Revision: 309748 > > > > Built a shiny new kernel, which hangs during boot. > > There is no panic. Using the dmesg from kernel.old/kernel, > > the last few reported are > > > > > > pci2: on pcib2 > > xhci0: mem 0xfe90-0xfe900fff > > irq 48 at device 0.0 on pci2 > > xhci0: 32 bytes context size, 64-bit DMA > > > > At this point, the system is completely unresponse and > > needs to be power cycled. > > > > Hi, > > What is the next message in the old kernel which is printed? There has > been zero changes in the XHCI driver recently. > > Can you copy /boot/kernel.old to /boot/kernel.works > > Then add this option to the GENERIC kernel config: > > options VERBOSE_SYSINIT > > What are the last few messages in dmesg when you boot with the above flag? > With a boot_verbose of the new kernel I get the following output: xhci0: 32 bytes context size, 64-bit DMA xhci0: attempting to allocate 1 MSI vectors (4 supported) msi: routing MSI IRQ 260 to local APIC 16 vector 55 xhci0: using IRQ 260 for MSI xhci0: MSI enabled usbus0 on xhci0 xhci0: usbpf: Attached random: harvesting attach, 8 bytes (4 bits) from usbus0 random: harvesting attach, 8 bytes (4 bits) from xhci0 random: harvesting attach, 8 bytes (4 bits) from pci2 random: harvesting attach, 8 bytes (4 bits) from pcib2 and then the system locks up. With the old kernel (circa Oct 10th sources), next few lines from dmesg are pcib3: irq 54 at device 10.0 on pci0 pcib0: allocated type 4 (0xd000-0xdfff) for rid 1c of pcib3 pcib0: allocated type 3 (0xfe80-0xfe8f) for rid 20 of pcib3 pcib3: domain0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode0xd000-0xdfff pcib3: memory decode 0xfe80-0xfe8f pci3: on pcib3 I think that hang isn't caused by xhci, but rather is a victim on being the last successfully probed device. In the last weeks there have been a few commits (309588, 309400, and 308953) that touched ACPI. I'm currently reverting these changes to test if one is causing the problem. I did see that one of these revisions specific mentions the ALASKA AMI bios, which I happen to have. However, that commit also mentions a skylake processor while I have an AMD FX-8350. -- Steve http://troutmask.apl.washington.edu/~kargl/ https://www.youtube.com/watch?v=6hwgPfCcpyQ ___ 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: System hangs at boot in xhci0
On 12/09/16 22:09, Steve Kargl wrote: I updated my system to % svn info /usr/src Path: /usr/src Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 309748 Built a shiny new kernel, which hangs during boot. There is no panic. Using the dmesg from kernel.old/kernel, the last few reported are pci2: on pcib2 xhci0: mem 0xfe90-0xfe900fff irq 48 at device 0.0 on pci2 xhci0: 32 bytes context size, 64-bit DMA At this point, the system is completely unresponse and needs to be power cycled. Hi, What is the next message in the old kernel which is printed? There has been zero changes in the XHCI driver recently. Can you copy /boot/kernel.old to /boot/kernel.works Then add this option to the GENERIC kernel config: options VERBOSE_SYSINIT What are the last few messages in dmesg when you boot with the above flag? --HPS ___ 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"
FreeBSD_HEAD_i386 - Build #4342 - Fixed
FreeBSD_HEAD_i386 - Build #4342 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4342/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4342/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4342/console Change summaries: 309766 by glebius: Fix build for 32-bit machines. Submitted by: tuexen ___ 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"
System hangs at boot in xhci0
I updated my system to % svn info /usr/src Path: /usr/src Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 309748 Built a shiny new kernel, which hangs during boot. There is no panic. Using the dmesg from kernel.old/kernel, the last few reported are pci2: on pcib2 xhci0: mem 0xfe90-0xfe900fff irq 48 at device 0.0 on pci2 xhci0: 32 bytes context size, 64-bit DMA At this point, the system is completely unresponse and needs to be power cycled. -- steve ___ 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"
FreeBSD_HEAD_i386 - Build #4341 - Failure
FreeBSD_HEAD_i386 - Build #4341 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4341/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4341/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4341/console Change summaries: 309752 by emaste: src.conf.5: regen after r309142 (WITH_LLD_AS_LD knob) Reported by:Nikolai Lifanov Sponsored by: The FreeBSD Foundation 309751 by glebius: Use acquire write to cr_lock to complement with release write at end of locked region. Submitted by: kib 309750 by markj: Conditionalize PG_CACHE sysctls on COMPAT_FREEBSD11. Reviewed by:glebius, imp, jhb Differential Revision: https://reviews.freebsd.org/D8736 309749 by markj: Add a COMPAT_FREEBSD11 kernel option. Use it wherever COMPAT_FREEBSD10 is currently specified. Reviewed by:glebius, imp, jhb Differential Revision: https://reviews.freebsd.org/D8736 309748 by glebius: Treat R_X86_64_PLT32 relocs as R_X86_64_PC32. If we load a binary that is designed to be a library, it produces relocatable code via assembler directives in the assembly itself (rather than compiler options). This emits R_X86_64_PLT32 relocations, which are not handled by the kernel linker. Submitted by: gallatin Reviewed by:kib 309747 by glebius: Backout accidentially leaked in r309746 not yet reviewed patch :( 309746 by glebius: Use counter_ratecheck() in the ICMP rate limiting. Together with: rrs, jtl 309745 by glebius: Provide counter_ratecheck(), a MP-friendly substitution to ppsratecheck(). When rated event happens at a very quick rate, the ppsratecheck() is not only racy, but also becomes a performance bottleneck. Together with: rrs, jtl 309744 by tuexen: Don't bundle a SACK chunk with a SHUTDOWN chunk if it is not required. MFC after: 1 week 309743 by tuexen: Don't send multiple SHUTDOWN chunks in a single packet. Thanks to Felix Weinrank for making me aware of this issue. MFC after: 1 week 309739 by br: Add registers for jz4780 audio and PDMA controllers. Sponsored by: DARPA, AFRL The end of the build log: [...truncated 219759 lines...] cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -MD -MF.depend.ieee80211_ageq.o -MTieee80211_ageq.o -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/net80211/ieee80211_ageq.c --- ieee80211_action.o --- ctfconvert -L VERSION -g ieee80211_action.o --- ieee80211.o --- ctfconvert -L VERSION -g ieee80211.o --- ieee80211_ageq.o --- ctfconvert -L VERSION -g ieee80211_ageq.o --- ieee80211_adhoc.o --- cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -MD -MF.depend.ieee80211_adhoc.o -MTieee80211_adhoc.o -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/net80211/ieee80211_adhoc.c -Wno-unused-function --- ieee80211_amrr.o --- --- ieee80211_crypto.o --- --- ieee80211_amrr.o --- cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -MD -MF.depend.ieee80211_amrr.o -MTieee80211_amrr.o -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function
Re: Mac OS X on bhyve
On 9 December 2016 at 09:54, A. Wilcox wrote: > > > And VirtualBox can boot Mac OS X without any bootloader or hacking, so > it is much more stable, and resilient to automatic updates (which you > need much experience to disable on newer releases, including macOS Sierra). > > > Assumed you run Virtualbox on OSX. Otherwise you still need to fake SMBIOS entries to make it boot from what I have read. Guess Clover does that automatically but true enough it seems less hassle. ___ 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: Mac OS X on bhyve
On 09/12/16 02:16, Matthias Gamsjager wrote: > On 9 December 2016 at 04:16, A. Wilcox wrote: >> If you do have the proper type of Mac OS X that can be virtualised >> legally on PC hardware, you still need the SMC to be emulated. That >> will need to be added to bhyve before you could boot Mac OS X natively, >> i.e. without hacks. >> >> > The hacktingtosh community did quite a lot of work in that aspect. Eg. the > Clover bootloader which most use to start OSX on normal PC hardware And VirtualBox can boot Mac OS X without any bootloader or hacking, so it is much more stable, and resilient to automatic updates (which you need much experience to disable on newer releases, including macOS Sierra). Note that if you have an AMD CPU, your options will be limited. I'm unaware of any bhyve option to customise the CPUID presented to the guest (it may be undocumented, but I doubt it - the team is very good at docs). If you have an AMD CPU, you will need Clover and likely a patched mach_kernel for AMD support. I thought all this knowledge would be useless, three years after I retired my last full-time OS X box... Who knew... --arw -- A. Wilcox (awilfox) Open-source programmer (C, C++, Python) https://code.foxkit.us/u/awilfox/ signature.asc Description: OpenPGP digital signature
Re: Mac OS X on bhyve (was: Is there possible run a MacOS X binary)
On 9 December 2016 at 04:16, A. Wilcox wrote: > > Depending on version and edition of Mac OS X, this may or may not be a > legal suggestion; Apple has made various terms in their license that you > can only virtualise Mac OS X on Apple-branded hardware. (Some creative > types from a virtualisation forum once suggested taking the Apple > stickers from the iPhone box and placing them on your PC, making it > Apple branded. Not sure that would stand up in court.) > > If you do have the proper type of Mac OS X that can be virtualised > legally on PC hardware, you still need the SMC to be emulated. That > will need to be added to bhyve before you could boot Mac OS X natively, > i.e. without hacks. > > The hacktingtosh community did quite a lot of work in that aspect. Eg. the Clover bootloader which most use to start OSX on normal PC hardware ___ 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"
