Konstantin Belousov wrote:
Log:
Add the devctl notifications for the cdev create/destroy events.
Very cool!
___
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTE
Andrew Thompson wrote:
thompsa 2007-12-05 01:22:03 UTC
FreeBSD src repository
Modified files:
sys/kern kern_conf.c
Log:
Apply a workaround for the unkillable jail problem where some devices created
within the jail are never freed. si_cred is only used by the MAC
On Thu, 19 Oct 2006, Giorgos Keramidas wrote:
FWIW, reverting revision 1.199 of kern_conf.c locally fixes the
unkillable xterms, stuck in "devdrn", problem.
With rev 1.199, modules that do destroy_dev() in their d_close() will
hang in "devdrn" state upon device closing. For example, netsmb a
Giorgos Keramidas writes:
> On 2006-10-19 02:49, Giorgos Keramidas <[EMAIL PROTECTED]> wrote:
> > Maybe it's not related, but all xterm's seem unkillable and blocked
> > forever in "devdrn" here, in a build from 2006.10.18.15.56.11.
> >
> > An earlier sync from 2006.10.13.12.45.54 didn't exhibit
On 2006-10-19 02:49, Giorgos Keramidas <[EMAIL PROTECTED]> wrote:
> Maybe it's not related, but all xterm's seem unkillable and blocked
> forever in "devdrn" here, in a build from 2006.10.18.15.56.11.
>
> An earlier sync from 2006.10.13.12.45.54 didn't exhibit this behavior,
> so I guess there's s
> FWIW, reverting revision 1.199 of kern_conf.c locally fixes the
> unkillable xterms, stuck in "devdrn", problem.
destroy_devl() is only stuck in "devdrn" if a thread has called dev_refthread()
but not yet called dev_relthread(). If that thread doesn't sleep forever then
it might write to freed
FWIW, reverting revision 1.199 of kern_conf.c locally fixes the
unkillable xterms, stuck in "devdrn", problem.
On 2006-10-19 02:49, Giorgos Keramidas <[EMAIL PROTECTED]> wrote:
>
> Maybe it's not related, but all xterm's seem unkillable and blocked
> forever in "devdrn" here, in a build from 2006.
Maybe it's not related, but all xterm's seem unkillable and blocked
forever in "devdrn" here, in a build from 2006.10.18.15.56.11.
An earlier sync from 2006.10.13.12.45.54 didn't exhibit this behavior,
so I guess there's something mildly buggy with this change?
On 2006-10-15 09:15, Martin Blapp <
Cool, thank you !
Martin
Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 61 826 93 00 Fax: +41 61 826 93 01
PGP:
PGP Fingerprint: B434 53FC C87
> This is quite likely to not happen without intervention. It might
> be a good idea to to deliver a signal to the process, if we can find it.
The process might have been woken but not yet scheduled due to the caller of
destroy_dev() having called something similar to the purge method before
cal
In message <[EMAIL PROTECTED]>, Tor Egge writes:
>tegge 2006-10-13 20:49:24 UTC
>
> FreeBSD src repository
>
> Modified files:
>sys/kern kern_conf.c
> Log:
> Wait for thread count to reach zero in destroy_devl() even when no purge
> method is defined, to avoid memory bei
On Fri, 13 Jan 2006 06:15, Joao Barros wrote:
> > This protects people from loading _really_ old modules, like say from
> > 5.x to a 6.x or 7.x system, like for instance right after an upgrade.
>
> Will this prevent loading an old nvidia module on boot after a kernel
> upgrade, which most times
On Thursday 12 January 2006 02:45 pm, Joao Barros wrote:
> On 1/12/06, Alfred Perlstein <[EMAIL PROTECTED]> wrote:
> > alfred 2006-01-12 19:15:14 UTC
> >
> > FreeBSD src repository
> >
> > Modified files:
> > sys/kern kern_conf.c
> > Log:
> > Novel idea, don't print a s
On 1/12/06, Alfred Perlstein <[EMAIL PROTECTED]> wrote:
> alfred 2006-01-12 19:15:14 UTC
>
> FreeBSD src repository
>
> Modified files:
> sys/kern kern_conf.c
> Log:
> Novel idea, don't print a string if it is NULL!
>
> This protects people from loading _really_ old m
14 matches
Mail list logo
