Re: iso numbering
On Mon, 9 May 2005 07:02:07 +0200 Zoran Kolic [EMAIL PROTECTED] wrote: Just a question before 5.4: what would be iso 1 on release? Live system or instalation? Both. -- IOnut Unregistered ;) FreeBSD user ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: examples/etc/make.conf: nocona?
Damian Gerow [EMAIL PROTECTED] writes: Ack. I just noticed that 'pentiumpro' is also mis-spelled 'penitumpro' as well... PR time, I think. No, that was fixed two months ago (rev 1.261) DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RAID 1 with Adaptec SATA 1210SA + FreeBSD 5.4 + ata mkIII OK
Hi Soeren, I have to thank you for the work you put in the ata driver. After patching the 5.4 sources with the new ata mkIII (http://people.freebsd.org/~sos/ATA) I am able to use the RAID 1 with my Adaptec SATA 1210SA. The dmesg (the Adaptec is recognized as Sil 3112 SATA150): FreeBSD 5.4-RELEASE #2: Mon May 9 12:07:51 EEST 2005 ardelean at quasar.physics.uvt.ro:/usr/obj/usr/src/sys/QUASAR ... atapci1: Promise PDC20267 UDMA100 controller port 0xa400-0xa43f,0xa000-0xa003,0x9c00-0x9c07,0x9800-0x9803,0x9400-0x9407 mem 0 d510-0xd511 irq 10 at device 9.0 on pci0 ata2: ATA channel 0 on atapci1 ata3: ATA channel 1 on atapci1 ... atapci2: SiI 3112 SATA150 controller port 0xbc00-0xbc0f,0xb800-0xb803,0xb400-0xb407,0xb000-0xb003,0xac00-0xac07 mem 0xd512100-0xd51211ff irq 5 at device 13.0 on pci0 ata4: ATA channel 0 on atapci2 ata4: SATA connect ready time=0ms ata5: ATA channel 1 on atapci2 ata5: SATA connect ready time=0ms ... ad4: 38166MB Seagate ST340014A 3.04 at ata2-master UDMA100 ad6: 38166MB Seagate ST340014A 3.04 at ata3-master UDMA100 ad8: 190782MB SAMSUNG SP2004C VM100-31 at ata4-master SATA150 ad10: 190782MB SAMSUNG SP2004C VM100-31 at ata5-master SATA150 Waiting 5 seconds for SCSI devices to settle ATA PseudoRAID loaded ar0: 38166MB Promise Fasttrak RAID1 array status: READY ar0: disk0 READY (master) using ad6 at ata3-master ar0: disk1 READY (mirror) using ad4 at ata2-master ar1: 190782MB Adaptec HostRAID RAID1 array status: READY ar1: disk0 READY (master) using ad8 at ata4-master ar1: disk1 READY (mirror) using ad10 at ata5-master Mounting root from ufs:/dev/ar0s1a Is it possible to MFC the ata mkIII from -current to 5-STABLE ? Once again thank you! G. Ardelean West Univ. Of Timisoara Dept. of Theoretical and Computational Physics V. Parvan No.4, Ro-300223, Timisoara, ROMANIA Tel: +40-(0)256-494068 Ext. 203, 201, 108 | Fax: +40-(0)256-496088 Email: ardelean at physics.uvt.ro Copyright 1999-2005 Gheorghe Ardelean. All rights reserved. Duplication and redistribution prohibited without consent of the author. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nss_ldap / top startup
Hi Gavin,
sorry, took some time to test it, but we're currently very busy moving
services to the new machines.
On Wed, Apr 27, 2005 at 08:06:38PM +0100, Gavin Atkinson wrote:
Sorry - even with that patch, I suspect you'll have to either run top with
the -u option, or define RANDOM_PW before recompiling it. If you can, try
both individually, I'd be interested in your finding.
Your patch is just fine, even without defining RANDOM_PW!
I would suggest you file an PR with the patch, it could be like that:
--- CUT HERE ---
#ifndef TOP_NO_NAMELEN
while ((pw = getpwent()) != NULL) {
if (strlen(pw-pw_name) namelength)
namelength = strlen(pw-pw_name);
}
#else
namelength = 15;
#endif
--- CUT HERE ---
In the Makefile there should be something like that:
--- CUT HERE ---
.if defined(TOP_NO_NAMELEN)
CFLAGS+= -DTOP_NO_NAMELEN
.endif
--- CUT HERE ---
If you don't want to file a PR, I would like to ask for permission to
put the changes into a patch and file the PR, I guess there are more
people having lot's of users - and always reading them all and counting
the namelength seems to be eating resources unnecessarily, at leats on
systems with some 10k users.
Thank you,
Oliver
--
| Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin |
| Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ |
| Ich bin das Internet. Sowahr ich Gott helfe. |
| Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
ACPI(pci_link) problem in 5.4-STABLE: TIMEOUT - WRITE_DMA retrying
Submitter-Id: current-users Originator:Eugene Grosbein Organization: Svyaz Service JSC Confidential: no Synopsis: ACPI(pci_link) problem in 5.4-STABLE: TIMEOUT - WRITE_DMA retrying Severity: non-critical Priority: low Category: kern Class: sw-bug Release: FreeBSD 5.4-STABLE i386 Environment: System: FreeBSD dadv.grosbein.pp.ru 5.4-STABLE FreeBSD 5.4-STABLE #1: Sun May 8 21:16:52 KRAST 2005 [EMAIL PROTECTED]:/mnt/old/home/obj/usr/local/src/sys/DADV i386 Description: RELENG_5 (sources of 4 may 2005) runs fine on Iwill BD100+ motherboard (440BX chipset) when ACPI is disabled at boot time. With ACPI enabled, it suffers from delays using ATA drives and the GENERIC kernel prints: ad4: TIMEOUT - WRITE_DMA retrying (2 retries left) LBA=146992553 ad6: TIMEOUT - WRITE_DMA retrying (2 retries left) LBA=2228575 ad4: FAILURE - ATA_IDENTIFY timed out ad6: TIMEOUT - READ_DMA retrying (2 retries left) LBA=7895167 And so on, but no data corruption is observed. How-To-Repeat: Take Iwill BD100+ motherboard, install 5.3-RELEASE and update it to RELENG_5 (boot with ACPI disabled to upgrade). Fix: Unknown. There is a workaround, add to /boot/loader.conf: debug.acpi.disabled=pci_link With this workaround, the problem disappears. Here comes dmesg.boot (custom kernel, ACPI enabled, pci_link disabled, atapicam enabled): Copyright (c) 1992-2005 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.4-STABLE #1: Sun May 8 21:16:52 KRAST 2005 [EMAIL PROTECTED]:/mnt/old/home/obj/usr/local/src/sys/DADV Timecounter i8254 frequency 1193165 Hz quality 0 CPU: Intel Celeron (902.04-MHz 686-class CPU) Origin = GenuineIntel Id = 0x68a Stepping = 10 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 603914240 (575 MB) avail memory = 581259264 (554 MB) npx0: math processor on motherboard npx0: INT 16 interface acpi0: AWARD AWRDACPI on motherboard acpi0: Power Button (fixed) Timecounter ACPI-safe frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 cpu0: ACPI CPU (3 Cx states) port 0x530-0x537 on acpi0 acpi_throttle0: ACPI CPU Throttling on cpu0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0x5000-0x500f,0x4000-0x4041,0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: no PRT entry for 0.7.INTD pcib0: no PRT entry for 0.16.INTA pcib0: no PRT entry for 0.18.INTA agp0: Intel 82443BX (440 BX) host to PCI bridge mem 0xe800-0xebff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pcib0: no PRT entry for 0.1.INTA pci1: display, VGA at device 0.0 (no driver attached) pci1: display at device 0.1 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 UDMA33 controller port 0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xd000-0xd01f irq 9 at device 7.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered intpm0: Intel 82371AB Power management controller port 0x5000-0x500f irq 9 at device 7.3 on pci0 intpm0: I/O mapped 5000 intpm0: intr IRQ 9 enabled revision 0 intsmb0: Intel PIIX4 SMBUS Interface on intpm0 smbus1: System Management Bus on intsmb0 smb0: SMBus generic I/O on smbus1 intpm0: PM I/O mapped 4000 fxp0: Intel 82557 Pro/100 Ethernet port 0xd400-0xd41f mem 0xf000-0xf00f,0xf0104000-0xf0104fff irq 9 at device 16.0 on pci0 miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:a0:c9:89:95:1f atapci1: Promise PDC20268 UDMA100 controller port 0xe800-0xe80f,0xe400-0xe403,0xe000-0xe007,0xdc00-0xdc03,0xd800-0xd807 mem 0xf010-0xf0103fff irq 10 at device 18.0 on pci0 ata2: channel #0 on atapci1 ata3: channel #1 on atapci1 acpi_tz0: Thermal Zone port 0x530-0x537 on acpi0 speaker0: PC speaker port 0x61 on acpi0 fdc0: floppy drive controller port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fd0: 1440-KB 3.5 drive on fdc0 drive 0 sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1: 16550A-compatible COM port port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0: ECP parallel printer port port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppbus0: Parallel port bus on ppc0
Re: Fw: 5.4-STABLE panic: kernel trap 12 with interrupts diabled
On Sun, May 08, 2005 at 03:41:38PM +0200, Fabian Keil wrote: Hi list, forwarding to freebsd-stable (probably the right place anyway), since I got no further responses on freebsd-questions. Subhro [EMAIL PROTECTED] wrote: On 5/5/2005 19:43, Fabian Keil wrote: the day before yesterday I experienced my first panic on 5.4-STABLE. Build and cvsup'ed last Friday. My system is a ThinkPad R51 [...] Then I moved the laptop and plugged in the AC/DC adapter. whoami brought me: Kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0xa94d06c fault code = supervisor read, page not present instruction pointer = 0x8:0xc053cbe5 stack pointer = 0x10:0xe669f98c frame pointer= 0x10:0xe669f990 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 601 (whoami) trap number = 12 panic: page fault [...] Yes, I also experienced that problem. So, I came back to 5.4-PRERELEASE. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bin/64198: init(8) may keep zombies
Hi! The problem is still here for 5.4-STABLE: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/64198 Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Use PCMCIA instead of CardBus?
I have an older laptop (AMS TravelTech w/ K6-3+/333) and a Microsoft MN-520 WLAN adapter. I want to put FreeBSD on it, but I'm having a lot of trouble with the card not being recognized after the infamous errors: CIS is too long -- truncating pccard0: Card has no functions! cbb0: PC Card card activation failed The same setup can boot NetBSD and Linux to get full use of the card by disabling the Cardbus drivers in favor of the PCMCIA ones (ie, by running config on NetBSD and typing disable cbb, or by building a custom Linux kernel with the appropriate settings). I can't seem to get the same results from FreeBSD, though. Any suggestions? -- Kirk Strauser pgpIP7IKFd6uL.pgp Description: PGP signature
Performance issue
Hi All, I have what I think is a serious performance issue with fbsd 5.3 release. I've read about threading issues, and it seems to me that that is what I'm looking at, but I'm not confident enough to rule out that it might be a hardware issue, a kernel configuration issue, or something to do with the python port. I'd appreciate it if someone would it point out if I'm overlooking something obvious. Otherwise, if it is the problem I think it is, then there seems entirely too little acknowledgement of a major issue. Here's the background. I just got a new (to me) AMD machine and put 5.3 release on it. I'd been very happy with the way my old Intel machine had been performing with 4.10 stable, and I decided to run a simple performance diagnostic on both machines, to wow myself with the amazing performance of the new hardware / kernel combination. However, the result was pretty disappointing. Here are what I think are the pertinent dmesg details. Old rig: FreeBSD 4.10-RELEASE #0: Thu Jul 1 22:47:08 EDT 2004 Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 449235058 Hz CPU: Pentium III/Pentium III Xeon/Celeron (449.24-MHz 686-class CPU) New rig: FreeBSD 5.3-RELEASE #0: Fri Nov 5 04:19:18 UTC 2004 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) Processor (995.77-MHz 686-class CPU) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 Timecounter TSC frequency 995767383 Hz quality 800 Timecounters tick every 10.000 msec The diagnostic I selected was a python program to generate 1 million pseudo-random numbers and then to perform a heap sort on them. That code is included at the foot of this email. I named the file heapsort.py. I ran it on both machines, using the time utility in /usr/bin/ (not the builtin tcsh time). So the command line was /usr/bin/time -al -o heapsort.data ./heapsort.py 100 A typical result for the old rig was 130.78 real 129.86 user 0.11 sys 22344 maximum resident set size 608 average shared memory size 20528 average unshared data size 128 average unshared stack size 5360 page reclaims 0 page faults 0 swaps 0 block input operations 0 block output operations 0 messages sent 0 messages received 0 signals received 0 voluntary context switches 2386 involuntary context switches Whereas, the typical result for the new rig looked more like 105.36 real71.10 user33.41 sys 23376 maximum resident set size 659 average shared memory size 20796 average unshared data size 127 average unshared stack size 5402 page reclaims 0 page faults 0 swaps 0 block input operations 0 block output operations 0 messages sent 0 messages received 0 signals received 0 voluntary context switches 10548 involuntary context switches You'll notice that the new rig is indeed a little faster (times in seconds): 105.36 real (new rig) compared with 130.78 real (old rig). However, the new rig spends about 33.41 seconds on system overhead compared with just 0.11 seconds on the old rig. Comparing the rusage stats, the only significant difference is the involuntary context switches field, where the old rig has 2386 and the new rig has a whopping 10548. Further, I noticed that the number of context switches on the new rig seems to be more or less exactly one per 10 msec of real time, that is, one per timecounter tick. (I saw this when comparing heapsort.py runs with arguments other than 100.) I think the new rig ought to execute this task in about 70 seconds: just over the amount of user time. Assuming that I'm not overlooking something obvious, and that I'm not interpreting a feature as a bug, this business with the context switches strikes me as a bit of a show-stopper. If that's right, it appears to be severely underplayed in the release documentation. I'll be happy if someone would kindly explain to me what's going on here. I'll be even happier to hear of a fix or workaround to remedy the situation. Thanks in advance, -e heapsort.py: #!/usr/local/bin/python -O # $Id: heapsort-python-3.code,v 1.3 2005/04/04 14:56:45 bfulgham Exp $ # # The Great Computer Language Shootout # http://shootout.alioth.debian.org/ # # Updated by Valentino Volonghi for Python 2.4 # Reworked by Kevin Carson to produce correct results and same intent import sys IM = 139968 IA = 3877 IC = 29573 LAST = 42 def gen_random(max) : global LAST LAST = (LAST * IA + IC) % IM return( (max * LAST) / IM ) def heapsort(n, ra) : ir = n l = (n 1) + 1 while True : if l 1 : l -= 1 rra = ra[l] else : rra = ra[ir] ra[ir] = ra[1] ir -= 1 if ir == 1 : ra[1] =
re(4) and half-duplex -- FreeBSD 5.4-RC4
Hello, I was trying to connect a FreeBSD box with an integrated realtek network card to a hub but the re driver is unable to set the card in half-duplex: # ifconfig re0 inet 10.20.30.40 netmask 255.255.255.0 mtu 1492 media 10baseT/UTP mediaopt half-duplex up ifconfig: SIOCSIFMEDIA (mediaopt): Device not configured # # ifconfig re0 inet 10.20.30.40 netmask 255.255.255.0 mtu 1492 media 10baseT/UTP mediaopt full-duplex up # however, the man page for this driver states that both modes are supported: [] The re driver supports the following media options: full-duplex Force full duplex operation. half-duplex Force half duplex operation. [] because this I have a lot of collisions in the hub port. I think either the re driver is unable to manage half-duplex on this chip or simply the man page is wrong. Regards. /-/ re0: RealTek 8169S Single-chip Gigabit Ethernet port 0x8c00-0x8cff mem 0xe1006000-0xe10060ff irq 16 at device 11.0 on pci1 miibus0: MII bus on re0 rgephy0: RTL8169S/8110S media interface on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto re0: Ethernet address: 00:0d:61:78:cf:2f ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance issue
Ewan Todd wrote: Hi All, I have what I think is a serious performance issue with fbsd 5.3 release. I've read about threading issues, and it seems to me that that is what I'm looking at, but I'm not confident enough to rule out that it might be a hardware issue, a kernel configuration issue, or something to do with the python port. I'd appreciate it if someone would it point out if I'm overlooking something obvious. Otherwise, if it is the problem I think it is, then there seems entirely too little acknowledgement of a major issue. Here's the background. I just got a new (to me) AMD machine and put 5.3 release on it. I'd been very happy with the way my old Intel machine had been performing with 4.10 stable, and I decided to run a simple performance diagnostic on both machines, to wow myself with the amazing performance of the new hardware / kernel combination. However, the result was pretty disappointing. Here are what I think are the pertinent dmesg details. Old rig: FreeBSD 4.10-RELEASE #0: Thu Jul 1 22:47:08 EDT 2004 Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 449235058 Hz CPU: Pentium III/Pentium III Xeon/Celeron (449.24-MHz 686-class CPU) New rig: FreeBSD 5.3-RELEASE #0: Fri Nov 5 04:19:18 UTC 2004 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) Processor (995.77-MHz 686-class CPU) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 Timecounter TSC frequency 995767383 Hz quality 800 Timecounters tick every 10.000 msec The diagnostic I selected was a python program to generate 1 million pseudo-random numbers and then to perform a heap sort on them. That code is included at the foot of this email. I named the file heapsort.py. I ran it on both machines, using the time utility in /usr/bin/ (not the builtin tcsh time). So the command line was /usr/bin/time -al -o heapsort.data ./heapsort.py 100 A typical result for the old rig was 130.78 real 129.86 user 0.11 sys 22344 maximum resident set size 608 average shared memory size 20528 average unshared data size 128 average unshared stack size 5360 page reclaims 0 page faults 0 swaps 0 block input operations 0 block output operations 0 messages sent 0 messages received 0 signals received 0 voluntary context switches 2386 involuntary context switches Whereas, the typical result for the new rig looked more like 105.36 real71.10 user33.41 sys 23376 maximum resident set size 659 average shared memory size 20796 average unshared data size 127 average unshared stack size 5402 page reclaims 0 page faults 0 swaps 0 block input operations 0 block output operations 0 messages sent 0 messages received 0 signals received 0 voluntary context switches 10548 involuntary context switches You'll notice that the new rig is indeed a little faster (times in seconds): 105.36 real (new rig) compared with 130.78 real (old rig). However, the new rig spends about 33.41 seconds on system overhead compared with just 0.11 seconds on the old rig. Comparing the rusage stats, the only significant difference is the involuntary context switches field, where the old rig has 2386 and the new rig has a whopping 10548. Further, I noticed that the number of context switches on the new rig seems to be more or less exactly one per 10 msec of real time, that is, one per timecounter tick. (I saw this when comparing heapsort.py runs with arguments other than 100.) I think the new rig ought to execute this task in about 70 seconds: just over the amount of user time. Assuming that I'm not overlooking something obvious, and that I'm not interpreting a feature as a bug, this business with the context switches strikes me as a bit of a show-stopper. If that's right, it appears to be severely underplayed in the release documentation. I'll be happy if someone would kindly explain to me what's going on here. I'll be even happier to hear of a fix or workaround to remedy the situation. Thanks in advance, -e First of all, make sure that you have WITNESS and INVARIANTS off in your kernel. You might also want to recompile your kernel with the SMP option turned off. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bin/61355: login(1) does not restore terminal ownership on exit
Hi! The problem is still here for 4.11-STABLE and 5.4-STABLE: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/61355 Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ehci is broken?
At 05:22 PM 07/05/2005, Alexander S. Usov wrote: Hi! It looks that somewhere recently something was broken in ehci again. Trying to write something to msdosfs/ext3fs mounted from external usb2 drive blocks quite qickly. Writing process gets stuck in wdrain state, and disk seems unresponsive -- it just lights up the lamp and does nothing. Any ideas what to check? Are you sure its not something specific to your USB stick or the FS ? I am able to write to a couple of different USB sticks here using USB 2.0 no problem on RELENG_5 umass0: SanDisk Corporation Cruzer Mini, rev 2.00/0.10, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: SanDisk Cruzer Mini 0.1 Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 488MB (1000944 512 byte sectors: 64H 32S/T 488C) umass1: LEXAR MEDIA JUMPDRIVE ELITE, rev 2.00/20.00, addr 3 da1 at umass-sim1 bus 1 target 0 lun 0 da1: LEXAR JUMPDRIVE ELITE 1000 Removable Direct Access SCSI-0 device da1: 40.000MB/s transfers da1: 493MB (1010784 512 byte sectors: 64H 32S/T 493C) [releng5-865]# time dd if=/dev/zero of=/mnt/test bs=1024k count=100 100+0 records in 100+0 records out 104857600 bytes transferred in 25.112543 secs (4175507 bytes/sec) 0.000u 0.472s 0:25.11 1.8% 22+2423k 4+800io 0pf+0w [releng5-865]# time dd if=/dev/zero of=/mnt2/test bs=1024k count=100 100+0 records in 100+0 records out 104857600 bytes transferred in 14.301753 secs (7331800 bytes/sec) 0.000u 0.484s 0:14.30 3.3% 30+3330k 5+800io 0pf+0w [releng5-865]# [releng5-865]# df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/ad0s1a989M 56M854M 6%/ devfs 1.0K1.0K 0B 100%/dev /dev/ad0s1d1.9G 27M1.8G 1%/tmp /dev/ad0s1f 23G5.6G 16G26%/usr /dev/ad0s1e8.7G976M7.1G12%/var /dev/da0s1d473M100M335M23%/mnt /dev/da1s1d477M100M339M23%/mnt2 [releng5-865]# [releng5-865]# time dd if=/dev/zero of=/mnt/test bs=1024k count=100 time dd if=/dev/zero of=/mnt2/test bs=1024k count=100 [1] 816 [2] 817 [releng5-865]# 100+0 records in 100+0 records out 104857600 bytes transferred in 24.052264 secs (4359573 bytes/sec) 100+0 records in 100+0 records out 104857600 bytes transferred in 26.485008 secs (3959130 bytes/sec) [2] + Done dd if=/dev/zero of=/mnt2/test bs=1024k count=100 0.000u 0.513s 0:24.08 2.1% 24+2582k 0+800io 0pf+0w [1] + Done dd if=/dev/zero of=/mnt/test bs=1024k count=100 0.000u 0.513s 0:26.54 1.9% 27+2882k 0+800io 0pf+0w [releng5-865]# ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bin/56558: [PATCH] locate(1) cannot be safely used with xargs(1)
Hi! The problem is still here for 5.4-STABLE. http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/56558 Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance issue
At 11:00 AM 09/05/2005, Ewan Todd wrote: Here's the background. I just got a new (to me) AMD machine and put 5.3 release on it. I'd been very happy with the way my old Intel There have been quite a few changes since 5.3. If you are starting fresh, I would strongly recommend going to 5.4 RC4. There have been a number of improvements that might help the problems you are seeing. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance issue
Whereas, the typical result for the new rig looked more like 105.36 real71.10 user33.41 sys ... 10548 involuntary context switches Now I just ran this test myself. This machine is a 2.4 gig P4 with hyperthreading enabled. Much as I am an AMD fan, I would expect a 1gig Athlon to be significantly slower than a 2.4 gig Pentium 4. but: 93.45 real56.55 user36.85 sys 1857 involuntary context switches Uhhh... so it takes almost the same time to do the calculation, but spends actually *more* of it in system space. Does far less context switches though, but I am assuming thats due to HTT. Numbers look very odd to me. So I then ran it on another P4 system we have round here which is still running 4.11. This is a 2.66 gig P4, not a 2.4 so it should be a bit faster, but: 33.77 real33.49 user 0.07 sys 711 involuntary context switches Over two and a half times faster ?! Thats not right at all! All the new systems I have tried are 5.4-RC4, so should be the latest and greatest. When my colleague finishes on his machine I can try a GENERIC 5.4-RC4 kernel on another P4 and see what that gives. -pcf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problems with Maestro sound card
On Sat, May 07, 2005 at 04:29:19PM +0200, Kirill Ponomarew wrote: The same troubles I got on FreeBSD 5.3-RELEASE. Any tips and advices ? Thanks. Try using driver from http://www.opensound.com/ -ip -- Never tell them what you wouldn't do. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Performance issue
Same test on a 5.3-STABLE from 31.01.2005: 81,90 real77,05 user 3,51 sys 22908 maximum resident set size 620 average shared memory size 20083 average unshared data size 128 average unshared stack size 5379 page reclaims 26 page faults 0 swaps 36 block input operations 0 block output operations 0 messages sent 0 messages received 0 signals received 62 voluntary context switches 10623 involuntary context switches This is a on a slow dual-processor system: Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel Pentium III (732.98-MHz 686-class CPU) Origin = GenuineIntel Id = 0x683 Stepping = 3 Features=0x387fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CM OV,PAT,PSE36,PN,MMX,FXSR,SSE real memory = 2281635840 (2175 MB) avail memory = 2232012800 (2128 MB) ACPI APIC Table: PTLTDAPIC FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 (if this is of any help). Scheduler is 4BSD. Regards, Holger Kipp -Original Message- From: [EMAIL PROTECTED] on behalf of Pete French Sent: Mon 09.05.2005 18:10 To: [EMAIL PROTECTED]; freebsd-stable@freebsd.org Subject: Re: Performance issue Whereas, the typical result for the new rig looked more like 105.36 real71.10 user33.41 sys ... 10548 involuntary context switches Now I just ran this test myself. This machine is a 2.4 gig P4 with hyperthreading enabled. Much as I am an AMD fan, I would expect a 1gig Athlon to be significantly slower than a 2.4 gig Pentium 4. but: 93.45 real56.55 user36.85 sys 1857 involuntary context switches Uhhh... so it takes almost the same time to do the calculation, but spends actually *more* of it in system space. Does far less context switches though, but I am assuming thats due to HTT. Numbers look very odd to me. So I then ran it on another P4 system we have round here which is still running 4.11. This is a 2.66 gig P4, not a 2.4 so it should be a bit faster, but: 33.77 real33.49 user 0.07 sys 711 involuntary context switches Over two and a half times faster ?! Thats not right at all! All the new systems I have tried are 5.4-RC4, so should be the latest and greatest. When my colleague finishes on his machine I can try a GENERIC 5.4-RC4 kernel on another P4 and see what that gives. -pcf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [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: Performance issue
Whereas, the typical result for the new rig looked more like 105.36 real71.10 user33.41 sys ... 10548 involuntary context switches First of all, make sure that you have WITNESS and INVARIANTS off in your kernel. You might also want to recompile your kernel with the SMP option turned off. Scott First of all, thanks to Mike Tancsa for suggesting 5.4 RC4 and to Pete French for running the test independently on the higher spec machines with 5.4 RC4 on them, confirming the system time thing, ruling out an AMD problem, dissociating the system time result from the context switching, and saving me the trouble of rediscovering the same problem on 5.4 RC4. This is my first foray into the public world of FreeBSD discussion lists, and I am encouraged by the helpfulness of the response. Scott, the 5.3 kernel I had was a essentially a GENERIC release kernel, with about 100 options commented out. WITNESS and INVARIANTS are off by default, which I confirmed by looking through `sysctl -a`. However, I was curious to see what I would get if I switched them on, so I added these options and recompiled the kernel: options KDB options DDB options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN The result, below, has essentially the same user time (or just less, if that makes any sense), but tripled system time. The context switches are consistent with the one-per-10msec I saw before. Is there anything useful I can do while I still have the kernel debug options on? -e 172.29 real67.53 user 103.07 sys 23376 maximum resident set size 659 average shared memory size 20805 average unshared data size 127 average unshared stack size 5402 page reclaims 0 page faults 0 swaps 0 block input operations 0 block output operations 0 messages sent 0 messages received 0 signals received 0 voluntary context switches 17234 involuntary context switches ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance issue
Ewan Todd wrote: Whereas, the typical result for the new rig looked more like 105.36 real71.10 user33.41 sys ... 10548 involuntary context switches First of all, make sure that you have WITNESS and INVARIANTS off in your kernel. You might also want to recompile your kernel with the SMP option turned off. Scott First of all, thanks to Mike Tancsa for suggesting 5.4 RC4 and to Pete French for running the test independently on the higher spec machines with 5.4 RC4 on them, confirming the system time thing, ruling out an AMD problem, dissociating the system time result from the context switching, and saving me the trouble of rediscovering the same problem on 5.4 RC4. This is my first foray into the public world of FreeBSD discussion lists, and I am encouraged by the helpfulness of the response. Scott, the 5.3 kernel I had was a essentially a GENERIC release kernel, with about 100 options commented out. WITNESS and INVARIANTS are off by default, which I confirmed by looking through `sysctl -a`. However, I was curious to see what I would get if I switched them on, so I added these options and recompiled the kernel: options KDB options DDB options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN The result, below, has essentially the same user time (or just less, if that makes any sense), but tripled system time. The context switches are consistent with the one-per-10msec I saw before. Is there anything useful I can do while I still have the kernel debug options on? -e 172.29 real67.53 user 103.07 sys 23376 maximum resident set size 659 average shared memory size 20805 average unshared data size 127 average unshared stack size 5402 page reclaims 0 page faults 0 swaps 0 block input operations 0 block output operations 0 messages sent 0 messages received 0 signals received 0 voluntary context switches 17234 involuntary context switches 5.3 ships with SMP turned on, which makes lock operations rather expensive on single-processor machines. 4.x does not have SMP turned on by default. Would you be able to re-run your test with SMP turned off? Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance issue
5.3 ships with SMP turned on, which makes lock operations rather expensive on single-processor machines. 4.x does not have SMP turned on by default. Would you be able to re-run your test with SMP turned off? I'm pretty sure there's no SMP in this kernel. #cd /usr/src/sys/i386/conf #fgrep SMP MYKERNEL # GENERIC has no SMP in it, but there's a second GENERIC kernel conf called SMP, which simply says: include GENERIC options SMP However, sysctl seems to show smp not active, but not disabled. Is that anything to worry about? #sysctl -a | grep smp kern.smp.maxcpus: 1 kern.smp.active: 0 kern.smp.disabled: 0 kern.smp.cpus: 1 debug.psmpkterrthresh: 2 -e ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance issue
Ewan Todd wrote: 5.3 ships with SMP turned on, which makes lock operations rather expensive on single-processor machines. 4.x does not have SMP turned on by default. Would you be able to re-run your test with SMP turned off? I'm pretty sure there's no SMP in this kernel. #cd /usr/src/sys/i386/conf #fgrep SMP MYKERNEL # GENERIC has no SMP in it, but there's a second GENERIC kernel conf called SMP, which simply says: include GENERIC options SMP However, sysctl seems to show smp not active, but not disabled. Is that anything to worry about? #sysctl -a | grep smp kern.smp.maxcpus: 1 kern.smp.active: 0 kern.smp.disabled: 0 kern.smp.cpus: 1 debug.psmpkterrthresh: 2 -e Bah, you're right, sorry for the confusion. Too many releases in my mind, they all seem like a blur. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance issue
5.3 ships with SMP turned on, which makes lock operations rather expensive on single-processor machines. 4.x does not have SMP turned on by default. Would you be able to re-run your test with SMP turned off? I just ran a test here with SMP turned of on 5.4-RC4 (GENERIC) I got the following result: 67.52 real41.13 user26.16 sys 7034 involuntary context switches i.e. it still has system time a a huge proportion of the total compared to the 4.11 kernel. Interesingly, after reading Holger Kipp's results I tried it on a genuine multi-processor box with SMP enabled running 5.3. He got a very small percentage of the time in sys (3.51 out of 81.90) but I got: 255.30 real 160.20 user88.50 sys Once again a far higher proprtion of the time spent in sys than you would expect. -pcf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance issue
Scott Long wrote: First of all, make sure that you have WITNESS and INVARIANTS off in your kernel. You might also want to recompile your kernel with the SMP option turned off. I can confirm this. I just rerun it on RELENG_5_4 as of yesterday and got 136.52 real80.29 user50.16 sys 23212 maximum resident set size 674 average shared memory size 20961 average unshared data size 128 average unshared stack size 5419 page reclaims 0 page faults 0 swaps 0 block input operations 0 block output operations 0 messages sent 0 messages received 0 signals received 0 voluntary context switches 25738 involuntary context switches No debugging or SMP in kernel. -- Best regards, Alexander. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance issue
Hello, On May 9, 2005, at 1:31 PM, Pete French wrote: 5.3 ships with SMP turned on, which makes lock operations rather expensive on single-processor machines. 4.x does not have SMP turned on by default. Would you be able to re-run your test with SMP turned off? I just ran a test here with SMP turned of on 5.4-RC4 (GENERIC) I got the following result: 67.52 real41.13 user26.16 sys 7034 involuntary context switches i.e. it still has system time a a huge proportion of the total compared to the 4.11 kernel. Interesingly, after reading Holger Kipp's results I tried it on a genuine multi-processor box with SMP enabled running 5.3. He got a very small percentage of the time in sys (3.51 out of 81.90) but I got: 255.30 real 160.20 user88.50 sys Once again a far higher proprtion of the time spent in sys than you would expect. I ran ktrace(1) on it, and it appears that python keeps calling sigprocmask() continually: 673 python 0.07 CALL sigprocmask(0x3,0,0x811d11c) 673 python 0.05 RET sigprocmask 0 673 python 0.09 CALL sigprocmask(0x1,0,0x8113d1c) 673 python 0.05 RET sigprocmask 0 etc.. This explains why it's using so much system time. Now the question is why is python doing this? -- Suleiman Souhlal | [EMAIL PROTECTED] The FreeBSD Project | [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: Performance issue
On Mon, May 9, 2005 1:06 pm, Scott Long said: 5.3 ships with SMP turned on, which makes lock operations rather expensive on single-processor machines. 4.x does not have SMP turned on by default. Would you be able to re-run your test with SMP turned off? This is what i get on my system, which has debugging and smp off in the kernel. FreeBSD 6.0-CURRENT #0: Tue May 3 23:55:43 EDT 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DP Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) Processor (1410.21-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x644 Stepping = 4 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR AMD Features=0xc044RSVD,AMIE,DSP,3DNow! --- 76.89 real49.33 user22.87 sys 23116 maximum resident set size 686 average shared memory size 20795 average unshared data size 127 average unshared stack size 5380 page reclaims 0 page faults 0 swaps 0 block input operations 0 block output operations 0 messages sent 0 messages received 0 signals received 1 voluntary context switches 10018 involuntary context switches --- As we can see, it is still spending a lot of time in system, and there are a lot of context switches being done. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance issue
On Mon, 9 May 2005, Suleiman Souhlal wrote:
Hello,
I ran ktrace(1) on it, and it appears that python keeps calling
sigprocmask() continually:
673 python 0.07 CALL sigprocmask(0x3,0,0x811d11c)
673 python 0.05 RET sigprocmask 0
673 python 0.09 CALL sigprocmask(0x1,0,0x8113d1c)
673 python 0.05 RET sigprocmask 0
etc..
This explains why it's using so much system time. Now the question is
why is python doing this?
I don't know what python's doing, but it might not be calling
sigprocmask directly. There are a few libc functions that use
sigprocmask:
db/btree/
db/hash/
pselect(),
setmode(),
{sig}setjmp(), {sig}longjmp(),
grantpt(),
system()
to name a few. Python may also be using other libraries which
use sigprocmask().
--
DE
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unexpected panic in idle process (RELENG_5 2005/04/25UTC)
On Thu, 28 Apr 2005, I wrote: Fatal trap 9: general protection fault while in kernel mode instruction pointer = 0x8:0xc05e8ca2 stack pointer = 0x10:0xc7499d10 frame pointer = 0x10:0xc7499d10 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 = 11 (idle) [thread pid 11 tid 13 ] Stopped at cpu_idle_default+0x5: leave and Doug White [EMAIL PROTECTED] answered on Sun, 8 May 2005: This is an odd one; the IA32 manual doesn't say you can take a GPF from a LEAVE instruction in protected mode. %ebp looks correct so I'd wonder if you have cooling problems or a bad processor. Yes, odd, but maybe there is a simpler explanation: I have DDB enabled, and the serial console may have sent a spurious break. After nobody suggested any smart commands for db I issued a c and tadda, the system was back (albeit with the wrong time). So this may be a red herring. Thanks for the analysis. Adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance issue
On 5/9/2005 12:31 PM, Pete French wrote: 5.3 ships with SMP turned on, which makes lock operations rather expensive on single-processor machines. 4.x does not have SMP turned on by default. Would you be able to re-run your test with SMP turned off? I just ran a test here with SMP turned of on 5.4-RC4 (GENERIC) I got the following result: 67.52 real41.13 user26.16 sys 7034 involuntary context switches i.e. it still has system time a a huge proportion of the total compared to the 4.11 kernel. Interesingly, after reading Holger Kipp's results I tried it on a genuine multi-processor box with SMP enabled running 5.3. He got a very small percentage of the time in sys (3.51 out of 81.90) but I got: 255.30 real 160.20 user88.50 sys Once again a far higher proprtion of the time spent in sys than you would expect. I ran into a similar issue when attempting to thread a card game solver program I wrote. Performance in early versions was horrific and I noticed tons of context switches. I resolved the issue by allocating pools of memory beforehand. This seems to point the finger to malloc and context switch overhead. In any case, I believe this is related to threading. Check your results with libthr instead. The following are on my 2.53 GHz P4 which is running CURRENT from last night (with INVARIANTS on). libpthread: $ /usr/bin/time -al ./heapsort.py 100 0.928555 124.04 real65.71 user48.47 sys 23464 maximum resident set size 680 average shared memory size 21104 average unshared data size 129 average unshared stack size 5400 page reclaims 0 page faults 0 swaps 15 block input operations 0 block output operations 4 messages sent 0 messages received 0 signals received 21 voluntary context switches 40274 involuntary context switches libthr: $ /usr/bin/time -al ./heapsort.py 100 0.928555 79.75 real50.63 user25.34 sys 23348 maximum resident set size 679 average shared memory size 21041 average unshared data size 129 average unshared stack size 5394 page reclaims 1 page faults 0 swaps 2 block input operations 0 block output operations 3 messages sent 0 messages received 0 signals received 7 voluntary context switches 26113 involuntary context switches -- Jonathan Noack | [EMAIL PROTECTED] | OpenPGP: 0x991D8195 signature.asc Description: OpenPGP digital signature
Re: Performance issue
On Mon, 2005-May-09 11:00:18 -0400, Ewan Todd wrote: I have what I think is a serious performance issue with fbsd 5.3 release. I've read about threading issues, and it seems to me that that is what I'm looking at, but I'm not confident enough to rule out that it might be a hardware issue, a kernel configuration issue, or something to do with the python port. There does appear to be a problem in FreeBSD. Python is built with threading enabled by default, the threading libraries play with the signal mask and there have been extensive changes there. My suggestions on things you could check are: 1) Rebuild python with threading disabled (add '-DWITHOUT_THREADS' to the 'make' command line and see if that makes any difference 2) Re-write the sample program in a non-threaded language - eg C or perl and see if the high system time goes away. Unfortunately, I can't think of a solution at present. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance issue
On Tue, 10 May 2005, Peter Jeremy wrote: On Mon, 2005-May-09 11:00:18 -0400, Ewan Todd wrote: I have what I think is a serious performance issue with fbsd 5.3 release. I've read about threading issues, and it seems to me that that is what I'm looking at, but I'm not confident enough to rule out that it might be a hardware issue, a kernel configuration issue, or something to do with the python port. There does appear to be a problem in FreeBSD. Python is built with threading enabled by default, the threading libraries play with the signal mask and there have been extensive changes there. My The threading libraries don't play with the signal mask. In fact, libpthread has userland versions of sigprocmask() et. al. and won't even make the syscall() unless the threads are system scope. There is a special thread in libpthread that handles signals which does use the system sigprocmask(), but unless the application is making heavy use of signals in general, it shouldn't matter. suggestions on things you could check are: 1) Rebuild python with threading disabled (add '-DWITHOUT_THREADS' to the 'make' command line and see if that makes any difference 2) Re-write the sample program in a non-threaded language - eg C or perl and see if the high system time goes away. Unfortunately, I can't think of a solution at present. You can also set LIBPTHREAD_SYSTEM_SCOPE in the environment to force libpthread to use system scope threads. It uses process scope threads by default. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance issue
Daniel Eischen wrote:
{sig}setjmp(), {sig}longjmp(),
A very wild guess.. python is using setjmp/longjmp to implement
continuations, tailcalls, or any mechanism similar to that and using
that in a loop?
mkb.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Common disk format between 2.4.current linux and FreeBSD 5.3 and later
I'm building a usb harddrive and i'll be using it under both linux and FreeBSD. vfat is not a contender due to a 2gb limit of file size (I'm using it as a dump disk and I don't want to deal with multiple volumes). It seems that BSD can talk to ext2 partitions and Linux can talk to the older UFS format. Suggestions on which is the more stable implementation for a r/w environment? I've read that there were issues in the past, but I could see anything within the last year or so. Thanks jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 5.4-RELEASE is now available
The Release Engineering Team is happy to announce the availability of FreeBSD 5.4-RELEASE, the latest release of the FreeBSD Stable development branch. Since FreeBSD 5.3-RELEASE in November 2004 we have made many improvements in functionality, stability, performance, and device driver support for some hardware, as well as dealt with known security issues and made many bugfixes. For a complete list of new features, known problems, and late-breaking news, please see the release notes and errata list, available here: http://www.FreeBSD.org/releases/5.4R/relnotes.html http://www.FreeBSD.org/releases/5.4R/errata.html FreeBSD 5.4 will become an Errata Branch. In addition to Security fixes other well-tested fixes to basic functionality will be committed to the RELENG_5.4 branch after the release. Both Security Advisories and Errata Notices are announced on the freebsd-announce@freebsd.org mailing list. It is expected there will be at least one more release from the RELENG_5 branch, most likely two. The current plans are for the RELENG_6 branch to be created within the next few months, and an initial 6.0-RELEASE will be made a few months afterwards. There will be a 5.5-RELEASE following a few months after the 6.0-RELEASE. For more information about FreeBSD release engineering activities, please see: http://www.FreeBSD.org/releng/ Dedication -- The FreeBSD 5.4 Release is dedicated to the memory of Cameron Grant. Cameron was an active FreeBSD Developer and principal architect of the sound driver subsystem despite his physical handicap. His is a superb example of human spirit dominating over adversity. Cameron was an inspiration to those who met him; he will be fondly remembered and sorely missed. Availability FreeBSD 5.4-RELEASE supports the i386, amd64, ia64, pc98, sparc64, and alpha architectures and can be installed directly over the net, using bootable media, or copied to a local NFS/FTP server. Distributions for all architectures except alpha are available now. The distribution for alpha should become available within the next day or two. Please continue to support the FreeBSD Project by purchasing media from one of our supporting vendors. The following companies will be offering FreeBSD 5.4 based products: FreeBSD Mall, Inc.http://www.freebsdmall.com/ Daemonnews, Inc. http://www.bsdmall.com/freebsd1.html If you can not afford FreeBSD on media, are impatient, or just want to use it for evangelism purposes, then by all means download the ISO images. We can not promise that all the mirror sites will carry the larger ISO images. At the time of this announcement they are available from the following sites. MD5 checksums for the release images are included at the bottom of this message. Bittorrent -- As with the 5.3 release we are experimenting with Bittorrent. A collection of trackers for the release ISO images is available at http://people.freebsd.org/~kensmith/5.4-torrent/ FTP --- At the time of this announcement the following FTP sites have FreeBSD 5.4-RELEASE available. ftp://ftp.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.FreeBSD.org/pub/FreeBSD/ ftp://ftp5.FreeBSD.org/pub/FreeBSD/ ftp://ftp.at.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.ch.FreeBSD.org/pub/FreeBSD/ ftp://ftp.cz.FreeBSD.org/pub/FreeBSD/ ftp://ftp.ee.FreeBSD.org/pub/FreeBSD/ ftp://ftp.es.FreeBSD.org/pub/FreeBSD/ ftp://ftp.fi.FreeBSD.org/pub/FreeBSD/ ftp://ftp.fr.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.ie.FreeBSD.org/pub/FreeBSD/ ftp://ftp.is.FreeBSD.org/pub/FreeBSD/ ftp://ftp5.pl.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.ru.FreeBSD.org/pub/FreeBSD/ ftp://ftp.se.FreeBSD.org/pub/FreeBSD/ ftp://ftp.si.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.tw.FreeBSD.org/pub/FreeBSD/ ftp://ftp.uk.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.us.FreeBSD.org/pub/FreeBSD/ ftp://ftp5.us.FreeBSD.org/pub/FreeBSD/ FreeBSD is also available via anonymous FTP from mirror sites in the following countries and territories: Argentina, Australia, Austria, Brazil, Canada, China, Croatia, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hong Kong, Hungary, Iceland, Indonesia, Ireland, Italy, Japan, Korea, Lithuania, Netherlands, New Zealand, Norway, Poland, Portugal, Romania, Russia, Saudi Arabia, Singapore, Slovak Republic, Slovenia, South Africa, Spain, Sweden, Switzerland, Taiwan, Turkey, Ukraine, United Kingdom, and the United States. Before trying the central FTP site, please check your regional mirror(s) first by going to: ftp://ftp.yourdomain.FreeBSD.org/pub/FreeBSD Any additional mirror sites will be labeled ftp2, ftp3 and so on. More information about FreeBSD mirror sites and the current list of all active mirror sites can be found at: http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/mirrors-ftp.html For instructions on installing FreeBSD, please see
Re: Performance issue
On 5/9/2005 1:30 PM, Jonathan Noack wrote: On 5/9/2005 12:31 PM, Pete French wrote: 5.3 ships with SMP turned on, which makes lock operations rather expensive on single-processor machines. 4.x does not have SMP turned on by default. Would you be able to re-run your test with SMP turned off? I just ran a test here with SMP turned of on 5.4-RC4 (GENERIC) I got the following result: 67.52 real41.13 user26.16 sys 7034 involuntary context switches i.e. it still has system time a a huge proportion of the total compared to the 4.11 kernel. Interesingly, after reading Holger Kipp's results I tried it on a genuine multi-processor box with SMP enabled running 5.3. He got a very small percentage of the time in sys (3.51 out of 81.90) but I got: 255.30 real 160.20 user88.50 sys Once again a far higher proprtion of the time spent in sys than you would expect. I ran into a similar issue when attempting to thread a card game solver program I wrote. Performance in early versions was horrific and I noticed tons of context switches. I resolved the issue by allocating pools of memory beforehand. This seems to point the finger to malloc and context switch overhead. In any case, I believe this is related to threading. Check your results with libthr instead. The following are on my 2.53 GHz P4 which is running CURRENT from last night (with INVARIANTS on). libpthread: $ /usr/bin/time -al ./heapsort.py 100 0.928555 124.04 real65.71 user48.47 sys 23464 maximum resident set size 680 average shared memory size 21104 average unshared data size 129 average unshared stack size 5400 page reclaims 0 page faults 0 swaps 15 block input operations 0 block output operations 4 messages sent 0 messages received 0 signals received 21 voluntary context switches 40274 involuntary context switches libthr: $ /usr/bin/time -al ./heapsort.py 100 0.928555 79.75 real50.63 user25.34 sys 23348 maximum resident set size 679 average shared memory size 21041 average unshared data size 129 average unshared stack size 5394 page reclaims 1 page faults 0 swaps 2 block input operations 0 block output operations 3 messages sent 0 messages received 0 signals received 7 voluntary context switches 26113 involuntary context switches Oooh... same machine with libc_r: $ /usr/bin/time -al ./heapsort.py 100 0.928555 38.72 real36.85 user 0.06 sys 23496 maximum resident set size 678 average shared memory size 21126 average unshared data size 129 average unshared stack size 5418 page reclaims 2 page faults 0 swaps 2 block input operations 0 block output operations 3 messages sent 0 messages received 0 signals received 8 voluntary context switches 13137 involuntary context switches -- Jonathan Noack | [EMAIL PROTECTED] | OpenPGP: 0x991D8195 signature.asc Description: OpenPGP digital signature
Re: FreeBSD 5.4-RELEASE is now available
Am Montag, 9. Mai 2005 23:04 schrieb Ken Smith: The Release Engineering Team is happy to announce the availability of FreeBSD 5.4-RELEASE, the latest release of the FreeBSD Stable development branch. Since FreeBSD 5.3-RELEASE in November 2004 we have made many improvements in functionality, stability, performance, and device driver support for some hardware, as well as dealt with known security issues and made many bugfixes. Thanks a lot to all those hard working guys, 5.4 is a really nice release! -Mano pgpiKSiPcGTdN.pgp Description: PGP signature
Re: Performance issue
Hello, On May 9, 2005, at 3:54 PM, Daniel Eischen wrote: On Tue, 10 May 2005, Peter Jeremy wrote: On Mon, 2005-May-09 11:00:18 -0400, Ewan Todd wrote: I have what I think is a serious performance issue with fbsd 5.3 release. I've read about threading issues, and it seems to me that that is what I'm looking at, but I'm not confident enough to rule out that it might be a hardware issue, a kernel configuration issue, or something to do with the python port. There does appear to be a problem in FreeBSD. Python is built with threading enabled by default, the threading libraries play with the signal mask and there have been extensive changes there. My The threading libraries don't play with the signal mask. In fact, libpthread has userland versions of sigprocmask() et. al. and won't even make the syscall() unless the threads are system scope. There is a special thread in libpthread that handles signals which does use the system sigprocmask(), but unless the application is making heavy use of signals in general, it shouldn't matter. I think I've found the problem: Python uses setjmp/longjmp to protect against SIGFPU every time it does floating point operations. The python script does not actually use threads, and libpthread assumes non-threaded processes are system scope. So, it would end up using the sigprocmask syscall, even though it doesn't really need to. The diff at http://people.freebsd.org/~ssouhlal/testing/ thr_sigmask-20050509.diff fixes this, by making sure the process is threaded, before using the syscall. -- Suleiman Souhlal | [EMAIL PROTECTED] The FreeBSD Project | [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: loader causes reboot
On 5/8/2005 10:57 PM, Jonathan Noack wrote: On 05/08/05 14:29, David Gurvich wrote: cdrom /boot/loader from 5.3 has no problem. However, after updating world from kernel, /boot/loader is replaced with cvs version. This one goes into endless cycle of reboots. When replaced with /boot/loader from cdrom boots normally. Are you setting CPUTYPE? A few people have reported an endless reboot with the athlon-xp or pentium-m settings. I experience this on my athlon-xp and the only workaround I've found is just to not set CPUTYPE. This problem is way beyond my feeble skills to track down and fix, but it doesn't seem to affect many people and no one has stepped up to resolve it. As it is easily worked around, I've brought it up a few times but haven't made too big of a fuss. Come to think of it, why didn't I ever open a PR? Hmm... perhaps I'll do that at work tomorrow (this is on a machine at work). Huh... setting CPUTYPE?=athlon-xp seems to work fine for me with 5.4-RELEASE. -- Jonathan Noack | [EMAIL PROTECTED] | OpenPGP: 0x991D8195 signature.asc Description: OpenPGP digital signature
Re: Performance issue
On Mon, 9 May 2005, Suleiman Souhlal wrote: On May 9, 2005, at 3:54 PM, Daniel Eischen wrote: The threading libraries don't play with the signal mask. In fact, libpthread has userland versions of sigprocmask() et. al. and won't even make the syscall() unless the threads are system scope. There is a special thread in libpthread that handles signals which does use the system sigprocmask(), but unless the application is making heavy use of signals in general, it shouldn't matter. I think I've found the problem: Python uses setjmp/longjmp to protect against SIGFPU every time it does floating point operations. The python script does not actually use threads, and libpthread assumes non-threaded processes are system scope. So, it would end up using the sigprocmask syscall, even though it doesn't really need to. The diff at http://people.freebsd.org/~ssouhlal/testing/ thr_sigmask-20050509.diff fixes this, by making sure the process is threaded, before using the syscall. I don't think that patch is correct. You need the signal mask in the kernel to match in case of an exec() after a fork() for instance. If the application fork()'s, then changes the signal mask in the child (which is now single threaded), then the child exec()s, the mask is wrong. If the process wasn't linked to libpthread, then the longjmp() and setjmp() would still be calling the syscall, so it isn't the syscall itself that is making things slower. You'll notice that there are two calls to __sys_sigprocmask() in the section of code you have patched. You could eliminate the second call if you do some of what the remainder of the function does instead of returning early (the locks aren't needed and pending signals don't need to be run down). -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: twa0: INFO: (0x04: 0x000c): Background initialize started: unit=0
Ya, this looks like it might be a problem ... server just crashed, and fsck is once more dog slow, and I suspect its in the 'initialization mode' again ... Looking at the following that I've also found, things appear to be pointing to ACPI as the 'trigger' ... does anyone else have any experiences with these cards? http://leaf.dragonflybsd.org/mailarchive/bugs/2004-09/msg00169.html There appear to be whole threads on this issue on the Dragonfly lists, altho I'm not finding anything easily on the freebsd lists themselves ... On Fri, 6 May 2005, Marc G. Fournier wrote: yOn Fri, 6 May 2005, Erik Stian Tefre wrote: I believe you should see this message only once after creating a new array/unit, given that you give the box enough uptime to finish the initialization. The following message confirms that the initialization is complete (it took 4.5 hours on my box with a 9500-8LP, which btw is running 5.3): twa0: INFO: (0x04: 0x0007): Background initialize done: unit=0 'k, it *had* had 16 days of production uptime before the power outage :( I have seen the 'initalize done' though, so hopefully it doesn't happen again on Saturday when we replace the power strip ... On Wed, 2005-05-04 at 16:01 -0300, Marc G. Fournier wrote: Running FreeBSD 4.11-STABLE ... Has anyone seen this before? Only reference on the 'net I can find seems to be similar issue on a Dragonfly system: http://leaf.dragonflybsd.org/mailarchive/bugs/2004-09/msg00176.html Mine is a 9500-4LP controller ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Erik Stian Tefre [EMAIL PROTECTED] Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance issue
On Mon, 9 May 2005, Daniel Eischen wrote: On Mon, 9 May 2005, Suleiman Souhlal wrote: I think I've found the problem: Python uses setjmp/longjmp to protect against SIGFPU every time it does floating point operations. The python script does not actually use threads, and libpthread assumes non-threaded processes are system scope. So, it would end up using the sigprocmask syscall, even though it doesn't really need to. The diff at http://people.freebsd.org/~ssouhlal/testing/ thr_sigmask-20050509.diff fixes this, by making sure the process is threaded, before using the syscall. [ ... ] If the process wasn't linked to libpthread, then the longjmp() and setjmp() would still be calling the syscall, so it isn't the syscall itself that is making things slower. You'll notice that there are two calls to __sys_sigprocmask() in the section of code you have patched. You could eliminate the second call if you do some of what the remainder of the function does instead of returning early (the locks aren't needed and pending signals don't need to be run down). As in something like this: http://people.freebsd.org/~deischen/kse/thr_sigmask.c.diffs It has not been tested. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ep/X11 problems
I have a Dell Inspiron 7500 on which I have put FreeBSD Release 5.4. The 3Com Megahertz 574B pccard ethernet card works well with the ep driver, except that after I run X11, it simply stops working. I am guessing that it is an interupt conflict. I have tried everything I can think of so that sp0 is not irq 11, most notably putting hints.ep.0.irq=10 in /boot/loader.conf, but it just doesn't work - the irq for ep0 is still 11. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ep/X11 problems
Stephen Montgomery-Smith wrote: I have a Dell Inspiron 7500 on which I have put FreeBSD Release 5.4. The 3Com Megahertz 574B pccard ethernet card works well with the ep driver, except that after I run X11, it simply stops working. I am guessing that it is an interupt conflict. I have tried everything I can think of so that sp0 is not irq 11, most notably putting hints.ep.0.irq=10 in /boot/loader.conf, but it just doesn't work - the irq for ep0 is still 11. Oops - I was supposed to put it in /boot/device.hints. But it still didn't work. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
gvinum RAID5 stable in 5.4-RELEASE?
I tried to install a RAID5 array using both vinum and gvinum under 5.3-RELEASE and couldn't get a reliable system running. I reinstalled using 4.11-STABLE and so far the system (and vinum) have been error-free. The 5.4-RELEASE documentation only mentions that geom_vinum provides a GEOM compatible replacement for vinum. I've seen contradictory messages on this mailing list and the geom mailing list about whether 5.4-RELEASE's gvinum provides a stable RAID5 solution. Hardware is a Supermicro P4DC6+, dual 1.7Ghz Xeon, 512MB RAMBUS, boot device is a RAID1 array using an Adaptec 2005 in the RAID adapter slot, 8 Seagate 43GB SCSI disks attached to a Compaq/Adaptec 39160 controller using vinum. I don't want to use the on-board controller for the RAID5 array since I believe the cabling will be problematical with two external SCSI towers plus the long run from the SCSI port to the back of the case. I tried installing 5.3_RELEASE/RAID5 several times using both vinum and gvinum; I also tried installing and then upgrading to 5.3-STABLE in the hopes that a bugfix had appeared. I had gvinum working for almost a day before the system crashed under heavy load; since this is a hobby and not my employment I decided to back off to 4.11 and try again. I do have an alternative - a DPT SmartRAID V - but vinum has been so reliable under 4.x that I'd like to continue with it, if possible. Mike Squires ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Outdated lib*_p.a files
I run a homegrown script after upgrades to find outdated binaries. I have a bunch of files name /usr/lib/lib*_p.a that predate my recent upgrade to 5.4-RELEASE. What are these? Can they be deleted without harm? Thanks, Jason C. Wells ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance issue
On 05/09/05 18:47, Daniel Eischen wrote: On Mon, 9 May 2005, Daniel Eischen wrote: On Mon, 9 May 2005, Suleiman Souhlal wrote: I think I've found the problem: Python uses setjmp/longjmp to protect against SIGFPU every time it does floating point operations. The python script does not actually use threads, and libpthread assumes non-threaded processes are system scope. So, it would end up using the sigprocmask syscall, even though it doesn't really need to. The diff at http://people.freebsd.org/~ssouhlal/testing/ thr_sigmask-20050509.diff fixes this, by making sure the process is threaded, before using the syscall. [ ... ] If the process wasn't linked to libpthread, then the longjmp() and setjmp() would still be calling the syscall, so it isn't the syscall itself that is making things slower. You'll notice that there are two calls to __sys_sigprocmask() in the section of code you have patched. You could eliminate the second call if you do some of what the remainder of the function does instead of returning early (the locks aren't needed and pending signals don't need to be run down). As in something like this: http://people.freebsd.org/~deischen/kse/thr_sigmask.c.diffs It has not been tested. When I tried to test this every threaded program died with sig 11. Does this require me to recompile the program before it will work? -- Jonathan Noack | [EMAIL PROTECTED] | OpenPGP: 0x991D8195 signature.asc Description: OpenPGP digital signature
Re: Outdated lib*_p.a files
In the last episode (May 09), Jason C. Wells said: I run a homegrown script after upgrades to find outdated binaries. I have a bunch of files name /usr/lib/lib*_p.a that predate my recent upgrade to 5.4-RELEASE. What are these? Can they be deleted without harm? Those are versions of libraries built with profiling code. If you have NOPROFILE set in your make.conf, you should remove them from /usr/lib. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
nfs bug df: Can I lock up my kernel and overflow this buffer?
Here's something pretty stupid about either the code in mount, df, or both. I'm on the verge of a denial of service if this lasts much longer. When I mount an nfs device more than once, I get this ridiculous output from df and mount: #df Filesystem 1K-blocksUsed Avail Capacity Mounted on /dev/ad0s1a253678 137554 9583059%/ devfs 1 1 0 100%/dev /dev/ad0s1e253678 18 233366 0%/tmp /dev/ad0s1f 7782878 3273986 388626246%/usr /dev/ad0s1d253678 125386 10799854%/var devfs 1 1 0 100%/var/named/dev dell:/nfs 8883912 4104516 477939646%/dellbak dell:/nfs 8883912 4104516 477939646%/dellbak dell:/nfs 8883912 4104516 477939646%/dellbak dell:/nfs 8883912 4104516 477939646%/dellbak dell:/nfs 8883912 4104516 477939646%/dellbak dell:/nfs 8883912 4104516 477939646%/dellbak #mount /dev/ad0s1a on / (ufs, NFS exported, local) devfs on /dev (devfs, local) /dev/ad0s1e on /tmp (ufs, local, soft-updates) /dev/ad0s1f on /usr (ufs, NFS exported, local, soft-updates) /dev/ad0s1d on /var (ufs, NFS exported, local) devfs on /var/named/dev (devfs, local) dell:/nfs on /dellbak (nfs) dell:/nfs on /dellbak (nfs) dell:/nfs on /dellbak (nfs) dell:/nfs on /dellbak (nfs) dell:/nfs on /dellbak (nfs) dell:/nfs on /dellbak (nfs) Ha, ha! How many times will this last line repeat itself? I'm curious to see if I can get it to give me a screenful of data. Will this eventually crash the kernel or fill some buffer up? All I'm doing is mounting the same nfs drive over and over. Normally, mounting a device twice will just give a device busy or something. Is there some sanity check missing that will prevent mount_nfs from actually mounting the same resource at the same mount point over and over? Details: * FreeBSD 5.3. Updated and compiled in mid-February. I froze it there and may soon upgrade to 5.4, but I don't count on this fixing this issue. * I needed to make sure I had an nfs drive mounted properly, even after a reboot, but didn't want to (couldn't?) put it in fstab. So cron has this particular line(s). 44 10 * * * /sbin/mount_nfs -s -x 2 -T dell:/nfs /dellbak * I am connecting to a local net NFS server running Windows 2000 and Services for UNIX 3.5. Due to some major problems with rebooting and NFS, I determined that I needed some of the special commands (-s -x 2) to enable the server to reboot. * I put the mount_nfs command in cron and in an rc.d startup script because I didn't see a way to put all of the options in fstab, nor did I particularly enjoy booting the FreeBSD server without connecting to the NFS drive I would fill up my root directory pretty fast. * Look at the fsid for /dellbak below, using verbose output. Pretty odd. # mount -v /dev/ad0s1a on / (ufs, NFS exported, local, writes: sync 165 async 29170, reads: sync 2308 async 45, fsid f044aa41725bf386) devfs on /dev (devfs, local, fsid 01ff00040400) /dev/ad0s1e on /tmp (ufs, local, soft-updates, writes: sync 9 async 4002, reads: sync 125 async 0, fsid f144aa411e8f31da) /dev/ad0s1f on /usr (ufs, NFS exported, local, soft-updates, writes: sync 420 async 129755, reads: sync 170752 async 1401, fsid f144aa4134661c3c) /dev/ad0s1d on /var (ufs, NFS exported, local, writes: sync 32187 async 49433, reads: sync 4043 async 102, fsid f244aa416aeef171) devfs on /var/named/dev (devfs, local, fsid 02ff00040400) dell:/nfs on /dellbak (nfs, fsid 03ff00020200) dell:/nfs on /dellbak (nfs, fsid 04ff00020200) dell:/nfs on /dellbak (nfs, fsid 05ff00020200) dell:/nfs on /dellbak (nfs, fsid 06ff00020200) dell:/nfs on /dellbak (nfs, fsid 07ff00020200) dell:/nfs on /dellbak (nfs, fsid 08ff00020200) Any help? Thanks. BN ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance issue
Hello, On May 9, 2005, at 7:21 PM, Daniel Eischen wrote: I don't think that patch is correct. You need the signal mask in the kernel to match in case of an exec() after a fork() for instance. If the application fork()'s, then changes the signal mask in the child (which is now single threaded), then the child exec()s, the mask is wrong. If the process wasn't linked to libpthread, then the longjmp() and setjmp() would still be calling the syscall, so it isn't the syscall itself that is making things slower. You'll notice that there are two calls to __sys_sigprocmask() in the section of code you have patched. You could eliminate the second call if you do some of what the remainder of the function does instead of returning early (the locks aren't needed and pending signals don't need to be run down). Processes linked with libc_r NEVER call the syscall, once they have started (after rtld-elf): zZzZ:~/py% LD_LIBMAP=libpthread.so.1=libc_r.so.5 ktrace -t c python heapsort.py 1 /dev/null kdump -T | grep sigprocmask 2991 python 1115698354.240301 CALL sigprocmask (0x1,0x2810a820,0xbfbfea60) 2991 python 1115698354.240304 RET sigprocmask 0 2991 python 1115698354.240307 CALL sigprocmask(0x3,0x2810a830,0) 2991 python 1115698354.240308 RET sigprocmask 0 zZzZ:~/py% compare with libpthread: zZzZ:~/py% ktrace -t c python heapsort.py 1 /dev/null kdump - T | grep -c sigprocmask 92114 zZzZ:~/py% Is this a bug in libc_r? -- Suleiman Souhlal | [EMAIL PROTECTED] The FreeBSD Project | [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: nfs bug df: Can I lock up my kernel and overflow this buffer?
On Mon, May 09, 2005 at 11:14:51PM -0500, Billy Newsom wrote: Here's something pretty stupid about either the code in mount, df, or both. I'm on the verge of a denial of service if this lasts much longer. Why do you think so? When I mount an nfs device more than once, I get this ridiculous output from df and mount: #df Filesystem 1K-blocksUsed Avail Capacity Mounted on /dev/ad0s1a253678 137554 9583059%/ devfs 1 1 0 100%/dev /dev/ad0s1e253678 18 233366 0%/tmp /dev/ad0s1f 7782878 3273986 388626246%/usr /dev/ad0s1d253678 125386 10799854%/var devfs 1 1 0 100%/var/named/dev dell:/nfs 8883912 4104516 477939646%/dellbak dell:/nfs 8883912 4104516 477939646%/dellbak dell:/nfs 8883912 4104516 477939646%/dellbak dell:/nfs 8883912 4104516 477939646%/dellbak dell:/nfs 8883912 4104516 477939646%/dellbak dell:/nfs 8883912 4104516 477939646%/dellbak Why's it ridiculous? You mounted it more than once, so it appears more than once in the list of mounted filesystems. * Look at the fsid for /dellbak below, using verbose output. Pretty odd. Why is it odd? The fsid is by definition different for different mounts. Kris pgpoQVP1xyMlu.pgp Description: PGP signature
Re: nfs bug df: Can I lock up my kernel and overflow this buffer?
On 05/09/05 23:14, Billy Newsom wrote: snip Details: * FreeBSD 5.3. Updated and compiled in mid-February. I froze it there and may soon upgrade to 5.4, but I don't count on this fixing this issue. * I needed to make sure I had an nfs drive mounted properly, even after a reboot, but didn't want to (couldn't?) put it in fstab. So cron has this particular line(s). 44 10 * * * /sbin/mount_nfs -s -x 2 -T dell:/nfs /dellbak From the fstab(5) man page: The fourth field, (fs_mntops), describes the mount options associated with the file system. It is formatted as a comma separated list of options. It contains at least the type of mount (see fs_type below) plus any additional options appropriate to the file system type. See the options flag (-o) in the mount(8) page and the file system specific page, such as mount_nfs(8), for additional options that may be specified. What trouble did you have with fstab? You can specify as many options as you want as long as you separate them with commas (I think putting a '=' between an option and its value is also necessary, although I don't know for sure). For you it should look like this (assuming you want read/write): dell:/nfs /dellbak nfs rw,-s,-x=2,-T 0 0 -- Jonathan Noack | [EMAIL PROTECTED] | OpenPGP: 0x991D8195 signature.asc Description: OpenPGP digital signature
Re: FreeBSD 5.4-RELEASE is now available
On Mon, May 09, 2005 at 05:04:58PM -0400, Ken Smith wrote: The Release Engineering Team is happy to announce the availability of FreeBSD 5.4-RELEASE, the latest release of the FreeBSD Stable development branch. Since FreeBSD 5.3-RELEASE in November 2004 we have made many improvements in functionality, stability, performance, and device driver support for some hardware, as well as dealt with known security issues and made many bugfixes. [...] Thank you! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
freebsd and asus
Dear all! I'm preparing to build desktop box with amd64 processor and some GF3 motherboard and ati9550 video card. My dealer offers asus. Is there any issue with asus that should prevent me from that? Bios, incom- patibility with freebsd in this moment? Best regards Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance issue
On Mon, 9 May 2005, Jonathan Noack wrote: On 05/09/05 18:47, Daniel Eischen wrote: If the process wasn't linked to libpthread, then the longjmp() and setjmp() would still be calling the syscall, so it isn't the syscall itself that is making things slower. You'll notice that there are two calls to __sys_sigprocmask() in the section of code you have patched. You could eliminate the second call if you do some of what the remainder of the function does instead of returning early (the locks aren't needed and pending signals don't need to be run down). As in something like this: http://people.freebsd.org/~deischen/kse/thr_sigmask.c.diffs It has not been tested. When I tried to test this every threaded program died with sig 11. Does this require me to recompile the program before it will work? No, the patch just must have a bug in it. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nfs bug df: Can I lock up my kernel and overflow this buffer?
Jonathan Noack wrote: On 05/09/05 23:14, Billy Newsom wrote: From the fstab(5) man page: The fourth field, (fs_mntops), describes the mount options associated with the file system. It is formatted as a comma separated list of options. It contains at least the type of mount (see fs_type below) plus any additional options appropriate to the file system type. See the options flag (-o) in the mount(8) page and the file system specific page, such as mount_nfs(8), for additional options that may be specified. That is how I read the man page, too, long ago. But when I tried the -o option on the commandline, I was unable to send mount all of the mount_nfs commandline switches I needed. I either misunderstand the mount -o option, or it doesn't work for all of the mount_nfs stuff I tried to send it. In other words, the -o option seems to not like any of the many switches understood by mount_nfs hence I seemed to be forced to use mount_nfs directly. And that precludes using it in fstab. What trouble did you have with fstab? You can specify as many options as you want as long as you separate them with commas (I think putting a '=' between an option and its value is also necessary, although I don't know for sure). For you it should look like this (assuming you want read/write): dell:/nfs /dellbak nfs rw,-s,-x=2,-T 0 0 I don't know. Since mount wasn't able to understand those switches on the commandline, I never tried anything in fstab, for the sake of not causing any problems with my boot. Anyone tried that sort of stuff in fstab? I'm a little skeptical. Thanks. BN ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance issue
On Tue, 10 May 2005, Suleiman Souhlal wrote: Hello, On May 9, 2005, at 7:21 PM, Daniel Eischen wrote: I don't think that patch is correct. You need the signal mask in the kernel to match in case of an exec() after a fork() for instance. If the application fork()'s, then changes the signal mask in the child (which is now single threaded), then the child exec()s, the mask is wrong. If the process wasn't linked to libpthread, then the longjmp() ^^ or any thread library. and setjmp() would still be calling the syscall, so it isn't the syscall itself that is making things slower. You'll notice that there are two calls to __sys_sigprocmask() in the section of code you have patched. You could eliminate the second call if you do some of what the remainder of the function does instead of returning early (the locks aren't needed and pending signals don't need to be run down). Processes linked with libc_r NEVER call the syscall, once they have started (after rtld-elf): [...] Is this a bug in libc_r? No, libc_r wraps execve() and a lot of other syscalls that libpthread or libthr don't need to. Take a look at libc_r/uthread/uthread_execve.c and you will see it sets the signal mask before exec()ing. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Apache + Caching DNS: conflict at bootup? (DNS runs too late)
Hi, I'm running 5-Stable as of today. The PC is a dual-homed gateway to a local network, a caching nameserver, httpd server, firewall etc. In /etc/rc.conf, I have: named_enable=YES apache2_enable=YES The nameserver works fine after bootup, so I suppose that the named.conf is properly configured as a caching nameserver. After bootup, there's no httpd running, so I have to start it manually. During the bootup, following line occurs in httpd-error logs: hostname nor servname provided, or not known: mod_unique_id: unable to find IPv4 address of my.host.name (I faked my.host.name in this email, but it is an officially registered hostname + IP) I solved the problem, by commenting out the line LoadModule unique_id_module libexec/apache2/mod_unique_id.so in httpd.conf. But I think the actual problem is that there's a conflict in bootup order of the caching nameserver and the apache server. Some time ago, there was (or still is) a similar conflict with hostname resolution at bootup when using ntpd. Somehow the caching nameserver seems to get up and working too late in the boot process. Is that possible? Regards, Rob. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Apache + Caching DNS: conflict at bootup? (DNS runs too late)
Rob wrote: Some time ago, there was (or still is) a similar conflict with hostname resolution at bootup when using ntpd. Yes, but not with named -- the problem was only when using a dns cache from the ports tree, since those are started later in the boot sequence. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
