Hi,
my problem occures on a 151a server with a large filesystem (12 TB) exported
via sun-cifs.
When doing a simple "dir" from a windows mount or a linux or even local
smbclient connection
I get sometimes a delay of about 20 seconds or sometimes an
NT_STATUS_IO_TIMEOUT or sometimes
an instant an
Hi, after reading a lot, I understand that LACP aggregation won't let me run a
single
connection on all the available links, but just allocate one per connection.
So, considering this, and considering one NFS client mounting a share through
an aggregated
path, I was wondering if multiple files us
On 10/20/11 06:24, Gabriele Bulfon wrote:
> Hi, after reading a lot, I understand that LACP aggregation won't let me run
> a single
> connection on all the available links, but just allocate one per connection.
> So, considering this, and considering one NFS client mounting a share through
> an a
On Wed, Oct 19, 2011 at 4:16 AM, Jonathan Adams wrote:
> did you set 'vboxnet0's IP address to 192.168.56.1/24 after you brought it up?
>
> On 18 October 2011 22:12, Ron Parker wrote:
>> ...
>> After a 'ipadm create-if vboxnet0', it shows up in ifconfig's output
>> and I was able to assign it an
I'm using nwam, so I have the vboxnet0 in /etc/nwam/llp and
/etc/nwam/ncp-User.conf
On 20 October 2011 15:10, Ron Parker wrote:
> On Wed, Oct 19, 2011 at 4:16 AM, Jonathan Adams wrote:
>> did you set 'vboxnet0's IP address to 192.168.56.1/24 after you brought it
>> up?
>>
>> On 18 October 2011
If you need multiple connections, use multiple IPs and/or host names.
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
On Thu, Oct 20, 2011 at 9:30 AM, Jonathan Adams wrote:
> I'm using nwam, so I have the vboxnet0 in /etc/nwam/llp and
> /etc/nwam/ncp-User.conf
Jonathan, Thanks. Due to your responses, I was able to get it working
either way, with ipadm or nwam.
The last thing I had to realize was don't try mixin
Hello all,
I have a machine here at my home running OpenIndiana oi_151a, which
serves as a NAS on my home network. The original install was OpenSolaris
2009.6 which was later upgraded to snv_134b, and recently to oi_151a.
So far this OSOL (now OI) box has performed excellently, with one major
No they're just set up in DNS. After b134 (any flavor, OpenSolaris, Solaris
11 Express) it won't accept CIFS connections to DNS aliases.
Windows 2008 is the same way, but you can flip a registry setting to let SMB
Connections come in on DNS Aliases even if its not set as a SPN alias (the
more pro
Sorry I meant it won't accept DNS aliases at the same time.
On Thu, Oct 20, 2011 at 9:48 AM, Jonathan Leafty <
jleafty+openindianadisc...@gmail.com> wrote:
> No they're just set up in DNS. After b134 (any flavor, OpenSolaris,
> Solaris 11 Express) it won't accept CIFS connections to DNS aliases.
On Thu, 2011-10-20 at 18:44 +0200, Gernot Wolf wrote:
> Hello all,
>
> I have a machine here at my home running OpenIndiana oi_151a, which
> serves as a NAS on my home network. The original install was OpenSolaris
> 2009.6 which was later upgraded to snv_134b, and recently to oi_151a.
>
> So fa
I saw a comment it was fixed in Opensolaris snv_161 (I think) but you can't
get that.
It seems to work for me in OI 148, but I haven't tested it extensively yet,
but opening 2 windows on two different aliases work.
John
-Original Message-
From: Jonathan Leafty [mailto:jleafty+openindiana
Hi Gernot,
You have a high context switch rate.
try
#dtrace -n 'sched:::off-cpu { @[execname]=count()}'
For a few seconds to see if you can get the name of and executable.
Mike
On Thu, 2011-10-20 at 18:44 +0200, Gernot Wolf wrote:
> Hello all,
>
> I have a machine here at my home running Ope
Dontchya just love dtrace?
On 10/20/11 10:22 AM, "Michael Stapleton"
wrote:
>Hi Gernot,
>
>You have a high context switch rate.
>
>try
>#dtrace -n 'sched:::off-cpu { @[execname]=count()}'
>
>For a few seconds to see if you can get the name of and executable.
>
>Mike
>On Thu, 2011-10-20 at 18:4
Wow, that was fast :)
However, the NIC integrated on the Intel DG965WHMKR mainbord is an Intel
82566DC according to the device driver utility, the reported driver
e1000g. Isn't the bge driver for Broadcom NICs?
And what do you mean by "the other nvidia based interface"? This
mainboard has on
On Thu, 2011-10-20 at 19:34 +0200, Gernot Wolf wrote:
> Wow, that was fast :)
Just caught me with the morning coffee email review.
> However, the NIC integrated on the Intel DG965WHMKR mainbord is an Intel
> 82566DC according to the device driver utility, the reported driver
> e1000g. Isn't the
Sure do :-)
People tend to think only about ZFS and maybe Zones. They don't
understand dtrace and resource management.
Solaris is much more than ZFS, but you really have to know what you are
doing to appreciate it.
The true strength of Solaris is server side in the hands of
professionals.
Ther
Yeah, I've been able to run this diagnostics on another OI box (at my
office, so much for OI not being used in production ;)), and noticed
that there were several values that were quite different. I just don't
have any idea on the meaning of this figures...
Anyway, here are the results of the
Your lockstat output fingers Acpi debug tracing functions.
I wonder why these are running in the first place.
Steve
- Original Message -
Hello all,
I have a machine here at my home running OpenIndiana oi_151a, which
serves as a NAS on my home network.
Sched is the scheduler itself. How long did you let this run? If only
for a couple of seconds, then that number is high, but not ridiculous for
a loaded system, so I think that this output rules out a high context
switch rate.
Try this command to see if some process is making an excessive numb
That rules out userland.
Sched tells me that it is not a user process. If kernel code is
executing on a cpu, tools will report the sched process. The count was
how many times the process was taken off the CPU while dtrace was
running.
Lets see what kernel code is running the most:
#dtrace -n '
Wow, that was fast :)
Just caught me with the morning coffee email review.
Well, I just had a nice dinner :)
However, the NIC integrated on the Intel DG965WHMKR mainbord is an Intel
82566DC according to the device driver utility, the reported driver
e1000g. Isn't the bge driver for Broadco
Gernot,
is there anything suspicious in /var/adm/messages?
Michael
On Thu, Oct 20, 2011 at 20:07, Michael Stapleton
wrote:
> That rules out userland.
>
> Sched tells me that it is not a user process. If kernel code is
> executing on a cpu, tools will report the sched process. The count was
> ho
Try the following script, which will identify any drivers with high
interrupt load
-
#!/usr/sbin/dtrace -s
sdt:::interrupt-start { self->ts = vtimestamp; }
sdt:::interrupt-complete
/self->ts && arg0 != 0/
{
this->devi = (struct dev_info *)arg0;
self->name = thi
My understanding is that it is not supposed to be a loaded system. We
want to know what the load is.
gernot@tintenfass:~# intrstat 30
device | cpu0 %tim cpu1 %tim
-+--
e1000g#0 | 1 0,0 0 0,0
ehci#0 | 0 0
Hi,
just found this:
http://download.oracle.com/docs/cd/E19253-01/820-5245/ghgoc/index.html
does it help?
On Thu, Oct 20, 2011 at 20:23, Michael Stapleton
wrote:
> My understanding is that it is not supposed to be a loaded system. We
> want to know what the load is.
>
>
> gernot@tintenfass:~# i
On Thu, Oct 20, 2011 at 12:48 PM, Jonathan Leafty
wrote:
> No they're just set up in DNS. After b134 (any flavor, OpenSolaris, Solaris
> 11 Express) it won't accept CIFS connections to DNS aliases.
>
> Windows 2008 is the same way, but you can flip a registry setting to let SMB
> Connections come
Don't know. I don't like to trouble shoot by guess if possible. I rather
follow the evidence to capture the culprit. Use what we know to discover
what we do not know.
We know CS rate in vmstat is high, we know Sys time is high, we know
syscall rate is low, we know it is not a user process therefor
On Thu, Oct 20, 2011 at 20:33, Michael Stapleton
wrote:
> Don't know. I don't like to trouble shoot by guess if possible. I rather
> follow the evidence to capture the culprit. Use what we know to discover
> what we do not know.
if you're answering my question: I'm not guessing that much: I looke
I'd like to see a run of the script I sent earlier. I don't trust
intrstat (not for any particular reason, other than that I have never used
it)...
On 10/20/11 11:33 AM, "Michael Stapleton"
wrote:
>Don't know. I don't like to trouble shoot by guess if possible. I rather
>follow the evidence to
You might be right.
But 45% of what?
Profiling interrupt: 5844 events in 30.123 seconds (194 events/sec)
Count indv cuml rcnt nsec Hottest CPU+PIL
Caller
---
2649 45% 45% 0.00 1070 cpu[1]
i86
On Thu, Oct 20, 2011 at 20:55, Michael Stapleton
wrote:
> You might be right.
>
> But 45% of what?
>
> Profiling interrupt: 5844 events in 30.123 seconds (194 events/sec)
>
> Count indv cuml rcnt nsec Hottest CPU+PIL
> Caller
> --
+1
Mike
On Thu, 2011-10-20 at 11:47 -0700, Rennie Allen wrote:
> I'd like to see a run of the script I sent earlier. I don't trust
> intrstat (not for any particular reason, other than that I have never used
> it)...
>
>
> On 10/20/11 11:33 AM, "Michael Stapleton"
> wrote:
>
> >Don't know.
Profiling is AFAIK statistical, so it might not show the correct number.
Certainly the count of interrupts does not appear high, but if the handler
is spending a long time in the interrupt...
The script I sent measures the time spent in the handler (intrstat might do
this as well, but I just don'
i86_mwait is the idle function the cpu is executing when it has
nothing else to do. Basically it sleeps inside of that function.
Lockstat based profiling just samples what is on cpu, so idle time
shows up as some form of mwait, depending on how the bios
is configured.
Steve
- Original
You mean, besides being quite huge? I took a quick look at it, but other
than getting a headache by doing that, my limited unix skills
unfortunately fail me.
I've zipped it an attached it to this mail, maybe someone can get
anything out of it...
Regards,
Gernot
Am 20.10.11 20:17, schrieb M
Here are the results (let the script run for a few secs):
CPU IDFUNCTION:NAME
1 2 :END DEVICE TIME (ns)
i9151 22111
heci0 23119
pci-ide0 38700
uhci1 4
Ooops, something went wrong with my attachement. I'll try again...
Regards,
Gernot Wolf
Am 20.10.11 21:09, schrieb Gernot Wolf:
You mean, besides being quite huge? I took a quick look at it, but other
than getting a headache by doing that, my limited unix skills
unfortunately fail me.
I've zi
Here is something to check:
Pop into the debugger ( mdb -k) and see what AcpiDbgLevel's current setting is.
E.g:
AcpiDbgLevel/x
The default setting is 3. If its something higher, that would explain the high
incidence of
Acpi trace/debug calls.
To exit the debugger type $q or ::quit
S
Attachment is missing...
I'd like to see the whole things, but in the mean while
#grep -i acpi /var/adm/messages
Anything?
Mike
On Thu, 2011-10-20 at 21:09 +0200, Gernot Wolf wrote:
> You mean, besides being quite huge? I took a quick look at it, but other
> than getting a headache by doing
I let it run (as all the other dtrace commands you guys have given me)
just for a couple of seconds. And no, it's not a loaded system, that's
the problem here. It's just a home NAS...
Here is the dtrace output:
gernot@tintenfass:/root# dtrace -n 'syscall:::entry { @[execname]=count()}'
dtrace:
Ok, for some reason this attachement refuses to go out :( Have to figure
that out...
Regards,
Gernot Wolf
Am 20.10.11 21:20, schrieb Gernot Wolf:
Ooops, something went wrong with my attachement. I'll try again...
Regards,
Gernot Wolf
Am 20.10.11 21:09, schrieb Gernot Wolf:
You mean, besid
Gernot Wolf wrote:
> Ok, for some reason this attachement refuses to go out :( Have to figure
> that out...
Probably just because it's huge. Try "tail -100 /var/adm/messages".
It's likely that if there's something going nuts on your system,
there'll be enough log-spam to identify it.
--
James C
Nope. Cpu load remains the same. top shows:
CPU states: 47.5% idle, 0.0% user, 52.5% kernel, 0.0% iowait, 0.0% swap
Regards,
Gernot Wolf
Am 20.10.11 20:25, schrieb Michael Schuster:
Hi,
just found this:
http://download.oracle.com/docs/cd/E19253-01/820-5245/ghgoc/index.html
does it help?
Since Gernot is seeing the issue, maybe he wants to pitch in here?
He wants, he's just having a hard time keeping up with you guys. You're
so fast, I'm hopelessly lagging behind ;)
Thanks a lot for all the help so far to all of you!
Regards,
Gernot
__
Results are up, see other post...
Regards,
Gernot Wolf
Am 20.10.11 21:00, schrieb Michael Stapleton:
+1
Mike
On Thu, 2011-10-20 at 11:47 -0700, Rennie Allen wrote:
I'd like to see a run of the script I sent earlier. I don't trust
intrstat (not for any particular reason, other than that I
Probably just too big.
Are there any ACPI settings in the BIOS?
or we can try to change ACPI in OI.
#man eeprom
.
.
.
OPERANDS
x86 Only
acpi-user-options
A configuration variable that controls the use of
Advanced Configuration and Power Interface (ACPI), a
Am 20.10.11 20:57, schrieb Michael Schuster:
On Thu, Oct 20, 2011 at 20:55, Michael Stapleton
wrote:
You might be right.
But 45% of what?
Profiling interrupt: 5844 events in 30.123 seconds (194 events/sec)
Count indv cuml rcnt nsec Hottest CPU+PIL
Caller
Well, I zipped it, the zipfile is just 211K? Shouldn't be a problem, I
think...
Regards,
Gernot Wolf
Am 20.10.11 21:38, schrieb James Carlson:
Gernot Wolf wrote:
Ok, for some reason this attachement refuses to go out :( Have to figure
that out...
Probably just because it's huge. Try "tai
Ok, here we go:
gernot@tintenfass:~# mdb -k
Loading modules: [ unix genunix specfs dtrace mac cpu.generic uppc
pcplusmp scsi_vhci zfs ip hook neti sockfs arp usba uhci s1394 fctl
stmf_sbd stmf idm fcip cpc random sata crypto sd lofs logindmux ptm ufs
sppp smbsrv nfs ipc ]
> AcpiDbgLevel
> Acp
I would not worry about it. The messages are being caused by some
problem. Lets focus on getting the messages.
Debug will increase your load, but not like you are seeing.
Mike
On Thu, 2011-10-20 at 22:10 +0200, Gernot Wolf wrote:
> Ok, here we go:
>
> gernot@tintenfass:~# mdb -k
> Loading modul
Is this running in a VM?
Mike
On Thu, 2011-10-20 at 22:20 +0200, Gernot Wolf wrote:
> Grep output attached. Hopefully this attachement will go through ;)
>
> Regards,
> Gernot Wolf
>
>
> Am 20.10.11 21:25, schrieb Michael Stapleton:
> > Attachment is missing...
> >
> > I'd like to see the who
Yes, I noticed that to when I compared the lockstat output on my OI box
with that on the OI box at my office. There no Acpi debug tracing
functions are shown at all...
Mike made further suggestions concerning apci, but that will have to
wait for tomorrow. My bed is calling my name ;)
Regards
No. Why?
Regards,
Gernot Wolf
Am 20.10.11 22:33, schrieb Michael Stapleton:
Is this running in a VM?
Mike
On Thu, 2011-10-20 at 22:20 +0200, Gernot Wolf wrote:
Grep output attached. Hopefully this attachement will go through ;)
Regards,
Gernot Wolf
Am 20.10.11 21:25, schrieb Michael Sta
Ok, I'll try that tomorrow. Too late to try anything that might result
in my box having booting problems ;)
Regards,
Gernot Wolf
Am 20.10.11 21:55, schrieb Michael Stapleton:
Probably just too big.
Are there any ACPI settings in the BIOS?
or we can try to change ACPI in OI.
#man eeprom
.
.
Just checking ;-)
Night!
Mike
On Thu, 2011-10-20 at 22:40 +0200, Gernot Wolf wrote:
> No. Why?
>
> Regards,
> Gernot Wolf
>
>
> Am 20.10.11 22:33, schrieb Michael Stapleton:
> > Is this running in a VM?
> >
> > Mike
> >
> > On Thu, 2011-10-20 at 22:20 +0200, Gernot Wolf wrote:
> >
> >> Grep
Sorry, I was away from my desk for a while. Obviously this isn't an issue,
in fact, if anything, those numbers are surprisingly small.
On Thu, Oct 20, 2011 at 12:18 PM, Gernot Wolf wrote:
> Here are the results (let the script run for a few secs):
>
> CPU IDFUNCTION:NAME
Ok, I could not resist giving it a try, screw my bed ;)
Mike, bingo! That one hit home. With acpi-user-options set to 0x08 and
subsequent reboot cpu load is back to normal (that is load average=0.05).
I'll run my diagnostics again on my system and post the results in case
anyone is interested
No network captures yet, I was kind of waiting for the fqdn to be fixed as I
was thinking it was related. I think I'll have time to do it this weekend,
I'll load Wireshark on a Windows 7 VM and report back.
Also, I can open two different Explorer Windows (though if you quickly
navigate against bo
Oh! I might have a guess what this is - but your captures will verify.
You can also turn on debug logging. I think you may see that the
"vc==0" feature is causing the new connection to kill the prior ones.
On Thu, Oct 20, 2011 at 6:13 PM, Jonathan Leafty
wrote:
> No network captures yet, I was
60 matches
Mail list logo
