Re: ALTQ support

[Michael Lee]

> On Mon, 10 Nov 2003 12:29:34 +0800, Michael Lee <[EMAIL PROTECTED]> wrote:
>
> > Dear Sir,
> >
> > I don't know if I am posting this question to a wrong mailing list.
> >
> > I am looking for a solution to make QoS possible on my FreeBSD box.
After
> > searching for the internet, I found that there is a software called ALTQ
> > that can do possibly what I want. However, I found that it is still not
> > directly built into the kernel. Those who want to use it need to patch
> > the
> > kernel themselves.
> >
> > http://www.rofug.ro/projects/freebsd-altq/
>
> I am not really sure which is better or difference, but there has another
> link: http://www.nipsi.de/altq/index.html
>
> Cheers,
> Mezz

Hi Jeremy,

Thank you.
It seems better than the link I found. However, those who want to use it
still need to patch the kernel themselves.

If it can be built into the kernel as it was illustrated in the homepage, it
would be better.
I know it depends on the way the core team members see it.
Is there any plan to make it into the kernel ?

Michael Lee

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Kernel memory leak in ATAPI/CAM or ATAng?

[Scott Long]

Kevin Oberman wrote:
Tested. It's much better, although ATA request keeps adding more
memory all the time when mplayer is playing, but it's now increasing
at about 20K/minute which is a huge improvement. Still, I don't
understand why it should just continue to grow all of the time. The
data rate is about constant. I would expect that it should grow to a
size where the data being processed can be accommodated and then stop
growing. I don't see it stopping.
Thanks for the quick fix.
Well, it sounds like there is still a memory leak somewhere.  Make sure
that you have rev 1.27 of atapi-cam.c to be sure.  If so, please let me
know which malloc type in vmstat -m is growing.
Scott

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Kernel memory leak in ATAPI/CAM or ATAng?

[Kevin Oberman]

Tested. It's much better, although ATA request keeps adding more
memory all the time when mplayer is playing, but it's now increasing
at about 20K/minute which is a huge improvement. Still, I don't
understand why it should just continue to grow all of the time. The
data rate is about constant. I would expect that it should grow to a
size where the data being processed can be accommodated and then stop
growing. I don't see it stopping.

Thanks for the quick fix.

Sorry to have taken so long to test it, but I am at SC2003 in Phoenix
for the next two weeks building and running the show network. About
40 10Gig links this year and about 150 100K and 1Gig links this
year. I have no idea how many miles of fiber in the convention
center, but we start installing it tomorrow morning. We also should be
bringing up the OC-192s to the major research nets over the next two
days. 

If any of you are at the show, stop by the NOC and say "Hi".
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]   Phone: +1 510 486-8634
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

taskqueue patch

[Alfred Perlstein]

I noticed that init was complaining about processes not exiting
when doing a transition to single user mode.  It appears
that the problem is that the taskqueue kernel process is 
started with RFNOWAIT but doesn't respect orderly shutdown
signs.

Diff follows:

Index: subr_taskqueue.c
===
RCS file: /home/ncvs/src/sys/kern/subr_taskqueue.c,v
retrieving revision 1.19
diff -u -r1.19 subr_taskqueue.c
--- subr_taskqueue.c6 Sep 2003 21:05:18 -   1.19
+++ subr_taskqueue.c10 Nov 2003 05:00:00 -
@@ -271,7 +271,7 @@
 
 TASKQUEUE_DEFINE(thread, taskqueue_thread_enqueue, 0,
 kthread_create(taskqueue_kthread, NULL,
-&taskqueue_thread_proc, RFNOWAIT, 0, "taskqueue"));
+&taskqueue_thread_proc, 0, 0, "taskqueue"));
 
 int
 taskqueue_enqueue_fast(struct taskqueue *queue, struct task *task)


-- 
- Alfred Perlstein
- Research Engineering Development Inc.
- email: [EMAIL PROTECTED] cell: 408-480-4684
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Kernel memory leak in ATAPI/CAM or ATAng?

[Kevin Oberman]

> Date: Mon, 10 Nov 2003 11:37:00 +1030
> From: Alex Wilkinson <[EMAIL PROTECTED]>
> 
>   On Thu, Nov 06, 2003 at 08:08:31AM -0800, Kevin Oberman wrote:
>   
>   Any ideas on where I can look for more information? I'm going to try
>   doing some monitoring with vmstat while running to see if I can spot
>   anything, but I am not sure just what I am looking for. The VM system
>   is not something I know much about, but I did read Terry Lambert's
>   excellent message to current on KVM tuning and I'm hoping that this
>   might help, but, if there really is a memory leak, tuning will not fix
>   it.
> 
> Got a link to "...Terry Lambert's excellent message to current on KVM tuning.." ?

I found it in Google Groups. Search for "mailing.freebsd.current
Lambert kmem_map" and you will find several good articles. It's really
worth reading the entire threads to get a better understanding of how
all of this works.

The one I was referring to was at:
http://groups.google.com/groups?q=mailing.freebsd.current+Lambert+kmem_map&start=10&hl=en&lr=&ie=UTF-8&selm=bde8n6%244jb%241%40FreeBSD.csie.NCTU.edu.tw&rnum=12

-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]   Phone: +1 510 486-8634
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ALTQ support

[Jeremy Messenger]

On Mon, 10 Nov 2003 12:29:34 +0800, Michael Lee <[EMAIL PROTECTED]> wrote:

Dear Sir,

I don't know if I am posting this question to a wrong mailing list.

I am looking for a solution to make QoS possible on my FreeBSD box. After
searching for the internet, I found that there is a software called ALTQ
that can do possibly what I want. However, I found that it is still not
directly built into the kernel. Those who want to use it need to patch 
the
kernel themselves.

http://www.rofug.ro/projects/freebsd-altq/
I am not really sure which is better or difference, but there has another 
link: http://www.nipsi.de/altq/index.html

Cheers,
Mezz
I wonder if any of the core team members has the plan to build it into 
the
kernel since I was told that it is not a good way to patch the kernel
myself. ( for the system stability concern. )

Thanks!

Michael Lee

PS: Please c.c me since I did not subscribe to this mailing list.


--
bsdforums.org 's moderator, mezz.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

ALTQ support

[Michael Lee]

Dear Sir,

I don't know if I am posting this question to a wrong mailing list.

I am looking for a solution to make QoS possible on my FreeBSD box. After
searching for the internet, I found that there is a software called ALTQ
that can do possibly what I want. However, I found that it is still not
directly built into the kernel. Those who want to use it need to patch the
kernel themselves.

http://www.rofug.ro/projects/freebsd-altq/

I wonder if any of the core team members has the plan to build it into the
kernel since I was told that it is not a good way to patch the kernel
myself. ( for the system stability concern. )

Thanks!

Michael Lee

PS: Please c.c me since I did not subscribe to this mailing list.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: the PS/2 mouse problem

[Alex Wilkinson]

On Wed, Nov 05, 2003 at 08:33:58PM -0700, Scott Long wrote:
 
One thought that I had was to make psmintr() be INTR_FAST.  I need to
stare at the code some more to fully understand it, but it looks like it
wouldn't be all that hard to do.  Basically just use the interrupt handler
to pull all of the data out of the hardware and into a ring buffer in
memory, and then a fast taskqueue to process that ring buffer.  It would
at least answer the question of whether the observed problems are due to
ithread latency.  And if done right, no locks would be needed in
psmintr().

I seemed to have solved my mouse problem: 

