hmm.. ok, there are some subsystems using sbuf's:
linprocfs
procfs
pseudofs
I think someone may have broken something in pseudofs, procfs,
and/or linprocfs that is causing the VFS cache and sbuf MALLOC
area to run away.
Anybody have any ideas?
$BFMA3$N%a!<%k$r:9$7>e$2$?$3$H!"$4MF$BM-1W$J>&IJ$r$40FFb$7$^$9%a!<%k%^%,%8%s$rH/4)CW$7$F$*$j$^$9!#(B$B>&IJ>pJs$K6=L#$r$*;}$A$G$7$?$i!"@'Hs9XFI!JL5NA!K$r$*4j$$CW$7$^$9!#(B$BITI,MW$G$7$?$i!"$*$B>!
$B9XFIEPO?!!(Bhttp://www.ec-inter.com/mk/uef.html
$B%^%,%8%sG[?.$O!"=5#12s$G$9!#!!N
On Wed, Dec 19, 2001 at 12:02:49AM -0800, Matthew Dillon wrote:
> hmm.. ok, there are some subsystems using sbuf's:
>
> linprocfs
> procfs
> pseudofs
>
> I think someone may have broken something in pseudofs, procfs,
> and/or linprocfs that is causing the VFS cache
:> hmm.. ok, there are some subsystems using sbuf's:
:>=20
:> linprocfs
:> procfs
:> pseudofs
:>=20
:> I think someone may have broken something in pseudofs, procfs,
:> and/or linprocfs that is causing the VFS cache and sbuf MALLOC
:> area to run away.
:>=20
:>
On 19-Dec-01 Matthew Dillon wrote:
>
>:> hmm.. ok, there are some subsystems using sbuf's:
>:>=20
>:> linprocfs
>:> procfs
>:> pseudofs
>:>=20
>:> I think someone may have broken something in pseudofs, procfs,
>:> and/or linprocfs that is causing the VFS cache and sbuf MA
¾È³çÇϼ¼¿ä.
¸ÕÁ® ¿øÄ¡¾ÊÀº ¸ÞÀÏ º¸³½Á¡ »ç°úµå¸³´Ï´Ù.
º» ¸ÞÀÏÀº Á¤º¸Åë½Å À±¸®À§¿øȸ¿¡ Áöħ¿¡ µû¶ó ¼ºÀα¤°í¸ÞÀÏÀÓÀ» ¾Ë·Áµå¸³´Ï´Ù.
º» ¸ÞÀÏÀº ¼ö½Å°ÅºÎ¿¡ µî·ÏÇØ ÁÖ½Ã¸é ´Ù½Ã´Â ¹ÞÁö ¾ÊÀ¸½Ç °Ì´Ï´Ù.
http://24sextv.wo.to ·Î
¿Íº¸¼¼¿ä.
Àý´ë ¼ºÀθ¸ ¿À¼Å¾ß ÇÕ´Ï´Ù.
[¼ö½Å°ÅºÎ]
To Unsubscribe: send
:> The structure is being bzero()'d before its dynamic flag gets checked.
:> I've included a patch below. Josef, I would appreciate it if you would
:> apply the patch and try your system with the various procfs devices
:> mounted again. It's an obvious bug so I'm comitting it to
On Wed, Dec 19, 2001 at 11:05:22AM -0800, Matthew Dillon wrote:
>
> The structure is being bzero()'d before its dynamic flag gets checked.
> I've included a patch below. Josef, I would appreciate it if you would
> apply the patch and try your system with the various procfs devices
>
On 19-Dec-01 Matthew Dillon wrote:
>:> The structure is being bzero()'d before its dynamic flag gets checked.
>:> I've included a patch below. Josef, I would appreciate it if you would
>:> apply the patch and try your system with the various procfs devices
>:> mounted again. It'
libc_r seems to be broke on alpha and I'm trying to fix it.
We munge jmp_bufs to create new contexts for threads and for
the thread scheduler. It seems that sometime over the last
few weeks/months something broke that. It doesn't look like
_setjmp of _longjmp have changed at all, though.
Includ
mail dumps core on current with latest /usr/src/usr.bin/mail updates:
(root)502}mail manfred
Subject: test
test
test
EOT
Segmentation fault (core dumped)
(root)503}
This is from a current built today, although i think the changes were
made yesterday. I noticed that I did not get mail from the da
Does anyone know when installation of -CURRENT from CD-ROM got broken or a
solution thereof? We end up having two problems: the fixit shell doesn't
work, but before that an actual installation doesn't work because
sysinstall's attempt to mount /dev/acd0c on /dist returns ENOENT. I havne't
de
>Date: Wed, 19 Dec 2001 14:07:28 -0800
>From: Manfred Antar <[EMAIL PROTECTED]>
>mail dumps core on current with latest /usr/src/usr.bin/mail updates:
Yeah; I was able to reproduce that result.
I then re-made mail, this time with the -g flag, and tried again;
problem is detected in fixhead() (s
I'm seeing a lot of this during heavy disk I/O (5 postmark benchmarks
running in parallel):
microuptime() went backwards (44525.3954411 -> 44524.563978)
microuptime() went backwards (57425.4282241 -> 57424.766121)
microuptime() went backwards (57425.4282241 -> 57424.845844)
microuptime()
On Wed, 19 Dec 2001, Matthew Dillon wrote:
> I'm seeing a lot of this during heavy disk I/O (5 postmark benchmarks
> running in parallel):
>
> microuptime() went backwards (44525.3954411 -> 44524.563978)
> microuptime() went backwards (57425.4282241 -> 57424.766121)
> microuptime() went b
Really easy to reproduce.
ls -lR /proc
vmstat -m | fgrep vfscache
ls -lR /proc
vmstat -m | fgrep vfscache
ls -lR /proc
vmstat -m | fgrep vfscache
The pseudofs code is using the wrong VOP descriptor, but I'll let DES
fix it when he gets back. In the mean time
:This has been asked on just about every FreeBSD list since the printf was
:added. Use the archives, man! :)
:
:This is when you have a device generating too much interrupt latency --
:enough to stall the RTC. Usually the offender is video cards, but in this
:case it could be your IDE controlle
I've been seeing them a lot too on a "recent" (NOV) -current
On Wed, 19 Dec 2001, Matthew Dillon wrote:
> I'm seeing a lot of this during heavy disk I/O (5 postmark benchmarks
> running in parallel):
>
> microuptime() went backwards (44525.3954411 -> 44524.563978)
> microuptime() went
On 19-Dec-2001 Manfred Antar wrote:
| mail dumps core on current with latest /usr/src/usr.bin/mail updates:
|
Argh, I forgot braces around a 'for' loop. This has been fixed by Andrey in
rev. 1.12 of send.c.
Mike
--
Mike Heffner
Blacksburg, VA <[EMAIL PROTECTED]>
msg33139
I'm getting the following error when running 'make buildworld'
perl
-I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/des/asm:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/perlasm
/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/bf/asm/bf-586.pl
elf 386 > b
subscribe freebsd-current
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
21 matches
Mail list logo