Re: gcc compile error
On Wed, 29 Dec 1999, Amancio Hasty wrote: !> !>Without -O or -O2 the program compiles okay. !> !>gcc -c bug.c !> Ouch! This looks an awful lot like the last report with `GCC' and `problem' in the subject. As Matt just mentionned one or two posts ago, and as I observed in the last thread, have you tried making some of the variables `volatile?' Assuming of course that the code does compile well without the optimization flags, one would assume that the "problem" occurs because of caching of certain variable values in registers (not that this should be a problem, mind you; one would assume that the optimization isn't performed too well). Due to lack of time, and generally speaking, lack of experience with GCC, I haven't taken a detailed shot at debugging this. Bosko. -- Bosko Milekic Email: [EMAIL PROTECTED] WWW:http://pages.infinit.net/bmilekic/ -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic at kern/uipc_socket2.c
On Sun, 2 Jan 2000, Jun Kuriyama wrote: !> !>I don't know what I did at that time, but my box is panic'ed with this !>message. !> !>- !>Jan 1 16:19:21 leda kernel: panic: sbflush: cc 0 || mb 0xc05a7400 || mbcnt 256 !>- !> !>It seems that this message is created by sbflush() in !>kern/uipc_socket2.c. !> !>Should I add some hooks into this function to display details !>preparing for when I get this panic()? !> !> !>Jun Kuriyama // [EMAIL PROTECTED] !>// [EMAIL PROTECTED] !> You don't happen to have a backtrace? Was anything particular happening at the time of the crash? Do you have any way to not necessarily directly reproduce the panic but rather "force" it to happen (e.g. as a consequence of execution of something or, even as a result of some external "trigger")? -- Bosko Milekic Email: [EMAIL PROTECTED] WWW:http://pages.infinit.net/bmilekic/ -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic at kern/uipc_socket2.c
On Wed, 5 Jan 2000, Jun Kuriyama wrote: >From: Bosko Milekic <[EMAIL PROTECTED]> >> You don't happen to have a backtrace? > >I don't have it. When my box gives no reaction, I've hit some keys, >keys, keys...and rebooted automatically. At that time, I could not >switch to VT1 from X with [Ctrl]+[Alt]+[F1]. > >> Was anything particular happening at the time of the crash? Do you >> have any way to not necessarily directly reproduce the panic but rather >> "force" it to happen (e.g. as a consequence of execution of something or, >> even as a result of some external "trigger")? > >I think I used XEmacs, Netscape Communicator and many console works >with ssh'ed remote login. I have no idea which one made this. > > >Jun Kuriyama // [EMAIL PROTECTED] >// [EMAIL PROTECTED] > Can you look at kern/10872 and see if your hardware matches Bob's? (e.g. The infamous fxp and ncr combo.) and regardless, attempt executing the script that is provided and note whether or not you can reproduce the panic in sbdrop()? If so, a backtrace and a `print *sb' would be helpful, certainly. It looks as though some mbufs are literally being `zapped' off of sb_mb while sb_cc and sb_mbcnt are still greater than zero. Either that, or something's not adjusting sb_cc and/or sb_mbcnt under the proper spl which may lead to an interrupt eventually leading to the sbdrop with an sb_cc and sb_mb that just don't go together. -- Bosko Milekic Email: [EMAIL PROTECTED] WWW:http://pages.infinit.net/bmilekic/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Loader.rc: unknown command
On Sun, 30 Jan 2000, Jean-Marc Zucconi wrote: >Hi, > >With a new installed world I get this message at boot: > >> \ Loader.rc >Loader.rc: unknown command > >Fortunately this does not prevent the machine to boot :-) >Any clue? > >Jean-Marc Try rebuilding and re-installing the loader. ----- | Bosko Milekic | Coffee vector: 1.0i+1.0j+1.0k | | Email: [EMAIL PROTECTED] | Sleep vector: -1.0i-1.0j-1.0k | | WWW: http://pages.infinit.net/bmilekic/ | Resulting life: 0i+0j+0k (DNE)| - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel
Try looking at the sysctl(3) interface. Issue `sysctl -A' and note one of the exported variable names. Then, search the code to see how it's setup. This is most probably what you're looking for. On Mon, 21 Feb 2000, [iso-8859-1] José Luís Faria wrote: >Hello > >I'm creating a litle update to a freebsd 3.4 kernel. >My program is for account some data: number of >packets by class, number of packets dropped by class, etc. >Now I need to pass this values to another program wich in X-Window >display this values on-line. After, I want to save this values >in a file. > >I need some docs about how I can do this. >Which are the primitives in the kernel to do this. >I use the printf to put this data in /var/log/messages. >This inappropriate, I dont want this. This is only for testing now. > >Can you help me ? > >Thank you very much. > > >P.S. I'm sorry my english. > > >-- > > :) cumprimentos > > Jose Luis Faria > Administrador de Sistemas > Universidade do Minho - Departamento de Informática > Campus de Gualtar > 4710-057 Braga > Portugal > tel.: +351 253604440 Fax:+351 253604471 > http://admin.di.uminho.pt/~jose > <--> Bosko Milekic * [EMAIL PROTECTED] * http://pages.infinit.net/bmilekic/ <--> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic caused by mbuf exhaustion in i4b with AVM PCI
On Thu, 25 Nov 1999, Gary Jennejohn wrote: !>I can only guess, but it looks like the user-land process isn't told !>about the hangup and keeps sending packets down the line. The packets !>never go out (no connection), so the mbufs eventually run out. The !>raw interface evidently doesn't have the safety belts that the other !>interfaces (like ipr, isppp) have. Out of curiosity, is anything regarding the exhaustion of mb_map being logged to /var/log/messages ? If not, chances are that this is not directly related to an mbuf exhaustion -- the panic, that is, because if mb_map hasn't even been exhausted, then you still potentially have space to allocate from (this is the way it presently works) and the panic is unlikely to be related to an mbuf pointer being NULL and mis-treated. -- Bosko Milekic <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Current kernel compile fails
On Sat, 18 Dec 1999, Manfred Antar wrote: !>I think this happened when mbuf.h was changed : !> !>linking kernel.debug !>uipc_mbuf.o: In function `m_mballoc_wait': !>/sys/compile/pro2/../../kern/uipc_mbuf.c(.text+0x2cb): undefined reference !>to `m_mballoc_wakeup' !>uipc_mbuf.o: In function `m_clalloc_wait': !>/sys/compile/pro2/../../kern/uipc_mbuf.c:349: undefined reference to !>`m_clalloc_wakeup' !>*** Error code 1 !> !>Manfred !>= !>||[EMAIL PROTECTED] || !>||Ph. (415) 681-6235|| !>= Yeah, you just caught some bad timing. Re-cvsup, all should be fixed now. :-) .. . . . . . . .. .. . . . Bosko Milekic -- [EMAIL PROTECTED] . . . . . .. . . . . .. . . WWW: http://pages.infinit.net/bmilekic/ . To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cc taking a signal 11
On Mon, 20 Dec 1999, Thomas David Rivers wrote:
!>> FreeBSD(root)/tmp %cc -O foo.c -o foo.o -c
!>> cc: Internal compiler error: program cc1 got fatal signal 11
!>>
!>>
!>>
!>> static void getsig11(parfree,dbl,lambda)
!>> long parfree;
!>> double *dbl;
!>> double *lambda;
!>> {
!>> long i, j;
!>> j = -1;
!>> for(i = 0; i < parfree; i++) {
!>>j += i+1;
!>>dbl[j] *= (1.0 + *lambda);
!>>}
!>> return;
!>> }
!>>
!>>
!>>Yes, the algorithm looks funny, but is correct. The program will
!>> compile correctly if the 'j += i+1;' is changed to 'j = i+1;' or if
!>> the variable 'lambda' is changed from a pointer to an actual value.
!>>
!>>Anyone want to take a stab at this? I'm not a big compiler
!>> person myself... (Dave, you there?).
!>
!> Yes - I'm here :-)
!>
!> Typically - signal 11 problems from GNU's front-end are hardware
!> memory issues
!>
!> I will add that a quick test on a 3.3 system compiles this just
!> fine (Systems/C compiles it as well.)
!>
!> I would suspect hardware problems first.
!>
!> As I have learned from painful experience, *always* use ECC or at least
!> parity memory...
!>
!> - Dave R. -
This seems to only be an issue if you're compiling with optimization.
I *think* it's because the compiler tries to make `j' a register. If you
explicitly declare `j' a volatile, you should not get this.
Is this correct?
Bosko.
.. . . . . . . .. .. . .
. Bosko Milekic -- [EMAIL PROTECTED] . .
. . . .. . . . . .. .
. WWW: http://pages.infinit.net/bmilekic/ .
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: INVARIANTS doesn't work?
On Thu, 23 Mar 2000, Brad Knowles wrote: >Folks, > > It looks to me like setting INVARIANTS in your kernel doesn't >work in 4.0-STABLE. > [...] >reference to `zerror' >vm_zone.o: In function `zfreei': > > The kernel config is a bit large, so I will transmit it on >request to interested parties, but I won't post it to the list unless >specifically asked to do so. The one thing I'll note is that this >might be an interaction between INVARIANTS and "makeoptions >DEBUG=-g". I'll try turning off DEBUG and see if I can make a kernel >that way > Hopefully, you've done this and the following will come out as a pretty useless question for you, but I have not seen it mentionned in your Email: Do you have `options INVARIANT_SUPPORT' ? .. Bosko Milekic * [EMAIL PROTECTED] * http://pages.infinit.net/bmilekic/ Montreal, Quebec, Canada. * Technokratis: http://www.technokratis.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: linux-flashplugin...no sound?
On Mon, 15 May 2000, emre wrote: > Hi, > > This is really not that important and in case it doesn't work or if there > > is no solution for this, I'll live :) > > I'm running FreeBSD 5.0-2419-CURRENT on i386, and I'm using the ports > > from whatever date I installed the system. Linux emulation and all that > > stuff works fine (I had a problem with real player which is fixed now). I > > installed the macromedia flash plugin for Linux and I am also using the > > Linux version of Communicator (with no problems by the way). > > The flash plugin also seems to do its job, with one exception: there is no > > sound. I've made sure that there is no other application using the sound > Yes, try cvsup-ing more recent sources. I re-call having problems with the linux flash plugin and sound around that date. After rebuilding a more recent world, all was well again. As I recall at least one more person having the exact same problem at the same time, I don't believe it to be an isolated case. --Bosko -- Bosko Milekic * pages.infinit.net/bmilekic/index.html * www.technokratis.com [EMAIL PROTECTED] * [EMAIL PROTECTED] * [EMAIL PROTECTED] "Give a man a fish and he will eat for a day. Teach him how to fish, and he will sit in a boat and drink beer all day." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FOLLOWING config changes? : Kernel profiling support
I've recently cleaned up and updated my sources, saving some changes I made elsewhere. I performed a buildworld, installworld, etc. yesterday night with no problems. When I rebuilt my kernel, after having collected the appropriate hints for the system and modified my kernel configuration file appropriately, I had some trouble booting it. The loader would load the kernel into memory but when it was time to `boot' it, I was not able to see anything on the console, this includes the initial copyright message. Furthermore, my keyboard was unresponsive. However, I could tell that the kernel was booting nonetheless (even though I could not see it), judging by the hard disk drives' activity (and upon checking /var/log/messages after I booted with my previously saved kernel). I then decided to rebuild the kernel with the hints statically compiled in, and this worked fine, and the kernel booted properly. Note that I did not use any notable optimisation flag during the build, and that this is all on i386 architecture. However, I decided to build a kernel with profiling support this morning (config -p KERNEL, etc.), and I left the hints compiled in statically. The kernel built fine, but when it came time to boot it, again, no response from keyboard, nothing at the console. This time though, the kernel wasn't even booting. Has anybody noticed/tried this recently? Am I forgetting something? Cheers, Bosko. -- Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237 [EMAIL PROTECTED] * http://www.technokratis.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FOLLOWING config changes? : Kernel profiling support
Yes, this is what I initially got. Although I'm not quite interested in this particular problem. What I need is profiling to work. Still, what you should look at is adding the `hints' directive to your kernel configuration file, if you haven't done so already. See if that fixes your problem. On Mon, 19 Jun 2000, The Hermit Hacker wrote: > > Ya know, I never thought about checkign /var/log/messages on mine to see > if it was, in fact, booting (I thought it was, it sounded like it was, but > I couldn't think of a way to check) ... > > Using kernel sources up-to-date as of a few hours ago, I've tried to pare > my optimzatins down to a simple '-O -pipe', and I'm getting the same thing > as you, where I effectively get: > > Booting kernel ... > \ > > on my screen, and that's the end of it. Looking at /var/log/messages, it > looks like I am getting a full reboot happening, right down to > initializing 'vmmon', but nothing to my screen. > > I've been trying to follow the -current list to see if any ideas/solutions > pop up, but the only things I've noticed so far have revolved around > optimization issues, but its more then possible that I missed a message > ... > > My last good kernel, that boot'd fine, is: > > @(#)FreeBSD 5.0-CURRENT #0: Wed Jun 14 01:03:00 ADT 2000 > > With every other one since resulting in the above ... > -- Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237 [EMAIL PROTECTED] * http://www.technokratis.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Huh? ssh stopped working with new kernel.
Julian, "me too." Note that if I go back to kernel.saved, it works again. --Bosko On Tue, 27 Jun 2000, Julian Elischer wrote: > So I cvsupped yesterday, and tehn made a new kernel. > so suddenly ssh doesn't work any more. > > it says: > > > jules# ssh www.elischer.org > ssh: no RSA support in libssl and libcrypto. See ssl(8). > Disabling protocol version 1 > Protocol major versions differ: 2 vs. 1 > jules# > > luckily /usr/local/bin/ssh was still there > and still works. > (same if ssh-ing to freefall as well). > I decided maybe marks broken urandom may be the prolem > but making it a symlink to /dev/random > didn't help.. > jules# ls -l /dev/*rand* > crw-r--r-- 1 root wheel2, 3 Jun 27 10:26 /dev/random > lrwx-- 1 root wheel 6 Jun 27 10:26 /dev/urandom -> random > jules# > > Any suggestions.. > it worked this morning > and I have NOT changed any user programs/libraries > > > > -- > __--_|\ Julian Elischer > / \ [EMAIL PROTECTED] > ( OZ) World tour 2000 > )_.---._/ presently in: Budapest > v > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > > -- Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237 [EMAIL PROTECTED] * http://www.technokratis.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Questions about kmem_malloc and SPL levels
On Wed, 28 Jun 2000, Bruce Evans wrote: > > The first part will be news to the folks running SMP. :-) The business > > about splhigh is also wrong. But what worries me is that malloc calls > > it at splmem, while m_clalloc calls it at splimp. Is that a problem? > > malloc() calls it on kmem_map while m_clalloc() call it on mb_map, so I > think there is no problem in principle. vm just has to call splvm() > itself and not depend on kmem_malloc() being called at splvm() (so the > comment is broken in yet another way). > > Bruce There is a general inconsistency in the vm code it seems, for what concerns this issue. I noticed it while looking at the mbuf stuff. As you mention, kmem_malloc() should really just raise to splvm() itself, as do some other routines already in such a situation (look at vm_map). As in the mbuf stuff I seperated mb_map into two parts: mb_map and mcl_map, the long if () statements in vm_map became tedious, not to mention, a slight loss in speed, so what I did (after Emailing dillon about it) was add an alloc_intr field in the vm_map. This is set to 1 for kmem_map, mb_map, and mcl_map, and is checked in the vm_map stuff to decide whether to raise to splvm(), and should probably also be checked in kmem_malloc() for the same reason as well. However, I suspect that kmem_malloc calls some of those vm_map routines at one point or another and they take care of raising to splvm() when necessary, so I don't suspect a critical problem. The question is exactly: How much of kmem_malloc needs to be under splvm() ? In any case, the comment needs to be changed ASAP (I Emailed the lists myself about this maybe on 2 different occasions before and have gotten no reply). --Bosko -- Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237 [EMAIL PROTECTED] * http://www.technokratis.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: freeing free cluster?
I'm trying to update and isolate the external object reference stuff and am getting page faults in nfs_writebp. Very odd, could be freeing free cluster problem, will perform explicit check and post details. Rebuilding regular non-modified kernel to see if I stumble upon it. On Mon, 10 Jul 2000, Pascal Hofstee wrote: > On Mon, Jul 10, 2000 at 01:15:20PM -0700, Matthew Jacob wrote: > > > > > > -current, as of ~today: > > > > FreeBSD/alpha (farrago.feral.com) (console) > > > > login: panic: freeing free cluster > > panic > > Stopped at Debugger+0x2c: ldq ra,0(sp) <0xfe000a2019f0> > > > > I am getting a very strong suspicion, this is the same bug i have reported > earlier as well as DES did in another message. Anyone here that is able to > shed some more light on it ? > > -- > Pascal Hofstee < daeron @ shadowmere . student . utwente . nl > > Managers know it must be good because the programmers hate it so much. > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > > -- Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237 [EMAIL PROTECTED] * http://www.technokratis.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: (URGENT) Instant panic in _MEXT_ALLOC_CNT
Hrmmm, there may be a logic problem here. Try this (apply it manually,
as I am not able to produce a diff at this time):
change:
if ((__mcnt == NULL) && (m_alloc_ref(1) == 0))
panic("mbuf subsystem: out of ref counts!");
to:
if (__mcnt == NULL) {
if (m_alloc_ref(1) != 0)
__mcnt = mext_refcnt_free;
else
panic("mbuf subsystem: out of ref counts!");
}
It could be that the m_alloc_ref(1) doesn't fail, but that __mcnt
is still NULL, it's missing that __mcnt = mext_refcnt_free assignment.
This is most probably a BUG, so please commit the fix...
If this does not solve the problem, we may be looking at a newly
uncovered problem in fxp, although I doubt this.
-Bosko
[EMAIL PROTECTED]
- Original Message -
From: "John Polstra" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, August 19, 2000 6:21 PM
Subject: Instant panic in _MEXT_ALLOC_CNT
> With sources from this morning I am getting an instant kernel-mode
> page fault in the new mbuf cluster reference counting code. It is
> failing in this statement of _MEXT_ALLOC_CNT (sys/mbuf.h), as far as
> I can tell:
>
> #define _MEXT_ALLOC_CNT(m_cnt) MBUFLOCK(\
> union mext_refcnt *__mcnt; \
> \
> __mcnt = mext_refcnt_free; \
> if ((__mcnt == NULL) && (m_alloc_ref(1) == 0)) \
> panic("mbuf subsystem: out of ref counts!");\
> mext_refcnt_free = __mcnt->next_ref;\
> [*crash*]
>
> Here is the console output and a stack trace from DDB:
>
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> The Regents of the University of California. All rights reserved.
> FreeBSD 5.0-CURRENT #0: Sat Aug 19 14:49:39 PDT 2000
> [EMAIL PROTECTED]:/local0/obj/local0/src/sys/BLAKE
> Timecounter "i8254" frequency 1193163 Hz
> Timecounter "TSC" frequency 400902857 Hz
> CPU: Pentium II/Pentium II Xeon/Celeron (400.90-MHz 686-class CPU)
> Origin = "GenuineIntel" Id = 0x653 Stepping = 3
>
>
Features=0x183f9ff ,MMX,FXSR>
> real memory = 134205440 (131060K bytes)
> avail memory = 127336448 (124352K bytes)
> Preloaded elf kernel "kernel" at 0xc034b000.
> Pentium Pro MTRR support enabled
> npx0: on motherboard
> npx0: INT 16 interface
> pcib0: on motherboard
> pci0: on pcib0
> pci0: at 0.0
> pcib1: at device 1.0 on pci0
> pci1: on pcib1
> pci1: at 0.0 irq 11
> isab0: at device 4.0 on pci0
> isa0: on isab0
> pci0: at 4.1
> pci0: at 4.2
> intpm0: port 0xe800-0xe80f irq
9 at
> device 4.3 on pci0
> intpm0: I/O mapped e800
> intpm0: intr IRQ 9 enabled revision 0
> smbus0: on intsmb0
> smb0: on smbus0
> intpm0: PM I/O mapped e400
> ahc0: port 0xd000-0xd0ff mem
> 0xe000-0xefff irq 5 at device 6.0 on pci0
> ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 32/255 SCBs
> fxp0: port 0xb800-0xb83f mem
> 0xdf00-0xdf0f,0xdf80-0xdf800fff irq 12 at device 10.
> 0 on pci0
>
>
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x0
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xc02126ac
> stack pointer = 0x10:0xc035fea8
> frame pointer = 0x10:0xc035febc
> 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 = 0 (swapper)
> interrupt mask = net tty bio cam
> kernel: type 12 trap, code=0
> Stopped at fxp_add_rfabuf+0x170: movl0(%ebx),%eax
> db> trace
> fxp_add_rfabuf(c0a52c00,0) at fxp_add_rfabuf+0x170
> fxp_attach_common(c0a52c00,c0a52cd8) at fxp_attach_common+0xb8
> fxp_attach(c0a4ad80,c0a4ad80,c0a49600,c0a49580,0) at fxp_attach+0x1ad
> device_probe_and_attach(c0a4ad80) at device_probe_and_attach+0x8e
> bus_generic_attach(c0a49580,c0a49580,c0a49700,c0a49600,0) at
bus_generic_attach+0x16
> device_probe_and_attach(c0a49580) at device_probe_and_attach+0x8e
> bus_generic_attach(c0a49600,c0a49600,c071b680,c0a49700,0) at
bus_generic_attach+0x16
> device_probe_and_attach(c0a49600) at device_probe_and_attach+0x8e
> bus_generic_attach(c0a49700,c0a35080,c035ffc0,c0170c46,c0a49700) at
> bus_generic_attach+0x16
> nexus_attach(c0a49700,c0a49700,c02c0e10,364000,0) at nexus_attach+0xd
> device_probe_and_attach(c0a49700) at device_probe_and_attach+0x8e
> root_bus_configure(c071b680,c029bacc,0) at root_bus_configure+0x16
> configure(0,35dc00,364000,0,c011dc09) at configure+0x33
> mi_startup(0,0,0,0,0) at mi_startup+0x68
> begin() at begin+0x30
>
>
> John
> --
> John Polstra
[EMAIL PROTECTED]
> John D. Polstra & Co., Inc.Seattle, Washington
USA
> "Disappointment is a good sign of
Re: Kernel panic on fxp
PLEASE read this: http://www.freebsd.org/FAQ/hackers.html#AEN4885 Basically, by just looking at the page fault message, this appears to be the dereferencing of a NULL pointer. That's all that I'm afraid pretty much anybody will be able to conclude from this unless you, at least, provide us with a backtrace as well as an assembly dump of whatever function the crash occured in. On Tue, 22 Aug 2000, Patrick Gardella wrote: > I've been working for a while to try to figure out a problem I'm having > here. > > I did a buildworld Sunday, and started to get kernel panics on boot when > it probed fxp. So I removed fxp from my kernel and loaded it as a > module (via loader.conf.local). It paniced. Then I unloaded the > if_fxp.ko on startup, and it booted. But if I load the fxp module now, > after a full boot, everything is great. Rebooting with fxp in the > kernel or loading the module on boot will cause a panic *every* time. > > Thinking it might be build problem, I redid the build/install/kernel > again on Monday, and am having the same problems. The panics only > started on the upgrade from a -current dated sometime in early July. > > As you will see from below, this is an SMP machine (dual P200) with 256 > Megs RAM. > I am also using NETGRAPH to run PPPoE. > > Any ideas? > > Patrick > > The panic is: > Fatal trap 12: page fault while in kernel mode > mp_lock=0005; cpuid = 0; lapic.id= > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc034e304 > stack pointer = 0x10:0xc038bea8 > frame pointer = 0x10=0xc038bebc > code segment= base 0x0, limit 0xf, type 0x1b > = DPC 0, pres 1, def 32 1, gran 1 > processor eflag = interrupt enabled, resume, IOPC=0 > current process = 0 (swapper) > interrupt mask = net tty bio cam <- SMP:XXX > trap number = 12 > panic: page fault Cheers, Bosko. -- Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237 [EMAIL PROTECTED] * http://www.technokratis.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposal to clarify mbuf handling rules
On Sun, 27 Aug 2000, David Malone wrote: [...] > (This is why the flag I was talking about in the other mail > would be useful for spotting other cases where the storage > may be writable, even if it's not a cluster). Thoughts: 1) The mbuf should be marked read-only explicitly with a single additional M_FLAG. #define M_RDONLY0x0x2000 2) The flag should be ORed in in MEXT_ADD_REF() only if the ref_cnt is equal to or greater than 2. This is unfortunate because an additional check would have to be introduced. 3) The flag should be removed in _MEXTFREE only if that first MEXT_IS_REF() evaluates true and if, upon returning from MEXT_REM_REF(), the new ref_cnt is exactly 1. I'm pretty sure that this way, the subsystem will take care of the read-onlyness itself pretty transparently, so that relevant code can simply check for the M_RDONLY bit. (2) is questionable. As for the protocol routines that rely on the mbuf to be "read-only," there may be other side-effects besides for this illegal sharing of multiple-reference ext_bufs that could result from the possibility of passing these "read-only mbufs" to them. This possibility should be investigated. > Cleaning up this sounds like a good plan. It would be worth > getting Ian and Bosko involved if possible. > > David. Sure. If I remember correctly, it was Ian who initially brought this up. This is perhaps a 2-month old issue by now -- I, at the time, was busy with the referencing stuff as well as the allocator re-writing/playing around with (which I will have to continue once the direction of SMP is further cleared up - at least for this part of the code) - so I did not want to mix apples and oranges. I wonder if Ian has some code, though. I have _some_ modifications regarding this already in my local tree but have not yet been able to roll over a diff as my monitor is presently broken (until the end of this week). In any case, how do you propose coordinating the work? This seems like a fairly straightforward change. I'm ready to put on hold whatever I'm doing right now in order to do this, but only if that's okay with you guys - I want to make sure that no efforts are being duplicated. Regards, Bosko. [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI??? was - Re: -current TCP performance hosed?
On Sat, Sep 15, 2001 at 01:08:28AM +0200, Geoff Rehmet wrote: > It seems that, on Fri, Sep 14, 2001 at 03:18:47PM -0700, > in message <[EMAIL PROTECTED]>, Mike Smith wrote: > > > Nope, no debug options, but I am getting loads of > > > > > > microuptime() went backwards (29804.3839847 -> 29804.925730) > > > > ALi chipset? Try turning off the ACPI timer if you haven't already; > > > > set debug.acpi.disable="timer" > > > > at the loader prompt. If this works, please let me know (with ACPI in the > > subject line so I don't miss it). > Tried that, also tried "set hint.acpi.0.disable=1" - neither > had any effect. > The kernel is not compiled with apm... You said this happens with a few-day-old kernel. Is this an implication that it didn't happen before? Can you say, with a certain level of certainty exactly when this started happening, especially if it's something that only started to occur very recently, this may be a worthy piece of information. Thanks. > Geoff. > > -- > Geoff Rehmet, Internet Solutions > tel: +27-11-283-5462, fax: +27-11-283-5401 mobile: +27-83-292-5800 > email: [EMAIL PROTECTED], [EMAIL PROTECTED] > URL: http://www.is.co.za > -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current TCP performance hosed?
On Fri, Sep 14, 2001 at 09:57:24PM +0200, Geoff Rehmet wrote: > I was just wondering if anyone has been experiencing problems with > TCP performance on -current -- my box built on 11 Sept is dog slow - > max 60kbps over 10baseT. I'm going to try and revert to an older > kernel and see if there is a difference. No. Not here. Make sure that all the debugging options are OFF in your kernel configuration file? > Geoff. > -- > Geoff Rehmet, Internet Solutions > tel: +27-11-283-5462, fax: +27-11-283-5401 mobile: +27-83-292-5800 > email: [EMAIL PROTECTED] > URL: http://www.is.co.za -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: send_packet: No buffer space available
>From the netstat output, it looks more like an application-level problem having to do with exhausting socket buffer space. Whatever the cause of the problem, it certainly isn't a lack of mbufs and/or clusters. Try verifying what is generating the messages. It could be coming from a syscall or, it may be that the application is printing them. If it is the latter (you should find the string in the application code), then it's fairly trivial to figure the rest out. If not, I'd check the network card driver you're using next. On Wed, Nov 21, 2001 at 05:01:16PM +0100, Andrea Campi wrote: > This is a long-standing problem which is getting more and more annoying (or > so I feel, might be just an impression). I was wondering if anybody might > be interested in helping me debug and fix it. > I can repeat this at will using Tivoli Storage Manager for Linux to backup > my -CURRENT laptop. Basically, after a few minutes I start getting these > messages; at that point networking is basically hosed until I kill TSM. > > First of all, is this just an application misbehaving and it should be fixed > only by tuning some sysctl, or is it an OS bug proper? Note that -STABLE > doesn't exhibit this problem. > > netstat -m output is as follow: > > mbuf usage: > GEN list: 0/0 (in use/in pool) > CPU #0 list:71/144 (in use/in pool) > Total: 71/144 (in use/in pool) > Maximum number allowed on each CPU list: 512 > Maximum possible: 18432 > Allocated mbuf types: > 46 mbufs allocated to data > 25 mbufs allocated to packet headers > 0% of mbuf map consumed > mbuf cluster usage: > GEN list: 0/0 (in use/in pool) > CPU #0 list:20/66 (in use/in pool) > Total: 20/66 (in use/in pool) > Maximum number allowed on each CPU list: 128 > Maximum possible: 9216 > 0% of cluster map consumed > 168 KBytes of wired memory reserved (34% in use) > 0 requests for memory denied > 0 requests for memory delayed > 0 calls to protocol drain routines > > > Relevant parts of vmstat -m: > > Memory statistics by type Type Kern > Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) > mbufmgr6531K 32K 31594K 2687850 0 16,32,64,128,8K,32K > > What else is needed to diagnose this? It's been baffling me for much too long... > > > Bye, > Andrea > > -- > Tagline generated by 'gensig' mail-client-independent .signature generator. > Get your copy at http://www.geeks.com/~robf/gensig/ > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: send_packet: No buffer space available
On Mon, Nov 26, 2001 at 05:49:01PM +0100, Andrea Campi wrote:
> OK, I traced it to sys/netinet/ip_output.c:
>
> /*
> * Verify that we have any chance at all of being able to queue
> * the packet or packet fragments
> */
> if ((ifp->if_snd.ifq_len + ip->ip_len / ifp->if_mtu + 1) >=
> ifp->if_snd.ifq_maxlen) {
> error = ENOBUFS;
> ipstat.ips_odropped++;
> goto bad;
> }
>
> So this means the output queue on my net card is full, right? And I guess
It means that the interface output queue is full, yes.
> there is no easy solution... Oh well, I'll have to cope. But I still wonder,
> shouldn't this show up on netstat -i? netstat -s does show the dropped packets,
> anyway...
I'm not sure about this. In fact, that's a good question. Usually,
if the queue is full, we should increment ifp->if_snd.ifq_drops as well
as ipstat.ips_odropped. Perhaps this test ought to be more like:
[lock ifp->if_snd]
if ((ifp->if_snd.ifq_len + ip->ip_len / ifp->if_mtu + 1) >
ifp->if_snd.ifq_maxlen) {
error = ENOBUFS;
_IFQ_DROP(ifp->if_snd);
ipstat.ips_odropped++;
goto bad;
}
[queue packet...]
[etc...]
[unlock ifp->if_snd]
Note that we presently don't lock anything (this is expected, we
haven't gotten there yet). However, note also that in the new version we
also do an "_IFQ_DROP()" if we have exceeded the ifq_maxlen, and
finally, also note that the new test is ">" and not ">=" - I don't know
why it is ">=" to begin with. One would think that we should be testing
for whether we are going to _exceed_ ifq_maxlen, not if we're going to
reach it (we should be allowed to reach it).
You should take my suggestion here with a grain of salt, and I think
the best person to comment on this is Jonathan Lemon.
> So, no solution, right? :(
Well, you're sending out packets faster than your hardware can
transmit them. You can `artificially' define IFQ_MAXLEN to something
greater than 50 but practically, you probably won't get much besides for
consuming more memory for the output queue.
> Bye,
> Andrea
>
> --
> The best things in life are free, but the
> expensive ones are still worth a look.
>
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: MEXTFREE
On Sat, Dec 22, 2001 at 12:54:16AM -0700, Chad David wrote: > MEXTFREE results in a call to _mext_free() which is only defined within > subr_mbuf.c, and is not static. Should the prototype be moved into > sys/mbuf.h, or should MEXTFREE be moved into subr_mbuf.c, or is it ok > like this? It should stay like this. The easy (macro) case deals with only the reference count issue. We only call the function if we really have to free the object (i.e. ref count is dropped to zero). > Thanks. > > -- > Chad David[EMAIL PROTECTED] > ACNS Inc. Calgary, Alberta Canada -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Junior Annoying Hacker Task
On Fri, Feb 01, 2002 at 04:26:13PM -0800, Terry Lambert wrote: > Who is a GTK hacker? > > Does someone want to write a "registry editor" program? > > The point of the program would be to edit the "FreeBSD > Registry", rc.conf, and make it look just like the Windows > Registry in the editor, using "_" as the implied path > component/terminal component (key) seperator. > > Then we can all be honest with ourselves that the only > difference between it an the Windows Registry is that > the Windows registry is accessible/modifiable from > kernel mode, and the path component and key names. > > You can start with: > > My Computer\HKEY_LOCAL_MACHINE\natd > > NameData > --- - > enable NO > interface fxp0 > > My Computer\HKEY_LOCAL_MACHINE\inetd > > NameData > --- - > enable NO > program /usr/sbin/inetd > > etc. > > If you want to get ambitious: > > o Make "HKEY_LOCAL_MACHINE" an alias for your node name, > and include your node name in the list. > > o Call it "localhost", if you are feeling too guilty > about calling it "HKEY_LOCAL_MACHINE". > > o Make the tool operate on node names other than > "localhost", so you can do remote administration > of configuration files on a cluster of FreeBSD > boxes > > o Add more subkeys; perhaps it should not be just > > My Computer\localhost\inetd > > but > > My Computer\localhost\rc.conf\inetd > > letting you fold in the other files, like the > inetd.conf, into "registry handlers", e.g.: > > My Computer\localhost\inetd.conf\telnet > > enable NO > sockettype stream > protocoltcp > waitNO > userroot > program /usr/libexec/telnetd > > etc.. > > o Support sysctls in the HKEY_DYN_DATA and HKEY_CURRENT_CONFIG > sections (for those that can go into loader.rc). This last point is neat, especially if whoever is doing it could setup something with the doc team and actually get to actively documenting, as things progress, what each sysctl does and affects. > Sure, people would be annoyed to find out that they had been > moving towards an idea that Microsoft had developed, but > wouldn't this be a fun tweak to people's tails? > > 8-) 8-) 8-) > > -- Terry -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch to improve mutex collision performance
On Mon, Feb 18, 2002 at 11:51:44AM -0800, Matthew Dillon wrote: > > :I request that you give say a 3 day review period for this. > :I know JHB still has limited email access (no DSL yet). > :This may be something he should review. > > Sigh. Are you intending to ask me to have JHB review every single change > I make to -current? Because if you are the answer is: "Are you out of > your mind?". > > I'm fairly sure JHB does not have a patch to address this but, please, > be my guest and check P4. I've looked at it and I think it's OK. There are a few minor things I could think of, but they are only related to the context-borrowing interrupt stuff I'm working on in parallel (notably, when it goes in, I'll modify the "if ()" statement in there to add a check and only perform the lazy spin if we're not borrowing context). This only to say that I'm glad that you at least posted it for review, as it allowed me to make a quick note of this. The only other issue has to do with you getting pre-empted by, say, an interrupt after dropping sched_lock and then, should the lock you're trying to get become contested while the handler is running, have relatively weak priority on it after you iret and continue iterating. However, the odds of this happening are not only weak but this small loss of priority already exists in the locking code anyway (think of when we're trying to get a lock and get pre-empted right after failing to get it but before grabbing sched_lock and putting ourselves to sleep). So, in effect, it's a non-issue. > -Matt > Matthew Dillon > <[EMAIL PROTECTED]> -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Inscription
Stephane Legrand wrote: > On Wed, Feb 28, 2001 at 02:46:06PM +0100, Patrice JACQUES-GUSTAVE wrote: > > Bonjour à tous !!! > > > > Je découvre jour après jour Freebsd, qui finit par vraiment me plaire. Du > > coup, j'aimerais faire partie de votre liste de diffusion. > > > > Merci d'avance et merci à vous tous... > > > > Bonjour, > > Attention, "freebsd-current" est une liste en langue anglaise, il > faut normalement éviter d'envoyer des messages dans une autre > langue. Si vous voulez toujours vous inscrire, la procédure à suivre > est indiquée sur > http://www.freebsd.org/handbook/eresources.html#ERESOURCES-MAIL > par exemple. > > Pour info, il existe une liste de diffusion francophone au sujet > de FreeBSD. Pour plus de détails et pour vous inscrire, vous pouvez > consulter http://www.freebsd-fr.org/mailing-lists.html Attention. Certains de nous parlent et écrivent le français, quand même. :-) > > Cordialement. > Stéphane Legrand. > > -- > [EMAIL PROTECTED] > FreeBSD Francophone : http://www.freebsd-fr.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FW: Filesystem gets a huge performance boost
On Tue, Apr 17, 2001 at 10:18:34PM +, E.B. Dreger wrote: > > Once the mutexes are in place the underlying implementation can > > change pretty easily from task switching always to only task > > switching when the mutex is owned by the same CPU that I'm running > > I'm not sure that I follow... if the task switch is on the same CPU, then > why do we need any new structures? Without a global memory cache*, I > think that keeping processes on the same CPU is the first goal, anyway, > and increased concurrency second. > > * Does Intel have any sort of cache coherency mechanism, where a processor > can tell other CPUs, "hey, this line is dirty" and the others retrieve the > new info as needed? The Alpha? There is a mechanism, yes. Whether or not it can be compared to the Alpha's, I have no idea. :-) Intel provides documentation on-line detailing somewhat how cache invalidating happens. Unfortunately, I lost the exact URL in recent CURRENT crashes (ahhh, the irony of it all :-)), so you'll have to dig a little. > > on. (to avoid spinlock deadlock) > > > > I agree that task switching _might_ be a performance hit, however > > that can be fixed by only task switching when in interrupt context. > > Ughh. AFAIK, traditional wisdom holds that interrupt loops should be as > short as possible. Assuming that one performs quick operations, DMA > transfers, etc., preemptive task switching *would* be expensive. Probably true, but then you really only need to task switch if all the CPUs are busy. So, as you say somewhere earlier in this message, "on a lightly loaded system," this actually won't be the case. > > A lot of things remain to be seen, but only if people like you sit > > down and start working with the SMP team to achieve the main goal, > > which is making the kernel MP safe for concurrant execution by > > locking down the appropriate structures and code paths. > > Let's look at userland code. I don't use async I/O because I don't want > to screw with interrupts and callbacks. Polling of large structures? > Ughh. Kernel queues are the solution, and what totally sold me on > FreeBSD. > > How about basing things on *cooperative* multitasking? All else being > equal, cooperative is faster because of lower overhead. What makes co-op > break down is greedy programs that monopolize the CPU... but there should > not be any code like that in the kernel. > > My instinct (whatever it's worth; remember my disclaimer) is that co-op > switching using something like tsleep() and wakeup_one() or similar would > be more efficient than trying to screw with mutexes. > > However, perhaps that could be improved upon: Use something a la kqueue > for portions of the kernel to say "I'm waiting for condition XYZ". When > we wakeup_one(), we specify "for condition XYZ". We could then avoid > waking processes that would only go back to sleep again. See condition variables, as those are the closest I can think of regarding what you described. They are implemented in -CURRENT. > I hope that I'm not too far out of my league, here... :-) > > > Eddy > > ------- > > Brotsman & Dreger, Inc. > EverQuick Internet / EternalCommerce Division > > Phone: (316) 794-8922 > > --- Later, -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel preemption, yes or no? (was: Filesystem gets a huge performance boost)
On Tue, Apr 17, 2001 at 05:47:23PM -0700, Matt Dillon wrote:
> Proposed:
>
> mainline kernel {
> get_spin_mutex(&somemutex);
> .
> .
> masked interrupt occurs, interrupt structure contains array
> of mutexes the interrupt will need. Check said mutexes, one
> found to be held by current cpu. Set interrupt-pending bit
> in mutex and iret immediately.
You cannot be pre-empted by an interrupt if you are holding a spin
mutex, AFAIK, even under present implementation.
> .
> .
> release_spin_mutex(&somemutex)
> (bit found to be set in mutex, triggers interrupt reissuing code)
> }
>
> And there you have it. The mutex/array test is takes very little time
> being a read-only test that requires no bus locking, and the collision
> case is cheap also because the current cpu already owns the mutex, allowing
> us to set the interrupt-pending bit in that mutex without any bus
> locking. The check during the release of the mutex is two instructions,
> no bus locking required. The whole thing can be implemented without any
> additional bus locking and virtually no contention.
>
> The case could be further optimized by requiring that interrupts only
> use a single mutex, period. This would allow the mainline interrupt
> routine to obtain the mutex on entry to the interrupt and allow the
> reissuing code to reissue the interrupt without freeing the mutex that
> caused the reissue, so the mutex is held throughout and then freed by
> the interrupt itself.
>
> Holy shit. I think that's it! I don't think it can get much better then
> that. It solves all of BDE's issues, solves the interrupt-as-thread
> issue (by not using threads for interrupts at all), and removes a huge
> amount of unnecessary complexity from the system. We could even get rid
> of the idle processes if we wanted to.
What happens if we get an interrupt, we're thinking about servicing
it, about to check whether we're already holding a mutex that may potentially
be used inside the mainline int routine, and another CPU becomes idle?
In this particular case, let's say that we decide that we have to set
ipending and iret immediately, because we're already holding a potential
lock when we got interrupted. Isn't the result that we have a second
CPU idling while we just set ipending? (I could be missing something, really).
Also, some mainline interrupt code may need to acquire a really
large number of locks, but only in some cases. Let's say we have to first
check if we have a free cached buffer sitting somewhere, and if not, malloc()
a new one. Well, the malloc() will eventually trigger a chain of mutex
lock operations, but only in the case where we lack the cached buffer to
allocate it. There is no practical way of telling up front whether or not
we'll have to malloc(), so I'm wondering how efficiently we would be able
to predict in cases such as these?
> -Matt
Cheers,
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: lock recursion in uipc_mbuf.c
Although I'm ripping all this out and replacing it with new code within [hopefully] the next week, a backtrace would be nice nonetheless. On Tue, Jun 12, 2001 at 06:00:34PM -0500, Michael Harnois wrote: > This is from today's current. Can you spot the problem from this or do > you need a backtrace? > > recursed on non-recursive lock (sleep mutex) mbuf free list lock @ > ../../kern/uipc_mbuf.c:573 > > -- > Michael D. Harnois[EMAIL PROTECTED] > Redeemer Lutheran Church Washburn, Iowa > God made everything out of nothing, > but the nothingness shows through. -- Paul Valery Regards, -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
New SMP Mbuf Allocator (PATCH and TESTING request)
Hi -current && -alpha, If you run -CURRENT on multiprocessor alpha, please please please read this! :-) The final version (or next to final, depending on how this final testing stage goes) of the new mbuf allocator which I have been working on for the past 1.5 months and which I've already mentionned on -arch is now ready. I plan to commit the new bits within the next week. However, as is usually the case with commits of this magnitude, I'd like a few more tests to be run by a few more people. I've been testing the allocator myself (in several different ways, mainly resource exhaustion simulations) for the past couple of weeks and have been able to catch and fix a couple of bugs. Also, jake, jlemon, and Silby (Mike Silbersack) have provided me with some reviews, all of which have been integrated into the latest version of the patch (below). The latest version of the "mb_alloc" code, applying to -CURRENT as of 5 minutes ago can be found here: http://people.freebsd.org/~bmilekic/code/mb_slab/mb_alloc-LATEST.diff People who have the following hardware are needed to help test the patch: 1- UP -CURRENT systems (Intel && Alpha) 2- SMP -CURRENT systems (Intel) 3- SMP -CURRENT systems (Alpha) *** Especially important *** who are *not* using the if_vx.c driver [*] [*] The if_vx.c driver is broken for the Alpha, and is marked so by this patch. Before committing this, I plan to first fix the driver but, obviously, for now, if you are using if_vx, you won't be able to help with testing. :-( To test the patch: apply, build, reboot, do network-related things, check stats with `netstat -m', etc. For those looking at the code: Finally, a few things should be noted about the code itself (if you're just helping test, feel free to skip this part): - I disabled mbtypes[] related statistics _FOR NOW_. This is because if I were to presently enable them, I wouldn't be able to consistently update them (unless I do it atomic()ally, which is not so good for overall performance). I plan to re-enable them later on, but would prefer to wait and go over them (perhaps clean them up - add/remove types as needed - many are if 0'd anyway) rather than rush and waste time doing it now. - The patch is big. sys/mbuf.h includes need to also #include _BEFORE_ because sys/mbuf.h requires MALLOC_DECLARE() to be defined. - counters for m_ext objects are now all malloc()ed. This will likely eventually change for what concerns clusters (I am looking at storing the cluster counter in the cluster 2 region itself). For other object types, I plan to leave malloc() as the standard allocator for the counters, seeing as how the external objects are not allocated in a PCPU fashion anyway. That's it! This patch also sets up the way to more mbuf-related cleanups (i.e. obvious ones like merging uipc_mbuf.c code with uipc_mbuf2.c code, and ridding ourselves of the latter, etc.). It also moves a bundle of mbuf related things out of sys/conf/param.c and into subr_mbuf.c, where they will now belong. :-) Best Regards and PLEASE help test (especially if you have alpha hardware!!!), -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New SMP Mbuf Allocator (PATCH and TESTING request)
On Tue, Jun 12, 2001 at 10:13:12PM -0700, Matthew Jacob wrote: > > Right, will do some testing, thanks.. can you give us a bit more than a week > tho? Your prompt reply is extremely encouraging. Thanks! :- The reason I said "in the next week" is actually because on Sat. June 23rd (not this upcoming one, but the one after), I should be flying off to Yugoslavia (actually to London, and only then to Yugoslavia). I will be gone for 3 weeks and seeing as how maintaining this huge diff is a real (especially given the state of -CURRENT, as I'm sure you know :-)), I would really like to commit it before then. Preferably not this next Thursday (this week) but the thursday next week, to give me a 1.5 day `buffer zone' in case of emergency (The Infamous Pointy-Hat Award). I've given it considerable testing on Intel hardware and don't really expect any problems on alpha, but better be safe than accidently break alpha and have some very peeved developers on my tail. :-) Cheers and thanks again, -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New SMP Mbuf Allocator (PATCH and TESTING request)
On Wed, Jun 13, 2001 at 12:48:14AM -0700, Mike Smith wrote: > > The reason I said "in the next week" is actually because on Sat. June 23rd > > (not this upcoming one, but the one after), I should be flying off to > > Yugoslavia (actually to London, and only then to Yugoslavia). I will be > > gone for 3 weeks and seeing as how maintaining this huge diff is a real > > (especially given the state of -CURRENT, as I'm sure you know :-)), > > I realise that maintaining the diff is a major pain, but this is *not* a > good reason to be rushing it now, *especially* when you're going to be > gone for three weeks. I'm not rushing it. > I appreciate the extra work involved, but please take this as an > extremely serious request to defer your commit until it's had some more > testing, and until you're in a position to support it for more than 36 > hours after you commit. This is likely going to happen anyway, following some discussions with Bruce, in order to improve the situation of sys/mbuf.h :-) However, testing should still continue as none of the planned changes affect any of the conceptual/functional bits. > Thanks. > > -- > ... every activity meets with opposition, everyone who acts has his > rivals and unfortunately opponents also. But not because people want > to be opponents, rather because the tasks and relationships force > people to take different points of view. [Dr. Fritz Todt] >V I C T O R Y N O T V E N G E A N C E Cheers, -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MBUF locking- this can't be right, can it?
Yes, I certainly didn't write that. I think it was KAME.
On Wed, Jun 13, 2001 at 10:37:22AM -0700, Matthew Jacob wrote:
>
> A recent change to the MFREE macro was made as noted below:
>
> /*
> * MFREE(struct mbuf *m, struct mbuf *n)
> * Free a single mbuf and associated external storage.
> * Place the successor, if any, in n.
> *
> * we do need to check non-first mbuf for m_aux, since some of existing
> * code does not call M_PREPEND properly.
> * (example: call to bpf_mtap from drivers)
> */
> #define MFREE(m, n) do {\
> struct mbuf *_mm = (m); \
> \
> KASSERT(_mm->m_type != MT_FREE, ("freeing free mbuf")); \
> if (_mm->m_flags & M_EXT) \
> MEXTFREE(_mm); \
> mtx_lock(&mbuf_mtx);\
> mbtypes[_mm->m_type]--; \
> ++if ((_mm->m_flags & M_PKTHDR) != 0 && _mm->m_pkthdr.aux) { \
> ++m_freem(_mm->m_pkthdr.aux); \
> ++_mm->m_pkthdr.aux = NULL; \
> ++} \
> _mm->m_type = MT_FREE; \
> mbtypes[MT_FREE]++; \
> (n) = _mm->m_next; \
> _mm->m_next = mmbfree.m_head; \
> mmbfree.m_head = _mm; \
> MBWAKEUP(m_mballoc_wid, &mmbfree.m_starved);\
> mtx_unlock(&mbuf_mtx); \
> } while (0)
>
>
> Unfortunately, m_freem also calls MFREE. Tsk. Now, it seems to me that even in
> cases where you *could* allow recursive locks, the right idea here would be to
> change it to:
>
> /*
> * MFREE(struct mbuf *m, struct mbuf *n)
> * Free a single mbuf and associated external storage.
> * Place the successor, if any, in n.
> *
> * we do need to check non-first mbuf for m_aux, since some of existing
> * code does not call M_PREPEND properly.
> * (example: call to bpf_mtap from drivers)
> */
> #define MFREE(m, n) do {\
> struct mbuf *_mm = (m); \
> struct mbuf *_aux; \
> \
> KASSERT(_mm->m_type != MT_FREE, ("freeing free mbuf")); \
> if (_mm->m_flags & M_EXT) \
> MEXTFREE(_mm); \
> mtx_lock(&mbuf_mtx);\
> mbtypes[_mm->m_type]--; \
> if ((_mm->m_flags & M_PKTHDR) != 0 && _mm->m_pkthdr.aux) { \
> _aux = _mm->m_pkthdr.aux; \
> _mm->m_pkthdr.aux = NULL; \
> } else {\
> _aux = NULL;\
> } \
> _mm->m_type = MT_FREE; \
> mbtypes[MT_FREE]++; \
> (n) = _mm->m_next; \
> _mm->m_next = mmbfree.m_head; \
> mmbfree.m_head = _mm; \
> MBWAKEUP(m_mballoc_wid, &mmbfree.m_starved);\
> mtx_unlock(&mbuf_mtx); \
> if (_aux) \
> m_freem(_aux); \
> } while (0)
>
>
> Comments?
>
> -matt
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: MBUF locking- this can't be right, can it?
On Thu, Jun 14, 2001 at 03:12:06AM +0900, Hajimu UMEMOTO wrote: > >>>>> On Wed, 13 Jun 2001 13:42:51 -0400 > >>>>> Bosko Milekic <[EMAIL PROTECTED]> said: > > bmilekic> Yes, I certainly didn't write that. I think it was KAME. > > Yup, current KAME is based on 4.3-RELEASE which doesn't have > mtx_lock() issue. It is my mistake during merging it into 5-CURRENT. > The fix looks good to me. If there is no objection, I'll commit it. Nope, no objection here. :-) Regards, -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New SMP Mbuf Allocator (PATCH and TESTING request)
Folks, I have a new version of the patch for you to test. It's up: http://people.freebsd.org/~bmilekic/code/mb_slab/mb_alloc-LATEST.diff (same place as before). The difference is that I have removed the HUGE src/sys sweep for #include's and have removed the need to include before . This had the added effect of effectively nuking the allocation/deallocation macros in sys/mbuf.h, which is good because what was previously there was a pessimization. The reason it was a pessimization was because callers that used the macros would only pay the cost of one function call but callers that used the function equivalents would pay the cost of two function calls, even in the best case scenario. With these changes, all callers do one function call per allocation. Bruce: Would you please glance over these changes (particularily the mbuf.h and the bottom of subr_mbuf.c - m_get() and downward)? I think it fixes the problem you brought up to me earlier today. :-) Matt Jacob: If you have already started testing the other diff, that's okay, nothing much has changed functionally. However, if you haven't or if you have extra time, please consider backing it out and applying this one. Sorry for the inconvenience. Cheers, Bosko. On Wed, Jun 13, 2001 at 01:07:44AM -0400, Bosko Milekic wrote: > > Hi -current && -alpha, > > If you run -CURRENT on multiprocessor alpha, please > please please read this! :-) > > The final version (or next to final, depending on how > this final testing stage goes) of the new mbuf allocator which > I have been working on for the past 1.5 months and which I've > already mentionned on -arch is now ready. > I plan to commit the new bits within the next week. > However, as is usually the case with commits of this magnitude, > I'd like a few more tests to be run by a few more people. > I've been testing the allocator myself (in several different > ways, mainly resource exhaustion simulations) for the past > couple of weeks and have been able to catch and fix a couple > of bugs. > Also, jake, jlemon, and Silby (Mike Silbersack) have > provided me with some reviews, all of which have been integrated > into the latest version of the patch (below). > > The latest version of the "mb_alloc" code, applying > to -CURRENT as of 5 minutes ago can be found here: > > http://people.freebsd.org/~bmilekic/code/mb_slab/mb_alloc-LATEST.diff > > People who have the following hardware are needed to help > test the patch: > > 1- UP -CURRENT systems (Intel && Alpha) > 2- SMP -CURRENT systems (Intel) > 3- SMP -CURRENT systems (Alpha) *** Especially important *** > who are *not* using the if_vx.c driver [*] > > [*] The if_vx.c driver is broken for the Alpha, and is marked so > by this patch. Before committing this, I plan to first fix > the driver but, obviously, for now, if you are > using if_vx, you won't be able to help with testing. :-( > > To test the patch: apply, build, reboot, do network-related > things, check stats with `netstat -m', etc. > > For those looking at the code: > > Finally, a few things should be noted about the code > itself (if you're just helping test, feel free to skip this > part): > > - I disabled mbtypes[] related statistics _FOR NOW_. This is >because if I were to presently enable them, I wouldn't be >able to consistently update them (unless I do it atomic()ally, >which is not so good for overall performance). I plan to >re-enable them later on, but would prefer to wait and >go over them (perhaps clean them up - add/remove types as >needed - many are if 0'd anyway) rather than rush and waste >time doing it now. > > - The patch is big. sys/mbuf.h includes need to also #include > _BEFORE_ because sys/mbuf.h requires >MALLOC_DECLARE() to be defined. > > - counters for m_ext objects are now all malloc()ed. This will >likely eventually change for what concerns clusters (I am >looking at storing the cluster counter in the cluster 2 >region itself). For other object types, I plan to leave >malloc() as the standard allocator for the counters, seeing >as how the external objects are not allocated in a PCPU >fashion anyway. > > That's it! This patch also sets up the way to more > mbuf-related cleanups (i.e. obvious ones like merging uipc_mbuf.c > code with uipc_mbuf2.c code, and ridding ourselves of the latter, > etc.). It also moves a bundle of mbuf related things out of > sys/conf/param.c and into subr_mbuf.c, where they will now > belong. :-) > > Best Regards and PLEASE help test (especially if you have alpha > hardware!!!), > -- > Bosko Milekic > [EMAIL PROTECTED] -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New SMP Mbuf Allocator (PATCH and TESTING request)
gt; > You realize that there is a dependency on MAXFILES, right? > > Specifically, there is an mbuf allocated per open socket > for the tcptmpl (even though it only needs 60 bytes). > > --- > > If you fix the tcptmpl allocation, a couple of additional > issues arise: > > 1)Since the allocations are in page-units, you will > end up with a lot of waste. > > 2)Allocation in page units will make it hard to give > 60 byte allocations back to the system. > > 3)The allocator is not really general enough for this > (or for things like TIME_WAIT zombie structs, etc.). > > 4)Yeah, this sort of also implies that mbuf cluster > headers come from a seperate pool, instead of being > 256 bytes as well... Huh? I haven't changed anything in terms of the sizes of allocations. The allocator only allocates mbufs and clusters, which are of fixed size in order to ease allocations of the same object in page units (it's much faster and simpler). I realize that some wastage occurs but that's just a fact of BSD (and has been forever). The new allocator doesn't make it worse. > -- > > Why do you lock around things in mb_init()? It's never > called twice, let alone reentrantly... the code will be > done before an AP is allowed to run. Alpha has this same > restriction, from what I can see from the code. > > -- Simply because mb_pop_cont() expects it and because it's a consistent thing to do with respect to the internal interface. > Dropping the lock in mb_pop_cont() seems wrong; I guess > you are avoiding sleeping with the lock held? > > I don't think you need to worry (per-CPU, again), unless > you later attempt lazy repopulation; it seems to me that > the lock that should be held is a global lock, to prevent > reentrancy on the global memory pool, and the malloc() > code does that. > > Perhaps I'm missing something here. Yeah. There have been some discussions as to why this is presently necessary. In the future, it may not be required. But, basically, right now, we can have Giant -> mbuf_related_lock and, if I don't drop the lock, then also mbuf_related_lock -> Giant, which would be a lock order reversal. > -- > > The ability to specify a "how" that implies an unwillingness > to block implies interrupt allocation; yet you can't support > this, since you do not preallocate a kernel map (ala the zone > allocator). The zone allocator is actually very misleading, > in that some of it's code never has the values it implies that > it might have; in particular, there are functions which are > passed parameters which can't really be variant, as implied by > the use of per zone variables as arguments. Although I don't quite understand everything you mention in this last paragraph, the `how' parameter implies more than just willingness to block in the new allocator. It also determines whether or not, during starvation, the system will call the protocol drain routines and whether or not it will attempt to "steal" from other CPU lists. Feel free to clarify, though, if it's still a concern. > -- > > Ah. I see why all the locks: mb_alloc_wait attempts to be > a primitive reclaimer. You would do much better with a per-CPU > high-watermark reclaim at free(), I think, instead of doing > this. Really, you are in a starvation condition because of > your load, and not because someone is "hogging already free > mbufs", I think. This is probably premature optimization. > > -- > > In the starvation case during a free, I don't think you > really care, except perhaps to adjust the high/low watermarks. > > An interesting issue here is that the average TCP window size > will end up being 16k, which comes out to 4 1-page buckets (2, > on Alpha), where you end up with multiple buckets and many > mbufs (64) per, so freeing isn't really an option, if you are > sending lots of data (serving content). It would be different > for a desktop system, since the receive interrupt might come > to any idle CPU. > > -- > > I like the cleanup via the use of local macros. Thanks. So do I. :-) > -- > > I think the m_getclr -> m_get_clrd change is gratuitous. m_getclr() isn't used at many places so it's not that big of a deal. The reason I changed it is because it's confusing: m_getclr() sounds like "m_get a cluster." > -- > > I like the "only" comment claifications. > > -- > > I dislike the bloating of one line comments into three lines, > with the first and last blank. It happens once or twice, as far as I could see (
New Mbuf Allocator (some graphs)
Hi Folks, Here are some performance results. Keep in mind that we're still under Giant. http://people.freebsd.org/~bmilekic/code/mb_alloc/results.html Terry, is this OK for you? Regards, -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New Mbuf Allocator (some graphs)
On Fri, Jun 15, 2001 at 06:32:55PM -0500, Jonathan Lemon wrote: > On Fri, Jun 15, 2001 at 06:54:21PM -0400, Bosko Milekic wrote: > > > > Hi Folks, > > > > Here are some performance results. Keep in mind that we're still under > > Giant. > > > > http://people.freebsd.org/~bmilekic/code/mb_alloc/results.html > > Just for comparision, 6-way results are at: > > http://www.flugsvamp.com/~jlemon/fbsd/netpipe/ Are you sure those aren't inverted? (i.e. swap(present, mb_alloc)?) In any case, the mb_alloc code you used still has the malloc() and free() calls during cluster allocation and freeing and still, it looks to me as very comparable nonetheless. > -- > Jonathan -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New Mbuf Allocator (some graphs)
On Fri, Jun 15, 2001 at 06:55:29PM -0500, Jonathan Lemon wrote: > > In any case, the mb_alloc code you used still has the malloc() and > > free() calls during cluster allocation and freeing and still, it looks to > > me as very comparable nonetheless. > > The results look good to me; the only thing that really stands out > is the signature graph for stream tests; that odd curve at the start > of the run. However, if I'm interpreting it correctly, it shows > better performance in the mb_alloc case. Oh yeah, they're certainly decent, especially given that we're under Giant. Remember that the scalability should come into play only when Giant is unzipped, and then there is space for improvement. For me, all that matters is that there is no significant degradation at this point, because the new allocator has another significant advantage over the old one: possibility of resource reclamation. As for the `bulge' it is likely related to the fact that your old allocator code may not be configured to pre-allocate enough mbufs and/or clusters so it's stuck fetching from the map. But, in any case, although mb_alloc does show to be slightly better here, keep in mind that the x-axis is logarithmically scaled, so the difference is rather minimal. > -- > Jonathan Cheers, -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New Mbuf Allocator (some graphs)
On Sat, Jun 16, 2001 at 03:11:21AM -0400, Alfred Perlstein wrote: > It would be better if we could allocate/free clusters+mbufs+refcounts > under a single lock. It would simplify the API and save a boatload > of cycles and i-cache by avoiding the mutex operations. > > Not that I object to the current code, I'm just wondering when this > important optimization is going to be made, or that the interface > will settle down enough so that I can get started on it. Well, as I've mentionned to you previously, I don't think this will be an optimization. The mb_alloc code already shares the same lock for both mbufs and clusters and, as for counters, it is not efficient to allocate them from the mb_alloc allocation routines (due to their extremely small size, we would consume double the memory to manage them). So what I've done in mb_alloc is have the counters malloc()ed. However, as I've mentionned, and as I've already (although quickly) implemented in order to perform testing, I'm going to change it so that for clusters, the space for the reference counter will actually be located at the end of the unused portion of the cluster. As for the other types of buffers, I'll have to sit and think about it some more but there are obvious solutions that are more optimal than the present malloc() scheme which I've put in for simplicity purposes. In any case, I don't *think* it will be an actual optimization (because the lists are now per-CPU and there doesn't seem to be a genuine reason for it), but if, once the dust settles, you can figure out a way to easily implement it without pessimizing any of the code to do it, then it's certainly worth a shot. After all, you were right about some of these not-so-obvious things before. :-) I think that once we have the new code in, and once I fix the little malloc() thing, that we should really focus on the remainder of the net code simply because I want to see Giant get lifted from this area. > -- > -Alfred Perlstein [[EMAIL PROTECTED]] > Instead of asking why a piece of software is using "1970s technology," > start asking why software is ignoring 30 years of accumulated wisdom. Regards, -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[HEADS-UP]: Mbuf allocator changes
Hi -current people, I have recently made some significant changes to the mbuf allocator. Although I have invested, along with several other developers, very significant time in testing the newly introduced code, should any problems arise, please let me know ASAP. One noticeable difference that I am aware of is that mbtypes statistics have been TEMPORARILY disabled. Please be patient. :-) Thank you for flying -CURRENT, -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [HEADS-UP]: Mbuf allocator changes
On Fri, Jun 22, 2001 at 11:45:50AM -0400, Alexander N. Kabaev wrote: > UP kernel can not be compiled in -CURRENT after your changes because > kern/subr_mbuf.c references mp_ncpus variable, which is defined only in SMP > case. Should this variable be moved out of #ifdef SMP? It turns out that it should stay under SMP ifdef. I'll fix this another way immediately. Please allow an hour or so for testing. Thanks! Oh, would somebody please pass the Pointy Hat this way? > > E-Mail: Alexander N. Kabaev <[EMAIL PROTECTED]> > Date: 22-Jun-2001 > Time: 11:41:47 > -------- Regards, -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [HEADS-UP]: Mbuf allocator changes
On Fri, Jun 22, 2001 at 08:51:55AM -0700, Matthew Jacob wrote: > > I would think not. > > Bosko might be gone now. I'll look at this as soon as a CVS update continues. > > It's odd, though. A GENERIC kernel built for me yesterday w/o problems. Nah, don't worry. I'm still here (and plan to remain until I'm sure to have knocked out the initial problems). When I leave (tomorrow night) and once I get settled in, I will get a dialup and be in the vincinity to commit emergency changes (such as this) if necessary. As for this, I'm in the process of fixing it immediately. Sorry! Cheers, -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current kernel compile broken...
On Fri, Jun 22, 2001 at 09:03:43AM -0700, Matthew Jacob wrote: > > Fixed temporarily at least. > > It seems that the stuff checked in last night is a fair amount different from > the patches I was given to test on alpha. If this is so, this is really not > right or fair. No, it's the same code. The only thing changed is that I've removed the silliness in if_vx (because that's been fixed with the m_devget patch committed earlier) and merged changes to netstat(1) and updated systat(1) so as to not break world. Other than that, the changes are identical. In fact, subr_mbuf.c is identical modulo one of the lines in the copyright. > -matt -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [HEADS-UP]: Mbuf allocator changes
On Fri, Jun 22, 2001 at 01:52:01AM -0500, Alfred Perlstein wrote: > If you want accurate stats you should be able to lock the per-cpu > stats areas all at once as long as you always do it in a certain > order, basically, lock CPU 0, then 1, then 2, then 3, sum then > unlock. If correctness doesn't matter you can just walk the > per cpu stats locking each (or not) and assumulating the info. I don't need to lock the per-CPU locks to merely read the stats (unless I'm reall obsessed with getting consistent stats at the cost of performance every time a person issues `netstat -m' or, even worse, runs `systat -mbufs'). The main issue with the mbtypes stats, as I've previously mentionned, was that it is difficult to *update* them consistently. However, I think I have devised a way. I'll keep you posted if you're interested in reviewing it. > -Alfred Cheers, -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [HEADS-UP]: Mbuf allocator changes
On Fri, Jun 22, 2001 at 10:35:32AM -0700, John Baldwin wrote: > > On 22-Jun-01 Alfred Perlstein wrote: > > * Alexander N. Kabaev <[EMAIL PROTECTED]> [010622 10:46] wrote: > >> UP kernel can not be compiled in -CURRENT after your changes because > >> kern/subr_mbuf.c references mp_ncpus variable, which is defined only in SMP > >> case. Should this variable be moved out of #ifdef SMP? > > > > Yes, I asked for this months ago, I thought it was already done. > > mp_npcus is not initialized, etc. in the UP case. I suppose it could be > statically initialized to 1 and moved, but in that case it needs renaming, as > mp_ncpus implies SMP (mp_ prefix). If you want to make it ncpus and move it to > sys/systm.h and stick it somewhere MI initialized to 1 that is fine. Then > hw.ncpus can reference that (well, it's called hw.ncpu right now, perhaps it > should be renamed to match the variable *shrug*) and kern.smp.cpus can die as > it won't be needed any longer. Note that we already have a (machdep, I think) sysctl exported ncpu variable. > > -Alfred > > -- > > John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [HEADS-UP]: Mbuf allocator changes
On Fri, Jun 22, 2001 at 01:32:21PM -0400, Bosko Milekic wrote: > > mp_ncpus implies SMP (mp_ prefix). If you want to make it ncpus and move it to > > sys/systm.h and stick it somewhere MI initialized to 1 that is fine. Then > > hw.ncpus can reference that (well, it's called hw.ncpu right now, perhaps it > > should be renamed to match the variable *shrug*) and kern.smp.cpus can die as > > it won't be needed any longer. > > Note that we already have a (machdep, I think) sysctl exported ncpu > variable. Doh, I missed the fact that you mentionned this. :-) > > > -Alfred > > > > -- > > > > John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ > > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock order reversals that aren't problematic
On Mon, Jul 30, 2001 at 12:31:43PM -0400, Garrett Wollman wrote: > < said: > > > However, the networking stack is being redone, > > By whom? I haven't seen anything about this posted to -net. I don't think John actually means "redone," just "locked down," or "mutexified." > -GAWollman -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE milestone-2
On Sat, Aug 25, 2001 at 01:37:24PM -0700, Julian Elischer wrote: > > Diffs for KSE milestone 2 are at http://www.freebsd.org/~julian > (about 1.8MB) > > Thanks to Matt Dillon who tracked down the last major instability. > > This is i386 only (some other diffs included but not working) > > This pushes the 'thread' pointer through nearly all of the kernel > in preparation for architectural changes which will > start soon. This is basically -current with > a lot of housekeeping and parameter changes. Do you plan to commit this chunk first, seeing as how it may be stable enough at this point? [...] > In particular kernel hackers are invited to check out diffs in their > own areas of expertise looking for such logical problems. > > > -- > ++ __ _ __ > | __--_|\ Julian Elischer | \ U \/ / hard at work in > | / \ [EMAIL PROTECTED] +-->x USA\ a very strange > | ( OZ)\___ ___ | country ! > +- X_.---._/presently in San Francisco \_/ \\ > v -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE kernel comparissons
On Mon, Aug 27, 2001 at 03:09:53PM -0700, Julian Elischer wrote: > On Mon, 27 Aug 2001, Poul-Henning Kamp wrote: > > > In message <[EMAIL PROTECTED]>, Peter Wemm writes: > > > > >My personal check list before committing it to -current is: > > >- an honest shot at getting the Alpha working. Shouldn't be too hard. > > > I'll work on this if nobody else will. > > >- finish the userland build stuff. > > >- carefully reread all of the key diffs for i386/i386/*, kern/*, vm/* etc. > > >- take a look at ports impact and prepare them for the landing. > > > > If you add: > > > > - Beat the shit out of it together with other developers for a couple of > >weeks. > > > > Then I'm all for committing it when you have checked off those boxes. > > I agree with this list. I think that realistically speaking, after having looked over the diff, and after considering what was discussed here, that it would be a good time to introduce the KSE work done thus far some time soon, after said testing is done. The reason for this is that the KSE changes to date are, as Julian and some others mentionned, "infrastructural changes," and not _functional_ changes. Therefore, I don't expect them to create additional logic issues (e.g. "I wonder if it's KSE's semantics that are breaking this..." shouldn't come up with these changes when debugging other code). Thus, I agree with Peter and Julian on this issue and will be applying the diff to both dual CPU machines I have here and testing tonight. At the same time, I do hope that the actual _functional_ changes come in a hopefully more orderly/slower manner so that it is in fact possible to track down logic problems w.r.t. KSE should they arise. On another (perhaps unrelated) note, I've noticed on the lists at least one or two -CURRENT users/testers insist on having KSE functionality but at the same time expecting to have production material in early 5.0 "releases." I find this to be disturbing. While I do agree that earlier "5.0 releases" should deffinately reach out to the largest userbase possible, I am concerned that some users will perhaps expect so much from the system that they will immediately go ahead and pit it against more mature SMP OSes out there and then go on to complain about everything under the Sun because "brand new functionality (X) is not what I expected." The robustness and performance of the work being done now will become more and more apparent only as things progress and it should be noted that all of these "nice things" resulting from all the work we're presently doing will not just all magically surface when 5.0-RC1 (or whatever it's going to be called) is "released." -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern uipc_socket2.c
Uh-oh. Could this have something to do with the fact that Brian passes `cc' to chgsbsize(), which declares it as a u_long, when in fact it should be handled as an rlim_t, which is really a 64-bit integer? I'm not too sure, as I didn't think at first that reverting just this back would solve the problem. On Thu, 31 Aug 2000, Nickolay Dudorov wrote: > In article <[EMAIL PROTECTED]> you wrote: > > green 2000/08/29 17:09:58 PDT > > > > Modified files: > > sys/kern uipc_socket2.c > > Log: > > Remove an extraneous setting of sb_hiwat. > > > > Revision ChangesPath > > 1.63 +1 -2 src/sys/kern/uipc_socket2.c > > After reverting this file to rev 1.62 i can build, boot > and use my kernel. The kernels builded after yesterday's and today's > cvsup (i.e. with the 1.63 rev of sys/kern/uipc_socket2.c) hung after > ssh-ing to this system (or telnet-ting ;-). (See 'current' and 'stable' > maillists for more detailed description of the problem). > > N.Dudorov Cheers, Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: page fault in sched_ithd
I catch this page fault (described in topic) following an: `ifconfig de0 down' Unfortunately, I don't have much more information to provide for now. I'm in the middle of debugging something else. More info can be provided on request (let me know if you want to look at it and cannot reproduce it). Sources of last friday (evening). On Sun, 10 Sep 2000, Mike Meyer wrote: > Ben Smithurst writes: > > After poking around a bit with remote GDB, this seems to be caused by a > > stray IRQ 7, since irq == 7, ir == ithds[irq] == NULL, ir->foo == BOOM. > > > > The attached rather crude patch has "fixed" the problem for now, but > > does anyone have any suggestions for a real fix? > > Isn't a stray IRQ a hardware glitch? If so, I'd say that logging it > and then ignoring it would be the right thing. > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > > Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
mbuf system with mutexes
For those interested, I have a preliminary patch that will add mutex locking in the mbuf subsystem and get rid of the splimp()s. It also fixes some race conditions previously existing and in relation to tsleep() (i.e. the wait routines). The patch is rough and early, but watch the same space for updates (soon), and please, if you have an SMP machine, give it a whirl (because I don't!). http://www.technokratis.com/code/mbuf/mbuf_mtx.patch Please note that this will only work for i386 for now. I have yet to clean up the initialization code such that it will run decently and as advertised. :-) Also, I plan to tackle as follows, and not necessarily in order: (roughly) a* sendfile(2) stuff SMP-izing b* cleanup mbuf_mtx, fix and tweak c* make sure m_reclaim is okay d* test for exhaustion e* test on real SMP machine f* make sure callers don't hold mutexes when calling with M_WAIT g* make sure the kmem_malloc() stuff has Giant h* atomic (real atomic) manipulation of mbstat * etc... Suggestions, as usual, are always welcome. Please don't consider anything in the above code final, it's the first and very early version. Finally, I'm trying to do this as closly as possible with Alfred's work, so Alfred, maybe you can also glance at point (f) above as well... :-) Cheers, Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "No buffer space available" errors
On Mon, 18 Sep 2000, Ben Smithurst wrote: > Does anyone have any clue what could cause errors like this? I've > been seeing this sort of stuff since the SMPng commit, IIRC. I'm sure > there's more information I should be giving, so just let me know what to > find. dmesg is at the end. This looks an awful lot like something I was seeing during early testing while adding locking to the mbuf system. Try `netstat -m' to see how many mbuf clusters are allocated. I would guess that the system is unable to allocate clusters reliably. In my case, at the time, I had forgotten to change a pointer dereference to meet the new structure, and thus it just worked out that after allocating the initial amount of clusters, nothing more was possible to allocate. I haven't seen this problem after fixing my mistake, nor before introducing it. None of the work I mentionned has been committed at any point in time (yet), so the problem can only be similar, at best (in any case, a `netstat -m' should offer a clue). Regards, Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Locking doc.?
I don't believe so. There are several external resources, such as on-line papers, and so on. There is also a man page (which I've found from jasone's web space) which has been prepared by Sheldon Hearn and which should be at ~jake/mutex.9 As far "standard way to do it" documents - I haven't seen any and I'm not sure how worthwile it would be to do this at this point in time, as the code is still quite dynamic. (Of course, I'm not implying "don't do it," just "be careful when you do it") On Fri, 22 Sep 2000, Julian Elischer wrote: > Do we have a document that descibes in great detail the > locking policy that the SMPng code should follow? > > I've seen several descriptionms as to how it might be done, > but I haven't seen a "Ok we've decided that this is the strategy > we are using" document. > > -- > __--_|\ Julian Elischer > / \ [EMAIL PROTECTED] > ( OZ) World tour 2000 > ---> X_.---._/ presently in: Perth > v Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Locking doc.?
On Fri, 22 Sep 2000, Julian Elischer wrote: > Throwing a lock in every structure is > one > thing but then to tie the whole bundle up together is a completely > different ballgame. Yes, that's the hard part. It can be potentially dangerous to, for example, call the mbuf resource allocation code, while holding a mutex, and with M_WAIT. If the call goes in with M_DONTWAIT, then, theoretically, we shouldn't be blocking, so it's not so much of a big deal. However, for now, if you call with M_WAIT, you better make sure that you're not holding any mutexes going in. According to what I've been able to deduce thus far (and I really haven't looked much yet), BSD/OS seems to do this sort of thing as well (drop a lock on the socket before going in to fetch mbufs with M_WAIT). Their locking in the mbuf system seems less fine-grained than what I have so far (they lock the entire subsystem, effectively, when they're allocating mbufs and mclusters (same lock)). Archie Cobbs recently brought up the idea of writing a mbuf(9) man page which should eventually document, amongst numerous other things, when it's safe to be holding a mutex and when it isn't. As each subsystem will most likely have its own locks, it may be difficult to generalize it all. Bottom line: I do agree that we need such documentation, I just think that's it's difficult to do in a definitive set-in-stone way right now... > -- > __--_|\ Julian Elischer > / \ [EMAIL PROTECTED] > ( OZ) World tour 2000 > ---> X_.---._/ presently in: Perth > v Later, Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[HEADS-UP] mbuf mutex code going in...
Hello, I've just committed the mbuf-related SMPng code please see commit logs for details, and: http://people.freebsd.org/~bmilekic/mtx_journal I sincerely hope that there were little or no errors, as I've tried hard to avoid them. But this is a big diff, it's been sitting around for a while, and it covers a lot of things. So, despite 6 versions of a diff, and numerous reviews, certain things may have slipped through the cracks. Please, don't panic: just report problems and provide all necessary details. I'll do my best to take care of all issues as soon as possible, if necessary. :-) If all goes well, more commits, some adding important functionality, to follow... Regards, Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: page fault while in kernel mode
Hi Michael, Do you think you can provide us with a stack trace, at the least? This would deffinately give us something more to work with. Unfortunately, with this information, it's very difficult to pin-point the problem, as we're not certain as to what is at 0xc029e6cb, exactly. Also, is there anything particular that you notice that is happening in parallel to this? Anything special you're doing? On 3 Oct 2000, Michael Harnois wrote: > The past three days or so with -current my system has been locking up > solid under load. Today I was fortunate enough to have in happen when > in console mode so that I could see the problem: > > Fatal trap 12: page fault while in kernel mode > > fault virtual address = 0x1 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc029e6cb > stack pointer = 0x10:0xcefdfe18 > frame pointer = 0x10:0xccfdfe20 > code segment= base 0x0, limit 0x, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 2355 (procmail) > trap number = 12 > panic: page fault > acpi0: acpi_io_pml_enable(1) = (0) > acpi0: acpi_io_gpe0_enable(1) = (0) > syncing disks... > > -- > Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA > [EMAIL PROTECTED] [EMAIL PROTECTED] > No man knows how bad he is > till he has tried very hard to be good. -- C.S. Lewis Regards, Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: latest ahc panic, more data ...
I've just been hit by one such problem on bootup. This is -current as of
today, so I suspect it's the commits that went in the past two days.
Basically, I tracked it down just enough to know that the problem is
happening during a call to ahc_print_path() in aic7xxx.c, specifically
for me, this happens during bootup in ahc_handle_scsiint() right after
the second call to ahc_abort_scbs().
ahc_print_path() is called like this:
ahc_print_path(ahc, scb);
(why both ahc and scb are being passed, I have no idea, since
ahc_print_path only actually makes use of scb).
For the unaware, ahc_print_path() seems to only wrap a call to
xpt_print_path() to which it passes scb->io_ctx->ccb_h.path as an
argument, and in this case, scb->io_ctx happens to be NULL, so during its
pass, a NULL pointer gets dereferenced and the page fault happens.
The NULLing out of this is coming somewhere in ahc_handle_scsiint(),
because some prior ahc_print_path()s (with the same arguments) are
succeeding.
I have not tried backing out the changes from the past two days and
trying again, but this was not happening a week ago.
So what's going on here?
On Sat, 7 Oct 2000, Marc G. Fournier wrote:
>
> okay, have been watching the conversation going on in the committers list,
> and am watching for any new commits that seem appropriate, but figure
> adding a little bit of extra info as I come up with it might help?
>
> latest reboot had a bit more info then the last, and started with:
>
> ahc0:A:1: ahc_intr - referenced scb not valid during seqint 0x73 scb(147)
> ach0: WARNING no command for scb 147 (cmdcmplt)
> QOUTPOS=132
>
> Marc G. Fournier [EMAIL PROTECTED]
> Systems Administrator @ hub.org
> scrappy@{postgresql|isc}.org ICQ#7615664
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Panic "m_copydata, negative off" out of tcp_output
Is this with code before or after the race condition in the sockbuf limiting code was fixed? On Fri, 13 Oct 2000, Greg Lehey wrote: > I've been having a few panics lately with a PRE_SMPNG snap: [...] > Does anybody recognize this? > > Greg > -- > Finger [EMAIL PROTECTED] for PGP public key > See complete headers for address and phone numbers Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Another broken buildworld?
Hi, I have some trouble building world today; after finally getting over what seemed to be like numerous endian.h related problems... I get failure while building usr.sbin/ppp now. /usr/src/usr.sbin/ppp/atm.c:32: netnatm/natm.h: No such file or directory /usr/src/usr.sbin/ppp/atm.c: In function `atm_CreateDevice': /usr/src/usr.sbin/ppp/atm.c:169: storage size of `sock' isn't known /usr/src/usr.sbin/ppp/atm.c:186: `PROTO_NATMAAL5' undeclared (first use in this function) /usr/src/usr.sbin/ppp/atm.c:186: (Each undeclared identifier is reported only once /usr/src/usr.sbin/ppp/atm.c:186: for each function it appears in.) /usr/src/usr.sbin/ppp/atm.c:169: warning: unused variable `sock' *** Error code 1 ... I don't know who/what broke this. Anybody have any ideas? Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sockstat causing OS lockups
On Thu, 19 Oct 2000, Steve Ames wrote: > admin# sockstat | grep -v '*.*' > close(fstat): > > The OS locked up after that. I'm running -CURRENT from approximately 4 days ago and I am not noticing this. > That's just not normal :) Could someone give me the quick and dirty > on how I can provide additional details? This is on -CURRENT from > 10/16. You should have debugging enabled in your kernel, then you can provide, at least, a stack trace. Please see the relevant handbook section for more information. > The hardware is: [...] Regards, Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Multiply defined 'struct mtx' ?
sys/mbuf.h unfortunately includes sys/mutex.h No obvious workaround is in sight, to my knowledge, anyway. On Sun, 29 Oct 2000, Darren Reed wrote: > > IP Filter doesn't introduce a "struct mtx" which suggests something isn't > protecting against multiple inclusions or similar ? > > Darren > > (ref5:~/freebsd/src/usr.sbin/ipftest) make > Warning: Object directory not changed from original >/d/home/darrenr/freebsd/src/usr.sbin/ipftest > cc -O -pipe -DIPL_NAME=\"/dev/ipl\" -I- >-I/d/home/darrenr/freebsd/src/usr.sbin/ipftest >-I/d/home/darrenr/freebsd/src/usr.sbin/ipftest/../../sys/netinet >-I/d/home/darrenr/freebsd/src/usr.sbin/ipftest/../../sys >-I/d/home/darrenr/freebsd/src/usr.sbin/ipftest/../../contrib/ipfilter -c >/d/home/darrenr/freebsd/src/usr.sbin/ipftest/../../sys/netinet/fil.c > In file included from >/d/home/darrenr/freebsd/src/usr.sbin/ipftest/../../sys/sys/mbuf.h:40, > from >/d/home/darrenr/freebsd/src/usr.sbin/ipftest/../../sys/netinet/fil.c:48: > /d/home/darrenr/freebsd/src/usr.sbin/ipftest/../../sys/sys/mutex.h:110: redefinition >of `struct mtx' > *** Error code 1 > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > > Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel panic with ipfw pipes
Hi, Please try this patch and report: http://people.freebsd.org/~bmilekic/ip_pipe.diff joe, it appears that this commit: Revision 1.114 / (download) - annotate - [select for diffs], Sun Oct 29 01:05:07 2000 UTC (3 weeks, 4 days ago) by joe Changes since 1.113: +7 -3 lines Diff to previous 1.113 (colored) Count per-address statistics for IP fragments. Requested by: ru Obtained from: BSD/OS is the cause of the crashes... joe, please verify that this is the correct fix and let me know so that I can commit. On Wed, 22 Nov 2000, Russell Vincent wrote: > The attached kernel panic occurs when a connection is made that > would pass through an ipfw pipe configured as: > > ipfw add 1000 pipe 1 tcp from any 119 to any out > ipfw add 1001 pipe 2 tcp from any to any 119 in > ipfw pipe 1 config bw 64Kbit/s > ipfw pipe 2 config bw 64Kbit/s > > I can reproduce this at will (and have the vmcore), so if anyone needs > more details, just let me know. > > This is -current of a few days ago (18th Nov 2000, if I recall correctly). > > -Russell Thanks, Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world broken: mbuf.h:120: `MSIZE' undeclared here
No biggie guys... jlemon, I think you may want to remove the include for sys/mbuf.h in if_var.h if it isn't needed (try) -- I think this is what may be screwing up netstat. Sorry, Steve, for this inconvenience, but this stuff does occasionally happen in -CURRENT. :-) On Sat, 25 Nov 2000, Steve Kargl wrote: > ===> usr.bin/netstat > cc -O -pipe -Wall -DIPSEC -DINET6 -DIPSEC -I/usr/obj/usr/src/i386/usr/include -c >/usr/src/usr.bin/netstat/if.c > In file included from /usr/obj/usr/src/i386/usr/include/net/if_var.h:78, > from /usr/src/usr.bin/netstat/if.c:49: > /usr/obj/usr/src/i386/usr/include/sys/mbuf.h:120: `MSIZE' undeclared here (not in a >function) > /usr/obj/usr/src/i386/usr/include/sys/mbuf.h:120: size of array `MH_databuf' has >non-integer type > /usr/obj/usr/src/i386/usr/include/sys/mbuf.h:123: `MSIZE' undeclared here (not in a >function) > /usr/obj/usr/src/i386/usr/include/sys/mbuf.h:123: size of array `M_databuf' has >non-integer type > /usr/obj/usr/src/i386/usr/include/sys/mbuf.h:239: `MCLBYTES' undeclared here (not in >a function) > *** Error code 1 > > Stop in /usr/src/usr.bin/netstat. > *** Error code 1 > > > Sources are from today at 10:27 PST. > -- > Steve Cheers, Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel panic with ipfw pipes
Gentlemen, I'm holding up on committing this as we speak as I believe the counter manipulations become illegal following the ifq locking commits. This is good as it will give us an opportunity/bigger reason to review this code further before making a commit. Feel free to use the diff for yourselves for now. Cheers, Bosko. On Sun, 26 Nov 2000, Clive Lin wrote: > Hi, > > This works ! I was the dummynet victim due to dummynet, but now > I'm saved :-) Hopes this to be committed soon. > > On Thu, Nov 23, 2000 at 11:40:19AM +0800, Bosko Milekic wrote: > > Please try this patch and report: > > > > http://people.freebsd.org/~bmilekic/ip_pipe.diff > > -- > CirX - This site doesnt' exist. > 9c k9o h9 s1bg s1f, 7v .y xqx a sj m8r ffg1 vg5 a6 asox tmul h38. > ant sj m8r ob ? 1fj mwby a1 tao vg5. soq df v' .a. CirX. > > Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic with fairly up to date -current, seems NFS related
On 18 Dec 2000 [EMAIL PROTECTED] wrote: > Since proc can be NULL and most of the other code in nfs_socket > handles it I do think this actually is the right thing to do. > Comments? I'm more concerned with whether it's actually normal for the process pointer to be NULL in the first place. Is this the case? And if so, why is nfs_msg() being called with this pointer being passed in in the first place? > /assar > [...] Regards, Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Network performance-problem
On Tue, 19 Dec 2000, Michael Class wrote: > It seems that NewReno is switched on by default in current. > Unfortunately switching off NewReno does not change the problem. In > times of very high network-traffic I am still unable to use the network. > The system does not even respond to a ping where as all other systems I > have (HPUX 10.20, 11.0 and NT4) behave as expected: slow response-times, > but still working and ping-able. What is your NMBCLUSTERS set to? And in cases of "high traffic," what does `netstat -m' show for number of clusters and mbufs "in use?" How much of mb_map (%) is in use? If any of these are relatively close to exhaustion, try increasing NMBCLUSTERS in your kernel configuration and rebuilding. > At home I am using this Laptop in a 100MB-Network and am able to almost > saturate the link without any problems. Could it be that this is just > happening for multicast-packets (that's what the high network-traffic > is)? > > Anything else I could check? > > TIA > > Michael > > > -- > ___ > Michael ClassE-Mail: [EMAIL PROTECTED] > E-Business Solution Division Phone: +49 7031 14-3707 > Fax:+49 7031 14-4505 > ___ > Hewlett-Packard GmbH, PO Box 1430, Mailstop ESD2, 71004 Boeblingen > Managing Directors: Rainer Geissel (Chairman),Rainer Erlat, Heribert > Schmitz, Hans-Jochen Lueckefett, Fritz Schuller > Chairman of the Supervisory Board: Joerg Menno Harms > Commercial register: Amtsgericht Boeblingen HRB 4081 > ___ > Cheers, Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
mini HEADS-UP: M_WAIT renamed to M_TRYWAIT
Hello, this is a mini-HEADSUP mainly targeted at those working on the kernel source in FreeBSD-CURRENT. In short, for the mbuf subsystem: M_WAIT is now deprecated and M_TRYWAIT should be used in its place. Summary: This ONLY applies to allocations for the "mbuf subsystem" and NOT any allocations with malloc() or any other subsystems: The M_WAIT flag has been renamed to M_TRYWAIT. The commit message explains the reason for the rename. It basically has to do with the developer needing to check whether calls to m_get(), m_gethdr() (and their macro equivalents MGET and MGETHDR) as well as calls to the mbuf cluster allocation routines and macros return a NULL pointer. In other words, even calls with M_(TRYWAIT) may fail in allocating mbufs or mbuf clusters and therefore must be accompanied by a check for that failure. This has been the case for a while and the time spent blocking/waiting for resources is tunable with the kern.ipc.mbuf_wait sysctl. The flag name has been changed in an effort to "communicate the right message" to developers, especially those porting code from NetBSD and OpenBSD where M_WAIT means "block indefinetely if you can't get me anything." M_WAIT is now deprecated and M_TRYWAIT should be used in its place. Happy Holidays! Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: I386_CPU
I'm sorry guys, I haven't been really "up-to-date" on this thread, but I was wondering: can config be made to define I386_CPU 0 if any other cpus are defined (or the inverse behavior)? (Maybe this was already done?) In the sysinstall case, I think it's safe to just exclude all other processors and use the slower I386_CPU kernel. Since the GENERIC kernel config file may contain all of the different CPU types, the config hack may ensure that we're excluding I386_CPU code. Cheers, Bosko. Warner wrote: > In message <[EMAIL PROTECTED]> Peter Wemm writes: > : I've requested a change for UPDATING: > > It is in my queue... I have a few other entries I need to dust off. > I'll try to do that today. > > Warner > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: await/asleep removal imminent
Alfred Perlstein wrote:
> * Alfred Perlstein <[EMAIL PROTECTED]> [010117 09:24] wrote:
> >
> > I'm not going to axe it for a few days, this is a really amazing
> > API that Matt added, the problem is utility and useage over code
> > complexity.
> >
> > It's just a proposal.
>
> I found several places where it may be useful, but I'm not sure if the
> benefits outweigh the gains.
>
> In a copy of the tree I've locked down the socket layer (not the entire
> stack, just sockets :) ) there's code like this:
>
> SOCKBUF_UNLOCK(&so->so_snd, 0);
> if (top == 0) {
> MGETHDR(m, M_TRYWAIT, MT_DATA);
> if (m == NULL) {
> error = ENOBUFS;
> SOCKBUF_LOCK(&so->so_snd, 0);
> goto release;
> }
> mlen = MHLEN;
> ...
> SOCKBUF_LOCK(&so->so_snd, 0); /* XXX */
>
> The lock must be unwound becasue we're calling MGETHDR with M_TRYWAIT.
> If wae used M_TRY'A'WAIT the code would probably look something like
> this:
>
> /* SOCKBUF_UNLOCK(&so->so_snd, 0); */
> again:
> if (top == 0) {
> MGETHDR(m, M_TRYWAIT, MT_DATA);
> if (m == NULL) {
> error = mawait(&so->so_snd.sb_mtx, -1, -1);
> if (error) {
> if (error == EWOULDBLOCK)
> error = ENOBUFS;
> goto release;
> }
> goto again;
> /* SOCKBUF_LOCK(&so->so_snd, 0); */
> }
> mlen = MHLEN;
> ...
> /* SOCKBUF_LOCK(&so->so_snd, 0); */ /* XXX */
>
> Which means we don't have to drop the lock over the socket unless
> we'd block on allocation.
No. You'd still have to drop it for now. Remember? (Last commit to
uipc_mbuf.c). You have to drop it because of the problem you may have if
Giant is gotten before your sockbuf/socket lock. In the allocation, you may
be acquiring Giant again. I don't know the exact semantics, but if you at
some point may grab the sockbuf/socket lock without already holding Giant and
call the allocation routine, you're opening the door for deadlock.
> Matt, is this what you intended for it to do? So far I've only
> seen it used to avoid races, but not to optimize out mutex
> aquire/release.
I've only seen it to be useful to avoid races. If you're holding a lock
and you need to sleep but if you drop the lock before you actually switch you
may get woken up and never find out, thus still going to sleep. With the
asleep you could hold the lock and place yourself on the sleep queue such
that when you drop the lock and call await, you'll find out if you've gotten
awoken (you'll be removed from the sleep queue). With the interlocking with
sched_lock now down in msleep(), this "feature" of asleep/await is useless.
> --
> -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
> "I have the heart of a child; I keep it in a jar on my desk."
Regards,
Bosko.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Small HEADS-UP
Hello, A few hours ago, this has been committed to -CURRENT: Commit log: [...] > Log: > Implement MTX_RECURSE flag for mtx_init(). > All calls to mtx_init() for mutexes that recurse must now include > the MTX_RECURSE bit in the flag argument variable. This change is in > preparation for an upcoming (further) mutex API cleanup. > The witness code will call panic() if a lock is found to recurse but > the MTX_RECURSE bit was not set during the lock's initialization. > > The old MTX_RECURSE "state" bit (in mtx_lock) has been renamed to > MTX_RECURSED, which is more appropriate given its meaning. > > The following locks have been made "recursive," thus far: > eventhandler, Giant, callout, sched_lock, possibly some others declared > in the architecture-specific code, all of the network card driver locks > in pci/, as well as some other locks in dev/ stuff that I've found to > be recursive. [...] This is a small HEADS-UP to let people who have WITNESS turned on that if they stumble into a panic() with a message such as: "[...] recursed on non-recursive mutex foo [...]" to take note of it and report it as soon as possible to the lists (feel free to CC me). I believe that I have covered the large majority of recursive mutexes in the patch, but it's difficult to go through all the surrounding code. So, if I happened to have missed some, it would be good to modify the required mtx_init()s immediately, before further cleanups are done. Thanks, Bosko. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WITNESS may cause failed boot, patch available
Jason Evans wrote: > Peter Wemm noticed that WITNESS currently causes a kernel trap the alpha. > The bug also exists on x86, but does not necessarily cause any problems. > If you run into problems (probably during boot), there is a patch available > that should fix the WITNESS problem: > > http://people.freebsd.org/~jasone/diffs/mutex_f_3.diff This looks like a variation of Peter's mutex.diff which moves a bunch of macros to kern/kern_mutex.c from sys/mutex.h - so is it final now that we will move them there? > Jason -Bosko To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mballoc kernel thread
On Mon, Dec 30, 2002 at 02:35:49AM +0900, Kyunghwan Kim wrote: > I made a mballoc kernel thread that fills up mbufs and mbuf clusters > when number of mbufs/clusters of its general list is under low watermark > along with suggestions that Mr. Milekic has made around late November. > > http://redjade.org/doc/patches/mballoc_kproc.diff > > It seems useful until and even after kmem_malloc() is out from under Giant. > Would someone please comment upon the diff and questions below? > > - Appropriate watermark check rate > - How to use mballoc [via wakeup] in mb_alloc() efficiently when it needs >to allocate a new page >[Hardest for me to decide because of lack of experience...] > - M_WAIT or M_NOWAIT in memory allocation of mballoc kproc > - Strategy for high watermark wash out > > Thanks. > -- > Kyunghwan Kim > [EMAIL PROTECTED] First of all, thanks for taking the incentive to work on FreeBSD code. With that said, I wish you had contacted me before the code-writing began because I'm currently working on a version myself. From a quick glance, your code is OK but the kproc needs to do more than just replenish the caches. It needs to be able to flush out the caches back to VM when necessary, at least, and should be able to perform some sort of basic auto-tuning on the watermarks. Yes, I do see that you have all of this in a "TODO" comment. I don't really know what to tell you because I'm working on the exact same thing (and I mentionned in the Emails you brought up that I would be) except just keep your code and go ahead and finish what you had intended but I doubt that I'll be looking at integrating it before I finish my version. Maybe then we could merge the two, or something. Heck, I don't know. It's not really like doing this is difficult so I don't know how we would resolve the conflict. -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mballoc kernel thread
On Mon, Dec 30, 2002 at 09:35:28AM +0900, Kyunghwan Kim wrote: > On Sun, Dec 29, 2002 at 06:47:35PM -0500, Bosko Milekic wrote: > > I don't really know what > > to tell you because I'm working on the exact same thing (and I > > mentionned in the Emails you brought up that I would be) except just > > keep your code and go ahead and finish what you had intended but I > > doubt that I'll be looking at integrating it before I finish my > > version. Maybe then we could merge the two, or something. Heck, I > > don't know. It's not really like doing this is difficult so I don't > > know how we would resolve the conflict. > > As you said, it was not difficult and a good chance to practice > programming in kernel. In fact, I'm almost a newbie who just wants > all network device drivers in -current to be mp-safe. In either case, it's good to have more than one version of the same thing if not for anything else but comparison purposes. I'm sure we'll end up merging the two, at least in some respect(s). I'll make sure to stay in touch with you and discuss before anything is committed. > Anyway, it'll be better to wait for your code and learn from you. > Thank you. > -- > Kyunghwan Kim > [EMAIL PROTECTED] Thanks again for your interest. -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mbuf header bloat ?
On Thu, Jan 02, 2003 at 01:53:53PM -0500, Andrew Gallatin wrote: > I'm just tuning up my driver now to catch up to the "recent" interface > changes. While there, I went to add a ref count for my driver managed > M_EXT clusters. However, m_extadd() does not take a parameter for > assignment into mp->m_ext.ref_cnt Eg, I cannot call m_extadd() if I > want to use my own refcounter. > > Is there any chance this could be fixed? O/w, I'll have to > avoid calling m_extadd().. I dunno. I hate the whole story behind the reference counters in the mbuf code and I don't know what the correct approach here would be. A long long while back I think m_extadd (or its equivalent) did allow something like this. Then, we changed it so that counters would be allocated by the mbuf code 'transparently' (i.e., so that the Rest Of The World didn't have to worry about it). However, not long ago, I changed the way reference counters were allocated for mbuf clusters so that it would be faster. Counters for other objects are allocated with malloc(). The only 'correct' (half-assed) solution I can see is to allow m_extadd() to take a 'refcount' argument (again?) - perhaps leave a backwards-compatible m_extadd() and add a m_addext() or something - and only call malloc() for the counter if refcnt_provided == NULL. To be honest, I don't really like the idea but I don't see a better solution. Right now, ref counting for regular mbuf clusters works fine and is pretty damn fast, but I don't know how I could make it happen for other external buffer types other than the way I just described. > Thanks, > > Drew -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mbuf header bloat ?
On Thu, Jan 02, 2003 at 03:47:46PM -0500, Andrew Gallatin wrote: > > To be honest, I don't really like the idea but I don't see a better > > solution. Right now, ref counting for regular mbuf clusters works > > fine and is pretty damn fast, but I don't know how I could make it > > happen for other external buffer types other than the way I just > > described. > > There's a second can of worms too. We don't want the mbuf system > freeing externally maintained refcnt pointers. So we need a type > or flag to distinguish them. > > I've appended a minimal impact patch that I came up with. It just > adds a new type (EXT_EXTREF) and leaves the m_extadd() api/abi pretty > much unchanged. Callers that want to manage their own refcnt memory > call m_extadd() like this: > > mp->m_ext.ref_cnt = &entry->ref_count; > MEXTADD(mp, (void *)entry->jbuf->buf, GM_JLEN, > gm_freebsd_ether_jfree, (void *)entry->jbuf, > 0, EXT_EXTREF); > > > It seems to work just fine, and together with some patches from Alan > Cox for kmem_malloc(), allows me to make my network driver MPSAFE. > I'm still testing for other hidden Giant acquisitions or > GIANT_REQUIRED() assertions in rare codepaths, but its been up for 15 > minutes now, and that's 14m 59sec longer than usual ;) > > Would you be OK with this or something like it? > > Thanks, > > Drew [patch snipped] Yeah, this looks like the least-intrusive way to do it. I'm okay with the patch. I like the idea of using an EXT-type flag to mark the data buffer types using this method. Thanks. P.S.: Try not to use MEXTADD, if possible. Use m_extadd() instead, which is the procedure-equivalent version. MEXTADD is just provided for 'backwards-compatibility'. It used to be a large ugly macro. -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HOWTO: Basic-block profiling on -current.
On Mon, Jan 06, 2003 at 02:28:52PM +0100, Poul-Henning Kamp wrote: > > I have committed the bits needed to use GCC's basicblock profiling > on -current. > > Make sure to recompile the kernbb(8) program first. > > Here's an simple example how to profile a single file (vfs_bio.c): > > cd /sys/i386/conf > config YOURKERNEL > cd ../compile/YOURKERNEL > make depend && make all > rm vfs_bio.o > make vfs_bio.o DEBUG="--test-coverage --profile-arcs" > make all && make install > reboot > # run your test. > kernbb > cd /sys/i386/compile/YOURKERNEL > gcov vfs_bio.c > # examine vfs_bio.c.gcov > > If you want to profile multiple files, you just give them all the > same treatment as vfs_bio. > > It's perfectly possible to profile the entire kernel if you want to. Hey Poul-Henning! Thanks! > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > [EMAIL PROTECTED] | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
Trish, Thanks for the tests, it would be good to also get results with hyperthreading turned off. However, I need you to pass the -o option to NPtcp and get an actual dat file, so that you can generate the graphs using the gnuplot config file I asked you to download. Having the results outputted in the text file is not very meaningful. From just eyeballing though, I can see that the maximum throughput is much higher in the second set of results. I'd still like the dat files and/or the gnuplot generated pngs, especially when hyperthreading is turned off, too. Thanks again, Trish. Regards, Bosko On Fri, Jan 31, 2003 at 01:04:52PM -0500, Trish Lynch wrote: > So, at the request of bmilekic, I ran netpipe on a hyperthreading box (non > hyperthreading, I'll do when I can turn it off in BIOS next time I'm down > there) > > > > however, I got a hint to turn machdep.cpu_idle_hlt on. > > > Dmesg: (With Hyperthreading) > > CPU: Pentium 4 (1796.94-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 > > Features=0xbfebfbff GE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,> > real memory = 1073217536 (1023 MB) > avail memory = 1034719232 (986 MB) > > Programming 24 pins in IOAPIC #0 > IOAPIC #0 intpin 2 -> irq 0 > Programming 24 pins in IOAPIC #1 > Programming 24 pins in IOAPIC #2 > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > cpu0 (BSP): apic id: 0, version: 0x00050014, at 0xfee0 > cpu1 (AP): apic id: 6, version: 0x00050014, at 0xfee0 > cpu2 (AP): apic id: 1, version: 0x00050014, at 0xfee0 > cpu3 (AP): apic id: 7, version: 0x00050014, at 0xfee0 > io0 (APIC): apic id: 2, version: 0x00178020, at 0xfec0 > io1 (APIC): apic id: 3, version: 0x00178020, at 0xfec8 > io2 (APIC): apic id: 4, version: 0x00178020, at 0xfec80400 > > > I tested with machdep.cpu_idle_hlt=0 and machdep.cpu_idle_hlt=1 > > The results are here: > > > http://bsdunix.net/performance > > all information on what command line options I used is in there. > > the difference with it on is pretty substantial, might be worth noting in > tuning(7) > > -Trish > > -- > Trish Lynch [EMAIL PROTECTED] > Ecartis Core Team [EMAIL PROTECTED] > EFNet IRC Operator @ efnet.demon.co.uk AilleCat@EFNet > Key fingerprint = 781D 2B47 AA4B FC88 B919 0CD6 26B2 1D62 6FC1 FF16 > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
On Fri, Jan 31, 2003 at 11:08:38AM -0800, Matthew Dillon wrote: > > :AFAIK, full hyperthreading support, as it is, has been merged to > :-stable. It consists of a patch to recognize the virtual CPUs, so they > :will be dealt with like any SMP system, as long as HTT is enabled on the > :BIOS. > : > :-- > :Daniel C. Sobral (8-DCS) > :Gerencia de Operacoes > > Yah. Shoot, well this Sony VAIO desktop has a P4 with HTT set in > it, but it doesn't have an APIC, the BIOS is clueless, and there > is no mptable, so I guess I am S.O.L. in regards to using hyperthreading > on this box. > > -Matt > Matthew Dillon > <[EMAIL PROTECTED]> Why do you think that hlt-ing the CPU(s) when idle would actually improve performance in this case? My only suspicion is that perhaps this reduces scheduling on the auxiliary 'logical' (fake) CPUs, thereby indirectly reducing cache ping-ponging and abuse. I would imagine that both units sharing the same execution engine in the HTT-enabled model would be effectively 'hlt'-ed when one of the two threads executes an 'hlt' until the next timer tick. I guess we'll wait for the two other data sets from Trish: one with HTT off, and cpu_idle_hlt=0, and the other with HTT off, and cpu_idle_hlt=1, before figuring this out. -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
On Fri, Jan 31, 2003 at 11:48:17AM -0800, Peter Wemm wrote: > The cache and most of the execution hardware is shared. The execution > units can run something like 4 instructions per clock. If the "idle" > logical core is in a spinloop, then it is generating instructions for > execution, so you are dividing the execution resources between one context > that is doing real work, and the other context that is burning off the > "excess" resources. Overall, it is a huge loss. It is absolutely essential > that logical cpus be halted when they are not doing useful work. What bothers me is that we have systems like UMA and mb_alloc (and possibly others) which have per-CPU structures, i.e., per-CPU caches, and when HTT is enabled, even the logical CPUs get their own cache when, in fact, it would probably be better (and less cache polluting) if the "logical units" (states) shared the same per-CPU structures. Briefly back to the cpu_idle_hlt story: Would it be possible to, at runtime - besides for just getting cpuid which gives us the logical unit number - get the actual physical CPU number that we're executing on? e.g., in a 2 x 4 Xeon with HTT enabled, cpuid will range from 0 to 3, would it be possible to have an equivalent variable that will give us only the physical unit number (in this case, it would range from 0 to 1, as there are two physical execution units). That way, we can count how many times we issue 'hlt' for a thread running on physical unit number N, for example, and if we have 2 logical units per physical unit for instance, then when the count hits 1 no longer do the 'hlt' to not lose a tick? The counter would have to be re-set at the next tick everytime a logical unit comes out of hlt and schedules a process. You know what I mean? It sounds a little complicated and I'm not sure it would be worth the effort, but it would get us the best of both scenarios, i.e., halt the logical unit when another logical unit on the same core is executing Real Code, and not halt the logical unit if both logical units on the given execution engine are idle. In any case, even if the above is not worth it, I'd still like to know if it's possible to get the physical unit number, as opposed to the logical unit number, at runtime? [...] > Cheers, > -Peter > -- > Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > "All of this is for nothing if we don't go to the stars" - JMS/B5 -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
On Fri, Jan 31, 2003 at 11:52:53AM -0800, Matthew Dillon wrote: > Another solution would be to have a global mask of 'idle' cpus and send > an IPI to them when a new KSE is scheduled on a non-idle cpu that would > simply serve to wakeup the HLT. IPIs are nasty, but there are large > (power consumption) advantages to standardizing on the HLT methodology. Or, as I explained in my previous post, only HLT the [virtual] CPU if the other [virtual] CPU that is sharing the same execution & cache units is not HLT'd itself. If the other one is HLT'd, then not do the HLT. > -Matt > Matthew Dillon > <[EMAIL PROTECTED]> -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
On Sat, Feb 01, 2003 at 12:47:59PM -0800, Terry Lambert wrote: > Bosko Milekic wrote: > > On Fri, Jan 31, 2003 at 11:52:53AM -0800, Matthew Dillon wrote: > > > Another solution would be to have a global mask of 'idle' cpus and send > > > an IPI to them when a new KSE is scheduled on a non-idle cpu that would > > > simply serve to wakeup the HLT. IPIs are nasty, but there are large > > > (power consumption) advantages to standardizing on the HLT methodology. > > > > Or, as I explained in my previous post, only HLT the [virtual] CPU if > > the other [virtual] CPU that is sharing the same execution & cache > > units is not HLT'd itself. If the other one is HLT'd, then not do the > > HLT. > > Actually, why is that? Why would you not want to HLT all the > units that are not being used? Because, the comment explains, a halted CPU will not pick up a new thread off the run queue until the next timer tick. So if all your logical units are idled then you can afford to just loop checking whether something is runnable without interfering with the performance of other threads running on a different logical cpu sharing your execution unit (because the other logical units are idle anyway). That way, you don't have to necessarily wait for the next timer tick to check whether something is runnable, especially if it's made runnable before. The disadvantage is that you don't really economize on power consumption. The ideal situation would be to have as Matt (and the comment actually) says a cpu mask of idle cpus and generate an IPI to wake up CPUs sitting in HLT when something hits the runqueue, then you can just hlt all of them and rely on the IPI to wake you up, or the next timer tick, whichever comes first and you can really get the best of both worlds. > -- Terry -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
On Sat, Feb 01, 2003 at 01:28:45PM -0800, Terry Lambert wrote: > Bosko Milekic wrote: > > > > Or, as I explained in my previous post, only HLT the [virtual] CPU if > > > > the other [virtual] CPU that is sharing the same execution & cache > > > > units is not HLT'd itself. If the other one is HLT'd, then not do the > > > > HLT. > > > > > > Actually, why is that? Why would you not want to HLT all the > > > units that are not being used? > > > > Because, the comment explains, a halted CPU will not pick up a new > > thread off the run queue until the next timer tick. So if all your > > logical units are idled then you can afford to just loop checking > > whether something is runnable without interfering with the performance > > of other threads running on a different logical cpu sharing your > > execution unit (because the other logical units are idle anyway). > > That way, you don't have to necessarily wait for the next timer tick > > to check whether something is runnable, especially if it's made > > runnable before. The disadvantage is that you don't really economize > > on power consumption. > > There's an assumption in there of a shared scheduler queue, and a > lack of CPU affinity (or negaffinity, for multiple threads in a > single process), isn't there? Well, euh, yeah, the runqueue was global the last time I checked (Jeff R.'s new stuff aside). Maybe I'm just out of it, I don't know. [... other probably meaningful stuff that makes the assumption that we do have per-CPU queues protected by their own locks ...] -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: TCP connections timing out "real fast"
On Sat, Feb 22, 2003 at 10:57:05AM -0500, Robert Watson wrote: > > Don't yet have any quantitative evidence that this is the case, but I feel > like TCP sessions have been timing out on me a lot faster than they used > to. For example, yesterday a machine got unplugged from the network for > about 15 seconds: in that time, the SSH sessions to the machine timed out > and disconnected. This morning, a machine generated a lot of output to > the serial console keeping it substantially busy for about 20 seconds; in > that time, the SSH session to it timed out. I'm going to see if I can't > generate some tcpdump traces later today to confirm my suspicions, but was > wondering if anyone else (annecdotally or not) has seen similar things? > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > [EMAIL PROTECTED] Network Associates Laboratories I have (annecdotally) but I believe I'm seeing it on -STABLE too... it's tough to tell... how recent are your -CURRENT machines, though, and is it something that you think just started happening or has it been happening for a while now? FWIW, I can't say for sure that this is related to TCP connection timeouts. -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT kernel freezing or rebooting
Do you have the debugging options enabled? makeoptions DEBUG=-g options DDB at the VERY least. Try also compiling with INVARIANTS and INVARIANT_SUPPORT... On Sat, Feb 22, 2003 at 05:10:15PM +, Daniel Flickinger wrote: > kernels built from cvsup date tags: > > 1200 GMT 21 Feb 2003 > 1200 GMT 22 Feb 2003 > > either hang hard or freeze and fall out to reboot. No > error messages logged. Both were full make world, etc. > followed by mergemaster. apache 1.3.27, X, Mozilla, etc > running. > > Previous build from cvsup date tag 1200 GMT 14 Feb 2003 ran > the week with zero problems. Will try again tomorrow morning > (1200 GMT) if there are "interesting" kernel commits. > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mbuf cache
On Wed, Mar 05, 2003 at 01:42:05AM +0200, Petri Helenius wrote:
> >
> > This does look odd... maybe there's a leak somewhere... does "in use"
> > go back down to a much lower number eventually? What kind of test are
> > you running? "in pool" means that that's the number in the cache
> > while "in use" means that that's the number out of the cache
> > currently being used by the system; but if you're telling me that
> > there's no way usage could be that high while you ran the netstat,
> > either there's a serious leak somewhere or I got the stats wrong
> > (anyone else notice irregular stats?)
> >
> I think I figured this, the "em" driver is allocating mbuf for each receive
> descriptor regardless if it´s needed or not. Does this cause a performance
> issue if there is 8000 mbufs in use and we get 100k-150k frees and
> allocates a second (for every packet?)
>
> (I have the em driver configured for 4096 receive descriptors)
Yeah, it kinda sucks but I'm not sure how it works... when are the
mbufs freed? If they're all freed in a continous for loop that kinda
sucks.
> > Another thing I find odd about those stats is that you've set the high
> > watermark to 8192, which means that in the next free, you should be
> > moving buckets to the general cache... see if that's really
> > happening... The low watermark doesn't affect anything right now.
>
> Nothing seems to be moving to the GEN pool.
Lower the high watermark to like 512... wait for the next free... if
it's still not moving, but you see that the per-cpu caches are being
used ("in use" is changing), please let me know ASAP.
> > Can you give me more details on the exact type of test you're running?
> > Let's move this to -current instead of -current and -net please (feel
> > free to trim the one you want), getting 3 copies of the same
> > message all the time is kinda annoying. :-(
> >
> I´m running a snort-like application with the interface getting receive only
> packets. It can either connect to a netgraph node or use bpf, both seem to have
> similar performance (most CPU is used elsewhere) as the email I sent previously
> had listed.
>
> Pete
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: mbuf cache
On Wed, Mar 05, 2003 at 01:12:55AM +0200, Petri Helenius wrote: > > > Any comments on the high cpu consumption of mb_free? Or any other places > > > where I should look to improve performance? > > > > What do you mean "high cpu consumption?" The common case of mb_free() > > is this: > > According to profiling mb_free takes 18.9% of all time consumed in kernel and is > almost double to next cpu consuming function. Since I´m looking how to optimize > the system, it´s usually a good idea to start looking where most CPU is spent. > > For example, I´m wondering if mbufs get unneccessarily freed and allocated or thrown > around different buckets because of the tunables are wrong. I´m not saying that > there must be something wrong with the code itself. > > For example what does "in use" mean below: There is no way there is enough > traffic on the system to allocate 7075 mbufs when this netstat -m was taken. > > mbuf usage: > GEN cache: 0/0 (in use/in pool) > CPU #0 cache: 7075/8896 (in use/in pool) > CPU #1 cache: 1119/4864 (in use/in pool) > Total: 8194/13760 (in use/in pool) > Mbuf cache high watermark: 8192 > Mbuf cache low watermark: 128 > > > Pete This does look odd... maybe there's a leak somewhere... does "in use" go back down to a much lower number eventually? What kind of test are you running? "in pool" means that that's the number in the cache while "in use" means that that's the number out of the cache currently being used by the system; but if you're telling me that there's no way usage could be that high while you ran the netstat, either there's a serious leak somewhere or I got the stats wrong (anyone else notice irregular stats?) Another thing I find odd about those stats is that you've set the high watermark to 8192, which means that in the next free, you should be moving buckets to the general cache... see if that's really happening... The low watermark doesn't affect anything right now. Can you give me more details on the exact type of test you're running? Let's move this to -current instead of -current and -net please (feel free to trim the one you want), getting 3 copies of the same message all the time is kinda annoying. :-( -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mbuf cache
On Tue, Mar 04, 2003 at 11:34:11PM +0200, Petri Helenius wrote: > > I did some profiling on -CURRENT from a few days back, and I think I haven´t > figured the new tunables out or the code is not doing what it´s supposed to > or I´m asking more than it is supposed to do but it seems that mb_free > is being quite wasteful... > > Any pointers to how the new high/low watermark tunables should be used? > > Is it normal that after almost all traffic has been stopped there is still 8k+ > mbufs in "cache"? > > Pete Yes, it's normal. The commit log clearly states that the new watermarks do nothing for now. I have a patch that changes that but I haven't committed it yet because I left for vacation last Sunday and I only returned early this Monday. Since then, I've been too busy to clean up and commit it. In about a week or so you should notice a difference. -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mbuf cache
On Wed, Mar 05, 2003 at 12:24:27AM +0200, Petri Helenius wrote:
> >
> > Yes, it's normal. The commit log clearly states that the new
> > watermarks do nothing for now. I have a patch that changes that but I
> > haven't committed it yet because I left for vacation last Sunday and I
> > only returned early this Monday. Since then, I've been too busy to
> > clean up and commit it. In about a week or so you should notice a
> > difference.
> >
> Any comments on the high cpu consumption of mb_free? Or any other places
> where I should look to improve performance?
What do you mean "high cpu consumption?" The common case of mb_free()
is this:
bucket = mb_list->ml_btable[MB_BUCKET_INDX(m, mb_list)];
owner = bucket->mb_owner & ~MB_BUCKET_FREE;
switch (owner) {
...
default:
cnt_lst = MB_GET_PCPU_LIST_NUM(mb_list, owner);
MB_PUT_OBJECT(m, bucket, cnt_lst);
MB_MBTYPES_DEC(cnt_lst, type, 1);
if (bucket->mb_owner & MB_BUCKET_FREE) {
SLIST_INSERT_HEAD(&(cnt_lst->mb_cont.mc_bhead),
bucket,
mb_blist);
bucket->mb_owner = cnt_lst->mb_cont.mc_numowner;
}
}
That's the common path, modulo a couple checks on whether or not the
container being freed to needs to be moved or whether we're in a
starvation situation. The only thing to be done, possibly, is make
the routine smaller by moving those couple of actions to seperate
routines, but I'm not clear that this is very useful, given that
mb_free()'s usage is restricted to only inside subr_mbuf.c
> Pete
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: mbuf cache
On Wed, Mar 05, 2003 at 10:07:35AM +0200, Petri Helenius wrote: > I think there is nothing really special about the driver there? The mbufs > are allocated in the driver and then freed when other parts in the kernel > are done with the packet? The issue I´m having is that mb_free takes > almost four times the cycles than mb_alloc for each call which does > not seem to be right? I shouldn´t be having lock contention in mb_alloc > because the whole thing is still under Giant, right? There's probably a tightloop of frees going on somewhere. It's tough for me to analyze this as I cannot reproduce it. Have you tried running your tests over loopback to see if the same thing happens? If so, and it does, can you please explain how to exactly replicate the test? -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mbuf cache
On Fri, Mar 07, 2003 at 05:00:42PM +0200, Petri Helenius wrote: > > There's probably a tightloop of frees going on somewhere. It's tough > > for me to analyze this as I cannot reproduce it. Have you tried > > running your tests over loopback to see if the same thing happens? > > What is the definition of "tightloop"? The received packet mbufs are freed > when the packets get processed/discarded which happens once for > a packet. The received packet rate is 5-15 packets per second. > > > > If so, and it does, can you please explain how to exactly replicate > > the test? > > Mirror a port with ~300-800Mbps of IP traffic to an em port. Just enable > promisc and monitor so it drops the packets after interrupt processing. > The overhead beyond that is neglible compared to mb_free. > > Pete Ok I have a patch that makes mb_free() a lot smaller by moving out everything not in the common case to seperate functions. I'm going to wait until I get home to give it a test run before I send it to you. At least this way you'll be able to profile again and tell me whether it's really the common case of mb_free() that's being expensive or if you're often hitting non-common-cases (in which case the auxilary routines should register the higher CPU usage). -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP problem with uma_zalloc
On Sat, Jul 19, 2003 at 08:31:26PM +0200, Lara & Harti Brandt wrote: [...] > Well the problem is, that nothing is starved. I have an idle machine and > a zone that I have limited to 60 or so items. When allocating the 2nd > item I get block on the zone limit. Usually I get unblocked whenever I > free an item. This will however not happen, because I have neither > reached the limit nor is there memory pressure in the system to which I > could react. I simply may be blocked forever. UMA_ZFLAG_FULL is set on the zone prior to the msleep(). This means that the next free will result in your wakeup, as the next free will be sent to the zone internally, and not the pcpu cache. > That makes the limit feature for zones rather useless, because I cannot > predict how many of the items I can really allocate (this depends on the > number of processors, the page size and the configuration of UMA itself). > > Perhaps we could make the behaviour dependent on the maximum number of > items. When it is rather low (a couple of pages worth) and I would block > on the zone limit and I have free items in another CPU's cache then > drain one of the caches. > > Or I could simply remove the limits. > > > harti > > > -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] TECHNOkRATIS Consulting Services * http://www.technokratis.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SMP problem with uma_zalloc
On Mon, Jul 21, 2003 at 09:03:00AM +0200, Harti Brandt wrote: > On Sat, 19 Jul 2003, Bosko Milekic wrote: > > BM> > BM>On Sat, Jul 19, 2003 at 08:31:26PM +0200, Lara & Harti Brandt wrote: > BM>[...] > BM>> Well the problem is, that nothing is starved. I have an idle machine and > BM>> a zone that I have limited to 60 or so items. When allocating the 2nd > BM>> item I get block on the zone limit. Usually I get unblocked whenever I > BM>> free an item. This will however not happen, because I have neither > BM>> reached the limit nor is there memory pressure in the system to which I > BM>> could react. I simply may be blocked forever. > BM> > BM> UMA_ZFLAG_FULL is set on the zone prior to the msleep(). This means > BM> that the next free will result in your wakeup, as the next free will > BM> be sent to the zone internally, and not the pcpu cache. > > But there is no free to come. To explain where we have the problem: > > the HARP ATM code uses a zone in the IP code to allocate control blocks > for VCCs. The zone is limited to 100 items which evaluates to 1 page. > When I start an interface, first the signalling vcc=5 is opened. This > allocates one item from the zone, all the other items go into the CPU > cache. Next I start ILMI. ILMI tries to open its vcc=16. While this works > on UP machines (the zone allocator will find a free item in the CPU > cache), on my 2-proc machine half of the time ILMI gets blocked on the > zonelimit. And it blocks there forever, because, of course nobody is going > to free the one and only allocated item. On a four processor machine the > blocking probability will be 75%. > > So in order to be able to get out N items from a zone (given that there is > no shortage of memory) one has to set the limit to N + nproc * > items_per_allocation, which one cannot do because he doesn't know > items_per_allocation. It sounds to me like your example is really not the general-case one. Basically, you're using a zone capped off at 1 page. Currently in UMA, this is the size of the slab. So, basically, you have this whole zone (with all associated overhead) so as to serve a maximum of only one slab. This defeats most of the assumptions made when the zone is created with PCPU caches. The zone maximum exists to prevent more than the specified amount of resources to be allocated toward the given zone; I don't think that the intention was "to ensure that if the maximum items aren't allocated, there will always be one available," despite the fact that that is the effective behavior on UP. The solution to your really small zone problem is to either make the zone bigger, or to hack at UMA to export the UMA_ZONE_INTERNAL API properly so that you can skip the pcpu caches for all allocations and go straight to the zone. I'd suggest that you make the zone bigger, unless there's a Really Good reason not to. In mb_alloc (for mbufs) I had implemented something that in this sort of scenario would dip into the other caches and transfer over what I called a "bucket" to the current cpu cache. Although in this scenario, it seems like that sort of solution would do what you want, some more thought into its behavior reveals that in fact it pessimizes the situation. To give you a better idea, let's consider what happens in this specific scenario, where a "bucket" would be all of a page. The allocator would make an attempt to allocate from its pcpu cache but would find it empty, so it would then attempt to steal a bucket from the second cpu's cache. There, it would find the bucket, move it to its cpu's cache, and grab an item from it. However, a thread on the second cpu may then attempt to grab an item, and the bucket will just ping-pong from pcpu cache to pcpu cache; the problem that the allocator was trying to solve for such really small zones was in fact still there - because of the general assumptions made in the design with respect to the size of most zones that it dealt with - only instead of failing the allocation, it was pessimizing it. > harti Regards, -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] TECHNOkRATIS Consulting Services * http://www.technokratis.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SMP problem with uma_zalloc
On Mon, Jul 21, 2003 at 03:47:54PM +0200, Harti Brandt wrote: > On Mon, 21 Jul 2003, Bosko Milekic wrote: [...] > BM> It sounds to me like your example is really not the general-case one. > BM> Basically, you're using a zone capped off at 1 page. Currently in > BM> UMA, this is the size of the slab. So, basically, you have this whole > BM> zone (with all associated overhead) so as to serve a maximum of only > BM> one slab. This defeats most of the assumptions made when the zone is > BM> created with PCPU caches. The zone maximum exists to prevent more > BM> than the specified amount of resources to be allocated toward the > BM> given zone; I don't think that the intention was "to ensure that if > BM> the maximum items aren't allocated, there will always be one > BM> available," despite the fact that that is the effective behavior on > BM> UP. > BM> > BM> The solution to your really small zone problem is to either make the > BM> zone bigger, or to hack at UMA to export the UMA_ZONE_INTERNAL API > BM> properly so that you can skip the pcpu caches for all allocations and > BM> go straight to the zone. I'd suggest that you make the zone bigger, > BM> unless there's a Really Good reason not to. > > I think I take two paths: for stuffs like VCC where there may be a large > number I will just remove the limit. The limits were a leftover when the > ATM code had its own memory pool code. For stuff where there is a high > probability that only a handful (usually 1 or 2) of them will be allocated > (network interfaces) I will try to make it to use malloc(). A. Given the explanation, the small size of the limits makes a lot more sense now. Previously, the limit probably enforced the actual number of cached (pre-allocated) items in the pool. So, it was more than just a "limit," it was a cache size parameter. That is probably why its size was kept relatively small. In the zone setting, the limit can easily be made larger or removed altogether (if there is no danger of that structure consuming all of kernel memory). > How do you think about adding a paragraph for uma_zone_set_max to the man > page?: > > An upper limit of items in the zone can be specified with a call to > uma_zone_set_max. This limits the total number of items which includes: > allocated items, free items and free items in the per-cpu caches. On > systems with more than one CPU it may not be possible to allocate the > specified number of items, because all of the remaining free items may > be in the caches of the other CPUs when the limit is hit. Given that it has obviously led to confusion, this sort of change to the man page would be encouraging. Perhaps you would also ammend to it the purpose of uma_zone_set_max(), as it currently stands: "The purpose of uma_zone_set_max() is to limit the maximum amount of memory that the system can dedicate toward the zone specified by the 'zone' argument." Would you like to commit the change? > Regards, > harti > > -- > harti brandt, > http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private > [EMAIL PROTECTED], [EMAIL PROTECTED] Cheers, -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] TECHNOkRATIS Consulting Services * http://www.technokratis.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.1-R kernel panic
On Mon, Jul 21, 2003 at 03:01:24PM -0600, Stephane Raimbault wrote: > I'm running FreeBSD 5.1-RELEASE with the SMP kernel and ran across the > following kernel panic. > > panic: kmem_malloc(4096): kmem_map too small: 275251200 total allocated > > I'm trying to figure out what could be causing this, what kind of > information that I could provide to this group (or other group?) to see if > this is a bug in FreeBSD that needs to be looked into? > > The box is basically a busy apache server... the kernel panic seemed to > occur during the periodic daily was running. It seems to complete the > 440.status-mailq part of periodic daily , but doesn't do > 450.status-security. > > This isn't the first time the box has crashed at aprox. 3:01 am (when daily > runs)... however this is the first time I've seend the kernel panic message > quoted above in the /var/run/dmesg.boot file. > > I have attached the entire /var/run/dmesg.boot file to this message. > > What can I do to assist in identifiying and resolving this problem? > > Thanks, > Stephane Raimbault. Just a few things: 1) Do you have PAE enabled? 2) Can you upgrade to src/sys/kern/kern_malloc.c version 1.126 or upgrade to HEAD? If you have PAE enabled and (2) does not fix your problem, then please post a stack trace that resulted in the panic. You also have a lot of RAM so if (2) above does not fix your problem, try setting the kern.vm.kmem.size bootable to approximately 350,000,000 or so (even 400,000,000 is OK as long as NMBCLUSTERS is not too-too high). -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] TECHNOkRATIS Consulting Services * http://www.technokratis.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.1-R kernel panic
On Mon, Jul 21, 2003 at 06:24:07PM -0400, Mik Firestone wrote: > For what it is worth, I am having the exact same problem. I cvsup'd and > builtworld on Sunday, July 20, and my machine has been crashing about every > half-hour since. It starts slowing down, the load average begins to > climb until it eventually grinds to a halt. If I wait long enough, I > will see the same panic Stephane saw. > > Doing a ps -auxw shows that usb0 is using the vast majority of the CPU > time before the grinding halt. I have tried leaving the machine in > multi-user and sigle-user mode with the same results. I have attempted > to compile a new kernel that does not have the USB stuff compiled in, > but my machine won't stay running long enough. > > I do have the debugger compiled in, but I do not know enough of what I > am doing to provide reasonable information to the list. If somebody > can tell me the commands to run in the debugger, I will let my machine > panic again and grab that data. > > Mik Does reverting to pre-July 20 get rid of your problem? Note that the originator of the first Email mentionned that he is running what appeared to be stock 5.1-RELEASE, which may or may not be related to what you're seeing. If reverting to pre-July 20 gets rid of your problem, perhaps we can figure out what commit triggered this behavior for you. Also, do you have PAE enabled? -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] TECHNOkRATIS Consulting Services * http://www.technokratis.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.1-R kernel panic
On Wed, Jul 23, 2003 at 09:08:18AM -0600, Stephane Raimbault wrote: ... > I was looking at uping the kern.vm.kmem.size as suggested to do as well, but > I cannot find that value in sysctl -a, so I'm not sure where to set that > specifically. I have found the value for nmbclusters and it is set to the > following: It's a boot-time tunable. Look at /boot/defaults/loader.conf and copy over the relevant line with a setting such as, for example, 35 into your /boot/loader.conf. Increasing nmbclusters will not help you here. In fact, if you're not running out, I would recommend keeping the value reasonable (e.g., 8192). > kern.ipc.nmbclusters: 25600 > > I guess short of setting the kern.vm.kmem.size I need to get someone here > the stack trace leading to the crash... is there a URL that someone can > point me to for me to set the box up for this? I'll dig around in the > developers handbook, I seem to remember seeing something about it in there. > > Thanks, > Stephane. ... -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] TECHNOkRATIS Consulting Services * http://www.technokratis.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.1-R kernel panic
On Wed, Jul 23, 2003 at 09:24:24AM -0600, Stephane Raimbault wrote: > Thanks Bosko, > > I've changed my /boot/loader.conf to reflect the kern.vm.kmem.size option. > > kern.vm.kmem.size="35" > > As far as changing the nmbclusters, I'm not sure how many I use now. Do you > know where I could get some values as what the total vs. how much is being > used for the above values? I'll setup some graphs to monitor those values > for me and get an idea of how much the system is using and when if I can. 'netstat -m' You can access the relevant sysctls directly; take a look at the way netstat does it in src/usr.bin/netstat/mbuf.c > Also, I took a quick look at the developers handbook and couldn't find just > yet what I needed to change to the kernel to provide a stack trace... do you > know what options I should be adding to my kernel? Also, should I try not > to use an SMP kernel and just run GENERIC to see if continues to have the > problem? I can probably run on one CPU for a few days, especially over the > weekend. At the very least, you need "options DDB". This will drop you into the debugger on a kernel panic, at which point you can just issue 'tr' to get a stack trace. Be careful, if you only have remote access to the machine, this is generally not a good idea. > Thanks, > Stephane. -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] TECHNOkRATIS Consulting Services * http://www.technokratis.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.1-R kernel panic
On Wed, Jul 23, 2003 at 09:56:32AM -0600, Stephane Raimbault wrote: > Hi Bosko, > > Looking at netstat -m, the value I'd probably be interested in is the > following: > > 3% of cluster map consumed > > knowing that the Maximum possible is 25600 I can deduce that ~768 are being > used? Is that correct. I'm not much of a programmer, but I did recognize > the printf(); statements from a C class I didn't do well in half a decade > ago... as you can tell, I'm not much of a programmer :). If it's not the 3% > I should be paying attention too... then let me know :) Look at the "in pool" values for all the pcpu and GEN caches and add them up. Do this for clusters (since there are fewer). Compare to the "Maximum Possible" value. With a machine that goes into spike-load periods, you may want to have the Maximum Possible stay about 4-6 times what you have as your average "in pool" value (remember to sum the "in pool" values for the pcpu and GEN caches). The 3% is not what you think it is. It's the percentage of the allocated wired-down memory that is NOT in any of the caches but is allocated and circulating in the system. If you have a high number of cached items but the percentage is relatively low for most of the time, it's a sign that you were probably in a heavy-usage scenario some time ago, but that your current usage is relatively low. > As for using the option DDB in my kernel, I do have one question. I do have > remote console access that I use to go into single user mode on the box > remotely. I'm suspecting I could use the debugger mode over the > comconsole... I just want to make sure there is some kind of reboot command > from the debugger so that I can tell the box to reboot once I've captured > the stack trace? If so, I'll enable the DDB tonight and get you the info as > soon as I can. Yes, you can do DDB over serial console. Take a look at the handbook for more information on using DDB. If you have the space in /var and enough swap, you may want to try getting a crashdump so that you can reboot and use GDB to debug. Again, take a look at the handbook. > thanks again, > Stephane. -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] TECHNOkRATIS Consulting Services * http://www.technokratis.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
