Re: my git development snapshot(s)
On Sep 20, 2011, at 6:58 AM, Arnaud Lacombe wrote: > Hi, > > [adding Fabien Thomas to the CC: list] > > On Sun, Sep 18, 2011 at 5:14 AM, Andriy Gapon wrote: >> >> Just decided to follow the global trends and trying to throw all of my >> local/private changes at you in hope that the "crowd-sourcing magic" might >> somehow happen :-) This seems definitely easier than carefully producing the >> patch files and keeping them up-to-date. >> >> So, my newly cloned gitorious repository: >> https://gitorious.org/~avg/freebsd/avgbsd >> > I see that this tree is a clone of: > > https://gitorious.org/freebsd/freebsd > > One issue I've got with that tree, is that it is not usable for any > serious work because of the following: I'm working seriously with it :D > > % git merge-base origin/master origin/svn_stable_8 > % echo $? > 1 > That's strange: # git merge-base origin/master origin/svn_stable_8 08b4e774d45547b6476807eacbfc1d2b5aab02e2 I've tried from fresh fresh clone with same result. > The whole FreeBSD 8.x branch is on its own. However: > > % git merge-base origin/master origin/svn_stable_7 > bdad8b50a25980737a8e00047f41fc1e588fc9e5 > > % git show bdad8b50a25980737a8e00047f41fc1e588fc9e5 > commit bdad8b50a25980737a8e00047f41fc1e588fc9e5 > Author: obrien > Date: Wed Oct 10 16:59:14 2007 + > > For 7.0 make the shared lib "version" '3'. > Approved by:re(kensmith) > > git-svn-id: svn://svn.freebsd.org/base/head@172505 > ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > > So something should have gone wrong when the mirror was created with > the 8-STABLE branch as its root commit is: # git log origin/svn_stable_8 commit 46c8a8db6dae5c885c7c1de5d39904566cc19685 Author: ume Date: Sun Sep 13 11:34:33 2009 + MFC r196475: - Add AS lookup functionality to traceroute6(8) as well. - Support for IPv6 transport for AS lookup. - Introduce $RA_SERVER to set whois server. - Support for 4 byte ASN. - ANSIfy function declaration in as.c. Approved by:re (kib) git-svn-id: http://svn.freebsd.org/base/stable/8@197158 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > > commit 47c9e1cbe6e19ab62a112f67fa4baf081aa213be > Author: jfv > Date: Fri Sep 4 22:37:03 2009 + > > This patch seperates the control of header split from LRO (which it > was previously dependent on), LRO gets turned off when bridging but > its been found that header split is still a performance win in that case. > > Secondly, there was some interface specific control in stats code that > has been missing, and a logic error that resulted in bogus reporting. > Thanks to Manish and John of LineRateSystems for the report and help in > this code. > > Approved by: re > > git-svn-id: http://svn.freebsd.org/base/stable/8@196843 > ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > > which should rather be: > > commit d4a6bb6e18d2601fe08d76be4610ae4a303574b2 > Author: ache > Date: Fri Jan 21 13:31:02 2005 + > > Whitespace/style tweaking of prev. commit. > > Noted by: bde > > git-svn-id: svn://svn.freebsd.org/base/head@140577 > ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > > > Regards, > - Arnaud > >> And the first branch of interest: >> https://gitorious.org/~avg/freebsd/avgbsd/commits/devel-20110915 >> >> This is a snapshot of almost all of my local changes to the FreeBSD src tree. >> Please note that the branch is not intended to be public in the git sense. >> That >> is, there will be no linear history - I periodically rebase my changes on >> top of >> the svn head and also frequently reshuffle/merge/split commits. >> The snapshot is not tidied up, there are quite a few commits that should be >> merged into other commits, some commit messages are not accurate/pretty, etc. >> The older the commits, the more mature they are supposed to be. >> >> Based on the above, no new commits are expected to this snapshot branch. >> I will produce new snapshot branches from time to time. >> >> I am posting this information to this list initially, later I plan to share >> the >> code with the wider audience e.g. via hackers@. >> >> P.S. This code sharing is made easier for me by git, Gitorious and "git >> rebase >> --onto" in particular. Thanks to Fabien Thomas for the initial FreeBSD clone >> repository at Gitorious! >> >> -- >> Andriy Gapon >> ___ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" >> -- Fabien Thomas ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: my git development snapshot(s)
git merge-base upstream/svn_trunk upstream/svn_stable_8 does not work. it seems that at some point in time it was working. (upstream = live tree, origin = my sandbox) I will need to dig a little more to understand the problem. Regards, Fabien ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: my git development snapshot(s)
Hi, On Tue, Sep 20, 2011 at 4:58 AM, Fabien Thomas wrote: > > On Sep 20, 2011, at 6:58 AM, Arnaud Lacombe wrote: > >> Hi, >> >> [adding Fabien Thomas to the CC: list] >> >> On Sun, Sep 18, 2011 at 5:14 AM, Andriy Gapon wrote: >>> >>> Just decided to follow the global trends and trying to throw all of my >>> local/private changes at you in hope that the "crowd-sourcing magic" might >>> somehow happen :-) This seems definitely easier than carefully producing >>> the >>> patch files and keeping them up-to-date. >>> >>> So, my newly cloned gitorious repository: >>> https://gitorious.org/~avg/freebsd/avgbsd >>> >> I see that this tree is a clone of: >> >> https://gitorious.org/freebsd/freebsd >> >> One issue I've got with that tree, is that it is not usable for any >> serious work because of the following: > > I'm working seriously with it :D > he, I guess we do not have the same kind of workflow :) In my case, I was trying a tree from 7-STABLE into 8-STABLE. >> >> % git merge-base origin/master origin/svn_stable_8 >> % echo $? >> 1 >> > That's strange: > # git merge-base origin/master origin/svn_stable_8 > 08b4e774d45547b6476807eacbfc1d2b5aab02e2 > > I've tried from fresh fresh clone with same result. > You will see this issue online too: https://gitorious.org/freebsd/freebsd/commits/svn_release_8_0_0?page=8 https://gitorious.org/freebsd/freebsd/commits/svn_release_8_1_0?page=82 https://gitorious.org/freebsd/freebsd/commits/svn_releng_8_0?page=8 https://gitorious.org/freebsd/freebsd/commits/svn_releng_8_1?page=82 There is no history before commit 47c9e1c. https://gitorious.org/freebsd/freebsd/commits/svn_releng_8_2?page=3 There is no history before commit aca2adc. Now, compare with 7.x branches: https://gitorious.org/freebsd/freebsd/commits/svn_releng_7_0?page=776 https://gitorious.org/freebsd/freebsd/commits/svn_releng_7_1?page=858 https://gitorious.org/freebsd/freebsd/commits/svn_releng_7_3?page=928 https://gitorious.org/freebsd/freebsd/commits/svn_releng_7_4?page=963 All have exactly the same root commit: d4a6bb6. I'm trying a new clone now, I'll let you know the result... - Arnaud >> The whole FreeBSD 8.x branch is on its own. However: >> >> % git merge-base origin/master origin/svn_stable_7 >> bdad8b50a25980737a8e00047f41fc1e588fc9e5 >> >> % git show bdad8b50a25980737a8e00047f41fc1e588fc9e5 >> commit bdad8b50a25980737a8e00047f41fc1e588fc9e5 >> Author: obrien >> Date: Wed Oct 10 16:59:14 2007 + >> >> For 7.0 make the shared lib "version" '3'. >> Approved by: re(kensmith) >> >> git-svn-id: svn://svn.freebsd.org/base/head@172505 >> ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >> >> So something should have gone wrong when the mirror was created with >> the 8-STABLE branch as its root commit is: > > # git log origin/svn_stable_8 > commit 46c8a8db6dae5c885c7c1de5d39904566cc19685 > Author: ume > Date: Sun Sep 13 11:34:33 2009 + > > MFC r196475: > - Add AS lookup functionality to traceroute6(8) as well. > - Support for IPv6 transport for AS lookup. > - Introduce $RA_SERVER to set whois server. > - Support for 4 byte ASN. > - ANSIfy function declaration in as.c. > > Approved by: re (kib) > > > git-svn-id: http://svn.freebsd.org/base/stable/8@197158 > ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > >> >> commit 47c9e1cbe6e19ab62a112f67fa4baf081aa213be >> Author: jfv >> Date: Fri Sep 4 22:37:03 2009 + >> >> This patch seperates the control of header split from LRO (which it >> was previously dependent on), LRO gets turned off when bridging but >> its been found that header split is still a performance win in that case. >> >> Secondly, there was some interface specific control in stats code that >> has been missing, and a logic error that resulted in bogus reporting. >> Thanks to Manish and John of LineRateSystems for the report and help in >> this code. >> >> Approved by: re >> >> git-svn-id: http://svn.freebsd.org/base/stable/8@196843 >> ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >> >> which should rather be: >> >> commit d4a6bb6e18d2601fe08d76be4610ae4a303574b2 >> Author: ache >> Date: Fri Jan 21 13:31:02 2005 + >> >> Whitespace/style tweaking of prev. commit. >> >> Noted by: bde >> >> git-svn-id: svn://svn.freebsd.org/base/head@140577 >> ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >> >> >> Regards, >> - Arnaud >> >>> And the first branch of interest: >>> https://gitorious.org/~avg/freebsd/avgbsd/commits/devel-20110915 >>> >>> This is a snapshot of almost all of my local changes to the FreeBSD src >>> tree. >>> Please note that the branch is not intended to be public in the git sense. >>> That >>> is, there will be no linear history - I periodically rebase my changes on >>> top of >>> the svn head and also frequently reshuffle/merge/split commits. >>> The snapshot is not tidied up, there are quite a few commits that should be >>> merged into other commits, some commit messages are not accurate/pretty,
Re: my git development snapshot(s)
Hi, On Tue, Sep 20, 2011 at 10:11 AM, Arnaud Lacombe wrote: > Hi, > > On Tue, Sep 20, 2011 at 4:58 AM, Fabien Thomas > wrote: >> >> On Sep 20, 2011, at 6:58 AM, Arnaud Lacombe wrote: >> >>> Hi, >>> >>> [adding Fabien Thomas to the CC: list] >>> >>> On Sun, Sep 18, 2011 at 5:14 AM, Andriy Gapon wrote: Just decided to follow the global trends and trying to throw all of my local/private changes at you in hope that the "crowd-sourcing magic" might somehow happen :-) This seems definitely easier than carefully producing the patch files and keeping them up-to-date. So, my newly cloned gitorious repository: https://gitorious.org/~avg/freebsd/avgbsd >>> I see that this tree is a clone of: >>> >>> https://gitorious.org/freebsd/freebsd >>> >>> One issue I've got with that tree, is that it is not usable for any >>> serious work because of the following: >> >> I'm working seriously with it :D >> > he, I guess we do not have the same kind of workflow :) In my case, I > was trying a tree from 7-STABLE into 8-STABLE. > >>> >>> % git merge-base origin/master origin/svn_stable_8 >>> % echo $? >>> 1 >>> >> That's strange: >> # git merge-base origin/master origin/svn_stable_8 >> 08b4e774d45547b6476807eacbfc1d2b5aab02e2 >> >> I've tried from fresh fresh clone with same result. >> > You will see this issue online too: > > https://gitorious.org/freebsd/freebsd/commits/svn_release_8_0_0?page=8 > https://gitorious.org/freebsd/freebsd/commits/svn_release_8_1_0?page=82 > https://gitorious.org/freebsd/freebsd/commits/svn_releng_8_0?page=8 > https://gitorious.org/freebsd/freebsd/commits/svn_releng_8_1?page=82 > > There is no history before commit 47c9e1c. > > https://gitorious.org/freebsd/freebsd/commits/svn_releng_8_2?page=3 > > There is no history before commit aca2adc. > > Now, compare with 7.x branches: > > https://gitorious.org/freebsd/freebsd/commits/svn_releng_7_0?page=776 > https://gitorious.org/freebsd/freebsd/commits/svn_releng_7_1?page=858 > https://gitorious.org/freebsd/freebsd/commits/svn_releng_7_3?page=928 > https://gitorious.org/freebsd/freebsd/commits/svn_releng_7_4?page=963 > > All have exactly the same root commit: d4a6bb6. > > I'm trying a new clone now, I'll let you know the result... > Still the same issue: % git clone git://gitorious.org/freebsd/freebsd.git Cloning into freebsd... remote: Counting objects: 639377, done. remote: Compressing objects: 100% (159732/159732), done. remote: Total 639377 (delta 489007), reused 619601 (delta 470781) Receiving objects: 100% (639377/639377), 339.01 MiB | 382 KiB/s, done. Resolving deltas: 100% (489007/489007), done. % cd freebsd freebsd/% git merge-base origin/master origin/svn_stable_8 freebsd/% echo $? 1 freebsd/% git --version git version 1.7.4.1 freebsd/% git log --pretty=oneline origin/svn_releng_7_0 | wc -l 23276 freebsd/% git log --pretty=oneline origin/svn_releng_7_1 | wc -l 25731 freebsd/% git log --pretty=oneline origin/svn_releng_7_2 | wc -l 26620 freebsd/% git log --pretty=oneline origin/svn_releng_7_3 | wc -l 27826 freebsd/% git log --pretty=oneline origin/svn_releng_7_4 | wc -l 28872 freebsd/% git log --pretty=oneline origin/svn_releng_8_0 | wc -l 238 freebsd/% git log --pretty=oneline origin/svn_releng_8_1 | wc -l 2446 freebsd/% git log --pretty=oneline origin/svn_releng_8_2 | wc -l 77 freebsd/% git log --pretty=oneline origin/master | wc -l 52252 Beside that, this repository is the only one with which I've got problem. - Arnaud > >>> The whole FreeBSD 8.x branch is on its own. However: >>> >>> % git merge-base origin/master origin/svn_stable_7 >>> bdad8b50a25980737a8e00047f41fc1e588fc9e5 >>> >>> % git show bdad8b50a25980737a8e00047f41fc1e588fc9e5 >>> commit bdad8b50a25980737a8e00047f41fc1e588fc9e5 >>> Author: obrien >>> Date: Wed Oct 10 16:59:14 2007 + >>> >>> For 7.0 make the shared lib "version" '3'. >>> Approved by: re(kensmith) >>> >>> git-svn-id: svn://svn.freebsd.org/base/head@172505 >>> ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >>> >>> So something should have gone wrong when the mirror was created with >>> the 8-STABLE branch as its root commit is: >> >> # git log origin/svn_stable_8 >> commit 46c8a8db6dae5c885c7c1de5d39904566cc19685 >> Author: ume >> Date: Sun Sep 13 11:34:33 2009 + >> >> MFC r196475: >> - Add AS lookup functionality to traceroute6(8) as well. >> - Support for IPv6 transport for AS lookup. >> - Introduce $RA_SERVER to set whois server. >> - Support for 4 byte ASN. >> - ANSIfy function declaration in as.c. >> >> Approved by: re (kib) >> >> >> git-svn-id: http://svn.freebsd.org/base/stable/8@197158 >> ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >> >>> >>> commit 47c9e1cbe6e19ab62a112f67fa4baf081aa213be >>> Author: jfv >>> Date: Fri Sep 4 22:37:03 2009 + >>> >>> This patch seperates the control of header split from LRO (which it >>> was previously dependent on), LRO gets tu
Re: my git development snapshot(s)
At some point in time (when i've migrated my server from i386 to amd64) the git-svn metadata was corrupted (perl problem). Maybe this problem is related as my original clone does not have the problem. I will try to restore and force push a new repo. Fabien ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: my git development snapshot(s)
On Tue, Sep 20, 2011 at 6:34 AM, Fabien Thomas wrote: > git merge-base upstream/svn_trunk upstream/svn_stable_8 > does not work. Ditto here. > > it seems that at some point in time it was working. > (upstream = live tree, origin = my sandbox) > I will need to dig a little more to understand the problem. Here's an observation that may be relevant. Some time back repository had much deeper history. Then at one point remote branches got forcefully updated during 'git fetch origin'. Once that happened, new svn_stable_8 branch had completely separate one from the one that was in the clone before the fetch. History also got trimmed and would only go as deep as ~2009. I suspected that history depth was trimmed in the original repository. The same trim could've 'disconnected' branches from the trunk, too. --Artem ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Sharing device driver between kernel and user space
Currently i'm developing VUART device drivers for PS3 architecture. VUART is bi-directional FIFO queue between 2 logical partitions on PS3. I want to use the device in the kernel and user space. During system boot PS3 system has to read/write some data from/to the VUART devices and sometimes i want to access the device from user space , e.g. with character device driver by using read/write syscalls. The quuestion is what is the best solution to share the device between kernel and user lands. One solution i found would be to porohibit kernel access to the device as soon as a user application opens the corresponding character device. And allow it again when the application calls close syscall. The user space should have higher priority then the kernel. Are there any better solutions for this problem ? Forgot to mention that a VUART device cannot be accessed simultaneously by user land and the kernel. The VUART devices are used by PS3 management logical partition to provide different request/response services and event notification to other logical partitions. E.g. setting video mode or configuring audio outputs. Thanks. -- Все возможности @Mail.Ru в твоем мобильном. Просто зайди с телефона на m.mail.ru___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
SW_WATCHDOG vs new eventtimer code
Alexander, just want to check with you first if the following makes sense. I use SW_WATCHDOG on one of the test machines, which was recently updated to from stable/8 to head. Now it seems to get seemingly random watchdog events. My theory is that this is because of the eventtimer logic. If during idle period we accumulate enough timer ticks and then run all those ticks very rapidly, then the SW_WATCHDOG code may get an impression that it was not patted for many real ticks. Not sure what would be the best way to make SW_WATCHDOG happier/smarter. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Sharing device driver between kernel and user space
On Tuesday 20 September 2011 20:35:57 geoffrey levand wrote: > Currently i'm developing VUART device drivers for PS3 architecture. VUART > is bi-directional FIFO queue between 2 logical partitions on PS3. I want > to use the device in the kernel and user space. During system boot PS3 > system has to read/write some data from/to the VUART devices and sometimes > i want to access the device from user space , e.g. with character device > driver by using read/write syscalls. The quuestion is what is the best > solution to share the device between kernel and user lands. One solution i > found would be to porohibit kernel access to the device as soon as a user > application opens the corresponding character device. And allow it again > when the application calls close syscall. The user space should have > higher priority then the kernel. Are there any better solutions for this > problem ? Forgot to mention that a VUART device cannot be accessed > simultaneously by user land and the kernel. The VUART devices are used by > PS3 management logical partition to provide different request/response > services and event notification to other logical partitions. E.g. setting > video mode or configuring audio outputs. > Have you looked at cuse4bsd in ports/multimedia/cuse4bsd-kmod ? --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: SW_WATCHDOG vs new eventtimer code
Hi. On 20.09.2011 22:19, Andriy Gapon wrote: > just want to check with you first if the following makes sense. > I use SW_WATCHDOG on one of the test machines, which was recently updated to > from stable/8 to head. Now it seems to get seemingly random watchdog events. > My theory is that this is because of the eventtimer logic. > If during idle period we accumulate enough timer ticks and then run all those > ticks very rapidly, then the SW_WATCHDOG code may get an impression that it > was > not patted for many real ticks. > Not sure what would be the best way to make SW_WATCHDOG happier/smarter. Eventtimer code now set to generate interrupts at least 4 times per second for each CPU. As soon as SW_WATCHDOG only handles periods more then one second, I would say it should not be hurt. I would try to add some debug there to see what's going on (how big the tick busts are). I'll try it to do it tomorrow. -- Alexander Motin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: SW_WATCHDOG vs new eventtimer code
on 20/09/2011 23:04 Alexander Motin said the following:
> Hi.
>
> On 20.09.2011 22:19, Andriy Gapon wrote:
>> just want to check with you first if the following makes sense.
>> I use SW_WATCHDOG on one of the test machines, which was recently updated to
>> from stable/8 to head. Now it seems to get seemingly random watchdog events.
>> My theory is that this is because of the eventtimer logic.
>> If during idle period we accumulate enough timer ticks and then run all those
>> ticks very rapidly, then the SW_WATCHDOG code may get an impression that it
>> was
>> not patted for many real ticks.
>> Not sure what would be the best way to make SW_WATCHDOG happier/smarter.
>
> Eventtimer code now set to generate interrupts at least 4 times per
> second for each CPU. As soon as SW_WATCHDOG only handles periods more
> then one second, I would say it should not be hurt. I would try to add
> some debug there to see what's going on (how big the tick busts are).
> I'll try it to do it tomorrow.
Just in case, here is a debugging snippet from a panic that I've got:
...
#12 0x80425d80 in watchdog_fire () at /usr/src/sys/kern/kern_clock.c:858
#13 0x8042603e in hardclock_anycpu (cnt=15761, usermode=Variable
"usermode" is not available.
) at atomic.h:183
#14 0x80660ae5 in handleevents (now=0xff80e3e0b8b0, fake=0) at
/usr/src/sys/kern/kern_clocksource.c:209
#15 0x80661b48 in timercb (et=Variable "et" is not available.
) at /usr/src/sys/kern/kern_clocksource.c:379
#16 0x802cc068 in hpet_intr_single (arg=Variable "arg" is not available.
) at /usr/src/sys/dev/acpica/acpi_hpet.c:258
#17 0x802cc71e in hpet_intr (arg=0xff80e3e0b5b0) at
/usr/src/sys/dev/acpica/acpi_hpet.c:276
#18 0x80444b02 in intr_event_handle (ie=0xfe0002751500,
frame=0xff80e3e0ba30) at /usr/src/sys/kern/kern_intr.c:1428
#19 0x8062f920 in intr_remove_handler (cookie=0xff80e3e0b5b0) at
/usr/src/sys/amd64/amd64/intr_machdep.c:197
#20 0x8069cca9 in lapic_enable_pmc () at
/usr/src/sys/x86/x86/local_apic.c:431
#21 0x8062cc70 in Xapic_isr2 () at apic_vector.S:87
#22 0x80443118 in intr_event_execute_handlers (p=0xfe0002758000,
ie=0xfe0002a5eb00) at /usr/src/sys/kern/kern_intr.c:1244
#23 0x80444164 in ithread_loop (arg=0xfe0002758000) at
/usr/src/sys/kern/kern_intr.c:1269
#24 0x8044053a in fork_exit (callout=0x80444024
, arg=0xfe0002b4f700, frame=0xff80e3e0bc50)
at /usr/src/sys/kern/kern_fork.c:1024
#25 0x8062cb0e in Xint0x80_syscall () at ia32_exception.S:62
#26 0x in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) fr 14
#14 0x80660ae5 in handleevents (now=0xff80e3e0b8b0, fake=0) at
/usr/src/sys/kern/kern_clocksource.c:209
209 while (bintime_cmp(now, &state->nextstat, >=)) {
(kgdb) list
204 }
205 if (runs && fake < 2) {
206 hardclock_anycpu(runs, usermode);
207 done = 1;
208 }
209 while (bintime_cmp(now, &state->nextstat, >=)) {
210 if (fake < 2)
211 statclock(usermode);
212 bintime_add(&state->nextstat, &statperiod);
213 done = 1;
(kgdb) p state->nextstat
$1 = {sec = 90, frac = 15986939599958264124}
(kgdb) p *now
$3 = {sec = 106, frac = 11494276814354478452}
(kgdb) p statperiod
$4 = {sec = 0, frac = 145249953336295682}
(kgdb) fr 13
#13 0x8042603e in hardclock_anycpu (cnt=15761, usermode=Variable
"usermode" is not available.
) at atomic.h:183
183 atomic.h: No such file or directory.
in atomic.h
(kgdb) p cnt
$5 = 15761
(kgdb) p newticks
$6 = 15000
(kgdb) p watchdog_ticks
$7 = 16000
Watchdog timeout was set to ~16 seconds.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: xlocale patch
On 09/21/11 02:17 AM, David Chisnall wrote: Ooops, I forgot I uninstalled the subversion-freebsd package and installed subversion to work on libc++ (it would be really nice if these two could coexist, by the way...). The updated version of the diff now passes all of the libc++ locale tests (309 files, multiple tests in each), with my copy of libc++. I've just pushed the exception handling bits required to support std::exception_ptr to libcxxrt, so we can now build a mostly-working BSD licensed C++ stack. For anyone that's interested, the full results of the libc++ test suite are here: http://pastebin.com/UCskvjCv For those two lazy Sounds about right - David - If you have the time we may be able to extend part of our test-suite to help you validate this. Building and running boost tests is also a good way to flush out bugs and really stress things as well. (Same goes for QT or Chromium.. etc) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: xlocale patch
Hello, David. You wrote 20 сентября 2011 г., 23:17:28: > Ooops, I forgot I uninstalled the subversion-freebsd package and > installed subversion to work on libc++ (it would be really nice if > these two could coexist, by the way...). How does subversion-freebsd prevent you from working on libc++? Is it uses $FreeBSD$ string? :) FreeBSD changes are: (1) Support for additional keywords to make $FreeBSD works. (2) Different style of merge conflict markers. (3) Commit message template. (3) could be annoying, but not show-stopper for sure. Next version of subversion will not have -freebsd variant, but will have three different options for mentioned hacks :) -- // Black Lion AKA Lev Serebryakov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
