Re: Cam panic on r271170
On 9/17/2014 10:39 AM, Bryan Drewery wrote: > On 9/16/2014 9:28 PM, Bryan Drewery wrote: >> I've been getting this quite frequently on head recently. I have dumps >> if anyone is interested in more information. >> >>> Fatal trap 9: general protection fault while in kernel mode >>> cpuid = 10; Memory modified after free 0xf8003e0b0800(2040) >>> val= @ 0xf8003e0b0808 >>> apanic: Most recently used by CAM CCB >>> >>> cpuid = 6 >>> KDB: stack backtrace: >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >>> 0xfe124735b4c0 >>> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe124735b570 >>> vpanic() at vpanic+0x189/frame 0xfe124735b5f0 >>> panic() at panic+0x43/frame 0xfe124735b650 >>> mtrash_ctor() at mtrash_ctor+0x8a/frame 0xfe124735b680 >>> uma_zalloc_arg() at uma_zalloc_arg+0x4f1/frame 0xfe124735b6f0 >>> malloc() at malloc+0x192/frame 0xfe124735b740 >>> xpt_run_allocq() at xpt_run_allocq+0xb5/frame 0xfe124735b780 >>> adastrategy() at adastrategy+0x117/frame 0xfe124735b7b0 >>> g_io_request() at g_io_request+0x3b7/frame 0xfe124735b810 >>> g_part_start() at g_part_start+0x2b7/frame 0xfe124735b890 >>> g_io_request() at g_io_request+0x3b7/frame 0xfe124735b8f0 >>> g_io_request() at g_io_request+0x3b7/frame 0xfe124735b950 >>> vdev_geom_io_start() at vdev_geom_io_start+0x137/frame 0xfe124735b970 >>> zio_vdev_io_start() at zio_vdev_io_start+0x49f/frame 0xfe124735b9d0 >>> zio_execute() at zio_execute+0x204/frame 0xfe124735ba30 >>> vdev_queue_io_done() at vdev_queue_io_done+0x180/frame 0xfe124735ba80 >>> zio_vdev_io_done() at zio_vdev_io_done+0x11d/frame 0xfe124735bac0 >>> zio_execute() at zio_execute+0x204/frame 0xfe124735bb20 >>> taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame >>> 0xfe124735bb80 >>> taskqueue_thread_loop() at taskqueue_thread_loop+0x9b/frame >>> 0xfe124735bbb0 >>> fork_exit() at fork_exit+0x84/frame 0xfe124735bbf0 >>> fork_trampoline() at fork_trampoline+0xe/frame 0xfe124735bbf0 >>> --- trap 0, rip = 0, rsp = 0xfe124735bcb0, rbp = 0 --- >>> KDB: enter: panic >>> [ thread pid 0 tid 100571 ] >>> Stopped at kdb_enter+0x3e: movq$0,kdb_why >> >> > > I also had this one recently: > >> #8 0x80d1a162 in calltrap () at >> /usr/src/sys/amd64/amd64/exception.S:231 >> #9 0x802e52c4 in xpt_path_periph (path=0xdeadc0dedeadc0de) at >> /usr/src/sys/cam/cam_xpt.c:3738 >> #10 0x802dfe62 in cam_periph_error (ccb=0xf8003e0b6000, >> camflags=CAM_FLAG_NONE, sense_flags=0, save_ccb=0x0) at >> /usr/src/sys/cam/cam_periph.c:1602 >> #11 0x803057e4 in adadone (periph=0xf8003e09b700, >> done_ccb=0xf8003e0b6000) at /usr/src/sys/cam/ata/ata_da.c:1877 >> #12 0x802e6e44 in xpt_done_process (ccb_h=0xf8003e0b6000) at >> /usr/src/sys/cam/cam_xpt.c:5245 >> #13 0x80394d59 in ahci_ch_intr_direct (arg=) at >> /usr/src/sys/dev/ahci/ahci.c:1132 >> #14 0x80390ff1 in ahci_intr (data=) at >> /usr/src/sys/dev/ahci/ahci.c:417 >> #15 0x808ea5d3 in intr_event_execute_handlers (p=> out>, ie=0xf8000f725d00) at /usr/src/sys/kern/kern_intr.c:1252 >> #16 0x808eafb6 in ithread_loop (arg=0xf8000f6dea60) at >> /usr/src/sys/kern/kern_intr.c:1265 >> #17 0x808e7fc4 in fork_exit (callout=0x808eaf10 >> , arg=0xf8000f6dea60, frame=0xfe1245083c00) at >> /usr/src/sys/kern/kern_fork.c:977 >> #18 0x80d1a69e in fork_trampoline () at >> /usr/src/sys/amd64/amd64/exception.S:605 > > Another, with much more information here: https://people.freebsd.org/~bdrewery/cam.panic.txt This was with memguard (vm.memguard.desc="CAM CCB") and a KASSERT in malloc(9) and uma_zalloc_arg() to prevent M_WAITOK in non-sleepable threads. Neither triggered. It seems to be when syncing to the SSD ZFS log I have. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: Cam panic on r271170
On Wed, Sep 24, 2014 at 11:48 AM, Bryan Drewery wrote: > Another, with much more information here: > https://people.freebsd.org/~bdrewery/cam.panic.txt > > This was with memguard (vm.memguard.desc="CAM CCB") and a KASSERT in > malloc(9) and uma_zalloc_arg() to prevent M_WAITOK in non-sleepable > threads. Neither triggered. Well that's unfortunate. Are CCBs ever the target of DMA? Does your hardware have an Intel chipset and is it new enough to support an IOMMU? You might try enabling the IOMMU, which would catch out-of-bounds DMA by hardware: http://svnweb.freebsd.org/changeset/base/257251 One caveat is that while I understand that the busdma infrastructure for this is quite well tested, individual drivers and devices need to be well-behaved so it's possible that this won't work on your hardware right now. Also, don't enable this if you use BHyve with PCI Passthrough. ___ 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"
[PATCH] Lock ncr(4)
This patch adds locking to wds(4) and marks it MPSAFE. It also includes several other cleanups such as using bus_space instead of inb/outb. The patch is against HEAD but probably applies to 9 and 10 as well. http://people.freebsd.org/~jhb/patches/ncr_locking.patch -- John Baldwin ___ 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"
[PATCHES] Convert various pc98 drivers from timeout() to callout()
I have three patches to convert various pc98 drivers from timeout() to callout(). For the fdc driver I took a more drastic approach and have attempted to port the PC98 support into the main fdc driver: http://people.FreeBSD.org/~jhb/patches/pc98_fdc.patch The pckbd driver needs a similar change to what I recently comitted to atkbd: http://people.FreeBSD.org/~jhb/patches/pckbd_callout.patch For the olpt driver, I just did a simple conversion: http://people.FreeBSD.org/~jhb/patches/olpt_callout.patch These patches are against HEAD but likely apply to 9 and 10 as well. -- John Baldwin ___ 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"
[PATCH] Convert some timers in isp(4) from timeout(9) to callout(9)
This patch converts a few timers in isp(4) from timeout(9) to callout(9). It already used callout(9) for normal command timeouts. The patch is against HEAD but probably applies to 9 and 10 as well. http://people.freebsd.org/~jhb/patches/isp_callout.patch -- John Baldwin ___ 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: Poor state of the build infrastructure.
On Tuesday, September 23, 2014 09:29:48 AM Marcel Moolenaar wrote: > What is going on here? > Are we still in some kind of flux and people aren't done yet or is > this the intended state by virtue of noone having anything left on > there TODO list? Sorry to ask a dumb question, but are you sure you did the make buildworld first? Shouldn't that have errored if it couldn't build crt1? I think if you haven't done a make buildworld/toolchain, then when you do make buildenv you will fall back to using the host tools: > make TARGET=sparc64 buildenv Entering world for sparc64:sparc64 $ echo $PATH /usr/obj/sparc64.sparc64/usr/src/tmp/legacy/usr/sbin:/usr/obj/sparc64.sparc64/usr/src/tmp/legacy/usr/bin:/usr/obj/sparc64.sparc64/usr/src/tmp/legacy/usr/games:/usr/obj/sparc64.sparc64/usr/src/tmp/legacy/bin:/usr/obj/sparc64.sparc64/usr/src/tmp/usr/sbin:/usr/obj/sparc64.sparc64/usr/src/tmp/usr/bin:/usr/obj/sparc64.sparc64/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin $ which cc /usr/obj/sparc64.sparc64/usr/src/tmp/usr/bin/cc $ which cat /bin/cat -- John Baldwin ___ 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: Teach vidcontrol(1) and vt(4) to restore default font
On Sat, 13 Sep 2014, Benjamin Kaduk wrote: On Sat, 13 Sep 2014, Marcin Cieslak wrote: Hello, I tried loading gallant.fnt which I did not like and I was wondering how to come back to the nice default font. There does not seem to be the way to do this, so please find below a simple patch to add this functionality. It adds a new ioctl PIO_VDFFONT to the vt(4) driver. I hope I got the reference counting on the vt_font_default structure right. With this patch applied, "vidcontrol -f" restores the built-in font. Can you please submit this to our bug tracker so it doesn't get lost? https://bugs.freebsd.org/submit Sure, it lives under https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193910 now. //Marcin ___ 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: Poor state of the build infrastructure.
On Sep 24, 2014, at 12:54 PM, John Baldwin wrote: > On Tuesday, September 23, 2014 09:29:48 AM Marcel Moolenaar wrote: >> What is going on here? >> Are we still in some kind of flux and people aren't done yet or is >> this the intended state by virtue of noone having anything left on >> there TODO list? > > Sorry to ask a dumb question, but are you sure you did the make buildworld > first? Shouldn't that have errored if it couldn't build crt1? The root cause problem was that MAKEOBJDIRPREFIX was not set to whatever it was set to during buildworld. That was easy enough to figure out when a bunch of things don't add up. But neither problem mentioned in the email had anything to do with MAKEOBJDIRPREFIX. Having to set the COMPILER_TYPE as part of an install is a bug. Entering a powerpc buildenv and having a compiler that builds for the host (or maybe just some default) is a regression. The only thing the FreeBSD build is good at, really, is building in /usr/src for the host. The rest is just not up to par and I think it harms FreeBSD beyond belief. -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Poor state of the build infrastructure.
On Wed, 24 Sep 2014 16:33:46 -0700 Marcel Moolenaar wrote: > > On Sep 24, 2014, at 12:54 PM, John Baldwin wrote: > > > On Tuesday, September 23, 2014 09:29:48 AM Marcel Moolenaar wrote: > >> What is going on here? > >> Are we still in some kind of flux and people aren't done yet or is > >> this the intended state by virtue of noone having anything left on > >> there TODO list? > > > > Sorry to ask a dumb question, but are you sure you did the make > > buildworld first? Shouldn't that have errored if it couldn't build > > crt1? > > The root cause problem was that MAKEOBJDIRPREFIX was not set > to whatever it was set to during buildworld. That was easy > enough to figure out when a bunch of things don't add up. That's a very annoying problem, and even more annoying to track down. > But neither problem mentioned in the email had anything to > do with MAKEOBJDIRPREFIX. Having to set the COMPILER_TYPE > as part of an install is a bug. Entering a powerpc buildenv > and having a compiler that builds for the host (or maybe > just some default) is a regression. When MAKEOBJDIRPREFIX isn't set, it takes whatever compiler it can find. It should probably error out instead, since the build environment isn't sane at this point. I ran into this probably a few weeks back. > The only thing the FreeBSD build is good at, really, is > building in /usr/src for the host. The rest is just not > up to par and I think it harms FreeBSD beyond belief. I have no problems building outside of /usr/src. - Justin signature.asc Description: PGP signature
Re: Poor state of the build infrastructure.
On Sep 24, 2014, at 4:47 PM, Justin Hibbits wrote: > It should probably error out instead, since the build > environment isn't sane at this point. I ran into this probably a few > weeks back. > >> The only thing the FreeBSD build is good at, really, is >> building in /usr/src for the host. The rest is just not >> up to par and I think it harms FreeBSD beyond belief. > > I have no problems building outside of /usr/src. It's not a problem in the sense that it cannot be done, but just think about having to share a machine with a bunch of people and you don't own the machine. You quickly realize that without MAKEOBJDIRPREFIX or with files in /etc (like /etc/make.conf) that you can't tweak, you quick;y realize how error prone everything and how much time you end up wasting. -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Poor state of the build infrastructure.
On Sep 24, 2014, at 16:33, Marcel Moolenaar wrote: > > On Sep 24, 2014, at 12:54 PM, John Baldwin wrote: > >> On Tuesday, September 23, 2014 09:29:48 AM Marcel Moolenaar wrote: >>> What is going on here? >>> Are we still in some kind of flux and people aren't done yet or is >>> this the intended state by virtue of noone having anything left on >>> there TODO list? >> >> Sorry to ask a dumb question, but are you sure you did the make buildworld >> first? Shouldn't that have errored if it couldn't build crt1? > > The root cause problem was that MAKEOBJDIRPREFIX was not set > to whatever it was set to during buildworld. That was easy > enough to figure out when a bunch of things don't add up. > > But neither problem mentioned in the email had anything to > do with MAKEOBJDIRPREFIX. Having to set the COMPILER_TYPE > as part of an install is a bug. Entering a powerpc buildenv > and having a compiler that builds for the host (or maybe > just some default) is a regression. > > The only thing the FreeBSD build is good at, really, is > building in /usr/src for the host. The rest is just not > up to par and I think it harms FreeBSD beyond belief. I agree with Marcel. COMPILER_TYPE showed up before 10.0-CURRENT dealing with the gcc->clang cutover and caused some minor issues when integrating with some FreeBSD makefiles unless using the top-level make rules. It would be nice if it defaulted to something sane now that the build knobs work has been moved out to src.opts.mk . Thanks! -Garrett signature.asc Description: Message signed with OpenPGP using GPGMail
memguard(9) panics in proc_reap with vm.memguard.options=3
> #11 0x80976e12 in vmem_xfree (vm=0x816d2200, > addr=18446741889258000384, size=0) at /usr/src/sys/kern/subr_vmem.c:1237 > #12 0x80bafbe0 in memguard_free (ptr=) at > /usr/src/sys/vm/memguard.c:421 > #13 0x80904191 in free (addr=0xfe03648a9000, mtp= out>) at /usr/src/sys/kern/kern_malloc.c:554 > #14 0x808e733f in proc_reap (td=, > p=0xf80bf043c000, status=, options= out>) at /usr/src/sys/kern/kern_exit.c:882 > #15 0x808e784a in proc_to_reap (td=0xf8021d499000, > p=0xf80bf043c000, idtype=, id=, > status=0xfe35559bc914, options=55, The assert is "size > 0". I enabled vm.memguard.options=3 while the system was running. From reading is_memguard_addr() I assume it should be safe to do so. Only new allocations should be passed through memguard_free(). This panic seems to happen easily. This comment in sys/vm/memguard.c memguard_free() makes me think something is stale: > /* > * This requires carnal knowledge of the implementation of > * kmem_free(), but since we've already replaced kmem_malloc() > * above, it's not really any worse. We want to use the > * vm_map lock to serialize updates to memguard_wasted, since > * we had the lock at increment. > */ > kmem_unback(kmem_object, addr, size); > if (sizev > size) > addr -= PAGE_SIZE; > vmem_xfree(memguard_arena, addr, sizev); By the way, I can't get the kernel to even boot with vm.memguard.options=3. It panics very early in device probing IIRC. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: shmget (No space left on device) issue with firefox
All 3 mozilla-based ports that I have installed (Firefox, Seamonkey, Thunderbird) crash immediately. * Does anyone else on 11 have this problem or is it just me? * I had been merging the linux-c6 ports into my tree for some time (now part of the official tree) - could this have any relation to the problem (due to flash-player)? This does not explain Thunderbird however. Regards. - FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/shmget-No-space-left-on-device-issue-with-firefox-tp5938162p5951793.html Sent from the freebsd-current mailing list archive at Nabble.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"
