Re: flowtable usable or not
On 3/2/12 10:21 AM, Doug Barton wrote: On 03/02/2012 03:44, K. Macy wrote: not sure who wrote: Correct. However, I'm not sure the analogy is flawed. I am, to some degree, guilty of the same sin. I now run Ubuntu and have never had a single problem keeping my package system up date, in stark contrast to my experiences of slow and nightmarishly error-ridden port updates. but I use the PBIs from pcbsd.. you REALLY don't have this problem with them. Doug ___ 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"
[releng_9 tinderbox] failure on powerpc64/powerpc
TB --- 2012-03-03 04:27:54 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-03-03 04:27:54 - starting RELENG_9 tinderbox run for powerpc64/powerpc TB --- 2012-03-03 04:27:54 - cleaning the object tree TB --- 2012-03-03 04:27:54 - cvsupping the source tree TB --- 2012-03-03 04:27:54 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_9/powerpc64/powerpc/supfile TB --- 2012-03-03 04:28:25 - building world TB --- 2012-03-03 04:28:25 - CROSS_BUILD_TESTING=YES TB --- 2012-03-03 04:28:25 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-03 04:28:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-03 04:28:25 - SRCCONF=/dev/null TB --- 2012-03-03 04:28:25 - TARGET=powerpc TB --- 2012-03-03 04:28:25 - TARGET_ARCH=powerpc64 TB --- 2012-03-03 04:28:25 - TZ=UTC TB --- 2012-03-03 04:28:25 - __MAKE_CONF=/dev/null TB --- 2012-03-03 04:28:25 - cd /src TB --- 2012-03-03 04:28:25 - /usr/bin/make -B buildworld >>> World build started on Sat Mar 3 04:28:26 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Mar 3 07:16:52 UTC 2012 TB --- 2012-03-03 07:16:52 - generating LINT kernel config TB --- 2012-03-03 07:16:52 - cd /src/sys/powerpc/conf TB --- 2012-03-03 07:16:52 - /usr/bin/make -B LINT TB --- 2012-03-03 07:16:52 - cd /src/sys/powerpc/conf TB --- 2012-03-03 07:16:52 - /usr/sbin/config -m LINT TB --- 2012-03-03 07:16:52 - building LINT kernel TB --- 2012-03-03 07:16:52 - CROSS_BUILD_TESTING=YES TB --- 2012-03-03 07:16:52 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-03 07:16:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-03 07:16:52 - SRCCONF=/dev/null TB --- 2012-03-03 07:16:52 - TARGET=powerpc TB --- 2012-03-03 07:16:52 - TARGET_ARCH=powerpc64 TB --- 2012-03-03 07:16:52 - TZ=UTC TB --- 2012-03-03 07:16:52 - __MAKE_CONF=/dev/null TB --- 2012-03-03 07:16:52 - cd /src TB --- 2012-03-03 07:16:52 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Mar 3 07:16:52 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything -- cd /obj/powerpc.powerpc64/src/sys/LINT; MAKEOBJDIRPREFIX=/obj/powerpc.powerpc64 MACHINE_ARCH=powerpc64 MACHINE=powerpc CPUTYPE= GROFF_BIN_PATH=/obj/powerpc.powerpc64/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/obj/powerpc.powerpc64/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/obj/powerpc.powerpc64/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/obj/powerpc.powerpc64/src/tmp VERSION="FreeBSD 8.2-STABLE amd64 802512" INSTALL="sh /src/tools/install.sh" PATH=/obj/powerpc.powerpc64/src/tmp/legacy/usr/sbin:/obj/powerpc.powerpc64/src/tmp/legacy/usr/bin:/obj/powerpc.powerpc64/src/tmp/legacy/usr/games:/obj/powerpc.powerpc64/src/tmp/usr/sbin:/obj/powerpc.powerpc64/src/tmp/usr/bin:/obj/powerpc.powerpc64/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin /usr/bin/make KERNEL=kernel all -DNO_MODULES_OBJ cc -c -x assembler-with-cpp -DLOCORE -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/powerpc/aim/locore.S /src/sys/powerpc/aim/trap_subr64.S: Assembler messages: /src/sys/powerpc/aim/trap_subr64.S:421: Error: unsupported relocation against PC_SLBSTACK *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-03-03 07:19:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-03-03 07:19:19 - ERROR: failed to build LINT kernel TB --- 2012-03-03 07:19:19 - 7303.24 user 1070.76 system 10284.22 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-powerpc64-powerpc.full ___ 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: flowtable usable or not
Doug Barton wrote: > Just looking at the committers, of which we have over 300, only a > couple dozen at most have ever identified as actually using FreeBSD as > a desktop at my count. Taking the larger development community into > account I think the numbers are a little better, but not much. Sure, > our strength is servers, and that is not going to change. eventually that could be a good starting point, good question is, why not? > But how many real-life bugs have I personally uncovered in -current as > a result of actually running it (mostly) daily? I'm not the only one, > certainly, but if the numbers were flipped and the vast majority of > our developers *did* use FreeBSD routinely, how much better off would > we be? again, why? let's face some reality. Forever installing FreeBSD Desktop, either KDE or Gnome, was a nightmare process, or better, to make it appear on screen was a nightmare. Even if somebody got all packages into his system (by miracle?), it still did not popped up. Without some special knowledge _no_chance_. who knows, the guys who created and battled on area51 knew why they chose this name :) Still now, kde4, hours of install, missing packages, compiling and still nothing, somewhere over the process, flies over the screen please set kdm4_enable="YES" ... I guess that will not be noticed by any user Even if some smart guy figures out that he needs xorg-server, the port or package do not select all it needs for running, its own drivers and so. How a user should know that? There is a windeco which installs hundreds of deps, even sound what do not work on FreeBSD, but xorg do not have deps for its functionality? god ... ohhh I forgot, that has nothing to do with the desktop itself , sorry for mentioning ... Anybody can tell how somebody can find all this out? Don't say by reading because we need to look at the real facts and that is nobody want to read, they want a desktop nothing else, something silly and easy to read email and write docs and surf on the net, listen to a CD, they need to put a cd into the drive, running install process, reboot, using, nothing else and such a thing ... we do not have so where this potential users should come from? Only from heaven ... > And before anyone bothers to point it out, yes, I happen to be using > Windows at this exact moment. I have some layer 9 work to get done and > I need tools that are only available to me in Windows (more's the > pity). The sad thing is, judging by the activity on the -ports@ list, > the traffic in #bsdports, and just talking to/interacting with FreeBSD > users, a lot of *them* are not only interested in FreeBSD as a desktop > OS, they are actually doing it. IMO the weakest point is that we do not have the packages ready. Even if lots of you do not like it to hear, fact is that we must look around and see how others do it. Windows, whatever it is, it is easy to install for everybody. Same for Fedora, in order to stay with a Unix system, package handling, update with YUM on Fedora hardly fails. ALL packages are compiled, you never need to compile anything. Even if you need 800MB of packages, yum picks them all, installs them all, and all is fine up top date. Such a process is where we need to get orientation from. If it was my decision, it should be go to ports=no_no, packages=YES I mean, as long as the packages are not complete and ready, no new port version should be released or announced So who dares,understand and can or like adventures, compiles from ports Such a decision would help FreeBSD in all means and would help the users as well, in any case it will create more users Why somebody should chose FreeBSD as his daily desktop, oh man, only some die-hard-guys like you and me, but you know, that is not hours of work, that is days, weeks and constant setbacks for whatever reasons ... that is not for anybody. And you are right, no traffic on the specific lists, why? because the three on the list, two can help themselves (you and me) and the other is the moderator ... :) not even the port maintainer/packager is on that list ... :) ps. the last statement might be exaggerated and might not be valid in all cases, so please do not shoot -- H signature.asc Description: OpenPGP digital signature
Re: Regression between 9-RELEASE and 9-STABLE [PCIB ?]
Wilco ! Anything else I could usefully add ? - H On 3 March 2012 03:35, Adrian Chadd wrote: > Hi! > > You now officially have enough information to fill out a PR! Thankyou > so very much for finding out which particular commit/commits caused > this regression for you! > > http://www.freebsd.org/send-pr.html > > Would you mind doing this? :) > > Thanks! > > > Adrian > > On 2 March 2012 18:50, Harry Newton wrote: >> John, investigations shew bug introduced between 2012.02.23.22.26.00 >> and 2012.02.23.22.26.30 in these files: >> >> Edit src/sys/dev/acpica/acpi.c >> Add delta 1.305.2.4 2012.02.23.22.26.14 jkim >> Edit src/sys/dev/acpica/acpi_ec.c >> Add delta 1.95.2.2 2012.02.23.22.26.14 jkim >> Edit src/sys/dev/acpica/acpi_hpet.c >> Add delta 1.38.2.2 2012.02.23.22.26.14 jkim >> Edit src/sys/dev/acpica/acpi_timer.c >> Add delta 1.50.2.3 2012.02.23.22.26.14 jkim >> Edit src/sys/dev/acpica/acpivar.h >> Add delta 1.125.2.4 2012.02.23.22.26.14 jkim >> >> More details below. Let me know if I can do anything else. - H >> >> * dmesg >> Table 'FACP' at 0x77fd0200 >> Table 'APIC' at 0x77fd0390 >> APIC: Found table at 0x77fd0390 >> APIC: Using the MADT enumerator. >> MADT: Found CPU APIC ID 0 ACPI ID 1: enabled >> SMP: Added CPU 0 (AP) >> MADT: Found CPU APIC ID 1 ACPI ID 2: enabled >> SMP: Added CPU 1 (AP) >> Copyright (c) 1992-2012 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 is a registered trademark of The FreeBSD Foundation. >> FreeBSD 9.0-STABLE #19: Fri Mar 2 22:28:14 GMT 2012 >> t...@hydra.yewbarrow.net:/usr/obj/usr/src/sys/HYDRA amd64 >> WARNING: DIAGNOSTIC option enabled, expect reduced performance. >> Preloaded elf kernel "/boot/kernel.old/kernel" at 0x80b6f000. >> Calibrating TSC clock ... TSC clock: 2194794720 Hz >> CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2194.79-MHz K8-class >> CPU) >> Origin = "AuthenticAMD" Id = 0x40fb2 Family = f Model = 4b Stepping = 2 >> Features=0x178bfbff> MOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> >> Features2=0x2001 >> AMD Features=0xea500800 >> AMD Features2=0x1f >> L1 2MB data TLB: 8 entries, fully associative >> L1 2MB instruction TLB: 8 entries, fully associative >> L1 4KB data TLB: 32 entries, fully associative >> L1 4KB instruction TLB: 32 entries, fully associative >> L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative >> L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way >> associative >> L2 2MB unified TLB: 0 entries, disabled/not present >> L2 4KB data TLB: 512 entries, 4-way associative >> L2 4KB instruction TLB: 512 entries, 4-way associative >> L2 unified cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative >> real memory = 2147483648 (2048 MB) >> Physical memory chunk(s): >> 0x1000 - 0x0009bfff, 634880 bytes (155 pages) >> 0x0010 - 0x001f, 1048576 bytes (256 pages) >> 0x00b9e000 - 0x74722fff, 1941458944 bytes (473989 pages) >> avail memory = 1926897664 (1837 MB) >> Event timer "LAPIC" quality 400 >> ACPI APIC Table: <030107 APIC1519> >> INTR: Adding local APIC 1 as a target >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> FreeBSD/SMP: 1 package(s) x 2 core(s) >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP): APIC ID: 1 >> x86bios: IVT 0x00-0x0004ff at 0xfe00 >> x86bios: SSEG 0x001000-0x001fff at 0xff800020d000 >> x86bios: EBDA 0x09f000-0x09 at 0xfe09f000 >> x86bios: ROM 0x0a-0x0fefff at 0xfe0a >> APIC: CPU 0 has ACPI ID 1 >> APIC: CPU 1 has ACPI ID 2 >> ULE: setup cpu 0 >> ULE: setup cpu 1 >> ACPI: RSDP 0xf96d0 00014 (v00 ACPIAM) >> ACPI: RSDT 0x77fd 00038 (v01 030107 RSDT1519 20070301 MSFT 0097) >> ACPI: FACP 0x77fd0200 00084 (v02 030107 FACP1519 20070301 MSFT 0097) >> ACPI: DSDT 0x77fd0430 044A0 (v01 1ADNC 1ADNCB33 0B33 INTL 20051117) >> ACPI: FACS 0x77fde000 00040 >> ACPI: APIC 0x77fd0390 0005C (v01 030107 APIC1519 20070301 MSFT 0097) >> ACPI: MCFG 0x77fd03f0 0003C (v01 030107 OEMMCFG 20070301 MSFT 0097) >> ACPI: OEMB 0x77fde040 00071 (v01 030107 OEMB1519 20070301 MSFT 0097) >> ACPI: HPET 0x77fd48d0 00038 (v01 030107 OEMHPET 20070301 MSFT 0097) >> MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec0 >> ioapic0: Routing external 8259A's -> intpin 0 >> MADT: Interrupt override: source 0, irq 2 >> ioapic0: Routing IRQ 0 -> intpin 2 >> MADT: Interrupt override: source 9, irq 9 >> ioapic0: intpin 9 trigger: level >> ioapic0: intpin 9 polarity: low >> ioapic0 irqs 0-23 on motherboard >> cpu0 BSP: >> ID: 0x VER: 0x80050010 LDR: 0x DFR: 0x >> lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff >> timer: 0x000100ef therm: 0x0001 err: 0x00f0 pmc: 0x00010400 >> null: >> random: >> io: >> nfslock: pseudo-device >> kbd: new array size
Re: Regression between 9-RELEASE and 9-STABLE [PCIB ?]
Hi! You now officially have enough information to fill out a PR! Thankyou so very much for finding out which particular commit/commits caused this regression for you! http://www.freebsd.org/send-pr.html Would you mind doing this? :) Thanks! Adrian On 2 March 2012 18:50, Harry Newton wrote: > John, investigations shew bug introduced between 2012.02.23.22.26.00 > and 2012.02.23.22.26.30 in these files: > > Edit src/sys/dev/acpica/acpi.c > Add delta 1.305.2.4 2012.02.23.22.26.14 jkim > Edit src/sys/dev/acpica/acpi_ec.c > Add delta 1.95.2.2 2012.02.23.22.26.14 jkim > Edit src/sys/dev/acpica/acpi_hpet.c > Add delta 1.38.2.2 2012.02.23.22.26.14 jkim > Edit src/sys/dev/acpica/acpi_timer.c > Add delta 1.50.2.3 2012.02.23.22.26.14 jkim > Edit src/sys/dev/acpica/acpivar.h > Add delta 1.125.2.4 2012.02.23.22.26.14 jkim > > More details below. Let me know if I can do anything else. - H > > * dmesg > Table 'FACP' at 0x77fd0200 > Table 'APIC' at 0x77fd0390 > APIC: Found table at 0x77fd0390 > APIC: Using the MADT enumerator. > MADT: Found CPU APIC ID 0 ACPI ID 1: enabled > SMP: Added CPU 0 (AP) > MADT: Found CPU APIC ID 1 ACPI ID 2: enabled > SMP: Added CPU 1 (AP) > Copyright (c) 1992-2012 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 is a registered trademark of The FreeBSD Foundation. > FreeBSD 9.0-STABLE #19: Fri Mar 2 22:28:14 GMT 2012 > t...@hydra.yewbarrow.net:/usr/obj/usr/src/sys/HYDRA amd64 > WARNING: DIAGNOSTIC option enabled, expect reduced performance. > Preloaded elf kernel "/boot/kernel.old/kernel" at 0x80b6f000. > Calibrating TSC clock ... TSC clock: 2194794720 Hz > CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2194.79-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0x40fb2 Family = f Model = 4b Stepping = 2 > Features=0x178bfbff MOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> > Features2=0x2001 > AMD Features=0xea500800 > AMD Features2=0x1f > L1 2MB data TLB: 8 entries, fully associative > L1 2MB instruction TLB: 8 entries, fully associative > L1 4KB data TLB: 32 entries, fully associative > L1 4KB instruction TLB: 32 entries, fully associative > L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative > L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative > L2 2MB unified TLB: 0 entries, disabled/not present > L2 4KB data TLB: 512 entries, 4-way associative > L2 4KB instruction TLB: 512 entries, 4-way associative > L2 unified cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative > real memory = 2147483648 (2048 MB) > Physical memory chunk(s): > 0x1000 - 0x0009bfff, 634880 bytes (155 pages) > 0x0010 - 0x001f, 1048576 bytes (256 pages) > 0x00b9e000 - 0x74722fff, 1941458944 bytes (473989 pages) > avail memory = 1926897664 (1837 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: <030107 APIC1519> > INTR: Adding local APIC 1 as a target > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > x86bios: IVT 0x00-0x0004ff at 0xfe00 > x86bios: SSEG 0x001000-0x001fff at 0xff800020d000 > x86bios: EBDA 0x09f000-0x09 at 0xfe09f000 > x86bios: ROM 0x0a-0x0fefff at 0xfe0a > APIC: CPU 0 has ACPI ID 1 > APIC: CPU 1 has ACPI ID 2 > ULE: setup cpu 0 > ULE: setup cpu 1 > ACPI: RSDP 0xf96d0 00014 (v00 ACPIAM) > ACPI: RSDT 0x77fd 00038 (v01 030107 RSDT1519 20070301 MSFT 0097) > ACPI: FACP 0x77fd0200 00084 (v02 030107 FACP1519 20070301 MSFT 0097) > ACPI: DSDT 0x77fd0430 044A0 (v01 1ADNC 1ADNCB33 0B33 INTL 20051117) > ACPI: FACS 0x77fde000 00040 > ACPI: APIC 0x77fd0390 0005C (v01 030107 APIC1519 20070301 MSFT 0097) > ACPI: MCFG 0x77fd03f0 0003C (v01 030107 OEMMCFG 20070301 MSFT 0097) > ACPI: OEMB 0x77fde040 00071 (v01 030107 OEMB1519 20070301 MSFT 0097) > ACPI: HPET 0x77fd48d0 00038 (v01 030107 OEMHPET 20070301 MSFT 0097) > MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec0 > ioapic0: Routing external 8259A's -> intpin 0 > MADT: Interrupt override: source 0, irq 2 > ioapic0: Routing IRQ 0 -> intpin 2 > MADT: Interrupt override: source 9, irq 9 > ioapic0: intpin 9 trigger: level > ioapic0: intpin 9 polarity: low > ioapic0 irqs 0-23 on motherboard > cpu0 BSP: > ID: 0x VER: 0x80050010 LDR: 0x DFR: 0x > lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff > timer: 0x000100ef therm: 0x0001 err: 0x00f0 pmc: 0x00010400 > null: > random: > io: > nfslock: pseudo-device > kbd: new array size 4 > kbd1 at kbdmux0 > mem: > acpi0: <030107 RSDT1519> on motherboard > PCIe: Memory Mapped configuration base @ 0xe000 > ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 > ACPI: Executed 3 blocks of module-level
Re: FreeBSD 9.0 release - memstick installation fails
In article <719f8e0e-f88d-48e7-b2b7-aba44b4f4...@free.de>, galla...@free.de wrote: >Trying to install 9.0 release with a USB stick. >I use FreeBSD-9.0-RELEASE-amd64-memstick.img > >At first the bootup looks promising, but in the end it stops with "Root >mount waiting for: usbus2 usbus1 usbus" The 9.0 memstick image worked (nearly[1]) flawlessly for me, albeit on a different kind of device. It would be really nice if it supported installing directly onto ZFS, though, so that I could avoid doing the install-on-UFS, copy-to-ZFS, pull-boot-drive-and-reboot, reinsert-boot-drive-and-add-to-mirror business. Getting /boot/zfs/zpool.cache is really tricky with the new livefs architecture -- I was able to install on a ZFS pool just fine, but I wasted three hours trying to make it bootable before giving up and doing it the old-fashioned way. (That machine is now being tested as an NFS fileserver[2], getting the snot beat out of it by our most abusive users.) -GAWollman [1] The mps driver in 9.0 is no good, and would not allow the system to boot while even one drive shelf was hooked up. Booting with external drives disconnected, then connecting them in multiuser mode, works fine, although it didn't see one of the SES targets. After cherry-picking the new LSI-supported driver from 9-stable, it boots fine and sees all of the SES devices. [2] wollman@zfsnfs(9)$ uptime 10:17PM up 4 days, 13:07, 2 users, load averages: 8.54, 8.49, 8.72 wollman@zfsnfs(10)$ zpool status export pool: export state: ONLINE scan: scrub canceled on Thu Mar 1 15:22:42 2012 config: NAME STATE READ WRITE CKSUM exportONLINE 0 0 0 raidz2-0ONLINE 0 0 0 multipath/disk2 ONLINE 0 0 0 multipath/disk3 ONLINE 0 0 0 multipath/disk4 ONLINE 0 0 0 multipath/disk5 ONLINE 0 0 0 multipath/disk6 ONLINE 0 0 0 multipath/disk7 ONLINE 0 0 0 multipath/disk8 ONLINE 0 0 0 multipath/disk9 ONLINE 0 0 0 multipath/disk10 ONLINE 0 0 0 multipath/disk11 ONLINE 0 0 0 multipath/disk12 ONLINE 0 0 0 raidz2-1ONLINE 0 0 0 multipath/disk14 ONLINE 0 0 0 multipath/disk16 ONLINE 0 0 0 multipath/disk17 ONLINE 0 0 0 multipath/disk19 ONLINE 0 0 0 multipath/disk20 ONLINE 0 0 0 multipath/disk21 ONLINE 0 0 0 multipath/disk22 ONLINE 0 0 0 multipath/disk23 ONLINE 0 0 0 multipath/disk24 ONLINE 0 0 0 multipath/disk25 ONLINE 0 0 0 multipath/disk26 ONLINE 0 0 0 raidz2-2ONLINE 0 0 0 multipath/disk27 ONLINE 0 0 0 multipath/disk28 ONLINE 0 0 0 multipath/disk29 ONLINE 0 0 0 multipath/disk30 ONLINE 0 0 0 multipath/disk31 ONLINE 0 0 0 multipath/disk32 ONLINE 0 0 0 multipath/disk33 ONLINE 0 0 0 multipath/disk34 ONLINE 0 0 0 multipath/disk35 ONLINE 0 0 0 multipath/disk36 ONLINE 0 0 0 multipath/disk37 ONLINE 0 0 0 raidz2-3ONLINE 0 0 0 multipath/disk38 ONLINE 0 0 0 multipath/disk39 ONLINE 0 0 0 multipath/disk40 ONLINE 0 0 0 multipath/disk41 ONLINE 0 0 0 multipath/disk42 ONLINE 0 0 0 multipath/disk43 ONLINE 0 0 0 multipath/disk44 ONLINE 0 0 0 multipath/disk45 ONLINE 0 0 0 multipath/disk46 ONLINE 0 0 0 multipath/disk47 ONLINE 0 0 0 multipath/disk48 ONLINE 0 0 0 raidz2-4ONLINE 0 0 0 multipath/disk49 ONLINE 0 0 0 multipath/disk50 ONLINE 0 0 0 multipath/disk52 ONLINE 0 0 0 multipath/disk53 ONLINE 0 0 0 multipath/disk54 ONLINE 0 0 0 multipath/disk55 ONLINE 0 0 0 multipath/disk56 ONLINE 0 0 0 multipath/disk57 ONLINE 0 0 0 multipath/disk58 ONLINE 0 0
Re: Regression between 9-RELEASE and 9-STABLE [PCIB ?]
John, investigations shew bug introduced between 2012.02.23.22.26.00 and 2012.02.23.22.26.30 in these files: Edit src/sys/dev/acpica/acpi.c Add delta 1.305.2.4 2012.02.23.22.26.14 jkim Edit src/sys/dev/acpica/acpi_ec.c Add delta 1.95.2.2 2012.02.23.22.26.14 jkim Edit src/sys/dev/acpica/acpi_hpet.c Add delta 1.38.2.2 2012.02.23.22.26.14 jkim Edit src/sys/dev/acpica/acpi_timer.c Add delta 1.50.2.3 2012.02.23.22.26.14 jkim Edit src/sys/dev/acpica/acpivar.h Add delta 1.125.2.4 2012.02.23.22.26.14 jkim More details below. Let me know if I can do anything else. - H * dmesg Table 'FACP' at 0x77fd0200 Table 'APIC' at 0x77fd0390 APIC: Found table at 0x77fd0390 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 2: enabled SMP: Added CPU 1 (AP) Copyright (c) 1992-2012 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-STABLE #19: Fri Mar 2 22:28:14 GMT 2012 t...@hydra.yewbarrow.net:/usr/obj/usr/src/sys/HYDRA amd64 WARNING: DIAGNOSTIC option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel.old/kernel" at 0x80b6f000. Calibrating TSC clock ... TSC clock: 2194794720 Hz CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2194.79-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x40fb2 Family = f Model = 4b Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f L1 2MB data TLB: 8 entries, fully associative L1 2MB instruction TLB: 8 entries, fully associative L1 4KB data TLB: 32 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB unified TLB: 0 entries, disabled/not present L2 4KB data TLB: 512 entries, 4-way associative L2 4KB instruction TLB: 512 entries, 4-way associative L2 unified cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative real memory = 2147483648 (2048 MB) Physical memory chunk(s): 0x1000 - 0x0009bfff, 634880 bytes (155 pages) 0x0010 - 0x001f, 1048576 bytes (256 pages) 0x00b9e000 - 0x74722fff, 1941458944 bytes (473989 pages) avail memory = 1926897664 (1837 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: <030107 APIC1519> INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 x86bios: IVT 0x00-0x0004ff at 0xfe00 x86bios: SSEG 0x001000-0x001fff at 0xff800020d000 x86bios: EBDA 0x09f000-0x09 at 0xfe09f000 x86bios: ROM 0x0a-0x0fefff at 0xfe0a APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP 0xf96d0 00014 (v00 ACPIAM) ACPI: RSDT 0x77fd 00038 (v01 030107 RSDT1519 20070301 MSFT 0097) ACPI: FACP 0x77fd0200 00084 (v02 030107 FACP1519 20070301 MSFT 0097) ACPI: DSDT 0x77fd0430 044A0 (v01 1ADNC 1ADNCB33 0B33 INTL 20051117) ACPI: FACS 0x77fde000 00040 ACPI: APIC 0x77fd0390 0005C (v01 030107 APIC1519 20070301 MSFT 0097) ACPI: MCFG 0x77fd03f0 0003C (v01 030107 OEMMCFG 20070301 MSFT 0097) ACPI: OEMB 0x77fde040 00071 (v01 030107 OEMB1519 20070301 MSFT 0097) ACPI: HPET 0x77fd48d0 00038 (v01 030107 OEMHPET 20070301 MSFT 0097) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec0 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: low ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x VER: 0x80050010 LDR: 0x DFR: 0x lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff timer: 0x000100ef therm: 0x0001 err: 0x00f0 pmc: 0x00010400 null: random: io: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: acpi0: <030107 RSDT1519> on motherboard PCIe: Memory Mapped configuration base @ 0xe000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 ACPI: Executed 3 blocks of module-level executable AML code acpi0: Power Button (fixed) acpi0: reservation of fee0, 1000 (3) failed acpi0: reservation of ffb8, 8 (3) failed acpi0: reservation of fff8, 8 (3) failed acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 77f0 (3) failed ACPI timer: 1/1 1/2 0/3 1/2 1/2 1/2 1/3 1/2 1/2 1/2 -> 9 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu0: switching to generic Cx mode cpu1: on a
Re: Long delay on boot 9.0R on vmware+zfs
On Fri, Mar 02, 2012 at 12:25:24PM -0600, Adam Vande More wrote: > On Fri, Mar 2, 2012 at 12:17 PM, Slawa Olhovchenkov wrote: > > > Long delay (more 30 seconds) on loader disk detect. > > Debug print pointed to zfs/zfs.c:zfs_dev_init. > > This function found disk0 and walked over 128 potencial slices, trying > > 'p' slice and 's' slice. Each attempt -- 1/4s (and nothing found). > > > > How to speed up boot? > > > > Sounds quite similar to this: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=148296 I think no delayed in bd_open_gpt. ___ 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: flowtable usable or not
I've had the same problem with wireless. For some users, wireless works flawlessly. For other users, it's completely unusable. Trying to get any kind of useful feedback from people has been impossible at best. I've even had FreeBSD developers, sitting in the developers IRC channel, say wifi is so broken on FreeBSD they have to boot into windows to get anything done. Yet I still haven't seen any PRs about this. This is why I've been pushing people to keep filing PRs. I can't even begin to investigate what I don't know is broken and if the _developers_ don't use FreeBSD because supported wifi stuff is broken, then .. well, no hope, etc. The honest truth is this: for any system to work, there needs to be: * sufficient users reporting issues; * sufficient developers (and/or companies) wanting it to work and keeping the bug fixes coming; * a healthy cycle between the above two. If _either_ there are no developers or there is no feedback to the developer(s), the cycle breaks, and things rot in very annoying ways. Then you have the next problem, which is: * if it doesn't work, noone will use it * if noone uses it, noone will work on it. Try breaking that cycle. 2c, 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: FreeBSD 9.0 release - memstick installation fails
On Fri, 2012-03-02 Sean Bruno wrote: > You may want to try playing around with BIOS settings regarding USB. I'd happily do so, but unfortunately this BIOS.. PhoenixBIOS 4.0 Release 6.1 HP System BIOS - O09 (07/19/2007) HP FEATURES VERSION : 1.08.00 has no USB knobs to turn. Kai. > On Fri, 2012-03-02 at 13:01 -0800, Kai Gallasch wrote: >> Hi list. >> >> Trying to install 9.0 release with a USB stick. >> I use FreeBSD-9.0-RELEASE-amd64-memstick.img >> >> At first the bootup looks promising, but in the end it stops with "Root >> mount waiting for: usbus2 usbus1 usbus" >> >> To single out a bad USB stick I tried FreeBSD-8.3-BETA1-amd64-memstick.img >> with the same stick and there are no problems. >> >> The hardware is an older HP/Compaq DL145-G3, but why toss it in the trash? >> >> How can I debug this further? >> Any hints? >> >> Kai. >> >> >> snip >> >> SMAP type=01 base= len=0009c000 >> SMAP type=02 base=0009c000 len=4000 >> SMAP type=02 base=000ce000 len=00032000 >> SMAP type=01 base=0010 len=dbe6 >> SMAP type=03 base=dbf6 len=7000 >> SMAP type=04 base=dbf67000 len=00019000 >> SMAP type=02 base=dbf8 len=0008 >> SMAP type=02 base=e000 len=1000 >> SMAP type=02 base=fec0 len=3000 >> SMAP type=02 base=fee0 len=1000 >> SMAP type=02 base=fff8 len=0008 >> SMAP type=01 base=0001 len=00012400 >> Table 'FACP' at 0xdbf62be7 >> Table 'SPMI' at 0xdbf66bf5 >> Table 'SSDT' at 0xdbf66c35 >> Table 'HPET' at 0xdbf66e7d >> Table 'SSDT' at 0xdbf66eb5 >> Table 'MCFG' at 0xdbf66efe >> Table 'SPCR' at 0xdbf66f3a >> Table 'APIC' at 0xdbf66f8a >> APIC: Found table at 0xdbf66f8a >> APIC: Using the MADT enumerator. >> MADT: Found CPU APIC ID 0 ACPI ID 0: enabled >> SMP: Added CPU 0 (AP) >> MADT: Found CPU APIC ID 1 ACPI ID 1: enabled >> SMP: Added CPU 1 (AP) >> Copyright (c) 1992-2012 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 is a registered trademark of The FreeBSD Foundation. >> FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 >> r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >> Table 'FACP' at 0xdbf62be7 >> Table 'SPMI' at 0xdbf66bf5 >> Table 'SSDT' at 0xdbf66c35 >> Table 'HPET' at 0xdbf66e7d >> Table 'SSDT' at 0xdbf66eb5 >> Table 'MCFG' at 0xdbf66efe >> Table 'SPCR' at 0xdbf66f3a >> Table 'APIC' at 0xdbf66f8a >> ACPI: No SRAT table found >> Preloaded elf kernel "/boot/kernel/kernel" at 0x813cf000. >> Calibrating TSC clock ... TSC clock: 2394059007 Hz >> CPU: Dual-Core AMD Opteron(tm) Processor 2216 HE (2394.06-MHz K8-class CPU) >> Origin = "AuthenticAMD" Id = 0x40f13 Family = f Model = 41 Stepping = 3 >> Features=0x178bfbff >> Features2=0x2001 >> AMD Features=0xea500800 >> AMD Features2=0x1f >> L1 2MB data TLB: 8 entries, fully associative >> L1 2MB instruction TLB: 8 entries, fully associative >> L1 4KB data TLB: 32 entries, fully associative >> L1 4KB instruction TLB: 32 entries, fully associative >> L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative >> L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way >> associative >> L2 2MB unified TLB: 0 entries, disabled/not present >> L2 4KB data TLB: 512 entries, 4-way associative >> L2 4KB instruction TLB: 512 entries, 4-way associative >> L2 unified cache: 1024 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative >> real memory = 8589934592 (8192 MB) >> Physical memory chunk(s): >> 0x1000 - 0x00097fff, 618496 bytes (151 pages) >> 0x0010 - 0x001f, 1048576 bytes (256 pages) >> 0x01403000 - 0xdbf5, 3669348352 bytes (895837 pages) >> 0x0001 - 0x000213e45fff, 4628701184 bytes (1130054 pages) >> avail memory = 8244486144 (7862 MB) >> Event timer "LAPIC" quality 400 >> ACPI APIC Table: >> INTR: Adding local APIC 1 as a target >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> FreeBSD/SMP: 1 package(s) x 2 core(s) >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP): APIC ID: 1 >> x86bios: IVT 0x00-0x0004ff at 0xfe00 >> x86bios: SSEG 0x001000-0x001fff at 0xff800022 >> x86bios: EBDA 0x09c000-0x09 at 0xfe09c000 >> x86bios: ROM 0x0a-0x0fefff at 0xfe0a >> APIC: CPU 0 has ACPI ID 0 >> APIC: CPU 1 has ACPI ID 1 >> ULE: setup cpu 0 >> ULE: setup cpu 1 >> ACPI: RSDP 0xf8510 00024 (v02 PTLTD ) >> ACPI: XSDT 0xdbf62b83 00064 (v01 PTLTD ? XSDT 0604 LTP ) >> ACPI: FACP 0xdbf62be7 00084 (v02 HP TREX 0604 MSFT 0201) >> ACPI: DSDT 0xdbf62c6b 03F8A (v01 HP TREX 0604 MSFT 0202) >> ACPI: FACS 0xdbf6ffc0 00040 >> ACPI: SPMI 0xdb
Re: flowtable usable or not
on 03/03/2012 00:24 Doug Barton said the following: > On 3/2/2012 1:27 PM, Andriy Gapon wrote: >> on 02/03/2012 20:21 Doug Barton said the following: >>> ... and here is the crux of the problem. The vast majority of our >>> developers don't use FreeBSD as their regular workstation. >> >> Do you care to back this up with facts? > > You mean other than the very few hands that go up whenever we discuss > "who is actually using FreeBSD as their desktop?" If that doesn't work > for you, look around at the next developer's summit and take note of the > overwhelming preponderance of fruit logos. > > Just looking at the committers, of which we have over 300, only a couple > dozen at most have ever identified as actually using FreeBSD as a > desktop at my count. Taking the larger development community into > account I think the numbers are a little better, but not much. OK, I agree that anyone can have his own impressions and now I realize that you stated your own impression based on your observations. It's just that it sounded like you stated a fact. -- Andriy Gapon ___ 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: flowtable usable or not
On 3/2/2012 1:27 PM, Andriy Gapon wrote: > on 02/03/2012 20:21 Doug Barton said the following: >> ... and here is the crux of the problem. The vast majority of our >> developers don't use FreeBSD as their regular workstation. > > Do you care to back this up with facts? You mean other than the very few hands that go up whenever we discuss "who is actually using FreeBSD as their desktop?" If that doesn't work for you, look around at the next developer's summit and take note of the overwhelming preponderance of fruit logos. Just looking at the committers, of which we have over 300, only a couple dozen at most have ever identified as actually using FreeBSD as a desktop at my count. Taking the larger development community into account I think the numbers are a little better, but not much. Sure, our strength is servers, and that is not going to change. But how many real-life bugs have I personally uncovered in -current as a result of actually running it (mostly) daily? I'm not the only one, certainly, but if the numbers were flipped and the vast majority of our developers *did* use FreeBSD routinely, how much better off would we be? And before anyone bothers to point it out, yes, I happen to be using Windows at this exact moment. I have some layer 9 work to get done and I need tools that are only available to me in Windows (more's the pity). The sad thing is, judging by the activity on the -ports@ list, the traffic in #bsdports, and just talking to/interacting with FreeBSD users, a lot of *them* are not only interested in FreeBSD as a desktop OS, they are actually doing it. Doug -- This .signature sanitized for your protection ___ 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: FreeBSD 9.0 release - memstick installation fails
You may want to try playing around with BIOS settings regarding USB. Sean On Fri, 2012-03-02 at 13:01 -0800, Kai Gallasch wrote: > Hi list. > > Trying to install 9.0 release with a USB stick. > I use FreeBSD-9.0-RELEASE-amd64-memstick.img > > At first the bootup looks promising, but in the end it stops with "Root mount > waiting for: usbus2 usbus1 usbus" > > To single out a bad USB stick I tried FreeBSD-8.3-BETA1-amd64-memstick.img > with the same stick and there are no problems. > > The hardware is an older HP/Compaq DL145-G3, but why toss it in the trash? > > How can I debug this further? > Any hints? > > Kai. > > > snip > > SMAP type=01 base= len=0009c000 > SMAP type=02 base=0009c000 len=4000 > SMAP type=02 base=000ce000 len=00032000 > SMAP type=01 base=0010 len=dbe6 > SMAP type=03 base=dbf6 len=7000 > SMAP type=04 base=dbf67000 len=00019000 > SMAP type=02 base=dbf8 len=0008 > SMAP type=02 base=e000 len=1000 > SMAP type=02 base=fec0 len=3000 > SMAP type=02 base=fee0 len=1000 > SMAP type=02 base=fff8 len=0008 > SMAP type=01 base=0001 len=00012400 > Table 'FACP' at 0xdbf62be7 > Table 'SPMI' at 0xdbf66bf5 > Table 'SSDT' at 0xdbf66c35 > Table 'HPET' at 0xdbf66e7d > Table 'SSDT' at 0xdbf66eb5 > Table 'MCFG' at 0xdbf66efe > Table 'SPCR' at 0xdbf66f3a > Table 'APIC' at 0xdbf66f8a > APIC: Found table at 0xdbf66f8a > APIC: Using the MADT enumerator. > MADT: Found CPU APIC ID 0 ACPI ID 0: enabled > SMP: Added CPU 0 (AP) > MADT: Found CPU APIC ID 1 ACPI ID 1: enabled > SMP: Added CPU 1 (AP) > Copyright (c) 1992-2012 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 is a registered trademark of The FreeBSD Foundation. > FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 >r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > Table 'FACP' at 0xdbf62be7 > Table 'SPMI' at 0xdbf66bf5 > Table 'SSDT' at 0xdbf66c35 > Table 'HPET' at 0xdbf66e7d > Table 'SSDT' at 0xdbf66eb5 > Table 'MCFG' at 0xdbf66efe > Table 'SPCR' at 0xdbf66f3a > Table 'APIC' at 0xdbf66f8a > ACPI: No SRAT table found > Preloaded elf kernel "/boot/kernel/kernel" at 0x813cf000. > Calibrating TSC clock ... TSC clock: 2394059007 Hz > CPU: Dual-Core AMD Opteron(tm) Processor 2216 HE (2394.06-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0x40f13 Family = f Model = 41 Stepping = 3 > > Features=0x178bfbff > Features2=0x2001 > AMD Features=0xea500800 > AMD Features2=0x1f > L1 2MB data TLB: 8 entries, fully associative > L1 2MB instruction TLB: 8 entries, fully associative > L1 4KB data TLB: 32 entries, fully associative > L1 4KB instruction TLB: 32 entries, fully associative > L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative > L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative > L2 2MB unified TLB: 0 entries, disabled/not present > L2 4KB data TLB: 512 entries, 4-way associative > L2 4KB instruction TLB: 512 entries, 4-way associative > L2 unified cache: 1024 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative > real memory = 8589934592 (8192 MB) > Physical memory chunk(s): > 0x1000 - 0x00097fff, 618496 bytes (151 pages) > 0x0010 - 0x001f, 1048576 bytes (256 pages) > 0x01403000 - 0xdbf5, 3669348352 bytes (895837 pages) > 0x0001 - 0x000213e45fff, 4628701184 bytes (1130054 pages) > avail memory = 8244486144 (7862 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > INTR: Adding local APIC 1 as a target > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > x86bios: IVT 0x00-0x0004ff at 0xfe00 > x86bios: SSEG 0x001000-0x001fff at 0xff800022 > x86bios: EBDA 0x09c000-0x09 at 0xfe09c000 > x86bios: ROM 0x0a-0x0fefff at 0xfe0a > APIC: CPU 0 has ACPI ID 0 > APIC: CPU 1 has ACPI ID 1 > ULE: setup cpu 0 > ULE: setup cpu 1 > ACPI: RSDP 0xf8510 00024 (v02 PTLTD ) > ACPI: XSDT 0xdbf62b83 00064 (v01 PTLTD ? XSDT 0604 LTP ) > ACPI: FACP 0xdbf62be7 00084 (v02 HP TREX 0604 MSFT 0201) > ACPI: DSDT 0xdbf62c6b 03F8A (v01 HP TREX 0604 MSFT 0202) > ACPI: FACS 0xdbf6ffc0 00040 > ACPI: SPMI 0xdbf66bf5 00040 (v05 HP TREX 0604 PTL 0001) > ACPI: SSDT 0xdbf66c35 00248 (v01 PTLTD POWERNOW 0604 LTP 0001) > ACPI: HPET 0xdbf66e7d 00038 (v01 BRCM EXPLOSN 0604 BRCM 0201) > ACPI: SSDT 0xdbf66eb5 00049 (v01 PTLTDSSDT 0604 AMD 0201) > ACPI: MCFG 0xdbf66efe 0003C (v01
FreeBSD 9.0 release - memstick installation fails
Hi list. Trying to install 9.0 release with a USB stick. I use FreeBSD-9.0-RELEASE-amd64-memstick.img At first the bootup looks promising, but in the end it stops with "Root mount waiting for: usbus2 usbus1 usbus" To single out a bad USB stick I tried FreeBSD-8.3-BETA1-amd64-memstick.img with the same stick and there are no problems. The hardware is an older HP/Compaq DL145-G3, but why toss it in the trash? How can I debug this further? Any hints? Kai. snip SMAP type=01 base= len=0009c000 SMAP type=02 base=0009c000 len=4000 SMAP type=02 base=000ce000 len=00032000 SMAP type=01 base=0010 len=dbe6 SMAP type=03 base=dbf6 len=7000 SMAP type=04 base=dbf67000 len=00019000 SMAP type=02 base=dbf8 len=0008 SMAP type=02 base=e000 len=1000 SMAP type=02 base=fec0 len=3000 SMAP type=02 base=fee0 len=1000 SMAP type=02 base=fff8 len=0008 SMAP type=01 base=0001 len=00012400 Table 'FACP' at 0xdbf62be7 Table 'SPMI' at 0xdbf66bf5 Table 'SSDT' at 0xdbf66c35 Table 'HPET' at 0xdbf66e7d Table 'SSDT' at 0xdbf66eb5 Table 'MCFG' at 0xdbf66efe Table 'SPCR' at 0xdbf66f3a Table 'APIC' at 0xdbf66f8a APIC: Found table at 0xdbf66f8a APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 1: enabled SMP: Added CPU 1 (AP) Copyright (c) 1992-2012 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Table 'FACP' at 0xdbf62be7 Table 'SPMI' at 0xdbf66bf5 Table 'SSDT' at 0xdbf66c35 Table 'HPET' at 0xdbf66e7d Table 'SSDT' at 0xdbf66eb5 Table 'MCFG' at 0xdbf66efe Table 'SPCR' at 0xdbf66f3a Table 'APIC' at 0xdbf66f8a ACPI: No SRAT table found Preloaded elf kernel "/boot/kernel/kernel" at 0x813cf000. Calibrating TSC clock ... TSC clock: 2394059007 Hz CPU: Dual-Core AMD Opteron(tm) Processor 2216 HE (2394.06-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x40f13 Family = f Model = 41 Stepping = 3 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f L1 2MB data TLB: 8 entries, fully associative L1 2MB instruction TLB: 8 entries, fully associative L1 4KB data TLB: 32 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB unified TLB: 0 entries, disabled/not present L2 4KB data TLB: 512 entries, 4-way associative L2 4KB instruction TLB: 512 entries, 4-way associative L2 unified cache: 1024 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative real memory = 8589934592 (8192 MB) Physical memory chunk(s): 0x1000 - 0x00097fff, 618496 bytes (151 pages) 0x0010 - 0x001f, 1048576 bytes (256 pages) 0x01403000 - 0xdbf5, 3669348352 bytes (895837 pages) 0x0001 - 0x000213e45fff, 4628701184 bytes (1130054 pages) avail memory = 8244486144 (7862 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 x86bios: IVT 0x00-0x0004ff at 0xfe00 x86bios: SSEG 0x001000-0x001fff at 0xff800022 x86bios: EBDA 0x09c000-0x09 at 0xfe09c000 x86bios: ROM 0x0a-0x0fefff at 0xfe0a APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP 0xf8510 00024 (v02 PTLTD ) ACPI: XSDT 0xdbf62b83 00064 (v01 PTLTD ? XSDT 0604 LTP ) ACPI: FACP 0xdbf62be7 00084 (v02 HP TREX 0604 MSFT 0201) ACPI: DSDT 0xdbf62c6b 03F8A (v01 HP TREX 0604 MSFT 0202) ACPI: FACS 0xdbf6ffc0 00040 ACPI: SPMI 0xdbf66bf5 00040 (v05 HP TREX 0604 PTL 0001) ACPI: SSDT 0xdbf66c35 00248 (v01 PTLTD POWERNOW 0604 LTP 0001) ACPI: HPET 0xdbf66e7d 00038 (v01 BRCM EXPLOSN 0604 BRCM 0201) ACPI: SSDT 0xdbf66eb5 00049 (v01 PTLTDSSDT 0604 AMD 0201) ACPI: MCFG 0xdbf66efe 0003C (v01 PTLTDMCFG 0604 AMD 0201) ACPI: SPCR 0xdbf66f3a 00050 (v01 PTLTD $UCRTBL$ 0604 PTL 0001) ACPI: APIC 0xdbf66f8a 00076 (v01 PTLTDAPIC 0604 LTP ) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec0 ioapic0: Routing external 8259A's -> intpin 0 MADT: Found IO APIC ID 3, Interrupt 16 at 0xfec01000 MADT: Found IO APIC
Re: flowtable usable or not
on 02/03/2012 20:21 Doug Barton said the following: > ... and here is the crux of the problem. The vast majority of our > developers don't use FreeBSD as their regular workstation. Do you care to back this up with facts? Or are you going beyond constructive in your [self-]criticism of FreeBSD [OS, developers, procedures, community, etc]? -- Andriy Gapon ___ 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: flowtable usable or not
Doug Barton wrote: > ... and here is the crux of the problem. The vast majority of our > developers don't use FreeBSD as their regular workstation. So it has > increasingly become an OS where changes are being lobbed over the wall > by developers who don't run systems that those changes affect. That's > no way to run a railroad. Doug wow since it is not April 1st it must be revelation's day ...:) is this then the bottomline ? if [ $using_ports=YES ]; get_screwed($big_time); fi -- H signature.asc Description: OpenPGP digital signature
Re: ports usable or not [was: flowtable usable or not]
Yeah, I've been trying to prioritize some -exps that are blocking other people right now. I know there's many more :-) mcl ___ 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: Long delay on boot 9.0R on vmware+zfs
On Fri, Mar 02, 2012 at 12:25:24PM -0600, Adam Vande More wrote: > On Fri, Mar 2, 2012 at 12:17 PM, Slawa Olhovchenkov wrote: > > > Long delay (more 30 seconds) on loader disk detect. > > Debug print pointed to zfs/zfs.c:zfs_dev_init. > > This function found disk0 and walked over 128 potencial slices, trying > > 'p' slice and 's' slice. Each attempt -- 1/4s (and nothing found). > > > > How to speed up boot? > > > > Sounds quite similar to this: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=148296 Need to re-open? ___ 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: Resume broken in 8.3-PRERELEASE
On Friday 02 March 2012 03:50 am, Alexey Dokuchaev wrote:
> On Thu, Mar 01, 2012 at 04:55:03PM -0500, Jung-uk Kim wrote:
> > It does not make a difference for me (i.e., usb suspend/resume
> > still broken) but I think I found a typo:
> >
> > --- sys/dev/usb/controller/usb_controller.c (revision 232365)
> > +++ sys/dev/usb/controller/usb_controller.c (working copy)
> > @@ -407,7 +407,7 @@ usb_bus_suspend(struct usb_proc_msg *pm)
> >
> > USB_BUS_UNLOCK(bus);
> >
> > - bus_generic_shutdown(bus->bdev);
> > + bus_generic_suspend(bus->bdev);
> >
> > usbd_enum_lock(udev);
>
> Same thing here, does not seem to improve anything. It might
> suspend, resume (with keyboard working), then die on next suspend
> completely. Or it may die on the first suspend (without suspending
> -- fans are spinning, screen is black and no response to anything
> except hard power-off), this actually happens more often.
Try the attached patch. At least, it fixed my problem.
> ./danfe
>
> P.S. Also, doing "ps" in debugger shows that acpiconf(8) is
> running in the userland upon resume (and hang). Not sure if it
> helps or not though.
It usually means a device driver couldn't resume (and hang).
Jung-uk Kim
Index: sys/dev/usb/controller/usb_controller.c
===
--- sys/dev/usb/controller/usb_controller.c (revision 232401)
+++ sys/dev/usb/controller/usb_controller.c (working copy)
@@ -89,10 +89,15 @@ TUNABLE_INT("hw.usb.no_boot_wait", &usb_no_boot_wa
SYSCTL_INT(_hw_usb, OID_AUTO, no_boot_wait, CTLFLAG_RDTUN, &usb_no_boot_wait,
0,
"No USB device enumerate waiting at boot.");
+static int usb_no_suspend_wait = 0;
+TUNABLE_INT("hw.usb.no_suspend_wait", &usb_no_suspend_wait);
+SYSCTL_INT(_hw_usb, OID_AUTO, no_suspend_wait, CTLFLAG_RW|CTLFLAG_TUN,
+&usb_no_suspend_wait, 0, "No USB device waiting at system suspend.");
+
static int usb_no_shutdown_wait = 0;
TUNABLE_INT("hw.usb.no_shutdown_wait", &usb_no_shutdown_wait);
-SYSCTL_INT(_hw_usb, OID_AUTO, no_shutdown_wait, CTLFLAG_RW|CTLFLAG_TUN,
&usb_no_shutdown_wait, 0,
-"No USB device waiting at system shutdown.");
+SYSCTL_INT(_hw_usb, OID_AUTO, no_shutdown_wait, CTLFLAG_RW|CTLFLAG_TUN,
+&usb_no_shutdown_wait, 0, "No USB device waiting at system shutdown.");
static devclass_t usb_devclass;
@@ -240,6 +245,11 @@ usb_suspend(device_t dev)
USB_BUS_LOCK(bus);
usb_proc_msignal(&bus->explore_proc,
&bus->suspend_msg[0], &bus->suspend_msg[1]);
+ if (usb_no_suspend_wait == 0) {
+ /* wait for suspend callback to be executed */
+ usb_proc_mwait(&bus->explore_proc,
+ &bus->suspend_msg[0], &bus->suspend_msg[1]);
+ }
USB_BUS_UNLOCK(bus);
return (0);
@@ -407,7 +417,7 @@ usb_bus_suspend(struct usb_proc_msg *pm)
USB_BUS_UNLOCK(bus);
- bus_generic_shutdown(bus->bdev);
+ bus_generic_suspend(bus->bdev);
usbd_enum_lock(udev);
___
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: flowtable usable or not
> No, I already pointed out the distinction between "new, experimental > features;" and "essential components of the FreeBSD operating system." > It's Ok for you to disagree with that distinction, or with its > importance. But what you're suggesting is that if users don't help > developers debug "cool new feature X" then we won't have "cool new > feature X." By implication you're saying that if we don't continue to > develop cool new features then at some point down the road we wither and > die. What I have tried ever-so-delicately to avoid saying is that lack > of user help with debugging "cool new feature X" is generally a sign of > lack of user demand for "cool new feature X." Not all cool new ideas are > good ones. :) Considering there are firewall vendors and CDNs making consistent use of it because it dramatically increases the sustainable data rates it is a bit cavalier to say that there is a "lack of demand." It doesn't show up directly as a lack of demand when FreeBSD drastically underperforms linux in a high bandwidth environment. The solution is for the user to simply switch to linux how is a user to know (parodying Star Trek technobabble) "Darn it, if only FreeBSD provided an exponential phase inverter on the warp core in the network stack." All he or she will see is it is slow. Or another very concrete example is iX keeps losing sales because ZFS doesn't perform adequately. ZFS doesn't perform adequately largely because the VM system can't map and can't recycle pages fast enough because of locking limitations. It has nothing to do with the storage stack itself. However, most developers themselves are not familiar with the issues much less users. So if I were to make further locking changes I would initially inevitably break some things. Your response would be that it isn't something users want. You're absolutely right, because current users with higher performance demands DON'T USE FreeBSD. Now you may wish to cut hairs by saying well ... locking we need flowtable we don't. However, the gist of that would be that things that you don't understand, that don't solve anyone's immediate problems "user's don't want." For many prospective server class users the current performance profile is a bigger deterrent than the fact that Cairo took tons of hand-wringing to build and so I spent hours just getting a broken chat client to install and once I did OTR support didn't work. Taken collectively the "cool new feature X"s are every bit as important to FreeBSD as ports. > OTOH, if we don't fix the fundamental problems with ports, and other key > areas of the operating system, we're just not going to have users, > period. Given that most of the developers (like you) have stopped using > FreeBSD on a day-to-day basis, who can blame them? Not necessarily. Most big shops don't really use ports as is. Particularly appliance vendors don't care about how package management is handled. But yes, in principle we could end up with no desktop users. > Doug > > -- > > This .signature sanitized for your protection -- “The real damage is done by those millions who want to 'get by.' The ordinary men who just want to be left in peace. Those who don’t want their little lives disturbed by anything bigger than themselves. Those with no sides and no causes. Those who won’t take measure of their own strength, for fear of antagonizing their own weakness. Those who don’t like to make waves—or enemies. Those for whom freedom, honour, truth, and principles are only literature. Those who live small, love small, die small. It’s the reductionist approach to life: if you keep it small, you’ll keep it under control. If you don’t make any noise, the bogeyman won’t find you. But it’s all an illusion, because they die too, those people who roll up their spirits into tiny little balls so as to be safe. Safe?! >From what? Life is always on the edge of death; narrow streets lead to the same place as wide avenues, and a little candle burns itself out just like a flaming torch does. I choose my own way to burn.” Sophie Scholl ___ 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: flowtable usable or not
On 03/02/2012 10:46, K. Macy wrote: > You understand my point but then fail to or choose not to see how it > applies to you when it creates problems for you personally. No, I already pointed out the distinction between "new, experimental features;" and "essential components of the FreeBSD operating system." It's Ok for you to disagree with that distinction, or with its importance. But what you're suggesting is that if users don't help developers debug "cool new feature X" then we won't have "cool new feature X." By implication you're saying that if we don't continue to develop cool new features then at some point down the road we wither and die. What I have tried ever-so-delicately to avoid saying is that lack of user help with debugging "cool new feature X" is generally a sign of lack of user demand for "cool new feature X." Not all cool new ideas are good ones. :) OTOH, if we don't fix the fundamental problems with ports, and other key areas of the operating system, we're just not going to have users, period. Given that most of the developers (like you) have stopped using FreeBSD on a day-to-day basis, who can blame them? Doug -- This .signature sanitized for your protection ___ 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: flowtable usable or not
> > ... and here is the crux of the problem. The vast majority of our > developers don't use FreeBSD as their regular workstation. So it has > increasingly become an OS where changes are being lobbed over the wall > by developers who don't run systems that those changes affect. That's no > way to run a railroad. You understand my point but then fail to or choose not to see how it applies to you when it creates problems for you personally. In essence my point was that "It was broken so I turned it off, end of story." does not constitute constructive feedback and does not contribute to the development of FreeBSD. It isn't your responsibility to help me debug my code just as it isn't my responsibility to contribute to the maintenance of ports by dealing with a port management that for me has been virtually unusable in coping with dependencies. I'm not eating the ports dog food because it is broken for me and you're not fully eating the sys dog food because it is broken for you are perfectly reasonable courses of action taken in isolation. However, our respective actions cumulatively don't contribute to the welfare of FreeBSD and my response was simply voicing frustration with such conduct. If you do not see the parallels between the two then there really isn't anything further to discuss about how we engage with the community. -Kip > > > Doug > > -- > > This .signature sanitized for your protection -- “The real damage is done by those millions who want to 'get by.' The ordinary men who just want to be left in peace. Those who don’t want their little lives disturbed by anything bigger than themselves. Those with no sides and no causes. Those who won’t take measure of their own strength, for fear of antagonizing their own weakness. Those who don’t like to make waves—or enemies. Those for whom freedom, honour, truth, and principles are only literature. Those who live small, love small, die small. It’s the reductionist approach to life: if you keep it small, you’ll keep it under control. If you don’t make any noise, the bogeyman won’t find you. But it’s all an illusion, because they die too, those people who roll up their spirits into tiny little balls so as to be safe. Safe?! >From what? Life is always on the edge of death; narrow streets lead to the same place as wide avenues, and a little candle burns itself out just like a flaming torch does. I choose my own way to burn.” Sophie Scholl ___ 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: ports usable or not [was: flowtable usable or not]
On 02/03/2012 16:45, Mark Linimon wrote: >> Other ports aren't supported on certain target architectures but the build >> > doesn't tell you that until after it has run for a couple of hours > Those are also bugs. Please send PRs for those, as well. I am particularly > concerned about amd64 in this regard (although I am actually only myself > doing the package runs for sparc64 and powerpc). We continually try to > adjust the metadata for ports to indicate where they will and will not > run, based on the output of pointyhat runs. (OTOH pointyhat runs the > src tree from "the oldest supported minor release on each branch", so > this may be a clue .) Which reminds me about this: ports/164638 I've kind of taken my eye of progress on that, being distracted by other things. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: Long delay on boot 9.0R on vmware+zfs
On Fri, Mar 2, 2012 at 12:17 PM, Slawa Olhovchenkov wrote: > Long delay (more 30 seconds) on loader disk detect. > Debug print pointed to zfs/zfs.c:zfs_dev_init. > This function found disk0 and walked over 128 potencial slices, trying > 'p' slice and 's' slice. Each attempt -- 1/4s (and nothing found). > > How to speed up boot? > Sounds quite similar to this: http://www.freebsd.org/cgi/query-pr.cgi?pr=148296 -- Adam Vande More ___ 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: flowtable usable or not
On 03/02/2012 03:44, K. Macy wrote: >> Apparently you've missed all the times that I've given that exact advice. :) >> >> But your analogy is severely flawed. Flowtable was an experimental >> feature that theoretically might have increased performance for some >> work flows, but turned out to be fatally flawed. The ports system is an >> essential part of the FreeBSD operating *system*, depended on by >> virtually 100% of FreeBSD users. > > Certainly fatally flawed without any user support. Just as many new > features have been. Right, but what's your point? "I have this cool new thing, and you have to risk your network stability in order to help me debug it on a production network?" That's not how the world works man. >> Users don't have any obligation to help us debug new/experimental features. > > Correct. However, I'm not sure the analogy is flawed. I am, to some > degree, guilty of the same sin. I now run Ubuntu and have never had a > single problem keeping my package system up date, in stark contrast to > my experiences of slow and nightmarishly error-ridden port updates. So first of all, apples and oranges (Ubuntu packages vs. our ports), but yeah, I get it. I use both, and have had the same user experience you have, on both systems. I work with the ports infrastructure quite a bit, and I know it's flaws intimately. That's one reason that I wrote portmaster. > I > know there are users who have operated without such problems. It is > entirely possible that they're simply smarter than I am. Not necessarily. I have said many times that the ports system has some really bad fundamental design principles that make users' lives harder, and unfortunately there is a lot of inertia that prevents change. Some of this is improving, a lot of it is not. But, at the same time, a lot of work is going into improving usability, and I think the situation is better now than it was even just a few years ago. > I similarly > feel no compunction to use a FreeBSD feature (the ports system) that I > can't rely on. ... and here is the crux of the problem. The vast majority of our developers don't use FreeBSD as their regular workstation. So it has increasingly become an OS where changes are being lobbed over the wall by developers who don't run systems that those changes affect. That's no way to run a railroad. Doug -- This .signature sanitized for your protection ___ 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"
Long delay on boot 9.0R on vmware+zfs
ZFSRoot installation, FreeBSD 9.0R. GPT partition. VmWare ESXi 4.1. Long delay (more 30 seconds) on loader disk detect. Debug print pointed to zfs/zfs.c:zfs_dev_init. This function found disk0 and walked over 128 potencial slices, trying 'p' slice and 's' slice. Each attempt -- 1/4s (and nothing found). How to speed up boot? ___ 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: audit in jail
On 03/02/12 18:17, George Mamalakis wrote: Ah! And one more thing with respect to this issue. Since I realized that probably I won't be able to run audit within a jail, I tried to continue with my work from outside the jail. What I need is to audit some system users (like www) inside my jails and do stuff with their audit trails. In order to be able to audit www's actions, I downloaded setaudit from http://www.freebsd.org/~csjp/setaudit.c which allows this functionality. setaudit works fine from outside my jails, but when I run it from within a jail, I get the following error again: [root@in-jail] # setaudit -awww -mfr /bin/ls setaudit: setaudit_addr: Function not implemented Is there, at least, some easy/secure/not-whole-system-configuration-changing way to start apache from within a jail to be able to audit his actions from outside the jail? Thank you all in advance, once more. OK, found it! I am running: [root@out-of-jail] setaudit -awww -m fr,fw,fa,fm,fc,fd,cl jexec 6 /usr/local/bin/sudo -u www /usr/local/sbin/apachectl startssl from outside the jails and it works like a charm! Nasty, but at least it's working... Thank you all anyway! -- George Mamalakis IT and Security Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 ___ 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: ports usable or not [was: flowtable usable or not]
On Fri, Mar 02, 2012 at 03:35:24PM +0100, Nomen Nescio wrote:
> If you use [!i386] you are likely to find problems with ports and
> this gets amplified if you use nonstandard (read stuff not everybody uses)
> ports.
Fair enough.
> I have found several ports broken for many releases in a row.
These are bugs. Please report them via PRs.
> Other ports aren't supported on certain target architectures but the build
> doesn't tell you that until after it has run for a couple of hours
Those are also bugs. Please send PRs for those, as well. I am particularly
concerned about amd64 in this regard (although I am actually only myself
doing the package runs for sparc64 and powerpc). We continually try to
adjust the metadata for ports to indicate where they will and will not
run, based on the output of pointyhat runs. (OTOH pointyhat runs the
src tree from "the oldest supported minor release on each branch", so
this may be a clue .)
For those interested in investigating the metadata as seen by these
package build runs, they are available. For instance:
http://pointyhat.freebsd.org/errorlogs/amd64-9-latest/duds.verbose
Substitute {i386|sparc64|powerpc} for "amd64" and {7|8} for "9" to
look at the others.
Note that I haven't done any ia64 builds in quite a long time. Also
note that for sparc64 and powerpc, I no longer try to do 7. Finally,
we haven't done many runs on 10 yet.
You can see the overall state of the various package builds at:
http://pointyhat.freebsd.org/errorlogs/packagestats.html
whose "skipped" links will take you to the duds.verbose files.
mcl
___
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: flowtable usable or not
Em Sex, Março 2, 2012 11:35, Nomen Nescio escreveu: >> my experiences of slow and nightmarishly error-ridden port updates > > I have no intention to bash FreeBSD or ports but ports is certainly not > without problems. It's annoying but not a reason to use Ubuntu! Get a > grip, man! ;-) > >> I know there are users who have operated without such problems >> > > I think if you use the i386 architecture and the common ports you are > less likely to find something before somebody else finds it and it gets > fixed. If you use any other platform you are likely to find problems with > ports and this gets amplified if you use nonstandard (read stuff not > everybody uses) ports. with some good luck may be ... ports need some kind of disaster management for example, certain ports depending on perl, install or upgrade fine when using portupgrade or portinstall and are satisfied with let's say perl-8.9 then you use pkg_add, or -P[P] switch and the same port looks for perl.12.4 and bumps it into the system careless, not even checking if there is another perl already no way using batch on ports today unless you like to get screwed and never turn your eyes away from screen I do not need to say more, you all know that and I can understand the frustration of whom is gotten caught by this mess > I have found several ports broken for many releases > in a row. Other ports aren't supported on certain target architectures but > the build doesn't tell you that until after it has run for a couple of > hours downloading huge source tarballs and compiling them only to give you > a nastygram "Sorry this port is not available on AMD64" of something like > that. I understand not every port maintainer can test on every arch but come on, then the port should not be there for this architecture ... or it is and works or it is not or do we have new standards now as 0|0.5|1 or is it still 0|1 ? > come on, for stuff that you know doesn't work can't you check at the > beginning and stop rather than put out a message when the build breaks? some fine ports are compiling fine, go through the whole process and screw all up at the install process, they already run pkg_delete, do not find the dependency, do some stuff and bail out, at the end portupgrade confirm success but they do not got installed but de-installed, as present some dependencies are messed up ... :) so as it is, better grab the original sources and compile your stuff on your own and stay "far" away from ports -- João Martins (JoaoBR) Infomatik Development Team http://wipserver.matik.com.br +55 11 4249. ___ 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: audit in jail
Ah! And one more thing with respect to this issue. Since I realized that probably I won't be able to run audit within a jail, I tried to continue with my work from outside the jail. What I need is to audit some system users (like www) inside my jails and do stuff with their audit trails. In order to be able to audit www's actions, I downloaded setaudit from http://www.freebsd.org/~csjp/setaudit.c which allows this functionality. setaudit works fine from outside my jails, but when I run it from within a jail, I get the following error again: [root@in-jail] # setaudit -awww -mfr /bin/ls setaudit: setaudit_addr: Function not implemented Is there, at least, some easy/secure/not-whole-system-configuration-changing way to start apache from within a jail to be able to audit his actions from outside the jail? Thank you all in advance, once more. -- George Mamalakis IT and Security Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 ___ 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"
audit in jail
Hello everybody, has anyone started auditd inside a jail successfully? I allowed audit and auditpipe from devfs inside the jails (I have confirmed their existence in the jails as well...:-) ), but when I run auditd I am getting this message in my logs: Mar 2 15:20:29 myhost auditd[89494]: auditd_prevent_audit() could not set active audit session state: Function not implemented Mar 2 15:20:29 myhost mamalos: audit warning: nostart I googled it, but didn't find much. I checked the code and after some searching, I found that the problem was occurring when the setaudit system call is being called. I checked the code of audit_syscalls and found that: 584: if (jailed(td->td_ucred)) 585: return (ENOSYS); in the sys_setaudit() context...which is somewhat clear as to what it means :-). Is there anything I have omitted, or is it that clear that audit does not run in jails? And if so, are there any thoughts on implementing in the near future? Thank you all for your help and time in advance. -- George Mamalakis IT and Security Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 ___ 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: Resume broken in 8.3-PRERELEASE
On Fri, Mar 02, 2012 at 04:14:08PM +0100, Hans Petter Selasky wrote: > On Friday 02 March 2012 09:57:03 Alexey Dokuchaev wrote: > > On Fri, Mar 02, 2012 at 08:48:13AM +0100, Hans Petter Selasky wrote: > > > If the reset doesn't work, then try to enable hw.usb.uhub.debug=15 and > > > see what port change events are coming. > > > > I don't see such oid hw.usb.uhub.debug. Perhaps it should be hw.usb.debug? What about this? I've did hw.usb.debug=15, but didn't see anything new on the console. > > > If cfg=255 in usbconfig, then something is wrong. > > > > It seems they are all zeros, per the output I've sent earlier. > > If they are all zeros, then everything is working like it should. If you can > dump the device and configuration descriptors, then there is no USB problem. I can only dump this information *before* suspend, after "resume" I cannot do almost anything except breaking into debugger (but not being able to "call doadump"). I had to revert to earlier revision to call usbconfig(8) after resume. > I'm thinking it might be some MICROCODE issue that causes the problem. Maybe > we shouldn't reset the OHCI and EHCI and UHCI and XHCI before handing over to > the MICROCODE suspend handler? > > Have a look in /sys/dev/usb/controller/xhci/ehci/ohci/uhci and search for > suspend. OK, I will try and report back, thanks. ./danfe ___ 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: Resume broken in 8.3-PRERELEASE
On Friday 02 March 2012 09:57:03 Alexey Dokuchaev wrote: > On Fri, Mar 02, 2012 at 08:48:13AM +0100, Hans Petter Selasky wrote: > > If the reset doesn't work, then try to enable hw.usb.uhub.debug=15 and > > see what port change events are coming. > > I don't see such oid hw.usb.uhub.debug. Perhaps it should be hw.usb.debug? > > > If cfg=255 in usbconfig, then something is wrong. > > It seems they are all zeros, per the output I've sent earlier. If they are all zeros, then everything is working like it should. If you can dump the device and configuration descriptors, then there is no USB problem. I'm thinking it might be some MICROCODE issue that causes the problem. Maybe we shouldn't reset the OHCI and EHCI and UHCI and XHCI before handing over to the MICROCODE suspend handler? Have a look in /sys/dev/usb/controller/xhci/ehci/ohci/uhci and search for suspend. --HPS ___ 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: flowtable usable or not
> my experiences of slow and nightmarishly error-ridden port updates I have no intention to bash FreeBSD or ports but ports is certainly not without problems. It's annoying but not a reason to use Ubuntu! Get a grip, man! ;-) > I know there are users who have operated without such problems I think if you use the i386 architecture and the common ports you are less likely to find something before somebody else finds it and it gets fixed. If you use any other platform you are likely to find problems with ports and this gets amplified if you use nonstandard (read stuff not everybody uses) ports. I have found several ports broken for many releases in a row. Other ports aren't supported on certain target architectures but the build doesn't tell you that until after it has run for a couple of hours downloading huge source tarballs and compiling them only to give you a nastygram "Sorry this port is not available on AMD64" of something like that. I understand not every port maintainer can test on every arch but come on, for stuff that you know doesn't work can't you check at the beginning and stop rather than put out a message when the build breaks? ___ 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: [CFT] modular kernel config
On Fri, Mar 02, 2012 at 02:33:17PM +0100, Alexander Leidinger wrote: > Quoting Pavel Timofeev (from Thu, 1 Mar 2012 > 10:35:17 +0400): > > >I have just tried lastest configs and see following messages while > >kernel boot: > > > >Copyright (c) 1992-2012 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 is a registered trademark of The FreeBSD Foundation. > >FreeBSD 10.0-CURRENT #0: Wed Feb 29 22:47:35 MSK 2012 > >mox@rock:/usr/obj/usr/src/sys/SMALL amd64 > >WARNING: WITNESS option enabled, expect reduced performance. > >link_elf_obj: symbol xpt_create_path undefined > >KLD file hptiop.ko - could not finalize loading > >link_elf_obj: symbol firmware_get undefined > >KLD file isp.ko - could not finalize loading > >link_elf_obj: symbol xpt_freeze_simq undefined > >KLD file mps.ko - could not finalize loading > >link_elf_obj: symbol cam_simq_alloc undefined > >KLD file hptmv.ko - could not finalize loading > >CPU: Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz (2906.39-MHz > >K8-class CPU) > > > >Don't you know why do I get it? > > The xpt_* symbols are all in the cam module. If you downloaded the > loader.conf the cam module should be surely there (except you lost > it). Without the cam module I can understand the messages about xpt_*, > with the cam module I can't (I speicied cam before hptiop/mps/hptmv). > > Regarding the firmware_get module I changed the order of module > loading in the loader.conf, I've put the firmware_load to the front to > load it before a lot of other modules. Theoretically this should solve > the isse. The issue there, at least with mps(4), is that the driver erronously lacks the line MODULE_DEPEND(mps, cam, 1, 1, 1); somewhere in mps_pci.c to record dependency on the cam(4). Never looked at the other drivers, but I suspect that the problem is same. pgplaHC3ZoGuA.pgp Description: PGP signature
Re: [CFT] modular kernel config
Quoting Pavel Timofeev (from Thu, 1 Mar 2012 10:35:17 +0400): I have just tried lastest configs and see following messages while kernel boot: Copyright (c) 1992-2012 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #0: Wed Feb 29 22:47:35 MSK 2012 mox@rock:/usr/obj/usr/src/sys/SMALL amd64 WARNING: WITNESS option enabled, expect reduced performance. link_elf_obj: symbol xpt_create_path undefined KLD file hptiop.ko - could not finalize loading link_elf_obj: symbol firmware_get undefined KLD file isp.ko - could not finalize loading link_elf_obj: symbol xpt_freeze_simq undefined KLD file mps.ko - could not finalize loading link_elf_obj: symbol cam_simq_alloc undefined KLD file hptmv.ko - could not finalize loading CPU: Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz (2906.39-MHz K8-class CPU) Don't you know why do I get it? The xpt_* symbols are all in the cam module. If you downloaded the loader.conf the cam module should be surely there (except you lost it). Without the cam module I can understand the messages about xpt_*, with the cam module I can't (I speicied cam before hptiop/mps/hptmv). Regarding the firmware_get module I changed the order of module loading in the loader.conf, I've put the firmware_load to the front to load it before a lot of other modules. Theoretically this should solve the isse. Bye, Alexander. -- I THINK MAN INVENTED THE CAR by instinct. -- Jack Handey, "The New Mexican" (1988) http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: [CFT] modular kernel config
Quoting Slawa Olhovchenkov (from Fri, 2 Mar 2012 13:24:01 +0400): On Fri, Mar 02, 2012 at 10:09:24AM +0100, Alexander Leidinger wrote: Quoting Slawa Olhovchenkov (from Thu, 1 Mar 2012 18:58:34 +0400): > On Tue, Feb 21, 2012 at 02:35:37PM +0100, Alexander Leidinger wrote: > >> You can download from >>http://www.Leidinger.net/FreeBSD/current-patches/ >> The files are >>- i386_SMALL >>- i386_SMALL_loader.conf >>- amd64_SMALL >>- amd64_SMALL_loader.conf > > Where SCSI disk/etc? CAM and ATA are loaded as modules in the loader.conf (except for two SCSI controllers, which are not available as modules). I may have missed to load a module, or I may not load in the correct order (which would be a bug of missing/wrong dependencies in some modules). I'm investigating a corresponding report with error messages. Not controllers, peripherals: disk/tape/etc device scbus # SCSI bus (required for ATA/SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass# Passthrough device (direct ATA/SCSI access) device ses # SCSI Environmental Services (and SAF-TE) They should be all in the cam module, they don't exist as separate modules. If something is missing, it's a bug or omitted on purpose (but then there's hopefully a comment somewhere explaining why). Bye, Alexander. -- BOFH excuse #418: Sysadmins busy fighting SPAM http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: flowtable usable or not
> Apparently you've missed all the times that I've given that exact advice. :) > > But your analogy is severely flawed. Flowtable was an experimental > feature that theoretically might have increased performance for some > work flows, but turned out to be fatally flawed. The ports system is an > essential part of the FreeBSD operating *system*, depended on by > virtually 100% of FreeBSD users. Certainly fatally flawed without any user support. Just as many new features have been. > Users don't have any obligation to help us debug new/experimental features. Correct. However, I'm not sure the analogy is flawed. I am, to some degree, guilty of the same sin. I now run Ubuntu and have never had a single problem keeping my package system up date, in stark contrast to my experiences of slow and nightmarishly error-ridden port updates. I know there are users who have operated without such problems. It is entirely possible that they're simply smarter than I am. I similarly feel no compunction to use a FreeBSD feature (the ports system) that I can't rely on. Cheers ___ 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: Disk disconnects, with immediate reconnect
Hi, On Fri, Mar 02, 2012 at 09:49:59AM +0100, Willem Jan Withagen wrote: > On my ZFS server: > (info on: http://www.tegenbosch28.nl/FreeBSD/systems/ZFS/ ) > > +ahcich4: Timeout on slot 23 port 0 > +ahcich4: is cs 0080 ss rs 0080 tfd c0 serr > cmd 0004d717 > +(ada3:ahcich4:0:0:0): lost device > +(ada3:ahcich4:0:0:0): removing device entry > +ada3 at ahcich4 bus 0 scbus5 target 0 lun 0 > +ada3: ATA-8 SATA 2.x device > +ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > +ada3: Command Queueing enabled > +ada3: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) > > The reconnect occurs immediately after the disconnect. > > I had some discussions with Jeremy Chadwick, so below are the smartctl > stats. > > The system was not particularly busy at that moment. > Is this disk failure, or why other did it disconnect. I suggest changing the disk: > 5 Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail > Always - 13 I guess, this growing soon and fast ... > 197 Current_Pending_Sector 0x0012 100 100 000Old_age > Always - 3 > 198 Offline_Uncorrectable 0x0010 100 100 000Old_age > Offline - 3 Doesn't look too promising. - Oliver -- | Oliver Brandmueller http://sysadm.in/ o...@sysadm.in | |Ich bin das Internet. Sowahr ich Gott helfe. | ___ 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: Another ZFS ARC memory question
On Fri, 2012-03-02 at 10:25 +0100, Alexander Leidinger wrote: > Quoting Slawa Olhovchenkov (from Thu, 1 Mar 2012 > 18:28:26 +0400): > > > On Tue, Feb 28, 2012 at 05:14:37AM +1100, Peter Jeremy wrote: > > > >> > * what is the community's advice for production machines running > >> >ZFS on FreeBSD, is manually limiting the ARC cache (to ensure > >> >that there's enough actually free memory to handle a spike in > >> >application memory usage) the best solution to this > >> >spike-in-memory-means-crash problem? > >> > >> Are you swapping onto a ZFS vdev? We are not swapping onto a ZFS vdev (we've been down that road and know it's a bad idea). Our issue is primarily with ARC cache eviction not happening fast enough or at all when there is a spike in memory usage, causing machines to hang. We are presently working around it by limiting arc_max to 4G on our 24G RAM production boxes (which seems like a massive waste of performance) and by doing very careful/aggressive application level management of memory usage to ensure stability (limits.conf didn't work for us, so we rolled our own). A better solution would be welcome, though, so that we can utilise all the free memory we're presently keeping around as a safety margin - ideally it would be used as ARC cache. Two more questions, again wrt 8.2-RELEASE: 1. Is it expected that with a 4G limited arc_max value that we should see wired memory usage around 7-8G? I understand that the kernel has to use some memory, but really 3-4G of non-ARC data? 2. We have some development machines with only 3G of RAM. Previously they had no arc_max set and were left to tune themselves. They were quite unstable. Now we've set arc_max to 256M but things have got worse: we've seen a disk i/o big performance hit (untarring a ports tarball now takes 20 minutes), and wired memory usage is up around 2.5GB, the machines are swapping a lot, and crashing more frequently. Follows is arc_summary.pl from one of the troubled dev machines showing the ARC using 500% of the memory it should be. Also uname follows. My second question is: have there been fixes between 8.2-RELEASE and 8.3-BETA1 or 9.0-RELEASE which solve this ARC over-usage problem? hybrid@node5:~$ ./arc_summary.pl ZFS Subsystem ReportFri Mar 2 09:55:00 2012 System Memory: 8.92% 264.89 MiB Active, 6.43% 190.75 MiB Inact 80.91% 2.35GiB Wired, 1.97% 58.46 MiB Cache 1.74% 51.70 MiB Free, 0.03% 864.00 KiB Gap Real Installed: 3.00GiB Real Available: 99.56% 2.99GiB Real Managed: 97.04% 2.90GiB Logical Total: 3.00GiB Logical Used: 90.20% 2.71GiB Logical Free: 9.80% 300.91 MiB Kernel Memory: 1.08GiB Data: 98.75% 1.06GiB Text: 1.25% 13.76 MiB Kernel Memory Map: 2.83GiB Size: 26.80% 775.56 MiB Free: 73.20% 2.07GiB Page: 1 ARC Summary: (THROTTLED) Storage pool Version: 15 Filesystem Version: 4 Memory Throttle Count: 53.77m ARC Misc: Deleted:1.99m Recycle Misses: 6.84m Mutex Misses: 6.96k Evict Skips:6.96k ARC Size: 552.16% 1.38GiB Target Size: (Adaptive) 100.00% 256.00 MiB Min Size (Hard Limit): 36.23% 92.75 MiB Max Size (High Water): 2:1 256.00 MiB ARC Size Breakdown: Recently Used Cache Size: 16.97% 239.90 MiB Frequently Used Cache Size: 83.03% 1.15GiB ARC Hash Breakdown: Elements Max: 83.19k Elements Current: 84.72% 70.48k Collisions: 2.53m Chain Max: 9 Chains: 18.94k Page: 2 ARC Efficiency: 126.65m Cache Hit Ratio:95.07% 120.41m Cache Miss Ratio: 4.93% 6.24m Actual Hit R
Re: Another ZFS ARC memory question
Quoting Slawa Olhovchenkov (from Thu, 1 Mar 2012 18:28:26 +0400): On Tue, Feb 28, 2012 at 05:14:37AM +1100, Peter Jeremy wrote: > * what is the community's advice for production machines running >ZFS on FreeBSD, is manually limiting the ARC cache (to ensure >that there's enough actually free memory to handle a spike in >application memory usage) the best solution to this >spike-in-memory-means-crash problem? Are you swapping onto a ZFS vdev? If so, change back to a raw (or geom) device - swapping to ZFS is known to be problematic. If you I see kernel stuck when swapping to ZFS. This is only known problem? This is a known problem. Don't use swap on a zpool. If you want fault tollerance use gmirror for the swap paritions instead (make sure the swap partition does end _before_ the last sector of the disk in this case). Bye, Alexander. -- As of next Thursday, UNIX will be flushed in favor of TOPS-10. Please update your programs. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: [CFT] modular kernel config
On Fri, Mar 02, 2012 at 10:09:24AM +0100, Alexander Leidinger wrote: > Quoting Slawa Olhovchenkov (from Thu, 1 Mar 2012 > 18:58:34 +0400): > > > On Tue, Feb 21, 2012 at 02:35:37PM +0100, Alexander Leidinger wrote: > > > >> You can download from > >>http://www.Leidinger.net/FreeBSD/current-patches/ > >> The files are > >>- i386_SMALL > >>- i386_SMALL_loader.conf > >>- amd64_SMALL > >>- amd64_SMALL_loader.conf > > > > Where SCSI disk/etc? > > CAM and ATA are loaded as modules in the loader.conf (except for two > SCSI controllers, which are not available as modules). I may have > missed to load a module, or I may not load in the correct order (which > would be a bug of missing/wrong dependencies in some modules). I'm > investigating a corresponding report with error messages. Not controllers, peripherals: disk/tape/etc device scbus # SCSI bus (required for ATA/SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass# Passthrough device (direct ATA/SCSI access) device ses # SCSI Environmental Services (and SAF-TE) ___ 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: [CFT] modular kernel config
Quoting Slawa Olhovchenkov (from Thu, 1 Mar 2012 18:58:34 +0400): On Tue, Feb 21, 2012 at 02:35:37PM +0100, Alexander Leidinger wrote: You can download from http://www.Leidinger.net/FreeBSD/current-patches/ The files are - i386_SMALL - i386_SMALL_loader.conf - amd64_SMALL - amd64_SMALL_loader.conf Where SCSI disk/etc? CAM and ATA are loaded as modules in the loader.conf (except for two SCSI controllers, which are not available as modules). I may have missed to load a module, or I may not load in the correct order (which would be a bug of missing/wrong dependencies in some modules). I'm investigating a corresponding report with error messages. Bye, Alexander. -- If you analyse anything, you destroy it. -- Arthur Miller http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: Resume broken in 8.3-PRERELEASE
On Fri, Mar 02, 2012 at 08:48:13AM +0100, Hans Petter Selasky wrote: > If the reset doesn't work, then try to enable hw.usb.uhub.debug=15 and see > what port change events are coming. I don't see such oid hw.usb.uhub.debug. Perhaps it should be hw.usb.debug? > If cfg=255 in usbconfig, then something is wrong. It seems they are all zeros, per the output I've sent earlier. ./danfe ___ 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: Resume broken in 8.3-PRERELEASE
On Thu, Mar 01, 2012 at 04:55:03PM -0500, Jung-uk Kim wrote: > On Thursday 01 March 2012 01:53 pm, Hans Petter Selasky wrote: > > What is output from usbconfig as root, before and after > > suspend/resume ? Before suspend (just after reboot, this output is identical to pre/post SVN r229370): ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen1.1: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen2.1: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen3.1: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen4.1: at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen3.2: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON After resume (kernel from Jan 1): all lines are the same, except that last two lines are swapped (ugen3.2 is listed before ugen0.2). Presence of US232B does not affect behavior; ugen3.2 is built-in finger print scanner, and since in USB2 there is no separate ugen(4), I don't know how to selectively disable it. Man page for ugen(4) however exists. :-) > It does not make a difference for me (i.e., usb suspend/resume still > broken) but I think I found a typo: > > --- sys/dev/usb/controller/usb_controller.c (revision 232365) > +++ sys/dev/usb/controller/usb_controller.c (working copy) > @@ -407,7 +407,7 @@ usb_bus_suspend(struct usb_proc_msg *pm) > > USB_BUS_UNLOCK(bus); > > - bus_generic_shutdown(bus->bdev); > + bus_generic_suspend(bus->bdev); > > usbd_enum_lock(udev); Same thing here, does not seem to improve anything. It might suspend, resume (with keyboard working), then die on next suspend completely. Or it may die on the first suspend (without suspending -- fans are spinning, screen is black and no response to anything except hard power-off), this actually happens more often. ./danfe P.S. Also, doing "ps" in debugger shows that acpiconf(8) is running in the userland upon resume (and hang). Not sure if it helps or not though. ___ 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"
Disk disconnects, with immediate reconnect
On my ZFS server: (info on: http://www.tegenbosch28.nl/FreeBSD/systems/ZFS/ ) +ahcich4: Timeout on slot 23 port 0 +ahcich4: is cs 0080 ss rs 0080 tfd c0 serr cmd 0004d717 +(ada3:ahcich4:0:0:0): lost device +(ada3:ahcich4:0:0:0): removing device entry +ada3 at ahcich4 bus 0 scbus5 target 0 lun 0 +ada3: ATA-8 SATA 2.x device +ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) +ada3: Command Queueing enabled +ada3: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) The reconnect occurs immediately after the disconnect. I had some discussions with Jeremy Chadwick, so below are the smartctl stats. The system was not particularly busy at that moment. Is this disk failure, or why other did it disconnect. --WjW Smartctl output: [~wjw] r...@zfs.digiware.nl# smartctl -A /dev/ada3 smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.2-STABLE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net === START OF READ SMART DATA SECTION === SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 117 099 006Pre-fail Always - 167678942 3 Spin_Up_Time0x0003 100 100 000Pre-fail Always - 0 4 Start_Stop_Count0x0032 100 100 020Old_age Always - 35 5 Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail Always - 13 7 Seek_Error_Rate 0x000f 087 060 030Pre-fail Always - 523895462 9 Power_On_Hours 0x0032 085 085 000Old_age Always - 13172 10 Spin_Retry_Count0x0013 100 100 097Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020Old_age Always - 35 184 End-to-End_Error0x0032 100 100 099Old_age Always - 0 187 Reported_Uncorrect 0x0032 100 100 000Old_age Always - 0 188 Command_Timeout 0x0032 100 100 000Old_age Always - 1 189 High_Fly_Writes 0x003a 071 071 000Old_age Always - 29 190 Airflow_Temperature_Cel 0x0022 067 047 045Old_age Always - 33 (Min/Max 32/33) 194 Temperature_Celsius 0x0022 033 053 000Old_age Always - 33 (0 17 0 0 0) 195 Hardware_ECC_Recovered 0x001a 048 035 000Old_age Always - 167678942 197 Current_Pending_Sector 0x0012 100 100 000Old_age Always - 3 198 Offline_Uncorrectable 0x0010 100 100 000Old_age Offline - 3 199 UDMA_CRC_Error_Count0x003e 200 200 000Old_age Always - 0 240 Head_Flying_Hours 0x 100 253 000Old_age Offline - 95747705942900 241 Total_LBAs_Written 0x 100 253 000Old_age Offline - 656030587 242 Total_LBAs_Read 0x 100 253 000Old_age Offline - 2585367414 [~wjw] r...@zfs.digiware.nl# smartctl -l devstat /dev/ada3 smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.2-STABLE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net Device Statistics (GP Log 0x04) not supported [~wjw] r...@zfs.digiware.nl# smartctl -l sataphy /dev/ada3 smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.2-STABLE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net SATA Phy Event Counters (GP Log 0x11) ID Size Value Description 0x000a 21 Device-to-host register FISes sent due to a COMRESET 0x0001 20 Command failed due to ICRC error 0x0003 20 R_ERR response for device-to-host data FIS 0x0004 20 R_ERR response for host-to-device data FIS 0x0006 20 R_ERR response for device-to-host non-data FIS 0x0007 20 R_ERR response for host-to-device non-data FIS ___ 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: flowtable usable or not
On 03/01/2012 16:03, K. Macy wrote: > I understand the switch. Uptime is important in any production > network. However, it seems like it may have been too easy to turn it > off because no one has made any effort to help me debug the issues. By > analogy your guidance for ports usability problems would be to install > Ubuntu. Apparently you've missed all the times that I've given that exact advice. :) But your analogy is severely flawed. Flowtable was an experimental feature that theoretically might have increased performance for some work flows, but turned out to be fatally flawed. The ports system is an essential part of the FreeBSD operating *system*, depended on by virtually 100% of FreeBSD users. Users don't have any obligation to help us debug new/experimental features. Doug -- This .signature sanitized for your protection ___ 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"
