Re: 9.2-RC3 - suspend/resume causes slow system performance
My slowdown manifests as extremely slow disk access, even with low CPU. This happens even if CPU scaling is disabled, or if I am remotely accessing the system, with no X. On Wed, Sep 25, 2013 at 8:01 AM, Bengt Ahlgren ben...@sics.se wrote: Now having some experience with my new TP X201 and Intel/KMS graphics, I also ran into severe Xorg perfomance issues, but it was _not_ connected to suspend/resume, because it persisted after a clean reboot. I plugged in a projector to the VGA port, and used xrandr. The Xorg server seemed to come to a halt, in practice unusable. After the fact I saw in the log file that there were tons of these messages: [ 136.238] (II) intel(0): EDID vendor IFS, prod id 4354 [ 136.238] (II) intel(0): Using hsync ranges from config file [ 136.238] (II) intel(0): Using vrefresh ranges from config file [ 136.238] (II) intel(0): Printing DDC gathered Modelines: [ 136.238] (II) intel(0): Modeline 1280x800x0.0 83.40 1280 1344 1480 1680 800 801 804 828 -hsync +vsync (49.6 kHz eP) [ 136.238] (II) intel(0): Modeline 800x600x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e) [ 136.238] (II) intel(0): Modeline 800x600x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz e) [ 136.238] (II) intel(0): Modeline 640x480x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz e) [ 136.238] (II) intel(0): Modeline 640x480x0.0 31.50 640 664 704 832 480 489 492 520 -hsync -vsync (37.9 kHz e) [ 136.238] (II) intel(0): Modeline 640x480x0.0 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz e) [ 136.238] (II) intel(0): Modeline 640x480x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e) [ 136.238] (II) intel(0): Modeline 720x400x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz e) [ 136.238] (II) intel(0): Modeline 1280x1024x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz e) [ 136.238] (II) intel(0): Modeline 1024x768x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz e) [ 136.238] (II) intel(0): Modeline 1024x768x0.0 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz e) [ 136.238] (II) intel(0): Modeline 1024x768x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) [ 136.238] (II) intel(0): Modeline 832x624x0.0 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz e) [ 136.238] (II) intel(0): Modeline 800x600x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz e) [ 136.238] (II) intel(0): Modeline 800x600x0.0 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz e) [ 136.238] (II) intel(0): Modeline 1152x864x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz e) [ 136.238] (II) intel(0): Modeline 1280x720x60.0 74.48 1280 1336 1472 1664 720 721 724 746 -hsync +vsync (44.8 kHz e) [ 136.238] (II) intel(0): Modeline 1280x960x0.0 108.00 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync (60.0 kHz e) [ 136.238] (II) intel(0): Modeline 1280x1024x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz e) [ 136.238] (II) intel(0): Modeline 1366x768x59.8 84.75 1366 1431 1567 1776 768 771 781 798 -hsync +vsync (47.7 kHz e) [ 136.238] (II) intel(0): Modeline 1440x900x0.0 106.50 1440 1520 1672 1904 900 903 909 934 -hsync +vsync (55.9 kHz e) [ 136.238] (II) intel(0): Modeline 1400x1050x0.0 121.75 1400 1488 1632 1864 1050 1053 1057 1089 -hsync +vsync (65.3 kHz e) [ 136.238] (II) intel(0): Modeline 1600x1200x0.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz e) [ 136.238] (II) intel(0): Modeline 1680x1050x0.0 146.25 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync (65.3 kHz e) That is, the Xorg server constantly queried the display device for its capabilities (perhaps on behalf of some client - I run KDE, so you never know what it tries to do...). This seems to be a somewhat known issue: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/310857 Is this something different, or is this a variant of the slowdown others are seeing? Bengt Adrian Chadd adr...@freebsd.org writes: .. anything happening? -adrian On 2 September 2013 07:29, Adrian Chadd adr...@freebsd.org wrote: On 2 September 2013 07:25, Mike Harding mvhard...@gmail.com wrote: It's detailed in the ticket, see http://www.freebsd.org/cgi/query-pr.cgi?pr=181632 and search for 'reverted'. Ok. You and avg@ are digging into it deeper, so I'll leave it be for now. I'll retest this on my test laptops when I'm back home. -adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable
Re: 9.2-RC3 - suspend/resume causes slow system performance
Just a note for anybody who might have this problem with 9.2 that I am still having this issue with 9.2-releng (unless I patch the kernel) and Andriy hasn't accessed my system yet, to have a look so 9.2 release is likely to have this same issue for some subset of users (maybe only 1, me!). We were able to figure out that my symptoms have nothing to do with the user of powerd (still happens if powerd is not enabled, and the CPU still scales after suspend/resume). As this only appears to affect the disk access, here's the dmesg output related to the SATA hardware and affected disk: ... ahci0: Intel 5 Series/3400 Series AHCI SATA controller port 0xb880-0xb887,0xb\ 800-0xb803,0xb480-0xb487,0xb400-0xb403,0xb080-0xb09f mem 0xf7cf7000-0xf7cf77ff \ irq 21 at device 31.2 on pci0 ahci0: AHCI v1.30 with 6 3Gbps ports, Port Multiplier supported ... ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ST1000DM003-9YN162 CC4D ATA-8 SATA 3.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada0: quirks=0x14K ada0: Previously was known as ad4 On Fri, Sep 6, 2013 at 3:01 PM, Adrian Chadd adr...@freebsd.org wrote: .. anything happening? -adrian On 2 September 2013 07:29, Adrian Chadd adr...@freebsd.org wrote: On 2 September 2013 07:25, Mike Harding mvhard...@gmail.com wrote: It's detailed in the ticket, see http://www.freebsd.org/cgi/query-pr.cgi?pr=181632 and search for 'reverted'. Ok. You and avg@ are digging into it deeper, so I'll leave it be for now. I'll retest this on my test laptops when I'm back home. -adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.2-RC3 - suspend/resume causes slow system performance
It's detailed in the ticket, see http://www.freebsd.org/cgi/query-pr.cgi?pr=181632 and search for 'reverted'. On Mon, Sep 2, 2013 at 6:35 AM, Adrian Chadd adr...@freebsd.org wrote: So you tinkered with this - which particular line(s) did you revert back to get the old behaviour? -adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.2-RC3 - suspend/resume causes slow system performance
This would be a 'strange story' if I had not tracked this down. The disk works, only much slower than normal. I only noticed it because I was doing a buildworld. There is no crash, no dmesg, no console logs. I'll ask again, why change that line? Did you feel that the original author of the code had made a mistake? The code in question is from Oct. 2005. Also why move the check for the HT in front of the check for the disabled idle? The only change that affects my system is that idle is enabled in a code path that should only be run when idle is disabled. I don't know the larger context but I also don't know why the code was changed. It looks like the intent of the code has been changed (don't suspend if this flag is set) and I don't know what benefit this provides. The code path seems to only be run during startup, shutdown and wake from sleep. Contact me via email and I'll set up remote access. This is a personal machine so this is a bit awkward. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.2-RC3 - suspend/resume causes slow system performance
Why not put this out to stable and take a survey with more than 2 members? I am sure that there are those who will be delighted, as I was with 9.1, to discover that suspend/resume worked without rebooting the machine. I can make the system available to you, contact me at this email. I am in the PDT time zone. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.2-RC3 - suspend/resume causes slow system performance
I've tracked this down to a single line, details in http://www.freebsd.org/cgi/query-pr.cgi?pr=181632. Basically, the code is now doing a 'sti, hlt' vs. a 'sti' in some code that is only supposed to run if idle is disabled. Given that 'hlt' is the idle instruction, this doesn't seem right. On Thu, Aug 29, 2013 at 11:50 PM, Adrian Chadd adr...@freebsd.org wrote: On 29 August 2013 23:46, Mike Harding mvhard...@gmail.com wrote: I was able to track this down by building kernels against /base/stable/9 (it took -hours!-). Wow, thanks! The issue does occur with commit 244616, but does not occur with 244614. The only difference is a small patch to /usr/src/sys/dev/acpica/acpi_cpu.c - this code appears to do with c-state processing. I'll note it in the ticket, but somebody might want to look at this ASAP That's awesome. It's a very small ACPI patch. Let's see if the others who are having this issue can test this out and report back! Thanks! -adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.2-RC3 - suspend/resume causes slow system performance
I was able to track this down by building kernels against /base/stable/9 (it took -hours!-). The issue does occur with commit 244616, but does not occur with 244614. The only difference is a small patch to /usr/src/sys/dev/acpica/acpi_cpu.c - this code appears to do with c-state processing. I'll note it in the ticket, but somebody might want to look at this ASAP On Thu, Aug 29, 2013 at 7:10 AM, Adrian Chadd adr...@freebsd.org wrote: Wow. Uhm, can you downgrade to 9.1 and see if it still happens? Would you be able to bisect the kernel source and see if you can find where along stable/9 it happened? That's the fastest way to determine what broke. Thanks! -adrian On 29 August 2013 06:32, Mike Harding mvhard...@gmail.com wrote: I opened a ticket about this: kern/181632 Basically, if I do a 'zzz' and then wake the system up, operations like a buildworld or portmaster take much longer after the resume - systat shows very low CPU/disk utilization. It's 100% repeatable, I don't recall this happening on 9.1 I build 9.2-RC3 from source (as I have for years) - this is a fairly generic SMP system (i5 750 with 4 cpus). Let me know if I can provide any data - this is a fairly significant regression for me as I have taken to bringing the system up as needed vs. leaving it on all of the time. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
9.2-RC3 - suspend/resume causes slow system performance
I opened a ticket about this: kern/181632 Basically, if I do a 'zzz' and then wake the system up, operations like a buildworld or portmaster take much longer after the resume - systat shows very low CPU/disk utilization. It's 100% repeatable, I don't recall this happening on 9.1 I build 9.2-RC3 from source (as I have for years) - this is a fairly generic SMP system (i5 750 with 4 cpus). Let me know if I can provide any data - this is a fairly significant regression for me as I have taken to bringing the system up as needed vs. leaving it on all of the time. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
crash during shutdown -after- disks unmounted
I had a panic during shutdown, in the if_re.c interrupt handler,
likely because I had
ifconfig_re0=inet 192.168.0.2 netmask 255.255.255.0 -rxcsum -txcsum
in /etc/rc.conf.
Please feel free to contact me for details. This is a very recent -stable.
(kgdb) bsd# uname -a
FreeBSD bsd.mvh 6.2-STABLE FreeBSD 6.2-STABLE #0: Tue Sep 18 14:45:37 PDT 2007
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/M62 i386
bsd# cd /usr/obj/usr/src/sys/M62
bsd# kgdb kernel.debug /usr/crash/vmcore.2
kdbd: Command not found.
bsd# kgdb kernel.debug /usr/crash/vmcore.2
kgdb: kvm_nlist(_stopped_cpus):
kgdb: kvm_nlist(_stoppcbs):
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 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-marcel-freebsd.
Unread portion of the kernel message buffer:
118.
118Terminated
118.
118Sep 18 20:46:50 bsd syslogd: exiting on signal 15
Waiting (max 60 seconds) for system process `vnlru' to stop...done
Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining...5 4 3 0 0 0 done
All buffers synced.
Uptime: 5h42m34s
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xc
fault code = supervisor write, page not present
instruction pointer = 0x20:0xc05d8f4d
stack pointer = 0x28:0xe571cc64
frame pointer = 0x28:0xe571cc84
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 19 (swi5: +)
trap number = 12
panic: page fault
Uptime: 5h42m34s
Dumping 1022 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 1022MB (261600 pages) 1006 990 974 958 942 926 910 894 878 862 846
830 814 798 782 766 750 734 718 702 686 670 654 638 622 606 590 574 558 542 526
510 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206
190 174 158 142 126 110 94 78 62 46 30 14
#0 doadump () at pcpu.h:165
165 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) list *0xc05d8f4d
0xc05d8f4d is in re_rxeof (/usr/src/sys/dev/re/if_re.c:1723).
1718}
1719m = sc-rl_head;
1720sc-rl_head = sc-rl_tail = NULL;
1721m-m_pkthdr.len = total_len - ETHER_CRC_LEN;
1722} else
1723m-m_pkthdr.len = m-m_len =
1724(total_len - ETHER_CRC_LEN);
1725
1726#ifdef RE_FIXUP_RX
1727re_fixup_rx(m);
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc068f2c2 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2 0xc068f558 in panic (fmt=0xc0904c14 %s)
at /usr/src/sys/kern/kern_shutdown.c:565
#3 0xc08a68fc in trap_fatal (frame=0xe571cc24, eva=12)
at /usr/src/sys/i386/i386/trap.c:838
#4 0xc08a6663 in trap_pfault (frame=0xe571cc24, usermode=0, eva=12)
at /usr/src/sys/i386/i386/trap.c:745
#5 0xc08a6299 in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -985962496, tf_esi = 38,
tf_ebp = -445526908, tf_isp = -445526960, tf_ebx = 0, tf_edx = -985337856,
tf_ecx = 536872960, tf_eax = 66, tf_trapno = 12, tf_err = 2, tf_eip =
-1067610291, tf_cs = 32, tf_eflags = 590342, tf_esp = 15, tf_ss = 31743})
at /usr/src/sys/i386/i386/trap.c:435
#6 0xc089377a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc05d8f4d in re_rxeof (sc=0xc53b6800) at /usr/src/sys/dev/re/if_re.c:1723
#8 0xc05d9416 in re_int_task (arg=0xc53b6800, npending=1)
at /usr/src/sys/dev/re/if_re.c:1984
#9 0xc06aee43 in taskqueue_run (queue=0xc53bf100)
at /usr/src/sys/kern/subr_taskqueue.c:257
#10 0xc06af43a in taskqueue_fast_run (dummy=0x0)
at /usr/src/sys/kern/subr_taskqueue.c:435
#11 0xc0679685 in ithread_execute_handlers (p=0xc53ca860, ie=0xc53bf080)
---Type return to continue, or q return to quit---
at /usr/src/sys/kern/kern_intr.c:682
#12 0xc067979c in ithread_loop (arg=0xc539e170)
at /usr/src/sys/kern/kern_intr.c:765
#13 0xc067860c in fork_exit (callout=0xc0679748 ithread_loop,
arg=0xc539e170, frame=0xe571cd38) at /usr/src/sys/kern/kern_fork.c:830
#14 0xc08937dc in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208
(kgdb)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Crash report
I have had -lots- of panics since upgrading to 6.2 - my system was
pretty much 100% before that. One thing I do have on my system is
some jails, and I also see this crashes during tinderbox builds. I
upgraded to 6.2-STABLE to see if the crashes were fixed, I still have
them. Any ideas? memtest shows nothing wrong...
- Mike H.
bsd# kgdb kernel.debug /usr/crash/vmcore.3
kgdb: kvm_nlist(_stopped_cpus):
kgdb: kvm_nlist(_stoppcbs):
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 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-marcel-freebsd.
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc065962a
stack pointer = 0x28:0xe9a72a80
frame pointer = 0x28:0xe9a72a94
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 45 (bufdaemon)
trap number = 12
panic: page fault
Uptime: 1h57m10s
Dumping 1022 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 1022MB (261600 pages) 1006 990 974 958 942 926 910 894 878 862 846
830 814 798 782 766 750 734 718 702 686 670 654 638 622 606 590 574 558 542 526
510 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206
190 174 158 142 126 110 94 78 62 46 30 14
#0 doadump () at pcpu.h:165
165 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) (kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc0692b66 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2 0xc0692dfc in panic (fmt=0xc08e2397 %s)
at /usr/src/sys/kern/kern_shutdown.c:565
#3 0xc08847f4 in trap_fatal (frame=0xe9a72a40, eva=0)
at /usr/src/sys/i386/i386/trap.c:837
#4 0xc088455b in trap_pfault (frame=0xe9a72a40, usermode=0, eva=0)
at /usr/src/sys/i386/i386/trap.c:745
#5 0xc0884199 in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -981774848, tf_esi = 0,
tf_ebp = -374920556, tf_isp = -374920596, tf_ebx = -948495924, tf_edx = 2048,
tf_ecx = 0, tf_eax = 2, tf_trapno = 12, tf_err = 0, tf_eip = -1067084246, tf_cs
= 32, tf_eflags = 66182, tf_esp = 2, tf_ss = -981470960})
at /usr/src/sys/i386/i386/trap.c:435
#6 0xc08718ca in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc065962a in g_io_request (bp=0xc77719cc, cp=0xc57b4e00)
at /usr/src/sys/geom/geom_io.c:275
#8 0xc065bb81 in g_vfs_strategy (bo=0x2, bp=0xd938b618)
at /usr/src/sys/geom/geom_vfs.c:107
#9 0xc07c67fd in ffs_geom_strategy (bo=0xc57ff1d0, bp=0xd938b618)
at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1805
#10 0xc07d26dd in ufs_strategy (ap=0x2)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:1973
#11 0xc0896549 in VOP_STRATEGY_APV (vop=0xc09ad260, a=0xe9a72b10)
at vnode_if.c:1796
#12 0xc06ddb84 in bufstrategy (bo=0xc78cba50, bp=0x2) at vnode_if.h:928
#13 0xc06d86a0 in bufwrite (bp=0xd938b618) at buf.h:426
#14 0xc06da0bb in vfs_bio_awrite (bp=0xd938b618) at buf.h:410
#15 0xc06daf01 in flushbufqueues (flushdeps=0)
at /usr/src/sys/kern/vfs_bio.c:2144
#16 0xc06daa03 in buf_daemon () at /usr/src/sys/kern/vfs_bio.c:2018
#17 0xc067cd50 in fork_exit (callout=0xc06da914 buf_daemon, arg=0x0,
frame=0xe9a72d38) at /usr/src/sys/kern/kern_fork.c:830
#18 0xc087192c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208
(kgdb) list *0xc065962a
0xc065962a is in g_io_request (/usr/src/sys/geom/geom_io.c:275).
270 KASSERT(bp-bio_length % cp-provider-sectorsize == 0,
271 (wrong length %jd for sectorsize %u,
272 bp-bio_length, cp-provider-sectorsize));
273 }
274
275 g_trace(G_T_BIO, bio_request(%p) from %p(%s) to %p(%s) cmd %d,
276 bp, cp, cp-geom-name, pp, pp-name, bp-bio_cmd);
277
278 bp-bio_from = cp;
279 bp-bio_to = pp;
(kgdb) 280 bp-bio_error = 0;
281 bp-bio_completed = 0;
282
283 KASSERT(!(bp-bio_flags BIO_ONQUEUE),
284 (Bio already on queue bp=%p, bp));
285 bp-bio_flags |= BIO_ONQUEUE;
286
287 binuptime(bp-bio_t0);
288
289 /*
(kgdb)
290 * The statistics collection is lockless, as such, but we
291 * can not update one instance of the statistics from more
292 * than one thread at a time, so grab the lock first.
293 */
294
Re: Crash report
Yep, have had to do this many many times. I had another crash, during the 'umount' process. Is there possibly a race condition with tinderbox? I generally run the tinderbox as 'idprio 10'... This crash happens with 2 different boxes, doing the same thing. One is an Intel Dell, one is a AMD system. 6.1 was so solid I may go back to it... On Tue, 2007-08-07 at 15:26 -0400, Kris Kennaway wrote: On Tue, Aug 07, 2007 at 10:43:54AM -0700, Mike Harding wrote: I have had -lots- of panics since upgrading to 6.2 - my system was pretty much 100% before that. One thing I do have on my system is some jails, and I also see this crashes during tinderbox builds. I upgraded to 6.2-STABLE to see if the crashes were fixed, I still have them. Any ideas? memtest shows nothing wrong... Try disabling bg fsck, then booting to single user mode and running fsck -f. You may have residual file system corruption. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Crash report
I should also mention, fwiw, that I use tinderbox with the 'nullfs' mounts. I can forward my config to anybody who is interested in trying to recreate these crashes. On Tue, 2007-08-07 at 15:26 -0400, Kris Kennaway wrote: On Tue, Aug 07, 2007 at 10:43:54AM -0700, Mike Harding wrote: I have had -lots- of panics since upgrading to 6.2 - my system was pretty much 100% before that. One thing I do have on my system is some jails, and I also see this crashes during tinderbox builds. I upgraded to 6.2-STABLE to see if the crashes were fixed, I still have them. Any ideas? memtest shows nothing wrong... Try disabling bg fsck, then booting to single user mode and running fsck -f. You may have residual file system corruption. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Mounting a powered-down HDD renders system unusable
On a 5.4-pre system as of the last few days, If I mount a spun down hard disk (one I am using only for backup): # mount /backup/usr I get ad1: TIMEOUT _ READ DMA retrying (2 retries left) LBA=7340273 ad0: WARNING - removed from configuration ad1: WARNING - removed from configuration at0-slave: FAILURE - READ DMA Timeout mount:/dev/ad1s1g : Input/Output error ata0-slave: timeout state=0 unexpected initiate_write_filepage: already started initiate_write_filepage: already started (repeat until reset is pushed) Nothing works because all of the disks are unmounted. Can't even shut down. This worked great in 4.10, and also 5.3 (where the initial mount generated an error, but I could do the mount again after the disk spun up). Anybody else get the same thing? I'll open a bug report if so... -- Mike Harding [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 4.10-RELEASE
Look at the todo list. They are apparently testing out the 'twe' device right now, and a fix for a vmpsace leak that can cause a crash. By these todo notes rc3 has already been released, but it hasn't been announced... Would be nice if the release dates were twiddled, though, if only to give us a little hope... If you are very antsy I would go ahead and build RELENG_4_10 and use it, I can't imagine there will be any significant changes in the release, especially if you are not using the 'twe' device. I am just waiting because 4.9-RELEASE is not stable in my hardware and I want to populate my jails with a tagged release... - Mike H. X-Original-To: [EMAIL PROTECTED] Date: Thu, 13 May 2004 22:08:10 +0200 From: Ivo Schmagler [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] X-Virus-Scanned: by amavisd-new at mvh.mine.nu Hi, I just wonder what happened to 4.10-RELEASE. Heard rumors about RC3 being planned, but seems to be wrong. According to webpage release is still scheduled for May 5th (?) ... Anybody else who wonders what's going on? When will it be released? I can't wait. Ivo ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Possible mouse/ATA problems in -STABLE
My mouse has been losing sync several times a day and then eventually disappearing, requiring, AFAIK, a reboot to make the system usable. It's possible that this is hardware on my end, but I did change mice and I still have the same problem. This may be related to some recent mfc ATA changes at this only seems to happen during periods of high disk activity. Also, the mouse seems to generate almost 300 interrupts per second at times. I am going to back my system down to sept. 1 and see if I get the problem again, and will advise if this seems to 'fix' it. When the mouse goes it looks like this: Oct 22 08:53:58 netcom1 /kernel: psmintr: reset the mouse. Oct 22 08:53:58 netcom1 /kernel: psm0: failed to reset the aux device. Oct 22 08:53:58 netcom1 /kernel: psm0: the aux device has gone! (reinitialize). Thanks for working on FreeBSD... - Mike H. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possible mouse/ATA problems in -STABLE
Mouse is on interrupt 12, ATA on 14 and 15. I don't have any interrupt conflicts AFAIK. I think that maybe the new ATA drivers are staying in the interrupt a bit longer and causing data to be dropped. I have reverted to 1-sep -STABLE and it seems stable (so far), I am going to try a new -STABLE and look at the interrupt counts. The -STABLE ATA drivers were MFC'd - after this merge I see the following comment for a commit on ata-dma.c (revision 1.122) ... This pushed the time spent between starting the ATA command and starting the DMA engine over the hill for some controllers (especially the Silicon Image DS3112a) and caused what looked like lost interrupts. - so possibly we need another MFC... ? On Thu, 2003-10-23 at 09:22, Doug White wrote: On Thu, 23 Oct 2003, Mike Harding wrote: My mouse has been losing sync several times a day and then eventually disappearing, requiring, AFAIK, a reboot to make the system usable. It's possible that this is hardware on my end, but I did change mice and I still have the same problem. This may be related to some recent mfc ATA changes at this only seems to happen during periods of high disk activity. Also, the mouse seems to generate almost 300 interrupts per second at times. It sounds like your ATA device and ps/2 ports have ended up with the same interrupt. You might see if you can convince the ATA controller to move elsewhere by locking out irq 12. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Squid memory leaks in -stable using libc malloc
There can of course be a difference between what malloc allocates and what the application asked for. Various malloc implementations will do things like round allocations up to a power of 2, etc. The application is only aware of the memory it asked for - the OS knows how much memory was actually allocated. 'Wasted' memory isn't an indication of a bug, it's a characteristic of the malloc used. It's only leaking memory if the memory usage grows without bound, and I've never seen that with squid, in a few years anyway. Different malloc implementations optimize for different things - the FreeBSD malloc, looking at the man page, appears to try to minimize page faults. It also looks like it uses buckets with various powers of 2. dlmalloc looks to have a maximum 'wastage' of 15 bytes per chunk. There is a good writeup of dlmalloc here: http://g.oswego.edu/dl/html/malloc.html Sounds like you might as well use dlmalloc with squid - squid does generate a lot of memory allocations, and the characteristics of squid may function better with this malloc, which is likely why they provide it as an option. You may want to suggest to the port maintainer that dlmalloc be used as the default... - Mike H. On Sun, 2003-09-07 at 08:20, Anders Nordby wrote: Hi, On Sat, Sep 06, 2003 at 08:17:19AM -0700, Mike Harding wrote: Squid uses more memory than you assign to cache_mem, this is documented in the Squid FAQ, section 8. cache_mem is sort of a 'suggested' value, it's normal for squid to use a lot more memory than cache_mem. I know this, and I know the contents of the FAQ. However, there's a huge difference between what top reports as memory used (SIZE) and what cache manager reports as total allocated KB. In a running process I have just now, top says Squid uses 1235 MB of memory, while cache manager reports 663 MB allocated (contents of /proc/pid/map attached). That's after running for around 10 hours. If I use dlmalloc (I do on one system), the numbers are 2291 MB according to top and 2221 MB according to cache manager after running for 30 hours. Do you see the difference? To me, there seems to be a leak, or at least very unfavourable results with phkmalloc and Squid. BTW, in the first example I gave here, I (still) use phkmalloc with H configured in malloc.conf, although H did not seem to make a difference. If you are happy with dmalloc, though, go ahead and use it, just check out the squid FAQ about memory usage. I don't think that there is anything wrong with FreeBSD's malloc, it just has different performance characteristics. I agree that there doesn't have to be something technically wrong with (phk)malloc. However, if there is, someone may have an interest in following this up (tjr@ seems to be - I talked to him on IRC about this). Cheers, ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ok, are all the panics fixed now?
RAM is cheap, so I don't need swapping. Naps are -not- negotiable. :) - Mike H. X-Original-To: [EMAIL PROTECTED] X-pair-Authenticated: 209.68.2.70 Date: Wed, 27 Aug 2003 13:34:15 -0500 (CDT) From: Mike Silbersack [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] X-Spam-Status: No, hits=-5.4 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) On Wed, 27 Aug 2003, Mike Silbersack wrote: Ah, that's a good idea! I'll try setting hw.physmem down to 12M or so and see if that causes the panics to occur over here. Mike Silby Silbersack Ok, I booted with hw.physmem=16M, and a buildworld paniced with free/cache page dirty. (I was taking a nap at the time the buildworld crashed, we'll talk about that soon.) (Are you guys running with INVARIANTS?) So, I think we'll just include a warning with 4.9: WARNING! Do not attempt to stress a FreeBSD 4.9 machine if you: a) Will be swapping whatsoever or b) Will be taking a nap while it is running. Doing either or both of these may result in panics. Mike Silby Silbersack P.S. - now that we have an easy way to reproduce this, perhaps we can get it fixed. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
How to force a kernel panic?
...so I can test my debugging kernel? Thanks, Mike H. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PAE removal patch for testing
Do you mean RELENG_4 rather than RELENG_4_8? Would this affect an single processor AMD Athlon? I have had a few reboots in this time frame and have been worrying about my hardware... - Mike H. If you're one of the people who has cvsup'd to 4.8-stable since August 8th and you've since begun to experience panics on a previously stable system, please apply the attached patch and see if your previous stability has been restored. Please tell me your results. Thanks, Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: system slowdown - vnode related
I'll try this if I can tickle the bug again.
I may have just run out of freevnodes - I only have about 1-2000 free
right now. I was just surprised because I have never seen a reference
to tuning this sysctl.
- Mike H.
On Tue, 2003-05-27 at 11:09, Matthew Dillon wrote:
I'm a little confused. What state is the vnlru kernel thread in? It
sounds like vnlru must be stuck.
Note that you can gdb the live kernel and get a stack backtrace of any
stuck process.
gdb -k /kernel.debug /dev/mem (or whatever)
proc N(e.g. vnlru's pid)
back
All the processes stuck in 'inode' are likely associated with the
problem, but if that is what is causing vnlru to be stuck I would expect
vnlru itself to be stuck in 'inode'.
unionfs is probably responsible. I would not be surprised at all if
unionfs is causing a deadlock somewhere which is creating a chain of
processes stuck in 'inode' which is in turn causing vnlru to get stuck.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
:
:On Mon, 26 May 2003, Mike Harding wrote:
:
: Er - are any changes made to RELENG_4_8 that aren't made to RELENG_4? I
: thought it was the other way around - that 4_8 only got _some_ of the
: changes to RELENG_4...
:
:Ack, my fault ... sorry, wasn't thinking :( RELENG_4 is correct ... I
:should have confirmed my settings before blathering on ...
:
:One of the scripts I used extensively while debugging this ... a quite
:simple one .. was:
:
:#!/bin/tcsh
:while ( 1 )
: echo `sysctl debug.numvnodes` - `sysctl debug.freevnodes` - `sysctl
debug.vnlru_nowhere` - `ps auxl | grep vnlru | grep -v grep | awk '{print $20}'`
: sleep 10
:end
:
:which outputs this:
:
:debug.numvnodes: 463421 - debug.freevnodes: 220349 - debug.vnlru_nowhere: 3 - vlruwt
:
:I have my maxvnodes set to 512k right now ... now, when the server hung,
:the output would look something like (this would be with 'default' vnodes):
:
:debug.numvnodes: 199252 - debug.freevnodes: 23 - debug.vnlru_nowhere: 12 - vlrup
:
:with the critical bit being the vlruwt - vlrup change ...
:
:with unionfs, you are using two vnodes per file, instead of one in
:non-union mode, which is why I went to 512k vs the default of ~256k vnodes
:... it doesn't *fix* the problem, it only reduces its occurance ...
:___
:[EMAIL PROTECTED] mailing list
:http://lists.freebsd.org/mailman/listinfo/freebsd-stable
:To unsubscribe, send any mail to [EMAIL PROTECTED]
:
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
What changed -STABLE in May 2002 with disks?
I bought a Asus A7V133 and am apparently having stability problems. The problem only manifests with cvsup - I get a Treelist error and have to delete the cvsup files. This does not happen all the time, just occasionally. I bought the system in 8/2001 but did not notice any problems until 5/2002 - I was wondering if there was a change to -STABLE around then that might be causing me problems. I am naseous after reading about all of the A7V133/Via 686B southbridge issues. Thanks, Mike H. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Need instructions: build kernel on one machine; install on another
I can validate that this works - one way you can automate this is to put the KERNCONF definition in /etc/make.conf. We used this to bulk update a farm of SMP and uniprocessor systems, the SMP kernel was different for us. One thing that can bite you is _other_ things in /etc/make.conf - like if you use NO_SENDMAIL=yes in the base system - if /etc/make.conf doesn't have the same options in the install systems the install will fail. Likewise for kerberos. I don't know what can be done about CPU variants unless you have a relatively homogenous setup. What worked best for us was to keep /etc/make.conf as short as possible, even if all of the systems ended up getting the games directory installed... - Mike H. Date: Tue, 13 Aug 2002 10:35:14 -0400 Cc: [EMAIL PROTECTED] From: Chen Xu [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] X-Loop: FreeBSD.ORG X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 X-Spam-Level: On Tuesday, August 13, 2002, at 10:20 AM, Dmitry Agafonov wrote: We have compiled kernels (make buildkernel KERNCONF=LALALA) on one machine, and then after nfs-mounting /usr/src and /usr/obj to target machine - make installkernel KERNCONF=LALALA This works fine and is very good for poor-cpu/ram machines :) The question still remains - can one build a number of kernels and then install them? This will save some time on updating a number of machines: 3 steps (cvsup'ing and world and kernel(s) building) may be fully automated. I don't see why you cann't do it for many machines. One can just make buildkernel KERNCONF=LALALA ... make buildkernel KERNCONF=ZAZAZA then nfs mount to each machine to installkernel. Only problem is that you have to do `installkernel KERNCONF=$cornel_config` on each target boxes, which makes fully auto a problem. \ Chen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
another high hz issue
just noticed this after bumping HZ to 1000: $sysctl -a ... net.inet.tcp.keepidle: -1389934 ... I don't know if the display is overflowed, or the display, but either way it's a little confusing... - Mike H. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: HTTP_PROXY in /etc/make.conf doesn't make it into the environment
They are, as far as I can tell, incorrect, I have been using FETCH_ENV= HTTP_PROXY=http://127.0.0.1:3128/ for a while in /etc/make.conf. Note that the syntax is different than 4.4, and it caused a bit of stir during our recent OS upgrades to 4.5. - Mike H. From: Patrick M. Hausen [EMAIL PROTECTED] Date: Thu, 31 Jan 2002 14:19:04 +0100 (CET) Sender: [EMAIL PROTECTED] X-Loop: FreeBSD.ORG Hi all! In /etc/defaults/make.conf there are sample entries suggesting that you could set HTTP_PROXY or FTP_PROXY in /etc/make.conf and have fetch et. al. honour it - like when installing ports. Unfortunately this has no effect at all on the operation of make install in some port's directory. You have to setenv these values for fetch to work. If this is on purpose, why are these sample entries in /etc/defaults/make.conf? Thanks, Patrick M. Hausen Technical Director -- punkt.de GmbH Internet - Dienstleistungen - Beratung Scheffelstr. 17 a Tel. 0721 9109 -0 Fax: -100 76135 Karlsruhe http://punkt.de To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: IPFW/IPSEC/NAT interaction issues with 4.4, Bug ???
This is a feature - if you don't do this, you can't tell decapsulated
traffic from raw traffic. That was the old config. If you have a
router, you can filter on the inside interface. I suggested inserting
the traffic on a fake interface so you could do more interesting
things like NAT, better filtering, etc, but some KAME folk seemed to
get very upset about this, although I couldn't follow the reasoning...
- Mike H.
X-Envelope-From: [EMAIL PROTECTED]
X-Priority: 3 (Normal)
Date: Thu, 25 Oct 2001 14:06:36 +0200 (CEST)
Organization: FIO holding
From: [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
X-Loop: FreeBSD.ORG
I have similar configuration and same problem.
I have compiled several log messages to my kernel
and it looks as follows:
After EPS decapsulation packet is re-injected to input queue
and then processed by ip_input.
On line 402 ( ip_input.c, 4.4-RELEASE )
is
if (ipsec_gethist(m, NULL ))
goto pass;
Condition is true and firewall skipped.
Is it feature or bug?
Vita
On 23-Oct-2001 Barry Irwin wrote:
I have had no luck with this on the ipfw or KAME lists : maybe someone here
can help , I have a horrible feeling that I have stumbled across a rather
nasty bug.
Hi All
I'm hoping someone here can shed some light on a problem I came across this
morning. I have two VPN gateways connected to cisco VPN concentrators.
These are running Freebsd 4.2-RELEASE and 4.4-RELEASE. The 4.2 based
gateway has been functioning without hastles for a while now. however when
I configured the 4.4 based system this morning, I ran into the problem that
the IP packets seem to ne be being re-injected into the firewall ruleset
after the ESP decapsulation. The firewall rulesets are identicle between
the systems. This re-injection is neccessary for me to be able to then
place the packet into a divert socket feeding natd, and from there onto the
client machines behind the VPN gateway.
Network diagram is as follows:
[SERVER] - [FW] - [VPNC] --{INTERNET}-- [FBSD VPN GW/FW] -- [CLIENT]
I can connect fine from the firewall itself to the SERVER.
bash-2.05# telnet S.S.S.22 2300
Trying S.S.S.22...
Connected to S.S.S.22.
Escape character is '^]'.
^]
telnet q
Connection closed.
The firewall rules in place at this time are:
00040 allow udp from any 500 to any 500
00045 allow esp from any to any
00046 deny ip from S.S.S.22/24 to any
65535 allow ip from any to any
My understanding is that rule 46 would deny the traffic, however an ipfw
show 46 indicates that the rules is NOT matching ANY packets!
bash-2.05# ipfw show 45 46
00045 9 896 allow esp from any to any
00046 0 0 deny ip from 203.20.35.0/24 to any
Connections from the client are correctly natted, and go out, responses
however also seem to be accepted by the FBSD firewall immediately after
decryption.
[bvi@client1 bvi]$ netstat -tn | grep 203
tcp0 1 192.168.10.2:1615 203.20.35.22:2300 SYN_SENT
and on the firewall
Oct 23 18:13:38 off-fw1 /kernel: Connection attempt to TCP B.B.B.8:1615 from
S.S.S.22:2300
Oct 23 18:13:56 off-fw1 last message repeated 2 times
Oct 23 18:14:20 off-fw1 /kernel: Connection attempt to TCP B.B.B.8:1615 from
S.S.S.22:2300
this proves that the packets are getting accepted by default witout the
reinjection after decoding. B.B.B.8 being the IP address of the firewall,
the endpoint of the VPN IPSEC/ESP Tunnel and the Address to which traffic
from the client network is natted. The same setup works fine on the 4.2
system.
My understanding of the packet flow process is:
INet - packet received with ESP - passed through IP firewall ruleset
- packet matching IPSEC SP - YES - Decrypt and re-inject
- NO IS it ipsec - yes discard
- no re-inject
- reinjected packets passed through ipfirewall again
- ipfw passes packets off to NAT and things WORK :
With 4.4
The process should work as above, however the packet appears to being
accepted by the host as soon as it has been decrypted.
Have checked the sysctls for ipsec, and the are the same, except for the
adddition of the following one on the 4.4 box (which is undocumented??)
net.inet.ipsec.esp_randpad: -1
Full sysctl output from the 4.4 box is:
bash-2.05# sysctl -a | grep ipsec
net.inet.ipsec.def_policy: 1
net.inet.ipsec.esp_trans_deflev: 1
net.inet.ipsec.esp_net_deflev: 1
net.inet.ipsec.ah_trans_deflev: 1
net.inet.ipsec.ah_net_deflev: 1
net.inet.ipsec.ah_cleartos: 1
net.inet.ipsec.ah_offsetmask: 0
Re: dirpref gives massive performance boost
So it sounds like there would be some benefit in tar'ing and untarring /usr/local, /usr/ports, /usr/src, etc. which will be less disruptive... Thanks! - Mike H. X-Authentication-Warning: cwsys.cwsent.com: smtpd set sender to cy@cwsys using -f Reply-To: Cy Schubert - ITSD Open Systems Group [EMAIL PROTECTED] From: Cy Schubert - ITSD Open Systems Group [EMAIL PROTECTED] X-Sender: schubert Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Date: Sun, 30 Sep 2001 08:49:47 -0700 Sender: [EMAIL PROTECTED] X-SpamBouncer: 1.4 (8/24/01) X-SBClass: OK In message [EMAIL PROTECTED], Mike Harding writes: Um - what about my question? Is the newfs necessary? Repartitioning, backup, and restore also require a backup medium, etc. The more of your filesystem that has had its files allocated using the new dirpref, the greater the benefit. There was a comment made earlier in another thread on another list (see archives) that the new dirpref has the risk of greater fragmentation. There were no responses to the comment. I'm not sure whether this is just a concern someone had or whether the risk is real. The fact that there were no replies to that comment seems to indicate we just don't know yet. In some OpenBSD mailing list archives (search Google) there were comments about dirpref + softupdates being 60x faster than UFS without the two features. Regards, Phone: (250)387-8437 Cy SchubertFax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: [EMAIL PROTECTED] Open Systems Group, ITSD Ministry of Management Services Province of BC To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Default user directory (adduser) filemode
'adduser' is a perl script, search it for '755' and you will find where the permissions are set, it's trivial to change in the source, although logically this could be a configuration parameter. The script is in /usr/sbin/adduser. - Mike H. Date: Thu, 13 Sep 2001 09:17:51 -0400 (EDT) From: Kenneth W Cochran [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] List-ID: freebsd-stable.FreeBSD.ORG List-Archive: http://docs.freebsd.org/mail/ (Web Archive) List-Help: mailto:[EMAIL PROTECTED]?subject=help (List Instructions) List-Subscribe: mailto:[EMAIL PROTECTED]?subject=subscribe%20freebsd-stable List-Unsubscribe: mailto:[EMAIL PROTECTED]?subject=unsubscribe%20freebsd-stable X-Loop: FreeBSD.ORG Precedence: bulk Hello -stable: I notice that when I add a user to FreeBSD, either from adduser or from /stand/sysinstall -- UserAdd(sp?), the default filemode of the user's home directory is 755. So far, I can't find (something like) a config-option for this (i.e., in /etc/adduser.conf). Is this a bug or a feature(tm)? :) OS is -stable (RELENG_4), as of 8 September 2001. Thanks, -kc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: mass uninstall all ports?
It's nice, but I have had it burn my ports so bad I had to start over. Gnome seemed to confuse it. I have had this happen twice and will use portupgrade after I hear people saying nice things about it for a while. - Mike H. Date: Thu, 12 Jul 2001 15:22:05 -0700 From: Kris Kennaway [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Content-Type: multipart/signed; micalg=pgp-md5; protocol=application/pgp-signature; boundary=HcAYCG3uE/tztfnV Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: [EMAIL PROTECTED] List-ID: freebsd-stable.FreeBSD.ORG List-Archive: http://docs.freebsd.org/mail/ (Web Archive) List-Help: mailto:[EMAIL PROTECTED]?subject=help (List Instructions) List-Subscribe: mailto:[EMAIL PROTECTED]?subject=subscribe%20freebsd-stable List-Unsubscribe: mailto:[EMAIL PROTECTED]?subject=unsubscribe%20freebsd-stable X-Loop: FreeBSD.ORG Precedence: bulk --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 12, 2001 at 03:05:12PM -0700, abram olson wrote: I just updated from 4.3 release to 4.3 stable. My entire system is built via ports. I want to make some updates but I keep running into endless dependency chains. I'm doing a=20 Look into portupgrade in the ports collection, which does a superb job of upgrading ports and dependencies in the correct order. Kris --HcAYCG3uE/tztfnV Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7TiMNWry0BWjoQKURAsABAKCOs+LzqQ7Xk4HuOoqfdOHH5fh66QCfV067 H5CSDVt+nXKhZ6LwKrdmTkI= =OUsp -END PGP SIGNATURE- --HcAYCG3uE/tztfnV-- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: natd blues
Try ipnat - it's part of ipfilter. It runs in the kernel so it might be a bit faster. - Mike H. Date: Mon, 21 May 2001 09:14:36 -0400 From: Normand Leclerc [EMAIL PROTECTED] User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20010131 Netscape6/6.01 X-Accept-Language: en Content-Type: text/plain; charset=us-ascii; format=flowed Sender: [EMAIL PROTECTED] List-ID: freebsd-stable.FreeBSD.ORG List-Archive: http://docs.freebsd.org/mail/ (Web Archive) List-Help: mailto:majordomo?subject=help (List Instructions) List-Subscribe: mailto:majordomo?subject=subscribe%20freebsd-stable List-Unsubscribe: mailto:majordomo?subject=unsubscribe%20freebsd-stable X-Loop: FreeBSD.ORG Precedence: bulk It looks like my natd is slowing down my cable internet transfers. When running, I can't get the speed I get when natd isn't around (tested downloading 20 megs with natd diverting packets from gateway and then tested with an extra ipfw pass all rule before divert). With divert, ETA is around 30 mins, without: 8 mins! And I tested it more than once. I didn't have this kind of slowdown on 3.4 ... Is there a kernel option that can slow down ipfw diverts like that? Normand Leclerc [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Apache 1.3.19/Mod Perl 1.25 and 4.3 RC
I think you will find that all of these ports are up to date. You
might at least try them to see if they have any patches that you need
to apply.
If you are doing the work to bring in up to date material and update
it then I would consider contributing to the ports system so that
others may benefit from your work and you can also get bug reports
from the field. I have found that ports maintainers, if available,
are generally receptive to update information. Ports maintainers
'gone missing' is about the only problem I have had.
We use ports almost exclusively, even if we have to make our own
modified ports to bring in patches. The overall benefits are
enormous. As far as core services go, I think you will find that the
web related ports are brought up to date within a few days. I would
have a problem with core services being run on a one-off installation.
I don't have anything special in make.conf, but here it is anyway...
CFLAGS= -O -pipe
NOPROFILE= true
#INSTALL=install -C
#NO_SENDMAIL= true# do not build sendmail and related programs
COPTFLAGS= -O -pipe
COMPAT22= yes
COMPAT3X= yes
HAVE_MOTIF= yes
USA_RESIDENT=YES
FETCH_BEFORE_ARGS=-p
CPUTYPE=i586
- Mike Harding
Date: Sun, 25 Mar 2001 22:21:25 -0800
From: Sean Chittenden [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="H+4ONPRPur6+Ovig"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
X-PGP-Key: 0x1EDDFAAD
X-PGP-Fingerprint: C665 A17F 9A56 286C 5CFB 1DEA 9F4F 5CEF 1EDD FAAD
X-Web-Homepage: http://sean.chittenden.org/
X-SpamBouncer: 1.3 (1/18/00)
X-SBClass: OK
--H+4ONPRPur6+Ovig
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Ports are nice, but they lag a little in release dates and I
try not to depend on them for core services that I use.
What is the contents of your /etc/make.conf file? -sc
On Sun, Mar 25, 2001 at 10:11:18PM -0800, Mike Harding wrote:
Delivered-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
From: Mike Harding [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
In-reply-to: [EMAIL PROTECTED] (message from Eric Dannewit=
z on
Sun, 25 Mar 2001 17:35:01 -0800)
Subject: Re: Apache 1.3.19/Mod Perl 1.25 and 4.3 RC
Date: Sun, 25 Mar 2001 22:11:18 -0800 (PST)
X-Loop: FreeBSD.ORG
Precedence: bulk
=20
=20
I am running mod_perl, mod_php4 on apache 1.3.19 with ssl and it seems
to work fine.
=20
In fact, I just rebuilt the whole thing and it is still fine...
=20
Are you using the ports? There is a reason for them you know...
=20
- Mike H.
=20
Date: Sun, 25 Mar 2001 17:35:01 -0800
From: Eric Dannewitz [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Organization: Jazz-Sax
X-Accept-Language: en,pdf
Content-Type: text/plain; charset=3Dus-ascii
Sender: [EMAIL PROTECTED]
X-Loop: FreeBSD.ORG
Precedence: bulk
=20
Ok, I was having problems with Apache 1.3.19 and mod_perl 1.25 with Fr=
eeBSD 4.3
RC (cvsuped from last night).
The perl libraries and CPAN seem uptodate.
=20
I downloaded the source from apache.org and untarred it into /usr/src/=
. I cd to
/usr/src/mod_perl-1.25 and typed perl Makefile.PL APACHE_SRC=3D/usr/sr=
c/apache
DO_HTTPD=3D1 USE_APACI=3D1 PERL_MARK_WHERE=3D1 EVERYTHING=3D1
APACHE_PREFIX=3D/usr/local/apache
this runs ok. As does make. A 'make test' produces this error. Any att=
empt to
run apachectl start results in a core dump.
=20
Ideas? Sorry for the length of the post, but I've been at this for a w=
hile.
=20
freebsd# make test
(cd ../apache PERL5LIB=3D/usr/src/mod_perl-1.25/lib make)
=3D=3D=3D src
=3D=3D=3D src/os/unix
=3D=3D=3D src/os/unix
=3D=3D=3D src/ap
=3D=3D=3D src/ap
=3D=3D=3D src/main
=3D=3D=3D src/main
=3D=3D=3D src/lib
=3D=3D=3D src/lib
=3D=3D=3D src/modules
=3D=3D=3D src/modules/standard
=3D=3D=3D src/modules/standard
=3D=3D=3D src/modules/perl
=3D=3D=3D src/modules/perl
=3D=3D=3D src/modules
cc -c -I. -I/usr/libdata/perl/5.00503/mach/CORE -I./os/unix -I./include
-funsigned-char -DMOD_PERL -DUSE_PERL_SSI -pthread -DNO_DL_NEEDED
-DPERL_MARK_WHERE=3D1 `./apaci` modules.c
cc -c -I. -I/usr/libdata/perl/5.00503/mach/CORE -I./os/unix -I./include
-funsigned-char -DMOD_PERL -DUSE_PERL_SSI -pthread -DNO_DL_NEEDED
-DPERL_MARK_WHERE=3D1 `./apaci` buildmark.c
cc -funsigned-char -DMOD_PERL -DUSE_PERL_SSI -pthread -DNO_DL_NEEDED
-DPERL_MARK_WHERE=3D1 `./apaci` -o httpd b
Re: ipf idiot wants to roam
It will work, you just won't have a working firewall. I filed a PR about this after discovering that ipf wasn't filtering _any_ packets coming in. Yech. If you have a static address it may not be an issue. I use dial-on-demand as well, but with a dynamic address. - Mike H. Date: Mon, 26 Mar 2001 12:20:40 +0100 From: Rasputin [EMAIL PROTECTED] Reply-To: Rasputin [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Sender: [EMAIL PROTECTED] X-Loop: FreeBSD.ORG Precedence: bulk * Mike Harding [EMAIL PROTECTED] [010325 20:06]: You can specify interfaces by name in your rules - but you have to issue 'ipf -y' to sync up with interface address changes. I've done this with a dial-up line by putting 'ipf -y' in /etc/rc.network at the end of pass 1. This file should be updated in the distribution so that this happens automatically or ppp users may not see any packet filtering! Well I've been using ipf on a dialup for a year now, and don't have an ipf -y anywhere in my config files. Maybe it's because I use tun0 demand-dialling? Or is the manpage (man 1 ipf) correct? -y (SOLARIS 2 ONLY) Manually resync the in-kernel ^^^ interface list maintained by IP Filter with the current interface status list. Either the manpage or the ppp linkup fiels should be modified, I reckon. -- Rasputin Jack of All Trades :: Master of Nuns To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: KDE 2.1
I had built this and run it under X4.02 until somebody broke it recently - it no longer builds, complaining about pthreads. - Mike Harding Date: Wed, 14 Mar 2001 08:42:42 -0500 From: "Brandon S. Allbery KF8NH" [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Sender: [EMAIL PROTECTED] X-Loop: FreeBSD.ORG Precedence: bulk On Wednesday, March 14, 2001 10:52:42 +0200, Irvine Short [EMAIL PROTECTED] wrote: +- | It now compiles straight out of the box, thanks for all the work guys! | | Now though it hangs a long time on "initialising peripherals" and then | gives me a plain grey screen. | | Anyone using it seccuessfully on FreeBSD? +---8 I just built it... well, "just" meaning "it was compiling from Saturday morning until the middle of yesterday on my ancient dual-P200. I had similar hanging symptoms (kdeinit crashed, aborting startup) until I went back and rebuilt libpng. You might check to see if you have a kdeinit.core and a stack backtrace shows it dying in the PNG routines. -- brandon s. allbery [os/2][linux][solaris][japh] [EMAIL PROTECTED] system administrator[WAY too many hats] [EMAIL PROTECTED] electrical and computer engineering KF8NH carnegie mellon university ["better check the oblivious first" -ke6sls] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Major upgrade
Having done this before I would HIGHLY recommend doing a clean install and restoring the 'good stuff' from backup. You can do the upgrades in place, but it takes a while, and you have to do it in steps, and if you misstep you may blow up the box, and so on. You should know how to do clean installs and backups anyways. Since you have 2 machines, assuming sufficient clear disk space on each, you can back one up onto the other and so on. - Mike H. From: "Steffen Vorrix" [EMAIL PROTECTED] Date: Wed, 14 Mar 2001 10:44:34 -0500 Content-Type: multipart/alternative; boundary="=_NextPart_000_000B_01C0AC73.C2523D80" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-MDRemoteIP: 208.60.70.195 X-Return-Path: [EMAIL PROTECTED] X-MDaemon-Deliver-To: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] X-Loop: FreeBSD.ORG Precedence: bulk This is a multi-part message in MIME format. --=_NextPart_000_000B_01C0AC73.C2523D80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have been tracking this list for about 3 or 4 weeks now, and I have = learned alot more about FreeBSD then I thought I might. I have = successfully upgrade my two home FreeBSD machines from 4.2 REL to the = current stable version, and everything went just fine. However, I now = need to upgrade 2 production machines for my employer, and these have to = go as painlessly as possible. The problem is that these machines are = 3.4 REL. I have looked through the mail over the past weeks, and I have = found people mention that 3.4 to 4 can have some gotcha's associated = with it, but I haven't seen anything specifically mentioned. Are there = things that I need to watch out for? The reference that I am referring = to was a thread regarding remotely updating servers. While this was = frowned upon by almost everyone in the list, one person specifically = mentioned that remote updating would be a problem from a 3.x to a 4.x. = I don't plan to do any remote updating, but I want to be sure there = aren't other things I need to watch out for. Thanks a bunch. Chris Schremser --=_NextPart_000_000B_01C0AC73.C2523D80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" HTMLHEAD META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1" META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR STYLE/STYLE /HEAD BODY bgColor=3D#ff DIVFONT face=3DArial size=3D2I have been tracking this list for = about 3 or 4=20 weeks now, and I have learned alot more about FreeBSD then I thought I=20 might.nbsp; I have successfully upgrade my two home FreeBSD machines = from 4.2=20 REL to the current stable version, and everything went just fine.nbsp; = However,=20 I now need to upgrade 2 production machines for my employer, and these = have to=20 go as painlessly as possible.nbsp; The problem is that these machines = are 3.4=20 REL.nbsp; I have looked through the mail over the past weeks, and I = have found=20 people mention that 3.4 to 4 can have some gotcha's associated with it, = but I=20 haven't seen anything specifically mentioned.nbsp; Are there things = that I need=20 tonbsp;watch out for?nbsp; The reference that I am referring to was a = thread=20 regarding remotely updating servers.nbsp; While this was frowned upon = by almost=20 everyone in the list, one person specifically mentioned that remote = updating=20 would be a problem from a 3.x to a 4.x.nbsp; I don't plan to do any = remote=20 updating, but I want to be sure there aren't other things I need to = watch out=20 for./FONT/DIV DIVFONT face=3DArial size=3D2/FONTnbsp;/DIV DIVFONT face=3DArial size=3D2Thanks a bunch./FONT/DIV DIVFONT face=3DArial size=3D2/FONTnbsp;/DIV DIVFONT face=3DArial size=3D2Chris = Schremser/FONT/DIV/BODY/HTML --=_NextPart_000_000B_01C0AC73.C2523D80-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: KDE
2.0 has been around for a bit, 2.1 made an appearance last night but does not build, and least on my machine. - Mike H. Date: Tue, 27 Feb 2001 09:52:25 + From: Antony T Curtis [EMAIL PROTECTED] Organization: Abacus Polar PLC (UK) X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Sender: [EMAIL PROTECTED] X-Loop: FreeBSD.ORG Precedence: bulk Just wondering if KDE 2.x would make an appearence in the FreeBSD 4.3 release? -- ANTONY T CURTIS Tel: +44 (1635) 36222 Abacus Polar Holdings Ltd Fax: +44 (1635) 38670 Somebody ought to cross ball point pens with coat hangers so that the pens will multiply instead of disappear. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Fatal Tarp in 4.1.1
Just another data point - I also got 2 'Fatal Trap 12 - supervisor page not present' followed by a system lockup. Both appeared to have occurred while 'dump' was backing up the system. This happened with 4.1.1 - it had never happened before this and hasn't happened since I upgraded the system to -STABLE (fingers crossed). I'll post if it happens again, I notice that there were changes made to the SCSI drivers. This is on a dual processor board with an Adaptec 7896/7897 SCSI interface. - Mike H. Date: Fri, 13 Oct 2000 07:46:37 -0700 From: [EMAIL PROTECTED] Cc: Stable [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Sender: [EMAIL PROTECTED] X-Loop: FreeBSD.ORG Precedence: bulk X-RULES: lists On Wed, Oct 11, 2000 at 09:13:43AM -0800, Jason Neumann wrote: Greetings, A few days ago I received a 'Fatal Trap 12' followed by a spontaneous reboot on 4.1.1-stable. My installed src was up to date as of Sept. 29, 2000. A common cause of this is loading modules which are out of date with respect to the kernel you are running, e.g. the linux module which is loaded at boot. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Recent ports behavior (fetch)
Recently I have noticed that one of the following happens if you interrupt a fetch during a ports 'make' (say because you have a dialup and the port is downloading an 18M file): 1. Fetch runs in the background and you have to stop it multiple times. 2. Fetch leaves a truncated file in /usr/ports/distfiles which much be deleted by hand. Is there any chance for a return to the old behavior (cntl-C stops fetch, file deleted) for 4.1? It's a lot friendlier for us dial-up folk... - Mike H. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: ssh and librsaintl
This port is still broken, at least for me using internat code and cvsup as of yesterday. I have not been able to get it to work for a long time... netcom1# make === Extracting for librsaintl-1.1 Checksum OK for librsaintl/rsa_eay.c. Checksum OK for librsaintl/rsa_err.c. Checksum OK for librsaintl/rsa_intlstubs.c. Checksum OK for librsaintl/cryptlib.h. === Patching for librsaintl-1.1 === Configuring for librsaintl-1.1 === Building for librsaintl-1.1 Warning: Object directory not changed from original /usr/ports/security/librsaintl/work cc -march=k6 -O -pipe -DTERMIOS -DANSI_SOURCE -DNO_IDEA -DL_ENDIAN -DDEVRANDOM=\"/dev/urandom\" -c rsa_err.c -o rsa_err.o rsa_err.c:77: `RSA_F_RSA_NULL' undeclared here (not in a function) rsa_err.c:77: initializer element is not constant rsa_err.c:77: (near initialization for `RSA_str_functs[8].error') rsa_err.c:115: `RSA_R_INVALID_MESSAGE_LENGTH' undeclared here (not in a function) rsa_err.c:115: initializer element is not constant rsa_err.c:115: (near initialization for `RSA_str_reasons[16].error') rsa_err.c:124: `RSA_R_RSA_OPERATIONS_NOT_SUPPORTED' undeclared here (not in a function) rsa_err.c:124: initializer element is not constant rsa_err.c:124: (near initialization for `RSA_str_reasons[25].error') *** Error code 1 Stop in /usr/ports/security/librsaintl/work. *** Error code 1 Stop in /usr/ports/security/librsaintl. *** Error code 1 Stop in /usr/ports/security/librsaintl. *** Error code 1 Stop in /usr/ports/security/librsaintl. netcom1# X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Sun, 2 Jul 2000 23:58:30 -0700 (PDT) From: Kris Kennaway [EMAIL PROTECTED] Cc: Ray Kohler [EMAIL PROTECTED], [EMAIL PROTECTED] Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [EMAIL PROTECTED] X-Loop: FreeBSD.ORG Precedence: bulk X-RULES: lists On Sun, 2 Jul 2000, Kris Kennaway wrote: anyone have any clues? The port is broken, someone needs to fix it. Actually, having said that it doesnt seem as if the port is broken, at least for me (well, there were two dumb typos in the MASTER_SITES which were my fault, but they won't stop it from building). Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Softupdates disappears?
Now I am totally confused. There is a /usr/src/sys/ufs/ffs/README file I see via cvsweb which I don't have as well, and the two files you are supposed to link appear to already be in the directory, but I don't fetch them. There was a change on Jun 22 which is when I started seeing a problem. I assume that changes are being done for 3.5 release - regardless something is fishy in cvs/cvsup land and/or the instructions need to get updated. Could somebody with more of a clue check this out? Anybody with a setup like mine (4.0-STABLE) who does a CVSUP and kernel build will lose softupdates. I have a completely generic stable-supfile so I think this should be easy to test... - Mike Harding Date: Thu, 22 Jun 2000 04:08:32 -0400 (EDT) From: Adrian Filipi-Martin [EMAIL PROTECTED] Reply-To: Adrian Filipi-Martin [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [EMAIL PROTECTED] X-Loop: FreeBSD.ORG Precedence: bulk X-RULES: lists On Wed, 21 Jun 2000, Mike Harding wrote: I just did a 'cvsup' of 4.0-RELENG and the soft update links in /usr/src/sys/ufs/ffs got deleted. Created them again, ran cvsup again, and they got deleted again. Anyone know what's going on? - Mike H. Did the files just disapear, or did they change locations? I haven't cvsup'd today, so I cannot anwser this for certain, but I suspect this is what hapened: Kirk relaxed the license on thge softupdate files today, and I suspect they have simply moved. Worst case, they only got checked back in on -CURRENT. Adrian -- [ [EMAIL PROTECTED] -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Softupdates disappears?
I just did a 'cvsup' of 4.0-RELENG and the soft update links in /usr/src/sys/ufs/ffs got deleted. Created them again, ran cvsup again, and they got deleted again. Anyone know what's going on? - Mike H. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Softupdates disappears?
I have been doing cvsup at least weekly for at long time and this is the first time that this has happened. - Mike H. X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Jun 2000 13:48:04 +0930 (CST) Sender: [EMAIL PROTECTED] From: "Daniel O'Connor" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] X-RULES: lists On 22-Jun-00 Mike Harding wrote: I just did a 'cvsup' of 4.0-RELENG and the soft update links in /usr/src/sys/ufs/ffs got deleted. Created them again, ran cvsup again, and they got deleted again. Anyone know what's going on? Probably because you told cvsup it should delete things it doesn't know about.. And it doesn't know about the symlinks :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Broken final script in defaults/rc.conf?
I got on Asmodai about this - /etc/defaults/rc.conf and /etc/rc were out of sync in 4.0 stable. He has fixed it. - Mike Harding Date: Sun, 28 May 2000 14:39:21 -0700 From: Doug Barton [EMAIL PROTECTED] Organization: Triborough Bridge Tunnel Authority X-Accept-Language: en Cc: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Sender: [EMAIL PROTECTED] X-Loop: FreeBSD.ORG Precedence: bulk X-RULES: lists "Boris B. Samorodov" wrote: Hi! FreeBSD 4.0-STABLE: Cvsup'ed today evening + make world + mergemaster = subj? Final scripting in /etc/default/rc.conf was changed. As a result we have /etc/rc.conf /etc/rc.conf.local that are not processed. Am I right? Well, it's been working with the most recent changes for a month in 5.0-Current, so I suspect that something in your situation is different from the majority. First, try cvsup'ing and running mergemaster again to see if anything is different. It's possible that you updated your source at a time period when not all of the relevant files in rc-land had been updated. btw in my case I changed default script and all works fine. If that doesn't work, please send me a copy of your /etc/defaults/rc.conf, and your /etc/rc.conf[.local] scripts. I wrote the new code for sourcing the rc.conf's, so I may be able to spot the problem. You could also send them to the list if you're more comfortable with that. Good luck, Doug -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: ftp(1) breakage w/ passive mode?
Actually, since FTP proxies have come up - does anyone know how to get 'fetch' to use 'squid' as an FTP proxy? I thought I had set this up in the past, but maybe it was ncftp. Anyway, when I do the obvious, it says 'wrong state' or somesuch. - Mike Harding Date: Sun, 28 May 2000 19:03:27 -0400 From: Will Andrews [EMAIL PROTECTED] Cc: FreeBSD Current [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii X-Operating-System: FreeBSD 5.0-CURRENT i386 Sender: [EMAIL PROTECTED] X-Loop: FreeBSD.ORG Precedence: bulk X-RULES: lists [ i'm not on -stable, but am on -current ] Hi all, I'm having trouble with ftp(1) in passive mode on 4-STABLE and 5-CURRENT: FreeBSD 4.0-STABLE #0: Sat May 27 10:26:43 EDT 2000 FreeBSD 5.0-CURRENT #1: Fri May 26 04:52:03 EDT 2000 2 5002-0 (18:46:17) [will@radon ~]% ftp ftp://ftp.FreeBSD.org/pub/ Connected to ftp.freesoftware.com. [..] 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. 200 Type set to I. 250 CWD command successful. 250 CWD command successful. ftp ls 500 'EPSV': command not understood. 500 'LPSV': command not understood. Passive mode refused. ftp However, it works on some servers: 2 5007-0 (18:49:16) [will@radon /usr/src/usr.bin/ftp]% ftp ftp://ftp.cs.ubc.ca/ Connected to ftp.cs.ubc.ca. [..] 200 Type set to I. 250 CWD command successful. ftp ls 227 Entering Passive Mode (142,103,6,49,233,148) 150 Opening ASCII mode data connection for /bin/ls. total 28 drwxrwxr-x 10 root other512 Jan 17 1996 . drwxrwxr-x 10 root other512 Jan 17 1996 .. lrwxrwxrwx 1 root other 7 Dec 27 1995 bin - usr/bin lrwxrwxrwx 1 root other 1 Dec 27 1995 cs - . [..] ftp quit So it seems there's something quite broken in the code. My suspect is rev 1.25 of ftp.c and associated commits. -- Will Andrews [EMAIL PROTECTED] GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP t++ 5 X++ R+ tv+ b++ DI+++ D+ G+ e- h! r--+++ y? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 4.0-RELEASE to 4.0-STABLE upgrade
having used mergemaster "billions and billions" of times: you can run it from any directory. Date: Mon, 29 May 2000 06:27:46 +0200 From: Szilveszter Adam [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i Sender: [EMAIL PROTECTED] X-Loop: FreeBSD.ORG Precedence: bulk X-RULES: lists On Sun, May 28, 2000 at 05:46:51PM -0400, Mbwa wrote: Have you also upgraded the Handbook?:-) It is now possible by going to an ftp mirror site and cd-ing to /pub/FreeBSD/doc/your language/ and downloading the docs in the wanted format. I only ask this because the new docs should have pointers to mergemaster... I just downloaded the book.html.zip from ftp.freebsd.org and I didn't notice any reference to mergemaster. Where can I get more info regarding this utility OK, I was caught at this:-) The Handbook is still not updated to reflect this (although I remembered otherwise) so you should see man page for mergemaster(8)... it is in the base system for 3.4 for sure (and of course above) but normally you do not need much documentation for using it: cd to /usr/src/etc and say 'mergemaster'. It will build a temproot environment under /var/tmp/temproot just as the Handbook does tell you but you do not have to do it by hand and also it automatically diffs the files in /etc and the temproot and if it spots any differences, you are given the choice of installing the new file as is, to keep the old file (eg you should do this with master.passwd) or to merge the two. It can also leave the file untouched and then you can finish it up later by hand. After it is finished, it asks if you want to delete the old temproot. (which you normally want to do, unless there are files you want to deal with by hand.) -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: X11
I was just bit by this as well - I rebuilt my X server and was unable
to log in...
- Mike Harding
Reply-To: Cy Schubert - ITSD Open Systems Group [EMAIL PROTECTED]
From: Cy Schubert - ITSD Open Systems Group [EMAIL PROTECTED]
X-OS: FreeBSD 3.4-RELEASE
X-Sender: cy
Cc: [EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii
Date: Sun, 26 Dec 1999 12:24:10 -0800
Sender: [EMAIL PROTECTED]
X-Loop: FreeBSD.ORG
Precedence: bulk
X-RULES: lists
In message [EMAIL PROTECTED], Kev
in Entringer writes:
Thanks for the suggestion. I suspect that this was the problem, however X
is still not working. The following no happens:
Dec 26 11:29:13 discord login: ROOT LOGIN (root) ON ttyv3
Dec 26 11:29:14 discord Xwrapper: unable to dlopen(/usr/lib/pam_unix.so)
Dec 26 11:29:14 discord
Xwrapper: [dlerror: /usr/lib/pam_unix.so: Undefined symb
ol "crypt"]
Dec 26 11:29:14 discord Xwrapper: adding faulty
module: /usr/lib/pam_unix.so
It appears that the problem was fixed in -current and not in -stable:
markm 1999/09/30 11:53:34 PDT
Modified files:
lib/libpam/modules/pam_unix Makefile
Log:
Add libcrypt. This previously/coincidentally worked for login,
because login was already linked against it, but others have a
problem.
Revision ChangesPath
1.4 +3 -3 src/lib/libpam/modules/pam_unix/Makefile
Even though the patch is for -current, it applies cleanly to -stable.
Would someone please MFC this.
Kevin, apply the following patch to and rebuild pam_unix. I've
modified the "old" $FreeBSD$ to allow the patch to apply cleanly.
===
RCS file: /home/ncvs/src/lib/libpam/modules/pam_unix/Makefile,v
retrieving revision 1.3
retrieving revision 1.4
diff -p -u -r1.3 -r1.4
--- src/lib/libpam/modules/pam_unix/Makefile 1999/05/08 01:59:27 1.3
+++ /home/ncvs/src/lib/libpam/modules/pam_unix/Makefile 1999/09/30 18:53:34
1.4
@@ -22,7 +22,7 @@
# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
# SUCH DAMAGE.
#
-# $FreeBSD: src/lib/libpam/modules/pam_unix/Makefile,v 1.2.2.1 1999/05/08
21:32:00 jdp Exp $
+# $FreeBSD: src/lib/libpam/modules/pam_unix/Makefile,v 1.3 1999/05/08 01:59:27
jdp Exp $
PAMDIR= ${.CURDIR}/../../../../contrib/libpam
@@ -32,8 +32,8 @@ SRCS= pam_unix.c
CFLAGS+=-Wall
CFLAGS+=-I${PAMDIR}/libpam/include
CFLAGS+=-I${.CURDIR}/../../libpam
-DPADD+= ${LIBUTIL} ${LIBGCC_PIC}
-LDADD+= -lutil -lgcc_pic
+DPADD+= ${LIBUTIL} ${LIBGCC_PIC} ${LIBCRYPT}
+LDADD+= -lutil -lgcc_pic -lcrypt
INTERNALLIB=yes
INTERNALSTATICLIB=yes
Regards, Phone: (250)387-8437
Cy Schubert Fax: (250)387-5766
Sun/DEC Team, UNIX GroupInternet: [EMAIL PROTECTED]
ITSD
Province of BC
"e**(i*pi)+1=0"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: strange named behavior in 3.4-STABLE
It's an issue with the new version of Bind - 8.2.2 seems to ping the network on startup, whereas the previous version did not. I haven't found a way around this behaviour but that doesn't mean there isn't one. I noticed this behaviour when I was an early 8.2 adapter via the ports. - Mike H. Date: Sat, 25 Dec 1999 00:50:01 +0300 From: Lev Serebryakov [EMAIL PROTECTED] X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Sender: [EMAIL PROTECTED] X-Loop: FreeBSD.ORG Precedence: bulk X-RULES: lists Hi, All! I've upgraded from 3.3-STABLE to 3.4-STABLE and notice strange thing: I have ``named'' run on my machine, which have only dial-up Internet connection. I have ``ppp -nat -auto provider'' run too. My named have configured to be primary NS in my network (domain is not registered and IP addresses are from 192.168.xx.xx range). Also, named have ``forward-only'' option and two addresses of my ISP DNS. Whet it was 3.3-STABLE (really -- 3.3-RELEASE with stable kernel) everything works perfectly. PPP doesn't call my ISP until I (or somebody in local network) need connection. But with new system (3.4-RELEASE) ``named'' initiate dial-up just after start! Why new named want to connect when there is no any outgoing packets? How could I disable such behavior? Lev Serebryakov, 2:5030/661.0 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Anticipated release date for 3.4
Did you read the isc release about what the latest patches fix? Pretty scary... Cc: "Jordan K. Hubbard" [EMAIL PROTECTED], [EMAIL PROTECTED] Date: Thu, 18 Nov 1999 15:09:11 -0800 From: "Jordan K. Hubbard" [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] X-Loop: FreeBSD.ORG Precedence: bulk X-RULES: lists I also vote for the new BIND if at all possible. But that hasnt even made it into CURRENT yet. That disqualifies it pretty significantly then. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