[http://www.mail-archive.com/[EMAIL PROTECTED]/msg62824.html].

Solution: I disabled IPCA in the BIOS and the mouse problem went away.

Does IPCA have anything to do with ACPI. Yes, I have googled and looked at anandtech 
forums
and had no luck.

In disabling IPCA have I disabled ACPI ?

 - aW
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: --- trap 0x1, eip = 0, esp = 0xd77cdd7c, ebp = 0 ---

[Alex Wilkinson]

On Mon, Nov 10, 2003 at 01:08:30PM +1030, Kris Kennaway wrote:

> Not sure how to interpret these errors on the console ?? 
> Running: FreeBSD 5.1-CURRENT #4: Thu Nov  6 16:49:21 CST 2003

Part of a backtrace from an error detected by WITNESS.  There was more
above that that you didn't post.

There wasn't actually:




Starting sshd.
Starting sendmail.
Initial i386 initialization:.
Additional ABI support: linux.
Starting cron.
Local package initialization: Samba.
Additional TCP options:.
Starting moused:.
Starting inetd.
Starting background file system checks in 60 seconds.

Mon Nov 10 10:38:35 CST 2003

FreeBSD/i386 (hostname.dsto.defence.gov.au) (ttyv0)

login: backtrace(c0883a21,c0971e6c,c088a4f4,c088a4f4,c088b844) at backtrace+0x17
witness_lock(c0971e6c,8,c088b844,26d,d77cda24) at witness_lock+0x672
_mtx_lock_flags(c0971e6c,0,c088b844,26d,0) at _mtx_lock_flags+0xba
tcp_usr_rcvd(c4e66000,80,c0690520,c0884028,3b9aca00) at tcp_usr_rcvd+0x30
soreceive(c4e66000,d77cda98,d77cdaa4,d77cda9c,0) at soreceive+0x8ef
nfsrv_rcv(c4e66000,c4e26780,4,28,60f4) at nfsrv_rcv+0x87
sowakeup(c4e66000,c4e6604c,c088af2f,446,108) at sowakeup+0x91
tcp_input(c1d32900,14,c094b5d0,c094a820,2b3) at tcp_input+0x133e
ip_input(c1d32900,0,c08891b3,89,0) at ip_input+0x92a
netisr_processqueue(c09700d0,0,c08891b3,e5,c46f70c0) at netisr_processqueue+0x8e
swi_net(0,0,c087e536,21f,c1d211e4) at swi_net+0x98
ithread_loop(c1d18580,d77cdd48,c087e39c,311,1) at ithread_loop+0x192
fork_exit(c0656420,c1d18580,d77cdd48) at fork_exit+0xb4
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xd77cdd7c, ebp = 0 ---


How can I help debug this error ?

 - aW
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: --- trap 0x1, eip = 0, esp = 0xd77cdd7c, ebp = 0 ---

[Kris Kennaway]

On Mon, Nov 10, 2003 at 12:51:21PM +1030, Alex Wilkinson wrote:
> Not sure how to interpret these errors on the console ?? 
> 
> Running: FreeBSD 5.1-CURRENT #4: Thu Nov  6 16:49:21 CST 2003

Part of a backtrace from an error detected by WITNESS.  There was more
above that that you didn't post.

Kris


pgp0.pgp
Description: PGP signature

--- trap 0x1, eip = 0, esp = 0xd77cdd7c, ebp = 0 ---

[Alex Wilkinson]

Not sure how to interpret these errors on the console ?? 

Running: FreeBSD 5.1-CURRENT #4: Thu Nov  6 16:49:21 CST 2003

backtrace(c0883a21,c0971e6c,c088a4f4,c088a4f4,c088b844) at backtrace+0x17
witness_lock(c0971e6c,8,c088b844,26d,d77cda24) at witness_lock+0x672
_mtx_lock_flags(c0971e6c,0,c088b844,26d,0) at _mtx_lock_flags+0xba
tcp_usr_rcvd(c4e66000,80,c0690520,c0884028,3b9aca00) at tcp_usr_rcvd+0x30
soreceive(c4e66000,d77cda98,d77cdaa4,d77cda9c,0) at soreceive+0x8ef
nfsrv_rcv(c4e66000,c4e26780,4,28,60f4) at nfsrv_rcv+0x87
sowakeup(c4e66000,c4e6604c,c088af2f,446,108) at sowakeup+0x91
tcp_input(c1d32900,14,c094b5d0,c094a820,2b3) at tcp_input+0x133e
ip_input(c1d32900,0,c08891b3,89,0) at ip_input+0x92a
netisr_processqueue(c09700d0,0,c08891b3,e5,c46f70c0) at 
netisr_processqueue+0x8e
swi_net(0,0,c087e536,21f,c1d211e4) at swi_net+0x98
ithread_loop(c1d18580,d77cdd48,c087e39c,311,1) at ithread_loop+0x192
fork_exit(c0656420,c1d18580,d77cdd48) at fork_exit+0xb4
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xd77cdd7c, ebp = 0 ---

Anyone have a clue ?

 - aW
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Kernel memory leak in ATAPI/CAM or ATAng?

[Alex Wilkinson]

On Thu, Nov 06, 2003 at 08:08:31AM -0800, Kevin Oberman wrote:

Any ideas on where I can look for more information? I'm going to try
doing some monitoring with vmstat while running to see if I can spot
anything, but I am not sure just what I am looking for. The VM system
is not something I know much about, but I did read Terry Lambert's
excellent message to current on KVM tuning and I'm hoping that this
might help, but, if there really is a memory leak, tuning will not fix
it.

Got a link to "...Terry Lambert's excellent message to current on KVM tuning.." ?

Very keen to read it.

 - aW
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: buildworld error

[Kris Kennaway]

On Sun, Nov 09, 2003 at 07:32:57PM -0500, Jason wrote:
> Ok, here is the last section of output and the error.  After this if I 
> do ethier gzip command I get an error, but if I enter the makeinfo 
> commands first the gzip command then works.  Could this be some kind of 
> schedualling problem because  I normally use the command $time make -j4 
> buildworld.  But it always stops at this point, so it must be something 
> specific to the cvs/doc files.  I have emailed the maintiner listed in 
> the make files and have gotten no response.  Anyone else have this 
> experience?
> Thanks,
> Jason

Don't use -j when posting buildworld errors, because they are obscured
amongst other output.  Please retry without -j and post the actual
error.

Kris


pgp0.pgp
Description: PGP signature

Re: New interrupt code slows hyperthreading down

[Jens Rehsack]

John Baldwin wrote:
On 07-Nov-2003 Jens Rehsack wrote:

John Baldwin wrote:

Thanks, IRQ 16 was programmed as level, activelo, so it wasn't an
off by one error there.  Grr.
I've seen, but I didn't found a bios option to set it to edge.
Is there anything I can do on my machine to fix the problem, or
should Asus be notified for a bios update or ...?
No, level is correct.  The APIC code doesn't mask edge triggered
interrupts, and if it thought IRQ 16 was edge rather than level,
that could explain the high interrupt rate.  Since that isn't the
case I'm not sure why it's triggering so many interrupts.
Ok, but what I can do now to get my machine running with HTT again?
It's out main development machine and with the single-processor
config it runs mostly with a very high load. Is there any chance
to get it running just before the new interrupt code. Could it be
fixed?
Regards,
Jens
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: buildworld error

[Jason]

Ok, here is the last section of output and the error.  After this if I 
do ethier gzip command I get an error, but if I enter the makeinfo 
commands first the gzip command then works.  Could this be some kind of 
schedualling problem because  I normally use the command $time make -j4 
buildworld.  But it always stops at this point, so it must be something 
specific to the cvs/doc files.  I have emailed the maintiner listed in 
the make files and have gotten no response.  Anyone else have this 
experience?
Thanks,
Jason

===> gnu/usr.bin/cvs/doc
makeinfo --no-split -I /usr/src/gnu/usr.bin/cvs/doc -I 
/usr/src/gnu/usr.bin/cvs/doc/../../../../contrib/cvs/doc 
/usr/src/gnu/usr.bin/cvs/doc/../../../../contrib/cvs/doc/cvs.texinfo  -o 
cvs.info
makeinfo --no-split -I /usr/src/gnu/usr.bin/cvs/doc -I 
/usr/src/gnu/usr.bin/cvs/doc/../../../../contrib/cvs/doc 
/usr/src/gnu/usr.bin/cvs/doc/../../../../contrib/cvs/doc/cvsclient.texi  
-o cvsclient.info
gzip -cn cvsclient.info > cvsclient.info.gz
gzip -cn cvs.info > cvs.info.gz
1 error
*** Error code 2
1 error
*** Error code 2
1 error

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Radeon DRM-Problem

[John Baldwin]

On 08-Nov-2003 Ralf Folkerts wrote:
> Hi,
> 
> thanks for the hints! 
> 
> Well, I didn't set anything "special" in XF86Config; I'll put in my
> XF86Config and attach an XFree86.0.log

Actually, try adding an 'AGPSize' option in the 'Device' section with a value
set to the size of your aperture.  I Think X uses a 1mb aperture by default
and it may be that it is failing to allocate some buffers due to your screen
resolution combined with the small default size of the aperture.

Adding 'AGPMode 4' probably couldn't hurt as well.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: New interrupt code slows hyperthreading down

[John Baldwin]

On 07-Nov-2003 Jens Rehsack wrote:
> John Baldwin wrote:
> 
>> Thanks, IRQ 16 was programmed as level, activelo, so it wasn't an
>> off by one error there.  Grr.
> 
> I've seen, but I didn't found a bios option to set it to edge.
> Is there anything I can do on my machine to fix the problem, or
> should Asus be notified for a bios update or ...?

No, level is correct.  The APIC code doesn't mask edge triggered
interrupts, and if it thought IRQ 16 was edge rather than level,
that could explain the high interrupt rate.  Since that isn't the
case I'm not sure why it's triggering so many interrupts.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: panic: Most recently used by mount

[Tim Robbins]

On Sun, Nov 09, 2003 at 01:30:52PM -0800, Kris Kennaway wrote:

> On Sun, Nov 09, 2003 at 06:05:06PM +0100, Lukas Ertl wrote:
> 
> > ---
> > panic: Most recently used by mount
> 
> I reported this the other day..tjr has a fix in his p4 branch.

Here's the patch:
(http://perforce.freebsd.org/chv.cgi?CH=41739)

--- kern/vfs_mount.c.oldMon Nov 10 10:30:14 2003
+++ kern/vfs_mount.cSun Nov  9 00:26:03 2003
@@ -700,6 +700,8 @@
mac_destroy_mount(mp);
 #endif
crfree(mp->mnt_cred);
+   lockdestroy(&mp->mnt_lock);
+   mtx_destroy(&mp->mnt_mtx);
free(mp, M_MOUNT);
}
vrele(vp);
@@ -794,6 +796,8 @@
mac_destroy_mount(mp);
 #endif
crfree(mp->mnt_cred);
+   lockdestroy(&mp->mnt_lock);
+   mtx_destroy(&mp->mnt_mtx);
free(mp, M_MOUNT);
vput(vp);
goto bad;
@@ -1066,6 +1070,8 @@
mac_destroy_mount(mp);
 #endif
crfree(mp->mnt_cred);
+   lockdestroy(&mp->mnt_lock);
+   mtx_destroy(&mp->mnt_mtx);
free(mp, M_MOUNT);
}
vrele(vp);
@@ -1147,6 +1153,8 @@
mac_destroy_mount(mp);
 #endif
