Re: API explosion (Re: [RFC/RFT] calloutng)
In message <2012125025.ga46...@stack.nl>, Jilles Tjoelker writes: >> Either way, such a facility should be layered on top of the callout >> facility, which should always run in "elapsed time"[1] with no attention >> paid to what NTPD might do to the UTC estimate. > >POSIX specifies functions that assume such a facility exists, although >applications may not care much if we implement them incorrectly. It should still be implemented op top of callouts, not as part of: it is an entirely different thing to try to do right. >> I think it prudent to specify a flag to callouts, to tell what >> should happen on suspend/resume, something like: > >> SR_CANCEL /* Cancel the callout on S/R */ >> /* no flag* /* Toll this callout only when system is running */ >> SR_IGNORE /* Toll suspended time from callout */ > >> If you get this right, callouts from device drivers will just "DTRT", >> if you get it wrong, all device drivers will need boilerplate code >> to handle S/R > >Userland could get access to this via CLOCK_REALTIME vs CLOCK_MONOTONIC >vs CLOCK_UPTIME. I have _no_ idea what you are trying to say here... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: API explosion (Re: [RFC/RFT] calloutng)
On Wed, Dec 19, 2012 at 11:00:06AM +, Poul-Henning Kamp wrote:
>
> In message <50d192e8.3020...@freebsd.org>, Alexander Motin writes:
> >Linux uses 32.32 format in their eventtimers code.
> (And that is no accident, I know who they got the number from :-)
> >But if at some point we want to be able to
> >handle absolute wall time, [...]
> Then you have other problems, including but not limited to clock
> being stepped, leap-seconds, suspend/resume and frequency stability.
> If you want to support callouts of the type ("At 14:00 UTC tomorrow")
> (disregarding the time-zone issue), you need to catch all significant
> changes to our UTC estimate and recalibrate your callout based on
> that.
> It is not obvious that we have applications for such an API that
> warrant the complexity.
> Either way, such a facility should be layered on top of the callout
> facility, which should always run in "elapsed time"[1] with no attention
> paid to what NTPD might do to the UTC estimate.
POSIX specifies functions that assume such a facility exists, although
applications may not care much if we implement them incorrectly.
For example, pthread_mutex_timedlock() and sem_timedwait() shall time
out when the CLOCK_REALTIME clock reaches the given value, and
pthread_cond_timedwait() and clock_nanosleep() (with TIMER_ABSTIME)
shall time out when the specified clock reaches the given value.
> So summary: 32.32 is the right format.
> Poul-Henning
> [1] Notice that "elapsed time" needs a firm definition with respect
> to suspend/resume, and that this decision has big implications
> for the API use and code duplication.
> I think it prudent to specify a flag to callouts, to tell what
> should happen on suspend/resume, something like:
> SR_CANCEL /* Cancel the callout on S/R */
> /* no flag* /* Toll this callout only when system is running */
> SR_IGNORE /* Toll suspended time from callout */
> If you get this right, callouts from device drivers will just "DTRT",
> if you get it wrong, all device drivers will need boilerplate code
> to handle S/R
Userland could get access to this via CLOCK_REALTIME vs CLOCK_MONOTONIC
vs CLOCK_UPTIME.
--
Jilles Tjoelker
___
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: protoc crash in libstdc++
On 2012-12-18 22:12, George Liaskos wrote: Try removing --gc-sections from the link flags for protoc, that should solve it for now. I am still looking at the root cause, which seems to be something in our ld; it does not seem to be related to either clang or libstdc++. Whoa, thank you! Removing --gc-sections from the link flags solves the issue indeed! I have committed the real bugfix for ld --gc-sections in r244600. I will also MFC it in a week. ___ 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: ipv6_addrs_IF aliases in rc.conf(5)
On Sat, Dec 22, 2012 at 4:25 PM, Łukasz Wąsikowski wrote: > W dniu 2012-12-22 04:41, Kimmo Paasiala pisze: > It looks like the reason for the difference to ipv4_addrs_IF is that the "alias" parameter for ifconfig(8) operates differently for IPv6 addresses, the first address of an interface can't be added with "alias", for IPv4 it does not care. I'll have to dig deeper but that's what the problem seems to be. -Kimmo >>> >>> The 'alias' parameter of ifconfig(8) is not the problem on the first >>> ipv6 address, I have verified that. However, there's probably >>> something in network.subr or /etc/rc.d/netif that I have overlooked >>> and causes my code to be skipped if there's no ifconfig_IF_ipv6 >>> variable defined in rc.conf(5). >>> >>> -Kimmo >> >> Yeah, this is problem in network.subr. An interface is not recognized >> as IPv6 capable if the interface is not in "ipv6_network_interfaces" >> and there's no "ifconfig_IF_ipv6" in rc.conf(5), bummer. For IPv4 it >> "just works" because the interface is always assumed to be IPv4 >> capable. > > Ok, I used ifconfig_em0_ipv6="up" and it worked. So it looks like this: > > ipv6_activate_all_interfaces="NO" > ipv6_network_interfaces="em0" > ifconfig_em0_ipv6="up" > ipv6_addrs_em0="2001:6a0:1cb::1-ff/64" > ipv6_defaultrouter="2001:6a0:1cb::" > > Good job, thank you! :) > > -- > best regards, > Lukasz Wasikowski I'm looking into fixing the issue so you could just have the ipv6_addrs_em0 line in rc.conf. However I don't want to flood the PR and this mailing list with different versions of the patch. I want to get it right next time. Stay tuned. -Kimmo ___ 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: ipv6_addrs_IF aliases in rc.conf(5)
W dniu 2012-12-22 04:41, Kimmo Paasiala pisze: >>> It looks like the reason for the difference to ipv4_addrs_IF is that >>> the "alias" parameter for ifconfig(8) operates differently for IPv6 >>> addresses, the first address of an interface can't be added with >>> "alias", for IPv4 it does not care. I'll have to dig deeper but that's >>> what the problem seems to be. >>> >>> -Kimmo >> >> The 'alias' parameter of ifconfig(8) is not the problem on the first >> ipv6 address, I have verified that. However, there's probably >> something in network.subr or /etc/rc.d/netif that I have overlooked >> and causes my code to be skipped if there's no ifconfig_IF_ipv6 >> variable defined in rc.conf(5). >> >> -Kimmo > > Yeah, this is problem in network.subr. An interface is not recognized > as IPv6 capable if the interface is not in "ipv6_network_interfaces" > and there's no "ifconfig_IF_ipv6" in rc.conf(5), bummer. For IPv4 it > "just works" because the interface is always assumed to be IPv4 > capable. Ok, I used ifconfig_em0_ipv6="up" and it worked. So it looks like this: ipv6_activate_all_interfaces="NO" ipv6_network_interfaces="em0" ifconfig_em0_ipv6="up" ipv6_addrs_em0="2001:6a0:1cb::1-ff/64" ipv6_defaultrouter="2001:6a0:1cb::" Good job, thank you! :) -- best regards, Lukasz Wasikowski ___ 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: double fault [Was: clang compiled kernel panic when mounting zfs root on i386]
On 2012-12-22 12:11, Andriy Gapon wrote: on 21/12/2012 18:38 Hans Petter Selasky said the following: I've built a 10-current i386 kernel as of today, and I see double fault when USB audio is allocating memory. Anyone knows why? kdb_enter() vpanic() panic() dblfault_handler() vm_map_lookup() vm_fault_hold() vm_fault() vm_fault_wire() vm_map_wire() kmem_alloc_attr(xxx, 0x4000,2,0,0x) bus_dmamem_alloc() usb_pc_alloc_mem() I suspect that this double fault may have nothing to do with the thread to which you followed up. You need to obtain full debug information to answer your question. Specifically interesting are the stack frame addresses, which Kostik has added recently. From these, you can easily see whether the double fault is due to stack exhaustion (which seems unlikely with such a small call stack), or to something else. ___ 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: Fatal trap 1
On Sat, Dec 22, 2012 at 01:44:49PM +0200, Andriy Gapon wrote: > on 22/12/2012 13:21 Konstantin Belousov said the following: > > This is due to the vtoslab() returning NULL. Since slabref is dereferenced > > later, clang tries to be helpful as usual and converts the !(p->flags & > > PG_SLAB) case from vtoslab() into the jump to un2 instruction if vtoslab() > > result is NULL. > > > > So instead of KASSERT triggering the next line, you see this improvement. > > Interesting. Thank you for the explanation. > > But looking at the code I think that slabref->us_keg access _before_ KASSERT > is the culprit? I.e. even with GCC we could get a page fault before the > KASSERT is reached (modulo reordering)? May be, but I do not think it is matter. Because KASSERT() now can return, even if you reorder the assert and deref, I think that compiler authors still find an excuse. pgp8ueyRkyG3w.pgp Description: PGP signature
Re: Fatal trap 1
on 22/12/2012 13:21 Konstantin Belousov said the following: > This is due to the vtoslab() returning NULL. Since slabref is dereferenced > later, clang tries to be helpful as usual and converts the !(p->flags & > PG_SLAB) case from vtoslab() into the jump to un2 instruction if vtoslab() > result is NULL. > > So instead of KASSERT triggering the next line, you see this improvement. Interesting. Thank you for the explanation. But looking at the code I think that slabref->us_keg access _before_ KASSERT is the culprit? I.e. even with GCC we could get a page fault before the KASSERT is reached (modulo reordering)? -- Andriy Gapon ___ 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: Fatal trap 1 [Was: "Memory modified after free" - by whom?]
On Sat, Dec 22, 2012 at 01:08:10PM +0200, Andriy Gapon wrote: > on 22/12/2012 02:21 Garrett Cooper said the following: > > Fatal trap 1: privileged instruction fault while in kernel mode > > Fatal trap 1: privileged instruction fault while in kernel mode > > Unrelated to the original topic - this looks very weird. > I mean all the CPUs getting this unusual trap... > Could you please do 'disassemble 0x80af5099' in kgdb with the same > kernel. Or if you have a different kernel now, please use "instruction > pointer" > value from a trap with that kernel. > This is due to the vtoslab() returning NULL. Since slabref is dereferenced later, clang tries to be helpful as usual and converts the !(p->flags & PG_SLAB) case from vtoslab() into the jump to un2 instruction if vtoslab() result is NULL. So instead of KASSERT triggering the next line, you see this improvement. > > Memory modified after free 0xff800040d000(9216) val=5a5a5a5a @ > > 0xff800040d000 > > Fatal trap 1: privileged instruction fault while in kernel mode > > cpuid = 3; > > cpuid = 1; > > apic id = 02 > > cpuid = 0; apic id = 06 > > apic id = 00 > > instruction pointer = 0x20:0x80af5099 > > instruction pointer = 0x20:0x80af5099 > > instruction pointer = 0x20:0x80af5099 > > Fatal trap 1: privileged instruction fault while in kernel mode > > stack pointer = 0x28:0xff8496fff880 > > stack pointer = 0x28:0xff8496fe1880 > > cpuid = 2; frame pointer= 0x28:0xff8496fff8b0 > > frame pointer = 0x28:0xff8496fe18b0 > > stack pointer = 0x28:0xff849705d880 > > code segment= base 0x0, limit 0xf, type 0x1b > > frame pointer = 0x28:0xff849705d8b0 > > apic id = 04 > > code segment= base 0x0, limit 0xf, type 0x1b > > code segment= base 0x0, limit 0xf, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > instruction pointer = 0x20:0x80af5099 > > processor eflags= = DPL 0, pres 1, long > > 1, def32 0, gran 1 > > interrupt enabled, processor eflags = stack pointer = > > 0x28:0xff8497067880 > > interrupt enabled, resume, resume, frame pointer= > > 0x28:0xff84970678b0 > > IOPL = 0 > > code segment= base 0x0, limit 0xf, type 0x1b > > current process = = DPL 0, pres 1, long > > 1, def32 0, gran 1 > > processor eflags= 12 (irq280: ix0:que 3) > > ilock order reversal: (Giant after non-sleepable) > > 1st 0xfe0078148b38 ix0:rx(3) (ix0:rx(3)) @ > > /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c:4296 > > 2nd 0x814457b8 Giant (Giant) @ > > /usr/src/sys/dev/usb/input/ukbd.c:1946 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xff8496fff320 > > kdb_backtrace() at kdb_backtrace+0x39/frame 0xff8496fff3d0 > > witness_checkorder() at witness_checkorder+0xc47/frame 0xff8496fff450 > > __mtx_lock_flags() at __mtx_lock_flags+0x89/frame 0xff8496fff490 > > ukbd_poll() at ukbd_poll+0x28/frame 0xff8496fff4b0 > > kbdmux_poll() at kbdmux_poll+0x5b/frame 0xff8496fff4d0 > > cngrab() at cngrab+0x35/frame 0xff8496fff4f0 > > kdb_trap() at kdb_trap+0x124/frame 0xff8496fff550 > > trap_fatal() at trap_fatal+0x345/frame 0xff8496fff5b0 > > trap() at trap+0x836/frame 0xff8496fff7c0 > > calltrap() at calltrap+0x8/frame 0xff8496fff7c0 > > --- trap 0x1, rip = 0x80af5099, rsp = 0xff8496fff880, rbp > > = 0xff8496fff8b0 --- > > uma_find_refcnt() at uma_find_refcnt+0x79/frame 0xff8496fff8b0 > > > -- > Andriy Gapon > ___ > 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" pgps9pTddrmqz.pgp Description: PGP signature
double fault [Was: clang compiled kernel panic when mounting zfs root on i386]
on 21/12/2012 18:38 Hans Petter Selasky said the following: > I've built a 10-current i386 kernel as of today, and I see double fault when > USB audio is allocating memory. Anyone knows why? > > kdb_enter() > vpanic() > panic() > dblfault_handler() > vm_map_lookup() > vm_fault_hold() > vm_fault() > vm_fault_wire() > vm_map_wire() > kmem_alloc_attr(xxx, 0x4000,2,0,0x) > bus_dmamem_alloc() > usb_pc_alloc_mem() I suspect that this double fault may have nothing to do with the thread to which you followed up. You need to obtain full debug information to answer your question. -- Andriy Gapon ___ 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"
Fatal trap 1 [Was: "Memory modified after free" - by whom?]
on 22/12/2012 02:21 Garrett Cooper said the following: > Fatal trap 1: privileged instruction fault while in kernel mode > Fatal trap 1: privileged instruction fault while in kernel mode Unrelated to the original topic - this looks very weird. I mean all the CPUs getting this unusual trap... Could you please do 'disassemble 0x80af5099' in kgdb with the same kernel. Or if you have a different kernel now, please use "instruction pointer" value from a trap with that kernel. > Memory modified after free 0xff800040d000(9216) val=5a5a5a5a @ > 0xff800040d000 > Fatal trap 1: privileged instruction fault while in kernel mode > cpuid = 3; > cpuid = 1; > apic id = 02 > cpuid = 0; apic id = 06 > apic id = 00 > instruction pointer = 0x20:0x80af5099 > instruction pointer = 0x20:0x80af5099 > instruction pointer = 0x20:0x80af5099 > Fatal trap 1: privileged instruction fault while in kernel mode > stack pointer = 0x28:0xff8496fff880 > stack pointer = 0x28:0xff8496fe1880 > cpuid = 2; frame pointer= 0x28:0xff8496fff8b0 > frame pointer = 0x28:0xff8496fe18b0 > stack pointer = 0x28:0xff849705d880 > code segment= base 0x0, limit 0xf, type 0x1b > frame pointer = 0x28:0xff849705d8b0 > apic id = 04 > code segment= base 0x0, limit 0xf, type 0x1b > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > = DPL 0, pres 1, long 1, def32 0, gran 1 > instruction pointer = 0x20:0x80af5099 > processor eflags= = DPL 0, pres 1, long > 1, def32 0, gran 1 > interrupt enabled, processor eflags = stack pointer = > 0x28:0xff8497067880 > interrupt enabled, resume, resume, frame pointer= > 0x28:0xff84970678b0 > IOPL = 0 > code segment= base 0x0, limit 0xf, type 0x1b > current process = = DPL 0, pres 1, long > 1, def32 0, gran 1 > processor eflags= 12 (irq280: ix0:que 3) > ilock order reversal: (Giant after non-sleepable) > 1st 0xfe0078148b38 ix0:rx(3) (ix0:rx(3)) @ > /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c:4296 > 2nd 0x814457b8 Giant (Giant) @ /usr/src/sys/dev/usb/input/ukbd.c:1946 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xff8496fff320 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xff8496fff3d0 > witness_checkorder() at witness_checkorder+0xc47/frame 0xff8496fff450 > __mtx_lock_flags() at __mtx_lock_flags+0x89/frame 0xff8496fff490 > ukbd_poll() at ukbd_poll+0x28/frame 0xff8496fff4b0 > kbdmux_poll() at kbdmux_poll+0x5b/frame 0xff8496fff4d0 > cngrab() at cngrab+0x35/frame 0xff8496fff4f0 > kdb_trap() at kdb_trap+0x124/frame 0xff8496fff550 > trap_fatal() at trap_fatal+0x345/frame 0xff8496fff5b0 > trap() at trap+0x836/frame 0xff8496fff7c0 > calltrap() at calltrap+0x8/frame 0xff8496fff7c0 > --- trap 0x1, rip = 0x80af5099, rsp = 0xff8496fff880, rbp > = 0xff8496fff8b0 --- > uma_find_refcnt() at uma_find_refcnt+0x79/frame 0xff8496fff8b0 -- Andriy Gapon ___ 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"
