: Matthew Dillon
: <[EMAIL PROTECTED]>
I believe this will fix the problem (I'll leave it to Soren to commit it
or the appropriate fix):
-Matt
Index:
Matthew Dillon
<[EMAIL PROTECTED]>
/boot/kernel/acpi.ko text=0x2ae68 data=0x1618+0x6ec syms=[0x4+0x4df0+0x4+0x66dd]
Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents
:The following files under sys/ still use MFREE():
:
:alpha/tc/am7990.c
:netatm/port.h
:security/lomac/kernel_socket.c
:
:Please fix.
:
:
:Cheers,
:--
:Ruslan Ermilov Sysadmin and DBA,
Please review the following patch. Note that the KB_ macros in
netatm could be further rewri
:I have a system using a fairly new Supermicro MB, with 2 P3-1GHZ, and 512mb
:ram. Running stable works fine at least a day or so with LOTS of activity.
:Running current it hangs (with no output of any kind, and apparently all
:interrupts disabled) so DDB does me no good... This requires a fair
:On Mon, 31 Dec 2001, Michal Mertl wrote:
:
:Sorry to bloat the list but I forgot to mention that the panics occur when
:I actually try to read from ntfs partition (after appliing pach from
:previous email). cd works ok but ls panics the kernel.
:
:
:--
:Michal Mertl
:[EMAIL PROTECTED]
Yah.
Oops, sorry, that patch was for smbfs on -stable. Not -current.
ntfs has a similar problem. It implements VOP_BMAP but fakes it,
and ntfs_read() doesn't *USE* the buffer cache, so again sendfile()
believes that a UIO_NOCOPY read will work when it won't. And, again
there is
bject's backing store.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
:
:On Sun, 30 Dec 2001 15:47:45 +0100, Michal Mertl wrote:
:
:> I did use the "goto oldway;"
:Please note that I am taking no position regarding whether Matt's sio
:changes should remain or be backed out.
:
:That said, the following was the minimal change I found necessary to
:get today's -CURRENT to build:
Ha! My original commit was correct. My bruce-backout commit was
flawed
:I'm starting to get spam since I joined this list, and the spam is
:coming from freebsd.org. If I'm reading the headers right, it's coming
:in through a freebsd.org mail server.
Ha. In the last two weeks the amount of personal spam I receive has
gone up exponentially. I'm getting aro
Power to Serve
I would prefer that it figure out the correct time counter itself
rather then plague us with fraggin microuptime messages for the last N
years :-(
-Matt
Matthew Dillon
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
44.3800035 -> 62344.415407)
Anyone know what's up?
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
put carefully!
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
:> 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
:>
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?
21496720 0 32,1K,4K
I am going to add freebsd-current back to the list, maybe this will
ring a bell with someone else. Something is obviously blowing up,
but I have no idea what.
-Matt
Matthew
nt IBM firmware versions. See if Fujitsu has a firmware upgrade.
:
:--
:Justin
I don't see an update for them. When I get a chance I'll throw a seagate
in and test with that as well.
-Matt
ach i ( t1 t2 t3 t4 t5 )
./runtest $i &
end
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
Dec 18 13:32:05 test3 kernel: swap_pager: indefinite wait buff
omatically apply
to preexisting works). I don't think it's even close to being legal.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to
:>
:>Just to balance this point out;
:>
:>Only the copyright holder can do this, what code of any significance has
:>RMS contributed recently to this or any other project where this would be
:>a consideration?
:
:Uh, people have been signing their copyright over to FSF for a long
:time...
:
:--
I've noticed that -current has much lower TCP performance. I haven't
had time to investigate it but I presume there is some overhead
somewhere that is killing it.
-Matt
:Hi,
:I am testing the forwarding performance of CURRENT vs. STABLE
:(both
:> Well, for reads a non-stripe-crossing op would still work reasonably
:> well. But for writes less then full-stripe operations without
:> spindle sync are going to be terrible due to the read-before-write
:> requirement (to calculate parity). The disk cache is useless in that
:For RAID3 that is true. For the other ones...
:
:> performance without it - for reading OR writing. It doesn't matter
:> so much for RAID{1,10}, but it matters a whole lot for something like
:> RAID-5 where the difference between a spindle-synced read or write
:> and a non-spi
t spindle synced, no matter what
the stripe size, and will go down the drain for reads if you cross
a stripe - something that is quite common I think.
-Matt
Matthew Dillon
or write can be upwards of 35%.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
:> Wouldn't the linear speed be faster closer to the spindle at 7200 RPM
:> than at the edge?
:
:The stunning ignorance being displayed in this thread appears to have
:reached an all-time low.
:
:*sigh*
Ah, another poor soul who didn't read the first sentence of
tuning(7).
:> etc... So apparently my warning about these drives in 'man tuning' is
:> still appropriate :-)
:>
:> -Matt
:>
:> :> > IBM DTLA drives are known to rotate fast enough near the spindle
:> :> > that the sustained write speed exceeds the ability of th
On google search for:
deskstar 75gxp class action
http://www.theregister.co.uk/content/54/22412.html
http://www.pcworld.com/news/article/0,aid,67608,00.asp
etc... So apparently my warning about these drives in 'man tuning' is
still appropriate :-)
:This illegal geometry causes divide by zero errors in a handful of scsi
:bioses from Adaptec.
:
:This illegal geometry causes divide by zero errors in a handful of scsi
:bioses from NCR/Symbios.
:
:This is why it is called dangerous.
:
:Cheers,
:-Peter
:--
:Peter Wemm - [EMAIL PROTECTED]; [EMAIL
:boot block itself). The comments tell a bit more about it. But
:adding pointless messages that flush the boot log and possibly hide
:important boot messages can't be goo.
:
:--
:cheers, J"org .-.-. --... ...-- -.. . DL8DTL
Yes, Goo in the computer is wery, wery bad!
cted transfer speed upto the drives cache size.
:
:-Søren
Ahhh. Hmm. That is very odd then. Even at irq 14/15 the interrupt
priority should not make a difference, at least not in a simple test
when the machine isn't doing anything else.
-M
ne transaction full of data (ie max 128k).
:
:-Søren
The larger transfers are probably choking the IDE drive's pipelining
capabilities. That's my guess, anyway. I avoid IDE like the plague.
-Matt
od... look at SX locks, for example. The
struct sx is about 8 times as big as it needs to be to implement
reasonable functionality. I would scrap the upgrade and
downgrade API and I would scrap the condition variables
and go with a simple shared/exclusive counter.
lem though.
:
:--
:
:John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
Would it make sense for me to add a new MTX flag that disables certain
non-applicable warnings?
-Matt
Matthe
Hmm.. that last patch didn't do it. I've noticed some errors on the
console before the lockup:
unexpected md driver lock: 0xe1813900: type VREG, usecount 2, writecount 1, refcount
3871, flags (VOBJBUF)
tag VT_UFS, ino 4, on dev da0s1h (13, 131079) lock type inode: EXCL (count 1
Ok, I think I've whacked this one. Try this patch and see if it
fixes your buf_daemon() lockups. The patch also fixes the
double-data-caching that occurs with file-backed MD.
If this works for you, Mark, I'll commit it and probably also MFC it.
I'll also be able to apply th
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
:I have an easy to reproduce case where my system goes into a blocking
:sleep.
:
:# mdconfig -a -t vnode -f largefile -u 0
:# newfs /dev/md0c
:# mount /dev/md0c /mnt
:# cd /mnt
:# cp
onal Giant wrapper
variables and sysctls to kern/kern_mutex.c.
Note that these are long term mechanisms, it will probably be several
years of diminishing bugs before we work the races out.
-Matt
(I meant must be closed with FWRITE, not VWRITE. There is no VWRITE).
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
:
:Hmm. The way the revamped console code works is this:
:
: cn_devopen() calls vn_open() to open the device. If this is not a
:VCHR device, then it is closed. Otherwise, the vnode is stashed in
:cnd->cnd_vp.
:
: When the device is closed though cnclose(), it walks through a list
:of consol
:...
:Sttopped at Debugger+0x44: pushl%ebx
:db> trace
:Debugger()
:panic()
:vrele()
:vn_close()
:cnclose()
:spec_close()
:spec_vnoperate()
:vclean()
:vgonel()
:vgone()
:vop_revoke()
:devfs_revoke()
:exit1()
:...
In looking at a diff in the last few days, a huge number of changes have be
:I got a panic on -current which is updated 3 hours before.
:
:...
:Additional TCP options:.
:Starting background filesystem checks
:
:Wed Oct 24 20:28:15 JST 2001
:panic: vrele: missed vn_close
:Debugger("panic")
:Sttopped at Debugger+0x44: pushl%ebx
:db> trace
:Debugger()
:panic()
:vrele()
:
:I got a panic on -current which is updated 3 hours before.
How old was your kernel prior to the update?
:Additional TCP options:.
:Starting background filesystem checks
:
:Wed Oct 24 20:28:15 JST 2001
:panic: vrele: missed vn_close
:Debugger("panic")
:Sttopped at Debugger+0x44: pushl
Try turning off vmiodirenable:
sysctl -w vfs.vmiodirenable=0
And see if that makes a difference.
-Matt
:On one of my current boxes I run amanda, which some 2 weeks ago (after an
:upgrade to that current) started dying reliable when the bac
nt option flags.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
:On Mon, Jun 19, 2000 at 05:34:47PM -0700, Matthew Dillon wrote:
:>
:> Ok, I have put up a web page that will track my efforts.
:>
:> http://apollo.backplane.com/FreeBSDSmp/
:
:Your first patchset contains only i386 code.
:What is the timeframe for alpha relative to i386
ciple applies here.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
d
the BSDI merger. Jordan and other core members have hinted, intimated,
and outright told people that FreeBSD-current would be used for the BSDI
merge work. Well, the time is now folks!
-Matt
Matthew Dillon
All SMP/FreeBSD/BSDI work should move to the freebsd-smp list.
(I've BCC'd this to -current).
--
I now have mutexes 99% working in an SP build. I will be making
SP (single processor) patch sets available tonight or tomorrow
morning. (99% == I can boot the machine norm
Giant lock and doesn't *have* any other mutexes beyond
SchedMutex and GiantMutex.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL P
SD/OS, which should make
:things go much more smoothly than they otherwise might, but we still expect
:-current to be destabilized for an extended period of time.
:
:Matthew Dillon is currently working on the locking primitives, as well as
:some changes to the way our top-level kernel locking works.
:What do people think about adding a -e option to umount(8) to eject a
:removable medium where possible?
:
:Greg
:--
:Finger [EMAIL PROTECTED] for PGP public key
Sounds good!
-Matt
Matthew Dillon
?
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
m able to turn DDB and INVARIANT* on again. I haven't
tried remote GDB debugging.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL
e and vid_configure is dying.
The list is generated from a linker_set ... one of those special linker
lists.
Something's broken the list maybe the DATA_SET macro is something ilke
that.
-Matt
:
:> Err.. how did you run it? 'perl < MYKERNEL'? If you run 'perl MYKERNEL'
:> it will generate nothing because I was kinda lame and didn't know how to do
:> argument parsing. :-]
:
:Yep, I ran it exactly as you specified in your "HEADS UP" message
:to -current. It generates no output for eit
:NOTE: I'm not on -current, so if you trim committers, please cc me.
:
:I believe I have discovered a problem w/ -current... I would like more
:data points to see if this is a problem... when I run
:http://people.FreeBSD.org/~jmg/bench.py against a -current box (so far
:I have tested against buil
asonable, and there's overkill. mktemp() has no business
using punctuation in the temporary file names.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscr
VSZ of the netscape binary while
the paging is going on? Please post a ps axl of the state of the system
while the paging is going on.
-Matt
Matthew Dillon
<[EMAIL PRO
:I'm running a 700Mhz K7 with 256M of RAM as my workstation. I have
:two fast SCSI drives with a Gig of swap between them. The system
:shouldn't normally be a bottleneck as a workstation.
:
:I find, however, that there seem to be some bad worst-case senerios
:popping up rather often.
:...
to the retry loop.
:
:Jonathan Hanna <[EMAIL PROTECTED]>
Hmm. Yes, there does appear to be an issue there. The
'goto tryagain' on line 777 is leaving the clp and al_auth allocated
as well, so there is a memory leak there too.
I'll do a whole clean
:Here is a rather suspicious fix, I have not looked at rpc call
:use in detail:
:
:--- mount_nfs.c.origSat Jun 10 11:08:19 2000
:+++ mount_nfs.c Sat Jun 10 11:09:06 2000
:@@ -784,10 +784,11 @@
:warnx("%s", clnt_sperror(clp,
:
with a non-random number,
using xor, what you get is a random number. It's neither stronger
nor weaker.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Uns
It
:is possible to avoid using them ?
:
:--
:Boris Popov
:http://www.butya.kz/~bp/
It would be a good idea to avoid any punctuation.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]&
:
:
:The patch fixes the problem with the overflow message and gets my connection
:speed back up. Which is good. Unfotunately my display is having problems.
:Not nearly as much as before but still noticable and a little annoying.
:
:steve
I can't imagine how the display problems could be r
y because I wanted a little time to
be able to trace out the interrupt path to make sure the patch was ok.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubs
:The patch seems to have completely broken fast interrupts.
:GET_FAST_INTR_LOCK is neither necessary nor sufficient as far as I can see.
:The necessary and sufficient locking is done by COM_LOCK() in individual
:drivers. The patch changed GET_FAST_INTR_LOCK from s_lock(&fast_intr_lock),
:which do
]
Ok, at least it wasn't me :-) That's all I care about, bye! .. heh heh,
just kidding. It seems that people are homing in on the problem being
syscons, that's two so far. Is there any further corroboration?
-Matt
ow if the mouse problems are related or not, did anyone have
jumpy-mouse problems before the SMP cleanup was committed? (i.e. in
kernels then two weeks old for 4.0, and four weeks old for 5.0).
-Matt
ersion of the buffer and then
redirty the buffer with the dependant data.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
wi
Softupdates
issues all non-conflicting writes in parallel and doesn't care what order
they are written to the disk. When those complete, softupdates will then
followup with all the writes that depend on the original set.
-Matt
:Matthew Dillon <[EMAIL PROTECTED]> writes:
:> Index: anonFTP.c
:> ===
:> RCS file: /home/ncvs/src/release/sysinstall/anonFTP.c,v
:> retrieving revision 1.29
:> diff -u -r1.29 anonFTP.c
:> --- anonFTP.c
This is a general bounded-buffer patch for sysinstall plus it fixes
PR misc/18466 (limited 'device name' size screws up FTP installs).
It does not fix all the potential buffer overflows -- there are still
a lot of strcpy's, but it gets half way there with the introduction
and u
This is both a heads up and a, well, ok, and a solicitation. I'll admit
it!
As many of you know I was a founder of BEST Internet, an ISP which was
eventually sold to Verio at the end of 1998. I've also been extremely
active in the FreeBSD community. Throughout 1999 I've b
be
opssible to track the problem down.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
:Is anyone else observing kernel panics in the NFS code with Alpha
:(pc164) and rl0 (the Alpha is running as a client only) ?
:
:NFS worked just fine when I had a de0 in the box. After installing an
:rl0 (I know they suck, but they're so cheap :) I _always_ get an
:unaligned access panic when I t
:
:On Thu, Apr 27, 2000 at 06:32:24PM -0700, Matthew Dillon wrote:
:> A Swap-backed VN /tmp will work as well, but keep in mind that the
:> sector size is 4K and you should use the appropriate options to
:> vnconfig to pre-reserve the swap space so performance does no
:Hi Matthew,
:
:On Thu, 27 Apr 2000, Matthew Dillon wrote:
:
:> I can't imagine why MFS would perform better... it shouldn't, every
:> block is stored in system memory *TWICE* (once in the VM cache, and
:> once in the mfs process's address space). If you hav
:
: Do you have any thoughts on this subject? Is 3.2-RELEASE old and
:non-optimized enough that it really could stand replacing?
3.2 is certainly old. The question is whether or not the performance
issue that caught you under 3.2 is fixed under 4.0. Not knowing what
was caus
: I use a mfs for storing the Diablo history file on our news
:peering server. Yes, I know the front part of the file is mmap()'ed
:and effectively kept completely in memory anyway, but I've seen
:periods of time when we received over 160,000 articles in a single
:hour (an average of ab
:Hi,
:
: Today, we tried to create a 5Gig mfs. It turns out this is
:not such a good idea. It turns out that support is basically
:limited to an int. Extracts from some of the appropriate files
:show some of the problems...
More then just a few MFS uses an mmap()'d segment, so you
c
(on a different topic) I am also seeing serial stream corruption
for serial console output. If I add a kernel printf() that generates
a lot of output, I get most of it on the serial console plus a lot
of other random garbage. Very weird.
The linux emulation patch has been committed to -current, you must
recompile your linux emulation kld.
This patch will be MFC'd to 4.x on Friday.
-Matt
Matthew D
queue packets with fixed-length
bidirectional FIFOs.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
After further review I don't think there are any compatibility problems
with the spl*() mechanisms.
But I must still caution that due to the extensive nature of the
cleanup, despite being mostly internal to the kernel, there could
very well be other things that we have overlo
The KISS principle applies to SMP big-time.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
st of the SMP innards are invisible to the user and even invisible
(for the most part) to KLD's. For example, making the VM subsystem and
network stack MP-safe can probably be done without any external
visibility.
-Matt
isn't from
the point of view of modules that use it).
So I think we're safe in this particular case.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Un
the benefits of
further SMP development or not? If you choose no, beware that without
this base cleanup there is *NO* chance whatsoever of any further SMP
work being MFC'd to 4.x. None. Zilch. It will have diverged too
much.
:
:On Sun, 23 Apr 2000, Matthew Dillon wrote:
:>
:> :Rather than break the FreeBSD4 modules over which you have no control,
:> :perhaps your arguments should be used to accelerate the 5.0 release
:> :and make 4.x a short lived branch.
:>
:> I don't think this is pos
it will suddenly
break FreeBSD even under the worst possible assumptions. As DG said,
the linux scripting patch is simply not this big a deal... I don't know
what Poul is barking at.
-Matt
Matthew Dill
:
:Matthew Dillon <[EMAIL PROTECTED]> writes:
:> obviously missing __FUNCTION__ was added by GCC many years ago, but it was
:> a while before it's use in defines in header (.h) files was dealt with
:> properly.
:
:You mean outside a function? What's the p
all it may
be ok. I think we should resign ourselves to recompiling the KLD's,
though.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
:
:On Sun, 23 Apr 2000, Matthew Dillon wrote:
:
:> :In that case I have a strong objection to the SMP patchset being
:> :merged to 4.0. I have kernel modules in object format only that
:> :are working now, which this would break :-(.
:> :
:> :Rod Grimes - KD7CAX @
nt to do is to do
the SMP MFC and the scripting MFC at the same time so people only have
to recompile their kernel modules once. It happens to work out
well ).
-Matt
Matthew Dillon
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
:
:In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
:
:>Core should consider reverting the special rules that were originally
:>created with the expectation of major breakage in 5.x back to
:>the set of rules we had for 3.x and 4.x.
:
:I have no idea what sp
ules for 4.x is overrated,
and the rules should probably be reverted back to standard.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
:[EMAIL PROTECTED] | TCP/
Core should consider reverting the special rules that were originally
created with the expectation of major breakage in 5.x back to
the set of rules we had for 3.x and 4.x.
-Matt
Matthew Dillon
:
:In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
:
:>There's another good reason to MFC the linux patch on wednesday...
:>that is, to do it at the same time the SMP cleanup is MFC'd, and that
:>is because both patch sets require the
301 - 400 of 1252 matches
Mail list logo
