Re: Recommended kernel config for a dell 8450, 8 cpu, 8GB of ram.
Mark Sergeant wrote: Just seeking some general information. I've got a couple of dell 8 cpu boxes here running FreeBSD 5.1-RELEASE and am interested in peoples thoughts on the best kernel configs for this type of machine. I'm interested in the best way of making use of 8 cpu's and also seeing the whole 8GB of RAM. For more than 4G of physical RAM, your only option is to enable the PAE support. In terms of other configuration options, it really depends on your intended use. In general, the PAE support doesn't allow the address space of the combined user and kernel to exceed 4G; what it does is let you have more processes resident instead of being swapped out. You also can't really increase your kernel memory usage over the KVA size limit, in any case, and unless you increase the KVA from 2G to 3G (simultaneously decreasing the UVA available to user processses), you will likely run into the kmem_map too small, even if you set the hard limits up. Doing this will reduce the maximum size of user processes, which may not be what you want, given that the reason you have more than 4G in the box in the first place is that you are expecting to be able to make use of it. 8-). One thing that would be helpful (and last time I looked, it still wasn't easily supportable) would be to change the KVA/UVA ratio, and deuinify the kernel and process address space. Doing this would have implications for the pipe code and the loopback device, but it would also let you replace uiomove() to do map flipping to copy data in and out, and basically that would give you the full 4G UVA and full 4G KVA, instead of being limited to UVA+KVA=4G. This is basically what the Alpha, SPARC, and PPC platforms do. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
psmintr: discard a byte (1) [moused issues]
:Can you add :options PSM_DEBUG=2 :to your kernel config and recompile, then do a verbose boot (boot -v) and :send me the output? Jul 29 15:00:15 hostname kernel: Copyright (c) 1992-2003 The FreeBSD Project. Jul 29 15:00:15 hostname kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jul 29 15:00:15 hostname kernel: The Regents of the University of California. All rights reserved. Jul 29 15:00:15 hostname kernel: FreeBSD 5.1-CURRENT #1: Tue Jul 29 14:23:55 CST 2003 Jul 29 15:00:15 hostname kernel: [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Jul 29 15:00:15 hostname kernel: Preloaded elf kernel /boot/kernel/kernel at 0xc077. Jul 29 15:00:15 hostname kernel: Preloaded elf module /boot/kernel/vesa.ko at 0xc07701f4. Jul 29 15:00:15 hostname kernel: Preloaded elf module /boot/kernel/snd_ich.ko at 0xc07702a0. Jul 29 15:00:15 hostname kernel: Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc077034c. Jul 29 15:00:15 hostname kernel: Preloaded elf module /boot/kernel/acpi.ko at 0xc07703f8. Jul 29 15:00:15 hostname kernel: Timecounter i8254 frequency 1193182 Hz Jul 29 15:00:15 hostname kernel: Timecounter TSC frequency 1004833815 Hz Jul 29 15:00:15 hostname kernel: CPU: Intel Pentium III (1004.83-MHz 686-class CPU) Jul 29 15:00:15 hostname kernel: Origin = GenuineIntel Id = 0x686 Stepping = 6 Jul 29 15:00:15 hostname kernel: Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE Jul 29 15:00:15 hostname kernel: real memory = 536805376 (511 MB) Jul 29 15:00:15 hostname kernel: avail memory = 513347584 (489 MB) Jul 29 15:00:15 hostname kernel: Pentium Pro MTRR support enabled Jul 29 15:00:15 hostname kernel: VESA: v3.0, 32768k memory, flags:0x1, mode table:0xc00c52bd (c00052bd) Jul 29 15:00:15 hostname kernel: VESA: Matrox Graphics Inc. Jul 29 15:00:15 hostname kernel: npx0: math processor on motherboard Jul 29 15:00:15 hostname kernel: npx0: INT 16 interface Jul 29 15:00:15 hostname kernel: acpi0: IntelR MSI ACPI on motherboard Jul 29 15:00:15 hostname kernel: pcibios: BIOS version 2.10 Jul 29 15:00:15 hostname kernel: Using $PIR table, 10 entries at 0xc00fdeb0 Jul 29 15:00:15 hostname kernel: acpi0: power button is handled as a fixed feature programming model. Jul 29 15:00:15 hostname kernel: Timecounter ACPI-fast frequency 3579545 Hz Jul 29 15:00:15 hostname kernel: acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 Jul 29 15:00:15 hostname kernel: acpi_cpu0: CPU on acpi0 Jul 29 15:00:15 hostname kernel: acpi_tz0: thermal zone on acpi0 Jul 29 15:00:15 hostname kernel: acpi_button0: Power Button on acpi0 Jul 29 15:00:15 hostname kernel: acpi_button1: Sleep Button on acpi0 Jul 29 15:00:15 hostname kernel: pcib0: ACPI Host-PCI bridge port 0x4000-0x40f7,0xcf8-0xcff on acpi0 Jul 29 15:00:15 hostname kernel: pci0: ACPI PCI bus on pcib0 Jul 29 15:00:15 hostname kernel: pcib0: slot 31 INTD is routed to irq 10 Jul 29 15:00:15 hostname kernel: pcib0: slot 31 INTC is routed to irq 11 Jul 29 15:00:15 hostname kernel: pcib0: slot 31 INTB is routed to irq 11 Jul 29 15:00:15 hostname kernel: agp0: Intel 82815 (i815 GMCH) host to PCI bridge mem 0xd000-0xd3ff at device 0.0 on pci0 Jul 29 15:00:15 hostname kernel: pcib1: PCI-PCI bridge at device 1.0 on pci0 Jul 29 15:00:15 hostname kernel: pci1: PCI bus on pcib1 Jul 29 15:00:15 hostname kernel: pcib0: slot 1 INTA is routed to irq 11 Jul 29 15:00:15 hostname kernel: pcib1: slot 0 INTA is routed to irq 11 Jul 29 15:00:15 hostname kernel: pci1: display, VGA at device 0.0 (no driver attached) Jul 29 15:00:15 hostname kernel: pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 Jul 29 15:00:15 hostname kernel: pci2: ACPI PCI bus on pcib2 Jul 29 15:00:15 hostname kernel: pcib2: slot 1 INTA is routed to irq 11 Jul 29 15:00:15 hostname kernel: pcib2: slot 3 INTA is routed to irq 10 Jul 29 15:00:15 hostname kernel: bt0: Buslogic Multi-Master SCSI Host Adapter port 0xc000-0xc003 irq 11 at device 1.0 on pci2 Jul 29 15:00:15 hostname kernel: bt0: BT-946C FW Rev. 4.25J Narrow SCSI Host Adapter, SCSI ID 7, 100 CCBs Jul 29 15:00:15 hostname kernel: xl0: 3Com 3c905C-TX Fast Etherlink XL port 0xc400-0xc47f mem 0xda00-0xda7f irq 10 at device 3.0 on pci2 Jul 29 15:00:15 hostname kernel: xl0: Ethernet address: 00:01:03:45:32:a0 Jul 29 15:00:15 hostname kernel: miibus0: MII bus on xl0 Jul 29 15:00:15 hostname kernel: ukphy0: Generic IEEE 802.3u media interface on miibus0 Jul 29 15:00:15 hostname kernel: ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Jul 29 15:00:15 hostname kernel: isab0: PCI-ISA bridge at device 31.0 on pci0 Jul 29 15:00:15 hostname kernel: isa0: ISA bus on isab0 Jul 29 15:00:15 hostname kernel: atapci0: Intel ICH2 UDMA100 controller port 0xf000-0xf00f at device 31.1 on pci0 Jul 29 15:00:15 hostname kernel: ata0: at 0x1f0 irq 14 on atapci0 Jul 29 15:00:15 hostname kernel: ata1: at 0x170 irq 15 on
Re: dereferencing type-punned pointer will break strict-aliasingrules
On Mon, 28 Jul 2003, Thomas Moestl wrote:
On Mon, 2003/07/28 at 09:30:08 +0900, Jun Kuriyama wrote:
Is this caused by -oS option?
- in making BOOTMFS in make release
cc -c -Os -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions
-std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev
-I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter
-I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL
-include opt_global.h -fno-common -finline-limit=15000 -mno-align-long-strings
-mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/geom/geom_dev.c
/usr/src/sys/geom/geom_dev.c: In function `g_dev_open':
/usr/src/sys/geom/geom_dev.c:198: warning: dereferencing type-punned pointer will
break strict-aliasing rules
[...]
Yes, by implying -fstrict-aliasing, so using -fno-strict-aliasing is a
workaround.
gcc.info claims that -fstrict-aliasing is implied by -Wall, but this is
apparently wrong -- adding -fstrict-aliasing to our standard warning flags
gives the same warnings. -Os gives it since -Os is more like -O2 than -O,
and gcc.info's claim that -fstrict-aliasing is implied by -O2 is apparently
not wrong. Related bug: our warning flags are missing other new gcc warnings.
The problem is caused by the i386 PCPU_GET/PCPU_SET
implementation:
#define __PCPU_GET(name) ({ \
__pcpu_type(name) __result; \
\
[...]
} else if (sizeof(__result) == 4) { \
u_int __i; \
__asm __volatile(movl %%fs:%1,%0 \
: =r (__i)\
: m (*(u_int *)(__pcpu_offset(name; \
__result = *(__pcpu_type(name) *)__i; \
[...]
In this case, the PCPU_GET is used to retrieve curthread, causing
sizeof(__result) to be 4, so the cast at the end of the code snippet
is from a u_int * to struct thread *, and __i is accessed through the
casted pointer, which violates the C99 aliasing rules.
An alternative is to type-pun via a union, which is also a bit ugly,
but explicitly allowed by C99. Patch attached (but only superficially
tested).
Uh, this macro is hideous enough without making it larger. I found that
using __builtin_memcpy() avoids the warning at little or no cost in
object code size (the memcpy gets optimized away in almost the same way
as the assignment). Then I tried to improve the macro. I didn't quite
succeed -- the smller versions gave slightly larger object code for
5-20 out of 300 object files that depend on pcpu.h.
Annotated version:
% Index: pcpu.h
% ===
% RCS file: /home/ncvs/src/sys/i386/include/pcpu.h,v
% retrieving revision 1.35
% diff -u -2 -r1.35 pcpu.h
% --- pcpu.h1 Oct 2002 14:01:58 - 1.35
% +++ pcpu.h28 Jul 2003 14:02:30 -
% @@ -78,5 +80,5 @@
% * Evaluates to the address of the per-cpu variable name.
% */
% -#define __PCPU_PTR(name) ({ \
% +#define __PCPU_PTR(name) __extension__ ({ \
Unrelated change. This prevents warnings when compiled with certain
strict warning flags (-pedantic?).
% __pcpu_type(name) *__p; \
% \
% @@ -96,21 +98,21 @@
% \
% if (sizeof(__result) == 1) {\
% - u_char __b; \
% - __asm __volatile(movb %%fs:%1,%0 \
% - : =r (__b)\
% - : m (*(u_char *)(__pcpu_offset(name; \
% - __result = *(__pcpu_type(name) *)__b; \
% + __pcpu_type(name) __res;\
The temporary variable with a basic type is to avoid gcc getting confused
doing reloads in dead code. E.g., if __pcpu_type(name) is struct timeval,
then the type can't be loaded into a byte register, and gcc would die
trying since it apparently tries to load things in dead code, especially
in asms. However, this problem doesn't seem to affect __PCPU_GET().
There is no problem loading the source operand since only its address
can really be loaded, and no problem loading the target operand since the
asm does it. There might be a problem unloading the
Re: LOR with filedesc structure and Giant
Robert Watson wrote: On Sun, 27 Jul 2003, Kris Kennaway wrote: After upgrading last night, one of the package machines found this: I've bumped into some similar problems -- it's a property of how we current lock select(). We hold the file descriptor lock for the duration of polling each object being selected, and if any of those objects has to grab a lock for any reason, it has to implicitly fall after the file descriptor lock. I actually run into this in some of our MAC code, because I need to grab a vnode lock to authorize polling the vnode using VOP_POLL(), and since the vnode lock is a sleep lock, this generates a WITNESS warning. Unfortunately, it's not immediately clear what a better locking scheme would look like without going overboard on the fine-grained side. We probably need to grab Giant before entering the select code since it's highly likely something in there will require Giant -- it reaches down into VFS, the device stuff, socket code, tc. This is basically an instance of the race I warned against being an impending danger to FreeBSD last week, now that we have the possibility of multiple application threads in the kernel simutaneously. The easiest fix is to take a reference on the descriptors in the select itself around the calls to selscan(). This is annoying, because it's moderately expensive. The problem is that you have to avoid false positives, and you could sleep as a result of some of the underylying implementation stuff. Effectively, this means that you have to allocate a copy of the descriptor table to hold a reference over the whole thing, so that a close of the descriptors out from under you doesn't cause you to panic after coming back. The tricky part is that you have to change the semantics of the selscan() (this part is ugly), which you do by verifying that the descriptor you are using is the same one you were using. You have to do this because there's no way to safely avoid the race of the first and second selscan, where someone closes a descriptor out from under you, and then opens another one in its place in a separate thread in the same application. The way Solaris deals with this issue is that all sleeps are at the same level, so what it can do is force the call to fail out (basically, a cancellation point) for outstanding read() on an fd in one thread, with the descriptor being closed in another. It turns out that parts of the Java netwoking implementation in the full-on Java implementation actually *depends* on this behaviour, so we will have to bite the bullet on it eventually, or rewrite that code when/if it makes it to FreeBSD. The only other things I've thought of that could let you fix this is to be Evil(tm) and fail the close() with the only error that would cause the application to retry it later -- EINTR. This is truly evil, since it's likely the application doesn't check the return value from close, and even if it did, an EINTR would likely cause it to try again immediately. The only other semi-sane approach is Too Evil For Words(tm), which would be to delay the return on the close until the reference count goes from 2-1; the reason this is Too Evil For Words(tm) is this: what do you do when one thread is blocked in the close(), and one is blocked in a read(), and a third thread *also* calls close()? You'd pretty much be guaranteeing that applications that assume the Solaris semantics will all break (arguably, they are already broken, with one thread closing files out from under another, but they appear to function. I guess there's always psignal(p,SIGABRT); 8-) 8-)). I don't think FreeBSD could really implement the Solaris approach, without a lot of code needing to be rewritten to support the idea of cancellation of blocked operations pending completion (basically, a wake-up-any-slept-on-this-fd-process). Maybe Dragonfly BSD will be able to solve this elegantly, but I really doubt it's going to be able to do it. You might also be able to kludge up an internal signal, but the slept thread is probably not sleeping on e.g. the descriptor address (maybe it's slept in a malloc, etc.), so I don't know how you'd know that it had a reference to the thing your trying to take away from it without a rendevous. Maybe it's time to give each blocking context a kqueue or something equally gross. 8-(. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fixed another leak in USB code
On Mon, 28 Jul 2003, John-Mark Gurney wrote: Ok, those of you coming with panics due to kmem exhaustion w/ USB, I have fixed another leak. For some reason I assumed that big blocks were being deallocated upon free, not being put back on the freelist. (Have I mentioned how much it sucks that the USB code it self has five different allocators?) As mentioned in the commit message, I did some testing, and a simple bulk transfer over aue did not increase the devbuf memory usage, while before this patch, I got it quickly over 20megs and growing. Sorry for the breakage. Thanks! regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
STEP 2, fixing dhclient behaviour with multiple interfaces
Hi all, I't is my goal to make dhclient really functional, so it can not only be used with one interface, but several. On a well known OS this works just fine. A first interface gets initialized and the GW gets set as usual. But if a second interface gets added, and the first one is still active and has a working lease, the GW will not be overwriten. If you remove now the first interface, the default GW changes to the one of the second interface. X = Link on IF + = Interface gets added or has new link - = Interface gets removed or lost link IF1 IF2 GW1 GW2 --- X X X + X - X X + X X Too this functionality to dhclient, there is only one way to do it. the ISC-dhclient package offers a OMAPI Command Shell omsshell(1). There you can add new interfaces or even remove existing ones. The work that needs to be done is: - Adding a unix domain socket to OMAPI, so root (or a choosen user) can access dhclient (or dhcpd) on the local machine without authentification. - Providing the omshell scripts for adding and removing interfaces, adding new default gateways on interface removal etc ... - Change our infrastructure (devd, rc.d/dhclient script) to use them. If there are other ideas, I'm open to them. Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
Martin Blapp wrote: I't is my goal to make dhclient really functional, so it can not only be used with one interface, but several. On a well known OS this works just fine. A first interface gets initialized and the GW gets set as usual. But if a second interface gets added, and the first one is still active and has a working lease, the GW will not be overwriten. If you remove now the first interface, the default GW changes to the one of the second interface. [ ... ] If there are other ideas, I'm open to them. You could add kevents for interface arrival and departure, and add a kqueue to the dhcpd to catch the arrival/departure events, and then just act on them. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: device driver memory leak in 5.1-20030726?
John-Mark Gurney writes: Gary Jennejohn wrote this message on Mon, Jul 28, 2003 at 12:58 +0200: It appears to me that the test in usb_block_allocmem() should be (p-tag-parent == tag || p-tag-parent == tag-parent) and NOT p-tag == tag! That's because bus_dma_tag_create() uses the tag passed into usb_block_allocmem() as newtag-parent! Unfortunately, bus_dma_tag is an opaque type and there's no way to access the parent member anywhere but in the MD busdma_machdep.c :-( Anyway, as written there's no way that I can see that the code can work correctly. You miss the code in the XXX bit that overrides the tag with the tag passed in. If we allocate a fullblock, the tag doesn't need to be overwriten since we end up freeing it, but in the fragment case, we override the tag, and we don't need to keep the tag allocated by usb_block_allocmem since we never end up freeing the block that is part of the fragments. The bug fixed in rev1.2 was because of a difference in how NetBSD/OpenBSD handles things. We wouldn't need this if we had a size parameter to bus_dmamem_alloc. Please reread the code and see what I mean. OK. The questions still remains why it isn't working, or have you figured that out? Obviously, I don't understand it ;-) --- Gary Jennejohn / garyj[at]jennejohn.org gj[at]freebsd.org gj[at]denx.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
new.h is missing
Hi, I am running FreeBSD 5.1-CURRENT (22.07.03) im trying to port a software, and on compile time i get Tools_List.hpp:51:17: new.h: No such file or directory Leading to lots of errors afterwards i.e. : void* operator new(unsigned int, SAPDBMem_IRawAllocator) RTEMem_Allocator.cpp:124: no matching function for call to `operator new(unsigned int, SAPDBMem_IRawAllocator::AlignType[1])' Any ideas ? Thanx Kai ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new.h is missing
On Tuesday 29 July 2003 11:54, Kai Mosebach wrote: Hi, I am running FreeBSD 5.1-CURRENT (22.07.03) im trying to port a software, and on compile time i get Tools_List.hpp:51:17: new.h: No such file or directory Leading to lots of errors afterwards i.e. : void* operator new(unsigned int, SAPDBMem_IRawAllocator) RTEMem_Allocator.cpp:124: no matching function for call to `operator new(unsigned int, SAPDBMem_IRawAllocator::AlignType[1])' Any ideas ? new.h is an obsolete header file (which was removed in gcc 3.3)... use #include new instead to get placement new with C++ Thanx Kai ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- Bradley T. Hughes - bhughes at trolltech.com Trolltech AS - Waldemar Thranes gt. 98 N-0175 Oslo, Norway ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new.h is missing
On Tue, 29 Jul 2003, Kai Mosebach wrote: Date: Tue, 29 Jul 2003 11:54:25 +0200 From: Kai Mosebach [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: new.h is missing Hi, I am running FreeBSD 5.1-CURRENT (22.07.03) im trying to port a software, and on compile time i get Tools_List.hpp:51:17: new.h: No such file or directory Shouldn't that be: ... #include new ... since new.h is not standart any longer... Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
-current 'make release' status?
Hi,
I'm currently down to this patch to allow a make release to complete
for -current:
===
RCS file: /home/ncvs/src/release/Makefile,v
retrieving revision 1.801
diff -u -r1.801 Makefile
--- Makefile26 Jul 2003 06:47:40 - 1.801
+++ Makefile29 Jul 2003 05:09:31 -
@@ -1053,7 +1053,7 @@
cd ${.CURDIR}/..; \
KERNEL_KO=BOOTMFS KODIR= \
${CROSSMAKE} ${KERNEL_FLAGS} -DNO_MODULES -DNO_KERNELCLEAN \
- KERNCONF=BOOTMFS COPTFLAGS=-Os -pipe -DNO_CPU_COPTFLAGS \
+ KERNCONF=BOOTMFS COPTFLAGS=-Os -pipe -w -DNO_CPU_COPTFLAGS \
buildkernel reinstallkernel \
DESTDIR=${RD}/kernels
[ -r ${.CURDIR}/../sys/${TARGET}/conf/BOOTMFS.hints ] \
without it, the following causes BOOTMFS to abort:
cc -c -Os -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith
-Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys
-I/usr/src/sys/dev -I/usr/src
/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath
-I/usr/src/sys/contrib/dev/a
th/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000
-mno-align-long-strings -mpreferred-st
ack-boundary=2 -ffreestanding -Werror /usr/src/sys/cam/cam_periph.c
In file included from /usr/src/sys/cam/cam_periph.c:41:
/usr/src/sys/sys/buf.h: In function `BUF_LOCK':
/usr/src/sys/sys/buf.h:289: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:289: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h: In function `BUF_TIMELOCK':
/usr/src/sys/sys/buf.h:310: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:310: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h: In function `BUF_UNLOCK':
/usr/src/sys/sys/buf.h:325: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:325: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h: In function `BUF_KERNPROC':
/usr/src/sys/sys/buf.h:350: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:350: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:352: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:352: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/cam/cam_periph.c: In function `cam_periph_mapmem':
/usr/src/sys/cam/cam_periph.c:624: warning: dereferencing type-punned pointer will
break strict-aliasing rules
.
.
.
Thoughts? Plans?
It's also worth noting that the BOOTMFS kernel build is inconsistant. The
initial build via 'make release' fails with no patch. After the failure,
a followup:
chroot $RDIR /bin/sh
/mk doMFSKERN
works correctly. The 'make release' environment is setup differently
from that of /mk. Depending on what folks think, maybe some form of:
make mk TARGET=doMFSKERN
would be appropriate to guarentee consistancy. Just a thought.
-John
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
AW: new.h is missing
Tried that too, but wasnt working either. [EMAIL PROTECTED]:/usr/sapdb/src/FreeBSD/sys/src/SAPDB] # locate new|grep include /usr/include/c++/3.3/backward/new.h /usr/include/c++/3.3/new is that sufficient for g++ to find ? regards Kai -Ursprüngliche Nachricht- Von: Michael Reifenberger [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 29. Juli 2003 12:03 An: Kai Mosebach Cc: [EMAIL PROTECTED] Betreff: Re: new.h is missing On Tue, 29 Jul 2003, Kai Mosebach wrote: Date: Tue, 29 Jul 2003 11:54:25 +0200 From: Kai Mosebach [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: new.h is missing Hi, I am running FreeBSD 5.1-CURRENT (22.07.03) im trying to port a software, and on compile time i get Tools_List.hpp:51:17: new.h: No such file or directory Shouldn't that be: ... #include new ... since new.h is not standart any longer... Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
rcng: additional argument to run_rc_command
is it possible to give an extra argument to an $extra_commands command? the usual call to run_rc_command run_rc_command $1 suggests otherwise, as $1 already is the name of the command to be executed (start, stop, etc). would this be possible/a good idea to implement? thx, t. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
On Tue, Jul 29, 2003 at 09:56:48AM +0200, Martin Blapp wrote: I't is my goal to make dhclient really functional, so it can not only be used with one interface, but several. Yay! This bites me badly on my laptop with a permanent fxp0 and a sometimes-present wi0. On a well known OS this works just fine. A first interface gets initialized and the GW gets set as usual. But if a second interface gets added, and the first one is still active and has a working lease, the GW will not be overwriten. If you remove now the first interface, the default GW changes to the one of the second interface. X = Link on IF + = Interface gets added or has new link - = Interface gets removed or lost link IF1 IF2 GW1 GW2 --- X X X + X - X X + X X Too this functionality to dhclient, there is only one way to do it. the ISC-dhclient package offers a OMAPI Command Shell omsshell(1). There you can add new interfaces or even remove existing ones. The work that needs to be done is: - Adding a unix domain socket to OMAPI, so root (or a choosen user) can access dhclient (or dhcpd) on the local machine without authentification. You can get omshell working without auth over tcp/ip - I managed this today when playing. But a unix domain socket would be nicer because the dhclient server binds to INADDR_ANY by default. - Providing the omshell scripts for adding and removing interfaces, adding new default gateways on interface removal etc ... - Change our infrastructure (devd, rc.d/dhclient script) to use them. If there are other ideas, I'm open to them. At present, dhclient gets given a list of interfaces at startup-time. Would it be better to start it in no-interfaces mode (-n -w) and dynamically add /all/ interfaces using omshell? Another (loosely related) thing is that we should be able to use omshell to tell dhclient to pause before going into suspend. This is hinted at in the dhclient man page, but it would be good to get it into the standard infrastructure. -Dom ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AW: new.h is missing
On Tuesday, July 29, 2003, at 5:51AM, Kai Mosebach wrote: Tried that too, but wasnt working either. [EMAIL PROTECTED]:/usr/sapdb/src/FreeBSD/sys/src/SAPDB] # locate new|grep include /usr/include/c++/3.3/backward/new.h /usr/include/c++/3.3/new /usr/include/c++/3.3/new ought to be it. did you try your program with #include new yet? is that sufficient for g++ to find ? regards Kai -Ursprüngliche Nachricht- Von: Michael Reifenberger [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 29. Juli 2003 12:03 An: Kai Mosebach Cc: [EMAIL PROTECTED] Betreff: Re: new.h is missing On Tue, 29 Jul 2003, Kai Mosebach wrote: Date: Tue, 29 Jul 2003 11:54:25 +0200 From: Kai Mosebach [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: new.h is missing Hi, I am running FreeBSD 5.1-CURRENT (22.07.03) im trying to port a software, and on compile time i get Tools_List.hpp:51:17: new.h: No such file or directory Shouldn't that be: ... #include new ... since new.h is not standart any longer... Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
AW: AW: new.h is missing
-Ursprüngliche Nachricht- Von: David Leimbach [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 29. Juli 2003 13:57 An: Kai Mosebach Cc: 'Michael Reifenberger'; [EMAIL PROTECTED] Betreff: Re: AW: new.h is missing On Tuesday, July 29, 2003, at 5:51AM, Kai Mosebach wrote: Tried that too, but wasnt working either. [EMAIL PROTECTED]:/usr/sapdb/src/FreeBSD/sys/src/SAPDB] # locate new|grep include /usr/include/c++/3.3/backward/new.h /usr/include/c++/3.3/new /usr/include/c++/3.3/new ought to be it. did you try your program with #include new yet? Yes i did, but it wasnt found too. I was wondering, that in 4.x there is a folder /usr/include/g++ where all the stuff is found, and on 5.1-CURRENT its in /usr/include/c++/3.3, where im not sure, whether g++ uses this path automatically ? is that sufficient for g++ to find ? regards Kai -Ursprüngliche Nachricht- Von: Michael Reifenberger [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 29. Juli 2003 12:03 An: Kai Mosebach Cc: [EMAIL PROTECTED] Betreff: Re: new.h is missing On Tue, 29 Jul 2003, Kai Mosebach wrote: Date: Tue, 29 Jul 2003 11:54:25 +0200 From: Kai Mosebach [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: new.h is missing Hi, I am running FreeBSD 5.1-CURRENT (22.07.03) im trying to port a software, and on compile time i get Tools_List.hpp:51:17: new.h: No such file or directory Shouldn't that be: ... #include new ... since new.h is not standart any longer... Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
Hi, can access dhclient (or dhcpd) on the local machine without authentification. You can get omshell working without auth over tcp/ip - I managed this today when playing. But a unix domain socket would be nicer because the dhclient server binds to INADDR_ANY by default. Cool. Do you have any pointers for me to try ? Little example etc ? At present, dhclient gets given a list of interfaces at startup-time. Would it be better to start it in no-interfaces mode (-n -w) and dynamically add /all/ interfaces using omshell? Exactly. Starting dhclient as a daemon without any interfaces. And just use omshell to add/remove interfaces. Another (loosely related) thing is that we should be able to use omshell to tell dhclient to pause before going into suspend. This is hinted at in the dhclient man page, but it would be good to get it into the standard infrastructure. Yup, that makes sence. Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: -current 'make release' status?
On Tue, Jul 29, 2003 at 06:30:54AM -0400, John wrote:
Hi,
I'm currently down to this patch to allow a make release to complete
for -current:
[...]
Try setting the KERNEL_FLAGS=-DNO_WERROR instead.
without it, the following causes BOOTMFS to abort:
cc -c -Os -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith
-Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I.
-I/usr/src/sys -I/usr/src/sys/dev -I/usr/src
/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter
-I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/a
th/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000
-mno-align-long-strings -mpreferred-st
ack-boundary=2 -ffreestanding -Werror /usr/src/sys/cam/cam_periph.c
In file included from /usr/src/sys/cam/cam_periph.c:41:
/usr/src/sys/sys/buf.h: In function `BUF_LOCK':
/usr/src/sys/sys/buf.h:289: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:289: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h: In function `BUF_TIMELOCK':
/usr/src/sys/sys/buf.h:310: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:310: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h: In function `BUF_UNLOCK':
/usr/src/sys/sys/buf.h:325: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:325: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h: In function `BUF_KERNPROC':
/usr/src/sys/sys/buf.h:350: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:350: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:352: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:352: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/cam/cam_periph.c: In function `cam_periph_mapmem':
/usr/src/sys/cam/cam_periph.c:624: warning: dereferencing type-punned pointer will
break strict-aliasing rules
.
.
.
Thoughts? Plans?
It's also worth noting that the BOOTMFS kernel build is inconsistant. The
initial build via 'make release' fails with no patch. After the failure,
a followup:
chroot $RDIR /bin/sh
/mk doMFSKERN
works correctly. The 'make release' environment is setup differently
from that of /mk. Depending on what folks think, maybe some form of:
make mk TARGET=doMFSKERN
would be appropriate to guarentee consistancy. Just a thought.
If this is the case, then it's a bug and should be fixed. I am
looking to see now if I can reproduce the problem, but a wild
guess is that: release/Makefile calls chroot(8) a bit differently,
with a clean environment, like this:
env -i /usr/sbin/chroot ${CHROOTDIR} /mk
Could it be that you have something in your environment similar
to NO_WERROR?
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
pgp0.pgp
Description: PGP signature
Re: new.h is missing
On Tue, Jul 29, 2003 at 02:00:59PM +0200, Kai Mosebach wrote: [...] I was wondering, that in 4.x there is a folder /usr/include/g++ where all the stuff is found, and on 5.1-CURRENT its in /usr/include/c++/3.3, where im not sure, whether g++ uses this path automatically ? /usr/libexec/cc1plus -v Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
AW: new.h is missing
-Ursprüngliche Nachricht- Von: Ruslan Ermilov [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 29. Juli 2003 14:06 An: Kai Mosebach Cc: David Leimbach; Michael Reifenberger; [EMAIL PROTECTED] Betreff: Re: new.h is missing On Tue, Jul 29, 2003 at 02:00:59PM +0200, Kai Mosebach wrote: [...] I was wondering, that in 4.x there is a folder /usr/include/g++ where all the stuff is found, and on 5.1-CURRENT its in /usr/include/c++/3.3, where im not sure, whether g++ uses this path automatically ? /usr/libexec/cc1plus -v [EMAIL PROTECTED]:~] # /usr/libexec/cc1plus -v GNU CPP version 3.2.2 [FreeBSD] 20030205 (release) (cpplib) (i386 FreeBSD/ELF) ignoring nonexistent directory /usr/include/g++/backward ignoring duplicate directory /usr/include #include ... search starts here: #include ... search starts here: /usr/include/g++ /usr/include End of search list. Where are they defined ? Cheers, -- Ruslan ErmilovSysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
On Tue, Jul 29, 2003 at 02:01:36PM +0200, Martin Blapp wrote: can access dhclient (or dhcpd) on the local machine without authentification. You can get omshell working without auth over tcp/ip - I managed this today when playing. But a unix domain socket would be nicer because the dhclient server binds to INADDR_ANY by default. Cool. Do you have any pointers for me to try ? Little example etc ? /etc/dhclient.conf contains: omapi port 7911; Then, as root: # dhclient -n -w And in another terminal: % netstat -an | grep -w 7911 tcp4 0 0 *.7911 *.* LISTEN % omshell connect obj: null new control obj: control open obj: control state = 00:00:00:00 set state = 2 obj: control state = 2 update obj: control state = 2 At this point, go back to the other window and notice that dhclient hs terminated. I haven't played much further than this yet, though. The only other thing I noticed is that getting a list of what objects are present doesn't seem to be supported. Well, I couldn't see how to do it... -Dom ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new.h is missing
On Tue, Jul 29, 2003 at 02:09:24PM +0200, Kai Mosebach wrote: -Urspr?ngliche Nachricht- Von: Ruslan Ermilov [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 29. Juli 2003 14:06 An: Kai Mosebach Cc: David Leimbach; Michael Reifenberger; [EMAIL PROTECTED] Betreff: Re: new.h is missing On Tue, Jul 29, 2003 at 02:00:59PM +0200, Kai Mosebach wrote: [...] I was wondering, that in 4.x there is a folder /usr/include/g++ where all the stuff is found, and on 5.1-CURRENT its in /usr/include/c++/3.3, where im not sure, whether g++ uses this path automatically ? /usr/libexec/cc1plus -v [EMAIL PROTECTED]:~] # /usr/libexec/cc1plus -v GNU CPP version 3.2.2 [FreeBSD] 20030205 (release) (cpplib) (i386 FreeBSD/ELF) ignoring nonexistent directory /usr/include/g++/backward ignoring duplicate directory /usr/include #include ... search starts here: #include ... search starts here: /usr/include/g++ /usr/include End of search list. Where are they defined ? On 5.1-CURRENT, this looks differently: $ /usr/libexec/cc1plus -v ignoring duplicate directory /usr/include #include ... search starts here: #include ... search starts here: /usr/include/c++/3.3 /usr/include/c++/3.3/backward /usr/include End of search list. ^C Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: rcng: additional argument to run_rc_command
On Tue, Jul 29, 2003 at 01:13:51PM +0200, Tobias Roth wrote: is it possible to give an extra argument to an $extra_commands command? the usual call to run_rc_command run_rc_command $1 suggests otherwise, as $1 already is the name of the command to be executed (start, stop, etc). would this be possible/a good idea to implement? I very much doubt it. If you want to use multiple arguments just special case it in the script itself (i.e - rc.d/netif). Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - Unleash the Daemon! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.2-RELEASE TODO
This is an automated bi-weekly mailing of the FreeBSD 5.2 open issues list. The live version of this list is available at: http://www.FreeBSD.org/releases/5.2R/todo.html Automated mailing of this list will continue through the release of FreeBSD 5.2. FreeBSD 5.2 Open Issues Open Issues This is a list of open issues that need to be resolved for FreeBSD 5.2. If you have any updates for this list, please e-mail [EMAIL PROTECTED] Must Resolve Issues for 5.2-RELEASE ++ |Issue| Status | Responsible | Description | |-+--+-+-| | | | | KSE M:N threading | | | | | support is reaching | | | | | experimental yet| | | | Julian | usable status on| | Production-quality | In | Elischer, David | i386 for| | M:N threading | progress | Xu, Daniel | 5.1-RELEASE. M:N| | | | Eischen | threading should be | | | | | productionable and | | | | | usable on all | | | | | platforms by| | | | | 5.2-RELEASE.| |-+--+-+-| | | | | Currently, the MD | | | | | elements of KSE are | | | | | present only for| | | | | the i386 platform, | | | | | limiting use of KSE | | | | | to the i386 | | | | | platform. It is | | | | | highly desirable to | | KSE support for | | Jake| make KSE available | | sparc64, alpha, | -- | Burkholder, --, | on non-i386 | | ia64| | -- | platforms for | | | | | 5.2-RELEASE so that | | | | | KSE can see more| | | | | broad exposure, and | | | | | the performance | | | | | benefits of KSE can | | | | | be visible to users | | | | | of the 64-bit | | | | | FreeBSD | | | | | architectures. | |-+--+-+-| | | | | Kris Kennaway | | | | | reports high| | | | | instability of | | | | | 5-CURRENT on ia64 | | | In | Marcel | machines, such as | | ia64 stability | Progress | Moolenaar | the pluto* | | | | | machines. These | | | | | problems need to be | | | | | fixed in order to | | | | | get a successful| | | | | package build. | |-+--+-+-| | | | | ia64 serial console | | | | | support is reported | | | | | to not be | | | | | functional on HP| | | In | Marcel | Itanium2 platforms. | | ia64 sio support| progress | Moolenaar, | A reworking of the | | | | Warner Losh | sio driver to | | | | | improve platform| | | | | independence and| | | | | bus handling is | | | |
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
On Tue, 29 Jul 2003, Terry Lambert wrote: Martin Blapp wrote: I't is my goal to make dhclient really functional, so it can not only be used with one interface, but several. On a well known OS this works just fine. A first interface gets initialized and the GW gets set as usual. But if a second interface gets added, and the first one is still active and has a working lease, the GW will not be overwriten. If you remove now the first interface, the default GW changes to the one of the second interface. [ ... ] If there are other ideas, I'm open to them. You could add kevents for interface arrival and departure, and add a kqueue to the dhcpd to catch the arrival/departure events, and then just act on them. Some of those events already exist for routing sockets, so in a worst case scenario, you can hook up a routing socket to a kqueue :-). Martin -- you might want to try the route monitor command sometime and take a look at the vent stream there for things to consider. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Highly loaded machine getting slower and slower
On Mon, 28 Jul 2003, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Lukas Ertl writes: Hi there, I'm having again problems with a highly loaded 5.1-current machine. The box is a 2.4GHz Dual Xeon (HTT enabled) with 1GB RAM and acts as a news server/feeder running diablo. It's pumping out 120+Mbit/sec over Gigabit without a glitch, but after some time, it's getting slower and slower, until it seems to completely freeze, but it's still alive, just _very_ unresponsive and in fact has to be rebooted. Run a shell script in cron every 5 minutes where you record date sysctl kern.malloc sysctl vm.zone swapinfo ps -axlw and look out for anything which just gobbles up more and more memory. Unfortunately, this didn't show anything significant. But I've played around a little and built a kernel without WITNESS and friends, but with options ADAPTIVE_MUTEXES. Now the box is up for almost five hours and is still running, which really surprised us. :-) Throughput is ok, but the limiting factor currently seems to be disk I/O. It's a pity that ciss(4) isn't more performant right now. Anyway, we hope the box stays up and we'll keep monitoring that. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: -current 'make release' status? [SOLVED]
On Tue, Jul 29, 2003 at 09:41:54AM -0400, John De Boskey wrote: - Ruslan Ermilov's Original Message - No, I have nothing in my environment that should affect the build, no /etc/make.conf in the chroot area.. But then again: running make rerelease is effectively just calls the command above. I'm currently in the middle of the make release and will see if this is reproduceable. # chroot /vol/vol0/work/5-current-chrootdir /bin/sh # env A few things not needed that are inherited from my normal account, but nothing that should have a negative affect. Do you still get the error if you try make rerelease? Do you still get the error if you try chroot ... /mk? Do you still get the error if you try env -i chroot ... /mk? I'll see what I can find.. John, I see the same breakage as you do. But in all three cases above, I see the same breakage (as expected). Even if I'm running chroot /data/ru/R then ./mk doMFSKERN, I still get it: : In file included from /usr/src/sys/cam/cam_periph.c:41: : /usr/src/sys/sys/buf.h: In function `BUF_LOCK': : /usr/src/sys/sys/buf.h:289: warning: dereferencing type-punned pointer will break strict-aliasing rules : ... : *** Error code 1 : : Stop in /usr/obj/usr/src/sys/BOOTMFS. Forget what I've said about NO_WERROR, it (unfortunately) only applies to the userland. Still, running make rerelease KERNEL_FLAGS=WERROR= gets the release done. I wondered why I get it, and similarly my nigthly buildkernel completed without errors. This turned out to be due to the -O vs. -Os differences. For example, compiling vfs_subr.o from the GENERIC kernel results in these same warnings when compiled with COPTFLAGS=-Os -pipe. Peter, should we switch -Werror back off in kern.pre.mk? Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: linksys wireless usb adapter
Someone said few weeks ago that USB-wifi is not supported at all under FreeBSD for now. Olivier Le Lun 28/07/2003 17:01, Paulo Roberto a crit : Is there any on going work for this usb network interface? thanks Paulo __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
Robert Watson wrote: [ ... ] If there are other ideas, I'm open to them. You could add kevents for interface arrival and departure, and add a kqueue to the dhcpd to catch the arrival/departure events, and then just act on them. Some of those events already exist for routing sockets, so in a worst case scenario, you can hook up a routing socket to a kqueue :-). Martin -- you might want to try the route monitor command sometime and take a look at the vent stream there for things to consider. Does that work if you don't have an IP address assigned to the interface at all yet? I was under the impression that it only sent out route change events (maybe I need to update my copy of the -current sources, though). What I was talking about is the idea that naked interface (0.0.0.0) arrivals and departures could be signalled, which would cause dhclient to try to get a lease on the interface. I'm afraid there's still a chicken-and-egg problem over devices that you want to be able to come and go, without attempting to get a lease. Probably the way to handle them is with an explicit not this device list, since it would let unknown devices just work by default, which is kind of what you want. Presumably, if you don't want a lease it's because you've got a static assignment for that particular device that you want used instead. I can't wait for IPv6 stateless autoconfiguration plus SLPv2 so we can get rid of all this DHCP crap once and for all. 8-(. SLPv2 is used to find the gateway and DNS server, and after that, everything magically works. If you get a lease in a zone, then because the forward record exists (because you have a Cert. for your own zone, the local DNS server should be willing to perform updates for your reverse record which it knows matcheds the forward record that lives in its zone but exists back on your home domain. Of course, this only works with IPv6, unless you use IPv4 with a link.local net plus integrated NAT in the gateway box. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[PATCH] jail NG schript patch for mounting devfs and procfsautomatically
Hi all, hi Clement,
I updated the rcng jail start script to mount devfs and procfs
into the jail if wanted. Adding entries to /etc/fstab didn't
work properly, because the jail filesystem wasn't mounted when
the startup process wants to mount it.
Going this way allows us to control which jail could be used
via ssh (or another remote shell), too.
Any comments gladly welcome.
If it's useful for FreeBSD, I will write the rc.conf(5) update,
too. Please inform me to do this.
Regards,
Jens
--- etc/rc.d/jail.orig Mon May 5 15:38:41 2003
+++ etc/rc.d/jail Tue Jul 29 14:49:34 2003
@@ -53,6 +53,16 @@
eval jail_hostname=\\$jail_${_jail}_hostname\
eval jail_ip=\\$jail_${_jail}_ip\
eval jail_exec=\\$jail_${_jail}_exec\
+ eval jail_devfs=\\$jail_${_jail}_mount_devfs\
+ eval jail_procfs=\\$jail_${_jail}_mount_procfs\
+ if [ -n ${jail_devfs} ] checkyesno jail_devfs ; then
+ echo Mounting devfs to ${jail_rootdir}/dev
+ mount -t devfs devfs ${jail_rootdir}/dev
+ fi;
+ if [ -n ${jail_procfs} ] checkyesno jail_procfs ; then
+ echo Mounting procfs to ${jail_rootdir}/proc
+ mount -t procfs procfs ${jail_rootdir}/proc
+ fi;
[ -z ${jail_exec} ] jail_exec=/bin/sh /etc/rc
jail ${jail_rootdir} ${jail_hostname} ${jail_ip} ${jail_exec}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] jail NG schript patch for mounting devfs and procfsautomatically
On Tue, 29 Jul 2003, Jens Rehsack wrote: I updated the rcng jail start script to mount devfs and procfs into the jail if wanted. Adding entries to /etc/fstab didn't work properly, because the jail filesystem wasn't mounted when the startup process wants to mount it. Going this way allows us to control which jail could be used via ssh (or another remote shell), too. Any comments gladly welcome. If it's useful for FreeBSD, I will write the rc.conf(5) update, too. Please inform me to do this. Neat. Someone, and unfortunately I appear to have lost track of who, had some tweaks to the rcNG scripts to set up some reasonable devfs rules for a jail, and apply them to the devfs mounted in a jail. Otherwise, you risk exposing undesired device nodes to the virtual environment. I suspect a search of the -current archives will turn up who, but I think a necessary part of a solution here will be to make sure jails are set up with the right devfs contents. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: USB da(4) quirks deprecated
You may have a device (USB camera, pen drive, hard drive, ...) that begins to get errors like ... Synchronize cache failed, status 0x35. If the Sync cache fails with a reasonable error code, then the code that silence these errors should be enhanced rather than have a quirk entry added. Just to reitterate, the quirks are there for situations that cannot be handled in a more programatic way (e.g. a device that dies when you send it a certain command). Please don't blindly re-enable quirks to silence junk that winds up in syslog. -- Justin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.1-RELEASE hardware detect problem - install stalls
I am attempting to install 5.1-RELEASE. The following items appear in the log file. This section is repeated ~15 times, and then the install procedure moves on to the ...probing devices ... screen and never moves on from there (of course, never is the limit if my patience ... 30 minutes). I am using the 5.1-RELEASE-i386-disc1.iso pulled down from a mirror ftp site today. First, here's the cut/paste of dmesg for 4.8. I think it might be relevant to the hardware configuration with which 5.1 is having problems. --- start dmesg-- - FreeBSD 4.8-STABLE #0: Fri Jul 25 10:22:38 PDT 2003 [EMAIL PROTECTED]:/usr/src/sys/compile/KERNEL.4 Timecounter i8254 frequency 1193182 Hz CPU: AMD Athlon(tm) XP 1700+ (1471.92-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x662 Stepping = 2 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc048MP,AMIE,DSP,3DNow! real memory = 268369920 (262080K bytes) snip atapci0: VIA 8233 ATA100 controller port 0xfc00-0xfc0f at device 17.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 snip ad0: 19470MB Maxtor 52049U4 [39560/16/63] at ata0-master UDMA66 ad1: 19470MB QUANTUM FIREBALLP LM20 [39560/16/63] at ata0-slave UDMA66 acd0: CD-RW PLEXTOR CD-R PX-W1210A at ata1-master PIO4 acd1: MODE_SENSE_BIG command timeout - resetting ata1: resetting devices .. done acd1: CDROM CD-ROM CDU611-F at ata1-slave PIO4 Mounting root from ufs:/dev/ad0s2a cd1 at ata1 bus 0 target 1 lun 0 cd1: SONY CD-ROM CDU611-F 2.1a Removable CD-ROM SCSI-0 device cd1: 16.000MB/s transfers cd1: cd present [315026 x 2048 byte records] cd0 at ata1 bus 0 target 0 lun 0 cd0: PLEXTOR CD-R PX-W1210A 1.10 Removable CD-ROM SCSI-0 device cd0: 16.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed --- end dmesg - --- I used the verbose logging option to obtain the following information -- start 5.1 install logging - acd0: Plextor CDR at ata1 as master snip, the next 7 lines repeat acd1: MODE_SENSE_BIG command timeout - resetting ata1: resetting devices .. ata1: pre reset mask=03 ostat0=50 ostat2=08 acd0: ATAPI 14eb acd1: ATAPI 14eb ata1: after reset mask=03 stat0=00 stat1=00 ata1: devices=0c -- Joe Sotham praxis makes Perfect. - Meister Eckhart ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] jail NG schript patch for mounting devfs and procfsautomatically
On 29.07.2003 18:47, Robert Watson wrote: On Tue, 29 Jul 2003, Jens Rehsack wrote: I updated the rcng jail start script to mount devfs and procfs into the jail if wanted. Adding entries to /etc/fstab didn't work properly, because the jail filesystem wasn't mounted when the startup process wants to mount it. Going this way allows us to control which jail could be used via ssh (or another remote shell), too. Any comments gladly welcome. If it's useful for FreeBSD, I will write the rc.conf(5) update, too. Please inform me to do this. Neat. :-) Someone, and unfortunately I appear to have lost track of who, had some tweaks to the rcNG scripts to set up some reasonable devfs rules for a jail, and apply them to the devfs mounted in a jail. Otherwise, you risk exposing undesired device nodes to the virtual environment. I suspect a search of the -current archives will turn up who, but I think a necessary part of a solution here will be to make sure jails are set up with the right devfs contents. Sorry, overseen. Sct W. Hetzel was the submitter, but it never becomes committed. If could be be so kind, please :-) (of course, not without prove it first) Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: USB da(4) quirks deprecated
On Tue, 29 Jul 2003, Justin T. Gibbs wrote: You may have a device (USB camera, pen drive, hard drive, ...) that begins to get errors like ... Synchronize cache failed, status 0x35. If the Sync cache fails with a reasonable error code, then the code that silence these errors should be enhanced rather than have a quirk entry added. I'm committed to doing that for devices which respond in a reasonable way (whether error or success). Just to reitterate, the quirks are there for situations that cannot be handled in a more programatic way (e.g. a device that dies when you send it a certain command). Please don't blindly re-enable quirks to silence junk that winds up in syslog. I won't be re-enabling quirks except for devices which hang. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] jail NG schript patch for mounting devfs and procfsautomatically
On Tue, Jul 29, 2003 at 07:08:38PM +0200, Jens Rehsack wrote: On 29.07.2003 18:47, Robert Watson wrote: Someone, and unfortunately I appear to have lost track of who, had some tweaks to the rcNG scripts to set up some reasonable devfs rules for a jail, and apply them to the devfs mounted in a jail. Otherwise, you risk exposing undesired device nodes to the virtual environment. I suspect a search of the -current archives will turn up who, but I think a necessary part of a solution here will be to make sure jails are set up with the right devfs contents. Sorry, overseen. Sct W. Hetzel was the submitter, but it never becomes committed. If could be be so kind, please :-) (of course, not without prove it first) Yeah, I'll take care of this. I had asked scott to mail me his final patch so I could commit it, but I never heard back from him. I'll dig out the revisions from my mail archives and combine the two. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - Unleash the Daemon! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on alpha/alpha
TB --- 2003-07-29 16:00:04 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-07-29 16:00:04 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-29 16:03:25 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-07-29 17:08:53 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Tue Jul 29 17:08:53 GMT 2003 Kernel build for GENERIC completed on Tue Jul 29 17:20:40 GMT 2003 TB --- 2003-07-29 17:20:40 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- /usr/bin/make -B LINT TB --- 2003-07-29 17:20:41 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Tue Jul 29 17:20:41 GMT 2003 [...] cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/advansys/adwlib.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/advansys/adwmcode.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/aha/aha.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror
Palm syncing over USB on FreeBSD, any hopes?
[ I sent this message to pilot-link-devel and coldsync-users. I'm trying in freebsd-current and freebsd-hardware to see if I have better luck. -rsi ] So I've tried everything I could to sync my Sony Clie SJ10 (PalmOS 4.0) with FreeBSD 4.8-STABLE and 5-CURRENT including setting up ppp over ucom0 for netsync as David Desrosiers suggested in: http://lists.pilot-link.org/pipermail/pilot-link-general/2003-February/000896.html. No dice. When I use ucom, the device_probe_and_attach fails. The exact message is: ucom0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 ucom0: init failed, STALLED device_probe_and_attach: ucom0 attach returned 6 Coldsync doesn't work with ugen0 either. I turned on USB debugging and it seems like the failure point is when the FreeBSD USB driver tries to do a bulk read at the second end point on ugen0. I've been digging into the USB code, but am not sure how to fix it. Any suggestions? I'll be more than happy to help with any testing and debugging, but need a pointer in the right direction. Thanks, Rajappa -- [EMAIL PROTECTED] a.k.a. Rajappa Iyer. Absinthe makes the tart grow fonder. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Palm syncing over USB on FreeBSD, any hopes?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 29 July 2003 19:24, Rajappa Iyer wrote: ucom0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 ucom0: init failed, STALLED device_probe_and_attach: ucom0 attach returned 6 Try this: http://www.lphp.org/popups/articleswindow.php?id=13 It's been working great for me since FreeBSD-4.7 (now running 4.8) with a Palm m505. Antoine -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/JrB7Y3Hnhkr+5cQRAoMnAJ9AZzDHPCwo4msdpTIt7wcxK/6lUwCffo04 8zgFdNxeD3VzLgFC8dsqW7k= =/SEh -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
On Tue, 29 Jul 2003, Terry Lambert wrote: Some of those events already exist for routing sockets, so in a worst case scenario, you can hook up a routing socket to a kqueue :-). Martin -- you might want to try the route monitor command sometime and take a look at the vent stream there for things to consider. Does that work if you don't have an IP address assigned to the interface at all yet? I was under the impression that it only sent out route change events (maybe I need to update my copy of the -current sources, though). What I was talking about is the idea that naked interface (0.0.0.0) arrivals and departures could be signalled, which would cause dhclient to try to get a lease on the interface. got message of size 24 on Tue Jul 29 13:27:59 2003 RTM_IFANNOUNCE: interface arrival/departure: len 24, if# 6, what: arrival got message of size 96 on Tue Jul 29 13:28:45 2003 RTM_IFINFO: iface status change: len 96, if# 6, flags: got message of size 24 on Tue Jul 29 13:28:45 2003 RTM_IFANNOUNCE: interface arrival/departure: len 24, if# 6, what: departure The event that you currently have to get using kqueue() is the link state, which isn't announced using routing sockets. If only for consistency, I'd like it if there were an ifnet level announcement in routing sockets for a link state change on capable interfaces. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Palm syncing over USB on FreeBSD, any hopes?
Antoine Jacoutot [EMAIL PROTECTED] writes: On Tuesday 29 July 2003 19:24, Rajappa Iyer wrote: ucom0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 ucom0: init failed, STALLED device_probe_and_attach: ucom0 attach returned 6 Try this: http://www.lphp.org/popups/articleswindow.php?id=13 It's been working great for me since FreeBSD-4.7 (now running 4.8) with a Palm m505. Unfortunately, this doesn't seem to work with the Clie. I get the same messages as above. The behavior is the same on 4.8-STABLE and 5.1-CURRENT. There was a note in the usb-bsd mailing list about this issue: http://groups.yahoo.com/group/usb-bsd/message/1645 Is this an accurate statement? Rajappa -- [EMAIL PROTECTED] a.k.a. Rajappa Iyer. Absinthe makes the tart grow fonder. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] jail NG schript patch for mounting devfs and procfsautomatically
On 29.07.2003 19:21, Mike Makonnen wrote: On Tue, Jul 29, 2003 at 07:08:38PM +0200, Jens Rehsack wrote: Yeah, I'll take care of this. I had asked scott to mail me his final patch so I could commit it, but I never heard back from him. I'll dig out the revisions from my mail archives and combine the two. You can mail me the patch first, so that I can test it before you commit it, if you want. Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
Terry Lambert wrote: Martin Blapp wrote: I't is my goal to make dhclient really functional, so it can not only be used with one interface, but several. On a well known OS this works just fine. A first interface gets initialized and the GW gets set as usual. But if a second interface gets added, and the first one is still active and has a working lease, the GW will not be overwriten. If you remove now the first interface, the default GW changes to the one of the second interface. [ ... ] If there are other ideas, I'm open to them. You could add kevents for interface arrival and departure, and add a kqueue to the dhcpd to catch the arrival/departure events, and then just act on them. Instead of just adding the stuff to devd? -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Some people have parts that are so private they themselves have no knowledge of them. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on i386/i386
TB --- 2003-07-29 18:31:41 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-07-29 18:31:41 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/i386 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-29 18:34:24 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-07-29 19:34:01 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Tue Jul 29 19:34:01 GMT 2003 Kernel build for GENERIC completed on Tue Jul 29 19:48:29 GMT 2003 TB --- 2003-07-29 19:48:29 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- /usr/bin/make -B LINT TB --- 2003-07-29 19:48:29 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Tue Jul 29 19:48:29 GMT 2003 [...] cc -shared -nostdlib hack.c -o hack.So rm -f hack.c sh /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/conf/newvers.sh LINT cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -finline-limit=15000 -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline vers.c linking kernel ng_atm.o: In function `ng_atm_mod_event': ng_atm.o(.text+0x24c0): undefined reference to `ng_atm_message_p' ng_atm.o(.text+0x255c): undefined reference to `ng_atm_message_p' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. TB --- 2003-07-29 20:01:08 - /usr/bin/make returned exit code 1 TB --- 2003-07-29 20:01:08 - ERROR: failed to build lint kernel TB --- 2003-07-29 20:01:08 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: -current 'make release' status? [SOLVED]
On Tue, 29 Jul 2003, Ruslan Ermilov wrote: ... Forget what I've said about NO_WERROR, it (unfortunately) only applies to the userland. Still, running make rerelease KERNEL_FLAGS=WERROR= gets the release done. I wondered why I get it, and similarly my nigthly buildkernel completed without errors. This turned out to be due to the -O vs. -Os differences. For example, compiling vfs_subr.o from the GENERIC kernel results in these same warnings when compiled with COPTFLAGS=-Os -pipe. Peter, should we switch -Werror back off in kern.pre.mk? Use -fno-strict-aliasing if you use -Os. Otherwise, -Os is stricter than -O. On second thoughts, -Os implies -f-strict-aliasing because -Os may need strict aliasing for the same reasons as -O2. We've seen -O2 in combination with broken aliasing in libm cause fatal errors. Better find part of -O2 that needs strict aliasing and turn it off too. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: -current 'make release' status? [SOLVED]
On Wed, Jul 30, 2003 at 06:14:17AM +1000, Bruce Evans wrote: On Tue, 29 Jul 2003, Ruslan Ermilov wrote: ... Forget what I've said about NO_WERROR, it (unfortunately) only applies to the userland. Still, running make rerelease KERNEL_FLAGS=WERROR= gets the release done. I wondered why I get it, and similarly my nigthly buildkernel completed without errors. This turned out to be due to the -O vs. -Os differences. For example, compiling vfs_subr.o from the GENERIC kernel results in these same warnings when compiled with COPTFLAGS=-Os -pipe. Peter, should we switch -Werror back off in kern.pre.mk? Use -fno-strict-aliasing if you use -Os. Otherwise, -Os is stricter than -O. On second thoughts, -Os implies -f-strict-aliasing because -Os may need strict aliasing for the same reasons as -O2. We've seen -O2 in combination with broken aliasing in libm cause fatal errors. Better find part of -O2 that needs strict aliasing and turn it off too. Hm, I always thought that -O2 and -Os are just useful aliases that in effect only turn a few dozens of -f optimization flags, and that switching some of them off later is allowed. I.e., -Os -fno-strict-aliasing should work. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: -current 'make release' status? [SOLVED]
In the last episode (Jul 29), Ruslan Ermilov said: Hm, I always thought that -O2 and -Os are just useful aliases that in effect only turn a few dozens of -f optimization flags, and that switching some of them off later is allowed. I.e., -Os -fno-strict-aliasing should work. That does work, but there are still things you can't turn off with -f. They're half-aliases. toplev.c::parse_options_and_default_flags does set -f flags based on the optimization level, but there is still a whole lot of gcc code that directly tests the value of optimize and optimize_size. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADSUP: UMA not reentrant / possible memory leak
[I'm CC'ing current because this seems to have a significant negative
impact on -current kernel stability, and we can use some more data,
in particular on non-i386 SMP machines]
Thanks to Lukas Ertl and Bosko we have found a clear indication that
UMA is in fact not reentrant (enough).
The indication of this is that the g_bio zone does not return to
zero USED as it should.
The attached patch adds an atomic counter in GEOM to count the number
of actually used items in the sysctl variable debug.ngbio.
Here is a typical output from my SMP box:
bang# sh a.sh
g_bio: 144,0, 35, 77, 4281
debug.ngbio: 0
10:58PM up 36 secs, 1 user, load averages: 0.65, 0.20, 0.07
g_bio: 144,0, 66,102, 5917
debug.ngbio: 0
10:58PM up 56 secs, 3 users, load averages: 0.46, 0.18, 0.07
g_bio: 144,0, 69, 99,12352
debug.ngbio: 0
10:59PM up 1 min, 3 users, load averages: 0.56, 0.22, 0.09
g_bio: 144,0,185,123,20023
debug.ngbio: 0
10:59PM up 2 mins, 3 users, load averages: 0.62, 0.25, 0.10
g_bio: 144,0,227, 81,28259
debug.ngbio: 0
10:59PM up 2 mins, 3 users, load averages: 0.64, 0.28, 0.11
g_bio: 144,0,222, 86,32256
debug.ngbio: 0
11:00PM up 2 mins, 3 users, load averages: 0.74, 0.33, 0.13
Notice that the USED column fluctuates both up and down. Other
machines are able to reproduce negative USED counts.
As you can see in the patch I have added a mutex around the zone
operations in order to see if that solved the issue, and it doesn't
seem to make any difference at all.
I am unable to tell if it is just the UMA zone statistics which
are f**ked up, or if the important data structures in UMA are
also victims of this. The machines which Lukas and Bosko work
on seem to die after some short period of time, and this could
indicate that this is not just statistics being b0rked.
We see this problem also on GCC 3.2.2 machines.
HELP!
Poul-Henning
Index: geom_io.c
===
RCS file: /home/ncvs/src/sys/geom/geom_io.c,v
retrieving revision 1.44
diff -u -r1.44 geom_io.c
--- geom_io.c 18 Jun 2003 10:33:09 - 1.44
+++ geom_io.c 29 Jul 2003 20:51:55 -
@@ -39,6 +39,7 @@
#include sys/param.h
#include sys/systm.h
#include sys/kernel.h
+#include sys/sysctl.h
#include sys/malloc.h
#include sys/bio.h
@@ -55,6 +56,12 @@
static u_int pace;
static uma_zone_t biozone;
+struct mtx gbiomutex;
+static int ngbio;
+SYSCTL_INT(_debug, OID_AUTO, ngbio, CTLFLAG_RD,
+ngbio, 0, );
+
+
#include machine/atomic.h
static void
@@ -116,15 +123,26 @@
{
struct bio *bp;
+ mtx_lock(gbiomutex);
bp = uma_zalloc(biozone, M_NOWAIT | M_ZERO);
+ mtx_unlock(gbiomutex);
+ if (bp != NULL)
+ atomic_add_int(ngbio, 1);
return (bp);
}
void
g_destroy_bio(struct bio *bp)
{
-
+ if (bp == NULL) {
+ printf(g_destroy_bio(NULL));
+ Debugger(foo);
+ return;
+ }
+ mtx_lock(gbiomutex);
uma_zfree(biozone, bp);
+ mtx_unlock(gbiomutex);
+ atomic_add_int(ngbio, -1);
}
struct bio *
@@ -132,8 +150,11 @@
{
struct bio *bp2;
+ mtx_lock(gbiomutex);
bp2 = uma_zalloc(biozone, M_NOWAIT | M_ZERO);
+ mtx_unlock(gbiomutex);
if (bp2 != NULL) {
+ atomic_add_int(ngbio, 1);
bp2-bio_parent = bp;
bp2-bio_cmd = bp-bio_cmd;
bp2-bio_length = bp-bio_length;
@@ -304,6 +325,7 @@
bzero(mymutex, sizeof mymutex);
mtx_init(mymutex, g_xdown, MTX_DEF, 0);
+ mtx_init(gbiomutex, gbio, MTX_DEF, 0);
for(;;) {
g_bioq_lock(g_bio_run_down);
--
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.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
On Tue, 29 Jul 2003, Daniel C. Sobral wrote: You could add kevents for interface arrival and departure, and add a kqueue to the dhcpd to catch the arrival/departure events, and then just act on them. Instead of just adding the stuff to devd? Currently, devd is in the business of dealing with attachment and removal from the hardware management subsystem. Network subsystem events, such as interface has arrived are semantically different, but close enough in many cases. In the past, routing sockets have been the means by which topology-relevant changes are announced to the user processes. More recently, kqueue has permitted monitoring of a plethora of event types. I think there's a decent argument for a neteventd, perhaps integrated as a thread into devd, listening on network events rather than device attach/detach events. The only real problem is that it would be very nice if the DHCP client code were available in a library so it could be linked into a network event manager. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] jail NG schript patch for mounting devfs andprocfsautomatically
From: Mike Makonnen [EMAIL PROTECTED] On Tue, Jul 29, 2003 at 07:08:38PM +0200, Jens Rehsack wrote: Someone, and unfortunately I appear to have lost track of who, had some tweaks to the rcNG scripts to set up some reasonable devfs rules for a jail, and apply them to the devfs mounted in a jail. Otherwise, you risk exposing undesired device nodes to the virtual environment. I suspect a search of the -current archives will turn up who, but I think a necessary part of a solution here will be to make sure jails are set up with the right devfs contents. Sorry, overseen. Sct W. Hetzel was the submitter, but it never becomes committed. If could be be so kind, please :-) (of course, not without prove it first) Yeah, I'll take care of this. I had asked scott to mail me his final patch so I could commit it, but I never heard back from him. I'll dig out the revisions from my mail archives and combine the two. I thought I had submitted my final patch, the only thing left was what number to use for the default jail devfs rule. We also need a way to load user defined devfs rules. I'll need to re-cvs diff my current devfs and jail scripts, before I'll be able to send them again. Scot ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: UMA not reentrant / possible memory leak
In message [EMAIL PROTECTED], Poul-Henning Kamp writes: [I'm CC'ing current because this seems to have a significant negative impact on -current kernel stability, and we can use some more data, in particular on non-i386 SMP machines] I just committed a workaround for this problem, until JeffR can find time to hunt it down. People running 5.1 and possibly 5.0 on SMP kernels may want to apply this patch: Index: uma_core.c === RCS file: /home/ncvs/src/sys/vm/uma_core.c,v retrieving revision 1.63 retrieving revision 1.64 diff -u -r1.63 -r1.64 --- uma_core.c 28 Jul 2003 02:29:07 - 1.63 +++ uma_core.c 29 Jul 2003 22:07:10 - 1.64 @@ -197,6 +197,7 @@ bucketdisable = 1; else bucketdisable = 0; + bucketdisable = 1; } -- 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. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: -current 'make release' status? [SOLVED]
On Tue, 29 Jul 2003, Ruslan Ermilov wrote: On Wed, Jul 30, 2003 at 06:14:17AM +1000, Bruce Evans wrote: On Tue, 29 Jul 2003, Ruslan Ermilov wrote: ... Forget what I've said about NO_WERROR, it (unfortunately) only applies to the userland. Still, running make rerelease KERNEL_FLAGS=WERROR= gets the release done. I wondered why I get it, and similarly my nigthly buildkernel completed without errors. This turned out to be due to the -O vs. -Os differences. For example, compiling vfs_subr.o from the GENERIC kernel results in these same warnings when compiled with COPTFLAGS=-Os -pipe. Peter, should we switch -Werror back off in kern.pre.mk? Use -fno-strict-aliasing if you use -Os. Otherwise, -Os is stricter ^^ This was too complete :-). I meant -Wno-strict-aliasing when I wrote it (since I misread the info about -Os). than -O. On second thoughts, -Os implies -f-strict-aliasing because -Os may need strict aliasing for the same reasons as -O2. We've seen -O2 in combination with broken aliasing in libm cause fatal errors. Better find part of -O2 that needs strict aliasing and turn it off too. Hm, I always thought that -O2 and -Os are just useful aliases that in effect only turn a few dozens of -f optimization flags, and that switching some of them off later is allowed. I.e., -Os -fno-strict-aliasing should work. Yes, this seems to be the only option that needs warnings about strict aliasing. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] jail NG schript patch for mounting devfs andprocfsautomatically
Below is my current patch to devfs and jail to support the mounting of devfs
and procfs in jails. This patch also allows a jail to specify what devfs
rule to apply to the jail. As well as defining a default jail devfs rule
in /etc/rc.d/devfs.
Scot
Index: etc/defaults/rc.conf
===
RCS file: /home/ncvs/src/etc/defaults/rc.conf,v
retrieving revision 1.182
diff -u -r1.182 rc.conf
--- etc/defaults/rc.conf28 Jul 2003 13:09:00 - 1.182
+++ etc/defaults/rc.conf29 Jul 2003 22:06:08 -
@@ -426,12 +426,35 @@
harvest_ethernet=YES # Entropy device harvests ethernet randomness
harvest_p_to_p=YES # Entropy device harvests point-to-point randomness
dmesg_enable=YES # Save dmesg(8) to /var/run/dmesg.boot
-jail_enable=NO # Set to NO to disable starting of any jails
-jail_list= # Space separated list of names of jails
-jail_set_hostname_allow=YES # Allow root user in a jail to change its hostname
-jail_socket_unixiproute_only=YES # Route only TCP/IP within a jail
-jail_sysvipc_allow=NO # Allow SystemV IPC use from within a jail
watchdogd_enable=NO # Start the software watchdog daemon
+
+##
+### Jail Configuration ###
+##
+devfs_jail_ruleset_enable=NO # Enable Standard Jail devfs ruleset in
rc.d/devfs
+devfs_jail_ruleset_num=666 # Standard Jail ruleset number
+ # (change if it conflicts with your rulesets)
+
+jail_enable=NO # Set to NO to disable starting of any jails
+jail_list= # Space separated list of names of jails
+jail_set_hostname_allow=YES # Allow root user in a jail to change its
hostname
+jail_socket_unixiproute_only=YES # Route only TCP/IP within a jail
+jail_sysvipc_allow=NO# Allow SystemV IPC use from within a
jail
+jail_default_ruleset=666 # Default jail devfs ruleset to apply
+jail_stop_jailer=NO # Only stop jailer. Requires jail_*_exec be set
+ # to use sysutils/jailer port to start the
jail.
+
+# create an entry for each jail named in jail_list, with these variables
+#
+#jail_example_rootdir=/usr/jail/default # Jails root directory
+#jail_example_hostname=default.domain.com# Jails hostname
+#jail_example_ip=192.168.0.10# Jails IP number
+#jail_example_exec=/bin/sh /etc/rc # command to execute in jail
+#jail_example_devfs=NO # mount devfs in jail
+#jail_example_devfs_ruleset=666 # devfs ruleset to apply to jail
+#jail_example_procfs=NO # mount procfs in jail
+#
+# NOTE: replace 'example' with the jail's name from jail_list
##
### Define source_rc_confs, the mechanism used by /etc/rc.* ##
Index: etc/rc.d/devfs
===
RCS file: /home/ncvs/src/etc/rc.d/devfs,v
retrieving revision 1.5
diff -u -r1.5 devfs
--- etc/rc.d/devfs 6 May 2003 01:10:33 - 1.5
+++ etc/rc.d/devfs 6 May 2003 16:24:39 -
@@ -39,3 +39,21 @@
load_rc_config $name
run_rc_command $1
+
+# Standard Jail ruleset
+if checkyesno devfs_jail_ruleset_enable ; then
+ /sbin/devfs rule -s ${devfs_jail_ruleset_num} delset
+ /sbin/devfs rule -s ${devfs_jail_ruleset_num} add 100 hide
+ /sbin/devfs rule -s ${devfs_jail_ruleset_num} add 200 path ptyp* unhide
+ /sbin/devfs rule -s ${devfs_jail_ruleset_num} add 300 path ttyp* unhide
+ /sbin/devfs rule -s ${devfs_jail_ruleset_num} add 400 path null unhide
+ /sbin/devfs rule -s ${devfs_jail_ruleset_num} add 500 path zero unhide
+ /sbin/devfs rule -s ${devfs_jail_ruleset_num} add 600 path random unhide
+ /sbin/devfs rule -s ${devfs_jail_ruleset_num} add 610 path urandom unhide
+ /sbin/devfs rule -s ${devfs_jail_ruleset_num} add 700 path fd unhide
+ /sbin/devfs rule -s ${devfs_jail_ruleset_num} add 800 path fd/* unhide
+ /sbin/devfs rule -s ${devfs_jail_ruleset_num} add 810 path mdctl unhide
+ /sbin/devfs rule -s ${devfs_jail_ruleset_num} add 900 path stdin unhide
+ /sbin/devfs rule -s ${devfs_jail_ruleset_num} add 910 path stdout unhide
+ /sbin/devfs rule -s ${devfs_jail_ruleset_num} add 920 path stderr unhide
+fi
Index: etc/rc.d/jail
===
RCS file: /home/ncvs/src/etc/rc.d/jail,v
retrieving revision 1.4
diff -u -r1.4 jail
--- etc/rc.d/jail 5 May 2003 15:38:41 - 1.4
+++ etc/rc.d/jail 21 Jun 2003 20:22:44 -
@@ -6,7 +6,7 @@
# PROVIDE: jail
# REQUIRE: LOGIN
# BEFORE: securelevel
-# KEYWORD: FreeBSD
+#
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
Hi Folks, I had a closer loom at the OMAPI stuff in dhclient. Just to say, I'm very disappointed. The only objects that exist are: control and interface. The later is not inplemented at all. It pretends to work, but if you look at the source there are stubs only :P. control does only release leases and exit (state 2), I never managed to make dhclient sleep (state 3) and wake up (state 2). It seems that the whole implementation is only a proof of concept and not very functional at all, at least for the client side, dhcpd may be different. I'll think about how we can solve this differently. This really sucks ! Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: UMA not reentrant / possible memory leak
On Wed, Jul 30, 2003 at 12:09:18AM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Poul-Henning Kamp writes: [I'm CC'ing current because this seems to have a significant negative impact on -current kernel stability, and we can use some more data, in particular on non-i386 SMP machines] I just committed a workaround for this problem, until JeffR can find time to hunt it down. People running 5.1 and possibly 5.0 on SMP kernels may want to apply this patch: Thank you so much for doing this. I was going to do this myself but had to leave the office. Hopefully Jeff will have a chance to take a look at it otherwise I`ll be glancing at it tomorrow. Also, it would be nice if those suffering from recent problems with kmem_map exhaustion on 5.1 try this and note whether or not it gets rid of your panics. 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: STEP 2, fixing dhclient behaviour with multiple interfaces
On Wed, 30 Jul 2003, Martin Blapp wrote: control does only release leases and exit (state 2), I never managed to make dhclient sleep (state 3) and wake up (state 2). Odd: %%% # cat /etc/sleep_dhclient #!/bin/sh omshell /dev/null EOF connect new control open set state = 3 update close EOF # cat /etc/wakeup_dhclient #!/bin/sh omshell /dev/null EOF connect new control open set state = 4 update close EOF %%% This was working fine for me a few months ago. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: UMA not reentrant / possible memory leak
The indication of this is that the g_bio zone does not return to
zero USED as it should.
It looks like z-uz_cachefree is slightly out of date (updated in
zone_timout() every 20th second) and often too low (not taking the
z-uz_full_bucket list into account).
The enclosed patch recalculates the number of free elements on the
buckets instead of using z-uz_cachefree.
- Tor Egge
Index: sys/vm/uma_core.c
===
RCS file: /home/ncvs/src/sys/vm/uma_core.c,v
retrieving revision 1.63
diff -u -r1.63 uma_core.c
--- sys/vm/uma_core.c 28 Jul 2003 02:29:07 - 1.63
+++ sys/vm/uma_core.c 30 Jul 2003 01:05:37 -
@@ -2092,6 +2092,10 @@
char *tmpbuf, *offset;
uma_zone_t z;
char *p;
+ int cpu;
+ int cachefree;
+ uma_bucket_t bucket;
+ uma_cache_t cache;
cnt = 0;
mtx_lock(uma_mtx);
@@ -2112,8 +2116,27 @@
LIST_FOREACH(z, uma_zones, uz_link) {
if (cnt == 0) /* list may have changed size */
break;
+ for (cpu = 0; cpu maxcpu; cpu++) {
+ if (CPU_ABSENT(cpu))
+ continue;
+ CPU_LOCK(cpu);
+ }
ZONE_LOCK(z);
- totalfree = z-uz_free + z-uz_cachefree;
+ cachefree = 0;
+ for (cpu = 0; cpu maxcpu; cpu++) {
+ if (CPU_ABSENT(cpu))
+ continue;
+ cache = z-uz_cpu[cpu];
+ if (cache-uc_allocbucket != NULL)
+ cachefree += cache-uc_allocbucket-ub_ptr + 1;
+ if (cache-uc_freebucket != NULL)
+ cachefree += cache-uc_freebucket-ub_ptr + 1;
+ CPU_UNLOCK(cpu);
+ }
+ LIST_FOREACH(bucket, z-uz_full_bucket, ub_link) {
+ cachefree += bucket-ub_ptr + 1;
+ }
+ totalfree = z-uz_free + cachefree;
len = snprintf(offset, linesize,
%-12.12s %6.6u, %8.8u, %6.6u, %6.6u, %8.8llu\n,
z-uz_name, z-uz_size,
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: UMA not reentrant / possible memory leak
On Wed, Jul 30, 2003 at 01:23:21AM +, [EMAIL PROTECTED] wrote: The indication of this is that the g_bio zone does not return to zero USED as it should. It looks like z-uz_cachefree is slightly out of date (updated in zone_timout() every 20th second) and often too low (not taking the z-uz_full_bucket list into account). The enclosed patch recalculates the number of free elements on the buckets instead of using z-uz_cachefree. - Tor Egge We took this into account when we did the comparison. We know that uz_cachefree is only a snapshot count; but Poul-Henning`s patch clearly illustrates a frequent fluctuation in the free zone value but where the actual number of allocated g_bio zone elements stays stable at 0, for example. The fact that the problem is solved when buckets are disabled also is indicative that there is a clear reentrancy problems somewhere. There may also be some bucket leakage (although I have not yet confirmed this) as well. -- 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: HEADSUP: UMA not reentrant / possible memory leak
On Wed, 30 Jul 2003 [EMAIL PROTECTED] wrote: The indication of this is that the g_bio zone does not return to zero USED as it should. It looks like z-uz_cachefree is slightly out of date (updated in zone_timout() every 20th second) and often too low (not taking the z-uz_full_bucket list into account). The enclosed patch recalculates the number of free elements on the buckets instead of using z-uz_cachefree. I definitely like this patch. If it works would you please commit it? There are other issues for sure though. UMA can leak pages from zones when they are destroyed. I'm going to look into this asap. Cheers, Jeff ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
In message: [EMAIL PROTECTED] Robert Watson [EMAIL PROTECTED] writes: : : On Tue, 29 Jul 2003, Daniel C. Sobral wrote: : : You could add kevents for interface arrival and departure, and : add a kqueue to the dhcpd to catch the arrival/departure events, : and then just act on them. : : Instead of just adding the stuff to devd? : : Currently, devd is in the business of dealing with attachment and removal : from the hardware management subsystem. currently, that's true. : Network subsystem events, such as : interface has arrived are semantically different, but close enough in : many cases. I've been pondering making devd grok such events, as well as other power events. Eg, it will be a place that acpi could route acpi events to replace apm. : In the past, routing sockets have been the means by which : topology-relevant changes are announced to the user processes. More : recently, kqueue has permitted monitoring of a plethora of event types. I : think there's a decent argument for a neteventd, perhaps integrated as a : thread into devd, listening on network events rather than device : attach/detach events. I think that would be a good idea Don't know if there's a 'thread' or a virtual thread-like thing. : The only real problem is that it would be very nice : if the DHCP client code were available in a library so it could be linked : into a network event manager. It would make things a lot easier. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
In message: [EMAIL PROTECTED] Martin Blapp [EMAIL PROTECTED] writes: : : Hi Folks, : : I had a closer loom at the OMAPI stuff in dhclient. : : Just to say, I'm very disappointed. The only objects that exist are: : control and interface. The later is not inplemented at all. : It pretends to work, but if you look at the source there are : stubs only :P. : : control does only release leases and exit (state 2), I never managed to make : dhclient sleep (state 3) and wake up (state 2). : : It seems that the whole implementation is only a proof of concept : and not very functional at all, at least for the client side, dhcpd : may be different. : : I'll think about how we can solve this differently. This : really sucks ! That's why I start/kill dhclient from pccard_ether. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on alpha/alpha
TB --- 2003-07-30 04:00:05 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-07-30 04:00:05 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-30 04:02:05 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-07-30 05:08:02 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Wed Jul 30 05:08:02 GMT 2003 Kernel build for GENERIC completed on Wed Jul 30 05:20:02 GMT 2003 TB --- 2003-07-30 05:20:02 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- /usr/bin/make -B LINT TB --- 2003-07-30 05:20:02 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Jul 30 05:20:02 GMT 2003 [...] cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/advansys/adwlib.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/advansys/adwmcode.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/aha/aha.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
Daniel C. Sobral wrote: Terry Lambert wrote: You could add kevents for interface arrival and departure, and add a kqueue to the dhcpd to catch the arrival/departure events, and then just act on them. Instead of just adding the stuff to devd? The entire dhcpd code? Isn't that what dhcpd is for? Is devd a kitchen sink program? -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: STEP 2, fixing dhclient behaviour with multiple interfaces
Robert Watson wrote: On Tue, 29 Jul 2003, Daniel C. Sobral wrote: You could add kevents for interface arrival and departure, and add a kqueue to the dhcpd to catch the arrival/departure events, and then just act on them. Instead of just adding the stuff to devd? Currently, devd is in the business of dealing with attachment and removal from the hardware management subsystem. Network subsystem events, such as interface has arrived are semantically different, but close enough in many cases. In the past, routing sockets have been the means by which topology-relevant changes are announced to the user processes. More recently, kqueue has permitted monitoring of a plethora of event types. I think there's a decent argument for a neteventd, perhaps integrated as a thread into devd, listening on network events rather than device attach/detach events. The only real problem is that it would be very nice if the DHCP client code were available in a library so it could be linked into a network event manager. This is part of the problem. The other parts are that this is really networking code, and should be a separate thing, if possible, and, as Martin just pointed out, the OMAPI stuff is not really cooked yet. It's really a lot easier the process a small list of events in dhacpd as a result of a kqueue or kqueue/select combo, if you want to avoid rewriting as much code as humanly possible, and still be able to pull this feature out of the project. I still haven't been able to repeat your test; are you sure you are listening on a routing socket for the configuration change events? Maybe I'm doing something silly with my dumb little test program that you aren't doing with yours? I'm not seeing my Linksys my 3COM interfaces showing up and disappearing as kevents, but they are definitely still being seen by the laptop. Maybe it's my local hacks to make it work at all (it's an older Sony VAIO PCG-XG29). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
strange umass/scsi behaviour
Hi, Does anyone have an idea why the umass/scsi code behave differently between if you boot with a device already plugged in as opposed to plugging it in later? In my case it is a Sandisk Cruiser. If I plug it in before booting, it works just great, but if I plug it in later, it does not want to work. Below is the dmesg output of the various stages. # Here I have plugged it in after FreeBSD was already up and running. umass0: SanDisk Cruzer, rev 1.10/1.00, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: SanDisk Cruzer 2.00 Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present (da0:umass-sim0:0:0:0): Unretryable error Opened disk da0 - 6 (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (da0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (da0:umass-sim0:0:0:0): Retrying Command (per Sense Data) # Here I boot with it plugged in. FreeBSD 5.1-CURRENT #12: Tue Jul 29 09:59:56 SAST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/LAPTOP Preloaded elf kernel /boot/kernel/kernel at 0xc04e5000. Preloaded elf module /boot/kernel/snd_neomagic.ko at 0xc04e51f4. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc04e52a8. Preloaded elf module /boot/kernel/acpi.ko at 0xc04e5354. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 363961368 Hz CPU: Pentium II/Pentium II Xeon/Celeron (363.96-MHz 686-class CPU) Origin = GenuineIntel Id = 0x66a Stepping = 10 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 134135808 (127 MB) avail memory = 124919808 (119 MB) Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: DELL CPi A on motherboard pcibios: BIOS version 2.10 Using $PIR table, 5 entries at 0xc00fbda0 Timecounter ACPI-safe frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 acpi_acad0: AC adapter on acpi0 acpi_cmbat0: Control method Battery on acpi0 acpi_cmbat1: Control method Battery on acpi0 acpi_lid0: Control Method Lid Switch on acpi0 acpi_button0: Power Button on acpi0 acpi_button1: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: slot 7 INTD is routed to irq 11 agp0: Intel 82443BX (440 BX) host to PCI bridge mem 0xf400-0xf7ff at device 0.0 on pci0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib1: slot 0 INTA is routed to irq 11 pcib1: slot 0 INTB is routed to irq 5 pci1: display, VGA at device 0.0 (no driver attached) pcm0: NeoMagic 256AV mem 0xfda0-0xfdaf,0xf8c0-0xf8ff irq 5 at device 0.1 on pci1 pcm0: SigmaTel STAC9704 AC97 Codec cbb0: TI1225 PCI-CardBus Bridge at device 3.0 on pci0 cardbus0: CardBus bus on cbb0 pccard0: 16-bit PCCard bus on cbb0 pcib0: slot 3 INTA is routed to irq 11 cbb1: TI1225 PCI-CardBus Bridge at device 3.1 on pci0 cardbus1: CardBus bus on cbb1 pccard1: 16-bit PCCard bus on cbb1 pcib0: slot 3 INTA is routed to irq 11 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 UDMA33 controller port 0x860-0x86f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xece0-0xecff irq 11 at device 7.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered umass0: SanDisk Cruzer, rev 1.10/1.00, addr 2 pci0: bridge, PCI-unknown at device 7.3 (no driver attached) atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 orm0: Option ROMs at iomem 0xcf800-0xc,0xcf000-0xcf7ff,0xce800-0xcefff,0xce000-0xce7ff,0xc-0xcdfff on isa0 pmtimer0 on isa0 fdc0: Enhanced floppy controller (i82077, NE72065 or clone) at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold
