Re: new xorg segfault 11 with KMS

[Niclas Zeising]

On 12/14/12 01:24, Johannes Dieterich wrote:
> On Thu, Dec 13, 2012 at 6:51 PM, Artyom Mirgorodskiy
>  wrote:
>> This patch work for me. Thanks.
> I can confirm that it also works for me. Thanks a lot!
> 
>> On Friday 14 December 2012 00:30:52 Niclas Zeising wrote:
>>
>>> Can you please try the attached patch, against x11-servers/xorg-server.
>>
>>> Apply it and recompile xorg-server with normal flags (that is, no
>>
>>> debugging) and let me and the list know the result when starting X.
>>
>>> Regards!
Patch is applied to the ports tree now.  Thanks for help testing!
Regards!
-- 
Niclas Zeising
___
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: new xorg segfault 11 with KMS

[Niclas Zeising]

On 12/14/12 00:51, Artyom Mirgorodskiy wrote:
> This patch work for me. Thanks.
> 
> On Friday 14 December 2012 00:30:52 Niclas Zeising wrote:
>> Can you please try the attached patch, against x11-servers/xorg-server.
>>  Apply it and recompile xorg-server with normal flags (that is, no
>> debugging) and let me and the list know the result when starting X.
>> Regards!
>>

Patch is in the ports tree now.  Thanks for testing!
Regards!
-- 
Niclas Zeising
___
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: fifolog_writer

[Darrel]

I ran installworld and am stuck here:

===> /usr.sbin/fifolog/fifolog_writer (install)



Well, after a power cycle it boots and reports to be r244114.  I
have run 'svn up' and am going to try it again- seems like it will
try to build r244201.

Actually, right now I do not recall whether or not I cleared /usr/obj
before the build- could be due to brain damage of the system
administrator.

Darrel
___
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"

10-CURRENT r244183 amd64 multiple lock order reversals

[Fleuriot Damien]

Hello list,


I'm getting multipe LORs at boot on 10-CURRENT r244183 built yesterday on amd64.


Anyone else getting these ?
Anything I can do to help get them fixed ?


My make.conf contains:
===
CC=clang
CXX=clang++
CPP=clang-cpp

# This setting to build world without -Werror
NO_WERROR=
# This setting to build kernel without -Werror
WERROR=
# Don't forget this when using jails !
NO_FSCHG=

CFLAGS= -O2 -fno-strict-aliasing -pipe

NO_GAMES=true
NO_INFO=true
NO_KERBEROS=true
NO_LPR=true
NO_NIS=true
NO_BLUETOOTH=true

KERNCONF=DAM
MODULES_OVERRIDE= opensolaris zfs if_lagg pf pflog
===



First LOR, apparently in PF:

altq: emulate 25600Hz cpu clock
lock order reversal: (sleepable after non-sleepable)
 1st 0x81390418 pf rulesets (pf rulesets) @ 
/data/freebsd/src/head/sys/modules/pf/../../netpfil/pf/pf_ioctl.c:1153
 2nd 0x80e5e298 ifnet_sx (ifnet_sx) @ 
/data/freebsd/src/head/sys/modules/pf/../../netpfil/pf/pf_if.c:481
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xff80f6e4a9d0
kdb_backtrace() at kdb_backtrace+0x39/frame 0xff80f6e4aa80
witness_checkorder() at witness_checkorder+0xc47/frame 0xff80f6e4ab00
_sx_slock() at _sx_slock+0x69/frame 0xff80f6e4ab40
pfi_kif_update() at pfi_kif_update+0x10d/frame 0xff80f6e4abb0
pfi_dynaddr_setup() at pfi_dynaddr_setup+0x2d1/frame 0xff80f6e4ac20
pfioctl() at pfioctl+0x4a61/frame 0xff80f6e4b9a0
devfs_ioctl_f() at devfs_ioctl_f+0xf0/frame 0xff80f6e4ba00
kern_ioctl() at kern_ioctl+0x1ce/frame 0xff80f6e4ba50
sys_ioctl() at sys_ioctl+0x11f/frame 0xff80f6e4baa0
amd64_syscall() at amd64_syscall+0x265/frame 0xff80f6e4bbb0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xff80f6e4bbb0
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x800d923ea, rsp = 
0x7fffbde8, rbp = 0x7fffc9e0 ---

PF is used as a module, however I've compiled in ALTQ support:
options ALTQ
options ALTQ_CBQ
options ALTQ_RED
options ALTQ_RIO
options ALTQ_HFSC
options ALTQ_CDNR
options ALTQ_PRIQ
options ALTQ_NOPCC
options ALTQ_DEBUG



Second and third LORs, with vfs:

lock order reversal:
 1st 0xff80c0f92a48 bufwait (bufwait) @ 
/data/freebsd/src/head/sys/kern/vfs_bio.c:2631
 2nd 0xfe000619d600 dirhash (dirhash) @ 
