cted crashes at boot time. This will
give us time to come up with a more permanent solution.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
cards cannot DMA beyond 4GB. We would avoid these
issues as well by only using the memory as physical backing store
for SysV shared memory segments.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
GB worth of swap-meta supported VM may wind
up only being 15GB of actually-swapped-out-dat in reallity. It
depends very heavily on the applications being run.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
release. I did some simple testing under -stable, including bumping up
maxusers and NMBCLUSTERS.
-Matt
Index: conf/options
===
RCS file: /home/ncvs/src/sys/conf/options,v
the file explicitly, the dirty data
might not be written out for days. It might look good in a benchmark,
but it would play havoc on system stability in the event of a crash.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsub
(). But simplelock()'s cannot survive
context switches so the caller must pass the simplelock to lockmgr()
so lockmgr() can release it temporarily when it decides it needs to
block. Weird, but it works.
-Matt
To Unsubscribe: send mail to
:Matt
:
:Ok I see..the interlock is a lock on a collection (e.g
:on vfs mount list) and it can be released once the simple
:lock within the to-be-locked object has been acquired.
:These are really spin locks, now that I saw simplelock.s
:
:One more clarification if you will.. :-)
:
:What is the
This gets an 'A' on my cool-o-meter.
http://www.vnunet.com/News/1124839
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
:
:* Matt Dillon <[EMAIL PROTECTED]> [010822 18:30] wrote:
:> This gets an 'A' on my cool-o-meter.
:>
:> http://www.vnunet.com/News/1124839
:
:Interesting, I guess one could work around it by periodically
:sending bogus empty packets in the middle of activity.
MAP_INHERIT is broken and always has been.
-Matt
:exec gives you an new vm space..
:inherrit only applies to forks
:
:
:On Thu, 23 Aug 2001, Alfred Perlstein wrote:
:
:> * Bernd Walter <[EMAIL PROTECTED]> [010823 06:16] wrote:
:> > I d
vid Greenman
Yah, I agree. Even if we implemented it it would be a massive security
hole. a MAP_SHARED mmap() is easier.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
ficient if APTDpde gets ripped
out from under the loop. Is this race real or am I blowing smoke?
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
gain..
Hmm. Ok, I think you are right. APTDpde is what is being loaded
and that points into the user page table directory page, which is
per-process. So APTDpde should be per-process.
-Matt
To Unsubscribe: send mail to [EMAIL
.
-Matt
cc -S -O -fomit-frame-pointer -mpreferred-stack-boundary=2 x.c
printasint:
pushl 4(%esp)
pushl $.LC0
call printf
addl $8,%esp
ret
cc -S -fomit-frame-pointer -mpreferred-stack-boundary=2 x.c
printasint:
movl 4(%esp),%eax
PROTECTED]; [EMAIL PROTECTED]
Oh !@#$#@$.. you're right! That means there *IS* a race, just that it
is a race in the case where you use rfork. APTDpde can be ripped out
from under one thread by another thread.
-Matt
To Unsubscribe
didn't have to do anything.
You can imagine the result!
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
You need to tune kern.ipc.maxsockbuf. I normally use 2097152 for the ti
gigabit cards.
Thanks,
Matt Ayres
On Tue, 28 Aug 2001, Deepak Jain wrote:
>
>
> -Original Message-
> From: Deepak Jain [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 27, 2001 7:04 PM
> To:
:In article <[EMAIL PROTECTED]>,
:John Baldwin <[EMAIL PROTECTED]> wrote:
:>
:> Looks good to me, but I'm only somewhat familiar with libstand. :)
:
:Thanks for taking a look at it. Matt Dillon also reviewed it and gave
:it a clean bill of health. He made a suggestio
*just* as sshd is trying to free() something.
-Matt
(gdb) back
#0 0x28231e34 in kill () from /usr/lib/libc.so.4
#1 0x2826dd8a in abort () from /usr/lib/libc.so.4
#2 0x2826c899 in isatty () from /usr/lib/libc.so.4
#3 0x2826c8cf in isatty () from /
I looked at the code and there is definitely a serious issue. This
proposed patch should solve the problem. Here it is for review before
I commit it and send a bug report off to the openssh folks. I am testing
it now.
-Matt
:
:* Matt Dillon <[EMAIL PROTECTED]> [010917 15:32] wrote:
:> sshd died on one of our machines today. The traceback seems to
:> indicate that a signal is interrupting a free(). I'm going to
:> play with the code a bit to see if there's an easy fix.
:>
I forwarded the whole thing to Brian. We'll wait to see what he decides
to do. Obviously a fix like this needs to go, it's just a matter of who,
how, and when.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with &q
Les Biffle wrote:
> > pkt.ipbit.ip_sum=in_cksum((unsigned short*)(void*)&pkt,20);
> > pkt.tcpbit.th_sum=tcpsum(&pkt.ipbit);
>
> You need to do the TCP checksum first. It changes the payload (the TCP
> checksum). The IP checksum includes all data, so must be done after the
> payloa
come to think of it... perhaps you are not calculating the tcp checksum
correctly because of the tcp/ip pseudo header. i no longer have the code that
was posted, but thinking back i believe this might be the case.
Matt Finlay wrote:
> Les Biffle wrote:
>
> > > pkt.ipbit.
Mario Sergio Fujikawa Ferreira wrote:
> Hi,
>
> While working on a make .mk code, I and Chris Wasser (TDF
> on IRC) came across an interesting behavior:
>
> sh -c 'TDF="echo a && echo b";for i in `${TDF}`; do echo "i:$i"; done'
>
i do not believe this is a bug... it is the way the bash
a complete scan of the namei cache!
-Matt
Index: kern/vfs_cache.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_cache.c,v
retrieving revision 1.61
diff -u -r1.61 vfs_cache.c
--- kern/vfs_cache.c2001/09/12 08:
;.
I'm setting up a postfix test too. As far as I can tell, my changes
have had no effect on namei cache efficiency other then eating less cpu.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
nearby VM pages in idle VM objects, getting them cleared out more
quickly and allowing their vnodes to be reused without compromising
the VM system's excellent page selection code. At least then it would
truely take a million 'small' files to create an issue.
(Poul's work). Inevitably we will have to manage device-based I/O
on a page-by-page basis and being able to do it via a VM Object seems
to fit the bill in my opinion.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
:>Well, this has turned into a rather sticky little problem. I've
:>spent all day going through the vnode/name-cache reclaim code, looking
:>both at Seigo's cache_purgeleafdirs() and my own patch.
:
: Can you forward me your patch? I'd like to try it out on some machines in
:the TS
cache at the filesystem level. Or something
like that.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
up the vnode/inode malloc space.
I'll run some buildworld tests tomorrow. Er, later today.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
se I/O
significantly.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
y can be up to 8:1 (4096/512),
this factor is somewhat deceptive in regards to the actual effect on
the system.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Here is the latest patch for -stable. vmiodirenable is turned on by
default, the cache purge code is enabled based on vmiodirenable, and
I added a new sysctl called nameileafonly which defaults to ON (1).
nameileafonly vmiodirenable action
1 1 (DEFAULT
Here is the latest patch for -current. vmiodirenable is turned on by
default, the cache purge code is enabled based on vmiodirenable, and
I added a new sysctl called nameileafonly which defaults to ON (1).
The old cache_purgeleafdirs() stuff is #if 0'd out.
nameileafonly vmio
eclaim
: -1 0 puger any dir on vnode reclaim
Correction.
-1 any do NOT purge dirs on vnode reclaim
Sorry for the mixup.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscr
is to take very long.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
I got the cache_leaf_test() return values backwards. But that's ok,
because my cache_leaf_test() if() statement is also backwards :-). I'll
turn them around in a later patch set.
-Matt
To Unsubscribe: send mail to [EMAIL
header file. These are rcs id's, so it should be something like
__FBSDID() or __FBSD_ID() or something like that, not just __FBSD().
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
at it doesn't matter what we do
with the namei cache. vmiodirenable is the only thing that really makes
a difference. I expect we will see more differentiation in the 128M
tests.
-Matt
WIDE TERMINAL WINDO
ks I will rip-out nameileafonly and cache_leaf_test().
-Matt
WIDE TERMINAL WINDOW REQUIRED!
---
TES
:
:In message <[EMAIL PROTECTED]>, Matt Dillon writes:
:>
:>$8 = 58630
:>(kgdb) print vm_page_buckets[$8]
:
:What is vm_page_hash_mask? The chunk of memory you printed out below
:looks alright; it is consistent with vm_page_array == 0xc051c000. Is
:it just the vm_page_buckets[]
if they are related? Stack overflows could result
:in corruption of local variables, after which anything could happen.
:
:That said, hardware problems are still a possiblilty.
:
:Ian
Hmm. Do we have a guard page at the base of the per process kernel
stack?
e bit errors then anything else. Either
the memory is bad or something in our kernel is setting or clearing flags
through a bad pointer.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
:In message <[EMAIL PROTECTED]>, Matt Dillon writes:
:>
:>Hmm. Do we have a guard page at the base of the per process kernel
:>stack?
:
:As I understand it, no. In RELENG_4 there are UPAGES (== 2 on i386)
:pages of per-process kernel state at p->p_addr. The stack grows
:
:In message <[EMAIL PROTECTED]>, Matt Dillon writes:
:>
:>Hmm. Do we have a guard page at the base of the per process kernel
:>stack?
:
:As I understand it, no. In RELENG_4 there are UPAGES (== 2 on i386)
:pages of per-process kernel state at p->p_addr. The stack gr
to try to cover the problem areas. I'm not sure
how Pentium III's and IV's are setup.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
further but this is very odd. Am I missing something
about the UAREA?
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
ing up. That's too close.
note the 3984 that came up after playing with the system for a few
seconds!
I'll post the patch set to use to test this stuff in a moment.
-Matt
process 323 exit kstackuse 2272
...
process 333 exit kstack
ic,
so for a fun time you can leave UPAGES at 2 and watch in horror.
note: make sure you make depend before making a new kernel, or use
buildkernel.
-Matt
Index: sys/user.h
===
:
:Matt Dillon wrote:
:> This isn't perfect but it should be a good start in regards to
:> testing kstack use. This patch is against -stable. It reports
:> kernel stack use on process exit and will generate a 'Kernel stack
:> underflow' message if i
:stack size = 4688
Sep 24 22:47:22 test1 /kernel: process 29144 exit kstackuse 4496
closer... :-)
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
rrent),
:ensuring that something like getpid couldn't stomp on the vm structures
:w/o first doing a splvm().
Kinda sounds like Multics :-)... no, it would be too messy trying
to protect kernel structures in one subsystem from another.
-Matt
To U
x27;t notice it.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
:So, Matt, does this solve the original question? (VM Corruption) or
:is it just a fruitful red-herring?
:--
:++ __ _ __
:| __--_|\ Julian Elischer | \ U \/ / hard at work in
It seems unlikely to me, but you never know
used.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
ith less than 64MB of RAM,
:# on machines with more than 64MB it can provide a
:# substantial benefit related to directory caching.
:
:That was what I read and confused me ;)
Yah. That isn't correct any more.
) and file per process.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
:
:In message <[EMAIL PROTECTED]>, Matt Dillon writes:
:>: Second, application not always grows to 1G, most of the time it keeps
:>: as small as 500M ;). Why should we precommit 1G for 500M data? Doing
:>: multi-mmap memory management is additional pain.
:>
:>Even usi
he Intel derivatives are going to be much, much cheaper... $2 or $3
for an MCU that does what you want and extremely easy to program. Look
at the MCS51 and MCS96 series. Note that there are dozens of manfacturers
of Intel-style controllers.
lly guarentee massive
fragmentation.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
I recommend using cpdup ( /usr/ports/sysutils/cpdup ), mainly because
you can ^C it and restart it at any time so it's a lot easier to
play around with your directory dup'ing.
-Matt
To Unsubscribe: send mail to [EMAIL PROTE
This patch set does not yet include fixes to unionfs or the nfs server
and is for informational purposes only. Comments?
-Matt
Index: kern/vfs_lookup.c
===
RCS file: /home
* Tested for collision probability. Answer: Very low even when
one tries on purpose. There is no need to implement a more
sophisticated fine-grained tsleep.
-Matt
Index: kern/vfs_
:
:Matt Dillon wrote:
:> Here is the latest patch I have. It appears to completely solve the
:> problem. I have shims in unionfs and nfs for the moment.
:
:This seems rather large compared to Ian Dowse's version.. Are you sure that
:you're doing this the right way? Ad
V shared memory (kern.ipc.shm_use_phys=1)
then any shm segments you allocate (see manual pages for
shmctl, shmget, and shmat) will reside in unswappable shared memory.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
another process...
for example, a process doing an (unrelated) rename in the reverse
direction.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
nks,
:
:-Zhihui
I don't know the answer to this at the moment.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
;m not sure why v_interlock even exists
in -stable.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
andard
commit-to-current-wait-commit-to-stable sequence. But due to the
complexity of the changes (even after simplifying them), it is going to
be another few days before anything gets into -stable officially.
-Matt
To Unsubscribe:
stening on the socket...
probably an older named that you missed, or perhaps the other named
simply wasn't exiting quickly enough before you started the new one.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hac
le (object->paging_in_progress)
:+ vm_object_pip_sleep(object, "vnvlbv");
: }
:
: splx(s);
Hey Douglas, try the patch fragment below and see if you can reproduce the
problem.
-Matt
@@ -721,10 +746,21 @@
}
ta. Problem solved.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
ught to be easy to track down. I am somewhat skeptical that
vmiodirenable could cause that but I suppose it's possible.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
t the file mtime
has been changed by someone else (ugly ugly ugly). So this sort of
crash can occur if one client is mmap()ing a file another another
client (or the server) writes to the file.
-Matt
:I recently mentioned on freebsd-stab
tterly
trivial and I will commit it after I test it.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
r friends your messy room! (read: I haven't
been keeping it cleaned up.) 8-|
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
a more elegant manner that I can do this
completely in modules.
Thank-you,
Matt
--
Matt Busigin - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
:
:On Tue, 2 Oct 2001, Matt Dillon wrote:
:
:>
:> :
:> :Dwayne wrote:
:> :> I'm creating an app where I want to use memory to store data so I
:> :> can get at it quickly. The problem is, I can't afford the delays that
:> :> would occur if the memory
uple of weeks ago,
though you provide a great deal more information. I'll take a look
at it (if others have a patch and want to jump in, then by all means
post away!).
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsu
vm_map_pageable() in
contigmalloc1() but it crashed the machine, so there might be something
else going on as well.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
x27;t understand the ramifications in 4.x.
This seems very reasonable to me... a nice quick and easy solution.
-Matt
:my fix (a reversion in part) is as follows:
:
:Index: kernel.h
:===
:RCS
t it a bit.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
other sites are
saturated with high quality, barely used hardware.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
ers.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
do BGP for you.
IMHO.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
contiguous space,
so the case is not supposed to come up. Of course, that means that it
does come up from time to time :-(.
If you want to have a go at fixing it I will be happy to review.
-Matt
To Unsubscribe: send mail to [EMAIL PROTE
that aren't always obvious or consistent.
thanks,
matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Does FreeBSD support the new 64 bit AMD Opteron? I am thinking about
having a dual processor opteron system built, can i stay with freebsd?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send a
libdata /usr/share /usr/local /var/db
>do
>mv ${D} ${D}5
>mv ${D}4 {D}
>done
>
> 9. Reboot and hope 4.8 will load and run.
>
> I attached some local outputs to check for unexpectedness.
>
>
> -netch-
This is probably obvious, but whatever yo
Howdy,
Would it be possible to add disk percentage support in the sysinstall
slice editor? That is, instead of building slice based on a fixed size
(ie: 5Gb) use percentage of the total disk size (ie: 25%). I ask this
for automated PXE installs using unknown hard drive/compantflash sizes.
__
On Wed, Oct 29, 2003 at 3:01 AM, Andreas Klemm wrote:
> Is there a freebsd tool that shows you in realtime, which users
> are logged in from remote using which pty port ?
>
> So to say something like
> while true
> do
> clear; w; sleep 10
> done
>
> Preferable as X11 application.
>
The closest th
DP83820/1 10/100/1000 Gigabit Ethernet Adapter'
class= network
subclass = ethernet
Is there some PCI conflict I'm or some other dumb thing I'm missing
here? if_nge.c looks perfectly happy with a DP83820.
Am I nuts?
-Matt
Copyright (c) 1992-2002 The FreeBSD Project.
e loopback interface:
host - lo0 = 127.0.0.1
127.0.0.2
.
On each of the loopback addresses I have a DNS server listening. This part works just fine:
matt@matt: {101} % dig www.foo.com @127.0.0.2
;; ANSWER SECTION:
www.foo.com.1D IN A 207.89.154.94
What I want to be
My apologies,
I didn't realize the default format on my new client was rich text
format.
Matt
On Thursday, April 11, 2002, at 01:17 PM, Asenchi wrote:
> could you please not send emails to the list in html. thank you.
> asenchi.
To Unsubscribe: send mail to [EMAIL PROT
e loopback interface:
host - lo0 = 127.0.0.1
127.0.0.2
.
On each of the loopback addresses I have a DNS server listening. This part works just fine:
matt@matt: {101} % dig www.foo.com @127.0.0.2
;; ANSWER SECTION:
www.foo.com.1D IN A 207.89.154.94
What I want to be abl
51 55
ipfw add fwd 127.0.0.2,53 tcp from any to 192.168.7.251 55
matt# ipfw show
00100 4 228 fwd 127.0.0.2,53 udp from any to 192.168.7.251 55
00200 00 fwd 127.0.0.2,53 tcp from any to
192.168.7.251 55
65535 528096 456266843 allow ip from any to any
(I use DEFAULT_TO_A
er,
since it's on loopback I can't query it directly unless I'm on the box.
So, I'm fishing for a clean way to test each VIP on each server remotely.
Matt
> On Friday, April 12, 2002, at 02:01 AM, Crist J. Clark wrote:
>
> Why don't you just have each named(8)
I don't know of a way to do this in FreeBSD, however OpenBSD's bridging
code does support this. man brconfig on an OpenBSD box.
Simply bridging a tunneling device and an ethernet device might work under
FreeBSD.
Matt
On Wed, 17 Apr 2002, Peter J. Blok wrote:
> Hi All,
&g
501 - 600 of 616 matches
Mail list logo
