Re: CFT: patch for process shared pthread objects
On Tuesday 30 November 2010 06:48:11 David Xu wrote: I finally have worked out first patch to make our pthread library support process shared pthread objects: yay! http://people.freebsd.org/~davidxu/pshared/patch1.diff wouldn't it require activation of #define _POSIX_THREAD_PROCESS_SHARED in include/unistd.h? -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla We are all worms. But I do believe I am a glowworm. -- Winston Churchill signature.asc Description: This is a digitally signed message part.
Re: CFT: patch for process shared pthread objects
Alberto Villa wrote: On Tuesday 30 November 2010 06:48:11 David Xu wrote: I finally have worked out first patch to make our pthread library support process shared pthread objects: yay! http://people.freebsd.org/~davidxu/pshared/patch1.diff wouldn't it require activation of #define _POSIX_THREAD_PROCESS_SHARED in include/unistd.h? Yes. ___ 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: CFT: patch for process shared pthread objects
David Xu davi...@freebsd.org writes: Garrett Cooper wrote: Doesn't build :/...: === lib/libthr (obj,depend,all,install) make: don't know how to make thr_sleepq.c. Stop *** Error code 2 Sorry, I have updated it, please download it again, or just download file: http://people.freebsd.org/~davidxu/pshared/thr_sleepq.c and put it in directory src/lib/libthr/thread/ One more cc -c [...] kern/kern_umtx.c /usr/src/sys/kern/kern_umtx.c: In function '__umtx_op_lock_umutex_compat32': /usr/src/sys/kern/kern_umtx.c:4107: error: too few arguments to function 'do_lock_umutex' /usr/src/sys/kern/kern_umtx.c: In function '__umtx_op_wait_umutex_compat32': /usr/src/sys/kern/kern_umtx.c:4128: error: too few arguments to function 'do_lock_umutex' *** Error code 1 As for runtime issues - mplayer's vo_gl and vo_vdpau crash as do many GL games when using nvidia-driver - csup hangs at the end of checkout $ gdb mplayer (gdb) bt #0 0x0020 in ?? () #1 0x000807e749a3 in glXCreateWindow () from /usr/local/lib/libGL.so.1 #2 0x0008116ab00f in _nv011glcore () from /usr/local/lib/libnvidia-glcore.so.1 #3 0x000807e5a81f in glXCreateWindow () from /usr/local/lib/libGL.so.1 #4 0x000800de64a9 in objlist_call_init (list=value optimized out) at /usr/src/libexec/rtld-elf/rtld.c:1684 #5 0x000800de78f5 in _rtld (sp=0x7fff55b0, exit_proc=0x7fff5590, objp=0x7fff5598) at /usr/src/libexec/rtld-elf/rtld.c:528 #6 0x000800de1e99 in .rtld_start () at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:39 #7 0x in ?? () ... $ cat supfile *default host=cvsup4.freebsd.org *default base=/a/test *default prefix=/a/test *default delete use-rel-suffix ports-base release=cvs $ csup supfile Connected to 149.20.64.73 Updating collection ports-base/cvs [...] Create ports/YEAR2000,v - Attic SetAttrs ports load: 2.61 cmd: csup 47332 [running] 154.51r 271.80u 0.14s 99% 2896k load: 1.10 cmd: csup 47332 [runnable] 633.97r 750.61u 0.14s 100% 2896k $ gdb csup $(pgrep csup) (gdb) i th 3 Thread 801007100 (LWP 100310/initial thread) 0x00080281f67c in _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 2 Thread 801008000 (LWP 101283/csup) sender_scan (arg=value optimized out) at /usr/src/usr.bin/csup/mux.c:938 * 1 Thread 801008a00 (LWP 101285/csup) 0x00080f4a9bcc in __sys_sigwait () at _sigwait.S:3 (gdb) bt #0 0x00080f4a9bcc in __sys_sigwait () at _sigwait.S:3 #1 0x00080281b47e in ___sigwait (set=0x7fff16b8, sig=0x7f7fcfa4) at /usr/src/lib/libthr/thread/thr_sig.c:713 #2 0x0040fe1b in killer_run (arg=value optimized out) at /usr/src/usr.bin/csup/proto.c:970 #3 0x0008028171e4 in thread_start (curthread=0x801008a00) at /usr/src/lib/libthr/thread/thr_create.c:272 #4 0x in ?? () (gdb) t 2 (gdb) bt #0 sender_scan (arg=value optimized out) at /usr/src/usr.bin/csup/mux.c:938 #1 sender_waitforwork (arg=value optimized out) at /usr/src/usr.bin/csup/mux.c:912 #2 sender_loop (arg=value optimized out) at /usr/src/usr.bin/csup/mux.c:790 #3 0x0008028171e4 in thread_start (curthread=0x801008000) at /usr/src/lib/libthr/thread/thr_create.c:272 #4 0x in ?? () (gdb) t 3 (gdb) bt #0 0x00080281f67c in _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 #1 0x0008028206c9 in join_common (pthread=0x801008000, thread_return=0x7fff1640, abstime=0x0) at /usr/src/lib/libthr/thread/thr_join.c:125 #2 0x0040d7b5 in mux_shutdown (m=0x8010180c0, errmsg=value optimized out, status=value optimized out) at /usr/src/usr.bin/csup/mux.c:752 #3 0x0041090e in proto_run (config=0x801020080) at /usr/src/usr.bin/csup/proto.c:629 #4 0x0040c72a in main (argc=value optimized out, argv=value optimized out) at /usr/src/usr.bin/csup/main.c:321 ___ 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 noise in ifconfig
Just updated to HEAD and I saw the recent ifconfig, usb ethernet, et all changes: $ ifconfig usbus0: flags=0 metric 0 mtu 0 usbus1: flags=0 metric 0 mtu 0 usbus2: flags=0 metric 0 mtu 0 usbus3: flags=0 metric 0 mtu 0 msk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=c011bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,VLAN_HWTSO,LINKSTATE ether 00:1d:60:b6:eb:97 inet 192.168.20.3 netmask 0xff00 broadcast 192.168.20.255 media: Ethernet autoselect (1000baseT full-duplex,flowcontrol,rxpause,txpause) status: active usbus4: flags=0 metric 0 mtu 0 usbus5: flags=0 metric 0 mtu 0 usbus6: flags=0 metric 0 mtu 0 usbus7: flags=0 metric 0 mtu 0 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet 127.0.0.1 netmask 0xff00 $ ifconfig -l usbus0 usbus1 usbus2 usbus3 msk0 usbus4 usbus5 usbus6 usbus7 lo0 I don't have any USB ethernet devices, so I would expect usbus, et all to be blank, but this would break a few (dumb) scenarios we have at my work where it goes and looks at ifconfig -l (of course I've tried convincing others to use ifconfig -l inet instead, but that was to no avail). This could potentially break other dumb scripts as well. So the question is: what are we gaining with this additional, terse output? Thanks, -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: More noise in ifconfig
On Tue, Nov 30, 2010 at 11:21 AM, Garrett Cooper yaneg...@gmail.com wrote: Just updated to HEAD and I saw the recent ifconfig, usb ethernet, et all changes: $ ifconfig usbus0: flags=0 metric 0 mtu 0 usbus1: flags=0 metric 0 mtu 0 usbus2: flags=0 metric 0 mtu 0 usbus3: flags=0 metric 0 mtu 0 msk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=c011bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,VLAN_HWTSO,LINKSTATE ether 00:1d:60:b6:eb:97 inet 192.168.20.3 netmask 0xff00 broadcast 192.168.20.255 media: Ethernet autoselect (1000baseT full-duplex,flowcontrol,rxpause,txpause) status: active usbus4: flags=0 metric 0 mtu 0 usbus5: flags=0 metric 0 mtu 0 usbus6: flags=0 metric 0 mtu 0 usbus7: flags=0 metric 0 mtu 0 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet 127.0.0.1 netmask 0xff00 $ ifconfig -l usbus0 usbus1 usbus2 usbus3 msk0 usbus4 usbus5 usbus6 usbus7 lo0 I don't have any USB ethernet devices, so I would expect usbus, et all to be blank, but this would break a few (dumb) scenarios we have at my work where it goes and looks at ifconfig -l (of course I've tried convincing others to use ifconfig -l inet instead, but that was to no avail). This could potentially break other dumb scripts as well. So the question is: what are we gaining with this additional, terse output? Thanks, -Garrett I believe a patch has been proposed that would eliminate the usbus devices from ifconfig output: http://lists.freebsd.org/pipermail/freebsd-current/2010-November/021542.html -Brandon ___ 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: CFT: patch for process shared pthread objects
On Tue, 30 Nov 2010, Anonymous wrote: David Xu davi...@freebsd.org writes: Garrett Cooper wrote: Doesn't build :/...: === lib/libthr (obj,depend,all,install) make: don't know how to make thr_sleepq.c. Stop *** Error code 2 Sorry, I have updated it, please download it again, or just download file: http://people.freebsd.org/~davidxu/pshared/thr_sleepq.c and put it in directory src/lib/libthr/thread/ One more cc -c [...] kern/kern_umtx.c /usr/src/sys/kern/kern_umtx.c: In function '__umtx_op_lock_umutex_compat32': /usr/src/sys/kern/kern_umtx.c:4107: error: too few arguments to function 'do_lock_umutex' /usr/src/sys/kern/kern_umtx.c: In function '__umtx_op_wait_umutex_compat32': /usr/src/sys/kern/kern_umtx.c:4128: error: too few arguments to function 'do_lock_umutex' *** Error code 1 As for runtime issues - mplayer's vo_gl and vo_vdpau crash as do many GL games when using nvidia-driver - csup hangs at the end of checkout I'm not sure this is your problem, but as a note to others - if you recompile any applications or libraries that use the new pthread ABIs, you might have to rebuild all dependencies. Just as when we used to bump libc versions, you cannot use different pthread ABIs in the same binary. This is similar to the pre-symbol versioning days when an older library libFOO was linked to libc.so.5 and an application was rebuilt linking to both libFOO and the newer libc.so.6. This should only be a problem if any of the pthread types are passed between applications and/or libraries; the older binary will be expecting the older pthread type, but will be passed the new pthread type. So if you are going to use this patch, be careful about what you rebuild. -- DE ___ 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
'panic: make_dev_credv: bad si_name (error=17, si_name=ttyU0)' with USB serial adapter
Thoughts? anh-thu.NUXI.org dumped core - see ./vmcore.1 Tue Nov 30 16:10:57 PST 2010 FreeBSD anh-thu.NUXI.org 9.0-CURRENT FreeBSD 9.0-CURRENT #85 r214782M: Thu Nov 4 09:13:24 PDT 2010 ro...@anh-thu.nuxi.org:/usr/src/sys/i386/compile/ANH-THU i386 panic: make_dev_credv: bad si_name (error=17, si_name=ttyU0) GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... Unread portion of the kernel message buffer: Copyright (c) 1992-2010 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-CURRENT #85 r214782M: Thu Nov 4 09:13:24 PDT 2010 ro...@anh-thu.nuxi.org:/usr/src/sys/i386/compile/ANH-THU i386 CPU: Intel(R) Core(TM) Duo CPU T2400 @ 1.83GHz (1828.79-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6ec Family = 6 Model = e Stepping = 12 Features=0xbfe9fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xc1a9SSE3,MON,VMX,EST,TM2,xTPR,PDCM AMD Features=0x10NX TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 2093707264 (1996 MB) Event timer LAPIC quality 400 ACPI APIC Table: LENOVO TP-79 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 ACPI Warning: 32/64X length mismatch in Gpe1Block: 0/32 (20101013/tbfadt-625) ACPI Warning: Optional field Gpe1Block has zero address or length: 0x102C/0x0 (20101013/tbfadt-655) ioapic0: Changing APIC ID to 1 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: LENOVO TP-79 on motherboard CPU0: local APIC error 0x40 acpi_ec0: Embedded Controller: GPE 0x1c, ECDT port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 7ff0 (3) failed Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 acpi_lid0: Control Method Lid Switch on acpi0 acpi_button0: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge irq 16 at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display port 0x2000-0x20ff mem 0xd800-0xdfff,0xee10-0xee10 irq 16 at device 0.0 on pci1 hdac0: Intel 82801G High Definition Audio Controller mem 0xee40-0xee403fff irq 17 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 pcib2: ACPI PCI-PCI bridge irq 20 at device 28.0 on pci0 pci2: ACPI PCI bus on pcib2 em0: Intel(R) PRO/1000 Network Connection 7.1.7 port 0x3000-0x301f mem 0xee00-0xee01 irq 16 at device 0.0 on pci2 em0: Using an MSI interrupt em0: [FILTER] em0: Ethernet address: 00:1a:6b:67:33:3d pcib3: ACPI PCI-PCI bridge irq 21 at device 28.1 on pci0 pci3: ACPI PCI bus on pcib3 wpi0: Intel(R) PRO/Wireless 3945ABG mem 0xedf0-0xedf00fff irq 17 at device 0.0 on pci3 pcib4: ACPI PCI-PCI bridge irq 22 at device 28.2 on pci0 pci4: ACPI PCI bus on pcib4 pcib5: ACPI PCI-PCI bridge irq 23 at device 28.3 on pci0 pci12: ACPI PCI bus on pcib5 uhci0: Intel 82801G (ICH7) USB controller USB-A port 0x1800-0x181f irq 16 at device 29.0 on pci0 usbus0: Intel 82801G (ICH7) USB controller USB-A on uhci0 uhci1: Intel 82801G (ICH7) USB controller USB-B port 0x1820-0x183f irq 17 at device 29.1 on pci0 usbus1: Intel 82801G (ICH7) USB controller USB-B on uhci1 uhci2: Intel 82801G (ICH7) USB controller USB-C port 0x1840-0x185f irq 18 at device 29.2 on pci0 usbus2: Intel 82801G (ICH7) USB controller USB-C on uhci2 uhci3: Intel 82801G (ICH7) USB controller USB-D port 0x1860-0x187f irq 19 at device 29.3 on pci0 usbus3: Intel 82801G (ICH7) USB controller USB-D on uhci3 ehci0: Intel 82801GB/R (ICH7) USB 2.0 controller mem 0xee404000-0xee4043ff irq 19 at device 29.7 on pci0 usbus4: EHCI version 1.0 usbus4: Intel 82801GB/R (ICH7) USB 2.0 controller on ehci0 pcib6: ACPI PCI-PCI bridge at device 30.0 on pci0 pci21: ACPI PCI bus on pcib6 cbb0: TI1510 PCI-CardBus Bridge mem 0xe430-0xe4300fff irq 16 at device 0.0 on pci21 cardbus0: CardBus bus on cbb0 pccard0: 16-bit PCCard bus on cbb0 cbb0: [FILTER] isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH7 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1880-0x188f at device 31.1 on pci0 ata0: ATA channel 0 on atapci0 atapci1: Intel ICH7M SATA150
Re: CFT: patch for process shared pthread objects
David Xu wrote: Hi, I finally have worked out first patch to make our pthread library support process shared pthread objects: http://people.freebsd.org/~davidxu/pshared/patch1.diff Patch is updated: http://people.freebsd.org/~davidxu/pshared/patch2.diff Changes: 1) Macro _POSIX_THREAD_PROCESS_SHARED in unistd.h is changed, now its value is 200112L. 2) Version of libgcc is bumped. 3) Thread cancellation is fixed in pthread_cond_wait(), this should make csup run again. ___ 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: CURRENT: Issue with ZFS and 2TB WD HDD (WDC WD20EURS-63Z9B1 80.00A80)
On 29.11.2010 11:52, O. Hartmann wrote: Exporting both volumes in FreeBSD 8 works. But importing them in FreeBSD 9.0-CURRENT/amd64 as with the most recent make world of today fails on the 2TB HDD (ZFS pool/volume BACKUP00). Issuing zpool import BACKUP00 results in cannot import 'BACKUP': no such pool available and on console I receive message It seems strange, why the pool name in error message is 'BACKUP' but not 'BACKUP00'? Surprisingly, the GPT partition of the pool BACKUP00 isn't shown in FreeBSD 9, while I see ada3p1 in FreeBSD 8.2. gpart show ada3 lists this: =34 3907029101 ada3 GPT (1.8T) 344062- free - (2.0M) 4096 3907025039 1 freebsd-zfs (1.8T) Do you have something related to GPT in log files? Can you show full output of `gpart show` from FreeBSD-8 and FreeBSD-9? -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: More noise in ifconfig
2010/11/30 Ilya A. Arhipov pa36ouhu...@yandex.ru: 30.11.10, 20:21, Garrett Cooper yaneg...@gmail.com: Just updated to HEAD and I saw the recent ifconfig, usb ethernet, et all changes: $ ifconfig usbus0: flags=0 metric 0 mtu 0 usbus1: flags=0 metric 0 mtu 0 usbus2: flags=0 metric 0 mtu 0 usbus3: flags=0 metric 0 mtu 0 msk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=c011bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,VLAN_HWTSO,LINKSTATE ether 00:1d:60:b6:eb:97 inet 192.168.20.3 netmask 0xff00 broadcast 192.168.20.255 media: Ethernet autoselect (1000baseT full-duplex,flowcontrol,rxpause,txpause) status: active usbus4: flags=0 metric 0 mtu 0 usbus5: flags=0 metric 0 mtu 0 usbus6: flags=0 metric 0 mtu 0 usbus7: flags=0 metric 0 mtu 0 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet 127.0.0.1 netmask 0xff00 $ ifconfig -l usbus0 usbus1 usbus2 usbus3 msk0 usbus4 usbus5 usbus6 usbus7 lo0 I don't have any USB ethernet devices, so I would expect usbus, et all to be blank, but this would break a few (dumb) scenarios we have at my work where it goes and looks at ifconfig -l (of course I've tried convincing others to use ifconfig -l inet instead, but that was to no avail). This could potentially break other dumb scripts as well. So the question is: what are we gaining with this additional, terse output? ... Log: Don't print usbus[0-9] interfaces that it's not the interesting interface type for ifconfig(8). svn commit: r216089 Yeah, I saw that earlier. Thanks, -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: More noise in ifconfig
30.11.10, 20:21, Garrett Cooper yaneg...@gmail.com: Just updated to HEAD and I saw the recent ifconfig, usb ethernet, et all changes: $ ifconfig usbus0: flags=0 metric 0 mtu 0 usbus1: flags=0 metric 0 mtu 0 usbus2: flags=0 metric 0 mtu 0 usbus3: flags=0 metric 0 mtu 0 msk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=c011bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,VLAN_HWTSO,LINKSTATE ether 00:1d:60:b6:eb:97 inet 192.168.20.3 netmask 0xff00 broadcast 192.168.20.255 media: Ethernet autoselect (1000baseT full-duplex,flowcontrol,rxpause,txpause) status: active usbus4: flags=0 metric 0 mtu 0 usbus5: flags=0 metric 0 mtu 0 usbus6: flags=0 metric 0 mtu 0 usbus7: flags=0 metric 0 mtu 0 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet 127.0.0.1 netmask 0xff00 $ ifconfig -l usbus0 usbus1 usbus2 usbus3 msk0 usbus4 usbus5 usbus6 usbus7 lo0 I don't have any USB ethernet devices, so I would expect usbus, et all to be blank, but this would break a few (dumb) scenarios we have at my work where it goes and looks at ifconfig -l (of course I've tried convincing others to use ifconfig -l inet instead, but that was to no avail). This could potentially break other dumb scripts as well. So the question is: what are we gaining with this additional, terse output? Thanks, -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 Log: Don't print usbus[0-9] interfaces that it's not the interesting interface type for ifconfig(8). svn commit: r216089 ___ 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
