pf startup: KDB stack backtrace -restarted
Running -current r240768 at boot and on reload with pfctl -f /etc/pf.conf a considerable amount of KDB backtrace data is logged. The data at boot from dmesg is located at: http://pastebin.com/uEJH97Em thanks -kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ia64 panic: make_dev_credv: bad si_name (error=17, si_name=pass3)
From j...@freebsd.org Thu Sep 20 20:30:06 2012 On Thursday, September 20, 2012 4:53:30 am Anton Shterenlikht wrote: On ia64 r235474 I added another disk and did camcontrol rescan all to see it. I got this panic: panic: make_dev_credv: bad si_name (error=17, si_name=pass3) 17 is EEXIST. It seems you still had a pass3 device present (that is the root cause of this panic). Presumably you pulled a disk first and that didn't get cleaned up properly? Either that or CAM is trying to use the same name for two devices for some reason. Ok, what I did exactly was this. This node had 3 scsi disks directly inside it: da0 at mpt0 bus 0 scbus0 target 0 lun 0 da0: HP 73.4G ST373454LC HPC2 Fixed Direct Access SCSI-3 device da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit) da0: Command Queueing enabled da0: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) da1 at mpt0 bus 0 scbus0 target 1 lun 0 da1: SEAGATE ST318452LC 2213 Fixed Direct Access SCSI-3 device da1: 160.000MB/s transfers (80.000MHz, offset 63, 16bit) da1: Command Queueing enabled da1: 17366MB (35566478 512 byte sectors: 255H 63S/T 2213C) da2 at mpt1 bus 0 scbus1 target 2 lun 0 da2: SEAGATE ST318452LC 2213 Fixed Direct Access SCSI-3 device da2: 160.000MB/s transfers (80.000MHz, offset 63, 16bit) da2: Command Queueing enabled da2: 17366MB (35566478 512 byte sectors: 255H 63S/T 2213C) and another 2 logical disks attached via fibre, isp(4): da3 at isp0 bus 0 scbus2 target 0 lun 1 da3: COMPAQ MSA1000 VOLUME 4.32 Fixed Direct Access SCSI-4 device da3: 200.000MB/s transfers WWNN 0x500805f3000ec220 WWPN 0x500805f3000ec221 PortID 0x1 da3: Command Queueing enabled da3: 69460MB (142255575 512 byte sectors: 255H 63S/T 8855C) da4 at isp0 bus 0 scbus2 target 0 lun 5 da4: COMPAQ MSA1000 VOLUME 4.32 Fixed Direct Access SCSI-4 device da4: 200.000MB/s transfers WWNN 0x500805f3000ec220 WWPN 0x500805f3000ec221 PortID 0x1 da4: Command Queueing enabled da4: 140011MB (286744185 512 byte sectors: 255H 63S/T 17849C) I then cut out another logical disk from MSA1000, and assigned it lun 2. So if da(4) numbers disks in the order of their lun, then I guess there was a conflict - lun 2 disk had to become da4, but da4 already existed. Is that what you refer to? Anyway, after the panic and a reboot the former da4 became da5, and the new disk became da4: da3 at isp0 bus 0 scbus2 target 0 lun 1 da3: COMPAQ MSA1000 VOLUME 4.32 Fixed Direct Access SCSI-4 device da3: 200.000MB/s transfers WWNN 0x500805f3000ec220 WWPN 0x500805f3000ec221 PortID 0x1 da3: Command Queueing enabled da3: 69460MB (142255575 512 byte sectors: 255H 63S/T 8855C) da4 at isp0 bus 0 scbus2 target 0 lun 2 da4: COMPAQ MSA1000 VOLUME 4.32 Fixed Direct Access SCSI-4 device da4: 200.000MB/s transfers WWNN 0x500805f3000ec220 WWPN 0x500805f3000ec221 PortID 0x1 da4: Command Queueing enabled da4: 69460MB (142255575 512 byte sectors: 255H 63S/T 8855C) da5 at isp0 bus 0 scbus2 target 0 lun 5 da5: COMPAQ MSA1000 VOLUME 4.32 Fixed Direct Access SCSI-4 device da5: 200.000MB/s transfers WWNN 0x500805f3000ec220 WWPN 0x500805f3000ec221 PortID 0x1 da5: Command Queueing enabled da5: 140011MB (286744185 512 byte sectors: 255H 63S/T 17849C) So how could I've done what I wanted to do without causing a panic? Maybe I should've unmounted all but the root disk? Thank you Anton ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Call for bge(4) testers
On Thu, Sep 20, 2012 at 06:56:09AM +0900, Wanpeng Qian wrote: Hi, On Mon, Sep 17, 2012 at 09:37:21PM +0900, Wanpeng Qian wrote: Hi, here is the dmesg output. bge0: HP NC107i PCIe Gigabit Server Adapter, ASIC rev. 0x5784100 mem 0xfe9f-0xfe9f irq 18 at device 0.0 on pci4 bge0: CHIP ID 0x05784100; ASIC REV 0x5784; CHIP REV 0x57841; PCI-E miibus0: MII bus on bge0 brgphy0: BCM5784 10/100/1000baseT PHY PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow It seems your controller is BCM5784 A1. The latest WIP have one change that may affect its DMA behavior. So it would be good to know how the WIP version works on your box. I update my system to 9-STABLE and using your WIP files. after I reboot the whole system. I cannot find bge anymore. here is the pciconf -lv output. none1@pci0:4:0:0:class=0x02 card=0x705d103c chip=0x165b14e4 rev=0x10 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme BCM5723 Gigabit Ethernet PCIe' class = network subclass = ethernet Hmm, the WIP version didn't remove the chip id so bge(4) may have failed to attach. Could you check any message printed by bge(4) in dmesg output? There is neither message related to bge in the dmesg output. nor ifconfig -a output. anything else I can try ? Regards. Qian FreeBSD 9.0 RELEASE. Regards. Qian watchdog timeouts can be triggered by various issues so it's hard to guess the root cause of the issue. Would you show me the dmesg output(bge(4)/brgphy(4) output only)? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Proposal for change to kernel linker for fixing a VNET and DPCPU problem.
On 9/21/12 2:22 AM, Mikolaj Golub wrote: On Fri, Sep 07, 2012 at 01:28:16AM -0700, Anuranjan Shukla wrote: Hi George, Thanks for taking a look. Some answers/comments below. Building FreeBSD without the network stack (network stack as a module) -- This would be interesting for many reasons, and I think it would be a good contribution. Does the work you've done in this area handle the VNET stuff that is in the stack as well? That is, how well does the network stack as a module play with the vnet architecture? I'll follow up on this one separately. FYI, there is at least this issue with virtualized global variables in modules: http://lists.freebsd.org/pipermail/freebsd-virtualization/2011-July/000737.html On archs that use link_elf.c (i.e. all except amd64, which uses link_elf_obj.c) virtualized global variables in modules can not be accessed from another modules, because link_elf on a module load does relocation only for VNET variables defined in this module. As it was pointed by Marko Zec, the same issue is with DPCPU. The latest patch I have (both for VNET and DPCPU): http://people.freebsd.org/~trociny/link_elf.c.pcpu_vnet.patch The fix is to make the linker on a module load recognize external VNET/DPCPU variables defined in the previously loaded modules and relocate them accordingly. For this set_pcpu_list and set_vnet_list are used, where the addresses of modules 'set_pcpu' and 'set_vnet' linker sets are stored in. it makes sense to me, but I really am not a linker person.. I think it woul be good to get Doug Rabson to weigh in on it, and maybe john Baldwin.. moving to -current as it's not a net issue really.. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
open-sshd uses non-default Kerberos cred cache breaking Kerberized NFS
Herbert emailed with a problem using the kerberized NFS client in FreeBSD. He has been able to isolate the problem to the fact that the sshd he uses (from open-sshd in ports) uses a non-default tgt credentials cache. The problem is that the gssd sets KRB5CCNAME to /tmp/krb5cc_N, where N is the effective uid of the process doing the NFS RPC, so that it can do an init_sec_context() GSSAPI call to get the GSSAPI token. This fails if the tgt is in a credentials cache file under a different name. Here's the code snippet from gssd.c: snprintf(ccname, sizeof(ccname), FILE:/tmp/krb5cc_%d, (int) argp-uid); setenv(KRB5CCNAME, ccname, TRUE); I can't think of any way to fix this, since the gssd runs as effective uid==0 and needs to access the credentials cache for other users. Can anyone conversant with Kerberos suggest a fix? Or does anyone know if there is an easy way to tell open-sshd to use the default credential cache file name? If not, all I can think of is to document this in gssd.8. Thanks in advance for any help with this, rick [Herbert Poeckl wrote in an email to me, copied with his permission] Hi Rick, On 09/20/2012 11:45 PM, Rick Macklem wrote: Ok, after the mount, if you log in as a non-root user, kinit as that user to get a tgt, then try and access the mount point... what happens? And then the request for root@IST.INTRA happens. If you can capture packets from the mount until this happens and email it to me, hopefully I can spot when this happens. For example, try something like: # tcpdump -s 0 -w file.pcap host srv.ist.intra - then in another window # mount -t nfs -o nfsv4,gssname=host,sec=krb5 srv.ist.intra:/path? /mnt # - then in a window logged into a non-root user that has kinit'd % ls /mnt - and whatever else it takes to cause it to access root@IST.INTRA, which shouldn't happen. (It should use the non-root user's principal or the host/soy.ist.intra@IST.INTRA one.) My guess is that some recent change has confused it so it tries to use a credential for uid 0. I did some more testing. This is what I found out: If the environment variable KRB5CCNAME for the user is not set, or is set to FILE:/tmp/krb5cc_20001 (user with uidnumber 20001) then everything works as expected! If the environment variable is set to something different, which happens when the user logs in with SSH, like FILE:/tmp/krb5cc_20001_HNYQhqGftu then I get the problem as described (request for root@IST.INTRA). Herbert ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
More kernel performance tests on FreeBSD 10.0-CURRENT
Hi all, As a followup to my previous post about the performance of FreeBSD 10.0 kernels compiled with different compilers (clang and gcc), I did another series of tests, now on a more modern machine (Core i5-based). I also tested the performance with different compiler optimization settings. The attached text file[1] contains more information about these tests, performance data, and my conclusions. Any errors and omissions are also my fault, so if you notice them, please let me know. The executive summary: GENERIC kernels compiled with clang 3.2 are again a little faster than those compiled with gcc 4.2.1. For gcc, compiling with -O2 also gives a slightly faster kernel than with -O1, but for clang there is no measurable difference between those flags. Again, many thanks to Gavin Atkinson for providing the required hardware. -Dimitry [1]: Also available at: http://www.andric.com/freebsd/perftest/perftest-kernel-2012-09-21a.txt KERNEL PERFORMANCE TESTS ON FREEBSD 10.0-CURRENT, SEPTEMBER 2012, PART 2 INTRODUCTION These tests aim to give an indication of the runtime performance of FreeBSD kernels compiled with different compilers, at various optimization levels. The compilers tested were: - gcc 4.2.1, the system compiler in FreeBSD. - clang 3.2 (trunk 162107), which is the default version of clang in FreeBSD 10.0-CURRENT, after r239462. All tests were run on a machine gracefully provided by Gavin Atkinson, which is based on an Intel DQ57TM desktop board, with a quad-core 3.20 GHz Intel Core i5 CPU (id=0x20652), and 4 GB RAM. It runs FreeBSD/amd64 10.0-CURRENT as of Tue Sep 11 19:11:00 UTC 2012. An excerpt of dmesg follows: CPU: Intel(R) Core(TM) i5 CPU 650 @ 3.20GHz (3192.08-MHz K8-class CPU) Origin = GenuineIntel Id = 0x20652 Family = 6 Model = 25 Stepping = 2 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA, CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT, TM,PBE Features2=0x298e3ffSSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3, CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AESNI AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 3882647552 (3702 MB) Event timer LAPIC quality 600 ACPI APIC Table: INTEL DQ57TM FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 5 With each compiler, stock GENERIC kernels for amd64 were built from head as of r240384, for each of the following optimization flags: -O2 -frename-registers -pipe -fno-strict-aliasing -O1 -pipe -O0 -pipe Note that clang does not support -frename-registers, so it was omitted for the corresponding kernel builds. No CPU-specific optimization flags (-march=) were used. Each kernel was installed into a separate kernel installation directory under /boot. The system was then booted with each of these kernels, without modifying anything else, and multiple runs of make -j8 buildworld were done. Between each run, the /usr/obj directory was fully cleaned out, and filesystems were synced. The timing results, processed with ministat(1), are below. Building world, multi-threaded, on a GENERIC kernel compiled by clang 3.2 -O0 - N Min MaxMedian Avg Stddev real 6 6503.62 6527.84 6520.49 6517.2817 8.3845558 user 6 12534.49 12576.55 12555.29 12555.547 14.079771 sys 69655.1 9733.929716.1 9709.9533 28.981809 maxrss6758208758248758224 758222.67 13.779213 ixrss 6 4396 4401 4397 4397.1667 1.9407902 idrss 6 523 523 523 523 0 isrss 6 126 126 126 126 0 minflt6 6.6264519e+08 6.6337812e+08 6.6297908e+08 6.6299306e+08 249092.49 majflt6 4354 10457 5722 6207.8333 2208.4725 nswap 6405642 44.33 6.1210021 inblock 6 25167 44267 29212 31042.667 6677.3727 oublock 6 32801 34666 33500 33635.167 692.27897 msgsnd6 0 0 0 0 0 msgrcv6 0 0 0 0 0 nsignals 6 60495 60504 60502 60500 3.5213634 nvcsw 6 1750409 1759010 1754971
Re: manual page | zpool-features
On Wed, 19 Sep 2012, Darrel wrote: Does this mean that I can not update from 9 to 10? No. So I ran mergemaster and upgraded zpool from '28' to 'zpool-features' and installed the new bootcode to ada0 and ada1. The next step needs to be right before I can reboot. pfctl and snmp_pf need to be recompiled. Does this mean 'make clean', 'make', and 'make install' in /usr/src/usr.sbin/bsnmpd/modules/snmp_pf and /usr/src/sbin/pfctl? Is either of the directories incorrect or some other combination of make calls required there? I asked this on 'questions' and no one answered- perhaps they are not running -current. I seem to be stuck with it now since zpool has been upgraded. Is there no one on this list willing to take a moment to let me know if the steps in the previous paragraph which I guess are correct are actually correct? The file /usr/src/UPDATING merely mentions that the modules should be compiled but does not describe it. Actually, I am becoming suspicious that FreeBSD does not maintain a OpenBSD Packet Firewall that survives upgrades. Perhaps I should just take all of the Packet Firewall stuff out of my kernel and learn to use ipfw2. Mergemaster was run on Wednesday and the file server just sits there waiting for a couple of commands and a reboot. Darrel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: manual page | zpool-features
On Fri, Sep 21, 2012 at 7:10 PM, Darrel levi...@iglou.com wrote: Welcome to the wonderful world that no one knows how UPDATING works anymore... -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: manual page | zpool-features
Welcome to the wonderful world that no one knows how UPDATING works anymore... -Garrett Thank you. Assholes [ pardon me] that they tend to be, with many exceptions- the steps would have been included in an OpenBSD update that required portions of the tree to be recompiled. Darrel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: manual page | zpool-features
On Fri, Sep 21, 2012 at 11:14:36PM -0400, Darrel wrote: Welcome to the wonderful world that no one knows how UPDATING works anymore... -Garrett Thank you. Assholes [ pardon me] that they tend to be, with many exceptions- the steps would have been included in an OpenBSD update that required portions of the tree to be recompiled. You should always rebuild the tree in its entirety when upgrading. Plus, if you are running -CURRENT, you should expect some things to break on occasion. While those cases are not intentional, they do happen. Glen pgp1D4EIb94Yt.pgp Description: PGP signature