crfree(mp->mnt_cred);
+   lockdestroy(&mp->mnt_lock);
+   mtx_destroy(&mp->mnt_mtx);
free(mp, M_MOUNT);
vput(vp);
}
@@ -1587,11 +1595,14 @@
free(path, M_MOUNT);
if (error != 0) {
if (mp != NULL) {
+   mp->mnt_vfc->vfc_refcount--;
vfs_unbusy(mp, curthread);
 #ifdef MAC
mac_destroy_mount(mp);
 #endif
crfree(mp->mnt_cred);
+   lockdestroy(&mp->mnt_lock);
+   mtx_destroy(&mp->mnt_mtx);
free(mp, M_MOUNT);
}
printf("Root mount failed: %d\n", error);
--- nfsclient/nfs_vfsops.c.old  Mon Nov 10 10:31:08 2003
+++ nfsclient/nfs_vfsops.c  Sun Nov  9 00:26:03 2003
@@ -510,8 +510,15 @@
printf("nfs_mountroot: mount %s on %s: %d", path, which, error);
mp->mnt_vfc->vfc_refcount--;
vfs_unbusy(mp, td);
-   if (didalloc)
+   if (didalloc) {
+#ifdef MAC
+   mac_destroy_mount(mp);
+#endif
+   crfree(mp->mnt_cred);
+   lockdestroy(&mp->mnt_lock);
+   mtx_destroy(&mp->mnt_mtx);
free(mp, M_MOUNT);
+   }
FREE(nam, M_SONAME);
return (error);
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: tcp hostcache and ip fastforward for review

[Jonathan Mini]

On Nov 9, 2003, at 2:47 PM, Andre Oppermann wrote:

Jonathan Mini wrote:
On Nov 9, 2003, at 8:19 AM, Andre Oppermann wrote:

  - DoS attack 2: make MSS very low on local side of connection
and send mny small packet to remote host. For every packet
(eg. 2 bytes payload) a sowakeup is done to the listening
process. Consumes a lot of CPU there.
This sounds as if it might be worthwhile to add a delay to
the TF_NODELAY case for receive processing as well.
Unfortunatly it is not that easy. We can't just do that unconditionally
to all connections. It would probably break or delay many things. You
never know how much data is outstanding and whether it's just this
packet with 2 bytes outstanding...
This would be disastrous to the performance of interactive
sockets, however theoretically those connections have
NODELAY set. My above comment is a bit confusing: I meant the
"non TF_NODELAY" case, that is when Nagling is enabled.
In this situation, you would be delay an sowakeup until
either a timeout or SO_RCVLOWAT-set value was reached.  The normal
SO_RCVLOWAT case delays until SO_RCVTIMEO is reached.  I suppose
the application could simulate this with a large SO_RCVLOWAT and a
small SO_RCVTIMEO, but I was wondering about the effects of such a
change as part of !TF_NODELAY.
Sadly, there's this PSH bit in the TCP header that's completely
unreliable and could be used for scenarios like this.
As an application aware of this problematic you have currently two
options: use accept filters (FreeBSD only) or set SO_RCVLOWAT to some
higher value than the default 1 byte. Only the first one is workable
if you don't know what and how much the clients send to you. Relying
on the application to activate any such option to prevent this kind
of DoS is unfortunatly whishful thinking.
I was not suggesting that we use this to counter an attack, only asking
if it might be a worthwhile performance optimization to consider.
This is an unlikely case (many small packets sent to a non-interactive
application), so I can't see the improvement as being globally useful.
The code I've put in here simply caps off the extreme cases. It
counts all packets and bytes in any given second and computes the
average payload size per packet. If that is less than we have defined
for minmss it will reset and drop the connection. However it will only
start to compute the average if there are more than 1'000 packets per
second on the same tcp connection. I've chosen this quite high value
to never disconnect any ligitimate connection which just happens to
send many small packets. In my tests I've seen telnet/ssh sending
close to 100 small packets per second (some large copy-pasting and
cat'ing of many small files). Probably 500 packets per second is a
better cut-off value but I just want to be sure to never hit a false
positive.
This is actually a small value for TCP connections which are being
used to forward messages, especially on gigabit links.  
Heavily-intensive
web applications that are using small HTTP requests (pipelined inside a
persistent connection) to update small manipulations of state are
a good example of this.  I wouldn't be surprised to see chatter
between SQL servers follow similar patterns.  Applications which
use XML-based messaging often send several small packets per message,
which is unfortunate.

On the other hand, I'm used to looking at proxies, which are not
the general case.  This is why the limits are tunable, after all. =)
--
Jonathan Mini
[EMAIL PROTECTED]
http://www.freebsd.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: New EHCI device ID

[Bernd Walter]

On Sun, Nov 09, 2003 at 11:56:19PM +0100, Pav Lucistnik wrote:
> It's that easy? Just adding device ID? I was under impression that you
> need to write/modify a driver for a new chip.

Adding the ID is just beautifying the boot messages.
EHCI controllers are all compatible (modulo bugs) from the software
point of view.

> In that case I'm here with my own motherboard:
> 
> ehci0:  mem 0xdffeff00-0xdffe irq 21 at 
> device 16.3 on pci0
> ehci0: (New EHCI DeviceId=0x31041106)
> 
> [EMAIL PROTECTED]:16:3:class=0x0c0320 card=0x71201462 chip=0x31041106 
> rev=0x82 hdr=0x00
> vendor   = 'VIA Technologies Inc'
> device   = 'VT6202 USB 2.0 Enhanced Host Controller'
> class= serial bus
> subclass = USB
> 
> But not that it does not work correctly ATM. USB2 devices have problems attaching.

That must be for a different reason.

> I'm willing to test any patches you can come up with.

Well - I need to see the errors first :)

