Mar 2003 - Sep 2003 FreeBSD Status Report
Navigation Bar March-September 2003 Status Report Introduction: The FreeBSD Bi-monthly status reports are back! In this edition, we catch up on seven highly productive months and look forward to the end of 2003. As always, the FreeBSD development crew has been hard at work. Support for the AMD64 platform quickly sprang up and is nearly complete. KSE has improved greatly since the 5.1 release and will soon become the default threading package in FreeBSD. Many other projects are in the works to improve performance, enhance the user experience, and expand FreeBSD into new areas. Take a look below at the impressive summary of work! Scott Long, Robert Watson * Bluetooth stack for FreeBSD (Netgraph implementation) * ACPI Status Report * AMD64 Porting * ATAPI/CAM Status Report * Binary security updates for FreeBSD * bsd.java.mk version 2.0 * Compile FreeBSD with Intels C compiler (icc) * Cryptographic Support * Device_t locking * Disk I/O * Dynamically Linked Root Support * FreeBSD Java Project * FreeBSD ports monitoring system * FreeBSD/ia64 * jpman project * KDE FreeBSD Project * kgi4BSD Status Report * KSE * Network Subsystem Locking and Performance * Porting OpenBSD's pf * PowerPC Port * Release Engineering Status * Rescue build infrastructure * uart(4) * VideoBSD * WifiBSD Status Report * Wireless Networking Support Bluetooth stack for FreeBSD (Netgraph implementation) URL: http://www.geocities.com/m_evmenkin/ URL: http://bluez.sf.net URL: http://sourceforge.net/projects/openobex/ Contact: Maksim Yevmenkin [EMAIL PROTECTED] I'm very pleased to announce that another release is available for download at http://www.geocities.com/m_evmenkin/ngbt-fbsd-20030908.tar.gz. I have also prepared patch for the FreeBSD source tree. The patch was submitted for review to the committers. Fixed few bugs in kernel modules. The ng_hci(4) and ng_l2cap(4) modules were changed to fix issue with Netgraph timeouts. The ng_ubt(4) module was changed to fix compilation issue on -current. Improved user-space utilities. Implemented new libsdp(3). Added new sdpcontrol(8) utility. The rfcomm_sppd(1), rfcomm_pppd(8) and obexapp(1) were changed and now can obtain RFCOMM channel via SDP from the server. The hccontorol(8) utility now has four new commands. The hcsecd(8) daemon now saves link keys on the disk. I've been recently contacted by few individuals who whould like to port current FreeBSD Bluetooth code to other BSD systems (OpenBSD and NetBSD). The work is slowly progressing towards un-Netgraph'ing current code. In the mean time Netgraph version will be the primary supported version of the code. _ ACPI Status Report URL: http://www.root.org/~nate/freebsd/ Contact: Nate Lawson [EMAIL PROTECTED] Work is continuing on updating ACPI with new features as well as bugfixing. A new embedded controller driver was written in July with support for the ACPI 2.0 ECDT as well as more robust polling support. Also, a buffer overflow in the ACPICA resource list handling that caused panics for some users was fixed. Marcel helped get acpidump(8) tested and basically working on ia64. Upcoming work includes integrating ACPI notifies with devd(8), committing user-submitted drivers for ASUS and Toshiba hotkeys, Cx processor sleep states (so my laptop doesn't burn my lap), and power resource support for intelligently powering down unused or idle devices. Users who have problems with ACPI are encouraged to submit a PR and email its number to [EMAIL PROTECTED] Bug reports of panics or crashes have first priority and non-working features or missing devices (except suspend/resume problems) second. Reports of failed suspend/resume should NOT be submitted as PRs at this time due to most of them being a result of incomplete device support that is being addressed. However, feel free to mail them to the list as any information is helpful. _ AMD64 Porting Contact: Peter Wemm [EMAIL PROTECTED] The last known bug that prevented AMD64 machines completing a full release has been fixed - one single character error that caused ghostscript to crash during rendering diagrams. SMP work is nearing completion and should be committed within the next few days. The SMP code uses the ACPI MADT table based on John Baldwin's work-in-progress there for i386. We need to spend some time on low level optimization because there are several suboptimal places that have been ignored for simplicity, context switching in particular. MTRR support has been committed and XFree86 can
Re: Can not remove directory
Hello! I know about -r and -f options. They don't help. Proc wrote: man rm Note -r and -f. Boris Kovalenko wrote: Hello! Can not remove directory /usr/obj/usr/src/gnu/usr.bin/cc/cc1 rm: /usr/obj/usr/src/gnu/usr.bin/cc/cc1: Directory not empty bash-2.05b# pwd; ls -la /usr/obj/usr/src/gnu/usr.bin/cc/cc1 total 4 drwxr-xr-x 2 root wheel 512 Oct 9 08:54 . drwxr-xr-x 13 root wheel 512 Oct 9 08:54 .. bash-2.05b# pwd; ls -la /usr/obj/usr/src/gnu/usr.bin/cc total 26 drwxr-xr-x 13 root wheel 512 Oct 9 08:54 . drwxr-xr-x 21 root wheel 512 Oct 9 11:23 .. drwxr-xr-x 2 root wheel 512 Oct 9 08:55 c++ drwxr-xr-x 2 root wheel 512 Oct 9 08:55 c++filt drwxr-xr-x 2 root wheel 512 Oct 9 08:54 cc1 drwxr-xr-x 2 root wheel 512 Oct 9 08:55 cc1obj drwxr-xr-x 2 root wheel 1024 Oct 9 08:55 cc1plus drwxr-xr-x 2 root wheel 512 Oct 9 08:55 cpp drwxr-xr-x 2 root wheel 512 Oct 9 08:55 cpp0 drwxr-xr-x 2 root wheel 512 Sep 26 10:34 doc drwxr-xr-x 2 root wheel 512 Oct 9 08:55 gcov drwxr-xr-x 2 root wheel 512 Oct 9 08:55 protoize drwxr-xr-x 2 root wheel 512 Oct 9 08:55 tradcpp0 What is wrong? Current system is 5.1-RELEASE-p8 Yours truly, Boris Kovalenko ___ [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: Can not remove directory
Hello! Seems You are right: BAD INODE NUMBER FOR '.' I=353381 OWNER=root MODE=40755 SIZE=512 MTIME=Oct 9 08:54 2003 DIR=/obj/usr/src/gnu/usr.bin/cc/cc1 UNEXPECTED SOFT UPDATE INCONSISTENCY FIX? no Will reboot and run fsck manually. Thanks for advance! Yours truly, Boris Kovalenko Dan Nelson wrote: In the last episode (Oct 09), Boris Kovalenko said: Can not remove directory /usr/obj/usr/src/gnu/usr.bin/cc/cc1 rm: /usr/obj/usr/src/gnu/usr.bin/cc/cc1: Directory not empty bash-2.05b# pwd; ls -la /usr/obj/usr/src/gnu/usr.bin/cc/cc1 total 4 drwxr-xr-x 2 root wheel 512 Oct 9 08:54 . drwxr-xr-x 13 root wheel 512 Oct 9 08:54 .. Interesting. Usually you get this after a crash, due to how softupdates buffers directory updates. The background fsck should have repaired the directory, though. If it isn't still running, try rebooting in single-user mode and run fsck -p on the filesystem. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipnat memory leak?
Several reasons: Having it in the kernel improves performance natd chokes on the latest windoze worms and I have implemented some DoS prevention/worm protection in ipnat but I'm seeing this memory leak without my improvements there at all. If it's in the kernel, ipnat is kept under control when natd would normally be sucking the CPU dry and preventing things like remote logins, very slugish updates, etc... and others I won't go into at the moment. vec - Original Message - From: marcos [EMAIL PROTECTED] To: Vector [EMAIL PROTECTED] Sent: Thursday, October 09, 2003 12:02 AM Subject: Re: ipnat memory leak? Why I want to do that?? natd work with IPFW and so much better than ipfilter - Original Message - From: Vector [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 09, 2003 5:51 PM Subject: ipnat memory leak? I was using ipfw and natd but I wanted to move nat into the kernel so I recompiled with ipfilter and ipnat. Now, after terminating natd, and setting up ipnat rules in /etc/ipnat.rules, I see memory increase at a rate of just under 1MB per minutes. Has anyone else seen a memory leak in ipnat or ipfilter? vec ___ [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: ipnat memory leak?
Several reasons: Having it in the kernel improves performance natd chokes on the latest windoze worms and I have implemented some DoS prevention/worm protection in ipnat but I'm seeing this memory leak without my improvements there at all. If it's in the kernel, ipnat is kept under control when natd would normally be sucking the CPU dry and preventing things like remote logins, very slugish updates, etc... and others I don't particularly want to go into at the moment. vec - Original Message - From: marcos [EMAIL PROTECTED] To: Vector [EMAIL PROTECTED] Sent: Thursday, October 09, 2003 12:02 AM Subject: Re: ipnat memory leak? Why I want to do that?? natd work with IPFW and so much better than ipfilter - Original Message - From: Vector [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 09, 2003 5:51 PM Subject: ipnat memory leak? I was using ipfw and natd but I wanted to move nat into the kernel so I recompiled with ipfilter and ipnat. Now, after terminating natd, and setting up ipnat rules in /etc/ipnat.rules, I see memory increase at a rate of just under 1MB per minutes. Has anyone else seen a memory leak in ipnat or ipfilter? vec ___ [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: Sched_Ule
I ran with SCHED_ULE for a couple days recently and had trouble beyond just sluggishness. When doing really intensive tasks such as buildworld or installworld, the computer would actually stall. The first time was immediately after booting single user after building the world and kernel. I started and installworld, and it hung there until I did a hard reset. Horrible timing for it, but such is life. Later (after I fixed the damage from the partial install) it hung when doing my buildworld, so I booted up on a different (SCHED_4BSD) kernel to do the buildworld (subsequently switching back to SCHED_4BSD). If you want any particulars about my system just let me know. -- Evan Dower Undergraduate, Computer Science University of Washington Public key: http://students.washington.edu/evantd/pgp-pub-key.txt Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D From: Scott Sipe [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Sched_Ule Date: Thu, 9 Oct 2003 00:28:59 -0400 (EDT) Hi, I see some posts from late Sept about people having issues with SCHED_ULE. I just wanted to add in that I am having the exact same problems. In short: Anything that seems disk intensive: bzip2 (unbzip2ing one big file makes this happen), making world, building ports, etc makes my X environment practically unusable. Mouse stutters, reaction times is very slow, feels 10x more sluggish than normal. (I'm running KDE if anyone is curious). I rebuilt my kernel today (running yesterday's world) with SCHED_4BSD instead, and things are much better. System is much much more responsive. If there's any tests I can run, or anyone I should talk to, I'd love to be of assistance, thanks much, Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] _ Instant message with integrated webcam using MSN Messenger 6.0. Try it now FREE! http://msnmessenger-download.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UDMA33 on older acer aladdin chips
It seems Daniel Rock wrote:
I recently decided to update my alpha UP1000 to today's current from a
mid-July build. However, UDMA33 did not work on a hard disk attached
to the built-in Acer Aladdin controller (verbose dmesg appended).
I think I have narrowed the problem down to this line of code:
atadev-channel-flags |= ATA_ATAPI_DMA_RO;
Removing this line gets my UDMA33 back.
If I understand the code correctly, the right fix should more look like:
diff -u -r1.18 ata-lowlevel.c
--- ata-lowlevel.c 7 Oct 2003 13:45:56 - 1.18
+++ ata-lowlevel.c 8 Oct 2003 22:38:15 -
@@ -73,7 +73,8 @@
request-device-channel-running = request;
/* disable ATAPI DMA writes if HW doesn't support it */
-if (request-flags (ATA_R_ATAPI | ATA_R_DMA | ATA_R_WRITE)
+if (((request-flags (ATA_R_ATAPI | ATA_R_DMA | ATA_R_WRITE)) ==
+ (ATA_R_ATAPI | ATA_R_DMA | ATA_R_WRITE))
request-device-channel-flags ATA_ATAPI_DMA_RO)
request-flags = ~ATA_R_DMA;
Yep, thats close, I have a patch out for testing that looks semilar,
if you can confirm it works, I'll commit it asap:
And yes pointy hat to me :)
Index: ata-lowlevel.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-lowlevel.c,v
retrieving revision 1.18
diff -u -r1.18 ata-lowlevel.c
--- ata-lowlevel.c 7 Oct 2003 13:45:56 - 1.18
+++ ata-lowlevel.c 9 Oct 2003 06:32:14 -
@@ -73,8 +73,9 @@
request-device-channel-running = request;
/* disable ATAPI DMA writes if HW doesn't support it */
-if (request-flags (ATA_R_ATAPI | ATA_R_DMA | ATA_R_WRITE)
- request-device-channel-flags ATA_ATAPI_DMA_RO)
+if ((request-device-channel-flags ATA_ATAPI_DMA_RO)
+ ((request-flags (ATA_R_ATAPI | ATA_R_DMA | ATA_R_WRITE)) ==
+(ATA_R_ATAPI | ATA_R_DMA | ATA_R_WRITE)))
request-flags = ~ATA_R_DMA;
switch (request-flags (ATA_R_ATAPI | ATA_R_DMA)) {
-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipnat memory leak?
On Wed, Oct 08, 2003 at 10:51:52PM -0600, Vector wrote: I was using ipfw and natd but I wanted to move nat into the kernel so I recompiled with ipfilter and ipnat. Now, after terminating natd, and setting up ipnat rules in /etc/ipnat.rules, I see memory increase at a rate of just under 1MB per minutes. Has anyone else seen a memory leak in ipnat or ipfilter? If at the same rate, the amount of nat entries is growing, there is no leak. Doesn't the amount of memory allocated, stabilize? Btw: you can see the amount of netries in the various tables with ipnat -s andthe stae table entries with ipfstat -s -Guido ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: vm_map_wire: lookup failed
Hi,
The latest development source of ntpd started to use setrlimit() before
using mlockall(). This combination proves fatal on -current. The code
in ntpd/ntpd.c looks like this:
###
#if defined(HAVE_MLOCKALL) defined(MCL_CURRENT) defined(MCL_FUTURE)
# ifdef HAVE_SETRLIMIT
/*
* Set the stack limit to something smaller, so that we don't lock a lot
* of unused stack memory.
*/
{
struct rlimit rl;
if (getrlimit(RLIMIT_STACK, rl) != -1
(rl.rlim_cur = 20 * 4096) rl.rlim_max)
{
if (setrlimit(RLIMIT_STACK, rl) == -1)
{
msyslog(LOG_ERR,
Cannot adjust stack limit for mlockall: %m);
}
}
}
# endif /* HAVE_SETRLIMIT */
/*
* lock the process into memory
*/
if (mlockall(MCL_CURRENT|MCL_FUTURE) 0)
msyslog(LOG_ERR, mlockall(): %m);
#else /* not (HAVE_MLOCKALL MCL_CURRENT MCL_FUTURE) */
###
The panic message is:
panic: vm_map_wire: lookup failed
and a backtrace looks like this:
##
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc047ff07 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc04801c8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc055a714 in vm_map_wire (map=0xc0e0c6e4, start=0, end=3216949248,
flags=3) at /usr/src/sys/vm/vm_map.c:1919
#4 0xc055d113 in mlockall (td=0x0, uap=0xc6361d14)
at /usr/src/sys/vm/vm_map.h:201
#5 0xc0591efb in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077936788, tf_esi = 2, tf_ebp =
-1077936904, tf_isp = -969532044, tf_ebx = -1077936944, tf_edx = 0, tf_ecx = 9, tf_eax
= 324, tf_trapno = 12, tf_err = 2, tf_eip = 673338079, tf_cs = 31, tf_eflags = 658,
tf_esp = -1077937108, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1006
#6 0xc0584c5d in Xint0x80_syscall () at {standard input}:144
---Can't read userspace from dump, or kernel process---
(kgdb)
##
John
--
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why is em nic generating interrupts?
Michael O. Boev wrote: I've got a [uniprocessor 5.1-RELEASE] router machine with fxp and em nics. I've built my kernel with the following included: options DEVICE_POLLING options HZ=2500 and enabled polling in /etc/sysctl.conf. [ ... ] What's happening? Is polling working in my case? If yes, why is vmstat showing interrupts? I see clearly, that fxp's counter doesn't increase, and em's is constantly growing. Is there anyone who knows for sure that em's polling works? You may want to ask Luigi; polling is his code. However, I believe the issue is that polling doesn't start until you take an interrupt, and it stops as soon as there is no more data to process, and waits for the next interrupt. If you were to jack your load way up, you would probably see an increase in interrupts, then them dropping off dramatically. If all else fails, read the source code... 8-). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Nvidia driver
On Wed, 2003-10-08 at 19:53, Andre Guibert de Bruet wrote: On Wed, 8 Oct 2003, Justin Smith wrote: If you hook up a serial console, are there any messages that get printed out? Unfortunately, I have no way of doing this on the machine that has the nvidia card. I think the random crashes are actually the result of running screen savers that use OpenGL. The random crashes always happen when I leave the machine alone for a while. When I come back to it, it has rebooted. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Nvidia driver
On Wed, 2003-10-08 at 21:46, Daniel O'Connor wrote: On Thursday 09 October 2003 01:41, Justin Smith wrote: Ahh! Here is a fragment of my loader.conf.. nvidia_load=YES machdep.disable_mtrrs=1 hw.nvidia.registry.ReqAGPRate=1 Although this fix alloes me to start up the nvidia driver, the machine still reboots when I run certain apps (openuniverse, for instance) and at random times otherwise. Since I need this, I'll have to retreat to stable for a while... Ahh, sounds exactly like the status of my wife's machine.. Openuniverse sounds.. opengl'ish.. I would suggest putting back the original X OGL libs so you don't accidentally blow your feet off :) Openuinivers does use OpenGL, but I can run the Cube game which also uses it. I didn't do much with cube, though --- I just started it up. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
11b/g PCMCIA
Hi, does it plan to support PCMCIA card Proxim Orinoco model 8471-WD in FreeBSD? There isn't in 'man ath' ... Tin INVEXOV CENOV LENSTV V DEXXU - superakn nalapan sestava DEXX Narsil 18a za neuvitelnch 18.990 K v. DPH! - procesor Athlon XP 2500+ BARTON, 19'' monitor, vypalovaka, DVD, ... - http://www.email.cz/dexx ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ATA broken as of yesterday?
A machine I had recompiled with a CVSUP as of yesterday (and again today, to no avail) can't mount root from a HPT370 (/dev/ar0s1a) RAID 1 array anymore, with the saved old kernel (two weeks or so I think) it boots without any trouble. Regards, Gabriel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Buildkernel with SCHED_ULE fails
Hi, Can someone tell me what is needed to play with the new scheduler these days? I seem to be completely unable to compile my kernel with it enabled, getting lots of undefined references to sched_*. Have I missed some critical information? /Eirik ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UDMA33 on older acer aladdin chips
Soren Schmidt writes: Yep, thats close, I have a patch out for testing that looks semilar, if you can confirm it works, I'll commit it asap: And yes pointy hat to me :) This fixes my box with the acer aladdin chip. Thanks! Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Why is em nic generating interrupts?
-Original Message- From: Terry Lambert [mailto:[EMAIL PROTECTED] Sent: Thursday, October 09, 2003 5:19 PM To: Michael O. Boev Cc: [EMAIL PROTECTED] Subject: Re: Why is em nic generating interrupts? Michael O. Boev wrote: I've got a [uniprocessor 5.1-RELEASE] router machine with fxp and em nics. I've built my kernel with the following included: options DEVICE_POLLING options HZ=2500 and enabled polling in /etc/sysctl.conf. [ ... ] What's happening? Is polling working in my case? If yes, why is vmstat showing interrupts? I see clearly, that fxp's counter doesn't increase, and em's is constantly growing. Is there anyone who knows for sure that em's polling works? You may want to ask Luigi; polling is his code. However, I believe the issue is that polling doesn't start until you take an interrupt, and it stops as soon as there is no more data to process, and waits for the next interrupt. If you were to jack your load way up, you would probably see an increase in interrupts, then them dropping off dramatically. To this dare I object, that there is traffic going through this machine, and fxp0 is NOT generating interrupts, while em IS. So, if the rule above works, they both have to behave in same ways. If all else fails, read the source code... 8-). )) I've tried to, but... had to ask here. So all is left is to ask Luigi and Intel. -- Terry -- Best wishes, [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sched_Ule
On Wednesday 08 October 2003 11:28 pm, Scott Sipe wrote: Anything that seems disk intensive: bzip2 (unbzip2ing one big file makes this happen), making world, building ports, etc makes my X environment practically unusable. Mouse stutters, reaction times is very slow, feels 10x more sluggish than normal. (I'm running KDE if anyone is curious). me tooI'm seeing the same thing running from -CURRENT that was built on Monday. I am using KDE+XFree86-4.3.0+nvidia (QT was compiled without OpenGL). I wouldn't consider X unusable, rather more of an annoyance, but that could just be me. I think it still performs a tad bit better than KDE on Cygwin, which is what I was doing before I was able to put FreeBSD on this machine. ;) /me too -- Jonathan Fosburgh AIX and Storage Administrator UT MD Anderson Cancer Center Houston, TX ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: pmap_enter: attempted pmap_enter on 4MB page
Hi, this panic just happened on a i386/SMP box with yesterday's current: %% Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #6: Thu Oct 9 13:34:31 CEST 2003 [EMAIL PROTECTED]:/freebsd/testing/obj/freebsd/testing/src/sys/TESTING Preloaded elf kernel /boot/kernel.testing/kernel at 0xc0721000. Preloaded elf module /boot/kernel.testing/acpi.ko at 0xc0721274. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(TM) MP 1600+ (1400.06-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 = 1073659904 (1023 MB) avail memory = 1037778944 (989 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040010, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040010, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS A7M266-D on motherboard pcibios: BIOS version 2.10 Using $PIR table, 9 entries at 0xc00f24a0 acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 IOAPIC #0 intpin 16 - irq 2 pci1: display, VGA at device 5.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: AMD 768 UDMA100 controller port 0xb800-0xb80f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] pci0: bridge, PCI-unknown at device 7.3 (no driver attached) pcib2: ACPI PCI-PCI bridge at device 16.0 on pci0 pci2: ACPI PCI bus on pcib2 IOAPIC #0 intpin 17 - irq 10 IOAPIC #0 intpin 19 - irq 11 pci2: multimedia, audio at device 4.0 (no driver attached) pci2: mass storage, SCSI at device 6.0 (no driver attached) fxp0: Intel 82558 Pro/100 Ethernet port 0xa000-0xa01f mem 0xec80-0xec8f,0xef00-0xef000fff irq 11 at device 8.0 on pci2 fxp0: Ethernet address 00:a0:c9:f0:05:22 miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ppc0 port 0x778-0x77f,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: Parallel port bus on ppc0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A, console sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 orm0: Option ROMs at iomem 0xcc000-0xc,0xc-0xcbfff on isa0 pmtimer0 on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x100 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 Timecounters tick every 10.000 msec acpi_cpu: throttling enabled, 2 steps (100% to 50.0%), currently 100.0% GEOM: create disk ad0 dp=0xc6537b70 ad0: 78533MB IC35L080AVVA07-0 [159560/16/63] at ata0-master UDMA100 SMP: AP CPU #1 Launched! Mounting root from ufs:/dev/ad0s4a panic: pmap_enter: attempted pmap_enter on 4MB page cpuid = 1; lapic.id = 0100 Debugger(panic) Stopped at Debugger+0x4e: xchgl %ebx,in_Debugger.0 db t Debugger(c05cb499,100,c05dc5d1,e3e4bbb0,100) at Debugger+0x4e panic(c05dc5d1,280ee000,c05d760c,bed,c1b3a0b8) at panic+0x151 pmap_enter(c73602a8,280ee000,c13d9108,7,0) at pmap_enter+0xae vm_fault(c73601f8,280ee000,1,0,c6859be0) at vm_fault+0x1174 trap_pfault(e3e4bd48,1,280ee014,3,280ee014) at trap_pfault+0xf6 trap(2f,2f,2f,3,0) at trap+0x1e4 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0x80ad0f2, esp = 0xbfbff370, ebp = 0xbfbff398 --- db panic panic: from debugger cpuid = 1; lapic.id = 0100 boot() called on cpu#1 Uptime: 21m6s Dumping 1023 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008 Dump complete Shutting down ACPI panic: absolutely cannot call smp_ipi_shootdown with interrupts already disabled cpuid = 1; lapic.id = 0100 boot() called on cpu#1 Uptime: 21m7s Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = 0100 fault virtual
SMBFS with EMC Celerra
Gordon, did you ever get a resolution for this? We have an EMC NS600 and are migrating macs to the Celerra. Jim Kunysz ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipnat memory leak?
Quoting Vector [EMAIL PROTECTED]: Several reasons: Having it in the kernel improves performance It also avoids at least 2 context switches per packet... one when the packet goes into natd and one when it goes back to the kernel. natd chokes on the latest windoze worms and I have implemented some DoS prevention/worm protection in ipnat but I'm seeing this memory leak without my improvements there at all. If it's in the kernel, ipnat is kept under control when natd would normally be sucking the CPU dry and preventing things like remote logins, very slugish updates, etc... and others I don't particularly want to go into at the moment. vec Not to mention the syntax for doing things like stateful firewalling is much more sane, and the fact that you can view the firewall state-table in near real-time using ipfstat -t (top style viewing). Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sched_Ule
On Thu, 9 Oct 2003, Evan Dower wrote: I ran with SCHED_ULE for a couple days recently and had trouble beyond just sluggishness. When doing really intensive tasks such as buildworld or installworld, the computer would actually stall. The first time was immediately after booting single user after building the world and kernel. I started and installworld, and it hung there until I did a hard reset. Horrible timing for it, but such is life. Later (after I fixed the damage from the partial install) it hung when doing my buildworld, so I booted up on a different (SCHED_4BSD) kernel to do the buildworld (subsequently switching back to SCHED_4BSD). If you want any particulars about my system just let me know. Do you have P4's with hyper threading? -- Evan Dower Undergraduate, Computer Science University of Washington Public key: http://students.washington.edu/evantd/pgp-pub-key.txt Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D From: Scott Sipe [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Sched_Ule Date: Thu, 9 Oct 2003 00:28:59 -0400 (EDT) Hi, I see some posts from late Sept about people having issues with SCHED_ULE. I just wanted to add in that I am having the exact same problems. In short: Anything that seems disk intensive: bzip2 (unbzip2ing one big file makes this happen), making world, building ports, etc makes my X environment practically unusable. Mouse stutters, reaction times is very slow, feels 10x more sluggish than normal. (I'm running KDE if anyone is curious). I rebuilt my kernel today (running yesterday's world) with SCHED_4BSD instead, and things are much better. System is much much more responsive. If there's any tests I can run, or anyone I should talk to, I'd love to be of assistance, thanks much, Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] _ Instant message with integrated webcam using MSN Messenger 6.0. Try it now FREE! http://msnmessenger-download.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: Why is em nic generating interrupts?
From: Terry Lambert [mailto:[EMAIL PROTECTED] Michael O. Boev wrote: I've got a [uniprocessor 5.1-RELEASE] router machine with fxp and em nics. I've built my kernel with the following included: options DEVICE_POLLING options HZ=2500 and enabled polling in /etc/sysctl.conf. [ ... ] What's happening? Is polling working in my case? If yes, why is vmstat showing interrupts? I see clearly, that fxp's counter doesn't increase, and em's is constantly growing. Is there anyone who knows for sure that em's polling works? You may want to ask Luigi; polling is his code. However, I believe the issue is that polling doesn't start until you take an interrupt, and it stops as soon as there is no more data to process, and waits for the next interrupt. If you were to jack your load way up, you would probably see an increase in interrupts, then them dropping off dramatically. If all else fails, read the source code... 8-). FWIW, this works for me with 4.7. As terry says, you do see a couple of initial interrupts, as below, and then they stop. $ vmstat -i interrupt total rate em0 irq16 4 0 em1 irq17 4 0 ahc0 irq18 5653 0 ahc1 irq19 15 0 em2 irq20 4 0 mux irq21 3 0 sio0 irq41583 0 sio1 irq3 1 0 clk irq0 14545633 2501 rtc irq8 744224128 Total15297124 2631 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cannot create partition entries for /dev/ad3
Daniel == Daniel O'Connor [EMAIL PROTECTED] writes: Daniel The only reason most people will ever touch /dev is to either Daniel make devices (hence no longer necessary with devfs), or change Daniel permissions. The later is more difficult with devfs, but IMHO Daniel the tradeoff is worthwhile. This brings me to my (small) beef with devfs. When you invoke an abstraction, a metric of the usefulness of that abstraction is how well the abstractions metaphors map onto the target system's metaphors. So as a filesystem, devfs does will by replicating the average person's view of should be in /dev ... subject to what devices are actually found... But filesystems also have persistence. In the trivial case, the persistence of the object (say ... a disk) preserved the filesystems node. But if I walk into /dev and change the permissions on a node, this persists only until the next reboot. Now... part of the problem here is that there is no simple interface for the kernel to access (and update) a file ... which might be an easy way to store persistence... but that's all a larger design problem. Now we do have the /etc/devfs.conf ... but this doesn't (yet) approach the topic of devices added and removed from the system. Maybe this is a natural extension for devd. Dave. Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cannot create partition entries for /dev/ad3
On Thu, 9 Oct 2003, David Gilbert wrote: DG Daniel == Daniel O'Connor [EMAIL PROTECTED] writes: DG DGDaniel The only reason most people will ever touch /dev is to either DGDaniel make devices (hence no longer necessary with devfs), or change DGDaniel permissions. The later is more difficult with devfs, but IMHO DGDaniel the tradeoff is worthwhile. DG DGThis brings me to my (small) beef with devfs. When you invoke an DGabstraction, a metric of the usefulness of that abstraction is how DGwell the abstractions metaphors map onto the target system's DGmetaphors. DG DGSo as a filesystem, devfs does will by replicating the average DGperson's view of should be in /dev ... subject to what devices are DGactually found... DG DGBut filesystems also have persistence. In the trivial case, the DGpersistence of the object (say ... a disk) preserved the filesystems DGnode. But if I walk into /dev and change the permissions on a node, DGthis persists only until the next reboot. Filesystems not necessarily have persistance. Although it would be fancy to be able to backup and restore /proc or /portal. Many devices (especially with all this hot-plugable stuff today) are not persistant, why should their representation be? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cannot create partition entries for /dev/ad3
In message [EMAIL PROTECTED], David Gilbert writes: But filesystems also have persistence. In the trivial case, the persistence of the object (say ... a disk) preserved the filesystems node. But if I walk into /dev and change the permissions on a node, this persists only until the next reboot. Rubbish! When did you last see your changes to /proc survive a reboot ? What you call a filesystem is really a name-resolution facility which translates what you think of as a filename into a particular kernel object. That kernel object can be a file on a persistent media, a file on a non-persistent media, a socket, a FIFO, a device, a process and almost any oddball thing you can can come up with. Persistence is a very optional property and it has nothing to do with the object living in the filesystem naming space. -- 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: Sched_Ule
Dual AMD Athlon MP 1900+s actually, on an Asus motherboard. -- Evan Dower Undergraduate, Computer Science University of Washington Public key: http://students.washington.edu/evantd/pgp-pub-key.txt Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D From: Jeff Roberson [EMAIL PROTECTED] To: Evan Dower [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Sched_Ule Date: Thu, 9 Oct 2003 10:33:39 -0400 (EDT) On Thu, 9 Oct 2003, Evan Dower wrote: I ran with SCHED_ULE for a couple days recently and had trouble beyond just sluggishness. When doing really intensive tasks such as buildworld or installworld, the computer would actually stall. The first time was immediately after booting single user after building the world and kernel. I started and installworld, and it hung there until I did a hard reset. Horrible timing for it, but such is life. Later (after I fixed the damage from the partial install) it hung when doing my buildworld, so I booted up on a different (SCHED_4BSD) kernel to do the buildworld (subsequently switching back to SCHED_4BSD). If you want any particulars about my system just let me know. Do you have P4's with hyper threading? -- Evan Dower Undergraduate, Computer Science University of Washington Public key: http://students.washington.edu/evantd/pgp-pub-key.txt Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D From: Scott Sipe [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Sched_Ule Date: Thu, 9 Oct 2003 00:28:59 -0400 (EDT) Hi, I see some posts from late Sept about people having issues with SCHED_ULE. I just wanted to add in that I am having the exact same problems. In short: Anything that seems disk intensive: bzip2 (unbzip2ing one big file makes this happen), making world, building ports, etc makes my X environment practically unusable. Mouse stutters, reaction times is very slow, feels 10x more sluggish than normal. (I'm running KDE if anyone is curious). I rebuilt my kernel today (running yesterday's world) with SCHED_4BSD instead, and things are much better. System is much much more responsive. If there's any tests I can run, or anyone I should talk to, I'd love to be of assistance, thanks much, Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] _ Instant message with integrated webcam using MSN Messenger 6.0. Try it now FREE! http://msnmessenger-download.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] _ Get MSN 8 Dial-up Internet Service FREE for one month. Limited time offer-- sign up now! http://join.msn.com/?page=dept/dialup ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
backup doesn't compare to primary bootblock
I`m getting that error when trying to run fsck_msdos on one of my partitions. This also make my system not-bootable(that is, i can boot, but i have to run fsck manually.) the part will mount, no problem there :/ Running FreeBSD 5.1-RELEASE-p10. -- Med vennlig hilsen / Best regards Christer Solskogen http://dtz.cjb.net - http://carebears.mine.nu Cheap, but not as cheap as your girlfriend! -Spider Jerusalem ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 11b/g PCMCIA
On Thu, 9 Oct 2003 [EMAIL PROTECTED] wrote: Hi, does it plan to support PCMCIA card Proxim Orinoco model 8471-WD in FreeBSD? If someone wants to work on it and can get specs, sure. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildkernel with SCHED_ULE fails
On Thu, 9 Oct 2003, Eirik Oeverby wrote: Hi, Can someone tell me what is needed to play with the new scheduler these days? I seem to be completely unable to compile my kernel with it enabled, getting lots of undefined references to sched_*. Replace SCHED_4BSD with SCHED_ULE in your kernel config, rebuild, and party on. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: backup doesn't compare to primary bootblock
On Thu, 9 Oct 2003, Christer Solskogen wrote: I`m getting that error when trying to run fsck_msdos on one of my partitions. This also make my system not-bootable(that is, i can boot, but i have to run fsck manually.) the part will mount, no problem there :/ Sounds like fsck_msdos has become fsck_ffs somehow. What happens if you run fsck_msdos manually? -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: backup doesn't compare to primary bootblock
On Thu, 9 Oct 2003, Christer Solskogen wrote: I`m getting that error when trying to run fsck_msdos on one of my partitions. This also make my system not-bootable(that is, i can boot, but i have to run fsck manually.) the part will mount, no problem there :/ Sounds like fsck_msdos has become fsck_ffs somehow. What happens if you run fsck_msdos manually? I run fsck_msdos manually ;-) -- Med vennlig hilsen / Best regards Christer Solskogen http://dtz.cjb.net - http://carebears.mine.nu Cheap, but not as cheap as your girlfriend! -Spider Jerusalem ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Nvidia driver
On Oct 09, Justin Smith wrote: On Wed, 2003-10-08 at 19:53, Andre Guibert de Bruet wrote: On Wed, 8 Oct 2003, Justin Smith wrote: If you hook up a serial console, are there any messages that get printed out? Unfortunately, I have no way of doing this on the machine that has the nvidia card. I think the random crashes are actually the result of running screen savers that use OpenGL. The random crashes always happen when I leave the machine alone for a while. When I come back to it, it has rebooted. I've also had bad experiences running xlock -mode random +fullrandom ...one of them didn't end up locking the screen, and left X in a semi-crashed state, but did not cause a reboot for me. There's a bunch of stuff in the nvidia-driver documentation about linux compat issues regarding multi-threading and openGL, IIRC. So it seems like the main reason to run the nvidia binary driver, openGL, is suspect. Which leaves us with seeing the nvidia splash-spam as our only reason for running it, along with driving external monitors on Dell D800's :) Mike ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: Sched_Ule
JR Do you have P4's with hyper threading? Why? Are there particular issues with HT and ULE? The normal scheduler doesn't seem to utilize the second virtual processor at all (as long as I trust in what top tells me). Any suggestions how to build a desktop system (i.e. with X, audio/video etc.) kernel for a P4 HT appreciated! -- Best regards, Maxmailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipnat memory leak?
At 12:56 AM -0600 2003/10/09, Vector wrote: natd chokes on the latest windoze worms and I have implemented some DoS prevention/worm protection in ipnat but I'm seeing this memory leak without my improvements there at all. If it's in the kernel, ipnat is kept under control when natd would normally be sucking the CPU dry and preventing things like remote logins, very slugish updates, etc... That seems to be very odd to me. If anything, putting it in the kernel should guarantee that it could runaway with as much memory, CPU, etc... as it wanted. Could you explain a bit more about the added controls you have over this process because it's part of the kernel, as opposed to operating in user space? This is a serious question -- I don't understand, and I'd like to learn. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA broken as of yesterday?
On Thu, 9 Oct 2003 14:36:12 +0200 Gabriel Ambuehl [EMAIL PROTECTED] wrote: A machine I had recompiled with a CVSUP as of yesterday (and again today, to no avail) can't mount root from a HPT370 (/dev/ar0s1a) RAID 1 array anymore, with the saved old kernel (two weeks or so I think) it boots without any trouble. I've got the same controller onboard and just cvsupped and rebuild world and kernel and everyting seems to be working fine. I don't have my root-partition on it and it's configured for striping instead of RAID 1. atapci1: HighPoint HPT370 UDMA100 controller port 0xcc00-0xccff,0xc800-0xc803,0xc400-0xc407,0xc000-0xc003,0xbc00-0xbc07 irq 9 at device 14.0 on pci0 -- Bruno The cow is nothing but a machine with makes grass fit for us people to eat. -- John McNulty ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ATA_IDENTITY soft error
Did a -CURRENT buildworld this AM, and restarted on the new kernel. On detecting ad0, it throws an error: ad0: 38166MB Maxtor 5T040H4 [77545/16/63] at ata0-master UDMA 100 ata1-master: WARNING - ATA_IDENTITY soft error (ECC corrected) What's this? Patrick ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_map_wire: lookup failed
On Thu, Oct 09, 2003 at 11:59:35AM +0200, John Hay wrote: The latest development source of ntpd started to use setrlimit() before using mlockall(). This combination proves fatal on -current. The code in ntpd/ntpd.c looks like this: [snip] I'll look into this. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ATAng errors on compaq proliant 330e
hi this verbosed dmesg is from my box maybe it help you have a nice day -- Archeologists near mount Sinai have discovered what is believed to be a missing page from the Bible. The page is currently being carbon dated in Bonn. If genuine it belongs at the beginning of the Bible and is believed to read To my darling Candy. All characters portrayed within this book are fictitous and any resemblance to persons living or dead is purely coincidental. The page has been universally condemned by church leaders. RED DWARF Series II Episode 2, Better Than Life - R 52D 0x15 3 4 5 7 10 11 14 15 slot 2 51A 0x10 3 4 5 7 10 11 14 15 slot 2 51B 0x11 3 4 5 7 10 11 14 15 slot 2 51C 0x12 3 4 5 7 10 11 14 15 slot 2 51D 0x12 3 4 5 7 10 11 14 15 slot 3 01A 0x16 3 4 5 7 10 11 14 15 slot 3 01B 0x17 3 4 5 7 10 11 14 15 slot 3 01C 0x18 3 4 5 7 10 11 14 15 slot 3 01D 0x19 3 4 5 7 10 11 14 15 slot 4 02A 0x1a 3 4 5 7 10 11 14 15 slot 4 02B 0x1b 3 4 5 7 10 11 14 15 slot 4 02C 0x1a 3 4 5 7 10 11 14 15 slot 4 02D 0x1b 3 4 5 7 10 11 14 15 slot 5 03A 0x1c 3 4 5 7 10 11 14 15 slot 5 03B 0x1d 3 4 5 7 10 11 14 15 slot 5 03C 0x1c 3 4 5 7 10 11 14 15 slot 5 03D 0x1d 3 4 5 7 10 11 14 15 slot 6 04A 0x1e 3 4 5 7 10 11 14 15 slot 6 04B 0x1f 3 4 5 7 10 11 14 15 slot 6 04C 0x1e 3 4 5 7 10 11 14 15 slot 6 04D 0x1f 3 4 5 7 10 11 14 15 AcpiOsDerivePciId: bus 0 dev 0 func 0 AcpiOsDerivePciId: bus 0 dev 0 func 1 unknown: I/O range not supported unknown: I/O range not supported unknown: I/O range not supported unknown: I/O range not supported unknown: I/O range not supported unknown: I/O range not supported unknown: I/O range not supported unknown: I/O range not supported unknown: I/O range not supported unknown: I/O range not supported unknown: I/O range not supported unknown: I/O range not supported unknown: I/O range not supported unknown: I/O range not supported unknown: I/O range not supported unknown: I/O range not supported unknown: I/O range not supported unknown: I/O range not supported unknown: I/O range not supported unknown: I/O range not supported unknown: I/O range not supported unknown: I/O range not supported unknown: I/O range not supported ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.IBRG.SMIC] in namespace, AE_NOT_FOUND SearchNode 0xc2d39a40 StartNode 0xc2d39a40 ReturnNode 0 ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.IBRG.KBD_._STA] (Node 0xc2d39a40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.IBRG.SMIC] in namespace, AE_NOT_FOUND SearchNode 0xc2d39980 StartNode 0xc2d39980 ReturnNode 0 ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.IBRG.PS2M._STA] (Node 0xc2d39980), AE_NOT_FOUND acpi_timer0: 32-bit timer at 3.579545MHz port 0xf808-0xf80b on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 initial configuration \\_SB_.LNK6 irq 10: [ 3 4 5 7 10 11 14 15] low,level,sharable 0.1.0 \\_SB_.LNK7 irq 11: [ 3 4 5 7 10 11 14 15] low,level,sharable 0.1.1 \\_SB_.LNK8 irq 5: [ 3 4 5 7 10 11 14 15] low,level,sharable 0.1.2 \\_SB_.LNK9 irq 5: [ 3 4 5 7 10 11 14 15] low,level,sharable 0.1.3 \\_SB_.LNKA irq 0: [ 3 4 5 7 10 11 14 15] low,level,sharable 0.2.0 \\_SB_.LNKB irq 0: [ 3 4 5 7 10 11 14 15] low,level,sharable 0.2.1 \\_SB_.LNKA irq 0: [ 3 4 5 7 10 11 14 15] low,level,sharable 0.2.2 \\_SB_.LNKB irq 0: [ 3 4 5 7 10 11 14 15] low,level,sharable 0.2.3 \\_SB_.LNKC irq 0: [ 3 4 5 7 10 11 14 15] low,level,sharable 0.3.0 \\_SB_.LNKD irq 0: [ 3 4 5 7 10 11 14 15] low,level,sharable 0.3.1 \\_SB_.LNKC irq 0: [ 3 4 5 7 10 11 14 15] low,level,sharable 0.3.2 \\_SB_.LNKD irq 0: [ 3 4 5 7 10 11 14 15] low,level,sharable 0.3.3 \\_SB_.LNKE irq 11: [ 3 4 5 7 10 11 14 15] low,level,sharable 0.4.0 \\_SB_.LNKF irq 0: [ 3 4 5 7 10 11 14 15] low,level,sharable 0.4.1 \\_SB_.LNKE irq 11: [ 3 4 5 7 10 11 14 15] low,level,sharable 0.4.2 \\_SB_.LNKF irq 0: [ 3 4 5 7 10 11 14 15] low,level,sharable 0.4.3 \\_SB_.LNKG irq 5: [ 3 4 5 7 10 11 14 15] low,level,sharable 0.15.0 before setting priority for links \\_SB_.LNKA: interrupts: 3 4 5 710111415 penalty: 2100 2100 1400 2100 1200 1400 11100 11100 references: 2 priority: 0 \\_SB_.LNKB: interrupts: 3 4 5 710111415 penalty: 2100 2100 1400 2100 1200 1400 11100 11100 references: 2 priority: 0 \\_SB_.LNKC: interrupts: 3 4 5 710111415
Re: ATAng errors on compaq proliant 330e
It seems Radko Keves wrote: hi this verbosed dmesg is from my box maybe it help you Uhm, and what exactly is the problem ? -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
failed -current build
Today I attempted to build the latest -current but got the following when trying to compile the kernel: ../../../dev/cardbus/cardbus.c:380: error: `card_cis_read_desc' undeclared here (not in a function) ../../../dev/cardbus/cardbus.c:380: error: initializer element is not constant ../../../dev/cardbus/cardbus.c:380: error: (near initialization for `cardbus_methods[27].desc') ../../../dev/cardbus/cardbus.c:380: error: initializer element is not constant ../../../dev/cardbus/cardbus.c:380: error: (near initialization for `cardbus_methods[27]') ../../../dev/cardbus/cardbus.c:381: error: `card_cis_free_desc' undeclared here (not in a function) ../../../dev/cardbus/cardbus.c:381: error: initializer element is not constant ../../../dev/cardbus/cardbus.c:381: error: (near initialization for `cardbus_methods[28].desc') ../../../dev/cardbus/cardbus.c:381: error: initializer element is not constant ../../../dev/cardbus/cardbus.c:381: error: (near initialization for `cardbus_methods[28]') ../../../dev/cardbus/cardbus.c:384: error: initializer element is not constant ../../../dev/cardbus/cardbus.c:384: error: (near initialization for `cardbus_methods[29]') ../../../dev/cardbus/cardbus.c:385: error: initializer element is not constant ../../../dev/cardbus/cardbus.c:385: error: (near initialization for `cardbus_methods[30]') ../../../dev/cardbus/cardbus.c:386: error: initializer element is not constant ../../../dev/cardbus/cardbus.c:386: error: (near initialization for `cardbus_methods[31]') ../../../dev/cardbus/cardbus.c:387: error: initializer element is not constant ../../../dev/cardbus/cardbus.c:387: error: (near initialization for `cardbus_methods[32]') and several more of those errors. I found old posts stating this a gcc bug so I did a make buildworld make installworld before trying to compile my kernel but to no avail. -James ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sched_Ule
On (2003/10/09 00:28), Scott Sipe wrote: Anything that seems disk intensive: bzip2 (unbzip2ing one big file makes this happen), making world, building ports, etc makes my X environment practically unusable. Mouse stutters, reaction times is very slow, feels 10x more sluggish than normal. (I'm running KDE if anyone is curious). A number of us are seeing this problem, and not all of us are entry level end-users. I'm using a single PIII with 1GB of RAM and maxusers 0. No Hyper-threading, nothing interesting in the kernel (apart from I686_CPU only, KTRACE and _KPOSIX_PRIORITY_SCHEDULING). The problem (as I recall) is that Jeff hasn't received reports from people who can dig into the problem and have the time to do so. For example, I'm pretty sure I could at least point a finger at the problem if I had time. But I'm under heavy pressure, and so the only solution that's feasible for me is to just switch to SCHED_4BSD and keep moving. What surprises me is that Jeff can't reproduce it. For me, the sluggish mouse problem manifests under these conditions: 1) Use a USB mouse, not a PS2 mouse. 2) SCHED_ULE in the kernel. 3) make buildworld (no -j necessary, but -k exacerbates the problem). 4) Fiddle around in X (no particular window manager required). Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sched_Ule
On Thu, 9 Oct 2003, Sheldon Hearn wrote: On (2003/10/09 00:28), Scott Sipe wrote: Anything that seems disk intensive: bzip2 (unbzip2ing one big file makes this happen), making world, building ports, etc makes my X environment practically unusable. Mouse stutters, reaction times is very slow, feels 10x more sluggish than normal. (I'm running KDE if anyone is curious). A number of us are seeing this problem, and not all of us are entry level end-users. I'm using a single PIII with 1GB of RAM and maxusers 0. No Hyper-threading, nothing interesting in the kernel (apart from I686_CPU only, KTRACE and _KPOSIX_PRIORITY_SCHEDULING). The problem (as I recall) is that Jeff hasn't received reports from people who can dig into the problem and have the time to do so. For example, I'm pretty sure I could at least point a finger at the problem if I had time. But I'm under heavy pressure, and so the only solution that's feasible for me is to just switch to SCHED_4BSD and keep moving. What surprises me is that Jeff can't reproduce it. For me, the sluggish mouse problem manifests under these conditions: 1) Use a USB mouse, not a PS2 mouse. Is this _only_ with usb? 2) SCHED_ULE in the kernel. 3) make buildworld (no -j necessary, but -k exacerbates the problem). 4) Fiddle around in X (no particular window manager required). Ciao, Sheldon. ___ [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: Sched_Ule
On (2003/10/09 16:57), Jeff Roberson wrote: For me, the sluggish mouse problem manifests under these conditions: 1) Use a USB mouse, not a PS2 mouse. Is this _only_ with usb? For me, yes. -CURRENT gets a little sluggish with either scheduler, but the noticible difference between SCHED_4BSD and SCHED_ULE only strikes me with a USB mouse. YMMV. Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Problem building net-snmp on 5.1-release-p10
Hello I'm trying to build net-snmp but I get this build error: mv -f host/.libs/hr_system.lo host/hr_system.lo /bin/sh ../../libtool --mode=compile cc -I../../include -I../../include -I. -I../.. -I. -I./../.. -I./../../snmplib -I./.. -I.. -DINET6 -O -pipe -march=pentium3 -Dfreebsd5 -c -o host/hr_storage.lo host/hr_storage.c rm -f host/.libs/hr_storage.lo cc -I../../include -I../../include -I. -I../.. -I. -I./../.. -I./../../snmplib -I./.. -I.. -DINET6 -O -pipe -march=pentium3 -Dfreebsd5 -c host/hr_storage.c -fPIC -DPIC -o host/.libs/hr_storage.lo In file included from host/hr_storage.c:36: /usr/include/machine/types.h:50: redefinition of `vm_offset_t' /usr/include/sys/types.h:250: `vm_offset_t' previously declared here /usr/include/machine/types.h:51: redefinition of `vm_ooffset_t' /usr/include/sys/types.h:251: `vm_ooffset_t' previously declared here /usr/include/machine/types.h:55: redefinition of `vm_paddr_t' /usr/include/sys/types.h:252: `vm_paddr_t' previously declared here /usr/include/machine/types.h:57: conflicting types for `vm_pindex_t' /usr/include/sys/types.h:253: previous declaration of `vm_pindex_t' /usr/include/machine/types.h:58: redefinition of `vm_size_t' /usr/include/sys/types.h:254: `vm_size_t' previously declared here /usr/include/machine/types.h:60: redefinition of `register_t' /usr/include/sys/types.h:203: `register_t' previously declared here /usr/include/machine/types.h:61: redefinition of `u_register_t' /usr/include/sys/types.h:237: `u_register_t' previously declared here *** Error code 1 Stop in /usr/ports/net/net-snmp/work/net-snmp-5.0.9/agent/mibgroup. *** Error code 1 Stop in /usr/ports/net/net-snmp/work/net-snmp-5.0.9/agent. *** Error code 1 Stop in /usr/ports/net/net-snmp/work/net-snmp-5.0.9. *** Error code 1 Stop in /usr/ports/net/net-snmp. Does anyone know what I can do about this? /John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[releng_5_1 tinderbox] failure on alpha/alpha
TB --- mkdir /home/des/tinderbox/RELENG_5_1 TB --- mkdir /home/des/tinderbox/RELENG_5_1/alpha TB --- mkdir /home/des/tinderbox/RELENG_5_1/alpha/alpha ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on sparc64/sparc64
TB --- 2003-10-09 20:32:02 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-10-09 20:32:02 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-10-09 20:34:28 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-10-09 21:28:33 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Thu Oct 9 21:28:33 GMT 2003 [...] /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/trap.c: In function `syscall': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/trap.c:582: warning: implicit declaration of function `PTRACESTOP_SC' /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/trap.c:582: error: `S_PT_SCE' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/trap.c:582: error: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/trap.c:582: error: for each function it appears in.) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/trap.c:648: warning: redundant redeclaration of `PTRACESTOP_SC' in same scope /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/trap.c:582: warning: previous declaration of `PTRACESTOP_SC' /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/trap.c:648: error: `S_PT_SCX' undeclared (first use in this function) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-10-09 21:33:18 - /usr/bin/make returned exit code 1 TB --- 2003-10-09 21:33:18 - ERROR: failed to build generic kernel TB --- 2003-10-09 21:33:18 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[releng_5_1 tinderbox] failure on i386/pc98
TB --- mkdir /home/des/tinderbox/RELENG_5_1/i386/pc98 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[releng_5_1 tinderbox] failure on sparc64/sparc64
TB --- mkdir /home/des/tinderbox/RELENG_5_1/sparc64 TB --- mkdir /home/des/tinderbox/RELENG_5_1/sparc64/sparc64 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sched_Ule
On Thursday 09 October 2003 22:57, Jeff Roberson wrote: On Thu, 9 Oct 2003, Sheldon Hearn wrote: On (2003/10/09 00:28), Scott Sipe wrote: Anything that seems disk intensive: bzip2 (unbzip2ing one big file makes this happen), making world, building ports, etc makes my X environment practically unusable. Mouse stutters, reaction times is very slow, feels 10x more sluggish than normal. (I'm running KDE if anyone is curious). A number of us are seeing this problem, and not all of us are entry level end-users. I'm using a single PIII with 1GB of RAM and maxusers 0. No Hyper-threading, nothing interesting in the kernel (apart from I686_CPU only, KTRACE and _KPOSIX_PRIORITY_SCHEDULING). The problem (as I recall) is that Jeff hasn't received reports from people who can dig into the problem and have the time to do so. For example, I'm pretty sure I could at least point a finger at the problem if I had time. But I'm under heavy pressure, and so the only solution that's feasible for me is to just switch to SCHED_4BSD and keep moving. What surprises me is that Jeff can't reproduce it. For me, the sluggish mouse problem manifests under these conditions: 1) Use a USB mouse, not a PS2 mouse. Is this _only_ with usb? Hi Jeff, I have the same problem, but with a PS2 mouse. I've never tried an USB mouse on this system. I've seen this behavior on at least 4 systems now myself, fast and slow systems (my own workstation is an Athlon XP 2000+, 512MB RAM). It must be possible for you to reproduce this behavior. I've seen the lagging mouse on many occasions, always when my system was under high load. It's very difficult to pinpoint though; for example, if I'm building a port, I only notice the lagging for small periods of time during the build (sometimes I don't see it for 5 minutes, then suddenly it lags for about 3 seconds). Most of the time, it doesn't even bother me. One of the places it _always_ happens, is when I log out of GNOME 2.4. The background fades to a darker color, and during the fade, I experience the mouse lag. Can you reproduce this? Maybe you have some hints for me, some things I can try to find out more about this problem? Arjan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
include/xmmintrin.h
Hi, include/xmmintrin.h defines __v4si twice, once in line 45, and once again in line 1113 inside an __SSE2__ ifdef block. This causes errors when building ports that define __SSE2__. I locally fixed this by removing the second definition of __v4si. Not sure what the right solution is, because xmmintrin.h is contributed code from gcc. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Sched_Ule
On Thu, 9 Oct 2003, Jeff Roberson wrote: 1) Use a USB mouse, not a PS2 mouse. Is this _only_ with usb? Is moused running? That would give an extra scheduling complication.. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why is em nic generating interrupts?
On Thursday 09 October 2003 05:57 am, Michael O. Boev wrote: -Original Message- From: Terry Lambert [mailto:[EMAIL PROTECTED] Sent: Thursday, October 09, 2003 5:19 PM To: Michael O. Boev Cc: [EMAIL PROTECTED] Subject: Re: Why is em nic generating interrupts? Michael O. Boev wrote: I've got a [uniprocessor 5.1-RELEASE] router machine with fxp and em nics. I've built my kernel with the following included: options DEVICE_POLLING options HZ=2500 and enabled polling in /etc/sysctl.conf. [ ... ] What's happening? Is polling working in my case? If yes, why is vmstat showing interrupts? I see clearly, that fxp's counter doesn't increase, and em's is constantly growing. Is there anyone who knows for sure that em's polling works? You may want to ask Luigi; polling is his code. However, I believe the issue is that polling doesn't start until you take an interrupt, and it stops as soon as there is no more data to process, and waits for the next interrupt. If you were to jack your load way up, you would probably see an increase in interrupts, then them dropping off dramatically. To this dare I object, that there is traffic going through this machine, and fxp0 is NOT generating interrupts, while em IS. So, if the rule above works, they both have to behave in same ways. If all else fails, read the source code... 8-). )) I've tried to, but... had to ask here. So all is left is to ask Luigi and Intel. I cannot comment on 5.1-R, but I am running DEVICE_POLLING tests today with -current and 2 em NICS and systat -vm shows no interrupts for the IRQs where the NICs are. I can only guess that either 5.1-R has a bug or the polling support was not in the driver at that point. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: The GEOM class BDE already loaded
Hi, just got the following panic on my server. The panic occured while trying to attach a gbde encrypted disk. geom_bde is compiled into the kernel. Dump and debugging kernel are available for further debugging. Sources are from October 9th, around 2 PM CET. GNU gdb 5.3 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-portbld-freebsd5.1... panic: The GEOM class BDE already loaded panic messages: --- panic: The GEOM class BDE already loaded cpuid = 1; lapic.id = 0100 boot() called on cpu#1 syncing disks, buffers remaining... 1077 1077 1076 1076 1074 1074 1074 1073 1076 1073 1073 1073 1073 1073 107 3 1073 1073 1073 1073 1073 1073 1073 1073 1073 1073 1073 1073 1073 1073 giving up on 911 buffers Uptime: 1m17s Dumping 511 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 46 4 480 496 --- #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 240 dumping++; (kgdb) where #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 #1 0xc0512b90 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372 #2 0xc0512f96 in panic (fmt=0xc06ac0cf The GEOM class %s already loaded) at /usr/src/sys/kern/kern_shutdown.c:550 #3 0xc04ca466 in g_load_class (arg=0xc49014d0, flag=0) at /usr/src/sys/geom/geom_subr.c:91 #4 0xc04c7f48 in one_event () at /usr/src/sys/geom/geom_event.c:180 #5 0xc04c8035 in g_run_events () at /usr/src/sys/geom/geom_event.c:200 #6 0xc04c9085 in g_event_procbody () at /usr/src/sys/geom/geom_kern.c:134 #7 0xc04e9d8f in fork_exit (callout=0xc04c9040 g_event_procbody, arg=0x0, frame=0x0) at /usr/src/sys/kern/kern_fork.c:796 - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
Re: ipnat memory leak?
natd chokes on the latest windoze worms and I have implemented some DoS prevention/worm protection in ipnat but I'm seeing this memory leak without my improvements there at all. If it's in the kernel, ipnat is kept under control when natd would normally be sucking the CPU dry and preventing things like remote logins, very slugish updates, etc... That seems to be very odd to me. If anything, putting it in the kernel should guarantee that it could runaway with as much memory, CPU, etc... as it wanted. Could you explain a bit more about the added controls you have over this process because it's part of the kernel, as opposed to operating in user space? OK, fair enough, perhaps I mispoke. From a system and a control standpoint, you do technically have more control over a user land process. The biggest problem was that I was unable to view the nat table or even really see anything about what is going on in natd without shutting it down, killing everyone's connections, fireing it back up and having it spit everything out at the terminal/session. Now, doing this remotely with users using the system get's very very ugly. natd was spinning out of control and consequently making the system ultimately completely unresponsive. I did not know why and even with it's limited logging capabilities, was having a difficult time getting at what was going on. The biggest thing I was after was performance. I needed more pps throughput in the system than I was getting with natd. However, as soon as I put it in the kernel, ipnat -l and ipnat -t became my best friends. They are incredibly useful. I discovered there are users on our network infected with a variety of the latest MS worms (and possibly port scanning the internet) and consequently opening thousands and thousands of connections so the time taking natd to process a packet was skyrocketing. It is basically DoS, whether intentional or not, malicious or not, worm or whatever, it's DoS. I was quickly able to code up some patches to ip_nat.h, mlfk_ipl.c, and ip_nat.c to essentially 'rate limit' NAT'd connections so that a few infected users don't burry my nat box. BTW, don't worry about the mem leak question...my bad, it was in my patch. I thought I was using a kernel without my patch when I sent the first message. I've added a sysctl value for rate limiting user connections to prevent DoS such as this when using ipnat. It works quite well (minus the mem leak, but I'm working on that!). Right now it's just a hard limit on max connections while tweaking fr_defnatage but I will be making it smarter in the future. I just need something right now to keep the system from going down. vec ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ath0 stop connection
Hi there. I have 2 FreeBSD with a Atheros chipset wireless card one Access point one client, I pinging between the wiereless link (ping -s 25000 client_ip) and I have very good speed on turbo mode close to 3,2Mbps/s but after 3 hours the Freebsd AP cut the connection and put in the screen a sheel like dd . ideas? thanks Sam Leffler wrote: On Wednesday 08 October 2003 08:45 pm, Marcos Biscaysaqu wrote: Hi There. I have 2 PCI wireless card with the Atheros chipset some one know how can i setup a point-to-point with 2 of this wireless card on Freebsd, I could made work Access Point client, but i couln't adhoc turbo mode 11a Apparently adhoc mode is currently busted. It's at the top of my todo list and I may even get to it this week... Sam -- Marcos Biscaysaqu Systems Administrator ThePacific.Net Ltd. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipnat memory leak?
At 6:37 PM -0600 2003/10/09, Vector wrote: However, as soon as I put it in the kernel, ipnat -l and ipnat -t became my best friends. They are incredibly useful. Okay, now that you explain it that way, it makes sense. That was very interesting to read. Thank you! -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sched_Ule
How many of the people experiencing SCHED_ULE related problems (primarily lagging) are also using nvidia-driver? I know I am, and I'm pretty sure Arjan is. Could there be a connection? -- Evan Dower Undergraduate, Computer Science University of Washington Public key: http://students.washington.edu/evantd/pgp-pub-key.txt Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D From: Arjan van Leeuwen [EMAIL PROTECTED] To: Jeff Roberson [EMAIL PROTECTED],Sheldon Hearn [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: Sched_Ule Date: Thu, 9 Oct 2003 23:36:48 +0200 On Thursday 09 October 2003 22:57, Jeff Roberson wrote: On Thu, 9 Oct 2003, Sheldon Hearn wrote: On (2003/10/09 00:28), Scott Sipe wrote: Anything that seems disk intensive: bzip2 (unbzip2ing one big file makes this happen), making world, building ports, etc makes my X environment practically unusable. Mouse stutters, reaction times is very slow, feels 10x more sluggish than normal. (I'm running KDE if anyone is curious). A number of us are seeing this problem, and not all of us are entry level end-users. I'm using a single PIII with 1GB of RAM and maxusers 0. No Hyper-threading, nothing interesting in the kernel (apart from I686_CPU only, KTRACE and _KPOSIX_PRIORITY_SCHEDULING). The problem (as I recall) is that Jeff hasn't received reports from people who can dig into the problem and have the time to do so. For example, I'm pretty sure I could at least point a finger at the problem if I had time. But I'm under heavy pressure, and so the only solution that's feasible for me is to just switch to SCHED_4BSD and keep moving. What surprises me is that Jeff can't reproduce it. For me, the sluggish mouse problem manifests under these conditions: 1) Use a USB mouse, not a PS2 mouse. Is this _only_ with usb? Hi Jeff, I have the same problem, but with a PS2 mouse. I've never tried an USB mouse on this system. I've seen this behavior on at least 4 systems now myself, fast and slow systems (my own workstation is an Athlon XP 2000+, 512MB RAM). It must be possible for you to reproduce this behavior. I've seen the lagging mouse on many occasions, always when my system was under high load. It's very difficult to pinpoint though; for example, if I'm building a port, I only notice the lagging for small periods of time during the build (sometimes I don't see it for 5 minutes, then suddenly it lags for about 3 seconds). Most of the time, it doesn't even bother me. One of the places it _always_ happens, is when I log out of GNOME 2.4. The background fades to a darker color, and during the fade, I experience the mouse lag. Can you reproduce this? Maybe you have some hints for me, some things I can try to find out more about this problem? Arjan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] _ Frustrated with dial-up? Get high-speed for as low as $29.95/month (depending on the local service providers in your area). https://broadband.msn.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i865 Video Memory
On Wednesday 08 October 2003 10:10 am, David Malone wrote: You can just run 855patch 8192 before starting X, and suddenly you can do a resolution higher than 640x480 in 8 bit mode ;-) Kewl. What do we have to do to convince you to make a port of it? ;^) -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sched_Ule
On Thursday 09 October 2003 08:16 pm, Evan Dower wrote: How many of the people experiencing SCHED_ULE related problems (primarily lagging) are also using nvidia-driver? I know I am, and I'm pretty sure Arjan is. Could there be a connection? I switched back to the XFree86 nv driver earlier today and still have trouble. moused is running and it is a PS/2 mouse. -- Jonathan Fosburgh AIX/SAN Administrator UT MD Anderson Cancer Center Houston, TX Home Page: http://www.fosburgh.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sched_Ule
From: Jonathan E Fosburgh [EMAIL PROTECTED] I switched back to the XFree86 nv driver earlier today and still have trouble. moused is running and it is a PS/2 mouse. Is nvidia.ko still loaded in the kernel? -- Evan Dower Undergraduate, Computer Science University of Washington Public key: http://students.washington.edu/evantd/pgp-pub-key.txt Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D _ Get a FREE computer virus scan online from McAfee. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can not remove directory
On Thu, 9 Oct 2003, Boris Kovalenko wrote: Can not remove directory /usr/obj/usr/src/gnu/usr.bin/cc/cc1 rm: /usr/obj/usr/src/gnu/usr.bin/cc/cc1: Directory not empty What's going on is that the background file system checker hasn't adjusted down the reference counts for the directory in question. I've run into this on a couple of occasions, and Kirk and I have bantered about possible fixes. Basically, the only inconsistencies permitted by soft updates are freed space being unavailable for reuse, and elevated reference counts. The background file system checker walks through the file system metadata in a snapshot to move blocks to the free list and adjust reference counts. The problem will clear by itself once bgfsck catches up; as a workaround, just move it out of the way somewhere in the same file system until bgfsck is done. Or you can manually clear up the reference if you're willing to risk it :-). A normal fsck in single-user would also clear it up. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories bash-2.05b# pwd; ls -la /usr/obj/usr/src/gnu/usr.bin/cc/cc1 total 4 drwxr-xr-x 2 root wheel 512 Oct 9 08:54 . drwxr-xr-x 13 root wheel 512 Oct 9 08:54 .. bash-2.05b# pwd; ls -la /usr/obj/usr/src/gnu/usr.bin/cc total 26 drwxr-xr-x 13 root wheel 512 Oct 9 08:54 . drwxr-xr-x 21 root wheel 512 Oct 9 11:23 .. drwxr-xr-x 2 root wheel 512 Oct 9 08:55 c++ drwxr-xr-x 2 root wheel 512 Oct 9 08:55 c++filt drwxr-xr-x 2 root wheel 512 Oct 9 08:54 cc1 drwxr-xr-x 2 root wheel 512 Oct 9 08:55 cc1obj drwxr-xr-x 2 root wheel 1024 Oct 9 08:55 cc1plus drwxr-xr-x 2 root wheel 512 Oct 9 08:55 cpp drwxr-xr-x 2 root wheel 512 Oct 9 08:55 cpp0 drwxr-xr-x 2 root wheel 512 Sep 26 10:34 doc drwxr-xr-x 2 root wheel 512 Oct 9 08:55 gcov drwxr-xr-x 2 root wheel 512 Oct 9 08:55 protoize drwxr-xr-x 2 root wheel 512 Oct 9 08:55 tradcpp0 What is wrong? Current system is 5.1-RELEASE-p8 Yours truly, Boris Kovalenko ___ [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]
[current tinderbox] failure on alpha/alpha
TB --- 2003-10-10 04:00:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-10-10 04:00:01 - 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-10-10 04:03:53 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: populating /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include [...] ./make-roken tmp.h ; if [ -f roken.h ] cmp -s tmp.h roken.h ; then rm -f tmp.h ; else rm -f roken.h; mv tmp.h roken.h; fi === kerberos5/lib/libvers === kerberos5/lib/libasn1 ./asn1_compile /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/k5.asn1 krb5_asn1 test -e /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/kerberos5/lib/libasn1/asn1_err.et || ln -sf /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/asn1_err.et compile_et asn1_err.et === kerberos5/lib/libhdb make: don't know how to make hdb_asn1.h. Stop *** Error code 2 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/kerberos5/lib. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/kerberos5. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/kerberos5. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. TB --- 2003-10-10 04:10:16 - /usr/bin/make returned exit code 1 TB --- 2003-10-10 04:10:16 - ERROR: failed to build world TB --- 2003-10-10 04:10:16 - tinderbox aborted ___ [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-10-10 04:10:17 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-10-10 04:10:17 - 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-10-10 04:12:31 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: populating /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include [...] ./make-roken tmp.h ; if [ -f roken.h ] cmp -s tmp.h roken.h ; then rm -f tmp.h ; else rm -f roken.h; mv tmp.h roken.h; fi === kerberos5/lib/libvers === kerberos5/lib/libasn1 ./asn1_compile /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/k5.asn1 krb5_asn1 test -e /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/kerberos5/lib/libasn1/asn1_err.et || ln -sf /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/asn1_err.et compile_et asn1_err.et === kerberos5/lib/libhdb make: don't know how to make hdb_asn1.h. Stop *** Error code 2 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/kerberos5/lib. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/kerberos5. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/kerberos5. *** 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. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. TB --- 2003-10-10 04:19:19 - /usr/bin/make returned exit code 1 TB --- 2003-10-10 04:19:19 - ERROR: failed to build world TB --- 2003-10-10 04:19:19 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on i386/pc98
TB --- 2003-10-10 04:19:20 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-10-10 04:19:20 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/pc98 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-10-10 04:21:07 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: populating /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include [...] ./make-roken tmp.h ; if [ -f roken.h ] cmp -s tmp.h roken.h ; then rm -f tmp.h ; else rm -f roken.h; mv tmp.h roken.h; fi === kerberos5/lib/libvers === kerberos5/lib/libasn1 ./asn1_compile /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/k5.asn1 krb5_asn1 test -e /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/kerberos5/lib/libasn1/asn1_err.et || ln -sf /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/asn1_err.et compile_et asn1_err.et === kerberos5/lib/libhdb make: don't know how to make hdb_asn1.h. Stop *** Error code 2 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/kerberos5/lib. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/kerberos5. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/kerberos5. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. TB --- 2003-10-10 04:27:42 - /usr/bin/make returned exit code 1 TB --- 2003-10-10 04:27:42 - ERROR: failed to build world TB --- 2003-10-10 04:27:42 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on sparc64/sparc64
TB --- 2003-10-10 04:27:43 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-10-10 04:27:43 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-10-10 04:29:31 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include [...] ./make-roken tmp.h ; if [ -f roken.h ] cmp -s tmp.h roken.h ; then rm -f tmp.h ; else rm -f roken.h; mv tmp.h roken.h; fi === kerberos5/lib/libvers === kerberos5/lib/libasn1 ./asn1_compile /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/k5.asn1 krb5_asn1 test -e /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/kerberos5/lib/libasn1/asn1_err.et || ln -sf /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/asn1_err.et compile_et asn1_err.et === kerberos5/lib/libhdb make: don't know how to make hdb_asn1.h. Stop *** Error code 2 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/kerberos5/lib. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/kerberos5. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/kerberos5. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-10-10 04:35:38 - /usr/bin/make returned exit code 1 TB --- 2003-10-10 04:35:38 - ERROR: failed to build world TB --- 2003-10-10 04:35:38 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[releng_5_1 tinderbox] failure on alpha/alpha
___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[releng_5_1 tinderbox] failure on i386/i386
___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[releng_5_1 tinderbox] failure on i386/pc98
___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[releng_5_1 tinderbox] failure on sparc64/sparc64
___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
