headers
Andrew Thompson | 1 Sep 2010 01:07
Picon
Favicon

Re: DTrace userland project

On 1 September 2010 10:21, Rui Paulo <rpaulo <at> freebsd.org> wrote:
> Hi,
> The DTrace userland project is near completion and you can start using parts of it right away (only on
FreeBSD HEAD right now).
>
> For more information on how to use DTrace with userland, please read:
> http://wiki.freebsd.org/DTrace/userland
>
> This project is being sponsored by the FreeBSD Foundation.

I am getting some odd behavior with your test example. Using your
pid.d with the additional line "tick-1sec { exit(0); }" to limit it to
one second runtime I get the following output

CPU     ID                    FUNCTION:NAME
  1  45220                     _sleep:entry
  1  45220                     _sleep:entry
....
  0  45220                     _sleep:entry

With 54932 lines of output for the "_sleep:entry". It jumps around on
the reported CPU, if I use cpuset to limit it to just one core then it
does not reduce the 50,000 lines of output but just reports all on a
single CPU.

My kernel was build yesterday, r212042

Andrew
_______________________________________________
freebsd-current <at> freebsd.org mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
ben wilber | 1 Sep 2010 01:13

TSO panic

Hi,

I just upgraded from r210042 to r212073 and keep getting the panic
introduced in r211317:

panic: tcp_output: len <= tso_segsz

db:0:kdb.enter.default>  bt
Tracing pid 12 tid 100063 td 0xffffff001881b000
kdb_enter() at kdb_enter+0x3d
panic() at panic+0x1c8
tcp_output() at tcp_output+0x1445
tcp_do_segment() at tcp_do_segment+0x252d
tcp_input() at tcp_input+0x1044
ip_input() at ip_input+0x5cd
netisr_dispatch_src() at netisr_dispatch_src+0xc1
netisr_dispatch() at netisr_dispatch+0x11
ether_demux() at ether_demux+0x19a
ether_input() at ether_input+0x36a
mxge_intr() at mxge_intr+0x5be
intr_event_execute_handlers() at intr_event_execute_handlers+0x107
ithread_loop() at ithread_loop+0xb5
fork_exit() at fork_exit+0x147
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xffffff8810df2cf0, rbp = 0 ---

If there's someone interested in debugging this further, please let me
know what I can do to help.
_______________________________________________
freebsd-current <at> freebsd.org mailing list
(Continue reading)

Permalink | Reply | 5 comments |
headers
V. T. Mueller, Continum | 1 Sep 2010 01:18
Favicon

Re: ZFS v28 is ready for wider testing.

Pawel,

Pawel Jakub Dawidek wrote:
> I'd like to give you ZFS v28 for testing. If you are neither brave nor
> mad, you can stop here.
> The patchset is very experimental. It can eat your cookie and hurt your
> teddy bear, so be warned. Don't try it for anything except testing.

Thank you very much - now that there are a couple of major steps 
feature-wise we're going to give the experimental version a try.

> This patchset is also a message we, as the FreeBSD project, would like
> to send to our users: Eventhough OpenSolaris is dead, the ZFS file
> system is going to stay in FreeBSD. At this point we have quite a few
> developers involved in ZFS on FreeBSD as well as serveral companies.
> We are also looking forward to work with IllumOS.

Fine. FYI:
http://www.h-online.com/open/news/item/ZFS-as-a-Linux-kernel-module-1069056.html

Too bad FreeBSD still lacks Infiniband support. Currently we use ZFS on 
FreeBSD and Infiniband on Linux. If Linux supports both, we will (be 
forced to) switch.

Cheers,
vt
--

-- 
Volker T. Mueller
Continum AG
Bismarckallee 7d
(Continue reading)

Permalink | Reply | 1 comment |
headers
Matthew Jacob | 1 Sep 2010 01:23
Favicon

Re: ZFS v28 is ready for wider testing.


Infiniband is currently being worked on, sponsored by Panasas, Isilon 
and someone else. It's coming along pretty well.

> http://www.h-online.com/open/news/item/ZFS-as-a-Linux-kernel-module-1069056.html 
>
>
> Too bad FreeBSD still lacks Infiniband support. Currently we use ZFS 
> on FreeBSD and Infiniband on Linux. If Linux supports both, we will 
> (be forced to) switch.
>
> Cheers,
> vt

_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
Petersen Liman | 1 Sep 2010 07:24
Picon

Re: ZFS v28 is ready for wider testing.

Cool, but i may try this on a VM and maybe try this on a expermential
production system after I test it on  VM since a real system may help
the progress of the new ZFS sinc

On Tue, Aug 31, 2010 at 8:09 PM, Zhu Han <schumi.han <at> gmail.com> wrote:
> That's cool. Thank you for your work on it.
>
> best regards,
> hanzhu
>
>
> On Wed, Sep 1, 2010 at 5:59 AM, Pawel Jakub Dawidek <pjd <at> freebsd.org> wrote:
>
>> Hello.
>>
>> I'd like to give you ZFS v28 for testing. If you are neither brave nor
>> mad, you can stop here.
>>
>> The patchset is very experimental. It can eat your cookie and hurt your
>> teddy bear, so be warned. Don't try it for anything except testing.
>>
>> This patchset is also a message we, as the FreeBSD project, would like
>> to send to our users: Eventhough OpenSolaris is dead, the ZFS file
>> system is going to stay in FreeBSD. At this point we have quite a few
>> developers involved in ZFS on FreeBSD as well as serveral companies.
>> We are also looking forward to work with IllumOS.
>>
>> So, what this new ZFS brings?
>>
>> - Data deduplication. Read more here:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Anonymous | 1 Sep 2010 08:27
Picon