-- 
B.Walter   BWCThttp://www.bwct.de
[EMAIL PROTECTED]  [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: problems compiling the src from diff directory...

[Kris Kennaway]

On Sun, Nov 09, 2003 at 05:14:45PM -0500, ivan georgiev wrote:
> Hello all,
> 
> I am running 5-1p10 and I wanted to try out -CURRENT. I cvsup-ed it in 
> a different from /usr/src location. When I cd to that location and 
> type "make buildkernel" I get:
> 
>  
> make buildkernel
> "Makefile.inc1", line 744: warning: String comparison operator should 
> be either == or !=
> "Makefile.inc1", line 744: Malformed conditional ((!defined(NO_RESCUE) 
> ||  defined(RELEASEDIR)) &&  (${TARGET_ARCH} != ${MACHINE_ARCH} || 
> ${BOOTSTRAPPING} < 501101))
> "Makefile.inc1", line 744: Missing dependency operator
> "Makefile.inc1", line 746: if-less endif
> "Makefile.inc1", line 746: Need an operator
> make: fatal errors encountered -- cannot continue
> *** Error code 1
>  
> 
> I cannot figure out what is wrong. Please let me know.

This is a FAQ..read UPDATING.

Kris


pgp0.pgp
Description: PGP signature

Re: New EHCI device ID

[Pav Lucistnik]

V ne, 09. 11. 2003 v 22:22, Bernd Walter píše:

> > Hi,
> > 
> > I get this in the dmesg:
> > ---snip---
> > ehci0:  mem 0xfc00-0xfc0003ff irq 12 at d
> > evice 29.7 on pci0
> > ehci0: (New EHCI DeviceId=0x24dd8086)
> > ---snip---
> > 
> > pciconv tells me:
> > ---snip---
> > [EMAIL PROTECTED]:29:7:class=0x0c0320 card=0x24dd17f2 chip=0x24dd8086 
> > rev=0x02 hdr=0x00
> > vendor   = 'Intel Corporation'
> > device   = '82801EB/ER (ICH4/ICH5R) USB EHCI Controller'
> > class= serial bus
> > subclass = USB
> > ---snip---
> > 
> > It's an Intel 865PE chipset.
> 
> Will take this - there is already a ticket open with a new ID - maybe the
> same.

It's that easy? Just adding device ID? I was under impression that you
need to write/modify a driver for a new chip.

In that case I'm here with my own motherboard:

ehci0:  mem 0xdffeff00-0xdffe irq 21 at device 
16.3 on pci0
ehci0: (New EHCI DeviceId=0x31041106)

[EMAIL PROTECTED]:16:3:class=0x0c0320 card=0x71201462 chip=0x31041106 rev=0x82 
hdr=0x00
vendor   = 'VIA Technologies Inc'
device   = 'VT6202 USB 2.0 Enhanced Host Controller'
class= serial bus
subclass = USB

But not that it does not work correctly ATM. USB2 devices have problems attaching.
I'm willing to test any patches you can come up with.

BTW PR you're referring to is probably this one:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/55094

-- 
Pav Lucistnik <[EMAIL PROTECTED]>
What do we know about love? Love is like a pear. Pear is sweet and have
a specific shape. Try to exactly define the shape of a pear.
  -- Marigold: 50 Years Of Poetry


signature.asc
Description: Toto je =?iso-8859-2?Q?digit=E1ln=EC?=	=?ISO-8859-1?Q?_podepsan=E1?= =?iso-8859-2?Q?_=E8=E1st?=	=?ISO-8859-1?Q?_zpr=E1vy?=

Re: tcp hostcache and ip fastforward for review

[Andre Oppermann]

Jonathan Mini wrote:
> 
> On Nov 9, 2003, at 8:19 AM, Andre Oppermann wrote:
> 
> >   - DoS attack 2: make MSS very low on local side of connection
> > and send mny small packet to remote host. For every packet
> > (eg. 2 bytes payload) a sowakeup is done to the listening
> > process. Consumes a lot of CPU there.
> >
> 
> This sounds as if it might be worthwhile to add a delay to
> the TF_NODELAY case for receive processing as well.

Unfortunatly it is not that easy. We can't just do that unconditionally
to all connections. It would probably break or delay many things. You
never know how much data is outstanding and whether it's just this
packet with 2 bytes outstanding...

As an application aware of this problematic you have currently two
options: use accept filters (FreeBSD only) or set SO_RCVLOWAT to some
higher value than the default 1 byte. Only the first one is workable
if you don't know what and how much the clients send to you. Relying
on the application to activate any such option to prevent this kind
of DoS is unfortunatly whishful thinking.

The code I've put in here simply caps off the extreme cases. It
counts all packets and bytes in any given second and computes the
average payload size per packet. If that is less than we have defined
for minmss it will reset and drop the connection. However it will only
start to compute the average if there are more than 1'000 packets per
second on the same tcp connection. I've chosen this quite high value
to never disconnect any ligitimate connection which just happens to
send many small packets. In my tests I've seen telnet/ssh sending
close to 100 small packets per second (some large copy-pasting and
cat'ing of many small files). Probably 500 packets per second is a
better cut-off value but I just want to be sure to never hit a false
positive.

-- 
Andre
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

problems compiling the src from diff directory...

[ivan georgiev]

Hello all,

I am running 5-1p10 and I wanted to try out -CURRENT. I cvsup-ed it in 
a different from /usr/src location. When I cd to that location and 
type "make buildkernel" I get:

 
make buildkernel
"Makefile.inc1", line 744: warning: String comparison operator should 
be either == or !=
"Makefile.inc1", line 744: Malformed conditional ((!defined(NO_RESCUE) 
||  defined(RELEASEDIR)) &&  (${TARGET_ARCH} != ${MACHINE_ARCH} || 
${BOOTSTRAPPING} < 501101))
"Makefile.inc1", line 744: Missing dependency operator
"Makefile.inc1", line 746: if-less endif
"Makefile.inc1", line 746: Need an operator
make: fatal errors encountered -- cannot continue
*** Error code 1
 

I cannot figure out what is wrong. Please let me know.

Thanks,
Ivan





___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

[current tinderbox] failure on i386/pc98

[Tinderbox]

TB --- 2003-11-09 21:04:35 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org
TB --- 2003-11-09 21:04:35 - starting CURRENT tinderbox run for i386/pc98
TB --- 2003-11-09 21:04:35 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/i386/pc98
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-11-09 21:07:25 - building world
TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src
TB --- /usr/bin/make -B buildworld
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything..
TB --- 2003-11-09 22:05:38 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
>>> Kernel build for GENERIC started on Sun Nov  9 22:05:39 GMT 2003
[...]
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/aha/aha_isa.c:127: 
warning: passing arg 1 of `aha_alloc' makes pointer from integer without a cast
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/aha/aha_isa.c:127: 
warning: passing arg 2 of `aha_alloc' makes integer from pointer without a cast
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/aha/aha_isa.c:127: 
warning: passing arg 3 of `aha_alloc' from incompatible pointer type
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/aha/aha_isa.c:127: error: 
too few arguments to function `aha_alloc'
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/aha/aha_isa.c:127: error: 
void value not ignored as it ought to be
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/aha/aha_isa.c:189: error: 
`aha_unit' undeclared (first use in this function)
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/aha/aha_isa.c:189: error: 
(Each undeclared identifier is reported only once
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/aha/aha_isa.c:189: error: 
for each function it appears in.)
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/modules/aha.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/modules.
*** Error code 1

Stop in 
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src.
TB --- 2003-11-09 22:11:47 - TB --- /usr/bin/make returned exit code  1 
TB --- 2003-11-09 22:11:47 - TB --- ERROR: failed to build generic kernel
TB --- 2003-11-09 22:11:47 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: kernel trap 12 with interrupts disabled

[Don Lewis]

On  9 Nov, I wrote:
> I just got one of these shortly after I rebooted my November 7th
> -CURRENT box. DDB doesn't show much interesting.
> 
>  kernel trap 12 with interrupts disabled
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0xbc04d753
> fault code  = supervisor read, page not present
> instruction pointer = 0x8:0xc0685ddf
> stack pointer   = 0x10:0xe5f3bca8
> frame pointer   = 0x10:0xe5f3bcfc
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags= resume, IOPL = 0
> current process = 519 (setiathome)
> kernel: type 12 trap, code=0
> Stopped at  mi_switch+0xcf: cmpl0x8(%esi),%ebx
> db> tr
> mi_switch(c6bbc500,df,c08a3da3,f8,0) at mi_switch+0xcf
> ast(e5f3bd48) at ast+0x3f2
> doreti_ast() at doreti_ast+0x17
> 
> Alas, I didn't have enough free space to capture a core file B-(

This problem doesn't appear to be reproduceable and doesn't seem to be
load dependent.  I had portupgrade cranking for many hours yesterday
without a hiccup.  I cleaned up a bunch of old distfiles and packages,
so I should have sufficient space to get a core dump in case this
problem happens again.

I forgot to include the vital statistics.  BTW, the RAM is ECC.

Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.1-CURRENT #35: Fri Nov  7 14:50:18 PST 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERICSMB
Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a9e000.
Preloaded elf module "/boot/kernel/aout.ko" at 0xc0a9e244.
ACPI APIC Table: 
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Athlon(tm) XP 1900+ (1608.23-MHz 686-class CPU)
  Origin = "AuthenticAMD"  Id = 0x662  Stepping = 2
  
Features=0x383fbff
  AMD Features=0xc048
real memory  = 1073676288 (1023 MB)
avail memory = 1033592832 (985 MB)
ioapic0  irqs 0-23 on motherboard
Pentium Pro MTRR support enabled
acpi0:  on motherboard
pcibios: BIOS version 2.10
Using $PIR table, 11 entries at 0xc00fdc30
acpi0: Power Button (fixed)
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0
acpi_cpu0:  on acpi0
acpi_button0:  on acpi0
acpi_button1:  on acpi0
pcib0:  port 
0x6000-0x607f,0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0
pci0:  on pcib0
pcib0: slot 7 INTD is routed to irq 10
pcib0: slot 7 INTD is routed to irq 10
agp0:  port 0xc000-0xc003 mem 
0xef02-0xef020fff,0xe800-0xebff at device 0.0 on pci0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
pci_cfgintr: 1:5 INTA BIOS irq 15
pci1:  at device 5.0 (no driver attached)
isab0:  at device 7.0 on pci0
isa0:  on isab0
atapci0:  port 0xc400-0xc40f at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata0: [MPSAFE]
ata1: at 0x170 irq 15 on atapci0
ata1: [MPSAFE]
uhci0:  port 0xc800-0xc81f irq 10 at device 7.2 on pci0
usb0:  on uhci0
usb0: USB revision 1.0
uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhub0: port error, restarting port 1
uhub0: port error, giving up port 1
uhub0: port error, restarting port 2
uhub0: port error, giving up port 2
uhci1:  port 0xcc00-0xcc1f irq 10 at device 7.3 on pci0
usb1:  on uhci1
usb1: USB revision 1.0
uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhub1: port error, restarting port 1
uhub1: port error, giving up port 1
uhub1: port error, restarting port 2
uhub1: port error, giving up port 2
viapropm0: SMBus I/O base at 0x5000
viapropm0:  port 0x5000-0x500f at device 7.4 on 
pci0
viapropm0: SMBus revision code 0x40
smbus0:  on viapropm0
smb0:  on smbus0
fxp0:  port 0xe000-0xe03f mem 
0xef00-0xef01,0xef021000-0xef021fff irq 18 at device 10.0 on pci0
fxp0: Ethernet address 00:02:b3:5c:8c:e0
miibus0:  on fxp0
inphy0:  on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ahc0:  port 0xe400-0xe4ff mem 
0xef022000-0xef022fff irq 16 at device 12.0 on pci0
aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
fdc0:  port 0x3f7,0x3f0-0x3f5 
irq 6 drq 2 on acpi0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
sio0 port 0x3f8-0x3ff irq 4 on acpi0
sio0: type 16550A, console
sio1 port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/8 bytes threshold
ppbus0:  on ppc0
plip0:  on ppbus0
lpt0:  on ppbus0
lpt0: Interrupt-driven port
ppi0:  on ppbus0
atkbdc0:  port 0x64,0x60 irq 1 on acpi0
atkbd0:  flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
psm0:  irq 12 on atkbdc0
psm0: model IntelliMouse Explorer, device ID 4
npx0: [FAST]
npx0:  on moth

Re: gcc ICE building R-letter is gone with gcc 3.3.3

[Kris Kennaway]

On Sun, Nov 09, 2003 at 03:40:59PM -0500, Michael L. Squires wrote:
> The internal compiler error compiling R-letter (R-1.8.0) under 5-CURRENT  went 
> away when gcc was updated to 3.3.3.

Cool, it's good to know they're fixing bugs with those version updates :-)

Kris


pgp0.pgp
Description: PGP signature

Re: panic: Most recently used by mount

[Kris Kennaway]

On Sun, Nov 09, 2003 at 06:05:06PM +0100, Lukas Ertl wrote:

> ---
> panic: Most recently used by mount

I reported this the other day..tjr has a fix in his p4 branch.

Kris


pgp0.pgp
Description: PGP signature

Re: New EHCI device ID

[Bernd Walter]

On Sun, Nov 09, 2003 at 08:24:25PM +0100, Alexander Leidinger wrote:
> 
> Hi,
> 
> I get this in the dmesg:
> ---snip---
> ehci0:  mem 0xfc00-0xfc0003ff irq 12 at d
> evice 29.7 on pci0
> ehci0: (New EHCI DeviceId=0x24dd8086)
> ---snip---
> 
> pciconv tells me:
> ---snip---
> [EMAIL PROTECTED]:29:7:class=0x0c0320 card=0x24dd17f2 chip=0x24dd8086 
> rev=0x02 hdr=0x00
> vendor   = 'Intel Corporation'
> device   = '82801EB/ER (ICH4/ICH5R) USB EHCI Controller'
> class= serial bus
> subclass = USB
> ---snip---
> 
> It's an Intel 865PE chipset.

Will take this - there is already a ticket open with a new ID - maybe the
same.

-- 
B.Walter   BWCThttp://www.bwct.de
[EMAIL PROTECTED]  [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

kernel trap 12 with interrupts disabled

[Don Lewis]

I just got one of these shortly after I rebooted my November 7th
-CURRENT box. DDB doesn't show much interesting.

 kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0xbc04d753
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc0685ddf
stack pointer   = 0x10:0xe5f3bca8
frame pointer   = 0x10:0xe5f3bcfc
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 519 (setiathome)
kernel: type 12 trap, code=0
Stopped at  mi_switch+0xcf: cmpl0x8(%esi),%ebx
db> tr
mi_switch(c6bbc500,df,c08a3da3,f8,0) at mi_switch+0xcf
ast(e5f3bd48) at ast+0x3f2
doreti_ast() at doreti_ast+0x17

Alas, I didn't have enough free space to capture a core file B-(
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Kernel memory leak in ATAPI/CAM or ATAng?

[Scott Long]

Fixed.  Please retest.

Scott Long wrote:
Kevin Oberman wrote:

Date: Thu, 6 Nov 2003 11:23:30 -0500 (EST)
From: Robert Watson <[EMAIL PROTECTED]>
On Thu, 6 Nov 2003, Kevin Oberman wrote:


I have learned a bit more about the problems I have been having with
the DVD drive on my T30 laptop. When I have run the drive for an
extended time (like 2 or 3 hours), I invariably have my system lock up
because it can't malloc kernel memory for the ATAPI/CAM or ATA
device. (Usually it's both.)
The only recovery seems to be to reboot the system.


Is it possible to drop to DDB and generate a coredump at that point?  If
so, you can run vmstat on the core to look at memory use statistics in a
post-mortem way.  As to what to look for: "big numbers" is about the 
limit
of what I can suggest, I'm afraid :-).  Usually the activity of 
choice is
to compare vmstat statistics (with -m and -z) during normal operation 
and
when the leak has occurred, and look for any marked differences.  It's
worth observing that there are two failure modes here that appear almost
identical: (1) a memory leak resulting in address space exhaustion 
for the
kernel, and (2) a tunable maximum allocation being too high for the
available address space.  Note that (2) isn't a leak, simply a poorly
tuned value.  We've noticed a number of tuned memory limits were set 
when
memory sizes on systems were much lower, and so we've had to readjust 
the
tuning parameters for large memory systems.  Likewise, a number of
problems were observed when PAE was introduced, as some of the tuning
parameters scaled with the amount of physical memory, not with the
addressable space for the kernel.  So we probably want to be on the look
out for both of these possibilities.


Well, I have no details to this point, but 'vmstat -m' makes the
problem obvious. The amount of kernel memory allocated to ATA request
climbs forever and after enough data is transferred, it runs out of
KVM. This is a continual leak, and monitoring it on the running system
makes it pretty clear that something is leaking. I don't think (2) is
the issue. Because the field allocated in vmstat are not large enough,
this is a bit hard to read. The field all merge into some REALLY large
numbers. After reboot, it is <5K. When running mencode I see this
increasing at a rate of a bit under 1.9 MB per minute.
It does not look like a tuning issue. No matter how big KVM is allowed
to grow, it's only a matter of time until it is gone.
I am going to do some testing to see what operations seem to causse
this. I assume it does not happen all of the time or everyone would
have seen it. I suspect it only happens with ATAPI/CAM activity,
possibly only with simultaneous ATA and ATAPI/COM activity.


Does vmstat -m show which malloc type is growing?  Knowing this will
greatly speed up the debugging process.
Thanks!

Scott



___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Problem on a laptop with current

[Yannick FAHAM]

Hi.

I have recently bought a centrino laptop and tried to install current on
it. the fact is my network card is only supported in this branche
(broadcom 4401).

after compiling the kernel, the boot process freeze on the hardware
enumeration. I have disabled acpi and boot in verbose mode and I have
many errors message like
(probe0)... Error 22.
Sorry for my english, i'm french.
-- 
Yanncik FAHAM
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

[current tinderbox] failure on i386/i386

[Tinderbox]

TB --- 2003-11-09 19:41:10 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org
TB --- 2003-11-09 19:41:10 - starting CURRENT tinderbox run for i386/i386
TB --- 2003-11-09 19:41:10 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/i386/i386
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-11-09 19:43:21 - building world
TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src
TB --- /usr/bin/make -B buildworld
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything..
TB --- 2003-11-09 20:41:26 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
>>> Kernel build for GENERIC started on Sun Nov  9 20:41:26 GMT 2003
>>> Kernel build for GENERIC completed on Sun Nov  9 20:56:16 GMT 2003
TB --- 2003-11-09 20:56:16 - generating LINT kernel config
TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf
TB --- /usr/bin/make -B LINT
TB --- 2003-11-09 20:56:16 - building LINT kernel
TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src
TB --- /usr/bin/make buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Sun Nov  9 20:56:16 GMT 2003
[...]
cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99  -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL 
-include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF 
-falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings 
-mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/i4b/layer3/i4b_q932fac.c
cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99  -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL 
-include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -DGPROF 
-falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings 
-mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/i4b/layer4/i4b_i4bdrv.c
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/i4b/layer4/i4b_i4bdrv.c: In 
function `i4bputqueue':
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/i4b/layer4/i4b_i4bdrv.c:823: 
error: `TTIPRI' undeclared (first use in this function)
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/i4b/layer4/i4b_i4bdrv.c:823: 
error: (Each undeclared identifier is reported only once
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/i4b/layer4/i4b_i4bdrv.c:823: 
error: for each function it appears in.)
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/i4b/layer4/i4b_i4bdrv.c: In 
function `i4bputqueue_hipri':
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/i4b/layer4/i4b_i4bdrv.c:866: 
error: `TTIPRI' undeclared (first use in this function)
*** Error code 1

Stop in 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/LINT.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src.
TB --- 2003-11-09 21:04:34 - TB --- /usr/bin/make returned exit code  1 
TB --- 2003-11-09 21:04:34 - TB --- ERROR: failed to build lint kernel
TB --- 2003-11-09 21:04:34 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: serial console oddity

[Don Lewis]

On  9 Nov, Don Lewis wrote:
> On  9 Nov, Bruce Evans wrote:
>> On Sat, 8 Nov 2003, Don Lewis wrote:

>>> This is totally consistent until I "kill
>>> -HUP" syslogd, which I believe causes syslogd to close and open
>>> /dev/console, after which the syslog output appears correct on the
>>> console. When the syslogd output is being corrupted, I can cat a file to
>>> /dev/console and the output appears to be correct.
>> 
>> When I debugged this, syslogd didn't seem to keep the console open,
>> so the open()/close() in ttymsg() always caused the problem.  I didn't
>> notice killing syslogd makes a difference.  Perhaps it helps due to a
>> missing close.  Holding the console open may be a workaround or even
>> the correct fix.  It's not clear where this should be done (should all
>> clients of ttymsg() do it?).  Running getty on the console or on the
>> underlying tty device should do it accidentally.
> 
> It looks to me like syslogd keeps the console open in addition to the
> open()/close() in ttymsg().  cfline() calls open() on anything that
> begins with '/' and calls isatty() to figure out whether it should set
> the type to F_CONSOLE, F_TTY, or F_FILE, and init() closes the file
> descriptor for all of these when syslogd is HUPed.
> 
> I wonder if the console descriptor is getting revoked ...

That appears to be the situation:

scratch:~ 101>cat /var/run/syslog.pid 
275
scratch:~ 102>fstat -p 275
USER CMD  PID   FD MOUNT  INUM MODE SZ|DV R/W
root syslogd  275 root / 2 drwxr-xr-x1024  r
root syslogd  275   wd / 2 drwxr-xr-x1024  r
root syslogd  275 text /575452 -r-xr-xr-x   32204  r
root syslogd  2750 /dev  8 crw-rw-rw-null rw
root syslogd  2751 /dev  8 crw-rw-rw-null rw
root syslogd  2752 /dev  8 crw-rw-rw-null rw
root syslogd  2753* local dgram c6c97000
root syslogd  2754* internet6 dgram udp c6c84ee0
root syslogd  2755* internet dgram udp c6c85000
root syslogd  2756 /dev 17 crw---klog  r
root syslogd  2758 - - bad-
root syslogd  2759 /447635 -rw-r--r--   45602  w
root syslogd  275   10 /450144 -rw---   0  w
root syslogd  275   11 /448526 -rw---   85593  w
root syslogd  275   12 /447600 -rw-r-3119  w
root syslogd  275   13 /450142 -rw-r--r--   19324  w
root syslogd  275   14 /447744 -rw-r--r-- 274  w
root syslogd  275   15 /447492 -rw---   19063  w
root syslogd  275   16 /448732 -rw---   15508  w
root syslogd  275   17 /450145 -rw-r-   0  w
root syslogd  275   18 /450146 -rw-r-   0  w

If we could somehow keep the console open, that would probably be a
sufficient fix for the problem of discarded output.  We probably don't
care in the case of messages to users' terminals, since the users
presumably have those devices open.  There's no such guarantee in the
case of the console.


BTW, here's an example where I HUPed syslogd so that it works, but the
rc script output is truncated.  I think the partial message at the
beginning of the 'vnlru' line should be "Stopping cron.".

Nov  9 12:46:54 scratch shutdown: reboot by dl: 
Stopping inetd.
Shutting down daemon processes:killall: Nov  9 12:46:56 scratch upsmon[504]: upsmon 
parent: exiting (child exited)
warning: kill -TERM 504: No such process
Nov  9 12:46:56 scratch kernel: pid 502 (upsd), uid 66: exited on signal 6
.
Stopping cWaiting (max 60 seconds) for system process `vnlru' to stop...stopped
Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped
Waiting (max 60 seconds) for system process `syncer' to stop...stopped

syncing disks, buffers remaining... 12 12 
done
Uptime: 13h34m21s
Shutting down ACPI
Rebooting...


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: tcp hostcache and ip fastforward for review

[Jonathan Mini]

On Nov 9, 2003, at 8:19 AM, Andre Oppermann wrote:

  - DoS attack 2: make MSS very low on local side of connection
and send mny small packet to remote host. For every packet
(eg. 2 bytes payload) a sowakeup is done to the listening
process. Consumes a lot of CPU there.
This sounds as if it might be worthwhile to add a delay to
the TF_NODELAY case for receive processing as well.
--
Jonathan Mini
[EMAIL PROTECTED]
http://www.freebsd.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

nextboot.conf on sparc64

[Andre Guibert de Bruet]

Hi,

It appears that nexboot.conf isn't cleared on boot on sparc64. I tested
this with on:

FreeBSD ultra.home 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Fri Nov  7 23:59:19
GMT 2003 root@:/usr/src/sys/sparc64/compile/GENERIC sparc64

The nextboot command was invoked with:
nextboot -o "-s" -k kernel

I have reason to believe that the problem is due to / being read-only
on single-user boot (which is a good thing for fsck purposes) so the file
cannot be unlinked. When the system boots multi-user though, all
appropriate filesystems are mounted rw, and nexboot.conf still doesn't get
cleared. Then again, I could be wrong... :)

Any ideas?

Regards,

> Andre Guibert de Bruet | Enterprise Software Consultant >
> Silicon Landmark, LLC. | http://siliconlandmark.com/>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

gcc ICE building R-letter is gone with gcc 3.3.3

[Michael L. Squires]

The internal compiler error compiling R-letter (R-1.8.0) under 5-CURRENT  went 
away when gcc was updated to 3.3.3.

Mike Squires
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Typos in -CURRENT?

[Scott Long]

Andre Guibert de Bruet wrote:
Hi,

The Online Merriam-Webster dictionary (m-w.com) doesn't have an entry for
the word 'recognised', yet it features throughout our source tree
(Including manpages).
The following was run on CURRENT as of a few hours ago:

bling# grep -R recognised /usr/src/ | wc -l
 155
bling# grep -R recognized /usr/src/ | wc -l
1898
This isn't a color/colour type of thing...

Regards,


Andre Guibert de Bruet | Enterprise Software Consultant >
Silicon Landmark, LLC. | http://siliconlandmark.com/>

www.m-w.com does indeed have a listing for 'recognise' and notes
that it is a variant of 'recognize'.  Appending a 'd' to the end
of both words is valid and denotes past tense.
As we have gone over many, many times in the past, we recognise
no preference in British vs American spellings in our source tree
and man pages.
Scott

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Typos in -CURRENT?

[Julian St.]

On Sun, 9 Nov 2003 15:27:17 -0500 (EST)
Andre Guibert de Bruet <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> The Online Merriam-Webster dictionary (m-w.com) doesn't have an entry
> for the word 'recognised', yet it features throughout our source tree
> (Including manpages).
[...]
> This isn't a color/colour type of thing...

It is. At least according to http://dict.leo.org/ (English-German
dictionary)

->
recognised  adj.  chiefly  [Brit.]


Regards,
Julian
-- 
Just wait until I reply to YOUR reply!
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Typos in -CURRENT?

[Andre Guibert de Bruet]

Hi,

The Online Merriam-Webster dictionary (m-w.com) doesn't have an entry for
the word 'recognised', yet it features throughout our source tree
(Including manpages).

The following was run on CURRENT as of a few hours ago:

bling# grep -R recognised /usr/src/ | wc -l
 155
bling# grep -R recognized /usr/src/ | wc -l
1898

This isn't a color/colour type of thing...

Regards,

> Andre Guibert de Bruet | Enterprise Software Consultant >
> Silicon Landmark, LLC. | http://siliconlandmark.com/>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

New EHCI device ID

[Alexander Leidinger]

Hi,

I get this in the dmesg:
---snip---
ehci0:  mem 0xfc00-0xfc0003ff irq 12 at d
evice 29.7 on pci0
ehci0: (New EHCI DeviceId=0x24dd8086)
---snip---

pciconv tells me:
---snip---
[EMAIL PROTECTED]:29:7:class=0x0c0320 card=0x24dd17f2 chip=0x24dd8086 rev=0x02 
hdr=0x00
vendor   = 'Intel Corporation'
device   = '82801EB/ER (ICH4/ICH5R) USB EHCI Controller'
class= serial bus
subclass = USB
---snip---

It's an Intel 865PE chipset.

Bye,
Alexander.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: serial console oddity

[Don Lewis]

On  9 Nov, Bruce Evans wrote:

> For a non-half-baked fix, do somethng like:
> - never block in ttymsg(), but always wait for output to drain using
>   tcdrain() in a single child process.  It's probably acceptable for
>   this to not report errors to ttymsg()'s caller.
> - limit children better.  I think we now fork children iff writev()
>   returns EWOULDBLOCK and this happens mainly when the tty buffers
>   fill up due to clocal being off and the external console not
>   listening.  Handling this right seems to require handing off the
>   messages to a single child process that can buffer the messages
>   in userland and can block writing and draining them.  Blocked write()s
>   and tcdrain()s are easy enough to handle in a specialized process by
>   sending signals to abort them.

Another way of handling EWOULDBLOCK would be to add the descriptor to
syslogd's select loop instead of forking a child process.  There is
still the issue of how to handle blocking trdrain()s or close()s,
perhaps a thread.  Syslogd should not attempt to re-open the device if a
tcdrain() or close() was in progress.

BTW, it sounds like the pending output should not be discarded by the
close(), the termios(4) man page says:

   Closing a Terminal Device File
 The last process to close a terminal device file causes any output to be
 sent to the device and any input to be discarded.

If output is discarded in the O_NONBLOCK case, it seems to be
undocumented.  Should close() return ENOSPC in this case?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

panic: Most recently used by mount

[Lukas Ertl]

Hi,

I get the following repeatable panic by just doing:

# mount /cdrom

when there's no disk in the drive.  The panic doesn't happen immediately,
the mount call returns and gives the error 'device not configured' (as it
should), but if I wait some time, it panics.

The system is:
FreeBSD 5.1-CURRENT #4: Sat Nov  8 01:15:35 CET 2003

I somehow suspect the GEOMified SCSI CD driver, since I can do the same on
my laptop (which has an IDE DVD-ROM) just fine.

Attached is the backtrace and the dmesg.

---8<---
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
panic: Most recently used by mount

panic messages:
---
panic: Most recently used by mount

Dumping 255 MB
 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
---
Reading symbols from 
/usr/obj/usr/src/sys/LEELOU/modules/usr/src/sys/modules/ipfw/ipfw.ko.debug...done.
Loaded symbols for 
/usr/obj/usr/src/sys/LEELOU/modules/usr/src/sys/modules/ipfw/ipfw.ko.debug
Reading symbols from /boot/kernel/daemon_saver.ko...done.
Loaded symbols for /boot/kernel/daemon_saver.ko
Reading symbols from 
/usr/obj/usr/src/sys/LEELOU/modules/usr/src/sys/modules/linux/linux.ko.debug...done.
Loaded symbols for 
/usr/obj/usr/src/sys/LEELOU/modules/usr/src/sys/modules/linux/linux.ko.debug
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) where
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1  0xc04731cd in db_fncall (dummy1=0, dummy2=0, dummy3=0,
dummy4=0xd3085778 "") at /usr/src/sys/ddb/db_command.c:548
#2  0xc0472f6a in db_command (last_cmdp=0xc07891a0, cmd_table=0x0,
aux_cmd_tablep=0xc0739b18, aux_cmd_tablep_end=0xc0739b1c)
at /usr/src/sys/ddb/db_command.c:346
#3  0xc0473078 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#4  0xc0475db9 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:73
#5  0xc06be632 in kdb_trap (type=3, code=0, regs=0xd30858b8)
at /usr/src/sys/i386/i386/db_interface.c:171
#6  0xc06d0f2b in trap (frame=
  {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 1, tf_esi = -1066205972, tf_ebp = 
-754427644, tf_isp = -754427676, tf_ebx = 0, tf_edx = 0, tf_ecx = 0, tf_eax = 18, 
tf_trapno = 3, tf_err = 0, tf_eip = -109875, tf_cs = 8, tf_eflags = 642, tf_esp = 
-1066196186, tf_ss = -1066285008})
at /usr/src/sys/i386/i386/trap.c:580
#7  0xc06bff08 in calltrap () at {standard input}:94
#8  0xc057a37c in panic (fmt=0xc072fcec "Most recently used by %s\n")
at /usr/src/sys/kern/kern_shutdown.c:534
#9  0xc069b377 in mtrash_ctor (mem=0xc2fe1800, size=0, arg=0x0)
at /usr/src/sys/vm/uma_dbg.c:137
#10 0xc0699ca4 in uma_zalloc_arg (zone=0xc103acc0, udata=0x0, flags=2)
at /usr/src/sys/vm/uma_core.c:1413
#11 0xc056ef16 in malloc (size=3238243520, type=0xc0769c20, flags=2)
at /usr/src/sys/vm/uma.h:234
#12 0xc0552881 in elf32_load_file (p=0xc2e9b3c8, file=0x0, addr=0xd3085a9c,
entry=0x0, pagesize=4096) at /usr/src/sys/kern/imgact_elf.c:519
#13 0xc0553066 in exec_elf32_imgact (imgp=0xd3085b8c)
at /usr/src/sys/kern/imgact_elf.c:825
#14 0xc05613cc in kern_execve (td=0xc2e9d140, fname=---Can't read userspace from dump, 
or kernel process---)
at /usr/src/sys/kern/kern_exec.c:311
#15 0xc0561de0 in execve (td=0x0, uap=0x0) at /usr/src/sys/kern/kern_exec.c:695
#16 0xc06d17f2 in syscall (frame=
  {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135278700, tf_esi = 135278752, 
tf_ebp = -1077941128, tf_isp = -754426508, tf_ebx = 0, tf_edx = -1077940370, tf_ecx = 
135278639, tf_eax = 59, tf_trapno = 12, tf_err = 2, tf_eip = 134716943,---Type 
 to continue, or q  to quit---
 tf_cs = 31, tf_eflags = 646, tf_esp = -1077941156, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1010
#17 0xc06bff5d in Xint0x80_syscall () at {standard input}:136
---Can't read userspace from dump, or kernel process---
---8<---


---8<---
Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.1-CURRENT #4: Sat Nov  8 01:15:35 CET 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/LEELOU
Preloaded elf kernel "/boot/kernel/kernel" at 0xc089f000.
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Duron(tm) Processor (700.03-MHz 686-class CPU)
  Origin = "AuthenticAMD"  Id = 0x631  Stepping = 1
  
Features=0x183f9ff
  AMD Features=0xc044
real memory  = 268369920 (255 MB)
avail memory = 251052032 (239 MB)
Pentium Pro MTRR support enabled
acpi0:  on motherboard
pcibios: BIOS version 2.10
Using $PIR table, 9 entries at 0xc00fddd0
acpi0: Power Button (fixed)
Timecounter "ACPI-fast" frequency 3579545 Hz qua

tcp hostcache and ip fastforward for review

[Andre Oppermann]

Hello all,

this patch contains three things (to be separated for committing):

 tcp_hostcache

  - removes protocol cloning from routing table (IPv4+6)
  - removes rtentry pointer from inpcb and in6pcb
  - removes ip route cache in ip_input.c (locking much easier)
  - removes most (tcp specific) metrics from rtentry metrics
  - adds a hostcache table which carries the metrics for tcp
  - works transparently for IPv4 and IPv6
  - is designed for concurrent access in SMP environments
  - significant reduction of routing table size (no cloning anymore)
  - eases many routing table locking situations in ip/tcp code

 ip_fastforward

  - removes ip_flow forwarding code
  - adds full direct process-to-completion IPv4 forwarding code
  - handles ip fragmentation incl. hw support (ip_flow did not)
  - supports ipfw and ipfilter (ip_flow did not)
  - supports divert and ipfw fwd (ip_flow did not)
  - drops anything it can't handle back to normal ip_input


 tcp bug fixes and MSS DoS attack prevention
  - fixes wrong goto in tcp_input.c which sends two RST packets
instead of one
  - adds tcp_minmss sysctl which limits the lowest MSS we accept
during TCP setup and path MTU discovery
  - adds tcp_minmssoverload which disconnects a TCP session if
it receives too many (1000) packets per second whose average
segement size is lower than tcp_minmss
  - DoS attack 1: send very low MSS in syn to remote host,
request large data stream (file) and let other host produce
mny small packets which consumes a lot of CPU
  - DoS attack 2: make MSS very low on local side of connection
and send mny small packet to remote host. For every packet
(eg. 2 bytes payload) a sowakeup is done to the listening
process. Consumes a lot of CPU there.


I'm looking for any comments, testing and bug reports (if any ;-).

Hajimu-san, I'm looking especially for comments on whether my changes
to IPv6 are correct wrt IPv6 concepts. (I hope they are).

Hopefully these things can make it into -CURRENT before 5.2 release.
Sam Leffler has indicated he is willing to commit it when there are
no objections to the implementation and the code. I am fully committed
to fix any bugs that might come up after it's in the tree.

I am running my machines with these changes for a couple of weeks now
without any problems. The attached patch obviously doesn't have that
much exposure because I've had to update it all the time to track
Sam's locking changes and UME's IPv6 updates.


The patch is here (relative to -CURRENT as of 2003-11-09):

 http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031109.patch

I'm grateful for everyone who tries out the patch and reports their
success and/or other findings.

-- 
Andre
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: hard lockup with new interrupt code, possible cause irq14: ata0

[Florian C. Smeets]

Barney Wolff wrote:

Hey Barney,

Try adding
options   NO_MIXED_MODE
to your conf.  That fixed boot-time hangs on my Asus A7M266-D.
Thanks for the reply but this didn't work for me. I'm goning to 
investigate further.

Regards,
flo
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: serial console oddity

[Don Lewis]

On  9 Nov, Bruce Evans wrote:
> On Sat, 8 Nov 2003, Don Lewis wrote:
> 
>> I've been seeing some wierd things for many months when using a serial
>> console on my -CURRENT box.  I finally had a chance to take a closer
>> look today.
>>
>> It looks like the problem is some sort of interference between kernel
>> output to the console and userland writes to /dev/console.  I typically
>> see syslogd output to the console get corrupted.  Each message that
>> syslogd writes seems to get truncated or otherwise corrupted.  The most
>> common thing I see is that each syslog message is reduced to a space and
>> the first character of the month, or sometimes just a space, or
>> sometimes nothing at all.
> 
> This is (at least primarily) a longstanding bug in ttymsg().  It uses
> nonblocking mode so that it doesn't block in write() or close().  For
> the same reason, it doesn't wait for output to drain before close().
> If the close happens to be the last one on the device, this causes any
> data buffered in the tty and lower software layers to be discarded
> cleanly and any data in lower hardware layers to by discarded in a
> driver plus hardware-dependent way (usually not so cleanly, especially
> for the character being transmitted).

I didn't think of a flush on close problem because I thought syslogd
always kept the console open.

>> This is totally consistent until I "kill
>> -HUP" syslogd, which I believe causes syslogd to close and open
>> /dev/console, after which the syslog output appears correct on the
>> console. When the syslogd output is being corrupted, I can cat a file to
>> /dev/console and the output appears to be correct.
> 
> When I debugged this, syslogd didn't seem to keep the console open,
> so the open()/close() in ttymsg() always caused the problem.  I didn't
> notice killing syslogd makes a difference.  Perhaps it helps due to a
> missing close.  Holding the console open may be a workaround or even
> the correct fix.  It's not clear where this should be done (should all
> clients of ttymsg() do it?).  Running getty on the console or on the
> underlying tty device should do it accidentally.

It looks to me like syslogd keeps the console open in addition to the
open()/close() in ttymsg().  cfline() calls open() on anything that
begins with '/' and calls isatty() to figure out whether it should set
the type to F_CONSOLE, F_TTY, or F_FILE, and init() closes the file
descriptor for all of these when syslogd is HUPed.

I wonder if the console descriptor is getting revoked ...

>> I truss'ed syslogd, and it appears to be working normally, the writev()
>> call that writes the data to the console appears to be writing the
>> correct character count, so it would appear that the fault is in the
>> kernel.
> 
> If there are any kernel bugs in this area, then they would be that
> last close of the console affects the underlying tty.  The multiple
> console changes are quite likely to have broken this if getty is run
> on the underlying tty (they silently discarded the half-close of the
> underlying tty which was needed to avoided trashing some of its state
> when only the console is closed).

I'm not running getty on my serial console.  It is running on ttyv*. I'm
only using the serial console to capture kernel stack traces, etc.

>> The problem doesn't appear to be specific to syslogd, because I have
>> seen the output from the shutdown scripts that goes to the console get
>> truncated as well.
> 
> Yes, in theory it should affect anything that uses ttymsg() or does
> direct non-blocking writes without waiting for the output to drain.

> Here are some half-baked fixes.  The part that clears O_NONBLOCK is
> wrong, and the usleep() part is obviously a hack.  ttymsg() shouldn't
> block even in close(), since if the close is in the parent ttymsg()
> might block forever and if the close() is in a forked child then
> blocking could create zillions of blocked children.
> 
> Another part of the patch is concerned with limiting forked children.
> If I were happy with that part then blocking would not be so bad.  In
> practice, I don't have enough system activity for blocked children to
> be a problem.  To see the problem with blocked children, do something
> like the following:
> - turn off clocal on the console so that the console can block better.
>   For sio consoles this often requires turning it off in the lock-state
>   device, since the driver defends against this foot shooting by locking
>   it on.
> - hold the console open or otherwise avoid the original bug in this
>   thread, else messages will just be discarded in close() faster than
>   they can pile up.
> - turn off your external console device or otherwise drop carrier.
> - send lots of messages.

I ran into this years ago when I was using actual terminals for console
devices and someone typed a ^S and went away.  The failure mode wasn't
pretty.  It was probably in the days when I was managing Masscomp boxes,
but it might have been the first batch o

Re: ATAPI-CD corruption since GEOMification (& possible fix)

[Soren Schmidt]

It seems Peter Edwards wrote:
> With a -current built after atapi-cd was changed over to GEOM, reads
> from a filesystem mounted on a CD device are being corrupted, with
> junk being inserted into the file from offset 63489 onwards.
> 
> I had a quick look around atapi-cd.c, and I think I spotted the
> problem: applying this patch certainly stopped the corruption
> I was seeing. Anyone else seeing this? Can someone verify that
> this is indeed the correct fix?

Yeps looks like what I intended, but apprarently didn't type :(

Fix committed, thanks!

-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: serial console oddity

[Bruce Evans]

On Sat, 8 Nov 2003, Don Lewis wrote:

> I've been seeing some wierd things for many months when using a serial
> console on my -CURRENT box.  I finally had a chance to take a closer
> look today.
>
> It looks like the problem is some sort of interference between kernel
> output to the console and userland writes to /dev/console.  I typically
> see syslogd output to the console get corrupted.  Each message that
> syslogd writes seems to get truncated or otherwise corrupted.  The most
> common thing I see is that each syslog message is reduced to a space and
> the first character of the month, or sometimes just a space, or
> sometimes nothing at all.

This is (at least primarily) a longstanding bug in ttymsg().  It uses
nonblocking mode so that it doesn't block in write() or close().  For
the same reason, it doesn't wait for output to drain before close().
If the close happens to be the last one on the device, this causes any
data buffered in the tty and lower software layers to be discarded
cleanly and any data in lower hardware layers to by discarded in a
driver plus hardware-dependent way (usually not so cleanly, especially
for the character being transmitted).

> This is totally consistent until I "kill
> -HUP" syslogd, which I believe causes syslogd to close and open
> /dev/console, after which the syslog output appears correct on the
> console. When the syslogd output is being corrupted, I can cat a file to
> /dev/console and the output appears to be correct.

When I debugged this, syslogd didn't seem to keep the console open,
so the open()/close() in ttymsg() always caused the problem.  I didn't
notice killing syslogd makes a difference.  Perhaps it helps due to a
missing close.  Holding the console open may be a workaround or even
the correct fix.  It's not clear where this should be done (should all
clients of ttymsg() do it?).  Running getty on the console or on the
underlying tty device should do it accidentally.

> I truss'ed syslogd, and it appears to be working normally, the writev()
> call that writes the data to the console appears to be writing the
> correct character count, so it would appear that the fault is in the
> kernel.

If there are any kernel bugs in this area, then they would be that
last close of the console affects the underlying tty.  The multiple
console changes are quite likely to have broken this if getty is run
on the underlying tty (they silently discarded the half-close of the
underlying tty which was needed to avoided trashing some of its state
when only the console is closed).

> The problem doesn't appear to be specific to syslogd, because I have
> seen the output from the shutdown scripts that goes to the console get
> truncated as well.

Yes, in theory it should affect anything that uses ttymsg() or does
direct non-blocking writes without waiting for the output to drain.

> I have my serial console running at the default 9600 bps.

I always use 115200 bps and the symptoms are similar right down to
normally getting only the first character of the month name followed
by 0-1 bytes of garbage.  The first character of the month name is
just the first character of the message.  Apparently my systems are
fast enough for close() to be called before transmission of the second
character has completed (2 * 87+ usec at 115200 bps).

Here are some half-baked fixes.  The part that clears O_NONBLOCK is
wrong, and the usleep() part is obviously a hack.  ttymsg() shouldn't
block even in close(), since if the close is in the parent ttymsg()
might block forever and if the close() is in a forked child then
blocking could create zillions of blocked children.

Another part of the patch is concerned with limiting forked children.
If I were happy with that part then blocking would not be so bad.  In
practice, I don't have enough system activity for blocked children to
be a problem.  To see the problem with blocked children, do something
like the following:
- turn off clocal on the console so that the console can block better.
  For sio consoles this often requires turning it off in the lock-state
  device, since the driver defends against this foot shooting by locking
  it on.
- hold the console open or otherwise avoid the original bug in this
  thread, else messages will just be discarded in close() faster than
  they can pile up.
- turn off your external console device or otherwise drop carrier.
- send lots of messages.

%%%
Index: ttymsg.c
===
RCS file: /home/ncvs/src/usr.bin/wall/ttymsg.c,v
retrieving revision 1.11
diff -u -2 -r1.11 ttymsg.c
--- ttymsg.c11 Oct 2002 14:58:34 -  1.11
+++ ttymsg.c11 Oct 2002 18:13:51 -
@@ -32,14 +32,16 @@
  */

-#include 
-
-__FBSDID("$FreeBSD: src/usr.bin/wall/ttymsg.c,v 1.11 2002/10/11 14:58:34 mike Exp $");
-
+#if 0
 #ifndef lint
-static const char sccsid[] = "@(#)ttymsg.c 8.2 (Berkeley) 11/16/93";
+static char sccsid[] = "@(#)ttymsg.c   8.2 (Berkeley) 11/16/93";
+#e

Re: ssh port forwarding changed under 5-CURRENT vs. STABLE?

[Aditya]

On Sat, Nov 08, 2003 at 11:01:58PM +, David Taylor wrote:
> > > Is something else (e.g. another ssh session) already bound to that port?
> > 
> > nope -- and I've tried all sorts of ports other than 8000 too:
> 
> (I'm assuming you do have a lo0 device with 127.0.0.1)

duh! that's exactly it, I didn't have lo0 config'd with 127.0.0.1 -- now that
I do, it's fine!

Thanks,
Adi
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

serial console oddity

[Don Lewis]

I've been seeing some wierd things for many months when using a serial
console on my -CURRENT box.  I finally had a chance to take a closer
look today.

It looks like the problem is some sort of interference between kernel
output to the console and userland writes to /dev/console.  I typically
see syslogd output to the console get corrupted.  Each message that
syslogd writes seems to get truncated or otherwise corrupted.  The most
common thing I see is that each syslog message is reduced to a space and
the first character of the month, or sometimes just a space, or
sometimes nothing at all.  This is totally consistent until I "kill
-HUP" syslogd, which I believe causes syslogd to close and open
/dev/console, after which the syslog output appears correct on the
console. When the syslogd output is being corrupted, I can cat a file to
/dev/console and the output appears to be correct.

I truss'ed syslogd, and it appears to be working normally, the writev()
call that writes the data to the console appears to be writing the
correct character count, so it would appear that the fault is in the
kernel.

The problem doesn't appear to be specific to syslogd, because I have
seen the output from the shutdown scripts that goes to the console get
truncated as well.

I have my serial console running at the default 9600 bps.

I dug around in the source in search of the problem, but I got lost in a
maze of twisty little passages.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

select + signal + truss => LOR

[Don Lewis]

I don't believe I've seen any reports of this particular lock order
reversal.  I got it by pointing truss at syslogd.  My kernel and world
were built from a cvsup run slightly before Fri Nov  7 14:50:18 PST
2003.


 Sleeping on "stopevent" with the following non-sleepable locks held:
exclusive sleep mutex sigacts r = 0 (0xc6bc0aa8) locked @ /usr/src/sys/kern/kern
_condvar.c:289
lock order reversal
 1st 0xc6bc0aa8 sigacts (sigacts) @ /usr/src/sys/kern/kern_condvar.c:289
 2nd 0xc6bbabc4 process lock (process lock) @ /usr/src/sys/kern/kern_synch.c:309
Stack backtrace:
backtrace(c08a4327,c6bbabc4,c08a0922,c08a0922,c08a1964) at backtrace+0x17
witness_lock(c6bbabc4,8,c08a1964,135,c08a05a9) at witness_lock+0x672
_mtx_lock_flags(c6bbabc4,0,c08a1964,135,) at _mtx_lock_flags+0xba
msleep(c6bbac98,c6bbabc4,5c,c08a4b24,0) at msleep+0x794
stopevent(c6bbab58,2,e,822,c096d440) at stopevent+0x85
issignal(c640,2,c08a1463,bd,c6bbab58) at issignal+0x168
cursig(c640,0,c089e483,121,0) at cursig+0xf0
cv_wait_sig(c0991f34,c0991f00,c08a492e,348,4) at cv_wait_sig+0x448
kern_select(c640,7,8055060,0,0) at kern_select+0x526
select(c640,e5f26d10,c08bea62,3ee,5) at select+0x66
syscall(2f,2f,2f,8,1) at syscall+0x2c0
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (93), eip = 0x480d03ff, esp = 0xbfbff79c, ebp = 0xbfbffd98 ---
Sleeping on "stopevent" with the following non-sleepable locks held:
exclusive sleep mutex sigacts r = 0 (0xc6bc0aa8) locked @ /usr/src/sys/kern/subr
_trap.c:260
Sleeping on "stopevent" with the following non-sleepable locks held:
exclusive sleep mutex sigacts r = 0 (0xc6bc0aa8) locked @ /usr/src/sys/kern/subr
_trap.c:260



___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: build problems

[Jason]

matti k wrote:

On Sun, 09 Nov 2003 00:36:57 -0500
Jason <[EMAIL PROTECTED]> wrote:
 

I have had problems finishing buildworld and the problem is the same
each time the build fails.  It has failed 4 times at
file:///usr/src/gnu/usr.bin/cvs/doc/.  I have cvsuped 3 times in 2
days.  I am running 5.1.  Any info you might have would be helpful.
Thanks,
Jason
   



Are you using -02 optimizations in /etc/make.conf ?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
 

No, just the basics.  How does it look?
CPUTYPE=athlon-xp
CFLAGS=-O -pipe
CXXFLAGS+=-fmemoize-lookups -fsave-memoized
COPTFLAGES=-O -pipe
jason
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"