> Is it possible that the ip address assigned to the
> system's hostname was bound to the bge0 interface;
> that is, after disabling the bge driver, connections
> to the local machine using the machine' `hostname`
> failed ? I suspect that the X screen blank needs
> such
> a connection to wake up
> The machine answered the question: It was running
> smoothly for close to an hour. Then I left for lunch.
> When I came back, the monitor was black, no reaction.
> I tried all and everything, with power button as last
> resort. That resulted in a cold start.
Is it possible that the ip address as
> What next?
The machine answered the question: It was running smoothly for close to an
hour. Then I left for lunch. When I came back, the monitor was black, no
reaction. I tried all and everything, with power button as last resort. That
resulted in a cold start.
Since this was a good opportun
> Hmm, looks like the bge driver is using
> software interrupts, and I think these could
> be running at priority level 4.
>
> Seems that the bge hardware has some
> problems, and the driver tries to reset the
> bge network hardware in an attempt to
> recover from the bge hardware problem.
>
> b
> > Maybe we can find out who's calling drv_usecwait(),
> > using:
> > lockstat -kIW -f drv_usecwait -s 10 sleep 15
> # lockstat -kIW -f drv_usecwait -s 10 sleep 15
>
> Profiling interrupt: 88 events in 16.823 seconds (5 events/sec)
>
> ---
> If you repeat that lockstat, does the result look
> similar?
> cpu usage by "cpu[0]+4", in tsc_read(),
> ddi_mem_get32(),
> tsc_gethrtime(), ...drv_usecwait() ?
>
>
> Maybe we can find out who's calling drv_usecwait(),
> using:
> lockstat -kIW -f drv_usecwait -s 10 sleep 15
Okay, think, I
> > Ok, for system cpu time usage: try to run a kernel
> > profile, to find out what kernel functions are consuming
> > the time, lockstat -kIW -D 20 sleep 15
>
> I did one on the machine, and then quickly an ssh and
> another one in ssh for the screenshot:
>
> # lockstat -kIW -D 20 sleep 15
>
> ISR(s)
> > ...
> > 25 0x30 4 PCIEdg MSI0 1 -
> pepb_intr_handler
> could be related to PCI-e / PCI bus bridge;
> maybe some hotplug or power management event
> interrupt.
>
> The five minute delay could be a hint that it is
> related to
> power management. Are there p
> > Looks like driver interrupts, on cpu #0, and at IPL 4.
> >
> > What interrupts are bound to cpu 0 / IPL 4, on your
> > machine? This information is printed by
> >
> > echo ::interrupts | mdb -k
>
> This is whole lot while 'sane' (close to 0 CPU use):
> IRQ Vect IPL BusTrg Type C
> Looks like driver interrupts, on cpu #0, and at IPL
> 4.
>
> What interrupts are bound to cpu 0 / IPL 4, on your
> machine? This information is printed by
>
> echo ::interrupts | mdb -k
This is whole lot while 'sane' (close to 0 CPU use):
IRQ Vect IPL BusTrg Type CPU Share APIC/IN
> Count indv cuml rcnt nsec Hottest CPU+PIL Caller
> -
> --
> 2430 79% 79% 0.00 2682 cpu[0] i86_mwait
> 279 9% 88% 0.00 1364 cpu[0]+4 tsc_read
> 113 4% 92% 0.00 554980 cpu[0]+4 ddi_mem_get32
> 103 3% 95% 0.00 1437 cpu[0]+4
> Ok, for system cpu time usage: try to run a kernel
> profile, to find out what kernel functions are
> consuming
> the time, lockstat -kIW -D 20 sleep 15
I did one on the machine, and then quickly an ssh and another one in ssh for
the screenshot:
# lockstat -kIW -D 20 sleep 15
Profiling inte
> > Did you have a look at "mpstat 1" output before and
> > after the jump to 50% cpu usage?
> >
> > Does it consume user or system cpu time?
>
> 100% system time of CPU0 when the CPU usage bumps up
> to 50%. Before it is around 1-3 % for each CPU.
Ok, for system cpu time usage: try to run a ke
> Did you have a look at "mpstat 1" output before and
> after the jump to 50% cpu usage?
>
> Does it consume user or system cpu time?
100% system time of CPU0 when the CPU usage bumps up to 50%. Before it is
around 1-3 % for each CPU.
--
This message posted from opensolaris.org
___
> What I observed: the Gnome Resource Applet shows
> normal values, after around 5 minutes, whatever I do,
> the CPU will suddenly jump to 50% usage and stay there.
> Then, and this is also reproducable, the external
> mouse becomes almost unresponsive, while the touchpad
> gets 'jumpy' only. Then
Yes, it is the Core 2 Duo (isainfo -k: amd64), and it runs in 'SATA Native
Mode' disabled. It wouldn't run XP the other way round. Bluetooth is disabled.
mdb says:
Kernel: 13%
ZFS File Data 8%
Anon 9%
Page cache 2%
Free (cachelist) 1%
Free 66%
Total 3311
Physical 3311
What I observed: the Gnome
> It has 4 GB of RAM. Just after boot, 31% thereof are
> consumes for programs, 0% for cache, by the desktop
> alone. Is that normal?
Where are these percentages coming from?
mdb -k ::memstat command?
My 8GB box shows 0% (12MB) for "Exec and libs",
and 85% "Free", and the rest is used by the kern
> I gave OpenSolaris 2009.06 a shot, on an old HP
> nx6320.
I am running it daily on an equally old HP NX6310 (I *think* yours has got Core
2 Duo CPU, whereas mine is the older Core Duo ; 'isainfo -k' will confirm
this).
> Already during the install, it slows down
> considerably, and got stuc
I gave OpenSolaris 2009.06 a shot, on an old HP nx6320. Already during the
install, it slows down considerably, and got stuck completely. The third effort
succeeded finally.
Now, after reboot, the system is normal, if not snappy, for a few minutes, then
the mouse starts to react slow, that is, i
19 matches
Mail list logo