/data/freebsd/src/head/sys/ufs/ufs/ufs_dirhash.c:284
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xff80f0c32690
kdb_backtrace() at kdb_backtrace+0x39/frame 0xff80f0c32740
witness_checkorder() at witness_checkorder+0xc47/frame 0xff80f0c327c0
_sx_xlock() at _sx_xlock+0x66/frame 0xff80f0c32800
ufsdirhash_remove() at ufsdirhash_remove+0x37/frame 0xff80f0c32830
ufs_dirremove() at ufs_dirremove+0x116/frame 0xff80f0c32880
ufs_remove() at ufs_remove+0x75/frame 0xff80f0c328e0
VOP_REMOVE_APV() at VOP_REMOVE_APV+0xc8/frame 0xff80f0c32900
kern_unlinkat() at kern_unlinkat+0x20b/frame 0xff80f0c32aa0
amd64_syscall() at amd64_syscall+0x265/frame 0xff80f0c32bb0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xff80f0c32bb0
--- syscall (10, FreeBSD ELF64, sys_unlink), rip = 0x80091a61a, rsp = 
0x7fffca78, rbp = 0x7fffdc30 ---

lock order reversal:
 1st 0xfe0006208668 ufs (ufs) @ 
/data/freebsd/src/head/sys/kern/vfs_mount.c:851
 2nd 0xfe00371d1098 devfs (devfs) @ 
/data/freebsd/src/head/sys/kern/vfs_subr.c:2161
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xff80f6e283f0
kdb_backtrace() at kdb_backtrace+0x39/frame 0xff80f6e284a0
witness_checkorder() at witness_checkorder+0xc47/frame 0xff80f6e28520
__lockmgr_args() at __lockmgr_args+0x6e2/frame 0xff80f6e28650
vop_stdlock() at vop_stdlock+0x3c/frame 0xff80f6e28670
VOP_LOCK1_APV() at VOP_LOCK1_APV+0xd0/frame 0xff80f6e28690
_vn_lock() at _vn_lock+0xab/frame 0xff80f6e28700
vget() at vget+0x70/frame 0xff80f6e28750
devfs_allocv() at devfs_allocv+0xfd/frame 0xff80f6e287a0
devfs_root() at devfs_root+0x43/frame 0xff80f6e287d0
vfs_donmount() at vfs_donmount+0xf92/frame 0xff80f6e28a60
sys_nmount() at sys_nmount+0x72/frame 0xff80f6e28aa0
amd64_syscall() at amd64_syscall+0x265/frame 0xff80f6e28bb0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xff80f6e28bb0
--- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x800a950fa, rsp = 
0x7fffccc8, rbp = 0x7fffd230 ---

___
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: Reproduceable hang

[Alexander Yerenkow]

Setup: ESXi 5.1.0
Seems this happens when vmmemctl.ko loaded (from their latest vmtools), and
when you give a bit more memory than there is free.


2012/12/13 Andriy Gapon 

> on 13/12/2012 12:46 Alexander Yerenkow said the following:
> > 2012/12/13 Alexander Yerenkow 
> >
> >> Hello there.
> >> I have here 100% reproduceable hangs when run one custom java program.
> >> Can someone look into?
> >>
> >> I can give some more info (some other trace) if required.
> >>
> >>
> >
> >
> > If someone didn't get attachment - here's link to screenshot
> >
> > https://www.box.com/s/fir8ntjc4rjq5xv0vbyl
>
> Looks like either a bug or an "out-of-sync" issue in whatever
> (virtualization?)
> driver that has function OS_ReservedPageAlloc.
>
> --
> Andriy Gapon
>



-- 
Regards,
Alexander Yerenkow
___
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"

Lenovo x220 suspend/resume broken

[Ganael LAPLANCHE]

Hi everyone,

Following this thread :

http://lists.freebsd.org/pipermail/freebsd-current/2012-March/032519.html

I have finally taken time to track this regression. It occurs with
revision 231797 :

http://svnweb.freebsd.org/base?view=revision&revision=231797

Could anyone have a look at it ?

Best regards,

--
Ganael LAPLANCHE 
http://www.martymac.org | http://contribs.martymac.org
FreeBSD: martymac , http://www.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: [RFC/RFT] calloutng

[Davide Italiano]

