Re: [dtrace-discuss] dtrace wired issue
On Jan 15, 2008 2:45 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi Aubrey, >> ---snip-- > > setrlimit(RLIMIT_NOFILE, 0xFD7FFFDFEE80)= 0 > > openat(AT_FDCWD, "/dev/dtrace/provider", O_RDONLY|O_NDELAY|O_LARGEFILE) = 3 > > fcntl(3, F_SETFD, 0x0001) = 0 > > fstat(3, 0xFD7FFFDFE8E0)= 0 > > getdents(3, 0xFD7FFF174000, 8192) (sleeping...) > > ---here, dtrace sleep almost 4 minutes > > ...and continue... > > > > > How long does an ls -l /dev/dtrace/provider take? Yes, it costs almost 4 minutes. > I doubt you are swapping with 2G of memory. > You can run vmstat -S 2 to see if there is any swapping. I'll look a > bit more... # vmstat -S 2 kthr memorypagedisk faults cpu r b w swap free si so pi po fr de sr cd -- -- -- in sy cs us sy id 0 0 0 1601116 1352560 0 0 717 2 53 0 2502 71 0 0 0 718 7222 2813 4 3 93 0 0 0 1516012 1236776 0 0 0 0 0 0 0 0 0 0 0 388 269 347 0 0 99 0 0 0 1516012 1236808 0 0 0 0 0 0 0 0 0 0 0 394 262 354 0 0 100 0 0 0 1516012 1236808 0 0 0 0 0 0 0 0 0 0 0 392 255 356 0 0 100 0 0 0 1516016 1236812 0 0 0 0 0 0 0 23 0 0 0 425 380 396 1 0 99 0 0 0 1516016 1236812 0 0 0 0 0 0 0 0 0 0 0 389 294 332 0 0 100 0 0 0 1516016 1236812 0 0 0 0 0 0 0 0 0 0 0 382 466 444 0 0 99 0 0 0 1516016 1236812 0 0 0 0 0 0 0 0 0 0 0 394 273 346 0 0 100 0 0 0 1516016 1236812 0 0 0 0 0 0 0 0 0 0 0 387 250 328 0 0 99 0 0 0 1516016 1236812 0 0 0 0 0 0 0 0 0 0 0 384 264 339 0 0 100 > By the way, are you running on Indiana (just curious...). > No, I'm using nevada. [EMAIL PROTECTED] /etc/release Solaris Express Community Edition snv_77 X86 Copyright 2007 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 06 November 2007 Thanks, -Aubrey ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] dtrace wired issue
Aubrey Li wrote: > On Jan 15, 2008 2:45 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >> Hi Aubrey, >> >>> ---snip-- >>> setrlimit(RLIMIT_NOFILE, 0xFD7FFFDFEE80)= 0 >>> openat(AT_FDCWD, "/dev/dtrace/provider", O_RDONLY|O_NDELAY|O_LARGEFILE) = 3 >>> fcntl(3, F_SETFD, 0x0001) = 0 >>> fstat(3, 0xFD7FFFDFE8E0)= 0 >>> getdents(3, 0xFD7FFF174000, 8192) (sleeping...) >>> ---here, dtrace sleep almost 4 minutes >>> ...and continue... >>> >>> >>> >> How long does an ls -l /dev/dtrace/provider take? >> > > Yes, it costs almost 4 minutes. > > So, what does ls -l /dev/dtrace/provider show? max >> I doubt you are swapping with 2G of memory. >> You can run vmstat -S 2 to see if there is any swapping. I'll look a >> bit more... >> > > # vmstat -S 2 > kthr memorypagedisk faults cpu > r b w swap free si so pi po fr de sr cd -- -- -- in sy cs us sy id > 0 0 0 1601116 1352560 0 0 717 2 53 0 2502 71 0 0 0 718 7222 2813 4 3 93 > 0 0 0 1516012 1236776 0 0 0 0 0 0 0 0 0 0 0 388 269 347 0 0 99 > 0 0 0 1516012 1236808 0 0 0 0 0 0 0 0 0 0 0 394 262 354 0 0 > 100 > 0 0 0 1516012 1236808 0 0 0 0 0 0 0 0 0 0 0 392 255 356 0 0 > 100 > 0 0 0 1516016 1236812 0 0 0 0 0 0 0 23 0 0 0 425 380 396 1 0 99 > 0 0 0 1516016 1236812 0 0 0 0 0 0 0 0 0 0 0 389 294 332 0 0 > 100 > 0 0 0 1516016 1236812 0 0 0 0 0 0 0 0 0 0 0 382 466 444 0 0 99 > 0 0 0 1516016 1236812 0 0 0 0 0 0 0 0 0 0 0 394 273 346 0 0 > 100 > 0 0 0 1516016 1236812 0 0 0 0 0 0 0 0 0 0 0 387 250 328 0 0 99 > 0 0 0 1516016 1236812 0 0 0 0 0 0 0 0 0 0 0 384 264 339 0 0 > 100 > > >> By the way, are you running on Indiana (just curious...). >> >> > > No, I'm using nevada. > > [EMAIL PROTECTED] /etc/release >Solaris Express Community Edition snv_77 X86 >Copyright 2007 Sun Microsystems, Inc. All Rights Reserved. > Use is subject to license terms. >Assembled 06 November 2007 > > Thanks, > -Aubrey > > ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] dtrace wired issue
On Jan 15, 2008 4:43 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Aubrey Li wrote: > > On Jan 15, 2008 2:45 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > >> Hi Aubrey, > >> > >>> ---snip-- > >>> setrlimit(RLIMIT_NOFILE, 0xFD7FFFDFEE80)= 0 > >>> openat(AT_FDCWD, "/dev/dtrace/provider", O_RDONLY|O_NDELAY|O_LARGEFILE) = > >>> 3 > >>> fcntl(3, F_SETFD, 0x0001) = 0 > >>> fstat(3, 0xFD7FFFDFE8E0)= 0 > >>> getdents(3, 0xFD7FFF174000, 8192) (sleeping...) > >>> ---here, dtrace sleep almost 4 minutes > >>> ...and continue... > >>> > >>> > >>> > >> How long does an ls -l /dev/dtrace/provider take? > >> > > > > Yes, it costs almost 4 minutes. > > > > > So, what does ls -l /dev/dtrace/provider show? > max > > # ls -l /dev/dtrace/provider total 14 lrwxrwxrwx 1 root root 43 Sep 3 01:21 fasttrap -> ../../../devices/pseudo/[EMAIL PROTECTED]:fasttrap lrwxrwxrwx 1 root root 33 Sep 3 01:21 fbt -> ../../../devices/pseudo/[EMAIL PROTECTED]:fbt lrwxrwxrwx 1 root root 43 Sep 3 01:21 lockstat -> ../../../devices/pseudo/[EMAIL PROTECTED]:lockstat lrwxrwxrwx 1 root root 49 Sep 3 01:21 lx_systrace -> ../../../devices/pseudo/[EMAIL PROTECTED]:lx_systrace lrwxrwxrwx 1 root root 41 Sep 3 01:21 profile -> ../../../devices/pseudo/[EMAIL PROTECTED]:profile lrwxrwxrwx 1 root root 33 Sep 3 01:21 sdt -> ../../../devices/pseudo/[EMAIL PROTECTED]:sdt lrwxrwxrwx 1 root root 43 Sep 3 01:21 systrace -> ../../../devices/pseudo/[EMAIL PROTECTED]:systrace err, now I got something interesting. It looks like this wired issue is caused by the ata driver bug which I reported on the opensolaris-bug mailing list. When I switch the system to the console mode(X is disabled), I got #dtrace -l snip scsi: WARNING: /[EMAIL PROTECTED],0/[EMAIL PROTECTED],2/[EMAIL PROTECTED] (ata1): timeout: abort request, target=0 lun=0 scsi: WARNING: /[EMAIL PROTECTED],0/[EMAIL PROTECTED],2/[EMAIL PROTECTED] (ata1): timeout: abort device, target=0 lun=0 scsi: WARNING: /[EMAIL PROTECTED],0/[EMAIL PROTECTED],2/[EMAIL PROTECTED] (ata1): timeout: reset target, target=0 lun=0 scsi: WARNING: /[EMAIL PROTECTED],0/[EMAIL PROTECTED],2/[EMAIL PROTECTED] (ata1): timeout: reset bus, target=0 lun=0 ID PROVIDERMODULE FUNCTION NAME 1 dtrace BEGIN 2 dtrace END 3 dtrace ERROR 4 lockstat genunix mutex_enter adaptive-acquire 5 lockstat genunix mutex_enter adaptive-block 6 lockstat genunix mutex_enter adaptive-spin 7 lockstat genunixmutex_exit adaptive-release 8 lockstat genunix mutex_destroy adaptive-release 9 lockstat genunixmutex_tryenter adaptive-acquire snip -Aubrey ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] destructive actions
Brian Kolaci wrote: > Peter Shoults wrote: > >> Brian Kolaci wrote: >> >>> Chip Bennett wrote: >>> >>> Chip Bennett wrote: > According to the manual, if you give all of the dtrace privs to a > normal user, that user can access everything except destructive > actions, which is still reserved for the super user. As such a user > a ran a script that did a "chip(10)", and got the following error: > > dtrace: error on enabled probe ID 3 (ID 13: syscall::read:return): > invalid kernel access in action #2 > > > Pardon me, That should have been a "chill(10)". Sorry. Chip (not 10) ;-) >>> Thanks alot. >>> Its been a long time since I've read the manual. Should have known >>> that... >>> >>> ___ >>> dtrace-discuss mailing list >>> dtrace-discuss@opensolaris.org >>> >>> >> Also, you would have to start the dtrace sccript with a -w option, if >> you do not, the destructive actions do not take. Actually, I think the >> script will not even run >> > > Yep, they knew that. But audit wants to make sure they can't even do it > by mistake (for example, hidden in the first line of a D script). > Well, it really wouldn't be hidden would it. It would have to be in the first line as an arg passed into dtrace. I guess I do not get it.all they would have to do is more the script and see if it has a -w on the first line.. ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
