Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 27 Nov 2003 08:56:44 +0100
From:      "Daan Vreeken [PA4DAN]" <Danovitsch@Vitsch.net>
To:        Jay Cornwall <jay@evilrealms.net>
Cc:        FreeBSD-current@FreeBSD.org
Subject:   Re: Panic with ugen
Message-ID:  <200311270856.44214.Danovitsch@Vitsch.net>
In-Reply-To: <3FC54095.6030209@evilrealms.net>
References:  <1069874342.704.18.camel@klotz.local> <1069888991.2521.7.camel@klotz.local> <3FC54095.6030209@evilrealms.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 27 November 2003 01:08, Jay Cornwall wrote:
> > It looks like this:
> >
> > panic()
> > destroy_dev()
> > ugen_destroy_devnodes()
> > ugen_set_config()
>
> Yes, that's the one, and I think I can see why. The existing code fixed
> devfs problems for normal ugen_set_config calls, but doesn't account fo=
r
> what happens when an error occurs (which is presumably happening in you=
r
> example program, as you said it gives an error the first time round) - =
the
> devfs stuff only half completes.
>
> (actually, looking at that error handling code, it doesn't look like it=
's
> been thought through well anyway - /* XXX should only do this after set=
ting
> new altno has succeeded */ - maybe time to clean this code up?)
>
> After the device endpoints are destroyed (sys/dev/ugen.c:1038), the ret=
urns
> on lines 1055 and 1058 need to be covered by a devnode recovery procedu=
re -
> particularly tricky given we just wiped the endpoint descriptors clean.
>
> I'll look at restructuring this code tomorrow, if Bernd doesn't beat me=
 to
> it.
If you have time left, could you perhaps also have a look at kern/51186?
I have filed it back in March and it's still open. (Fixes a memory corrup=
tion=20
bug in ugen).

grtz,
Daan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200311270856.44214.Danovitsch>