On Fri, Dec 14, 2012 at 7:41 AM, Luigi Rizzo  wrote:
>
> On Fri, Dec 14, 2012 at 12:12 AM, Davide Italiano 
> wrote:
>>
>> Hi.
>> This patch takes callout(9) and redesign the KPI and the
>> implementation. The main objective of this work is making the
>> subsystem tickless.  In the last several years, this possibility has
>> been discussed widely (http://markmail.org/message/q3xmr2ttlzpqkmae),
>> but until now noone really implemented that.
>> If you want a complete history of what has been done in the last
>> months you can check the calloutng project repository
>> http://svnweb.freebsd.org/base/projects/calloutng/
>> For lazy people, here's a summary:
>
>
> thanks for the work and the detailed summary.
> Perhaps it would be useful if you could provide a few high level
> details on the use and performance of the new scheme, such as:
>
> - is the old callout KPI still available ? (i am asking because it would
>   help maintaining third party kernel modules that are expected to
>   work on different FreeBSD releases)
>

Obviously the old KPI is still available. callout(9) is a very popular
interface and I don't think removing the old interface is a good idea,
because could make unhappy some vendor when its code doesn't build
anymore on FreeBSD.

> - do you have numbers on what is the fastest rate at which callouts
>   can be fired (e.g. say you have a callout which increments a
>   counter and schedules the next callout in (struct bintime){0,1} ) ?
>
>
> - is there a possibility that if callout requests are too close to each
>   other  (e.g. the above test) the thread dispatching callouts will
>   run forever ? if so, is there a way to make such thread yield
>   after a while ?
>
> - since you mentioned nanosleep() poll() and select() have been
>   ported to the new callout, is there a way to guarantee that user
>   using these functions with a very short timeout are actually
>   descheduled as opposed to "interval too short, don't bother" ?
>
> - do you have numbers on how many calls per second we can
>   have for a process that does
>   for (;;) {  nanosleep(min_value_that_causes_descheduling);
>
> I also have some comments on the diff:
> - can you provide a diff -p ?
>
> - for several functions the only change is the name of an argument
>   from "busy" to "us". Can you elaborate the reason for the change,
>   and whether "us" means microseconds or the pronoun ?)
>

Please see r242905 by mav@.

> Finally, a more substantial comment:
> - a lot of functions which formerly had only a "timo" argument
>   now have "timo, bt, precision, flags". Take seltdwait() as an example.
>

seltdwait() is not part of the public KPI. It has been modified to
avoid code duplication. Having seltdwait() and seltdwait_bt(), i.e.
two separate functions, even though we could share most of the code is
not a clever approach, IMHO.
As I told before, seltdwait() is not exposed so we can modify its
argument without breaking anything.

>   It seems that you have been undecided between two approaches:
>   for some of these functions you have preserved the original function
>   that deals with ticks and introduced a new one that deals with the
> bintime,
>   whereas in other cases you have modified the original function to add
>   "bt, precision, flags".
>

I'm not. All the functions which are part of the public KPI (e.g.
condvar(9), sleepq(9), *) are still available.  *_flags variants have
been introduced so that consumers can take advantage of the new
'precision tolerance mechanism' implemented. Also, *_bt variants have
been introduced. I don't see any "undecision" between the two
approaches.
Please note that now the callout backend deals with bintime, so every
time callout_reset_on() is called, the 'tick' argument passed is
silently converted to bintime.

>   I would suggest a more uniform approach, namely:
>   - preserve all the existing functions (T) that take a timeout in ticks;
>   - add a new set of corresponding functions (BT) that take
> bt, precision, flags _instead_ of the ticks
>   - the functions (T) make immediately the conversion from ticks to
> bintime(s), using macros or inline
>   - optionally, convert kernel components to the new (BT) functions
> where this makes sense (e.g. we can exploit the finer-granularity
> of the new calls, etc.)
>



