> >> Wait - if it returns EAGAIN for a while, then look at that code above.
> >> It will hold the sysctl lock for some indefinite amount of time. Maybe
> >> it should look like this instead:
> >>
> >>
> >>do {
> >>SYSCTL_LOCK();
> >>req.oldidx = 0;
> >>req.newidx =
- Original Message -
From: "Steven Hartland" <[EMAIL PROTECTED]>
- Original Message -
From: "Eric Anderson" <[EMAIL PROTECTED]>
Wait - if it returns EAGAIN for a while, then look at that code above.
It will hold the sysctl lock for some indefinite amount of time. Maybe
it
- Original Message -
From: "Eric Anderson" <[EMAIL PROTECTED]>
Wait - if it returns EAGAIN for a while, then look at that code above.
It will hold the sysctl lock for some indefinite amount of time. Maybe
it should look like this instead:
do {
SYSCTL_LOCK();
req.oldi
- Original Message -
From: "Ivan Voras" <[EMAIL PROTECTED]>
...
geom debugging I get:-
Feb 1 06:04:45 geomtest kernel: g_post_event_x(0x802394c0,
0xff00010e6100, 2, 0)
Feb 1 06:04:45 geomtest kernel: ref 0xff00010e6100
Feb 1 06:04:45 geomtest kernel: g_post_event_x(0xf
Steven Hartland wrote:
- Original Message - From: "Eric Anderson" <[EMAIL PROTECTED]>
I saw this once before, a long time back, and every time I went
through a debugging session, it came to some kind of lock on the
sysctl tree with regards to the geom info (maybe the XML kind of tree
Steven Hartland wrote:
> Yep thats where I've traced it to its requesting: kern.geom.confxml
>
> Which does:-
> static int
> sysctl_kern_geom_confxml(SYSCTL_HANDLER_ARGS)
> {
>int error;
>struct sbuf *sb;
>
>sb = sbuf_new(NULL, NULL, 0, SBUF_AUTOEXTEND);
>g_waitfor_event(g_confxm
- Original Message -
From: "Eric Anderson" <[EMAIL PROTECTED]>
I saw this once before, a long time back, and every time I went through a debugging session, it came to some kind of lock on the
sysctl tree with regards to the geom info (maybe the XML kind of tree dump or something). I
Dieter wrote:
What *exactly* do you mean by
machine still locks up with no activity for anywhere from 20 to 30 seconds.
Is there disk activity? (e.g. activity light(s) flashing if you have them)
Cant tell if there is disk activity its in a DC miles away ;)
Does top continue to update the sc
> > What *exactly* do you mean by
> >
> >> machine still locks up with no activity for anywhere from 20 to 30 seconds.
> >
> > Is there disk activity? (e.g. activity light(s) flashing if you have them)
>
> Cant tell if there is disk activity its in a DC miles away ;)
>
> > Does top continue to
- Original Message -
From: "Dieter" <[EMAIL PROTECTED]>
What *exactly* do you mean by
machine still locks up with no activity for anywhere from 20 to 30 seconds.
Is there disk activity? (e.g. activity light(s) flashing if you have them)
Cant tell if there is disk activity its in a
In message <[EMAIL PROTECTED]>, "Steven Hartland" writes:
> From: "Ivan Voras" <[EMAIL PROTECTED]>
> >> The machine is running with ULE on 7.0 as mention using an Areca 1220
> >> controller over 8 disks in RAID 6 + Hotspare.
> >
> > I'd suggest you first try to reproduce the stall without ULE, wh
- Original Message -
From: "Ivan Voras" <[EMAIL PROTECTED]>
The machine is running with ULE on 7.0 as mention using an Areca 1220
controller over 8 disks in RAID 6 + Hotspare.
I'd suggest you first try to reproduce the stall without ULE, while
keeping all other parameters exactly the
- Original Message -
From: "Ivan Voras" <[EMAIL PROTECTED]>
Steven Hartland wrote:
The machine is running with ULE on 7.0 as mention using an Areca 1220
controller over 8 disks in RAID 6 + Hotspare.
I'd suggest you first try to reproduce the stall without ULE, while
keeping all oth
Steven Hartland wrote:
> The machine is running with ULE on 7.0 as mention using an Areca 1220
> controller over 8 disks in RAID 6 + Hotspare.
I'd suggest you first try to reproduce the stall without ULE, while
keeping all other parameters exactly the same.
__
14 matches
Mail list logo
