Re: pmspcv panic on boot on this box
On Fri, Jul 31, 2015 at 01:33:32AM -0500, Larry Rosenman wrote: > On 2015-07-30 23:21, Glen Barber wrote: > >On Fri, Jul 31, 2015 at 04:18:15AM +, Glen Barber wrote: > >>On Thu, Jul 30, 2015 at 06:57:05PM -0500, Larry Rosenman wrote: > >>> On 2015-07-30 17:17, Glen Barber wrote: > >>> >On Thu, Jul 30, 2015 at 03:20:46PM -0500, Larry Rosenman wrote: > >>> >>Kernel compiling -- give mr a bit and I'll boot it and make sure it > >>> >>comes > >>> >>up. > >>> >> > >>> > > >>> >Larry, have you had any luck with this patch applied? If it resolves > >>> >your issue, I want to make sure it is included in the 10.2-RC2 build. > >>> > > >>> >Thanks. > >>> > > >>> [...] > >>> > >>> There are 3 pictures from the CURRENT panic. > >>> > >>> it STILL fails. :( > >>> > >> > >>Larry, I am sorry this is causing headaches for you, and I certainly > >>appreciate the prompt (and detailed) report, and assistance debugging > >>this. > >> > >>Would you be able to try one more test case? > >> > >>I'm interested in the behavior without the 'nodevice pmsdrv' addition to > >>your kernel configuration (effectively, removing the device from the > >>GENERIC kernel), and *without* the patch provided from Benno? > >> > > > >To be more specific on what I'm interested in, 'nodevice pmsdrv' and > >'device pmsdrv' should *both* be removed from the kernel configuration, > >and the pms(4) should only be available as a .ko module. > > > >>In particular, I'm interested in if ahd(4) attaches or if loader(8) > >>auto-loads pms(4) after the PCI IDs are detected. > >> > >>As this issue also affects the upcoming 10.2-RELEASE, your willingness > >>to help debug this is greatly appreciated, as you've tripped over > >>something that would have caused a great deal of pain after 10.2 was > >>release. > >> > >>I owe you several beers. > >> > > > >Glen > My kernel is based on GENERIC (I.E. include GENERIC). > With the nodedevice pmspcv, after boot, if I kldload pmspcv, NO PANIC. > Okay. I'm interested in the behavior if the pmspcv is removed entirely (no 'nodevice' or 'device' entry). > Unfortunately, I've got a funeral to go to in Dallas (~150Mi away from home) > today, Friday, and will > not be back until late Saturday (US/CDT, GMT-5). > My condolences. :( I'm going to be occupied testing the 10.2-RC2 (while taking into account the pms(4) issue), so no worries regarding getting back to me. There was another report as well, so I'll parallelize as needed. > I can probably help someone with this on Sunday, but would appreciate a > real-tome conversation, as the box in question is at > a COLO facility, and does NOT have IPMI, so I need to be physically there. > > Where in the world are you located, Glen? > I'm in Pennsylvania. I'll email you my phone number off-list when you return if that is helpful for debugging, and we can try to streamline this. Deal with the non-computer stuff first though, please. Glen pgpZWbFACqc7S.pgp Description: PGP signature
Re: pmspcv panic on boot on this box
On 2015-07-30 23:21, Glen Barber wrote: On Fri, Jul 31, 2015 at 04:18:15AM +, Glen Barber wrote: On Thu, Jul 30, 2015 at 06:57:05PM -0500, Larry Rosenman wrote: > On 2015-07-30 17:17, Glen Barber wrote: > >On Thu, Jul 30, 2015 at 03:20:46PM -0500, Larry Rosenman wrote: > >>Kernel compiling -- give mr a bit and I'll boot it and make sure it > >>comes > >>up. > >> > > > >Larry, have you had any luck with this patch applied? If it resolves > >your issue, I want to make sure it is included in the 10.2-RC2 build. > > > >Thanks. > > > [...] > > There are 3 pictures from the CURRENT panic. > > it STILL fails. :( > Larry, I am sorry this is causing headaches for you, and I certainly appreciate the prompt (and detailed) report, and assistance debugging this. Would you be able to try one more test case? I'm interested in the behavior without the 'nodevice pmsdrv' addition to your kernel configuration (effectively, removing the device from the GENERIC kernel), and *without* the patch provided from Benno? To be more specific on what I'm interested in, 'nodevice pmsdrv' and 'device pmsdrv' should *both* be removed from the kernel configuration, and the pms(4) should only be available as a .ko module. In particular, I'm interested in if ahd(4) attaches or if loader(8) auto-loads pms(4) after the PCI IDs are detected. As this issue also affects the upcoming 10.2-RELEASE, your willingness to help debug this is greatly appreciated, as you've tripped over something that would have caused a great deal of pain after 10.2 was release. I owe you several beers. Glen My kernel is based on GENERIC (I.E. include GENERIC). With the nodedevice pmspcv, after boot, if I kldload pmspcv, NO PANIC. Unfortunately, I've got a funeral to go to in Dallas (~150Mi away from home) today, Friday, and will not be back until late Saturday (US/CDT, GMT-5). I can probably help someone with this on Sunday, but would appreciate a real-tome conversation, as the box in question is at a COLO facility, and does NOT have IPMI, so I need to be physically there. Where in the world are you located, Glen? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 ___ 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: [CURRENT] buildworld failure: pfkeyv2.h:230:10: error: expected parameter declarator
On Fri, Jul 31, 2015 at 07:57:20AM +0200, O. Hartmann wrote:
> CURRENT (r286107) fails in buildworld with the error shown below:
>
> --- all_subdir_libipsec ---
> In file included from /usr/src/lib/libipsec/ipsec_strerror.c:39:
> In file included from /usr/obj/usr/src/tmp/usr/include/netipsec/ipsec.h:45:
> /usr/obj/usr/src/tmp/usr/include/net/pfkeyv2.h:230:10: error: expected
> parameter declarator CTASSERT(sizeof(struct sadb_x_policy) == 16);
> ^
> /usr/obj/usr/src/tmp/usr/include/net/pfkeyv2.h:230:10: error: expected ')'
> /usr/obj/usr/src/tmp/usr/include/net/pfkeyv2.h:230:9: note: to match this '('
Known issue.
Glen
pgp4x7wA6rQHl.pgp
Description: PGP signature
[CURRENT] buildworld failure: pfkeyv2.h:230:10: error: expected parameter declarator
CURRENT (r286107) fails in buildworld with the error shown below:
--- all_subdir_libipsec ---
In file included from /usr/src/lib/libipsec/ipsec_strerror.c:39:
In file included from /usr/obj/usr/src/tmp/usr/include/netipsec/ipsec.h:45:
/usr/obj/usr/src/tmp/usr/include/net/pfkeyv2.h:230:10: error: expected
parameter declarator CTASSERT(sizeof(struct sadb_x_policy) == 16);
^
/usr/obj/usr/src/tmp/usr/include/net/pfkeyv2.h:230:10: error: expected ')'
/usr/obj/usr/src/tmp/usr/include/net/pfkeyv2.h:230:9: note: to match 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"
FreeBSD_HEAD-tests - Build #1237 - Still Unstable
FreeBSD_HEAD-tests - Build #1237 - Still Unstable: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1237/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1237/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1237/console Change summaries: No changes The end of the build log: [...truncated 4438 lines...] [192.168.10.2] out: local/lutok/state_test:is_table__ok -> passed [0.289s] [192.168.10.2] out: local/lutok/state_test:is_userdata__empty -> passed [0.106s] [192.168.10.2] out: local/lutok/state_test:is_userdata__ok -> passed [0.130s] [192.168.10.2] out: local/lutok/state_test:load_file__api_error -> passed [0.090s] [192.168.10.2] out: local/lutok/state_test:load_file__file_not_found_error -> passed [0.104s] [192.168.10.2] out: local/lutok/state_test:load_file__ok -> passed [0.071s] [192.168.10.2] out: local/lutok/state_test:load_string__fail -> passed [0.140s] [192.168.10.2] out: local/lutok/state_test:load_string__ok -> passed [0.115s] [192.168.10.2] out: local/lutok/state_test:new_table -> passed [0.146s] [192.168.10.2] out: local/lutok/state_test:new_userdata -> passed [0.065s] [192.168.10.2] out: local/lutok/state_test:next__empty -> passed [0.070s] [192.168.10.2] out: local/lutok/state_test:next__many -> passed [0.141s] [192.168.10.2] out: local/lutok/state_test:open_all -> passed [0.100s] [192.168.10.2] out: local/lutok/state_test:open_base -> passed [0.097s] [192.168.10.2] out: local/lutok/state_test:open_string -> passed [0.084s] [192.168.10.2] out: local/lutok/state_test:open_table -> passed [0.098s] [192.168.10.2] out: local/lutok/state_test:pcall__fail -> passed [0.079s] [192.168.10.2] out: local/lutok/state_test:pcall__ok -> passed [0.045s] [192.168.10.2] out: local/lutok/state_test:pop__many -> passed [0.069s] [192.168.10.2] out: local/lutok/state_test:pop__one -> passed [0.068s] [192.168.10.2] out: local/lutok/state_test:push_boolean -> passed [0.261s] [192.168.10.2] out: local/lutok/state_test:push_cxx_closure -> passed [0.457s] [192.168.10.2] out: local/lutok/state_test:push_cxx_function__fail_anything -> passed [0.096s] [192.168.10.2] out: local/lutok/state_test:push_cxx_function__fail_exception -> passed [0.245s] [192.168.10.2] out: local/lutok/state_test:push_cxx_function__fail_overflow -> passed [0.370s] [192.168.10.2] out: local/lutok/state_test:push_cxx_function__ok -> passed [0.219s] [192.168.10.2] out: local/lutok/state_test:push_integer -> passed [0.120s] [192.168.10.2] out: local/lutok/state_test:push_nil -> passed [0.163s] [192.168.10.2] out: local/lutok/state_test:push_string -> passed [0.098s] [192.168.10.2] out: local/lutok/state_test:push_value -> passed [0.144s] [192.168.10.2] out: local/lutok/state_test:raw_get -> passed [0.075s] [192.168.10.2] out: local/lutok/state_test:raw_set -> passed [0.083s] [192.168.10.2] out: local/lutok/state_test:registry_index -> passed [0.068s] [192.168.10.2] out: local/lutok/state_test:set_global -> passed [0.087s] [192.168.10.2] out: local/lutok/state_test:set_metatable -> passed [0.038s] [192.168.10.2] out: local/lutok/state_test:set_table__nil -> passed [0.038s] [192.168.10.2] out: local/lutok/state_test:set_table__ok -> passed [0.073s] [192.168.10.2] out: local/lutok/state_test:to_boolean -> passed [0.038s] [192.168.10.2] out: local/lutok/state_test:to_integer -> passed [0.271s] [192.168.10.2] out: local/lutok/state_test:to_string -> passed [0.199s] [192.168.10.2] out: local/lutok/state_test:to_userdata -> passed [0.290s] [192.168.10.2] out: local/lutok/state_test:upvalue_index -> passed [0.163s] [192.168.10.2] out: sys/aio/aio_test:aio_fifo_test -> skipped: module aio could not be resolved: No such file or directory [0.320s] [192.168.10.2] out: sys/aio/aio_test:aio_file_test -> skipped: module aio could not be resolved: No such file or directory [0.034s] [192.168.10.2] out: sys/aio/aio_test:aio_md_test -> skipped: module aio could not be resolved: No such file or directory [0.034s] [192.168.10.2] out: sys/aio/aio_test:aio_pipe_test -> skipped: module aio could not be resolved: No such file or directory [0.125s] [192.168.10.2] out: sys/aio/aio_test:aio_pty_test -> skipped: module aio could not be resolved: No such file or directory [0.171s] [192.168.10.2] out: sys/aio/aio_test:aio_unix_socketpair_test -> skipped: module aio could not be resolved: No such file or directory [0.112s] [192.168.10.2] out: sys/aio/aio_kqueue_test:main -> passed [0.101s] [192.168.10.2] out: sys/aio/lio_kqueue_test:main -> passed [0.039s] [192.168.10.2] out: sys/fifo/fifo_create:main -> passed [4.478s] [192.168.10.2] out: sys/fifo/fifo_io:main -> passed [12.106s] [192.168.10.2] out: sys/fifo/fifo_misc:main -> passed [0.823s] [192.168.10.2] out: sys/fifo/fifo_open:main -> passed [15.340s] [192.168.10.2] out: sys/file/ftr
FreeBSD_HEAD_i386 - Build #722 - Still Failing
FreeBSD_HEAD_i386 - Build #722 - Still Failing: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/722/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/722/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/722/console Change summaries: 286107 by np: cxgbe(4): initialize debug_flags from the kernel environment. MFC after: 3 days 286106 by kib: vn_io_fault() handling of the LOR for i/o into the file-backed buffers has observable overhead when the buffer pages are not resident or not mapped. The overhead comes at least from two factors, one is the additional work needed to detect the situation, prepare and execute the rollbacks. Another is the consequence of the i/o splitting into the batches of the held pages, causing filesystems see series of the smaller i/o requests instead of the single large request. Note that expected case of the resident i/o buffer does not expose these issues. Provide a prefaulting for the userspace i/o buffers, disabled by default. I am careful of not enabling prefaulting by default for now, since it would be detrimental for the applications which speculatively pass extra-large buffers of anonymous memory to not deal with buffer sizing (if such apps exist). Found and tested by:bde, emaste Sponsored by: The FreeBSD Foundation MFC after: 1 week 286103 by jmg: The implementation note isn't true anymore.. Not that anyone reads it, but those that do, remind them that this isn't usable in userland... I can't wait till this doc is wrong.. The end of the build log: [...truncated 58337 lines...] --- gpio.o --- cc -O2 -pipe -I/usr/src/lib/libgpio -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/lib/libgpio/gpio.c -o gpio.o --- all_subdir_libdwarf --- --- libdwarf.o --- cc -O2 -pipe -I. -I/usr/src/lib/libdwarf/../../contrib/elftoolchain/libdwarf -I/usr/src/lib/libdwarf/../../contrib/elftoolchain/common -I/usr/src/lib/libdwarf/../../contrib/elftoolchain/libelf -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/lib/libdwarf/../../contrib/elftoolchain/libdwarf/libdwarf.c -o libdwarf.o --- all_subdir_libgpio --- --- libgpio.so.0 --- building shared library libgpio.so.0 cc -fstack-protector -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-textrel -o libgpio.so.0 -Wl,-soname,libgpio.so.0 `NM='nm' lorder gpio.So | tsort -q` --- all_subdir_libdwarf --- --- libdwarf.So --- cc -fpic -DPIC -O2 -pipe -I. -I/usr/src/lib/libdwarf/../../contrib/elftoolchain/libdwarf -I/usr/src/lib/libdwarf/../../contrib/elftoolchain/common -I/usr/src/lib/libdwarf/../../contrib/elftoolchain/libelf -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/lib/libdwarf/../../contrib/elftoolchain/libdwarf/libdwarf.c -o libdwarf.So --- libdwarf_abbrev.o --- cc -O2 -pipe -I. -I/usr/src/lib/libdwarf/../../contrib/elftoolchain/libdwarf -I/usr/src/lib/libdwarf/../../contrib/elftoolchain/common -I/usr/src/lib/libdwarf/../../contrib/elftoolchain/libelf -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/lib/libdwarf/../../contrib/elftoolchain/libdwarf/libdwarf_abbrev.c -o libdwarf_abbrev.o --- all_subdir_libgpio --- --- libgpio.a ---
Re: pmspcv panic on boot on this box
On Fri, Jul 31, 2015 at 04:48:18AM +, mailingli...@debank.tv wrote: > July 31 2015 4:21 PM, "Glen Barber" wrote: > > On Fri, Jul 31, 2015 at 04:18:15AM +, Glen Barber wrote: > > > >> On Thu, Jul 30, 2015 at 06:57:05PM -0500, Larry Rosenman wrote: > >>> On 2015-07-30 17:17, Glen Barber wrote: > On Thu, Jul 30, 2015 at 03:20:46PM -0500, Larry Rosenman wrote: > > Kernel compiling -- give mr a bit and I'll boot it and make sure it > > comes > > up. > > > > Larry, have you had any luck with this patch applied? If it resolves > your issue, I want to make sure it is included in the 10.2-RC2 build. > > Thanks. > > >>> [...] > >>> > >>> There are 3 pictures from the CURRENT panic. > >>> > >>> it STILL fails. :( > >>> > >> > >> Larry, I am sorry this is causing headaches for you, and I certainly > >> appreciate the prompt (and detailed) report, and assistance debugging > >> this. > >> > >> Would you be able to try one more test case? > >> > >> I'm interested in the behavior without the 'nodevice pmsdrv' addition to > >> your kernel configuration (effectively, removing the device from the > >> GENERIC kernel), and *without* the patch provided from Benno? > > > > To be more specific on what I'm interested in, 'nodevice pmsdrv' and > > 'device pmsdrv' should *both* be removed from the kernel configuration, > > and the pms(4) should only be available as a .ko module. > > > >> In particular, I'm interested in if ahd(4) attaches or if loader(8) > >> auto-loads pms(4) after the PCI IDs are detected. > >> > >> As this issue also affects the upcoming 10.2-RELEASE, your willingness > >> to help debug this is greatly appreciated, as you've tripped over > >> something that would have caused a great deal of pain after 10.2 was > >> release. > >> > >> I owe you several beers. > > > > Hi All, > > I've experienced the same bug although with a mvs(4) device on > 10.2-PRERELEASE, once the pms driver is removed from the kernel config the > problem disappears, I haven't had time to try the suggested patch as I only > found this thread after removing the pms driver from the kernel. > > Thank you for the information (stripped from my reply). So, to be clear, you have 'device pmsdrv' removed from the kernel config, but the /boot/kernel/pmspcv.ko is still available to the system? Glen pgpgXu5q7OFHI.pgp Description: PGP signature
Re: pmspcv panic on boot on this box
July 31 2015 4:21 PM, "Glen Barber" wrote: > On Fri, Jul 31, 2015 at 04:18:15AM +, Glen Barber wrote: > >> On Thu, Jul 30, 2015 at 06:57:05PM -0500, Larry Rosenman wrote: >>> On 2015-07-30 17:17, Glen Barber wrote: On Thu, Jul 30, 2015 at 03:20:46PM -0500, Larry Rosenman wrote: > Kernel compiling -- give mr a bit and I'll boot it and make sure it > comes > up. > Larry, have you had any luck with this patch applied? If it resolves your issue, I want to make sure it is included in the 10.2-RC2 build. Thanks. >>> [...] >>> >>> There are 3 pictures from the CURRENT panic. >>> >>> it STILL fails. :( >>> >> >> Larry, I am sorry this is causing headaches for you, and I certainly >> appreciate the prompt (and detailed) report, and assistance debugging >> this. >> >> Would you be able to try one more test case? >> >> I'm interested in the behavior without the 'nodevice pmsdrv' addition to >> your kernel configuration (effectively, removing the device from the >> GENERIC kernel), and *without* the patch provided from Benno? > > To be more specific on what I'm interested in, 'nodevice pmsdrv' and > 'device pmsdrv' should *both* be removed from the kernel configuration, > and the pms(4) should only be available as a .ko module. > >> In particular, I'm interested in if ahd(4) attaches or if loader(8) >> auto-loads pms(4) after the PCI IDs are detected. >> >> As this issue also affects the upcoming 10.2-RELEASE, your willingness >> to help debug this is greatly appreciated, as you've tripped over >> something that would have caused a great deal of pain after 10.2 was >> release. >> >> I owe you several beers. > > Glen Hi All, I've experienced the same bug although with a mvs(4) device on 10.2-PRERELEASE, once the pms driver is removed from the kernel config the problem disappears, I haven't had time to try the suggested patch as I only found this thread after removing the pms driver from the kernel. Rob Evers P.S. some info from the machine working system: # pciconf -l | grep mvs1 mvs1@pci0:5:0:0:class=0x010400 card=0x02439005 chip=0x02439005 rev=0x02 hdr=0x00 Failed boot: cib2: allocated memory range (0xd040-0xd04f) for rid 10 of pci0:5:0:0 map[18]: type I/O Port, range 32, base 0x3000, size 8, enabled pcib2: allocated I/O port range (0x3000-0x30ff) for rid 18 of pci0:5:0:0 map[1c]: type Memory, range 64, base 0xd030, size 20, enabled pcib2: attempting to grow memory window for (0xd030-0xd03f,0x10) front candidate range: 0xd030-0xd03f pci5: pci0:5:0:0 bar 0x1c failed to allocate pcib2: matched entry for 5.0.INTA pcib2: slot 0 INTA hardwired to IRQ 16 pmspcv0 port 0x3000-0x30ff mem 0xd040-0xd04f irq 16 at device 0.0 on pci5 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x28 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80a0d984 stack pointer = 0x28:0x821ac2c0 frame pointer = 0x28:0x821ac2d0 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 = 0 (swapper) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0x80a17a30 at kdb_backtrace+0x60 #1 0x809db196 at vpanic+0x126 #2 0x809db063 at panic+0x43 #3 0x80dee3eb at trap_fatal+0x36b #4 0x80dee6ed at trap_pfault+0x2ed #5 0x80dedd8a at trap+0x47a #6 0x80dd4102 at calltrap+0x8 #7 0x806b7a20 at agtiapi_attach+0x3a0 #8 0x80a0e6cd at device_attach+0x43d #9 0x80a0f82c at bus_generic_attach+0x4c #10 0x8038069c at acpi_pci_attach+0x15c #11 0x80a0e6cd at device_attach+0x43d #12 0x80a0f82c at bus_generic_attach+0x4c #13 0x803827cc at acpi_pcib_attach+0x22c #14 0x80383a2f at acpi_pcib_pci_attach+0x9f #15 0x80a0e6cd at device_attach+0x43d #16 0x80a0f82c at bus_generic_attach+0x4c #17 0x8038069c at acpi_pci_attach+0x15c Uptime: 1s ___ 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: pmspcv panic on boot on this box
On Fri, Jul 31, 2015 at 04:18:15AM +, Glen Barber wrote: > On Thu, Jul 30, 2015 at 06:57:05PM -0500, Larry Rosenman wrote: > > On 2015-07-30 17:17, Glen Barber wrote: > > >On Thu, Jul 30, 2015 at 03:20:46PM -0500, Larry Rosenman wrote: > > >>Kernel compiling -- give mr a bit and I'll boot it and make sure it > > >>comes > > >>up. > > >> > > > > > >Larry, have you had any luck with this patch applied? If it resolves > > >your issue, I want to make sure it is included in the 10.2-RC2 build. > > > > > >Thanks. > > > > > [...] > > > > There are 3 pictures from the CURRENT panic. > > > > it STILL fails. :( > > > > Larry, I am sorry this is causing headaches for you, and I certainly > appreciate the prompt (and detailed) report, and assistance debugging > this. > > Would you be able to try one more test case? > > I'm interested in the behavior without the 'nodevice pmsdrv' addition to > your kernel configuration (effectively, removing the device from the > GENERIC kernel), and *without* the patch provided from Benno? > To be more specific on what I'm interested in, 'nodevice pmsdrv' and 'device pmsdrv' should *both* be removed from the kernel configuration, and the pms(4) should only be available as a .ko module. > In particular, I'm interested in if ahd(4) attaches or if loader(8) > auto-loads pms(4) after the PCI IDs are detected. > > As this issue also affects the upcoming 10.2-RELEASE, your willingness > to help debug this is greatly appreciated, as you've tripped over > something that would have caused a great deal of pain after 10.2 was > release. > > I owe you several beers. > Glen pgp2B9PyLFDIx.pgp Description: PGP signature
Re: pmspcv panic on boot on this box
On Thu, Jul 30, 2015 at 06:57:05PM -0500, Larry Rosenman wrote: > On 2015-07-30 17:17, Glen Barber wrote: > >On Thu, Jul 30, 2015 at 03:20:46PM -0500, Larry Rosenman wrote: > >>Kernel compiling -- give mr a bit and I'll boot it and make sure it > >>comes > >>up. > >> > > > >Larry, have you had any luck with this patch applied? If it resolves > >your issue, I want to make sure it is included in the 10.2-RC2 build. > > > >Thanks. > > > [...] > > There are 3 pictures from the CURRENT panic. > > it STILL fails. :( > Larry, I am sorry this is causing headaches for you, and I certainly appreciate the prompt (and detailed) report, and assistance debugging this. Would you be able to try one more test case? I'm interested in the behavior without the 'nodevice pmsdrv' addition to your kernel configuration (effectively, removing the device from the GENERIC kernel), and *without* the patch provided from Benno? In particular, I'm interested in if ahd(4) attaches or if loader(8) auto-loads pms(4) after the PCI IDs are detected. As this issue also affects the upcoming 10.2-RELEASE, your willingness to help debug this is greatly appreciated, as you've tripped over something that would have caused a great deal of pain after 10.2 was release. I owe you several beers. Glen pgpxK8fd3erJc.pgp Description: PGP signature
FreeBSD_HEAD_amd64_gcc4.9 - Build #262 - Failure
FreeBSD_HEAD_amd64_gcc4.9 - Build #262 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/262/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/262/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/262/console Change summaries: 286102 by pfg: Buffer overflow in wall(1). This affected syslogd, wall and talkd. Detected by FORTIFY_SOURCE GSoC (with clang). Submitted by: Oliver Pinter Differential Revision: https://reviews.freebsd.org/D3254 Reviewed by:delphij, jmg MFC after: 3 days 286101 by jmg: these are comparing authenticators and need to be constant time... This could be a side channel attack... Now that we have a function for this, use it... jmgurney/ipsecgcm: 24d704cc and 7f37a14 286100 by jmg: Clean up this header file... use CTASSERTs now that we have them... Replace a draft w/ RFC that's over 10 years old. Note that _AALG and _EALG do not need to match what the IKE daemons think they should be.. This is part of the KABI... I decided to renumber AESCTR, but since we've never had working AESCTR mode, I'm not really breaking anything.. and it shortens a loop by quite a bit.. remove SKIPJACK IPsec support... SKIPJACK never made it out of draft (in 1999), only has 80bit key, NIST recommended it stop being used after 2010, and setkey nor any of the IKE daemons I checked supported it... jmgurney/ipsecgcm: a357a33, c75808b, e008669, b27b6d6 Reviewed by:gnn (earlier version) 286095 by eri: Correct IPSec SA statistic keeping The IPsec SA statistic keeping is used even for decision making on expiry/rekeying SAs. When there are multiple transformations being done the statistic keeping might be wrong. This mostly impacts multiple encapsulations on IPsec since the usual scenario it is not noticed due to the code path not taken. Differential Revision: https://reviews.freebsd.org/D3239 Reviewed by:ae, gnn Approved by:gnn(mentor) The end of the build log: [...truncated 95538 lines...] --- select.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include -L/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/lib --sysroot=/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libevent -DHAVE_CLOCK_GETTIME -DHAVE_FCNTL_H -DHAVE_POLL -DHAVE_SELECT -DHAVE_SETFD -DHAVE_STDARG_H -DHAVE_SYS_IOCTL_H -DHAVE_SYS_TIME_H -DHAVE_UNISTD_H -DHAVE_VASPRINTF -DHAVE_WORKING_KQUEUE -DVERSION='"1.3b"' -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libevent/../../contrib/pf/libevent/select.c -o select.o --- all_subdir_libdwarf --- --- dwarf_pro_die.So --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include -L/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/lib --sysroot=/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp -B/usr/local/x86_64-freebsd/bin/ -fpic -DPIC -O2 -pipe -I. -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libdwarf/../../contrib/elftoolchain/libdwarf -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libdwarf/../../contrib/elftoolchain/common -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libdwarf/../../contrib/elftoolchain/libelf -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /builds/FreeBSD_HEAD_am d64_gcc4.9/lib/libdwarf/../../contrib/elftoolchain/libdwarf/dwarf_pro_die.c -o dwarf_pro_die.So --- dwarf_pro_expr.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include -L/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/lib --sysroot=/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -I. -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libdwarf/../../contrib/elftoolchain/libdwarf -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libdwarf/../../contrib/elftoolchain/common -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libdwarf/../../contrib/elftoolchain/libelf -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
Re: FreeBSD_HEAD_i386 - Build #721 - Failure
jenkins-ad...@freebsd.org wrote this message on Fri, Jul 31, 2015 at 01:44 +: > FreeBSD_HEAD_i386 - Build #721 - Failure: > > Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/721/ > Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/721/changes > Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/721/console > > Change summaries: > > 286102 by pfg: > Buffer overflow in wall(1). > > This affected syslogd, wall and talkd. > Detected by FORTIFY_SOURCE GSoC (with clang). > > Submitted by: Oliver Pinter > Differential Revision:https://reviews.freebsd.org/D3254 > Reviewed by: delphij, jmg > MFC after:3 days > > 286101 by jmg: > these are comparing authenticators and need to be constant time... > This could be a side channel attack... Now that we have a function > for this, use it... > > jmgurney/ipsecgcm:24d704cc and 7f37a14 > > 286100 by jmg: > Clean up this header file... > > use CTASSERTs now that we have them... > > Replace a draft w/ RFC that's over 10 years old. > > Note that _AALG and _EALG do not need to match what the IKE daemons > think they should be.. This is part of the KABI... I decided to > renumber AESCTR, but since we've never had working AESCTR mode, I'm > not really breaking anything.. and it shortens a loop by quite > a bit.. > > remove SKIPJACK IPsec support... SKIPJACK never made it out of draft > (in 1999), only has 80bit key, NIST recommended it stop being used > after 2010, and setkey nor any of the IKE daemons I checked supported > it... > > jmgurney/ipsecgcm: a357a33, c75808b, e008669, b27b6d6 > > Reviewed by: gnn (earlier version) > > > > The end of the build log: > > [...truncated 58275 lines...] > cc -fpic -DPIC -O2 -pipe -I. > -I/usr/src/lib/libdwarf/../../contrib/elftoolchain/libdwarf > -I/usr/src/lib/libdwarf/../../contrib/elftoolchain/common > -I/usr/src/lib/libdwarf/../../contrib/elftoolchain/libelf -std=gnu99 > -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow > -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs > -Wredundant-decls -Wold-style-definition -Wno-pointer-sign > -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body > -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c > /usr/src/lib/libdwarf/../../contrib/elftoolchain/libdwarf/dwarf_ranges.c -o > dwarf_ranges.So > --- all_subdir_libgpio --- > --- libgpio.so.0 --- > building shared library libgpio.so.0 > cc -fstack-protector -shared -Wl,-x -Wl,--fatal-warnings > -Wl,--warn-shared-textrel -o libgpio.so.0 -Wl,-soname,libgpio.so.0 `NM='nm' > lorder gpio.So | tsort -q` > --- all_subdir_libgssapi --- > ===> lib/libgssapi (all) > --- all_subdir_libdwarf --- > --- dwarf_reloc.o --- > cc -O2 -pipe -I. > -I/usr/src/lib/libdwarf/../../contrib/elftoolchain/libdwarf > -I/usr/src/lib/libdwarf/../../contrib/elftoolchain/common > -I/usr/src/lib/libdwarf/../../contrib/elftoolchain/libelf -std=gnu99 > -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow > -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs > -Wredundant-decls -Wold-style-definition -Wno-pointer-sign > -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body > -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c > /usr/src/lib/libdwarf/../../contrib/elftoolchain/libdwarf/dwarf_reloc.c -o > dwarf_reloc.o > --- all_subdir_libgpio --- > --- libgpio.a --- > building static gpio library > ar -crD libgpio.a `NM='nm' lorder gpio.o | tsort -q` > ranlib -D libgpio.a > --- all_subdir_libdwarf --- > --- dwarf_reloc.So --- > cc -fpic -DPIC -O2 -pipe -I. > -I/usr/src/lib/libdwarf/../../contrib/elftoolchain/libdwarf > -I/usr/src/lib/libdwarf/../../contrib/elftoolchain/common > -I/usr/src/lib/libdwarf/../../contrib/elftoolchain/libelf -std=gnu99 > -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow > -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs > -Wredundant-decls -Wold-style-definition -Wno-pointer-sign > -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body > -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c > /usr/src/lib/libdwarf/../../contrib/elftoolchain/libdwarf/dwarf_reloc.c -o > dwarf_reloc.So > --- all_subdir_libfetch --- > --- libfetch.a --- > building static fetch library > ar -crD libfetch.a `NM='nm' lorder fetch.o common.o ftp.o http.o file.o | > tsort -q` > --- all_subdir_librpcsec_gss
FreeBSD_HEAD_i386 - Build #721 - Failure
FreeBSD_HEAD_i386 - Build #721 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/721/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/721/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/721/console Change summaries: 286102 by pfg: Buffer overflow in wall(1). This affected syslogd, wall and talkd. Detected by FORTIFY_SOURCE GSoC (with clang). Submitted by: Oliver Pinter Differential Revision: https://reviews.freebsd.org/D3254 Reviewed by:delphij, jmg MFC after: 3 days 286101 by jmg: these are comparing authenticators and need to be constant time... This could be a side channel attack... Now that we have a function for this, use it... jmgurney/ipsecgcm: 24d704cc and 7f37a14 286100 by jmg: Clean up this header file... use CTASSERTs now that we have them... Replace a draft w/ RFC that's over 10 years old. Note that _AALG and _EALG do not need to match what the IKE daemons think they should be.. This is part of the KABI... I decided to renumber AESCTR, but since we've never had working AESCTR mode, I'm not really breaking anything.. and it shortens a loop by quite a bit.. remove SKIPJACK IPsec support... SKIPJACK never made it out of draft (in 1999), only has 80bit key, NIST recommended it stop being used after 2010, and setkey nor any of the IKE daemons I checked supported it... jmgurney/ipsecgcm: a357a33, c75808b, e008669, b27b6d6 Reviewed by:gnn (earlier version) The end of the build log: [...truncated 58275 lines...] cc -fpic -DPIC -O2 -pipe -I. -I/usr/src/lib/libdwarf/../../contrib/elftoolchain/libdwarf -I/usr/src/lib/libdwarf/../../contrib/elftoolchain/common -I/usr/src/lib/libdwarf/../../contrib/elftoolchain/libelf -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/lib/libdwarf/../../contrib/elftoolchain/libdwarf/dwarf_ranges.c -o dwarf_ranges.So --- all_subdir_libgpio --- --- libgpio.so.0 --- building shared library libgpio.so.0 cc -fstack-protector -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-textrel -o libgpio.so.0 -Wl,-soname,libgpio.so.0 `NM='nm' lorder gpio.So | tsort -q` --- all_subdir_libgssapi --- ===> lib/libgssapi (all) --- all_subdir_libdwarf --- --- dwarf_reloc.o --- cc -O2 -pipe -I. -I/usr/src/lib/libdwarf/../../contrib/elftoolchain/libdwarf -I/usr/src/lib/libdwarf/../../contrib/elftoolchain/common -I/usr/src/lib/libdwarf/../../contrib/elftoolchain/libelf -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/lib/libdwarf/../../contrib/elftoolchain/libdwarf/dwarf_reloc.c -o dwarf_reloc.o --- all_subdir_libgpio --- --- libgpio.a --- building static gpio library ar -crD libgpio.a `NM='nm' lorder gpio.o | tsort -q` ranlib -D libgpio.a --- all_subdir_libdwarf --- --- dwarf_reloc.So --- cc -fpic -DPIC -O2 -pipe -I. -I/usr/src/lib/libdwarf/../../contrib/elftoolchain/libdwarf -I/usr/src/lib/libdwarf/../../contrib/elftoolchain/common -I/usr/src/lib/libdwarf/../../contrib/elftoolchain/libelf -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/lib/libdwarf/../../contrib/elftoolchain/libdwarf/dwarf_reloc.c -o dwarf_reloc.So --- all_subdir_libfetch --- --- libfetch.a --- building static fetch library ar -crD libfetch.a `NM='nm' lorder fetch.o common.o ftp.o http.o file.o | tsort -q` --- all_subdir_librpcsec_gss --- ===> lib/librpcsec_gss (all) --- all_subdir_libfetch --- ranlib -D libfetch.a --- all_subdir_libiconv_modules --- ===> lib/libiconv_modules (all) --- all_subdir_libdwarf --- --- dwarf_sections.o --- cc -O2 -pipe -I. -I/usr/src/lib/libdwarf/../../contrib/elftoolchain/libdwarf -I/usr/src/lib/libdwar
Re: pmspcv panic on boot on this box
On 2015-07-30 17:17, Glen Barber wrote: On Thu, Jul 30, 2015 at 03:20:46PM -0500, Larry Rosenman wrote: Kernel compiling -- give mr a bit and I'll boot it and make sure it comes up. Larry, have you had any luck with this patch applied? If it resolves your issue, I want to make sure it is included in the 10.2-RC2 build. Thanks. Glen https://drive.google.com/file/d/1ouZHMEWXiPcZQ_zmpJY6hhwPItXitb7DxQ/view?usp=sharing https://drive.google.com/file/d/1CBf4v9cgSc3RgVLZDLdYDztP0_29k1vzAA/view?usp=sharing https://drive.google.com/file/d/1MuvvEXROrkiP2N78v9t1xdYPR7dDGO_0lA/view?usp=sharing There are 3 pictures from the CURRENT panic. it STILL fails. :( -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 ___ 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"
FreeBSD_HEAD-tests - Build #1236 - Unstable
[0.061s] [192.168.10.2] out: sys/kern/unix_seqpacket_test:sendrecv_64k_nonblocking -> passed [0.078s] [192.168.10.2] out: sys/kern/unix_seqpacket_test:sendrecv_8k -> passed [0.073s] [192.168.10.2] out: sys/kern/unix_seqpacket_test:sendrecv_8k_nonblocking -> passed [0.050s] [192.168.10.2] out: sys/kern/unix_seqpacket_test:sendto_recvfrom -> passed [0.060s] [192.168.10.2] out: sys/kern/unix_seqpacket_test:shutdown_send -> passed [0.029s] [192.168.10.2] out: sys/kern/unix_seqpacket_test:shutdown_send_sigpipe -> passed [0.028s] [192.168.10.2] out: sys/kern/execve/execve_test:bad_interp_len -> passed [0.079s] [192.168.10.2] out: sys/kern/execve/execve_test:empty -> passed [0.132s] [192.168.10.2] out: sys/kern/execve/execve_test:good_aout -> passed [0.134s] [192.168.10.2] out: sys/kern/execve/execve_test:good_script -> passed [0.187s] [192.168.10.2] out: sys/kern/execve/execve_test:non_exist -> passed [0.072s] [192.168.10.2] out: sys/kern/execve/execve_test:non_exist_shell -> passed [0.120s] [192.168.10.2] out: sys/kern/execve/execve_test:script_arg -> passed [0.076s] [192.168.10.2] out: sys/kern/execve/execve_test:script_arg_nospace -> passed [0.075s] [192.168.10.2] out: sys/kern/execve/execve_test:sparse_aout -> passed [0.086s] [192.168.10.2] out: sys/kern/execve/execve_test:trunc_aout -> passed [0.107s] [192.168.10.2] out: sys/kqueue/kqueue_test:main -> passed [11.188s] [192.168.10.2] out: sys/mqueue/mqueue_test:mqtest1 -> passed [0.140s] [192.168.10.2] out: sys/mqueue/mqueue_test:mqtest2 -> passed [0.085s] [192.168.10.2] out: sys/mqueue/mqueue_test:mqtest3 -> passed [0.140s] [192.168.10.2] out: sys/mqueue/mqueue_test:mqtest4 -> passed [0.105s] [192.168.10.2] out: sys/mqueue/mqueue_test:mqtest5 -> passed [0.119s] [192.168.10.2] out: sys/netinet/fibs_test:arpresolve_checks_interface_fib -> skipped: Required configuration property 'fibs' not defined [0.000s] [192.168.10.2] out: sys/netinet/fibs_test:default_route_with_multiple_fibs_on_same_subnet -> skipped: Required configuration property 'fibs' not defined [0.000s] [192.168.10.2] out: sys/netinet/fibs_test:loopback_and_network_routes_on_nondefault_fib -> skipped: Required configuration property 'fibs' not defined [0.000s] [192.168.10.2] out: sys/netinet/fibs_test:same_ip_multiple_ifaces -> skipped: Required configuration property 'fibs' not defined [0.000s] [192.168.10.2] out: sys/netinet/fibs_test:same_ip_multiple_ifaces_fib0 -> skipped: Required configuration property 'fibs' not defined [0.000s] [192.168.10.2] out: sys/netinet/fibs_test:subnet_route_with_multiple_fibs_on_same_subnet -> skipped: Required configuration property 'fibs' not defined [0.000s] [192.168.10.2] out: sys/netinet/fibs_test:udp_dontroute -> skipped: Required configuration property 'fibs' not defined [0.000s] [192.168.10.2] out: sys/opencrypto/runtests:main -> passed [0.093s] [192.168.10.2] out: sys/vm/mmap_test:main -> passed [0.148s] [192.168.10.2] out: [192.168.10.2] out: Results file id is usr_tests.20150730-224202-164369 [192.168.10.2] out: Results saved to /root/.kyua/store/results.usr_tests.20150730-224202-164369.db [192.168.10.2] out: [192.168.10.2] out: 4339/4340 passed (1 failed) [192.168.10.2] out: Warning: run() received nonzero return code 1 while executing 'kyua test'! [192.168.10.2] run: kyua report --verbose --results-filter passed,skipped,xfail,broken,failed --output test-report.txt [192.168.10.2] run: kyua report-junit --output=test-report.xml [192.168.10.2] run: shutdown -p now [192.168.10.2] out: Shutdown NOW! [192.168.10.2] out: shutdown: [pid 68109] [192.168.10.2] out: adcast 192.168.10.255 kyuatestprompt # Jul 30 22:57:54 t_openpam_readword: in openpam_readword(): unexpected end of file lock order reversal: 1st 0xf800073e19a0 syncer (syncer) @ /builds/FreeBSD_HEAD/sys/kern/vfs_subr.c:1767 2nd 0xf80007da17c8 ufs (ufs) @ /builds/FreeBSD_HEAD/sys/kern/vfs_subr.c:2219 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0096f0a760 witness_checkorder() at witness_checkorder+0xe7a/frame 0xfe0096f0a7e0 __lockmgr_args() at __lockmgr_args+0xa5c/frame 0xfe0096f0a910 ffs_lock() at ffs_lock+0x84/frame 0xfe0096f0a960 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfe0096f0a990 _vn_lock() at _vn_lock+0x9a/frame 0xfe0096f0aa00 vget() at vget+0x7e/frame 0xfe0096f0aa50 vfs_msync() at vfs_msync+0xd6/frame 0xfe0096f0aab0 sync_fsync() at sync_fsync+0xc6/frame 0xfe0096f0aaf0 VOP_FSYNC_APV() at VOP_FSYNC_APV+0xf7/frame 0xfe0096f0ab20 sched_sync() at sched_sync+0x3c8/frame 0xfe0096f0abb0 fork_exit() at fork_exit+0x84/frame 0xfe0096f0abf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe0096f0abf0 ---
Re: pmspcv panic on boot on this box
On Thu, Jul 30, 2015 at 03:20:46PM -0500, Larry Rosenman wrote: > Kernel compiling -- give mr a bit and I'll boot it and make sure it comes > up. > Larry, have you had any luck with this patch applied? If it resolves your issue, I want to make sure it is included in the 10.2-RC2 build. Thanks. Glen pgpBxa8F2_IXJ.pgp Description: PGP signature
Re: Segmentation fault running ntpd
Adrian the crash we are seeing here is very easily reproducible. Grab our private ports repo and revert my most recent revert and build. It appears to show up multiple times per day somehow in our configuration. On 7/28/15 7:25 PM, Adrian Chadd wrote: On 28 July 2015 at 16:09, David Wolfskill wrote: On Tue, Jul 28, 2015 at 04:05:33PM -0700, Adrian Chadd wrote: Is this still happening for you? g1-245(10.2-P)[4] ls -lT /S4/ntpd.core -rw-r--r-- 1 root wheel 13783040 Jul 28 04:56:28 2015 /S4/ntpd.core Apparently so, yes. (/S4 is where I have the head root file system mounted when I'm not running from slice 4.) Hm, is there any way you can get symbols for it? I don't think I can easily get symbols for the crash we have, but my crash is also deep in malloc code.. -a ___ 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" ___ 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 in sysctl code in recent head
Thu, 30 Jul 2015 21:53:20 +0200 Mateusz Guzik написав: > On Thu, Jul 30, 2015 at 10:17:10PM +0300, Ivan Klymenko wrote: > > Thu, 30 Jul 2015 12:11:22 -0700 > > Navdeep Parhar написав: > > > > > Does anyone else see this too? > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201992 > > This bz is unrelated. Oops. Sorry. > > Problematic change was reverted in r286094. > ___ 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: pmspcv panic on boot on this box
On 2015-07-30 15:15, Glen Barber wrote:
On Thu, Jul 30, 2015 at 08:13:51PM +, Glen Barber wrote:
On Thu, Jul 30, 2015 at 03:09:30PM -0500, Larry Rosenman wrote:
> $ sudo -s
> Password:
> # cd /usr/src
> # patch -p0 < ~ler/pmspcv.diff
> Hmm... Looks like a unified diff to me...
> The text leading up to this was:
> --
> |Index: sys/dev/pms/freebsd/driver/common/lxutil.c
> |===
> |--- sys/dev/pms/freebsd/driver/common/lxutil.c(revision 286083)
> |+++ sys/dev/pms/freebsd/driver/common/lxutil.c(working copy)
> --
> Patching file sys/dev/pms/freebsd/driver/common/lxutil.c using Plan A...
> Hunk #1 failed at 758.
> Hunk #2 failed at 767.
> 2 out of 2 hunks failed--saving rejects to
> sys/dev/pms/freebsd/driver/common/lxutil.c.rej
> done
> # vi sys/dev/pms/freebsd/driver/common/lxutil.c.rej
> @@ -758,6 +758,7 @@
>int idx;^M
>static U32 cardMap[4] = { 0, 0, 0, 0 };^M
Hmm. Somehow you ended up with MS DOS EOL...
I'm able to apply the patch without issues. Try this:
vi pmspcv.diff
:%s:[ctrl-m]::g
It should apply afterward.
Or, fetch the patch from here:
https://people.freebsd.org/~gjb/pmspcv.diff.txt
Glen
Kernel compiling -- give mr a bit and I'll boot it and make sure it
comes up.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961
___
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: pmspcv panic on boot on this box
On Thu, Jul 30, 2015 at 08:13:51PM +, Glen Barber wrote:
> On Thu, Jul 30, 2015 at 03:09:30PM -0500, Larry Rosenman wrote:
> > $ sudo -s
> > Password:
> > # cd /usr/src
> > # patch -p0 < ~ler/pmspcv.diff
> > Hmm... Looks like a unified diff to me...
> > The text leading up to this was:
> > --
> > |Index: sys/dev/pms/freebsd/driver/common/lxutil.c
> > |===
> > |--- sys/dev/pms/freebsd/driver/common/lxutil.c (revision 286083)
> > |+++ sys/dev/pms/freebsd/driver/common/lxutil.c (working copy)
> > --
> > Patching file sys/dev/pms/freebsd/driver/common/lxutil.c using Plan A...
> > Hunk #1 failed at 758.
> > Hunk #2 failed at 767.
> > 2 out of 2 hunks failed--saving rejects to
> > sys/dev/pms/freebsd/driver/common/lxutil.c.rej
> > done
> > # vi sys/dev/pms/freebsd/driver/common/lxutil.c.rej
> > @@ -758,6 +758,7 @@
> >int idx;^M
> >static U32 cardMap[4] = { 0, 0, 0, 0 };^M
>
> Hmm. Somehow you ended up with MS DOS EOL...
>
> I'm able to apply the patch without issues. Try this:
>
> vi pmspcv.diff
> :%s:[ctrl-m]::g
>
> It should apply afterward.
>
Or, fetch the patch from here:
https://people.freebsd.org/~gjb/pmspcv.diff.txt
Glen
pgpw87P9B5UV2.pgp
Description: PGP signature
Re: pmspcv panic on boot on this box
On Thu, Jul 30, 2015 at 03:09:30PM -0500, Larry Rosenman wrote:
> $ sudo -s
> Password:
> # cd /usr/src
> # patch -p0 < ~ler/pmspcv.diff
> Hmm... Looks like a unified diff to me...
> The text leading up to this was:
> --
> |Index: sys/dev/pms/freebsd/driver/common/lxutil.c
> |===
> |--- sys/dev/pms/freebsd/driver/common/lxutil.c (revision 286083)
> |+++ sys/dev/pms/freebsd/driver/common/lxutil.c (working copy)
> --
> Patching file sys/dev/pms/freebsd/driver/common/lxutil.c using Plan A...
> Hunk #1 failed at 758.
> Hunk #2 failed at 767.
> 2 out of 2 hunks failed--saving rejects to
> sys/dev/pms/freebsd/driver/common/lxutil.c.rej
> done
> # vi sys/dev/pms/freebsd/driver/common/lxutil.c.rej
> @@ -758,6 +758,7 @@
>int idx;^M
>static U32 cardMap[4] = { 0, 0, 0, 0 };^M
Hmm. Somehow you ended up with MS DOS EOL...
I'm able to apply the patch without issues. Try this:
vi pmspcv.diff
:%s:[ctrl-m]::g
It should apply afterward.
Glen
pgpNAsx5wWYdP.pgp
Description: PGP signature
Re: pmspcv panic on boot on this box
$ sudo -s
Password:
# cd /usr/src
# patch -p0 < ~ler/pmspcv.diff
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--
|Index: sys/dev/pms/freebsd/driver/common/lxutil.c
|===
|--- sys/dev/pms/freebsd/driver/common/lxutil.c (revision 286083)
|+++ sys/dev/pms/freebsd/driver/common/lxutil.c (working copy)
--
Patching file sys/dev/pms/freebsd/driver/common/lxutil.c using Plan A...
Hunk #1 failed at 758.
Hunk #2 failed at 767.
2 out of 2 hunks failed--saving rejects to
sys/dev/pms/freebsd/driver/common/lxutil.c.rej
done
# vi sys/dev/pms/freebsd/driver/common/lxutil.c.rej
@@ -758,6 +758,7 @@
int idx;^M
static U32 cardMap[4] = { 0, 0, 0, 0 };^M
u_int16_t agtiapi_dev; // PCI device ID^M
+ u_int16_t agtiapi_vendor; // PCI vendor ID^M
AGTIAPI_PRINTK("agtiapi_ProbeCard: start\n");^M
^M
if ( ! atomic_cmpset_32( &cardMap[thisCard], 0, 5 ) ) { // card
already ran^M
@@ -766,10 +767,12 @@
}^M
else {^M
agtiapi_dev = pci_get_device( dev ); // get PCI device ID^M
+agtiapi_vendor = pci_get_vendor( dev ); // get PCI vendor ID^M
for( idx = 0; idx < COUNT(ag_card_type); idx++ ) ^M
{^M
- if( ag_card_type[idx].deviceId == agtiapi_dev ) ^M
- { // device ID match^M
+ if( ag_card_type[idx].deviceId == agtiapi_dev &&^M
+ ag_card_type[idx].vendorId == agtiapi_vendor ) ^M
+ { // device and vendor IDs match^M
memset( (void *)&agCardInfoList[ thisCard ], 0,^M
sizeof(ag_card_info_t) );^M
thisCardInst->cardIdIndex = idx;^M
~
:q
#
Not good :(
On 2015-07-30 15:05, Benno Rice wrote:
Can you try the attached patch and let me know if it fixes the issue?
Many thanks,
Benno.
On Jul 30, 2015, at 11:55 AM, Benno Rice wrote:
Hi Larry,
I’ve brought this to the attention of PMC Sierra and we’re pretty sure
we’ve worked out what the problem is. I’m just waiting on their review
of the fix I’ve suggested.
Sorry this has caused you problems.
Many apologies,
Benno.
On Jul 28, 2015, at 2:01 PM, Larry Rosenman wrote:
When I upgraded an approximately 3 month old -CURRENT system to
yesterday, I
got page not present panics, after a message about pmspcv not
supporting
my ahd(4) deviceid.
I did NOT capture the panic, but adding
nodevicepmspcv
Allowed me to boot.
Dmesg.boot from the WORKING system attached.
I *CAN* work with someone if they want.
___
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"
___
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"
___
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"
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961
___
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: pmspcv panic on boot on this box
Can you try the attached patch and let me know if it fixes the issue? Many thanks, Benno. pmspcv.diff Description: Binary data > On Jul 30, 2015, at 11:55 AM, Benno Rice wrote: > > Hi Larry, > > I’ve brought this to the attention of PMC Sierra and we’re pretty sure we’ve > worked out what the problem is. I’m just waiting on their review of the fix > I’ve suggested. > > Sorry this has caused you problems. > > Many apologies, > Benno. > >> On Jul 28, 2015, at 2:01 PM, Larry Rosenman wrote: >> >> When I upgraded an approximately 3 month old -CURRENT system to yesterday, I >> got page not present panics, after a message about pmspcv not supporting >> my ahd(4) deviceid. >> >> I did NOT capture the panic, but adding >> >> nodevice pmspcv >> >> Allowed me to boot. >> >> Dmesg.boot from the WORKING system attached. >> >> I *CAN* work with someone if they want. >> >> >> ___ >> 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" > > ___ > 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" ___ 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 in sysctl code in recent head
On Thu, Jul 30, 2015 at 10:17:10PM +0300, Ivan Klymenko wrote: > Thu, 30 Jul 2015 12:11:22 -0700 > Navdeep Parhar написав: > > > Does anyone else see this too? > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201992 This bz is unrelated. Problematic change was reverted in r286094. -- Mateusz Guzik ___ 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 in sysctl code in recent head
Thu, 30 Jul 2015 12:11:22 -0700 Navdeep Parhar написав: > Does anyone else see this too? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201992 ___ 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 in sysctl code in recent head
A kernel built from head as of today panics with this on loading a module. Does anyone else see this too? panic: sleepq_add: td 0xf8000e7f89e0 to sleep on wchan 0x824056c8 with sleeping prohibited cpuid = 3 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2e/frame 0xfe02383ebe40 kdb_backtrace() at kdb_backtrace+0x58/frame 0xfe02383ebf10 vpanic() at vpanic+0x25e/frame 0xfe02383ebfe0 kassert_panic() at kassert_panic+0xcc/frame 0xfe02383ec070 sleepq_add() at sleepq_add+0x1ed/frame 0xfe02383ec0e0 _sx_xlock_hard() at _sx_xlock_hard+0xa88/frame 0xfe02383ec320 __sx_xlock() at __sx_xlock+0x77/frame 0xfe02383ec380 _sx_xlock() at _sx_xlock+0x170/frame 0xfe02383ec3f0 _rm_rlock_hard() at _rm_rlock_hard+0x323/frame 0xfe02383ec490 _rm_rlock() at _rm_rlock+0x173/frame 0xfe02383ec4e0 _rm_rlock_debug() at _rm_rlock_debug+0x284/frame 0xfe02383ec560 sysctl_root_handler_locked() at sysctl_root_handler_locked+0x148/frame 0xfe02383ec5b0 sysctl_root() at sysctl_root+0x38d/frame 0xfe02383ec660 userland_sysctl() at userland_sysctl+0x315/frame 0xfe02383ec7a0 sys___sysctl() at sys___sysctl+0xfc/frame 0xfe02383ec8a0 syscallenter() at syscallenter+0x521/frame 0xfe02383ec980 amd64_syscall() at amd64_syscall+0x2a/frame 0xfe02383ecab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe02383ecab0 --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x8011b02ba, rsp = 0x7fffda28, rbp = 0x7fffda60 --- KDB: enter: panic ___ 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: pmspcv panic on boot on this box
Hi Larry, I’ve brought this to the attention of PMC Sierra and we’re pretty sure we’ve worked out what the problem is. I’m just waiting on their review of the fix I’ve suggested. Sorry this has caused you problems. Many apologies, Benno. > On Jul 28, 2015, at 2:01 PM, Larry Rosenman wrote: > > When I upgraded an approximately 3 month old -CURRENT system to yesterday, I > got page not present panics, after a message about pmspcv not supporting > my ahd(4) deviceid. > > I did NOT capture the panic, but adding > > nodevice pmspcv > > Allowed me to boot. > > Dmesg.boot from the WORKING system attached. > > I *CAN* work with someone if they want. > > > ___ > 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" ___ 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: E1000 mbuf leaks
On 07/27/15 at 01:02P, Hans Petter Selasky wrote: > Hi, > > I'm currently doing some busdma work, and possibly stepped over some > driver bugs. When "bus_dmamap_load_mbuf_sg()" returns ENOMEM the mbuf > chain is not freed. Is there some magic in "bus_dmamap_load_mbuf_sg()" > for that error code or is there a possible memory leak in all E1000 > drivers? See attached patch. Can you open a phabricator review if this hasn't been reviewed/committed yet? cheers, Hiren pgpJXdQwQgkIL.pgp Description: PGP signature
Re: FreeBSD_HEAD_amd64_gcc4.9 - Build #260 - Failure
Fixed in the very next revision, r286077. On Thu, Jul 30, 2015 at 9:31 AM, wrote: > FreeBSD_HEAD_amd64_gcc4.9 - Build #260 - Failure: > > Build information: > https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/260/ > Full change log: > https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/260/changes > Full build log: > https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/260/console > > Change summaries: > > 286076 by royger: > vfs: fix off-by-one error in vfs_buf_check_mapped > > The check added in r285872 can trigger for valid buffers if the buffer space > used happens to be just after unmapped_buf in KVA space. > > Discussed with: kib > Sponsored by: Citrix Systems R&D > > 286074 by pfg: > GCC: Add a new option "-fstack-protector-strong" > > This includes additional functions to be protected: those that > have local array definitions, or have references to local frame > addresses. This is a new option in GCC-4.9 that was relicensed > by Han Shen from Google under GPLv2 for OpenBSD. > > Obtained from: OpenBSD (2014-01-14) > MFC after: 2 weeks > > 286073 by emaste: > Add ARM64TODO markers to unimplemented functionality > > Reviewed by:andrew > Sponsored by: The FreeBSD Foundation > Differential Revision: https://reviews.freebsd.org/D2389 > > 286072 by zbb: > Enable IRQ during syscalls on ARM64 > > FreeBSD provides a feature called Adaptive Mutexes, which allows > a thread to spin for a while when the mutex is taken instead of > immediately going to sleep. This causes issues when called from > syscall handler if interrupts are masked. If every other core > also attempts to access the same mutex there is a chance that > all of them are spinning on the same lock at the same time. > If interrupts are disabled, no kernel preemtion can occur and > the system becomes unresponsive. > > This patch enables interrupts when syscall is being executed > and masks them as soon as it is completed. > > Reviewed by: andrew > Obtained from: Semihalf > Sponsored by: The FreeBSD Foundation > Differential Revision: https://reviews.freebsd.org/D3246 > > 286071 by zbb: > Remove obsolete vendor code from Alpine platform support > > This is a clean-up patch from a serie delivering support for > Annapurna Labs Alpine PoC. > The HAL files have already been added to sys/contrib/alpine-hal > so there is no need for them in the platform directory. > This patch removes obsolete files. > > Reviewed by:andrew > Obtained from: Semihalf > Sponsored by: Annapurna Labs > Differential Revision: https://reviews.freebsd.org/D3248 > > 286070 by emaste: > Add ELF Tool Chain's ar(1) and elfdump(1) to contrib > > ELF Tool Chain built on FreeBSD's ar and elfdump, but has a number of > improvements and enhancements. Bring them into contrib in order to start > integrating into our build. > > 286069 by ae: > Build if_stf(4) module only when both INET and INET6 support are enabled. > > > > The end of the build log: > > [...truncated 297432 lines...] > ./machine/smp.h:38:12: note: previous declaration of 'bootAP' was here > extern int bootAP; > ^ > ctfconvert -L VERSION -g kern_shutdown.o > --- kern_time.o --- > /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem > /builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include > > -L/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/lib > > --sysroot=/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp > -B/usr/local/x86_64-freebsd/bin/ -c -O2 -frename-registers -pipe > -fno-strict-aliasing -g -nostdinc -I. > -I/builds/FreeBSD_HEAD_amd64_gcc4.9/sys > -I/builds/FreeBSD_HEAD_amd64_gcc4.9/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 -fwrapv > -fstack-protector -gdwarf-2 -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-u nk > nown-pragmas -Wno-error=inline -Wno-error=enum-compare > -Wno-error=unused-but-set-variable -Wno-error=aggressive-loop-optimizations > -Wno-error=maybe-uninitialized -Wno-error=array-bounds -Wno-error=address > -Wno-error=cast-qual -Wno-error=sequence-point -Wno-error=attributes > -Wno-error=strict-overflow -Wno-error=overflow -fno-common -fms-extensions > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -std=iso9899:1999 > /builds/FreeBSD_HEAD_amd64_gcc4.9/sys/kern/kern_time.c > --- kern_jail.o --- > ctfconvert -L VERSION -g kern_jail.o > --- posix4_mib.o --- > /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem > /builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include
FreeBSD_HEAD_amd64_gcc4.9 - Build #260 - Failure
FreeBSD_HEAD_amd64_gcc4.9 - Build #260 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/260/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/260/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/260/console Change summaries: 286076 by royger: vfs: fix off-by-one error in vfs_buf_check_mapped The check added in r285872 can trigger for valid buffers if the buffer space used happens to be just after unmapped_buf in KVA space. Discussed with: kib Sponsored by: Citrix Systems R&D 286074 by pfg: GCC: Add a new option "-fstack-protector-strong" This includes additional functions to be protected: those that have local array definitions, or have references to local frame addresses. This is a new option in GCC-4.9 that was relicensed by Han Shen from Google under GPLv2 for OpenBSD. Obtained from: OpenBSD (2014-01-14) MFC after: 2 weeks 286073 by emaste: Add ARM64TODO markers to unimplemented functionality Reviewed by:andrew Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D2389 286072 by zbb: Enable IRQ during syscalls on ARM64 FreeBSD provides a feature called Adaptive Mutexes, which allows a thread to spin for a while when the mutex is taken instead of immediately going to sleep. This causes issues when called from syscall handler if interrupts are masked. If every other core also attempts to access the same mutex there is a chance that all of them are spinning on the same lock at the same time. If interrupts are disabled, no kernel preemtion can occur and the system becomes unresponsive. This patch enables interrupts when syscall is being executed and masks them as soon as it is completed. Reviewed by: andrew Obtained from: Semihalf Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D3246 286071 by zbb: Remove obsolete vendor code from Alpine platform support This is a clean-up patch from a serie delivering support for Annapurna Labs Alpine PoC. The HAL files have already been added to sys/contrib/alpine-hal so there is no need for them in the platform directory. This patch removes obsolete files. Reviewed by:andrew Obtained from: Semihalf Sponsored by: Annapurna Labs Differential Revision: https://reviews.freebsd.org/D3248 286070 by emaste: Add ELF Tool Chain's ar(1) and elfdump(1) to contrib ELF Tool Chain built on FreeBSD's ar and elfdump, but has a number of improvements and enhancements. Bring them into contrib in order to start integrating into our build. 286069 by ae: Build if_stf(4) module only when both INET and INET6 support are enabled. The end of the build log: [...truncated 297432 lines...] ./machine/smp.h:38:12: note: previous declaration of 'bootAP' was here extern int bootAP; ^ ctfconvert -L VERSION -g kern_shutdown.o --- kern_time.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include -L/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/lib --sysroot=/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp -B/usr/local/x86_64-freebsd/bin/ -c -O2 -frename-registers -pipe -fno-strict-aliasing -g -nostdinc -I. -I/builds/FreeBSD_HEAD_amd64_gcc4.9/sys -I/builds/FreeBSD_HEAD_amd64_gcc4.9/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 -fwrapv -fstack-protector -gdwarf-2 -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-unk nown-pragmas -Wno-error=inline -Wno-error=enum-compare -Wno-error=unused-but-set-variable -Wno-error=aggressive-loop-optimizations -Wno-error=maybe-uninitialized -Wno-error=array-bounds -Wno-error=address -Wno-error=cast-qual -Wno-error=sequence-point -Wno-error=attributes -Wno-error=strict-overflow -Wno-error=overflow -fno-common -fms-extensions -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -std=iso9899:1999 /builds/FreeBSD_HEAD_amd64_gcc4.9/sys/kern/kern_time.c --- kern_jail.o --- ctfconvert -L VERSION -g kern_jail.o --- posix4_mib.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include -L/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/lib --sysroot=/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp -B/usr/local/x86_64-freebsd/bin/ -c -O2 -frename-registers -pipe -fno-strict-aliasing -g -nostdinc -I. -I/builds/FreeBSD_HEAD_amd
Re: About virtio-scsi and\or scsi.
Yes it is; it just needs review, fixing and committing. :) -a On 30 July 2015 at 07:24, Kubilay Kocak wrote: > On 31/07/2015 12:06 AM, Bryan Venteicher wrote: >> On Wed, Jul 29, 2015 at 4:53 PM, Eliezer Croitoru >> wrote: >> >>> I am testing couple VMs under kvm and from my tests it seems that there >>> might not be support for hot-plug of virtio disks or virtio-scsi disks in >>> freebsd? >>> >>> >> >> Hot plug of VirtIO block devices is not supported, but that is more >> because of a lack PCI hot plug. Hot plugging of disks to an existing >> VirtIO SCSI adapter is supported. > > I wonder if John-Marks (cc'd) recent work on PCIe Hot-Plug [1] is at all > relevant to this: > > [1] > https://www.freebsd.org/news/status/report-2015-04-2015-06.html#Adding-PCIe-Hot-plug-Support > > ./koobs > ___ > 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" ___ 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: About virtio-scsi and\or scsi.
On 31/07/2015 12:06 AM, Bryan Venteicher wrote: > On Wed, Jul 29, 2015 at 4:53 PM, Eliezer Croitoru > wrote: > >> I am testing couple VMs under kvm and from my tests it seems that there >> might not be support for hot-plug of virtio disks or virtio-scsi disks in >> freebsd? >> >> > > Hot plug of VirtIO block devices is not supported, but that is more > because of a lack PCI hot plug. Hot plugging of disks to an existing > VirtIO SCSI adapter is supported. I wonder if John-Marks (cc'd) recent work on PCIe Hot-Plug [1] is at all relevant to this: [1] https://www.freebsd.org/news/status/report-2015-04-2015-06.html#Adding-PCIe-Hot-plug-Support ./koobs ___ 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: About virtio-scsi and\or scsi.
On Wed, Jul 29, 2015 at 4:53 PM, Eliezer Croitoru wrote: > I am testing couple VMs under kvm and from my tests it seems that there > might not be support for hot-plug of virtio disks or virtio-scsi disks in > freebsd? > > Hot plug of VirtIO block devices is not supported, but that is more because of a lack PCI hot plug. Hot plugging of disks to an existing VirtIO SCSI adapter is supported. > I wanted to make sure I am understand right the situation FreeBSD is right > now. > > If anyone knows please reply. > > Thanks, > Eliezer > ___ > 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" > ___ 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"
Buf ring cleanups
Hello, I'm writing to ensure what to do with that patch: https://reviews.freebsd.org/D1945 It was created as a result of discussion related to this review: https://reviews.freebsd.org/D1833 The patch (D1945) is still waiting to be committed. We really need fix for ARM in buf_ring so if someone is sure that the patch is OK then please commit. Thanks in advance and best regards zbb ___ 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: MS DNS doesn't answer to CURRENT under Hyper-V
Just committed the fix in releng/10.2 branch as r286058. Wei > -Original Message- > From: Pavel Timofeev [mailto:tim...@gmail.com] > Sent: Wednesday, July 29, 2015 3:48 PM > To: Wei Hu > Cc: Slawa Olhovchenkov ; freebsd-current@freebsd.org; > freebsd-virtualizat...@freebsd.org > Subject: Re: MS DNS doesn't answer to CURRENT under Hyper-V > > Hi! > r285785 still isn't MFCed. > RC2 is coming soon. > > 2015-07-23 10:54 GMT+03:00 Pavel Timofeev : > > Ok, sorry! > > > > 2015-07-23 7:51 GMT+03:00 Wei Hu : > >> The TCP offloading is still working on these platforms. There is no flag to > distinguish UDP and TCP offloading, so the RXCSUM and TXCSUM are still set. > Let me know if there is any other way to show it properly. > >> > >> Thanks, > >> Wei > >> > >> > >> -Original Message- > >> From: Pavel Timofeev [mailto:tim...@gmail.com] > >> Sent: Wednesday, July 22, 2015 9:04 PM > >> To: Wei Hu > >> Cc: Slawa Olhovchenkov ; freebsd- > curr...@freebsd.org; > >> freebsd-virtualizat...@freebsd.org > >> Subject: Re: MS DNS doesn't answer to CURRENT under Hyper-V > >> > >> Hi! I see you have done the code for disabling UDP checksum > >> offloading when running on the Hyper-V on Windows Server 2012 and > >> earlier hosts > >> > >> https://svnweb.freebsd.org/base?view=revision&revision=285785 > >> > >> I tried new CURRENT and it works. Thank you! > >> > >> A small note here: while it disables and works it still shows RXCSUM and > TSCSUM in iface's options: > >> > >> root@proxy:/usr/src # ifconfig hn0 > >> hn0: flags=8843 metric > 0 mtu 1500 > >> > options=31b > >> ether 00:15:5d:02:9c:09 > >> inet 192.168.25.26 netmask 0xffc0 broadcast 192.168.25.63 > >> nd6 options=29 > >> > >> Is it possible to hide it automatically if it's disabled by new code? > >> > >> > >> 2015-07-13 11:06 GMT+03:00 Wei Hu : > >>> We have root caused the problem. This issue happens on the Hyper-Vs > on Windows Server 2012 (Win 8.0) and earlier releases. On these releases, > the UPD checksum offloading on host side does not work properly. The > workaround is to disable UPD checksum offloading in the FreeBSD guest > through 'ifconfig'. We are also working on a patch to turn off UPD checksum > offloading in the netvsc driver when detecting the Hyper-V releases. > >>> > >>> The UDP checksum offloading works fine on Windows Server 2012R2 and > Win 8.1 hosts. > >>> > >>> Thanks Pavel and Slawa for the support. > >>> > >>> Wei > >>> > >>> > -Original Message- > From: owner-freebsd-virtualizat...@freebsd.org > [mailto:owner-freebsd- virtualizat...@freebsd.org] On Behalf Of > Pavel Timofeev > Sent: Wednesday, July 8, 2015 4:06 PM > To: Slawa Olhovchenkov > Cc: freebsd-current@freebsd.org; freebsd-virtualizat...@freebsd.org > Subject: Re: MS DNS doesn't answer to CURRENT under Hyper-V > > Ok, r284746 is the root of the problem. MS DNS works under r284745 > and doesn't work under r284746. > Slawa, what should I look at in wireshark output? > > > 2015-07-07 18:49 GMT+03:00 Slawa Olhovchenkov : > > On Tue, Jul 07, 2015 at 06:04:46PM +0300, Pavel Timofeev wrote: > > > >> Well, turning off checksum offloading by `ifconfig hn0 -txcsum > >> -rxcsum` definitely helps. > >> > >> As for tcpdump I'm not completely sure if I did it right, but I > >> see "bad udp cksum" phrase: > >> > >> # tcpdump -i hn0 -vvv -nn udp dst port 53 > >> tcpdump: listening on hn0, link-type EN10MB (Ethernet), capture > >> size > >> 262144 bytes > >> 18:01:19.139994 IP (tos 0x0, ttl 64, id 61218, offset 0, flags > >> [none], proto UDP (17), length 51) > >> 192.168.25.26.45683 > 192.168.25.3.53: [bad udp cksum 0xb39e > >> -> 0xf210!] 52886+ A? ya.ru. (23) > >> 18:01:24.140544 IP (tos 0x0, ttl 64, id 17293, offset 0, flags > >> [none], proto UDP (17), length 51) > >> 192.168.25.26.12575 > 192.168.25.3.53: [bad udp cksum 0xb39e > >> -> 0x7365!] 52886+ A? ya.ru. (23) > > > > tcpdump "bad udp cksum" is normal on FreeBSD host in case > > checksum offload (and may be need only for help finding issuse in > code). > > Need wireshark capturing from MS DNS host (or from mirroring port). > ___ > freebsd-virtualizat...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to "freebsd-virtualization- > unsubscr...@freebsd.org" ___ 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"