> cheers
> luigi
>
>  1) callout(9) is not anymore constrained to the resolution a periodic
>>
>> "hz" clock can give. In order to do that, the eventtimers(4) subsystem
>> is used as backend.
>> 2) Conversely from what discussed in past, we maintained the callwheel
>> as underlying data structure for keeping track of the outstading
>> timeouts. This choice has a couple of advantages, in particular we can
>> still take benefits from the O(1) average complexity of the wheel for
>> all the operations. Also, we thought the code duplication that would
>> arise from the use of a two-staged backend for callout (e.g. use wheel
>> for coarse resolution event and another 

Re: 10-CURRENT r244183 amd64 multiple lock order reversals

[Gleb Smirnoff]

On Fri, Dec 14, 2012 at 11:56:19AM +0100, Fleuriot Damien wrote:
F> First LOR, apparently in PF:
F> 
F> altq: emulate 25600Hz cpu clock
F> lock order reversal: (sleepable after non-sleepable)
F>  1st 0x81390418 pf rulesets (pf rulesets) @ 
/data/freebsd/src/head/sys/modules/pf/../../netpfil/pf/pf_ioctl.c:1153
F>  2nd 0x80e5e298 ifnet_sx (ifnet_sx) @ 
/data/freebsd/src/head/sys/modules/pf/../../netpfil/pf/pf_if.c:481
F> KDB: stack backtrace:
F> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xff80f6e4a9d0
F> kdb_backtrace() at kdb_backtrace+0x39/frame 0xff80f6e4aa80
F> witness_checkorder() at witness_checkorder+0xc47/frame 0xff80f6e4ab00
F> _sx_slock() at _sx_slock+0x69/frame 0xff80f6e4ab40
F> pfi_kif_update() at pfi_kif_update+0x10d/frame 0xff80f6e4abb0
F> pfi_dynaddr_setup() at pfi_dynaddr_setup+0x2d1/frame 0xff80f6e4ac20
F> pfioctl() at pfioctl+0x4a61/frame 0xff80f6e4b9a0
F> devfs_ioctl_f() at devfs_ioctl_f+0xf0/frame 0xff80f6e4ba00
F> kern_ioctl() at kern_ioctl+0x1ce/frame 0xff80f6e4ba50
F> sys_ioctl() at sys_ioctl+0x11f/frame 0xff80f6e4baa0
F> amd64_syscall() at amd64_syscall+0x265/frame 0xff80f6e4bbb0
F> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xff80f6e4bbb0
F> --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x800d923ea, rsp = 
0x7fffbde8, rbp = 0x7fffc9e0 ---

Strange that it wasn't noticed or reported before.

Fixed. Thanks for submission.

-- 
Totus tuus, Glebius.
___
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: [RFC/RFT] calloutng

[Davide Italiano]

On Fri, Dec 14, 2012 at 1:57 PM, Davide Italiano  wrote:
> On Fri, Dec 14, 2012 at 7:41 AM, Luigi Rizzo  wrote:
>>
>> On Fri, Dec 14, 2012 at 12:12 AM, Davide Italiano 
>> wrote:
>>>
>>> Hi.
>>> This patch takes callout(9) and redesign the KPI and the
>>> implementation. The main objective of this work is making the
>>> subsystem tickless.  In the last several years, this possibility has
>>> been discussed widely (http://markmail.org/message/q3xmr2ttlzpqkmae),
>>> but until now noone really implemented that.
>>> If you want a complete history of what has been done in the last
>>> months you can check the calloutng project repository
>>> http://svnweb.freebsd.org/base/projects/calloutng/
>>> For lazy people, here's a summary:
>>
>>
>> thanks for the work and the detailed summary.
>> Perhaps it would be useful if you could provide a few high level
>> details on the use and performance of the new scheme, such as:
>>
>> - is the old callout KPI still available ? (i am asking because it would
>>   help maintaining third party kernel modules that are expected to
>>   work on different FreeBSD releases)
>>
>
> Obviously the old KPI is still available. callout(9) is a very popular
> interface and I don't think removing the old interface is a good idea,
> because could make unhappy some vendor when its code doesn't build
> anymore on FreeBSD.
>
>> - do you have numbers on what is the fastest rate at which callouts
>>   can be fired (e.g. say you have a callout which increments a
>>   counter and schedules the next callout in (struct bintime){0,1} ) ?
>>

Right now, all the services rely on the old interface. This means they
cannot be fired before 1 tick has elapsed, e.g. considering hz = 1000
on most of the machines, 1 millisecond.
Now that nanosleep() relies on the new interface, we measured 4-5
microseconds latency for the processing before the callout is actually
fired. I can't say if we can still lower this value, but I cannot
imagine, for now, a consumer that actually request a shorter timeout.

>>
>> - is there a possibility that if callout requests are too close to each
>>   other  (e.g. the above test) the thread dispatching callouts will
>>   run forever ? if so, is there a way to make such thread yield
>>   after a while ?
>>

Most of the processing is still done in a SWI thread, "at a later
time", so I don't think this is a problem.

>> - since you mentioned nanosleep() poll() and select() have been
>>   ported to the new callout, is there a way to guarantee that user
>>   using these functions with a very short timeout are actually
>>   descheduled as opposed to "interval too short, don't bother" ?
>>
>> - do you have numbers on how many calls per second we can
>>   have for a process that does
>>   for (;;) {  nanosleep(min_value_that_causes_descheduling);
>>

I don't follow you here.

>> I also have some comments on the diff:
>> - can you provide a diff -p ?
>>
>> - for several functions the only change is the name of an argument
>>   from "busy" to "us". Can you elaborate the reason for the change,
>>   and whether "us" means microseconds or the pronoun ?)
>>
>
> Please see r242905 by mav@.
>
>> Finally, a more substantial comment:
>> - a lot of functions which formerly had only a "timo" argument
>>   now have "timo, bt, precision, flags". Take seltdwait() as an example.
>>
>
> seltdwait() is not part of the public KPI. It has been modified to
> avoid code duplication. Having seltdwait() and seltdwait_bt(), i.e.
> two separate functions, even though we could share most of the code is
> not a clever approach, IMHO.
> As I told before, seltdwait() is not exposed so we can modify its
> argument without breaking anything.
>
>>   It seems that you have been undecided between two approaches:
>>   for some of these functions you have preserved the original function
>>   that deals with ticks and introduced a new one that deals with the
>> bintime,
>>   whereas in other cases you have modified the original function to add
>>   "bt, precision, flags".
>>
>
> I'm not. All the functions which are part of the public KPI (e.g.
> condvar(9), sleepq(9), *) are still available.  *_flags variants have
> been introduced so that consumers can take advantage of the new
> 'precision tolerance mechanism' implemented. Also, *_bt variants have
> been introduced. I don't see any "undecision" between the two
> approaches.
> Please note that now the callout backend deals with bintime, so every
> time callout_reset_on() is called, the 'tick' argument passed is
> silently converted to bintime.
>
>>   I would suggest a more uniform approach, namely:
>>   - preserve all the existing functions (T) that take a timeout in ticks;
>>   - add a new set of corresponding functions (BT) that take
>> bt, precision, flags _instead_ of the ticks
>>   - the functions (T) make immediately the conversion from ticks to
>> bintime(s), using macros or inline
>>   - optionally, convert kernel components to the new (BT) functions
>> w

Re: ath0: unable to attach hardware

[Adrian Chadd]

Hi,

Ok. I'm travelling for a little bit; if I don't reply in a few days,
please poke me again.

It may be that the device is asleep for a bit longer (failing this
test) and has completed resetting at this point.

It may be that the power on sequence is not quite right for some reason.

Would you mind recompiling your kernel and making if_ath a kld, rather
than statically in the kernel?

Thanks,


Adrian

>
> attached to this e-mail you find the output of dmesg. What I guess the most 
> relevant lines could be is:
>
> ath0:  mem 0xfdee-0xfdee irq 16 at device 4.0 on pci2
> ar5212ChipTest: address test failed addr: 0x8000 - wr:0x != 
> rd:0x
> ar5212Attach: hardware self-test failed
> ath0: unable to attach hardware; HAL status 14
> device_attach: ath0 attach returned 6
>
> I read the registers 4004 and 4010 again to make sure the values still are 
> the same, which indeed they are.
>
> I hope this helps.
>
> Thanks!
>
> On Donnerstag, 13. Dezember 2012 at 10:18 PM, "Adrian Chadd" 
>  wrote:
>>
>>On 13 December 2012 13:11,   wrote:
>>> Hello everyone,
>>>
>>> I'm afraid I still don't know what exactly BAR is, or how I get
>>its value that I'm supposed to plug into the line John provided:
>>> dd if=/dev/mem bs=4 iseek=((start of bar + reg offset)/4)
>>count=1 | hd
>>>
>>> I assumed that "start of bar" is 0xfdee in my case, since
>>dmesg reports
>>> ath0:  mem 0xfdee-0xfdee irq 16 at device
>>4.0 on pci2
>>
>>Yup.
>>
>>> This is what I get:
>>> # dd if=/dev/mem bs=4 iseek=`echo "ibase=16; (FDEE+4004)/4"
>>| bc` count=1 | hd
>>> 00 00 01 00
>>> # dd if=/dev/mem bs=4 iseek=`echo "ibase=16; (FDEE+4010)/4"
>>| bc` count=1 | hd
>>> 14 00 01 00
>>>
>>> Please correct me if my assumption about "start of bar" was
>>wrong and/or I made some other mistake.
>>> Also, please don't hesitate to ask me to do anything else that
>>might help you during debugging.
>>>
>>> Thank you very much for the effort.
>>
>>Hm. Wait, what's the rest of the ath0: output?
>>
>>
>>
>>Adrian
___
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"

Request import of fix for clang 3.2 bug

[Guido Falsi]

I have stumbled upon a solved bug in clang 3.2 while testing some ports:

http://llvm.org/bugs/show_bug.cgi?id=14491

Fixed in this commit:

http://llvm.org/viewvc/llvm-project?view=rev&revision=169451

Should the fix be imported in FreeBSD??

Thanks.

--
Guido Falsi 
___
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: [RFC/RFT] calloutng

[Oliver Pinter]

Hi!

 635 -   return tticks;
 636 +   getbinuptime(&pbt);
 637 +   bt.sec = data / 1000;
 638 +   bt.frac = (data % 1000) * (uint64_t)1844674407309000LL;
 639 +   bintime_add(&bt, &pbt);
 640 +   return bt;
 641  }

What is this 1844674407309000LL constant?


 783 @@ -275,7 +288,7 @@
 784 do {
 785 th = timehands;
 786 gen = th->th_generation;
 787 -   bintime2timeval(&th->th_offset, tvp);
 788 +   Bintime2timeval(&th->th_offset, tvp);
 789 } while (gen == 0 || gen != th->th_generation);
 790  }
 791

Capital B is there possible a typo?

On 12/14/12, Davide Italiano  wrote:
> On Fri, Dec 14, 2012 at 1:57 PM, Davide Italiano 
> wrote:
>> On Fri, Dec 14, 2012 at 7:41 AM, Luigi Rizzo  wrote:
>>>
>>> On Fri, Dec 14, 2012 at 12:12 AM, Davide Italiano 
>>> wrote:

 Hi.
 This patch takes callout(9) and redesign the KPI and the
 implementation. The main objective of this work is making the
 subsystem tickless.  In the last several years, this possibility has
 been discussed widely (http://markmail.org/message/q3xmr2ttlzpqkmae),
 but until now noone really implemented that.
 If you want a complete history of what has been done in the last
 months you can check the calloutng project repository
 http://svnweb.freebsd.org/base/projects/calloutng/
 For lazy people, here's a summary:
>>>
>>>
>>> thanks for the work and the detailed summary.
>>> Perhaps it would be useful if you could provide a few high level
>>> details on the use and performance of the new scheme, such as:
>>>
>>> - is the old callout KPI still available ? (i am asking because it would
>>>   help maintaining third party kernel modules that are expected to
>>>   work on different FreeBSD releases)
>>>
>>
>> Obviously the old KPI is still available. callout(9) is a very popular
>> interface and I don't think removing the old interface is a good idea,
>> because could make unhappy some vendor when its code doesn't build
>> anymore on FreeBSD.
>>
>>> - do you have numbers on what is the fastest rate at which callouts
>>>   can be fired (e.g. say you have a callout which increments a
>>>   counter and schedules the next callout in (struct bintime){0,1} ) ?
>>>
>
> Right now, all the services rely on the old interface. This means they
> cannot be fired before 1 tick has elapsed, e.g. considering hz = 1000
> on most of the machines, 1 millisecond.
> Now that nanosleep() relies on the new interface, we measured 4-5
> microseconds latency for the processing before the callout is actually
> fired. I can't say if we can still lower this value, but I cannot
> imagine, for now, a consumer that actually request a shorter timeout.
>
>>>
>>> - is there a possibility that if callout requests are too close to each
>>>   other  (e.g. the above test) the thread dispatching callouts will
>>>   run forever ? if so, is there a way to make such thread yield
>>>   after a while ?
>>>
>
> Most of the processing is still done in a SWI thread, "at a later
> time", so I don't think this is a problem.
>
>>> - since you mentioned nanosleep() poll() and select() have been
>>>   ported to the new callout, is there a way to guarantee that user
>>>   using these functions with a very short timeout are actually
>>>   descheduled as opposed to "interval too short, don't bother" ?
>>>
>>> - do you have numbers on how many calls per second we can
>>>   have for a process that does
>>>   for (;;) {  nanosleep(min_value_that_causes_descheduling);
>>>
>
> I don't follow you here.
>
>>> I also have some comments on the diff:
>>> - can you provide a diff -p ?
>>>
>>> - for several functions the only change is the name of an argument
>>>   from "busy" to "us". Can you elaborate the reason for the change,
>>>   and whether "us" means microseconds or the pronoun ?)
>>>
>>
>> Please see r242905 by mav@.
>>
>>> Finally, a more substantial comment:
>>> - a lot of functions which formerly had only a "timo" argument
>>>   now have "timo, bt, precision, flags". Take seltdwait() as an example.
>>>
>>
>> seltdwait() is not part of the public KPI. It has been modified to
>> avoid code duplication. Having seltdwait() and seltdwait_bt(), i.e.
>> two separate functions, even though we could share most of the code is
>> not a clever approach, IMHO.
>> As I told before, seltdwait() is not exposed so we can modify its
>> argument without breaking anything.
>>
>>>   It seems that you have been undecided between two approaches:
>>>   for some of these functions you have preserved the original function
>>>   that deals with ticks and introduced a new one that deals with the
>>> bintime,
>>>   whereas in other cases you have modified the original function to add
>>>   "bt, precision, flags".
>>>
>>
>> I'm not. All the functions which are part of the public KPI (e.g.
>> condvar(9), sleepq(9), *) are still available.  *_flags variants have
>> been introduced so that consumers c

Re: Request import of fix for clang 3.2 bug

[David Chisnall]

Looks like it's been imported to the 3.2 branch, so we should get it when dim 
pulls in the latest version.

David

On 14 Dec 2012, at 14:14, Guido Falsi wrote:

> I have stumbled upon a solved bug in clang 3.2 while testing some ports:
> 
> http://llvm.org/bugs/show_bug.cgi?id=14491
> 
> Fixed in this commit:
> 
> http://llvm.org/viewvc/llvm-project?view=rev&revision=169451
> 
> Should the fix be imported in FreeBSD??
> 
> Thanks.
> 
> -- 
> Guido Falsi 
> ___
> 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: Reproduceable hang

[Andriy Gapon]

on 14/12/2012 14:46 Alexander Yerenkow said the following:
> Setup: ESXi 5.1.0
> Seems this happens when vmmemctl.ko loaded (from their latest vmtools), and 
> when
> you give a bit more memory than there is free.

This is weird... As I can see in os_kmem_alloc function (in
modules/freebsd/vmmemctl/os.c of /usr/ports/emulators/open-vm-tools port), the
object lock is correctly acquired there.  I suspect some binary incompatibility
between the module and your kernel.  Try to recompile the module again using the
same source tree tree and the option.

> 2012/12/13 Andriy Gapon mailto:a...@freebsd.org>>
> 
> on 13/12/2012 12:46 Alexander Yerenkow said the following:
> > 2012/12/13 Alexander Yerenkow  >
> >
> >> Hello there.
> >> I have here 100% reproduceable hangs when run one custom java program.
> >> Can someone look into?
> >>
> >> I can give some more info (some other trace) if required.
> >>
> >>
> >
> >
> > If someone didn't get attachment - here's link to screenshot
> >
> > https://www.box.com/s/fir8ntjc4rjq5xv0vbyl
> 
> Looks like either a bug or an "out-of-sync" issue in whatever 
> (virtualization?)
> driver that has function OS_ReservedPageAlloc.

-- 
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: [RFC/RFT] calloutng

[Davide Italiano]

On Fri, Dec 14, 2012 at 3:21 PM, Oliver Pinter  wrote:
> Hi!
>
>  635 -   return tticks;
>  636 +   getbinuptime(&pbt);
>  637 +   bt.sec = data / 1000;
>  638 +   bt.frac = (data % 1000) * (uint64_t)1844674407309000LL;
>  639 +   bintime_add(&bt, &pbt);
>  640 +   return bt;
>  641  }
>
> What is this 1844674407309000LL constant?
>
>
>  783 @@ -275,7 +288,7 @@
>  784 do {
>  785 th = timehands;
>  786 gen = th->th_generation;
>  787 -   bintime2timeval(&th->th_offset, tvp);
>  788 +   Bintime2timeval(&th->th_offset, tvp);
>  789 } while (gen == 0 || gen != th->th_generation);
>  790  }
>  791
>
> Capital B is there possible a typo?
>

Hi Oliver,
thanks for reporting. Yes, both are typos.
The costant is  /* 18446744073709 = int(2^64 / 100) */ used to
convert from timeval to bintime.


> On 12/14/12, Davide Italiano  wrote:
>> On Fri, Dec 14, 2012 at 1:57 PM, Davide Italiano 
>> wrote:
>>> On Fri, Dec 14, 2012 at 7:41 AM, Luigi Rizzo  wrote:

 On Fri, Dec 14, 2012 at 12:12 AM, Davide Italiano 
 wrote:
>
> Hi.
> This patch takes callout(9) and redesign the KPI and the
> implementation. The main objective of this work is making the
> subsystem tickless.  In the last several years, this possibility has
> been discussed widely (http://markmail.org/message/q3xmr2ttlzpqkmae),
> but until now noone really implemented that.
> If you want a complete history of what has been done in the last
> months you can check the calloutng project repository
> http://svnweb.freebsd.org/base/projects/calloutng/
> For lazy people, here's a summary:


 thanks for the work and the detailed summary.
 Perhaps it would be useful if you could provide a few high level
 details on the use and performance of the new scheme, such as:

 - is the old callout KPI still available ? (i am asking because it would
   help maintaining third party kernel modules that are expected to
   work on different FreeBSD releases)

>>>
>>> Obviously the old KPI is still available. callout(9) is a very popular
>>> interface and I don't think removing the old interface is a good idea,
>>> because could make unhappy some vendor when its code doesn't build
>>> anymore on FreeBSD.
>>>
 - do you have numbers on what is the fastest rate at which callouts
   can be fired (e.g. say you have a callout which increments a
   counter and schedules the next callout in (struct bintime){0,1} ) ?

>>
>> Right now, all the services rely on the old interface. This means they
>> cannot be fired before 1 tick has elapsed, e.g. considering hz = 1000
>> on most of the machines, 1 millisecond.
>> Now that nanosleep() relies on the new interface, we measured 4-5
>> microseconds latency for the processing before the callout is actually
>> fired. I can't say if we can still lower this value, but I cannot
>> imagine, for now, a consumer that actually request a shorter timeout.
>>

 - is there a possibility that if callout requests are too close to each
   other  (e.g. the above test) the thread dispatching callouts will
   run forever ? if so, is there a way to make such thread yield
   after a while ?

>>
>> Most of the processing is still done in a SWI thread, "at a later
>> time", so I don't think this is a problem.
>>
 - since you mentioned nanosleep() poll() and select() have been
   ported to the new callout, is there a way to guarantee that user
   using these functions with a very short timeout are actually
   descheduled as opposed to "interval too short, don't bother" ?

 - do you have numbers on how many calls per second we can
   have for a process that does
   for (;;) {  nanosleep(min_value_that_causes_descheduling);

>>
>> I don't follow you here.
>>
 I also have some comments on the diff:
 - can you provide a diff -p ?

 - for several functions the only change is the name of an argument
   from "busy" to "us". Can you elaborate the reason for the change,
   and whether "us" means microseconds or the pronoun ?)

>>>
>>> Please see r242905 by mav@.
>>>
 Finally, a more substantial comment:
 - a lot of functions which formerly had only a "timo" argument
   now have "timo, bt, precision, flags". Take seltdwait() as an example.

>>>
>>> seltdwait() is not part of the public KPI. It has been modified to
>>> avoid code duplication. Having seltdwait() and seltdwait_bt(), i.e.
>>> two separate functions, even though we could share most of the code is
>>> not a clever approach, IMHO.
>>> As I told before, seltdwait() is not exposed so we can modify its
>>> argument without breaking anything.
>>>
   It seems that you have been undecided between two approaches:
   for some of these functions you have preserved the original function
   that deals with ticks 

Re: Reproduceable hang

[Alexander Yerenkow]

I'm using official tools, not open ones. Will try to repeat this at
saturday with openvm tools.
I could place somewhere their archive. Btw, they require compat6x.

Regards, Alexander Yerenkow
14.12.2012 16:39 пользователь "Andriy Gapon"  написал:

> on 14/12/2012 14:46 Alexander Yerenkow said the following:
> > Setup: ESXi 5.1.0
> > Seems this happens when vmmemctl.ko loaded (from their latest vmtools),
> and when
> > you give a bit more memory than there is free.
>
> This is weird... As I can see in os_kmem_alloc function (in
> modules/freebsd/vmmemctl/os.c of /usr/ports/emulators/open-vm-tools port),
> the
> object lock is correctly acquired there.  I suspect some binary
> incompatibility
> between the module and your kernel.  Try to recompile the module again
> using the
> same source tree tree and the option.
>
> > 2012/12/13 Andriy Gapon mailto:a...@freebsd.org>>
> >
> > on 13/12/2012 12:46 Alexander Yerenkow said the following:
> > > 2012/12/13 Alexander Yerenkow  yeren...@gmail.com>>
> > >
> > >> Hello there.
> > >> I have here 100% reproduceable hangs when run one custom java
> program.
> > >> Can someone look into?
> > >>
> > >> I can give some more info (some other trace) if required.
> > >>
> > >>
> > >
> > >
> > > If someone didn't get attachment - here's link to screenshot
> > >
> > > https://www.box.com/s/fir8ntjc4rjq5xv0vbyl
> >
> > Looks like either a bug or an "out-of-sync" issue in whatever
> (virtualization?)
> > driver that has function OS_ReservedPageAlloc.
>
> --
> 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: Reproduceable hang

[Andriy Gapon]

on 14/12/2012 17:00 Alexander Yerenkow said the following:
> I'm using official tools, not open ones. Will try to repeat this at saturday 
> with
> openvm tools.
> I could place somewhere their archive. Btw, they require compat6x.

Using third-party binary modules with head does not always work.
compat6x does not affect internal kernel interfaces.

So I suggest that you stick to some stable branch and use modules compiled for
that branch if you want to keep using the binary modules.

-- 
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: Request import of fix for clang 3.2 bug

[Dimitry Andric]

On 2012-12-14 15:14, Guido Falsi wrote:

I have stumbled upon a solved bug in clang 3.2 while testing some ports:

http://llvm.org/bugs/show_bug.cgi?id=14491

Fixed in this commit:

http://llvm.org/viewvc/llvm-project?view=rev&revision=169451

Should the fix be imported in FreeBSD??


Yes, it will come with the import of 3.2, when it is released.  This
should be Really Soon Now. :-)
___
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: Request import of fix for clang 3.2 bug

[Guido Falsi]

On 12/14/12 16:08, Dimitry Andric wrote:

On 2012-12-14 15:14, Guido Falsi wrote:

I have stumbled upon a solved bug in clang 3.2 while testing some ports:

http://llvm.org/bugs/show_bug.cgi?id=14491

Fixed in this commit:

http://llvm.org/viewvc/llvm-project?view=rev&revision=169451

Should the fix be imported in FreeBSD??


Yes, it will come with the import of 3.2, when it is released.  This
should be Really Soon Now. :-)


Thanks to all for the fast feedback. I'll quietly wait for the import.

--
Guido Falsi 
___
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: Lenovo x220 suspend/resume broken

[matt]

On 12/14/12 04:55, Ganael LAPLANCHE wrote:
> Hi everyone,
>
> Following this thread :
>
> http://lists.freebsd.org/pipermail/freebsd-current/2012-March/032519.html
>
> I have finally taken time to track this regression. It occurs with
> revision 231797 :
>
> http://svnweb.freebsd.org/base?view=revision&revision=231797
>
> Could anyone have a look at it ?
>
> Best regards,
>
> --
> Ganael LAPLANCHE 
> http://www.martymac.org | http://contribs.martymac.org
> FreeBSD: martymac , http://www.FreeBSD.org
Thanks for digging for that...

Perhaps revert the spinlocks to the the intr_suspend/intr_resume code
and see if it has an effect?
It's an uneducated guess :)

Matt
___
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: looking for help from ppp users

[Eitan Adler]

On 3 December 2012 10:41, Gary Palmer  wrote:
> While not commenting on the correctness of the current contents, the userland
> PPP section of the FAQ appears to mostly deal with dialup modems.  I suspect
> more people use it now to do PPPoA or PPPoE for some form of DSL link and
> there probably needs to be some effort to address the differences.

I've never used PPP in any sense.  Any chance I could enlist you to
help write some content?  I could turn it into docbook, edit it, etc.



-- 
Eitan Adler
___
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"