On Sat, 23 Jan 2010 18:47:45 +0100, Frank Batschulat (Home)
wrote:
> so lets wait for build 132...I'll also look at your dump from your test system
> on monday, but I suspect it'll be the same IP panic...
Hey Glenn, so I finally managed testing latest ISC with this stress test on
build 132.
I
Frank,
Thanks so much for all of your effort. I never thought it would be this
hard to track down. I will sync up with you after I have had a chance
to test on b132. I am looking forward to 132 as it also has this fix:
6776009 nwam doesn't bring up pseudo data-links or flows at boot time
g
On Mon, 18 Jan 2010 16:33:38 +0100, Frank Batschulat (Home)
wrote:
> the bad news is, I'm not getting the dumps, sigh. this is due to bug:
>
> 6911155 kernel dump fails if panic happens in interrupt service routine
>
> which is fixed in build 131.
>
> So I will persue this further once OSOL_131
On Wed, 23 Dec 2009 15:26:17 +0100, Glenn Brunette
wrote:
> Just verified that something is still wrong in b129, but the problem is
> _not_ with a vanilla configuration. This time around boot/halt #102,
> the system apparently shutdown/panic'ed? I was running it overnight
> and came in to a sy
On Wed, 06 Jan 2010 03:28:35 +0100, Glenn Brunette
wrote:
> Just an update. I am still able to get the repeatable hangs, but I am
> still not able to generate a dump. If anyone has any further ideas as
> to how to troubleshoot this please let me know!
Hey Glenn, you are not fogotten, I shall
Just an update. I am still able to get the repeatable hangs, but I am
still not able to generate a dump. If anyone has any further ideas as
to how to troubleshoot this please let me know!
g
On 12/23/09 2:09 PM, Frank Batschulat (Home) wrote:
Glenn, I'll try to reproduce this on my end on an
Glenn, I'll try to reproduce this on my end on an osol_129 system based on the
setup you outlines and then using the wellknown "script" and report back.
though that may take time until after christmas.
cheers
frankB
On Wed, 23 Dec 2009 15:26:17 +0100, Glenn Brunette
wrote:
>
> Frank,
>
> Jus
That's the thing, I did not see any!? I am still running my test.
It is up to iteration #98 right now. I have verified via dumpadm
that a dump device is configured/enabled, so it is a bit of a
waiting game at this point. I did extend the delay between boot
and halt just a bit to more accuratel
Do you have the panic message or crash dump?
-Steve L.
On Wed, Dec 23, 2009 at 09:26:17AM -0500, Glenn Brunette wrote:
>
> Frank,
>
> Just verified that something is still wrong in b129, but the problem is
> _not_ with a vanilla configuration. This time around boot/halt #102,
> the system appar
Frank,
Just verified that something is still wrong in b129, but the problem is
_not_ with a vanilla configuration. This time around boot/halt #102,
the system apparently shutdown/panic'ed? I was running it overnight
and came in to a system that had been rebooted. I did not see any
problem in
Frank,
I am back from vacation and will be doing some additional testing. I
have upgraded to b129 to see if the problem persists. I have first
created a basic (generic) zone to see how it behaves. If ok, I will
apply the Immutable Service Container construction kit to see if there
is any chan
And finally, I have had this script run on a real, OSOL build 127 box for a day
now.
can not reproduce it there either.
So I failed to reproduce this at all using the script on:
- ONNV 129 (zfs root, 1 cpu)
- ONNV 126 (ufs root, 2 cpus)
- OSOL 127 (zfs root, 4 cores)
there must be something sp
Glenn, I've not been able to reproduce this on onnv build 126 (it's running for
a day now)
if that script would reproduce 6894901 straight away it should be doing so
on 126 as well (similar to what you've seen in 127)
this pose the question if there are either some other details in your
environm
Glenn, I've been running this test case now for nearly a day on build 129,
could'nt
reproduce at all. good chance this being indeed fixed by 6894901 in build 128.
I'll also try to reproduce this now on buil 126.
cheers
frankB
On Fri, 11 Dec 2009 21:48:52 +0100, Glenn Brunette
wrote:
>
> As p
On Sat, 12 Dec 2009 10:06:43 +0100, Frank Batschulat (Home)
wrote:
> sounds somewhat similar to
>
> 6773836 zoneadm halt or halting/rebooting a non-global zone hangs the global
> zone
wrong cut+past I did ment to say:
6734679 zoneadm halt hung during zones test
> I'll try to reproduce this
sounds somewhat similar to
6773836 zoneadm halt or halting/rebooting a non-global zone hangs the global
zone
I'll try to reproduce this using your test case and see what I find. please
file a bug
if it's still happen with 128 and is not fixed by 6894901 as Steve suggested.
cheers
frankB
On
Steve,
Thanks for the ptr. Will give it a try!
g
On 12/11/09 5:59 PM, Steve Lawrence wrote:
Looks a lot like 6894901. Can you try build 128?
-Steve
On Fri, Dec 11, 2009 at 03:48:52PM -0500, Glenn Brunette wrote:
As part of some Immutable Service Container[1] demonstration that I am
cre
Looks a lot like 6894901. Can you try build 128?
-Steve
On Fri, Dec 11, 2009 at 03:48:52PM -0500, Glenn Brunette wrote:
>
> As part of some Immutable Service Container[1] demonstration that I am
> creating for an event in January. I have the need to start/stop a zone
> quite a few times (as par
As part of some Immutable Service Container[1] demonstration that I am
creating for an event in January. I have the need to start/stop a zone
quite a few times (as part of a Self-Cleansing[2] demo). During the
course of my testing, I have been able to repeatedly get zoneadm to
hang.
Since I am
19 matches
Mail list logo