Re: ZFS v28 is ready for wider testing.

Pawel Jakub Dawidek <pjd <at> FreeBSD.org> writes:

> I'd like to give you ZFS v28 for testing. If you are neither brave nor
> mad, you can stop here.
[...]
> So test whatever you can and report back. Look for regressions, strange
> behaviour, missing features, deadlocks, livelocks, preformance
> degradation, etc.
[...]
> The boot code is not updated at all, so booting off of ZFS doesn't
> currently work.

This only apply when one's upgrading the pool's metadata.
Besides, I think bootcode doesn't support gzip-compressed pools, too.
_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
Andriy Gapon | 1 Sep 2010 10:22
Picon

stable/8 build broken on head without WITH_CTF


stable/8 build seems to be broken for me on head without WITH_CTF:
...
cc -c -x assembler-with-cpp -DLOCORE -O2 -fno-strict-aliasing -pipe -march=k8
-std=c99 -g -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef
-Wno-pointer-sign -fformat-extensions -nostdinc  -I.
-I/usr/devel/svn/base/stable/8/sys
-I/usr/devel/svn/base/stable/8/sys/contrib/altq -D_KERNEL
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common
-finline-limit=8000 --param inline-unit-growth=100 --param
large-function-growth=1000  -fno-omit-frame-pointer -mcmodel=kernel
-mno-red-zone  -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow
-msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
-Werror /usr/devel/svn/base/stable/8/sys/amd64/amd64/locore.S
: No such file or directory
*** Error code 1

The reason is that kernel Makefile (generated by config I assume) has these in
it (just two examples):
...
cam.o: $S/cam/cam.c
        ${NORMAL_C}
         <at> ${NORMAL_CTFCONVERT}
...
locore.o: $S/amd64/amd64/locore.S
        ${NORMAL_S}
         <at> ${NORMAL_CTFCONVERT}
...
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andriy Gapon | 1 Sep 2010 10:25
Picon

Re: stable/8 kernel build broken on head without WITH_CTF


The subject should have been what it is now, sorry.

--

-- 
Andriy Gapon
_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
Marius Nünnerich | 1 Sep 2010 12:20
Picon
Favicon

Re: DTrace userland project

On Wed, Sep 1, 2010 at 00:21, Rui Paulo <rpaulo <at> freebsd.org> wrote:
> Hi,
> The DTrace userland project is near completion and you can start using parts of it right away (only on
FreeBSD HEAD right now).
>
> For more information on how to use DTrace with userland, please read:
> http://wiki.freebsd.org/DTrace/userland

Hi,

I set this up in a VirtualBox with 9-current r212073 amd64, 4-cores,
amd-v and nested paging enabled.
I tried
dtruss /usr/bin/true
it works but is really slow, it takes ~10s to switch vt.

I tried the pid example as well, if I execute it on ttyv0 I can see lots of
kernel trap 12 with interrupts disabled
messages flying by and inbetween the desired _sleep:entry probes. When
I execute that script on ttyv1 I obviously don't see the kernel trap
messages and the machine kindof locks up (no output at all). I can do
a clean ACPI shutdown though.

 - Marius
_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"
(Continue reading)

Permalink | Reply | 2 comments |
headers
Rui Paulo | 1 Sep 2010 12:57
Picon
Favicon

Re: DTrace userland project

On 1 Sep 2010, at 11:20, Marius Nünnerich wrote:

> On Wed, Sep 1, 2010 at 00:21, Rui Paulo <rpaulo <at> freebsd.org> wrote:
>> Hi,
>> The DTrace userland project is near completion and you can start using parts of it right away (only on
FreeBSD HEAD right now).
>> 
>> For more information on how to use DTrace with userland, please read:
>> http://wiki.freebsd.org/DTrace/userland
> 
> Hi,
> 
> I set this up in a VirtualBox with 9-current r212073 amd64, 4-cores,
> amd-v and nested paging enabled.
> I tried
> dtruss /usr/bin/true
> it works but is really slow, it takes ~10s to switch vt.

This is not really using the new userland dtrace code, but the old one. I suspect DTrace has a problem running
on your system. Can you try a different VM software or real hardware? I never experienced this problem on
VMWare Fusion.

> I tried the pid example as well, if I execute it on ttyv0 I can see lots of
> kernel trap 12 with interrupts disabled
> messages flying by and inbetween the desired _sleep:entry probes. When
> I execute that script on ttyv1 I obviously don't see the kernel trap
> messages and the machine kindof locks up (no output at all). I can do
> a clean ACPI shutdown though.

This looks like I race that I haven't fixed yet. Either way, if the VM is interfering, then it will be hard to
(Continue reading)

Permalink | Reply | 1 comment |

Gmane