I'm curious what the long-term plan is for witness(4). For
example, it complains about BPF and device locks being reversed
when BPF takes the device out of promiscuous mode --
lock order reversal
1st 0xc04c1560 bpf global lock @ /usr/src/sys/net/bpf.c:365
2nd 0xc1302b88 dc1 @ /usr/src/sys/pci
Hi All,
For a while now (July 12 first noticed) I've been experiencing a
intermittent panic on a non-recursive lock. Whilst I can grab the panic,
savecore panics again writing it. It seems to occur only under heavy disk
io and hence a make install of XFree86 causes the condition (not alway
===> usr.sbin/pcvt/vttest
cc -O -pipe -march=k6 -traditional -DUSEMYSTTY -I/usr/obj/usr/src/i386/usr/include
-c /usr/src/usr.sbin/pcvt/vttest/main.c
/usr/src/usr.sbin/pcvt/vttest/main.c: In function `readnl':
/usr/src/usr.sbin/pcvt/vttest/main.c:1942: `STDIN_FILENO' undeclared (first use in
t
On Fri, 27 Jul 2001 [EMAIL PROTECTED] wrote:
> either of the following works. the other configurations are now
> considered ambiguous. (the point is, if you specify prefixlen < 128
> you don't need to say the peer's address)
>
> # ifconfig inet6 A prefixlen X (X can be
>When I compiled/installed -current, and started setting things up again, I
>noticed that gif devices now expect IPv6 prefix lengths of 128. Most
>providers use 127, and some even use 64 as prefix lengths for tunnels. I
>was just curious why the change was made to only support prefix lengths of
When I compiled/installed -current, and started setting things up again, I
noticed that gif devices now expect IPv6 prefix lengths of 128. Most
providers use 127, and some even use 64 as prefix lengths for tunnels. I
was just curious why the change was made to only support prefix lengths of
128.
In message <[EMAIL PROTECTED]>, Michael Harnois writes:
>
>The only result it generated was
>
>/usr/home/mdharnois off 120 ino 0 reclen 0x188 type 010 namelen 14 name '.fetc
>hmail.pid' [368]
>
>and that file is destroted and recreated every couple of minutes.
It's the directory (/usr/home/mdharn
I remember getting mails about my driver before, so it's ok. Basically,
whenever bsd.kmod.mk is broken, my module (being the first in the list),
is always where the error pops up. I'll take a look at it, but you shouldn't
be using it on -stable. It is only guaranteed to work on -current, in fact,
On Thu, 26 Jul 2001 15:14:09 +0100, Ian Dowse <[EMAIL PROTECTED]> said:
> That should show up any directories that would fail that dirhash
> sanity check - there will probably just be one or two that
> resulted from some old filesystem corruption.
The only result it generated was
/u
In message <[EMAIL PROTECTED]> David Malone writes:
: Or don't work as the case may be ;-) Posix doesn't actually require
: select to be able to deal with large wait times (I think 31 days was
: the figure I found in the SUSv2 spec). Have a look at:
31 days, interestingly enough, is very close to
On 24-Jul-01 Mike Smith wrote:
>
> There is a bug in the Intel ACPI CA code which will cause your system to
> power off upon waking from suspend mode. Iwasaki-san tracked it down and
> posted a fix to the acpi-jp list (message 1186) for folks that want to
> patch locally.
>
> Intel have ado
In message <[EMAIL PROTECTED]>, Michael Harnois writes:
>I'm tearing my hair out trying to find a filesystem error that's
>causing me a panic: ufsdirhash_checkblock: bad dir inode.
>
>When I run fsck from a single user boot, it finds no errors.
>
>When I run it on the same filesystem mounted, it f
>
> On Wed, Jul 25, 2001 at 02:12:06PM +0300, Maxim Sobolev wrote:
> > I found that the attached small program behaves very strangely when
> > linked with -pthread - it chews 100% CPU cycles while waiting in
> > select(2). This misbehaviour observed both on 5-CURRENT and 4-STABLE
> > systems. *we
On Wed, Jul 25, 2001 at 02:12:06PM +0300, Maxim Sobolev wrote:
> I found that the attached small program behaves very strangely when
> linked with -pthread - it chews 100% CPU cycles while waiting in
> select(2). This misbehaviour observed both on 5-CURRENT and 4-STABLE
> systems. *weird*
The tim
> It is much easier, at least to me, to just remove much of the KLD
> screen saver support from syscons to the user-land, than to utilize
> the kthread :-)
Just FWIW, I think that moving the screen saver to userspace is an
excellent thing to do.
--
... every activity meets with opposition, eve
There is a bug in the Intel ACPI CA code which will cause your system to
power off upon waking from suspend mode. Iwasaki-san tracked it down and
posted a fix to the acpi-jp list (message 1186) for folks that want to
patch locally.
Intel have adopted the patch, and the next update will fix t
Hi,
I found that the attached small program behaves very strangely when
linked with -pthread - it chews 100% CPU cycles while waiting in
select(2). This misbehaviour observed both on 5-CURRENT and 4-STABLE
systems. *weird*
-Maxim
P.S. And yes, I know that I ought to use NULL instead of &tv when
On Wed, 25 Jul 2001 19:20:45 MST, Kris Kennaway wrote:
> Isn't this backwards? Code shouldn't be making assumptions about the
> special meaning of numeric gids. What if you wanted to renumber gid
> wheel to something else?
So? My primary group is 0. In /etc/group, group wheel's numeric val
>You can stick the screen saver in a low priority kthread and achieve the same
>effect.
As the screen saver accesses and uses syscons' internal structures and
facilities, its operation must be carefully coordinated with syscons.
Thus, putting the screen saver in a kthread will require major
restr
19 matches
Mail list logo
