Re: nmbclusters
It's always only been boot-time tunable (well, always is of course relative to my time with FreeBSD -- Dag-Erling has been around longer and therefore recounts its more comprehensive history). In 6.0-CURRENT there was an intention to make it sysctl (runtime) tunable, as it finally became at least theoretically possible to do so. I have recently seen a patch floating around from Paul Saab (ps@) who has finally made it runtime tunable -- at least enough so that it can be _increased_. Not sure if he has committed it, yet. Note that _decreasing_ nmbclusters at run-time will probably never be possible -- implementing is too difficult for what it would be worth. Cheers, Bosko On 3/29/06, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Conrad J. Sabatier [EMAIL PROTECTED] writes: Chris [EMAIL PROTECTED] wrote: so [kern.ipc.nmbclusters] has no affect, has this become a read only tunable again only settable in loader.conf? To the best of my knowledge, this has *always* been a loader tunable, not configurable on-the-fly. kern.ipc.nmbclusters is normally computed at boot time. A compile- time option to override it was introduced in 2.0-CURRENT. At that time, it was defined in param.c. A read-only sysctl was introduced in 3.0-CURRENT. It moved from param.c to uipc_mbuf.c in 4.0-CURRENT, then to subr_mbuf.c when mballoc was introduced in 5.0-CURRENT; became a tunable at some point after that; then moved again to kern_mbuf.c when mballoc was replaced with mbuma in 6.0-CURRENT. That is the point where it became read-write, for no good reason that I can see; setting it at runtime has no effect, because the size of the mbuf zone is determined at boot time. Perhaps Bosko (who wrote both mballoc and mbuma, IIRC) knows. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] -- Bosko Milekic [EMAIL PROTECTED] To see all the content I generate on the web, check out my Peoplefeeds profile at: http://peoplefeeds.com/bosko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HTT/SMP does not start 2nd processor
Make sure the acpi kernel module is being loaded on startup. See acpi(4). -Bosko On Tue, May 10, 2005 at 04:57:47PM +0100, Pete French wrote: I have two P4 machines here, both with processors supporting hyperthreading, and running identical SMP kernels from 5.4-RELEASE. One runs with two logical processors and the oother doesn't. This has been puzlling me all day. On the machine where the second CPU does not start up, HTTP is enabled in the BIOS, and I get the following in dmesg: CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.52-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf29 Stepping = 9 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,C MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Hyperthreading: 2 logical CPUs real memory = 536739840 (511 MB) avail memory = 515579904 (491 MB) MPTable: COMPAQ Workstation ioapic0: Changing APIC ID to 1 ioapic0: Assuming intbase of 0 ioapic0 Version 2.0 irqs 0-23 on motherboard On the one which starts up the 2nd CPU the equivalent part is: CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2392.04-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf29 Stepping = 9 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,C MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Hyperthreading: 2 logical CPUs real memory = 536301568 (511 MB) avail memory = 515137536 (491 MB) ACPI APIC Table: DELL WS 450 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 8 ioapic1: Changing APIC ID to 9 ioapic2: Changing APIC ID to 10 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard ioapic2 Version 2.0 irqs 48-71 on motherboard So both are reporting 2 logical CPU's, but only the second is then detecting this as a multiprocessor system. I notice that one syas it is using an ACPI APIC table and the other (that does not start) is just finding an MPTable. That seems to be the difference between them. Does anyone have any suggestions ? I dont really understand how this stuff is detected, so I am not sure how to sart digging into this. It is obviously finding a dual CPU processor, so why isn't it then detecting it as a multiprocessor system ? *puzzled* -pcf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mbufs on 5.3-STABLE possible bug
On Tue, Feb 01, 2005 at 01:18:38PM +, Chris wrote: Sorry, yes have tried it, I am still seeing a negative perofrmance difference with the setting on 0 but the gap is greatly reduced and its something that is a lot more acceptable, at most it has been 10% worse then if left on auto or set to a value. Let me know if there is any specific types of tests you want doing. Chris I'm not sure I understand. Setting it to zero _means_ auto. I'll likely commit the patch. Thanks. -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mbufs on 5.3-STABLE possible bug
Can you please give an update? -Bosko On Fri, Jan 21, 2005 at 08:43:10PM +, Chris wrote: I apologise I have yet to test the patch, but will try and do so as soon as possible by the end of the weekend. Chris On Fri, 21 Jan 2005 12:52:19 -0500, Bosko Milekic [EMAIL PROTECTED] wrote: Can you please give an update? -Bosko On Sat, Jan 08, 2005 at 08:43:53PM +, Chris wrote: thanks I will try this out as soon as possible and report back. On Thu, 6 Jan 2005 17:38:54 -0500, Bosko Milekic [EMAIL PROTECTED] wrote: Please try the attached patch. It's not exactly perfect but it might solve your problem. Let me know. -Bosko On Thu, Jan 06, 2005 at 02:12:33PM +, Chris wrote: Hi After reading the release notes and upgrading my server's I had set the following in my /boot/loader.conf. kern.ipc.nmbclusters=0 This is supposed to make the limit to unlimited as I understood from the docs, but a user on one of my server's reported slow download speeds he was testing with wget and fetch, so we compared with another FreeBSD server (5.2.1) on the same network and sure enough there was a massive difference (45mbit on the other server 5mbit on mine), I spent ages checking all my tweaks and changes I made comparing between the 2 server's and ended up checking my loader.conf and tried setting a value and leaving it as auto, both of these changes fixed the download speed issue but setting to 0 introduces the problem. Has anyone else noticed this? Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mbufs on 5.3-STABLE possible bug
Can you please give an update? -Bosko On Sat, Jan 08, 2005 at 08:43:53PM +, Chris wrote: thanks I will try this out as soon as possible and report back. On Thu, 6 Jan 2005 17:38:54 -0500, Bosko Milekic [EMAIL PROTECTED] wrote: Please try the attached patch. It's not exactly perfect but it might solve your problem. Let me know. -Bosko On Thu, Jan 06, 2005 at 02:12:33PM +, Chris wrote: Hi After reading the release notes and upgrading my server's I had set the following in my /boot/loader.conf. kern.ipc.nmbclusters=0 This is supposed to make the limit to unlimited as I understood from the docs, but a user on one of my server's reported slow download speeds he was testing with wget and fetch, so we compared with another FreeBSD server (5.2.1) on the same network and sure enough there was a massive difference (45mbit on the other server 5mbit on mine), I spent ages checking all my tweaks and changes I made comparing between the 2 server's and ended up checking my loader.conf and tried setting a value and leaving it as auto, both of these changes fixed the download speed issue but setting to 0 introduces the problem. Has anyone else noticed this? Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mbufs on 5.3-STABLE possible bug
Please try the attached patch. It's not exactly perfect but it might
solve your problem. Let me know.
-Bosko
On Thu, Jan 06, 2005 at 02:12:33PM +, Chris wrote:
Hi
After reading the release notes and upgrading my server's I had set
the following in my /boot/loader.conf.
kern.ipc.nmbclusters=0
This is supposed to make the limit to unlimited as I understood from
the docs, but a user on one of my server's reported slow download
speeds he was testing with wget and fetch, so we compared with another
FreeBSD server (5.2.1) on the same network and sure enough there was a
massive difference (45mbit on the other server 5mbit on mine), I spent
ages checking all my tweaks and changes I made comparing between the 2
server's and ended up checking my loader.conf and tried setting a
value and leaving it as auto, both of these changes fixed the download
speed issue but setting to 0 introduces the problem.
Has anyone else noticed this?
Chris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Index: src/sys/kern/kern_mbuf.c
===
RCS file: /home/ncvs/src/sys/kern/kern_mbuf.c,v
retrieving revision 1.4
diff -u -r1.4 kern_mbuf.c
--- src/sys/kern/kern_mbuf.c20 Sep 2004 08:52:04 - 1.4
+++ src/sys/kern/kern_mbuf.c6 Jan 2005 22:37:34 -
@@ -1,5 +1,5 @@
/*-
- * Copyright (c) 2004
+ * Copyright (c) 2004, 2005
* Bosko Milekic [EMAIL PROTECTED].
* All rights reserved.
*
@@ -85,13 +85,16 @@
int nmbclusters;
struct mbstat mbstat;
+static int nmbclusters2;
+
static void
tunable_mbinit(void *dummy)
{
/* This has to be done before VM init. */
nmbclusters = 1024 + maxusers * 64;
- TUNABLE_INT_FETCH(kern.ipc.nmbclusters, nmbclusters);
+ nmbclusters2 = nmbclusters;
+ TUNABLE_INT_FETCH(kern.ipc.nmbclusters, nmbclusters2);
}
SYSINIT(tunable_mbinit, SI_SUB_TUNABLES, SI_ORDER_ANY, tunable_mbinit, NULL);
@@ -141,8 +144,8 @@
NULL, NULL, MSIZE - 1, UMA_ZONE_MAXBUCKET);
zone_clust = uma_zcreate(MbufClust, MCLBYTES, mb_ctor_clust,
mb_dtor_clust, NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_REFCNT);
- if (nmbclusters 0)
- uma_zone_set_max(zone_clust, nmbclusters);
+ if (nmbclusters2 0)
+ uma_zone_set_max(zone_clust, nmbclusters2);
zone_pack = uma_zsecond_create(Packet, mb_ctor_pack, mb_dtor_pack,
mb_init_pack, mb_fini_pack, zone_mbuf);
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Memory handling problem with FreeBSD 5.3?
On Thu, Dec 30, 2004 at 10:41:27AM -0700, Scott Long wrote: Christian R. wrote: On Thu, 30 Dec 2004 12:02:16 +0100, you wrote: Would the AMD64 version of FreeBSD 5.3 be a better choice? I have now installed the AMD64 version on the server. It has been running stable now for some hours with alot of load and all the 6 GB activated. It seems to be a problem with the i386 version og FreeBSD 5.3. i386 and amd64 have the exact same code for handling the needs of the amr driver. I'm a bit worried that one works for you while the other doesn't; I extensively tested the code on both platforms with 8GB of RAM. Scott Maybe I missed something in this thread, but what does it have to do with the amr driver? The first thing that came to mind was something with PAE and how it affects PDE modifications. On i386, it might be worth trying these combinations: 1. SMP, NO PAE. 2. UP, PAE. 3. UP, NO PAE. As we already know that SMP, PAE for you has problems. -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nmbcluster change
Setting it to zero means it's unlimited. Be careful. -Bosko On Thu, Dec 16, 2004 at 02:42:02PM +0100, Mipam wrote: Hi, The nmbcluster option from the kernel config file is no longer possible in 5.3. Instead the systctl kern.ipc.nmbclusters should be used now in /boot/loader.conf? Normally i would set this value to 65535 (maximum value?) in order to make fbsd handle lots and lots of connections. So i should put kern.ipc.nmbclusters=65535 in /boot/loader.conf in order to reach the same result? Setting this value to 0, what does this do? Bye, Mipam. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sudden and unexplained reboots
On Wed, Jun 04, 2003 at 08:13:24PM +0200, Noor Dawod wrote: Hello, I'm having a problem in one of the FreeBSD boxes that I manage. All of a sudden, and for no particular reason, the machine just reboots abruptly. When it loads up again, I cannot see an indication that there's anything wrong in the configuration. By the way, the machine is running like this for few months, and no changes were made lately. Machine has 2GB RAM, RAID-5 disk array and a Xeon 933Mhz CPU. There's enough space on disk and more free RAM to drive 5 desktop computers. Anyone got an idea how to debug the problem? and better, how to resolve and fix it? Thanks in advance. /Noor Build a kernel with INVARIANTS and DDB options and see if you get dumped to the console debugger following a trap or panic at some point. Also, obviously, make sure that you're not getting any power surges or anything of the sort; basically anything hardware-related that could possibly cause a reboot. If you're plugged into a series-connected outlet, I would advise to try a different outlet. If you're plugged into a UPS, make sure that the load on it is not too high. -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Security updates on freebsd stable
On Sat, Dec 28, 2002 at 11:28:32AM -0500, Murat Bicer wrote: Once I choose to use a stable version of freebsd, What are the ways to apply a security patch to all these servers? I need to automate this for 1 servers. All feedback appreciated. Murat You can do several things, depending on your needs. If these are production servers then I would not recommend just blindly having them cvsup RELENG_4 and rebuilding themselves every couple of weeks. Instead, you may want to have one machine store and NFS export the source. Then, you can occasionally cvsup fresh RELENG_4 to that one machine and have the others mount the exported NFS partition and build using the same sources, once you know the bits you have are stable. Otherwise, you could just keep a version of the RELENG_4 sources on that one machine that you know are stable and occasionally apply your security patches to that one machine which would again export the sources via NFS. You could then build using the NFS mounted sources with a local object target on each server, as needed. This is how I do it here and it works pretty well. -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: mbuf usage - how do i track it down?
,
control=0x0) at /usr/src/sys/netinet/ip_divert.c:327
#11 0xc01d61fb in div_send (so=0xc8d3ce40, flags=0, m=0xc0ee5000,
nam=0xc1ac2650, control=0x0, p=0xc874b380)
at /usr/src/sys/netinet/ip_divert.c:440
#12 0xc01990db in sosend (so=0xc8d3ce40, addr=0xc1ac2650, uio=0xc97f0ecc,
top=0xc0ee5000, control=0x0, flags=0, p=0xc874b380)
at /usr/src/sys/kern/uipc_socket.c:609
#13 0xc019c49b in sendit (p=0xc874b380, s=3, mp=0xc97f0f0c, flags=0)
at /usr/src/sys/kern/uipc_syscalls.c:585
#14 0xc019c59e in sendto (p=0xc874b380, uap=0xc97f0f80)
at /usr/src/sys/kern/uipc_syscalls.c:638
#15 0xc02bdfe1 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1078002552, tf_esi = 1, tf_ebp = -1077937016,
tf_isp = -914419756, tf_ebx = 60, tf_edx = 3, tf_ecx = 1, tf_eax = 133,
tf_trapno = 7, tf_err = 2, tf_eip = 134551364, tf_cs = 31,
tf_eflags = 643, tf_esp = -1078002724, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1175
#16 0xc02aef45 in Xint0x80_syscall ()
(kgdb) f 6
#6 0xc0196db8 in m_copydata (m=0x0, off=-1, len=1,
cp=0xc0ee5070 :sha1:UPA6SGRR2Z7Y3YSND2J3JYQTFPMKK5JI)
at /usr/src/sys/kern/uipc_mbuf.c:863
863 while (len 0) {
(kgdb) f 7
#7 0xc01e438c in tcp_output (tp=0xc8e11140)
at /usr/src/sys/netinet/tcp_output.c:607
607 m_copydata(so-so_snd.sb_mb, off, (int) len,
(kgdb)
(kgdb) p so
$1 = (struct socket *) 0xc8d3d380
(kgdb) p *so
$2 = {so_type = 1, so_options = 4, so_linger = 0, so_state = 258,
so_pcb = 0xc8e11080 \003X{`k(, so_proto = 0xc0332be8,
so_head = 0x0, so_incomp = {tqh_first = 0x0, tqh_last = 0xc8d3d394},
so_comp = {tqh_first = 0x0, tqh_last = 0xc8d3d39c}, so_list = {
tqe_next = 0x0, tqe_prev = 0x0}, so_qlen = 0, so_incqlen = 0,
so_qlimit = 0, so_timeo = 0, so_error = 0, so_sigio = 0x0, so_oobmark = 0,
so_aiojobq = {tqh_first = 0x0, tqh_last = 0xc8d3d3c0}, so_rcv = {sb_cc = 0,
sb_hiwat = 57920, sb_mbcnt = 0, sb_mbmax = 262144, sb_lowat = 1,
sb_mb = 0x0, sb_sel = {si_pid = 0, si_note = {slh_first = 0x0},
si_flags = 0}, sb_flags = 0, sb_timeo = 0}, so_snd = {sb_cc = 0,
sb_hiwat = 33304, sb_mbcnt = 0, sb_mbmax = 262144, sb_lowat = 2048,
sb_mb = 0x0, sb_sel = {si_pid = 0, si_note = {slh_first = 0x0},
si_flags = 0}, sb_flags = 0, sb_timeo = 0}, so_upcall = 0,
so_upcallarg = 0x0, so_cred = 0xc1a0a900, so_gencnt = 72140,
so_emuldata = 0x0, so_accf = 0x0}
(kgdb)
SO it looks like somewhere there is also a use-mbuf-alloc-without-checking
bug somewhere.
Gavin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
Re: Can someone MFC the patch in bin/37717?
On Tue, Aug 13, 2002 at 09:32:54AM -0600, Fred Clift wrote: As the subject says, can someone MFC the patch in bin/37717? It is not terribly critical, but it's a simple little fix that I'm concerned aobut only for vanity-type reasons :). That, and it's one less local patch I have to worry about applying... Done. Thank you. Fred -- Fred Clift - [EMAIL PROTECTED] -- Remember: If brute force doesn't work, you're just not using enough. -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Bullshit! Mac OS X is not FreeBSD. Get real please.
Go away, go away, go away, go away, go away! You clearly have no idea what you're talking about, and risk mis-informing people who read the list in hopes of actually learning something. Congratulations, though, you've earned a spot in my killfile. On Wed, Jul 25, 2001 at 12:36:06AM -0400, Sung Nae Cho wrote: Okay, don't give me crap like I'm troll or anything stupid for I'm FreeBSD user. But, I think there is a double standards in BSD community. First of all, MAC OS X is not FreeBSD. How can it be a FreeBSD if it has totally different core except that it has a FreeBSD user land commands? Or, have I heard this wrong? 2nd, I personally don't see the difference between APPLE and MICROSOFT. At least Microsoft doesn't pretend to be friends with Open Sourced Community. APPLE is bullshit company. It builds an OS based on Open Source and they're making it a proprietary. That's bullshit! 3rd, OS X is a one crappy OS I've ever seen! Infact, most APPLE users have gone back to OS 9 because OS X requires them to buy all the softwares (Office suites...etc) built for OS X since the emulation is terrible and utterally useless (TOO DAMN SLOW!). Go away. It's also bullshit that FreeBSD community cannot throw away it's pride and accept the defeat and try to learn from it. We all heard that in recent benchmark, both Linux 2.4 and Windows 2000 kick FreeBSD butt in performance. FreeBSDers complained so they did the test again with all the optimizations enabled and FreeBSD still couldn't beat both Windows 2000 and Linux 2.4 (not to mention, Linux 2.4 and Win 2000 didn't even receive special treat for getting tuned.) Come one people! Let's cut the bull shit and get real. I'm sick of this idiots just saying this and that without actually contributing anything to FreeBSD development. I hope FreeBSD 5.x does a milestone just like Linux 2.4 and Windows 2000 did. Also, don't give me the crap like Windows 2000 and Linux are unstable! I've tried em and Windows 2000 is a totally different beast than any previous Windows (2000 is stable as a rock!). So is Linux. Linux 2.4 is even stabler! Go away. Why then do I use FreeBSD? I use FreeBSD not because it's better than Linux or Windows 2000, not because it has better hardware support than Linux or Windows, but just because I like the consistent layout of the file structures. Redhat seems to move around files on every release. Also, ports collections seem to be handy when I'm not in mood to compile manually (not that I can't do it in Linux). I wish FreeBSD 5.x finally get support for my new Kensington USB (OPTICAL) mouse on my Laptop! I don't know about FreeBSD hardware support on desktops, but laptop hardware support is simply not impressive! I'm not about to go back to wheel based mouse (got tired of cleaning wheels). I hope this doesn't offend anyone. (Just got tired of listening to crap!) Go away. Sung N. Cho Go away, -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Continued panics on a recent STABLE machine
Eurgh. Not the first time I see this, and not from one source. Recent complaints have come in about the exact same problem only for RELENG_4. Please try: http://people.freebsd.org/~bmilekic/code/bogus_mb.diff And try your best to reproduce. Regards, Bosko. Mike Tancsa wrote: Not sure if its hardware, but the panics seem to be in the same location each time. At first I thought it might be IPSEC, but I got rid of that. db trace m_copym(c0ad3300,3908,5b4,1,ccf5e0c0) at m_copym+0x13c tcp_output(ccf5e0c0,0,c0ad3300,cca2fcc0,0) at tcp_output+0x838 tcp_usr_send(cca2fcc0,4,c0ad3300,0,0) at tcp_usr_send+0x14a sosend(cca2fcc0,0,ceb06ed8,c0ad3300,0) at sosend+0x5df soo_write(c1bc80c0,ceb06ed8,c158ea00,0,ce5aeba0) at soo_write+0x24 dofilewrite(ce5aeba0,c1bc80c0,4,80fc000,4470) at dofilewrite+0xbd write(ce5aeba0,ceb06f80,28248928,2825a740,80fc000) at write+0x36 syscall2(2f,2f,2f,80fc000,2825a740) at syscall2+0x1f1 Xint0x80_syscall() at Xint0x80_syscall+0x25 Fatal trap 12: page fault while in kernel mode fault virtual address = 0xadc0fa00 fault code = supervisor read, page not present instruction pointer = 0x8:0xc017b078 stack pointer = 0x10:0xceb06d4c frame pointer = 0x10:0xceb06d68 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 7625 (sendmail) interrupt mask = net tty kernel: type 12 trap, code=0 Stopped at m_copym+0x13c: movl0(%edx),%eax Fatal trap 12: page fault while in kernel mode fault virtual address = 0xacc06400 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01b7c8c stack pointer = 0x10:0xce639dc0 frame pointer = 0x10:0xce639e34 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 32323 (cc1) interrupt mask = net tty kernel: type 12 trap, code=0 Stopped at tcp_output+0x658: movl0(%edx),%eax db trace tcp_output(ccf5f2e0,0,c0a74020,,0) at tcp_output+0x658 tcp_input(c0ab5a00,14,6,c0ab5a00,400400) at tcp_input+0x2233 ip_input(c0ab5a00) at ip_input+0x7fb ipintr(c0276c80,400400,c0289a2a,c028953b,400400) at ipintr+0x4b swi_net_next(c0a34820,0,2f,2f,2f) at swi_net_next Xresume10() at Xresume10+0x2b --- interrupt, eip = 0x8076319, esp = 0xce639fe0, ebp = 0xbfbfe7c0 --- db FreeBSD 4.2-STABLE #3: Tue Feb 27 21:16:15 EST 2001 Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (448.62-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x653 Stepping = 3 Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PG E,M Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PG E,MCA, CMOV,PAT,PSE36,MMX,FXSR real memory = 268427264 (262136K bytes) avail memory = 257769472 (251728K bytes) Preloaded elf kernel "kernel" at 0xc036a000. Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface pcib0: Intel 82443GX host to PCI bridge on motherboard pci0: PCI bus on pcib0 pcib2: Intel 82443GX (440 GX) PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib2 pci1: VGA-compatible display device at 0.0 irq 5 isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xffa0-0xffaf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 pci0: Intel 82371AB/EB (PIIX4) USB controller at 7.2 irq 11 chip1: Intel 82371AB Power management controller port 0x850-0x85f at device 7.3 on pci0 fxp0: Intel Pro 10/100B/100+ Ethernet port 0xecc0-0xecdf mem 0xfe00-0xfe0f,0xf600-0xf6000fff irq 10 at device 14.0 on pci0 fxp0: Ethernet address 00:a0:c9:d6:db:ba xl0: 3Com 3c905B-TX Fast Etherlink XL port 0xec00-0xec7f mem 0xfe10-0xfe10007f irq 10 at device 17.0 on pci0 xl0: Ethernet address: 00:c0:4f:68:13:88 miibus0: MII bus on xl0 xlphy0: 3Com internal media interface on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcib3: DEC 21152 PCI-PCI bridge at device 19.0 on pci0 pci2: PCI bus on pcib3 pcib1: Intel 82443GX host to AGP bridge on motherboard pci3: PCI bus on pcib1 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x100 sio0 at port
Re: Kernel crush due to frag attack
Adrian Penisoara wrote:
Hi,
As we are facing a heavy fragments attack (40-60byte packets in a
~ 1000 pkts/sec flow) I see some sporadic panics. Kernel/world is
4.2-STABLE as of 18 Jan 2001 -- it's a production machine and I
hadn't yet
the chance for another update; if it's been fixed in the mean time I
would
be glad to hear it...
I have attached a gdb trace and a snip of a tcpdump log. When I
rebuilt
the kernel with debug options it seemed to crush less often. I
remember
that at the time of this panic I had an ipfw rule to deny IP
fragments.
This is one of those "odd" faults I've seen in -STABLE sometimes.
Thanks to good debugging information you've provided, to be noted:
#16 0xc014de98 in m_copym (m=0xc07e7c00, off0=0, len=40, wait=1)
at ../../kern/uipc_mbuf.c:621
621 n-m_pkthdr.len -= off0;
(kgdb) list
616 if (n == 0)
617 goto nospace;
618 if (copyhdr) {
619 M_COPY_PKTHDR(n, m);
620 if (len == M_COPYALL)
621 n-m_pkthdr.len -= off0;-- fault happens here (XXX)
622else
623 n-m_pkthdr.len = len;
624 copyhdr = 0;
625}
(kgdb) print n
$1 = (struct mbuf *) 0x661c20
(kgdb) print *n
cannot read proc at 0
(kgdb) print m
$2 = (struct mbuf *) 0xc07e7c00
Where the fault happens (XXX), the possible problem is that the mbuf
pointer n is bad, and as printed from the debugger, it does appear to
be bad. However, there are two things to note:
1. the fault virtual address displayed in the trap message:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x89c0c800
[...]
is different from the one printed in your analysis (even though
0x89c0c800 seems bogus as well, although it is at a correct boundry).
2. Nothing bad happens in M_COPY_PKTHDR() which dereferences an
equivalent pointer.
Something seriously evil is happening here and, unfortunately, I have
no idea what.
Does this only happen on this one machine? Or is it reproducable on
several different machines? I used to stress test -STABLE for mbuf
starvation and never stumbled upon one of these `spontaneous pointer
deaths' myself. Although I have seen other weird problems reported by
other people, but only in RELENG_3.
If you cannot reproduce it on any other machines, I would start
looking at possibly bad hardware... unless someone else sees something
I'm not.
If you need further data just ask, I'd be glad to help,
Ady (@warpnet.ro)
Regards,
Bosko.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: Bridging code in 4.2RC1 still not fixed
On Tue, 14 Nov 2000, Thomas T. Veldhouse wrote: It has been mentioned in the past many many times - and promptly forgotton just as many times. Forgive the harsh sounding critcism - just trying to get attention called to this issue. It is not at all hard to reproduce - but it does not log anything to the system logs when this sort of crash happens. The fact that nobody has looked at this over the course of the last year really surprises me. Tom Veldhouse [EMAIL PROTECTED] You know what's unfortunate? What's unfortunate is that this entire thread has failed to provide any single piece of VALID debugging information, despite my (and I'm sure others') efforts in obtaining that. Even if "the problem" isn't that hard to reproduce, maybe there are more than one problem. Maybe there is only one, but its side-effects are apparent at several different places. Unless someone experiencing the problems provides valid debugging information, how exactly do you expect anybody to fix it? Simply saying "yeah, there's a problem, it's related to X, so fix it" just doesn't cut it, if you're expecting people to prioritize it. Furthermore, I've noticed that Marko's report doesn't include the debugging information which I feel I made very clear is required to even glance at the problem. Regards, Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: SYN Hardening patches? / SYN Code in 3.4-RC
On Sun, 12 Dec 1999, Tom wrote: ! ! Setting maxusers to 256 isn't help you any at all, btw. ! !Tom ! This is simply untrue. MAXUSERS directly influences the number of mbufs which, in turn, influence the size of mb_map. Bumping up MAXUSERS in reasonable amounts will, in fact, contribute to a larger mb_map. -- Bosko Milekic [EMAIL PROTECTED] http://pages.infinit.net/bmilekic/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: SYN Hardening patches? / SYN Code in 3.4-RC
On Sun, 12 Dec 1999, David Greenman wrote: !On Sun, 12 Dec 1999, Tom wrote: ! !! !! Setting maxusers to 256 isn't help you any at all, btw. !! !!Tom !! ! ! This is simply untrue. ! ! MAXUSERS directly influences the number of mbufs which, in turn, ! influence the size of mb_map. Bumping up MAXUSERS in reasonable amounts ! will, in fact, contribute to a larger mb_map. ! ! Only if you don't specify NMBCLUSTERS, which the original poster did. ! !-DG ! !David Greenman !Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org !Creator of high-performance Internet servers - http://www.terasolutions.com !Pave the road of life with opportunities. ! Even at that, MAXUSERS still contributes to the mb_map size. I see your point, though, in the sense that by setting up NMBCLUSTERS, the overall size of mb_map will be affected by that setting, and not MAXUSERS, in general. So here's the question: Why not remove MAXUSERS' influence over the size of the mb_map, and just have it influenced by a single option? -- Bosko Milekic [EMAIL PROTECTED] http://pages.infinit.net/bmilekic/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
