Pawel Jakub Dawidek wrote:
> On Mon, Sep 01, 2003 at 12:48:41AM -0600, Kenneth D. Merry wrote:
> +> - I tried just holding a mutex all the time, but obviously you can't
> +>malloc while holding a mutex (except Giant), and the sysctl code does a
> +>number of mallocs. (The original cause o
On Mon, Sep 01, 2003 at 12:48:41AM -0600, Kenneth D. Merry wrote:
+> - I tried just holding a mutex all the time, but obviously you can't
+>malloc while holding a mutex (except Giant), and the sysctl code does a
+>number of mallocs. (The original cause of this problem -- M_WAITOK
+>ma
In message <[EMAIL PROTECTED]>, "Kenneth D. Merry" writes:
>In particular, I went through some interesting permutations in
>taskqueue_kthread() to make things work right:
>
> - I tried holding Giant when calling tsleep, but it complained that I
> didn't own Giant.
I have had a similar issue a c
On Mon, Sep 01, 2003 at 02:23:18 +0200, Pawel Jakub Dawidek wrote:
> On Mon, Sep 01, 2003 at 02:13:45AM +0200, Pawel Jakub Dawidek wrote:
> +> I was getting same panics while I was working on GEOM Gate.
> +> After many hours of debugging I've tracked this down - I've initialized
> +> a mutex, but I
On Sun, Aug 31, 2003 at 12:52:47 +0200, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, "Kenneth D. Merry" writes:
>
> >Anyway, I got some debugging output, and I've attached dmesg output. Let
> >me know whether anything in there looks suspicious or points to a possible
> >problem.
>
On Mon, Sep 01, 2003 at 02:13:45AM +0200, Pawel Jakub Dawidek wrote:
+> I was getting same panics while I was working on GEOM Gate.
+> After many hours of debugging I've tracked this down - I've initialized
+> a mutex, but I haven't destroy it.
+>
+> As I susspect you're loading cd(4) as kld modul
On Fri, Aug 29, 2003 at 10:03:57PM -0600, Kenneth D. Merry wrote:
+> I've been working on a set of patches to remove the sysctl variable creation
+> from interrupt context in the cd(4) and da(4) drivers.
+>
+> To fix the problem, I've created a new taskqueue that runs in a thread
+> context, inste
In message <[EMAIL PROTECTED]>, "Kenneth D. Merry" writes:
>Anyway, I got some debugging output, and I've attached dmesg output. Let
>me know whether anything in there looks suspicious or points to a possible
>problem.
There's nothing which jumps out at me, and I guess the best strategy is
hunti
On Sat, Aug 30, 2003 at 09:22:10 +0200, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, "Kenneth D. Merry" writes:
>
> >I think I have everything setup correctly, but I keep getting panics inside
> >the GEOM code with these patches. (Memory modified after free.) I don't
> >know whethe
In message <[EMAIL PROTECTED]>, "Kenneth D. Merry" writes:
>I think I have everything setup correctly, but I keep getting panics inside
>the GEOM code with these patches. (Memory modified after free.) I don't
>know whether I've just exposed some race condition, or whether I've done
>something wr
I've been working on a set of patches to remove the sysctl variable creation
from interrupt context in the cd(4) and da(4) drivers.
To fix the problem, I've created a new taskqueue that runs in a thread
context, instead of inside a software interrupt like the current task
queues. (The eventual f
11 matches
Mail list logo