From owner-freebsd-current@FreeBSD.ORG Sun Sep 14 03:19:49 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE98D106564A for ; Sun, 14 Sep 2008 03:19:49 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id B31EC8FC14 for ; Sun, 14 Sep 2008 03:19:48 +0000 (UTC) (envelope-from randy@psg.com) Received: from 50.216.138.210.bn.2iij.net ([210.138.216.50] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kei9L-000B3c-7V for current@freebsd.org; Sun, 14 Sep 2008 03:19:47 +0000 Message-ID: <48CC82D1.1080009@psg.com> Date: Sun, 14 Sep 2008 12:19:45 +0900 From: Randy Bush User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: FreeBSD Current X-Enigmail-Version: 0.95.7 Content-Type: multipart/mixed; boundary="------------010402070408030606030701" Cc: Subject: /usr/src/sys/modules/aout/Makefile X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2008 03:19:49 -0000 This is a multi-part message in MIME format. --------------010402070408030606030701 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit very current soekris build. kernel conf appended ===> an (cleandir) rm -f export_syms if_an.ko if_an.kld if_an.o if_an_pccard.o if_an_pci.o if_an_isa.o if_an.ko.debug if_an.ko.symbols opt_inet.h card_if.h pci_if.h isa_if.h bus_if.h device_if.h pccarddevs.h rm -f @ machine rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> aout (cleandir) ".depend", line 1: Need an operator ".depend", line 2: Need an operator ".depend", line 3: Need an operator ".depend", line 4: Error in archive specification: "bus_release_resource_t" ".depend", line 5: Need an operator ".depend", line 6: Need an operator ".depend", line 7: Need an operator ".depend", line 8: Need an operator ".depend", line 9: Need an operator ".depend", line 10: Missing dependency operator ".depend", line 11: Need an operator ".depend", line 12: Need an operator ".depend", line 13: Need an operator ".depend", line 14: Need an operator ".depend", line 15: Need an operator ".depend", line 16: Need an operator ".depend", line 17: Need an operator ".depend", line 18: Need an operator ".depend", line 20: Error in archive specification: "BUS_RELEASE_RESOURCE" ".depend", line 21: Need an operator ".depend", line 22: Need an operator ".depend", line 23: Need an operator ".depend", line 27: Need an operator ".depend", line 29: Need an operator ".depend", line 30: Need an operator ".depend", line 31: Need an operator ".depend", line 32: Error in archive specification: "bus_setup_intr_t" ".depend", line 33: Need an operator ".depend", line 34: Need an operator ".depend", line 35: Need an operator ".depend", line 36: Need an operator ".depend", line 37: Need an operator ".depend", line 38: Need an operator ".depend", line 39: Need an operator ".depend", line 40: Need an operator make: fatal errors encountered -- cannot continue No closing parenthesis in archive specification No closing parenthesis in archive specification No closing parenthesis in archive specification *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/SOEK0. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. --------------010402070408030606030701 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="SOEK0" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="SOEK0" # 2008.09.08 # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.497 2008/08/20 08:31:58 ed Exp $ #cpu I486_CPU cpu I586_CPU #cpu I686_CPU ident SOEK0 options CPU_GEODE options CPU_SOEKRIS # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists #options UFS_DIRHASH # Improve performance on big directories #options UFS_GJOURNAL # Enable gjournal-based UFS journaling #options MD_ROOT # MD is a potential root device #options NFSCLIENT # Network Filesystem Client #options NFSSERVER # Network Filesystem Server #options NFSLOCKD # Network Lock Manager #options NFS_ROOT # NFS usable as /, requires NFSCLIENT #options MSDOSFS # MSDOS Filesystem #options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] #options COMPAT_FREEBSD4 # Compatible with FreeBSD4 #options COMPAT_FREEBSD5 # Compatible with FreeBSD5 #options COMPAT_FREEBSD6 # Compatible with FreeBSD6 #options COMPAT_FREEBSD7 # Compatible with FreeBSD7 #options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions #options KBD_INSTALL_CDEV # install a CDEV entry in /dev options STOP_NMI # Stop CPUS using NMI instead of IPI options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing # Debugging for use in -current #options KDB # Enable kernel debugger support. #options DDB # Support DDB. #options GDB # Support remote GDB. #options INVARIANTS # Enable calls of extra sanity checking #options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS #options WITNESS # Enable checks to detect deadlocks and cycles #options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed # To make an SMP kernel, the next two lines are needed #options SMP # Symmetric MultiProcessor Kernel device apic # I/O APIC options IPFIREWALL options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity options IPDIVERT options IPFIREWALL_NAT #ipfw kernel nat support options LIBALIAS # CPU frequency control device cpufreq # Bus support. #device eisa device pci # Floppy drives #device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives #device ataraid # ATA RAID drives #device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives #options ATA_STATIC_ID # Static device numbering # SCSI Controllers #device ahb # EISA AHA1742 family #device ahc # AHA2940 and onboard AIC7xxx devices #options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. #device ahd # AHA39320/29320 and onboard AIC79xx devices #options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. #device amd # AMD 53C974 (Tekram DC-390(T)) #device hptiop # Highpoint RocketRaid 3xxx series #device isp # Qlogic family #device ispfw # Firmware for QLogic HBAs- normally a module #device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic #device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') #device trm # Tekram DC395U/UW/F DC315U adapters #device adv # Advansys SCSI adapters #device adw # Advansys wide SCSI adapters #device aha # Adaptec 154x SCSI adapters #device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. #device bt # Buslogic/Mylex MultiMaster SCSI adapters #device ncv # NCR 53C500 #device nsp # Workbit Ninja SCSI-3 #device stg # TMC 18C30/18C50 # SCSI peripherals device scbus # SCSI bus (required for 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 SCSI access) #device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem #device amr # AMI MegaRAID #device arcmsr # Areca SATA II RAID #device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID #device ciss # Compaq Smart RAID 5* #device dpt # DPT Smartcache III, IV - See NOTES for options #device hptmv # Highpoint RocketRAID 182x #device hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx #device iir # Intel Integrated RAID #device ips # IBM (Adaptec) ServeRAID #device mly # Mylex AcceleRAID/eXtremeRAID #device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers #device aac # Adaptec FSA RAID #device aacp # SCSI passthrough for aac (requires CAM) #device ida # Compaq Smart RAID #device mfi # LSI MegaRAID SAS #device mlx # Mylex DAC960 family #device pst # Promise Supertrak SX6000 #device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse #device atkbdc # AT keyboard controller #device atkbd # AT keyboard #device psm # PS/2 mouse #device kbdmux # keyboard multiplexer #device vga # VGA video card driver #device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console #device sc #device agp # support several AGP chipsets # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. #device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support #device cbb # cardbus (yenta) bridge #device pccard # PC Card (16-bit) bus #device cardbus # CardBus (32-bit) bus # Serial (COM) ports device uart # Generic UART driver # Parallel port #device ppc #device ppbus # Parallel port bus (required) #device lpt # Printer #device plip # TCP/IP over parallel #device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to sio, uart and/or ppc drivers): #device puc # PCI Ethernet NICs. #device de # DEC/Intel DC21x4x (``Tulip'') #device em # Intel PRO/1000 Gigabit Ethernet Family #device igb # Intel PRO/1000 PCIE Server Gigabit Family #device ixgb # Intel PRO/10GbE Ethernet Card #device le # AMD Am7900 LANCE and Am79C9xx PCnet #device ti # Alteon Networks Tigon I/II gigabit Ethernet #device txp # 3Com 3cR990 (``Typhoon'') #device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support #device age # Attansic/Atheros L1 Gigabit Ethernet #device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet #device bfe # Broadcom BCM440x 10/100 Ethernet #device bge # Broadcom BCM570xx Gigabit Ethernet #device dc # DEC/Intel 21143 and various workalikes #device et # Agere ET1310 10/100/Gigabit Ethernet #device fxp # Intel EtherExpress PRO/100B (82557, 82558) #device jme # JMicron JMC250 Gigabit/JMC260 Fast Ethernet #device lge # Level 1 LXT1001 gigabit Ethernet #device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet #device nfe # nVidia nForce MCP on-board Ethernet #device nge # NatSemi DP83820 gigabit Ethernet #device nve # nVidia nForce MCP on-board Ethernet Networking #device pcn # AMD Am79C97x PCI 10/100(precedence over 'le') #device re # RealTek 8139C+/8169/8169S/8110S #device rl # RealTek 8129/8139 #device sf # Adaptec AIC-6915 (``Starfire'') #device sis # Silicon Integrated Systems SiS 900/SiS 7016 #device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet #device ste # Sundance ST201 (D-Link DFE-550TX) #device stge # Sundance/Tamarack TC9021 gigabit Ethernet #device tl # Texas Instruments ThunderLAN #device tx # SMC EtherPower II (83c170 ``EPIC'') #device vge # VIA VT612x gigabit Ethernet device vr # VIA Rhine, Rhine II #device wb # Winbond W89C840F #device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. #device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' #device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards #device ex # Intel EtherExpress Pro/10 and Pro/10+ #device ep # Etherlink III based cards #device fe # Fujitsu MB8696x based cards #device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. #device sn # SMC's 9000 series of Ethernet chips #device xe # Xircom pccard Ethernet # Wireless NIC cards device wlan # 802.11 support options IEEE80211_DEBUG # enable debug msgs options IEEE80211_AMPDU_AGE # age frames in AMPDU reorder q's device wlan_wep # 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_amrr # AMRR transmit rate control algorithm device an # Aironet 4500/4800 802.11 wireless NICs. device ath # Atheros pci/cardbus NIC's device ath_hal # Atheros HAL (Hardware Access Layer) device ath_rate_sample # SampleRate tx rate control for ath #device ral # Ralink Technology RT2500 wireless NICs. #device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device tun # Packet tunnel. device pty # BSD-style compatibility pseudo ttys device md # Memory "disks" device gif # IPv6 and IPv4 tunneling #device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support #device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface #device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic #device uhid # "Human Interface Devices" #device ukbd # Keyboard #device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da #device ums # Mouse #device ural # Ralink Technology RT2500USB wireless NICs #device rum # Ralink Technology RT2501USB wireless NICs #device zyd # ZyDAS zb1211/zb1211b wireless NICs #device urio # Diamond Rio 500 MP3 player #device uscanner # Scanners # USB Serial devices #device ucom # Generic com ttys #device uark # Technologies ARK3116 based serial adapters #device ubsa # Belkin F5U103 and compatible serial adapters #device uftdi # For FTDI usb serial adapters #device uipaq # Some WinCE based devices #device uplcom # Prolific PL-2303 serial adapters #device uslcom # SI Labs CP2101/CP2102 serial adapters #device uvisor # Visor and Palm devices #device uvscom # USB serial support for DDI pocket's PHS # USB Ethernet, requires miibus #device aue # ADMtek USB Ethernet #device axe # ASIX Electronics USB Ethernet #device cdce # Generic USB over Ethernet #device cue # CATC USB Ethernet #device kue # Kawasaki LSI USB Ethernet #device rue # RealTek RTL8150 USB Ethernet #device udav # Davicom DM9601E USB # FireWire support #device firewire # FireWire bus code #device sbp # SCSI over FireWire (Requires scbus and da) #device fwe # Ethernet over FireWire (non-standard!) #device fwip # IP over FireWire (RFC 2734,3146) #device dcons # Dumb console driver #device dcons_crom # Configuration ROM for dcons --------------010402070408030606030701-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 14 03:53:33 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40E46106564A for ; Sun, 14 Sep 2008 03:53:33 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 26CEE8FC14 for ; Sun, 14 Sep 2008 03:53:33 +0000 (UTC) (envelope-from randy@psg.com) Received: from 50.216.138.210.bn.2iij.net ([210.138.216.50] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Keig0-0000I0-VQ for current@freebsd.org; Sun, 14 Sep 2008 03:53:33 +0000 Message-ID: <48CC8ABB.8030708@psg.com> Date: Sun, 14 Sep 2008 12:53:31 +0900 From: Randy Bush User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: FreeBSD Current References: <48CC82D1.1080009@psg.com> In-Reply-To: <48CC82D1.1080009@psg.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: /usr/src/sys/modules/aout/Makefile X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2008 03:53:33 -0000 Randy Bush wrote: > very current soekris build. kernel conf appended never mind. an rm -rf /usr/obj seems to have fixed it randy > ===> an (cleandir) > rm -f export_syms if_an.ko if_an.kld if_an.o if_an_pccard.o if_an_pci.o > if_an_isa.o if_an.ko.debug if_an.ko.symbols opt_inet.h card_if.h > pci_if.h isa_if.h bus_if.h device_if.h pccarddevs.h > rm -f @ machine > rm -f .depend GPATH GRTAGS GSYMS GTAGS > ===> aout (cleandir) > ".depend", line 1: Need an operator > ".depend", line 2: Need an operator > ".depend", line 3: Need an operator > ".depend", line 4: Error in archive specification: "bus_release_resource_t" > ".depend", line 5: Need an operator > ".depend", line 6: Need an operator > ".depend", line 7: Need an operator > ".depend", line 8: Need an operator > ".depend", line 9: Need an operator > ".depend", line 10: Missing dependency operator > ".depend", line 11: Need an operator > ".depend", line 12: Need an operator > ".depend", line 13: Need an operator > ".depend", line 14: Need an operator > ".depend", line 15: Need an operator > ".depend", line 16: Need an operator > ".depend", line 17: Need an operator > ".depend", line 18: Need an operator > ".depend", line 20: Error in archive specification: "BUS_RELEASE_RESOURCE" > ".depend", line 21: Need an operator > ".depend", line 22: Need an operator > ".depend", line 23: Need an operator > ".depend", line 27: Need an operator > ".depend", line 29: Need an operator > ".depend", line 30: Need an operator > ".depend", line 31: Need an operator > ".depend", line 32: Error in archive specification: "bus_setup_intr_t" > ".depend", line 33: Need an operator > ".depend", line 34: Need an operator > ".depend", line 35: Need an operator > ".depend", line 36: Need an operator > ".depend", line 37: Need an operator > ".depend", line 38: Need an operator > ".depend", line 39: Need an operator > ".depend", line 40: Need an operator > make: fatal errors encountered -- cannot continue > No closing parenthesis in archive specification > No closing parenthesis in archive specification > No closing parenthesis in archive specification > *** Error code 1 > > Stop in /usr/src/sys/modules. > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/SOEK0. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 From owner-freebsd-current@FreeBSD.ORG Sun Sep 14 04:45:52 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 023411065675 for ; Sun, 14 Sep 2008 04:45:52 +0000 (UTC) (envelope-from vehemens@verizon.net) Received: from vms044pub.verizon.net (vms044pub.verizon.net [206.46.252.44]) by mx1.freebsd.org (Postfix) with ESMTP id DE00D8FC0A for ; Sun, 14 Sep 2008 04:45:51 +0000 (UTC) (envelope-from vehemens@verizon.net) Received: from sam ([71.106.230.165]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0K76008L858FKBJ4@vms044.mailsrvcs.net> for freebsd-current@freebsd.org; Sat, 13 Sep 2008 23:45:51 -0500 (CDT) Date: Sat, 13 Sep 2008 21:51:17 -0700 From: vehemens In-reply-to: <200809111013.34194.vehemens@verizon.net> To: freebsd-current@freebsd.org Message-id: <200809132151.18008.vehemens@verizon.net> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Content-disposition: inline References: <200809080202.00664.vehemens@verizon.net> <20080911090449.GV39652@deviant.kiev.zoral.com.ua> <200809111013.34194.vehemens@verizon.net> User-Agent: KMail/1.9.10 Subject: Re: cdefpriv usage (was: bsd versus linux device drivers) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2008 04:45:52 -0000 On Thursday 11 September 2008 10:13:34 am vehemens wrote: ... > Looks like the ioctl get randomly fails with ENOENT. Turned out to be a bug in my code. > Something else is going on with mmap get which fails with EBADF almost all > of the time.. Looking at the man page and code, it appears that cdevpriv has not been implemented for mmap. I'm still somewhat confused about what cdevpriv is supposed to do. I was after per open private data association, and the code appears to only implement per thread open private data association. From owner-freebsd-current@FreeBSD.ORG Sun Sep 14 06:28:55 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B43B41065671 for ; Sun, 14 Sep 2008 06:28:55 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outZ.internet-mail-service.net (outz.internet-mail-service.net [216.240.47.249]) by mx1.freebsd.org (Postfix) with ESMTP id A542B8FC0C for ; Sun, 14 Sep 2008 06:28:55 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id C23222386; Sat, 13 Sep 2008 23:28:56 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 01FE92D6012; Sat, 13 Sep 2008 23:28:52 -0700 (PDT) Message-ID: <48CCAF23.1010605@elischer.org> Date: Sat, 13 Sep 2008 23:28:51 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Giorgos Keramidas References: <87prnjh80z.fsf@kobe.laptop> <48CC14AD.4090708@elischer.org> <874p4ju8t3.fsf@kobe.laptop> <87zlmbstv1.fsf@kobe.laptop> In-Reply-To: <87zlmbstv1.fsf@kobe.laptop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Robert Watson Subject: Re: panic in rt_check_fib() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2008 06:28:55 -0000 To recap on this, I rewrote this function a couple of week sagobecause I couldn't keep track of what was going on, and I thought it might havesome bad edge cases. a couple of days later Giorgos contacted me saying hta the had a fairly reproducible situation where this was triggered and it appeared to be an edge case in this function that allowed it to try lock the same lock twice. I immediatly thought "ah=hah!" I may have a solution to this, and gave him a copy of my new function and indead it DOES fix that panic. however after deleting and recreating intefaces a few hundred times without crashing in rt_check_fib() it then fails somewhere else, (actually it leacks some resources and eventually networking stops). I'm not convinced that is a problem with the new or old rt_check() but it did stop me from just committing the new code. I rereading the way the function (did and still does) work it occurred to me that there was a large flaw in teh way it worked.. It dropped a the lock on one route while it went off an did something else that might block, On returning it blindly re-grabbed that lock, completely ignoring the fact that the route might not even be valid any more. (or any of several other things that may have changed while it was away (maybe sleeping)). the code Giorgos is referring to is a patch I suggested to him to fix this oversight and not the one that I originally tested and had suggested to fix the edge case. I do however ask that some other people look at this patch! Julian Giorgos Keramidas wrote: > On Sat, 13 Sep 2008 22:47:52 +0300, Giorgos Keramidas wrote: >> +#define RT_RELOCK(_rt) do { \ >> + RT_LOCK(_rt) \ >> + if ((_rt)->rt_refcnt <= 1) \ >> + rtfree(_rt); \ >> + _rt = 0; /* signal that it went away */ \ >> + else { \ >> + RT_REMREF(_rt); \ >> + /* note that _rt is still valid */ \ >> + } \ >> +} while (0) >> + > > This macro needs a semicolon after Rt_LOCK(_rt) and a pair of { ... } in > the if part too: > > %%% > #define RT_RELOCK(_rt) do { \ > RT_LOCK(_rt); \ > if ((_rt)->rt_refcnt <= 1) { \ > rtfree(_rt); \ > _rt = 0; /* signal that it went away */ \ > } else { \ > RT_REMREF(_rt); \ > /* note that _rt is still valid */ \ > } \ > } while (0) > %%% > > and the `error' variable is unused in the new rt_check_fib(), or it > breaks the kernel with a warning about an unused variable: > > /usr/src/sys/net/route.c: In function 'rt_check_fib': > /usr/src/sys/net/route.c:1716: warning: unused variable 'error' > > The updated patch that I'm build-testing now is: > > %%% > diff -r ef8e7f2fc284 sys/net/route.c > --- a/sys/net/route.c Fri Sep 12 02:12:33 2008 +0300 > +++ b/sys/net/route.c Sat Sep 13 22:55:45 2008 +0300 > @@ -1676,19 +1676,31 @@ > * *lrt0 points to the cached route to the final destination; > * *lrt is not meaningful; > * fibnum is the index to the correct network fib for this packet > + * (*lrt0 has not ref held on it so REMREF is not needed ) > * > * === Operation === > * If the route is marked down try to find a new route. If the route > * to the gateway is gone, try to setup a new route. Otherwise, > * if the route is marked for packets to be rejected, enforce that. > + * Note that rtalloc returns an rtentry with an extra REF that we need to lose. > * > * === On return === > * *dst is unchanged; > * *lrt0 points to the (possibly new) route to the final destination > - * *lrt points to the route to the next hop > + * *lrt points to the route to the next hop [LOCKED] > * > * Their values are meaningful ONLY if no error is returned. > + * > + * To follow this you have to remember that: > + * RT_REMREF reduces the reference count by 1 but doesn't check it for 0 (!) > + * RTFREE_LOCKED includes an RT_REMREF (or an rtfree if refs == 1) > + * and an RT_UNLOCK > + * RTFREE does an RT_LOCK and an RTFREE_LOCKED > + * The gwroute pointer counts as a reference on the rtentry to which it points. > + * so when we add it we use the ref that rtalloc gives us and when we lose it > + * we need to remove the reference. > */ > + > int > rt_check(struct rtentry **lrt, struct rtentry **lrt0, struct sockaddr *dst) > { > @@ -1701,58 +1713,81 @@ > { > struct rtentry *rt; > struct rtentry *rt0; > - int error; > > KASSERT(*lrt0 != NULL, ("rt_check")); > - rt = rt0 = *lrt0; > + rt0 = *lrt0; > + rt = NULL; > > /* NB: the locking here is tortuous... */ > - RT_LOCK(rt); > - if ((rt->rt_flags & RTF_UP) == 0) { > - RT_UNLOCK(rt); > - rt = rtalloc1_fib(dst, 1, 0UL, fibnum); > - if (rt != NULL) { > - RT_REMREF(rt); > - /* XXX what about if change? */ > - } else > + RT_LOCK(rt0); > +retry: > + if (rt0 && (rt0->rt_flags & RTF_UP) == 0) { > + /* Current rt0 is useless, try get a replacement. */ > + RT_UNLOCK(rt0); > + rt0 = NULL; > + } > + if (rt0 == NULL) { > + rt0 = rtalloc1_fib(dst, 1, 0UL, fibnum); > + if (rt0 == NULL) { > return (EHOSTUNREACH); > - rt0 = rt; > + } > + RT_REMREF(rt0); /* don't need the reference. */ > } > - /* XXX BSD/OS checks dst->sa_family != AF_NS */ > - if (rt->rt_flags & RTF_GATEWAY) { > - if (rt->rt_gwroute == NULL) > - goto lookup; > - rt = rt->rt_gwroute; > - RT_LOCK(rt); /* NB: gwroute */ > - if ((rt->rt_flags & RTF_UP) == 0) { > - RTFREE_LOCKED(rt); /* unlock gwroute */ > - rt = rt0; > - rt0->rt_gwroute = NULL; > - lookup: > - RT_UNLOCK(rt0); > -/* XXX MRT link level looked up in table 0 */ > - rt = rtalloc1_fib(rt->rt_gateway, 1, 0UL, 0); > - if (rt == rt0) { > - RT_REMREF(rt0); > - RT_UNLOCK(rt0); > + > + if (rt0->rt_flags & RTF_GATEWAY) { > + if ((rt = rt0->rt_gwroute) != NULL) { > + RT_LOCK(rt); /* NB: gwroute */ > + if ((rt->rt_flags & RTF_UP) == 0) { > + /* gw route is dud. ignore/lose it */ > + RTFREE_LOCKED(rt); /* unref (&unlock) gwroute */ > + rt = rt0->rt_gwroute = NULL; > + } > + } > + if (rt == NULL) { /* NOT AN ELSE CLAUSE */ > + RT_TEMP_UNLOCK(rt0); /* MUST return to undo this */ > + rt = rtalloc1_fib(rt0->rt_gateway, 1, 0UL, fibnum); > + if ((rt == rt0) || (rt == NULL)) { > + /* the best we can do is not good enough */ > + if (rt) { > + RT_REMREF(rt); /* assumes ref > 0 */ > + RT_UNLOCK(rt); > + } > + RTFREE(rt0); /* lock, unref, (unlock) */ > return (ENETUNREACH); > } > - RT_LOCK(rt0); > - if (rt0->rt_gwroute != NULL) > - RTFREE(rt0->rt_gwroute); > - rt0->rt_gwroute = rt; > - if (rt == NULL) { > - RT_UNLOCK(rt0); > - return (EHOSTUNREACH); > + /* > + * Relock it and lose the added reference. > + * All sorts of things could have happenned while we > + * had no lock on it, so check for them. > + */ > + RT_RELOCK(rt0); > + if (rt0 == NULL || ((rt0->rt_flags & RTF_UP) == 0)) > + /* Ru-roh.. what we had is no longer any good */ > + goto retry; > + /* > + * While we were away, someone replaced the gateway. > + * Since a reference count is involved we can't just > + * overwrite it. > + */ > + if (rt0->rt_gwroute) { > + if (rt0->rt_gwroute != rt) { > + RTFREE_LOCKED(rt); > + goto retry; > + } > + } else { > + rt0->rt_gwroute = rt; > } > } > + RT_LOCK_ASSERT(rt); > RT_UNLOCK(rt0); > + } else { > + /* think of rt as having the lock from now on.. */ > + rt = rt0; > } > /* XXX why are we inspecting rmx_expire? */ > - error = (rt->rt_flags & RTF_REJECT) && > - (rt->rt_rmx.rmx_expire == 0 || > - time_uptime < rt->rt_rmx.rmx_expire); > - if (error) { > + if ((rt->rt_flags & RTF_REJECT) && > + (rt->rt_rmx.rmx_expire == 0 || > + time_uptime < rt->rt_rmx.rmx_expire)) { > RT_UNLOCK(rt); > return (rt == rt0 ? EHOSTDOWN : EHOSTUNREACH); > } > diff -r ef8e7f2fc284 sys/net/route.h > --- a/sys/net/route.h Fri Sep 12 02:12:33 2008 +0300 > +++ b/sys/net/route.h Sat Sep 13 22:55:45 2008 +0300 > @@ -315,6 +315,22 @@ > (_rt)->rt_refcnt--; \ > } while (0) > > +#define RT_TEMP_UNLOCK(_rt) do { \ > + RT_ADDREF(_rt); \ > + RT_UNLOCK(_rt); \ > +} while (0) > + > +#define RT_RELOCK(_rt) do { \ > + RT_LOCK(_rt); \ > + if ((_rt)->rt_refcnt <= 1) { \ > + rtfree(_rt); \ > + _rt = 0; /* signal that it went away */ \ > + } else { \ > + RT_REMREF(_rt); \ > + /* note that _rt is still valid */ \ > + } \ > +} while (0) > + > #define RTFREE_LOCKED(_rt) do { \ > if ((_rt)->rt_refcnt <= 1) \ > rtfree(_rt); \ > %%% From owner-freebsd-current@FreeBSD.ORG Sun Sep 14 07:24:27 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B18FF106564A for ; Sun, 14 Sep 2008 07:24:27 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outL.internet-mail-service.net (outl.internet-mail-service.net [216.240.47.235]) by mx1.freebsd.org (Postfix) with ESMTP id 688568FC12 for ; Sun, 14 Sep 2008 07:24:27 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id C213222FA; Sun, 14 Sep 2008 00:24:42 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 334BF2D601D; Sun, 14 Sep 2008 00:24:26 -0700 (PDT) Message-ID: <48CCBC29.5070802@elischer.org> Date: Sun, 14 Sep 2008 00:24:25 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Giorgos Keramidas References: <87prnjh80z.fsf@kobe.laptop> <48CC14AD.4090708@elischer.org> <874p4ju8t3.fsf@kobe.laptop> <87zlmbstv1.fsf@kobe.laptop> <48CCAF23.1010605@elischer.org> In-Reply-To: <48CCAF23.1010605@elischer.org> Content-Type: multipart/mixed; boundary="------------060405080301040705060307" Cc: freebsd-current@freebsd.org, Robert Watson Subject: Re: panic in rt_check_fib() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2008 07:24:27 -0000 This is a multi-part message in MIME format. --------------060405080301040705060307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Julian Elischer wrote: > To recap on this, I rewrote this function a couple of week sagobecause I > couldn't keep track of what was going on, and I thought it might > havesome bad edge cases. a couple of days later Giorgos contacted me > saying hta the had a fairly reproducible situation > where this was triggered and it appeared to be an edge case in > this function that allowed it to try lock the same lock twice. > > I immediatly thought "ah=hah!" I may have a solution to this, > and gave him a copy of my new function and indead it DOES fix that > panic. however after deleting and recreating intefaces a few hundred > times without crashing in rt_check_fib() it then fails somewhere else, > (actually it leacks some resources and eventually networking stops). > > I'm not convinced that is a problem with the new or old rt_check() but > it did stop me from just committing the new code. > > I rereading the way the function (did and still does) work it > occurred to me that there was a large flaw in teh way it worked.. > > It dropped a the lock on one route while it went off an did something > else that might block, On returning it blindly re-grabbed that lock, > completely ignoring the fact that the route might not even be valid any > more. (or any of several other things that may have changed while > it was away (maybe sleeping)). > > the code Giorgos is referring to is a patch I suggested to him to > fix this oversight and not the one that I originally tested and > had suggested to fix the edge case. > > I do however ask that some other people look at this patch! > > Julian > here's the version of the patch I ended up with... --------------060405080301040705060307 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="rt_check.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rt_check.diff" Index: route.c =================================================================== --- route.c (revision 183012) +++ route.c (working copy) @@ -1676,18 +1676,39 @@ * *lrt0 points to the cached route to the final destination; * *lrt is not meaningful; * fibnum is the index to the correct network fib for this packet + * XXX maybe we should/could get it from (*lrt0)->rt_fibnum + * instead of bringing it in here? I guess it depends on the + * call graph of how we get here. + * (*lrt0 has no ref held on it by us so REMREF is not needed. + * Refs only account for major structural references and not usages, + * which is actually a bit of a problem.) * * === Operation === * If the route is marked down try to find a new route. If the route * to the gateway is gone, try to setup a new route. Otherwise, * if the route is marked for packets to be rejected, enforce that. + * Note that rtalloc returns an rtentry with an extra REF that we may + * need to lose. * * === On return === * *dst is unchanged; * *lrt0 points to the (possibly new) route to the final destination - * *lrt points to the route to the next hop + * *lrt points to the route to the next hop [LOCKED] * * Their values are meaningful ONLY if no error is returned. + * + * To follow this you have to remember that: + * RT_REMREF reduces the reference count by 1 but doesn't check it for 0 (!) + * RTFREE_LOCKED includes an RT_REMREF (or an rtfree if refs == 1) + * and an RT_UNLOCK + * RTFREE does an RT_LOCK and an RTFREE_LOCKED + * The gwroute pointer counts as a reference on the rtentry to which it points. + * so when we add it we use the ref that rtalloc gives us and when we lose it + * we need to remove the reference. + * RT_TEMP_UNLOCK does an RT_ADDREF before freeing the lock, and + * RT_RELOCK locks it (it can't have gone away due to the ref) and + * drops the ref, possibly freeing it (unocking in the process) if the + * ref goes to 0. (and zeroing the pointer if we do). */ int rt_check(struct rtentry **lrt, struct rtentry **lrt0, struct sockaddr *dst) @@ -1701,58 +1722,82 @@ { struct rtentry *rt; struct rtentry *rt0; - int error; KASSERT(*lrt0 != NULL, ("rt_check")); - rt = rt0 = *lrt0; + rt0 = *lrt0; + rt = NULL; /* NB: the locking here is tortuous... */ - RT_LOCK(rt); - if ((rt->rt_flags & RTF_UP) == 0) { - RT_UNLOCK(rt); - rt = rtalloc1_fib(dst, 1, 0UL, fibnum); - if (rt != NULL) { - RT_REMREF(rt); - /* XXX what about if change? */ - } else + RT_LOCK(rt0); +retry: + if (rt0 && (rt0->rt_flags & RTF_UP) == 0) { + /* Current rt0 is useless, try get a replacement. */ + RT_UNLOCK(rt0); + rt0 = NULL; + } + if (rt0 == NULL) { + rt0 = rtalloc1_fib(dst, 1, 0UL, fibnum); + if (rt0 == NULL) { return (EHOSTUNREACH); - rt0 = rt; + } + RT_REMREF(rt0); /* don't need the reference. */ } - /* XXX BSD/OS checks dst->sa_family != AF_NS */ - if (rt->rt_flags & RTF_GATEWAY) { - if (rt->rt_gwroute == NULL) - goto lookup; - rt = rt->rt_gwroute; - RT_LOCK(rt); /* NB: gwroute */ - if ((rt->rt_flags & RTF_UP) == 0) { - RTFREE_LOCKED(rt); /* unlock gwroute */ - rt = rt0; - rt0->rt_gwroute = NULL; - lookup: - RT_UNLOCK(rt0); -/* XXX MRT link level looked up in table 0 */ - rt = rtalloc1_fib(rt->rt_gateway, 1, 0UL, 0); - if (rt == rt0) { - RT_REMREF(rt0); - RT_UNLOCK(rt0); + + if (rt0->rt_flags & RTF_GATEWAY) { + if ((rt = rt0->rt_gwroute) != NULL) { + RT_LOCK(rt); /* NB: gwroute */ + if ((rt->rt_flags & RTF_UP) == 0) { + /* gw route is dud. ignore/lose it */ + RTFREE_LOCKED(rt); /* unref (&unlock) gwroute */ + rt = rt0->rt_gwroute = NULL; + } + } + + if (rt == NULL) { /* NOT AN ELSE CLAUSE */ + RT_TEMP_UNLOCK(rt0); /* MUST return to undo this */ + rt = rtalloc1_fib(rt0->rt_gateway, 1, 0UL, fibnum); + if ((rt == rt0) || (rt == NULL)) { + /* the best we can do is not good enough */ + if (rt) { + RT_REMREF(rt); /* assumes ref > 0 */ + RT_UNLOCK(rt); + } + RTFREE(rt0); /* lock, unref, (unlock) */ return (ENETUNREACH); } - RT_LOCK(rt0); - if (rt0->rt_gwroute != NULL) - RTFREE(rt0->rt_gwroute); - rt0->rt_gwroute = rt; - if (rt == NULL) { - RT_UNLOCK(rt0); - return (EHOSTUNREACH); + /* + * Relock it and lose the added reference. + * All sorts of things could have happenned while we + * had no lock on it, so check for them. + */ + RT_RELOCK(rt0); + if (rt0 == NULL || ((rt0->rt_flags & RTF_UP) == 0)) + /* Ru-roh.. what we had is no longer any good */ + goto retry; + /* + * While we were away, someone replaced the gateway. + * Since a reference count is involved we can't just + * overwrite it. + */ + if (rt0->rt_gwroute) { + if (rt0->rt_gwroute != rt) { + RTFREE_LOCKED(rt); + goto retry; + } + } else { + rt0->rt_gwroute = rt; } } + RT_LOCK_ASSERT(rt); RT_UNLOCK(rt0); + } else { + /* think of rt as having the lock from now on.. */ + rt = rt0; } /* XXX why are we inspecting rmx_expire? */ - error = (rt->rt_flags & RTF_REJECT) && - (rt->rt_rmx.rmx_expire == 0 || - time_uptime < rt->rt_rmx.rmx_expire); - if (error) { + if ((rt->rt_flags & RTF_REJECT) && + (rt->rt_rmx.rmx_expire == 0 || + time_uptime < rt->rt_rmx.rmx_expire)) { RT_UNLOCK(rt); return (rt == rt0 ? EHOSTDOWN : EHOSTUNREACH); } Index: route.h =================================================================== --- route.h (revision 183012) +++ route.h (working copy) @@ -316,21 +316,37 @@ } while (0) #define RTFREE_LOCKED(_rt) do { \ - if ((_rt)->rt_refcnt <= 1) \ - rtfree(_rt); \ - else { \ - RT_REMREF(_rt); \ - RT_UNLOCK(_rt); \ - } \ - /* guard against invalid refs */ \ - _rt = 0; \ - } while (0) + if ((_rt)->rt_refcnt <= 1) \ + rtfree(_rt); \ + else { \ + RT_REMREF(_rt); \ + RT_UNLOCK(_rt); \ + } \ + /* guard against invalid refs */ \ + _rt = 0; \ +} while (0) #define RTFREE(_rt) do { \ - RT_LOCK(_rt); \ - RTFREE_LOCKED(_rt); \ - } while (0) + RT_LOCK(_rt); \ + RTFREE_LOCKED(_rt); \ +} while (0) +#define RT_TEMP_UNLOCK(_rt) do { \ + RT_ADDREF(_rt); \ + RT_UNLOCK(_rt); \ +} while (0) + +#define RT_RELOCK(_rt) do { \ + RT_LOCK(_rt); \ + if ((_rt)->rt_refcnt <= 1) { \ + rtfree(_rt); \ + _rt = 0; /* signal that it went away */ \ + } else { \ + RT_REMREF(_rt); \ + /* note that _rt is still valid */ \ + } \ +} while (0) + extern struct radix_node_head *rt_tables[][AF_MAX+1]; struct ifmultiaddr; --------------060405080301040705060307-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 14 10:07:16 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6FB51065678; Sun, 14 Sep 2008 10:07:16 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id B84AE8FC13; Sun, 14 Sep 2008 10:07:11 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m8EA78Di037613; Sun, 14 Sep 2008 06:07:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id m8EA78DM003482; Sun, 14 Sep 2008 06:07:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D6FBF73039; Sun, 14 Sep 2008 06:07:07 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080914100707.D6FBF73039@freebsd-current.sentex.ca> Date: Sun, 14 Sep 2008 06:07:07 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2008 10:07:17 -0000 TB --- 2008-09-14 08:45:22 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-14 08:45:22 - starting HEAD tinderbox run for i386/pc98 TB --- 2008-09-14 08:45:22 - cleaning the object tree TB --- 2008-09-14 08:45:52 - cvsupping the source tree TB --- 2008-09-14 08:45:52 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2008-09-14 08:45:59 - building world (CFLAGS=-O -pipe) TB --- 2008-09-14 08:45:59 - cd /src TB --- 2008-09-14 08:45:59 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 14 08:46:00 UTC 2008 >>> 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 >>> World build completed on Sun Sep 14 09:59:46 UTC 2008 TB --- 2008-09-14 09:59:46 - generating LINT kernel config TB --- 2008-09-14 09:59:46 - cd /src/sys/pc98/conf TB --- 2008-09-14 09:59:46 - /usr/bin/make -B LINT TB --- 2008-09-14 09:59:46 - building LINT kernel (COPTFLAGS=) TB --- 2008-09-14 09:59:46 - cd /src TB --- 2008-09-14 09:59:46 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Sep 14 09:59:46 UTC 2008 >>> 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 [...] cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/pfil.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/radix.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/radix_mpath.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/raw_cb.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/raw_usrreq.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/route.c /src/sys/net/route.c: In function 'rt_check': /src/sys/net/route.c:1701: error: invalid type argument of '->' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-14 10:07:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-14 10:07:07 - ERROR: failed to build lint kernel TB --- 2008-09-14 10:07:07 - tinderbox aborted TB --- 3343.69 user 429.34 system 4905.37 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sun Sep 14 10:59:24 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAB2D1065670; Sun, 14 Sep 2008 10:59:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id BD7558FC13; Sun, 14 Sep 2008 10:59:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m8EAxMgd039944; Sun, 14 Sep 2008 06:59:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id m8EAxMhq023324; Sun, 14 Sep 2008 06:59:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 6B4A773039; Sun, 14 Sep 2008 06:59:22 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080914105922.6B4A773039@freebsd-current.sentex.ca> Date: Sun, 14 Sep 2008 06:59:22 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2008 10:59:25 -0000 TB --- 2008-09-14 09:28:57 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-14 09:28:57 - starting HEAD tinderbox run for ia64/ia64 TB --- 2008-09-14 09:28:57 - cleaning the object tree TB --- 2008-09-14 09:29:32 - cvsupping the source tree TB --- 2008-09-14 09:29:32 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2008-09-14 09:29:40 - building world (CFLAGS=-O -pipe) TB --- 2008-09-14 09:29:40 - cd /src TB --- 2008-09-14 09:29:40 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 14 09:29:42 UTC 2008 >>> 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 >>> World build completed on Sun Sep 14 10:51:01 UTC 2008 TB --- 2008-09-14 10:51:01 - generating LINT kernel config TB --- 2008-09-14 10:51:01 - cd /src/sys/ia64/conf TB --- 2008-09-14 10:51:01 - /usr/bin/make -B LINT TB --- 2008-09-14 10:51:01 - building LINT kernel (COPTFLAGS=) TB --- 2008-09-14 10:51:01 - cd /src TB --- 2008-09-14 10:51:01 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Sep 14 10:51:01 UTC 2008 >>> 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 [...] cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -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 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/net/pfil.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -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 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/net/radix.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -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 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/net/radix_mpath.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -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 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/net/raw_cb.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -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 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/net/raw_usrreq.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -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 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/net/route.c /src/sys/net/route.c: In function 'rt_check': /src/sys/net/route.c:1701: error: invalid type argument of '->' *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-14 10:59:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-14 10:59:22 - ERROR: failed to build lint kernel TB --- 2008-09-14 10:59:22 - tinderbox aborted TB --- 3897.97 user 423.74 system 5425.05 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sun Sep 14 11:27:27 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70B62106566B; Sun, 14 Sep 2008 11:27:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 43D1E8FC0C; Sun, 14 Sep 2008 11:27:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m8EBRNhR041163; Sun, 14 Sep 2008 07:27:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id m8EBRNv2090384; Sun, 14 Sep 2008 07:27:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C6D4373039; Sun, 14 Sep 2008 07:27:23 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080914112723.C6D4373039@freebsd-current.sentex.ca> Date: Sun, 14 Sep 2008 07:27:23 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2008 11:27:27 -0000 TB --- 2008-09-14 10:07:08 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-14 10:07:08 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-09-14 10:07:08 - cleaning the object tree TB --- 2008-09-14 10:07:41 - cvsupping the source tree TB --- 2008-09-14 10:07:41 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-09-14 10:07:49 - building world (CFLAGS=-O -pipe) TB --- 2008-09-14 10:07:49 - cd /src TB --- 2008-09-14 10:07:49 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 14 10:07:51 UTC 2008 >>> 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 >>> World build completed on Sun Sep 14 11:21:17 UTC 2008 TB --- 2008-09-14 11:21:17 - generating LINT kernel config TB --- 2008-09-14 11:21:17 - cd /src/sys/powerpc/conf TB --- 2008-09-14 11:21:17 - /usr/bin/make -B LINT TB --- 2008-09-14 11:21:17 - building LINT kernel (COPTFLAGS=) TB --- 2008-09-14 11:21:17 - cd /src TB --- 2008-09-14 11:21:17 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Sep 14 11:21:17 UTC 2008 >>> 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 [...] cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -fno-omit-frame-pointer -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/pfil.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -fno-omit-frame-pointer -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/radix.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -fno-omit-frame-pointer -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/radix_mpath.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -fno-omit-frame-pointer -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/raw_cb.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -fno-omit-frame-pointer -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/raw_usrreq.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -fno-omit-frame-pointer -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/route.c /src/sys/net/route.c: In function 'rt_check': /src/sys/net/route.c:1701: error: invalid type argument of '->' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-14 11:27:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-14 11:27:23 - ERROR: failed to build lint kernel TB --- 2008-09-14 11:27:23 - tinderbox aborted TB --- 3382.23 user 400.08 system 4815.40 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Sep 14 12:56:53 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27D66106564A; Sun, 14 Sep 2008 12:56:53 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 924CB8FC0C; Sun, 14 Sep 2008 12:56:52 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (adsl172-222.kln.forthnet.gr [62.1.21.222]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-5) with ESMTP id m8ECuQ6v006475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 14 Sep 2008 15:56:40 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id m8ECuQpO009757; Sun, 14 Sep 2008 15:56:26 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id m8ECuDAv009736; Sun, 14 Sep 2008 15:56:13 +0300 (EEST) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: Julian Elischer References: <87prnjh80z.fsf@kobe.laptop> <48CC14AD.4090708@elischer.org> <874p4ju8t3.fsf@kobe.laptop> <87zlmbstv1.fsf@kobe.laptop> <48CCAF23.1010605@elischer.org> Date: Sun, 14 Sep 2008 15:56:12 +0300 Message-ID: <87tzcij383.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: m8ECuQ6v006475 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.55, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL -0.15, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: freebsd-current@freebsd.org, Robert Watson Subject: Re: panic in rt_check_fib() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2008 12:56:53 -0000 On Sat, 13 Sep 2008 23:28:51 -0700, Julian Elischer wrote: > To recap on this, I rewrote this function a couple of week sagobecause I > couldn't keep track of what was going on, and I thought it might > havesome bad edge cases. a couple of days later Giorgos contacted me > saying hta the had a fairly reproducible situation > where this was triggered and it appeared to be an edge case in > this function that allowed it to try lock the same lock twice. > > I immediatly thought "ah=hah!" I may have a solution to this, > and gave him a copy of my new function and indead it DOES fix that > panic. however after deleting and recreating intefaces a few hundred > times without crashing in rt_check_fib() it then fails somewhere else, > (actually it leacks some resources and eventually networking stops). > > I'm not convinced that is a problem with the new or old rt_check() but > it did stop me from just committing the new code. > > I rereading the way the function (did and still does) work it > occurred to me that there was a large flaw in teh way it worked.. > > It dropped a the lock on one route while it went off an did something > else that might block, On returning it blindly re-grabbed that lock, > completely ignoring the fact that the route might not even be valid any > more. (or any of several other things that may have changed while > it was away (maybe sleeping)). > > the code Giorgos is referring to is a patch I suggested to him to > fix this oversight and not the one that I originally tested and > had suggested to fix the edge case. > > I do however ask that some other people look at this patch! Exactly. Thanks for summarizing this so well :) I have started a kernel with your latest patch (from the quoted message above), and I can't panic my kernel with the script that did it in a semi-reliable manner before: % root@kobe:/root# while true ; do \ % sh home.sh > /dev/null 2>&1 ; \ % vmstat -z | sed -n -e 1p -e /rt/p ; \ % sleep 1 ; \ % done % ITEM SIZE LIMIT USED FREE REQUESTS FAILURES % rtentry: 120, 0, 19, 77, 43, 0 % ITEM SIZE LIMIT USED FREE REQUESTS FAILURES % rtentry: 120, 0, 20, 76, 47, 0 % ITEM SIZE LIMIT USED FREE REQUESTS FAILURES % rtentry: 120, 0, 21, 75, 51, 0 % ITEM SIZE LIMIT USED FREE REQUESTS FAILURES % rtentry: 120, 0, 23, 73, 55, 0 % ITEM SIZE LIMIT USED FREE REQUESTS FAILURES % rtentry: 120, 0, 24, 72, 59, 0 % ITEM SIZE LIMIT USED FREE REQUESTS FAILURES % rtentry: 120, 0, 25, 71, 62, 0 % ITEM SIZE LIMIT USED FREE REQUESTS FAILURES % rtentry: 120, 0, 26, 70, 65, 0 % ITEM SIZE LIMIT USED FREE REQUESTS FAILURES % rtentry: 120, 0, 27, 69, 69, 0 % ITEM SIZE LIMIT USED FREE REQUESTS FAILURES % rtentry: 120, 0, 29, 67, 73, 0 % ITEM SIZE LIMIT USED FREE REQUESTS FAILURES % rtentry: 120, 0, 30, 66, 76, 0 % ^C % root@kobe:/root# sh home.sh rtentries seem to be going up every time I cycle through the script, which essentially brings down both wireless and wired interfaces and then brings up the wired interface of my laptop. The core of the script is currently: # network interface options export ifconfig_re0="inet 192.168.1.10/24" export defaultrouter='192.168.1.1' echo '## Stopping network interfaces.' /etc/rc.d/netif stop re0 && ifconfig re0 delete /etc/rc.d/netif stop iwn0 && ifconfig iwn0 delete echo '## Bringing up network interface.' /etc/rc.d/netif start re0 echo "## Reloading firewall rules." /etc/rc.d/pf reload # The default route may be pointing to another interface. Find out # the IP address of the default gateway, delete it and point to the # default gateway configured as ${defaultrouter}. if [ -n "${defaultrouter}" ]; then echo '## Setting default router.' _oldrouter=`netstat -rn | grep default | awk '{print $2}'` if [ -n "${_oldrouter}" ]; then route delete default "${_oldrouter}" unset _oldrouter fi route add default "$defaultrouter" fi With your version of rt_check_fib() I have no panics so far. This doesn't mean we don't have a bug elsewhere, or that it will not panic tomorrow, but it's nice that thing seem a bit more stable now. The old version of rt_check_fib() used to panic about one third of the time I ran my 'home.sh' script... Now an interesting question is: Is it `normal' that the USED rtentry objects keep going up at every interface restart and are (at least at first glance) not reclaimed as fast as they are acquired? From owner-freebsd-current@FreeBSD.ORG Sun Sep 14 13:18:15 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA9F11065675 for ; Sun, 14 Sep 2008 13:18:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 80C448FC08 for ; Sun, 14 Sep 2008 13:18:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1KerUS-0006uG-33; Sun, 14 Sep 2008 16:18:12 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m8EDI919072913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Sep 2008 16:18:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m8EDI9tQ026589; Sun, 14 Sep 2008 16:18:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id m8EDI9tg026587; Sun, 14 Sep 2008 16:18:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 14 Sep 2008 16:18:09 +0300 From: Kostik Belousov To: vehemens Message-ID: <20080914131809.GX39652@deviant.kiev.zoral.com.ua> References: <200809080202.00664.vehemens@verizon.net> <20080911090449.GV39652@deviant.kiev.zoral.com.ua> <200809111013.34194.vehemens@verizon.net> <200809132151.18008.vehemens@verizon.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QU0xYvH/CPhunj+E" Content-Disposition: inline In-Reply-To: <200809132151.18008.vehemens@verizon.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1KerUS-0006uG-33 51836dc4691cc5779ff8f756b43f55c1 X-Terabit: YES Cc: freebsd-current@freebsd.org Subject: Re: cdefpriv usage (was: bsd versus linux device drivers) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2008 13:18:15 -0000 --QU0xYvH/CPhunj+E Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 13, 2008 at 09:51:17PM -0700, vehemens wrote: > On Thursday 11 September 2008 10:13:34 am vehemens wrote: > ... > > Looks like the ioctl get randomly fails with ENOENT. >=20 > Turned out to be a bug in my code. >=20 > > Something else is going on with mmap get which fails with EBADF almost = all > > of the time.. >=20 > Looking at the man page and code, it appears that cdevpriv has not been= =20 > implemented for mmap. Yes, d_mmap is mostly called from PF# context, where no associated fp is available. This is fixable, but somewhat ugly. >=20 > I'm still somewhat confused about what cdevpriv is supposed to do. I was= =20 > after per open private data association, and the code appears to only=20 > implement per thread open private data association. It is "after per open". --QU0xYvH/CPhunj+E Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkjNDxAACgkQC3+MBN1Mb4jdvACeNLG8ReakvA+5OJOJmkY1Xqlh ckQAn3aC36i70MvXtC6yFAYt0H3MkE25 =sTOT -----END PGP SIGNATURE----- --QU0xYvH/CPhunj+E-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 14 14:15:45 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 990B3106564A for ; Sun, 14 Sep 2008 14:15:45 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from fallbackmx06.syd.optusnet.com.au (fallbackmx06.syd.optusnet.com.au [211.29.132.8]) by mx1.freebsd.org (Postfix) with ESMTP id 2FD458FC1C for ; Sun, 14 Sep 2008 14:15:44 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail34.syd.optusnet.com.au (mail34.syd.optusnet.com.au [211.29.133.218]) by fallbackmx06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m8E4g5jo008987 for ; Sun, 14 Sep 2008 14:42:05 +1000 Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail34.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m8E4g20s030753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Sep 2008 14:42:03 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.2) with ESMTP id m8E4g2VE086983; Sun, 14 Sep 2008 14:42:02 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m8E4g1UP086982; Sun, 14 Sep 2008 14:42:01 +1000 (EST) (envelope-from peter) Date: Sun, 14 Sep 2008 14:42:01 +1000 From: Peter Jeremy To: Randy Bush Message-ID: <20080914044201.GU15376@server.vk2pj.dyndns.org> References: <48CC82D1.1080009@psg.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AsKt9WDFSpw8OJmf" Content-Disposition: inline In-Reply-To: <48CC82D1.1080009@psg.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD Current Subject: Re: /usr/src/sys/modules/aout/Makefile X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2008 14:15:45 -0000 --AsKt9WDFSpw8OJmf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Sep-14 12:19:45 +0900, Randy Bush wrote: >very current soekris build. kernel conf appended =2E.. >=3D=3D=3D> aout (cleandir) >".depend", line 1: Need an operator I'd have a look at the content of your .depend file - either in=20 /usr/src/sys/modules/aout (there shouldn't be one here) or /usr/obj/usr/src/sys/SOEK0/modules/usr/src/sys/modules/aout --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --AsKt9WDFSpw8OJmf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjMlhkACgkQ/opHv/APuIe7DACfSfYZ5NSBSZ/MfFe6+22k+5eq 5KAAoIXUvWyCjxVKI8SUD8QGjQASCnUt =6cLU -----END PGP SIGNATURE----- --AsKt9WDFSpw8OJmf-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 14 17:32:21 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3E681065678; Sun, 14 Sep 2008 17:32:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 8B0358FC08; Sun, 14 Sep 2008 17:32:16 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m8EHWDIO006756; Sun, 14 Sep 2008 13:32:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m8EHWDDM028719; Sun, 14 Sep 2008 13:32:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 7B17F73039; Sun, 14 Sep 2008 13:32:13 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080914173213.7B17F73039@freebsd-current.sentex.ca> Date: Sun, 14 Sep 2008 13:32:13 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2008 17:32:21 -0000 TB --- 2008-09-14 17:08:41 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-14 17:08:41 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-09-14 17:08:41 - cleaning the object tree TB --- 2008-09-14 17:09:07 - cvsupping the source tree TB --- 2008-09-14 17:09:07 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-09-14 17:09:16 - building world (CFLAGS=-O -pipe) TB --- 2008-09-14 17:09:16 - cd /src TB --- 2008-09-14 17:09:16 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 14 17:09:17 UTC 2008 >>> 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 [...] cc -O -pipe -DPTHREAD_KERNEL -I/src/lib/libthr/../libc/include -I/src/lib/libthr/thread -I/src/lib/libthr/../../include -I/src/lib/libthr/arch/powerpc/include -I/src/lib/libthr/sys -I/src/lib/libthr/../../libexec/rtld-elf -I/src/lib/libthr/../../libexec/rtld-elf/powerpc -I/src/lib/libthr/../libthread_db -Winline -D_PTHREADS_INVARIANTS -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libthr/thread/thr_detach.c cc -O -pipe -DPTHREAD_KERNEL -I/src/lib/libthr/../libc/include -I/src/lib/libthr/thread -I/src/lib/libthr/../../include -I/src/lib/libthr/arch/powerpc/include -I/src/lib/libthr/sys -I/src/lib/libthr/../../libexec/rtld-elf -I/src/lib/libthr/../../libexec/rtld-elf/powerpc -I/src/lib/libthr/../libthread_db -Winline -D_PTHREADS_INVARIANTS -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libthr/thread/thr_equal.c cc -O -pipe -DPTHREAD_KERNEL -I/src/lib/libthr/../libc/include -I/src/lib/libthr/thread -I/src/lib/libthr/../../include -I/src/lib/libthr/arch/powerpc/include -I/src/lib/libthr/sys -I/src/lib/libthr/../../libexec/rtld-elf -I/src/lib/libthr/../../libexec/rtld-elf/powerpc -I/src/lib/libthr/../libthread_db -Winline -D_PTHREADS_INVARIANTS -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libthr/thread/thr_event.c cc1: warnings being treated as errors /src/lib/libthr/thread/thr_event.c: In function '_thr_report_creation': /src/lib/libthr/thread/thr_event.c:45: warning: assignment makes pointer from integer without a cast /src/lib/libthr/thread/thr_event.c: In function '_thr_report_death': /src/lib/libthr/thread/thr_event.c:58: warning: assignment makes pointer from integer without a cast *** Error code 1 Stop in /src/lib/libthr. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-14 17:32:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-14 17:32:13 - ERROR: failed to build world TB --- 2008-09-14 17:32:13 - tinderbox aborted TB --- 1009.98 user 132.73 system 1411.71 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Sep 14 17:48:09 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CEC81065677; Sun, 14 Sep 2008 17:48:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id E76E88FC23; Sun, 14 Sep 2008 17:48:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Kevhd-000KGb-Hb; Sun, 14 Sep 2008 20:48:05 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m8EHm2Aq085543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Sep 2008 20:48:02 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m8EHm2iE053634; Sun, 14 Sep 2008 20:48:02 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id m8EHm1mY053632; Sun, 14 Sep 2008 20:48:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 14 Sep 2008 20:48:01 +0300 From: Kostik Belousov To: current@freebsd.org Message-ID: <20080914174801.GC39652@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hgy5D1otryeNPdmY" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1Kevhd-000KGb-Hb cfa83b32e99b5ed9fd09b5d658c75ba4 X-Terabit: YES Cc: "Yair K." , rnoland@freebsd.org, vehemens Subject: cdevpriv and mmap(2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2008 17:48:09 -0000 --hgy5D1otryeNPdmY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable When implementing cdevpriv, I completeley missed the support for d_mmap() driver method. This method is called by the kernel (at least) twice: one time to validate the mmaped region and protection mode (see vm/device_pager.c:dev_pager_alloc()), and second time to obtain the physical address when serving page fault (see dev_pager_getpages()). Support for cdevpriv for the first call(s) is trivial, and is implemented by the patch below. Second calls are much harder and essentially require attaching cdevpriv bookkeeping data to the struct vm_map_entry. In fact, I am not sure whether this support for the second time calls is needed at all in real usage. I Cc:ed people that pointed me to the issue, please evaluate the patch against your needs. I think I will commit it shortly after your feedback. On the other hand, I would think about implementing full support for d_mmap only if actually needed. Thanks ! diff --git a/sys/vm/vm_mmap.c b/sys/vm/vm_mmap.c index 7e6b04f..c3f08b0 100644 --- a/sys/vm/vm_mmap.c +++ b/sys/vm/vm_mmap.c @@ -391,8 +391,10 @@ map: goto done; } =20 + td->td_fpop =3D fp; error =3D vm_mmap(&vms->vm_map, &addr, size, prot, maxprot, flags, handle_type, handle, pos); + td->td_fpop =3D NULL; #ifdef HWPMC_HOOKS /* inform hwpmc(4) if an executable is being mapped */ if (error =3D=3D 0 && handle_type =3D=3D OBJT_VNODE && --hgy5D1otryeNPdmY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkjNTlEACgkQC3+MBN1Mb4ht9ACg3aJ2J8zEFMECoo7bQeamCL1h /1EAoJf8PxWzTDHsUH8Mzv5zpOGTtBpZ =CjiN -----END PGP SIGNATURE----- --hgy5D1otryeNPdmY-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 14 19:13:43 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92E3B1065671 for ; Sun, 14 Sep 2008 19:13:43 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outA.internet-mail-service.net (outa.internet-mail-service.net [216.240.47.224]) by mx1.freebsd.org (Postfix) with ESMTP id 7136D8FC16 for ; Sun, 14 Sep 2008 19:13:43 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id A3C852438; Sun, 14 Sep 2008 12:14:02 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id AC7842D6017; Sun, 14 Sep 2008 12:13:42 -0700 (PDT) Message-ID: <48CD6266.4030008@elischer.org> Date: Sun, 14 Sep 2008 12:13:42 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Giorgos Keramidas References: <87prnjh80z.fsf@kobe.laptop> <48CC14AD.4090708@elischer.org> <874p4ju8t3.fsf@kobe.laptop> <87zlmbstv1.fsf@kobe.laptop> <48CCAF23.1010605@elischer.org> <87tzcij383.fsf@kobe.laptop> In-Reply-To: <87tzcij383.fsf@kobe.laptop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Robert Watson Subject: Re: panic in rt_check_fib() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2008 19:13:43 -0000 Giorgos Keramidas wrote: [...] > Now an interesting question is: Is it `normal' that the USED rtentry > objects keep going up at every interface restart and are (at least at > first glance) not reclaimed as fast as they are acquired? does it happen with the old rt_check in the case where it doesn't crash? From owner-freebsd-current@FreeBSD.ORG Sun Sep 14 19:15:05 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74410106567C; Sun, 14 Sep 2008 19:15:05 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (unknown [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 453F48FC13; Sun, 14 Sep 2008 19:15:05 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id DEC4346C46; Sun, 14 Sep 2008 15:15:04 -0400 (EDT) Date: Sun, 14 Sep 2008 20:15:04 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kostik Belousov In-Reply-To: <20080914174801.GC39652@deviant.kiev.zoral.com.ua> Message-ID: References: <20080914174801.GC39652@deviant.kiev.zoral.com.ua> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: rnoland@freebsd.org, current@freebsd.org, "Yair K." , vehemens Subject: Re: cdevpriv and mmap(2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2008 19:15:05 -0000 On Sun, 14 Sep 2008, Kostik Belousov wrote: > When implementing cdevpriv, I completeley missed the support for d_mmap() > driver method. This method is called by the kernel (at least) twice: one > time to validate the mmaped region and protection mode (see > vm/device_pager.c:dev_pager_alloc()), and second time to obtain the physical > address when serving page fault (see dev_pager_getpages()). > > Support for cdevpriv for the first call(s) is trivial, and is implemented by > the patch below. Second calls are much harder and essentially require > attaching cdevpriv bookkeeping data to the struct vm_map_entry. In fact, I > am not sure whether this support for the second time calls is needed at all > in real usage. > > I Cc:ed people that pointed me to the issue, please evaluate the patch > against your needs. I think I will commit it shortly after your feedback. On > the other hand, I would think about implementing full support for d_mmap > only if actually needed. I'm not really sure that these changes "make sense" given the way our device pager works right now. My understanding is that most consumers of cdevpriv use it in order to provide session-centric device nodes as a cleaner alternative to cloning. However, even with your change, it's not possible to support session-centric memory mapping of devices as the memory map and device pager code assumes there is one VM object for each device, and hence all pages mapped independently from different file descriptors on the same device are from the same set of pages (and hence in the same VM object page cache). In order to implement session-centric semantics, I think it's actually quite a bit more complicated than just adding vm_map_entry book-keeping -- we also need to have a different VM object for each session. And, arguably, we need a more mature device_pager that understands that pages might someday no longer be associated with a device due to that device being removed... Robert N M Watson Computer Laboratory University of Cambridge > > Thanks ! > > diff --git a/sys/vm/vm_mmap.c b/sys/vm/vm_mmap.c > index 7e6b04f..c3f08b0 100644 > --- a/sys/vm/vm_mmap.c > +++ b/sys/vm/vm_mmap.c > @@ -391,8 +391,10 @@ map: > goto done; > } > > + td->td_fpop = fp; > error = vm_mmap(&vms->vm_map, &addr, size, prot, maxprot, > flags, handle_type, handle, pos); > + td->td_fpop = NULL; > #ifdef HWPMC_HOOKS > /* inform hwpmc(4) if an executable is being mapped */ > if (error == 0 && handle_type == OBJT_VNODE && > From owner-freebsd-current@FreeBSD.ORG Sun Sep 14 19:18:05 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F045B1065672; Sun, 14 Sep 2008 19:18:05 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id A9C2A8FC18; Sun, 14 Sep 2008 19:18:05 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m8EJI25b066872; Sun, 14 Sep 2008 15:18:02 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id m8EJI2hh016344; Sun, 14 Sep 2008 15:18:02 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 6F0E973039; Sun, 14 Sep 2008 15:18:02 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080914191802.6F0E973039@freebsd-current.sentex.ca> Date: Sun, 14 Sep 2008 15:18:02 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2008 19:18:06 -0000 TB --- 2008-09-14 18:05:13 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-14 18:05:13 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-09-14 18:05:13 - cleaning the object tree TB --- 2008-09-14 18:05:36 - cvsupping the source tree TB --- 2008-09-14 18:05:36 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-09-14 18:05:46 - building world (CFLAGS=-O -pipe) TB --- 2008-09-14 18:05:46 - cd /src TB --- 2008-09-14 18:05:46 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 14 18:05:47 UTC 2008 >>> 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 >>> World build completed on Sun Sep 14 19:13:57 UTC 2008 TB --- 2008-09-14 19:13:57 - generating LINT kernel config TB --- 2008-09-14 19:13:57 - cd /src/sys/sun4v/conf TB --- 2008-09-14 19:13:57 - /usr/bin/make -B LINT TB --- 2008-09-14 19:13:57 - building LINT kernel (COPTFLAGS=) TB --- 2008-09-14 19:13:57 - cd /src TB --- 2008-09-14 19:13:57 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Sep 14 19:13:58 UTC 2008 >>> 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 [...] cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/sound/unit.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/sound/pci/atiixp.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/sound/pci/envy24.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/sound/pci/envy24ht.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/sound/pci/es137x.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/sound/pci/spicds.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/sound/pci/hda/hdac.c /src/sys/dev/sound/pci/hda/hdac.c:642: error: 'HDA_CODEC_ALC663' undeclared here (not in a function) *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-14 19:18:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-14 19:18:02 - ERROR: failed to build lint kernel TB --- 2008-09-14 19:18:02 - tinderbox aborted TB --- 3121.24 user 390.16 system 4368.60 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sun Sep 14 21:35:15 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EA801065676; Sun, 14 Sep 2008 21:35:15 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (unknown [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0D2E88FC12; Sun, 14 Sep 2008 21:35:15 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id DCA382844D; Mon, 15 Sep 2008 05:35:13 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id F3C2EF65186; Mon, 15 Sep 2008 05:35:12 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id qG1P1655yrnk; Mon, 15 Sep 2008 05:35:04 +0800 (CST) Received: from delta.delphij.net (c-76-103-40-85.hsd1.ca.comcast.net [76.103.40.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 76824EB8C05; Mon, 15 Sep 2008 05:35:03 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=hXWCf3jbVgFNeZi6mZTiPVfuGcZ8YsvFIOusX2bwmJrehQiojX6aHl/RwC4YbIMpm TYwyZJF9aWThu/1ReeIJw== Message-ID: <48CD837C.9050206@delphij.net> Date: Sun, 14 Sep 2008 14:34:52 -0700 From: Xin LI User-Agent: Thunderbird 2.0.0.16 (X11/20080813) MIME-Version: 1.0 To: "Carlos A. M. dos Santos" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , olli@FreeBSD.org Subject: Re: Why VESA and DPMS are available only for i386? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2008 21:35:15 -0000 Carlos A. M. dos Santos wrote: > Hello, > > Several PRs were closed based on the argument that FreeBSD/amd64 > cannot call to the VESA BIOS. XFree86 solved this problem by means of > the INT10 module. I believe that it would be possible to do the same > on the FreeBSD kernel. > > Is there any ongoing effort to enable the VESA kernel moule on > non-i386 platform? Is there any particular difficulty for doing this, > besides depending on VM86? > According to VESA's VBE 3.0 standard, there is a "Protected Mode Entry Point" [optionally] provided by BIOS, which OS or application is supposed to copy to a place where it is writable. The code there would be written in 16-bit protected mode. Therefore I think it's do-able... http://www.vesa.org/public/VBE/vbe3.pdf Cheers, From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 01:38:01 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62FA0106566B for ; Mon, 15 Sep 2008 01:38:01 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from cauchy.math.missouri.edu (cauchy.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id 0C5048FC22 for ; Mon, 15 Sep 2008 01:38:00 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from laptop3.gateway.2wire.net (cauchy.math.missouri.edu [128.206.184.213]) by cauchy.math.missouri.edu (8.14.2/8.14.2) with ESMTP id m8F1bPRe017191 for ; Sun, 14 Sep 2008 20:37:25 -0500 (CDT) (envelope-from stephen@math.missouri.edu) Message-ID: <48CDBC78.4010409@math.missouri.edu> Date: Sun, 14 Sep 2008 20:38:00 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.1.16) Gecko/20080909 SeaMonkey/1.1.11 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Improved multiprocessor usage on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 01:38:01 -0000 I have a dual core amd64 on which I run a processor intensive numerical program. I had been frustrated because it seemed to run 3 or 4 times faster under Linux. But with a recent upgrade of FreeBSD-CURRENT, it now goes at about the same speed as Linux. The program takes about an hour. For the first minute, the program runs rather slowly, but then it is as if the operating system finds its way, and suddenly it speeds up. "top -H" suggests that for the first minute that one thread is going really slowly, and is perhaps being starved or something. My question is - why is this happening, and is this something I should expect? Are there certain switches or sysctls I can set to make it go fast from the get go? I should add that I am gratified that FreeBSD has caught up with Linux in this respect. I hope that I will see even more improvements. I will be happy to share the software I am running to help in this regard, but I don't yet have permission from my employer (University of Missouri) to give it an open source license, so I only feel comfortable giving it to people on a case by case basis. Thanks, Stephen From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 02:39:41 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF5BF106566B for ; Mon, 15 Sep 2008 02:39:41 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 5F93C8FC1D for ; Mon, 15 Sep 2008 02:39:41 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so573992yxb.13 for ; Sun, 14 Sep 2008 19:39:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=/+9IoMSXRWB5DiO3+31PuMX1sxMfqDUTKWQsBxjb6+c=; b=BnWEWWl4z+DI4jpf3WBtv78w8CYrPnfBjIzxrShGZL0JxPsa6KoAtRXTMU36jPQwrN z+3fr/m1Gh0wGHvmDoI5nYQRNOvkUcwoItyjhTUao3suBxIJaVUoizgsNmr/fljTwxn5 i3fR1XhKezQowrQqlBt4rHKjXjqLiNS94AErM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=GFmVGBzKnd1ybq0UVlgwLfsNnfRi8zsVz0CmZog7QX7+f3qYGyLG2UGoN0JlW85Tv/ UIJNY+FmU0Z+GDfMgH5kY9/DGdjSPZ5g6Geq3rOzF3xjcj7GuNgigQED5Jnb7b5lAvlk exh6nmtVN0ampXadNwiheOxu+cu2mJdlgIJtw= Received: by 10.150.98.18 with SMTP id v18mr2725175ybb.64.1221446380671; Sun, 14 Sep 2008 19:39:40 -0700 (PDT) Received: by 10.150.140.14 with HTTP; Sun, 14 Sep 2008 19:39:40 -0700 (PDT) Message-ID: <8cb6106e0809141939l99ebb62kea67172fe2fbd411@mail.gmail.com> Date: Sun, 14 Sep 2008 22:39:40 -0400 From: "Josh Carroll" To: "Stephen Montgomery-Smith" In-Reply-To: <48CDBC78.4010409@math.missouri.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48CDBC78.4010409@math.missouri.edu> Cc: freebsd-current@freebsd.org Subject: Re: Improved multiprocessor usage on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 02:39:41 -0000 On Sun, Sep 14, 2008 at 9:38 PM, Stephen Montgomery-Smith wrote: > I have a dual core amd64 on which I run a processor intensive numerical > program. I had been frustrated because it seemed to run 3 or 4 times faster > under Linux. But with a recent upgrade of FreeBSD-CURRENT, it now goes at > about the same speed as Linux. Which release/version were you running prior? Keep in mind, by default, various debugging knobs/etc are enabled in -current, so perhaps you went from a kernel with WITNESS/etc enabled to a kernel without these? I can run it here (on 7.1-PRERELEASE/amd64) if you'd like to send the source (to this address). > The program takes about an hour. For the first minute, the program runs > rather slowly, but then it is as if the operating system finds its way, and > suddenly it speeds up. "top -H" suggests that for the first minute that one > thread is going really slowly, and is perhaps being starved or something. Have you run a ktrace on it? That would be useful to see what's going on. > My question is - why is this happening, and is this something I should > expect? Are there certain switches or sysctls I can set to make it go fast > from the get go? Hard to say without seeing the code and knowing precisely what it does. Perhaps it's doing a lot of I/O up front or some preparations prior to the calculations? Regards, Josh From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 02:54:46 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F11E0106567D; Mon, 15 Sep 2008 02:54:44 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 5DA338FC1F; Mon, 15 Sep 2008 02:54:43 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (adsl172-222.kln.forthnet.gr [62.1.21.222]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-5) with ESMTP id m8F2sT5l006647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Sep 2008 05:54:36 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id m8F2sSDY002454; Mon, 15 Sep 2008 05:54:28 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id m8F2sQTB002453; Mon, 15 Sep 2008 05:54:26 +0300 (EEST) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: Julian Elischer References: <87prnjh80z.fsf@kobe.laptop> <48CC14AD.4090708@elischer.org> <874p4ju8t3.fsf@kobe.laptop> <87zlmbstv1.fsf@kobe.laptop> <48CCAF23.1010605@elischer.org> <87tzcij383.fsf@kobe.laptop> <48CD6266.4030008@elischer.org> Date: Mon, 15 Sep 2008 05:54:14 +0300 In-Reply-To: <48CD6266.4030008@elischer.org> (Julian Elischer's message of "Sun, 14 Sep 2008 12:13:42 -0700") Message-ID: <87fxo2qfu1.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-MailScanner-ID: m8F2sT5l006647 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.521, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL -0.12, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: freebsd-current@freebsd.org, Robert Watson Subject: Re: panic in rt_check_fib() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 02:54:47 -0000 --=-=-= On Sun, 14 Sep 2008 12:13:42 -0700, Julian Elischer wrote: > Giorgos Keramidas wrote: >> Now an interesting question is: Is it `normal' that the USED rtentry >> objects keep going up at every interface restart and are (at least at >> first glance) not reclaimed as fast as they are acquired? > > does it happen with the old rt_check in the case where it doesn't crash? Hi Julian, Yes it happens with the old kernel too. I tried bringing the re0 interface up and down with a kernel compiled from a clean copy of base/head @ 182948. The rtentry's allocated seem to be going linearly up every time I restart the interface with the old, unpatched rt_check_fib() too. So if there is an rtentry leak, it exists in both the unpatched and the patched kernels. By going through the last rt_check_fib() you sent, I don't see an obvious place where the leak could occur in *this* function, so I will try to see if it's easier to find out where rtentry's are pulled from the related zone. Then by correlating these with the places where rtentry's are freed it may become more obvious why/when the USED objects get bumped. It may be just a missing RT_REMREF() elsewhere, but I can't tell for sure yet where/when this happens... I'll keep looking. In the meantime, the new rt_check_fib() has saved me from several semi-random panics a week, so I think I like it :-D --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjNzmIACgkQ1g+UGjGGA7ZziQCbBWdjFqgHVjDGC650jh1Vk9J8 cZwAoL6pz63aXDTFyyOaL3ML4OEWq8eA =kfLK -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 04:12:09 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3E12106564A for ; Mon, 15 Sep 2008 04:12:09 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-gx0-f17.google.com (mail-gx0-f17.google.com [209.85.217.17]) by mx1.freebsd.org (Postfix) with ESMTP id 66A3B8FC08 for ; Mon, 15 Sep 2008 04:12:09 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by gxk10 with SMTP id 10so22502656gxk.19 for ; Sun, 14 Sep 2008 21:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=6NxJlWF50rRNJ8JKzDpcF3AgTb0Q06sDHGqnzCRRSFA=; b=cgIC87nb6eXRQWocR78NFTUDSzmMq1a9E8Gf7pNX2lmQB1RsZ6sCmnUuzf5rbinv22 Cqt2oH6kc6X7VTn3vmUYdtjzxipAb85t6r1hwQv4dHsUaVBkK11w3CvX1HPcVAoeV0qJ B4rCHTdLlxcza/CideDU2lkfFjcDBMVcbp2l4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=AgZ1HlSGAcxifKDhBJyrIJvV9k9uc1j6LcXkurj0DY0QK9Zv42/ceobJFrxJJO9t/x i18U+J752Uouoc9crdcUZBfWXvw8d2RcuN4O/tE/aOhpUXnbo/xKAs2gmWqfdmmKF3KC jzkxTR297+AYhCN/niLgVuYUA9F/b+/+0NZm0= Received: by 10.86.82.6 with SMTP id f6mr5525159fgb.73.1221451927691; Sun, 14 Sep 2008 21:12:07 -0700 (PDT) Received: by 10.86.62.14 with HTTP; Sun, 14 Sep 2008 21:12:07 -0700 (PDT) Message-ID: <7d6fde3d0809142112o4de36352md0302b4d8608b03f@mail.gmail.com> Date: Sun, 14 Sep 2008 21:12:07 -0700 From: "Garrett Cooper" To: "FreeBSD Ports" , current@freebsd.org In-Reply-To: <7d6fde3d0809142110x1d28e40fm4e976f93ae507852@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200807241348.m6ODmVNe090621@www.freebsd.org> <7d6fde3d0807241118x122c25dbjad0e6f7b98f789d7@mail.gmail.com> <20080909212343.58886989@tau.draftnet> <7d6fde3d0809112324l5d99c157n1d5f23efbb32f3bf@mail.gmail.com> <7d6fde3d0809142110x1d28e40fm4e976f93ae507852@mail.gmail.com> Cc: Subject: Fwd: bin/125932: pkg_add(1) doesn't prompt for root credentials and then fails badly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 04:12:09 -0000 ------------------------ Fyi (From Bugbuster email for bin/125932): ------------------------ Here's a proposed patch for the first set of cleanup to pkg_install: , and some fixing to alleviate the issue in bin/125932. Rather than biting off more than I can chew with the perforce project, I'm going to work off the changes Anders has made and incrementally polish pkg_install (like I should have done last year -_-...) This patch causes pkg_install to error out at the first sign of install failure (which could take a while as it's still using tar(1) to extract archives in add/extract.c), BUT in getFileByURL I've completely replaced the tar requirement in lib/url.c with archive(3)'s, quite handy hooks for writing to files. So don't be alarmed when you see that the file has grown 4 times ;)... This patch hasn't gotten much mileage, other than a few failure and success cases, so if others could please take a look at this and provide comments I'd much appreciate it. Cheers, -Garrett PS Packages might not be dumped in the correct spot -- I just chose /var/tmp, but if someone could point me to the "industry standard" location that portupgrade uses for instance, I'd be more than happy to point there. From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 04:59:27 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 953B61065670 for ; Mon, 15 Sep 2008 04:59:27 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.232]) by mx1.freebsd.org (Postfix) with ESMTP id 4CCCA8FC18 for ; Mon, 15 Sep 2008 04:59:27 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: by wx-out-0506.google.com with SMTP id s17so816989wxc.7 for ; Sun, 14 Sep 2008 21:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=WFFdVDBKRMP+ehud61gUP7l6XqvAyDsLKPS0QRY63D4=; b=VB65m+hL/hMwaeSnAsYyoVgSC2X2kPKIqcC51WHxR94PFq2S3ol0kFl8xBF8p2t75Y 9mOzSpemsAMxDkSqjM2ID76BDewWbwfK5t42LR7OjdvJAnNzqIiVQuZueaiBFTfeqLkC AY7jDjZlb55Vv1iffRDVzgqis8/B5Z6xay2lE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=mBUa0YUvfAzzsyfsZSlFhmAXmgcJe1NG0UJj/rjvgd1nmLmlk4Vyb1YH5cGThknxV7 +YVDJfHV9gO0VkPzB+yCm7cqzLf6DemhquoohJHTDNgCJkHSxqurE9j2+uY6frreP0Uc NIQahtff/dkyjtOvKk9A6xPULZZIdBGyjBo84= Received: by 10.103.176.2 with SMTP id d2mr5084990mup.112.1221454765334; Sun, 14 Sep 2008 21:59:25 -0700 (PDT) Received: by 10.103.231.14 with HTTP; Sun, 14 Sep 2008 21:59:25 -0700 (PDT) Message-ID: Date: Mon, 15 Sep 2008 01:59:25 -0300 From: "Carlos A. M. dos Santos" To: "Xin LI" In-Reply-To: <48CD837C.9050206@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48CD837C.9050206@delphij.net> Cc: FreeBSD Current , olli@freebsd.org Subject: Re: Why VESA and DPMS are available only for i386? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 04:59:27 -0000 On Sun, Sep 14, 2008 at 6:34 PM, Xin LI wrote: > Carlos A. M. dos Santos wrote: >> Hello, >> >> Several PRs were closed based on the argument that FreeBSD/amd64 >> cannot call to the VESA BIOS. XFree86 solved this problem by means of >> the INT10 module. I believe that it would be possible to do the same >> on the FreeBSD kernel. >> >> Is there any ongoing effort to enable the VESA kernel moule on >> non-i386 platform? Is there any particular difficulty for doing this, >> besides depending on VM86? >> > According to VESA's VBE 3.0 standard, there is a "Protected Mode Entry > Point" [optionally] provided by BIOS, which OS or application is > supposed to copy to a place where it is writable. The code there would > be written in 16-bit protected mode. Therefore I think it's do-able... > > http://www.vesa.org/public/VBE/vbe3.pdf > > Cheers, I'm reading the specification and digging at the code of the X server and the X VESA driver. Look promising. -- cd /usr/ports/sysutils/life make clean From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 06:24:07 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EFE11065680; Mon, 15 Sep 2008 06:24:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id C04FB8FC3B; Mon, 15 Sep 2008 06:24:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m8F6O2Zs002673; Mon, 15 Sep 2008 02:24:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id m8F6O2dQ035258; Mon, 15 Sep 2008 02:24:02 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 91DD173039; Mon, 15 Sep 2008 02:24:02 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080915062402.91DD173039@freebsd-current.sentex.ca> Date: Mon, 15 Sep 2008 02:24:02 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 06:24:07 -0000 TB --- 2008-09-15 05:02:11 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-15 05:02:11 - starting HEAD tinderbox run for i386/pc98 TB --- 2008-09-15 05:02:11 - cleaning the object tree TB --- 2008-09-15 05:02:44 - cvsupping the source tree TB --- 2008-09-15 05:02:44 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2008-09-15 05:02:56 - building world (CFLAGS=-O -pipe) TB --- 2008-09-15 05:02:56 - cd /src TB --- 2008-09-15 05:02:56 - /usr/bin/make -B buildworld >>> World build started on Mon Sep 15 05:02:58 UTC 2008 >>> 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 >>> World build completed on Mon Sep 15 06:16:28 UTC 2008 TB --- 2008-09-15 06:16:28 - generating LINT kernel config TB --- 2008-09-15 06:16:28 - cd /src/sys/pc98/conf TB --- 2008-09-15 06:16:28 - /usr/bin/make -B LINT TB --- 2008-09-15 06:16:28 - building LINT kernel (COPTFLAGS=) TB --- 2008-09-15 06:16:28 - cd /src TB --- 2008-09-15 06:16:28 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Sep 15 06:16:28 UTC 2008 >>> 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 [...] cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/pfil.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/radix.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/radix_mpath.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/raw_cb.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/raw_usrreq.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/route.c /src/sys/net/route.c: In function 'rt_check': /src/sys/net/route.c:1719: error: invalid type argument of '->' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-15 06:24:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-15 06:24:02 - ERROR: failed to build lint kernel TB --- 2008-09-15 06:24:02 - tinderbox aborted TB --- 3342.54 user 428.63 system 4910.77 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 06:55:31 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8330A106564A; Mon, 15 Sep 2008 06:55:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 1B98F8FC19; Mon, 15 Sep 2008 06:55:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Kf7zc-000IZ8-U5; Mon, 15 Sep 2008 09:55:29 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m8F6tPnn025319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Sep 2008 09:55:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m8F6tP10045494; Mon, 15 Sep 2008 09:55:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id m8F6tPhQ045491; Mon, 15 Sep 2008 09:55:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 15 Sep 2008 09:55:25 +0300 From: Kostik Belousov To: Robert Watson Message-ID: <20080915065525.GD39652@deviant.kiev.zoral.com.ua> References: <20080914174801.GC39652@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SlNwLc1tujQOaj7L" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1Kf7zc-000IZ8-U5 0ee66110025d9f4fd7716939e3741e0d X-Terabit: YES Cc: rnoland@freebsd.org, current@freebsd.org, "Yair K." , vehemens Subject: Re: cdevpriv and mmap(2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 06:55:31 -0000 --SlNwLc1tujQOaj7L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 14, 2008 at 08:15:04PM +0100, Robert Watson wrote: >=20 > On Sun, 14 Sep 2008, Kostik Belousov wrote: >=20 > >When implementing cdevpriv, I completeley missed the support for d_mmap(= )=20 > >driver method. This method is called by the kernel (at least) twice: one= =20 > >time to validate the mmaped region and protection mode (see=20 > >vm/device_pager.c:dev_pager_alloc()), and second time to obtain the=20 > >physical address when serving page fault (see dev_pager_getpages()). > > > >Support for cdevpriv for the first call(s) is trivial, and is implemente= d=20 > >by the patch below. Second calls are much harder and essentially require= =20 > >attaching cdevpriv bookkeeping data to the struct vm_map_entry. In fact,= I=20 > >am not sure whether this support for the second time calls is needed at= =20 > >all in real usage. > > > >I Cc:ed people that pointed me to the issue, please evaluate the patch= =20 > >against your needs. I think I will commit it shortly after your feedback= .=20 > >On the other hand, I would think about implementing full support for=20 > >d_mmap only if actually needed. >=20 > I'm not really sure that these changes "make sense" given the way our=20 > device pager works right now. My understanding is that most consumers of= =20 > cdevpriv use it in order to provide session-centric device nodes as a=20 > cleaner alternative to cloning. However, even with your change, it's not= =20 > possible to support session-centric memory mapping of devices as the memo= ry=20 > map and device pager code assumes there is one VM object for each device,= =20 > and hence all pages mapped independently from different file descriptors = on=20 > the same device are from the same set of pages (and hence in the same VM= =20 > object page cache). In order to implement session-centric semantics, I= =20 > think it's actually quite a bit more complicated than just adding=20 > vm_map_entry book-keeping -- we also need to have a different VM object f= or=20 > each session. >=20 > And, arguably, we need a more mature device_pager that understands that= =20 > pages might someday no longer be associated with a device due to that=20 > device being removed... The issues you raised are obviously important, but IMHO they are ortogonal to the cdevpriv KPI working in for _any_ pager. Pager' getpages method is usually called from the context where kernel does not have naturally supplied filedescriptor. For instance, most typical caller if vm_fault(). Thus, whatever pager is used, we have to provide a way for kernel to somehow associate struct file with faulted page (region), and make that file available to the pager. [Hmm, because kernel is allowed to fault too, vm_fault() should save/restore td_fpop.] Another point is that we have important consumers of the existing device pager interface that already want to use cdevpriv. Their usage ATM is limited to authentification, whatever it means. I assume it means checking that the caller was given some token the validation step. The code should be structured approx. like this: dri_mmap(...) { some_dri_data *p; int error; error =3D devfs_get_cdevpriv(&p); if (error =3D=3D 0) { /* authenticate; */ } /* * Auth successfull or error =3D=3D EBADF * Do whatever needed to return phys address */ ... } And, the last issue you raised, the need for the new pager is actually real for GEM/TTM or whatever the newest DRI interface is called. I have an intent to play with it, but more smart thing would be to wait some time more. Hopefully, then DRI folks will finally decide on the (more) stable interface. I am sure that it would be changed several dozen times in the future, but have a hope that it will not be designed from scratch. --SlNwLc1tujQOaj7L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkjOBtwACgkQC3+MBN1Mb4iaRwCglRl560YvTHhWavJeI7Ih0C7C MJcAnjX9IubccQVwoYmUamaJ0oPBP3wO =p2bF -----END PGP SIGNATURE----- --SlNwLc1tujQOaj7L-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 07:18:28 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E9341065672; Mon, 15 Sep 2008 07:18:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id C75E08FC16; Mon, 15 Sep 2008 07:18:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m8F7IPxE005069; Mon, 15 Sep 2008 03:18:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id m8F7IPOR063493; Mon, 15 Sep 2008 03:18:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5E25A73039; Mon, 15 Sep 2008 03:18:25 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080915071825.5E25A73039@freebsd-current.sentex.ca> Date: Mon, 15 Sep 2008 03:18:25 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 07:18:28 -0000 TB --- 2008-09-15 05:45:37 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-15 05:45:37 - starting HEAD tinderbox run for ia64/ia64 TB --- 2008-09-15 05:45:37 - cleaning the object tree TB --- 2008-09-15 05:46:15 - cvsupping the source tree TB --- 2008-09-15 05:46:15 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2008-09-15 05:46:22 - building world (CFLAGS=-O -pipe) TB --- 2008-09-15 05:46:22 - cd /src TB --- 2008-09-15 05:46:22 - /usr/bin/make -B buildworld >>> World build started on Mon Sep 15 05:46:25 UTC 2008 >>> 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 >>> World build completed on Mon Sep 15 07:08:29 UTC 2008 TB --- 2008-09-15 07:08:29 - generating LINT kernel config TB --- 2008-09-15 07:08:29 - cd /src/sys/ia64/conf TB --- 2008-09-15 07:08:29 - /usr/bin/make -B LINT TB --- 2008-09-15 07:08:29 - building LINT kernel (COPTFLAGS=) TB --- 2008-09-15 07:08:29 - cd /src TB --- 2008-09-15 07:08:29 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Sep 15 07:08:30 UTC 2008 >>> 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 [...] cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -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 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/net/pfil.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -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 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/net/radix.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -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 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/net/radix_mpath.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -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 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/net/raw_cb.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -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 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/net/raw_usrreq.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -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 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/net/route.c /src/sys/net/route.c: In function 'rt_check': /src/sys/net/route.c:1719: error: invalid type argument of '->' *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-15 07:18:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-15 07:18:25 - ERROR: failed to build lint kernel TB --- 2008-09-15 07:18:25 - tinderbox aborted TB --- 3902.29 user 424.83 system 5567.60 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 07:47:46 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D47651065676; Mon, 15 Sep 2008 07:47:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 97A428FC1B; Mon, 15 Sep 2008 07:47:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m8F7lgaO006114; Mon, 15 Sep 2008 03:47:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id m8F7lgWW029253; Mon, 15 Sep 2008 03:47:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 222EB73039; Mon, 15 Sep 2008 03:47:42 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080915074742.222EB73039@freebsd-current.sentex.ca> Date: Mon, 15 Sep 2008 03:47:42 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 07:47:47 -0000 TB --- 2008-09-15 06:24:02 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-15 06:24:02 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-09-15 06:24:02 - cleaning the object tree TB --- 2008-09-15 06:24:28 - cvsupping the source tree TB --- 2008-09-15 06:24:29 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-09-15 06:24:36 - building world (CFLAGS=-O -pipe) TB --- 2008-09-15 06:24:36 - cd /src TB --- 2008-09-15 06:24:36 - /usr/bin/make -B buildworld >>> World build started on Mon Sep 15 06:24:37 UTC 2008 >>> 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 >>> World build completed on Mon Sep 15 07:41:16 UTC 2008 TB --- 2008-09-15 07:41:16 - generating LINT kernel config TB --- 2008-09-15 07:41:16 - cd /src/sys/powerpc/conf TB --- 2008-09-15 07:41:16 - /usr/bin/make -B LINT TB --- 2008-09-15 07:41:16 - building LINT kernel (COPTFLAGS=) TB --- 2008-09-15 07:41:16 - cd /src TB --- 2008-09-15 07:41:16 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Sep 15 07:41:16 UTC 2008 >>> 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 [...] cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -fno-omit-frame-pointer -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/pfil.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -fno-omit-frame-pointer -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/radix.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -fno-omit-frame-pointer -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/radix_mpath.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -fno-omit-frame-pointer -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/raw_cb.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -fno-omit-frame-pointer -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/raw_usrreq.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -fno-omit-frame-pointer -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/route.c /src/sys/net/route.c: In function 'rt_check': /src/sys/net/route.c:1719: error: invalid type argument of '->' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-15 07:47:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-15 07:47:41 - ERROR: failed to build lint kernel TB --- 2008-09-15 07:47:41 - tinderbox aborted TB --- 3385.69 user 403.96 system 5019.26 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 08:35:12 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AABFE1065672; Mon, 15 Sep 2008 08:35:12 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 695638FC22; Mon, 15 Sep 2008 08:35:12 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m8F8ZA4v008083; Mon, 15 Sep 2008 04:35:10 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id m8F8ZA9I045347; Mon, 15 Sep 2008 04:35:10 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 2BCB173039; Mon, 15 Sep 2008 04:35:10 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080915083510.2BCB173039@freebsd-current.sentex.ca> Date: Mon, 15 Sep 2008 04:35:10 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 08:35:12 -0000 TB --- 2008-09-15 07:18:25 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-15 07:18:25 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-09-15 07:18:25 - cleaning the object tree TB --- 2008-09-15 07:19:00 - cvsupping the source tree TB --- 2008-09-15 07:19:00 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-09-15 07:19:06 - building world (CFLAGS=-O -pipe) TB --- 2008-09-15 07:19:06 - cd /src TB --- 2008-09-15 07:19:06 - /usr/bin/make -B buildworld >>> World build started on Mon Sep 15 07:19:07 UTC 2008 >>> 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 >>> World build completed on Mon Sep 15 08:28:30 UTC 2008 TB --- 2008-09-15 08:28:30 - generating LINT kernel config TB --- 2008-09-15 08:28:30 - cd /src/sys/sparc64/conf TB --- 2008-09-15 08:28:30 - /usr/bin/make -B LINT TB --- 2008-09-15 08:28:30 - building LINT kernel (COPTFLAGS=) TB --- 2008-09-15 08:28:30 - cd /src TB --- 2008-09-15 08:28:30 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Sep 15 08:28:31 UTC 2008 >>> 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 [...] cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/pfil.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/radix.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/radix_mpath.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/raw_cb.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/raw_usrreq.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/route.c /src/sys/net/route.c: In function 'rt_check': /src/sys/net/route.c:1719: error: invalid type argument of '->' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-15 08:35:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-15 08:35:09 - ERROR: failed to build lint kernel TB --- 2008-09-15 08:35:09 - tinderbox aborted TB --- 3189.74 user 404.35 system 4604.34 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 08:59:02 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2FEE1065670 for ; Mon, 15 Sep 2008 08:59:02 +0000 (UTC) (envelope-from stevenschlansker@berkeley.edu) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by mx1.freebsd.org (Postfix) with ESMTP id DD16D8FC0A for ; Mon, 15 Sep 2008 08:59:02 +0000 (UTC) (envelope-from stevenschlansker@berkeley.edu) Received: from emu.stevenschlansker.is-a-geek.org (66-117-142-212.lmi.net [66.117.142.212]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id m8F8x1wM008729 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 15 Sep 2008 01:59:02 -0700 (PDT) Message-Id: <3A22C890-8724-4A41-8E67-2F6A8D4D7E3C@berkeley.edu> From: Steven Schlansker To: freebsd-current@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 15 Sep 2008 01:58:56 -0700 X-Mailer: Apple Mail (2.926) Subject: pjd's ZFS 2008-07-27 patches against HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 08:59:03 -0000 Hello everyone, First, a thank you to pjd and the other contributers for all their work getting ZFS to work. It's a really awesome feature, and I've gotten good use of it already :) I recently got fed up with all the deadlocks that ZFS seems to have on my home server (things hang in zfs: states, nothing can kill them, prevents rebooting, etc) so I decided to try out -CURRENT with the latest ZFS patches. However, they no longer seem to apply cleanly. Specifically, [steven@universe:/usr/src]% bzcat ~/zfs_20080727.patch.bz2 | sudo patch -s -C -p0 1 out of 14 hunks failed--saving rejects to cddl/contrib/opensolaris/ lib/libzpool/common/sys/zfs_context.h.rej 1 out of 11 hunks failed--saving rejects to sys/cddl/contrib/ opensolaris/uts/common/fs/zfs/vdev_file.c.rej 1 out of 33 hunks failed--saving rejects to sys/cddl/contrib/ opensolaris/uts/common/fs/zfs/zfs_ctldir.c.rej 1 out of 20 hunks failed--saving rejects to sys/cddl/contrib/ opensolaris/uts/common/fs/zfs/zfs_replay.c.rej 1 out of 115 hunks failed--saving rejects to sys/cddl/contrib/ opensolaris/uts/common/fs/zfs/zfs_vnops.c.rej 4 out of 29 hunks failed--saving rejects to sys/cddl/contrib/ opensolaris/uts/common/fs/zfs/zfs_znode.c.rej 1 out of 11 hunks failed--saving rejects to sys/kern/kern_jail.c.rej This is against a current HEAD (tag=. in csup as of 2 hours ago) I was wondering if there is a newer patch out there (I don't see anything in ~pjd/patches) or if anyone has had any luck getting the patch to apply cleanly to the latest sources. Thanks, Steven Schlansker From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 09:09:00 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D391B106566C for ; Mon, 15 Sep 2008 09:09:00 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 5824A8FC17 for ; Mon, 15 Sep 2008 09:09:00 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.2/8.14.2) with ESMTP id m8F8vfZq090848 for ; Mon, 15 Sep 2008 12:57:42 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Mon, 15 Sep 2008 12:57:41 +0400 (MSD) From: Dmitry Morozovsky To: current@FreeBSD.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (woozle.rinet.ru [0.0.0.0]); Mon, 15 Sep 2008 12:57:42 +0400 (MSD) Cc: Subject: cleandifles in kmod.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 09:09:00 -0000 Hi there colleagues, it seems we miss two files per kernel module when debug is defined (which kinda brokes cleandir target): marck@beaver:/FreeBSD/src.current/sys> svn diff conf/kmod.mk Index: conf/kmod.mk =================================================================== --- conf/kmod.mk (revision 183034) +++ conf/kmod.mk (working copy) @@ -168,6 +168,7 @@ FULLPROG= ${PROG} .else FULLPROG= ${PROG}.debug +CLEANFILES+= ${PROG}.debug ${PROG}.symbols ${PROG}: ${FULLPROG} ${PROG}.symbols ${OBJCOPY} --strip-debug --add-gnu-debuglink=${PROG}.symbols\ ${FULLPROG} ${.TARGET} Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 08:12:48 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78419106567C for ; Mon, 15 Sep 2008 08:12:48 +0000 (UTC) (envelope-from stevenschlansker@berkeley.edu) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by mx1.freebsd.org (Postfix) with ESMTP id 307908FC21 for ; Mon, 15 Sep 2008 08:12:48 +0000 (UTC) (envelope-from stevenschlansker@berkeley.edu) Received: from emu.stevenschlansker.is-a-geek.org (66-117-142-212.lmi.net [66.117.142.212]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id m8F7vZ2q008436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 15 Sep 2008 00:57:37 -0700 (PDT) Message-Id: From: Steven Schlansker To: freebsd-current@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 15 Sep 2008 00:57:30 -0700 X-Mailer: Apple Mail (2.926) X-Mailman-Approved-At: Mon, 15 Sep 2008 11:22:08 +0000 Subject: pjd's ZFS 2008-07-27 patches against HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 08:12:48 -0000 Hello everyone, I recently got fed up with all the deadlocks that ZFS seems to have on my home server (things hang in zfs: states, nothing can kill them, prevents rebooting, etc) so I decided to try out -CURRENT with the latest ZFS patches. However, they no longer seem to apply cleanly. Specifically, [steven@universe:/usr/src]% bzcat ~/zfs_20080727.patch.bz2 | sudo patch -s -C -p0 1 out of 14 hunks failed--saving rejects to cddl/contrib/opensolaris/ lib/libzpool/common/sys/zfs_context.h.rej 1 out of 11 hunks failed--saving rejects to sys/cddl/contrib/ opensolaris/uts/common/fs/zfs/vdev_file.c.rej 1 out of 33 hunks failed--saving rejects to sys/cddl/contrib/ opensolaris/uts/common/fs/zfs/zfs_ctldir.c.rej 1 out of 20 hunks failed--saving rejects to sys/cddl/contrib/ opensolaris/uts/common/fs/zfs/zfs_replay.c.rej 1 out of 115 hunks failed--saving rejects to sys/cddl/contrib/ opensolaris/uts/common/fs/zfs/zfs_vnops.c.rej 4 out of 29 hunks failed--saving rejects to sys/cddl/contrib/ opensolaris/uts/common/fs/zfs/zfs_znode.c.rej 1 out of 11 hunks failed--saving rejects to sys/kern/kern_jail.c.rej I was wondering if there is a newer patch out there (I don't see anything in ~pjd/patches) or if anyone has had any luck getting the patch to apply cleanly to the latest HEAD. Thanks, Steven Schlansker From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 09:43:48 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 864AB1065675 for ; Mon, 15 Sep 2008 09:43:48 +0000 (UTC) (envelope-from olli@fromme.com) Received: from haluter.fromme.com (haluter.fromme.com [212.17.241.231]) by mx1.freebsd.org (Postfix) with ESMTP id DABC48FC1D for ; Mon, 15 Sep 2008 09:43:42 +0000 (UTC) (envelope-from olli@fromme.com) Received: from haluter.fromme.com (irc_sucks@localhost [127.0.0.1]) by haluter.fromme.com (8.14.3/8.14.3) with ESMTP id m8F9Mb6W090581; Mon, 15 Sep 2008 11:22:38 +0200 (CEST) (envelope-from olli@fromme.com) Received: (from olli@localhost) by haluter.fromme.com (8.14.3/8.14.3/Submit) id m8F9MaHg090579; Mon, 15 Sep 2008 11:22:36 +0200 (CEST) (envelope-from olli) From: Oliver Fromme Message-Id: <200809150922.m8F9MaHg090579@haluter.fromme.com> To: unixmania@gmail.com (Carlos A. M. dos Santos) Date: Mon, 15 Sep 2008 11:22:36 +0200 (CEST) In-Reply-To: X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (haluter.fromme.com [127.0.0.1]); Mon, 15 Sep 2008 11:22:38 +0200 (CEST) X-Mailman-Approved-At: Mon, 15 Sep 2008 11:22:21 +0000 Cc: Xin LI , FreeBSD Current Subject: Re: Why VESA and DPMS are available only for i386? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 09:43:48 -0000 Carlos A. M. dos Santos wrote: > Xin LI wrote: > > Carlos A. M. dos Santos wrote: > > > Several PRs were closed based on the argument that FreeBSD/amd64 > > > cannot call to the VESA BIOS. XFree86 solved this problem by means of > > > the INT10 module. I believe that it would be possible to do the same > > > on the FreeBSD kernel. > > > > > > Is there any ongoing effort to enable the VESA kernel moule on > > > non-i386 platform? Is there any particular difficulty for doing this, > > > besides depending on VM86? > > > > According to VESA's VBE 3.0 standard, there is a "Protected Mode Entry > > Point" [optionally] provided by BIOS, which OS or application is > > supposed to copy to a place where it is writable. The code there would > > be written in 16-bit protected mode. Therefore I think it's do-able... > > > > http://www.vesa.org/public/VBE/vbe3.pdf > > I'm reading the specification and digging at the code of the X server > and the X VESA driver. Look promising. Don't hold your breath. Peter explained that this is more involved than it seems at first glance: http://lists.freebsd.org/pipermail/freebsd-amd64/2005-October/006376.html Here's a quote: | [FreeBSD's VESA code] is trying to use bios calls to change the | modes. This is something a 64 bit kernel cannot do. To make | this work, one would have to trampoline out of 64 bit mode and | into 32 bit mode, then do the vm86 or bios32() calls. This is | more work than it might appear at first because you have to deal | with interrupts. One would have to write a 32 bit mini-kernel | that can accept interrupts and traps, trampoline to 64 bit mode, | handle them, then return, switching back to 32 bit mode. All | with page tables etc. And of course you have to do extra data | copying and have a way to describe it to the API. By the way, It doesn't matter whether you use the VESA BIOS' real-mode functions or the protected-mode functions (which exist since VBE 2.0, not only 3.0). From the view of an amd64 kernel it doesn't make a difference. Another way would be to write a 32bit x86 instruction emulator (similar to what programs like qemu or bochs do), so you can execute the VESA functions within an emulated virtual machine that programs the VGA hardware registers. This isn't exactly trivial either. Note that there are already such emulators, but I'm not aware of a BSD-licensed one that could be included in the FreeBSD kernel without problems. There's a third way, and I think this is the easiest one. This is what the Linux VESA framebuffer driver does. Let the boot loader (which executes in 32bit mode) switch to the desired video mode, enable a linear frame buffer (which is supported since VBE 2.0) and pass the address of the frame buffer to the 64bit kernel. Then the kernel would not need to call any VESA functions at all, thus eliminating all of the above problems. The drawback is that you can't change the console video mode anymore once the kernel is booted, i.e. you have to reboot if you want a different mode. Best regards Oliver -- Oliver Fromme, Bunsenstr. 13, 81735 Muenchen, Germany ``We are all but compressed light'' (Albert Einstein) From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 13:18:57 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DE1A106564A for ; Mon, 15 Sep 2008 13:18:57 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 0097A8FC0C for ; Mon, 15 Sep 2008 13:18:56 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 962F074418E for ; Mon, 15 Sep 2008 15:49:07 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGZag4tlJNCs for ; Mon, 15 Sep 2008 15:49:07 +0300 (EEST) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [91.198.50.114]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 3F3BD744186 for ; Mon, 15 Sep 2008 15:49:07 +0300 (EEST) Message-ID: <48CE59C2.9060307@icyb.net.ua> Date: Mon, 15 Sep 2008 15:49:06 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.16 (X11/20080805) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: sio => uart: one port is gone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 13:18:57 -0000 This is a fairly standard and old machine with 2 COM ports. Recently (last Friday) I decided to update my RELENG_7 system and also to transition from sio to uart. This what I had before the upgrade: kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 kernel: sio0: type 16550A kernel: sio0: [FILTER] kernel: sio1: <16550A-compatible COM port> port 0x2e8-0x2ef irq 3 on acpi0 kernel: sio1: type 16550A kernel: sio1: [FILTER] This is what I have now: uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: [FILTER] This is what I have in device.hints for uart: hint.uart.0.at="isa" hint.uart.0.port="0x3F8" hint.uart.0.flags="0x10" hint.uart.0.irq="4" hint.uart.1.at="isa" hint.uart.1.port="0x2F8" hint.uart.1.irq="3" hint.uart.2.at="isa" Precisely the same hints (s/uart/sio/) I had for sio. Please advise. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 14:05:19 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 771E11065673 for ; Mon, 15 Sep 2008 14:05:19 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 239938FC14 for ; Mon, 15 Sep 2008 14:05:18 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m8FE5Cal053606; Mon, 15 Sep 2008 10:05:12 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m8FE5CbH031586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Sep 2008 10:05:12 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200809151405.m8FE5CbH031586@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 15 Sep 2008 10:05:19 -0400 To: Andriy Gapon , freebsd-current@freebsd.org From: Mike Tancsa In-Reply-To: <48CE59C2.9060307@icyb.net.ua> References: <48CE59C2.9060307@icyb.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: Re: sio => uart: one port is gone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 14:05:19 -0000 At 08:49 AM 9/15/2008, Andriy Gapon wrote: >kernel: sio1: <16550A-compatible COM port> port 0x2e8-0x2ef irq 3 on acpi0 >hint.uart.1.port="0x2F8" Hi, What if you change it to hint.uart.1.port="0x2E8" ? ---Mike From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 14:15:53 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 669DE1065672 for ; Mon, 15 Sep 2008 14:15:53 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 3BF378FC08 for ; Mon, 15 Sep 2008 14:15:52 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id AE7DE1632B6 for ; Mon, 15 Sep 2008 10:00:32 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Mon, 15 Sep 2008 10:00:32 -0400 X-Sasl-enc: VMfrHceJccHyNVRVwkY2oBEy17PK4A+urTNEhoub9cvc 1221487232 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 2D53113043 for ; Mon, 15 Sep 2008 10:00:32 -0400 (EDT) Message-ID: <48CE6A7E.8010306@incunabulum.net> Date: Mon, 15 Sep 2008 15:00:30 +0100 From: Bruce M Simpson User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: FreeBSD Current X-Enigmail-Version: 0.95.6 Content-Type: multipart/mixed; boundary="------------070109030907050207000703" Subject: [PATCH] Fix get max luns delay for QEMU USB disks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 14:15:53 -0000 This is a multi-part message in MIME format. --------------070109030907050207000703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, QEMU will allow you to emulate umass devices using files. However it does so with a VID/PID of 0, and does not support "get max lun" which causes a brief hang on boot. This patch is against RELENG_7 but you get the general idea. Any objections? BMS --------------070109030907050207000703 Content-Type: text/plain; name="qemu-umass.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="qemu-umass.diff" --- umass.c.orig 2008-09-15 14:35:10.000000000 +0100 +++ umass.c 2008-09-15 14:34:18.000000000 +0100 @@ -822,6 +822,10 @@ UMASS_PROTO_SCSI | UMASS_PROTO_BBB, NO_QUIRKS }, + { USB_VENDOR_UNKNOWN0, USB_PRODUCT_UNKNOWN0_UNKNOWN0, RID_WILDCARD, + UMASS_PROTO_SCSI | UMASS_PROTO_BBB, + NO_GETMAXLUN + }, { USB_VENDOR_VIA, USB_PRODUCT_VIA_USB2IDEBRIDGE, RID_WILDCARD, UMASS_PROTO_SCSI | UMASS_PROTO_BBB, NO_SYNCHRONIZE_CACHE --- usbdevs.orig 2008-09-15 14:31:04.000000000 +0100 +++ usbdevs 2008-09-15 14:32:09.000000000 +0100 @@ -62,6 +62,7 @@ * make the device recognised by the appropriate device driver. */ +vendor UNKNOWN0 0x0000 Unknown vendor vendor UNKNOWN1 0x0053 Unknown vendor vendor UNKNOWN2 0x0105 Unknown vendor vendor EGALAX2 0x0123 eGalax, Inc. @@ -2291,6 +2292,9 @@ /* VIA Technologies products */ product VIA USB2IDEBRIDGE 0x6204 USB 2.0 IDE Bridge +/* Unknown vendor: QEMU typically presents zeroed VID/PID for disk images */ +product UNKNOWN0 UNKNOWN0 0x0000 Unknown device + /* USI products */ product USI MC60 0x10c5 MC60 Serial --------------070109030907050207000703-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 14:27:39 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 572FC106567D for ; Mon, 15 Sep 2008 14:27:39 +0000 (UTC) (envelope-from hpcharles@gmail.com) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.190]) by mx1.freebsd.org (Postfix) with ESMTP id 0D6708FC1D for ; Mon, 15 Sep 2008 14:27:38 +0000 (UTC) (envelope-from hpcharles@gmail.com) Received: by rn-out-0910.google.com with SMTP id j71so1194030rne.12 for ; Mon, 15 Sep 2008 07:27:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=DfTYXG4V3V2nPy9b8T22annzRWwbxqUBQ6iv6kHPXTg=; b=PkwNeJAjizeCGEOmdaLyM8SW4zW4p/9d59j9lRTnLJN/wgxJMd2rjfTob3RRymyMr5 KpmRd6yoepqUV988xotBB3EJZ1g6hVdK28UpUxN5CKtLsHkR0c5AytZx0XGidovO1MiV Sxwsgry+agIsEi6d9+Gem2DMUdmEteF2jw/w4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=D0Sd5FLCRgxxxyclC9IZFvuY3SeEyeWqZVhpYRkrd8yMCYdeEUxC/So4FrL1Kvu1jL 5mZIYaWnCHuZdolzoerB6n2lnc/R87phXiuyEoozjg9Q14GpOAIeLpidE3ePb1D0XM5k dAP/BPD0fOB6/7EKJuuq57+JUm5HKnts0A8AQ= Received: by 10.143.1.12 with SMTP id d12mr2686638wfi.297.1221487143930; Mon, 15 Sep 2008 06:59:03 -0700 (PDT) Received: by 10.142.203.16 with HTTP; Mon, 15 Sep 2008 06:59:03 -0700 (PDT) Message-ID: <4734a3ed0809150659n438a5b20r59278908f4032a45@mail.gmail.com> Date: Mon, 15 Sep 2008 15:59:03 +0200 From: "Henri-Pierre Charles" To: "Rui Paulo" In-Reply-To: <20080828002919.GA54169@alpha.local> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080828002919.GA54169@alpha.local> Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: HEADS UP: ath_hal updated to 0.10.5.10 -- PLEASE TEST X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hpcharles@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 14:27:39 -0000 Hi, On Thu, Aug 28, 2008 at 2:29 AM, Rui Paulo wrote: > We've updated ath_hal in HEAD to 0.10.5.10. This supports a couple of > new chips, namely those on the Asus Eee PC, MacBooks and other laptops. It's included into 8.0-CURRENT-200809-i386 snapshot if I understand correctly. > If you have an Atheros or Atheros based card, I really wanted you to > test it. We were unable to test this in several Atheros chipsets, so > if you find a regression, please contact me or Sam Leffler > (sam@freebsd.org) ASAP. I've tried 7.1-BETA and 8.0-CURRENT-200809 on my eeepc model 701 7.1 does not recognize ath0, as expected, but 8.0-CURRENT does. The corresponding dmesg can be found here : * http://www.prism.uvsq.fr/~hpc/pmwiki/uploads/Data/dmesg-7.1-BETA.txt * http://www.prism.uvsq.fr/~hpc/pmwiki/uploads/Data/dmesg-8.0-200809.txt The 8.0-CURRENT-200809-i386 contain ath_hal 0.10.5.10 but I was unable to use the interface. "dhclient ath0" never give up. Let me know if I can try something. In the past I had success with 7.0 code base + madwifi-ng-r2756+ar5007.hal I was able to use ath with dhclient and wpa_supplicant. And what about the rj45 interface for eee 701 ? Any chance to be supported in a near future ? -- HPC From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 15:33:06 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AEEF1065671 for ; Mon, 15 Sep 2008 15:33:06 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id D31438FC23 for ; Mon, 15 Sep 2008 15:33:05 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id DC79E74419A; Mon, 15 Sep 2008 18:33:03 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjM7vn2RPlc6; Mon, 15 Sep 2008 18:33:03 +0300 (EEST) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [91.198.50.114]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 7C9C8744173; Mon, 15 Sep 2008 18:33:03 +0300 (EEST) Message-ID: <48CE802E.7070607@icyb.net.ua> Date: Mon, 15 Sep 2008 18:33:02 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.16 (X11/20080805) MIME-Version: 1.0 To: Mike Tancsa References: <48CE59C2.9060307@icyb.net.ua> <200809151405.m8FE5CbH031586@lava.sentex.ca> In-Reply-To: <200809151405.m8FE5CbH031586@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: sio => uart: one port is gone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 15:33:06 -0000 on 15/09/2008 17:05 Mike Tancsa said the following: > At 08:49 AM 9/15/2008, Andriy Gapon wrote: >> kernel: sio1: <16550A-compatible COM port> port 0x2e8-0x2ef irq 3 on >> acpi0 >> hint.uart.1.port="0x2F8" > > Hi, > What if you change it to hint.uart.1.port="0x2E8" ? Good catch, thank you! I'll try and report back. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 15:59:11 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E1E61065670 for ; Mon, 15 Sep 2008 15:59:11 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout020.mac.com (asmtpout020.mac.com [17.148.16.95]) by mx1.freebsd.org (Postfix) with ESMTP id 8D9FB8FC1B for ; Mon, 15 Sep 2008 15:59:06 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from vghiya-t60.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp020.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0K7800374V1WB040@asmtp020.mac.com> for freebsd-current@freebsd.org; Mon, 15 Sep 2008 08:58:45 -0700 (PDT) Message-id: From: Marcel Moolenaar To: Andriy Gapon In-reply-to: <48CE59C2.9060307@icyb.net.ua> Date: Mon, 15 Sep 2008 08:58:43 -0700 References: <48CE59C2.9060307@icyb.net.ua> X-Mailer: Apple Mail (2.928.1) Cc: freebsd-current@freebsd.org Subject: Re: sio => uart: one port is gone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 15:59:11 -0000 On Sep 15, 2008, at 5:49 AM, Andriy Gapon wrote: > > This is a fairly standard and old machine with 2 COM ports. > Recently (last Friday) I decided to update my RELENG_7 system and > also to transition from sio to uart. > > This what I had before the upgrade: > kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 > flags 0x10 on acpi0 > kernel: sio0: type 16550A > kernel: sio0: [FILTER] > kernel: sio1: <16550A-compatible COM port> port 0x2e8-0x2ef irq 3 on > acpi0 > kernel: sio1: type 16550A > kernel: sio1: [FILTER] > > This is what I have now: > uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on > isa0 > uart0: [FILTER] > > This is what I have in device.hints for uart: > hint.uart.0.at="isa" > hint.uart.0.port="0x3F8" > hint.uart.0.flags="0x10" > hint.uart.0.irq="4" > hint.uart.1.at="isa" > hint.uart.1.port="0x2F8" > hint.uart.1.irq="3" > hint.uart.2.at="isa" > > Precisely the same hints (s/uart/sio/) I had for sio. The hints are bogus. As you can see, sio(4) attached to acpi(4), whereas uart(4) attaches to isa(4). Don't compile ACPI as a kernel module and all is fine. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 16:03:22 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 887EE106564A for ; Mon, 15 Sep 2008 16:03:22 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4285D8FC15 for ; Mon, 15 Sep 2008 16:03:21 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KfGXm-0007ib-O0 for freebsd-current@freebsd.org; Mon, 15 Sep 2008 16:03:18 +0000 Received: from mulderlab.f5.com ([205.229.151.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Sep 2008 16:03:18 +0000 Received: from atkin901 by mulderlab.f5.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Sep 2008 16:03:18 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Mark Atkinson Date: Mon, 15 Sep 2008 09:03:11 -0700 Lines: 22 Message-ID: References: <200809111135.26480.jhb@freebsd.org> <20080913005622.GA1919@lorvorc.mips.inka.de> <200809131109.54790.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mulderlab.f5.com User-Agent: KNode/0.10.9 Sender: news Subject: Re: No root filesystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 16:03:22 -0000 John Baldwin wrote: > On Friday 12 September 2008 08:56:22 pm Christian Weisgerber wrote: >> John Baldwin: >> > Try an updated http://www.FreeBSD.org/~jhb/patches/pcie.patch. This is >> > another debugging patch. >> >> No change. The panic() call in that patch does not trigger for me, >> the machine just boots through until it can't find a root device. > > Gah, ok. I have no idea why MCFG is breaking for you then. You can use > the tunable (hw.pci.mcfg=0) to turn it off though. > Thanks for putting this tunable in. With it set to 0, I'm finally able to boot the tyan 2895 and have it probe/attach all the devices on todays kernel. -- Mark Atkinson atkin901@yahoo.com (!wired)?(coffee++):(wired); From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 16:28:43 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28BEC1065673 for ; Mon, 15 Sep 2008 16:28:43 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id D02688FC1A for ; Mon, 15 Sep 2008 16:28:42 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id E8558744188; Mon, 15 Sep 2008 19:28:30 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUTbJ9-O+8IB; Mon, 15 Sep 2008 19:28:30 +0300 (EEST) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [91.198.50.114]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 93B7874415D; Mon, 15 Sep 2008 19:28:30 +0300 (EEST) Message-ID: <48CE8D2D.4020400@icyb.net.ua> Date: Mon, 15 Sep 2008 19:28:29 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.16 (X11/20080805) MIME-Version: 1.0 To: Marcel Moolenaar References: <48CE59C2.9060307@icyb.net.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: sio => uart: one port is gone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 16:28:43 -0000 on 15/09/2008 18:58 Marcel Moolenaar said the following: > > On Sep 15, 2008, at 5:49 AM, Andriy Gapon wrote: > >> >> This is a fairly standard and old machine with 2 COM ports. >> Recently (last Friday) I decided to update my RELENG_7 system and also >> to transition from sio to uart. >> >> This what I had before the upgrade: >> kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 >> flags 0x10 on acpi0 >> kernel: sio0: type 16550A >> kernel: sio0: [FILTER] >> kernel: sio1: <16550A-compatible COM port> port 0x2e8-0x2ef irq 3 on >> acpi0 >> kernel: sio1: type 16550A >> kernel: sio1: [FILTER] >> >> This is what I have now: >> uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 >> uart0: [FILTER] >> >> This is what I have in device.hints for uart: >> hint.uart.0.at="isa" >> hint.uart.0.port="0x3F8" >> hint.uart.0.flags="0x10" >> hint.uart.0.irq="4" >> hint.uart.1.at="isa" >> hint.uart.1.port="0x2F8" >> hint.uart.1.irq="3" >> hint.uart.2.at="isa" >> >> Precisely the same hints (s/uart/sio/) I had for sio. > > The hints are bogus. As you can see, sio(4) attached to acpi(4), > whereas uart(4) attaches to isa(4). Yes and yes. > Don't compile ACPI as a kernel module and all is fine. What is the alternative? Building it into a kernel? Is this maybe too much of a requirement? From /sys/i386/conf/NOTES (RELENG_7): # Note that building ACPI into the kernel is deprecated; the module is # normally loaded automatically by the loader. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 16:41:33 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BF98106566B for ; Mon, 15 Sep 2008 16:41:33 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout015.mac.com (asmtpout015.mac.com [17.148.16.90]) by mx1.freebsd.org (Postfix) with ESMTP id 79AD38FC1C for ; Mon, 15 Sep 2008 16:41:33 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from vghiya-t60.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp015.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0K7800F79X181540@asmtp015.mac.com> for freebsd-current@freebsd.org; Mon, 15 Sep 2008 09:41:33 -0700 (PDT) Message-id: From: Marcel Moolenaar To: Andriy Gapon In-reply-to: <48CE8D2D.4020400@icyb.net.ua> Date: Mon, 15 Sep 2008 09:41:32 -0700 References: <48CE59C2.9060307@icyb.net.ua> <48CE8D2D.4020400@icyb.net.ua> X-Mailer: Apple Mail (2.928.1) Cc: freebsd-current@freebsd.org Subject: Re: sio => uart: one port is gone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 16:41:33 -0000 On Sep 15, 2008, at 9:28 AM, Andriy Gapon wrote: > on 15/09/2008 18:58 Marcel Moolenaar said the following: >> On Sep 15, 2008, at 5:49 AM, Andriy Gapon wrote: >>> >>> This is a fairly standard and old machine with 2 COM ports. >>> Recently (last Friday) I decided to update my RELENG_7 system and >>> also to transition from sio to uart. >>> >>> This what I had before the upgrade: >>> kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 >>> flags 0x10 on acpi0 >>> kernel: sio0: type 16550A >>> kernel: sio0: [FILTER] >>> kernel: sio1: <16550A-compatible COM port> port 0x2e8-0x2ef irq 3 >>> on acpi0 >>> kernel: sio1: type 16550A >>> kernel: sio1: [FILTER] >>> >>> This is what I have now: >>> uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 >>> on isa0 >>> uart0: [FILTER] >>> >>> This is what I have in device.hints for uart: >>> hint.uart.0.at="isa" >>> hint.uart.0.port="0x3F8" >>> hint.uart.0.flags="0x10" >>> hint.uart.0.irq="4" >>> hint.uart.1.at="isa" >>> hint.uart.1.port="0x2F8" >>> hint.uart.1.irq="3" >>> hint.uart.2.at="isa" >>> >>> Precisely the same hints (s/uart/sio/) I had for sio. >> The hints are bogus. As you can see, sio(4) attached to acpi(4), >> whereas uart(4) attaches to isa(4). > > Yes and yes. > >> Don't compile ACPI as a kernel module and all is fine. > > What is the alternative? > Building it into a kernel? Yes. > Is this maybe too much of a requirement? It's how our modules work. You can safely compile leaf drivers as modules (leaf drivers are drivers that have no other drivers depending on it), but we don't deal well with non-leaf drivers. acpi(4) is a non-leaf driver, with sio(4) and uart(4) depending on it. If you compile acpi(4) as a module, you should do the same for sio(4), uart(4), etc. We don't enforce that, which is the problem. sio(4) added a kluge to work around the design/implementation flaw, whereas uart(4) does not. The reason uart(4) does not is that you don't want to compile-in code that you don't need. It bloats the kernel and we need to keep our embedded platforms in mind. So, if you compile acpi(4) as a module, you must compile all it's depending drivers as modules as well. Or you compile acpi into the kernel... > From /sys/i386/conf/NOTES (RELENG_7): > # Note that building ACPI into the kernel is deprecated; the module is > # normally loaded automatically by the loader. Just another bogus note. Compiling ACPI into the kernel is not deprecated, because it's required for at least ia64 and I think for amd64 as well. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 16:47:43 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2A0D1065676 for ; Mon, 15 Sep 2008 16:47:43 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 854698FC18 for ; Mon, 15 Sep 2008 16:47:43 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id EC3B574419B; Mon, 15 Sep 2008 19:47:41 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEdK6Cch1-fK; Mon, 15 Sep 2008 19:47:41 +0300 (EEST) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [91.198.50.114]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 8B8FD74415D; Mon, 15 Sep 2008 19:47:41 +0300 (EEST) Message-ID: <48CE91AB.3000200@icyb.net.ua> Date: Mon, 15 Sep 2008 19:47:39 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.16 (X11/20080805) MIME-Version: 1.0 To: Marcel Moolenaar References: <48CE59C2.9060307@icyb.net.ua> <48CE8D2D.4020400@icyb.net.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: sio => uart: one port is gone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 16:47:43 -0000 on 15/09/2008 19:41 Marcel Moolenaar said the following: > > So, if you compile acpi(4) as a module, you must compile all > it's depending drivers as modules as well. Or you compile acpi > into the kernel... I understand the logic, but OTOH uart can work without acpi too, so it's not a strict dependency. Also, this (acpi dependency) doesn't seem to be documented. Anyway, I understand the issue now, thank you! >> From /sys/i386/conf/NOTES (RELENG_7): >> # Note that building ACPI into the kernel is deprecated; the module is >> # normally loaded automatically by the loader. > > Just another bogus note. Compiling ACPI into the kernel is > not deprecated, because it's required for at least ia64 and > I think for amd64 as well. Just a remark: such a note doesn't appear in amd64 NOTES, only in i386. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 16:51:30 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D39D1065672 for ; Mon, 15 Sep 2008 16:51:30 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id A60508FC1E for ; Mon, 15 Sep 2008 16:51:29 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id m8FGWiU2047738; Mon, 15 Sep 2008 12:32:44 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Mon, 15 Sep 2008 12:32:34 -0400 User-Agent: KMail/1.6.2 References: <200809150922.m8F9MaHg090579@haluter.fromme.com> In-Reply-To: <200809150922.m8F9MaHg090579@haluter.fromme.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200809151232.36756.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.92/8248/Mon Sep 15 11:28:54 2008 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: "Carlos A. M. dos Santos" , Xin LI , Oliver Fromme Subject: Re: Why VESA and DPMS are available only for i386? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 16:51:30 -0000 On Monday 15 September 2008 05:22 am, Oliver Fromme wrote: > Carlos A. M. dos Santos wrote: > > Xin LI wrote: > > > Carlos A. M. dos Santos wrote: > > > > Several PRs were closed based on the argument that > > > > FreeBSD/amd64 cannot call to the VESA BIOS. XFree86 solved > > > > this problem by means of the INT10 module. I believe that it > > > > would be possible to do the same on the FreeBSD kernel. > > > > > > > > Is there any ongoing effort to enable the VESA kernel moule > > > > on non-i386 platform? Is there any particular difficulty for > > > > doing this, besides depending on VM86? > > > > > > According to VESA's VBE 3.0 standard, there is a "Protected > > > Mode Entry Point" [optionally] provided by BIOS, which OS or > > > application is supposed to copy to a place where it is > > > writable. The code there would be written in 16-bit protected > > > mode. Therefore I think it's do-able... > > > > > > http://www.vesa.org/public/VBE/vbe3.pdf > > > > I'm reading the specification and digging at the code of the X > > server and the X VESA driver. Look promising. > > Don't hold your breath. Peter explained that this is more > involved than it seems at first glance: > > http://lists.freebsd.org/pipermail/freebsd-amd64/2005-October/00637 >6.html > > Here's a quote: > | [FreeBSD's VESA code] is trying to use bios calls to change > | the modes. This is something a 64 bit kernel cannot do. To > | make this work, one would have to trampoline out of 64 bit mode > | and into 32 bit mode, then do the vm86 or bios32() calls. This > | is more work than it might appear at first because you have to > | deal with interrupts. One would have to write a 32 bit > | mini-kernel that can accept interrupts and traps, trampoline to > | 64 bit mode, handle them, then return, switching back to 32 bit > | mode. All with page tables etc. And of course you have to do > | extra data copying and have a way to describe it to the API. > > By the way, It doesn't matter whether you use the VESA > BIOS' real-mode functions or the protected-mode functions > (which exist since VBE 2.0, not only 3.0). From the view > of an amd64 kernel it doesn't make a difference. > > Another way would be to write a 32bit x86 instruction > emulator (similar to what programs like qemu or bochs do), > so you can execute the VESA functions within an emulated > virtual machine that programs the VGA hardware registers. > This isn't exactly trivial either. Note that there are > already such emulators, but I'm not aware of a BSD-licensed > one that could be included in the FreeBSD kernel without > problems. doscmd(1) had a rudimentary 16-bit CPU emulation: http://www.freebsd.org/cgi/cvsweb.cgi/projects/doscmd/ http://www.freebsd.org/cgi/cvsweb.cgi/projects/doscmd/cpu.c Jung-uk Kim > There's a third way, and I think this is the easiest one. > This is what the Linux VESA framebuffer driver does. > Let the boot loader (which executes in 32bit mode) switch > to the desired video mode, enable a linear frame buffer > (which is supported since VBE 2.0) and pass the address > of the frame buffer to the 64bit kernel. Then the kernel > would not need to call any VESA functions at all, thus > eliminating all of the above problems. The drawback is > that you can't change the console video mode anymore once > the kernel is booted, i.e. you have to reboot if you want > a different mode. > > Best regards > Oliver From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 16:55:48 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED2931065676 for ; Mon, 15 Sep 2008 16:55:48 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout020.mac.com (asmtpout020.mac.com [17.148.16.95]) by mx1.freebsd.org (Postfix) with ESMTP id D9C258FC12 for ; Mon, 15 Sep 2008 16:55:48 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from vghiya-t60.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp020.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0K780053EXOL1920@asmtp020.mac.com> for freebsd-current@freebsd.org; Mon, 15 Sep 2008 09:55:34 -0700 (PDT) Message-id: <9D0F7169-9461-4F32-9420-702BED840A20@mac.com> From: Marcel Moolenaar To: Andriy Gapon In-reply-to: <48CE91AB.3000200@icyb.net.ua> Date: Mon, 15 Sep 2008 09:55:33 -0700 References: <48CE59C2.9060307@icyb.net.ua> <48CE8D2D.4020400@icyb.net.ua> <48CE91AB.3000200@icyb.net.ua> X-Mailer: Apple Mail (2.928.1) Cc: freebsd-current@freebsd.org Subject: Re: sio => uart: one port is gone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 16:55:49 -0000 On Sep 15, 2008, at 9:47 AM, Andriy Gapon wrote: > on 15/09/2008 19:41 Marcel Moolenaar said the following: >> So, if you compile acpi(4) as a module, you must compile all >> it's depending drivers as modules as well. Or you compile acpi >> into the kernel... > > I understand the logic, but OTOH uart can work without acpi too, so > it's not a strict dependency. Well, yes. That's what's causing your "problem". You compile a kernel without acpi but with uart. As such, uart will be built without acpi support. uart does indeed work without acpi. The problem is that people then load the acpi module at runtime and expect uart to work with acpi. That's not going to fly. If one builds uart as a module, all possible support is included and it works as expected. > Also, this (acpi dependency) doesn't seem to be documented. It's standard behaviour. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 17:15:37 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E72E106564A for ; Mon, 15 Sep 2008 17:15:37 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.179]) by mx1.freebsd.org (Postfix) with ESMTP id D961B8FC12 for ; Mon, 15 Sep 2008 17:15:36 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: by el-out-1112.google.com with SMTP id v27so887478ele.13 for ; Mon, 15 Sep 2008 10:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=IpjIXPhy5VYrTZnhWlchnTYi3eEcTjJFBPlPQ7aaATA=; b=aRbR/S6VW175lhgf+PDfEaR5CadVo8RWcODyeF9IsSEqkax+5p7w+AeyCFFJhn9Fco F1Tef5JWb6mJoPi7ftRZPETEWivqA5wGb83Zo9cTPyUkZg34CBHnmdDbvkH2SePPSOJK TCcHWMSb7yr8VcTqsvspHtj7KWx4W6ktf21NI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=BpdCTiyItaZkQpxmh3WYboBgbpWt5gYeDXHRpUcR+ur/uP5pBHA6wozhVb3IsftNV7 2j3BKG+w3Ips75jwY5Ia6HQ7brpyWm6GUpdaWqnKDHwgu61YNRr0tvrjdnjMJ3J/mSqc SkZirA6pvDGzAyUdoDocZTpFG9+lVMWO7uXIk= Received: by 10.103.179.17 with SMTP id g17mr1263689mup.31.1221498934577; Mon, 15 Sep 2008 10:15:34 -0700 (PDT) Received: by 10.103.231.14 with HTTP; Mon, 15 Sep 2008 10:15:34 -0700 (PDT) Message-ID: Date: Mon, 15 Sep 2008 14:15:34 -0300 From: "Carlos A. M. dos Santos" To: "Oliver Fromme" In-Reply-To: <200809150922.m8F9MaHg090579@haluter.fromme.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200809150922.m8F9MaHg090579@haluter.fromme.com> Cc: Xin LI , FreeBSD Current Subject: Re: Why VESA and DPMS are available only for i386? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 17:15:37 -0000 On Mon, Sep 15, 2008 at 6:22 AM, Oliver Fromme wrote: > > Carlos A. M. dos Santos wrote: > > Xin LI wrote: > > > Carlos A. M. dos Santos wrote: > > > > Several PRs were closed based on the argument that FreeBSD/amd64 > > > > cannot call to the VESA BIOS. XFree86 solved this problem by means of > > > > the INT10 module. I believe that it would be possible to do the same > > > > on the FreeBSD kernel. > > > > > > > > Is there any ongoing effort to enable the VESA kernel moule on > > > > non-i386 platform? Is there any particular difficulty for doing this, > > > > besides depending on VM86? > > > > > > According to VESA's VBE 3.0 standard, there is a "Protected Mode Entry > > > Point" [optionally] provided by BIOS, which OS or application is > > > supposed to copy to a place where it is writable. The code there would > > > be written in 16-bit protected mode. Therefore I think it's do-able... > > > > > > http://www.vesa.org/public/VBE/vbe3.pdf > > > > I'm reading the specification and digging at the code of the X server > > and the X VESA driver. Look promising. > > Don't hold your breath. Peter explained that this is more > involved than it seems at first glance: > > http://lists.freebsd.org/pipermail/freebsd-amd64/2005-October/006376.html > > Here's a quote: > > | [FreeBSD's VESA code] is trying to use bios calls to change the > | modes. This is something a 64 bit kernel cannot do. To make > | this work, one would have to trampoline out of 64 bit mode and > | into 32 bit mode, then do the vm86 or bios32() calls. This is > | more work than it might appear at first because you have to deal > | with interrupts. One would have to write a 32 bit mini-kernel > | that can accept interrupts and traps, trampoline to 64 bit mode, > | handle them, then return, switching back to 32 bit mode. All > | with page tables etc. And of course you have to do extra data > | copying and have a way to describe it to the API. > > By the way, It doesn't matter whether you use the VESA > BIOS' real-mode functions or the protected-mode functions > (which exist since VBE 2.0, not only 3.0). From the view > of an amd64 kernel it doesn't make a difference. Yeah, I came to the same conclusion when I saw, in pg. 24 of VBE 3.0 spac, that "protected mode entry point will put the CPU in 16-bit protected mode". Using this would require two trampolines (64->32 and 32-16) but the second one jumps out of the pool. :-( > Another way would be to write a 32bit x86 instruction > emulator (similar to what programs like qemu or bochs do), > so you can execute the VESA functions within an emulated > virtual machine that programs the VGA hardware registers. > This isn't exactly trivial either. Note that there are > already such emulators, but I'm not aware of a BSD-licensed > one that could be included in the FreeBSD kernel without > problems. This is done by the X server, by means of libint10. The x86 emulator is x86emu, which was donated by SciTech Software, Inc. and is available under a BSD-friendly license. This is what I had in mind when I sent the first message. > There's a third way, and I think this is the easiest one. > This is what the Linux VESA framebuffer driver does. > Let the boot loader (which executes in 32bit mode) switch > to the desired video mode, enable a linear frame buffer > (which is supported since VBE 2.0) and pass the address > of the frame buffer to the 64bit kernel. Then the kernel > would not need to call any VESA functions at all, thus > eliminating all of the above problems. The drawback is > that you can't change the console video mode anymore once > the kernel is booted, i.e. you have to reboot if you want > a different mode. This can also lead to a situation where the kernel can not restore the video controller to a known mode if the X server crashes or when the user attempts to switch from X to the "text mode" console. For instance, Linux has this problem when using the nVIDIA binary driver. -- cd /usr/ports/sysutils/life make clean From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 17:23:43 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0BFE106566B for ; Mon, 15 Sep 2008 17:23:43 +0000 (UTC) (envelope-from stevenschlansker@berkeley.edu) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by mx1.freebsd.org (Postfix) with ESMTP id 8978F8FC12 for ; Mon, 15 Sep 2008 17:23:38 +0000 (UTC) (envelope-from stevenschlansker@berkeley.edu) Received: from emu.stevenschlansker.is-a-geek.org (66-117-142-212.lmi.net [66.117.142.212]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id m8FHNPfn013656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Sep 2008 10:23:26 -0700 (PDT) Message-Id: From: Steven Schlansker To: Benjamin Close In-Reply-To: <48CE72BB.1050505@clearchain.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 15 Sep 2008 10:23:20 -0700 References: <3A22C890-8724-4A41-8E67-2F6A8D4D7E3C@berkeley.edu> <48CE72BB.1050505@clearchain.com> X-Mailer: Apple Mail (2.926) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: pjd's ZFS 2008-07-27 patches against HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 17:23:43 -0000 I have heard very dire warnings about disabling the ZIL, especially when using NFS (as I am) http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide#ZIL So unless this doesn't affect FreeBSD, I'm not inclined to disable the ZIL. I'll try disabling prefetch, though. Thanks for the idea. I'm still interested in trying out the patches, though, if anyone has gotten them to work recently... On Sep 15, 2008, at 7:35 AM, Benjamin Close wrote: > Hi Steven, > Try adding the following to /boot/loader.conf - fixes the > deadlocks > for me on 7.0 > > # ZFS deadlock fixes > vfs.zfs.prefetch_disable="1" > vfs.zfs.zil_disable="1" > > Cheers, > Benjamin > > Steven Schlansker wrote: >> Hello everyone, >> >> First, a thank you to pjd and the other contributers for all their >> work getting ZFS to work. It's a really awesome feature, and I've >> gotten good use of it already :) >> >> I recently got fed up with all the deadlocks that ZFS seems to have >> on >> my home server (things hang in zfs: states, nothing can kill them, >> prevents rebooting, etc) so I decided to try out -CURRENT with the >> latest ZFS patches. However, they no longer seem to apply cleanly. >> Specifically, >> >> [steven@universe:/usr/src]% bzcat ~/zfs_20080727.patch.bz2 | sudo >> patch -s -C -p0 >> 1 out of 14 hunks failed--saving rejects to >> cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h.rej >> 1 out of 11 hunks failed--saving rejects to >> sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_file.c.rej >> 1 out of 33 hunks failed--saving rejects to >> sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c.rej >> 1 out of 20 hunks failed--saving rejects to >> sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_replay.c.rej >> 1 out of 115 hunks failed--saving rejects to >> sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c.rej >> 4 out of 29 hunks failed--saving rejects to >> sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c.rej >> 1 out of 11 hunks failed--saving rejects to sys/kern/kern_jail.c.rej >> >> This is against a current HEAD (tag=. in csup as of 2 hours ago) >> >> I was wondering if there is a newer patch out there (I don't see >> anything in ~pjd/patches) or if anyone has had any luck getting the >> patch to apply cleanly to the latest sources. >> >> Thanks, >> Steven Schlansker >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 17:47:04 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 721D8106564A for ; Mon, 15 Sep 2008 17:47:04 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: from mail-gx0-f17.google.com (mail-gx0-f17.google.com [209.85.217.17]) by mx1.freebsd.org (Postfix) with ESMTP id 138998FC0A for ; Mon, 15 Sep 2008 17:47:03 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: by gxk10 with SMTP id 10so23969273gxk.19 for ; Mon, 15 Sep 2008 10:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=LERLyM+s+goE5k3uhQr5ZyBjZ4wEOayAri3Ig5Sldt4=; b=D4I7aaZpVnH3LG1F3Ts1Yurg4ySHI78fcOMISIARQu4WDD/vMX720W20sop2jpKpNo 5keWrN8VvOTdXzBIst9s5cHNSMt52346cQI1p5r1zkwePwJY5gxVT60dEZIqlH/jK3/k eiHLGgRpOQJPXbugjr917YowCAZN2b623jb9k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=EkidV91lGXfYuJiZqzVHIG83ZCT5MASC/a32OM5k3MqZRIeMPibZKij8QY1bpVvc9j us42lZKysKIs77XfHwCdID9n7yyotJsm93dWFrAvt5xlWAJODXW2aJQ4ETEPB70g9w0P 4tjaKcrBDhWSez+l6fFHtU3CqBW6lqvtrecAc= Received: by 10.103.200.9 with SMTP id c9mr5709828muq.11.1221499450581; Mon, 15 Sep 2008 10:24:10 -0700 (PDT) Received: by 10.103.231.14 with HTTP; Mon, 15 Sep 2008 10:24:10 -0700 (PDT) Message-ID: Date: Mon, 15 Sep 2008 14:24:10 -0300 From: "Carlos A. M. dos Santos" To: "Jung-uk Kim" In-Reply-To: <200809151232.36756.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200809150922.m8F9MaHg090579@haluter.fromme.com> <200809151232.36756.jkim@FreeBSD.org> Cc: Xin LI , freebsd-current@freebsd.org, Oliver Fromme Subject: Re: Why VESA and DPMS are available only for i386? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 17:47:04 -0000 On Mon, Sep 15, 2008 at 1:32 PM, Jung-uk Kim wrote: > On Monday 15 September 2008 05:22 am, Oliver Fromme wrote: >> Carlos A. M. dos Santos wrote: >> > Xin LI wrote: >> > > Carlos A. M. dos Santos wrote: >> > > > Several PRs were closed based on the argument that >> > > > FreeBSD/amd64 cannot call to the VESA BIOS. XFree86 solved >> > > > this problem by means of the INT10 module. I believe that it >> > > > would be possible to do the same on the FreeBSD kernel. >> > > > >> > > > Is there any ongoing effort to enable the VESA kernel moule >> > > > on non-i386 platform? Is there any particular difficulty for >> > > > doing this, besides depending on VM86? >> > > >> > > According to VESA's VBE 3.0 standard, there is a "Protected >> > > Mode Entry Point" [optionally] provided by BIOS, which OS or >> > > application is supposed to copy to a place where it is >> > > writable. The code there would be written in 16-bit protected >> > > mode. Therefore I think it's do-able... >> > > >> > > http://www.vesa.org/public/VBE/vbe3.pdf >> > >> > I'm reading the specification and digging at the code of the X >> > server and the X VESA driver. Look promising. >> >> Don't hold your breath. Peter explained that this is more >> involved than it seems at first glance: >> >> http://lists.freebsd.org/pipermail/freebsd-amd64/2005-October/00637 >>6.html >> >> Here's a quote: >> | [FreeBSD's VESA code] is trying to use bios calls to change >> | the modes. This is something a 64 bit kernel cannot do. To >> | make this work, one would have to trampoline out of 64 bit mode >> | and into 32 bit mode, then do the vm86 or bios32() calls. This >> | is more work than it might appear at first because you have to >> | deal with interrupts. One would have to write a 32 bit >> | mini-kernel that can accept interrupts and traps, trampoline to >> | 64 bit mode, handle them, then return, switching back to 32 bit >> | mode. All with page tables etc. And of course you have to do >> | extra data copying and have a way to describe it to the API. >> >> By the way, It doesn't matter whether you use the VESA >> BIOS' real-mode functions or the protected-mode functions >> (which exist since VBE 2.0, not only 3.0). From the view >> of an amd64 kernel it doesn't make a difference. >> >> Another way would be to write a 32bit x86 instruction >> emulator (similar to what programs like qemu or bochs do), >> so you can execute the VESA functions within an emulated >> virtual machine that programs the VGA hardware registers. >> This isn't exactly trivial either. Note that there are >> already such emulators, but I'm not aware of a BSD-licensed >> one that could be included in the FreeBSD kernel without >> problems. > > doscmd(1) had a rudimentary 16-bit CPU emulation: > > http://www.freebsd.org/cgi/cvsweb.cgi/projects/doscmd/ > http://www.freebsd.org/cgi/cvsweb.cgi/projects/doscmd/cpu.c No change in the last 4 years. Is there anybody responsible for it these days? -- cd /usr/ports/sysutils/life make clean From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 17:50:59 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED6801065692 for ; Mon, 15 Sep 2008 17:50:59 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [87.251.61.211]) by mx1.freebsd.org (Postfix) with ESMTP id B2B698FC1A for ; Mon, 15 Sep 2008 17:50:59 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 1A7F61CC22; Mon, 15 Sep 2008 19:50:28 +0200 (CEST) Date: Mon, 15 Sep 2008 19:50:28 +0200 From: Ed Schouten To: Andriy Gapon Message-ID: <20080915175028.GD81522@hoeg.nl> References: <48CE59C2.9060307@icyb.net.ua> <48CE8D2D.4020400@icyb.net.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TybLhxa8M7aNoW+V" Content-Disposition: inline In-Reply-To: <48CE8D2D.4020400@icyb.net.ua> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Marcel Moolenaar , FreeBSD Current Subject: Re: sio => uart: one port is gone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 17:51:00 -0000 --TybLhxa8M7aNoW+V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Andriy Gapon wrote: > What is the alternative? > Building it into a kernel? Is this maybe too much of a requirement? > From /sys/i386/conf/NOTES (RELENG_7): > # Note that building ACPI into the kernel is deprecated; the module is > # normally loaded automatically by the loader. I don't really understand why this is deprecated. 99.8% of the systems sold nowadays support ACPI. On AMD64 we enable ACPI by default, because it's impossible to use without ACPI (?) Shouldn't we just enable ACPI by default? --=20 Ed Schouten WWW: http://80386.nl/ --TybLhxa8M7aNoW+V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkjOoGQACgkQ52SDGA2eCwURHwCfSLtb5zHrIotyK1qbFei9CA+b oZ4AnRl3taQI0rdgek4P6uXWQ0CFOmuT =7Gyj -----END PGP SIGNATURE----- --TybLhxa8M7aNoW+V-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 17:53:23 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CA38106567C for ; Mon, 15 Sep 2008 17:53:23 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id D96C98FC35 for ; Mon, 15 Sep 2008 17:53:22 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id m8FHr92i083628; Mon, 15 Sep 2008 19:53:10 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id m8FHr9Gi083627; Mon, 15 Sep 2008 19:53:09 +0200 (CEST) (envelope-from olli) Date: Mon, 15 Sep 2008 19:53:09 +0200 (CEST) Message-Id: <200809151753.m8FHr9Gi083627@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, unixmania@gmail.com, delphij@delphij.net In-Reply-To: X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Mon, 15 Sep 2008 19:53:10 +0200 (CEST) Cc: Subject: Re: Why VESA and DPMS are available only for i386? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, unixmania@gmail.com, delphij@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 17:53:23 -0000 Carlos A. M. dos Santos wrote: > Oliver Fromme wrote: > > There's a third way, and I think this is the easiest one. > > This is what the Linux VESA framebuffer driver does. > > Let the boot loader (which executes in 32bit mode) switch > > to the desired video mode, enable a linear frame buffer > > (which is supported since VBE 2.0) and pass the address > > of the frame buffer to the 64bit kernel. Then the kernel > > would not need to call any VESA functions at all, thus > > eliminating all of the above problems. The drawback is > > that you can't change the console video mode anymore once > > the kernel is booted, i.e. you have to reboot if you want > > a different mode. > > This can also lead to a situation where the kernel can not restore the > video controller to a known mode if the X server crashes or when the > user attempts to switch from X to the "text mode" console. Why would you need to use VESA modes for syscons if you install and run Xorg anyway? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mn- chen, HRB 125758, Geschftsfhrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "IRIX is about as stable as a one-legged drunk with hypothermia in a four-hundred mile per hour wind, balancing on a banana peel on a greased cookie sheet -- when someone throws him an elephant with bad breath and a worse temper." -- Ralf Hildebrandt From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 18:22:57 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11FBF106567B for ; Mon, 15 Sep 2008 18:22:57 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: from mail-gx0-f17.google.com (mail-gx0-f17.google.com [209.85.217.17]) by mx1.freebsd.org (Postfix) with ESMTP id A5CA98FC17 for ; Mon, 15 Sep 2008 18:22:56 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: by gxk10 with SMTP id 10so24062714gxk.19 for ; Mon, 15 Sep 2008 11:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=DDUoZdOZMKVr/7F57xKypNndCRN7mOBYRqmstYUpjCQ=; b=j+nbVhUEhwhKZCQaYLLYeFX+mFyt5a2BqGAS2QCxGZX7mxtbbK9oejyi30QFmfC7Ij zwHfF3K/42pdL0itHKWbz5XS9SXoP8hgqaMoLRcZREvhSDCyEMWSBv5sSsKMs+UZpHwx feP95sqAPPJssU1qGgQNgpOiZkqtGkhnfB4X4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=PcTNEj2LYSeDp58Zh1ApQlj8L4DXgvoCDuLAyT6xsESC1FhgcAYoflzyO6ciB2/2Q7 BwlbdMlnVvoD+0ZIaf9f6pzW6KrKIATShuXg4Y/sRq9RQAGCU5Xrh74B3QQ66wiNO2Js UdiDtd6pgwT4Z/O/o0ZBSy+udiqDCH6SR+og8= Received: by 10.103.215.4 with SMTP id s4mr5775164muq.13.1221502973899; Mon, 15 Sep 2008 11:22:53 -0700 (PDT) Received: by 10.103.231.14 with HTTP; Mon, 15 Sep 2008 11:22:53 -0700 (PDT) Message-ID: Date: Mon, 15 Sep 2008 15:22:53 -0300 From: "Carlos A. M. dos Santos" To: freebsd-current@freebsd.org, unixmania@gmail.com, delphij@delphij.net In-Reply-To: <200809151753.m8FHr9Gi083627@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200809151753.m8FHr9Gi083627@lurza.secnetix.de> Cc: Subject: Re: Why VESA and DPMS are available only for i386? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 18:22:57 -0000 On Mon, Sep 15, 2008 at 2:53 PM, Oliver Fromme wrote: > Carlos A. M. dos Santos wrote: > > Oliver Fromme wrote: > > > There's a third way, and I think this is the easiest one. > > > This is what the Linux VESA framebuffer driver does. > > > Let the boot loader (which executes in 32bit mode) switch > > > to the desired video mode, enable a linear frame buffer > > > (which is supported since VBE 2.0) and pass the address > > > of the frame buffer to the 64bit kernel. Then the kernel > > > would not need to call any VESA functions at all, thus > > > eliminating all of the above problems. The drawback is > > > that you can't change the console video mode anymore once > > > the kernel is booted, i.e. you have to reboot if you want > > > a different mode. > > > > This can also lead to a situation where the kernel can not restore the > > video controller to a known mode if the X server crashes or when the > > user attempts to switch from X to the "text mode" console. > > Why would you need to use VESA modes for syscons if you > install and run Xorg anyway? Sorry, I was not clear enough in my previous message. I'm not proposing to use VESA modes for syscons. I was talking about a problem I see in the Linux console. On the other hand, suppose that I want to play games/digger. This would require the ability to switch from text to graphics mode and vice-versa even if I don't run the X server. -- cd /usr/ports/sysutils/life make clean From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 18:40:07 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id CE8A1106567B; Mon, 15 Sep 2008 18:40:04 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: "Carlos A. M. dos Santos" Date: Mon, 15 Sep 2008 14:39:42 -0400 User-Agent: KMail/1.6.2 References: <200809150922.m8F9MaHg090579@haluter.fromme.com> <200809151232.36756.jkim@FreeBSD.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200809151439.44049.jkim@FreeBSD.org> Cc: Xin LI , freebsd-current@freebsd.org, Oliver Fromme Subject: Re: Why VESA and DPMS are available only for i386? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 18:40:07 -0000 On Monday 15 September 2008 01:24 pm, Carlos A. M. dos Santos wrote: > On Mon, Sep 15, 2008 at 1:32 PM, Jung-uk Kim wrote: > > On Monday 15 September 2008 05:22 am, Oliver Fromme wrote: > >> Carlos A. M. dos Santos wrote: > >> > Xin LI wrote: > >> > > Carlos A. M. dos Santos wrote: > >> > > > Several PRs were closed based on the argument that > >> > > > FreeBSD/amd64 cannot call to the VESA BIOS. XFree86 > >> > > > solved this problem by means of the INT10 module. I > >> > > > believe that it would be possible to do the same on the > >> > > > FreeBSD kernel. > >> > > > > >> > > > Is there any ongoing effort to enable the VESA kernel > >> > > > moule on non-i386 platform? Is there any particular > >> > > > difficulty for doing this, besides depending on VM86? > >> > > > >> > > According to VESA's VBE 3.0 standard, there is a "Protected > >> > > Mode Entry Point" [optionally] provided by BIOS, which OS > >> > > or application is supposed to copy to a place where it is > >> > > writable. The code there would be written in 16-bit > >> > > protected mode. Therefore I think it's do-able... > >> > > > >> > > http://www.vesa.org/public/VBE/vbe3.pdf > >> > > >> > I'm reading the specification and digging at the code of the > >> > X server and the X VESA driver. Look promising. > >> > >> Don't hold your breath. Peter explained that this is more > >> involved than it seems at first glance: > >> > >> http://lists.freebsd.org/pipermail/freebsd-amd64/2005-October/00 > >>637 6.html > >> > >> Here's a quote: > >> | [FreeBSD's VESA code] is trying to use bios calls to change > >> | the modes. This is something a 64 bit kernel cannot do. To > >> | make this work, one would have to trampoline out of 64 bit > >> | mode and into 32 bit mode, then do the vm86 or bios32() > >> | calls. This is more work than it might appear at first > >> | because you have to deal with interrupts. One would have to > >> | write a 32 bit mini-kernel that can accept interrupts and > >> | traps, trampoline to 64 bit mode, handle them, then return, > >> | switching back to 32 bit mode. All with page tables etc. > >> | And of course you have to do extra data copying and have a > >> | way to describe it to the API. > >> > >> By the way, It doesn't matter whether you use the VESA > >> BIOS' real-mode functions or the protected-mode functions > >> (which exist since VBE 2.0, not only 3.0). From the view > >> of an amd64 kernel it doesn't make a difference. > >> > >> Another way would be to write a 32bit x86 instruction > >> emulator (similar to what programs like qemu or bochs do), > >> so you can execute the VESA functions within an emulated > >> virtual machine that programs the VGA hardware registers. > >> This isn't exactly trivial either. Note that there are > >> already such emulators, but I'm not aware of a BSD-licensed > >> one that could be included in the FreeBSD kernel without > >> problems. > > > > doscmd(1) had a rudimentary 16-bit CPU emulation: > > > > http://www.freebsd.org/cgi/cvsweb.cgi/projects/doscmd/ > > http://www.freebsd.org/cgi/cvsweb.cgi/projects/doscmd/cpu.c > > No change in the last 4 years. Is there anybody responsible for it > these days? doscmd(1) was removed from base and moved to ports: http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/doscmd/ Don't get me wrong, BTW. It does not work on amd64. I just brought it up because we *may* be able to do a hybrid approach as Linux DOSEMU does: http://en.wikipedia.org/wiki/DOSEMU "Virtual 8086 mode is not available in x86-64 long mode, so DOSEMU includes an 8086 processor emulator for use with 16-bit applications." Also, Linux people actually developed vm86 calls for amd64: http://v86-64.sourceforge.net/ Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 18:54:44 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EB57106566B for ; Mon, 15 Sep 2008 18:54:44 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from fw.farid-hajji.net (fw.farid-hajji.net [213.146.115.42]) by mx1.freebsd.org (Postfix) with ESMTP id BB4738FC19 for ; Mon, 15 Sep 2008 18:54:43 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from phenom.cordula.ws (phenom [192.168.254.60]) by fw.farid-hajji.net (Postfix) with ESMTP id 193C8354FA; Mon, 15 Sep 2008 20:54:41 +0200 (CEST) Date: Mon, 15 Sep 2008 12:54:46 -0600 From: cpghost To: Stephen Montgomery-Smith Message-ID: <20080915185446.GB69615@phenom.cordula.ws> References: <48CDBC78.4010409@math.missouri.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48CDBC78.4010409@math.missouri.edu> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-current@freebsd.org Subject: Re: Improved multiprocessor usage on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 18:54:44 -0000 On Sun, Sep 14, 2008 at 08:38:00PM -0500, Stephen Montgomery-Smith wrote: > I have a dual core amd64 on which I run a processor intensive numerical > program. I had been frustrated because it seemed to run 3 or 4 times > faster under Linux. But with a recent upgrade of FreeBSD-CURRENT, it > now goes at about the same speed as Linux. > > The program takes about an hour. For the first minute, the program runs > rather slowly, but then it is as if the operating system finds its way, > and suddenly it speeds up. "top -H" suggests that for the first minute > that one thread is going really slowly, and is perhaps being starved or > something. > > My question is - why is this happening, and is this something I should > expect? Are there certain switches or sysctls I can set to make it go > fast from the get go? It looks like you're running powerd (see in /etc/rc.conf). It can take up to a minute for the load average of the machine to exceed a certain threshold where powerd would finally bump the cpu(s) to full speed. As for sysctls, check the speed with something like: # sysctl dev.cpu.0 > Thanks, Stephen Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 19:10:37 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDE561065683; Mon, 15 Sep 2008 19:10:37 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id BC36A8FC1B; Mon, 15 Sep 2008 19:10:31 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 220893190; Mon, 15 Sep 2008 22:10:30 +0300 Message-ID: <48CEB318.9060401@FreeBSD.org> Date: Mon, 15 Sep 2008 22:10:16 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.16 (X11/20080726) MIME-Version: 1.0 To: "army.of.root@googlemail.com" References: <48CBF399.9080801@FreeBSD.org> <20080913201513.71995150@deskjail> <48CC0867.9020208@FreeBSD.org> <48CEB155.1020800@googlemail.com> In-Reply-To: <48CEB155.1020800@googlemail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-multimedia@FreeBSD.org, Alexander Leidinger , freebsd-current@freebsd.org, ariff@freebsd.org Subject: Re: New snd_hda driver came in. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 19:10:37 -0000 army.of.root@googlemail.com wrote: > Is there a chance for an inofficial backport to 7 ? I really would like > microphone rec to work with my HDA-Controller. http://people.freebsd.org/~mav/hda.7.20080913.patch Or just take whole /usr/src/sys/dev/sound/pci/hda directory from 8-CURRENT. Differences are minimal. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 18:46:22 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08BEF1065672 for ; Mon, 15 Sep 2008 18:46:22 +0000 (UTC) (envelope-from ayihu@vip.qq.com) Received: from smtpbg69.qq.com (smtpbg69.qq.com [119.147.10.228]) by mx1.freebsd.org (Postfix) with SMTP id 9FF488FC08 for ; Mon, 15 Sep 2008 18:46:20 +0000 (UTC) (envelope-from ayihu@vip.qq.com) X-QQ-ThreadID: 66m0uo8H10,3 X-QQ-mid: webmail374t1221493287t4381 X-QQ-STYLE: From: "=?ISO-8859-1?B?YXlpaHU=?=" To: "=?ISO-8859-1?B?ZnJlZWJzZC1jdXJyZW50?=" Sender: ayihu@vip.qq.com Mime-Version: 1.0 Date: Mon, 15 Sep 2008 23:41:27 +0800 X-Priority: 3 Message-ID: X-QQ-MIME: TCMime 1.0 by Tencent X-Mailer: QQMail 2.x X-QQ-Mailer: QQMail 2.x X-Mailman-Approved-At: Mon, 15 Sep 2008 19:19:18 +0000 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Benq S41-HC50 can not setup FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 18:46:22 -0000 Q2Fubm90IGluc3RhbGwgRnJlZUJTRCAsIGJ1dCBjYW4gaW5zdGFsbCBEZWJpYW4gTGludXgg NC4wDQogIA0KIEluc3RhbGxzIHRoZSBGcmVlQlNEIDcuMCw3LjEsOC4wIHByb21wdDoNCiAg DQogUkFNIHBhcml0eSBlcnJvcixsaWtlbHkgaGFyZHdhcmUgZmFpbHVyZS4NCiAgDQogcHM6 VGhlIG1lbW9yeSBkb2VzIG5vdCBoYXZlIHRoZSBxdWVzdGlvbg0KICANCiBkZW1zZyBtZXNz YWdlKGZvciBEZWJpYW4gTGludXggKToNCiAgDQogTGludXggdmVyc2lvbiAyLjYuMTgtNi02 ODYgKERlYmlhbiAyLjYuMTguZGZzZy4xLTIyKSAoZGFubmZAZGViaWFuLm9yZykgKGdjYyB2 ZXJzaW9uIDQuMS4yIDIwMDYxMTE1IChwcmVyZWxlYXNlKSAoRGViaWFuIDQuMS4xLTIxKSkg IzEgU01QIFR1ZSBKdW4gMTcgMjE6MzE6MjcgVVRDIDIwMDgNCkJJT1MtcHJvdmlkZWQgcGh5 c2ljYWwgUkFNIG1hcDoNCiBCSU9TLWU4MjA6IDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAw MDAwMDlmODAwICh1c2FibGUpDQogQklPUy1lODIwOiAwMDAwMDAwMDAwMDlmODAwIC0gMDAw MDAwMDAwMDBhMDAwMCAocmVzZXJ2ZWQpDQogQklPUy1lODIwOiAwMDAwMDAwMDAwMGNlMDAw IC0gMDAwMDAwMDAwMDBkMDAwMCAocmVzZXJ2ZWQpDQogQklPUy1lODIwOiAwMDAwMDAwMDAw MGUwMDAwIC0gMDAwMDAwMDAwMDEwMDAwMCAocmVzZXJ2ZWQpDQogQklPUy1lODIwOiAwMDAw MDAwMDAwMTAwMDAwIC0gMDAwMDAwMDA3ZmVkMDAwMCAodXNhYmxlKQ0KIEJJT1MtZTgyMDog MDAwMDAwMDA3ZmVkMDAwMCAtIDAwMDAwMDAwN2ZlZGYwMDAgKEFDUEkgTlZTKQ0KIEJJT1Mt ZTgyMDogMDAwMDAwMDA3ZmVkZjAwMCAtIDAwMDAwMDAwODAwMDAwMDAgKHJlc2VydmVkKQ0K IEJJT1MtZTgyMDogMDAwMDAwMDBlMDAwMDAwMCAtIDAwMDAwMDAwZjAwMDAwMDAgKHJlc2Vy dmVkKQ0KIEJJT1MtZTgyMDogMDAwMDAwMDBmZWMwMDAwMCAtIDAwMDAwMDAwZmVjMTAwMDAg KHJlc2VydmVkKQ0KIEJJT1MtZTgyMDogMDAwMDAwMDBmZWQwMDAwMCAtIDAwMDAwMDAwZmVk MDA0MDAgKHJlc2VydmVkKQ0KIEJJT1MtZTgyMDogMDAwMDAwMDBmZWQxNDAwMCAtIDAwMDAw MDAwZmVkMWEwMDAgKHJlc2VydmVkKQ0KIEJJT1MtZTgyMDogMDAwMDAwMDBmZWQxYzAwMCAt IDAwMDAwMDAwZmVkOTAwMDAgKHJlc2VydmVkKQ0KIEJJT1MtZTgyMDogMDAwMDAwMDBmZWUw MDAwMCAtIDAwMDAwMDAwZmVlMDEwMDAgKHJlc2VydmVkKQ0KIEJJT1MtZTgyMDogMDAwMDAw MDBmZjAwMDAwMCAtIDAwMDAwMDAxMDAwMDAwMDAgKHJlc2VydmVkKQ0KMTE1ME1CIEhJR0hN RU0gYXZhaWxhYmxlLg0KODk2TUIgTE9XTUVNIGF2YWlsYWJsZS4NCmZvdW5kIFNNUCBNUC10 YWJsZSBhdCAwMDBmN2VkMA0KT24gbm9kZSAwIHRvdGFscGFnZXM6IDUyMzk4NA0KICBETUEg em9uZTogNDA5NiBwYWdlcywgTElGTyBiYXRjaDowDQogIE5vcm1hbCB6b25lOiAyMjUyODAg cGFnZXMsIExJRk8gYmF0Y2g6MzENCiAgSGlnaE1lbSB6b25lOiAyOTQ2MDggcGFnZXMsIExJ Rk8gYmF0Y2g6MzENCkRNSSBwcmVzZW50Lg0KQUNQSTogUlNEUCAodjAwMiBQVExURCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICkgQCAweDAwMGY3ZWEwDQpBQ1BJOiBYU0RU ICh2MDAxIEJlblEgICBKb3lib29rICAweDA2MDQwMDAwICBMVFAgMHgwMDAwMDAwMCkgQCAw eDdmZWQzNzAyDQpBQ1BJOiBGQURUICh2MDAzIElOVEVMICBDUkVTVExORSAweDA2MDQwMDAw IEFMQU4gMHgwMDAwMDAwMSkgQCAweDdmZWRiYmQyDQpBQ1BJOiBNQURUICh2MDAxIElOVEVM ICBDUkVTVExORSAweDA2MDQwMDAwIExPSFIgMHgwMDAwMDA1YSkgQCAweDdmZWRiY2M2DQpB Q1BJOiBIUEVUICh2MDAxIElOVEVMICBDUkVTVExORSAweDA2MDQwMDAwIExPSFIgMHgwMDAw MDA1YSkgQCAweDdmZWRiZDJlDQpBQ1BJOiBNQ0ZHICh2MDAxIElOVEVMICBDUkVTVExORSAw eDA2MDQwMDAwIExPSFIgMHgwMDAwMDA1YSkgQCAweDdmZWRiZDY2DQpBQ1BJOiBUQ1BBICh2 MDAxIEludGVsICAgQ1JFU1RMTiAweDA2MDQwMDAwICAweDAwMDA1YTUyKSBAIDB4N2ZlZGJk YTINCkFDUEk6IFRNT1IgKHYwMDEgUFRMVEQgICAgICAgICAgIDB4MDYwNDAwMDAgUFRMICAw eDAwMDAwMDAzKSBAIDB4N2ZlZGJkZDQNCkFDUEk6IE1BRFQgKHYwMDEgUFRMVEQgICAgQVBJ QyAgIDB4MDYwNDAwMDAgIExUUCAweDAwMDAwMDAwKSBAIDB4N2ZlZGJkZmENCkFDUEk6IEJP T1QgKHYwMDEgUFRMVEQgICRTQkZUQkwkIDB4MDYwNDAwMDAgIExUUCAweDAwMDAwMDAxKSBA IDB4N2ZlZGJlNjINCkFDUEk6IFNMSUMgKHYwMDEgQmVuUSAgIEpveWJvb2sgIDB4MDYwNDAw MDAgIExUUCAweDAwMDAwMDAwKSBAIDB4N2ZlZGJlOGENCkFDUEk6IFNTRFQgKHYwMDEgU2F0 YVJlICBTYXRhUHJpIDB4MDAwMDEwMDAgSU5UTCAweDIwMDUwNjI0KSBAIDB4N2ZlZDRmNDAN CkFDUEk6IFNTRFQgKHYwMDEgU2F0YVJlICBTYXRhU2VjIDB4MDAwMDEwMDAgSU5UTCAweDIw MDUwNjI0KSBAIDB4N2ZlZDQ4YWUNCkFDUEk6IFNTRFQgKHYwMDEgIFBtUmVmICBDcHUwVHN0 IDB4MDAwMDMwMDAgSU5UTCAweDIwMDUwNjI0KSBAIDB4N2ZlZDNkMjINCkFDUEk6IFNTRFQg KHYwMDEgIFBtUmVmICBDcHUxVHN0IDB4MDAwMDMwMDAgSU5UTCAweDIwMDUwNjI0KSBAIDB4 N2ZlZDNjN2MNCkFDUEk6IFNTRFQgKHYwMDEgIFBtUmVmICAgIENwdVBtIDB4MDAwMDMwMDAg SU5UTCAweDIwMDUwNjI0KSBAIDB4N2ZlZDM3OTYNCkFDUEk6IERTRFQgKHYwMDIgSU5URUwg IENSRVNUTE5FIDB4MDYwNDAwMDAgSU5UTCAweDIwMDUwNjI0KSBAIDB4MDAwMDAwMDANCkFD UEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4MTAwOA0KQUNQSTogTG9jYWwgQVBJQyBhZGRyZXNz IDB4ZmVlMDAwMDANCkFDUEk6IDIgZHVwbGljYXRlIEFQSUMgdGFibGUgaWdub3JlZC4NCkFD UEk6IExBUElDIChhY3BpX2lkWzB4MDBdIGxhcGljX2lkWzB4MDBdIGVuYWJsZWQpDQpQcm9j ZXNzb3IgIzAgNjoxNSBBUElDIHZlcnNpb24gMjANCkFDUEk6IExBUElDIChhY3BpX2lkWzB4 MDFdIGxhcGljX2lkWzB4MDFdIGVuYWJsZWQpDQpQcm9jZXNzb3IgIzEgNjoxNSBBUElDIHZl cnNpb24gMjANCkFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDAwXSBoaWdoIGVkZ2UgbGlu dFsweDFdKQ0KQUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MDFdIGhpZ2ggZWRnZSBsaW50 WzB4MV0pDQpBQ1BJOiBJT0FQSUMgKGlkWzB4MDFdIGFkZHJlc3NbMHhmZWMwMDAwMF0gZ3Np X2Jhc2VbMF0pDQpJT0FQSUNbMF06IGFwaWNfaWQgMSwgdmVyc2lvbiAzMiwgYWRkcmVzcyAw eGZlYzAwMDAwLCBHU0kgMC0yMw0KQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEg MCBnbG9iYWxfaXJxIDIgZGZsIGRmbCkNCkFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNf aXJxIDkgZ2xvYmFsX2lycSA5IGhpZ2ggbGV2ZWwpDQpBQ1BJOiBJUlEwIHVzZWQgYnkgb3Zl cnJpZGUuDQpBQ1BJOiBJUlEyIHVzZWQgYnkgb3ZlcnJpZGUuDQpBQ1BJOiBJUlE5IHVzZWQg Ynkgb3ZlcnJpZGUuDQpFbmFibGluZyBBUElDIG1vZGU6ICBGbGF0LiAgVXNpbmcgMSBJL08g QVBJQ3MNCkFDUEk6IEhQRVQgaWQ6IDB4ODA4NmEyMDEgYmFzZTogMHhmZWQwMDAwMA0KVXNp bmcgQUNQSSAoTUFEVCkgZm9yIFNNUCBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uDQpBbGxv Y2F0aW5nIFBDSSByZXNvdXJjZXMgc3RhcnRpbmcgYXQgODgwMDAwMDAgKGdhcDogODAwMDAw MDA6NjAwMDAwMDApDQpEZXRlY3RlZCAxODI4LjgyMiBNSHogcHJvY2Vzc29yLg0KQnVpbHQg MSB6b25lbGlzdHMuICBUb3RhbCBwYWdlczogNTIzOTg0DQpLZXJuZWwgY29tbWFuZCBsaW5l OiByb290PS9kZXYvc2RhMyBybyANCm1hcHBlZCBBUElDIHRvIGZmZmZkMDAwIChmZWUwMDAw MCkNCm1hcHBlZCBJT0FQSUMgdG8gZmZmZmMwMDAgKGZlYzAwMDAwKQ0KRW5hYmxpbmcgZmFz dCBGUFUgc2F2ZSBhbmQgcmVzdG9yZS4uLiBkb25lLg0KRW5hYmxpbmcgdW5tYXNrZWQgU0lN RCBGUFUgZXhjZXB0aW9uIHN1cHBvcnQuLi4gZG9uZS4NCkluaXRpYWxpemluZyBDUFUjMA0K UElEIGhhc2ggdGFibGUgZW50cmllczogNDA5NiAob3JkZXI6IDEyLCAxNjM4NCBieXRlcykN CkNvbnNvbGU6IGNvbG91ciBWR0ErIDgweDI1DQpEZW50cnkgY2FjaGUgaGFzaCB0YWJsZSBl bnRyaWVzOiAxMzEwNzIgKG9yZGVyOiA3LCA1MjQyODggYnl0ZXMpDQpJbm9kZS1jYWNoZSBo YXNoIHRhYmxlIGVudHJpZXM6IDY1NTM2IChvcmRlcjogNiwgMjYyMTQ0IGJ5dGVzKQ0KTWVt b3J5OiAyMDY5OTY0ay8yMDk1OTM2ayBhdmFpbGFibGUgKDE1NDFrIGtlcm5lbCBjb2RlLCAy NDY3MmsgcmVzZXJ2ZWQsIDU4MGsgZGF0YSwgMTk2ayBpbml0LCAxMTc4NDMyayBoaWdobWVt KQ0KQ2hlY2tpbmcgaWYgdGhpcyBwcm9jZXNzb3IgaG9ub3VycyB0aGUgV1AgYml0IGV2ZW4g aW4gc3VwZXJ2aXNvciBtb2RlLi4uIE9rLg0KaHBldDA6IGF0IE1NSU8gMHhmZWQwMDAwMCAo dmlydHVhbCAweGY4ODAwMDAwKSwgSVJRcyAyLCA4LCAwDQpocGV0MDogMyA2NC1iaXQgdGlt ZXJzLCAxNDMxODE4MCBIeg0KVXNpbmcgSFBFVCBmb3IgYmFzZS10aW1lcg0KQ2FsaWJyYXRp bmcgZGVsYXkgdXNpbmcgdGltZXIgc3BlY2lmaWMgcm91dGluZS4uIDM2NjEuNDkgQm9nb01J UFMgKGxwaj03MzIyOTkxKQ0KU2VjdXJpdHkgRnJhbWV3b3JrIHYxLjAuMCBpbml0aWFsaXpl ZA0KU0VMaW51eDogIERpc2FibGVkIGF0IGJvb3QuDQpDYXBhYmlsaXR5IExTTSBpbml0aWFs aXplZA0KTW91bnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA1MTINCkNQVTogQWZ0ZXIg Z2VuZXJpYyBpZGVudGlmeSwgY2FwczogYmZlYmZiZmYgMjAxMDAwMDAgMDAwMDAwMDAgMDAw MDAwMDAgMDAwMGUzOWQgMDAwMDAwMDAgMDAwMDAwMDENCkNQVTogQWZ0ZXIgdmVuZG9yIGlk ZW50aWZ5LCBjYXBzOiBiZmViZmJmZiAyMDEwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAw ZTM5ZCAwMDAwMDAwMCAwMDAwMDAwMQ0KbW9uaXRvci9td2FpdCBmZWF0dXJlIHByZXNlbnQu DQp1c2luZyBtd2FpdCBpbiBpZGxlIHRocmVhZHMuDQpDUFU6IEwxIEkgY2FjaGU6IDMySywg TDEgRCBjYWNoZTogMzJLDQpDUFU6IEwyIGNhY2hlOiAyMDQ4Sw0KQ1BVOiBQaHlzaWNhbCBQ cm9jZXNzb3IgSUQ6IDANCkNQVTogUHJvY2Vzc29yIENvcmUgSUQ6IDANCkNQVTogQWZ0ZXIg YWxsIGluaXRzLCBjYXBzOiBiZmViZmJmZiAyMDEwMDAwMCAwMDAwMDAwMCAwMDAwMDk0MCAw MDAwZTM5ZCAwMDAwMDAwMCAwMDAwMDAwMQ0KSW50ZWwgbWFjaGluZSBjaGVjayBhcmNoaXRl Y3R1cmUgc3VwcG9ydGVkLg0KSW50ZWwgbWFjaGluZSBjaGVjayByZXBvcnRpbmcgZW5hYmxl ZCBvbiBDUFUjMC4NCkNvbXBhdCB2RFNPIG1hcHBlZCB0byBmZmZmZTAwMC4NCkNoZWNraW5n ICdobHQnIGluc3RydWN0aW9uLi4uIE9LLg0KU01QIGFsdGVybmF0aXZlczogc3dpdGNoaW5n IHRvIFVQIGNvZGUNCkFDUEk6IENvcmUgcmV2aXNpb24gMjAwNjA3MDcNCkNQVTA6IEludGVs KFIpIENvcmUoVE0pMiBEdW8gQ1BVICAgICBUNTU1MCAgQCAxLjgzR0h6IHN0ZXBwaW5nIDBk DQpTTVAgYWx0ZXJuYXRpdmVzOiBzd2l0Y2hpbmcgdG8gU01QIGNvZGUNCkJvb3RpbmcgcHJv Y2Vzc29yIDEvMSBlaXAgMzAwMA0KSW5pdGlhbGl6aW5nIENQVSMxDQpDYWxpYnJhdGluZyBk ZWxheSB1c2luZyB0aW1lciBzcGVjaWZpYyByb3V0aW5lLi4gMzY1Ny42MCBCb2dvTUlQUyAo bHBqPTczMTUyMDIpDQpDUFU6IEFmdGVyIGdlbmVyaWMgaWRlbnRpZnksIGNhcHM6IGJmZWJm YmZmIDIwMTAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDBlMzlkIDAwMDAwMDAwIDAwMDAw MDAxDQpDUFU6IEFmdGVyIHZlbmRvciBpZGVudGlmeSwgY2FwczogYmZlYmZiZmYgMjAxMDAw MDAgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMGUzOWQgMDAwMDAwMDAgMDAwMDAwMDENCm1vbml0 b3IvbXdhaXQgZmVhdHVyZSBwcmVzZW50Lg0KQ1BVOiBMMSBJIGNhY2hlOiAzMkssIEwxIEQg Y2FjaGU6IDMySw0KQ1BVOiBMMiBjYWNoZTogMjA0OEsNCkNQVTogUGh5c2ljYWwgUHJvY2Vz c29yIElEOiAwDQpDUFU6IFByb2Nlc3NvciBDb3JlIElEOiAxDQpDUFU6IEFmdGVyIGFsbCBp bml0cywgY2FwczogYmZlYmZiZmYgMjAxMDAwMDAgMDAwMDAwMDAgMDAwMDA5NDAgMDAwMGUz OWQgMDAwMDAwMDAgMDAwMDAwMDENCkludGVsIG1hY2hpbmUgY2hlY2sgYXJjaGl0ZWN0dXJl IHN1cHBvcnRlZC4NCkludGVsIG1hY2hpbmUgY2hlY2sgcmVwb3J0aW5nIGVuYWJsZWQgb24g Q1BVIzEuDQpDUFUxOiBJbnRlbChSKSBDb3JlKFRNKTIgRHVvIENQVSAgICAgVDU1NTAgIEAg MS44M0dIeiBzdGVwcGluZyAwZA0KVG90YWwgb2YgMiBwcm9jZXNzb3JzIGFjdGl2YXRlZCAo NzMxOS4wOSBCb2dvTUlQUykuDQpFTkFCTElORyBJTy1BUElDIElSUXMNCi4uVElNRVI6IHZl Y3Rvcj0weDMxIGFwaWMxPTAgcGluMT0yIGFwaWMyPS0xIHBpbjI9LTENCmNoZWNraW5nIFRT QyBzeW5jaHJvbml6YXRpb24gYWNyb3NzIDIgQ1BVczogcGFzc2VkLg0KQnJvdWdodCB1cCAy IENQVXMNCm1pZ3JhdGlvbl9jb3N0PTEwMA0KY2hlY2tpbmcgaWYgaW1hZ2UgaXMgaW5pdHJh bWZzLi4uIGl0IGlzDQpGcmVlaW5nIGluaXRyZCBtZW1vcnk6IDQ3NTVrIGZyZWVkDQpORVQ6 IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDE2DQpBQ1BJOiBidXMgdHlwZSBwY2kgcmVn aXN0ZXJlZA0KUENJOiBVc2luZyBNTUNPTkZJRw0KU2V0dGluZyB1cCBzdGFuZGFyZCBQQ0kg cmVzb3VyY2VzDQpBQ1BJOiBJbnRlcnByZXRlciBlbmFibGVkDQpBQ1BJOiBVc2luZyBJT0FQ SUMgZm9yIGludGVycnVwdCByb3V0aW5nDQpBQ1BJOiBQQ0kgUm9vdCBCcmlkZ2UgW1BDSTBd ICgwMDAwOjAwKQ0KUENJOiBQcm9iaW5nIFBDSSBoYXJkd2FyZSAoYnVzIDAwKQ0KQUNQSTog QXNzdW1lIHJvb3QgYnJpZGdlIFtcX1NCXy5QQ0kwXSBidXMgaXMgMA0KUENJOiBJZ25vcmlu ZyBCQVIwLTMgb2YgSURFIGNvbnRyb2xsZXIgMDAwMDowMDoxZi4yDQpCb290IHZpZGVvIGRl dmljZSBpcyAwMDAwOjAxOjAwLjANClBDSTogVHJhbnNwYXJlbnQgYnJpZGdlIC0gMDAwMDow MDoxZS4wDQpQQ0k6IEJ1cyAjMDcgKC0jMGEpIGlzIGhpZGRlbiBiZWhpbmQgdHJhbnNwYXJl bnQgYnJpZGdlICMwNiAoLSMwNykgKHRyeSAncGNpPWFzc2lnbi1idXNzZXMnKQ0KUGxlYXNl IHJlcG9ydCB0aGUgcmVzdWx0IHRvIGxpbnV4LWtlcm5lbCB0byBmaXggdGhpcyBwZXJtYW5l bnRseQ0KQUNQSTogUENJIEludGVycnVwdCBSb3V0aW5nIFRhYmxlIFtcX1NCXy5QQ0kwLl9Q UlRdDQpBQ1BJOiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuUEVH UC5fUFJUXQ0KQUNQSTogUENJIEludGVycnVwdCBSb3V0aW5nIFRhYmxlIFtcX1NCXy5QQ0kw LlJQMDEuX1BSVF0NCkFDUEk6IFBDSSBJbnRlcnJ1cHQgUm91dGluZyBUYWJsZSBbXF9TQl8u UENJMC5SUDAyLl9QUlRdDQpBQ1BJOiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xf U0JfLlBDSTAuUlAwNC5fUFJUXQ0KQUNQSTogUENJIEludGVycnVwdCBSb3V0aW5nIFRhYmxl IFtcX1NCXy5QQ0kwLlJQMDYuX1BSVF0NCkFDUEk6IFBDSSBJbnRlcnJ1cHQgUm91dGluZyBU YWJsZSBbXF9TQl8uUENJMC5QQ0lCLl9QUlRdDQpBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsg W0xOS0FdIChJUlFzIDEgMyA0ICo1IDYgNyAxMCAxMiAxNCAxNSkNCkFDUEk6IFBDSSBJbnRl cnJ1cHQgTGluayBbTE5LQl0gKElSUXMgMSAzIDQgNSA2IDcgMTEgMTIgMTQgMTUpICoxMA0K QUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktDXSAoSVJRcyAxIDMgNCA1IDYgKjcgMTAg MTIgMTQgMTUpDQpBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0RdIChJUlFzIDEgMyA0 IDUgNiA3IDExIDEyIDE0IDE1KSAqMTANCkFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5L RV0gKElSUXMgMSAzIDQgNSA2IDcgMTAgMTIgMTQgMTUpICoxMQ0KQUNQSTogUENJIEludGVy cnVwdCBMaW5rIFtMTktGXSAoSVJRcyAxIDMgNCA1IDYgNyAqMTEgMTIgMTQgMTUpDQpBQ1BJ OiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0ddIChJUlFzIDEgMyA0IDUgNiA3IDEwIDEyIDE0 IDE1KSAqMTENCkFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LSF0gKElSUXMgMSAzIDQg NSA2IDcgMTEgMTIgMTQgMTUpICoxMA0KQUNQSTogRW1iZWRkZWQgQ29udHJvbGxlciBbRUMw XSAoZ3BlIDIzKSBpbnRlcnJ1cHQgbW9kZS4NCkxpbnV4IFBsdWcgYW5kIFBsYXkgU3VwcG9y dCB2MC45NyAoYykgQWRhbSBCZWxheQ0KcG5wOiBQblAgQUNQSSBpbml0DQpwbnA6IFBuUCBB Q1BJOiBmb3VuZCAxMCBkZXZpY2VzDQpQblBCSU9TOiBEaXNhYmxlZCBieSBBQ1BJIFBOUA0K UENJOiBVc2luZyBBQ1BJIGZvciBJUlEgcm91dGluZw0KUENJOiBJZiBhIGRldmljZSBkb2Vz bid0IHdvcmssIHRyeSAicGNpPXJvdXRlaXJxIi4gIElmIGl0IGhlbHBzLCBwb3N0IGEgcmVw b3J0DQpQQ0k6IENhbm5vdCBhbGxvY2F0ZSByZXNvdXJjZSByZWdpb24gNyBvZiBicmlkZ2Ug MDAwMDowMDoxYy4wDQpQQ0k6IENhbm5vdCBhbGxvY2F0ZSByZXNvdXJjZSByZWdpb24gOCBv ZiBicmlkZ2UgMDAwMDowMDoxYy4wDQpQQ0k6IENhbm5vdCBhbGxvY2F0ZSByZXNvdXJjZSBy ZWdpb24gOSBvZiBicmlkZ2UgMDAwMDowMDoxYy4wDQpQQ0k6IENhbm5vdCBhbGxvY2F0ZSBy ZXNvdXJjZSByZWdpb24gNyBvZiBicmlkZ2UgMDAwMDowMDoxYy4xDQpQQ0k6IENhbm5vdCBh bGxvY2F0ZSByZXNvdXJjZSByZWdpb24gOCBvZiBicmlkZ2UgMDAwMDowMDoxYy4xDQpQQ0k6 IENhbm5vdCBhbGxvY2F0ZSByZXNvdXJjZSByZWdpb24gOSBvZiBicmlkZ2UgMDAwMDowMDox Yy4xDQpQQ0k6IENhbm5vdCBhbGxvY2F0ZSByZXNvdXJjZSByZWdpb24gNyBvZiBicmlkZ2Ug MDAwMDowMDoxYy4zDQpQQ0k6IENhbm5vdCBhbGxvY2F0ZSByZXNvdXJjZSByZWdpb24gOCBv ZiBicmlkZ2UgMDAwMDowMDoxYy4zDQpQQ0k6IENhbm5vdCBhbGxvY2F0ZSByZXNvdXJjZSBy ZWdpb24gOSBvZiBicmlkZ2UgMDAwMDowMDoxYy4zDQpQQ0k6IENhbm5vdCBhbGxvY2F0ZSBy ZXNvdXJjZSByZWdpb24gNyBvZiBicmlkZ2UgMDAwMDowMDoxYy41DQpQQ0k6IENhbm5vdCBh bGxvY2F0ZSByZXNvdXJjZSByZWdpb24gOCBvZiBicmlkZ2UgMDAwMDowMDoxYy41DQpQQ0k6 IENhbm5vdCBhbGxvY2F0ZSByZXNvdXJjZSByZWdpb24gOSBvZiBicmlkZ2UgMDAwMDowMDox Yy41DQpQQ0k6IENhbm5vdCBhbGxvY2F0ZSByZXNvdXJjZSByZWdpb24gMCBvZiBkZXZpY2Ug MDAwMDowNTowMC4wDQpQQ0k6IENhbm5vdCBhbGxvY2F0ZSByZXNvdXJjZSByZWdpb24gMiBv ZiBkZXZpY2UgMDAwMDowNTowMC4wDQpQQ0k6IEZhaWxlZCB0byBhbGxvY2F0ZSBtZW0gcmVz b3VyY2UgIzY6MjAwMDBAZTAwMDAwMDAgZm9yIDAwMDA6MDE6MDAuMA0KUENJOiBCcmlkZ2U6 IDAwMDA6MDA6MDEuMA0KICBJTyB3aW5kb3c6IDIwMDAtMmZmZg0KICBNRU0gd2luZG93OiBj YzAwMDAwMC1jZWZmZmZmZg0KICBQUkVGRVRDSCB3aW5kb3c6IGQwMDAwMDAwLWRmZmZmZmZm DQpQQ0k6IEJyaWRnZTogMDAwMDowMDoxYy4wDQogIElPIHdpbmRvdzogZGlzYWJsZWQuDQog IE1FTSB3aW5kb3c6IGRpc2FibGVkLg0KICBQUkVGRVRDSCB3aW5kb3c6IGRpc2FibGVkLg0K UENJOiBCcmlkZ2U6IDAwMDA6MDA6MWMuMQ0KICBJTyB3aW5kb3c6IGRpc2FibGVkLg0KICBN RU0gd2luZG93OiBkaXNhYmxlZC4NCiAgUFJFRkVUQ0ggd2luZG93OiBkaXNhYmxlZC4NClBD STogQnJpZGdlOiAwMDAwOjAwOjFjLjMNCiAgSU8gd2luZG93OiBkaXNhYmxlZC4NCiAgTUVN IHdpbmRvdzogZGlzYWJsZWQuDQogIFBSRUZFVENIIHdpbmRvdzogZGlzYWJsZWQuDQpQQ0k6 IEJyaWRnZTogMDAwMDowMDoxYy41DQogIElPIHdpbmRvdzogMzAwMC0zZmZmDQogIE1FTSB3 aW5kb3c6IDhhMDAwMDAwLThhMGZmZmZmDQogIFBSRUZFVENIIHdpbmRvdzogOGExMDAwMDAt OGExZmZmZmYNClBDSTogQnVzIDcsIGNhcmRidXMgYnJpZGdlOiAwMDAwOjA2OjA5LjANCiAg SU8gd2luZG93OiAwMDAwNDAwMC0wMDAwNDBmZg0KICBJTyB3aW5kb3c6IDAwMDA0NDAwLTAw MDA0NGZmDQogIFBSRUZFVENIIHdpbmRvdzogODgwMDAwMDAtODlmZmZmZmYNCiAgTUVNIHdp bmRvdzogOGMwMDAwMDAtOGRmZmZmZmYNClBDSTogQnJpZGdlOiAwMDAwOjAwOjFlLjANCiAg SU8gd2luZG93OiA0MDAwLTRmZmYNCiAgTUVNIHdpbmRvdzogZjAzMDAwMDAtZjAzZmZmZmYN CiAgUFJFRkVUQ0ggd2luZG93OiA4ODAwMDAwMC04OWZmZmZmZg0KQUNQSTogUENJIEludGVy cnVwdCAwMDAwOjAwOjAxLjBbQV0gLT4gR1NJIDE2IChsZXZlbCwgbG93KSAtPiBJUlEgMTY5 DQpQQ0k6IFNldHRpbmcgbGF0ZW5jeSB0aW1lciBvZiBkZXZpY2UgMDAwMDowMDowMS4wIHRv IDY0DQpBQ1BJOiBQQ0kgSW50ZXJydXB0IDAwMDA6MDA6MWMuMFtBXSAtPiBHU0kgMTcgKGxl dmVsLCBsb3cpIC0+IElSUSAxNzcNClBDSTogU2V0dGluZyBsYXRlbmN5IHRpbWVyIG9mIGRl dmljZSAwMDAwOjAwOjFjLjAgdG8gNjQNCkFDUEk6IFBDSSBJbnRlcnJ1cHQgMDAwMDowMDox Yy4xW0JdIC0+IEdTSSAxNiAobGV2ZWwsIGxvdykgLT4gSVJRIDE2OQ0KUENJOiBTZXR0aW5n IGxhdGVuY3kgdGltZXIgb2YgZGV2aWNlIDAwMDA6MDA6MWMuMSB0byA2NA0KQUNQSTogUENJ IEludGVycnVwdCAwMDAwOjAwOjFjLjNbRF0gLT4gR1NJIDE5IChsZXZlbCwgbG93KSAtPiBJ UlEgMTg1DQpQQ0k6IFNldHRpbmcgbGF0ZW5jeSB0aW1lciBvZiBkZXZpY2UgMDAwMDowMDox Yy4zIHRvIDY0DQpQQ0k6IEVuYWJsaW5nIGRldmljZSAwMDAwOjAwOjFjLjUgKDAxMDAgLT4g MDEwMykNCkFDUEk6IFBDSSBJbnRlcnJ1cHQgMDAwMDowMDoxYy41W0JdIC0+IEdTSSAxNiAo bGV2ZWwsIGxvdykgLT4gSVJRIDE2OQ0KUENJOiBTZXR0aW5nIGxhdGVuY3kgdGltZXIgb2Yg ZGV2aWNlIDAwMDA6MDA6MWMuNSB0byA2NA0KUENJOiBTZXR0aW5nIGxhdGVuY3kgdGltZXIg b2YgZGV2aWNlIDAwMDA6MDA6MWUuMCB0byA2NA0KQUNQSTogUENJIEludGVycnVwdCAwMDAw OjA2OjA5LjBbQV0gLT4gR1NJIDIwIChsZXZlbCwgbG93KSAtPiBJUlEgMTkzDQpORVQ6IFJl Z2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDINCklQIHJvdXRlIGNhY2hlIGhhc2ggdGFibGUg ZW50cmllczogMzI3NjggKG9yZGVyOiA1LCAxMzEwNzIgYnl0ZXMpDQpUQ1AgZXN0YWJsaXNo ZWQgaGFzaCB0YWJsZSBlbnRyaWVzOiAxMzEwNzIgKG9yZGVyOiA4LCAxMDQ4NTc2IGJ5dGVz KQ0KVENQIGJpbmQgaGFzaCB0YWJsZSBlbnRyaWVzOiA2NTUzNiAob3JkZXI6IDcsIDUyNDI4 OCBieXRlcykNClRDUDogSGFzaCB0YWJsZXMgY29uZmlndXJlZCAoZXN0YWJsaXNoZWQgMTMx MDcyIGJpbmQgNjU1MzYpDQpUQ1AgcmVubyByZWdpc3RlcmVkDQpTaW1wbGUgQm9vdCBGbGFn IGF0IDB4MzYgc2V0IHRvIDB4MQ0KYXVkaXQ6IGluaXRpYWxpemluZyBuZXRsaW5rIHNvY2tl dCAoZGlzYWJsZWQpDQphdWRpdCgxMjIxNDQ4MjQxLjEwODoxKTogaW5pdGlhbGl6ZWQNCmhp Z2htZW0gYm91bmNlIHBvb2wgc2l6ZTogNjQgcGFnZXMNClZGUzogRGlzayBxdW90YXMgZHF1 b3RfNi41LjENCkRxdW90LWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogMTAyNCAob3JkZXIg MCwgNDA5NiBieXRlcykNCkluaXRpYWxpemluZyBDcnlwdG9ncmFwaGljIEFQSQ0KaW8gc2No ZWR1bGVyIG5vb3AgcmVnaXN0ZXJlZA0KaW8gc2NoZWR1bGVyIGFudGljaXBhdG9yeSByZWdp c3RlcmVkDQppbyBzY2hlZHVsZXIgZGVhZGxpbmUgcmVnaXN0ZXJlZA0KaW8gc2NoZWR1bGVy IGNmcSByZWdpc3RlcmVkIChkZWZhdWx0KQ0KUENJOiBTZXR0aW5nIGxhdGVuY3kgdGltZXIg b2YgZGV2aWNlIDAwMDA6MDA6MDEuMCB0byA2NA0KYXNzaWduX2ludGVycnVwdF9tb2RlIEZv dW5kIE1TSSBjYXBhYmlsaXR5DQpBbGxvY2F0ZSBQb3J0IFNlcnZpY2VbMDAwMDowMDowMS4w OnBjaWUwMF0NCkFsbG9jYXRlIFBvcnQgU2VydmljZVswMDAwOjAwOjAxLjA6cGNpZTAyXQ0K QWxsb2NhdGUgUG9ydCBTZXJ2aWNlWzAwMDA6MDA6MDEuMDpwY2llMDNdDQpQQ0k6IFNldHRp bmcgbGF0ZW5jeSB0aW1lciBvZiBkZXZpY2UgMDAwMDowMDoxYy4wIHRvIDY0DQphc3NpZ25f aW50ZXJydXB0X21vZGUgRm91bmQgTVNJIGNhcGFiaWxpdHkNCkFsbG9jYXRlIFBvcnQgU2Vy dmljZVswMDAwOjAwOjFjLjA6cGNpZTAwXQ0KQWxsb2NhdGUgUG9ydCBTZXJ2aWNlWzAwMDA6 MDA6MWMuMDpwY2llMDJdDQpBbGxvY2F0ZSBQb3J0IFNlcnZpY2VbMDAwMDowMDoxYy4wOnBj aWUwM10NClBDSTogU2V0dGluZyBsYXRlbmN5IHRpbWVyIG9mIGRldmljZSAwMDAwOjAwOjFj LjEgdG8gNjQNCmFzc2lnbl9pbnRlcnJ1cHRfbW9kZSBGb3VuZCBNU0kgY2FwYWJpbGl0eQ0K QWxsb2NhdGUgUG9ydCBTZXJ2aWNlWzAwMDA6MDA6MWMuMTpwY2llMDBdDQpBbGxvY2F0ZSBQ b3J0IFNlcnZpY2VbMDAwMDowMDoxYy4xOnBjaWUwMl0NCkFsbG9jYXRlIFBvcnQgU2Vydmlj ZVswMDAwOjAwOjFjLjE6cGNpZTAzXQ0KUENJOiBTZXR0aW5nIGxhdGVuY3kgdGltZXIgb2Yg ZGV2aWNlIDAwMDA6MDA6MWMuMyB0byA2NA0KYXNzaWduX2ludGVycnVwdF9tb2RlIEZvdW5k IE1TSSBjYXBhYmlsaXR5DQpBbGxvY2F0ZSBQb3J0IFNlcnZpY2VbMDAwMDowMDoxYy4zOnBj aWUwMF0NCkFsbG9jYXRlIFBvcnQgU2VydmljZVswMDAwOjAwOjFjLjM6cGNpZTAyXQ0KQWxs b2NhdGUgUG9ydCBTZXJ2aWNlWzAwMDA6MDA6MWMuMzpwY2llMDNdDQpQQ0k6IFNldHRpbmcg bGF0ZW5jeSB0aW1lciBvZiBkZXZpY2UgMDAwMDowMDoxYy41IHRvIDY0DQphc3NpZ25faW50 ZXJydXB0X21vZGUgRm91bmQgTVNJIGNhcGFiaWxpdHkNCkFsbG9jYXRlIFBvcnQgU2Vydmlj ZVswMDAwOjAwOjFjLjU6cGNpZTAwXQ0KQWxsb2NhdGUgUG9ydCBTZXJ2aWNlWzAwMDA6MDA6 MWMuNTpwY2llMDJdDQpBbGxvY2F0ZSBQb3J0IFNlcnZpY2VbMDAwMDowMDoxYy41OnBjaWUw M10NCmlzYXBucDogU2Nhbm5pbmcgZm9yIFBuUCBjYXJkcy4uLg0KaXNhcG5wOiBObyBQbHVn ICYgUGxheSBkZXZpY2UgZm91bmQNClNlcmlhbDogODI1MC8xNjU1MCBkcml2ZXIgJFJldmlz aW9uOiAxLjkwICQgNCBwb3J0cywgSVJRIHNoYXJpbmcgZW5hYmxlZA0KUkFNRElTSyBkcml2 ZXIgaW5pdGlhbGl6ZWQ6IDE2IFJBTSBkaXNrcyBvZiA4MTkySyBzaXplIDEwMjQgYmxvY2tz aXplDQpQTlA6IFBTLzIgQ29udHJvbGxlciBbUE5QMDMwMzpQUzJLLFBOUDBmMTM6UFMyTV0g YXQgMHg2MCwweDY0IGlycSAxLDEyDQpzZXJpbzogaTgwNDIgQVVYIHBvcnQgYXQgMHg2MCww eDY0IGlycSAxMg0Kc2VyaW86IGk4MDQyIEtCRCBwb3J0IGF0IDB4NjAsMHg2NCBpcnEgMQ0K bWljZTogUFMvMiBtb3VzZSBkZXZpY2UgY29tbW9uIGZvciBhbGwgbWljZQ0KVENQIGJpYyBy ZWdpc3RlcmVkDQpORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDENCk5FVDogUmVn aXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTcNCk5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBm YW1pbHkgOA0KTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAyMA0KU3RhcnRpbmcg YmFsYW5jZWRfaXJxDQpVc2luZyBJUEkgTm8tU2hvcnRjdXQgbW9kZQ0KQUNQSTogKHN1cHBv cnRzIFMwIFMzIFM0IFM1KQ0KRnJlZWluZyB1bnVzZWQga2VybmVsIG1lbW9yeTogMTk2ayBm cmVlZA0KVGltZTogdHNjIGNsb2Nrc291cmNlIGhhcyBiZWVuIGluc3RhbGxlZC4NCmlucHV0 OiBBVCBUcmFuc2xhdGVkIFNldCAyIGtleWJvYXJkIGFzIC9jbGFzcy9pbnB1dC9pbnB1dDAN CkFDUEkgKGV4Y29uZmlnLTA0NTUpOiBEeW5hbWljIFNTRFQgTG9hZCAtIE9lbUlkIFsgUG1S ZWZdIE9lbVRhYmxlSWQgWyBDcHUwSXN0XSBbMjAwNjA3MDddDQpBQ1BJIChleGNvbmZpZy0w NDU1KTogRHluYW1pYyBTU0RUIExvYWQgLSBPZW1JZCBbIFBtUmVmXSBPZW1UYWJsZUlkIFsg Q3B1MENzdF0gWzIwMDYwNzA3XQ0KQUNQSTogQ1BVMCAocG93ZXIgc3RhdGVzOiBDMVtDMV0g QzJbQzJdIEMzW0MzXSkNCkFDUEk6IFByb2Nlc3NvciBbQ1BVMF0gKHN1cHBvcnRzIDggdGhy b3R0bGluZyBzdGF0ZXMpDQpBQ1BJIChleGNvbmZpZy0wNDU1KTogRHluYW1pYyBTU0RUIExv YWQgLSBPZW1JZCBbIFBtUmVmXSBPZW1UYWJsZUlkIFsgQ3B1MUlzdF0gWzIwMDYwNzA3XQ0K QUNQSSAoZXhjb25maWctMDQ1NSk6IER5bmFtaWMgU1NEVCBMb2FkIC0gT2VtSWQgWyBQbVJl Zl0gT2VtVGFibGVJZCBbIENwdTFDc3RdIFsyMDA2MDcwN10NCkFDUEk6IENQVTEgKHBvd2Vy IHN0YXRlczogQzFbQzFdIEMyW0MyXSBDM1tDM10pDQpBQ1BJOiBQcm9jZXNzb3IgW0NQVTFd IChzdXBwb3J0cyA4IHRocm90dGxpbmcgc3RhdGVzKQ0KQUNQSTogVGhlcm1hbCBab25lIFtU SFJNXSAoNTkgQykNClRpbWU6IGhwZXQgY2xvY2tzb3VyY2UgaGFzIGJlZW4gaW5zdGFsbGVk Lg0KdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgZHJpdmVyIHVzYmZzDQp1c2Jjb3JlOiByZWdp c3RlcmVkIG5ldyBkcml2ZXIgaHViDQpVU0IgVW5pdmVyc2FsIEhvc3QgQ29udHJvbGxlciBJ bnRlcmZhY2UgZHJpdmVyIHYzLjANCkFDUEk6IFBDSSBJbnRlcnJ1cHQgMDAwMDowMDoxYS4w W0FdIC0+IEdTSSAxNiAobGV2ZWwsIGxvdykgLT4gSVJRIDE2OQ0KUENJOiBTZXR0aW5nIGxh dGVuY3kgdGltZXIgb2YgZGV2aWNlIDAwMDA6MDA6MWEuMCB0byA2NA0KdWhjaV9oY2QgMDAw MDowMDoxYS4wOiBVSENJIEhvc3QgQ29udHJvbGxlcg0KdWhjaV9oY2QgMDAwMDowMDoxYS4w OiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDENCnVoY2lf aGNkIDAwMDA6MDA6MWEuMDogaXJxIDE2OSwgaW8gYmFzZSAweDAwMDAxODAwDQp1c2IgdXNi MTogY29uZmlndXJhdGlvbiAjMSBjaG9zZW4gZnJvbSAxIGNob2ljZQ0KaHViIDEtMDoxLjA6 IFVTQiBodWIgZm91bmQNCmh1YiAxLTA6MS4wOiAyIHBvcnRzIGRldGVjdGVkDQppZWVlMTM5 NDogSW5pdGlhbGl6ZWQgY29uZmlnIHJvbSBlbnRyeSBgaXAxMzk0Jw0KU0NTSSBzdWJzeXN0 ZW0gaW5pdGlhbGl6ZWQNCmxpYmF0YSB2ZXJzaW9uIDIuMDAgbG9hZGVkLg0KQUNQSTogUENJ IEludGVycnVwdCAwMDAwOjAwOjFhLjFbQl0gLT4gR1NJIDIxIChsZXZlbCwgbG93KSAtPiBJ UlEgNTgNClBDSTogU2V0dGluZyBsYXRlbmN5IHRpbWVyIG9mIGRldmljZSAwMDAwOjAwOjFh LjEgdG8gNjQNCnVoY2lfaGNkIDAwMDA6MDA6MWEuMTogVUhDSSBIb3N0IENvbnRyb2xsZXIN CnVoY2lfaGNkIDAwMDA6MDA6MWEuMTogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWdu ZWQgYnVzIG51bWJlciAyDQp1aGNpX2hjZCAwMDAwOjAwOjFhLjE6IGlycSA1OCwgaW8gYmFz ZSAweDAwMDAxODIwDQp1c2IgdXNiMjogY29uZmlndXJhdGlvbiAjMSBjaG9zZW4gZnJvbSAx IGNob2ljZQ0KaHViIDItMDoxLjA6IFVTQiBodWIgZm91bmQNCmh1YiAyLTA6MS4wOiAyIHBv cnRzIGRldGVjdGVkDQpBQ1BJOiBQQ0kgSW50ZXJydXB0IDAwMDA6MDA6MWQuMFtBXSAtPiBH U0kgMjMgKGxldmVsLCBsb3cpIC0+IElSUSA2Ng0KUENJOiBTZXR0aW5nIGxhdGVuY3kgdGlt ZXIgb2YgZGV2aWNlIDAwMDA6MDA6MWQuMCB0byA2NA0KdWhjaV9oY2QgMDAwMDowMDoxZC4w OiBVSENJIEhvc3QgQ29udHJvbGxlcg0KdWhjaV9oY2QgMDAwMDowMDoxZC4wOiBuZXcgVVNC IGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDMNCnVoY2lfaGNkIDAwMDA6 MDA6MWQuMDogaXJxIDY2LCBpbyBiYXNlIDB4MDAwMDE4NDANCnVzYiB1c2IzOiBjb25maWd1 cmF0aW9uICMxIGNob3NlbiBmcm9tIDEgY2hvaWNlDQpodWIgMy0wOjEuMDogVVNCIGh1YiBm b3VuZA0KaHViIDMtMDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQNCkFDUEk6IFBDSSBJbnRlcnJ1 cHQgMDAwMDowMDoxZC4xW0JdIC0+IEdTSSAxOSAobGV2ZWwsIGxvdykgLT4gSVJRIDE4NQ0K UENJOiBTZXR0aW5nIGxhdGVuY3kgdGltZXIgb2YgZGV2aWNlIDAwMDA6MDA6MWQuMSB0byA2 NA0KdWhjaV9oY2QgMDAwMDowMDoxZC4xOiBVSENJIEhvc3QgQ29udHJvbGxlcg0KdWhjaV9o Y2QgMDAwMDowMDoxZC4xOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMg bnVtYmVyIDQNCnVoY2lfaGNkIDAwMDA6MDA6MWQuMTogaXJxIDE4NSwgaW8gYmFzZSAweDAw MDAxODYwDQp1c2IgdXNiNDogY29uZmlndXJhdGlvbiAjMSBjaG9zZW4gZnJvbSAxIGNob2lj ZQ0KaHViIDQtMDoxLjA6IFVTQiBodWIgZm91bmQNCmh1YiA0LTA6MS4wOiAyIHBvcnRzIGRl dGVjdGVkDQpBQ1BJOiBQQ0kgSW50ZXJydXB0IDAwMDA6MDA6MWQuMltDXSAtPiBHU0kgMTgg KGxldmVsLCBsb3cpIC0+IElSUSA3NA0KUENJOiBTZXR0aW5nIGxhdGVuY3kgdGltZXIgb2Yg ZGV2aWNlIDAwMDA6MDA6MWQuMiB0byA2NA0KdWhjaV9oY2QgMDAwMDowMDoxZC4yOiBVSENJ IEhvc3QgQ29udHJvbGxlcg0KdWhjaV9oY2QgMDAwMDowMDoxZC4yOiBuZXcgVVNCIGJ1cyBy ZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDUNCnVoY2lfaGNkIDAwMDA6MDA6MWQu MjogaXJxIDc0LCBpbyBiYXNlIDB4MDAwMDE4ODANCnVzYiB1c2I1OiBjb25maWd1cmF0aW9u ICMxIGNob3NlbiBmcm9tIDEgY2hvaWNlDQpodWIgNS0wOjEuMDogVVNCIGh1YiBmb3VuZA0K aHViIDUtMDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQNCmF0YV9waWl4IDAwMDA6MDA6MWYuMjog dmVyc2lvbiAyLjAwDQphdGFfcGlpeCAwMDAwOjAwOjFmLjI6IE1BUCBbIFAwIFAyIElERSBJ REUgXQ0KQUNQSTogUENJIEludGVycnVwdCAwMDAwOjAwOjFmLjJbQl0gLT4gR1NJIDE5IChs ZXZlbCwgbG93KSAtPiBJUlEgMTg1DQpQQ0k6IFNldHRpbmcgbGF0ZW5jeSB0aW1lciBvZiBk ZXZpY2UgMDAwMDowMDoxZi4yIHRvIDY0DQphdGExOiBTQVRBIG1heCBVRE1BLzEzMyBjbWQg MHgxRjAgY3RsIDB4M0Y2IGJtZG1hIDB4MThFMCBpcnEgMTQNCnNjc2kwIDogYXRhX3BpaXgN CmF0YTEuMDA6IEFUQS04LCBtYXggVURNQS8xMDAsIDIzNDQ0MTY0OCBzZWN0b3JzOiBMQkE0 OCBOQ1EgKGRlcHRoIDAvMzIpDQphdGExLjAwOiBhdGExOiBkZXYgMCBtdWx0aSBjb3VudCAx Ng0KYXRhMS4wMDogY29uZmlndXJlZCBmb3IgVURNQS8xMDANCiAgVmVuZG9yOiBBVEEgICAg ICAgTW9kZWw6IEZVSklUU1UgTUhZMjEyMEIgIFJldjogMDAwMA0KICBUeXBlOiAgIERpcmVj dC1BY2Nlc3MgICAgICAgICAgICAgICAgICAgICAgQU5TSSBTQ1NJIHJldmlzaW9uOiAwNQ0K YXRhMjogUEFUQSBtYXggVURNQS8xMDAgY21kIDB4MTcwIGN0bCAweDM3NiBibWRtYSAweDE4 RTggaXJxIDE1DQpzY3NpMSA6IGF0YV9waWl4DQphdGEyLjAwOiBBVEFQSSwgbWF4IFVETUEv MzMNCmF0YTIuMDA6IGNvbmZpZ3VyZWQgZm9yIFVETUEvMzMNCiAgVmVuZG9yOiBPcHRpYXJj ICAgTW9kZWw6IENEUldEVkQgQ1JYODkwQSAgIFJldjogUFgwMg0KICBUeXBlOiAgIENELVJP TSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQU5TSSBTQ1NJIHJldmlzaW9uOiAwNQ0K QUNQSTogUENJIEludGVycnVwdCAwMDAwOjAwOjFhLjdbQ10gLT4gR1NJIDE4IChsZXZlbCwg bG93KSAtPiBJUlEgNzQNClBDSTogU2V0dGluZyBsYXRlbmN5IHRpbWVyIG9mIGRldmljZSAw MDAwOjAwOjFhLjcgdG8gNjQNCmVoY2lfaGNkIDAwMDA6MDA6MWEuNzogRUhDSSBIb3N0IENv bnRyb2xsZXINCmVoY2lfaGNkIDAwMDA6MDA6MWEuNzogbmV3IFVTQiBidXMgcmVnaXN0ZXJl ZCwgYXNzaWduZWQgYnVzIG51bWJlciA2DQplaGNpX2hjZCAwMDAwOjAwOjFhLjc6IGRlYnVn IHBvcnQgMQ0KUENJOiBjYWNoZSBsaW5lIHNpemUgb2YgMzIgaXMgbm90IHN1cHBvcnRlZCBi eSBkZXZpY2UgMDAwMDowMDoxYS43DQplaGNpX2hjZCAwMDAwOjAwOjFhLjc6IGlycSA3NCwg aW8gbWVtIDB4ZjA0MDQwMDANCmVoY2lfaGNkIDAwMDA6MDA6MWEuNzogVVNCIDIuMCBzdGFy dGVkLCBFSENJIDEuMDAsIGRyaXZlciAxMCBEZWMgMjAwNA0KdXNiIHVzYjY6IGNvbmZpZ3Vy YXRpb24gIzEgY2hvc2VuIGZyb20gMSBjaG9pY2UNCmh1YiA2LTA6MS4wOiBVU0IgaHViIGZv dW5kDQpodWIgNi0wOjEuMDogNCBwb3J0cyBkZXRlY3RlZA0KVW5pZm9ybSBNdWx0aS1QbGF0 Zm9ybSBFLUlERSBkcml2ZXIgUmV2aXNpb246IDcuMDBhbHBoYTINCmlkZTogQXNzdW1pbmcg MzNNSHogc3lzdGVtIGJ1cyBzcGVlZCBmb3IgUElPIG1vZGVzOyBvdmVycmlkZSB3aXRoIGlk ZWJ1cz14eA0KQUNQSTogUENJIEludGVycnVwdCAwMDAwOjAwOjFkLjdbQV0gLT4gR1NJIDIz IChsZXZlbCwgbG93KSAtPiBJUlEgNjYNClBDSTogU2V0dGluZyBsYXRlbmN5IHRpbWVyIG9m IGRldmljZSAwMDAwOjAwOjFkLjcgdG8gNjQNCmVoY2lfaGNkIDAwMDA6MDA6MWQuNzogRUhD SSBIb3N0IENvbnRyb2xsZXINCmVoY2lfaGNkIDAwMDA6MDA6MWQuNzogbmV3IFVTQiBidXMg cmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciA3DQplaGNpX2hjZCAwMDAwOjAwOjFk Ljc6IGRlYnVnIHBvcnQgMQ0KUENJOiBjYWNoZSBsaW5lIHNpemUgb2YgMzIgaXMgbm90IHN1 cHBvcnRlZCBieSBkZXZpY2UgMDAwMDowMDoxZC43DQplaGNpX2hjZCAwMDAwOjAwOjFkLjc6 IGlycSA2NiwgaW8gbWVtIDB4ZjA0MDQ0MDANCmVoY2lfaGNkIDAwMDA6MDA6MWQuNzogVVNC IDIuMCBzdGFydGVkLCBFSENJIDEuMDAsIGRyaXZlciAxMCBEZWMgMjAwNA0KdXNiIHVzYjc6 IGNvbmZpZ3VyYXRpb24gIzEgY2hvc2VuIGZyb20gMSBjaG9pY2UNCmh1YiA3LTA6MS4wOiBV U0IgaHViIGZvdW5kDQpodWIgNy0wOjEuMDogNiBwb3J0cyBkZXRlY3RlZA0KQUNQSTogUENJ IEludGVycnVwdCAwMDAwOjA2OjA5LjFbQl0gLT4gR1NJIDE3IChsZXZlbCwgbG93KSAtPiBJ UlEgMTc3DQpvaGNpMTM5NDogZnctaG9zdDA6IE9IQ0ktMTM5NCAxLjEgKFBDSSk6IElSUT1b MTc3XSAgTU1JTz1bZjAzMDIwMDAtZjAzMDI3ZmZdICBNYXggUGFja2V0PVsyMDQ4XSAgSVIv SVQgY29udGV4dHM9WzQvOF0NClNDU0kgZGV2aWNlIHNkYTogMjM0NDQxNjQ4IDUxMi1ieXRl IGhkd3Igc2VjdG9ycyAoMTIwMDM0IE1CKQ0Kc2RhOiBXcml0ZSBQcm90ZWN0IGlzIG9mZg0K c2RhOiBNb2RlIFNlbnNlOiAwMCAzYSAwMCAwMA0KU0NTSSBkZXZpY2Ugc2RhOiBkcml2ZSBj YWNoZTogd3JpdGUgYmFjaw0KU0NTSSBkZXZpY2Ugc2RhOiAyMzQ0NDE2NDggNTEyLWJ5dGUg aGR3ciBzZWN0b3JzICgxMjAwMzQgTUIpDQpzZGE6IFdyaXRlIFByb3RlY3QgaXMgb2ZmDQpz ZGE6IE1vZGUgU2Vuc2U6IDAwIDNhIDAwIDAwDQpTQ1NJIGRldmljZSBzZGE6IGRyaXZlIGNh Y2hlOiB3cml0ZSBiYWNrDQogc2RhOiBzZGExIHNkYTIgPCBzZGE1IHNkYTYgc2RhNyA+IHNk YTMNCnNkIDA6MDowOjA6IEF0dGFjaGVkIHNjc2kgZGlzayBzZGENCnVzYiA2LTE6IG5ldyBo aWdoIHNwZWVkIFVTQiBkZXZpY2UgdXNpbmcgZWhjaV9oY2QgYW5kIGFkZHJlc3MgMg0KdXNi IDYtMTogY29uZmlndXJhdGlvbiAjMSBjaG9zZW4gZnJvbSAxIGNob2ljZQ0KQXR0ZW1wdGlu ZyBtYW51YWwgcmVzdW1lDQpram91cm5hbGQgc3RhcnRpbmcuICBDb21taXQgaW50ZXJ2YWwg NSBzZWNvbmRzDQpFWFQzLWZzOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRh dGEgbW9kZS4NCnVzYiA2LTI6IG5ldyBoaWdoIHNwZWVkIFVTQiBkZXZpY2UgdXNpbmcgZWhj aV9oY2QgYW5kIGFkZHJlc3MgMw0KdXNiIDYtMjogY29uZmlndXJhdGlvbiAjMSBjaG9zZW4g ZnJvbSAxIGNob2ljZQ0KaWVlZTEzOTQ6IEhvc3QgYWRkZWQ6IElEOkJVU1swLTAwOjEwMjNd ICBHVUlEWzAwMWIyNDAwMDA5YTU0MGFdDQp1c2IgNC0yOiBuZXcgbG93IHNwZWVkIFVTQiBk ZXZpY2UgdXNpbmcgdWhjaV9oY2QgYW5kIGFkZHJlc3MgMg0KdXNiIDQtMjogY29uZmlndXJh dGlvbiAjMSBjaG9zZW4gZnJvbSAxIGNob2ljZQ0KYXRrYmQuYzogVW5rbm93biBrZXkgcHJl c3NlZCAodHJhbnNsYXRlZCBzZXQgMiwgY29kZSAweGMwIG9uIGlzYTAwNjAvc2VyaW8wKS4N CmF0a2JkLmM6IFVzZSAnc2V0a2V5Y29kZXMgZTA0MCA8a2V5Y29kZT4nIHRvIG1ha2UgaXQg a25vd24uDQphdGtiZC5jOiBVbmtub3duIGtleSByZWxlYXNlZCAodHJhbnNsYXRlZCBzZXQg MiwgY29kZSAweGMwIG9uIGlzYTAwNjAvc2VyaW8wKS4NCmF0a2JkLmM6IFVzZSAnc2V0a2V5 Y29kZXMgZTA0MCA8a2V5Y29kZT4nIHRvIG1ha2UgaXQga25vd24uDQpzcjA6IHNjc2kzLW1t YyBkcml2ZTogMjR4LzI0eCB3cml0ZXIgY2QvcncgeGEvZm9ybTIgY2RkYSB0cmF5DQpVbmlm b3JtIENELVJPTSBkcml2ZXIgUmV2aXNpb246IDMuMjANCnNyIDE6MDowOjA6IEF0dGFjaGVk IHNjc2kgQ0QtUk9NIHNyMA0KZXRoMTM5NDogZXRoMDogSUVFRS0xMzk0IElQdjQgb3ZlciAx Mzk0IEV0aGVybmV0IChmdy1ob3N0MCkNCkFDUEk6IFBDSSBJbnRlcnJ1cHQgMDAwMDowNTow MC4wW0FdIC0+IEdTSSAxNyAobGV2ZWwsIGxvdykgLT4gSVJRIDE3Nw0KUENJOiBTZXR0aW5n IGxhdGVuY3kgdGltZXIgb2YgZGV2aWNlIDAwMDA6MDU6MDAuMCB0byA2NA0Kc2t5MiB2MS41 IGFkZHIgMHg4YTAwMDAwMCBpcnEgMTc3IFl1a29uLUVDIFVsdHJhICgweGI0KSByZXYgMg0K c2t5MiBldGgxOiBhZGRyIDAwOjFlOjY4OjRlOmU1OjJkDQppbnB1dDogUEMgU3BlYWtlciBh cyAvY2xhc3MvaW5wdXQvaW5wdXQxDQpSZWFsIFRpbWUgQ2xvY2sgRHJpdmVyIHYxLjEyYWMN CnNkaGNpOiBTZWN1cmUgRGlnaXRhbCBIb3N0IENvbnRyb2xsZXIgSW50ZXJmYWNlIGRyaXZl ciwgMC4xMg0Kc2RoY2k6IENvcHlyaWdodChjKSBQaWVycmUgT3NzbWFuDQpzZGhjaTogU0RI Q0kgY29udHJvbGxlciBmb3VuZCBhdCAwMDAwOjA2OjA5LjMgWzEwNGM6ODAzY10gKHJldiAw KQ0KQUNQSTogUENJIEludGVycnVwdCAwMDAwOjA2OjA5LjNbQl0gLT4gR1NJIDE3IChsZXZl bCwgbG93KSAtPiBJUlEgMTc3DQptbWMwOiBTREhDSSBhdCAweGYwMzAyODAwIGlycSAxNzcg RE1BDQpzZCAwOjA6MDowOiBBdHRhY2hlZCBzY3NpIGdlbmVyaWMgc2cwIHR5cGUgMA0Kc3Ig MTowOjA6MDogQXR0YWNoZWQgc2NzaSBnZW5lcmljIHNnMSB0eXBlIDUNCnVzYmNvcmU6IHJl Z2lzdGVyZWQgbmV3IGRyaXZlciBoaWRkZXYNCmlucHV0OiBNaWNyb3NvZnQgTWljcm9zb2Z0 IDMtQnV0dG9uIE1vdXNlIHdpdGggSW50ZWxsaUV5ZShUTSkgYXMgL2NsYXNzL2lucHV0L2lu cHV0Mg0KaW5wdXQ6IFVTQiBISUQgdjEuMTAgTW91c2UgW01pY3Jvc29mdCBNaWNyb3NvZnQg My1CdXR0b24gTW91c2Ugd2l0aCBJbnRlbGxpRXllKFRNKV0gb24gdXNiLTAwMDA6MDA6MWQu MS0yDQp1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBkcml2ZXIgdXNiaGlkDQpkcml2ZXJzL3Vz Yi9pbnB1dC9oaWQtY29yZS5jOiB2Mi42OlVTQiBISUQgY29yZSBkcml2ZXINCkFDUEk6IFBD SSBJbnRlcnJ1cHQgMDAwMDowMDoxZi4zW0NdIC0+IEdTSSAxOSAobGV2ZWwsIGxvdykgLT4g SVJRIDE4NQ0KWWVudGE6IENhcmRCdXMgYnJpZGdlIGZvdW5kIGF0IDAwMDA6MDY6MDkuMCBb MTdmZjowNTkwXQ0KWWVudGE6IEVuYWJsaW5nIGJ1cnN0IG1lbW9yeSByZWFkIHRyYW5zYWN0 aW9ucw0KWWVudGE6IFVzaW5nIENTQ0lOVCB0byByb3V0ZSBDU0MgaW50ZXJydXB0cyB0byBQ Q0kNClllbnRhOiBSb3V0aW5nIENhcmRCdXMgaW50ZXJydXB0cyB0byBQQ0kNClllbnRhIFRJ OiBzb2NrZXQgMDAwMDowNjowOS4wLCBtZnVuYyAweDAxYWExYjIyLCBkZXZjdGwgMHg2NA0K dHM6IENvbXBhcSB0b3VjaHNjcmVlbiBwcm90b2NvbCBvdXRwdXQNCkFDUEk6IFBDSSBJbnRl cnJ1cHQgMDAwMDowMDoxYi4wW0FdIC0+IEdTSSAyMiAobGV2ZWwsIGxvdykgLT4gSVJRIDkw DQpQQ0k6IFNldHRpbmcgbGF0ZW5jeSB0aW1lciBvZiBkZXZpY2UgMDAwMDowMDoxYi4wIHRv IDY0DQpZZW50YTogSVNBIElSUSBtYXNrIDB4MGNmOCwgUENJIGlycSAxOTMNClNvY2tldCBz dGF0dXM6IDMwMDAwMDA2DQpZZW50YTogUmFpc2luZyBzdWJvcmRpbmF0ZSBidXMjIG9mIHBh cmVudCBidXMgKCMwNikgZnJvbSAjMDcgdG8gIzBhDQpwY21jaWE6IHBhcmVudCBQQ0kgYnJp ZGdlIEkvTyB3aW5kb3c6IDB4NDAwMCAtIDB4NGZmZg0KY3M6IElPIHBvcnQgcHJvYmUgMHg0 MDAwLTB4NGZmZjogY2xlYW4uDQpwY21jaWE6IHBhcmVudCBQQ0kgYnJpZGdlIE1lbW9yeSB3 aW5kb3c6IDB4ZjAzMDAwMDAgLSAweGYwM2ZmZmZmDQpwY21jaWE6IHBhcmVudCBQQ0kgYnJp ZGdlIE1lbW9yeSB3aW5kb3c6IDB4ODgwMDAwMDAgLSAweDg5ZmZmZmZmDQpoZGFfY29kZWM6 IFVua25vd24gbW9kZWwgZm9yIEFMQzI2MiwgdHJ5aW5nIGF1dG8tcHJvYmUgZnJvbSBCSU9T Li4uDQpTeW5hcHRpY3MgVG91Y2hwYWQsIG1vZGVsOiAxLCBmdzogNS4xMCwgaWQ6IDB4MjU4 ZWIxLCBjYXBzOiAweGEwNDcxMS8weDANCmlucHV0OiBTeW5QUy8yIFN5bmFwdGljcyBUb3Vj aFBhZCBhcyAvY2xhc3MvaW5wdXQvaW5wdXQzDQpjczogSU8gcG9ydCBwcm9iZSAweDEwMC0w eDNhZjogZXhjbHVkaW5nIDB4MzcwLTB4Mzc3DQpjczogSU8gcG9ydCBwcm9iZSAweDNlMC0w eDRmZjogZXhjbHVkaW5nIDB4M2YwLTB4M2Y3IDB4NGQwLTB4NGQ3DQpjczogSU8gcG9ydCBw cm9iZSAweDgyMC0weDhmZjogY2xlYW4uDQpjczogSU8gcG9ydCBwcm9iZSAweGMwMC0weGNm NzogY2xlYW4uDQpjczogSU8gcG9ydCBwcm9iZSAweGEwMC0weGFmZjogY2xlYW4uDQpBZGRp bmcgOTE1NjMyayBzd2FwIG9uIC9kZXYvc2RhNi4gIFByaW9yaXR5Oi0xIGV4dGVudHM6MSBh Y3Jvc3M6OTE1NjMyaw0KRVhUMyBGUyBvbiBzZGEzLCBpbnRlcm5hbCBqb3VybmFsDQpsb29w OiBsb2FkZWQgKG1heCA4IGRldmljZXMpDQppZWVlMTM5NDogc2JwMjogRHJpdmVyIGZvcmNl ZCB0byBzZXJpYWxpemUgSS9PIChzZXJpYWxpemVfaW89MSkNCmllZWUxMzk0OiBzYnAyOiBU cnkgc2VyaWFsaXplX2lvPTAgZm9yIGJldHRlciBwZXJmb3JtYW5jZQ0KZGV2aWNlLW1hcHBl cjogaW9jdGw6IDQuNy4wLWlvY3RsICgyMDA2LTA2LTI0KSBpbml0aWFsaXNlZDogZG0tZGV2 ZWxAcmVkaGF0LmNvbQ0Ka2pvdXJuYWxkIHN0YXJ0aW5nLiAgQ29tbWl0IGludGVydmFsIDUg c2Vjb25kcw0KRVhUMyBGUyBvbiBzZGE3LCBpbnRlcm5hbCBqb3VybmFsDQpFWFQzLWZzOiBt b3VudGVkIGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZS4NCnNreTIgZXRoMTog ZW5hYmxpbmcgaW50ZXJmYWNlDQpBQ1BJOiBCYXR0ZXJ5IFNsb3QgW0JBVDFdIChiYXR0ZXJ5 IHByZXNlbnQpDQpBQ1BJOiBBQyBBZGFwdGVyIFtBQ0FEXSAob24tbGluZSkNCkFDUEk6IFBv d2VyIEJ1dHRvbiAoRkYpIFtQV1JGXQ0KQUNQSTogTGlkIFN3aXRjaCBbTElEXQ0KQUNQSTog UG93ZXIgQnV0dG9uIChDTSkgW1BXUkJdDQpBQ1BJOiBTbGVlcCBCdXR0b24gKENNKSBbU0xQ Ql0NCnNreTIgZXRoMTogTGluayBpcyB1cCBhdCAxMDAwIE1icHMsIGZ1bGwgZHVwbGV4LCBm bG93IGNvbnRyb2wgbm9uZQ0KTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxMA0K bG86IERpc2FibGVkIFByaXZhY3kgRXh0ZW5zaW9ucw0KSVB2NiBvdmVyIElQdjQgdHVubmVs aW5nIGRyaXZlcg0KZXRoMTogbm8gSVB2NiByb3V0ZXJzIHByZXNlbnQ= From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 19:02:44 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAC79106566B for ; Mon, 15 Sep 2008 19:02:44 +0000 (UTC) (envelope-from army.of.root@googlemail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 3CE348FC1E for ; Mon, 15 Sep 2008 19:02:43 +0000 (UTC) (envelope-from army.of.root@googlemail.com) Received: by fg-out-1718.google.com with SMTP id l26so1434787fgb.35 for ; Mon, 15 Sep 2008 12:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=iEEtcg4AWnM5ORd+FLu6a3a8G92aOiKhe9PQDIul3OM=; b=vr4kTr1trMYwJYjMPpsK8p1ogjuawzH8wzaqwSfMWEr5rxyHrEi9d7Gxoi9FPenyik czraG4/vKbPtv1GcsNiwBgsk6DfUKpiqgUiClSD2kvIAmJTHtYLjQ8BF+Mv5Zs1Tg1Qg NelrR1oCKKt5KVgIqlATaWZ4pvPK/jFGsjYL8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=DWzjScu5+0M5IMGETU77CeClnuY5btCcIAwSw92+pattAWNo58RadE22z8DddlndmV 8GB2UOh0KgBLILLoLbvHypH/VGTQeBGLnmkgYppbDNoPiQbTzfJAPN50j1xlEC+m3lqB 36Bjz71lohe0FwcD1wSliqkn4D1FE6niH5LUo= Received: by 10.180.231.20 with SMTP id d20mr5853829bkh.11.1221505362485; Mon, 15 Sep 2008 12:02:42 -0700 (PDT) Received: from ?192.168.2.18? ( [84.134.250.133]) by mx.google.com with ESMTPS id 21sm14151183fkx.13.2008.09.15.12.02.40 (version=SSLv3 cipher=RC4-MD5); Mon, 15 Sep 2008 12:02:41 -0700 (PDT) Message-ID: <48CEB155.1020800@googlemail.com> Date: Mon, 15 Sep 2008 21:02:45 +0200 From: "army.of.root@googlemail.com" User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Alexander Motin References: <48CBF399.9080801@FreeBSD.org> <20080913201513.71995150@deskjail> <48CC0867.9020208@FreeBSD.org> In-Reply-To: <48CC0867.9020208@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 15 Sep 2008 19:19:35 +0000 Cc: freebsd-multimedia@FreeBSD.org, Alexander Leidinger , freebsd-current@freebsd.org, ariff@freebsd.org Subject: Re: New snd_hda driver came in. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 19:02:44 -0000 Alexander Motin schrieb: > Alexander Leidinger wrote: >>> New driver supports digital PCM playback and AC3 pass-through. I am >>> not sure about completeness of this implementation, but I have >>> several success stories including my own. Vchans subsystem does not >>> support AC3 pass-through so it had to be disabled for that devices >>> at this moment. >> >> As vchans is our internal many-to-one (physical output) mixer, and the >> fact that digital out can be anything (PCM, AC3, ...) I think a >> sensible default for vchans would be to ignore digital interfaces. I >> don't know if this is easy to do or not. > > As soon as AC3 is a separate stream format and vchans has info about > it, better solution would be to make vchans mute other streams, switch > hardware device to the AC3 stream sample rate and pass it though. For > usual PCM streams in such case mixing would work as before, that would > be good. > Is there a chance for an inofficial backport to 7 ? I really would like microphone rec to work with my HDA-Controller. Many Thanks for the great work! I love FreeBSD :) From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 19:29:01 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 676E71065683 for ; Mon, 15 Sep 2008 19:29:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id C98128FC1E for ; Mon, 15 Sep 2008 19:29:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8FJRe5j082601; Mon, 15 Sep 2008 15:28:54 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 15 Sep 2008 15:22:08 -0400 User-Agent: KMail/1.9.7 References: <48CE59C2.9060307@icyb.net.ua> <48CE91AB.3000200@icyb.net.ua> <9D0F7169-9461-4F32-9420-702BED840A20@mac.com> In-Reply-To: <9D0F7169-9461-4F32-9420-702BED840A20@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809151522.08679.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Mon, 15 Sep 2008 15:28:54 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8249/Mon Sep 15 12:31:36 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Marcel Moolenaar , Andriy Gapon Subject: Re: sio => uart: one port is gone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 19:29:01 -0000 On Monday 15 September 2008 12:55:33 pm Marcel Moolenaar wrote: > > On Sep 15, 2008, at 9:47 AM, Andriy Gapon wrote: > > > on 15/09/2008 19:41 Marcel Moolenaar said the following: > >> So, if you compile acpi(4) as a module, you must compile all > >> it's depending drivers as modules as well. Or you compile acpi > >> into the kernel... > > > > I understand the logic, but OTOH uart can work without acpi too, so > > it's not a strict dependency. > > Well, yes. That's what's causing your "problem". You compile a > kernel without acpi but with uart. As such, uart will be built > without acpi support. uart does indeed work without acpi. > > The problem is that people then load the acpi module at runtime > and expect uart to work with acpi. That's not going to fly. If > one builds uart as a module, all possible support is included > and it works as expected. > > > Also, this (acpi dependency) doesn't seem to be documented. > > It's standard behaviour. The problem is that right now we ship with acpi.ko as a module by default and have the loader auto-load acpi.ko IFF the machine supports ACPI. Considering how cheap a bus attachment is, I find this argument rather rediculous. If you are building uart into the kernel on i386, just always include the acpi attachment. Other drivers give a more sane user experience. GENERIC should DTRT out-of-the-box, for example. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 20:11:16 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39D051065694 for ; Mon, 15 Sep 2008 20:11:16 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout014.mac.com (asmtpout014.mac.com [17.148.16.89]) by mx1.freebsd.org (Postfix) with ESMTP id 3B4F88FC15 for ; Mon, 15 Sep 2008 20:11:15 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from vghiya-t60.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp014.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0K7900BOR6QQNZ10@asmtp014.mac.com>; Mon, 15 Sep 2008 13:11:15 -0700 (PDT) Message-id: <1A6B5018-ABC9-4612-A66A-1A6D21336619@mac.com> From: Marcel Moolenaar To: Andriy Gapon In-reply-to: <48CEBF42.3060901@icyb.net.ua> Date: Mon, 15 Sep 2008 13:11:14 -0700 References: <48CE59C2.9060307@icyb.net.ua> <48CE91AB.3000200@icyb.net.ua> <9D0F7169-9461-4F32-9420-702BED840A20@mac.com> <200809151522.08679.jhb@freebsd.org> <48CEBF42.3060901@icyb.net.ua> X-Mailer: Apple Mail (2.928.1) Cc: freebsd-current@freebsd.org Subject: Re: sio => uart: one port is gone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 20:11:16 -0000 On Sep 15, 2008, at 1:02 PM, Andriy Gapon wrote: > --- a/sys/conf/files > +++ b/sys/conf/files > @@ -1080,7 +1080,7 @@ dev/twe/twe.c optional twe > dev/twe/twe_freebsd.c optional twe > dev/tx/if_tx.c optional tx > dev/txp/if_txp.c optional txp > -dev/uart/uart_bus_acpi.c optional uart acpi > +dev/uart/uart_bus_acpi.c optional uart > #dev/uart/uart_bus_cbus.c optional uart cbus > dev/uart/uart_bus_ebus.c optional uart ebus > dev/uart/uart_bus_isa.c optional uart isa This is exactly the thing we shouldn't be doing. You now compile the acpi bus attachment on platforms that don't even have acpi. This is not a fix, it's a breakage... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 20:13:14 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EEBC106564A for ; Mon, 15 Sep 2008 20:13:14 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout017.mac.com (asmtpout017.mac.com [17.148.16.92]) by mx1.freebsd.org (Postfix) with ESMTP id 15F818FC18 for ; Mon, 15 Sep 2008 20:13:13 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from vghiya-t60.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp017.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0K790096B6TY7N30@asmtp017.mac.com>; Mon, 15 Sep 2008 13:13:11 -0700 (PDT) Message-id: <3B9B5EED-6627-43F8-A5FC-7B2C7B2D38ED@mac.com> From: Marcel Moolenaar To: John Baldwin In-reply-to: <200809151522.08679.jhb@freebsd.org> Date: Mon, 15 Sep 2008 13:13:10 -0700 References: <48CE59C2.9060307@icyb.net.ua> <48CE91AB.3000200@icyb.net.ua> <9D0F7169-9461-4F32-9420-702BED840A20@mac.com> <200809151522.08679.jhb@freebsd.org> X-Mailer: Apple Mail (2.928.1) Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: sio => uart: one port is gone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 20:13:14 -0000 On Sep 15, 2008, at 12:22 PM, John Baldwin wrote: > On Monday 15 September 2008 12:55:33 pm Marcel Moolenaar wrote: >> >> On Sep 15, 2008, at 9:47 AM, Andriy Gapon wrote: >> >>> on 15/09/2008 19:41 Marcel Moolenaar said the following: >>>> So, if you compile acpi(4) as a module, you must compile all >>>> it's depending drivers as modules as well. Or you compile acpi >>>> into the kernel... >>> >>> I understand the logic, but OTOH uart can work without acpi too, so >>> it's not a strict dependency. >> >> Well, yes. That's what's causing your "problem". You compile a >> kernel without acpi but with uart. As such, uart will be built >> without acpi support. uart does indeed work without acpi. >> >> The problem is that people then load the acpi module at runtime >> and expect uart to work with acpi. That's not going to fly. If >> one builds uart as a module, all possible support is included >> and it works as expected. >> >>> Also, this (acpi dependency) doesn't seem to be documented. >> >> It's standard behaviour. > > The problem is that right now we ship with acpi.ko as a module by > default and > have the loader auto-load acpi.ko IFF the machine supports ACPI. Well, don't do that then. Just have the device probe check if acpi is supported and attach if yes. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 20:16:32 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4AEB1065687 for ; Mon, 15 Sep 2008 20:16:32 +0000 (UTC) (envelope-from cracauer@koef.zs64.net) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id 7A0338FC1C for ; Mon, 15 Sep 2008 20:16:32 +0000 (UTC) (envelope-from cracauer@koef.zs64.net) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by koef.zs64.net (8.14.3/8.14.3) with ESMTP id m8FJoLn4069663; Mon, 15 Sep 2008 21:50:21 +0200 (CEST) (envelope-from cracauer@koef.zs64.net) Received: (from cracauer@localhost) by koef.zs64.net (8.14.3/8.14.3/Submit) id m8FJoLLa069662; Mon, 15 Sep 2008 15:50:21 -0400 (EDT) (envelope-from cracauer) Date: Mon, 15 Sep 2008 15:50:21 -0400 From: Martin Cracauer To: Stephen Montgomery-Smith Message-ID: <20080915195021.GA69528@cons.org> References: <48CDBC78.4010409@math.missouri.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48CDBC78.4010409@math.missouri.edu> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Improved multiprocessor usage on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 20:16:33 -0000 Stephen Montgomery-Smith wrote on Sun, Sep 14, 2008 at 08:38:00PM -0500: > I have a dual core amd64 on which I run a processor intensive numerical > program. I had been frustrated because it seemed to run 3 or 4 times > faster under Linux. But with a recent upgrade of FreeBSD-CURRENT, it > now goes at about the same speed as Linux. Are the threads meant to provide additional CPU resources or help with concurrency/IO issues? Do you create a lot of new threads on the fly? What kind of worker model do you have there? Do you have about as many threads as processor or more? How malloc intensive is it? Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 20:43:33 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D83A106567E for ; Mon, 15 Sep 2008 20:43:33 +0000 (UTC) (envelope-from pfgshield-freebsd@yahoo.com) Received: from web32701.mail.mud.yahoo.com (web32701.mail.mud.yahoo.com [68.142.207.245]) by mx1.freebsd.org (Postfix) with SMTP id C85858FC0C for ; Mon, 15 Sep 2008 20:43:32 +0000 (UTC) (envelope-from pfgshield-freebsd@yahoo.com) Received: (qmail 54799 invoked by uid 60001); 15 Sep 2008 20:43:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=OMrAYdMYxIY0YXYjnKq37BlPU2lX/ussgLdxclkVU3SJwy0rnMDtmaqTKWkPer0AJeWsRUH6Q6ioWSacOYDbkoRlIdXB+0+IMnwCtWOq+db57O671ZLlTQxUaHL8EmyBgW4gQ3S5LzeLH27Twig4/fr1nnfqT4CdTKhDPM3xs70=; X-YMail-OSG: yEha468VM1l0oFYtwjFJu6606yF9b_q3LDprWqjft2m8ol8Q9rAsFxa3So7v2KguXQFxQ1vgYJDzlv3lWgeO2MrieBDrKBn_KwcOVhCRoapvI9Ml2EMDqWbEoHH8kJh6wFNEOXKIp5oWqxuyo4kzOt4- Received: from [190.158.44.173] by web32701.mail.mud.yahoo.com via HTTP; Mon, 15 Sep 2008 13:43:31 PDT X-Mailer: YahooMailWebService/0.7.218.2 Date: Mon, 15 Sep 2008 13:43:31 -0700 (PDT) From: Pedro Giffuni To: Jung-uk Kim MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <179579.54770.qm@web32701.mail.mud.yahoo.com> X-Mailman-Approved-At: Mon, 15 Sep 2008 20:50:28 +0000 Cc: Oliver Fromme , freebsd-current@freebsd.org, Xin LI Subject: Re: Why VESA and DPMS are available only for i386? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pfgshield-freebsd@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 20:43:33 -0000 On Mon, Sep 15, 2008 at 1:32 PM, Jung-uk Kim wrote: ... >> Another way would be to write a 32bit x86 instruction >> emulator (similar to what programs like qemu or bochs do), >> so you can execute the VESA functions within an emulated >> virtual machine that programs the VGA hardware registers. >> This isn't exactly trivial either. Note that there are >> already such emulators, but I'm not aware of a BSD-licensed >> one that could be included in the FreeBSD kernel without >> problems. > > doscmd(1) had a rudimentary 16-bit CPU emulation: > FWIW, I can't find any reference, but according to the Wikipedia, even in long mo= de AMD64 is able to run 16-bit (or 80286) protected mode applications: http://en.wikipedia.org/wiki/AMD64#Operating_modes Pedro.=0A=0A__________________________________________________=0ADo You Yah= oo!?=0APoco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da= tanto spazio gratuito per i tuoi file e i messaggi =0Ahttp://mail.yahoo.it= From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 21:10:27 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF2E51065677; Mon, 15 Sep 2008 21:10:27 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from hosted.kievnet.com (hosted.kievnet.com [193.138.144.10]) by mx1.freebsd.org (Postfix) with ESMTP id 82D638FC0A; Mon, 15 Sep 2008 21:10:27 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost ([127.0.0.1] helo=edge.pp.kiev.ua) by hosted.kievnet.com with esmtpa (Exim 4.62) (envelope-from ) id 1KfKH1-000Cmh-TJ; Mon, 15 Sep 2008 23:02:15 +0300 Message-ID: <48CEBF42.3060901@icyb.net.ua> Date: Mon, 15 Sep 2008 23:02:10 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.16 (X11/20080821) MIME-Version: 1.0 To: John Baldwin References: <48CE59C2.9060307@icyb.net.ua> <48CE91AB.3000200@icyb.net.ua> <9D0F7169-9461-4F32-9420-702BED840A20@mac.com> <200809151522.08679.jhb@freebsd.org> In-Reply-To: <200809151522.08679.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Marcel Moolenaar Subject: Re: sio => uart: one port is gone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 21:10:27 -0000 on 15/09/2008 22:22 John Baldwin said the following: > The problem is that right now we ship with acpi.ko as a module by default and > have the loader auto-load acpi.ko IFF the machine supports ACPI. Considering > how cheap a bus attachment is, I find this argument rather rediculous. If > you are building uart into the kernel on i386, just always include the acpi > attachment. Other drivers give a more sane user experience. GENERIC should > DTRT out-of-the-box, for example. John, thank you for the idea, the following trivial patch did it for me. --- a/sys/conf/files +++ b/sys/conf/files @@ -1080,7 +1080,7 @@ dev/twe/twe.c optional twe dev/twe/twe_freebsd.c optional twe dev/tx/if_tx.c optional tx dev/txp/if_txp.c optional txp -dev/uart/uart_bus_acpi.c optional uart acpi +dev/uart/uart_bus_acpi.c optional uart #dev/uart/uart_bus_cbus.c optional uart cbus dev/uart/uart_bus_ebus.c optional uart ebus dev/uart/uart_bus_isa.c optional uart isa dmesg: uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart1: <16550 or compatible> port 0x2e8-0x2ef irq 3 on acpi0 uart1: [FILTER] -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 21:11:49 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E1931065686 for ; Mon, 15 Sep 2008 21:11:49 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from hosted.kievnet.com (hosted.kievnet.com [193.138.144.10]) by mx1.freebsd.org (Postfix) with ESMTP id D6E458FC17 for ; Mon, 15 Sep 2008 21:11:48 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost ([127.0.0.1] helo=edge.pp.kiev.ua) by hosted.kievnet.com with esmtpa (Exim 4.62) (envelope-from ) id 1KfKLF-000Ctj-Es; Mon, 15 Sep 2008 23:06:37 +0300 Message-ID: <48CEC04C.8000707@icyb.net.ua> Date: Mon, 15 Sep 2008 23:06:36 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.16 (X11/20080821) MIME-Version: 1.0 To: Marcel Moolenaar References: <48CE59C2.9060307@icyb.net.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Ian Smith , Mike Tancsa Subject: Re: sio => uart: one port is gone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 21:11:49 -0000 on 15/09/2008 18:58 Marcel Moolenaar said the following: > > On Sep 15, 2008, at 5:49 AM, Andriy Gapon wrote: > [snip] >> >> This is what I have in device.hints for uart: >> hint.uart.0.at="isa" >> hint.uart.0.port="0x3F8" >> hint.uart.0.flags="0x10" >> hint.uart.0.irq="4" >> hint.uart.1.at="isa" >> hint.uart.1.port="0x2F8" >> hint.uart.1.irq="3" >> hint.uart.2.at="isa" >> >> Precisely the same hints (s/uart/sio/) I had for sio. > > The hints are bogus. [snip] BTW, I think that the following patch should be applied (made against RELENG_7): --- a/sys/i386/conf/GENERIC.hints +++ b/sys/i386/conf/GENERIC.hints @@ -39,7 +39,7 @@ hint.sio.0.flags="0x10" hint.sio.0.irq="4" hint.sio.1.at="isa" -hint.sio.1.port="0x2F8" +hint.sio.1.port="0x2E8" hint.sio.1.irq="3" hint.sio.2.at="isa" hint.sio.2.disabled="1" This is from where I copied the wrong hint. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 21:27:40 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86BC5106564A; Mon, 15 Sep 2008 21:27:40 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe14.swipnet.se [212.247.155.161]) by mx1.freebsd.org (Postfix) with ESMTP id D45EC8FC0A; Mon, 15 Sep 2008 21:27:39 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=ZtwMFzhc6XSROYQlMkMA/A==:17 a=6I5d2MoRAAAA:8 a=Bk7slgqha-BLT9f5N6YA:9 a=Acbs0XiD0vLjvXcHcXmhI6vK9c4A:4 a=50e4U0PicR4A:10 Received: from [62.113.133.218] (account mc467741@c2i.net [62.113.133.218] verified) by mailfe14.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 336589341; Mon, 15 Sep 2008 22:27:36 +0200 From: Hans Petter Selasky To: ticso@cicely.de Date: Mon, 15 Sep 2008 22:29:25 +0200 User-Agent: KMail/1.9.7 References: <200809112044.43749.hselasky@c2i.net> <48CB3D09.4050908@elischer.org> <20080913170845.GT1147@cicely7.cicely.de> In-Reply-To: <20080913170845.GT1147@cicely7.cicely.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809152229.28590.hselasky@c2i.net> Cc: rink@freebsd.org, current@freebsd.org, fbsd-current@mawer.org, Julian Elischer , freebsd-usb@freebsd.org, volker@vwsoft.com, "M. Warner Losh" Subject: Re: "legacy" usb stack fixes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 21:27:40 -0000 Hi, Please find a link to my implementation. Panics when unplugging USB Mass Storage Devices is now a thing of the past, I hope. Any comments ? http://perforce.freebsd.org/chv.cgi?CH=149821 --HPS From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 21:32:27 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BCEA1065673; Mon, 15 Sep 2008 21:32:27 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 2AD3C8FC0A; Mon, 15 Sep 2008 21:32:26 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local ([192.168.254.200]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id m8FLW26e078675; Mon, 15 Sep 2008 15:32:03 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <48CED452.6020709@samsco.org> Date: Mon, 15 Sep 2008 15:32:02 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Hans Petter Selasky References: <200809112044.43749.hselasky@c2i.net> <48CB3D09.4050908@elischer.org> <20080913170845.GT1147@cicely7.cicely.de> <200809152229.28590.hselasky@c2i.net> In-Reply-To: <200809152229.28590.hselasky@c2i.net> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: rink@freebsd.org, current@freebsd.org, fbsd-current@mawer.org, Julian Elischer , freebsd-usb@freebsd.org, volker@vwsoft.com, ticso@cicely.de, "M. Warner Losh" Subject: Re: "legacy" usb stack fixes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 21:32:27 -0000 Hans Petter Selasky wrote: > Hi, > > Please find a link to my implementation. Panics when unplugging USB Mass > Storage Devices is now a thing of the past, I hope. Any comments ? > > http://perforce.freebsd.org/chv.cgi?CH=149821 > > --HPS So you're sticking with a SIM per umass target, and adding a global lock? Scott From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 22:09:56 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AEB1106567F for ; Mon, 15 Sep 2008 22:09:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id AAAE08FC0C for ; Mon, 15 Sep 2008 22:09:50 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8FM9bCJ083996; Mon, 15 Sep 2008 18:09:44 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Marcel Moolenaar Date: Mon, 15 Sep 2008 18:07:45 -0400 User-Agent: KMail/1.9.7 References: <48CE59C2.9060307@icyb.net.ua> <200809151522.08679.jhb@freebsd.org> <3B9B5EED-6627-43F8-A5FC-7B2C7B2D38ED@mac.com> In-Reply-To: <3B9B5EED-6627-43F8-A5FC-7B2C7B2D38ED@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809151807.45844.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Mon, 15 Sep 2008 18:09:44 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8251/Mon Sep 15 16:23:40 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: sio => uart: one port is gone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 22:09:56 -0000 On Monday 15 September 2008 04:13:10 pm Marcel Moolenaar wrote: > > On Sep 15, 2008, at 12:22 PM, John Baldwin wrote: > > > On Monday 15 September 2008 12:55:33 pm Marcel Moolenaar wrote: > >> > >> On Sep 15, 2008, at 9:47 AM, Andriy Gapon wrote: > >> > >>> on 15/09/2008 19:41 Marcel Moolenaar said the following: > >>>> So, if you compile acpi(4) as a module, you must compile all > >>>> it's depending drivers as modules as well. Or you compile acpi > >>>> into the kernel... > >>> > >>> I understand the logic, but OTOH uart can work without acpi too, so > >>> it's not a strict dependency. > >> > >> Well, yes. That's what's causing your "problem". You compile a > >> kernel without acpi but with uart. As such, uart will be built > >> without acpi support. uart does indeed work without acpi. > >> > >> The problem is that people then load the acpi module at runtime > >> and expect uart to work with acpi. That's not going to fly. If > >> one builds uart as a module, all possible support is included > >> and it works as expected. > >> > >>> Also, this (acpi dependency) doesn't seem to be documented. > >> > >> It's standard behaviour. > > > > The problem is that right now we ship with acpi.ko as a module by > > default and > > have the loader auto-load acpi.ko IFF the machine supports ACPI. > > Well, don't do that then. Just have the device probe check if acpi is > supported and attach if yes. It does that, the loader stuff is from someone trying to be fancy and save the memory of not having acpi.ko around if the system doesn't support it. This may in fact be dubious. :) -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 22:09:56 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9981106566C for ; Mon, 15 Sep 2008 22:09:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 615C68FC14 for ; Mon, 15 Sep 2008 22:09:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8FM9bCK083996; Mon, 15 Sep 2008 18:09:50 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Marcel Moolenaar Date: Mon, 15 Sep 2008 18:08:33 -0400 User-Agent: KMail/1.9.7 References: <48CE59C2.9060307@icyb.net.ua> <48CEBF42.3060901@icyb.net.ua> <1A6B5018-ABC9-4612-A66A-1A6D21336619@mac.com> In-Reply-To: <1A6B5018-ABC9-4612-A66A-1A6D21336619@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809151808.33400.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Mon, 15 Sep 2008 18:09:50 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8251/Mon Sep 15 16:23:40 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: sio => uart: one port is gone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 22:09:56 -0000 On Monday 15 September 2008 04:11:14 pm Marcel Moolenaar wrote: > > On Sep 15, 2008, at 1:02 PM, Andriy Gapon wrote: > > > --- a/sys/conf/files > > +++ b/sys/conf/files > > @@ -1080,7 +1080,7 @@ dev/twe/twe.c optional twe > > dev/twe/twe_freebsd.c optional twe > > dev/tx/if_tx.c optional tx > > dev/txp/if_txp.c optional txp > > -dev/uart/uart_bus_acpi.c optional uart acpi > > +dev/uart/uart_bus_acpi.c optional uart > > #dev/uart/uart_bus_cbus.c optional uart cbus > > dev/uart/uart_bus_ebus.c optional uart ebus > > dev/uart/uart_bus_isa.c optional uart isa > > This is exactly the thing we shouldn't be doing. > > You now compile the acpi bus attachment on platforms > that don't even have acpi. This is not a fix, it's > a breakage... You can change it in sys/conf/files.i386 instead. (It's ok to have duplicate lines across files*, the file gets compiled in if any one of the conditions matches). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 22:21:07 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94B381065676; Mon, 15 Sep 2008 22:21:07 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2E9E98FC08; Mon, 15 Sep 2008 22:21:07 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.2) with ESMTP id m8FMLuwM028165; Mon, 15 Sep 2008 17:21:56 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id m8FMLuYW028164; Mon, 15 Sep 2008 17:21:56 -0500 (CDT) (envelope-from brooks) Date: Mon, 15 Sep 2008 17:21:56 -0500 From: Brooks Davis To: John Baldwin Message-ID: <20080915222155.GD24685@lor.one-eyed-alien.net> References: <48CE59C2.9060307@icyb.net.ua> <200809151522.08679.jhb@freebsd.org> <3B9B5EED-6627-43F8-A5FC-7B2C7B2D38ED@mac.com> <200809151807.45844.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FFoLq8A0u+X9iRU8" Content-Disposition: inline In-Reply-To: <200809151807.45844.jhb@freebsd.org> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Mon, 15 Sep 2008 17:21:56 -0500 (CDT) Cc: Marcel Moolenaar , Andriy Gapon , freebsd-current@freebsd.org Subject: Re: sio => uart: one port is gone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 22:21:07 -0000 --FFoLq8A0u+X9iRU8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 15, 2008 at 06:07:45PM -0400, John Baldwin wrote: > On Monday 15 September 2008 04:13:10 pm Marcel Moolenaar wrote: > >=20 > > On Sep 15, 2008, at 12:22 PM, John Baldwin wrote: > >=20 > > > On Monday 15 September 2008 12:55:33 pm Marcel Moolenaar wrote: > > >> > > >> On Sep 15, 2008, at 9:47 AM, Andriy Gapon wrote: > > >> > > >>> on 15/09/2008 19:41 Marcel Moolenaar said the following: > > >>>> So, if you compile acpi(4) as a module, you must compile all > > >>>> it's depending drivers as modules as well. Or you compile acpi > > >>>> into the kernel... > > >>> > > >>> I understand the logic, but OTOH uart can work without acpi too, so > > >>> it's not a strict dependency. > > >> > > >> Well, yes. That's what's causing your "problem". You compile a > > >> kernel without acpi but with uart. As such, uart will be built > > >> without acpi support. uart does indeed work without acpi. > > >> > > >> The problem is that people then load the acpi module at runtime > > >> and expect uart to work with acpi. That's not going to fly. If > > >> one builds uart as a module, all possible support is included > > >> and it works as expected. > > >> > > >>> Also, this (acpi dependency) doesn't seem to be documented. > > >> > > >> It's standard behaviour. > > > > > > The problem is that right now we ship with acpi.ko as a module by =20 > > > default and > > > have the loader auto-load acpi.ko IFF the machine supports ACPI. > >=20 > > Well, don't do that then. Just have the device probe check if acpi is > > supported and attach if yes. >=20 > It does that, the loader stuff is from someone trying to be fancy and sav= e the=20 > memory of not having acpi.ko around if the system doesn't support it. Th= is=20 > may in fact be dubious. :) While acpi.ko is a beast (about .5MB) we're really only talking about savin= gs in the case when people are using GENERIC so it seems highly dubious. -- Brooks --FFoLq8A0u+X9iRU8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iD8DBQFIzuADXY6L6fI4GtQRAhHoAJ9fFvImoYKK4uIXZnYeuGyWq3tHKgCeK/W0 5/eodxxcg0vl5DMhO3CiJ1M= =D7G0 -----END PGP SIGNATURE----- --FFoLq8A0u+X9iRU8-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 22:59:23 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEDEF1065670 for ; Mon, 15 Sep 2008 22:59:23 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-gx0-f17.google.com (mail-gx0-f17.google.com [209.85.217.17]) by mx1.freebsd.org (Postfix) with ESMTP id 940FC8FC12 for ; Mon, 15 Sep 2008 22:59:23 +0000 (UTC) (envelope-from peter@wemm.org) Received: by gxk10 with SMTP id 10so24457315gxk.19 for ; Mon, 15 Sep 2008 15:59:22 -0700 (PDT) Received: by 10.142.194.4 with SMTP id r4mr67673wff.292.1221519562084; Mon, 15 Sep 2008 15:59:22 -0700 (PDT) Received: by 10.142.255.21 with HTTP; Mon, 15 Sep 2008 15:59:22 -0700 (PDT) Message-ID: Date: Mon, 15 Sep 2008 15:59:22 -0700 From: "Peter Wemm" To: pfgshield-freebsd@yahoo.com In-Reply-To: <179579.54770.qm@web32701.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <179579.54770.qm@web32701.mail.mud.yahoo.com> Cc: Xin LI , freebsd-current@freebsd.org, Oliver Fromme , Jung-uk Kim Subject: Re: Why VESA and DPMS are available only for i386? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 22:59:23 -0000 On Mon, Sep 15, 2008 at 1:43 PM, Pedro Giffuni wrote: > On Mon, Sep 15, 2008 at 1:32 PM, Jung-uk Kim wrote: > ... >>> Another way would be to write a 32bit x86 instruction >>> emulator (similar to what programs like qemu or bochs do), >>> so you can execute the VESA functions within an emulated >>> virtual machine that programs the VGA hardware registers. >>> This isn't exactly trivial either. Note that there are >>> already such emulators, but I'm not aware of a BSD-licensed >>> one that could be included in the FreeBSD kernel without >>> problems. >> >> doscmd(1) had a rudimentary 16-bit CPU emulation: >> > > FWIW, > > I can't find any reference, but according to the Wikipedia, even in long mode AMD64 is able to run 16-bit (or 80286) protected mode applications: > > http://en.wikipedia.org/wiki/AMD64#Operating_modes > > Pedro. I think you're right. We probably could implement bios32() and bios16() calls without too much trouble. It is vm86() real-mode calls that we can't do without switching out of long mode. For that we could theoretically use libint10 from Xfree86/Xorg. Our VESA code in i386 is vm86() based. We use bios16 in APM on i386. We use bios32 in APM and PCI on i386. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 23:05:10 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 208FA1065683; Mon, 15 Sep 2008 23:05:10 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout014.mac.com (asmtpout014.mac.com [17.148.16.89]) by mx1.freebsd.org (Postfix) with ESMTP id 09DC98FC1C; Mon, 15 Sep 2008 23:05:09 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from vghiya-t60.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp014.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0K7900B82ESCNZ80@asmtp014.mac.com>; Mon, 15 Sep 2008 16:05:01 -0700 (PDT) Message-id: From: Marcel Moolenaar To: Brooks Davis In-reply-to: <20080915222155.GD24685@lor.one-eyed-alien.net> Date: Mon, 15 Sep 2008 16:05:00 -0700 References: <48CE59C2.9060307@icyb.net.ua> <200809151522.08679.jhb@freebsd.org> <3B9B5EED-6627-43F8-A5FC-7B2C7B2D38ED@mac.com> <200809151807.45844.jhb@freebsd.org> <20080915222155.GD24685@lor.one-eyed-alien.net> X-Mailer: Apple Mail (2.928.1) Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: sio => uart: one port is gone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 23:05:10 -0000 On Sep 15, 2008, at 3:21 PM, Brooks Davis wrote: > On Mon, Sep 15, 2008 at 06:07:45PM -0400, John Baldwin wrote: >> On Monday 15 September 2008 04:13:10 pm Marcel Moolenaar wrote: >>> >>> On Sep 15, 2008, at 12:22 PM, John Baldwin wrote: >>> >>>> On Monday 15 September 2008 12:55:33 pm Marcel Moolenaar wrote: >>>>> >>>>> On Sep 15, 2008, at 9:47 AM, Andriy Gapon wrote: >>>>> >>>>>> on 15/09/2008 19:41 Marcel Moolenaar said the following: >>>>>>> So, if you compile acpi(4) as a module, you must compile all >>>>>>> it's depending drivers as modules as well. Or you compile acpi >>>>>>> into the kernel... >>>>>> >>>>>> I understand the logic, but OTOH uart can work without acpi >>>>>> too, so >>>>>> it's not a strict dependency. >>>>> >>>>> Well, yes. That's what's causing your "problem". You compile a >>>>> kernel without acpi but with uart. As such, uart will be built >>>>> without acpi support. uart does indeed work without acpi. >>>>> >>>>> The problem is that people then load the acpi module at runtime >>>>> and expect uart to work with acpi. That's not going to fly. If >>>>> one builds uart as a module, all possible support is included >>>>> and it works as expected. >>>>> >>>>>> Also, this (acpi dependency) doesn't seem to be documented. >>>>> >>>>> It's standard behaviour. >>>> >>>> The problem is that right now we ship with acpi.ko as a module by >>>> default and >>>> have the loader auto-load acpi.ko IFF the machine supports ACPI. >>> >>> Well, don't do that then. Just have the device probe check if acpi >>> is >>> supported and attach if yes. >> >> It does that, the loader stuff is from someone trying to be fancy >> and save the >> memory of not having acpi.ko around if the system doesn't support >> it. This >> may in fact be dubious. :) > > While acpi.ko is a beast (about .5MB) we're really only talking > about savings > in the case when people are using GENERIC so it seems highly dubious. I tend to agree. If we didn't had the side-effects, then it's neat little thing. It would be interesting to experiment with how we can control code/data placement, so that we can bundle code or data in a way that allows us to re-use memory when the code or data is not needed (anymore). Such as kernel initialization code, driver code, firmware data, etc... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 23:09:00 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8C92106566B for ; Mon, 15 Sep 2008 23:09:00 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (unknown [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5123C8FC16 for ; Mon, 15 Sep 2008 23:09:00 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 80B3628449 for ; Tue, 16 Sep 2008 07:08:59 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 124FEF6547D; Tue, 16 Sep 2008 07:08:59 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id K0Q6rQDm92JQ; Tue, 16 Sep 2008 07:08:54 +0800 (CST) Received: from charlie.delphij.net (71.5.7.139.ptr.us.xo.net [71.5.7.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 968C4F06CC5; Tue, 16 Sep 2008 07:08:52 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:subject:references:in-reply-to:x-enigmail-version:openpgp: content-type:content-transfer-encoding; b=WOg+pENXqSYOs/N0Gfv5VsmjPG7Ga4clSVc3OE+OIy3YTM/wAG7tC1qsxQ7lMGyYx z4KrZ1AgvzwdBt5MppAPg== Message-ID: <48CEEB00.5030703@delphij.net> Date: Mon, 15 Sep 2008 16:08:48 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.16 (X11/20080725) MIME-Version: 1.0 To: freebsd-current@FreeBSD.ORG, unixmania@gmail.com, delphij@delphij.net References: <200809151753.m8FHr9Gi083627@lurza.secnetix.de> In-Reply-To: <200809151753.m8FHr9Gi083627@lurza.secnetix.de> X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Why VESA and DPMS are available only for i386? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 23:09:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oliver Fromme wrote: > Carlos A. M. dos Santos wrote: > > Oliver Fromme wrote: > > > There's a third way, and I think this is the easiest one. > > > This is what the Linux VESA framebuffer driver does. > > > Let the boot loader (which executes in 32bit mode) switch > > > to the desired video mode, enable a linear frame buffer > > > (which is supported since VBE 2.0) and pass the address > > > of the frame buffer to the 64bit kernel. Then the kernel > > > would not need to call any VESA functions at all, thus > > > eliminating all of the above problems. The drawback is > > > that you can't change the console video mode anymore once > > > the kernel is booted, i.e. you have to reboot if you want > > > a different mode. > > > > This can also lead to a situation where the kernel can not restore the > > video controller to a known mode if the X server crashes or when the > > user attempts to switch from X to the "text mode" console. > > Why would you need to use VESA modes for syscons if you > install and run Xorg anyway? In order to be able to give more information upon startup? I always think that the Mac OS's pre-GUI message helpful, but they don't return to console mode anyway. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjO6wAACgkQi+vbBBjt66BSxQCfYh+RtmsHBUtTGouQkVIHvMqa LmUAoLn9sHd4QcgilmGdW02qlO6PULTt =rxjN -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 23:55:39 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27EA11065675 for ; Mon, 15 Sep 2008 23:55:39 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.190]) by mx1.freebsd.org (Postfix) with ESMTP id ACFEC8FC0A for ; Mon, 15 Sep 2008 23:55:33 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: by fk-out-0910.google.com with SMTP id k31so2170438fkk.11 for ; Mon, 15 Sep 2008 16:55:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:message-id:user-agent:mime-version:content-type; bh=Eb4/z64Bajthzo/pNgWCSWYgbKEvz79SrgZGzn9h9MU=; b=A5gohxs0bFWvUc+ris4kMjYjbI7NaRRUEbXxFtqEPxx/395hJKttTmxVk56l8U/jE+ UryMUphe3/SkRJtD/DD2Vj8ZSyhewXZaRLGvT8PIrsrIJRF/6vOSRJ5gDnro1Rb4DwNJ TLu9FGhMw+/zF546iyChNj3CjREu7tdVhtX7o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:message-id:user-agent :mime-version:content-type; b=O61/4AFbdCpeJxjXsVPWg9qleOSSKNnS0wjbGl+nakM4aF87Aw78jxX4TRg6MsizU8 KaHCEseJGnswxovCHxLAJJs3K+BwsL4gZw2m2HGCZKB2xF2J8aD1g05KfBCbmGe3K8v8 JIoesTcUhKJQhioy2LmTrRfrWLwOnKFfTXqIc= Received: by 10.181.22.8 with SMTP id z8mr107443bki.78.1221522932078; Mon, 15 Sep 2008 16:55:32 -0700 (PDT) Received: from localhost ( [89.178.186.140]) by mx.google.com with ESMTPS id y15sm14423817fkd.17.2008.09.15.16.55.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 15 Sep 2008 16:55:26 -0700 (PDT) From: swell.k@gmail.com To: Steven Schlansker References: <3A22C890-8724-4A41-8E67-2F6A8D4D7E3C@berkeley.edu> Date: Tue, 16 Sep 2008 03:55:20 +0400 Message-ID: <8663oxvuaf.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org Subject: Re: pjd's ZFS 2008-07-27 patches against HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 23:55:39 -0000 Steven Schlansker writes: > I recently got fed up with all the deadlocks that ZFS seems to have on > my home server (things hang in zfs: states, nothing can kill them, > prevents rebooting, etc) so I decided to try out -CURRENT with the > latest ZFS patches. However, they no longer seem to apply cleanly. > Specifically, Revisions before r182371 should work. Or you can try -CURRENT some later time when pjd commit[1] his work on latest zfs version. [1] http://docs.FreeBSD.org/cgi/mid.cgi?20080829074738.GB3026 > [steven@universe:/usr/src]% bzcat ~/zfs_20080727.patch.bz2 | sudo > patch -s -C -p0 > 1 out of 14 hunks failed--saving rejects to cddl/contrib/opensolaris/ > lib/libzpool/common/sys/zfs_context.h.rej > 1 out of 11 hunks failed--saving rejects to sys/cddl/contrib/ > opensolaris/uts/common/fs/zfs/vdev_file.c.rej > 1 out of 33 hunks failed--saving rejects to sys/cddl/contrib/ > opensolaris/uts/common/fs/zfs/zfs_ctldir.c.rej > 1 out of 20 hunks failed--saving rejects to sys/cddl/contrib/ > opensolaris/uts/common/fs/zfs/zfs_replay.c.rej > 1 out of 115 hunks failed--saving rejects to sys/cddl/contrib/ > opensolaris/uts/common/fs/zfs/zfs_vnops.c.rej > 4 out of 29 hunks failed--saving rejects to sys/cddl/contrib/ > opensolaris/uts/common/fs/zfs/zfs_znode.c.rej > 1 out of 11 hunks failed--saving rejects to sys/kern/kern_jail.c.rej > > This is against a current HEAD (tag=. in csup as of 2 hours ago) > > I was wondering if there is a newer patch out there (I don't see > anything in ~pjd/patches) or if anyone has had any luck getting the > patch to apply cleanly to the latest sources. http://pastebin.com/m30db3356 I've just copied `+' lines from p4 and `-' lines from svn, nothing special. Try it at your own risk and don't blame me if you lose your precious data. ;) So far I haven't lost mine, although I have a bad experience with zfs metadata corruption in the past with and without pjd's patch. Another way is just collect and revert conflicting commits then apply the patch without modifying it. I've already lost count how many there are to revert. From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 00:36:13 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1AC21065671 for ; Tue, 16 Sep 2008 00:36:13 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from cauchy.math.missouri.edu (cauchy.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id C37208FC15 for ; Tue, 16 Sep 2008 00:36:13 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from laptop3.gateway.2wire.net (cauchy.math.missouri.edu [128.206.184.213]) by cauchy.math.missouri.edu (8.14.2/8.14.2) with ESMTP id m8G0ZOOX001097; Mon, 15 Sep 2008 19:35:24 -0500 (CDT) (envelope-from stephen@math.missouri.edu) Message-ID: <48CEFF74.8020602@math.missouri.edu> Date: Mon, 15 Sep 2008 19:36:04 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.1.16) Gecko/20080909 SeaMonkey/1.1.11 MIME-Version: 1.0 To: Martin Cracauer References: <48CDBC78.4010409@math.missouri.edu> <20080915195021.GA69528@cons.org> In-Reply-To: <20080915195021.GA69528@cons.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Improved multiprocessor usage on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 00:36:14 -0000 Martin Cracauer wrote: > Stephen Montgomery-Smith wrote on Sun, Sep 14, 2008 at 08:38:00PM -0500: >> I have a dual core amd64 on which I run a processor intensive numerical >> program. I had been frustrated because it seemed to run 3 or 4 times >> faster under Linux. But with a recent upgrade of FreeBSD-CURRENT, it >> now goes at about the same speed as Linux. > > Are the threads meant to provide additional CPU resources or help with > concurrency/IO issues? They are meant to provide additional CPU resources. > > Do you create a lot of new threads on the fly? > No. They are synchronized via standard pthread_cond type constructions... > What kind of worker model do you have there? > ... and each thread is a loop of the form while (1) { wait until told to start; do massive amounts of floating point arithmetic (only additions and multiplications) on large arrays; tell the master process that you are done; } > Do you have about as many threads as processor or more? Both ways. The time difference between the two approaches is negligible. > > How malloc intensive is it? All mallocs are done one time at the beginning. > > Martin From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 00:36:52 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDFA21065670 for ; Tue, 16 Sep 2008 00:36:52 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from cauchy.math.missouri.edu (cauchy.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id AF10F8FC25 for ; Tue, 16 Sep 2008 00:36:52 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from laptop3.gateway.2wire.net (cauchy.math.missouri.edu [128.206.184.213]) by cauchy.math.missouri.edu (8.14.2/8.14.2) with ESMTP id m8G0a345001130; Mon, 15 Sep 2008 19:36:04 -0500 (CDT) (envelope-from stephen@math.missouri.edu) Message-ID: <48CEFF9B.2080505@math.missouri.edu> Date: Mon, 15 Sep 2008 19:36:43 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.1.16) Gecko/20080909 SeaMonkey/1.1.11 MIME-Version: 1.0 To: cpghost References: <48CDBC78.4010409@math.missouri.edu> <20080915185446.GB69615@phenom.cordula.ws> In-Reply-To: <20080915185446.GB69615@phenom.cordula.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Improved multiprocessor usage on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 00:36:53 -0000 cpghost wrote: > On Sun, Sep 14, 2008 at 08:38:00PM -0500, Stephen Montgomery-Smith wrote: >> I have a dual core amd64 on which I run a processor intensive numerical >> program. I had been frustrated because it seemed to run 3 or 4 times >> faster under Linux. But with a recent upgrade of FreeBSD-CURRENT, it >> now goes at about the same speed as Linux. >> >> The program takes about an hour. For the first minute, the program runs >> rather slowly, but then it is as if the operating system finds its way, >> and suddenly it speeds up. "top -H" suggests that for the first minute >> that one thread is going really slowly, and is perhaps being starved or >> something. >> >> My question is - why is this happening, and is this something I should >> expect? Are there certain switches or sysctls I can set to make it go >> fast from the get go? > > It looks like you're running powerd (see in /etc/rc.conf). It can take up > to a minute for the load average of the machine to exceed a certain > threshold where powerd would finally bump the cpu(s) to full speed. > > As for sysctls, check the speed with something like: > > # sysctl dev.cpu.0 Excellent idea! I should have thought of that myself. Unfortunately it didn't help much when I switched powerd off. From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 01:05:34 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CEE71065670 for ; Tue, 16 Sep 2008 01:05:34 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id C685E8FC13 for ; Tue, 16 Sep 2008 01:05:33 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.2.189] (c-71-56-39-94.hsd1.ga.comcast.net [71.56.39.94]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id m8G0q1Nj006532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Sep 2008 20:52:02 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Kostik Belousov In-Reply-To: <20080914174801.GC39652@deviant.kiev.zoral.com.ua> References: <20080914174801.GC39652@deviant.kiev.zoral.com.ua> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-2QtV01B86GwgnfjI9CNd" Organization: FreeBSD Date: Mon, 15 Sep 2008 20:51:55 -0400 Message-Id: <1221526316.1848.1.camel@wombat.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: current@freebsd.org, "Yair K." , vehemens Subject: Re: cdevpriv and mmap(2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 01:05:34 -0000 --=-2QtV01B86GwgnfjI9CNd Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2008-09-14 at 20:48 +0300, Kostik Belousov wrote: > When implementing cdevpriv, I completeley missed the support for > d_mmap() driver method. This method is called by the kernel (at least) > twice: one time to validate the mmaped region and protection mode (see > vm/device_pager.c:dev_pager_alloc()), and second time to obtain the > physical address when serving page fault (see dev_pager_getpages()). >=20 > Support for cdevpriv for the first call(s) is trivial, and is > implemented by the patch below. Second calls are much harder and > essentially require attaching cdevpriv bookkeeping data to the struct > vm_map_entry. In fact, I am not sure whether this support for the second > time calls is needed at all in real usage. >=20 > I Cc:ed people that pointed me to the issue, please evaluate the > patch against your needs. I think I will commit it shortly after your > feedback. On the other hand, I would think about implementing full > support for d_mmap only if actually needed. The needs of drm in this case are very minor, but after talking with rwatson the other night, I was going to work around this issue. But it would be great if this works, so I'll try it as soon as I get caught up on mail... robert. > Thanks ! >=20 > diff --git a/sys/vm/vm_mmap.c b/sys/vm/vm_mmap.c > index 7e6b04f..c3f08b0 100644 > --- a/sys/vm/vm_mmap.c > +++ b/sys/vm/vm_mmap.c > @@ -391,8 +391,10 @@ map: > goto done; > } > =20 > + td->td_fpop =3D fp; > error =3D vm_mmap(&vms->vm_map, &addr, size, prot, maxprot, > flags, handle_type, handle, pos); > + td->td_fpop =3D NULL; > #ifdef HWPMC_HOOKS > /* inform hwpmc(4) if an executable is being mapped */ > if (error =3D=3D 0 && handle_type =3D=3D OBJT_VNODE && --=-2QtV01B86GwgnfjI9CNd Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAkjPAysACgkQM4TrQ4qfROOumACePYop9EbPnY7aUh5NeHlHy5sO 6nQAn3I40H0hAqLWJJDKXzcvmHhm4XNk =LOuX -----END PGP SIGNATURE----- --=-2QtV01B86GwgnfjI9CNd-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 01:05:46 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF3C41065672 for ; Tue, 16 Sep 2008 01:05:46 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.189]) by mx1.freebsd.org (Postfix) with ESMTP id 59D668FC20 for ; Tue, 16 Sep 2008 01:05:46 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: by gv-out-0910.google.com with SMTP id n8so1196555gve.39 for ; Mon, 15 Sep 2008 18:05:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=EXaxyDnE7jDCVVw+gTdr8WgO1wWlABKjCwTMjSGNcuM=; b=cSBgqJluig8pVR1XRzIgpWE1n8DJBB1oVc1nkZCa2JFptmi6bkJT9Dk28MOWP+Bmlr SCjPEZUCJYMEhlroVu0Rp4zaSFvM2Mab6XLVXUfYUpFP1OsRAsHN6OYCz6Zh+/vbC5EJ wsZtw5I2ZYYnIT0z3tY+rC9g8KDkI9R9U87tY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=AA9oU3jcPo+PaOyqGVHLubdOhYh1jXFWx0qW2yChATWv7kPuf8Aju2gmvXSs5DGzJX e4SLGHFT6WWDyBDYdFgvR3pcZAKPXS0o7Gvu01O5wYPkGiR23eenlKoOf1J0OBSEIUUu x66+PBaSrgR75yKNnd6e8joDj3r1B0k+XxKb4= Received: by 10.102.228.10 with SMTP id a10mr194708muh.109.1221527143952; Mon, 15 Sep 2008 18:05:43 -0700 (PDT) Received: by 10.103.231.14 with HTTP; Mon, 15 Sep 2008 18:05:43 -0700 (PDT) Message-ID: Date: Mon, 15 Sep 2008 22:05:43 -0300 From: "Carlos A. M. dos Santos" To: "Jung-uk Kim" In-Reply-To: <200809151439.44049.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200809150922.m8F9MaHg090579@haluter.fromme.com> <200809151232.36756.jkim@FreeBSD.org> <200809151439.44049.jkim@FreeBSD.org> Cc: Xin LI , freebsd-current@freebsd.org, Oliver Fromme Subject: Re: Why VESA and DPMS are available only for i386? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 01:05:46 -0000 On Mon, Sep 15, 2008 at 3:39 PM, Jung-uk Kim wrote: > On Monday 15 September 2008 01:24 pm, Carlos A. M. dos Santos wrote: >> On Mon, Sep 15, 2008 at 1:32 PM, Jung-uk Kim > wrote: >> > On Monday 15 September 2008 05:22 am, Oliver Fromme wrote: >> >> Carlos A. M. dos Santos wrote: >> >> > Xin LI wrote: >> >> > > Carlos A. M. dos Santos wrote: >> >> > > > Several PRs were closed based on the argument that >> >> > > > FreeBSD/amd64 cannot call to the VESA BIOS. XFree86 >> >> > > > solved this problem by means of the INT10 module. I >> >> > > > believe that it would be possible to do the same on the >> >> > > > FreeBSD kernel. >> >> > > > >> >> > > > Is there any ongoing effort to enable the VESA kernel >> >> > > > moule on non-i386 platform? Is there any particular >> >> > > > difficulty for doing this, besides depending on VM86? >> >> > > >> >> > > According to VESA's VBE 3.0 standard, there is a "Protected >> >> > > Mode Entry Point" [optionally] provided by BIOS, which OS >> >> > > or application is supposed to copy to a place where it is >> >> > > writable. The code there would be written in 16-bit >> >> > > protected mode. Therefore I think it's do-able... >> >> > > >> >> > > http://www.vesa.org/public/VBE/vbe3.pdf >> >> > >> >> > I'm reading the specification and digging at the code of the >> >> > X server and the X VESA driver. Look promising. >> >> >> >> Don't hold your breath. Peter explained that this is more >> >> involved than it seems at first glance: >> >> >> >> http://lists.freebsd.org/pipermail/freebsd-amd64/2005-October/00 >> >>637 6.html >> >> >> >> Here's a quote: >> >> | [FreeBSD's VESA code] is trying to use bios calls to change >> >> | the modes. This is something a 64 bit kernel cannot do. To >> >> | make this work, one would have to trampoline out of 64 bit >> >> | mode and into 32 bit mode, then do the vm86 or bios32() >> >> | calls. This is more work than it might appear at first >> >> | because you have to deal with interrupts. One would have to >> >> | write a 32 bit mini-kernel that can accept interrupts and >> >> | traps, trampoline to 64 bit mode, handle them, then return, >> >> | switching back to 32 bit mode. All with page tables etc. >> >> | And of course you have to do extra data copying and have a >> >> | way to describe it to the API. >> >> >> >> By the way, It doesn't matter whether you use the VESA >> >> BIOS' real-mode functions or the protected-mode functions >> >> (which exist since VBE 2.0, not only 3.0). From the view >> >> of an amd64 kernel it doesn't make a difference. >> >> >> >> Another way would be to write a 32bit x86 instruction >> >> emulator (similar to what programs like qemu or bochs do), >> >> so you can execute the VESA functions within an emulated >> >> virtual machine that programs the VGA hardware registers. >> >> This isn't exactly trivial either. Note that there are >> >> already such emulators, but I'm not aware of a BSD-licensed >> >> one that could be included in the FreeBSD kernel without >> >> problems. >> > >> > doscmd(1) had a rudimentary 16-bit CPU emulation: >> > >> > http://www.freebsd.org/cgi/cvsweb.cgi/projects/doscmd/ >> > http://www.freebsd.org/cgi/cvsweb.cgi/projects/doscmd/cpu.c >> >> No change in the last 4 years. Is there anybody responsible for it >> these days? > > doscmd(1) was removed from base and moved to ports: > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/doscmd/ > > Don't get me wrong, BTW. It does not work on amd64. I just brought > it up because we *may* be able to do a hybrid approach [...] Depends on vm86 too. > [...] as Linux DOSEMU does: > > http://en.wikipedia.org/wiki/DOSEMU > > "Virtual 8086 mode is not available in x86-64 long mode, so DOSEMU > includes an 8086 processor emulator for use with 16-bit > applications." Wrong license. > Also, Linux people actually developed vm86 calls for amd64: > > http://v86-64.sourceforge.net/ It is a Linux kernel patch, doubtfully applicable to FreeBSD without a lot of hassle. I'm also concerned about the license terms. > Jung-uk Kim > -- cd /usr/ports/sysutils/life make clean From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 01:40:17 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id D01521065672; Tue, 16 Sep 2008 01:40:15 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: "Carlos A. M. dos Santos" Date: Mon, 15 Sep 2008 21:39:57 -0400 User-Agent: KMail/1.6.2 References: <200809150922.m8F9MaHg090579@haluter.fromme.com> <200809151439.44049.jkim@FreeBSD.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200809152139.58765.jkim@FreeBSD.org> Cc: Xin LI , freebsd-current@freebsd.org, Oliver Fromme Subject: Re: Why VESA and DPMS are available only for i386? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 01:40:17 -0000 On Monday 15 September 2008 09:05 pm, Carlos A. M. dos Santos wrote: > On Mon, Sep 15, 2008 at 3:39 PM, Jung-uk Kim wrote: > > On Monday 15 September 2008 01:24 pm, Carlos A. M. dos Santos wrote: > >> On Mon, Sep 15, 2008 at 1:32 PM, Jung-uk Kim > > > > wrote: > >> > On Monday 15 September 2008 05:22 am, Oliver Fromme wrote: > >> >> Carlos A. M. dos Santos wrote: > >> >> > Xin LI wrote: > >> >> > > Carlos A. M. dos Santos wrote: > >> >> > > > Several PRs were closed based on the argument that > >> >> > > > FreeBSD/amd64 cannot call to the VESA BIOS. XFree86 > >> >> > > > solved this problem by means of the INT10 module. I > >> >> > > > believe that it would be possible to do the same on > >> >> > > > the FreeBSD kernel. > >> >> > > > > >> >> > > > Is there any ongoing effort to enable the VESA kernel > >> >> > > > moule on non-i386 platform? Is there any particular > >> >> > > > difficulty for doing this, besides depending on VM86? > >> >> > > > >> >> > > According to VESA's VBE 3.0 standard, there is a > >> >> > > "Protected Mode Entry Point" [optionally] provided by > >> >> > > BIOS, which OS or application is supposed to copy to a > >> >> > > place where it is writable. The code there would be > >> >> > > written in 16-bit protected mode. Therefore I think > >> >> > > it's do-able... > >> >> > > > >> >> > > http://www.vesa.org/public/VBE/vbe3.pdf > >> >> > > >> >> > I'm reading the specification and digging at the code of > >> >> > the X server and the X VESA driver. Look promising. > >> >> > >> >> Don't hold your breath. Peter explained that this is more > >> >> involved than it seems at first glance: > >> >> > >> >> http://lists.freebsd.org/pipermail/freebsd-amd64/2005-October > >> >>/00 637 6.html > >> >> > >> >> Here's a quote: > >> >> | [FreeBSD's VESA code] is trying to use bios calls to > >> >> | change the modes. This is something a 64 bit kernel > >> >> | cannot do. To make this work, one would have to > >> >> | trampoline out of 64 bit mode and into 32 bit mode, then > >> >> | do the vm86 or bios32() calls. This is more work than it > >> >> | might appear at first because you have to deal with > >> >> | interrupts. One would have to write a 32 bit mini-kernel > >> >> | that can accept interrupts and traps, trampoline to 64 > >> >> | bit mode, handle them, then return, switching back to 32 > >> >> | bit mode. All with page tables etc. And of course you > >> >> | have to do extra data copying and have a way to describe > >> >> | it to the API. > >> >> > >> >> By the way, It doesn't matter whether you use the VESA > >> >> BIOS' real-mode functions or the protected-mode functions > >> >> (which exist since VBE 2.0, not only 3.0). From the view > >> >> of an amd64 kernel it doesn't make a difference. > >> >> > >> >> Another way would be to write a 32bit x86 instruction > >> >> emulator (similar to what programs like qemu or bochs do), > >> >> so you can execute the VESA functions within an emulated > >> >> virtual machine that programs the VGA hardware registers. > >> >> This isn't exactly trivial either. Note that there are > >> >> already such emulators, but I'm not aware of a BSD-licensed > >> >> one that could be included in the FreeBSD kernel without > >> >> problems. > >> > > >> > doscmd(1) had a rudimentary 16-bit CPU emulation: > >> > > >> > http://www.freebsd.org/cgi/cvsweb.cgi/projects/doscmd/ > >> > http://www.freebsd.org/cgi/cvsweb.cgi/projects/doscmd/cpu.c > >> > >> No change in the last 4 years. Is there anybody responsible for > >> it these days? > > > > doscmd(1) was removed from base and moved to ports: > > > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/doscmd/ > > > > Don't get me wrong, BTW. It does not work on amd64. I just > > brought it up because we *may* be able to do a hybrid approach > > [...] > > Depends on vm86 too. > > > [...] as Linux DOSEMU does: > > > > http://en.wikipedia.org/wiki/DOSEMU > > > > "Virtual 8086 mode is not available in x86-64 long mode, so > > DOSEMU includes an 8086 processor emulator for use with 16-bit > > applications." > > Wrong license. > > > Also, Linux people actually developed vm86 calls for amd64: > > > > http://v86-64.sourceforge.net/ > > It is a Linux kernel patch, doubtfully applicable to FreeBSD > without a lot of hassle. I'm also concerned about the license > terms. No, I am not saying we can reuse any of these. I was merely saying we could do something similar, conceptually. :-) Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 03:35:02 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA1A6106566B for ; Tue, 16 Sep 2008 03:35:02 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 999C88FC0C for ; Tue, 16 Sep 2008 03:35:02 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id m8G3YxkC031414; Mon, 15 Sep 2008 20:34:59 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id m8G3YxvD031413; Mon, 15 Sep 2008 20:34:59 -0700 (PDT) (envelope-from sgk) Date: Mon, 15 Sep 2008 20:34:59 -0700 From: Steve Kargl To: Stephen Montgomery-Smith Message-ID: <20080916033459.GA31220@troutmask.apl.washington.edu> References: <48CDBC78.4010409@math.missouri.edu> <20080915195021.GA69528@cons.org> <48CEFF74.8020602@math.missouri.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48CEFF74.8020602@math.missouri.edu> User-Agent: Mutt/1.4.2.3i Cc: Martin Cracauer , freebsd-current@freebsd.org Subject: Re: Improved multiprocessor usage on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 03:35:02 -0000 On Mon, Sep 15, 2008 at 07:36:04PM -0500, Stephen Montgomery-Smith wrote: > > ... and each thread is a loop of the form > > while (1) { > wait until told to start; > do massive amounts of floating point arithmetic (only additions and > multiplications) on large arrays; > tell the master process that you are done; > } > > >Do you have about as many threads as processor or more? > > Both ways. The time difference between the two approaches is negligible. > Are you using ULE? With my MPI applications, if the number of launched processes exceeds the number of cpus by 1, ULE falls through the floor. I have a nagging feeling that there is a problem with cpu affinity. http://lists.freebsd.org/pipermail/freebsd-current/2008-July/086917.html -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 03:41:40 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 007FF1065670 for ; Tue, 16 Sep 2008 03:41:40 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from cauchy.math.missouri.edu (cauchy.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id 8CFD58FC15 for ; Tue, 16 Sep 2008 03:41:39 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from laptop3.gateway.2wire.net (cauchy.math.missouri.edu [128.206.184.213]) by cauchy.math.missouri.edu (8.14.2/8.14.2) with ESMTP id m8G3etbm008083; Mon, 15 Sep 2008 22:40:56 -0500 (CDT) (envelope-from stephen@math.missouri.edu) Message-ID: <48CF2AEF.9070208@math.missouri.edu> Date: Mon, 15 Sep 2008 22:41:35 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.1.16) Gecko/20080909 SeaMonkey/1.1.11 MIME-Version: 1.0 To: Steve Kargl References: <48CDBC78.4010409@math.missouri.edu> <20080915195021.GA69528@cons.org> <48CEFF74.8020602@math.missouri.edu> <20080916033459.GA31220@troutmask.apl.washington.edu> In-Reply-To: <20080916033459.GA31220@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Martin Cracauer , freebsd-current@freebsd.org Subject: Re: Improved multiprocessor usage on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 03:41:40 -0000 Steve Kargl wrote: > On Mon, Sep 15, 2008 at 07:36:04PM -0500, Stephen Montgomery-Smith wrote: >> ... and each thread is a loop of the form >> >> while (1) { >> wait until told to start; >> do massive amounts of floating point arithmetic (only additions and >> multiplications) on large arrays; >> tell the master process that you are done; >> } >> >>> Do you have about as many threads as processor or more? >> Both ways. The time difference between the two approaches is negligible. >> > > Are you using ULE? With my MPI applications, if the number of > launched processes exceeds the number of cpus by 1, ULE falls > through the floor. I have a nagging feeling that there is > a problem with cpu affinity. > > http://lists.freebsd.org/pipermail/freebsd-current/2008-July/086917.html > I get the same phenomenon with ULE and 4BSD. I would say that they perform about the same. But yes, I do have at least one more process running than the number of CPUs. One of the processes is the master process, that controls the others, and it does comparatively little work compared to the others, but it is still there, and it does do some work. From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 03:48:56 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C768E1065679 for ; Tue, 16 Sep 2008 03:48:56 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from cauchy.math.missouri.edu (cauchy.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id 92EAE8FC15 for ; Tue, 16 Sep 2008 03:48:56 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from laptop3.gateway.2wire.net (cauchy.math.missouri.edu [128.206.184.213]) by cauchy.math.missouri.edu (8.14.2/8.14.2) with ESMTP id m8G3mCPE008343; Mon, 15 Sep 2008 22:48:13 -0500 (CDT) (envelope-from stephen@math.missouri.edu) Message-ID: <48CF2CA4.1000802@math.missouri.edu> Date: Mon, 15 Sep 2008 22:48:52 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.1.16) Gecko/20080909 SeaMonkey/1.1.11 MIME-Version: 1.0 To: Steve Kargl References: <48CDBC78.4010409@math.missouri.edu> <20080915195021.GA69528@cons.org> <48CEFF74.8020602@math.missouri.edu> <20080916033459.GA31220@troutmask.apl.washington.edu> <48CF2AEF.9070208@math.missouri.edu> In-Reply-To: <48CF2AEF.9070208@math.missouri.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Martin Cracauer , freebsd-current@freebsd.org Subject: Re: Improved multiprocessor usage on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 03:48:56 -0000 Stephen Montgomery-Smith wrote: > Steve Kargl wrote: >> On Mon, Sep 15, 2008 at 07:36:04PM -0500, Stephen Montgomery-Smith wrote: >>> ... and each thread is a loop of the form >>> >>> while (1) { >>> wait until told to start; >>> do massive amounts of floating point arithmetic (only additions and >>> multiplications) on large arrays; >>> tell the master process that you are done; >>> } >>> >>>> Do you have about as many threads as processor or more? >>> Both ways. The time difference between the two approaches is >>> negligible. >>> >> >> Are you using ULE? With my MPI applications, if the number of >> launched processes exceeds the number of cpus by 1, ULE falls >> through the floor. I have a nagging feeling that there is a problem >> with cpu affinity. >> >> http://lists.freebsd.org/pipermail/freebsd-current/2008-July/086917.html >> Let me say a little bit more. I have this gut feeling that the problem has a lot to do with cache management. My program has each thread doing, in effect, huge matrix multiplications, each one working on their own little bit. If a CPU core changes from one thread to another, it then has to flush out the cache to RAM, and read in a whole bunch of other RAM into cache. I have this sense that Linux and FreeBSD have something in its internals where it figures this out, and after a while starts changing the time between when it changes from one process to another. But Linux has a faster learning curve than FreeBSD. But this is all pure speculation on my part, because I have very little ideas as to how these internals work. Stephen From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 04:32:30 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21A0A1065677 for ; Tue, 16 Sep 2008 04:32:30 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.freebsd.org (Postfix) with ESMTP id D08A08FC26 for ; Tue, 16 Sep 2008 04:32:29 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.3/8.14.3) with ESMTP id m8G4BiIL037745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Sep 2008 23:11:45 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.3/8.14.3/Submit) id m8G4BhVo037744; Mon, 15 Sep 2008 23:11:43 -0500 (CDT) (envelope-from dan) Date: Mon, 15 Sep 2008 23:11:43 -0500 From: Dan Nelson To: Stephen Montgomery-Smith Message-ID: <20080916041142.GH3188@dan.emsphone.com> References: <48CDBC78.4010409@math.missouri.edu> <20080915195021.GA69528@cons.org> <48CEFF74.8020602@math.missouri.edu> <20080916033459.GA31220@troutmask.apl.washington.edu> <48CF2AEF.9070208@math.missouri.edu> <48CF2CA4.1000802@math.missouri.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48CF2CA4.1000802@math.missouri.edu> X-OS: FreeBSD 7.1-PRERELEASE User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Martin Cracauer , freebsd-current@freebsd.org, Steve Kargl Subject: Re: Improved multiprocessor usage on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 04:32:30 -0000 In the last episode (Sep 15), Stephen Montgomery-Smith said: > Stephen Montgomery-Smith wrote: > > Steve Kargl wrote: > >> On Mon, Sep 15, 2008 at 07:36:04PM -0500, Stephen Montgomery-Smith wrote: > >>> ... and each thread is a loop of the form > >>> > >>> while (1) { > >>> wait until told to start; > >>> do massive amounts of floating point arithmetic (only additions and > >>> multiplications) on large arrays; > >>> tell the master process that you are done; > >>> } > >>> > >>>> Do you have about as many threads as processor or more? > >>> Both ways. The time difference between the two approaches is > >>> negligible. > >>> > >> > >> Are you using ULE? With my MPI applications, if the number of > >> launched processes exceeds the number of cpus by 1, ULE falls > >> through the floor. I have a nagging feeling that there is a problem > >> with cpu affinity. > >> > >> http://lists.freebsd.org/pipermail/freebsd-current/2008-July/086917.html > > Let me say a little bit more. > > I have this gut feeling that the problem has a lot to do with cache > management. My program has each thread doing, in effect, huge matrix > multiplications, each one working on their own little bit. If a CPU > core changes from one thread to another, it then has to flush out the > cache to RAM, and read in a whole bunch of other RAM into cache. You can try playing with the new cpuset functions in HEAD and 7-STABLE to lock particular threads on certain CPUs. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 06:21:28 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBB101065672 for ; Tue, 16 Sep 2008 06:21:28 +0000 (UTC) (envelope-from stevenschlansker@berkeley.edu) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by mx1.freebsd.org (Postfix) with ESMTP id C4EC48FC25 for ; Tue, 16 Sep 2008 06:21:28 +0000 (UTC) (envelope-from stevenschlansker@berkeley.edu) Received: from emu.stevenschlansker.is-a-geek.org (66-117-142-212.lmi.net [66.117.142.212]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id m8G6LRJU026284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Sep 2008 23:21:28 -0700 (PDT) Message-Id: <6FB40451-1CBC-4FD2-ACA5-FF594E1E3F5C@berkeley.edu> From: Steven Schlansker To: swell.k@gmail.com In-Reply-To: <8663oxvuaf.fsf@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 15 Sep 2008 23:21:21 -0700 References: <3A22C890-8724-4A41-8E67-2F6A8D4D7E3C@berkeley.edu> <8663oxvuaf.fsf@gmail.com> X-Mailer: Apple Mail (2.926) Cc: freebsd-current@freebsd.org Subject: Re: pjd's ZFS 2008-07-27 patches against HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 06:21:28 -0000 On Sep 15, 2008, at 4:55 PM, swell.k@gmail.com wrote: > Steven Schlansker writes: > >> so I decided to try out -CURRENT with the >> latest ZFS patches. > > Revisions before r182371 should work. Or you can try -CURRENT > some later time when pjd commit[1] his work on latest zfs version. > > [1] http://docs.FreeBSD.org/cgi/mid.cgi?20080829074738.GB3026 > >> >> I was wondering if there is a newer patch out there (I don't see >> anything in ~pjd/patches) or if anyone has had any luck getting the >> patch to apply cleanly to the latest sources. > > http://pastebin.com/m30db3356 > > I've just copied `+' lines from p4 and `-' lines from svn, nothing > special. Try it at your own risk and don't blame me if you lose > your precious data. ;) So far I haven't lost mine, although I have > a bad experience with zfs metadata corruption in the past with > and without pjd's patch. > > Another way is just collect and revert conflicting commits then apply > the patch without modifying it. I've already lost count how many there > are to revert. Hm. I think I'll just wait until it hits HEAD before upgrading - I like my data ;) Thanks for the mailing list link - I hadn't found that before. Hopefully it will be committed soon! Thanks, Steven From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 06:31:34 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EDAB1065673 for ; Tue, 16 Sep 2008 06:31:34 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id 238448FC08 for ; Tue, 16 Sep 2008 06:31:34 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1KfTpk-000E9W-Pf; Tue, 16 Sep 2008 09:14:44 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Andriy Gapon In-reply-to: <48CEC04C.8000707@icyb.net.ua> References: <48CE59C2.9060307@icyb.net.ua> <48CEC04C.8000707@icyb.net.ua> Comments: In-reply-to Andriy Gapon message dated "Mon, 15 Sep 2008 23:06:36 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Sep 2008 09:14:44 +0300 From: Danny Braniss Message-ID: Cc: Mike Tancsa , Marcel Moolenaar , Ian Smith , freebsd-current@freebsd.org Subject: Re: sio => uart: one port is gone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 06:31:34 -0000 > on 15/09/2008 18:58 Marcel Moolenaar said the following: > > > > On Sep 15, 2008, at 5:49 AM, Andriy Gapon wrote: > > > [snip] > >> > >> This is what I have in device.hints for uart: > >> hint.uart.0.at="isa" > >> hint.uart.0.port="0x3F8" > >> hint.uart.0.flags="0x10" > >> hint.uart.0.irq="4" > >> hint.uart.1.at="isa" > >> hint.uart.1.port="0x2F8" > >> hint.uart.1.irq="3" > >> hint.uart.2.at="isa" > >> > >> Precisely the same hints (s/uart/sio/) I had for sio. > > > > The hints are bogus. > [snip] > > BTW, I think that the following patch should be applied (made against > RELENG_7): > > --- a/sys/i386/conf/GENERIC.hints > +++ b/sys/i386/conf/GENERIC.hints > @@ -39,7 +39,7 @@ > hint.sio.0.flags="0x10" > hint.sio.0.irq="4" > hint.sio.1.at="isa" > -hint.sio.1.port="0x2F8" > +hint.sio.1.port="0x2E8" > hint.sio.1.irq="3" > hint.sio.2.at="isa" > hint.sio.2.disabled="1" > > This is from where I copied the wrong hint. I think the standard for uart1/sio1/com2 IS 0x2F8. maybe your BIOS was modified? Then again, to quote A. Tanenbaum: 'I love standards, there are so many to choose from' danny From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 07:35:31 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6D39106566C; Tue, 16 Sep 2008 07:35:31 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe14.tele2.se [212.247.155.161]) by mx1.freebsd.org (Postfix) with ESMTP id 017078FC1C; Tue, 16 Sep 2008 07:35:30 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=ZtwMFzhc6XSROYQlMkMA/A==:17 a=6I5d2MoRAAAA:8 a=ORaZzADKHaVeJ42eVcQA:9 a=9sO5otT3i1YC8U0OspMA:7 a=GjG0WebW57JNIsO3tdCtDadf15EA:4 a=LY0hPdMaydYA:10 Received: from [62.113.133.218] (account mc467741@c2i.net [62.113.133.218] verified) by mailfe14.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 336993831; Tue, 16 Sep 2008 09:35:28 +0200 From: Hans Petter Selasky To: Scott Long Date: Tue, 16 Sep 2008 09:37:16 +0200 User-Agent: KMail/1.9.7 References: <200809112044.43749.hselasky@c2i.net> <200809152229.28590.hselasky@c2i.net> <48CED452.6020709@samsco.org> In-Reply-To: <48CED452.6020709@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809160937.17718.hselasky@c2i.net> Cc: rink@freebsd.org, current@freebsd.org, fbsd-current@mawer.org, Julian Elischer , freebsd-usb@freebsd.org, volker@vwsoft.com, ticso@cicely.de, "M. Warner Losh" Subject: Re: "legacy" usb stack fixes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 07:35:31 -0000 On Monday 15 September 2008, Scott Long wrote: > Hans Petter Selasky wrote: > > Hi, > > > > Please find a link to my implementation. Panics when unplugging USB Mass > > Storage Devices is now a thing of the past, I hope. Any comments ? > > > > http://perforce.freebsd.org/chv.cgi?CH=149821 > > > > --HPS > > So you're sticking with a SIM per umass target, and adding a global lock? > Yes, and I don't free the SIM until unloading the "umass" module. --HPS From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 07:47:47 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6910D106564A for ; Tue, 16 Sep 2008 07:47:47 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail34.syd.optusnet.com.au (mail34.syd.optusnet.com.au [211.29.133.218]) by mx1.freebsd.org (Postfix) with ESMTP id EEA6C8FC0A for ; Tue, 16 Sep 2008 07:47:41 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail34.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m8G7kx0s028397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Sep 2008 17:47:00 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.2) with ESMTP id m8G7kxBa045227; Tue, 16 Sep 2008 17:46:59 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m8G7kwgg045226; Tue, 16 Sep 2008 17:46:58 +1000 (EST) (envelope-from peter) Date: Tue, 16 Sep 2008 17:46:57 +1000 From: Peter Jeremy To: Pedro Giffuni Message-ID: <20080916074657.GF15376@server.vk2pj.dyndns.org> References: <179579.54770.qm@web32701.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9xA8aadJAx1hWuKz" Content-Disposition: inline In-Reply-To: <179579.54770.qm@web32701.mail.mud.yahoo.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Xin LI , freebsd-current@freebsd.org, Oliver Fromme , Jung-uk Kim Subject: Re: Why VESA and DPMS are available only for i386? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 07:47:47 -0000 --9xA8aadJAx1hWuKz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Sep-15 13:43:31 -0700, Pedro Giffuni = wrote: >I can't find any reference, but according to the Wikipedia, even in long m= ode AMD64 is able to run 16-bit (or 80286) protected mode applications: AMD64 Architecture Programmer's Manual, Volume 1: Application Programming - No. 24592 states: "Compatibility mode - the second submode of long mode - allows 64-bit operating systems to run existing 16-bit and 32-bit x86 applications. These legacy applications run in compatibility mode without recompilation." --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --9xA8aadJAx1hWuKz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjPZHEACgkQ/opHv/APuIcAuwCgtUmmJp0lq0mJq4E2pwNIvfrf ToYAninvGdkxJ9Xe0m1oVUqzmItOD6vt =ErQj -----END PGP SIGNATURE----- --9xA8aadJAx1hWuKz-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 09:06:18 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCD4C1065679 for ; Tue, 16 Sep 2008 09:06:18 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 36EC68FC1C for ; Tue, 16 Sep 2008 09:06:18 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id m8G968V8020866; Tue, 16 Sep 2008 11:06:08 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id m8G967H4020865; Tue, 16 Sep 2008 11:06:07 +0200 (CEST) (envelope-from olli) Date: Tue, 16 Sep 2008 11:06:07 +0200 (CEST) Message-Id: <200809160906.m8G967H4020865@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, cpghost@cordula.ws, stephen@math.missouri.edu In-Reply-To: <20080915185446.GB69615@phenom.cordula.ws> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 16 Sep 2008 11:06:09 +0200 (CEST) Cc: Subject: Re: Improved multiprocessor usage on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, cpghost@cordula.ws, stephen@math.missouri.edu List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 09:06:18 -0000 cpghost wrote: > On Sun, Sep 14, 2008 at 08:38:00PM -0500, Stephen Montgomery-Smith wrote: > > I have a dual core amd64 on which I run a processor intensive numerical > > program. I had been frustrated because it seemed to run 3 or 4 times > > faster under Linux. But with a recent upgrade of FreeBSD-CURRENT, it > > now goes at about the same speed as Linux. > > > > The program takes about an hour. For the first minute, the program runs > > rather slowly, but then it is as if the operating system finds its way, > > and suddenly it speeds up. "top -H" suggests that for the first minute > > that one thread is going really slowly, and is perhaps being starved or > > something. > > > > My question is - why is this happening, and is this something I should > > expect? Are there certain switches or sysctls I can set to make it go > > fast from the get go? > > It looks like you're running powerd (see in /etc/rc.conf). It can take up > to a minute for the load average of the machine to exceed a certain > threshold where powerd would finally bump the cpu(s) to full speed. No. powerd(8) does not look at the load average at all, it looks at the CPU usage. It detects within 0.5 seconds (the default polling interval) when the CPU usage went up and starts adjusting the performance. It certainly doesn't take a minute. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mn- chen, HRB 125758, Geschftsfhrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I invented Ctrl-Alt-Delete, but Bill Gates made it famous." -- David Bradley, original IBM PC design team From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 09:23:31 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AF101065675 for ; Tue, 16 Sep 2008 09:23:31 +0000 (UTC) (envelope-from hpcharles@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by mx1.freebsd.org (Postfix) with ESMTP id 5D6818FC1C for ; Tue, 16 Sep 2008 09:23:31 +0000 (UTC) (envelope-from hpcharles@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so3401185rvf.43 for ; Tue, 16 Sep 2008 02:23:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=CDnWMgunSR/CAb3WCYsy13FcYTFk7EwLPuB8kXgnd2U=; b=GzOCOUrsw24s3pfBrm6D9+QpiiTQ6fEYlGrPY4UXM1/APxWgBIOzYVZ3qSfptAItoC y7m7xtZ7OtO/LDZvYkDPKQQwFVd8CYR8sDq/7nfvxxeh+TKkYbXTcLUxO4GD37kEImmD C/aNjfhrK5QabRypNZ11DU8HnZALIfH9pSdrc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=OKHkOcYuQCELPHYrhyo5K5qBcDjcN4ORMQoiubRmfxe75djT9a8OgHecQSgnEVv7tj D/meJ3Lj1HLvqm3mhUUtJOr4DTFzCswezExMwIZ3R9HloM7EcGYFdQeHcZ7FSsZbhioh 8Z1AeNjtg1cu6p2569loHZ/nRj/05w4lCfp6M= Received: by 10.142.191.10 with SMTP id o10mr271894wff.94.1221557010836; Tue, 16 Sep 2008 02:23:30 -0700 (PDT) Received: by 10.142.203.16 with HTTP; Tue, 16 Sep 2008 02:23:30 -0700 (PDT) Message-ID: <4734a3ed0809160223p6ddc6fd5pacb901ea9dfccfe3@mail.gmail.com> Date: Tue, 16 Sep 2008 11:23:30 +0200 From: "Henri-Pierre Charles" To: "Rui Paulo" In-Reply-To: <4734a3ed0809150659n438a5b20r59278908f4032a45@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080828002919.GA54169@alpha.local> <4734a3ed0809150659n438a5b20r59278908f4032a45@mail.gmail.com> Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: HEADS UP: ath_hal updated to 0.10.5.10 -- PLEASE TEST X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hpcharles@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 09:23:31 -0000 Hello, (I reply to myself) On Mon, Sep 15, 2008 at 3:59 PM, Henri-Pierre Charles wrote: > Hi, > > On Thu, Aug 28, 2008 at 2:29 AM, Rui Paulo wrote: >> We've updated ath_hal in HEAD to 0.10.5.10. This supports a couple of >> new chips, namely those on the Asus Eee PC, MacBooks and other laptops. > > It's included into 8.0-CURRENT-200809-i386 snapshot if I understand correctly. > I've tried 7.1-BETA and 8.0-CURRENT-200809 on my eeepc model 701 > > 7.1 does not recognize ath0, as expected, but 8.0-CURRENT does. > The corresponding dmesg can be found here : > > * http://www.prism.uvsq.fr/~hpc/pmwiki/uploads/Data/dmesg-7.1-BETA.txt > * http://www.prism.uvsq.fr/~hpc/pmwiki/uploads/Data/dmesg-8.0-200809.txt > > The 8.0-CURRENT-200809-i386 contain ath_hal 0.10.5.10 but I was unable > to use the interface. "dhclient ath0" never give up. Let me know if I > can try something. I discover a "new" way to configure network interface, with wlan I have tried to put in my rc.conf: wlans_ath0=wlan0 ifconfig_wlan0="WPA DHCP" And .. it works, with a WPA2 configuration and also with only DHCP. Conclusion 8-0-CURRENT-200809 work out of the box for the eeepc 701. The only documentation I have found is http://people.freebsd.org/~sam/BSDCan2005.pdf . Is there something more substantial ? > And what about the rj45 interface for eee 701 ? Any chance to be supported > in a near future ? Any tips ? H-P -- HPC From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 09:52:18 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCAFC106566B; Tue, 16 Sep 2008 09:52:18 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 42F7D8FC2F; Tue, 16 Sep 2008 09:52:18 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from vhoffman.lon.namesco.net (150.117-84-212.staticip.namesco.net [212.84.117.150]) (authenticated bits=0) by unsane.co.uk (8.14.0/8.14.0) with ESMTP id m8G9qNNc007877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Sep 2008 10:52:24 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <48CF81CE.2070608@unsane.co.uk> Date: Tue, 16 Sep 2008 10:52:14 +0100 From: Vincent Hoffman User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: hpcharles@gmail.com References: <20080828002919.GA54169@alpha.local> <4734a3ed0809150659n438a5b20r59278908f4032a45@mail.gmail.com> <4734a3ed0809160223p6ddc6fd5pacb901ea9dfccfe3@mail.gmail.com> In-Reply-To: <4734a3ed0809160223p6ddc6fd5pacb901ea9dfccfe3@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Rui Paulo , freebsd-mobile@freebsd.org Subject: Re: HEADS UP: ath_hal updated to 0.10.5.10 -- PLEASE TEST X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 09:52:19 -0000 Henri-Pierre Charles wrote: > Hello, (I reply to myself) > > On Mon, Sep 15, 2008 at 3:59 PM, Henri-Pierre Charles > wrote: > >> Hi, >> >> On Thu, Aug 28, 2008 at 2:29 AM, Rui Paulo wrote: >> >>> We've updated ath_hal in HEAD to 0.10.5.10. This supports a couple of >>> new chips, namely those on the Asus Eee PC, MacBooks and other laptops. >>> >> It's included into 8.0-CURRENT-200809-i386 snapshot if I understand correctly. >> I've tried 7.1-BETA and 8.0-CURRENT-200809 on my eeepc model 701 >> >> 7.1 does not recognize ath0, as expected, but 8.0-CURRENT does. >> The corresponding dmesg can be found here : >> >> * http://www.prism.uvsq.fr/~hpc/pmwiki/uploads/Data/dmesg-7.1-BETA.txt >> * http://www.prism.uvsq.fr/~hpc/pmwiki/uploads/Data/dmesg-8.0-200809.txt >> >> The 8.0-CURRENT-200809-i386 contain ath_hal 0.10.5.10 but I was unable >> to use the interface. "dhclient ath0" never give up. Let me know if I >> can try something. >> > > I discover a "new" way to configure network interface, with wlan > I have tried to put in my rc.conf: > wlans_ath0=wlan0 > ifconfig_wlan0="WPA DHCP" > > And .. it works, with a WPA2 configuration and also with only DHCP. > Conclusion 8-0-CURRENT-200809 work out of the box for the eeepc 701. > > The only documentation I have found is > http://people.freebsd.org/~sam/BSDCan2005.pdf . Is there something > more substantial ? > > /usr/src/UPDATING check the 20080420 entry. Always check this when updating your sources unless you read every mail on the current@ mailing list and even then its worth checking it. Vince >> And what about the rj45 interface for eee 701 ? Any chance to be supported >> in a near future ? >> > > Any tips ? > > H-P > > From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 10:34:39 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FA66106564A for ; Tue, 16 Sep 2008 10:34:39 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 4254E8FC08 for ; Tue, 16 Sep 2008 10:34:31 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 097CA74419C; Tue, 16 Sep 2008 13:34:30 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWSlqfov-rYg; Tue, 16 Sep 2008 13:34:29 +0300 (EEST) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [91.198.50.114]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 64619744173; Tue, 16 Sep 2008 13:34:29 +0300 (EEST) Message-ID: <48CF8BB4.6050203@icyb.net.ua> Date: Tue, 16 Sep 2008 13:34:28 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.16 (X11/20080805) MIME-Version: 1.0 To: Danny Braniss References: <48CE59C2.9060307@icyb.net.ua> <48CEC04C.8000707@icyb.net.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mike Tancsa , Marcel Moolenaar , Ian Smith , freebsd-current@freebsd.org Subject: Re: sio => uart: one port is gone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 10:34:39 -0000 on 16/09/2008 09:14 Danny Braniss said the following: >> BTW, I think that the following patch should be applied (made against >> RELENG_7): >> >> --- a/sys/i386/conf/GENERIC.hints >> +++ b/sys/i386/conf/GENERIC.hints >> @@ -39,7 +39,7 @@ >> hint.sio.0.flags="0x10" >> hint.sio.0.irq="4" >> hint.sio.1.at="isa" >> -hint.sio.1.port="0x2F8" >> +hint.sio.1.port="0x2E8" >> hint.sio.1.irq="3" >> hint.sio.2.at="isa" >> hint.sio.2.disabled="1" >> >> This is from where I copied the wrong hint. > > I think the standard for uart1/sio1/com2 IS 0x2F8. maybe your BIOS was > modified? Got it, thank you. Sorry for the noise. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 11:00:46 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BAC51065673; Tue, 16 Sep 2008 11:00:46 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from bene1.itea.ntnu.no (bene1.itea.ntnu.no [IPv6:2001:700:300:3::56]) by mx1.freebsd.org (Postfix) with ESMTP id B973A8FC13; Tue, 16 Sep 2008 11:00:45 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from localhost (localhost [127.0.0.1]) by bene1.itea.ntnu.no (Postfix) with ESMTP id AFE3116C534; Tue, 16 Sep 2008 13:00:44 +0200 (CEST) Received: from carrot.studby.ntnu.no (unknown [IPv6:2001:700:300:3::184]) by bene1.itea.ntnu.no (Postfix) with ESMTP id 28F145359; Tue, 16 Sep 2008 13:00:44 +0200 (CEST) Date: Tue, 16 Sep 2008 13:03:46 +0200 From: Ulf Lilleengen To: freebsd-current@freebsd.org Message-ID: <20080916110346.GA12643@carrot.studby.ntnu.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="G4iJoqBmSsgzjUCe" Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-Virus-Scanned: Debian amavisd-new at bene1.itea.ntnu.no Cc: freebsd-hackers@freebsd.org, freebsd-wip-status@freebsd.org Subject: [PATCH] New patch for cvsmode in csup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 11:00:46 -0000 --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, Time again for a csup patch. There have been many improvements to make it b= ehave like cvsup in most circumstanses. A few notes: * Fixed a "bug" where csup would crash if the diff was not applied correctl= y, requiring changing the procedure on how diffs are applied within csup. * Fix so files added/removed to/from Attic will actually get removed from t= he client, making it work equally to csup. * Fix so the checkouts/status-file is mostly correctly updated, but this do= es=20 only matter a little if one mixes usage with csup/cvsup. * Note that updating of CVSROOT-* might take longer time than cvsup, because cvsup supports rsync algorithm, which fits those files better. * A lot of cleanups to the code, making it ready for review. Thanks to kris@ for helping out with testing. If anyone would like to review this patch, that would be nice. The patch can be found here: http://people.freebsd.org/~lulf/patches/csup/csup_09_16_2008.diff --=20 Ulf Lilleengen --G4iJoqBmSsgzjUCe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjPkpIACgkQCILg8nMIdCUlEwCcCjD5mubL+U7U+hly3WuL3jkU a94An3SnuplAzwmhhXwF5wpxDOnqU24m =rC2F -----END PGP SIGNATURE----- --G4iJoqBmSsgzjUCe-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 13:14:12 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7787D106566B; Tue, 16 Sep 2008 13:14:12 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id 3621F8FC16; Tue, 16 Sep 2008 13:14:12 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1KfaNe-000Iso-89; Tue, 16 Sep 2008 16:14:10 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-scsi@FreeBSD.org, freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Sep 2008 16:14:10 +0300 From: Danny Braniss Message-ID: Cc: Subject: PERC6/i/e cli X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 13:14:12 -0000 hi, mfi is ok, mfi0@pci0:1:0:0: class=0x010400 card=0x1f0c1028 chip=0x00601000 rev=0x04 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' device = 'SAS1078 PCI-X Fusion-MPT SAS' class = mass storage subclass = RAID mfi1@pci0:10:0:0: class=0x010400 card=0x1f0a1028 chip=0x00601000 rev=0x04 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' device = 'SAS1078 PCI-X Fusion-MPT SAS' class = mass storage subclass = RAID ... mfi0: port 0xec00-0xecff mem 0xfc980000-0xfc9bffff,0xfc940000-0xf c97ffff irq 16 at device 0.0 on pci1 mfi0: Megaraid SAS driver Ver 2.00 mfi0: [ITHREAD] pcib8: at device 4.0 on pci0 pci10: on pcib8 mfi1: port 0xdc00-0xdcff mem 0xfc780000-0xfc7bffff,0xfc740000-0xf c77ffff irq 16 at device 0.0 on pci10 mfi1: Megaraid SAS driver Ver 2.00 mfi1: [ITHREAD] ... mfid0: on mfi0 mfid0: 953344MB (1952448512 sectors) RAID volume '' is optimal mfid1: on mfi1 mfid1: 13346816MB (27334279168 sectors) RAID volume '' is optimal but megacli does not talk to it, am I missing something, or is there another cli that does work? thanks, danny From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 13:32:34 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6137A1065676 for ; Tue, 16 Sep 2008 13:32:34 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 1322C8FC17 for ; Tue, 16 Sep 2008 13:32:33 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id 3298E1B10EDC; Tue, 16 Sep 2008 15:32:32 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on malcho.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-8.8 required=5.0 tests=ALL_TRUSTED,BAYES_00, J_CHICKENPOX_52, J_CHICKENPOX_82, J_CHICKENPOX_92 autolearn=no version=3.2.4 Received: from hater.haters.org (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 022051B10EA4; Tue, 16 Sep 2008 15:32:30 +0200 (CEST) Message-ID: <48CFB56D.3070908@moneybookers.com> Date: Tue, 16 Sep 2008 16:32:29 +0300 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.16 (X11/20080813) MIME-Version: 1.0 To: Danny Braniss References: In-Reply-To: Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@FreeBSD.org, freebsd-current@freebsd.org Subject: Re: PERC6/i/e cli X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 13:32:34 -0000 Greetings, Danny Braniss wrote: > hi, mfi is ok, > > mfi0@pci0:1:0:0: class=0x010400 card=0x1f0c1028 chip=0x00601000 > rev=0x04 hdr=0x00 > vendor = 'LSI Logic (Was: Symbios Logic, NCR)' > device = 'SAS1078 PCI-X Fusion-MPT SAS' > class = mass storage > subclass = RAID > mfi0@pci0:1:0:0: class=0x010400 card=0x1f0c1028 chip=0x00601000 rev=0x04 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' device = 'SAS1078 PCI-X Fusion-MPT SAS' class = mass storage subclass = RAID (exactly the same model) and linux-megacli-1.01.40_1 works well with it. (freebsd 7 - amd64) If you search the mailing lists you will find that similar problems can happen if modules are not loaded in the proper way. I have in /boot/loader.conf: linux_load="YES" mfi_linux_load="YES" which loads: linux.ko mfi_linux.ko and also: (because of fstab) linprocfs.ko linsysfs.ko Then you can put in your periodic.conf - daily_status_mfi_raid_enable="YES" and you will receive in your daily mails something like: Virtual Drive Information: VD DRV RLP RLS RLQ STS SIZE STATE NAME 0 2 1 0 0 64kB 139392MB Optimal Ah and btw I think it was mandatory to have compat.linux.osrelease=2.6.12 (2.6.16 works too but you have to fix the script to not complain - i think the port is still not fixed?) > mfi1@pci0:10:0:0: class=0x010400 card=0x1f0a1028 chip=0x00601000 > rev=0x04 hdr=0x00 > vendor = 'LSI Logic (Was: Symbios Logic, NCR)' > device = 'SAS1078 PCI-X Fusion-MPT SAS' > class = mass storage > subclass = RAID > > ... > mfi0: port 0xec00-0xecff mem 0xfc980000-0xfc9bffff,0xfc940000-0xf > c97ffff irq 16 at device 0.0 on pci1 > mfi0: Megaraid SAS driver Ver 2.00 > mfi0: [ITHREAD] > pcib8: at device 4.0 on pci0 > pci10: on pcib8 > mfi1: port 0xdc00-0xdcff mem 0xfc780000-0xfc7bffff,0xfc740000-0xf > c77ffff irq 16 at device 0.0 on pci10 > mfi1: Megaraid SAS driver Ver 2.00 > mfi1: [ITHREAD] > ... > mfid0: on mfi0 > mfid0: 953344MB (1952448512 sectors) RAID volume '' is optimal > mfid1: on mfi1 > mfid1: 13346816MB (27334279168 sectors) RAID volume '' is optimal > > but megacli does not talk to it, am I missing something, or is there another > cli that does work? > > thanks, > danny > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 13:40:08 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1502C1065676 for ; Tue, 16 Sep 2008 13:40:08 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from fw.farid-hajji.net (fw.farid-hajji.net [213.146.115.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9F8F68FC19 for ; Tue, 16 Sep 2008 13:40:07 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from phenom.cordula.ws (phenom [192.168.254.60]) by fw.farid-hajji.net (Postfix) with ESMTP id 63B86352D2; Tue, 16 Sep 2008 15:40:05 +0200 (CEST) Date: Tue, 16 Sep 2008 13:40:11 +0000 From: cpghost To: freebsd-current@FreeBSD.ORG Message-ID: <20080916134011.GA18208@phenom.cordula.ws> References: <20080915185446.GB69615@phenom.cordula.ws> <200809160906.m8G967H4020865@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200809160906.m8G967H4020865@lurza.secnetix.de> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Subject: Re: Improved multiprocessor usage on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 13:40:08 -0000 On Tue, Sep 16, 2008 at 11:06:07AM +0200, Oliver Fromme wrote: > cpghost wrote: > > On Sun, Sep 14, 2008 at 08:38:00PM -0500, Stephen Montgomery-Smith wrote: > > > I have a dual core amd64 on which I run a processor intensive numerical > > > program. I had been frustrated because it seemed to run 3 or 4 times > > > faster under Linux. But with a recent upgrade of FreeBSD-CURRENT, it > > > now goes at about the same speed as Linux. > > > > > > The program takes about an hour. For the first minute, the program runs > > > rather slowly, but then it is as if the operating system finds its way, > > > and suddenly it speeds up. "top -H" suggests that for the first minute > > > that one thread is going really slowly, and is perhaps being starved or > > > something. > > > > > > My question is - why is this happening, and is this something I should > > > expect? Are there certain switches or sysctls I can set to make it go > > > fast from the get go? > > > > It looks like you're running powerd (see in /etc/rc.conf). It can take up > > to a minute for the load average of the machine to exceed a certain > > threshold where powerd would finally bump the cpu(s) to full speed. > > No. powerd(8) does not look at the load average at all, > it looks at the CPU usage. It detects within 0.5 seconds > (the default polling interval) when the CPU usage went up > and starts adjusting the performance. It certainly doesn't > take a minute. Oh, yes, you're right: I stand corrected. powerd looks at the kern.cp_time sysctl and not at the load average. > Best regards > Oliver Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 14:03:27 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60C1F1065673 for ; Tue, 16 Sep 2008 14:03:27 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id D1CEC8FC1E for ; Tue, 16 Sep 2008 14:03:26 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.3/8.14.3) with ESMTP id m8GE3OPH036203 for ; Tue, 16 Sep 2008 18:03:24 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1221573804; bh=5jkWtRLxW+m5gdQ9pQMOdIdMAXhgpFspzYKDvA0 Ll/A=; l=427; h=Date:From:To:Subject:Message-ID:MIME-Version: Content-Type; b=F8+p8D2mOy8IRErx4slVCK4E8p5OAiTsjICr/qbT14ismRHONQ OQZxtUKHSg80JSFYh7EXP+ugkZEidfLKhufocbM3H5X6XURnIfUj+cFwD7p1OHZxMG5 EZPSDXDlbFCg0sDrNDAW/fuPkQFqeRGYUl1QRx38Hvh8u7KcxwN9C4= Received: (from ache@localhost) by nagual.pp.ru (8.14.3/8.14.3/Submit) id m8GE3Lci036202 for current@freebsd.org; Tue, 16 Sep 2008 18:03:21 +0400 (MSD) (envelope-from ache) Date: Tue, 16 Sep 2008 18:03:20 +0400 From: Andrey Chernov To: current@freebsd.org Message-ID: <20080916140319.GA34447@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Subject: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 14:03:27 -0000 I need some sort of fork() hook to detect that pid is changed to re-stir ar4random() after that (in the child), simple flag variable with child's pid is needed. Currently OpenBSD does almost that checking getpid() every time arc4random() called, but it is very slow way to use getpid() syscall repeatedly, about 12-15 times slower than just arc4random() without getpid(). Any ideas? -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 14:24:10 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F8801065670 for ; Tue, 16 Sep 2008 14:24:10 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [216.101.162.50]) by mx1.freebsd.org (Postfix) with ESMTP id 2AC928FC16 for ; Tue, 16 Sep 2008 14:24:09 +0000 (UTC) (envelope-from null@pozo.com) Received: from T41p.pozo.com (t41p.pozo.com [192.168.0.4]) (authenticated bits=0) by pozo.com (8.14.3/8.14.3) with ESMTP id m8GEO3Qv074184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 16 Sep 2008 07:24:04 -0700 (PDT) (envelope-from null@pozo.com) Message-Id: <200809161424.m8GEO3Qv074184@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 16 Sep 2008 07:23:58 -0700 To: freebsd-current@freebsd.org From: Manfred Antar Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-101.4 required=5.0 tests=ALL_TRUSTED,MISSING_MID, USER_IN_WHITELIST autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on pozo.com X-Virus-Scanned: ClamAV 0.94-exp/8257/Tue Sep 16 01:29:49 2008 on pozo.com X-Virus-Status: Clean Subject: Fdisk broken on Current ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 14:24:10 -0000 Doing a buildworld on current i386 it stops at : /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x1f1): In function `geom_xml2tree': : undefined reference to `XML_ParserCreate' /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x22d): In function `geom_xml2tree': : undefined reference to `XML_SetUserData' /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x245): In function `geom_xml2tree': : undefined reference to `XML_SetElementHandler' /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x255): In function `geom_xml2tree': : undefined reference to `XML_SetCharacterDataHandler' /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x27b): In function `geom_xml2tree': : undefined reference to `XML_Parse' /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x28d): In function `geom_xml2tree': : undefined reference to `XML_ParserFree' /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x4ed): In function `EndElement': : undefined reference to `sbuf_finish' /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x4fc): In function `EndElement': : undefined reference to `sbuf_data' /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x51e): In function `EndElement': : undefined reference to `sbuf_delete' /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x864): In function `StartElement': : undefined reference to `sbuf_new' /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0xd74): In function `CharData': : undefined reference to `sbuf_bcat' *** Error code 1 Stop in /usr/src/sbin/fdisk. *** Error code 1 ================================== || null@pozo.com || || Ph. (415) 681-6235 || ================================== From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 14:40:00 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5D581065676; Tue, 16 Sep 2008 14:40:00 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id 922898FC22; Tue, 16 Sep 2008 14:40:00 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1Kfbig-000JaQ-Mp; Tue, 16 Sep 2008 17:39:58 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Stefan Lambrev In-reply-to: <48CFB56D.3070908@moneybookers.com> References: <48CFB56D.3070908@moneybookers.com> Comments: In-reply-to Stefan Lambrev message dated "Tue, 16 Sep 2008 16:32:29 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Sep 2008 17:39:58 +0300 From: Danny Braniss Message-ID: Cc: freebsd-scsi@FreeBSD.org, freebsd-current@freebsd.org Subject: Re: PERC6/i/e cli X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 14:40:01 -0000 > Greetings, > > Danny Braniss wrote: > > hi, mfi is ok, > > > > mfi0@pci0:1:0:0: class=0x010400 card=0x1f0c1028 chip=0x00601000 > > rev=0x04 hdr=0x00 > > vendor = 'LSI Logic (Was: Symbios Logic, NCR)' > > device = 'SAS1078 PCI-X Fusion-MPT SAS' > > class = mass storage > > subclass = RAID > > > > mfi0@pci0:1:0:0: class=0x010400 card=0x1f0c1028 chip=0x00601000 > rev=0x04 hdr=0x00 > vendor = 'LSI Logic (Was: Symbios Logic, NCR)' > device = 'SAS1078 PCI-X Fusion-MPT SAS' > class = mass storage > subclass = RAID > (exactly the same model) > and linux-megacli-1.01.40_1 works well with it. (freebsd 7 - amd64) > > If you search the mailing lists you will find that similar problems can > happen if > modules are not loaded in the proper way. > > I have in /boot/loader.conf: > linux_load="YES" > mfi_linux_load="YES" > > which loads: > linux.ko > mfi_linux.ko > and also: (because of fstab) > linprocfs.ko > linsysfs.ko > > Then you can put in your periodic.conf - daily_status_mfi_raid_enable="YES" > and you will receive in your daily mails something like: > > Virtual Drive Information: > VD DRV RLP RLS RLQ STS SIZE STATE NAME > 0 2 1 0 0 64kB 139392MB Optimal > > Ah and btw I think it was mandatory to have compat.linux.osrelease=2.6.12 > (2.6.16 works too but you have to fix the script to not complain - i > think the port is still not fixed?) > Ah, the order does affect the result! great, it now works for me too. thanks! > Best Wishes, > Stefan Lambrev > ICQ# 24134177 > From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 14:45:04 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB85A106566C for ; Tue, 16 Sep 2008 14:45:04 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 262428FC22 for ; Tue, 16 Sep 2008 14:45:03 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.3/8.14.3) with ESMTP id m8GEj2hR039882; Tue, 16 Sep 2008 18:45:02 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1221576302; bh=2uU5oknZEBbCOUTedldxoZ1Qw9FCqrMDOtGjV2m YbNs=; l=843; h=Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:In-Reply-To; b=A9zbJ4zWKnWDYslD2pjIjVoaW OBAKYqaxmjs7gRzEHyajj7Sv8iF3EoifBBEJBIZYPaFhN62K6nkmQV6oTYBL6NS/a14 0IV2X13ASzgopYp714pCwXRrxUX+ROurL1VvZMOrp1c4FWnwH5T2k7NjbAOFeE7CxAY INsQLk+yurq4= Received: (from ache@localhost) by nagual.pp.ru (8.14.3/8.14.3/Submit) id m8GEj2Qp039881; Tue, 16 Sep 2008 18:45:02 +0400 (MSD) (envelope-from ache) Date: Tue, 16 Sep 2008 18:45:02 +0400 From: Andrey Chernov To: Bob Bishop Message-ID: <20080916144502.GA39765@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Bob Bishop , current@freebsd.org References: <20080916140319.GA34447@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: current@freebsd.org Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 14:45:04 -0000 On Tue, Sep 16, 2008 at 03:38:16PM +0100, Bob Bishop wrote: > Hi, > > On 16 Sep 2008, at 15:03, Andrey Chernov wrote: > > > I need some sort of fork() hook to detect that pid is changed to re- > > stir > > ar4random() after that (in the child), simple flag variable with > > child's pid is needed. > > > > Currently OpenBSD does almost that checking getpid() every time > > arc4random() called, but it is very slow way to use getpid() syscall > > repeatedly, about 12-15 times slower than just arc4random() without > > getpid(). > > > > Any ideas? > > How about something hacky using mmap()/minherit()? Could you please provide working low cost example to detect that we are in the child (pid changed or something else)? Calling getpid() as OpenBSD does definitely is very high cost. :( -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 14:54:01 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E02B106566C for ; Tue, 16 Sep 2008 14:54:01 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-gx0-f17.google.com (mail-gx0-f17.google.com [209.85.217.17]) by mx1.freebsd.org (Postfix) with ESMTP id E7CCA8FC0C for ; Tue, 16 Sep 2008 14:53:55 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by gxk10 with SMTP id 10so25495008gxk.19 for ; Tue, 16 Sep 2008 07:53:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=IzaR1TlTflAHPjKgF8AG4EJHS1Sld4NV4EThfFhbX2w=; b=U//z3cpZ8z5wWksOlLEkfYqK6hhfMXojB1NwjoXtT/JdVPT1vFNZQX6LvT2Pr+iblC RA2tWGdskpJgDm0RnuU1PwS2bCCdPumm1P0KMox8amXv2+dtxJ0qbHs9QrkqkTXajItn QO79njKC95RRh291u2WsYzAL84hutzn2P14Vg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=dxCAhzevPe0dDI0C8NnJcWNZsgSsKDD3Tt0ClfIz+U5JoswORY59X6ZGvjfbwMV/Ld dsWrj3JHXmaDMLPhZYaWXJ9wimm7KqBuaacv0/PJQtfNa1d/sXL+PJnj3bAtETarsI21 fe9jWzKGl3pOBArEst56xMpPoTA7Dh2FAaw7s= Received: by 10.103.211.3 with SMTP id n3mr771428muq.43.1221576834083; Tue, 16 Sep 2008 07:53:54 -0700 (PDT) Received: by 10.103.239.14 with HTTP; Tue, 16 Sep 2008 07:53:54 -0700 (PDT) Message-ID: <3bbf2fe10809160753o7e5e8a78q7c6bd44c02bfd5c2@mail.gmail.com> Date: Tue, 16 Sep 2008 16:53:54 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Andrey Chernov" , "Bob Bishop" , current@freebsd.org In-Reply-To: <20080916144502.GA39765@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080916140319.GA34447@nagual.pp.ru> <20080916144502.GA39765@nagual.pp.ru> X-Google-Sender-Auth: 40842ea934c8271e Cc: Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 14:54:01 -0000 2008/9/16, Andrey Chernov : > On Tue, Sep 16, 2008 at 03:38:16PM +0100, Bob Bishop wrote: > > Hi, > > > > > On 16 Sep 2008, at 15:03, Andrey Chernov wrote: > > > > > I need some sort of fork() hook to detect that pid is changed to re- > > > stir > > > ar4random() after that (in the child), simple flag variable with > > > child's pid is needed. > > > > > > Currently OpenBSD does almost that checking getpid() every time > > > arc4random() called, but it is very slow way to use getpid() syscall > > > repeatedly, about 12-15 times slower than just arc4random() without > > > getpid(). > > > > > > Any ideas? > > > > > How about something hacky using mmap()/minherit()? > > Could you please provide working low cost example to detect that we are in > the child (pid changed or something else)? Calling getpid() as OpenBSD > does definitely is very high cost. :( An idea would be to implement a shared page between process and system which exports such informations. I'm sure we have a SoC project (2007) implementing this and perforce branches for it, I'm just not sure how far it did end. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 15:00:44 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D86671065670 for ; Tue, 16 Sep 2008 15:00:44 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 74BB58FC20 for ; Tue, 16 Sep 2008 15:00:38 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from gidgate.gid.co.uk (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id m8GEcRl9092544; Tue, 16 Sep 2008 15:38:27 +0100 (BST) (envelope-from rb@gid.co.uk) Received: from [192.168.2.3] (host81-151-132-23.range81-151.btcentralplus.com [81.151.132.23]) by gidgate.gid.co.uk (8.13.8/8.13.8) with ESMTP id m8GEcLTw041100; Tue, 16 Sep 2008 15:38:21 +0100 (BST) (envelope-from rb@gid.co.uk) Message-Id: From: Bob Bishop To: Andrey Chernov In-Reply-To: <20080916140319.GA34447@nagual.pp.ru> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 16 Sep 2008 15:38:16 +0100 References: <20080916140319.GA34447@nagual.pp.ru> X-Mailer: Apple Mail (2.929.2) Cc: current@freebsd.org Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 15:00:44 -0000 Hi, On 16 Sep 2008, at 15:03, Andrey Chernov wrote: > I need some sort of fork() hook to detect that pid is changed to re- > stir > ar4random() after that (in the child), simple flag variable with > child's pid is needed. > > Currently OpenBSD does almost that checking getpid() every time > arc4random() called, but it is very slow way to use getpid() syscall > repeatedly, about 12-15 times slower than just arc4random() without > getpid(). > > Any ideas? How about something hacky using mmap()/minherit()? > -- > http://ache.pp.ru/ > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > " > -- Bob Bishop rb@gid.co.uk From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 15:01:25 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 876DB1065677 for ; Tue, 16 Sep 2008 15:01:25 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id D4BA68FC0A for ; Tue, 16 Sep 2008 15:01:24 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.3/8.14.3) with ESMTP id m8GF1KdP040215; Tue, 16 Sep 2008 19:01:20 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1221577280; bh=gPiAbVRmLpon5clS7reva8rNT1mra+EGwpzMtQ+ DTfg=; l=1620; h=Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:In-Reply-To; b=ahWSmGtrCwujlro7+zpm+T1rs d5Iu0AwlrRa6mqxI1OxQT4MwYrIGSVc4swv9kLONAheNVyRD/YYtoWFQhJHz4YvEBYk +a/ahmKOuJwxtw4nnDPNQaUEhX4rtDnWDxaKsjgN005qvgpAMrGEjLpAcYw9hBTAJ+S ERv9gPiTJW2Q= Received: (from ache@localhost) by nagual.pp.ru (8.14.3/8.14.3/Submit) id m8GF1K1n040214; Tue, 16 Sep 2008 19:01:20 +0400 (MSD) (envelope-from ache) Date: Tue, 16 Sep 2008 19:01:20 +0400 From: Andrey Chernov To: Attilio Rao Message-ID: <20080916150120.GA40087@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Attilio Rao , Bob Bishop , current@freebsd.org References: <20080916140319.GA34447@nagual.pp.ru> <20080916144502.GA39765@nagual.pp.ru> <3bbf2fe10809160753o7e5e8a78q7c6bd44c02bfd5c2@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3bbf2fe10809160753o7e5e8a78q7c6bd44c02bfd5c2@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: current@freebsd.org Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 15:01:25 -0000 On Tue, Sep 16, 2008 at 04:53:54PM +0200, Attilio Rao wrote: > 2008/9/16, Andrey Chernov : > > On Tue, Sep 16, 2008 at 03:38:16PM +0100, Bob Bishop wrote: > > > Hi, > > > > > > > > On 16 Sep 2008, at 15:03, Andrey Chernov wrote: > > > > > > > I need some sort of fork() hook to detect that pid is changed to re- > > > > stir > > > > ar4random() after that (in the child), simple flag variable with > > > > child's pid is needed. > > > > > > > > Currently OpenBSD does almost that checking getpid() every time > > > > arc4random() called, but it is very slow way to use getpid() syscall > > > > repeatedly, about 12-15 times slower than just arc4random() without > > > > getpid(). > > > > > > > > Any ideas? > > > > > > > > How about something hacky using mmap()/minherit()? > > > > Could you please provide working low cost example to detect that we are in > > the child (pid changed or something else)? Calling getpid() as OpenBSD > > does definitely is very high cost. :( > > An idea would be to implement a shared page between process and system > which exports such informations. > I'm sure we have a SoC project (2007) implementing this and perforce > branches for it, I'm just not sure how far it did end. Please keep in mind that the hook itself must be invisible to user application, we have standard API only - fork() and arc4random() family, no additional setup or functions are possible outside of existen API. I.e. the low cost hack must be completely inside ether the fork() wrapper or arc4random(). -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 15:36:05 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C70F11065676 for ; Tue, 16 Sep 2008 15:36:05 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 6ADEF8FC19 for ; Tue, 16 Sep 2008 15:36:05 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id m8GFa3UC005867; Tue, 16 Sep 2008 11:36:03 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Tue, 16 Sep 2008 11:36:03 -0400 (EDT) Date: Tue, 16 Sep 2008 11:36:03 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Andrey Chernov In-Reply-To: <20080916150120.GA40087@nagual.pp.ru> Message-ID: References: <20080916140319.GA34447@nagual.pp.ru> <20080916144502.GA39765@nagual.pp.ru> <3bbf2fe10809160753o7e5e8a78q7c6bd44c02bfd5c2@mail.gmail.com> <20080916150120.GA40087@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Attilio Rao , current@freebsd.org Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 15:36:05 -0000 On Tue, 16 Sep 2008, Andrey Chernov wrote: > On Tue, Sep 16, 2008 at 04:53:54PM +0200, Attilio Rao wrote: >> 2008/9/16, Andrey Chernov : >>> On Tue, Sep 16, 2008 at 03:38:16PM +0100, Bob Bishop wrote: >>> > Hi, >>> >>>> >>> > On 16 Sep 2008, at 15:03, Andrey Chernov wrote: >>> > >>> >> I need some sort of fork() hook to detect that pid is changed to re- >>> >> stir >>> >> ar4random() after that (in the child), simple flag variable with >>> >> child's pid is needed. >>> >> >>> >> Currently OpenBSD does almost that checking getpid() every time >>> >> arc4random() called, but it is very slow way to use getpid() syscall >>> >> repeatedly, about 12-15 times slower than just arc4random() without >>> >> getpid(). >>> >> >>> >> Any ideas? >>> > >>> >>>> How about something hacky using mmap()/minherit()? >>> >>> Could you please provide working low cost example to detect that we are in >>> the child (pid changed or something else)? Calling getpid() as OpenBSD >>> does definitely is very high cost. :( >> >> An idea would be to implement a shared page between process and system >> which exports such informations. >> I'm sure we have a SoC project (2007) implementing this and perforce >> branches for it, I'm just not sure how far it did end. > > Please keep in mind that the hook itself must be invisible to user > application, we have standard API only - fork() and arc4random() family, > no additional setup or functions are possible outside of existen API. I.e. > the low cost hack must be completely inside ether the fork() wrapper or > arc4random(). Well, you could speed up getpid() by having libc wrap all fork() variants. The idea is that getpid() would only call __sys_getpid() the first time it was called and then only after a fork(). It would return the saved process id for all other cases. This wouldn't work if the application made its own syscall without going through libc. The shared page between process and system has been tossed around before and would probably be more benficial. Having access to time without making a syscall would be nice. -- DE From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 16:05:51 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C54161065673; Tue, 16 Sep 2008 16:05:51 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 53D828FC1A; Tue, 16 Sep 2008 16:05:45 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.3/8.14.3) with ESMTP id m8GG5gib041098; Tue, 16 Sep 2008 20:05:42 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1221581143; bh=U+sLeLy+G7XsvVX/TlyS9ina285e//T/Zp9iWvp d6Vs=; l=2810; h=Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:In-Reply-To; b=cnI8J62kI0kQmtWY+ml86FZ+c pFl6oCrx88Oc05gaz+l5L1dkMNTKswg5DdWcGavK0a6r0NY70MsjTNfEtqtsVtWWJ0v P9OZBirsk5bcxf8PzQruC6HFeQY3BGqIGnxx4M5GHwdpNwloZnNy+1DLYo1u0poOsLy LI/lECnEHXE4= Received: (from ache@localhost) by nagual.pp.ru (8.14.3/8.14.3/Submit) id m8GG5edj041097; Tue, 16 Sep 2008 20:05:40 +0400 (MSD) (envelope-from ache) Date: Tue, 16 Sep 2008 20:05:37 +0400 From: Andrey Chernov To: Daniel Eischen Message-ID: <20080916160535.GA40676@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Daniel Eischen , Attilio Rao , current@freebsd.org References: <20080916140319.GA34447@nagual.pp.ru> <20080916144502.GA39765@nagual.pp.ru> <3bbf2fe10809160753o7e5e8a78q7c6bd44c02bfd5c2@mail.gmail.com> <20080916150120.GA40087@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Attilio Rao , current@freebsd.org Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 16:05:51 -0000 On Tue, Sep 16, 2008 at 11:36:03AM -0400, Daniel Eischen wrote: > On Tue, 16 Sep 2008, Andrey Chernov wrote: > > > On Tue, Sep 16, 2008 at 04:53:54PM +0200, Attilio Rao wrote: > >> 2008/9/16, Andrey Chernov : > >>> On Tue, Sep 16, 2008 at 03:38:16PM +0100, Bob Bishop wrote: > >>> > Hi, > >>> > >>>> > >>> > On 16 Sep 2008, at 15:03, Andrey Chernov wrote: > >>> > > >>> >> I need some sort of fork() hook to detect that pid is changed to re- > >>> >> stir > >>> >> ar4random() after that (in the child), simple flag variable with > >>> >> child's pid is needed. > >>> >> > >>> >> Currently OpenBSD does almost that checking getpid() every time > >>> >> arc4random() called, but it is very slow way to use getpid() syscall > >>> >> repeatedly, about 12-15 times slower than just arc4random() without > >>> >> getpid(). > >>> >> > >>> >> Any ideas? > >>> > > >>> > >>>> How about something hacky using mmap()/minherit()? > >>> > >>> Could you please provide working low cost example to detect that we are in > >>> the child (pid changed or something else)? Calling getpid() as OpenBSD > >>> does definitely is very high cost. :( > >> > >> An idea would be to implement a shared page between process and system > >> which exports such informations. > >> I'm sure we have a SoC project (2007) implementing this and perforce > >> branches for it, I'm just not sure how far it did end. > > > > Please keep in mind that the hook itself must be invisible to user > > application, we have standard API only - fork() and arc4random() family, > > no additional setup or functions are possible outside of existen API. I.e. > > the low cost hack must be completely inside ether the fork() wrapper or > > arc4random(). > > Well, you could speed up getpid() by having libc wrap all fork() > variants. The idea is that getpid() would only call __sys_getpid() > the first time it was called and then only after a fork(). It > would return the saved process id for all other cases. > > This wouldn't work if the application made its own syscall > without going through libc. > > The shared page between process and system has been tossed around > before and would probably be more benficial. Having access to > time without making a syscall would be nice. Yes, speeding up getpid() by caching its pid is nice idea. But I am completely unaware how to create syscall wrappers inside libc. :( I think about something like that: __weak_reference(_fork, fork); pid_t _fork(void); pid_t _fork(void) { pid_t ret; if ((ret = __sys_fork()) == 0) _curr_pid = -1; return (ret); } But how it will coexists with the same __weak in thread/thr_fork.c ? Are some threading locks required in this code? -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 16:39:52 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 276601065670 for ; Tue, 16 Sep 2008 16:39:52 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.freebsd.org (Postfix) with ESMTP id ADDE08FC19 for ; Tue, 16 Sep 2008 16:39:51 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-010-043.pools.arcor-ip.net [88.66.10.43]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis) id 0MKwtQ-1KfdOO1B8C-0005c3; Tue, 16 Sep 2008 18:27:08 +0200 Received: (qmail 60298 invoked from network); 16 Sep 2008 16:27:07 -0000 Received: from fbsd8.laiers.local (192.168.4.151) by router.laiers.local with SMTP; 16 Sep 2008 16:27:07 -0000 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Tue, 16 Sep 2008 18:27:07 +0200 User-Agent: KMail/1.10.1 (FreeBSD/8.0-CURRENT; KDE/4.1.1; i386; ; ) References: <20080916140319.GA34447@nagual.pp.ru> In-Reply-To: <20080916140319.GA34447@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809161827.07627.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/1BdqWBDbvBL6epLhVz7oT8TzStzmFyt3keHD nf/VYRYlFOwT6eB4Zu1VAyddtq8Ta2JvfNb9234BBde/fNWFNr kn99Eed061olpG+6Cw/Kw== Cc: Andrey Chernov Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 16:39:52 -0000 On Tuesday 16 September 2008 16:03:20 Andrey Chernov wrote: > I need some sort of fork() hook to detect that pid is changed to re-stir > ar4random() after that (in the child), simple flag variable with > child's pid is needed. > > Currently OpenBSD does almost that checking getpid() every time > arc4random() called, but it is very slow way to use getpid() syscall > repeatedly, about 12-15 times slower than just arc4random() without > getpid(). > > Any ideas? I guess the goal here is not to leak the state of the seed to the child, right? Wouldn't it be easier to do something like this in libc's fork(): arc4random_stir(); /* create a new seed for the child */ fork_syscall(); if (parent) arc4random_stir(); /* create a new seed for the parent */ This should solve the problem and doesn't require any handling in arc4random. Of course, programs that call the fork syscall directly won't benefit, but then again ... they are using the syscall directly and should know what they are doing, right? -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 16:50:55 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12D40106567C; Tue, 16 Sep 2008 16:50:55 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id ABEEE8FC08; Tue, 16 Sep 2008 16:50:54 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id m8GGortX011704; Tue, 16 Sep 2008 12:50:53 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Tue, 16 Sep 2008 12:50:53 -0400 (EDT) Date: Tue, 16 Sep 2008 12:50:53 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Andrey Chernov In-Reply-To: <20080916160535.GA40676@nagual.pp.ru> Message-ID: References: <20080916140319.GA34447@nagual.pp.ru> <20080916144502.GA39765@nagual.pp.ru> <3bbf2fe10809160753o7e5e8a78q7c6bd44c02bfd5c2@mail.gmail.com> <20080916150120.GA40087@nagual.pp.ru> <20080916160535.GA40676@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Attilio Rao , current@freebsd.org Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 16:50:55 -0000 [ Trimmed ] On Tue, 16 Sep 2008, Andrey Chernov wrote: > On Tue, Sep 16, 2008 at 11:36:03AM -0400, Daniel Eischen wrote: > >> Well, you could speed up getpid() by having libc wrap all fork() >> variants. The idea is that getpid() would only call __sys_getpid() >> the first time it was called and then only after a fork(). It >> would return the saved process id for all other cases. > > Yes, speeding up getpid() by caching its pid is nice idea. > But I am completely unaware how to create syscall wrappers inside libc. :( > I think about something like that: > > __weak_reference(_fork, fork); I think you'll have to implement it as __fork() in libc, with _fork and fork both being weak references to __fork() in libc. The thread libraries will have to call __fork() instead of __sys_fork() by implementing "fork" as _fork() and providing a weak reference from fork to _fork. You can see wait() as an example. Probably rfork() and vfork() will need to be handled as well, though I don't think that the thread libraries care about these. > But how it will coexists with the same __weak in thread/thr_fork.c ? > Are some threading locks required in this code? I think you can do it without locks. After a fork() you are single threaded so you can easily set/clear __cur_thread. Otherwise, the worst case is that multiple threads will call _sys_getpid() simultaneously the first time, but as long as you atomically update __cur_thread, it won't matter - each thread will have retrieved the same exact process id so it is okay if they all update __cur_thread. pid_t __getpid(void) { if (__cur_thread != -1) return (__cur_thread); atomic_set_32(&__cur_thread, __sys_getpid()); return (__cur_thread); } __weak_reference(__getpid, getpid); __weak_reference(__getpid, _getpid); Or something like that... -- DE From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 17:09:53 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AB6F106564A for ; Tue, 16 Sep 2008 17:09:53 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id C426C8FC18 for ; Tue, 16 Sep 2008 17:09:52 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.3/8.14.3) with ESMTP id m8GGjwcJ041651; Tue, 16 Sep 2008 20:45:58 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1221583558; bh=WbTCRwNGElNMhrax+4zjEcqj07C3HWuo9kXLIUP /wBo=; l=1290; h=Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:In-Reply-To; b=MZmAFyAhaVuXKgGQbWxSuDF7X FhS008joMp1yaPgc+qcGu8TOr9/9LMxpF3CxbatU87yRlRxLvhW+Gfk1iD+6Z980m4U +wWd8fGtDphfoCQ6TxCy0AIT1q+8+80EtyEam0HE30wORIogBXtVl8ny4xCNcJ4e9EM YQCbq1TI9vzE= Received: (from ache@localhost) by nagual.pp.ru (8.14.3/8.14.3/Submit) id m8GGjwjg041650; Tue, 16 Sep 2008 20:45:58 +0400 (MSD) (envelope-from ache) Date: Tue, 16 Sep 2008 20:45:58 +0400 From: Andrey Chernov To: Max Laier Message-ID: <20080916164558.GA41258@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Max Laier , freebsd-current@freebsd.org References: <20080916140319.GA34447@nagual.pp.ru> <200809161827.07627.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200809161827.07627.max@love2party.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-current@freebsd.org Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 17:09:53 -0000 On Tue, Sep 16, 2008 at 06:27:07PM +0200, Max Laier wrote: > On Tuesday 16 September 2008 16:03:20 Andrey Chernov wrote: > > I need some sort of fork() hook to detect that pid is changed to re-stir > > ar4random() after that (in the child), simple flag variable with > > child's pid is needed. > > > > Currently OpenBSD does almost that checking getpid() every time > > arc4random() called, but it is very slow way to use getpid() syscall > > repeatedly, about 12-15 times slower than just arc4random() without > > getpid(). > > > > Any ideas? > > I guess the goal here is not to leak the state of the seed to the child, > right? > > Wouldn't it be easier to do something like this in libc's fork(): > > arc4random_stir(); /* create a new seed for the child */ > fork_syscall(); > if (parent) > arc4random_stir(); /* create a new seed for the parent */ > > This should solve the problem and doesn't require any handling in arc4random. > Of course, programs that call the fork syscall directly won't benefit, but > then again ... they are using the syscall directly and should know what they > are doing, right? Calling arc4random_stir() inside fork() will slow down fork() and is not acceptable because of it. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 17:31:58 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65DBE1065686 for ; Tue, 16 Sep 2008 17:31:58 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 27B688FC16 for ; Tue, 16 Sep 2008 17:31:57 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id m8GHLbNu017387; Tue, 16 Sep 2008 13:21:37 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Tue, 16 Sep 2008 13:21:37 -0400 (EDT) Date: Tue, 16 Sep 2008 13:21:37 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Andrey Chernov In-Reply-To: <20080916164558.GA41258@nagual.pp.ru> Message-ID: References: <20080916140319.GA34447@nagual.pp.ru> <200809161827.07627.max@love2party.net> <20080916164558.GA41258@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Max Laier , freebsd-current@freebsd.org Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 17:31:58 -0000 On Tue, 16 Sep 2008, Andrey Chernov wrote: > On Tue, Sep 16, 2008 at 06:27:07PM +0200, Max Laier wrote: >> On Tuesday 16 September 2008 16:03:20 Andrey Chernov wrote: >>> I need some sort of fork() hook to detect that pid is changed to re-stir >>> ar4random() after that (in the child), simple flag variable with >>> child's pid is needed. >>> >>> Currently OpenBSD does almost that checking getpid() every time >>> arc4random() called, but it is very slow way to use getpid() syscall >>> repeatedly, about 12-15 times slower than just arc4random() without >>> getpid(). >>> >>> Any ideas? >> >> I guess the goal here is not to leak the state of the seed to the child, >> right? >> >> Wouldn't it be easier to do something like this in libc's fork(): >> >> arc4random_stir(); /* create a new seed for the child */ >> fork_syscall(); >> if (parent) >> arc4random_stir(); /* create a new seed for the parent */ >> >> This should solve the problem and doesn't require any handling in arc4random. >> Of course, programs that call the fork syscall directly won't benefit, but >> then again ... they are using the syscall directly and should know what they >> are doing, right? > > Calling arc4random_stir() inside fork() will slow down fork() and is not > acceptable because of it. Could you add a new interface, arc4random_setstir() or something, to set a flag that indicates a stir should be done at the next opportunity? -- DE From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 18:22:08 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6226106566C; Tue, 16 Sep 2008 18:22:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 5E7A28FC14; Tue, 16 Sep 2008 18:22:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1KffBZ-000CXX-6S; Tue, 16 Sep 2008 21:22:01 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m8GILvxA086986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Sep 2008 21:21:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m8GILvfH078412; Tue, 16 Sep 2008 21:21:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id m8GILvGt078410; Tue, 16 Sep 2008 21:21:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 16 Sep 2008 21:21:57 +0300 From: Kostik Belousov To: Daniel Eischen Message-ID: <20080916182157.GS39652@deviant.kiev.zoral.com.ua> References: <20080916140319.GA34447@nagual.pp.ru> <20080916144502.GA39765@nagual.pp.ru> <3bbf2fe10809160753o7e5e8a78q7c6bd44c02bfd5c2@mail.gmail.com> <20080916150120.GA40087@nagual.pp.ru> <20080916160535.GA40676@nagual.pp.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Fcn+O7u6afXSKWdN" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1KffBZ-000CXX-6S 4682ca4a8df0952baeb8bc01799e0989 X-Terabit: YES Cc: Attilio Rao , Andrey Chernov , current@freebsd.org Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 18:22:09 -0000 --Fcn+O7u6afXSKWdN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 16, 2008 at 12:50:53PM -0400, Daniel Eischen wrote: >=20 > [ Trimmed ] >=20 > On Tue, 16 Sep 2008, Andrey Chernov wrote: >=20 > >On Tue, Sep 16, 2008 at 11:36:03AM -0400, Daniel Eischen wrote: > > > >>Well, you could speed up getpid() by having libc wrap all fork() > >>variants. The idea is that getpid() would only call __sys_getpid() > >>the first time it was called and then only after a fork(). It > >>would return the saved process id for all other cases. > > > >Yes, speeding up getpid() by caching its pid is nice idea. > >But I am completely unaware how to create syscall wrappers inside libc. = :( > >I think about something like that: > > > >__weak_reference(_fork, fork); >=20 > I think you'll have to implement it as __fork() in libc, with > _fork and fork both being weak references to __fork() in libc. The > thread libraries will have to call __fork() instead of __sys_fork() > by implementing "fork" as _fork() and providing a weak reference > from fork to _fork. You can see wait() as an example. >=20 > Probably rfork() and vfork() will need to be handled as well, > though I don't think that the thread libraries care about these. >=20 > >But how it will coexists with the same __weak in thread/thr_fork.c ? > >Are some threading locks required in this code? >=20 > I think you can do it without locks. After a fork() you are > single threaded so you can easily set/clear __cur_thread. > Otherwise, the worst case is that multiple threads will call > _sys_getpid() simultaneously the first time, but as long as > you atomically update __cur_thread, it won't matter - each > thread will have retrieved the same exact process id so it > is okay if they all update __cur_thread. >=20 > pid_t > __getpid(void) > { >=20 > if (__cur_thread !=3D -1) > return (__cur_thread); >=20 > atomic_set_32(&__cur_thread, __sys_getpid()); > return (__cur_thread); > } > __weak_reference(__getpid, getpid); > __weak_reference(__getpid, _getpid); >=20 > Or something like that... Do not forget about rfork(). Not sure about rfork_thread(). --Fcn+O7u6afXSKWdN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkjP+UUACgkQC3+MBN1Mb4iWNwCfcjSyL18xL2QChcJcLtusG7MP ASEAnjQyH/uoKNYxdTCEt8S6KPKHBPfj =gJRs -----END PGP SIGNATURE----- --Fcn+O7u6afXSKWdN-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 18:55:08 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38CC6106564A; Tue, 16 Sep 2008 18:55:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id D49FE8FC1C; Tue, 16 Sep 2008 18:55:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 345BA41C67E; Tue, 16 Sep 2008 20:55:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id ygwbixzGLtzj; Tue, 16 Sep 2008 20:55:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id B199241C679; Tue, 16 Sep 2008 20:55:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 891D044487F; Tue, 16 Sep 2008 18:51:05 +0000 (UTC) Date: Tue, 16 Sep 2008 18:51:04 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: freebsd-net@freebsd.org In-Reply-To: <20080824111925.X66593@maildrop.int.zabbadoz.net> Message-ID: <20080916183952.A65801@maildrop.int.zabbadoz.net> References: <20080824111925.X66593@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD current mailing list Subject: Re: [CFT/R] IPv4 source address selection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-net@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 18:55:08 -0000 On Sun, 24 Aug 2008, Bjoern A. Zeeb wrote: Hi, > I have a patch, that was inspired by work from Y!, to do porper > IPv4 source address selection for unbound sockets (with multi-IP > jails). > > You can temporary find it here: > http://people.freebsd.org/~bz/20080823-01-in_pcbladdr.diff > > People running my latest jail patches have been ``testing'' this > without really knowing the last weeks. > > In case you wonder why, in the jail case, I loop over the ifa first > before simply falling back to the primary jail IP (which is the only > jail IP as in HEAD) -- this is because with the upcoming jail patches > I have to check if any of possibly lots of IPs match any IP on an > interface and only if none matches I have to fall back to the 'primary' > jail IP. > So the code has been prepared for upcoming changes already. > > > Feel free to test it and report problems or unexpected behavior. > Unless someone is going to cry it'll hit HEAD in a few days. Okay, there was close to zero feedback:( I had Kris test it performance wise and he found a performance regression and I talked to Robert about the general code a bit more then decided that I can simplify it. After that I re-ran some performance tests myself and found that passing in pointers improves things and now we are at the following with unbound udp sockets: x cvs-plain2 + bz-laddr +------------------------------------------------------------+ |+ + + + x x x + x| | |______________________A_____M________|_______|_A________|| +------------------------------------------------------------+ N Min Max Median Avg Stddev x 5 498932.16 500399.34 499727.93 499724.08 668.35243 + 5 496178.62 500190.01 498391.13 497996.98 1649.8572 No difference proven at 95.0% confidence x cvs-plain2-jailed + bz-laddr-jailed +------------------------------------------------------------+ |x + * + xx + x +| | ||_________________M_AA______M____________|| | +------------------------------------------------------------+ N Min Max Median Avg Stddev x 5 493049.99 499015.59 497250.89 496364.37 2305.2757 + 5 493335.46 499712.52 496067.19 496411.24 2431.479 No difference proven at 95.0% confidence For jails this already has the loops, though I was still trying with a single (extra) IP only. So the latest patch is here: http://people.freebsd.org/~bz/20080831-01-in_pcbladdr.diff I'd really like some review before this goes in especially as it changes the semantics for jails a bit more. I'll probably time out by Sunday (UTC) or so; in case you want to look at it but need more time, let me know and I'll wait. /bz PS: I'll also post an updated jail patch for HEAD with this change in case people want to try that with multi-IP jails. > PS: in case you review this properly (not only glance at it or test > it) let me know so I can punish you in the Reviewed by: line;-) -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 19:26:02 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3CA3106567E for ; Tue, 16 Sep 2008 19:26:01 +0000 (UTC) (envelope-from peter@wemm.org) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id B8D428FC19 for ; Tue, 16 Sep 2008 19:26:01 +0000 (UTC) (envelope-from peter@wemm.org) Received: by yw-out-2324.google.com with SMTP id 9so867586ywe.13 for ; Tue, 16 Sep 2008 12:26:00 -0700 (PDT) Received: by 10.143.8.17 with SMTP id l17mr505889wfi.106.1221593160156; Tue, 16 Sep 2008 12:26:00 -0700 (PDT) Received: by 10.142.255.21 with HTTP; Tue, 16 Sep 2008 12:26:00 -0700 (PDT) Message-ID: Date: Tue, 16 Sep 2008 12:26:00 -0700 From: "Peter Wemm" To: "John Baldwin" In-Reply-To: <200809151808.33400.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48CE59C2.9060307@icyb.net.ua> <48CEBF42.3060901@icyb.net.ua> <1A6B5018-ABC9-4612-A66A-1A6D21336619@mac.com> <200809151808.33400.jhb@freebsd.org> Cc: Marcel Moolenaar , Andriy Gapon , freebsd-current@freebsd.org Subject: Re: sio => uart: one port is gone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 19:26:02 -0000 On Mon, Sep 15, 2008 at 3:08 PM, John Baldwin wrote: > On Monday 15 September 2008 04:11:14 pm Marcel Moolenaar wrote: >> >> On Sep 15, 2008, at 1:02 PM, Andriy Gapon wrote: >> >> > --- a/sys/conf/files >> > +++ b/sys/conf/files >> > @@ -1080,7 +1080,7 @@ dev/twe/twe.c optional twe >> > dev/twe/twe_freebsd.c optional twe >> > dev/tx/if_tx.c optional tx >> > dev/txp/if_txp.c optional txp >> > -dev/uart/uart_bus_acpi.c optional uart acpi >> > +dev/uart/uart_bus_acpi.c optional uart >> > #dev/uart/uart_bus_cbus.c optional uart cbus >> > dev/uart/uart_bus_ebus.c optional uart ebus >> > dev/uart/uart_bus_isa.c optional uart isa >> >> This is exactly the thing we shouldn't be doing. >> >> You now compile the acpi bus attachment on platforms >> that don't even have acpi. This is not a fix, it's >> a breakage... > > You can change it in sys/conf/files.i386 instead. (It's ok to have duplicate > lines across files*, the file gets compiled in if any one of the conditions > matches). I agree. If uart is representing itself as a sio replacement, then it needs to be a sio replacement. And on i386, that presently means compiling the acpi attachment always. ie: add a second "dev/uart/uart_bus_acpi.c optional uart" to files.i386. On the other hand, we shouldn't be compiling acpi.ko as a module anyway. It really is an integral part of any recent x86 machines. The PC2001 spec requires ACPI. You can't get a 'Designed for Windows XXX' logo unless you're compliant with >= PC2001 these days. Having it as a module just adds memory overhead (admittedly small, but it is there). Having a crash involving acpi means that you suddenly have more moving parts to keep track of for kgdb, and more things to go wrong in getting decent dump info. (Granted, kgdb handles modules much better now, but it is still something to go wrong if the on-disk acpi.ko gets out of sync with the kernel.debug or the vmcore) I prefer what happens on amd64. It is compiled into the kernel, but on the rare occasion where it is a problem there is a hint to shut it down at boot. i386 has the same hint already. And if somebody really wants to build a custom kernel without it, that can be done too. And they get the acpi bus attachments compiled out at the same time. We're at least two full machine upgrade life cycles beyond the point where ACPI was effectively mandatory in PC's. We really should be optimizing for the case where it is there rather than not. As for soekris boxes without acpi - we already have compile-time options that are compelling for building a custom kernel for use on a soekris. Booting GENERIC with embedded acpi is harmless though, except for the non-trivial kernel bloat in GENERIC. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 19:33:50 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EB3C1065671; Tue, 16 Sep 2008 19:33:50 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id B67F28FC14; Tue, 16 Sep 2008 19:33:49 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.3/8.14.3) with ESMTP id m8GJXmKq043949; Tue, 16 Sep 2008 23:33:48 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1221593628; bh=CtqIFOhHs2YX3SGl9pBSgTMyYmmEw3BuKI1oHmO MC7U=; l=537; h=Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:In-Reply-To; b=ibMgfjj220lQmBgx3BGAmXCiX tvBxIO/GxJ4aczLCR09fnj1ilRZy+cpVMrtLAffwKhKx+6LJqBmyDzhJ6pqdVoaDfz7 FTGnjo7koKJmCj3DZqut/gMg/1tZbvtLU+JoVRkyB4YXDtkV+SccuJXdVb/DcDaYnTX YXvGSshx0UaE= Received: (from ache@localhost) by nagual.pp.ru (8.14.3/8.14.3/Submit) id m8GJXmpn043948; Tue, 16 Sep 2008 23:33:48 +0400 (MSD) (envelope-from ache) Date: Tue, 16 Sep 2008 23:33:47 +0400 From: Andrey Chernov To: Daniel Eischen Message-ID: <20080916193347.GA43665@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Daniel Eischen , Max Laier , freebsd-current@freebsd.org References: <20080916140319.GA34447@nagual.pp.ru> <200809161827.07627.max@love2party.net> <20080916164558.GA41258@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Max Laier , freebsd-current@freebsd.org Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 19:33:50 -0000 On Tue, Sep 16, 2008 at 01:21:37PM -0400, Daniel Eischen wrote: > Could you add a new interface, arc4random_setstir() or something, > to set a flag that indicates a stir should be done at the next > opportunity? That was my original idea - to set the flag variable (not a new inteface) in the fork() wrapper which arc4random() will check later. I'll think about, what is better: getpid() speedup looks like more general solution for all similar cases while the flag will be for arc4random() only. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 19:48:27 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBCB8106566C for ; Tue, 16 Sep 2008 19:48:27 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.freebsd.org (Postfix) with ESMTP id 6B8D08FC22 for ; Tue, 16 Sep 2008 19:48:27 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-024-094.pools.arcor-ip.net [88.66.24.94]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis) id 0ML31I-1KfgXB3goV-0000u4; Tue, 16 Sep 2008 21:48:26 +0200 Received: (qmail 63130 invoked from network); 16 Sep 2008 19:48:24 -0000 Received: from fbsd8.laiers.local (192.168.4.151) by laiers.local with SMTP; 16 Sep 2008 19:48:24 -0000 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Tue, 16 Sep 2008 21:48:23 +0200 User-Agent: KMail/1.10.1 (FreeBSD/8.0-CURRENT; KDE/4.1.1; i386; ; ) References: <20080916140319.GA34447@nagual.pp.ru> <200809161827.07627.max@love2party.net> <20080916164558.GA41258@nagual.pp.ru> In-Reply-To: <20080916164558.GA41258@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809162148.24090.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+dLT/of9UN9txon4nf4cYtkZXwJG6aK8Ogd9J 4pkZRGI6Uh4ycJO/Z5BRyy7U3HYVcqwdGchKEfikbsC0jBHrfm 05KJCjuK7bF3u0pfg01Yw== Cc: Daniel Eischen , Andrey Chernov Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 19:48:27 -0000 On Tuesday 16 September 2008 18:45:58 Andrey Chernov wrote: > On Tue, Sep 16, 2008 at 06:27:07PM +0200, Max Laier wrote: > > On Tuesday 16 September 2008 16:03:20 Andrey Chernov wrote: > > > I need some sort of fork() hook to detect that pid is changed to > > > re-stir ar4random() after that (in the child), simple flag variable > > > with child's pid is needed. > > > > > > Currently OpenBSD does almost that checking getpid() every time > > > arc4random() called, but it is very slow way to use getpid() syscall > > > repeatedly, about 12-15 times slower than just arc4random() without > > > getpid(). > > > > > > Any ideas? > > > > I guess the goal here is not to leak the state of the seed to the child, > > right? > > > > Wouldn't it be easier to do something like this in libc's fork(): > > > > arc4random_stir(); /* create a new seed for the child */ > > fork_syscall(); > > if (parent) > > arc4random_stir(); /* create a new seed for the parent */ > > > > This should solve the problem and doesn't require any handling in > > arc4random. Of course, programs that call the fork syscall directly won't > > benefit, but then again ... they are using the syscall directly and > > should know what they are doing, right? > > Calling arc4random_stir() inside fork() will slow down fork() and is not > acceptable because of it. Slow down here. You haven't answered my question. What exactly is the issue this is supposed to fix? Do we want to prevent a child from knowing what the next few arc4random outputs of its parent will be? Or are we only concerned that the next few arc4random of the parent and child should not be the same? If the former, there is no way around destroying the state of the seed prior to fork. If the latter ... On Tuesday 16 September 2008 19:21:37 Daniel Eischen wrote: > Could you add a new interface, arc4random_setstir() or something, > to set a flag that indicates a stir should be done at the next > opportunity? ... this certainly is the right solution. arc4random() should not care about pids and such - IMHO, of course. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 20:08:30 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 069E71065750; Tue, 16 Sep 2008 20:08:30 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 6CB8C8FC23; Tue, 16 Sep 2008 20:08:29 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.3/8.14.3) with ESMTP id m8GK8RHA044659; Wed, 17 Sep 2008 00:08:27 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1221595707; bh=IDgAkqB8B86LmWh65eVIfioJSg9y/C/uETGrdgv DZow=; l=1267; h=Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:In-Reply-To; b=uXW4GwbG2cUPrjubpL+XIV1rZ 5X7zyLgj4FWELbNc6tdPHYrGIJYZHqN+6QntTqDSCFbSSgi13OIO/loHh0Q5SWRvoPo oudQaZJP7u3Upz41thtcdGZgc/YQYMiFmV3AODGvZrYX0JvLfm0meUsydnSiKm1+HI7 nLmwgqo95Mdc= Received: (from ache@localhost) by nagual.pp.ru (8.14.3/8.14.3/Submit) id m8GK8PK7044657; Wed, 17 Sep 2008 00:08:25 +0400 (MSD) (envelope-from ache) Date: Wed, 17 Sep 2008 00:08:23 +0400 From: Andrey Chernov To: Max Laier Message-ID: <20080916200822.GA44273@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Max Laier , freebsd-current@freebsd.org, Daniel Eischen References: <20080916140319.GA34447@nagual.pp.ru> <200809161827.07627.max@love2party.net> <20080916164558.GA41258@nagual.pp.ru> <200809162148.24090.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200809162148.24090.max@love2party.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Daniel Eischen , freebsd-current@freebsd.org Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 20:08:30 -0000 On Tue, Sep 16, 2008 at 09:48:23PM +0200, Max Laier wrote: > Slow down here. You haven't answered my question. What exactly is the issue > this is supposed to fix? Do we want to prevent a child from knowing what the > next few arc4random outputs of its parent will be? Or are we only concerned > that the next few arc4random of the parent and child should not be the same? The child and the parent should have different arc4random() states to produce different returns, say, for mktemp() they both called after fork() (or for any other function inside libs which use arc4random()). To achieve that it is enough to re-stir in the child only. > > Could you add a new interface, arc4random_setstir() or something, > > to set a flag that indicates a stir should be done at the next > > opportunity? > > ... this certainly is the right solution. arc4random() should not care about > pids and such - IMHO, of course. Perhaps clearing rs_stired flag just for arc4random() instead of general getpid() speedup will be the right solution, because we have an edge case: vfork() for which there is no sense to re-stir at all because both the parent and the child will be re-stired at the same time in any case. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 20:10:06 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2DF0106566C; Tue, 16 Sep 2008 20:10:06 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 9BE048FC12; Tue, 16 Sep 2008 20:10:06 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 4462E41C6BB; Tue, 16 Sep 2008 22:10:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id bhiaJ7gwZWyf; Tue, 16 Sep 2008 22:10:04 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id EFD7D41C6B4; Tue, 16 Sep 2008 22:10:04 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id BFBFB44487F; Tue, 16 Sep 2008 20:08:57 +0000 (UTC) Date: Tue, 16 Sep 2008 20:08:57 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: FreeBSD current mailing list Message-ID: <20080916200015.X65801@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-jail@FreeBSD.org, FreeBSD virtualization mailing list Subject: [CFR/T] multi-/no-IP jail patch for HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-jail@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 20:10:07 -0000 Hi, I have put a close to be commit candidate (if ipv4 src addr selection is in upfront) online here: http://people.freebsd.org/~bz/bz_jail-20080915-02-svn.diff This is for HEAD, for review and testing. Changes since last release: - SCTP enabled (again) for IPv4 and on for v6 as well. Might need another pari of eyes or someone to write regression tests. - jls -a/-v implemented/documented - updated ipv4 source address selection (changes semantics, please test/review carefully) - minor cleanup Please report anything you want/that need sto be/... changed/fixed/... Thanks. /bz PS: for anyone crying for RELENG_7. I am trying to put a patch together the next days. -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 20:11:21 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9508E106564A; Tue, 16 Sep 2008 20:11:21 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 589568FC2E; Tue, 16 Sep 2008 20:11:21 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 58F32170E4; Tue, 16 Sep 2008 19:42:19 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m8GJgIQa074568; Tue, 16 Sep 2008 19:42:18 GMT (envelope-from phk@critter.freebsd.dk) To: Andrey Chernov From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 16 Sep 2008 23:33:47 +0400." <20080916193347.GA43665@nagual.pp.ru> Date: Tue, 16 Sep 2008 19:42:18 +0000 Message-ID: <74567.1221594138@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Daniel Eischen , Max Laier , freebsd-current@freebsd.org Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 20:11:21 -0000 In message <20080916193347.GA43665@nagual.pp.ru>, Andrey Chernov writes: >That was my original idea - to set the flag variable (not a new inteface) >in the fork() wrapper which arc4random() will check later. I'll think >about, what is better: getpid() speedup looks like more general solution >for all similar cases while the flag will be for arc4random() only. Not to be devils advocate here, but isn't the process pid about the worst seed you can use for a random generator, considering that it is publically visible ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 20:16:38 2008 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1BD21065677 for ; Tue, 16 Sep 2008 20:16:38 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id B53DB8FC1B for ; Tue, 16 Sep 2008 20:16:38 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id m8GKJWg1060037; Tue, 16 Sep 2008 16:19:32 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id m8GKJWKL060036; Tue, 16 Sep 2008 16:19:32 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Tue, 16 Sep 2008 16:19:32 -0400 From: David Schultz To: Andrey Chernov , current@FreeBSD.ORG Message-ID: <20080916201932.GA59781@zim.MIT.EDU> Mail-Followup-To: Andrey Chernov , current@freebsd.org References: <20080916140319.GA34447@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080916140319.GA34447@nagual.pp.ru> Cc: Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 20:16:39 -0000 On Tue, Sep 16, 2008, Andrey Chernov wrote: > I need some sort of fork() hook to detect that pid is changed to re-stir > ar4random() after that (in the child), simple flag variable with > child's pid is needed. > > Currently OpenBSD does almost that checking getpid() every time > arc4random() called, but it is very slow way to use getpid() syscall > repeatedly, about 12-15 times slower than just arc4random() without > getpid(). Do you have a compelling example of why microoptimizing arc4random() is an urgent matter? Most apps don't need cryptographic-quality randomness thousands of times a second in the critical path, and OpenBSD has been surviving just fine with the calls to getpid(). The patches I sent you essentially upgrade to the OpenBSD source for arc4random() and try to minimize the diffs against them. (A comparison of the resultant sources to OpenBSD's is below.) This fixes several bugs, including: 1. silently using insecure entropy sources for jailed apps where /dev/random is unavailable 2. buffer sloppiness 3. spurious restir checks 4. the fork() problem you describe secteam@ already agreed to the idea of solving the fork problem as in OpenBSD over a month ago. I really do not understand why we need to keep trying to outdo OpenBSD with our own variant of arc4random(). They addressed the fork() issue more than 5 years ago and in general, they seem to be winning in terms of correctness. If getpid() really winds up being a serious problem, we can solve it in a principled way, e.g., by having the kernel fault in a read-only page containing the current process pid, and having libc's getpid() read it. I know Windows has a facility like this that they use for a number of things, and ISTR that Linux recently introduced one, too. The bottom line is that we shouldn't solve the problem with hacks in arc4random(), and we shouldn't try to solve it at all until it's proven to be a real problem. --- /usr/ob/src/lib/libc/crypt/arc4random.c 2008-06-03 20:50:23.000000000 -0400 +++ arc4random.c 2008-08-16 15:14:59.000000000 -0400 @@ -34,21 +34,22 @@ * RC4 is a registered trademark of RSA Laboratories. */ +#include +__FBSDID("$FreeBSD: head/lib/libc/gen/arc4random.c 181261 2008-08-03 20:15:22Z ache $"); + +#include "namespace.h" #include #include #include #include +#include #include #include #include #include -#include "thread_private.h" -#ifdef __GNUC__ -#define inline __inline -#else /* !__GNUC__ */ -#define inline -#endif /* !__GNUC__ */ +#include "libc_private.h" +#include "un-namespace.h" struct arc4_stream { u_int8_t i; @@ -56,6 +57,21 @@ u_int8_t s[256]; }; +static pthread_mutex_t arc4random_mtx = PTHREAD_MUTEX_INITIALIZER; + +#define RANDOMDEV "/dev/urandom" +#define _ARC4_LOCK() \ + do { \ + if (__isthreaded) \ + _pthread_mutex_lock(&arc4random_mtx); \ + } while (0) + +#define _ARC4_UNLOCK() \ + do { \ + if (__isthreaded) \ + _pthread_mutex_unlock(&arc4random_mtx); \ + } while (0) + static int rs_initialized; static struct arc4_stream rs; static pid_t arc4_stir_pid; @@ -114,9 +130,9 @@ /* * Discard early keystream, as per recommendations in: - * http://www.wisdom.weizmann.ac.il/~itsik/RC4/Papers/Rc4_ksa.ps + * "(Not So) Random Shuffles of RC4" by Ilya Mironov. */ - for (i = 0; i < 256; i++) + for (i = 0; i < 1024; i++) (void)arc4_getbyte(); arc4_count = 1600000; } @@ -135,6 +151,7 @@ return (rs.s[(si + sj) & 0xff]); } +#if 0 u_int8_t __arc4_getbyte(void) { @@ -147,6 +164,7 @@ _ARC4_UNLOCK(); return val; } +#endif static inline u_int32_t arc4_getword(void) From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 20:19:37 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 073511065679 for ; Tue, 16 Sep 2008 20:19:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8D0B08FC1A for ; Tue, 16 Sep 2008 20:19:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8GKJUDR097041; Tue, 16 Sep 2008 16:19:30 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Peter Wemm" Date: Tue, 16 Sep 2008 15:53:01 -0400 User-Agent: KMail/1.9.7 References: <48CE59C2.9060307@icyb.net.ua> <200809151808.33400.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809161553.02028.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 16 Sep 2008 16:19:30 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8265/Tue Sep 16 15:26:49 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Marcel Moolenaar , Andriy Gapon , freebsd-current@freebsd.org Subject: Re: sio => uart: one port is gone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 20:19:37 -0000 On Tuesday 16 September 2008 03:26:00 pm Peter Wemm wrote: > On Mon, Sep 15, 2008 at 3:08 PM, John Baldwin wrote: > > On Monday 15 September 2008 04:11:14 pm Marcel Moolenaar wrote: > >> > >> On Sep 15, 2008, at 1:02 PM, Andriy Gapon wrote: > >> > >> > --- a/sys/conf/files > >> > +++ b/sys/conf/files > >> > @@ -1080,7 +1080,7 @@ dev/twe/twe.c optional twe > >> > dev/twe/twe_freebsd.c optional twe > >> > dev/tx/if_tx.c optional tx > >> > dev/txp/if_txp.c optional txp > >> > -dev/uart/uart_bus_acpi.c optional uart acpi > >> > +dev/uart/uart_bus_acpi.c optional uart > >> > #dev/uart/uart_bus_cbus.c optional uart cbus > >> > dev/uart/uart_bus_ebus.c optional uart ebus > >> > dev/uart/uart_bus_isa.c optional uart isa > >> > >> This is exactly the thing we shouldn't be doing. > >> > >> You now compile the acpi bus attachment on platforms > >> that don't even have acpi. This is not a fix, it's > >> a breakage... > > > > You can change it in sys/conf/files.i386 instead. (It's ok to have duplicate > > lines across files*, the file gets compiled in if any one of the conditions > > matches). > > I agree. If uart is representing itself as a sio replacement, then it > needs to be a sio replacement. And on i386, that presently means > compiling the acpi attachment always. ie: add a second > "dev/uart/uart_bus_acpi.c optional uart" to files.i386. > > On the other hand, we shouldn't be compiling acpi.ko as a module > anyway. It really is an integral part of any recent x86 machines. > The PC2001 spec requires ACPI. You can't get a 'Designed for Windows > XXX' logo unless you're compliant with >= PC2001 these days. Having > it as a module just adds memory overhead (admittedly small, but it is > there). Having a crash involving acpi means that you suddenly have > more moving parts to keep track of for kgdb, and more things to go > wrong in getting decent dump info. (Granted, kgdb handles modules > much better now, but it is still something to go wrong if the on-disk > acpi.ko gets out of sync with the kernel.debug or the vmcore) > > I prefer what happens on amd64. It is compiled into the kernel, but > on the rare occasion where it is a problem there is a hint to shut it > down at boot. i386 has the same hint already. And if somebody really > wants to build a custom kernel without it, that can be done too. And > they get the acpi bus attachments compiled out at the same time. > > We're at least two full machine upgrade life cycles beyond the point > where ACPI was effectively mandatory in PC's. We really should be > optimizing for the case where it is there rather than not. > > As for soekris boxes without acpi - we already have compile-time > options that are compelling for building a custom kernel for use on a > soekris. Booting GENERIC with embedded acpi is harmless though, > except for the non-trivial kernel bloat in GENERIC. I agree with just adding acpi to GENERIC on i386 and have that be the real solution. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 20:33:21 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A4A6106564A; Tue, 16 Sep 2008 20:33:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id CE17E8FC17; Tue, 16 Sep 2008 20:33:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8GKXE4u097161; Tue, 16 Sep 2008 16:33:14 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 16 Sep 2008 16:28:53 -0400 User-Agent: KMail/1.9.7 References: <74567.1221594138@critter.freebsd.dk> In-Reply-To: <74567.1221594138@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809161628.54085.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 16 Sep 2008 16:33:14 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8265/Tue Sep 16 15:26:49 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Daniel Eischen , Andrey Chernov , Poul-Henning Kamp , Max Laier Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 20:33:21 -0000 On Tuesday 16 September 2008 03:42:18 pm Poul-Henning Kamp wrote: > In message <20080916193347.GA43665@nagual.pp.ru>, Andrey Chernov writes: > > >That was my original idea - to set the flag variable (not a new inteface) > >in the fork() wrapper which arc4random() will check later. I'll think > >about, what is better: getpid() speedup looks like more general solution > >for all similar cases while the flag will be for arc4random() only. > > Not to be devils advocate here, but isn't the process pid about the > worst seed you can use for a random generator, considering that it > is publically visible ? The PID isn't the seed, he's using a PID change as a notification that the process needs to do a re-stir the next time it wants a psuedo-random number (b/c the PID change means it is now a new process). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 20:41:35 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 609F31065678; Tue, 16 Sep 2008 20:41:35 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 219058FC12; Tue, 16 Sep 2008 20:41:34 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id CA707170E4; Tue, 16 Sep 2008 20:41:33 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m8GKfXhB075594; Tue, 16 Sep 2008 20:41:33 GMT (envelope-from phk@critter.freebsd.dk) To: John Baldwin From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 16 Sep 2008 16:28:53 -0400." <200809161628.54085.jhb@freebsd.org> Date: Tue, 16 Sep 2008 20:41:33 +0000 Message-ID: <75593.1221597693@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Daniel Eischen , Andrey Chernov , freebsd-current@freebsd.org, Max Laier Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 20:41:35 -0000 In message <200809161628.54085.jhb@freebsd.org>, John Baldwin writes: >The PID isn't the seed, he's using a PID change as a notification that the >process needs to do a re-stir the next time it wants a psuedo-random number >(b/c the PID change means it is now a new process). Seems to be a vast overkill to me, in countless other contexts, it is the responsibility of the programmer to do what needs done on a fork, and I see no reason why this couldn't be likewise. The majority of forks don't care a hoot about arc4random() because the call exec after a bit of plumbing on filedescriptors. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 21:07:34 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2B94106566B for ; Tue, 16 Sep 2008 21:07:34 +0000 (UTC) (envelope-from reddvinylene@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.freebsd.org (Postfix) with ESMTP id 4866C8FC12 for ; Tue, 16 Sep 2008 21:07:34 +0000 (UTC) (envelope-from reddvinylene@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so203806uge.39 for ; Tue, 16 Sep 2008 14:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=aIjjePRyDZYu/9M5iV0G9VScdtRRY+u8qTJzR7aspc8=; b=P1qDiQjf1vAnWgV8i8XMWL0RcV5i6nx/17PlcbEnjmq+HQO/mhfjKF/zri5yQvkFvE MAkt4wNWJAYdPjx/V42tenvxzFzzh3wFoUhUhQS4IKRHFAk2gAvhE7A/tIX6s8wg7xn9 V9agRbVmdhEhrk/ClHav794+kPpkANKCIUdhc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=g12cbw0UkCmiEvOmAGr6q89kVszm8rGlrjmXkvgPVfdnsh12K4yjc5UbmkInw+kcSG Up42rFgPcZ4xOZPE3p2a4CBB1C60CEGgDzO/tnFY/9Pj97i9p1cdi6F8lH5izJb4X4GT PzdKp7p+AzomJF4N8RDiyUONB4+HUOIIvih/0= Received: by 10.187.161.10 with SMTP id n10mr102797fao.43.1221597840034; Tue, 16 Sep 2008 13:44:00 -0700 (PDT) Received: by 10.187.180.9 with HTTP; Tue, 16 Sep 2008 13:43:59 -0700 (PDT) Message-ID: Date: Tue, 16 Sep 2008 22:43:59 +0200 From: "Redd Vinylene" To: freebsd-jail@freebsd.org In-Reply-To: <20080916200015.X65801@maildrop.int.zabbadoz.net> MIME-Version: 1.0 References: <20080916200015.X65801@maildrop.int.zabbadoz.net> X-Mailman-Approved-At: Tue, 16 Sep 2008 21:22:11 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD current mailing list , FreeBSD virtualization mailing list Subject: Re: [CFR/T] multi-/no-IP jail patch for HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 21:07:34 -0000 On Tue, Sep 16, 2008 at 10:08 PM, Bjoern A. Zeeb < bzeeb-lists@lists.zabbadoz.net> wrote: > Hi, > > I have put a close to be commit candidate (if ipv4 src addr selection > is in upfront) online here: > > http://people.freebsd.org/~bz/bz_jail-20080915-02-svn.diff > > This is for HEAD, for review and testing. > > Changes since last release: > - SCTP enabled (again) for IPv4 and on for v6 as well. Might need > another pari of eyes or someone to write regression tests. > - jls -a/-v implemented/documented > - updated ipv4 source address selection (changes semantics, please > test/review carefully) > - minor cleanup > > Please report anything you want/that need sto be/... changed/fixed/... > > Thanks. > /bz > > > PS: for anyone crying for RELENG_7. I am trying to put a patch > together the next days. > > -- > Bjoern A. Zeeb Stop bit received. Insert coin for new game. > > Excellent work! Keep it up bro! -- http://www.home.no/reddvinylene From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 01:12:21 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81D53106566B for ; Wed, 17 Sep 2008 01:12:21 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outH.internet-mail-service.net (outh.internet-mail-service.net [216.240.47.231]) by mx1.freebsd.org (Postfix) with ESMTP id 647708FC16 for ; Wed, 17 Sep 2008 01:12:20 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 80152242D; Tue, 16 Sep 2008 18:12:21 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 3A7B62D6013; Tue, 16 Sep 2008 18:12:20 -0700 (PDT) Message-ID: <48D05972.3060509@elischer.org> Date: Tue, 16 Sep 2008 18:12:18 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20080824111925.X66593@maildrop.int.zabbadoz.net> <20080916183952.A65801@maildrop.int.zabbadoz.net> In-Reply-To: <20080916183952.A65801@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD current mailing list Subject: Re: [CFT/R] IPv4 source address selection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 01:12:21 -0000 Bjoern A. Zeeb wrote: > On Sun, 24 Aug 2008, Bjoern A. Zeeb wrote: > > Hi, > >> I have a patch, that was inspired by work from Y!, to do porper >> IPv4 source address selection for unbound sockets (with multi-IP >> jails). >> >> You can temporary find it here: >> http://people.freebsd.org/~bz/20080823-01-in_pcbladdr.diff >> >> People running my latest jail patches have been ``testing'' this >> without really knowing the last weeks. >> >> In case you wonder why, in the jail case, I loop over the ifa first >> before simply falling back to the primary jail IP (which is the only >> jail IP as in HEAD) -- this is because with the upcoming jail patches >> I have to check if any of possibly lots of IPs match any IP on an >> interface and only if none matches I have to fall back to the 'primary' >> jail IP. >> So the code has been prepared for upcoming changes already. >> >> >> Feel free to test it and report problems or unexpected behavior. >> Unless someone is going to cry it'll hit HEAD in a few days. > > Okay, there was close to zero feedback:( sorry I'm flat out, but very interested.. > > I had Kris test it performance wise and he found a performance regression > and I talked to Robert about the general code a bit more then decided > that I can simplify it. After that I re-ran some performance tests > myself and found that passing in pointers improves things and now we are > at the following with unbound udp sockets: > > x cvs-plain2 > + bz-laddr > +------------------------------------------------------------+ > |+ + + + x x x + x| > | |______________________A_____M________|_______|_A________|| > +------------------------------------------------------------+ > N Min Max Median Avg > Stddev > x 5 498932.16 500399.34 499727.93 499724.08 668.35243 > + 5 496178.62 500190.01 498391.13 497996.98 1649.8572 > No difference proven at 95.0% confidence > > x cvs-plain2-jailed > + bz-laddr-jailed > +------------------------------------------------------------+ > |x + * + xx + x +| > | ||_________________M_AA______M____________|| | > +------------------------------------------------------------+ > N Min Max Median Avg > Stddev > x 5 493049.99 499015.59 497250.89 496364.37 2305.2757 > + 5 493335.46 499712.52 496067.19 496411.24 2431.479 > No difference proven at 95.0% confidence > > > For jails this already has the loops, though I was still trying > with a single (extra) IP only. > > So the latest patch is here: > http://people.freebsd.org/~bz/20080831-01-in_pcbladdr.diff > > I'd really like some review before this goes in especially as it > changes the semantics for jails a bit more. I'll probably time out > by Sunday (UTC) or so; in case you want to look at it but need more > time, let me know and I'll wait. > > /bz > > > PS: I'll also post an updated jail patch for HEAD with this change in case > people want to try that with multi-IP jails. > > >> PS: in case you review this properly (not only glance at it or test >> it) let me know so I can punish you in the Reviewed by: line;-) > From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 07:55:16 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D5BC106567B; Wed, 17 Sep 2008 07:55:16 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id ACA938FC12; Wed, 17 Sep 2008 07:55:15 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.3/8.14.3) with ESMTP id m8H7tEqi057327; Wed, 17 Sep 2008 11:55:14 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1221638114; bh=8f4V1WBWnUwconhSesoCFZvUrVwNmKc9RkTKCVn g0LU=; l=907; h=Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:In-Reply-To; b=Xkjebm01pabhculJNRzmcdV6g T0ItxdH3uxmYYL47qhma7wfbwOBM7LoXZliRC/VTLwKS776q20YG47Ok8y4GOiOKeYg cbqV1YPx4TR7Rrk+sB+BTosqKZI5Qa0VWEEDeqCqviyOqb+Iuumja4AmoJICkEqnffU uzEfFtGXJHvk= Received: (from ache@localhost) by nagual.pp.ru (8.14.3/8.14.3/Submit) id m8H7tDfq057326; Wed, 17 Sep 2008 11:55:13 +0400 (MSD) (envelope-from ache) Date: Wed, 17 Sep 2008 11:55:13 +0400 From: Andrey Chernov To: Poul-Henning Kamp Message-ID: <20080917075513.GB55535@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Poul-Henning Kamp , John Baldwin , freebsd-current@freebsd.org, Daniel Eischen , Max Laier References: <200809161628.54085.jhb@freebsd.org> <75593.1221597693@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75593.1221597693@critter.freebsd.dk> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Daniel Eischen , Max Laier , freebsd-current@freebsd.org Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 07:55:16 -0000 On Tue, Sep 16, 2008 at 08:41:33PM +0000, Poul-Henning Kamp wrote: > In message <200809161628.54085.jhb@freebsd.org>, John Baldwin writes: > > >The PID isn't the seed, he's using a PID change as a notification that the > >process needs to do a re-stir the next time it wants a psuedo-random number > >(b/c the PID change means it is now a new process). > > Seems to be a vast overkill to me, in countless other contexts, > it is the responsibility of the programmer to do what needs done on > a fork, and I see no reason why this couldn't be likewise. The situation is not so simple since the library functions can call ar4random() internally (like mktemp() family already and always does) and the programmer should always know all of such usage (which is impossible) or always call arc4random_stir() directly by himself (which no portable code will do). -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 08:05:00 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8841106567D; Wed, 17 Sep 2008 08:05:00 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 6DEB68FC1D; Wed, 17 Sep 2008 08:05:00 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id D4314170E4; Wed, 17 Sep 2008 08:04:58 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m8H84vUh089507; Wed, 17 Sep 2008 08:04:57 GMT (envelope-from phk@critter.freebsd.dk) To: Andrey Chernov From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 17 Sep 2008 11:55:13 +0400." <20080917075513.GB55535@nagual.pp.ru> Date: Wed, 17 Sep 2008 08:04:57 +0000 Message-ID: <89506.1221638697@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Daniel Eischen , Max Laier , freebsd-current@freebsd.org Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 08:05:00 -0000 In message <20080917075513.GB55535@nagual.pp.ru>, Andrey Chernov writes: >On Tue, Sep 16, 2008 at 08:41:33PM +0000, Poul-Henning Kamp wrote: >> In message <200809161628.54085.jhb@freebsd.org>, John Baldwin writes: >> >> >The PID isn't the seed, he's using a PID change as a notification that the >> >process needs to do a re-stir the next time it wants a psuedo-random number >> >(b/c the PID change means it is now a new process). >> >> Seems to be a vast overkill to me, in countless other contexts, >> it is the responsibility of the programmer to do what needs done on >> a fork, and I see no reason why this couldn't be likewise. > >The situation is not so simple since the library functions can call >ar4random() internally (like mktemp() family already and always does) I have a really hard time seeing how this could become a performance issue, ever. The solution however, is simple: Just have these hidden library calls to arc4random call a wrapper function that does the pid check. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 08:34:17 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 822CC106566C for ; Wed, 17 Sep 2008 08:34:17 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from munchkin.clue.co.za (munchkin.clue.co.za [66.219.59.160]) by mx1.freebsd.org (Postfix) with ESMTP id 4E9188FC1E for ; Wed, 17 Sep 2008 08:34:17 +0000 (UTC) (envelope-from ianf@clue.co.za) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=20070313; d=clue.co.za; h=Received:Received:Received:To:Subject:From:X-Attribution:Date:Message-Id; b=TEgMW5l3tGpoK/DYZdWnDFDiuG5mDnbvsTDUiRDoJb5M2sJsNYGZSNjxmXH11+kp0THmj4PAGOfTyPu04AHtzPp4aA80gXbOngRuU2Kj0DFsHe4TqQB1pr6QmgbJQMyaPwxbj3qLsbFSHRhlkaHZk3W8G7drJ89jD3w3Bsj+OEY8/Uj4fUwuOeJBvN7LmrsysJzMHDbFe/W9wk+HxyoujDSD0AA/QJg8OmugRM7fF7OvQbVEA0YNKE9wNGG5E0qb; Received: from uucp by munchkin.clue.co.za with local-rmail (Exim 4.67) (envelope-from ) id 1KfsDk-00051O-9H for current@freebsd.org; Wed, 17 Sep 2008 08:17:08 +0000 Received: from dsl-241-65-41.telkomadsl.co.za ([41.241.65.41] helo=clue.co.za) by urchin.clue.co.za with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1KfsD8-0000jm-NW for current@freebsd.org; Wed, 17 Sep 2008 08:16:30 +0000 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KfsD7-0001EE-LC for current@freebsd.org; Wed, 17 Sep 2008 10:16:29 +0200 To: current@freebsd.org From: "Ian Freislich" X-Attribution: BOFH Date: Wed, 17 Sep 2008 10:16:29 +0200 Message-Id: Cc: Subject: msk(4) issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 08:34:17 -0000 Hi I'm having an issue with the msk hardware in my laptop. It stops transmitting or recieving sometimes, always triggered by periods of intense network load. Sep 16 18:39:31 apple kernel: msk0: watchdog timeout (missed Tx interrupts) -- recovering Sep 16 18:40:35 apple kernel: msk0: watchdog timeout (missed Tx interrupts) -- recovering Sep 16 18:41:41 apple kernel: msk0: watchdog timeout (missed Tx interrupts) -- recovering But it never recovers. mskc0@pci0:2:0:0: class=0x020000 card=0x532111ab chip=0x436211ab rev=0x22 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = '88E8053 Marvell Yukon 88E8053 PCI-E Gigabit Ethernet Controller' class = network subclass = ethernet Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 08:34:18 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 273D31065670 for ; Wed, 17 Sep 2008 08:34:18 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from munchkin.clue.co.za (munchkin.clue.co.za [66.219.59.160]) by mx1.freebsd.org (Postfix) with ESMTP id E6E7D8FC33 for ; Wed, 17 Sep 2008 08:34:17 +0000 (UTC) (envelope-from ianf@clue.co.za) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=20070313; d=clue.co.za; h=Received:Received:Received:To:Subject:From:X-Attribution:Date:Message-Id; b=ImEjhHiZ5GOX1/K7rVWqdiBkLcdrR9xaPStGcx0Wtoe4WXTOR3ALPaxcZcPsEZ9Hfwmhdbm8tjA/7d5RLKdXi/1VGymmE+STfcKJ1rGE0Z2T6EewIrCvOzS1+JxM384DvHL6N7Sh6mhrWBr2W4I00rS41mGhyljtJNEPnNIHQ14lOOH1WBqfTmRPUVj9+AxJjk6G8ltlUdBsaj5rulsKo5FuNqOuTJR/CgvhIyh8RQTsjVxyBkuIVpD19bB3/Ysn; Received: from uucp by munchkin.clue.co.za with local-rmail (Exim 4.67) (envelope-from ) id 1Kfs46-000478-Ie for current@freebsd.org; Wed, 17 Sep 2008 08:07:10 +0000 Received: from dsl-241-65-41.telkomadsl.co.za ([41.241.65.41] helo=clue.co.za) by urchin.clue.co.za with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Kfs3p-0000f3-Us for current@freebsd.org; Wed, 17 Sep 2008 08:06:54 +0000 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kfs3n-0001CB-EC for current@freebsd.org; Wed, 17 Sep 2008 10:06:51 +0200 To: current@freebsd.org From: "Ian Freislich" X-Attribution: BOFH Date: Wed, 17 Sep 2008 10:06:51 +0200 Message-Id: Cc: Subject: PATCH: crypto/openssl/crypto/engine/eng_table.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 08:34:18 -0000 Hi I had to apply the following patch to fix the engine cache in openssl so that it will actually use the padlock driver for accelleration. It appears that the original logic was reversed. RCS file: /home/ncvs/src/crypto/openssl/crypto/engine/eng_table.c,v retrieving revision 1.1.1.2 diff -u -d -r1.1.1.2 eng_table.c --- eng_table.c 29 Jul 2006 19:10:18 -0000 1.1.1.2 +++ eng_table.c 12 Jun 2008 07:52:52 -0000 @@ -135,7 +135,7 @@ { fnd = OPENSSL_malloc(sizeof(ENGINE_PILE)); if(!fnd) goto end; - fnd->uptodate = 0; + fnd->uptodate = 1; fnd->nid = *nids; fnd->sk = sk_ENGINE_new_null(); if(!fnd->sk) @@ -152,7 +152,7 @@ if(!sk_ENGINE_push(fnd->sk, e)) goto end; /* "touch" this ENGINE_PILE */ - fnd->uptodate = 1; + fnd->uptodate = 0; if(setdefault) { if(!engine_unlocked_init(e)) @@ -180,7 +180,7 @@ { sk_ENGINE_delete(pile->sk, n); /* "touch" this ENGINE_CIPHER */ - pile->uptodate = 1; + pile->uptodate = 0; } if(pile->funct == e) { -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 08:50:34 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3C021065670 for ; Wed, 17 Sep 2008 08:50:34 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 326E18FC0C for ; Wed, 17 Sep 2008 08:50:33 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.3/8.14.3) with ESMTP id m8H8oUdP058486 for ; Wed, 17 Sep 2008 12:50:30 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1221641431; bh=g1ojOPtLGPbvxYBJ97IjLyE5DyF8BGXb3ZXc5Ir QQQA=; l=2466; h=Date:From:To:Subject:Message-ID:References: MIME-Version:Content-Type:In-Reply-To; b=Ax5humpcyrFXefdp2/HdkmiQJ 9OzxN6pw0VYyZaceAL3VYPdh4uBWUOfyk3jFeQoZmOm90v7213nBNK1mAxsciRFhyz3 mzDBwFE6vv6OpEAKZWPwrL9KCRL5VJmNw9TsD694oVFR5anEBZsQkhMorku/Zj+22Im kkOi3yjK9sD8= Received: (from ache@localhost) by nagual.pp.ru (8.14.3/8.14.3/Submit) id m8H8oROe058483 for current@freebsd.org; Wed, 17 Sep 2008 12:50:27 +0400 (MSD) (envelope-from ache) Date: Wed, 17 Sep 2008 12:50:25 +0400 From: Andrey Chernov To: current@freebsd.org Message-ID: <20080917085024.GA57480@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , current@freebsd.org References: <20080916140319.GA34447@nagual.pp.ru> <20080916201932.GA59781@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080916201932.GA59781@zim.MIT.EDU> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 08:50:34 -0000 On Tue, Sep 16, 2008 at 04:19:32PM -0400, David Schultz wrote: > Do you have a compelling example of why microoptimizing > arc4random() is an urgent matter? Most apps don't need > cryptographic-quality randomness thousands of times a second in > the critical path, and OpenBSD has been surviving just fine with > the calls to getpid(). arc4random() is just general PRNG. To confirm that OpenBSD itself treat arc4random() as general PRNG and use it _everywhere_ in their code instead of random() they phased out from every code piece. Contrary NetBSD don't have getpid() check at all like us now. Sooner or later some apps will want to use arc4random() intensively and having slowness here is not fundamental algo thing and can be avoided. > The patches I sent you essentially upgrade to the OpenBSD source > for arc4random() and try to minimize the diffs against them. (A > comparison of the resultant sources to OpenBSD's is below.) This > fixes several bugs, including: > > 1. silently using insecure entropy sources for jailed apps where > /dev/random is unavailable > 2. buffer sloppiness > 3. spurious restir checks > 4. the fork() problem you describe I agree with your patch (BTW you can remove unneded #define RANDOMDEV). I have exact the same plans to get rid of rs_stired and use rs_initialized only and use KERN_ARND as OpenBSD does, but can't consider or plan such big (but simple) changes in the paranoid atmosphere we already have around that unfortunate piece of code (and with review delays ~2months and increased) even with minimal step-by-step changes from our code towards OpenBSD one. Could you commit it, please? Hoping your commits will pass more easily than mine... > secteam@ already agreed to the idea of solving the fork problem as > in OpenBSD over a month ago. I really do not understand why we I don't hear about it. > need to keep trying to outdo OpenBSD with our own variant of > arc4random(). They addressed the fork() issue more than 5 years > ago and in general, they seem to be winning in terms of > correctness. > > If getpid() really winds up being a serious problem, we can solve > it in a principled way, e.g., by having the kernel fault in a > read-only page containing the current process pid, and having Speeding up getpid() by caching its value (as already discussed in this thread) looks like more general solution. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 09:01:04 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C30D1065677; Wed, 17 Sep 2008 09:01:04 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id B094D8FC24; Wed, 17 Sep 2008 09:01:03 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.3/8.14.3) with ESMTP id m8H912YQ058835; Wed, 17 Sep 2008 13:01:02 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1221642062; bh=CIQR8LAP+/b6qM+w9RM8RpohPY7A3JFAckDaFy6 lmu8=; l=879; h=Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:In-Reply-To; b=cG8xkUmwb9wlo80yafHV6SKHS vwOoh7iwFer/ufMN/7pkC8aqfJH+y4EuugAi7zkntvYbs6YygvLZh7M+2rqr5g/TTpZ FRecqfVNhCSLp9Z88NgB8Xz3aklquO+yzPIqwavOi/IeqjiJWvdp47z1k5U1PbxuRw+ /Z70eZ8AWN28= Received: (from ache@localhost) by nagual.pp.ru (8.14.3/8.14.3/Submit) id m8H912mY058834; Wed, 17 Sep 2008 13:01:02 +0400 (MSD) (envelope-from ache) Date: Wed, 17 Sep 2008 13:01:01 +0400 From: Andrey Chernov To: Poul-Henning Kamp Message-ID: <20080917090101.GC57480@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Poul-Henning Kamp , Daniel Eischen , Max Laier , freebsd-current@freebsd.org References: <20080917075513.GB55535@nagual.pp.ru> <89506.1221638697@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <89506.1221638697@critter.freebsd.dk> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Daniel Eischen , Max Laier , freebsd-current@freebsd.org Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 09:01:05 -0000 On Wed, Sep 17, 2008 at 08:04:57AM +0000, Poul-Henning Kamp wrote: > >The situation is not so simple since the library functions can call > >ar4random() internally (like mktemp() family already and always does) > > I have a really hard time seeing how this could become a performance > issue, ever. The performance issue happens when application tries to call arc4random() in the loop. > The solution however, is simple: Just have these hidden library calls > to arc4random call a wrapper function that does the pid check. We can control our own arc4random() internal calls inside our own libs in such way but can't control 3rd party libs or programs arc4random() calls (consider ports). There is no special mentions of pid check needed in arc4random() general API, so 3rd party code will tends to not come to that matter. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 09:07:45 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28E861065671; Wed, 17 Sep 2008 09:07:45 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 8F3498FC15; Wed, 17 Sep 2008 09:07:39 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.3/8.14.3) with ESMTP id m8H97cMn059024; Wed, 17 Sep 2008 13:07:38 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1221642458; bh=DBEURtM5MO2boh6ODU7YJJb5h0hv83qCcOdtPWB tqto=; l=679; h=Date:From:To:Subject:Message-ID:References: MIME-Version:Content-Type:In-Reply-To; b=Nat2B+pAzWetiaJtMs0jNkE6o k9NDcWpr6B5qfeuvPcREZziZCejePtgVxVzHKFRNljWT283W8jo1NwhwYUxvAx8rGKs +dy2hXaEC6l649cBhlpwW2ZXGcfwmSLiNWjyQ7olFAQosqs2Q4EVrZ21c8+bx//eICx 2LxvrtPSLLmM= Received: (from ache@localhost) by nagual.pp.ru (8.14.3/8.14.3/Submit) id m8H97b7u059023; Wed, 17 Sep 2008 13:07:37 +0400 (MSD) (envelope-from ache) Date: Wed, 17 Sep 2008 13:07:37 +0400 From: Andrey Chernov To: Poul-Henning Kamp , Daniel Eischen , Max Laier , freebsd-current@freebsd.org Message-ID: <20080917090737.GD57480@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Poul-Henning Kamp , Daniel Eischen , Max Laier , freebsd-current@freebsd.org References: <20080917075513.GB55535@nagual.pp.ru> <89506.1221638697@critter.freebsd.dk> <20080917090101.GC57480@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080917090101.GC57480@nagual.pp.ru> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 09:07:45 -0000 On Wed, Sep 17, 2008 at 01:01:01PM +0400, Andrey Chernov wrote: > > The solution however, is simple: Just have these hidden library calls > > to arc4random call a wrapper function that does the pid check. > > We can control our own arc4random() internal calls inside our own libs in > such way but can't control 3rd party libs or programs arc4random() calls > (consider ports). There is no special mentions of pid check needed in > arc4random() general API, so 3rd party code will tends to not come to that > matter. Moreover, in the light of OpenBSD move checking pid, 3rd party code oriented on OpenBSD will not do so definitely. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 09:10:57 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C6021065671 for ; Wed, 17 Sep 2008 09:10:57 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id ACFF78FC17 for ; Wed, 17 Sep 2008 09:10:56 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (unknown [93.197.243.44]) by redbull.bpaserver.net (Postfix) with ESMTP id 97E8B2E1FB; Wed, 17 Sep 2008 11:10:48 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 17092158DA5; Wed, 17 Sep 2008 11:10:36 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.14.2/8.13.8/Submit) id m8H9AZ0g079083; Wed, 17 Sep 2008 11:10:35 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Wed, 17 Sep 2008 11:10:35 +0200 Message-ID: <20080917111035.12175aklikhtltcs@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Wed, 17 Sep 2008 11:10:35 +0200 From: "Alexander Leidinger" To: "Stefan Lambrev" References: <48CFB56D.3070908@moneybookers.com> In-Reply-To: <48CFB56D.3070908@moneybookers.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.2) / FreeBSD-8.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 97E8B2E1FB.214B2 X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, ORDB-RBL, SpamAssassin (not cached, score=-14.2, required 6, BAYES_00 -15.00, MR_NOT_ATTRIBUTED_IP 0.20, NO_RDNS 0.50, RDNS_NONE 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: PERC6/i/e cli X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 09:10:57 -0000 Quoting "Stefan Lambrev" (from Tue, 16 Sep 2008 16:32:29 +0300): > Virtual Drive Information: > VD DRV RLP RLS RLQ STS SIZE STATE NAME > 0 2 1 0 0 64kB 139392MB Optimal Ah and btw I > think it was mandatory to have compat.linux.osrelease=2.6.12 > (2.6.16 works too but you have to fix the script to not complain - i > think the port is still not fixed?) Not related to $Subject, but related to the linuxulator: Only use the default osrelease value or 2.6.16. Anything else may open pandoras box. Bye, Alexander. -- I got the bill for my surgery. Now I know what those doctors were wearing masks for. -- James Boren http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 09:17:42 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32B211065670; Wed, 17 Sep 2008 09:17:42 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 9C0958FC08; Wed, 17 Sep 2008 09:17:41 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [195.93.241.11] (port=12520 helo=lissyara.moskb.local) by hosting.lissyara.su with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KftAK-0001Nh-BN; Wed, 17 Sep 2008 13:17:40 +0400 Message-ID: <48D0CB33.9060303@lissyara.su> Date: Wed, 17 Sep 2008 13:17:39 +0400 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.16) Gecko/20080903 Thunderbird/2.0.0.16 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Alexander Motin References: <48CBF399.9080801@FreeBSD.org> In-Reply-To: <48CBF399.9080801@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: freebsd-multimedia@FreeBSD.org, freebsd-current@freebsd.org Subject: Re: New snd_hda driver came in. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 09:17:42 -0000 Alexander Motin : > Hi. > > I have just committed my massive snd_hda driver update to the 8-CURRENT. > > Because of using more clear and same time more functional codec parser > new driver is able to handle more codecs, use them better then before > and without most of previous quirks. All of tested codecs itself > manage playback, record, input mixing and monitoring quite fine. In > all of investigated trouble cases problem was found or in nonstandard > codec usage or in incorrect codec configuration made by BIOS. Most of > that cases could be fixed using device hints, some of which are > already included to the driver. > > New driver supports multiple codecs per HDA bus, multiple audio > function groups per codec and multiple logical sound devices per audio > function group. So don't worry when you get several PCM devices > instead of one, it is normal. It is usual situation with powerful > codecs to provide, for example, 3 PCM devices: one for 7.1 playback > and main recording, one for headset and one for digital SPDIF I/O. > > New driver implements Universal Audio Architecture (UAA) much better > then previous one. Most information about recommended codec usage now > taken from the codec configuration registers initialized by BIOS. User > may alter that configuration using device hints to reconfigure logical > audio devices to his needs in a very broad range up to the limits of > the codec functionality. > > New driver supports digital PCM playback and AC3 pass-through. I am > not sure about completeness of this implementation, but I have several > success stories including my own. Vchans subsystem does not support > AC3 pass-through so it had to be disabled for that devices at this > moment. > > New driver is ready for multichannel playback, but until our OSS is > unable to use this it will just duplicate same stereo stream into all > channel pairs. > > New driver supports suspend/resume. I am unable to really test this > part myself, but I have got several success stories. > > Driver has very informative verbose boot messages. So if you have any > questions or problems - enable and read them first. > > Driver was actively discussed and tested on freebsd-multimedia@ mail > list. > after today update source, not work internal speaker... phones - works... lissyara$ dmesg | grep hda hdac0: mem 0xd8900000-0xd8903fff irq 16 at device 20.2 on pci0 hdac0: hdac0: [ITHREAD] hdac0: pcm0: on hdac0 lissyara$ uname -a FreeBSD lissyara.moskb.local 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Wed Sep 17 10:41:27 MSD 2008 lissyara@lissyara.moskb.local:/tmp/obj/usr/src/sys/GENERIC amd64 lissyara$ before update work and phones and speaker (but, when plug phones speaker not dead =() how say driver use internal speaker? From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 09:17:49 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B65A1065675; Wed, 17 Sep 2008 09:17:49 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id E1D7F8FC0A; Wed, 17 Sep 2008 09:17:48 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id C171A1B10EDC; Wed, 17 Sep 2008 11:17:46 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on malcho.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-10.6 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.4 Received: from hater.haters.org (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 23E7F1B10EF7; Wed, 17 Sep 2008 11:17:41 +0200 (CEST) Message-ID: <48D0CB34.4020207@moneybookers.com> Date: Wed, 17 Sep 2008 12:17:40 +0300 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.16 (X11/20080813) MIME-Version: 1.0 To: Alexander Leidinger References: <48CFB56D.3070908@moneybookers.com> <20080917111035.12175aklikhtltcs@webmail.leidinger.net> In-Reply-To: <20080917111035.12175aklikhtltcs@webmail.leidinger.net> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: PERC6/i/e cli X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 09:17:49 -0000 Alexander Leidinger wrote: > Quoting "Stefan Lambrev" (from Tue, > 16 Sep 2008 16:32:29 +0300): > >> Virtual Drive Information: >> VD DRV RLP RLS RLQ STS SIZE STATE NAME >> 0 2 1 0 0 64kB 139392MB Optimal Ah and btw I >> think it was mandatory to have compat.linux.osrelease=2.6.12 >> (2.6.16 works too but you have to fix the script to not complain - i >> think the port is still not fixed?) > > Not related to $Subject, but related to the linuxulator: Only use the > default osrelease value or 2.6.16. Anything else may open pandoras box. The port comes with a shell script/wrapper which require you to use 2.6.12. I think the maintainer promised to change it to >= 2.6.12 I personally use 2.6.16 and fixed the wrapper by myself to work only with this version. The point of the maintainer is that if it works with 2.6.12, why we should disable it? For me it's enough to work with default 2.6.16 value, but someone may want to experiment .. not that a small shell script will stop them .. > > Bye, > Alexander. > -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 09:24:09 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA7EA1065685; Wed, 17 Sep 2008 09:24:09 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 8E3C58FC2F; Wed, 17 Sep 2008 09:24:04 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id E4D7F170E4; Wed, 17 Sep 2008 09:24:02 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m8H9O1Si089741; Wed, 17 Sep 2008 09:24:01 GMT (envelope-from phk@critter.freebsd.dk) To: Andrey Chernov From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 17 Sep 2008 13:01:01 +0400." <20080917090101.GC57480@nagual.pp.ru> Date: Wed, 17 Sep 2008 09:24:01 +0000 Message-ID: <89740.1221643441@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Daniel Eischen , Max Laier , freebsd-current@freebsd.org Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 09:24:09 -0000 In message <20080917090101.GC57480@nagual.pp.ru>, Andrey Chernov writes: >On Wed, Sep 17, 2008 at 08:04:57AM +0000, Poul-Henning Kamp wrote: >> >The situation is not so simple since the library functions can call >> >ar4random() internally (like mktemp() family already and always does) >> >> I have a really hard time seeing how this could become a performance >> issue, ever. > >The performance issue happens when application tries to call arc4random() >in the loop. That is not what we are talking about, we are talking about the calls in mktemp and similar. >> The solution however, is simple: Just have these hidden library calls >> to arc4random call a wrapper function that does the pid check. > >We can control our own arc4random() internal calls inside our own libs in >such way but can't control 3rd party libs or programs arc4random() calls >(consider ports). We are not obliged to control these calls. If their authors do something stupid, it's not our problem. You are, as usual, trying to vastly overengineer a minor problem that has a simple solution. Just have the FreeBSD library calls, call the wrapper function that does a pid check and be done with it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 09:32:44 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31EEC1065671; Wed, 17 Sep 2008 09:32:44 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 8120A8FC12; Wed, 17 Sep 2008 09:32:43 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.3/8.14.3) with ESMTP id m8H9WgOQ059693; Wed, 17 Sep 2008 13:32:42 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1221643962; bh=4qbgQhLJlu1S50p5NdA1I9La3Gy0lo1ZHqzGlKL V5Us=; l=1312; h=Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:In-Reply-To; b=kYMTuRNbj0p+MYsgfNtOa5l44 ib+9WR4YM4Wrh2v4eNoLwLRRtoPas43xenVwxzzomQuwBgwBq2CME+E7RA6qaiq7YFN Tf0ZqAbr9JGjEwFb+oHESmV4TwTy8ynPRCTvJGEE29Lz2n9MFLtXv+dWGZufGheVaPu DTtogZvR2Gdk= Received: (from ache@localhost) by nagual.pp.ru (8.14.3/8.14.3/Submit) id m8H9Wgkb059691; Wed, 17 Sep 2008 13:32:42 +0400 (MSD) (envelope-from ache) Date: Wed, 17 Sep 2008 13:32:40 +0400 From: Andrey Chernov To: Poul-Henning Kamp Message-ID: <20080917093238.GA59500@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Poul-Henning Kamp , Daniel Eischen , Max Laier , freebsd-current@freebsd.org References: <20080917090101.GC57480@nagual.pp.ru> <89740.1221643441@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <89740.1221643441@critter.freebsd.dk> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Daniel Eischen , Max Laier , freebsd-current@freebsd.org Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 09:32:44 -0000 On Wed, Sep 17, 2008 at 09:24:01AM +0000, Poul-Henning Kamp wrote: > >The performance issue happens when application tries to call arc4random() > >in the loop. > > That is not what we are talking about, we are talking about the calls > in mktemp and similar. There are two things needed to be separated. mktemp etc. calls are the reason for the check. The check (in its current form) is the reason for slowing down in the loops because syscall overhead. > >We can control our own arc4random() internal calls inside our own libs in > >such way but can't control 3rd party libs or programs arc4random() calls > >(consider ports). > > We are not obliged to control these calls. If their authors do something > stupid, it's not our problem. The problem is that we are not authors of that API but currently OpenBSD are. We just integrate their API. Perhaps their API is stupid in this point (so they resolve it by non-efficient way), but people will try to follow their API because they are the authors, not ours. > Just have the FreeBSD library calls, call the wrapper function that > does a pid check and be done with it. I understand your idea and it was first idea that comes to me too, but since API is not ours, it does not work that way. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 09:34:14 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77F9B106580F; Wed, 17 Sep 2008 09:34:14 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 3BD498FC2E; Wed, 17 Sep 2008 09:34:14 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id D5613170E4; Wed, 17 Sep 2008 09:34:12 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m8H9YC5G089832; Wed, 17 Sep 2008 09:34:12 GMT (envelope-from phk@critter.freebsd.dk) To: Andrey Chernov From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 17 Sep 2008 13:32:40 +0400." <20080917093238.GA59500@nagual.pp.ru> Date: Wed, 17 Sep 2008 09:34:12 +0000 Message-ID: <89831.1221644052@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Daniel Eischen , Max Laier , freebsd-current@freebsd.org Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 09:34:14 -0000 In message <20080917093238.GA59500@nagual.pp.ru>, Andrey Chernov writes: >On Wed, Sep 17, 2008 at 09:24:01AM +0000, Poul-Henning Kamp wrote: >> Just have the FreeBSD library calls, call the wrapper function that >> does a pid check and be done with it. > >I understand your idea and it was first idea that comes to me too, but >since API is not ours, it does not work that way. Well, in that case, you should leave the "slow" check in place and live with it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 09:39:06 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8610F106567C; Wed, 17 Sep 2008 09:39:06 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id C3DDD8FC1D; Wed, 17 Sep 2008 09:39:05 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.14) with ESMTPA id 221075165; Wed, 17 Sep 2008 12:39:04 +0300 Message-ID: <48D0D037.4000005@FreeBSD.org> Date: Wed, 17 Sep 2008 12:39:03 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (X11/20080612) MIME-Version: 1.0 To: Alex Keda References: <48CBF399.9080801@FreeBSD.org> <48D0CB33.9060303@lissyara.su> In-Reply-To: <48D0CB33.9060303@lissyara.su> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-multimedia@FreeBSD.org, freebsd-current@freebsd.org Subject: Re: New snd_hda driver came in. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 09:39:06 -0000 Hi. Alex Keda wrote: > after today update source, not work internal speaker... > phones - works... > lissyara$ dmesg | grep hda > hdac0: mem > 0xd8900000-0xd8903fff irq 16 at device 20.2 on pci0 > hdac0: > hdac0: [ITHREAD] > hdac0: > pcm0: on hdac0 > lissyara$ uname -a > FreeBSD lissyara.moskb.local 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Wed Sep > 17 10:41:27 MSD 2008 > lissyara@lissyara.moskb.local:/tmp/obj/usr/src/sys/GENERIC amd64 > lissyara$ > before update work and phones and speaker (but, when plug phones speaker > not dead =() > how say driver use internal speaker? Send me please verbose boot messages from your system. Also try to plug/unplug headphones with verbose messages enabled looking for any kernel log activity and send that logs to me. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 09:45:48 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 191881065670; Wed, 17 Sep 2008 09:45:48 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 7CDFE8FC12; Wed, 17 Sep 2008 09:45:47 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.3/8.14.3) with ESMTP id m8H9jjYv060026; Wed, 17 Sep 2008 13:45:45 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1221644746; bh=0rzdvm4UtQ5JXIAa+lzBvY4IzTz/css7It/1/5l b0uw=; l=1115; h=Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:In-Reply-To; b=e3aI2hh+wlgsz7Z1qQN1At4gK q2ak6iPoLA9B2uYZC+sS+2K3CpEXPogAj9CrGyzUZvpN1N1qhrFTkk4yE3C5jCiNcsB pLks9kzb0V53uF/SFYl09/VfWkAKzPTJAgjkMe0ILEqGDl9MjboifNk9VKFF+lE6cmb w20Xes0qgNZ0= Received: (from ache@localhost) by nagual.pp.ru (8.14.3/8.14.3/Submit) id m8H9jjqx060024; Wed, 17 Sep 2008 13:45:45 +0400 (MSD) (envelope-from ache) Date: Wed, 17 Sep 2008 13:45:43 +0400 From: Andrey Chernov To: Poul-Henning Kamp Message-ID: <20080917094542.GA59756@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Poul-Henning Kamp , Daniel Eischen , Max Laier , freebsd-current@freebsd.org References: <20080917093238.GA59500@nagual.pp.ru> <89831.1221644052@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <89831.1221644052@critter.freebsd.dk> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Daniel Eischen , Max Laier , freebsd-current@freebsd.org Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 09:45:48 -0000 On Wed, Sep 17, 2008 at 09:34:12AM +0000, Poul-Henning Kamp wrote: > In message <20080917093238.GA59500@nagual.pp.ru>, Andrey Chernov writes: > >On Wed, Sep 17, 2008 at 09:24:01AM +0000, Poul-Henning Kamp wrote: > > >> Just have the FreeBSD library calls, call the wrapper function that > >> does a pid check and be done with it. > > > >I understand your idea and it was first idea that comes to me too, but > >since API is not ours, it does not work that way. > > Well, in that case, you should leave the "slow" check in place and > live with it. Not so doomed. As already discussed in this thread we can ether: a) Add *fork() hook to clear arc4random's flag which inidicates it is stired (to re-stir it on the next call). This slightly increases diffs with OpenBSD arc4random code. b) Speed up getpid() itself by caching its value (adding *fork() and getpid() hooks). This produces no diffs with OpenBSD arc4random code. That way give more benefits for other program that calls getpid() often to check they are in the child, but I don't have examples. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 10:00:27 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A94161065690; Wed, 17 Sep 2008 10:00:27 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 5B4848FC1E; Wed, 17 Sep 2008 10:00:27 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (unknown [93.197.243.44]) by redbull.bpaserver.net (Postfix) with ESMTP id 637182E098; Wed, 17 Sep 2008 12:00:20 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id B9E5815901F; Wed, 17 Sep 2008 12:00:07 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.14.2/8.13.8/Submit) id m8HA06JT087728; Wed, 17 Sep 2008 12:00:06 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Wed, 17 Sep 2008 12:00:06 +0200 Message-ID: <20080917120006.13141ndfdhnpaczo@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Wed, 17 Sep 2008 12:00:06 +0200 From: "Alexander Leidinger" To: "Stefan Lambrev" References: <48CFB56D.3070908@moneybookers.com> <20080917111035.12175aklikhtltcs@webmail.leidinger.net> <48D0CB34.4020207@moneybookers.com> In-Reply-To: <48D0CB34.4020207@moneybookers.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.2) / FreeBSD-8.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 637182E098.EEAD0 X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, ORDB-RBL, SpamAssassin (not cached, score=-14.2, required 6, BAYES_00 -15.00, MR_NOT_ATTRIBUTED_IP 0.20, NO_RDNS 0.50, RDNS_NONE 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: PERC6/i/e cli X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 10:00:27 -0000 Quoting "Stefan Lambrev" (from Wed, =20 17 Sep 2008 12:17:40 +0300): > > > Alexander Leidinger wrote: >> Quoting "Stefan Lambrev" (from =20 >> Tue, 16 Sep 2008 16:32:29 +0300): >> >>> Virtual Drive Information: >>> VD DRV RLP RLS RLQ STS SIZE STATE NAME >>> 0 2 1 0 0 64kB 139392MB Optimal Ah and btw I =20 >>> think it was mandatory to have compat.linux.osrelease=3D2.6.12 >>> (2.6.16 works too but you have to fix the script to not complain - =20 >>> i think the port is still not fixed?) >> >> Not related to $Subject, but related to the linuxulator: Only use =20 >> the default osrelease value or 2.6.16. Anything else may open =20 >> pandoras box. > The port comes with a shell script/wrapper which require you to use =20 > 2.6.12. I think the maintainer promised to change it to >=3D 2.6.12 > I personally use 2.6.16 and fixed the wrapper by myself to work only =20 > with this version. > The point of the maintainer is that if it works with 2.6.12, why we =20 > should disable it? > For me it's enough to work with default 2.6.16 value, but someone =20 > may want to experiment .. not that a small shell script will stop =20 > them .. The linuxulator (kernel) will only switch to 2.6 mode with 2.6.16, =20 with everything else it will stay in 2.4 mode. The linux =20 infrastructure (ports) may decide to do their own stuff based upon the =20 value of osversion. In the linux_base-fc6 this is the case for sure =20 (libc and so on). The port you use may do the same. You've been =20 warned... Bye, Alexander. --=20 You know it's going to be a bad day when you want to put on the clothes you wore home from the party and there aren't any. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 10:16:00 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED94E106566C for ; Wed, 17 Sep 2008 10:16:00 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (vlk.vlakno.cz [62.168.28.247]) by mx1.freebsd.org (Postfix) with ESMTP id 9D01C8FC1C for ; Wed, 17 Sep 2008 10:16:00 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 6D1DE65C43B; Wed, 17 Sep 2008 12:16:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (vlk.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjtXy9LH4OXv; Wed, 17 Sep 2008 12:16:06 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 16E6A65C394; Wed, 17 Sep 2008 12:16:05 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.2/8.14.2/Submit) id m8HAG5VZ091817; Wed, 17 Sep 2008 12:16:05 +0200 (CEST) (envelope-from rdivacky) Date: Wed, 17 Sep 2008 12:16:05 +0200 From: Roman Divacky To: Alexander Leidinger Message-ID: <20080917101605.GA91263@freebsd.org> References: <48CFB56D.3070908@moneybookers.com> <20080917111035.12175aklikhtltcs@webmail.leidinger.net> <48D0CB34.4020207@moneybookers.com> <20080917120006.13141ndfdhnpaczo@webmail.leidinger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080917120006.13141ndfdhnpaczo@webmail.leidinger.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org, Stefan Lambrev Subject: Re: PERC6/i/e cli X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 10:16:01 -0000 On Wed, Sep 17, 2008 at 12:00:06PM +0200, Alexander Leidinger wrote: > Quoting "Stefan Lambrev" (from Wed, > 17 Sep 2008 12:17:40 +0300): > > > > > > >Alexander Leidinger wrote: > >>Quoting "Stefan Lambrev" (from > >>Tue, 16 Sep 2008 16:32:29 +0300): > >> > >>>Virtual Drive Information: > >>>VD DRV RLP RLS RLQ STS SIZE STATE NAME > >>>0 2 1 0 0 64kB 139392MB Optimal Ah and btw I > >>>think it was mandatory to have compat.linux.osrelease=2.6.12 > >>>(2.6.16 works too but you have to fix the script to not complain - > >>>i think the port is still not fixed?) > >> > >>Not related to $Subject, but related to the linuxulator: Only use > >>the default osrelease value or 2.6.16. Anything else may open > >>pandoras box. > >The port comes with a shell script/wrapper which require you to use > >2.6.12. I think the maintainer promised to change it to >= 2.6.12 > >I personally use 2.6.16 and fixed the wrapper by myself to work only > >with this version. > >The point of the maintainer is that if it works with 2.6.12, why we > >should disable it? > >For me it's enough to work with default 2.6.16 value, but someone > >may want to experiment .. not that a small shell script will stop > >them .. > > The linuxulator (kernel) will only switch to 2.6 mode with 2.6.16, > with everything else it will stay in 2.4 mode. The linux > infrastructure (ports) may decide to do their own stuff based upon the > value of osversion. In the linux_base-fc6 this is the case for sure > (libc and so on). The port you use may do the same. You've been > warned... actually linuxulator checks if the "osrelease" string is at least 3 chars long and if the 3rd char is "6" so "2.6.16" works exactly the same as "9.6.IamAlittleBUTTERFLY".... the fact is that we officially support only 2.6.16 as this is what is most testing done with. On the other hand I think that anything below 16 (2.6.0 -> 2.6.15) should work exactly as good. The problem might be with version > 16. Anyway - the port should be fixed. In 8-CURRENT we default to "2.6.16" so the port doesnt work... roman From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 10:27:40 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6D24106566B for ; Wed, 17 Sep 2008 10:27:40 +0000 (UTC) (envelope-from hpcharles@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.freebsd.org (Postfix) with ESMTP id 800E38FC2A for ; Wed, 17 Sep 2008 10:27:40 +0000 (UTC) (envelope-from hpcharles@gmail.com) Received: by py-out-1112.google.com with SMTP id p76so2352620pyb.10 for ; Wed, 17 Sep 2008 03:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=iFnUX4d/HY4CDzT+gtylV+VbAnv3F+JjjYm6x+GNdY8=; b=NskkDglgJ8SDHoRq62KJwghFc8Frp7746RPNaEl2xB8+6Z5F0X652adPtl3SijQcoY zOUMn9WewRo/5GLJD/E+3UGEhiLxEvQh5TKqb2MhwS1z1/Z0a91ZCaLrfrkKdXDDbavM tYZZrdupzgSPqpwtOQSnMn6Q1kzZDAcs0LzDk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=B0pVufVqgQEaqr6XJWpefScCkGL7kNg2NC3/aKHHMx751gqsMXm8NzJzWzDpNn4+Mf wukFMUBE/kv4cW8Y55MnlJDxKiZyWh8bdjm+NyAv3+C/2L5lac1n4I6L0vopwP+gU7gG yo7D8cZ9Cvym/NDRaWryio2I1410wyYeCm0OI= Received: by 10.142.77.11 with SMTP id z11mr770489wfa.337.1221645647954; Wed, 17 Sep 2008 03:00:47 -0700 (PDT) Received: by 10.142.203.16 with HTTP; Wed, 17 Sep 2008 03:00:47 -0700 (PDT) Message-ID: <4734a3ed0809170300y33ee44e0u684a5820a0f392ab@mail.gmail.com> Date: Wed, 17 Sep 2008 12:00:47 +0200 From: "Henri-Pierre Charles" To: "Stanislav Sedov" In-Reply-To: <20080627163107.deccdd55.stas@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080627163107.deccdd55.stas@FreeBSD.org> Cc: current@freebsd.org Subject: Re: Attansic L2 driver test request X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hpcharles@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 10:27:40 -0000 Hello, I just discover your messages, I tried to use FreeBSD on my eeepc. 7.0-release has to be patched for ath0 8.0-CURRENT-200809 work out of the box On Fri, Jun 27, 2008 at 2:31 PM, Stanislav Sedov wrote: > For last weeks I was working on implementing an Attansic L2 > driver for FreeBSD that can be found on some of Asus motherboards > and Asus EeePC. I'm not sure if discrete adapters are available. > For the moment, I've implemented all the basic stuff, and the > drivers seems to perform stable enough. > http://www.SpringDaemons.com/stas/if_ae-1214569185.tar.bz2 I've tried your driver, but I'm not a specialist of device debug. So far I've tried : -- wget http://www.springdaemons.com/stas/if_ae-1214569185.tar.bz2 tar xvfz if_ae-1214569185.tar.bz2 cd if_ae make sudo kldload `pwd`/if_ae.ko ifconfig ae0 -- Just after the last command the ae0 interface show up and give ae0: flags=8802 metric 0 mtu 1500 options=8 ether 00:1e:8c:bc:9f:7a media: Ethernet autoselect (100baseTX ) status: active /var/log/message contain : Sep 17 09:55:55 eeebsd kernel: ae0: mem 0xfbfc0000-0xfbffffff irq 17 at device 0.0 on pci3 Sep 17 09:55:55 eeebsd kernel: ae0: pci device revision: 0xa0 Sep 17 09:55:55 eeebsd kernel: ae0: chip id: 0x3 Sep 17 09:55:55 eeebsd kernel: miibus0: on ae0 Sep 17 09:55:55 eeebsd kernel: ukphy0: PHY 0 on miibus0 Sep 17 09:55:55 eeebsd kernel: ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Sep 17 09:55:55 eeebsd kernel: ae0: Ethernet address: 00:1e:8c:bc:9f:7a Sep 17 09:55:55 eeebsd kernel: ae0: [FILTER] Sep 17 09:55:56 eeebsd kernel: ae0: link state changed to DOWN Sep 17 09:56:37 eeebsd kernel: ae0: link state changed to UP But all test to use it freeze the system : ifconfig ae0 up of dhclient ae0. Tested on 8.0-CURRENT-200809 Can I test anythink else ? Thanks for your work ! -- HPC From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 10:29:57 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 252D81065689 for ; Wed, 17 Sep 2008 10:29:57 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (vlk.vlakno.cz [62.168.28.247]) by mx1.freebsd.org (Postfix) with ESMTP id D59538FC15 for ; Wed, 17 Sep 2008 10:29:56 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 0362D65C438; Wed, 17 Sep 2008 12:10:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (vlk.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cL2mhWf2ImQw; Wed, 17 Sep 2008 12:10:14 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 139EB65C410; Wed, 17 Sep 2008 12:10:14 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.2/8.14.2/Submit) id m8HAADFE091140; Wed, 17 Sep 2008 12:10:13 +0200 (CEST) (envelope-from rdivacky) Date: Wed, 17 Sep 2008 12:10:13 +0200 From: Roman Divacky To: current@freebsd.org Message-ID: <20080917101013.GA90749@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: jb@freebsd.org Subject: dtrace status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 10:29:57 -0000 hi Dtrace was commited 3 months ago and the only things that prevents using it "out of the box" is building kernel with WITH_CTF=1. When is this going to be enabled on default. What is preventing this from happening? thank you very much roman From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 10:48:13 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11F7B1065686; Wed, 17 Sep 2008 10:48:13 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id BB6148FC13; Wed, 17 Sep 2008 10:48:06 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1KfuZo-0004N9-Tq; Wed, 17 Sep 2008 13:48:04 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Stefan Lambrev In-reply-to: <48D0CB34.4020207@moneybookers.com> References: <48CFB56D.3070908@moneybookers.com> <20080917111035.12175aklikhtltcs@webmail.leidinger.net> <48D0CB34.4020207@moneybookers.com> Comments: In-reply-to Stefan Lambrev message dated "Wed, 17 Sep 2008 12:17:40 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Sep 2008 13:48:04 +0300 From: Danny Braniss Message-ID: Cc: Alexander Leidinger , freebsd-current@FreeBSD.org, freebsd-scsi@FreeBSD.org Subject: Re: PERC6/i/e cli X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 10:48:13 -0000 > > > Alexander Leidinger wrote: > > Quoting "Stefan Lambrev" (from Tue, > > 16 Sep 2008 16:32:29 +0300): > > > >> Virtual Drive Information: > >> VD DRV RLP RLS RLQ STS SIZE STATE NAME > >> 0 2 1 0 0 64kB 139392MB Optimal Ah and btw I > >> think it was mandatory to have compat.linux.osrelease=2.6.12 > >> (2.6.16 works too but you have to fix the script to not complain - i > >> think the port is still not fixed?) > > > > Not related to $Subject, but related to the linuxulator: Only use the > > default osrelease value or 2.6.16. Anything else may open pandoras box. > The port comes with a shell script/wrapper which require you to use > 2.6.12. I think the maintainer promised to change it to >= 2.6.12 > I personally use 2.6.16 and fixed the wrapper by myself to work only > with this version. > The point of the maintainer is that if it works with 2.6.12, why we > should disable it? > For me it's enough to work with default 2.6.16 value, but someone may > want to experiment .. not that a small shell script will stop them .. > > personaly, I am using /usr/local/lib/MegaCli directly, since from experimentation, the mfi_linux module MUST be loaded before mounting linsysfs, and the shell script is missleading. I modified /etc/rc.d/abi to do it correctly. danny > > Bye, > > Alexander. > > > > -- > > Best Wishes, > Stefan Lambrev > ICQ# 24134177 > From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 11:38:08 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DE49106564A; Wed, 17 Sep 2008 11:38:08 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id A96B68FC20; Wed, 17 Sep 2008 11:38:07 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.14) with ESMTPA id 221088840; Wed, 17 Sep 2008 14:38:06 +0300 Message-ID: <48D0EC1D.9040901@FreeBSD.org> Date: Wed, 17 Sep 2008 14:38:05 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (X11/20080612) MIME-Version: 1.0 To: Alex Keda References: <48CBF399.9080801@FreeBSD.org> <48D0CB33.9060303@lissyara.su> <48D0D037.4000005@FreeBSD.org> <48D0DDF3.7050207@lissyara.su> In-Reply-To: <48D0DDF3.7050207@lissyara.su> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-multimedia@FreeBSD.org, freebsd-current@freebsd.org Subject: Re: New snd_hda driver came in. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 11:38:08 -0000 Alex Keda wrote: >>> after today update source, not work internal speaker... >>> phones - works... >>> lissyara$ dmesg | grep hda >>> hdac0: mem >>> 0xd8900000-0xd8903fff irq 16 at device 20.2 on pci0 >>> hdac0: >>> hdac0: [ITHREAD] >>> hdac0: >>> pcm0: on hdac0 >>> lissyara$ uname -a >>> FreeBSD lissyara.moskb.local 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Wed Sep >>> 17 10:41:27 MSD 2008 >>> lissyara@lissyara.moskb.local:/tmp/obj/usr/src/sys/GENERIC amd64 >>> lissyara$ >>> before update work and phones and speaker (but, when plug phones speaker >>> not dead =() >>> how say driver use internal speaker? >> >> Send me please verbose boot messages from your system. Also try to >> plug/unplug headphones with verbose messages enabled looking for any >> kernel log activity and send that logs to me. >> > see attached file As I can see, your BIOS configures codec in very unusual way. It defines 2 playback associations (logical devices): one for line-out jack and headphones jack and another for speaker. As soon as your ALC262 codec allows playback to speaker only from first DAC and it was already used by the first association, driver was unable to route any signal to speaker reporting: hdac0: Association 1 (2) trace failed You can specify hint.hdac.0.cad3.nid22.config="as=1" hint.hdac.0.cad3.nid27.config="as=2" in your loader.conf to reconfigure codec in a more usual way to make speaker and headphones jack a first association and line-out - second. That combination should work fine I think. If it will - tell me your system model to add permanent quirk to the driver. > and > > plug phones: > hdac0: Unsol Tag: 0x00000000 > hdac0: Pin sense: nid=21 res=0x80000000 > > unplug phones: > hdac0: Unsol Tag: 0x00000000 > hdac0: Pin sense: nid=21 res=0x00000000 This means that jack detection works. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 12:27:11 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FB631065684 for ; Wed, 17 Sep 2008 12:27:11 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from munchkin.clue.co.za (munchkin.clue.co.za [66.219.59.160]) by mx1.freebsd.org (Postfix) with ESMTP id 0252B8FC0C for ; Wed, 17 Sep 2008 12:27:10 +0000 (UTC) (envelope-from ianf@clue.co.za) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=20070313; d=clue.co.za; h=Received:Received:Received:To:cc:From:Subject:In-Reply-To:References:X-Attribution:Date:Message-Id; b=h80KipjtVltbMK5a9M30Jjid/YfzZ0TuS/ToCrcgFccmY6Kf7b4GAca9hT8jSCnlJqh13j3OnpkiNdoed9W1d5MTCuEyrh4rnernQe24zB8ECBItY0OwCTn5JqcKkiooxQZQ3w4/LTjC1bH2S5OlAfuxn/SOwc2yrSpiuhC5J9op2lzvyc9D1EXeLxHa+obccbQw+r82AJu9smNkmDUlJL3LnosNU07zYznT/GwAb9Vks8rnSjaMzSt9+GZeLxMV; Received: from uucp by munchkin.clue.co.za with local-rmail (Exim 4.67) (envelope-from ) id 1Kfw7i-0002ax-2o; Wed, 17 Sep 2008 12:27:10 +0000 Received: from dsl-241-65-41.telkomadsl.co.za ([41.241.65.41] helo=clue.co.za) by urchin.clue.co.za with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Kfw78-00039D-7V; Wed, 17 Sep 2008 12:26:34 +0000 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kfw76-0001dB-Gs; Wed, 17 Sep 2008 14:26:32 +0200 To: Mike Tancsa From: Ian FREISLICH In-Reply-To: <200809171213.m8HCDMgc043508@lava.sentex.ca> References: <200809171213.m8HCDMgc043508@lava.sentex.ca> X-Attribution: BOFH Date: Wed, 17 Sep 2008 14:26:32 +0200 Message-Id: Cc: current@freebsd.org Subject: Re: PATCH: crypto/openssl/crypto/engine/eng_table.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 12:27:11 -0000 Mike Tancsa wrote: > At 04:06 AM 9/17/2008, Ian Freislich wrote: > >Hi > > > >I had to apply the following patch to fix the engine cache in openssl > >so that it will actually use the padlock driver for accelleration. > >It appears that the original logic was reversed. > > Hi, > For applications (eg sshd), is not > --- crypto/openssl/crypto/engine/eng_cryptodev.c 2008-02-05 > 13:10:31.000000000 -0500 > +++ crypto/openssl/crypto/engine/eng_cryptodev.c.good 2008-08-21 > 13:10:26.000000000 -0400 > @@ -1127,6 +1127,7 @@ > } > > ENGINE_add(engine); > + ENGINE_set_default_ciphers(engine); > ENGINE_free(engine); > ERR_clear_error(); > } > > also necessary ? The patch I posted was sufficient in conjunction with the following addition to /etc/ssl/openssl.cnf: openssl_conf = openssl_def [openssl_def] engines = openssl_engines [openssl_engines] padlock = padlock_engine [padlock_engine] default_algorithms = ALL Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 12:30:27 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E982C1065674; Wed, 17 Sep 2008 12:30:27 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 719948FC14; Wed, 17 Sep 2008 12:30:27 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [195.93.241.11] (port=2653 helo=lissyara.moskb.local) by hosting.lissyara.su with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KfwAr-000FMg-WD; Wed, 17 Sep 2008 16:30:26 +0400 Message-ID: <48D0F860.6090307@lissyara.su> Date: Wed, 17 Sep 2008 16:30:24 +0400 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.16) Gecko/20080903 Thunderbird/2.0.0.16 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Alexander Motin References: <48CBF399.9080801@FreeBSD.org> <48D0CB33.9060303@lissyara.su> <48D0D037.4000005@FreeBSD.org> <48D0DDF3.7050207@lissyara.su> <48D0EC1D.9040901@FreeBSD.org> In-Reply-To: <48D0EC1D.9040901@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: freebsd-multimedia@FreeBSD.org, freebsd-current@freebsd.org Subject: Re: New snd_hda driver came in. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 12:30:28 -0000 Alexander Motin : > Alex Keda wrote: > >>>> after today update source, not work internal speaker... >>>> phones - works... >>>> lissyara$ dmesg | grep hda >>>> hdac0: mem >>>> 0xd8900000-0xd8903fff irq 16 at device 20.2 on pci0 >>>> hdac0: >>>> hdac0: [ITHREAD] >>>> hdac0: >>>> pcm0: on hdac0 >>>> lissyara$ uname -a >>>> FreeBSD lissyara.moskb.local 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Wed Sep >>>> 17 10:41:27 MSD 2008 >>>> lissyara@lissyara.moskb.local:/tmp/obj/usr/src/sys/GENERIC amd64 >>>> lissyara$ >>>> before update work and phones and speaker (but, when plug phones speaker >>>> not dead =() >>>> how say driver use internal speaker? >>>> >>> Send me please verbose boot messages from your system. Also try to >>> plug/unplug headphones with verbose messages enabled looking for any >>> kernel log activity and send that logs to me. >>> >>> >> see attached file >> > > As I can see, your BIOS configures codec in very unusual way. It defines > 2 playback associations (logical devices): one for line-out jack and > headphones jack and another for speaker. As soon as your ALC262 codec > allows playback to speaker only from first DAC and it was already used > by the first association, driver was unable to route any signal to > speaker reporting: > hdac0: Association 1 (2) trace failed > > You can specify > hint.hdac.0.cad3.nid22.config="as=1" > hint.hdac.0.cad3.nid27.config="as=2" > in your loader.conf to reconfigure codec in a more usual way to make > speaker and headphones jack a first association and line-out - second. > That combination should work fine I think. > > If it will - tell me your system model to add permanent quirk to the driver. > Thanks! It work! By default - sound from speaker, if I plug headphones - speaker is off, and sound from phones. ============== about my box. It brand HP computer - "HP xw4550 Workstation" Motherboard contain only "HP" logo and "Model FMB 0703" It's all... From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 12:47:48 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C851C1065674; Wed, 17 Sep 2008 12:47:48 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id E75098FC22; Wed, 17 Sep 2008 12:47:47 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.14) with ESMTPA id 221096513; Wed, 17 Sep 2008 15:47:47 +0300 Message-ID: <48D0FC72.9020707@FreeBSD.org> Date: Wed, 17 Sep 2008 15:47:46 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (X11/20080612) MIME-Version: 1.0 To: Alex Keda References: <48CBF399.9080801@FreeBSD.org> <48D0CB33.9060303@lissyara.su> <48D0D037.4000005@FreeBSD.org> <48D0DDF3.7050207@lissyara.su> <48D0EC1D.9040901@FreeBSD.org> <48D0F860.6090307@lissyara.su> In-Reply-To: <48D0F860.6090307@lissyara.su> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-multimedia@FreeBSD.org, freebsd-current@freebsd.org Subject: Re: New snd_hda driver came in. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 12:47:48 -0000 Alex Keda wrote: >> You can specify >> hint.hdac.0.cad3.nid22.config="as=1" >> hint.hdac.0.cad3.nid27.config="as=2" >> in your loader.conf to reconfigure codec in a more usual way to make >> speaker and headphones jack a first association and line-out - second. >> That combination should work fine I think. >> >> If it will - tell me your system model to add permanent quirk to the >> driver. >> > Thanks! It work! > By default - sound from speaker, if I plug headphones - speaker is off, > and sound from phones. > > ============== > about my box. > It brand HP computer - "HP xw4550 Workstation" > Motherboard contain only "HP" logo and "Model FMB 0703" > It's all... Desktop with speaker, it's unusual. Is it's speaker worth to play sound over it or it is not able to play well anything except BEEP..BEEP..? Do you think that my codec setup is good in it's case? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 12:53:31 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5708E1065673 for ; Wed, 17 Sep 2008 12:53:31 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 03F5F8FC1C for ; Wed, 17 Sep 2008 12:53:30 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m8HCDN0B014313; Wed, 17 Sep 2008 08:13:23 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m8HCDMgc043508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Sep 2008 08:13:22 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200809171213.m8HCDMgc043508@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 17 Sep 2008 08:13:21 -0400 To: "Ian Freislich" , current@freebsd.org From: Mike Tancsa In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: Re: PATCH: crypto/openssl/crypto/engine/eng_table.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 12:53:31 -0000 At 04:06 AM 9/17/2008, Ian Freislich wrote: >Hi > >I had to apply the following patch to fix the engine cache in openssl >so that it will actually use the padlock driver for accelleration. >It appears that the original logic was reversed. Hi, For applications (eg sshd), is not --- crypto/openssl/crypto/engine/eng_cryptodev.c 2008-02-05 13:10:31.000000000 -0500 +++ crypto/openssl/crypto/engine/eng_cryptodev.c.good 2008-08-21 13:10:26.000000000 -0400 @@ -1127,6 +1127,7 @@ } ENGINE_add(engine); + ENGINE_set_default_ciphers(engine); ENGINE_free(engine); ERR_clear_error(); } also necessary ? ---Mike >RCS file: /home/ncvs/src/crypto/openssl/crypto/engine/eng_table.c,v >retrieving revision 1.1.1.2 >diff -u -d -r1.1.1.2 eng_table.c >--- eng_table.c 29 Jul 2006 19:10:18 -0000 1.1.1.2 >+++ eng_table.c 12 Jun 2008 07:52:52 -0000 >@@ -135,7 +135,7 @@ > { > fnd = OPENSSL_malloc(sizeof(ENGINE_PILE)); > if(!fnd) goto end; >- fnd->uptodate = 0; >+ fnd->uptodate = 1; > fnd->nid = *nids; > fnd->sk = sk_ENGINE_new_null(); > if(!fnd->sk) >@@ -152,7 +152,7 @@ > if(!sk_ENGINE_push(fnd->sk, e)) > goto end; > /* "touch" this ENGINE_PILE */ >- fnd->uptodate = 1; >+ fnd->uptodate = 0; > if(setdefault) > { > if(!engine_unlocked_init(e)) >@@ -180,7 +180,7 @@ > { > sk_ENGINE_delete(pile->sk, n); > /* "touch" this ENGINE_CIPHER */ >- pile->uptodate = 1; >+ pile->uptodate = 0; > } > if(pile->funct == e) > { > > >-- >Ian Freislich > >_______________________________________________ >freebsd-current@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 13:09:50 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF386106564A; Wed, 17 Sep 2008 13:09:50 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 49E208FC13; Wed, 17 Sep 2008 13:09:50 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [195.93.241.11] (port=47925 helo=lissyara.moskb.local) by hosting.lissyara.su with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kfwmv-000NCt-PD; Wed, 17 Sep 2008 17:09:45 +0400 Message-ID: <48D10197.8020609@lissyara.su> Date: Wed, 17 Sep 2008 17:09:43 +0400 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.16) Gecko/20080903 Thunderbird/2.0.0.16 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Alexander Motin References: <48CBF399.9080801@FreeBSD.org> <48D0CB33.9060303@lissyara.su> <48D0D037.4000005@FreeBSD.org> <48D0DDF3.7050207@lissyara.su> <48D0EC1D.9040901@FreeBSD.org> <48D0F860.6090307@lissyara.su> <48D0FC72.9020707@FreeBSD.org> In-Reply-To: <48D0FC72.9020707@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: freebsd-multimedia@FreeBSD.org, freebsd-current@freebsd.org Subject: Re: New snd_hda driver came in. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 13:09:50 -0000 Alexander Motin : > Alex Keda wrote: > >>> You can specify >>> hint.hdac.0.cad3.nid22.config="as=1" >>> hint.hdac.0.cad3.nid27.config="as=2" >>> in your loader.conf to reconfigure codec in a more usual way to make >>> speaker and headphones jack a first association and line-out - second. >>> That combination should work fine I think. >>> >>> If it will - tell me your system model to add permanent quirk to the >>> driver. >>> >>> >> Thanks! It work! >> By default - sound from speaker, if I plug headphones - speaker is off, >> and sound from phones. >> >> ============== >> about my box. >> It brand HP computer - "HP xw4550 Workstation" >> Motherboard contain only "HP" logo and "Model FMB 0703" >> It's all... >> > > Desktop with speaker, it's unusual. Is it's speaker worth to play sound > over it or it is not able to play well anything except BEEP..BEEP..? Do > you think that my codec setup is good in it's case? > > No. All Hewlett Packard desktop, as I know (I use 4-5 models with different motherboards and CPU - Intel, AMD, P-III, P-IV, Opteron...), contain internal speaker, with play sound, and "beep" on boot (some old models contain another speaker for boot messages, but new - only one). HP - very out of the ordinary box... From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 13:16:08 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98891106567C; Wed, 17 Sep 2008 13:16:08 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 215768FC27; Wed, 17 Sep 2008 13:16:08 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [195.93.241.11] (port=55401 helo=lissyara.moskb.local) by hosting.lissyara.su with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kfwt5-000Ogx-BN; Wed, 17 Sep 2008 17:16:07 +0400 Message-ID: <48D10316.1090104@lissyara.su> Date: Wed, 17 Sep 2008 17:16:06 +0400 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.16) Gecko/20080903 Thunderbird/2.0.0.16 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Alexander Motin References: <48CBF399.9080801@FreeBSD.org> <48D0CB33.9060303@lissyara.su> <48D0D037.4000005@FreeBSD.org> <48D0DDF3.7050207@lissyara.su> <48D0EC1D.9040901@FreeBSD.org> <48D0F860.6090307@lissyara.su> <48D0FC72.9020707@FreeBSD.org> <48D10197.8020609@lissyara.su> In-Reply-To: <48D10197.8020609@lissyara.su> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: freebsd-multimedia@FreeBSD.org, freebsd-current@freebsd.org Subject: Re: New snd_hda driver came in. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 13:16:08 -0000 Alex Keda : > Alexander Motin : >> Alex Keda wrote: >> >>>> You can specify >>>> hint.hdac.0.cad3.nid22.config="as=1" >>>> hint.hdac.0.cad3.nid27.config="as=2" >>>> in your loader.conf to reconfigure codec in a more usual way to make >>>> speaker and headphones jack a first association and line-out - second. >>>> That combination should work fine I think. >>>> >>>> If it will - tell me your system model to add permanent quirk to the >>>> driver. >>>> >>> Thanks! It work! >>> By default - sound from speaker, if I plug headphones - speaker is off, >>> and sound from phones. >>> >>> ============== >>> about my box. >>> It brand HP computer - "HP xw4550 Workstation" >>> Motherboard contain only "HP" logo and "Model FMB 0703" >>> It's all... >>> >> >> Desktop with speaker, it's unusual. Is it's speaker worth to play sound >> over it or it is not able to play well anything except BEEP..BEEP..? Do >> you think that my codec setup is good in it's case? >> >> > No. All Hewlett Packard desktop, as I know (I use 4-5 models with > different motherboards and CPU - Intel, AMD, P-III, P-IV, Opteron...), > contain internal speaker, with play sound, and "beep" on boot (some > old models contain another speaker for boot messages, but new - only > one). > HP - very out of the ordinary box... may be wrong. I do not mean that the setting is bad. I had the view that it is not unusual. you just did not work with HP workstations From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 14:00:27 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0AD2106566B for ; Wed, 17 Sep 2008 14:00:26 +0000 (UTC) (envelope-from stas@ht-systems.ru) Received: from smtp.ht-systems.ru (mr0.ht-systems.ru [78.110.50.55]) by mx1.freebsd.org (Postfix) with ESMTP id 5A62A8FC1C for ; Wed, 17 Sep 2008 14:00:25 +0000 (UTC) (envelope-from stas@ht-systems.ru) Received: from [78.110.49.49] (helo=quasar.ht-systems.ru) by smtp.ht-systems.ru with esmtpa (Exim 4.62) (envelope-from ) id 1Kfuem-0006V2-F9; Wed, 17 Sep 2008 14:53:12 +0400 Received: by quasar.ht-systems.ru (Postfix, from userid 1024) id 64F1973020; Wed, 17 Sep 2008 14:53:11 +0400 (MSD) Date: Wed, 17 Sep 2008 14:53:11 +0400 From: Stanislav Sedov To: hpcharles@gmail.com Message-Id: <20080917145311.ff399006.stas@FreeBSD.org> In-Reply-To: <4734a3ed0809170300y33ee44e0u684a5820a0f392ab@mail.gmail.com> References: <20080627163107.deccdd55.stas@FreeBSD.org> <4734a3ed0809170300y33ee44e0u684a5820a0f392ab@mail.gmail.com> Organization: The FreeBSD Project X-XMPP: ssedov@jabber.ru X-Voice: +7 916 849 20 23 X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Wed__17_Sep_2008_14_53_11_+0400_Dmr68ujObsAZQd4e" Cc: Stanislav Sedov , current@freebsd.org Subject: Re: Attansic L2 driver test request X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 14:00:27 -0000 --Signature=_Wed__17_Sep_2008_14_53_11_+0400_Dmr68ujObsAZQd4e Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 17 Sep 2008 12:00:47 +0200 "Henri-Pierre Charles" mentioned: > Hello, I just discover your messages, I tried to use FreeBSD on my eeepc. >=20 > 7.0-release has to be patched for ath0 > 8.0-CURRENT-200809 work out of the box >=20 > On Fri, Jun 27, 2008 at 2:31 PM, Stanislav Sedov wrote: > > For last weeks I was working on implementing an Attansic L2 > > driver for FreeBSD that can be found on some of Asus motherboards > > and Asus EeePC. I'm not sure if discrete adapters are available. > > For the moment, I've implemented all the basic stuff, and the > > drivers seems to perform stable enough. > > http://www.SpringDaemons.com/stas/if_ae-1214569185.tar.bz2 >=20 > I've tried your driver, but I'm not a specialist of device debug. > So far I've tried : > -- > wget http://www.springdaemons.com/stas/if_ae-1214569185.tar.bz2 > tar xvfz if_ae-1214569185.tar.bz2 > cd if_ae > make > sudo kldload `pwd`/if_ae.ko > ifconfig ae0 >=20 > -- > Just after the last command the ae0 interface show up and give > ae0: flags=3D8802 metric 0 mtu 1500 > options=3D8 > ether 00:1e:8c:bc:9f:7a > media: Ethernet autoselect (100baseTX ) > status: active >=20 > /var/log/message contain : > Sep 17 09:55:55 eeebsd kernel: ae0: FastEthernet> mem 0xfbfc0000-0xfbffffff irq 17 at device 0.0 on pci3 > Sep 17 09:55:55 eeebsd kernel: ae0: pci device revision: 0xa0 > Sep 17 09:55:55 eeebsd kernel: ae0: chip id: 0x3 > Sep 17 09:55:55 eeebsd kernel: miibus0: on ae0 > Sep 17 09:55:55 eeebsd kernel: ukphy0: interface> PHY 0 on miibus0 > Sep 17 09:55:55 eeebsd kernel: ukphy0: 10baseT, 10baseT-FDX, > 100baseTX, 100baseTX-FDX, auto > Sep 17 09:55:55 eeebsd kernel: ae0: Ethernet address: 00:1e:8c:bc:9f:7a > Sep 17 09:55:55 eeebsd kernel: ae0: [FILTER] > Sep 17 09:55:56 eeebsd kernel: ae0: link state changed to DOWN > Sep 17 09:56:37 eeebsd kernel: ae0: link state changed to UP >=20 > But all test to use it freeze the system : > ifconfig ae0 up of dhclient ae0. >=20 > Tested on 8.0-CURRENT-200809 >=20 > Can I test anythink else ? >=20 > Thanks for your work ! >=20 Try the latest version from http://wiki.freebsd.org/AsusEee This problem was solved a bit ago. --=20 Stanislav Sedov ST4096-RIPE --Signature=_Wed__17_Sep_2008_14_53_11_+0400_Dmr68ujObsAZQd4e Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjQ4ZcACgkQK/VZk+smlYFoQACfZg71FhaEtxjHClQy3hH5bnVp +P0An2SoxsKLG7QZYqTcUxXpQUZ67Va4 =QGip -----END PGP SIGNATURE----- --Signature=_Wed__17_Sep_2008_14_53_11_+0400_Dmr68ujObsAZQd4e-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 15:00:07 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F6871065672 for ; Wed, 17 Sep 2008 15:00:07 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id 802D68FC1B for ; Wed, 17 Sep 2008 15:00:06 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so2011721fgb.35 for ; Wed, 17 Sep 2008 08:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:cc:x-mailer; bh=2mPukgjhEOUYB+K/usxgD/yKt36gVEo8eWPPHv3mglU=; b=nkKx95jAe6z2mAOGaucRXf5INlcpYZWb+DB6WfwwZzRQvqlN6qFvFhnw73ER/56df8 yBtZWP4z4CsNfIUVRNTvew2gyxmUipab8Q6HgWpMINl52mHhYTHGvHz+LHB/v3Fp0aZ8 5kpuTp3rLtnVXfr0Cumg/qbSXpWd4zPtYOYZI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:cc:x-mailer; b=RceG6O5e+g4LN0czcwVnt6BY6fYAbZsCffjQ/zOG17KLRwFIixhWqBbscwrVubuVO1 9rdZ21B5T2IXwZ3c9xerB4HBJ4wgMgC7xRHmzKWKpeRrTnffnH4H0TslQ+mtSZJP8M+l XlXzxE/9kQY3DciJLP7zD3UpDdBF+egd/vVJU= Received: by 10.180.215.9 with SMTP id n9mr1870158bkg.59.1221662347478; Wed, 17 Sep 2008 07:39:07 -0700 (PDT) Received: from ?192.168.0.11? ( [87.196.151.121]) by mx.google.com with ESMTPS id k29sm18452990fkk.2.2008.09.17.07.39.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Sep 2008 07:39:06 -0700 (PDT) References: Message-Id: <2E7DBE67-04CC-414A-87A7-AF8ED9C65C4D@gmail.com> From: Rui Paulo To: Ian Freislich In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPod Mail 5F137) Date: Wed, 17 Sep 2008 15:22:59 +0100 X-Mailer: iPod Mail (5F137) X-Mailman-Approved-At: Wed, 17 Sep 2008 15:27:41 +0000 Cc: "current@freebsd.org" Subject: Re: msk(4) issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 15:00:07 -0000 On 17 Sep 2008, at 09:16, "Ian Freislich" wrote: > Hi > > I'm having an issue with the msk hardware in my laptop. It stops > transmitting or recieving sometimes, always triggered by periods > of intense network load. > > Sep 16 18:39:31 apple kernel: msk0: watchdog timeout (missed Tx > interrupts) -- recovering > Sep 16 18:40:35 apple kernel: msk0: watchdog timeout (missed Tx > interrupts) -- recovering > Sep 16 18:41:41 apple kernel: msk0: watchdog timeout (missed Tx > interrupts) -- recovering > > But it never recovers. Try disabling MSI via the tunable. -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 16:09:18 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DA891065699 for ; Wed, 17 Sep 2008 16:09:18 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.177]) by mx1.freebsd.org (Postfix) with ESMTP id 3791D8FC24 for ; Wed, 17 Sep 2008 16:09:16 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: by ik-out-1112.google.com with SMTP id c29so2907869ika.3 for ; Wed, 17 Sep 2008 09:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=dyspLYAYKNrpn4SKCU76MWakMHmSc0VBBGKD+uZUbL4=; b=gB7L7+QYMXj7xcozBGSoatTjzMJm2cCvPY1OQV1wFv+yzW2lccVq7QT5BJhc3zKNR8 pdtG11RH0x9pF5xpiulOnFwMhOVN1Rwe/PDyeH5O8Ok1vDD1JCQPU9wOxCC+lLjbevyc zJuQYnP4POM3ACkeyxyyK7rBjDb/vN7OaJFH4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=tah3EA8WgwuBAF+7wjJhFBBYG051RxZoLxdVdTz35xHgTZjXDMK+cO5hZ/u6IdZ8rx Isqoz+QiYsGXYfk9jvccCtE9CRM8ryocLtVMtucnHa0SjKEsF02ZBLh3w5TdD3pgzw1U FiJqOzKsVNuFi1+z/dlHBJsmnEDTpfrlUL8vs= Received: by 10.210.62.12 with SMTP id k12mr3373035eba.15.1221666405209; Wed, 17 Sep 2008 08:46:45 -0700 (PDT) Received: by 10.210.34.13 with HTTP; Wed, 17 Sep 2008 08:46:44 -0700 (PDT) Message-ID: <1d6d20bc0809170846g69311401j7f93f97969756e43@mail.gmail.com> Date: Wed, 17 Sep 2008 23:46:44 +0800 From: "Jia-Shiun Li" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_9508_25063257.1221666405213" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Unable to boot Asus P5QL-EM w/ acpi enabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 16:09:18 -0000 ------=_Part_9508_25063257.1221666405213 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline The mainboard is an ASUS P5QL-EM (Intel G43/ICH10) with BIOS revision 0406. The kernel is loaded via firewire-enabled pxeboot. The kernel message showed that kernel hangs after attached acpi_hpet. At the moment firewire console would disconnect. If disable acpi then it boots fine. If booting with GENERIC kernel, it would hang even with acpi disabled, and the last message is "run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config" though there is no SCSI device onboard. According to my inaccurate memory, kernel version as of 2008/08/20 boots fine with acpi. dmesg, pciconf, acpidump and kernel config file attached. Regards, Jia-Shiun. ------=_Part_9508_25063257.1221666405213-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 19:00:34 2008 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 113B01065682 for ; Wed, 17 Sep 2008 19:00:34 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id C84CF8FC0C for ; Wed, 17 Sep 2008 19:00:33 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id m8HJ3b4M066454; Wed, 17 Sep 2008 15:03:37 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id m8HJ3aDq066453; Wed, 17 Sep 2008 15:03:36 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Wed, 17 Sep 2008 15:03:36 -0400 From: David Schultz To: Ian Freislich Message-ID: <20080917190336.GA66407@zim.MIT.EDU> Mail-Followup-To: Ian Freislich , current@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: current@FreeBSD.ORG Subject: Re: msk(4) issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 19:00:34 -0000 On Wed, Sep 17, 2008, Ian Freislich wrote: > Hi > > I'm having an issue with the msk hardware in my laptop. It stops > transmitting or recieving sometimes, always triggered by periods > of intense network load. > > Sep 16 18:39:31 apple kernel: msk0: watchdog timeout (missed Tx interrupts) -- recovering > Sep 16 18:40:35 apple kernel: msk0: watchdog timeout (missed Tx interrupts) -- recovering > Sep 16 18:41:41 apple kernel: msk0: watchdog timeout (missed Tx interrupts) -- recovering > > But it never recovers. I have the same problem. Disabling MSI reduces the frequency with which it occurs from once a day to once a month or so. You can recover the card without rebooting by loading the msk driver as a kld, then unloading and reloading it to reset the card. Of course this is a hack, but I haven't bothered to look into anything better yet. From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 19:05:13 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D52431065681; Wed, 17 Sep 2008 19:05:13 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from munchkin.clue.co.za (munchkin.clue.co.za [66.219.59.160]) by mx1.freebsd.org (Postfix) with ESMTP id 000768FC28; Wed, 17 Sep 2008 19:05:12 +0000 (UTC) (envelope-from ianf@clue.co.za) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=20070313; d=clue.co.za; h=Received:Received:Received:To:cc:From:Subject:In-Reply-To:References:X-Attribution:Date:Message-Id; b=ub4m8RvRmyNBP9+gyvsnvGCewmQjxy15w1ImfdssfKf7VAupIKoIRLPmJ1rjThpQWQN1/UXFRMEXtVpZOsETMSPYPw78MjdrYw8peAXgECMuoVVkecB0ADEuXH50lfLiCDYHKG+2hRyTNTRiTvD+Ooi0xcnhcAaqZ+hpEriSqIRFSZbVeCEpyCpfOA6bXZdcJ1THqz/f8DXdIq5CjZXFPNkAYHOGIT04yT+BoK51Rg+Cmvq29+5Mrprd6ddeisgP; Received: from uucp by munchkin.clue.co.za with local-rmail (Exim 4.67) (envelope-from ) id 1Kg2Kr-0005Q2-5D; Wed, 17 Sep 2008 19:05:09 +0000 Received: from dsl-241-65-41.telkomadsl.co.za ([41.241.65.41] helo=clue.co.za) by urchin.clue.co.za with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Kg2KO-0007i1-TH; Wed, 17 Sep 2008 19:04:41 +0000 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kg2KJ-0000Pa-R4; Wed, 17 Sep 2008 21:04:35 +0200 To: Kostik Belousov From: Ian FREISLICH In-Reply-To: <20080912130117.GJ39652@deviant.kiev.zoral.com.ua> References: <20080912130117.GJ39652@deviant.kiev.zoral.com.ua> <20080910104936.GR39652@deviant.kiev.zoral.com.ua> <20080826005920.8aca164b.nork@FreeBSD.org> <20080906080801.8099c753.nork@ninth-nine.com> <47655429@bb.ipt.ru> <20080907163909.e4ed4fab.nork@FreeBSD.org> <36888738@bb.ipt.ru> X-Attribution: BOFH Date: Wed, 17 Sep 2008 21:04:35 +0200 Message-Id: Cc: Boris Samorodov , freebsd-current@freebsd.org, Norikatsu Shigemura Subject: Re: Do you need x11-drivers/xf86-video-radeonhd-devel? (Re: How about AMD Puma platform support?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 19:05:14 -0000 Kostik Belousov wrote: > On Fri, Sep 12, 2008 at 02:46:39PM +0200, Ian FREISLICH wrote: > > Interesting, I have the same (card/chip) and same problem: > >=20 > > (--) PCI:*(2:0:0) ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)] re= > v 0, Mem @ 0xd0000000/27, 0xdfff0000/16, I/O @ 0xe800/8, BIOS @ 0xdffc0000/= > 17 > > (--) PCI: (2:0:1) ATI Technologies Inc RV370 [Radeon X300SE] rev 0, Mem @= > 0xdffe0000/16 > >=20 > > in my -STABLE box which is also plagued by these spurious freezes. > > They always happen when logging out or quitting the window manager. > > Yesterday the mouse pointer movd but very slowly. The Xorg process > > using 100% on one CPU and unkillable. In the past, it's locked up > > the machine entirely, but this time everything else was working. > > I still had to power cycle it to reboot though. > >=20 > > I'll try to get a ktrace next time it happens. > > This is quite similar to my problem. I expect your X server to spend time > in kernel. Please, use the procstat -k to get the kernel stack of the > process. [brane] ~ # procstat -k 1593 PID TID COMM TDNAME KSTACK 1593 100062 Xorg initial thread mi_switch ast Xfast_syscall [brane] ~ # procstat -k 1593 PID TID COMM TDNAME KSTACK 1593 100062 Xorg initial thread mi_switch turnstile_wait _mtx_lock_sleep giant_ioctl devfs_ioctl_f kern_ioctl ioctl syscall Xfast_syscall [brane] ~ # procstat -k 1593 PID TID COMM TDNAME KSTACK 1593 100062 Xorg initial thread mi_switch ast Xfast_syscall truss -p 1593 ioctl(8,0x20006444 { IO 0x64('d'), 68, 0 },0x0) ERR#16 'Device busy' ioctl(8,0x20006444 { IO 0x64('d'), 68, 0 },0x0) ERR#16 'Device busy' ioctl(8,0x20006444 { IO 0x64('d'), 68, 0 },0x0) ERR#16 'Device busy' ioctl(8,0x20006444 { IO 0x64('d'), 68, 0 },0x0) ERR#16 'Device busy' ioctl(8,0x20006444 { IO 0x64('d'), 68, 0 },0x0) ERR#16 'Device busy' ioctl(8,0x20006444 { IO 0x64('d'), 68, 0 },0x0) ERR#16 'Device busy' ioctl(8,0x20006444 { IO 0x64('d'), 68, 0 },0x0) ERR#16 'Device busy' And then, after killing it... [brane] ~ # kill -9 1593 [brane] ~ # truss -p 1593 truss: can not attach to target process: No such process Yet in top: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 1593 root 1 0 0 211M 35972K rdnrel 1 53:43 100.00% Xorg Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 19:59:59 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 213301065670; Wed, 17 Sep 2008 19:59:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id B39A28FC16; Wed, 17 Sep 2008 19:59:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Kg3Bs-00087X-S0; Wed, 17 Sep 2008 22:59:56 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m8HJxsTc092963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Sep 2008 22:59:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m8HJxsro034533; Wed, 17 Sep 2008 22:59:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id m8HJxrB2034531; Wed, 17 Sep 2008 22:59:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 17 Sep 2008 22:59:53 +0300 From: Kostik Belousov To: Ian FREISLICH Message-ID: <20080917195953.GH39652@deviant.kiev.zoral.com.ua> References: <20080912130117.GJ39652@deviant.kiev.zoral.com.ua> <20080910104936.GR39652@deviant.kiev.zoral.com.ua> <20080826005920.8aca164b.nork@FreeBSD.org> <20080906080801.8099c753.nork@ninth-nine.com> <47655429@bb.ipt.ru> <20080907163909.e4ed4fab.nork@FreeBSD.org> <36888738@bb.ipt.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kGqy73/z6kAbhglh" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1Kg3Bs-00087X-S0 1d7c29de2b20732a69d1a76758dbfb0c X-Terabit: YES Cc: Boris Samorodov , freebsd-current@freebsd.org, Norikatsu Shigemura Subject: Re: Do you need x11-drivers/xf86-video-radeonhd-devel? (Re: How about AMD Puma platform support?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 19:59:59 -0000 --kGqy73/z6kAbhglh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 17, 2008 at 09:04:35PM +0200, Ian FREISLICH wrote: > Kostik Belousov wrote: > > On Fri, Sep 12, 2008 at 02:46:39PM +0200, Ian FREISLICH wrote: > > > Interesting, I have the same (card/chip) and same problem: > > >=3D20 > > > (--) PCI:*(2:0:0) ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)= ] re=3D > > v 0, Mem @ 0xd0000000/27, 0xdfff0000/16, I/O @ 0xe800/8, BIOS @ 0xdffc0= 000/=3D > > 17 > > > (--) PCI: (2:0:1) ATI Technologies Inc RV370 [Radeon X300SE] rev 0, M= em @=3D > > 0xdffe0000/16 > > >=3D20 > > > in my -STABLE box which is also plagued by these spurious freezes. > > > They always happen when logging out or quitting the window manager. > > > Yesterday the mouse pointer movd but very slowly. The Xorg process > > > using 100% on one CPU and unkillable. In the past, it's locked up > > > the machine entirely, but this time everything else was working. > > > I still had to power cycle it to reboot though. > > >=3D20 > > > I'll try to get a ktrace next time it happens. > >=20 > > This is quite similar to my problem. I expect your X server to spend ti= me > > in kernel. Please, use the procstat -k to get the kernel stack of the > > process. >=20 > [brane] ~ # procstat -k 1593 > PID TID COMM TDNAME KSTACK = =20 > 1593 100062 Xorg initial thread mi_switch ast Xfast_syscal= l =20 > [brane] ~ # procstat -k 1593 > PID TID COMM TDNAME KSTACK = =20 > 1593 100062 Xorg initial thread mi_switch turnstile_wait _= mtx_lock_sleep giant_ioctl devfs_ioctl_f kern_ioctl ioctl syscall Xfast_sys= call=20 My backtrace is different. Anyway, as I was told, we should wait for 1.5 server and updated Mesa/libGL that could contain the fix. --kGqy73/z6kAbhglh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkjRYbgACgkQC3+MBN1Mb4j53QCeIvpOzr5U15Z9oBEe1q1p8z/D Ja0Ani0wmHZcXPO+aMNNHcp9Uuetlzui =pNhd -----END PGP SIGNATURE----- --kGqy73/z6kAbhglh-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 21:24:34 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56DA61065672 for ; Wed, 17 Sep 2008 21:24:34 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from cauchy.math.missouri.edu (cauchy.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id 2030E8FC13 for ; Wed, 17 Sep 2008 21:24:34 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from laptop3.gateway.2wire.net (cauchy.math.missouri.edu [128.206.184.213]) by cauchy.math.missouri.edu (8.14.2/8.14.2) with ESMTP id m8HLNddS004404; Wed, 17 Sep 2008 16:23:40 -0500 (CDT) (envelope-from stephen@math.missouri.edu) Message-ID: <48D17584.9020306@math.missouri.edu> Date: Wed, 17 Sep 2008 16:24:20 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.1.16) Gecko/20080909 SeaMonkey/1.1.11 MIME-Version: 1.0 To: Dan Nelson References: <48CDBC78.4010409@math.missouri.edu> <20080915195021.GA69528@cons.org> <48CEFF74.8020602@math.missouri.edu> <20080916033459.GA31220@troutmask.apl.washington.edu> <48CF2AEF.9070208@math.missouri.edu> <48CF2CA4.1000802@math.missouri.edu> <20080916041142.GH3188@dan.emsphone.com> In-Reply-To: <20080916041142.GH3188@dan.emsphone.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Martin Cracauer , freebsd-current@freebsd.org, Steve Kargl Subject: Re: Improved multiprocessor usage on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 21:24:34 -0000 Dan Nelson wrote: > In the last episode (Sep 15), Stephen Montgomery-Smith said: >> Stephen Montgomery-Smith wrote: >>> Steve Kargl wrote: >>>> On Mon, Sep 15, 2008 at 07:36:04PM -0500, Stephen Montgomery-Smith wrote: >>>>> ... and each thread is a loop of the form >>>>> >>>>> while (1) { >>>>> wait until told to start; >>>>> do massive amounts of floating point arithmetic (only additions and >>>>> multiplications) on large arrays; >>>>> tell the master process that you are done; >>>>> } >>>>> >>>>>> Do you have about as many threads as processor or more? >>>>> Both ways. The time difference between the two approaches is >>>>> negligible. >>>>> >>>> Are you using ULE? With my MPI applications, if the number of >>>> launched processes exceeds the number of cpus by 1, ULE falls >>>> through the floor. I have a nagging feeling that there is a problem >>>> with cpu affinity. >>>> >>>> http://lists.freebsd.org/pipermail/freebsd-current/2008-July/086917.html >> Let me say a little bit more. >> >> I have this gut feeling that the problem has a lot to do with cache >> management. My program has each thread doing, in effect, huge matrix >> multiplications, each one working on their own little bit. If a CPU >> core changes from one thread to another, it then has to flush out the >> cache to RAM, and read in a whole bunch of other RAM into cache. > > You can try playing with the new cpuset functions in HEAD and 7-STABLE > to lock particular threads on certain CPUs. > It was an excellent suggestion. But it didn't make any difference. From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 22:22:18 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37F49106566B for ; Wed, 17 Sep 2008 22:22:18 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from cauchy.math.missouri.edu (cauchy.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id E297F8FC1C for ; Wed, 17 Sep 2008 22:22:17 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from laptop3.gateway.2wire.net (cauchy.math.missouri.edu [128.206.184.213]) by cauchy.math.missouri.edu (8.14.2/8.14.2) with ESMTP id m8HMLZGc007168 for ; Wed, 17 Sep 2008 17:21:36 -0500 (CDT) (envelope-from stephen@math.missouri.edu) Message-ID: <48D18318.6060000@math.missouri.edu> Date: Wed, 17 Sep 2008 17:22:16 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.1.16) Gecko/20080909 SeaMonkey/1.1.11 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: man page for CPU_SET X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 22:22:18 -0000 On my system, there is no man page for CPU_SET(3) (advertised, for example, in cpuset(2)). Stephen From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 00:57:04 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D03E106564A for ; Thu, 18 Sep 2008 00:57:04 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by mx1.freebsd.org (Postfix) with ESMTP id 050888FC14 for ; Thu, 18 Sep 2008 00:57:03 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so4466461rvf.43 for ; Wed, 17 Sep 2008 17:57:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=FNfw79d8324pIgHJWkb0YdfEBTE3mlSZeb7Asidy6/8=; b=OWrW1LBQqeONVrUxhv+NfwqgYEwqQpCbGjJfSFH1t1pbU7Ck0cClU4kiclCicvSEY3 ouNWKMeEWAK/W2VTc1wUzMifdUCYL2P+QoYQahbpfPjGNFLZe8wtHHSk48lT7tGg9H25 ielCp3zZuR0ND3ls+hUUxoEm8JfwDHlrRuFrM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=FHNDZdrSjuQN4EWg69gpAAm99snflBZQkavHJktePs7l/oFkawj9bNOHsAh+r5gtjH kV9Bqv8euaIdQZUCc/SpYYhG3jHJ0g2o8e+eTi2/hY8b0FNdRxCAym6obfseWus80Gqq 1sD6GLzGsNN82MQGVQoFgc17OAdFKAks9ZT9A= Received: by 10.141.193.1 with SMTP id v1mr6959871rvp.245.1221699423691; Wed, 17 Sep 2008 17:57:03 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id k2sm28694434rvb.1.2008.09.17.17.57.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Sep 2008 17:57:02 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m8I0t2HB010728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Sep 2008 09:55:02 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m8I0t1ch010727; Thu, 18 Sep 2008 09:55:01 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 18 Sep 2008 09:55:01 +0900 From: Pyun YongHyeon To: David Schultz Message-ID: <20080918005501.GB10518@cdnetworks.co.kr> References: <20080917190336.GA66407@zim.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080917190336.GA66407@zim.MIT.EDU> User-Agent: Mutt/1.4.2.1i Cc: Ian Freislich , current@FreeBSD.ORG Subject: Re: msk(4) issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2008 00:57:04 -0000 On Wed, Sep 17, 2008 at 03:03:36PM -0400, David Schultz wrote: > On Wed, Sep 17, 2008, Ian Freislich wrote: > > Hi > > > > I'm having an issue with the msk hardware in my laptop. It stops > > transmitting or recieving sometimes, always triggered by periods > > of intense network load. > > > > Sep 16 18:39:31 apple kernel: msk0: watchdog timeout (missed Tx interrupts) -- recovering > > Sep 16 18:40:35 apple kernel: msk0: watchdog timeout (missed Tx interrupts) -- recovering > > Sep 16 18:41:41 apple kernel: msk0: watchdog timeout (missed Tx interrupts) -- recovering > > > > But it never recovers. > > I have the same problem. Disabling MSI reduces the frequency with > which it occurs from once a day to once a month or so. > Did it also happen after heavy network loads? If so I guess there is another bug in the hardware. Because the watchdog timeout indicated missing interrupts msk(4) didn't take actual hardware reset. If MSI work without problems it may indicate hardware is in stuck condition under heavy loads. I thought I fixed this kind of issue long ago as increasing FIFO threshold to flush received pause frames seemed to fixed the issue. I'll have to think again. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 01:08:38 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25DD8106566B for ; Thu, 18 Sep 2008 01:08:38 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by mx1.freebsd.org (Postfix) with ESMTP id E04078FC15 for ; Thu, 18 Sep 2008 01:08:32 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so4469985rvf.43 for ; Wed, 17 Sep 2008 18:08:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=RnNxKiHpNqkicLMiyzJ13ugDTOsKYNigQqg+pwOujJk=; b=IUOjbeb2klBUszikGAJicielDM+Nc/vhB6nHFIIaA6aNhm5xEiHBEKZU1cnTG3ZOHF SfSbmVIe1OG9SWm1SihIgaIVusPTgkBCaUyugE/OUuGEJBEBlTTmha7KvIRwFhD3Jfbd IqQVVfbfpj5VZfWnSEA8ilreKcF41jzweYrVA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=bWdtNQqW2WfGQWJ42G7FdQaCxg288PLHkO1piQehzRwr+nP6pSRGEmrbosCWaZbPtT 4tZgzU3wdLalRKiQmZUNnKozkWBiXNG4K8URxub0KBUimtKmd327jKiwQWmGNlBcOT5C JypXcw9YUYeXm/G7QcVlPJD3dOQEieSvD/ZbI= Received: by 10.140.201.8 with SMTP id y8mr6999634rvf.28.1221698574944; Wed, 17 Sep 2008 17:42:54 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id l31sm28713592rvb.2.2008.09.17.17.42.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Sep 2008 17:42:53 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m8I0eqlK010675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Sep 2008 09:40:52 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m8I0eqYq010674; Thu, 18 Sep 2008 09:40:52 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 18 Sep 2008 09:40:52 +0900 From: Pyun YongHyeon To: Stanislav Sedov Message-ID: <20080918004051.GA10518@cdnetworks.co.kr> References: <20080627163107.deccdd55.stas@FreeBSD.org> <4734a3ed0809170300y33ee44e0u684a5820a0f392ab@mail.gmail.com> <20080917145311.ff399006.stas@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080917145311.ff399006.stas@FreeBSD.org> User-Agent: Mutt/1.4.2.1i Cc: hpcharles@gmail.com, current@FreeBSD.org Subject: Re: Attansic L2 driver test request X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2008 01:08:38 -0000 On Wed, Sep 17, 2008 at 02:53:11PM +0400, Stanislav Sedov wrote: > On Wed, 17 Sep 2008 12:00:47 +0200 > "Henri-Pierre Charles" mentioned: > > > Hello, I just discover your messages, I tried to use FreeBSD on my eeepc. > > > > 7.0-release has to be patched for ath0 > > 8.0-CURRENT-200809 work out of the box > > > > On Fri, Jun 27, 2008 at 2:31 PM, Stanislav Sedov wrote: > > > For last weeks I was working on implementing an Attansic L2 > > > driver for FreeBSD that can be found on some of Asus motherboards > > > and Asus EeePC. I'm not sure if discrete adapters are available. > > > For the moment, I've implemented all the basic stuff, and the > > > drivers seems to perform stable enough. > > > http://www.SpringDaemons.com/stas/if_ae-1214569185.tar.bz2 > > > > I've tried your driver, but I'm not a specialist of device debug. > > So far I've tried : > > -- > > wget http://www.springdaemons.com/stas/if_ae-1214569185.tar.bz2 > > tar xvfz if_ae-1214569185.tar.bz2 > > cd if_ae > > make > > sudo kldload `pwd`/if_ae.ko > > ifconfig ae0 > > > > -- > > Just after the last command the ae0 interface show up and give > > ae0: flags=8802 metric 0 mtu 1500 > > options=8 > > ether 00:1e:8c:bc:9f:7a > > media: Ethernet autoselect (100baseTX ) > > status: active > > > > /var/log/message contain : > > Sep 17 09:55:55 eeebsd kernel: ae0: > FastEthernet> mem 0xfbfc0000-0xfbffffff irq 17 at device 0.0 on pci3 > > Sep 17 09:55:55 eeebsd kernel: ae0: pci device revision: 0xa0 > > Sep 17 09:55:55 eeebsd kernel: ae0: chip id: 0x3 > > Sep 17 09:55:55 eeebsd kernel: miibus0: on ae0 > > Sep 17 09:55:55 eeebsd kernel: ukphy0: > interface> PHY 0 on miibus0 > > Sep 17 09:55:55 eeebsd kernel: ukphy0: 10baseT, 10baseT-FDX, > > 100baseTX, 100baseTX-FDX, auto > > Sep 17 09:55:55 eeebsd kernel: ae0: Ethernet address: 00:1e:8c:bc:9f:7a > > Sep 17 09:55:55 eeebsd kernel: ae0: [FILTER] > > Sep 17 09:55:56 eeebsd kernel: ae0: link state changed to DOWN > > Sep 17 09:56:37 eeebsd kernel: ae0: link state changed to UP > > > > But all test to use it freeze the system : > > ifconfig ae0 up of dhclient ae0. > > > > Tested on 8.0-CURRENT-200809 > > > > Can I test anythink else ? > > > > Thanks for your work ! > > > > Try the latest version from > http://wiki.freebsd.org/AsusEee > The information for Atheros L1 FastEthernet in the URL looks incorrect. AFAIK the second generation of L1, also known as L1E, is PCIe *Gigabit* controller. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 05:38:46 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 027B51065678; Thu, 18 Sep 2008 05:38:46 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by mx1.freebsd.org (Postfix) with ESMTP id A50E78FC1C; Thu, 18 Sep 2008 05:38:45 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.3.58]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K7D00I53KXUJX30@mta-1.ms.rz.RWTH-Aachen.de>; Thu, 18 Sep 2008 07:08:18 +0200 (CEST) Received: from smarthost-1.ms.rz.rwth-aachen.de (HELO smarthost.rwth-aachen.de) ([134.130.7.89]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Thu, 18 Sep 2008 07:08:18 +0200 Received: from bigboss.hitnet.rwth-aachen.de (bigspace.hitnet.RWTH-Aachen.DE [137.226.181.2]) by smarthost.rwth-aachen.de (8.13.8+Sun/8.13.8/1) with ESMTP id m8I58IVg004288; Thu, 18 Sep 2008 07:08:18 +0200 (CEST) Received: from haakonia.hitnet.rwth-aachen.de ([137.226.181.92]) by bigboss.hitnet.rwth-aachen.de with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1KgBkY-00032b-Gd; Thu, 18 Sep 2008 07:08:18 +0200 Received: by haakonia.hitnet.rwth-aachen.de (Postfix, from userid 1001) id 550CE3F433; Thu, 18 Sep 2008 07:08:18 +0200 (CEST) Date: Thu, 18 Sep 2008 07:08:18 +0200 From: Christian Brueffer In-reply-to: <48D18318.6060000@math.missouri.edu> To: Stephen Montgomery-Smith Message-id: <20080918050818.GB1254@haakonia.hitnet.RWTH-Aachen.DE> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XF85m9dhOBO43t/C" Content-disposition: inline X-IronPort-AV: E=Sophos;i="4.32,419,1217800800"; d="scan'208";a="83558358" X-Operating-System: FreeBSD 6.4-PRERELEASE X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D References: <48D18318.6060000@math.missouri.edu> User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: man page for CPU_SET X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2008 05:38:46 -0000 --XF85m9dhOBO43t/C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 17, 2008 at 05:22:16PM -0500, Stephen Montgomery-Smith wrote: > On my system, there is no man page for CPU_SET(3) (advertised, for=20 > example, in cpuset(2)). >=20 You're right, though I could swear I reviewed the manpage back then. I've CCed Jeff, maybe he just forgot to commit it. - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --XF85m9dhOBO43t/C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFI0eJCbHYXjKDtmC0RAps+AJ420W7dD7CUI+NmMcUpfQ5b0HoiSgCg9s/b 49xHpPfsnzXsrBKnzzkqErA= =YyNT -----END PGP SIGNATURE----- --XF85m9dhOBO43t/C-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 07:13:52 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BB571065674 for ; Thu, 18 Sep 2008 07:13:52 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id B9F388FC17 for ; Thu, 18 Sep 2008 07:13:51 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [195.93.241.11] (port=64838 helo=lissyara.moskb.local) by hosting.lissyara.su with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KgDi1-0008xX-UO for freebsd-current@freebsd.org; Thu, 18 Sep 2008 11:13:50 +0400 Message-ID: <48D1FFAD.1010702@lissyara.su> Date: Thu, 18 Sep 2008 11:13:49 +0400 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.16) Gecko/20080903 Thunderbird/2.0.0.16 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: FreeBSD Current References: <48C6D4BD.3000302@lissyara.su> In-Reply-To: <48C6D4BD.3000302@lissyara.su> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Subject: Re: ad4 detached X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2008 07:13:52 -0000 Alex Keda пишет: > subj. > I update source and build kernel ~3 hour ago. > All OK > I again update source (I not remember, but changes 2-3 files) and > rebuild kernel > When starting network, very speed reboot. > I see only 'ad4 detached' > in loader - unload kernel and load kernel.old - boot OK... Yesterday, I update again. Again errors, but, I have messages and backtrace ======= first boot ========= Starting network: lo0. atapicam3: detached ad4: FAILURE - READ DMA status=51 error=0 Fatal trap 12: page fault while in kernel mode cpu id=1; apic id=01 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff80262d0c stack pointer = 0x10:0xfffffffe40039bb0 frame pointer = 0x10:0xfffffffe40039bf0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL0, pres 1, long 1, def 32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 3(g_up) [thread pid 3 tid 100010] stoped at ata_completed+0x68c: movzbl (%r9), %esi >db and laptop hangs... ====================================== second boot, single user mode - all OK, I run fsck, and type # exit (I`m not remember - mount or not root file system in 'rw' before go to multiuser mode) After >Starting network: lo0. box stay 2-3 minutes. I press power button, "Space" and "Enter" keys, and have: ACPI Error (evgpe-0848): no handler or method for GPE[1D], disabling event [20070320] ACPI Error (evgpe-0848): no handler or method for GPE[1D], disabling event [20070320] ath0: ath_chan_set:unable to reset channel 6 (2437 Mhz, flags 0x480 hal flags 0xc0), hal status 4294967295 atapicam3: detached subdisk4: detached ad4: detached atapicam2: detached Fatal trap9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x8:0xffffffff8024ae59 stack pointer = 0x10:0xfffffffe40065a50 frame pointer = 0x10:0xfffffffe40065a80 code segment = base 0x0, limit 0чаааааб type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (swi6: task queue) [thread pid 12 tid 100018 ] Stoped ad ata_sata_setmode+0x29: mozvl 0xa4(%rax), %eax db> Back trace: db> bt Tracing pid 12 tid 100018 id 0xffffff0002217a20 ata_sata_setmode() at ata_sata_setmode+0x29 ad_init() at ad_init+0x5a ad_reinit() at ad_reinit+0x3c ata_reinit() at ata_reinit+0x288 ata_completed() at ata_completed+0x75 taskqueue_run() at taskqueue_run+0x96 intr_event_execute_handlers() at intr_event_execute_handlers+0x68 ithread_loop() at ithread_loop+0xb2 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xfffffffe40065d40, rbp = 0 --- db> ================== attempt 3... I boot in single user mode, run fsck, mount root file systems and # mv kernel kernel.bad # mv kernel.old kernel # sync # sync # exit when laptop boot, I see: wlan0: Ethernet address: 00:19:7d:7b:72:82 starting wpa_supplicant. Starting Network: lo0 atapicam3: detached subdisk4: detached ad4: detached atapicam2: detached g_vfs_done():ad4s1a[READ(offset=26222493696, length=12288)]error = 6 vnode_pager_getpages: I/O read error eval: /usr/bin/id: Input/output error g_vfs_done():ad4s1a[READ(offset=25825181696, length=65536)]error = 6 vnode_pager_getpages: I/O read error eval: /sbin/devd: Input/output error g_vfs_done():ad4s1a[READ(offset=26200400064, length=16384)]error = 6 /etc/rc: WARNING: faled to start devd g_vfs_done():ad4s1a[READ(offset=25820741632, length=5632)]error = 6 vnode_pager_getpages: I/O read error /etc/rc.d/ipfw: kldload: Input/output error g_vfs_done():ad4s1a[READ(offset=26200408064, length=16384)]error = 6 /etc/rc: WARNING: Unable to load kernel module ipfw panic: vinvalbuf: dirty bufs cpuid = 0 KDB: enter: panic [thread pid 474 tid 100085] Stoped at kdb_enter+0x3d: movq $0,0x63ede8(%rip) db> I input "bt", and have: Tracing pid 474 tid 100085 td 0xffffff00027556c0 kdb_enter() at kdb_enter+0x3d panic() at panic+0x176 bufobj_invalbuf() at bufobj_invalbuf+0xcd vgonel() at vgonel+0xca vgone() at vgone+0x39 devfs_delete() at devfs_delete+0x196 devfs_populate_loop() at devfs_populate_loop+0x1a2 devfs_populate() at devfs_populate+0x3b devfs_lookup() at devfs_lookup+0x296 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x95 lookup() at lookup+0x4b2 namei() at namei+0x43f vn_open_cred() at vn_open_cred+0xb2 kern_openat() kern_openat+0x15e syscall() at syscall+0x1bf Xfast_syscall() at Xfast_syscall+0xab --- syscall (5, FreeBSD ELF64, open), rip = 0x8009999dc, rsp = 0x7fffffffdb28, rbp = 0x2 --- db> From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 08:00:52 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 682B6106566C; Thu, 18 Sep 2008 08:00:52 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id EC3028FC15; Thu, 18 Sep 2008 08:00:51 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p5DC5F32C.dip.t-dialin.net [93.197.243.44]) by redbull.bpaserver.net (Postfix) with ESMTP id 60A3C2E0BA; Thu, 18 Sep 2008 10:00:45 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id D64B6155C34; Thu, 18 Sep 2008 10:00:42 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.14.2/8.13.8/Submit) id m8I80g9o030277; Thu, 18 Sep 2008 10:00:42 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Thu, 18 Sep 2008 10:00:42 +0200 Message-ID: <20080918100042.58673tw6ihyqahs0@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Thu, 18 Sep 2008 10:00:42 +0200 From: "Alexander Leidinger" To: "Roman Divacky" References: <48CFB56D.3070908@moneybookers.com> <20080917111035.12175aklikhtltcs@webmail.leidinger.net> <48D0CB34.4020207@moneybookers.com> <20080917120006.13141ndfdhnpaczo@webmail.leidinger.net> <20080917101605.GA91263@freebsd.org> In-Reply-To: <20080917101605.GA91263@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.2) / FreeBSD-8.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 60A3C2E0BA.7013F X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, ORDB-RBL, SpamAssassin (not cached, score=-14.7, required 6, BAYES_00 -15.00, MR_NOT_ATTRIBUTED_IP 0.20, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org, Stefan Lambrev Subject: Re: PERC6/i/e cli X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2008 08:00:52 -0000 Quoting "Roman Divacky" (from Wed, 17 Sep 2008 =20 12:16:05 +0200): > On Wed, Sep 17, 2008 at 12:00:06PM +0200, Alexander Leidinger wrote: >> Quoting "Stefan Lambrev" (from Wed, >> 17 Sep 2008 12:17:40 +0300): >> >> > >> > >> >Alexander Leidinger wrote: >> >>Quoting "Stefan Lambrev" (from >> >>Tue, 16 Sep 2008 16:32:29 +0300): >> >> >> >>>Virtual Drive Information: >> >>>VD DRV RLP RLS RLQ STS SIZE STATE NAME >> >>>0 2 1 0 0 64kB 139392MB Optimal Ah and btw I >> >>>think it was mandatory to have compat.linux.osrelease=3D2.6.12 >> >>>(2.6.16 works too but you have to fix the script to not complain - >> >>>i think the port is still not fixed?) >> >> >> >>Not related to $Subject, but related to the linuxulator: Only use >> >>the default osrelease value or 2.6.16. Anything else may open >> >>pandoras box. >> >The port comes with a shell script/wrapper which require you to use >> >2.6.12. I think the maintainer promised to change it to >=3D 2.6.12 >> >I personally use 2.6.16 and fixed the wrapper by myself to work only >> >with this version. >> >The point of the maintainer is that if it works with 2.6.12, why we >> >should disable it? >> >For me it's enough to work with default 2.6.16 value, but someone >> >may want to experiment .. not that a small shell script will stop >> >them .. >> >> The linuxulator (kernel) will only switch to 2.6 mode with 2.6.16, >> with everything else it will stay in 2.4 mode. The linux >> infrastructure (ports) may decide to do their own stuff based upon the >> value of osversion. In the linux_base-fc6 this is the case for sure >> (libc and so on). The port you use may do the same. You've been >> warned... > > actually linuxulator checks if the "osrelease" string is at least 3 chars > long and if the 3rd char is "6" so "2.6.16" works exactly the same as > "9.6.IamAlittleBUTTERFLY".... Ups... sorry. It seems my memory fades away regarding this. Bye, Alexander. --=20 A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 11:01:59 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF6C11065678 for ; Thu, 18 Sep 2008 11:01:59 +0000 (UTC) (envelope-from akulatraxas@gmail.com) Received: from mail-gx0-f17.google.com (mail-gx0-f17.google.com [209.85.217.17]) by mx1.freebsd.org (Postfix) with ESMTP id 6728C8FC18 for ; Thu, 18 Sep 2008 11:01:59 +0000 (UTC) (envelope-from akulatraxas@gmail.com) Received: by gxk10 with SMTP id 10so28843413gxk.19 for ; Thu, 18 Sep 2008 04:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=dOFptUA+poLJT42C+sUEIngvxE2EApwKtBHDHQG0Kpo=; b=eCqTsBsjqFE9wOUzkGZ9E7fTHGOJcLZw3ctKYOE1RV7WO5wy08wPXOk2v6ilpZqqyf +N2z+szWpFo1nA/X3of2ZKjOLuhdG1zv2HB8pdDNbCszoWAWE+WP0I47mILnfd76u9nQ 8QyY3IxaBaqu2FeYmi2YFbKHlkjoVS88BgNrU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=QKyS7RJHzD7OT84LxFt7ldFT54HpYegTfmz1CwChgCesnSnS7Y0TWRoDHoqPxjM398 552cMKkqNny5e+BETYA3njQGLMH4+wGsEyMqxq2vqjUEH9g/dloSJT8Ytn09EDNBEJrZ kLPXpi3xbZG3kgVHGFGH8OCl4hM9RPPJ/SE08= Received: by 10.100.226.6 with SMTP id y6mr4961852ang.130.1221734451553; Thu, 18 Sep 2008 03:40:51 -0700 (PDT) Received: by 10.100.154.3 with HTTP; Thu, 18 Sep 2008 03:40:51 -0700 (PDT) Message-ID: <35e5bf980809180340x52a4cccdsc7fb7ebd9d2e676a@mail.gmail.com> Date: Thu, 18 Sep 2008 07:40:51 -0300 From: "Daniel de Oliveira" To: freebsd-current@freebsd.org In-Reply-To: <35e5bf980809180340j171e39ao3d6bf6732ff4c165@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <35e5bf980809180340j171e39ao3d6bf6732ff4c165@mail.gmail.com> Subject: Re: Current using -Os -pipe -march=pentium3m X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2008 11:01:59 -0000 Hi all I have some problems here trying to compile my system using.. CPUTYPE?=pentium3m CFLAGS=-Os -pipe When I take off the CFLAGS, all things works properly. A lot of errors in different points occurs (kernel and buildworld), so at this point I dont a have log, btw, when I comment CFLAGS lines, everything compiles fine. Just for information, is there something wrong with that? Daniel de Oliveira ---- Network and System Analyst Security Specialist IBM RISC Specialist IBM Storage Specialist Linux/Unix Specialist Linux User #: 405334 From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 11:10:40 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB3041065685 for ; Thu, 18 Sep 2008 11:10:40 +0000 (UTC) (envelope-from akulatraxas@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by mx1.freebsd.org (Postfix) with ESMTP id 8731E8FC1C for ; Thu, 18 Sep 2008 11:10:40 +0000 (UTC) (envelope-from akulatraxas@gmail.com) Received: by an-out-0708.google.com with SMTP id b33so355509ana.13 for ; Thu, 18 Sep 2008 04:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=dOFptUA+poLJT42C+sUEIngvxE2EApwKtBHDHQG0Kpo=; b=DjYQSZgGR4iIme+9dsCiAvgNCCA1cOQBPBCv3dUfxlQM4nYQ2EdcjdMB8EO9ncBlqz wL/ZgKnOX/7P/OZfubNx/R5u7KiGDtHNua+CcaKriVCFf6GFX5Rs1rGTbA86z8eXN7so FN3wT9OP4DrcRE2KyXk73AYoW2WG9BaMPHi8w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=t63+aMr5UC/yyuzwzUEyy3+Tqtpw5ash84SKMcKVMBKA2MNdwclGJDaxiXHyqRZowA jU/32pyLBZT6afzA3nrd+kS3piFxPQkcpli5QoCpxE93eZgByyXCRI/m5l1PYDaQLc1I emka7b45Do6B8UWiA9CbDwrExBna8eqlPFOtQ= Received: by 10.101.71.9 with SMTP id y9mr4946490ank.145.1221734402975; Thu, 18 Sep 2008 03:40:02 -0700 (PDT) Received: by 10.100.154.3 with HTTP; Thu, 18 Sep 2008 03:40:02 -0700 (PDT) Message-ID: <35e5bf980809180340j171e39ao3d6bf6732ff4c165@mail.gmail.com> Date: Thu, 18 Sep 2008 07:40:02 -0300 From: "Daniel de Oliveira" To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: Current using -Os -pipe -march=pentium3m X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2008 11:10:40 -0000 Hi all I have some problems here trying to compile my system using.. CPUTYPE?=pentium3m CFLAGS=-Os -pipe When I take off the CFLAGS, all things works properly. A lot of errors in different points occurs (kernel and buildworld), so at this point I dont a have log, btw, when I comment CFLAGS lines, everything compiles fine. Just for information, is there something wrong with that? Daniel de Oliveira ---- Network and System Analyst Security Specialist IBM RISC Specialist IBM Storage Specialist Linux/Unix Specialist Linux User #: 405334 From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 04:32:16 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5005A106566C for ; Thu, 18 Sep 2008 04:32:16 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id A09778FC08 for ; Thu, 18 Sep 2008 04:32:15 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so1410948eyi.7 for ; Wed, 17 Sep 2008 21:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:mime-version:content-type:content-transfer-encoding :message-id; bh=dlYIq+EXrMG8cBvTr0aTydmV/UDeKraGTuO1ybG6aTE=; b=l4V49vnPUOJe639cqcXdNshTksDAa1CHcFqzohCRyFs7hbUKmPRs5KzuYFbEXwj5NX 9hTrKX/h3C+Du6Mc5OZNAwe0HkggrZQcAipjYFAnmHOpHnEOqv3kldN14xzxEtM4AiTs Xdg1v2UqTFzs6/850XjK6A6etpmSQ5jtux9L8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:mime-version :content-type:content-transfer-encoding:message-id; b=WB3YGjhwqmXI5xcDmm8JLVeLtz+MpX0lufO9fxCAoTGkrJ9GXjFzvG5NjAj/hkDT5+ eq+jmersQGNNyfY4op19XK4XdMcPnQ/r/9ulkPcCG/o8HWgUVOLnXVH7loWKVp//fb75 OsB3IwZhkCMofiTf+7qwojSDhsB18egmb+1ck= Received: by 10.210.10.1 with SMTP id 1mr4315748ebj.23.1221712334402; Wed, 17 Sep 2008 21:32:14 -0700 (PDT) Received: from ?0.0.0.0? ( [196.34.241.123]) by mx.google.com with ESMTPS id q9sm6489347gve.5.2008.09.17.21.32.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Sep 2008 21:32:12 -0700 (PDT) From: David Naylor Organization: Private To: freebsd-current@freebsd.org Date: Thu, 18 Sep 2008 06:31:42 +0200 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1363582.xnixl2Qouk"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200809180631.47071.naylor.b.david@gmail.com> X-Mailman-Approved-At: Thu, 18 Sep 2008 11:27:36 +0000 Subject: FreeBSD deadlock (with fork?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2008 04:32:16 -0000 --nextPart1363582.xnixl2Qouk Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I have a program that spawns a lot of subprocesses (with pipes open) from=20 multiple threads. The problem is the program often deadlocks, but not=20 consistently. Sometimes the program can run over 5 times to competition=20 without incidence and yet othertimes it locks within a few seconds. =20 However if I limit the thread count to 1 the problem does not appear to be= =20 present. =20 Here are the logs from gdb: (gdb) info thread 5 Thread 7021c0 (LWP 100203) 0x00000008009a2e8c in _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 4 Thread a28480 (LWP 100174) 0x00000008009a2e8c in _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 3 Thread a61d80 (LWP 100175) 0x00000008009a2e8c in _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 2 Thread a61bc0 (LWP 100176) 0x00000008009a2e8c in _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 * 1 Thread a61840 (LWP 100177) 0x00000008009a2e8c in _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 (gdb) bt #0 0x00000008009a2e8c in _umtx_op_err ()=20 at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 #1 0x00000008009a1331 in cond_wait_common (cond=3DVariable "cond" is not=20 available. ) at /usr/src/lib/libthr/thread/thr_cond.c:204 #2 0x00000000004c0573 in PyThread_acquire_lock (lock=3D0x70a760, waitflag= =3D1) at=20 thread_pthread.h:452 #3 0x00000000004c38b0 in lock_PyThread_acquire_lock (self=3D0x83f258,=20 args=3DVariable "args" is not available. ) at ./Modules/threadmodule.c:46 #4 0x00000000004939e3 in PyEval_EvalFrameEx (f=3D0xa53920,=20 throwflag=3DVariable "throwflag" is not available. ) at Python/ceval.c:3679 #5 0x00000000004939a8 in PyEval_EvalFrameEx (f=3D0xb57420,=20 throwflag=3DVariable "throwflag" is not available. ) at Python/ceval.c:3765 #6 0x0000000000494ac1 in PyEval_EvalCodeEx (co=3D0x9aab70,=20 globals=3DVariable "globals" is not available. ) at Python/ceval.c:2942 #7 0x00000000004eb6bc in function_call (func=3D0x9d8938, arg=3D0x9d9990,=20 kw=3D0xa24da0) at Objects/funcobject.c:524 #8 0x0000000000417add in PyObject_Call (func=3D0x9d8938, arg=3D0x9d9990,=20 kw=3D0xa24da0) at Objects/abstract.c:2487 #9 0x000000000048f730 in PyEval_EvalFrameEx (f=3D0xb48e20,=20 throwflag=3DVariable "throwflag" is not available. ) at Python/ceval.c:3978 #10 0x00000000004939a8 in PyEval_EvalFrameEx (f=3D0xb57720,=20 throwflag=3DVariable "throwflag" is not available. ) at Python/ceval.c:3765 #11 0x00000000004939a8 in PyEval_EvalFrameEx (f=3D0xb49020,=20 throwflag=3DVariable "throwflag" is not available. ) at Python/ceval.c:3765 #12 0x0000000000494ac1 in PyEval_EvalCodeEx (co=3D0x947cd8,=20 globals=3DVariable "globals" is not available. ) at Python/ceval.c:2942 #13 0x00000000004eb5bd in function_call (func=3D0x9a5320, arg=3D0x9d9950, k= w=3D0x0)=20 at Objects/funcobject.c:524 #14 0x0000000000417add in PyObject_Call (func=3D0x9a5320, arg=3D0x9d9950, k= w=3D0x0)=20 at Objects/abstract.c:2487 #15 0x000000000041f12f in instancemethod_call (func=3D0x9a5320, arg=3D0x9d9= 950,=20 kw=3D0x0) at Objects/classobject.c:2558 #16 0x0000000000417add in PyObject_Call (func=3D0x93b410, arg=3D0x718050, k= w=3D0x0)=20 at Objects/abstract.c:2487 #17 0x000000000048d4c6 in PyEval_CallObjectWithKeywords (func=3D0x93b410,=20 arg=3D0x718050, kw=3D0x0) at Python/ceval.c:3548 #18 0x00000000004c3cbd in t_bootstrap (boot_raw=3D0x70ae60)=20 at ./Modules/threadmodule.c:425 #19 0x000000080099ac11 in thread_start (curthread=3D0xa61840)=20 at /usr/src/lib/libthr/thread/thr_create.c:288 #20 0x0000000000000000 in ?? () Error accessing memory address 0x7fffff5fc000: Bad address. (gdb) thr 2 [Switching to thread 2 (Thread a61bc0 (LWP 100176))]#0 0x00000008009a2e8c = in=20 _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 37 RSYSCALL_ERR(_umtx_op) (gdb) bt #0 0x00000008009a2e8c in _umtx_op_err ()=20 at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 #1 0x00000008009a1331 in cond_wait_common (cond=3DVariable "cond" is not=20 available. ) at /usr/src/lib/libthr/thread/thr_cond.c:204 #2 0x00000000004c0573 in PyThread_acquire_lock (lock=3D0x70a600, waitflag= =3D1) at=20 thread_pthread.h:452 #3 0x00000000004c38b0 in lock_PyThread_acquire_lock (self=3D0x83f168,=20 args=3DVariable "args" is not available. ) at ./Modules/threadmodule.c:46 #4 0x00000000004939e3 in PyEval_EvalFrameEx (f=3D0xb56520,=20 throwflag=3DVariable "throwflag" is not available. ) at Python/ceval.c:3679 #5 0x0000000000494ac1 in PyEval_EvalCodeEx (co=3D0x8d5dc8,=20 globals=3DVariable "globals" is not available. ) at Python/ceval.c:2942 #6 0x0000000000492c88 in PyEval_EvalFrameEx (f=3D0xb2de20,=20 throwflag=3DVariable "throwflag" is not available. ) at Python/ceval.c:3775 #7 0x0000000000494ac1 in PyEval_EvalCodeEx (co=3D0x8d5288,=20 globals=3DVariable "globals" is not available. ) at Python/ceval.c:2942 #8 0x00000000004eb5bd in function_call (func=3D0x9a8b18, arg=3D0xc524d0, k= w=3D0x0)=20 at Objects/funcobject.c:524 #9 0x0000000000417add in PyObject_Call (func=3D0x9a8b18, arg=3D0xc524d0, k= w=3D0x0)=20 at Objects/abstract.c:2487 #10 0x000000000041f12f in instancemethod_call (func=3D0x9a8b18, arg=3D0xc52= 4d0,=20 kw=3D0x0) at Objects/classobject.c:2558 #11 0x0000000000417add in PyObject_Call (func=3D0x93b370, arg=3D0x10331d0, = kw=3D0x0)=20 at Objects/abstract.c:2487 #12 0x0000000000464158 in slot_tp_init (self=3DVariable "self" is not avail= able. ) at Objects/typeobject.c:5532 #13 0x0000000000461561 in type_call (type=3D0x7d9420, args=3D0x10331d0, kwd= s=3D0x0)=20 at Objects/typeobject.c:700 #14 0x0000000000417add in PyObject_Call (func=3D0x7d9420, arg=3D0x10331d0, = kw=3D0x0)=20 at Objects/abstract.c:2487 #15 0x00000000004906f9 in PyEval_EvalFrameEx (f=3D0xb3a120,=20 throwflag=3DVariable "throwflag" is not available. ) at Python/ceval.c:3890 #16 0x0000000000494ac1 in PyEval_EvalCodeEx (co=3D0x8d5eb8,=20 globals=3DVariable "globals" is not available. ) at Python/ceval.c:2942 #17 0x0000000000492c88 in PyEval_EvalFrameEx (f=3D0xa47a20,=20 throwflag=3DVariable "throwflag" is not available. ) at Python/ceval.c:3775 #18 0x0000000000494ac1 in PyEval_EvalCodeEx (co=3D0x8d5cd8,=20 globals=3DVariable "globals" is not available. ) at Python/ceval.c:2942 #19 0x0000000000492c88 in PyEval_EvalFrameEx (f=3D0xb3a420,=20 throwflag=3DVariable "throwflag" is not available. ) at Python/ceval.c:3775 #20 0x0000000000494ac1 in PyEval_EvalCodeEx (co=3D0x9aabe8,=20 globals=3DVariable "globals" is not available. ) at Python/ceval.c:2942 #21 0x0000000000492c88 in PyEval_EvalFrameEx (f=3D0xb3a720,=20 throwflag=3DVariable "throwflag" is not available. ) at Python/ceval.c:3775 #22 0x0000000000494ac1 in PyEval_EvalCodeEx (co=3D0x9aab70,=20 globals=3DVariable "globals" is not available. ) at Python/ceval.c:2942 #23 0x00000000004eb6bc in function_call (func=3D0x9d8938, arg=3D0x9d98d0,=20 kw=3D0xa5a660) at Objects/funcobject.c:524 #24 0x0000000000417add in PyObject_Call (func=3D0x9d8938, arg=3D0x9d98d0,=20 kw=3D0xa5a660) at Objects/abstract.c:2487 #25 0x000000000048f730 in PyEval_EvalFrameEx (f=3D0xb2e020,=20 throwflag=3DVariable "throwflag" is not available. ) at Python/ceval.c:3978 =2D--Type to continue, or q to quit--- #26 0x00000000004939a8 in PyEval_EvalFrameEx (f=3D0xb3aa20,=20 throwflag=3DVariable "throwflag" is not available. ) at Python/ceval.c:3765 #27 0x00000000004939a8 in PyEval_EvalFrameEx (f=3D0xb2e220,=20 throwflag=3DVariable "throwflag" is not available. ) at Python/ceval.c:3765 #28 0x0000000000494ac1 in PyEval_EvalCodeEx (co=3D0x947cd8,=20 globals=3DVariable "globals" is not available. ) at Python/ceval.c:2942 #29 0x00000000004eb5bd in function_call (func=3D0x9a5320, arg=3D0x9d9890, k= w=3D0x0)=20 at Objects/funcobject.c:524 #30 0x0000000000417add in PyObject_Call (func=3D0x9a5320, arg=3D0x9d9890, k= w=3D0x0)=20 at Objects/abstract.c:2487 #31 0x000000000041f12f in instancemethod_call (func=3D0x9a5320, arg=3D0x9d9= 890,=20 kw=3D0x0) at Objects/classobject.c:2558 #32 0x0000000000417add in PyObject_Call (func=3D0x93b320, arg=3D0x718050, k= w=3D0x0)=20 at Objects/abstract.c:2487 #33 0x000000000048d4c6 in PyEval_CallObjectWithKeywords (func=3D0x93b320,=20 arg=3D0x718050, kw=3D0x0) at Python/ceval.c:3548 #34 0x00000000004c3cbd in t_bootstrap (boot_raw=3D0x70aee0)=20 at ./Modules/threadmodule.c:425 #35 0x000000080099ac11 in thread_start (curthread=3D0xa61bc0)=20 at /usr/src/lib/libthr/thread/thr_create.c:288 #36 0x0000000000000000 in ?? () Error accessing memory address 0x7fffff7fd000: Bad address. Apologies about the long backtraces [and thus the long message]. =20 Thanks David --nextPart1363582.xnixl2Qouk Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBI0dmzUaaFgP9pFrIRAtZLAJ4u93H8lRRBnKFoovdY0xwKkJlAqQCdHCar sKPisc2z5tIDPocnk1hVtug= =lED7 -----END PGP SIGNATURE----- --nextPart1363582.xnixl2Qouk-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 11:59:25 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABB71106566C for ; Thu, 18 Sep 2008 11:59:25 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout3.freenet.de (mout3.freenet.de [IPv6:2001:748:100:40::2:5]) by mx1.freebsd.org (Postfix) with ESMTP id 455268FC21 for ; Thu, 18 Sep 2008 11:59:25 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.18] (helo=8.mx.freenet.de) by mout3.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #65) id 1KgIAN-00088F-VO; Thu, 18 Sep 2008 13:59:23 +0200 Received: from r9431.r.pppool.de ([89.54.148.49]:32435 helo=peedub.jennejohn.org) by 8.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #65) id 1KgIAN-00021p-Nv; Thu, 18 Sep 2008 13:59:23 +0200 Date: Thu, 18 Sep 2008 13:59:23 +0200 From: Gary Jennejohn To: "Daniel de Oliveira" Message-ID: <20080918135923.784ca646@peedub.jennejohn.org> In-Reply-To: <35e5bf980809180340x52a4cccdsc7fb7ebd9d2e676a@mail.gmail.com> References: <35e5bf980809180340j171e39ao3d6bf6732ff4c165@mail.gmail.com> <35e5bf980809180340x52a4cccdsc7fb7ebd9d2e676a@mail.gmail.com> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.10.14; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Current using -Os -pipe -march=pentium3m X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2008 11:59:25 -0000 On Thu, 18 Sep 2008 07:40:51 -0300 "Daniel de Oliveira" wrote: > Hi all > > I have some problems here trying to compile my system using.. > > CPUTYPE?=pentium3m > CFLAGS=-Os -pipe > > When I take off the CFLAGS, all things works properly. A lot of errors > in different points occurs (kernel and buildworld), so at this point I > dont a have log, btw, when I comment CFLAGS lines, everything compiles > fine. Just for information, is there something wrong with that? > It's generally recommended not to play around with the CFLAGS settings for buildworld/buildkernel. The defaults have been chosen for a good reason - they work. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 12:16:25 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6A3E106564A for ; Thu, 18 Sep 2008 12:16:25 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7EEFF8FC15 for ; Thu, 18 Sep 2008 12:16:25 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KgIQq-0001Z8-Dx for freebsd-current@freebsd.org; Thu, 18 Sep 2008 12:16:24 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 18 Sep 2008 12:16:24 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 18 Sep 2008 12:16:24 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Thu, 18 Sep 2008 14:16:20 +0200 Lines: 46 Message-ID: References: <200809180631.47071.naylor.b.david@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig48D70C6DD19EC560AD67CCD2" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.16 (X11/20080724) In-Reply-To: <200809180631.47071.naylor.b.david@gmail.com> X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: FreeBSD deadlock (with fork?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2008 12:16:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig48D70C6DD19EC560AD67CCD2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable David Naylor wrote: > Hi, >=20 > I have a program that spawns a lot of subprocesses (with pipes open) fr= om=20 > multiple threads. The problem is the program often deadlocks, but not = > consistently. Sometimes the program can run over 5 times to competitio= n=20 > without incidence and yet othertimes it locks within a few seconds. =20 >=20 > However if I limit the thread count to 1 the problem does not appear to= be=20 > present. =20 >=20 > Here are the logs from gdb: =2E.. Are you sure it's not a design error in your program? Your best bet for solving this problem is to try to create a minimum program that will fail and post it here (don't post your whole program, it's probably too big). --------------enig48D70C6DD19EC560AD67CCD2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI0kaVldnAQVacBcgRAhJ2AJ9P5yIB7sHV8iYJVYtxiCiMzC3xUACgwzNI C5/VftEOnTGxSEjoy6XlHl8= =msOA -----END PGP SIGNATURE----- --------------enig48D70C6DD19EC560AD67CCD2-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 12:40:10 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA5591065670 for ; Thu, 18 Sep 2008 12:40:10 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 57E358FC1E for ; Thu, 18 Sep 2008 12:40:10 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id m8ICe8ll040953; Thu, 18 Sep 2008 14:40:08 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id m8ICe8h3040952; Thu, 18 Sep 2008 14:40:08 +0200 (CEST) (envelope-from olli) Date: Thu, 18 Sep 2008 14:40:08 +0200 (CEST) Message-Id: <200809181240.m8ICe8h3040952@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, akulatraxas@gmail.com In-Reply-To: <35e5bf980809180340j171e39ao3d6bf6732ff4c165@mail.gmail.com> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 18 Sep 2008 14:40:09 +0200 (CEST) Cc: Subject: Re: Current using -Os -pipe -march=pentium3m X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, akulatraxas@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2008 12:40:10 -0000 Daniel de Oliveira wrote: > I have some problems here trying to compile my system using.. > > CPUTYPE?=pentium3m > CFLAGS=-Os -pipe Does it make a difference when you add "-fno-strict-aliasing"? Note that the default is "-O2 -fno-strict-aliasing -pipe", and you shouldn't override that unless you have a good reason to do that. Specifically, using any optimization beyond -O1 (including -Os) without -fno-strict-aliasing is not supported; it's known to break some ports at least. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mn- chen, HRB 125758, Geschftsfhrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd $ dd if=/dev/urandom of=test.pl count=1 $ file test.pl test.pl: perl script text executable From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 12:51:11 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E5CA1065677 for ; Thu, 18 Sep 2008 12:51:11 +0000 (UTC) (envelope-from akulatraxas@gmail.com) Received: from mail-gx0-f17.google.com (mail-gx0-f17.google.com [209.85.217.17]) by mx1.freebsd.org (Postfix) with ESMTP id 104FE8FC19 for ; Thu, 18 Sep 2008 12:51:10 +0000 (UTC) (envelope-from akulatraxas@gmail.com) Received: by gxk10 with SMTP id 10so28932906gxk.19 for ; Thu, 18 Sep 2008 05:51:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=O6jkELb4tnkfteaO2zL9WnNDzFNQmDN20oNpGQh1toE=; b=qzqNjhfLiyCBgNFasSAiYfY/e2Syr5jLKHHzu6cCnpe/7zsdewJ9uKQHV9S2kH6uzu ji/BeIyH6G5DJbdt5nm0v4OMlQWNzoHd/Qv+J1NQ8ga4XfbxekZo+OFMAGjDObU4iNTw ubnPKpnHPUJ6iOZxA8eQS/BmChD3/DuhP8RPg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=rn/CfqCtUCxWqWBKpkJKvVHlXlau9O2ZG5UPjUcAgWTCbVRL74VJBGNmWXGxUOZTAN U/OXPWTA2DT1sG2O1bHaUd1gAt0r533lrGF+/SoQk177qBvNzJNI5klTEAMZBruZBq5Q C/ukxii6bCqG2dUaBLfYxdUnDpT88MdDQMCpc= Received: by 10.100.198.13 with SMTP id v13mr5186287anf.107.1221742270025; Thu, 18 Sep 2008 05:51:10 -0700 (PDT) Received: by 10.100.154.3 with HTTP; Thu, 18 Sep 2008 05:51:09 -0700 (PDT) Message-ID: <35e5bf980809180551o2d845346k4f07f0e298bc027@mail.gmail.com> Date: Thu, 18 Sep 2008 09:51:09 -0300 From: "Daniel de Oliveira" To: freebsd-current@freebsd.org, akulatraxas@gmail.com In-Reply-To: <200809181240.m8ICe8h3040952@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <35e5bf980809180340j171e39ao3d6bf6732ff4c165@mail.gmail.com> <200809181240.m8ICe8h3040952@lurza.secnetix.de> Cc: Subject: Re: Current using -Os -pipe -march=pentium3m X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2008 12:51:11 -0000 Thanks Olivera, I'll try this later. Daniel de Oliveira ---- Network and System Analyst Security Specialist IBM RISC Specialist IBM Storage Specialist Linux/Unix Specialist Linux User #: 405334 On Thu, Sep 18, 2008 at 09:40, Oliver Fromme wrote= : > Daniel de Oliveira wrote: > > I have some problems here trying to compile my system using.. > > > > CPUTYPE?=3Dpentium3m > > CFLAGS=3D-Os -pipe > > Does it make a difference when you add "-fno-strict-aliasing"? > > Note that the default is "-O2 -fno-strict-aliasing -pipe", > and you shouldn't override that unless you have a good > reason to do that. Specifically, using any optimization > beyond -O1 (including -Os) without -fno-strict-aliasing is > not supported; it's known to break some ports at least. > > Best regards > Oliver > > -- > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. > Handelsregister: Registergericht Muenchen, HRA 74606, Gesch=E4ftsfuehrun= g: > secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M=FC= n- > chen, HRB 125758, Gesch=E4ftsf=FChrer: Maik Bachmann, Olaf Erb, Ralf Geb= hart > > FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd > > $ dd if=3D/dev/urandom of=3Dtest.pl count=3D1 > $ file test.pl > test.pl: perl script text executable > From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 12:52:12 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D517D1065676 for ; Thu, 18 Sep 2008 12:52:12 +0000 (UTC) (envelope-from akulatraxas@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.226]) by mx1.freebsd.org (Postfix) with ESMTP id 8BFA78FC1F for ; Thu, 18 Sep 2008 12:52:12 +0000 (UTC) (envelope-from akulatraxas@gmail.com) Received: by wr-out-0506.google.com with SMTP id c8so609039wra.27 for ; Thu, 18 Sep 2008 05:52:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=tRXBLDQCO/dtT1bd/cgD9TcJJy0lcjzpa0a0UEzBuQM=; b=LuSrqxBvgo52aLkPtzb6UePsRnPCqEhIH+GFVnUh50ZoFCuKuOalENu4VFHkVMpcuq E8DGVkCfjrsZdiHjqUphkvKivB8IO1PBcrDS5cdrKnQf8LFUoXbiL4+EMYcdOe8D5JzF ZCp1zxtelY3tIqccmiAaUnGLKmovTfC1Me4y0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=lxr6INwoWdjm1YiIYk6k4e7B2pQT+Yv7C190ihhxOjlgpxwm5/5CyAjA6Wu25Az41J I9RgSAJFtFipKZgUNHn+KRfhhsx4OAwYCe7QpPfMQhM+hmIl8qrOgGxFFpcPKHmyDyzl nL63n/JjxedVxgi7uVnzzdCUJ32sDhMLl9WA8= Received: by 10.100.173.9 with SMTP id v9mr5198360ane.82.1221742331497; Thu, 18 Sep 2008 05:52:11 -0700 (PDT) Received: by 10.100.154.3 with HTTP; Thu, 18 Sep 2008 05:52:11 -0700 (PDT) Message-ID: <35e5bf980809180552l2f9dc1bheb90635094287afb@mail.gmail.com> Date: Thu, 18 Sep 2008 09:52:11 -0300 From: "Daniel de Oliveira" To: freebsd-current@freebsd.org, akulatraxas@gmail.com In-Reply-To: <35e5bf980809180551o2d845346k4f07f0e298bc027@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <35e5bf980809180340j171e39ao3d6bf6732ff4c165@mail.gmail.com> <200809181240.m8ICe8h3040952@lurza.secnetix.de> <35e5bf980809180551o2d845346k4f07f0e298bc027@mail.gmail.com> Cc: Subject: Re: Current using -Os -pipe -march=pentium3m X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2008 12:52:12 -0000 OPs.. sorry.. Oliver Daniel de Oliveira ---- Network and System Analyst Security Specialist IBM RISC Specialist IBM Storage Specialist Linux/Unix Specialist Linux User #: 405334 On Thu, Sep 18, 2008 at 09:51, Daniel de Oliveira w= rote: > Thanks Olivera, I'll try this later. > > Daniel de Oliveira > ---- > Network and System Analyst > Security Specialist > IBM RISC Specialist > IBM Storage Specialist > Linux/Unix Specialist > Linux User #: 405334 > > > > On Thu, Sep 18, 2008 at 09:40, Oliver Fromme wro= te: >> Daniel de Oliveira wrote: >> > I have some problems here trying to compile my system using.. >> > >> > CPUTYPE?=3Dpentium3m >> > CFLAGS=3D-Os -pipe >> >> Does it make a difference when you add "-fno-strict-aliasing"? >> >> Note that the default is "-O2 -fno-strict-aliasing -pipe", >> and you shouldn't override that unless you have a good >> reason to do that. Specifically, using any optimization >> beyond -O1 (including -Os) without -fno-strict-aliasing is >> not supported; it's known to break some ports at least. >> >> Best regards >> Oliver >> >> -- >> Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M= . >> Handelsregister: Registergericht Muenchen, HRA 74606, Gesch=E4ftsfuehru= ng: >> secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M= =FCn- >> chen, HRB 125758, Gesch=E4ftsf=FChrer: Maik Bachmann, Olaf Erb, Ralf Ge= bhart >> >> FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bs= d >> >> $ dd if=3D/dev/urandom of=3Dtest.pl count=3D1 >> $ file test.pl >> test.pl: perl script text executable >> > From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 14:02:23 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23DB9106566C for ; Thu, 18 Sep 2008 14:02:23 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id A2FCC8FC20 for ; Thu, 18 Sep 2008 14:02:22 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: by ey-out-2122.google.com with SMTP id 6so1480112eyi.7 for ; Thu, 18 Sep 2008 07:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer; bh=kkd/piepp2sZYUW2DzI775zBANPYY1dbLu8PTtFmvLI=; b=rVbF2r+3VqwxRl/GBBhmJVPrPLyWI7dT33YtxAZWV9aNGfJnNw89FBagySa0pbEcQU lB+feMO6bVqa1uSyj1lObwi2ewj83G4hRCQLISfwxG3gFhdjloVFnI4FpGIfbFWsLLNR f+dyIQID2YxDXrZdWVjiBN3tZ0OksK4R+KrPU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer; b=ppLIpZKBQ/sbyT31yayq8ciD19GvlPX9LRteQOdCVJUjNYj0zyRAM6ZPDMAatn7fi+ vOXqX3yo8sJYGrBiwVLxzwrIKUTXM2YmxMZoHK/MYeKHbHRM/81x0QhqpybQvyDawerk U7hEbgn5fI5G8T3k/Spc/4ujMs0Pgb27SkejQ= Received: by 10.210.117.1 with SMTP id p1mr4964335ebc.84.1221744846674; Thu, 18 Sep 2008 06:34:06 -0700 (PDT) Received: from ?127.0.0.1? ( [217.206.187.80]) by mx.google.com with ESMTPS id g9sm7747394gvc.0.2008.09.18.06.34.04 (version=SSLv3 cipher=RC4-MD5); Thu, 18 Sep 2008 06:34:05 -0700 (PDT) From: Tom Evans To: David Naylor In-Reply-To: <200809180631.47071.naylor.b.david@gmail.com> References: <200809180631.47071.naylor.b.david@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-HzK5RTmMxvFERkURJjKR" Date: Thu, 18 Sep 2008 14:33:52 +0100 Message-Id: <1221744832.68732.4.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD deadlock (with fork?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2008 14:02:23 -0000 --=-HzK5RTmMxvFERkURJjKR Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2008-09-18 at 06:31 +0200, David Naylor wrote: > Hi, >=20 > I have a program that spawns a lot of subprocesses (with pipes open) from= =20 > multiple threads. The problem is the program often deadlocks, but not=20 > consistently. Sometimes the program can run over 5 times to competition=20 > without incidence and yet othertimes it locks within a few seconds. =20 >=20 Do you create threads, which then fork(), or do you fork() and then create = threads?=20 I think the former will not work.. Cheers Tom --=-HzK5RTmMxvFERkURJjKR Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkjSWLwACgkQlcRvFfyds/fmIgCfUQh21NO2FqkmGylH2syswyC5 IcgAn0ubHjnroSlQ9UEjGwt7OZydFys0 =7XeH -----END PGP SIGNATURE----- --=-HzK5RTmMxvFERkURJjKR-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 16:50:07 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 948D91065672 for ; Thu, 18 Sep 2008 16:50:07 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from smtp.ht-systems.ru (mr0.ht-systems.ru [78.110.50.55]) by mx1.freebsd.org (Postfix) with ESMTP id 46DDC8FC12 for ; Thu, 18 Sep 2008 16:50:07 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from [85.21.245.235] (helo=orion.SpringDaemons.com) by smtp.ht-systems.ru with esmtpa (Exim 4.62) (envelope-from ) id 1KgMKJ-0004cd-UQ; Thu, 18 Sep 2008 20:25:56 +0400 Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id 9196439830; Thu, 18 Sep 2008 20:25:54 +0400 (MSD) Date: Thu, 18 Sep 2008 20:25:49 +0400 From: Stanislav Sedov To: pyunyh@gmail.com Message-Id: <20080918202549.4391c94f.stas@FreeBSD.org> In-Reply-To: <20080918004051.GA10518@cdnetworks.co.kr> References: <20080627163107.deccdd55.stas@FreeBSD.org> <4734a3ed0809170300y33ee44e0u684a5820a0f392ab@mail.gmail.com> <20080917145311.ff399006.stas@FreeBSD.org> <20080918004051.GA10518@cdnetworks.co.kr> Organization: The FreeBSD Project X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Thu__18_Sep_2008_20_25_49_+0400_QzZxySR_Z9.121Hu" Cc: hpcharles@gmail.com, current@FreeBSD.org Subject: Re: Attansic L2 driver test request X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2008 16:50:07 -0000 --Signature=_Thu__18_Sep_2008_20_25_49_+0400_QzZxySR_Z9.121Hu Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 18 Sep 2008 09:40:52 +0900 Pyun YongHyeon mentioned: >=20 > The information for Atheros L1 FastEthernet in the URL looks > incorrect. AFAIK the second generation of L1, also known as L1E, > is PCIe *Gigabit* controller.=20 >=20 Yeah, I was wondering as well how there come that L1 is FastEthernet... But I've decided not to fix that as I don't own one. --=20 Stanislav Sedov ST4096-RIPE --Signature=_Thu__18_Sep_2008_20_25_49_+0400_QzZxySR_Z9.121Hu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjSgRIACgkQK/VZk+smlYGyoACfe83RQUjiVR/JazBSpS/o8cUj lfoAn3KRAxlSUV5p4EaxMKhrfoMRkgvf =Lq9z -----END PGP SIGNATURE----- --Signature=_Thu__18_Sep_2008_20_25_49_+0400_QzZxySR_Z9.121Hu-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 16:57:52 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04C74106564A for ; Thu, 18 Sep 2008 16:57:52 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id 8494E8FC21 for ; Thu, 18 Sep 2008 16:57:51 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: by nf-out-0910.google.com with SMTP id h3so2106428nfh.33 for ; Thu, 18 Sep 2008 09:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=wrL9sCz+0pG7K4CSaeG9SoNuUQhjevYB2gRz9NAe6xI=; b=su+RN58vAVEx8ICzHsmM8QjUXHwlYPJaVPeMJ6pa72jg4lN1i6svZY/iezlt7NaGUl gtbn69wCTgNKEO0i9yDHW/Fv4bH3G1yrvJOGbPDT5miqnl1hUVgEEJ/JM6/ZXAfH53FI jhq3kBTkIAe0l8bCI3Cpj8iO0+HbnMiwHttUg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; b=xAFA6bNZzXnRfnmc2kwIZiWpS2XMvlJrxwOZnMQzq0NWx/GBVAJ6Vq70AT64LjorSU fJjR+5cUftR6sw0K8b3ZBLQPbTeEcvXX5XzKe2Y+EJF58mp+YMD9+xyxY1IZ0h2RdM3G Q19v98YTuiHQTQHvuBSkENL27bf2kupIRrpdE= Received: by 10.103.250.11 with SMTP id c11mr3112304mus.23.1221757069906; Thu, 18 Sep 2008 09:57:49 -0700 (PDT) Received: from ?0.0.0.0? ( [196.34.241.123]) by mx.google.com with ESMTPS id t10sm11007974muh.16.2008.09.18.09.57.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 18 Sep 2008 09:57:48 -0700 (PDT) From: David Naylor Organization: Private To: Tom Evans Date: Thu, 18 Sep 2008 18:57:21 +0200 User-Agent: KMail/1.9.7 References: <200809180631.47071.naylor.b.david@gmail.com> <1221744832.68732.4.camel@localhost> In-Reply-To: <1221744832.68732.4.camel@localhost> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart42174261.jbxUDPrD5S"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200809181857.25872.naylor.b.david@gmail.com> X-Mailman-Approved-At: Thu, 18 Sep 2008 17:04:22 +0000 Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD deadlock (with fork?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2008 16:57:52 -0000 --nextPart42174261.jbxUDPrD5S Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 18 September 2008 15:33:52 Tom Evans wrote: > On Thu, 2008-09-18 at 06:31 +0200, David Naylor wrote: > > Hi, > > > > I have a program that spawns a lot of subprocesses (with pipes open) fr= om > > multiple threads. The problem is the program often deadlocks, but not > > consistently. Sometimes the program can run over 5 times to competition > > without incidence and yet othertimes it locks within a few seconds. > > Do you create threads, which then fork(), or do you fork() and then create > threads? I have many threads that then fork. (aka forking threads). =20 > > I think the former will not work.. Is there any reason for this and is this a FreeBSD limitation or a general= =20 problem? =20 The problem is that my program has to have threads (or something similar)=20 since it handles lots of IO bound processes concurrently so is there a=20 work-a-round for this problem? I could limit the forking to a single thread (which I tried and did not wor= k)=20 but perhaps I need to have it fork from the master thread? One option I considered was forking a 'slave' program that then does all th= e=20 forking but that will become exceedingly complex (with the communication=20 between the 'slave' and the threads). =20 Lastly, how does GUIs, such as Qt, handle forking since they are threaded a= nd=20 some do fork? =20 > > Cheers > > Tom Regards David --nextPart42174261.jbxUDPrD5S Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBI0oh1UaaFgP9pFrIRAg7tAJ0YftXpRyZmILJTgPYT8tuaZp94zACfQ9eQ 9ky/Af7G8yBCGAeU2nsQks0= =YYdj -----END PGP SIGNATURE----- --nextPart42174261.jbxUDPrD5S-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 17:13:21 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2229C106566C for ; Thu, 18 Sep 2008 17:13:21 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id D565A8FC15 for ; Thu, 18 Sep 2008 17:13:20 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id m8IHDJVZ014905; Thu, 18 Sep 2008 13:13:19 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Thu, 18 Sep 2008 13:13:19 -0400 (EDT) Date: Thu, 18 Sep 2008 13:13:19 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: David Naylor In-Reply-To: <200809181857.25872.naylor.b.david@gmail.com> Message-ID: References: <200809180631.47071.naylor.b.david@gmail.com> <1221744832.68732.4.camel@localhost> <200809181857.25872.naylor.b.david@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Tom Evans , freebsd-current@freebsd.org Subject: Re: FreeBSD deadlock (with fork?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2008 17:13:21 -0000 On Thu, 18 Sep 2008, David Naylor wrote: > On Thursday 18 September 2008 15:33:52 Tom Evans wrote: >> On Thu, 2008-09-18 at 06:31 +0200, David Naylor wrote: >>> Hi, >>> >>> I have a program that spawns a lot of subprocesses (with pipes open) from >>> multiple threads. The problem is the program often deadlocks, but not >>> consistently. Sometimes the program can run over 5 times to competition >>> without incidence and yet othertimes it locks within a few seconds. >> >> Do you create threads, which then fork(), or do you fork() and then create >> threads? > > I have many threads that then fork. (aka forking threads). > >> >> I think the former will not work.. > > Is there any reason for this and is this a FreeBSD limitation or a general > problem? No, the former will work. You can fork() from threads, only as long as your forked processes only call async-signal-safe functions or some form of exec(). For instance, you can't fork and then create new threads from that child process. If you are not immediately exec()'ing from the child process, then you have to be careful and only use async-signal-safe functions. Remember that you have multiple threads in the parent, so the state of libthr, libc, etc may be inconsistent in a child process. -- DE From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 17:35:43 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AD081065676 for ; Thu, 18 Sep 2008 17:35:43 +0000 (UTC) (envelope-from jille@quis.cx) Received: from smtp2.versatel.nl (smtp2.versatel.nl [62.58.50.89]) by mx1.freebsd.org (Postfix) with ESMTP id 001708FC15 for ; Thu, 18 Sep 2008 17:35:42 +0000 (UTC) (envelope-from jille@quis.cx) Received: (qmail 25251 invoked by uid 0); 18 Sep 2008 17:09:02 -0000 Received: from ip83-113-174-82.adsl2.static.versatel.nl (HELO istud.quis.cx) ([82.174.113.83]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 18 Sep 2008 17:09:02 -0000 Received: from [192.168.1.4] (ille [192.168.1.4]) by istud.quis.cx (Postfix) with ESMTP id 450F35C1D; Thu, 18 Sep 2008 19:09:02 +0200 (CEST) Message-ID: <48D28B2D.90204@quis.cx> Date: Thu, 18 Sep 2008 19:09:01 +0200 From: Jille Timmermans User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: David Naylor References: <200809180631.47071.naylor.b.david@gmail.com> <1221744832.68732.4.camel@localhost> <200809181857.25872.naylor.b.david@gmail.com> In-Reply-To: <200809181857.25872.naylor.b.david@gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Tom Evans , freebsd-current@freebsd.org Subject: Re: FreeBSD deadlock (with fork?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2008 17:35:43 -0000 David Naylor schreef: > On Thursday 18 September 2008 15:33:52 Tom Evans wrote: >> On Thu, 2008-09-18 at 06:31 +0200, David Naylor wrote: >>> Hi, >>> >>> I have a program that spawns a lot of subprocesses (with pipes open) from >>> multiple threads. The problem is the program often deadlocks, but not >>> consistently. Sometimes the program can run over 5 times to competition >>> without incidence and yet othertimes it locks within a few seconds. >> Do you create threads, which then fork(), or do you fork() and then create >> threads? > > I have many threads that then fork. (aka forking threads). If you fork, the child will only have one thread, the one that called fork(). The parent is left as is. (This prevents a lot of races; mostly in programs that fork() and execve()) > >> I think the former will not work.. > > Is there any reason for this and is this a FreeBSD limitation or a general > problem? I assume all fork()ing OS's will do this. > > The problem is that my program has to have threads (or something similar) > since it handles lots of IO bound processes concurrently so is there a > work-a-round for this problem? > > I could limit the forking to a single thread (which I tried and did not work) > but perhaps I need to have it fork from the master thread? Doesn't matter wrt the single-threaddedness of the child (which can create threads after being forked off) -- Jille > > One option I considered was forking a 'slave' program that then does all the > forking but that will become exceedingly complex (with the communication > between the 'slave' and the threads). > > Lastly, how does GUIs, such as Qt, handle forking since they are threaded and > some do fork? >> Cheers >> >> Tom > > Regards > > David From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 17:28:22 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E42931065675 for ; Thu, 18 Sep 2008 17:28:22 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by mx1.freebsd.org (Postfix) with ESMTP id 6AA728FC17 for ; Thu, 18 Sep 2008 17:28:22 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: by nf-out-0910.google.com with SMTP id h3so2884nfh.33 for ; Thu, 18 Sep 2008 10:28:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=SoRWWgKlCJmLgU6/aRlixpyOW9S8sV1UWiB8silb3no=; b=jrnO2XftWvJIf8V9LYHq67LtpT9AOvFxhDsQUuIYF8JrjjEPUoKiU2wQLPR3G0PcPY 7fMnVULuIK/+AZWAL/55fQwsEFdple7BoPtMpvB7uB4KwcFJv+gVOUbIndNBP6H7fRIG v46+hzwDdVm3Z/9+PlR5ZE703FJFkkx8Tm4s4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; b=hGTiJwBHgrqoHoCpaLj5UZe6u5zPDhKB4s0YwtK2ttzehRtjCkQiCYbdUsfIuXp3pG ZX63rTaM4Suj+6LmjgZ6m3boLGw1phvgnIUywaToYFl3RThmy2TGfv+0XWXTOwaS3ZFJ +21vaP5YUptk4RV9sd4GEDVL4XOLVr2LnBXwo= Received: by 10.103.240.5 with SMTP id s5mr3133923mur.62.1221758900898; Thu, 18 Sep 2008 10:28:20 -0700 (PDT) Received: from ?0.0.0.0? ( [196.34.241.123]) by mx.google.com with ESMTPS id j10sm11192714mue.17.2008.09.18.10.28.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 18 Sep 2008 10:28:19 -0700 (PDT) From: David Naylor Organization: Private To: Daniel Eischen Date: Thu, 18 Sep 2008 19:27:47 +0200 User-Agent: KMail/1.9.7 References: <200809180631.47071.naylor.b.david@gmail.com> <200809181857.25872.naylor.b.david@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart12811148.oDATbWqooN"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200809181927.52384.naylor.b.david@gmail.com> X-Mailman-Approved-At: Thu, 18 Sep 2008 17:40:54 +0000 Cc: Tom Evans , freebsd-current@freebsd.org Subject: Re: FreeBSD deadlock (with fork?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2008 17:28:23 -0000 --nextPart12811148.oDATbWqooN Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 18 September 2008 19:13:19 Daniel Eischen wrote: > On Thu, 18 Sep 2008, David Naylor wrote: > > On Thursday 18 September 2008 15:33:52 Tom Evans wrote: > >> On Thu, 2008-09-18 at 06:31 +0200, David Naylor wrote: > >>> Hi, > >>> > >>> I have a program that spawns a lot of subprocesses (with pipes open) > >>> from multiple threads. The problem is the program often deadlocks, b= ut > >>> not consistently. Sometimes the program can run over 5 times to > >>> competition without incidence and yet othertimes it locks within a few > >>> seconds. > >> > >> Do you create threads, which then fork(), or do you fork() and then > >> create threads? > > > > I have many threads that then fork. (aka forking threads). > > > >> I think the former will not work.. > > > > Is there any reason for this and is this a FreeBSD limitation or a > > general problem? > > No, the former will work. You can fork() from threads, only as long > as your forked processes only call async-signal-safe functions or > some form of exec(). For instance, you can't fork and then create > new threads from that child process. If you are not immediately > exec()'ing from the child process, then you have to be careful > and only use async-signal-safe functions. > > Remember that you have multiple threads in the parent, so the > state of libthr, libc, etc may be inconsistent in a child > process. If you have a look at the backtrace from my original post you will see that= =20 all my threads are getting locked. The program I am using is python and th= e=20 call that is forking is Popen(['some', 'program'], stdout=3DPIPE,=20 stderr=3DSTDOUT). As far as I know it just sets up the pipes and does an=20 execvp. (See=20 http://svn.python.org/view/*checkout*/python/tags/r252/Lib/subprocess.py?co= ntent-type=3Dtext%2Fplain&rev=3D60915=20 from line 981 to 1091). [[I tried appending close_fds=3DTrue to the argume= nt,=20 it appeared to make the program deadlock less often...]] Any ideas as to what might be causing this dead lock (and why all the threa= ds=20 are stopping in amd64 specific assembler)? --nextPart12811148.oDATbWqooN Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBI0o+YUaaFgP9pFrIRArHCAJ4unxSPffSggossGz7l1Gz0LF8xugCfci3D c8wugKdG9K5F8CapMNITo7Y= =nEFp -----END PGP SIGNATURE----- --nextPart12811148.oDATbWqooN-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 17:46:03 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66D35106567E for ; Thu, 18 Sep 2008 17:46:03 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outK.internet-mail-service.net (outk.internet-mail-service.net [216.240.47.234]) by mx1.freebsd.org (Postfix) with ESMTP id 4D44B8FC0A for ; Thu, 18 Sep 2008 17:46:03 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id BA72B24DE; Thu, 18 Sep 2008 10:46:01 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 3699B2D6031; Thu, 18 Sep 2008 09:23:24 -0700 (PDT) Message-ID: <48D2807A.1050106@elischer.org> Date: Thu, 18 Sep 2008 09:23:22 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: David Naylor References: <200809180631.47071.naylor.b.david@gmail.com> In-Reply-To: <200809180631.47071.naylor.b.david@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD deadlock (with fork?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2008 17:46:03 -0000 David Naylor wrote: > Hi, > > I have a program that spawns a lot of subprocesses (with pipes open) from > multiple threads. The problem is the program often deadlocks, but not > consistently. Sometimes the program can run over 5 times to competition > without incidence and yet othertimes it locks within a few seconds. you sent this to -current. Is it in -current? (we fixed something like this some months back in current and 7) do your post-fork processes do an exec? according to the spec they should. if any of your threads other than the one that did the fork ho;ds any mutex at teh time of fork then your process will hang. If they hold a umtx (between processes) then everything will hang. > > However if I limit the thread count to 1 the problem does not appear to be > present. > > Here are the logs from gdb: > (gdb) info thread > 5 Thread 7021c0 (LWP 100203) 0x00000008009a2e8c in _umtx_op_err () > at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > 4 Thread a28480 (LWP 100174) 0x00000008009a2e8c in _umtx_op_err () > at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > 3 Thread a61d80 (LWP 100175) 0x00000008009a2e8c in _umtx_op_err () > at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > 2 Thread a61bc0 (LWP 100176) 0x00000008009a2e8c in _umtx_op_err () > at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > * 1 Thread a61840 (LWP 100177) 0x00000008009a2e8c in _umtx_op_err () > at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > > > (gdb) bt > #0 0x00000008009a2e8c in _umtx_op_err () > at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > #1 0x00000008009a1331 in cond_wait_common (cond=Variable "cond" is not > available. > ) at /usr/src/lib/libthr/thread/thr_cond.c:204 > #2 0x00000000004c0573 in PyThread_acquire_lock (lock=0x70a760, waitflag=1) at > thread_pthread.h:452 > #3 0x00000000004c38b0 in lock_PyThread_acquire_lock (self=0x83f258, > args=Variable "args" is not available. > ) at ./Modules/threadmodule.c:46 > #4 0x00000000004939e3 in PyEval_EvalFrameEx (f=0xa53920, > throwflag=Variable "throwflag" is not available. > ) at Python/ceval.c:3679 > #5 0x00000000004939a8 in PyEval_EvalFrameEx (f=0xb57420, > throwflag=Variable "throwflag" is not available. > ) at Python/ceval.c:3765 > #6 0x0000000000494ac1 in PyEval_EvalCodeEx (co=0x9aab70, > globals=Variable "globals" is not available. > ) at Python/ceval.c:2942 > #7 0x00000000004eb6bc in function_call (func=0x9d8938, arg=0x9d9990, > kw=0xa24da0) > at Objects/funcobject.c:524 > #8 0x0000000000417add in PyObject_Call (func=0x9d8938, arg=0x9d9990, > kw=0xa24da0) > at Objects/abstract.c:2487 > #9 0x000000000048f730 in PyEval_EvalFrameEx (f=0xb48e20, > throwflag=Variable "throwflag" is not available. > ) at Python/ceval.c:3978 > #10 0x00000000004939a8 in PyEval_EvalFrameEx (f=0xb57720, > throwflag=Variable "throwflag" is not available. > ) at Python/ceval.c:3765 > #11 0x00000000004939a8 in PyEval_EvalFrameEx (f=0xb49020, > throwflag=Variable "throwflag" is not available. > ) at Python/ceval.c:3765 > #12 0x0000000000494ac1 in PyEval_EvalCodeEx (co=0x947cd8, > globals=Variable "globals" is not available. > ) at Python/ceval.c:2942 > #13 0x00000000004eb5bd in function_call (func=0x9a5320, arg=0x9d9950, kw=0x0) > at Objects/funcobject.c:524 > #14 0x0000000000417add in PyObject_Call (func=0x9a5320, arg=0x9d9950, kw=0x0) > at Objects/abstract.c:2487 > #15 0x000000000041f12f in instancemethod_call (func=0x9a5320, arg=0x9d9950, > kw=0x0) > at Objects/classobject.c:2558 > #16 0x0000000000417add in PyObject_Call (func=0x93b410, arg=0x718050, kw=0x0) > at Objects/abstract.c:2487 > #17 0x000000000048d4c6 in PyEval_CallObjectWithKeywords (func=0x93b410, > arg=0x718050, kw=0x0) > at Python/ceval.c:3548 > #18 0x00000000004c3cbd in t_bootstrap (boot_raw=0x70ae60) > at ./Modules/threadmodule.c:425 > #19 0x000000080099ac11 in thread_start (curthread=0xa61840) > at /usr/src/lib/libthr/thread/thr_create.c:288 > #20 0x0000000000000000 in ?? () > Error accessing memory address 0x7fffff5fc000: Bad address. > > > (gdb) thr 2 > [Switching to thread 2 (Thread a61bc0 (LWP 100176))]#0 0x00000008009a2e8c in > _umtx_op_err () > at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > 37 RSYSCALL_ERR(_umtx_op) > (gdb) bt > #0 0x00000008009a2e8c in _umtx_op_err () > at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > #1 0x00000008009a1331 in cond_wait_common (cond=Variable "cond" is not > available. > ) at /usr/src/lib/libthr/thread/thr_cond.c:204 > #2 0x00000000004c0573 in PyThread_acquire_lock (lock=0x70a600, waitflag=1) at > thread_pthread.h:452 > #3 0x00000000004c38b0 in lock_PyThread_acquire_lock (self=0x83f168, > args=Variable "args" is not available. > ) at ./Modules/threadmodule.c:46 > #4 0x00000000004939e3 in PyEval_EvalFrameEx (f=0xb56520, > throwflag=Variable "throwflag" is not available. > ) at Python/ceval.c:3679 > #5 0x0000000000494ac1 in PyEval_EvalCodeEx (co=0x8d5dc8, > globals=Variable "globals" is not available. > ) at Python/ceval.c:2942 > #6 0x0000000000492c88 in PyEval_EvalFrameEx (f=0xb2de20, > throwflag=Variable "throwflag" is not available. > ) at Python/ceval.c:3775 > #7 0x0000000000494ac1 in PyEval_EvalCodeEx (co=0x8d5288, > globals=Variable "globals" is not available. > ) at Python/ceval.c:2942 > #8 0x00000000004eb5bd in function_call (func=0x9a8b18, arg=0xc524d0, kw=0x0) > at Objects/funcobject.c:524 > #9 0x0000000000417add in PyObject_Call (func=0x9a8b18, arg=0xc524d0, kw=0x0) > at Objects/abstract.c:2487 > #10 0x000000000041f12f in instancemethod_call (func=0x9a8b18, arg=0xc524d0, > kw=0x0) > at Objects/classobject.c:2558 > #11 0x0000000000417add in PyObject_Call (func=0x93b370, arg=0x10331d0, kw=0x0) > at Objects/abstract.c:2487 > #12 0x0000000000464158 in slot_tp_init (self=Variable "self" is not available. > ) at Objects/typeobject.c:5532 > #13 0x0000000000461561 in type_call (type=0x7d9420, args=0x10331d0, kwds=0x0) > at Objects/typeobject.c:700 > #14 0x0000000000417add in PyObject_Call (func=0x7d9420, arg=0x10331d0, kw=0x0) > at Objects/abstract.c:2487 > #15 0x00000000004906f9 in PyEval_EvalFrameEx (f=0xb3a120, > throwflag=Variable "throwflag" is not available. > ) at Python/ceval.c:3890 > #16 0x0000000000494ac1 in PyEval_EvalCodeEx (co=0x8d5eb8, > globals=Variable "globals" is not available. > ) at Python/ceval.c:2942 > #17 0x0000000000492c88 in PyEval_EvalFrameEx (f=0xa47a20, > throwflag=Variable "throwflag" is not available. > ) at Python/ceval.c:3775 > #18 0x0000000000494ac1 in PyEval_EvalCodeEx (co=0x8d5cd8, > globals=Variable "globals" is not available. > ) at Python/ceval.c:2942 > #19 0x0000000000492c88 in PyEval_EvalFrameEx (f=0xb3a420, > throwflag=Variable "throwflag" is not available. > ) at Python/ceval.c:3775 > #20 0x0000000000494ac1 in PyEval_EvalCodeEx (co=0x9aabe8, > globals=Variable "globals" is not available. > ) at Python/ceval.c:2942 > #21 0x0000000000492c88 in PyEval_EvalFrameEx (f=0xb3a720, > throwflag=Variable "throwflag" is not available. > ) at Python/ceval.c:3775 > #22 0x0000000000494ac1 in PyEval_EvalCodeEx (co=0x9aab70, > globals=Variable "globals" is not available. > ) at Python/ceval.c:2942 > #23 0x00000000004eb6bc in function_call (func=0x9d8938, arg=0x9d98d0, > kw=0xa5a660) > at Objects/funcobject.c:524 > #24 0x0000000000417add in PyObject_Call (func=0x9d8938, arg=0x9d98d0, > kw=0xa5a660) > at Objects/abstract.c:2487 > #25 0x000000000048f730 in PyEval_EvalFrameEx (f=0xb2e020, > throwflag=Variable "throwflag" is not available. > ) at Python/ceval.c:3978 > ---Type to continue, or q to quit--- > #26 0x00000000004939a8 in PyEval_EvalFrameEx (f=0xb3aa20, > throwflag=Variable "throwflag" is not available. > ) at Python/ceval.c:3765 > #27 0x00000000004939a8 in PyEval_EvalFrameEx (f=0xb2e220, > throwflag=Variable "throwflag" is not available. > ) at Python/ceval.c:3765 > #28 0x0000000000494ac1 in PyEval_EvalCodeEx (co=0x947cd8, > globals=Variable "globals" is not available. > ) at Python/ceval.c:2942 > #29 0x00000000004eb5bd in function_call (func=0x9a5320, arg=0x9d9890, kw=0x0) > at Objects/funcobject.c:524 > #30 0x0000000000417add in PyObject_Call (func=0x9a5320, arg=0x9d9890, kw=0x0) > at Objects/abstract.c:2487 > #31 0x000000000041f12f in instancemethod_call (func=0x9a5320, arg=0x9d9890, > kw=0x0) > at Objects/classobject.c:2558 > #32 0x0000000000417add in PyObject_Call (func=0x93b320, arg=0x718050, kw=0x0) > at Objects/abstract.c:2487 > #33 0x000000000048d4c6 in PyEval_CallObjectWithKeywords (func=0x93b320, > arg=0x718050, kw=0x0) > at Python/ceval.c:3548 > #34 0x00000000004c3cbd in t_bootstrap (boot_raw=0x70aee0) > at ./Modules/threadmodule.c:425 > #35 0x000000080099ac11 in thread_start (curthread=0xa61bc0) > at /usr/src/lib/libthr/thread/thr_create.c:288 > #36 0x0000000000000000 in ?? () > Error accessing memory address 0x7fffff7fd000: Bad address. > > Apologies about the long backtraces [and thus the long message]. > > Thanks > > David From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 18:13:38 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25E591065672 for ; Thu, 18 Sep 2008 18:13:38 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.235]) by mx1.freebsd.org (Postfix) with ESMTP id 963948FC1A for ; Thu, 18 Sep 2008 18:13:37 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: by qb-out-0506.google.com with SMTP id f30so21041qba.35 for ; Thu, 18 Sep 2008 11:13:36 -0700 (PDT) Received: by 10.180.220.5 with SMTP id s5mr2908432bkg.5.1221760641239; Thu, 18 Sep 2008 10:57:21 -0700 (PDT) Received: by 10.181.17.8 with HTTP; Thu, 18 Sep 2008 10:57:21 -0700 (PDT) Message-ID: <1de79840809181057v70cdc206o6f5017ca677bf528@mail.gmail.com> Date: Thu, 18 Sep 2008 13:57:21 -0400 From: "Michael Proto" To: "Daniel de Oliveira" In-Reply-To: <35e5bf980809180340j171e39ao3d6bf6732ff4c165@mail.gmail.com> MIME-Version: 1.0 References: <35e5bf980809180340j171e39ao3d6bf6732ff4c165@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: Current using -Os -pipe -march=pentium3m X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2008 18:13:38 -0000 On Thu, Sep 18, 2008 at 6:40 AM, Daniel de Oliveira wrote: > Hi all > > I have some problems here trying to compile my system using.. > > CPUTYPE?=pentium3m > CFLAGS=-Os -pipe > > When I take off the CFLAGS, all things works properly. A lot of errors > in different points occurs (kernel and buildworld), so at this point I > dont a have log, btw, when I comment CFLAGS lines, everything compiles > fine. Just for information, is there something wrong with that? > > > > Daniel de Oliveira > ---- > Network and System Analyst > Security Specialist > IBM RISC Specialist > IBM Storage Specialist > Linux/Unix Specialist > Linux User #: 405334 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > Use at your own risk/peril, but I ran into a similar problem trying to compile 8-CURRENT with -Os (I have a small PCEngines ALIX SBC with a 32MB flash, so space is at a premium). After several long bouts of trial-and-error, I found that several apps and libraries won't compile with -Os, so I've set those to -O and they work. Oh, and this is with -fno-strict-aliasing Here's my make.conf, it may save you some time: CPUTYPE?=pentium-mmx CFLAGS= -Os -fno-strict-aliasing -pipe COPTFLAGS= -O -pipe .if ${.CURDIR:M*/src/lib/libkse} CFLAGS= -O -pipe .endif .if ${.CURDIR:M*/src/lib/libarchive} CFLAGS= -O -pipe .endif .if ${.CURDIR:M*/src/lib/libngatm} CFLAGS= -O -pipe .endif .if ${.CURDIR:M*/src/lib/librpcsec_gss} CFLAGS= -O -pipe .endif .if ${.CURDIR:M*/src/lib/libthr} CFLAGS= -O -pipe .endif .if ${.CURDIR:M*/src/sbin/geom/*} CFLAGS= -O -pipe .endif .if ${.CURDIR:M*/src/sbin/ggate/*} CFLAGS= -O -pipe .endif .if ${.CURDIR:M*/src/usr.bin/csup} CFLAGS= -O -pipe .endif .if ${.CURDIR:M*/src/usr.sbin/acpi/acpidump} CFLAGS= -O -pipe .endif -Proto From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 19:22:48 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7383106566B for ; Thu, 18 Sep 2008 19:22:48 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.freebsd.org (Postfix) with ESMTP id 5F55A8FC08 for ; Thu, 18 Sep 2008 19:22:42 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: by nf-out-0910.google.com with SMTP id h3so29002nfh.33 for ; Thu, 18 Sep 2008 12:22:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=flGV7RpOwR1wig3gFZYC4dki4tSW17Rwmto6Lj5YWM0=; b=xCQMo6Gs8HyT6rIdk0tWt6sIjiVyRZul8h04Tnjb7c4Tkq0XLJOfLbUHz372bmkN+o +S1tWNylAYg0XV5T7bQM1nHnY/NLBkCSV5I5sYOIpqiYiK7EGXCX5afs8b7cIrc9DGpg lIJWdiEbcrRVyCwRwgHM4aTB+uDrL5oOALF3I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; b=ZclW3phXmTDIjjNkLQWaYu3/0XQ0Heo0bKoVj/zsE7nhyf8cbl+IwDQCMVfprMbxOZ mrLfljdF5nqzR3aJ0kCmCu/0ZXs5c4sOKd4FFTCJQVYlVzeLVeNHI6BvnDReRLcsDqsz I7Fy7x3q7HZvF/OpEIg8nuS80H25gk1rpRWTk= Received: by 10.210.119.16 with SMTP id r16mr5431075ebc.24.1221765761802; Thu, 18 Sep 2008 12:22:41 -0700 (PDT) Received: from ?0.0.0.0? ( [196.34.241.123]) by mx.google.com with ESMTPS id j8sm8563832gvb.1.2008.09.18.12.22.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 18 Sep 2008 12:22:39 -0700 (PDT) From: David Naylor Organization: Private To: Julian Elischer Date: Thu, 18 Sep 2008 21:22:04 +0200 User-Agent: KMail/1.9.7 References: <200809180631.47071.naylor.b.david@gmail.com> <48D2807A.1050106@elischer.org> In-Reply-To: <48D2807A.1050106@elischer.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7296846.maSOvWPULo"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200809182122.08221.naylor.b.david@gmail.com> X-Mailman-Approved-At: Thu, 18 Sep 2008 19:45:09 +0000 Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD deadlock (with fork?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2008 19:22:49 -0000 --nextPart7296846.maSOvWPULo Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 18 September 2008 18:23:22 you wrote: > David Naylor wrote: > > Hi, > > > > I have a program that spawns a lot of subprocesses (with pipes open) fr= om > > multiple threads. The problem is the program often deadlocks, but not > > consistently. Sometimes the program can run over 5 times to competition > > without incidence and yet othertimes it locks within a few seconds. > > you sent this to -current. Is it in -current? (we fixed something like > this some months back in current and 7) =2Dcurrent cvsuped about Tuesday. =20 > do your post-fork processes do an exec? according to the spec they > should. Yes, they do. See the other replies... > if any of your threads other than the one that did the fork ho;ds any > mutex at teh time of fork then your process will hang. If they hold a > umtx (between processes) then everything will hang. Yes, the system does make use of mutexes. The forking thread never holds a= =20 mutex but other threads could hold a mutex. This would explain the problem= =2E =20 Is there any way to get around it (i.e. make sure no mutexes are held when = a=20 fork is called?) --nextPart7296846.maSOvWPULo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBI0qpgUaaFgP9pFrIRAljRAJ4yB8YgGU5m4DcNCr0mt5GVX1mmuACfTPPo phWECfLkfwuS8eaW/LqLsP8= =1pKp -----END PGP SIGNATURE----- --nextPart7296846.maSOvWPULo-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 21:03:48 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97B331065671 for ; Thu, 18 Sep 2008 21:03:48 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 37C0D8FC0C for ; Thu, 18 Sep 2008 21:03:47 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id m8IL3kfO019172; Thu, 18 Sep 2008 17:03:46 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Thu, 18 Sep 2008 17:03:46 -0400 (EDT) Date: Thu, 18 Sep 2008 17:03:46 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: David Naylor In-Reply-To: <200809181927.52384.naylor.b.david@gmail.com> Message-ID: References: <200809180631.47071.naylor.b.david@gmail.com> <200809181857.25872.naylor.b.david@gmail.com> <200809181927.52384.naylor.b.david@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Tom Evans , freebsd-current@freebsd.org Subject: Re: FreeBSD deadlock (with fork?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2008 21:03:48 -0000 On Thu, 18 Sep 2008, David Naylor wrote: > On Thursday 18 September 2008 19:13:19 Daniel Eischen wrote: >> On Thu, 18 Sep 2008, David Naylor wrote: >>> On Thursday 18 September 2008 15:33:52 Tom Evans wrote: >>>> On Thu, 2008-09-18 at 06:31 +0200, David Naylor wrote: >>>>> Hi, >>>>> >>>>> I have a program that spawns a lot of subprocesses (with pipes open) >>>>> from multiple threads. The problem is the program often deadlocks, but >>>>> not consistently. Sometimes the program can run over 5 times to >>>>> competition without incidence and yet othertimes it locks within a few >>>>> seconds. >>>> >>>> Do you create threads, which then fork(), or do you fork() and then >>>> create threads? >>> >>> I have many threads that then fork. (aka forking threads). >>> >>>> I think the former will not work.. >>> >>> Is there any reason for this and is this a FreeBSD limitation or a >>> general problem? >> >> No, the former will work. You can fork() from threads, only as long >> as your forked processes only call async-signal-safe functions or >> some form of exec(). For instance, you can't fork and then create >> new threads from that child process. If you are not immediately >> exec()'ing from the child process, then you have to be careful >> and only use async-signal-safe functions. >> >> Remember that you have multiple threads in the parent, so the >> state of libthr, libc, etc may be inconsistent in a child >> process. > > If you have a look at the backtrace from my original post you will see that > all my threads are getting locked. The program I am using is python and the > call that is forking is Popen(['some', 'program'], stdout=PIPE, > stderr=STDOUT). As far as I know it just sets up the pipes and does an > execvp. (See > http://svn.python.org/view/*checkout*/python/tags/r252/Lib/subprocess.py?content-type=text%2Fplain&rev=60915 > from line 981 to 1091). [[I tried appending close_fds=True to the argument, > it appeared to make the program deadlock less often...]] > > Any ideas as to what might be causing this dead lock (and why all the threads > are stopping in amd64 specific assembler)? No, could be a bug in python though. -- DE From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 21:14:43 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C90F1065670 for ; Thu, 18 Sep 2008 21:14:43 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 28F4C8FC1A for ; Thu, 18 Sep 2008 21:14:43 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id m8ILEdFr024711; Thu, 18 Sep 2008 17:14:39 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Thu, 18 Sep 2008 17:14:41 -0400 (EDT) Date: Thu, 18 Sep 2008 17:14:39 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: David Naylor In-Reply-To: <200809182122.08221.naylor.b.david@gmail.com> Message-ID: References: <200809180631.47071.naylor.b.david@gmail.com> <48D2807A.1050106@elischer.org> <200809182122.08221.naylor.b.david@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, Julian Elischer Subject: Re: FreeBSD deadlock (with fork?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2008 21:14:43 -0000 On Thu, 18 Sep 2008, David Naylor wrote: > On Thursday 18 September 2008 18:23:22 you wrote: >> David Naylor wrote: >>> Hi, >>> >>> I have a program that spawns a lot of subprocesses (with pipes open) from >>> multiple threads. The problem is the program often deadlocks, but not >>> consistently. Sometimes the program can run over 5 times to competition >>> without incidence and yet othertimes it locks within a few seconds. >> >> you sent this to -current. Is it in -current? (we fixed something like >> this some months back in current and 7) > > -current cvsuped about Tuesday. > >> do your post-fork processes do an exec? according to the spec they >> should. > > Yes, they do. See the other replies... > >> if any of your threads other than the one that did the fork ho;ds any >> mutex at teh time of fork then your process will hang. If they hold a >> umtx (between processes) then everything will hang. > > Yes, the system does make use of mutexes. The forking thread never holds a > mutex but other threads could hold a mutex. This would explain the problem. > Is there any way to get around it (i.e. make sure no mutexes are held when a > fork is called?) You can hold mutexes while forking, you just can't rely on their state in any child process. There is also pthread_atfork(). -- DE From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 21:34:29 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D526106567D; Thu, 18 Sep 2008 21:34:29 +0000 (UTC) (envelope-from jb@what-creek.com) Received: from what-creek.com (what-creek.com [66.111.37.70]) by mx1.freebsd.org (Postfix) with ESMTP id 6B45B8FC14; Thu, 18 Sep 2008 21:34:24 +0000 (UTC) (envelope-from jb@what-creek.com) Received: by what-creek.com (Postfix, from userid 102) id 9E1A67416E; Thu, 18 Sep 2008 21:16:52 +0000 (GMT) Date: Thu, 18 Sep 2008 21:16:52 +0000 From: John Birrell To: Roman Divacky Message-ID: <20080918211652.GB19958@what-creek.com> References: <20080917101013.GA90749@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080917101013.GA90749@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: jb@freebsd.org, current@freebsd.org Subject: Re: dtrace status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2008 21:34:29 -0000 On Wed, Sep 17, 2008 at 12:10:13PM +0200, Roman Divacky wrote: > Dtrace was commited 3 months ago and the only things that prevents > using it "out of the box" is building kernel with WITH_CTF=1. > > When is this going to be enabled on default. What is preventing this > from happening? I wonder whether people generally want it enabled by default. -- John Birrell From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 21:38:07 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBE38106564A for ; Thu, 18 Sep 2008 21:38:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5C0BE8FC18 for ; Thu, 18 Sep 2008 21:38:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8ILbngg020803; Thu, 18 Sep 2008 17:38:01 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 18 Sep 2008 17:35:29 -0400 User-Agent: KMail/1.9.7 References: <200809180631.47071.naylor.b.david@gmail.com> In-Reply-To: <200809180631.47071.naylor.b.david@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809181735.29504.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Thu, 18 Sep 2008 17:38:01 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8282/Thu Sep 18 14:21:01 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: David Naylor Subject: Re: FreeBSD deadlock (with fork?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2008 21:38:07 -0000 On Thursday 18 September 2008 12:31:42 am David Naylor wrote: > Hi, > > I have a program that spawns a lot of subprocesses (with pipes open) from > multiple threads. The problem is the program often deadlocks, but not > consistently. Sometimes the program can run over 5 times to competition > without incidence and yet othertimes it locks within a few seconds. > > However if I limit the thread count to 1 the problem does not appear to be > present. > > Here are the logs from gdb: > (gdb) info thread > 5 Thread 7021c0 (LWP 100203) 0x00000008009a2e8c in _umtx_op_err () > at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > 4 Thread a28480 (LWP 100174) 0x00000008009a2e8c in _umtx_op_err () > at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > 3 Thread a61d80 (LWP 100175) 0x00000008009a2e8c in _umtx_op_err () > at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > 2 Thread a61bc0 (LWP 100176) 0x00000008009a2e8c in _umtx_op_err () > at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > * 1 Thread a61840 (LWP 100177) 0x00000008009a2e8c in _umtx_op_err () > at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > > > (gdb) bt > #0 0x00000008009a2e8c in _umtx_op_err () > at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > #1 0x00000008009a1331 in cond_wait_common (cond=Variable "cond" is not > available. This is not waiting on a lock, this is a pthread_condvar_wait() of some sort. > (gdb) thr 2 > [Switching to thread 2 (Thread a61bc0 (LWP 100176))]#0 0x00000008009a2e8c in > _umtx_op_err () > at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > 37 RSYSCALL_ERR(_umtx_op) > (gdb) bt > #0 0x00000008009a2e8c in _umtx_op_err () > at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > #1 0x00000008009a1331 in cond_wait_common (cond=Variable "cond" is not > available. Simiarly here. I don't think you have a deadlock. I think you have a bug where you are missing a pthread_condvar_signal() or broadcast or some such. Or maybe you aren't holding the mutex when doing the signal or broadcast. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 22:49:45 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A39EE106566B for ; Thu, 18 Sep 2008 22:49:45 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 2D8A98FC0C for ; Thu, 18 Sep 2008 22:49:44 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so349519fgb.35 for ; Thu, 18 Sep 2008 15:49:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=qWMr/Hauy0PDu4ZZrGhSXRFuto56MMDisxsBKulDBh4=; b=GW2zLO49Q3DscKvh9S8Wd2x+13RGK6U116xgeMKn8NezJbSbEFx0fXKN6EXY6XL7G9 vwIrQJWejtkP1EVgk4a1aN1nfYgUJ7ZN/8CMNfJ+GJobEno52nDYJWQtFzORLwlb1uJI S/bqKYY1oimZhwOue6/V6WXlyXYNEOPMbq0Lc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=NSQrjLOOX3ddsu39Ph40YGEwwOlznuEJ+I6W4PLUj/Mk7VBQiLp7u9rBRFPVrpmfwq fa0J9P3DYhBiXTeYgm++KrSz5Sii3TbAn6YBWboY3Ivc54YPp+mN73w+N95jEyTKmQH4 Jn4qDNer8OPbA2OcFrkQVOHAkAqciEmkQ5eoo= Received: by 10.86.90.13 with SMTP id n13mr1328412fgb.3.1221778183812; Thu, 18 Sep 2008 15:49:43 -0700 (PDT) Received: by 10.86.62.1 with HTTP; Thu, 18 Sep 2008 15:49:43 -0700 (PDT) Message-ID: Date: Thu, 18 Sep 2008 15:49:43 -0700 From: "Maksim Yevmenkin" To: "Kostik Belousov" , current@freebsd.org In-Reply-To: <20080918195049.GQ39652@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200809180023.m8I0NEJY032390@freefall.freebsd.org> <20080918195049.GQ39652@deviant.kiev.zoral.com.ua> Cc: Subject: Re: Fwd: Pending MFC Reminder [cvs commit: src/lib/libc/uuid Symbol.map] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2008 22:49:45 -0000 > > emax 2008-09-15 23:54:55 UTC > > > > FreeBSD src repository > > > > Modified files: > > lib/libc/uuid Symbol.map > > Log: > > SVN rev 183058 on 2008-09-15 23:54:55Z by emax > > > > Add uuid_enc,dec_le,be() functions to Symbol.map > > Pointy hat goes to me. > > > > MFC after: 3 days > > > > Revision Changes Path > > 1.3 +4 -0 src/lib/libc/uuid/Symbol.map > > > I has a question against original commit, that I missed when reading > commit mail. Why the new symbols introduced after 7.0 is released, > where added to the FBSD_1.0 version ? I think FBSD_1.1 is correct > there. > > Do you object ? hmm... not sure. those are new functions. old code should not know about them. may be FBSD_1.0.1? or is it better to have FBSD_1.1? anyone with libc foo care to chime in? thanks, max From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 22:58:55 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B13AA1065681 for ; Thu, 18 Sep 2008 22:58:55 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mx.egr.msu.edu (surfnturf.egr.msu.edu [35.9.37.164]) by mx1.freebsd.org (Postfix) with ESMTP id 86B478FC18 for ; Thu, 18 Sep 2008 22:58:55 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from localhost (localhost [127.0.0.1]) by mx.egr.msu.edu (Postfix) with ESMTP id 6C35871F1A9; Thu, 18 Sep 2008 18:42:49 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mx.egr.msu.edu ([127.0.0.1]) by localhost (surfnturf.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoCR87eQ5XRu; Thu, 18 Sep 2008 18:42:49 -0400 (EDT) Received: from [35.9.44.65] (daemon.egr.msu.edu [35.9.44.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mcdouga9) by mx.egr.msu.edu (Postfix) with ESMTPSA id 4A7B971F1A5; Thu, 18 Sep 2008 18:42:49 -0400 (EDT) Message-ID: <48D2D969.4040108@egr.msu.edu> Date: Thu, 18 Sep 2008 18:42:49 -0400 From: Adam McDougall User-Agent: Thunderbird 2.0.0.16 (X11/20080727) MIME-Version: 1.0 To: Rui Paulo , freebsd-current@freebsd.org References: <20080828002919.GA54169@alpha.local> In-Reply-To: <20080828002919.GA54169@alpha.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: HEADS UP: ath_hal updated to 0.10.5.10 -- PLEASE TEST X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2008 22:58:55 -0000 Rui Paulo wrote: > Hi, > We've updated ath_hal in HEAD to 0.10.5.10. This supports a couple of > new chips, namely those on the Asus Eee PC, MacBooks and other laptops. > > If you have an Atheros or Atheros based card, I really wanted you to > test it. We were unable to test this in several Atheros chipsets, so > if you find a regression, please contact me or Sam Leffler > (sam@freebsd.org) ASAP. > So, please give it a try :-) > > Unfortuntely, this will only make 7.1 if the release date slips. So, > don't expect this to be MFCed any time soon. > > Thanks, > Working on my 5212 a/b/g mini-pcie laptop. From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 23:03:37 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E9E51065670 for ; Thu, 18 Sep 2008 23:03:37 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 022888FC12 for ; Thu, 18 Sep 2008 23:03:37 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 0240528454 for ; Fri, 19 Sep 2008 07:03:36 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id A13B2F660A7; Fri, 19 Sep 2008 07:03:35 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id r7j-YF4dBu+O; Fri, 19 Sep 2008 07:03:30 +0800 (CST) Received: from charlie.delphij.net (71.5.7.139.ptr.us.xo.net [71.5.7.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 884AAF65F40; Fri, 19 Sep 2008 07:03:29 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=tqPjuE3EvQNkL4nPMmsFHMyd0JkRoYEDg+N0GFJF5r83w0BKVOxHtB9jKtCfijzpq ACtarnfaxo9PIgaozHu+w== Message-ID: <48D2DE3E.4020408@delphij.net> Date: Thu, 18 Sep 2008 16:03:26 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.16 (X11/20080725) MIME-Version: 1.0 To: Maksim Yevmenkin References: <200809180023.m8I0NEJY032390@freefall.freebsd.org> <20080918195049.GQ39652@deviant.kiev.zoral.com.ua> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , current@freebsd.org Subject: Re: Fwd: Pending MFC Reminder [cvs commit: src/lib/libc/uuid Symbol.map] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2008 23:03:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Maksim Yevmenkin wrote: >> > emax 2008-09-15 23:54:55 UTC >> > >> > FreeBSD src repository >> > >> > Modified files: >> > lib/libc/uuid Symbol.map >> > Log: >> > SVN rev 183058 on 2008-09-15 23:54:55Z by emax >> > >> > Add uuid_enc,dec_le,be() functions to Symbol.map >> > Pointy hat goes to me. >> > >> > MFC after: 3 days >> > >> > Revision Changes Path >> > 1.3 +4 -0 src/lib/libc/uuid/Symbol.map >> >> >> I has a question against original commit, that I missed when reading >> commit mail. Why the new symbols introduced after 7.0 is released, >> where added to the FBSD_1.0 version ? I think FBSD_1.1 is correct >> there. >> >> Do you object ? > > hmm... not sure. those are new functions. old code should not know > about them. may be FBSD_1.0.1? or is it better to have FBSD_1.1? > > anyone with libc foo care to chime in? I think there is some discussion about this in the past, and let me try to reproduce them: No new symbols should be ever introduced on a released frozen namespace. I.e. as soon as 7.0-RELEASE is released, FBSD_1.0 is considered as "frozen" and no new symbol should be introduced into it. Upon 8.0-RELEASE, FBSD_1.1 is considered frozen and new symbol should be introduced in 1.2 namespace, etc. On MFC'ing new symbols to earlier branches, one should use the new namespace. E.g. if you are merging a symbol from 8.0-CURRENT to 7-STABLE then FBSD_1.1 (or whatever it belongs to) should be used. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjS3j4ACgkQi+vbBBjt66CjyACcD8tUQNWM3Y9IuQgFCQlHns05 HH4An3/iozkzyrB/KzysEnHzaf1bX8YW =Djar -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 00:09:13 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F2291065684 for ; Fri, 19 Sep 2008 00:09:13 +0000 (UTC) (envelope-from akulatraxas@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id BBA018FC0A for ; Fri, 19 Sep 2008 00:09:12 +0000 (UTC) (envelope-from akulatraxas@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so37380ywe.13 for ; Thu, 18 Sep 2008 17:09:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=gdbuxqtnVBqR2++5GbfF68UP4IKVBZyfMVDTfBjuBQk=; b=Yk0Hh4yTuUzaAHRe2kezlkPnXzi4e6Q6uAMv3k7bltd+HAB7BJX1dvv5q9vNjT6tyi s70S6M+WqYoGnhXDZSjG6/1+La5HEchTQ93FIKAws8W5tJ2DRTuqQDRdaJ9kOAIk5b1l tavhvnNWqPvTONQjmjWJcN3gLMEFGqcE5rxUI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=PaJhI6TB9ck9CKb9EZXxnJlyGAd7StGw2QzHyyNRTvqPpLwPipDEk2kyfd1dwu1GQ2 U4r6U0xRYgsbdEvuY6ilU3DZS8DNZNz1nxsXNe7pQsCQ8UQO8YN67ij8PJ02FhKQiMtf cHlXXUvsIbE1Tck3KSMvyFpcw1nidKuXiu928= Received: by 10.100.33.11 with SMTP id g11mr6250531ang.110.1221782951481; Thu, 18 Sep 2008 17:09:11 -0700 (PDT) Received: by 10.100.154.3 with HTTP; Thu, 18 Sep 2008 17:09:11 -0700 (PDT) Message-ID: <35e5bf980809181709k73e904d7tc413f9191219309a@mail.gmail.com> Date: Thu, 18 Sep 2008 21:09:11 -0300 From: "Daniel de Oliveira" To: "Michael Proto" In-Reply-To: <1de79840809181057v70cdc206o6f5017ca677bf528@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <35e5bf980809180340j171e39ao3d6bf6732ff4c165@mail.gmail.com> <1de79840809181057v70cdc206o6f5017ca677bf528@mail.gmail.com> Cc: current@freebsd.org Subject: Re: Current using -Os -pipe -march=pentium3m X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 00:09:13 -0000 Hi Michael Thanks for your help. Im using your options here but I have the same error (and yes, Im on the same situation about space). I try to add a new "if" with the path with no luck. My error: cc -Os -fno-strict-aliasing -pipe -march=pentium3m -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica -DHAVE_KERNEL_OPTION_HEADERS -include /usr/src/sys/i386/compile/MJOLNIR/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/usr/src/sys/i386/compile/MJOLNIR -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/uteval.c cc1: warnings being treated as errors /usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/uteval.c: In function 'AcpiUtExecute_CID': /usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/uteval.c:614: warning: 'ObjDesc' may be used uninitialized in this function *** Error code 1 Stop in /usr/src/sys/modules/acpi/acpi. *** Error code 1 Stop in /usr/src/sys/modules/acpi. *** Error code 1 Daniel de Oliveira ---- Network and System Analyst Security Specialist IBM RISC Specialist IBM Storage Specialist Linux/Unix Specialist Linux User #: 405334 On Thu, Sep 18, 2008 at 14:57, Michael Proto wrote: > > > On Thu, Sep 18, 2008 at 6:40 AM, Daniel de Oliveira > wrote: >> >> Hi all >> >> I have some problems here trying to compile my system using.. >> >> CPUTYPE?=pentium3m >> CFLAGS=-Os -pipe >> >> When I take off the CFLAGS, all things works properly. A lot of errors >> in different points occurs (kernel and buildworld), so at this point I >> dont a have log, btw, when I comment CFLAGS lines, everything compiles >> fine. Just for information, is there something wrong with that? >> >> >> >> Daniel de Oliveira >> ---- >> Network and System Analyst >> Security Specialist >> IBM RISC Specialist >> IBM Storage Specialist >> Linux/Unix Specialist >> Linux User #: 405334 >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > Use at your own risk/peril, but I ran into a similar problem trying to > compile 8-CURRENT with -Os (I have a small PCEngines ALIX SBC with a 32MB > flash, so space is at a premium). After several long bouts of > trial-and-error, I found that several apps and libraries won't compile with > -Os, so I've set those to -O and they work. > > Oh, and this is with -fno-strict-aliasing > > Here's my make.conf, it may save you some time: > > CPUTYPE?=pentium-mmx > CFLAGS= -Os -fno-strict-aliasing -pipe > COPTFLAGS= -O -pipe > > .if ${.CURDIR:M*/src/lib/libkse} > CFLAGS= -O -pipe > .endif > .if ${.CURDIR:M*/src/lib/libarchive} > CFLAGS= -O -pipe > .endif > .if ${.CURDIR:M*/src/lib/libngatm} > CFLAGS= -O -pipe > .endif > .if ${.CURDIR:M*/src/lib/librpcsec_gss} > CFLAGS= -O -pipe > .endif > .if ${.CURDIR:M*/src/lib/libthr} > CFLAGS= -O -pipe > .endif > .if ${.CURDIR:M*/src/sbin/geom/*} > CFLAGS= -O -pipe > .endif > .if ${.CURDIR:M*/src/sbin/ggate/*} > CFLAGS= -O -pipe > .endif > .if ${.CURDIR:M*/src/usr.bin/csup} > CFLAGS= -O -pipe > .endif > .if ${.CURDIR:M*/src/usr.sbin/acpi/acpidump} > CFLAGS= -O -pipe > .endif > > > > -Proto > From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 00:58:42 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29FDC1065674 for ; Fri, 19 Sep 2008 00:58:42 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id E9DBE8FC18 for ; Fri, 19 Sep 2008 00:58:41 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.61] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id m8J0weuL020662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 18 Sep 2008 17:58:41 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <48D2F942.4070801@FreeBSD.org> Date: Thu, 18 Sep 2008 17:58:42 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "current@freebsd.org" Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Interface auto-cloning bug or feature? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 00:58:42 -0000 Hi, I've noticed that stat/open call on /dev/tun always creates new interface, despite the fact that existing spare interfaces may be available. I believe that it's a bug, since the whole purpose of auto-cloning is to create new instance only when no existing one could be allocated. At least that's my reading of the manual page for the tun(4). If the sysctl(8) variable net.link.tun.devfs_cloning is non-zero, the tun interface permits opens on the special control device /dev/tun. When this device is opened, tun will return a handle for the lowest unused tun device (use devname(3) to determine which). -Maxim [root@sp1 /usr/home/sobomax]# ifconfig -a tun0: flags=8010 mtu 1500 [root@sp1 /usr/home/sobomax]# stat /dev/tun 67174144 96 crw------- 1 uucp dialer 96 0 "May 2 22:21:28 2008" "May 2 22:21:28 2008" "May 2 22:21:28 2008" "Dec 31 23:59:59 1969" 4096 0 0 /dev/tun [root@sp1 /usr/home/sobomax]# ifconfig -a tun0: flags=8010 mtu 1500 tun1: flags=8010 mtu 1500 [root@sp1 /usr/home/sobomax]# stat /dev/tun 67174144 99 crw------- 1 uucp dialer 99 0 "May 2 22:21:28 2008" "May 2 22:21:28 2008" "May 2 22:21:28 2008" "Dec 31 23:59:59 1969" 4096 0 0 /dev/tun [root@sp1 /usr/home/sobomax]# ifconfig -a tun0: flags=8010 mtu 1500 tun1: flags=8010 mtu 1500 tun2: flags=8010 mtu 1500 [root@sp1 /usr/home/sobomax]# stat /dev/tun 67174144 105 crw------- 1 uucp dialer 105 0 "May 2 22:21:28 2008" "May 2 22:21:28 2008" "May 2 22:21:28 2008" "Dec 31 23:59:59 1969" 4096 0 0 /dev/tun [root@sp1 /usr/home/sobomax]# ifconfig -a tun0: flags=8010 mtu 1500 tun1: flags=8010 mtu 1500 tun2: flags=8010 mtu 1500 tun3: flags=8010 mtu 1500 From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 01:13:23 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50B8D1065673 for ; Fri, 19 Sep 2008 01:13:23 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 152A38FC24 for ; Fri, 19 Sep 2008 01:13:22 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.61] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id m8J1DKki021430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Sep 2008 18:13:20 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <48D2FCB2.8070904@FreeBSD.org> Date: Thu, 18 Sep 2008 18:13:22 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "M. Warner Losh" References: <57AF36D8-0F83-4DF8-BEAA-CF3B59EAA361@rabson.org> <20080304.090741.-1631526462.imp@bsdimp.com> <47CDF0FE.9040405@FreeBSD.org> <20080304.193120.-625041952.imp@bsdimp.com> In-Reply-To: <20080304.193120.-625041952.imp@bsdimp.com> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: gnn@FreeBSD.org, xcllnt@mac.com, current@FreeBSD.org, re@FreeBSD.org Subject: Re: IPSEC/crypto is broken in FreeBSD/powerpc 7.0-RELEASE! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 01:13:23 -0000 Sorry for the delay. After applying the patch I see the following message in the verbose log: Sep 18 23:42:33 sobomac kernel: nexus0: , type (unknown) (no driver attached) Not sure if it's OK or not. M. Warner Losh wrote: > OK. Digging deeper into this problem shows that sparc64 also appears > to do the same things to the nexus bus children that powerpc does. > There may be other nexus devices that do this, and rewriting them to > conform to the x86 conventions would take a little bit of effort. > > I'm starting to think that the architecturally clean way to solve this > issue is to allow children to ask if they have a fixed devclass or a > wildcard one in newbus. This is easy to implement, but as I typed > this up, something inside me rebelled. In this scenario, the newbus > would grow a new function device_is_wildcard() that drivers could > call. > > The other way to fix this is to return a better value from the probe > routine for those devices that attach to the nexus. A quick grep of > the tree suggests that opencrypto is the only MI driver that uses this > trick. There are a few MD drivers that use it as well, but they are > all well controlled. Here's a quick hack. If you want to test this > out without changing newbus, change the cryptosoft.c probe routine to > return (BUS_PROBE_HOOVER - 1) rather than zero. > > Comments? -Maxim From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 01:08:46 2008 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51C431065677 for ; Fri, 19 Sep 2008 01:08:46 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 1D4F78FC24 for ; Fri, 19 Sep 2008 01:08:46 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from [192.168.0.61] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id m8J0upgM020565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 18 Sep 2008 17:56:52 -0700 (PDT) (envelope-from sobomax@sippysoft.com) Message-ID: <48D2F8D5.6020509@sippysoft.com> Date: Thu, 18 Sep 2008 17:56:53 -0700 From: Maxim Sobolev Organization: Sippy Software User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "current@freebsd.org" Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 19 Sep 2008 01:32:19 +0000 Cc: Subject: Interface auto-cloning bug or feature? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 01:08:46 -0000 Hi, I've noticed that stat/open call on /dev/tun always creates new interface, despite the fact that existing spare interfaces may be available. I believe that it's a bug, since the whole purpose of auto-cloning is to create new instance only when no existing one could be allocated. At least that's my reading of the manual page for the tun(4). If the sysctl(8) variable net.link.tun.devfs_cloning is non-zero, the tun interface permits opens on the special control device /dev/tun. When this device is opened, tun will return a handle for the lowest unused tun device (use devname(3) to determine which). -Maxim [root@sp1 /usr/home/sobomax]# ifconfig -a tun0: flags=8010 mtu 1500 [root@sp1 /usr/home/sobomax]# stat /dev/tun 67174144 96 crw------- 1 uucp dialer 96 0 "May 2 22:21:28 2008" "May 2 22:21:28 2008" "May 2 22:21:28 2008" "Dec 31 23:59:59 1969" 4096 0 0 /dev/tun [root@sp1 /usr/home/sobomax]# ifconfig -a tun0: flags=8010 mtu 1500 tun1: flags=8010 mtu 1500 [root@sp1 /usr/home/sobomax]# stat /dev/tun 67174144 99 crw------- 1 uucp dialer 99 0 "May 2 22:21:28 2008" "May 2 22:21:28 2008" "May 2 22:21:28 2008" "Dec 31 23:59:59 1969" 4096 0 0 /dev/tun [root@sp1 /usr/home/sobomax]# ifconfig -a tun0: flags=8010 mtu 1500 tun1: flags=8010 mtu 1500 tun2: flags=8010 mtu 1500 [root@sp1 /usr/home/sobomax]# stat /dev/tun 67174144 105 crw------- 1 uucp dialer 105 0 "May 2 22:21:28 2008" "May 2 22:21:28 2008" "May 2 22:21:28 2008" "Dec 31 23:59:59 1969" 4096 0 0 /dev/tun [root@sp1 /usr/home/sobomax]# ifconfig -a tun0: flags=8010 mtu 1500 tun1: flags=8010 mtu 1500 tun2: flags=8010 mtu 1500 tun3: flags=8010 mtu 1500 From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 01:08:46 2008 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDB361065678; Fri, 19 Sep 2008 01:08:46 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 81EF58FC1E; Fri, 19 Sep 2008 01:08:46 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from [192.168.0.61] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id m8J0nYXs020211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Sep 2008 17:49:35 -0700 (PDT) (envelope-from sobomax@sippysoft.com) Message-ID: <48D2F720.2060608@sippysoft.com> Date: Thu, 18 Sep 2008 17:49:36 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "M. Warner Losh" References: <57AF36D8-0F83-4DF8-BEAA-CF3B59EAA361@rabson.org> <20080304.090741.-1631526462.imp@bsdimp.com> <47CDF0FE.9040405@FreeBSD.org> <20080304.193120.-625041952.imp@bsdimp.com> In-Reply-To: <20080304.193120.-625041952.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 19 Sep 2008 01:32:30 +0000 Cc: re@FreeBSD.ORG, gnn@FreeBSD.ORG, xcllnt@mac.com, current@FreeBSD.ORG Subject: Re: IPSEC/crypto is broken in FreeBSD/powerpc 7.0-RELEASE! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 01:08:47 -0000 Sorry for the delay. After applying the patch I see the following message in the verbose log: Sep 18 23:42:33 sobomac kernel: nexus0: , type (unknown) (no driver attached) Not sure if it's OK or not. M. Warner Losh wrote: > OK. Digging deeper into this problem shows that sparc64 also appears > to do the same things to the nexus bus children that powerpc does. > There may be other nexus devices that do this, and rewriting them to > conform to the x86 conventions would take a little bit of effort. > > I'm starting to think that the architecturally clean way to solve this > issue is to allow children to ask if they have a fixed devclass or a > wildcard one in newbus. This is easy to implement, but as I typed > this up, something inside me rebelled. In this scenario, the newbus > would grow a new function device_is_wildcard() that drivers could > call. > > The other way to fix this is to return a better value from the probe > routine for those devices that attach to the nexus. A quick grep of > the tree suggests that opencrypto is the only MI driver that uses this > trick. There are a few MD drivers that use it as well, but they are > all well controlled. Here's a quick hack. If you want to test this > out without changing newbus, change the cryptosoft.c probe routine to > return (BUS_PROBE_HOOVER - 1) rather than zero. > > Comments? Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 04:16:48 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96D2E1065677 for ; Fri, 19 Sep 2008 04:16:48 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 3810B8FC13 for ; Fri, 19 Sep 2008 04:16:42 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id m8J4GfGt015276; Fri, 19 Sep 2008 00:16:41 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Fri, 19 Sep 2008 00:16:41 -0400 (EDT) Date: Fri, 19 Sep 2008 00:16:41 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Maksim Yevmenkin In-Reply-To: Message-ID: References: <200809180023.m8I0NEJY032390@freefall.freebsd.org> <20080918195049.GQ39652@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kostik Belousov , current@freebsd.org Subject: Re: Fwd: Pending MFC Reminder [cvs commit: src/lib/libc/uuid Symbol.map] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 04:16:48 -0000 On Thu, 18 Sep 2008, Maksim Yevmenkin wrote: >> > emax 2008-09-15 23:54:55 UTC >> > >> > FreeBSD src repository >> > >> > Modified files: >> > lib/libc/uuid Symbol.map >> > Log: >> > SVN rev 183058 on 2008-09-15 23:54:55Z by emax >> > >> > Add uuid_enc,dec_le,be() functions to Symbol.map >> > Pointy hat goes to me. >> > >> > MFC after: 3 days >> > >> > Revision Changes Path >> > 1.3 +4 -0 src/lib/libc/uuid/Symbol.map >> >> >> I has a question against original commit, that I missed when reading >> commit mail. Why the new symbols introduced after 7.0 is released, >> where added to the FBSD_1.0 version ? I think FBSD_1.1 is correct >> there. >> >> Do you object ? Any symbols added to HEAD (8.x) go in FBSD_1.1. Symbols in HEAD always go to the latest version which is FBSD_1.1. Any symbols that are MFC'd, have to go to the _same_ version as they went to in HEAD (FBSD_1.1). What you must not do is MFC symbols to a different version in 7.x (or, more generally, any previous release/branch) than the version from which they came. If newfoo is in FBSD_1.1 in HEAD, then it has to be in FBSD_1.1 in 7.x. If you want to get picky and keep all 7.x versions in FBSD_1.0.x, then you first have to add FBSD_1.0.x in HEAD and add the symbols there. But that has not been the convention to date. Remember that all symbols and versions in 7.x _must_ be present in HEAD before they are MFC'd. HEAD is always a superset of 7.x. If you have added something to 7.x that doesn't exist in the same version as HEAD (in this case, FBSD_1.1), then please back it out and correct it. -- DE From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 04:22:38 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEA10106566B for ; Fri, 19 Sep 2008 04:22:38 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 7786D8FC0C for ; Fri, 19 Sep 2008 04:22:38 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id m8J4MbVC017228; Fri, 19 Sep 2008 00:22:37 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Fri, 19 Sep 2008 00:22:37 -0400 (EDT) Date: Fri, 19 Sep 2008 00:22:37 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: emax@freebsd.org In-Reply-To: Message-ID: References: <200809180023.m8I0NEJY032390@freefall.freebsd.org> <20080918195049.GQ39652@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kostik Belousov , current@freebsd.org, Maksim Yevmenkin Subject: Re: Fwd: Pending MFC Reminder [cvs commit: src/lib/libc/uuid Symbol.map] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 04:22:38 -0000 On Thu, 18 Sep 2008, Maksim Yevmenkin wrote: >> > emax 2008-09-15 23:54:55 UTC >> > >> > FreeBSD src repository >> > >> > Modified files: >> > lib/libc/uuid Symbol.map >> > Log: >> > SVN rev 183058 on 2008-09-15 23:54:55Z by emax >> > >> > Add uuid_enc,dec_le,be() functions to Symbol.map >> > Pointy hat goes to me. >> > >> > MFC after: 3 days >> > >> > Revision Changes Path >> > 1.3 +4 -0 src/lib/libc/uuid/Symbol.map >> >> >> I has a question against original commit, that I missed when reading >> commit mail. Why the new symbols introduced after 7.0 is released, >> where added to the FBSD_1.0 version ? I think FBSD_1.1 is correct >> there. >> >> Do you object ? I just looked at the original commit in revision 1.3. Yes, these symbols should not have been added to 1.0. They need to go into FBSD_1.1. Please fix. Thanks, -- DE From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 05:34:00 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB1B31065672 for ; Fri, 19 Sep 2008 05:34:00 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.236]) by mx1.freebsd.org (Postfix) with ESMTP id 80BF28FC18 for ; Fri, 19 Sep 2008 05:34:00 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: by qb-out-0506.google.com with SMTP id f30so197177qba.35 for ; Thu, 18 Sep 2008 22:33:59 -0700 (PDT) Received: by 10.181.11.3 with SMTP id o3mr3136246bki.105.1221802438906; Thu, 18 Sep 2008 22:33:58 -0700 (PDT) Received: by 10.181.17.8 with HTTP; Thu, 18 Sep 2008 22:33:58 -0700 (PDT) Message-ID: <1de79840809182233j44e956a6l5f5d3c5a9d505ab9@mail.gmail.com> Date: Fri, 19 Sep 2008 01:33:58 -0400 From: "Michael Proto" To: "Daniel de Oliveira" In-Reply-To: <35e5bf980809181709k73e904d7tc413f9191219309a@mail.gmail.com> MIME-Version: 1.0 References: <35e5bf980809180340j171e39ao3d6bf6732ff4c165@mail.gmail.com> <1de79840809181057v70cdc206o6f5017ca677bf528@mail.gmail.com> <35e5bf980809181709k73e904d7tc413f9191219309a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: Current using -Os -pipe -march=pentium3m X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 05:34:00 -0000 On Thu, Sep 18, 2008 at 8:09 PM, Daniel de Oliveira wrote: > Hi Michael > > Thanks for your help. > Im using your options here but I have the same error (and yes, Im on > the same situation about space). > I try to add a new "if" with the path with no luck. > > My error: > > cc -Os -fno-strict-aliasing -pipe -march=pentium3m -Werror -D_KERNEL > -DKLD_MODULE -std=c99 -nostdinc > -I/usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica > -DHAVE_KERNEL_OPTION_HEADERS -include > /usr/src/sys/i386/compile/MJOLNIR/opt_global.h -I. -I@ > -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 > --param large-function-growth=1000 -fno-common > -I/usr/src/sys/i386/compile/MJOLNIR -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -ffreestanding -fstack-protector -fstack-protector -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -c > /usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/uteval.c > cc1: warnings being treated as errors > /usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/uteval.c: > In function 'AcpiUtExecute_CID': > /usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/uteval.c:614: > warning: 'ObjDesc' may be used uninitialized in this function > *** Error code 1 > > Stop in /usr/src/sys/modules/acpi/acpi. > *** Error code 1 > > Stop in /usr/src/sys/modules/acpi. > *** Error code 1 > > > > Daniel de Oliveira > ---- > Network and System Analyst > Security Specialist > IBM RISC Specialist > IBM Storage Specialist > Linux/Unix Specialist > Linux User #: 405334 > > > > On Thu, Sep 18, 2008 at 14:57, Michael Proto wrote: > > > > > > On Thu, Sep 18, 2008 at 6:40 AM, Daniel de Oliveira < > akulatraxas@gmail.com> > > wrote: > >> > >> Hi all > >> > >> I have some problems here trying to compile my system using.. > >> > >> CPUTYPE?=pentium3m > >> CFLAGS=-Os -pipe > >> > >> When I take off the CFLAGS, all things works properly. A lot of errors > >> in different points occurs (kernel and buildworld), so at this point I > >> dont a have log, btw, when I comment CFLAGS lines, everything compiles > >> fine. Just for information, is there something wrong with that? > >> > >> > >> > >> Daniel de Oliveira > >> ---- > >> Network and System Analyst > >> Security Specialist > >> IBM RISC Specialist > >> IBM Storage Specialist > >> Linux/Unix Specialist > >> Linux User #: 405334 > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org" > > > > > > > > Use at your own risk/peril, but I ran into a similar problem trying to > > compile 8-CURRENT with -Os (I have a small PCEngines ALIX SBC with a 32MB > > flash, so space is at a premium). After several long bouts of > > trial-and-error, I found that several apps and libraries won't compile > with > > -Os, so I've set those to -O and they work. > > > > Oh, and this is with -fno-strict-aliasing > > > > Here's my make.conf, it may save you some time: > > > > CPUTYPE?=pentium-mmx > > CFLAGS= -Os -fno-strict-aliasing -pipe > > COPTFLAGS= -O -pipe > > > > .if ${.CURDIR:M*/src/lib/libkse} > > CFLAGS= -O -pipe > > .endif > > .if ${.CURDIR:M*/src/lib/libarchive} > > CFLAGS= -O -pipe > > .endif > > .if ${.CURDIR:M*/src/lib/libngatm} > > CFLAGS= -O -pipe > > .endif > > .if ${.CURDIR:M*/src/lib/librpcsec_gss} > > CFLAGS= -O -pipe > > .endif > > .if ${.CURDIR:M*/src/lib/libthr} > > CFLAGS= -O -pipe > > .endif > > .if ${.CURDIR:M*/src/sbin/geom/*} > > CFLAGS= -O -pipe > > .endif > > .if ${.CURDIR:M*/src/sbin/ggate/*} > > CFLAGS= -O -pipe > > .endif > > .if ${.CURDIR:M*/src/usr.bin/csup} > > CFLAGS= -O -pipe > > .endif > > .if ${.CURDIR:M*/src/usr.sbin/acpi/acpidump} > > CFLAGS= -O -pipe > > .endif > > > > > > > > -Proto > > > I forgot about my kernel compilation options: .if ${.CURDIR:M*/src/sys/*} CFLAGS= -O -pipe COPTFLAGS= -O -pipe .endif -Proto From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 05:45:31 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D89A0106566B for ; Fri, 19 Sep 2008 05:45:31 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outW.internet-mail-service.net (outw.internet-mail-service.net [216.240.47.246]) by mx1.freebsd.org (Postfix) with ESMTP id C36E28FC2A for ; Fri, 19 Sep 2008 05:45:31 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id EFAD62385 for ; Thu, 18 Sep 2008 22:45:31 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 6197C2D600D for ; Thu, 18 Sep 2008 22:45:31 -0700 (PDT) Message-ID: <48D33C7A.7010007@elischer.org> Date: Thu, 18 Sep 2008 22:45:30 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: amd opteron NUMA support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 05:45:31 -0000 Is anyone looking at trying to add specific support for the hyper-transport based numa AMD systems? It would be interesting to know what sort of things Sun did for Solaris for their old x-bus systems which had similar characteristics. with each processor having memory associated with it, and a penalty for accessing memory associated with other CPUS, several things come to mind, including: Obviously, doing a lot of work to stop threads from migrating around. Page replacement of pages that are 'far away' with closer ones over time. CPU or die specific memory allocators. Multiple copies of read-only segments (so that each cpu has it's own copy of the /bin/sh text segment for example). Servicing interrupts on CPUs most closely associated with the IO channels. Now I know SOME work has been done on some of this but it would be good to know if anyone if focusing on this. Julian (who just did a quick course on opteron and has come away quite stunned) From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 07:48:07 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09416106564A for ; Fri, 19 Sep 2008 07:48:07 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id B01B68FC15 for ; Fri, 19 Sep 2008 07:48:06 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p5DC5EDF6.dip.t-dialin.net [93.197.237.246]) by redbull.bpaserver.net (Postfix) with ESMTP id A901C2E1F9; Fri, 19 Sep 2008 09:48:00 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 5938F11D524; Fri, 19 Sep 2008 09:47:57 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.14.2/8.13.8/Submit) id m8J7luCD078285; Fri, 19 Sep 2008 09:47:56 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 19 Sep 2008 09:47:56 +0200 Message-ID: <20080919094756.853818f081ngscbo@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Fri, 19 Sep 2008 09:47:56 +0200 From: "Alexander Leidinger" To: "Daniel de Oliveira" References: <35e5bf980809180340j171e39ao3d6bf6732ff4c165@mail.gmail.com> In-Reply-To: <35e5bf980809180340j171e39ao3d6bf6732ff4c165@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.2) / FreeBSD-8.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: A901C2E1F9.AE5D6 X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, ORDB-RBL, SpamAssassin (not cached, score=-14.7, required 6, BAYES_00 -15.00, MR_NOT_ATTRIBUTED_IP 0.20, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: current@freebsd.org Subject: Re: Current using -Os -pipe -march=pentium3m X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 07:48:07 -0000 Quoting "Daniel de Oliveira" (from Thu, 18 Sep 2008 07:40:02 -0300): > Hi all > > I have some problems here trying to compile my system using.. > > CPUTYPE?=pentium3m > CFLAGS=-Os -pipe You should compare the size with -O2 and -Os. In -current it isn't worth to use it since the import of the new gcc version (long ago). I've seen a lot of bigger files with -Os than with -O2. Bye, Alexander. -- (1) If it's green or it wiggles, it's biology. (2) If it stinks, it's chemistry. (3) If it doesn't work, it's physics. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 08:06:24 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D182A1065676 for ; Fri, 19 Sep 2008 08:06:24 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id 7FCD58FC08 for ; Fri, 19 Sep 2008 08:06:18 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 1FF5EA06DA; Fri, 19 Sep 2008 10:06:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 1359FA06D9; Fri, 19 Sep 2008 10:06:17 +0200 (CEST) Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id F3B24A06D8; Fri, 19 Sep 2008 10:06:16 +0200 (CEST) Received: from wep4035.physik.uni-wuerzburg.de ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2) with ESMTP id 2008091910061686-32362 ; Fri, 19 Sep 2008 10:06:16 +0200 Received: by wep4035.physik.uni-wuerzburg.de (sSMTP sendmail emulation); Fri, 19 Sep 2008 10:06:16 +0200 From: "Alexey Shuvaev" Date: Fri, 19 Sep 2008 10:06:16 +0200 To: John Birrell , jb@freebsd.org Message-ID: <20080919080616.GA44330@wep4035.physik.uni-wuerzburg.de> References: <20080917101013.GA90749@freebsd.org> <20080918211652.GB19958@what-creek.com> MIME-Version: 1.0 In-Reply-To: <20080918211652.GB19958@what-creek.com> Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.18 (2008-05-17) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.0.2|August 07, 2008) at 09/19/2008 10:06:16 AM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2|August 07, 2008) at 09/19/2008 10:06:16 AM, Serialize complete at 09/19/2008 10:06:16 AM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: freebsd-current@freebsd.org Subject: Re: dtrace status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 08:06:24 -0000 On Thu, Sep 18, 2008 at 09:16:52PM +0000, John Birrell wrote: > On Wed, Sep 17, 2008 at 12:10:13PM +0200, Roman Divacky wrote: > > Dtrace was commited 3 months ago and the only things that prevents > > using it "out of the box" is building kernel with WITH_CTF=1. > > > > When is this going to be enabled on default. What is preventing this > > from happening? > > I wonder whether people generally want it enabled by default. > I am not sure for -STABLE but enabling it by default on -CURRENT might be a good idea. Just my 0.02$, Alexey. From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 08:11:44 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BDE11065679 for ; Fri, 19 Sep 2008 08:11:44 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id BEC1E8FC1B for ; Fri, 19 Sep 2008 08:11:43 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so83126eyi.7 for ; Fri, 19 Sep 2008 01:11:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Uz2Uj+D30uNP085yw6c6WpOuaamStRX0Z663rHAKfD4=; b=NaMzybPLa8oQF9jOKnyqlZ2gTyB+cs1tEDMch3kyjHTaXBdTlK0omCxMO7wnULI+k+ hYt/dFBnfDUH7Slz6hJBhorF0FLhN+L500F/TKAhMZFQkXClL+j3oGu/BXg4LBPceRFg BSUEUwo3YWvAt0/kg2AlN/J25560HAYQ2cVqE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=irdbHmlkMMlnyni1gf5ZBKUtA8mAWt9xo15zI5f4cZDAyq3E7KMVYTsB55w/ThntY6 4Rhfp+fluGrbi71rodSCgph7XyuNPAk2gDDhstsfv0CfGpJl7/S0a92V+MxFdGLKu42e Tf7fS/14VA9P3yuAXhoDNhc27Cz/RnsL7Lzl8= Received: by 10.210.105.19 with SMTP id d19mr6320982ebc.110.1221811902400; Fri, 19 Sep 2008 01:11:42 -0700 (PDT) Received: by 10.210.34.13 with HTTP; Fri, 19 Sep 2008 01:11:42 -0700 (PDT) Message-ID: <1d6d20bc0809190111ic50d597tea2ac6a0917c41@mail.gmail.com> Date: Fri, 19 Sep 2008 16:11:42 +0800 From: "Jia-Shiun Li" To: freebsd-current@freebsd.org In-Reply-To: <1d6d20bc0809170846g69311401j7f93f97969756e43@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1d6d20bc0809170846g69311401j7f93f97969756e43@mail.gmail.com> Subject: Re: Unable to boot Asus P5QL-EM w/ acpi enabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 08:11:44 -0000 On Wed, Sep 17, 2008 at 11:46 PM, Jia-Shiun Li wrote: > The mainboard is an ASUS P5QL-EM (Intel G43/ICH10) with BIOS revision 0406. > > dmesg, pciconf, acpidump and kernel config file attached. > Files available at http://jiashiun.googlepages.com/p5ql-em_acpi.tar.gz Jia-Shiun. From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 08:31:57 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5053106564A; Fri, 19 Sep 2008 08:31:57 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (vlk.vlakno.cz [62.168.28.247]) by mx1.freebsd.org (Postfix) with ESMTP id 9A4748FC21; Fri, 19 Sep 2008 08:31:57 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id DDC4C65C56C; Fri, 19 Sep 2008 10:32:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (vlk.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4P80rN-pq0YP; Fri, 19 Sep 2008 10:32:01 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 2B56065C510; Fri, 19 Sep 2008 10:31:59 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.2/8.14.2/Submit) id m8J8VwRi024902; Fri, 19 Sep 2008 10:31:58 +0200 (CEST) (envelope-from rdivacky) Date: Fri, 19 Sep 2008 10:31:58 +0200 From: Roman Divacky To: Alexey Shuvaev Message-ID: <20080919083158.GA24881@freebsd.org> References: <20080917101013.GA90749@freebsd.org> <20080918211652.GB19958@what-creek.com> <20080919080616.GA44330@wep4035.physik.uni-wuerzburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080919080616.GA44330@wep4035.physik.uni-wuerzburg.de> User-Agent: Mutt/1.4.2.3i Cc: jb@freebsd.org, John Birrell , freebsd-current@freebsd.org Subject: Re: dtrace status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 08:31:58 -0000 On Fri, Sep 19, 2008 at 10:06:16AM +0200, Alexey Shuvaev wrote: > On Thu, Sep 18, 2008 at 09:16:52PM +0000, John Birrell wrote: > > On Wed, Sep 17, 2008 at 12:10:13PM +0200, Roman Divacky wrote: > > > Dtrace was commited 3 months ago and the only things that prevents > > > using it "out of the box" is building kernel with WITH_CTF=1. > > > > > > When is this going to be enabled on default. What is preventing this > > > from happening? > > > > I wonder whether people generally want it enabled by default. > > > I am not sure for -STABLE but enabling it by default on -CURRENT might > be a good idea. yeah, definitely. I believe we want dtrace working out of the box, dont we? From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 08:42:03 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0B421065670 for ; Fri, 19 Sep 2008 08:42:03 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id 690928FC0C for ; Fri, 19 Sep 2008 08:42:03 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id B673EA06EE for ; Fri, 19 Sep 2008 10:42:02 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id A7101A06E0 for ; Fri, 19 Sep 2008 10:42:02 +0200 (CEST) Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 91E31A06EA for ; Fri, 19 Sep 2008 10:42:02 +0200 (CEST) Received: from wep4035.physik.uni-wuerzburg.de ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2) with ESMTP id 2008091910420194-32536 ; Fri, 19 Sep 2008 10:42:01 +0200 Received: by wep4035.physik.uni-wuerzburg.de (sSMTP sendmail emulation); Fri, 19 Sep 2008 10:42:01 +0200 From: "Alexey Shuvaev" Date: Fri, 19 Sep 2008 10:42:01 +0200 To: freebsd-current@freebsd.org Message-ID: <20080919084201.GD44330@wep4035.physik.uni-wuerzburg.de> References: <48D2F942.4070801@FreeBSD.org> MIME-Version: 1.0 In-Reply-To: <48D2F942.4070801@FreeBSD.org> Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.18 (2008-05-17) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.0.2|August 07, 2008) at 09/19/2008 10:42:01 AM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2|August 07, 2008) at 09/19/2008 10:42:02 AM, Serialize complete at 09/19/2008 10:42:02 AM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Subject: Re: Interface auto-cloning bug or feature? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 08:42:04 -0000 On Thu, Sep 18, 2008 at 05:58:42PM -0700, Maxim Sobolev wrote: > Hi, > > I've noticed that stat/open call on /dev/tun always creates new > interface, despite the fact that existing spare interfaces may be > available. I believe that it's a bug, since the whole purpose of > auto-cloning is to create new instance only when no existing one could > be allocated. At least that's my reading of the manual page for the tun(4). > > > If the sysctl(8) variable net.link.tun.devfs_cloning is non-zero, > the tun > interface permits opens on the special control device /dev/tun. When > this device is opened, tun will return a handle for the lowest > unused tun > device (use devname(3) to determine which). > > > -Maxim > > [root@sp1 /usr/home/sobomax]# ifconfig -a > tun0: flags=8010 mtu 1500 > [root@sp1 /usr/home/sobomax]# stat /dev/tun > 67174144 96 crw------- 1 uucp dialer 96 0 "May 2 22:21:28 2008" "May 2 > 22:21:28 2008" "May 2 22:21:28 2008" "Dec 31 23:59:59 1969" 4096 0 0 > /dev/tun > [root@sp1 /usr/home/sobomax]# ifconfig -a > tun0: flags=8010 mtu 1500 > tun1: flags=8010 mtu 1500 > [root@sp1 /usr/home/sobomax]# stat /dev/tun > 67174144 99 crw------- 1 uucp dialer 99 0 "May 2 22:21:28 2008" "May 2 > 22:21:28 2008" "May 2 22:21:28 2008" "Dec 31 23:59:59 1969" 4096 0 0 > /dev/tun > [root@sp1 /usr/home/sobomax]# ifconfig -a > tun0: flags=8010 mtu 1500 > tun1: flags=8010 mtu 1500 > tun2: flags=8010 mtu 1500 > [root@sp1 /usr/home/sobomax]# stat /dev/tun > 67174144 105 crw------- 1 uucp dialer 105 0 "May 2 22:21:28 2008" "May > 2 22:21:28 2008" "May 2 22:21:28 2008" "Dec 31 23:59:59 1969" 4096 0 > 0 /dev/tun > [root@sp1 /usr/home/sobomax]# ifconfig -a > tun0: flags=8010 mtu 1500 > tun1: flags=8010 mtu 1500 > tun2: flags=8010 mtu 1500 > tun3: flags=8010 mtu 1500 > Me too. I have seen that using ppp(8) and security/vpnc. Alexey. From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 09:45:31 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69083106567D; Fri, 19 Sep 2008 09:45:31 +0000 (UTC) (envelope-from lme@FreeBSD.org) Received: from mail.0x20.net (mail.ipv6.0x20.net [IPv6:2001:aa8:fffb::3]) by mx1.freebsd.org (Postfix) with ESMTP id 741448FC27; Fri, 19 Sep 2008 09:45:30 +0000 (UTC) (envelope-from lme@FreeBSD.org) Received: from mail.0x20.net (mail.0x20.net [217.69.67.217]) by mail.0x20.net (Postfix) with ESMTP id EED7E3A6B6; Fri, 19 Sep 2008 11:45:28 +0200 (CEST) Received: from 193.109.238.110 ([193.109.238.110]) by 0x20.net (Horde MIME library) with HTTP; Fri, 19 Sep 2008 11:45:28 +0200 Message-ID: <20080919114528.5yzyki2ry8044g4s@0x20.net> X-Priority: 3 (Normal) Date: Fri, 19 Sep 2008 11:45:28 +0200 From: Lars Engels To: John Birrell References: <20080917101013.GA90749@freebsd.org> <20080918211652.GB19958@what-creek.com> In-Reply-To: <20080918211652.GB19958@what-creek.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_6ro98keowc08"; protocol="application/pgp-signature"; micalg="pgp-sha1" Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) Cc: Roman Divacky , jb@freebsd.org, current@freebsd.org Subject: Re: dtrace status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 09:45:31 -0000 This message is in MIME format and has been PGP signed. --=_6ro98keowc08 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit Quoting John Birrell : > On Wed, Sep 17, 2008 at 12:10:13PM +0200, Roman Divacky wrote: >> Dtrace was commited 3 months ago and the only things that prevents >> using it "out of the box" is building kernel with WITH_CTF=1. >> >> When is this going to be enabled on default. What is preventing this >> from happening? > > I wonder whether people generally want it enabled by default. If it doesn't slow anything down, then why not? Are there any FreeBSD specific docs on this? Maybe a short article for /usr/share/doc or a new chapter for the handbook? :-) --=_6ro98keowc08 Content-Type: application/pgp-signature Content-Description: Digitale PGP-Unterschrift Content-Disposition: inline Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAkjTdLgACgkQKc512sD3afjffgCfWnfFZ2fLTkQpwKBZIkwL15bl ihUAoITS1SVk04+oLO1HaEKY/Koqd2tj =Zsx1 -----END PGP SIGNATURE----- --=_6ro98keowc08-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 10:17:01 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B09551065675; Fri, 19 Sep 2008 10:17:01 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:3fb::211]) by mx1.freebsd.org (Postfix) with ESMTP id 7492A8FC19; Fri, 19 Sep 2008 10:17:01 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id D460E1CCDC; Fri, 19 Sep 2008 12:17:00 +0200 (CEST) Date: Fri, 19 Sep 2008 12:17:00 +0200 From: Ed Schouten To: Maxim Sobolev Message-ID: <20080919101700.GS81522@hoeg.nl> References: <48D2F942.4070801@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4ZVTVymsHR1TEBjP" Content-Disposition: inline In-Reply-To: <48D2F942.4070801@FreeBSD.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "current@freebsd.org" Subject: Re: Interface auto-cloning bug or feature? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 10:17:01 -0000 --4ZVTVymsHR1TEBjP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Maxim, * Maxim Sobolev wrote: > I've noticed that stat/open call on /dev/tun always creates new > interface, despite the fact that existing spare interfaces may be > available. I believe that it's a bug, since the whole purpose of > auto-cloning is to create new instance only when no existing one could > be allocated. At least that's my reading of the manual page for the tun(4= ). I'd say the best way to fix this would be to convert tun and tap to devfs_[gs]et_cdevpriv() and turn tun and tap into single device nodes. That's what we've already been doing to bpf, snp, audit_pipe, etc. Unfortunately I'm no expert when it comes to our tun and tap implementations. We should eventually eliminate the dev_stdclone()/clone_create() interface. See the following URL for a list of drivers that still need to be converted: http://fxr.watson.org/fxr/ident?i=3DD_NEEDMINOR --=20 Ed Schouten WWW: http://80386.nl/ --4ZVTVymsHR1TEBjP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkjTfBwACgkQ52SDGA2eCwXQmACdFVPyQeiHBPcHy/kY18v+B/0r +w4An2f/M+xFhiR0tujV2bW6rwHp4CIE =xdMv -----END PGP SIGNATURE----- --4ZVTVymsHR1TEBjP-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 10:18:57 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F14C1065676; Fri, 19 Sep 2008 10:18:57 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:3fb::211]) by mx1.freebsd.org (Postfix) with ESMTP id 639568FC1B; Fri, 19 Sep 2008 10:18:57 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id C4EAF1CCDC; Fri, 19 Sep 2008 12:18:56 +0200 (CEST) Date: Fri, 19 Sep 2008 12:18:56 +0200 From: Ed Schouten To: Maxim Sobolev Message-ID: <20080919101856.GT81522@hoeg.nl> References: <48D2F942.4070801@FreeBSD.org> <20080919101700.GS81522@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wYXww9TlNKyqAMAe" Content-Disposition: inline In-Reply-To: <20080919101700.GS81522@hoeg.nl> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "current@freebsd.org" Subject: Re: Interface auto-cloning bug or feature? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 10:18:57 -0000 --wYXww9TlNKyqAMAe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Ed Schouten wrote: > We should eventually eliminate the dev_stdclone()/clone_create() ^^^^^^^^^^^^ > interface. Correct myself: there's nothing wrong with dev_stdclone - it can be used independently from the clone lists. --=20 Ed Schouten WWW: http://80386.nl/ --wYXww9TlNKyqAMAe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkjTfJAACgkQ52SDGA2eCwUddQCdGkFbPMspJYSOCxQzjJwSL2Nv WW0AnjOWJagJTzTSKEFedkDyOOF6TjMk =F1C8 -----END PGP SIGNATURE----- --wYXww9TlNKyqAMAe-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 11:07:17 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EE631065671 for ; Fri, 19 Sep 2008 11:07:17 +0000 (UTC) (envelope-from r.l.grint@qmul.ac.uk) Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6]) by mx1.freebsd.org (Postfix) with ESMTP id 627068FC0C for ; Fri, 19 Sep 2008 11:07:17 +0000 (UTC) (envelope-from r.l.grint@qmul.ac.uk) Received: from smtp.qmul.ac.uk ([138.37.6.40]) by mail2.qmul.ac.uk with esmtp (Exim 4.66) (envelope-from ) id 1KgcmQ-00014g-GI for current@freebsd.org; Fri, 19 Sep 2008 11:00:25 +0100 Received: from misu10589.admin.qmw.ac.uk ([138.37.16.31] helo=[192.168.40.128]) by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1KgcmQ-00009e-Be for current@freebsd.org; Fri, 19 Sep 2008 11:00:02 +0100 Message-ID: <48D37821.9010406@qmul.ac.uk> Date: Fri, 19 Sep 2008 11:00:01 +0100 From: Richard Grint User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: current@freebsd.org References: <48D33C7A.7010007@elischer.org> In-Reply-To: <48D33C7A.7010007@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sender-Host-Address: 138.37.16.31 X-QM-Scan-Virus: ClamAV says the message is clean X-QM-Scan-Virus: virusscan says the message is clean Cc: Subject: Re: amd opteron NUMA support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 11:07:17 -0000 Julian this may be of interest. Not Solaris and not for that matter kernel related but does give a lot of info (if you search other bits of this) how NUMA affects complex processes such as Oracle and Linux. Kevin Closson did a lot of Oracle tuning for the old Sequent boxes. http://kevinclosson.wordpress.com/2007/01/18/oracle-on-opteron-the-numa-angle-part-i/ Julian Elischer wrote: > Is anyone looking at trying to add specific support for the > hyper-transport based numa AMD systems? > > It would be interesting to know what sort of things Sun did > for Solaris for their old x-bus systems which had > similar characteristics. > > with each processor having memory associated with it, > and a penalty for accessing memory associated with other CPUS, > several things come to mind, including: > > Obviously, doing a lot of work to stop threads from migrating around. > Page replacement of pages that are 'far away' with closer ones over time. > CPU or die specific memory allocators. > Multiple copies of read-only segments (so that each cpu has it's own > copy of the /bin/sh text segment for example). > Servicing interrupts on CPUs most closely associated with the IO > channels. > > Now I know SOME work has been done on some of this > but it would be good to know if anyone if focusing on this. > > > Julian > (who just did a quick course on opteron and has come away quite stunned) > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 11:09:47 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F8391065673; Fri, 19 Sep 2008 11:09:47 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from services.rulez.sk (services.rulez.sk [92.240.234.125]) by mx1.freebsd.org (Postfix) with ESMTP id E65058FC0A; Fri, 19 Sep 2008 11:09:46 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from localhost (services.rulez.sk [92.240.234.125]) by services.rulez.sk (Postfix) with ESMTP id 2AD9313345E3; Fri, 19 Sep 2008 12:53:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.rulez.sk ([92.240.234.125]) by localhost (services.rulez.sk [92.240.234.125]) (amavisd-new, port 10024) with ESMTP id BYqfLahTSSph; Fri, 19 Sep 2008 12:53:55 +0200 (CEST) Received: from hosting.cia.sk (hosting.cia.sk [92.240.234.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by services.rulez.sk (Postfix) with ESMTPS id 78FC413345D7; Fri, 19 Sep 2008 12:53:55 +0200 (CEST) Received: (from www@localhost) by hosting.cia.sk (8.14.2/8.14.2/Submit) id m8JArtjR033526; Fri, 19 Sep 2008 12:53:55 +0200 (CEST) (envelope-from danger@FreeBSD.org) X-Authentication-Warning: hosting.cia.sk: www set sender to danger@FreeBSD.org using -f To: Lars Engels MIME-Version: 1.0 Date: Fri, 19 Sep 2008 12:53:55 +0200 From: Daniel Gerzo Organization: The FreeBSD Project In-Reply-To: <20080919114528.5yzyki2ry8044g4s@0x20.net> References: <20080917101013.GA90749@freebsd.org> <20080918211652.GB19958@what-creek.com> <20080919114528.5yzyki2ry8044g4s@0x20.net> X-Priority: 5 (Lowest) Message-ID: X-Sender: danger@FreeBSD.org User-Agent: RoundCube Webmail/0.2a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: Roman Divacky , jb@FreeBSD.org, John Birrell , current@FreeBSD.org Subject: Re: dtrace status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 11:09:47 -0000 Hello guys, > Are there any FreeBSD specific docs on this? Maybe a short article for > /usr/share/doc or a new chapter for the handbook? :-) I think Tom Rhodes is working on the Handbook chapter in collaboration with John. -- Best regards Daniel Geržo From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 11:33:20 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1260B1065673 for ; Fri, 19 Sep 2008 11:33:20 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id D218E8FC17 for ; Fri, 19 Sep 2008 11:33:19 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.61] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id m8JBXIjZ054042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Sep 2008 04:33:19 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <48D38DFF.8000803@FreeBSD.org> Date: Fri, 19 Sep 2008 04:33:19 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Alexey Shuvaev References: <48D2F942.4070801@FreeBSD.org> <20080919084201.GD44330@wep4035.physik.uni-wuerzburg.de> In-Reply-To: <20080919084201.GD44330@wep4035.physik.uni-wuerzburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Interface auto-cloning bug or feature? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 11:33:20 -0000 Alexey Shuvaev wrote: >> [root@sp1 /usr/home/sobomax]# ifconfig -a >> tun0: flags=8010 mtu 1500 >> tun1: flags=8010 mtu 1500 >> tun2: flags=8010 mtu 1500 >> tun3: flags=8010 mtu 1500 >> > Me too. > I have seen that using ppp(8) and security/vpnc. That what has caused me to look into this issue. You can find patch for security/vpnc to prevent unbounded interface cloning here: http://sobomax.sippysoft.com/~sobomax/vpnc.diff -Maxim From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 12:12:13 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28C7A1065678 for ; Fri, 19 Sep 2008 12:12:12 +0000 (UTC) (envelope-from annona2@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.185]) by mx1.freebsd.org (Postfix) with ESMTP id 042A48FC18 for ; Fri, 19 Sep 2008 12:12:11 +0000 (UTC) (envelope-from annona2@gmail.com) Received: by ti-out-0910.google.com with SMTP id d27so238824tid.3 for ; Fri, 19 Sep 2008 05:12:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:message-id:date:from :to:subject:user-agent:mime-version:content-type; bh=TE0flZyo8XJrxEH8AbuTW2dF+bQUi3CqwKHiYqUNaBM=; b=nCHhWZ3jdiYcN0cn3isXUoSelvmMSAkuEPBfy2IYg+5Hj38FPzLEkfUhlVqA2h2Q+4 2fA4GIAkiKMwMwlSlhUkD2yW8QUrGBFBOkot025Yy/qpvIXeG944KrhxQOEWhA0Mvbhf oFkqGfqgz4g/M7Z1ZpcwIS0owWqeQpxmfjtFI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:user-agent:mime-version :content-type; b=DsmjZv/T+R0v7yxrdIg1lcRVHESNhJgIWRCw56kQ8lNRKlUqlKH3vdnrJ5o6jiib2B 2JaqsTXSgPYBXJ9Ga/nom+tnAybNT6KWn/3I/lnmfkOPWktqNMNhsOpRMC+FhbcuIMiN aSuARHnlm4rGAbQH3v8NRkMbTVnqtgt4RTM/o= Received: by 10.110.11.1 with SMTP id 1mr7129149tik.53.1221826330805; Fri, 19 Sep 2008 05:12:10 -0700 (PDT) Received: from softbank219001162114.bbtec.net ( [219.1.162.114]) by mx.google.com with ESMTPS id w12sm623194tib.1.2008.09.19.05.12.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Sep 2008 05:12:09 -0700 (PDT) Received: from softbank219001162114.bbtec.net (localhost [127.0.0.1]) by softbank219001162114.bbtec.net (8.14.3/8.14.3) with ESMTP id m8JCC5Tc001784 for ; Fri, 19 Sep 2008 21:12:05 +0900 (JST) (envelope-from annona2@gmail.com) Message-Id: <200809191212.m8JCC5Tc001784@softbank219001162114.bbtec.net> Date: Fri, 19 Sep 2008 21:12:05 +0900 From: Gen Otsuji To: freebsd-current@freebsd.org User-Agent: Wanderlust/2.15.5 MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: Help me! about MCP78(GF8200) chipset X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 12:12:13 -0000 Hello, I don't speak English but I'll try. BIOSTAR TF8200A2+ have Nvidia MCP78(GForce 8200 chipset). but kernel doesn't enable SATA mode. my HDD is SATA300 but atacontrol mode ad6 is, current mode = UDMA33 and pciconf -lcv ( which I think related ) is, none0@pci0:0:0:0: class=0x050000 card=0x340b1565 chip=0x075410de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' class = memory subclass = RAM cap 08[94] = HT unknown d007 cap 08[60] = HT retry mode cap 08[44] = HT slave cap 08[d0] = HT unknown e000 isab0@pci0:0:1:0: class=0x060100 card=0x340b1565 chip=0x075c10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' class = bridge subclass = PCI-ISA ichsmb0@pci0:0:1:1: class=0x0c0500 card=0x340b1565 chip=0x075210de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' class = serial bus subclass = SMBus cap 01[44] = powerspec 2 supports D0 D3 current D0 none1@pci0:0:1:2: class=0x050000 card=0x340b1565 chip=0x075110de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' class = memory subclass = RAM none2@pci0:0:1:3: class=0x0b4000 card=0x340b1565 chip=0x075310de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' class = processor none3@pci0:0:1:4: class=0x050000 card=0x340b1565 chip=0x056810de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' class = memory subclass = RAM ohci0@pci0:0:2:0: class=0x0c0310 card=0x340b1565 chip=0x077b10de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' class = serial bus subclass = USB cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 ehci0@pci0:0:2:1: class=0x0c0320 card=0x340b1565 chip=0x077c10de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' class = serial bus subclass = USB cap 0a[44] = EHCI Debug Port at offset 0xa0 in map 0x14 cap 01[80] = powerspec 2 supports D0 D1 D2 D3 current D0 ohci1@pci0:0:4:0: class=0x0c0310 card=0x340b1565 chip=0x077d10de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' class = serial bus subclass = USB cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 ehci1@pci0:0:4:1: class=0x0c0320 card=0x340b1565 chip=0x077e10de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' class = serial bus subclass = USB cap 0a[44] = EHCI Debug Port at offset 0xa0 in map 0x14 cap 01[80] = powerspec 2 supports D0 D1 D2 D3 current D0 atapci0@pci0:0:6:0: class=0x01018a card=0x340b1565 chip=0x075910de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' class = mass storage subclass = ATA cap 01[44] = powerspec 2 supports D0 D3 current D0 pcm0@pci0:0:7:0: class=0x040300 card=0x82131565 chip=0x077410de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' class = multimedia cap 01[44] = powerspec 2 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 08[6c] = HT MSI fixed address window disabled at 0xfee00000 pcib1@pci0:0:8:0: class=0x060401 card=0x340b1565 chip=0x075a10de rev=0xa1 hdr=0x01 vendor = 'Nvidia Corp' class = bridge subclass = PCI-PCI cap 0d[b8] = PCI Bridge card=0x340b1565 cap 08[8c] = HT MSI address window disabled at 0xfee00000 atapci1@pci0:0:9:0: class=0x010185 card=0x54091565 chip=0x0ad010de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' class = mass storage subclass = ATA cap 01[44] = powerspec 2 supports D0 D3 current D0 cap 12[8c] = unknown cap 05[b0] = MSI supports 8 messages, 64 bit cap 08[ec] = HT MSI fixed address window disabled at 0xfee00000 pcib2@pci0:0:11:0: class=0x060400 card=0x340b1565 chip=0x056910de rev=0xa1 hdr=0x01 vendor = 'Nvidia Corp' class = bridge subclass = PCI-PCI cap 0d[40] = PCI Bridge card=0x340b1565 cap 01[48] = powerspec 2 supports D0 D3 current D0 cap 08[60] = HT MSI address window disabled at 0xfee00000 pcib3@pci0:0:16:0: class=0x060400 card=0x340b1565 chip=0x077810de rev=0xa1 hdr=0x01 vendor = 'Nvidia Corp' class = bridge subclass = PCI-PCI cap 0d[40] = PCI Bridge card=0x340b1565 cap 01[48] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 2 messages, 64 bit cap 08[60] = HT MSI address window enabled at 0xfee00000 cap 10[80] = PCI-Express 2 root port pcib4@pci0:0:18:0: class=0x060400 card=0x340b1565 chip=0x075b10de rev=0xa1 hdr=0x01 vendor = 'Nvidia Corp' class = bridge subclass = PCI-PCI cap 0d[40] = PCI Bridge card=0x340b1565 cap 01[48] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 2 messages, 64 bit cap 08[60] = HT MSI address window enabled at 0xfee00000 cap 10[80] = PCI-Express 1 root port pcib5@pci0:0:19:0: class=0x060400 card=0x340b1565 chip=0x077a10de rev=0xa1 hdr=0x01 vendor = 'Nvidia Corp' class = bridge subclass = PCI-PCI cap 0d[40] = PCI Bridge card=0x340b1565 cap 01[48] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 2 messages, 64 bit cap 08[60] = HT MSI address window enabled at 0xfee00000 cap 10[80] = PCI-Express 1 root port pcib6@pci0:0:20:0: class=0x060400 card=0x340b1565 chip=0x077a10de rev=0xa1 hdr=0x01 vendor = 'Nvidia Corp' class = bridge subclass = PCI-PCI cap 0d[40] = PCI Bridge card=0x340b1565 cap 01[48] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 2 messages, 64 bit cap 08[60] = HT MSI address window enabled at 0xfee00000 cap 10[80] = PCI-Express 1 root port please help me! Gen Otsuji From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 15:07:57 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B38791065679 for ; Fri, 19 Sep 2008 15:07:57 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) by mx1.freebsd.org (Postfix) with ESMTP id 7706E8FC1E for ; Fri, 19 Sep 2008 15:07:57 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by alto.onthenet.com.au (Postfix) with ESMTP id D1BAA1163E; Sat, 20 Sep 2008 00:49:36 +1000 (EST) Received: from peter-grehans-power-mac-g5.local (dsl-63-249-90-35.cruzio.com [63.249.90.35]) by dommail.onthenet.com.au (MOS 3.8.6-GA) with ESMTP id EIR25663 (AUTH peterg@ptree32.com.au); Sat, 20 Sep 2008 00:48:55 +1000 (EST) Message-ID: <48D3BBFD.4040403@freebsd.org> Date: Fri, 19 Sep 2008 07:49:33 -0700 From: Peter Grehan User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Julian Elischer References: <20080919120017.1D44810656A3@hub.freebsd.org> In-Reply-To: <20080919120017.1D44810656A3@hub.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: re: amd opteron NUMA support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: grehan@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 15:07:57 -0000 Hi Julian, > Is anyone looking at trying to add specific support for the > hyper-transport based numa AMD systems? You don't have to do anything. The penalty for remote access is hidden with caching. It's only hugely large working sets that would show the difference, and for those, the memory is probably set up interleaved to average out the worst-case behaviour. At least that was the NetApp quad-socket experience with the older 8xx Opterons and up to 2-hop trips for slow DDR2 RAM. These days, the 8xxx provide a cross-link, so you only have to deal with a single hop in a quad system. > with each processor having memory associated with it, > and a penalty for accessing memory associated with other CPUS, > several things come to mind, including: > > Obviously, doing a lot of work to stop threads from migrating around. > Page replacement of pages that are 'far away' with closer ones over time. ... > CPU or die specific memory allocators. That is certainly possible, though an experiment I witnessed with putting pcpu data in per-CPU pages made no difference, since caches do their job. > Multiple copies of read-only segments (so that each cpu has it's own > copy of the /bin/sh text segment for example). Try dealing with the debugger issues :) > Servicing interrupts on CPUs most closely associated with the IO channels. Once again, little to no difference. Any extra latency incurred with the HT interrupt packet traversing an extra hop is lost in the noise. > Now I know SOME work has been done on some of this > but it would be good to know if anyone if focusing on this. Linux has APIs for NUMA memory allocation. SGI did a lot of work for Irix on their large NUMA machines. later, Peter. From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 15:32:20 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6866A1065680 for ; Fri, 19 Sep 2008 15:32:20 +0000 (UTC) (envelope-from annona2@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.185]) by mx1.freebsd.org (Postfix) with ESMTP id E3AC98FC21 for ; Fri, 19 Sep 2008 15:32:13 +0000 (UTC) (envelope-from annona2@gmail.com) Received: by ti-out-0910.google.com with SMTP id d27so273863tid.3 for ; Fri, 19 Sep 2008 08:32:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:message-id:date:from :to:subject:user-agent:mime-version:content-type; bh=Go/tyXqMdjBtb9J5dww7aXl/tzQ/2HsJRUzxMWOl7dE=; b=bu0Saj9H50ZsrbMfOk9V2dJNxgKn2r+oRTmQTDSIlvzKFsdVDiYMzNfUTFO2WXXGyx 1alYTo6+/vnpDfCxbdvzf1nJybQWo+6yJ1M7HD3V35+FmNWll0Is/RqwktV8WM+7AZ+w RC36+QrdWiB4HlX5c6ya6P8yh/JU8Ypoiv+g0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:user-agent:mime-version :content-type; b=DcDvB/iFMlJe1B+e/WRvIQR4z48kPLp7G0zQnHSUrfrGCTjp4aYb5qnsEalfenV+ad Vx1UvI3vRWRRWIf96r1uDZ0SjxaHKWbvPB7jK6cz1Ttq/ec6OJ+JYFf0q5G/r2mWF0b0 KzRnxsmL19y8U8QPm+6uPaNlZNf41IvTUMI4A= Received: by 10.110.14.3 with SMTP id 3mr267198tin.55.1221838332816; Fri, 19 Sep 2008 08:32:12 -0700 (PDT) Received: from softbank219001162114.bbtec.net ( [219.1.162.114]) by mx.google.com with ESMTPS id d4sm1561949tib.13.2008.09.19.08.32.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Sep 2008 08:32:12 -0700 (PDT) Received: from softbank219001162114.bbtec.net (localhost [127.0.0.1]) by softbank219001162114.bbtec.net (8.14.3/8.14.3) with ESMTP id m8JFW862001466 for ; Sat, 20 Sep 2008 00:32:08 +0900 (JST) (envelope-from annona2@gmail.com) Message-Id: <200809191532.m8JFW862001466@softbank219001162114.bbtec.net> Date: Sat, 20 Sep 2008 00:32:06 +0900 From: Gen Otsuji To: freebsd-current@freebsd.org User-Agent: Wanderlust/2.15.5 MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: Re: Help me! about MCP78(GF8200) chipset X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 15:32:20 -0000 Hello, After searching in the internet, I've found the link http://www.nabble.com/new-SATA-chipsets-support-td16032419.html . And FreeBSD is not wrong, But BIOS setting was wrong. changing IDE setting SATAmode to AHCI mode and I've got SATA300 mode ad6. Thank you for the internet! and mailing list! and I hope this would help for someone else! Sincerly, Gen Otsuji -- annona2 means a-no-natsu in Japanese and "that summer" in English -- From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 15:54:06 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 446C11065671 for ; Fri, 19 Sep 2008 15:54:06 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx1.freebsd.org (Postfix) with ESMTP id BAD9A8FC1B for ; Fri, 19 Sep 2008 15:54:05 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so137208eyi.7 for ; Fri, 19 Sep 2008 08:54:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Bq0cX41JOJ7WoQpY1cY7fKlBob/3JunTyJjza/9TSxM=; b=ABSNqt/t4i0pkxnYH0aATIZnhCjtZxhyRF3ozci7+AvSN0ScbVEOXYTpFSn8x8rr3D zL0pftNt+CcUzQZk4pnCmt6ICVAF0bD7XZnq0LHDebq6otXALCUwj16GnkIRzqi+zdjP NlhUv+kxmKgPNDw8FTSUXbREJABdL1E1ksmMI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ML7ctH9PZkp4vwoH3hxAFcG18ZJyH9XcAlf5n9zR7bY2AeF8NRrjMuwJJoerM+t2yx vcbMmrkLsFrkHrh3uuw1eRMbd7iTO7aX9hAIJo71gbmdDPvcESKp6plIttSXhM3MHAJc n/zXWcBKMHGXEsjEMplUhzUGK6wtdFFkFWNwQ= Received: by 10.86.80.17 with SMTP id d17mr2101906fgb.33.1221839643206; Fri, 19 Sep 2008 08:54:03 -0700 (PDT) Received: by 10.86.62.1 with HTTP; Fri, 19 Sep 2008 08:54:03 -0700 (PDT) Message-ID: Date: Fri, 19 Sep 2008 08:54:03 -0700 From: "Maksim Yevmenkin" To: "Daniel Eischen" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200809180023.m8I0NEJY032390@freefall.freebsd.org> <20080918195049.GQ39652@deviant.kiev.zoral.com.ua> Cc: Kostik Belousov , current@freebsd.org Subject: Re: Fwd: Pending MFC Reminder [cvs commit: src/lib/libc/uuid Symbol.map] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 15:54:06 -0000 On 9/18/08, Daniel Eischen wrote: > On Thu, 18 Sep 2008, Maksim Yevmenkin wrote: > > > > > > > > emax 2008-09-15 23:54:55 UTC > > > > > > > > FreeBSD src repository > > > > > > > > Modified files: > > > > lib/libc/uuid Symbol.map > > > > Log: > > > > SVN rev 183058 on 2008-09-15 23:54:55Z by emax > > > > > > > > Add uuid_enc,dec_le,be() functions to Symbol.map > > > > Pointy hat goes to me. > > > > > > > > MFC after: 3 days > > > > > > > > Revision Changes Path > > > > 1.3 +4 -0 src/lib/libc/uuid/Symbol.map > > > > > > > > > I has a question against original commit, that I missed when reading > > > commit mail. Why the new symbols introduced after 7.0 is released, > > > where added to the FBSD_1.0 version ? I think FBSD_1.1 is correct > > > there. > > > > > > Do you object ? > > > > > > > I just looked at the original commit in revision 1.3. Yes, > these symbols should not have been added to 1.0. They need > to go into FBSD_1.1. > > Please fix. ok, fixed. sorry about this. it will teach me ask next time before committing :) now, where is that pointy hat again? :) pass it here :) thanks, max From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 16:09:22 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6E4E1065675; Fri, 19 Sep 2008 16:09:22 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from ftp.translate.ru (ftp.translate.ru [195.131.4.140]) by mx1.freebsd.org (Postfix) with ESMTP id 69FC48FC1F; Fri, 19 Sep 2008 16:09:22 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from desktop.home.serebryakov.spb.ru (unknown [89.163.10.141]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id D7E8213DF8E; Fri, 19 Sep 2008 19:50:02 +0400 (MSD) Date: Fri, 19 Sep 2008 19:50:03 +0400 From: Lev Serebryakov X-Mailer: The Bat! (v3.99.3) Professional Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1161333663.20080919195003@serebryakov.spb.ru> To: Peter Grehan In-Reply-To: <48D3BBFD.4040403@freebsd.org> References: <20080919120017.1D44810656A3@hub.freebsd.org> <48D3BBFD.4040403@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Julian Elischer Subject: Re[2]: amd opteron NUMA support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 16:09:22 -0000 Hello, Peter. You wrote 19 ???????? 2008 ?., 18:49:33: >> Is anyone looking at trying to add specific support for the >> hyper-transport based numa AMD systems? > You don't have to do anything. The penalty for remote access is hidden > with caching. It's only hugely large working sets that would show the > difference, and for those, the memory is probably set up interleaved to > average out the worst-case behaviour. It is not perfectly true. New Java versions have NUMA-aware memory allocator, which interacts with OS (Solaris is best an linux is much worse in providin adequate NUMA configuration information to userland) and this gives about +15% on 4-socket Opteron system and +200% on SunFire 15K with 72 sockets (of UltraSPARC, so SunFire expirience is not too releveant for FreeBSD) on typical benchmarks. -- // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 16:20:43 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 292DE106567C for ; Fri, 19 Sep 2008 16:20:43 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.freebsd.org (Postfix) with ESMTP id ABDF98FC27 for ; Fri, 19 Sep 2008 16:20:42 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so986018uge.39 for ; Fri, 19 Sep 2008 09:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=r8rCprG7oY230M2U1ABTP+hNY4p+dN/irntcK3CNLBQ=; b=ndAKbMQdB1awMHFWmPpZjcxkI1D2Q+xpOHiR+2DrIzBMRvc4p0kgfMVcUy/PiK7bqr 9McwiNf+tAdidj9BzKxlbcawC0DXBIAsboXL1C0mowDcnb21WpHgLG2WMhNO+HusRZS6 QThcXje8Hg+rmoM4BHyl4GFGNZGXC3I9BdoSc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=coRVwCEB8g4hcyhD/B+0ZnH+VQj6zHIT6jytcgSs0T7rPsNbCPQXBrEOtC2fKErYis ki9XoYpw3fHE72HoTvEGjog4IpIcm2RIVIS8K+Gzfgn84GUwMZ+RyGmqaKZ5RGO8V4QA k/4G8eK2oxtaaoaMdxwXvZUfk6AtbSs8VRkSk= Received: by 10.86.82.6 with SMTP id f6mr2129555fgb.53.1221841241340; Fri, 19 Sep 2008 09:20:41 -0700 (PDT) Received: by 10.86.62.1 with HTTP; Fri, 19 Sep 2008 09:20:41 -0700 (PDT) Message-ID: Date: Fri, 19 Sep 2008 09:20:41 -0700 From: "Maksim Yevmenkin" To: "Eygene Ryabinkin" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080917161633.9E2F717101@shadow.codelabs.ru> Cc: rik@freebsd.org, current@freebsd.org, bug-followup@freebsd.org Subject: Re: kern/127446: [patch] fix race in sys/dev/kbdmux/kbdmux.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 16:20:43 -0000 [moving to -current] On 9/18/08, Eygene Ryabinkin wrote: > Me again. > > > Thu, Sep 18, 2008 at 11:10:17AM +0400, Eygene Ryabinkin wrote: > > OK, I had tried substituting KBDMUX_LOCK/UNLOCK with Giant operations -- > > it works as expected. > > > Tried my initial patch on some 7.0-PRERELEASE -- it locks keyboard when > geli asks for the password. Had not much time to dig it out, will try > to do it as soon as I can. Substituting KBDMUX_LOCK/UNLOCK with Giant > locking helps even on this FreeBSD version. > > More testing needed, may be there are some other issues that aren't > revealing themselves... did you have a chance to do some testing? i tried substituting KBDMUX_LOCK/UNLOCK with Giant locking here locally and played with a couple of keyboards under X and console. no apparent issues or witness complains. would it be ok for me to commit this? --- kbdmux.c.orig 2008-07-29 14:21:20.000000000 -0700 +++ kbdmux.c 2008-09-19 09:02:54.000000000 -0700 @@ -104,9 +104,11 @@ #define KBDMUX_LOCK_DESTROY(s) -#define KBDMUX_LOCK(s) +#define KBDMUX_LOCK(s) \ + mtx_lock(&Giant) -#define KBDMUX_UNLOCK(s) +#define KBDMUX_UNLOCK(s) \ + mtx_unlock(&Giant) #define KBDMUX_LOCK_ASSERT(s, w) thanks, max From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 16:58:37 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04024106566C for ; Fri, 19 Sep 2008 16:58:37 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id 8ADF68FC08 for ; Fri, 19 Sep 2008 16:58:36 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so147281eyi.7 for ; Fri, 19 Sep 2008 09:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=+muT3GQQRE4zXi4AN0OYfFtjFUaBS01kr1uGNs8W60g=; b=aIM1Cpjz+BSq3TR1xE/sb0XVRt7DDOm36evvVv/rVSL2SKyBJBeztKwJWARA14gbZz Z3IPQq3NrjvPsXv3hufeE9Mg+sjwFnRxJr4DqfFtL+STt87pkwJQijALQTHhvSPt8xwl 5mk2muyJmLa5UiU9mpHq9zGcApdM2MBbAdzHk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=jlvowLuO9EbI7GoF3ytdRtluPdioDZGA1iQ/cDLe8/WeXeazKgVMDKC84Qq2TVAAkP C8oUbxAtmIh8w5GK7sEnTEEqPqVoh1mBHSQYxwZL3JyODtiIn211CI6MFAhNmMkkVsEn /f5MZTCT/5v+SrFpF/4dSh/n1a25z4cInJMfQ= Received: by 10.86.79.19 with SMTP id c19mr2179278fgb.79.1221843515053; Fri, 19 Sep 2008 09:58:35 -0700 (PDT) Received: by 10.86.62.1 with HTTP; Fri, 19 Sep 2008 09:58:34 -0700 (PDT) Message-ID: Date: Fri, 19 Sep 2008 09:58:35 -0700 From: "Maksim Yevmenkin" To: "Maxim Sobolev" In-Reply-To: <48D2F942.4070801@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48D2F942.4070801@FreeBSD.org> Cc: "current@freebsd.org" Subject: Re: Interface auto-cloning bug or feature? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 16:58:37 -0000 On 9/18/08, Maxim Sobolev wrote: > Hi, > > I've noticed that stat/open call on /dev/tun always creates new > interface, despite the fact that existing spare interfaces may be > available. I believe that it's a bug, since the whole purpose of > auto-cloning is to create new instance only when no existing one could > be allocated. At least that's my reading of the manual page for the tun(4). > > > If the sysctl(8) variable net.link.tun.devfs_cloning is non-zero, > the tun > interface permits opens on the special control device /dev/tun. When > this device is opened, tun will return a handle for the lowest > unused tun > device (use devname(3) to determine which). > yes, that is a bug/feature depending on how you look at it. basically, when /dev/tap,tun,vkbdctl is opened, unit is == -1. clone_create() runs over clonedevs list and tries to match unit (and it cant because unit is -1). so it end up allocating a new one. it would have been all fine, except the clone is not destroyed when /dev/tap is closed. at some point it used to be that tap/tun instances were removed as soon as device was closed. and, of course, network interfaces were also completely removed when character device was closed. i recall few people complained about this. i think it also was causing problems with some ports (vmware perhaps?) thanks, max From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 18:40:08 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C48691065676 for ; Fri, 19 Sep 2008 18:40:08 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by mx1.freebsd.org (Postfix) with ESMTP id 97F3C8FC12 for ; Fri, 19 Sep 2008 18:40:08 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so489551rvf.43 for ; Fri, 19 Sep 2008 11:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=B/4GHLkw/3ZsjHpqK88h79duBcnVAn3+FHNPRTviYJ0=; b=ojG31pQf49j1mObtDBuWX8a1qy5EP++HOB+UkcWUxGP/hNyTTwpq1vOvG8ZCP92/XN pu3xEvw41Gd4rI+t/mhUoQWTuJgYT4yfbVFUY3TMHld5ZFjL+zqfrQ40tQmtD+VVIbJh PDaR5ESrGlfU1pWz4HyYTGVvDlRGuwHGK9nOc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=n7D+BGHBXjzr8xihdHQj1696nO4wEJ88OTRUHfIaOFTMzhVQeBqfHSZbioXyByuTzZ AeZKpRx2GXe/lbK6eUIh/6BNc2BGZ/EXSN4s5rIzDU9w1Jm7CVW7LdjCW8FoMvhFbp/U 3F9hQDdtCK+15/73wZJdCNHcttdsqjyyAwy3c= Received: by 10.141.34.12 with SMTP id m12mr267848rvj.26.1221849608126; Fri, 19 Sep 2008 11:40:08 -0700 (PDT) Received: by 10.141.197.13 with HTTP; Fri, 19 Sep 2008 11:40:07 -0700 (PDT) Message-ID: Date: Fri, 19 Sep 2008 11:40:07 -0700 From: "Maksim Yevmenkin" To: "Ed Schouten" In-Reply-To: <20080919101700.GS81522@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48D2F942.4070801@FreeBSD.org> <20080919101700.GS81522@hoeg.nl> Cc: "current@freebsd.org" Subject: Re: Interface auto-cloning bug or feature? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 18:40:08 -0000 On 9/19/08, Ed Schouten wrote: > Hello Maxim, > > > * Maxim Sobolev wrote: > > I've noticed that stat/open call on /dev/tun always creates new > > interface, despite the fact that existing spare interfaces may be > > available. I believe that it's a bug, since the whole purpose of > > auto-cloning is to create new instance only when no existing one could > > be allocated. At least that's my reading of the manual page for the tun(4). > > > I'd say the best way to fix this would be to convert tun and tap to > devfs_[gs]et_cdevpriv() and turn tun and tap into single device nodes. > That's what we've already been doing to bpf, snp, audit_pipe, etc. > Unfortunately I'm no expert when it comes to our tun and tap > implementations. not so fast please :) the tap/tun/vkbd (and maybe others) have split personality. that is, on one side there is a network interface or keyboard, and on the other side is character device. those are always go in pairs. as far as i understand, of dev_stdclone/clone_create/clonedevs list/etc. is here to free up driver from managing resources (such as minor numbers). sure we can convert those drivers to devfs_set/get_cdevpriv, however, split personality drivers will still have to manage something similar to minor numbers (to name network interfaces/keyboards associated with the particular cdevpriv instance). also we need to make sure that any code still could use /dev/tunX/tapX names and get correct tunX/tapX interface (provided, of course, one is available). thanks, max From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 18:45:36 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C2D11065673 for ; Fri, 19 Sep 2008 18:45:36 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 2E8838FC23 for ; Fri, 19 Sep 2008 18:45:36 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.61] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id m8JIjAnC075290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Sep 2008 11:45:15 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <48D3F338.1050505@FreeBSD.org> Date: Fri, 19 Sep 2008 11:45:12 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Maksim Yevmenkin References: <48D2F942.4070801@FreeBSD.org> <20080919101700.GS81522@hoeg.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ed Schouten , "current@freebsd.org" Subject: Re: Interface auto-cloning bug or feature? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 18:45:36 -0000 Maksim Yevmenkin wrote: > On 9/19/08, Ed Schouten wrote: >> Hello Maxim, >> >> >> * Maxim Sobolev wrote: >> > I've noticed that stat/open call on /dev/tun always creates new >> > interface, despite the fact that existing spare interfaces may be >> > available. I believe that it's a bug, since the whole purpose of >> > auto-cloning is to create new instance only when no existing one could >> > be allocated. At least that's my reading of the manual page for the tun(4). >> >> >> I'd say the best way to fix this would be to convert tun and tap to >> devfs_[gs]et_cdevpriv() and turn tun and tap into single device nodes. >> That's what we've already been doing to bpf, snp, audit_pipe, etc. >> Unfortunately I'm no expert when it comes to our tun and tap >> implementations. > > not so fast please :) the tap/tun/vkbd (and maybe others) have split > personality. that is, on one side there is a network interface or > keyboard, and on the other side is character device. those are always > go in pairs. as far as i understand, of > dev_stdclone/clone_create/clonedevs list/etc. is here to free up > driver from managing resources (such as minor numbers). sure we can > convert those drivers to devfs_set/get_cdevpriv, however, split > personality drivers will still have to manage something similar to > minor numbers (to name network interfaces/keyboards associated with > the particular cdevpriv instance). also we need to make sure that any > code still could use /dev/tunX/tapX names and get correct tunX/tapX > interface (provided, of course, one is available). Why opening /dev/tun can't search and return the first unopened instance (as the manpage suggests it would) instead of unconditionally allocating a new one? Seems to me like a trivial change, most of the code is already there. -Maxim From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 19:24:13 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62290106566C for ; Fri, 19 Sep 2008 19:24:13 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by mx1.freebsd.org (Postfix) with ESMTP id 358A88FC14 for ; Fri, 19 Sep 2008 19:24:13 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so505092rvf.43 for ; Fri, 19 Sep 2008 12:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=szG2FJ+LX8/4e6DgH8jl94r8b/B0K5QsMRnlKid+rWg=; b=YQpt/LLxMC3fJrP/fZIVgXKfvECApNqeL7PAImrSnS/eViDiIwM5b2gyN7U9D50uBF yn5JvJ/KNcyBwwue88JLiQIr5Hoxt2tCXSyStq6/rFZrrvh3yEDbGOOvnymtTjjsQj18 izG7GHGmd4GPktJoBdw8ghJz5TB6yPV92euJo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=G6u2sPfNDGwFTlpRBgKwBCVw56bpvZ0emGv0C4FcOpsePRH4IwdMzNKImnnmUIKjwY qjU2KPjw8tepK+Ic4bo6MzA2uhoDVbKY3MYH58NSbgokEcNAqwMiEen8+xzEhQNZCr94 e1O6dRDuNMPyDkd4qa9eFcbApFxi3E8fuDZFE= Received: by 10.140.127.20 with SMTP id z20mr287199rvc.77.1221852253002; Fri, 19 Sep 2008 12:24:13 -0700 (PDT) Received: by 10.141.197.13 with HTTP; Fri, 19 Sep 2008 12:24:12 -0700 (PDT) Message-ID: Date: Fri, 19 Sep 2008 12:24:12 -0700 From: "Maksim Yevmenkin" To: "Maxim Sobolev" In-Reply-To: <48D3F338.1050505@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48D2F942.4070801@FreeBSD.org> <20080919101700.GS81522@hoeg.nl> <48D3F338.1050505@FreeBSD.org> Cc: Ed Schouten , "current@freebsd.org" Subject: Re: Interface auto-cloning bug or feature? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 19:24:13 -0000 On 9/19/08, Maxim Sobolev wrote: > Maksim Yevmenkin wrote: > > > On 9/19/08, Ed Schouten wrote: > > > > > Hello Maxim, > > > > > > > > > * Maxim Sobolev wrote: > > > > I've noticed that stat/open call on /dev/tun always creates new > > > > interface, despite the fact that existing spare interfaces may be > > > > available. I believe that it's a bug, since the whole purpose of > > > > auto-cloning is to create new instance only when no existing one > could > > > > be allocated. At least that's my reading of the manual page for the > tun(4). > > > > > > > > > I'd say the best way to fix this would be to convert tun and tap to > > > devfs_[gs]et_cdevpriv() and turn tun and tap into single device nodes. > > > That's what we've already been doing to bpf, snp, audit_pipe, etc. > > > Unfortunately I'm no expert when it comes to our tun and tap > > > implementations. > > > > > > > not so fast please :) the tap/tun/vkbd (and maybe others) have split > > personality. that is, on one side there is a network interface or > > keyboard, and on the other side is character device. those are always > > go in pairs. as far as i understand, of > > dev_stdclone/clone_create/clonedevs list/etc. is here to > free up > > driver from managing resources (such as minor numbers). sure we can > > convert those drivers to devfs_set/get_cdevpriv, however, split > > personality drivers will still have to manage something similar to > > minor numbers (to name network interfaces/keyboards associated with > > the particular cdevpriv instance). also we need to make sure that any > > code still could use /dev/tunX/tapX names and get correct tunX/tapX > > interface (provided, of course, one is available). > > > > Why opening /dev/tun can't search and return the first unopened instance > (as the manpage suggests it would) instead of unconditionally allocating a > new one? Seems to me like a trivial change, most of the code is already > there. why indeed :) i'll try to hack something up in the next couple of hours or so. stay tuned. thanks, max > > -Maxim > From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 19:56:44 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4744106566C for ; Fri, 19 Sep 2008 19:56:44 +0000 (UTC) (envelope-from wahjava@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.188]) by mx1.freebsd.org (Postfix) with ESMTP id 175A88FC0A for ; Fri, 19 Sep 2008 19:56:43 +0000 (UTC) (envelope-from wahjava@gmail.com) Received: by ti-out-0910.google.com with SMTP id d27so308966tid.3 for ; Fri, 19 Sep 2008 12:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:subject:x-face:x-uptime :x-url:x-openpgp-id:x-openpgp-fingerprint:x-os:x-mailer:x-mail-morse :x-attribution:organization:from:date:message-id:user-agent:face :mime-version:content-type:sender; bh=T83pTFMIZfyLQf7b4pg6HpGFFPcjwqpOsCpuat/28FM=; b=er4XABHdiNtt7/B1jlnqieBPsnI2E8AG5aozGySY0awVgL61gQJrqRDthLf2BAMNNz e2Upjx3WLCNu5wHEav+yO4kgB0R06dHM7EQ1ppG3phjreQPdC3MDoqGZVc6MXehDK2iI V1eM61IeTzy+v02+pdNPIdhm5eiQlUo1wxvJ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:subject:x-face:x-uptime:x-url:x-openpgp-id:x-openpgp-fingerprint :x-os:x-mailer:x-mail-morse:x-attribution:organization:from:date :message-id:user-agent:face:mime-version:content-type:sender; b=c2yOouTHl66ldGzZ+4UDBx/bM1Nf/eWq4OiTsmWmi9Ll+xISoPwxYOhwz6Yvh0z+yt +SdL1CjOoS07dp16El0RIjfyZjNlwhIDPCvyb6//cPxnO0Saofmkz3NW0alD+Pk4wvNV dg1uQUfC1UDrJ73zmeGr3D46mgM4dVSRuWHxs= Received: by 10.110.52.1 with SMTP id z1mr770854tiz.11.1221852553656; Fri, 19 Sep 2008 12:29:13 -0700 (PDT) Received: from chateau.d.lf ( [122.163.146.47]) by mx.google.com with ESMTPS id i9sm1896358tid.15.2008.09.19.12.29.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Sep 2008 12:29:12 -0700 (PDT) To: freebsd-current@freebsd.org X-Face: )vGQ9yK7Y$Flebu1C>(B\gYBm)[$zfKM+p&TT[[JWl6:]S>cc$%-z7-`46Zf0B*syL.C]oCq[upTG~zuS0.$"_%)|Q@$hA=9{3l{%u^h3jJ^Zl; t7 X-Uptime: 00:54:22 up 13:43, 1 user, load average: 0.05, 0.06, 0.07 X-URL: http://wahjava.wordpress.com/ X-OpenPGP-ID: 762E5E74 X-OpenPGP-Fingerprint: 1E00 4679 77E4 F8EE 2E4B 56F2 1F2F 8410 762E 5E74 X-OS: GNU/Linux on Linux 2.6.25-gentoo-r7 kernel on x86_64 architecture X-Mailer: Gnus/5.11 (Oort 5.11) Emacs/22.3.1 (x86_64-pc-linux-gnu) X-Mail-Morse: .-- .- .... .--- .- ...- .- .--.-. --. -- .- .. .-.. .-.-.- -.-. --- -- X-Attribution: =?utf-8?B?4KSG4KS24KWA4KS3?= Organization: alt.religion.emacs From: wahjava.ml@gmail.com (Ashish Shukla =?utf-8?B?4KSG4KS24KWA4KS3IA==?= =?utf-8?B?4KS24KWB4KSV4KWN4KSy?=) Date: Sat, 20 Sep 2008 00:59:17 +0530 Message-ID: <87od2kj5o2.fsf@chateau.d.lf> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJ1BMVEWpqal/f39tbW1jY2Md HR2goKCenp6UlJROTk7////9/f35+fnT09ORJdieAAACVklEQVQ4jXXUP2vbQBQA8AvUTkgz5OzY Z0iGWhpS6BSrkECn0mvx0MEJ6AjtYrfoBCVDlD8naJYmNlRfwZq8+mkKlIZaGpJSYmP7Q/XkJDrJ Td8i/H68u3vHPaPufwLdf32AMA4A6GcAgvAamY1pOJiDIFqicTwLswDhfr3uxfFtkAY/GFHPMwzD 8zpnACmIOnE6js7rQb+v4NJrG9od0C+QgpHMy5jBewV+UDSMWiw1Y4fWfyV7+NGFzDsYa3pth9LJ Q4XvXxFHcJRvHOmygn5NAEabnDcQQguarnfoiwSCJ99jmKKcphsZONmWsDK9Ro7cvZOCtQdg8nje egLhc2LNlkLmsezzTFUUy5w18ocox/f0LaLgJy0zO75zk+9pp85GAj36xjqhdI0y3tq2m4dqqcWX zQWBTz8L1irvolXV4J+3q7eCDgVnttjNq6X8H+9KOZsuNk1uCzx8pSp+E9HImfJOTLdcGqo+YKnG EIovizkEn48V7BO+ch2DXcD4ENSpWiU+q8hjjbgTBZCXnZtyj0Ws4Q1Q0B2WXFtYZo65Bbyeeldw RS6qFueM80LlLA29YlVwGRYvFD+kwI/0O+A2PlpOP9GwslUVciHuYGechuBTp922YiDZCrghTknm XSyOM+D3aoRZlo0Jb42zY7DN4p2x4AeZ+QAYutx1sHwTHzMT5cMNduQ9yW3GczN4KZ86kb0c9O8T yXDeFqpl2fryPEAYGXIlezAPXYh2NgVr/gvdoHIuDwuPwOhcWE8f8mmICq41eATkn8x0kuRTIKcB wE9+/QUtiiAnYcaN7wAAAABJRU5ErkJggg== MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: =?UTF-8?B?4KSG4KS24KWA4KS3IOCktuClgeCkleCljeCksiBBc2hpc2ggU2h1a2xh?= Subject: Compilation error occured during 'make buildkernel' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 19:56:45 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Hi all, I just started tracking 8.0-CURRENT, and this is my first 8.0-CURRENT 'make buildkernel' execution and my first posting to this list . I'm getting following compilation error while building it for my custom kernel configuration file: ---->8---->8---- cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=nocona -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --pa ram inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asy nchronous-unwind-tables -ffreestanding -fstack-protector -Werror /usr/src/sys/net/if_sl.c /usr/src/sys/net/if_sl.c:179: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'slclose' /usr/src/sys/net/if_sl.c:180: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'slinput' /usr/src/sys/net/if_sl.c:181: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'sltioctl' /usr/src/sys/net/if_sl.c:182: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'sltstart' /usr/src/sys/net/if_sl.c:189: error: variable 'slipdisc' has initializer but incomplete type /usr/src/sys/net/if_sl.c:190: error: unknown field 'l_open' specified in initializer cc1: warnings being treated as errors /usr/src/sys/net/if_sl.c:190: warning: excess elements in struct initializer /usr/src/sys/net/if_sl.c:190: warning: (near initialization for 'slipdisc') /usr/src/sys/net/if_sl.c:191: error: unknown field 'l_close' specified in initializer /usr/src/sys/net/if_sl.c:191: error: 'slclose' undeclared here (not in a function) /usr/src/sys/net/if_sl.c:191: warning: excess elements in struct initializer /usr/src/sys/net/if_sl.c:191: warning: (near initialization for 'slipdisc') /usr/src/sys/net/if_sl.c:192: error: unknown field 'l_read' specified in initializer /usr/src/sys/net/if_sl.c:192: error: 'l_noread' undeclared here (not in a function) /usr/src/sys/net/if_sl.c:192: warning: excess elements in struct initializer /usr/src/sys/net/if_sl.c:192: warning: (near initialization for 'slipdisc') /usr/src/sys/net/if_sl.c:193: error: unknown field 'l_write' specified in initializer /usr/src/sys/net/if_sl.c:193: error: 'l_nowrite' undeclared here (not in a function) /usr/src/sys/net/if_sl.c:193: warning: excess elements in struct initializer /usr/src/sys/net/if_sl.c:193: warning: (near initialization for 'slipdisc') /usr/src/sys/net/if_sl.c:194: error: unknown field 'l_ioctl' specified in initializer /usr/src/sys/net/if_sl.c:194: error: 'sltioctl' undeclared here (not in a function) /usr/src/sys/net/if_sl.c:194: warning: excess elements in struct initializer /usr/src/sys/net/if_sl.c:194: warning: (near initialization for 'slipdisc') /usr/src/sys/net/if_sl.c:195: error: unknown field 'l_rint' specified in initializer /usr/src/sys/net/if_sl.c:195: error: 'slinput' undeclared here (not in a function) /usr/src/sys/net/if_sl.c:195: warning: excess elements in struct initializer /usr/src/sys/net/if_sl.c:195: warning: (near initialization for 'slipdisc') /usr/src/sys/net/if_sl.c:196: error: unknown field 'l_start' specified in initializer /usr/src/sys/net/if_sl.c:196: error: 'sltstart' undeclared here (not in a function) /usr/src/sys/net/if_sl.c:196: warning: excess elements in struct initializer /usr/src/sys/net/if_sl.c:196: warning: (near initialization for 'slipdisc') /usr/src/sys/net/if_sl.c:197: error: unknown field 'l_modem' specified in initializer /usr/src/sys/net/if_sl.c:197: error: 'ttymodem' undeclared here (not in a function) /usr/src/sys/net/if_sl.c:198: warning: excess elements in struct initializer /usr/src/sys/net/if_sl.c:198: warning: (near initialization for 'slipdisc') /usr/src/sys/net/if_sl.c: In function 'sl_modevent': /usr/src/sys/net/if_sl.c:208: warning: implicit declaration of function 'ldisc_register' /usr/src/sys/net/if_sl.c:208: warning: nested extern declaration of 'ldisc_register' /usr/src/sys/net/if_sl.c:212: warning: implicit declaration of function 'ldisc_deregister' /usr/src/sys/net/if_sl.c:212: warning: nested extern declaration of 'ldisc_deregister' /usr/src/sys/net/if_sl.c: In function 'slopen': /usr/src/sys/net/if_sl.c:365: error: 'struct tty' has no member named 't_hotchar' /usr/src/sys/net/if_sl.c:367: error: 'struct tty' has no member named 't_ospeed' /usr/src/sys/net/if_sl.c:368: warning: implicit declaration of function 'ttyflush' /usr/src/sys/net/if_sl.c:368: warning: nested extern declaration of 'ttyflush' /usr/src/sys/net/if_sl.c:380: error: 'struct tty' has no member named 't_canq' /usr/src/sys/net/if_sl.c:383: warning: passing argument 1 of 'clist_alloc_cblocks' from incompatible pointer type /usr/src/sys/net/if_sl.c:384: error: 'struct tty' has no member named 't_rawq' /usr/src/sys/net/if_sl.c: In function 'slclose': /usr/src/sys/net/if_sl.c:423: warning: passing argument 1 of 'clist_free_cblocks' from incompatible pointer type /usr/src/sys/net/if_sl.c: In function 'sltioctl': /usr/src/sys/net/if_sl.c:486: warning: passing argument 1 of 'clist_alloc_cblocks' from incompatible pointer type /usr/src/sys/net/if_sl.c: In function 'sloutput': /usr/src/sys/net/if_sl.c:564: error: 'struct tty' has no member named 't_state' /usr/src/sys/net/if_sl.c:564: error: 'TS_CONNECTED' undeclared (first use in this function) /usr/src/sys/net/if_sl.c:564: error: (Each undeclared identifier is reported only once /usr/src/sys/net/if_sl.c:564: error: for each function it appears in.) ----8<----8<---- When I tried building with 'GENERIC' kernel configuration, it built fine. I'm not able to figure out, what is wrong ? I'm running FreeBSD 7.1-PRERELEASE (amd64). If my kernel configuration is desired, please mention. Since, this is also my first posting, so I'm wondering if posting compilation errors are not off-topic for this list ? TIA. Ashish -- ·-- ·- ···· ·--- ·- ···- ·- ·--·-· --· -- ·- ·· ·-·· ·-·-·- -·-· --- -- () ascii ribbon campaign - against HTML e-mail /\ www.asciiribbon.org - against proprietary attachments --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjT/ZAACgkQHy+EEHYuXnTWWACgrnjpiyXRtP4SQ2hAY3iS0MsU V5gAn2JeYq8P5/BunA1KIISp6BhxZ1VZ =xiZ4 -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 20:03:41 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B5521065676 for ; Fri, 19 Sep 2008 20:03:41 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout5.freenet.de (mout5.freenet.de [IPv6:2001:748:100:40::2:7]) by mx1.freebsd.org (Postfix) with ESMTP id E8CED8FC08 for ; Fri, 19 Sep 2008 20:03:40 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.21] (helo=11.mx.freenet.de) by mout5.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #65) id 1KgmCZ-0002wy-Eq; Fri, 19 Sep 2008 22:03:39 +0200 Received: from m8c90.m.pppool.de ([89.49.140.144]:16868 helo=peedub.jennejohn.org) by 11.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #65) id 1KgmCZ-0004PU-73; Fri, 19 Sep 2008 22:03:39 +0200 Date: Fri, 19 Sep 2008 22:03:38 +0200 From: Gary Jennejohn To: Cc: freebsd-current@freebsd.org Message-ID: <20080919220338.31cce41d@peedub.jennejohn.org> In-Reply-To: <87od2kj5o2.fsf@chateau.d.lf> References: <87od2kj5o2.fsf@chateau.d.lf> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.10.14; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Compilation error occured during 'make buildkernel' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 20:03:41 -0000 On Sat, 20 Sep 2008 00:59:17 +0530 wahjava.ml@gmail.com (Ashish Shukla ____________ _______________) wrote: > I just started tracking 8.0-CURRENT, and this is my first 8.0-CURRENT > 'make buildkernel' execution and my first posting to this list . I'm > getting following compilation error while building it for my custom > kernel configuration file: > [snip error output from trying to compile if_sl] The new MPSAFE tty code in current doesn't support slip yet. Remove slip from your configuration. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 20:13:45 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 229181065678 for ; Fri, 19 Sep 2008 20:13:45 +0000 (UTC) (envelope-from wahjava@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.187]) by mx1.freebsd.org (Postfix) with ESMTP id 7F45A8FC08 for ; Fri, 19 Sep 2008 20:13:44 +0000 (UTC) (envelope-from wahjava@gmail.com) Received: by ti-out-0910.google.com with SMTP id d27so310834tid.3 for ; Fri, 19 Sep 2008 13:13:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:cc:subject:x-face :references:x-uptime:x-url:x-openpgp-id:x-openpgp-fingerprint:x-os :x-mailer:x-mail-morse:x-attribution:organization:from:date :in-reply-to:message-id:user-agent:face:mime-version:content-type :sender; bh=MU+JP81UZXxxDAyMPPgs8F4gKasc0sfxv2/JAn2hoIY=; b=T+ZMrU4Sx/iumQ6c3IjPel6XAlPop96P8Zo8/K7ScVVGZrR2pcOf3M5ytHGq9nunsK HWjxqKrJYYpty1TmipzqvQ7q8GrQ6KsPBB3UL/1kMqYQTrt6C3oMF9avHe8XirfS+xhK H5wnh0IRE95fvkBFH7j6YvnPgB4dE+kKg/yGk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:cc:subject:x-face:references:x-uptime:x-url:x-openpgp-id :x-openpgp-fingerprint:x-os:x-mailer:x-mail-morse:x-attribution :organization:from:date:in-reply-to:message-id:user-agent:face :mime-version:content-type:sender; b=FP1XeYE4VinoOnaxj5HFynyMHbQqS0QPND9pd2WDyIzoQWQ1xtR4dkgZkBnJUcdylx ebVsFPIEJpozxTcrm9BWpaOzHExePVnvz4/CIYwvUaw4hVteBHtfpNl7UCK3axHWYe5f Qa0cJI6q48PgCo/9skT3Iq6rQ0xuj572f5ysQ= Received: by 10.110.33.15 with SMTP id g15mr768988tig.54.1221855223129; Fri, 19 Sep 2008 13:13:43 -0700 (PDT) Received: from chateau.d.lf ( [122.163.146.63]) by mx.google.com with ESMTPS id w5sm2873363tib.9.2008.09.19.13.13.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Sep 2008 13:13:42 -0700 (PDT) To: gary.jennejohn@freenet.de X-Face: )vGQ9yK7Y$Flebu1C>(B\gYBm)[$zfKM+p&TT[[JWl6:]S>cc$%-z7-`46Zf0B*syL.C]oCq[upTG~zuS0.$"_%)|Q@$hA=9{3l{%u^h3jJ^Zl; t7 References: <87od2kj5o2.fsf@chateau.d.lf> <20080919220338.31cce41d@peedub.jennejohn.org> X-Uptime: 01:42:34 up 14:31, 1 user, load average: 0.32, 0.26, 0.19 X-URL: http://wahjava.wordpress.com/ X-OpenPGP-ID: 762E5E74 X-OpenPGP-Fingerprint: 1E00 4679 77E4 F8EE 2E4B 56F2 1F2F 8410 762E 5E74 X-OS: GNU/Linux on Linux 2.6.25-gentoo-r7 kernel on x86_64 architecture X-Mailer: Gnus/5.11 (Oort 5.11) Emacs/22.3.1 (x86_64-pc-linux-gnu) X-Mail-Morse: .-- .- .... .--- .- ...- .- .--.-. --. -- .- .. .-.. .-.-.- -.-. --- -- X-Attribution: =?utf-8?B?4KSG4KS24KWA4KS3?= Organization: alt.religion.emacs From: wahjava.ml@gmail.com (Ashish Shukla =?utf-8?B?4KSG4KS24KWA4KS3IA==?= =?utf-8?B?4KS24KWB4KSV4KWN4KSy?=) Date: Sat, 20 Sep 2008 01:43:48 +0530 In-Reply-To: <20080919220338.31cce41d@peedub.jennejohn.org> (Gary Jennejohn's message of "Fri\, 19 Sep 2008 22\:03\:38 +0200") Message-ID: <87fxnvki6b.fsf@chateau.d.lf> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJ1BMVEWpqal/f39tbW1jY2Md HR2goKCenp6UlJROTk7////9/f35+fnT09ORJdieAAACVklEQVQ4jXXUP2vbQBQA8AvUTkgz5OzY Z0iGWhpS6BSrkECn0mvx0MEJ6AjtYrfoBCVDlD8naJYmNlRfwZq8+mkKlIZaGpJSYmP7Q/XkJDrJ Td8i/H68u3vHPaPufwLdf32AMA4A6GcAgvAamY1pOJiDIFqicTwLswDhfr3uxfFtkAY/GFHPMwzD 8zpnACmIOnE6js7rQb+v4NJrG9od0C+QgpHMy5jBewV+UDSMWiw1Y4fWfyV7+NGFzDsYa3pth9LJ Q4XvXxFHcJRvHOmygn5NAEabnDcQQguarnfoiwSCJ99jmKKcphsZONmWsDK9Ro7cvZOCtQdg8nje egLhc2LNlkLmsezzTFUUy5w18ocox/f0LaLgJy0zO75zk+9pp85GAj36xjqhdI0y3tq2m4dqqcWX zQWBTz8L1irvolXV4J+3q7eCDgVnttjNq6X8H+9KOZsuNk1uCzx8pSp+E9HImfJOTLdcGqo+YKnG EIovizkEn48V7BO+ch2DXcD4ENSpWiU+q8hjjbgTBZCXnZtyj0Ws4Q1Q0B2WXFtYZo65Bbyeeldw RS6qFueM80LlLA29YlVwGRYvFD+kwI/0O+A2PlpOP9GwslUVciHuYGechuBTp922YiDZCrghTknm XSyOM+D3aoRZlo0Jb42zY7DN4p2x4AeZ+QAYutx1sHwTHzMT5cMNduQ9yW3GczN4KZ86kb0c9O8T yXDeFqpl2fryPEAYGXIlezAPXYh2NgVr/gvdoHIuDwuPwOhcWE8f8mmICq41eATkn8x0kuRTIKcB wE9+/QUtiiAnYcaN7wAAAABJRU5ErkJggg== MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: =?UTF-8?B?4KSG4KS24KWA4KS3IOCktuClgeCkleCljeCksiBBc2hpc2ggU2h1a2xh?= Cc: freebsd-current@freebsd.org Subject: Re: Compilation error occured during 'make buildkernel' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 20:13:45 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Gary Jennejohn writes: > On Sat, 20 Sep 2008 00:59:17 +0530 > wahjava.ml@gmail.com (Ashish Shukla ____________ _______________) wrote: >> I just started tracking 8.0-CURRENT, and this is my first 8.0-CURRENT >> 'make buildkernel' execution and my first posting to this list . I'm >> getting following compilation error while building it for my custom >> kernel configuration file: >> > [snip error output from trying to compile if_sl] > The new MPSAFE tty code in current doesn't support slip yet. Remove > slip from your configuration. Thanks, I've remove 'device sl' and 'device ppp' (as I get similar compilation error with that, and noticed that both of these options aren't present in GENERIC configuration file) from my configuration, and now building. Thanks Ashish -- ·-- ·- ···· ·--- ·- ···- ·- ·--·-· --· -- ·- ·· ·-·· ·-·-·- -·-· --- -- () ascii ribbon campaign - against HTML e-mail /\ www.asciiribbon.org - against proprietary attachments --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjUB/8ACgkQHy+EEHYuXnTyrwCeM2LNs4u7q2bvviWoguTyVOgR OV0An25HzIKboQgHchFH3GUj+/rIyoJw =HKRp -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 20:28:51 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E2F71065675 for ; Fri, 19 Sep 2008 20:28:51 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id B31E68FC12 for ; Fri, 19 Sep 2008 20:28:50 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id F2092A06DD; Fri, 19 Sep 2008 22:28:48 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id E35EDA06DC; Fri, 19 Sep 2008 22:28:48 +0200 (CEST) Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id CD10BA06D9; Fri, 19 Sep 2008 22:28:48 +0200 (CEST) Received: from localhost.my.domain ([80.129.138.237]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2) with ESMTP id 2008091922284831-35168 ; Fri, 19 Sep 2008 22:28:48 +0200 Received: by localhost.my.domain (sSMTP sendmail emulation); Fri, 19 Sep 2008 22:33:10 +0200 Date: Fri, 19 Sep 2008 22:33:10 +0200 From: Alexey Shuvaev To: Maxim Sobolev , Sean , Maksim Yevmenkin Message-ID: <20080919203310.GA34131@localhost.my.domain> References: <48D2F942.4070801@FreeBSD.org> <20080919084201.GD44330@wep4035.physik.uni-wuerzburg.de> <48D38DFF.8000803@FreeBSD.org> MIME-Version: 1.0 In-Reply-To: <48D38DFF.8000803@FreeBSD.org> Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.18 (2008-05-17) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.0.2|August 07, 2008) at 09/19/2008 10:28:48 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2|August 07, 2008) at 09/19/2008 10:28:48 PM, Serialize complete at 09/19/2008 10:28:48 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: freebsd-current@freebsd.org Subject: Re: Interface auto-cloning bug or feature? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 20:28:51 -0000 On Fri, Sep 19, 2008 at 04:33:19AM -0700, Maxim Sobolev wrote: > Alexey Shuvaev wrote: >>> [root@sp1 /usr/home/sobomax]# ifconfig -a >>> tun0: flags=8010 mtu 1500 >>> tun1: flags=8010 mtu 1500 >>> tun2: flags=8010 mtu 1500 >>> tun3: flags=8010 mtu 1500 >>> >> Me too. >> I have seen that using ppp(8) and security/vpnc. > > That what has caused me to look into this issue. You can find patch for > security/vpnc to prevent unbounded interface cloning here: > > http://sobomax.sippysoft.com/~sobomax/vpnc.diff > Ok, the patch prevents interface cloning, but I think it doesn't solve the actual problem. Let's wait for Maksim :) Thanks, Alexey. From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 20:37:43 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5835E106566C for ; Fri, 19 Sep 2008 20:37:43 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 22C3A8FC15 for ; Fri, 19 Sep 2008 20:37:35 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.61] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id m8JKbXrV080602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Sep 2008 13:37:34 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <48D40D8E.60109@FreeBSD.org> Date: Fri, 19 Sep 2008 13:37:34 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Alexey Shuvaev References: <48D2F942.4070801@FreeBSD.org> <20080919084201.GD44330@wep4035.physik.uni-wuerzburg.de> <48D38DFF.8000803@FreeBSD.org> <20080919203310.GA34131@localhost.my.domain> In-Reply-To: <20080919203310.GA34131@localhost.my.domain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Maksim Yevmenkin Subject: Re: Interface auto-cloning bug or feature? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 20:37:43 -0000 Alexey Shuvaev wrote: > On Fri, Sep 19, 2008 at 04:33:19AM -0700, Maxim Sobolev wrote: >> Alexey Shuvaev wrote: >>>> [root@sp1 /usr/home/sobomax]# ifconfig -a >>>> tun0: flags=8010 mtu 1500 >>>> tun1: flags=8010 mtu 1500 >>>> tun2: flags=8010 mtu 1500 >>>> tun3: flags=8010 mtu 1500 >>>> >>> Me too. >>> I have seen that using ppp(8) and security/vpnc. >> That what has caused me to look into this issue. You can find patch for >> security/vpnc to prevent unbounded interface cloning here: >> >> http://sobomax.sippysoft.com/~sobomax/vpnc.diff >> > Ok, the patch prevents interface cloning, but I think it doesn't solve > the actual problem. Well, in any case checking kernel modules list to detect if_tun presence is more correct way than doing stat on /dev/tun. -Maxim From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 22:23:07 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7EE11065672 for ; Fri, 19 Sep 2008 22:23:07 +0000 (UTC) (envelope-from wahjava@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.184]) by mx1.freebsd.org (Postfix) with ESMTP id 35D238FC16 for ; Fri, 19 Sep 2008 22:23:06 +0000 (UTC) (envelope-from wahjava@gmail.com) Received: by ti-out-0910.google.com with SMTP id d27so324666tid.3 for ; Fri, 19 Sep 2008 15:23:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:subject:x-face:x-uptime :x-url:x-openpgp-id:x-openpgp-fingerprint:x-os:x-mailer:x-mail-morse :x-attribution:organization:from:date:message-id:user-agent:face :mime-version:content-type:sender; bh=zKEx0e6+xsbCgq//20B7287lMncjfiXBAXUBqm7KTXI=; b=i7JIUALVdmEQrfZU/n8hHjTk/o3HysCTcls6D3i/ORCi2fSZkkv1hPfiNSiVP4YzNi l5TGRiX6ncrcE+pU6gkAB66lDULA8j/hkZ99tjeZIIT90kY8WNMtP5Sch6/fcpMZrO5j aCmHQER8JOz4HWFMdFnp684/XmsMuSdHOrJlo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:subject:x-face:x-uptime:x-url:x-openpgp-id:x-openpgp-fingerprint :x-os:x-mailer:x-mail-morse:x-attribution:organization:from:date :message-id:user-agent:face:mime-version:content-type:sender; b=LxxNCS6NmsVUFvjrZOb9ajFQ3ZEcOJz/633F9p8VeXTg/8qXNa7lRIS74C8MO34VOA 5ANCalL/jfRR8ka/GZ2I4OkTYPWeWcSvZVahwGS0+x71vyxcZMJJzKmHW/hKwiuix8XY 0cYjEiha8F61E4GlsCRH5MFlfYJ46L1ftHaRk= Received: by 10.110.43.18 with SMTP id q18mr966978tiq.57.1221862985527; Fri, 19 Sep 2008 15:23:05 -0700 (PDT) Received: from chateau.d.lf ( [122.162.54.208]) by mx.google.com with ESMTPS id u12sm3464451tia.5.2008.09.19.15.23.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Sep 2008 15:23:04 -0700 (PDT) To: freebsd-current@freebsd.org X-Face: )vGQ9yK7Y$Flebu1C>(B\gYBm)[$zfKM+p&TT[[JWl6:]S>cc$%-z7-`46Zf0B*syL.C]oCq[upTG~zuS0.$"_%)|Q@$hA=9{3l{%u^h3jJ^Zl; t7 X-Uptime: 03:05:43 up 15:54, 1 user, load average: 0.61, 0.29, 0.15 X-URL: http://wahjava.wordpress.com/ X-OpenPGP-ID: 762E5E74 X-OpenPGP-Fingerprint: 1E00 4679 77E4 F8EE 2E4B 56F2 1F2F 8410 762E 5E74 X-OS: GNU/Linux on Linux 2.6.25-gentoo-r7 kernel on x86_64 architecture X-Mailer: Gnus/5.11 (Oort 5.11) Emacs/22.3.1 (x86_64-pc-linux-gnu) X-Mail-Morse: .-- .- .... .--- .- ...- .- .--.-. --. -- .- .. .-.. .-.-.- -.-. --- -- X-Attribution: =?utf-8?B?4KSG4KS24KWA4KS3?= Organization: alt.religion.emacs From: wahjava.ml@gmail.com (Ashish Shukla =?utf-8?B?4KSG4KS24KWA4KS3IA==?= =?utf-8?B?4KS24KWB4KSV4KWN4KSy?=) Date: Sat, 20 Sep 2008 03:53:10 +0530 Message-ID: <87bpyjkc6p.fsf@chateau.d.lf> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJ1BMVEWpqal/f39tbW1jY2Md HR2goKCenp6UlJROTk7////9/f35+fnT09ORJdieAAACVklEQVQ4jXXUP2vbQBQA8AvUTkgz5OzY Z0iGWhpS6BSrkECn0mvx0MEJ6AjtYrfoBCVDlD8naJYmNlRfwZq8+mkKlIZaGpJSYmP7Q/XkJDrJ Td8i/H68u3vHPaPufwLdf32AMA4A6GcAgvAamY1pOJiDIFqicTwLswDhfr3uxfFtkAY/GFHPMwzD 8zpnACmIOnE6js7rQb+v4NJrG9od0C+QgpHMy5jBewV+UDSMWiw1Y4fWfyV7+NGFzDsYa3pth9LJ Q4XvXxFHcJRvHOmygn5NAEabnDcQQguarnfoiwSCJ99jmKKcphsZONmWsDK9Ro7cvZOCtQdg8nje egLhc2LNlkLmsezzTFUUy5w18ocox/f0LaLgJy0zO75zk+9pp85GAj36xjqhdI0y3tq2m4dqqcWX zQWBTz8L1irvolXV4J+3q7eCDgVnttjNq6X8H+9KOZsuNk1uCzx8pSp+E9HImfJOTLdcGqo+YKnG EIovizkEn48V7BO+ch2DXcD4ENSpWiU+q8hjjbgTBZCXnZtyj0Ws4Q1Q0B2WXFtYZo65Bbyeeldw RS6qFueM80LlLA29YlVwGRYvFD+kwI/0O+A2PlpOP9GwslUVciHuYGechuBTp922YiDZCrghTknm XSyOM+D3aoRZlo0Jb42zY7DN4p2x4AeZ+QAYutx1sHwTHzMT5cMNduQ9yW3GczN4KZ86kb0c9O8T yXDeFqpl2fryPEAYGXIlezAPXYh2NgVr/gvdoHIuDwuPwOhcWE8f8mmICq41eATkn8x0kuRTIKcB wE9+/QUtiiAnYcaN7wAAAABJRU5ErkJggg== MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: =?UTF-8?B?4KSG4KS24KWA4KS3IOCktuClgeCkleCljeCksiBBc2hpc2ggU2h1a2xh?= Subject: Setting up atheros (168c:001c) wireless NIC in FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 22:23:08 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Hi all, I've just booted with 8.0-CURRENT :) . And expecting my Atheros 802.11 a/b/g Wireless NIC to work with the latest HAL and driver, but to my surprise it isn't even able to scan :( . ----8<----8<---- % pciconf -l hostb0@pci0:0:0:0: class=0x060000 card=0x30d9103c chip=0x2a008086 rev=0x03 hdr=0x00 vgapci0@pci0:0:2:0: class=0x030000 card=0x30d9103c chip=0x2a028086 rev=0x03 hdr=0x00 vgapci1@pci0:0:2:1: class=0x038000 card=0x30d9103c chip=0x2a038086 rev=0x03 hdr=0x00 hdac0@pci0:0:27:0: class=0x040300 card=0x505114f1 chip=0x284b8086 rev=0x03 hdr=0x00 pcib1@pci0:0:28:0: class=0x060400 card=0x30d9103c chip=0x283f8086 rev=0x03 hdr=0x01 uhci0@pci0:0:29:0: class=0x0c0300 card=0x30d9103c chip=0x28308086 rev=0x03 hdr=0x00 uhci1@pci0:0:29:1: class=0x0c0300 card=0x30d9103c chip=0x28318086 rev=0x03 hdr=0x00 uhci2@pci0:0:29:2: class=0x0c0300 card=0x30d9103c chip=0x28328086 rev=0x03 hdr=0x00 ehci0@pci0:0:29:7: class=0x0c0320 card=0x30d9103c chip=0x28368086 rev=0x03 hdr=0x00 pcib2@pci0:0:30:0: class=0x060401 card=0x30d9103c chip=0x24488086 rev=0xf3 hdr=0x01 isab0@pci0:0:31:0: class=0x060100 card=0x30d9103c chip=0x28158086 rev=0x03 hdr=0x00 atapci0@pci0:0:31:1: class=0x01018a card=0x30d9103c chip=0x28508086 rev=0x03 hdr=0x00 atapci1@pci0:0:31:2: class=0x010601 card=0x30d9103c chip=0x28298086 rev=0x03 hdr=0x00 none0@pci0:0:31:3: class=0x0c0500 card=0x30d9103c chip=0x283e8086 rev=0x03 hdr=0x00 ath0@pci0:1:0:0: class=0x020000 card=0x137b103c chip=0x001c168c rev=0x01 hdr=0x00 rl0@pci0:2:1:0: class=0x020000 card=0x30d9103c chip=0x813910ec rev=0x10 hdr=0x00 % dmesg|tail -11 ath_hal: 0.10.5.6 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, RF2425, RF2417) ath0: mem 0x91300000-0x9130ffff irq 16 at device 0.0 on pci1 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: mac 14.2 phy 7.0 radio 10.2 ath0: detached ath_hal: 0.10.5.10 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, RF2425, RF2417) ath0: mem 0x91300000-0x9130ffff irq 16 at device 0.0 on pci1 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: mac 14.2 phy 7.0 radio 10.2 % ifconfig ath0 ath0: flags=8843 metric 0 mtu 2290 ether 00:1f:3a:1a:50:b3 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier % sudo ifconfig ath0 scan Password: ifconfig: unable to get scan results % sudo ifconfig ath0 bgscan ifconfig: SIOCS80211: Invalid argument % sudo ifconfig wlan create wlandev ath0 wlan0 % sudo wpa_supplicant -Dbsd -iwlan0 -c/etc/wpa_supplicant.conf Trying to associate with 00:1e:2a:76:f4:60 (SSID='18-B-PARVATIYA' freq=2437 MHz) Authentication with 00:1e:2a:76:f4:60 timed out. Trying to associate with 00:1e:2a:76:f4:60 (SSID='18-B-PARVATIYA' freq=2437 MHz) Authentication with 00:1e:2a:76:f4:60 timed out. Trying to associate with 00:1e:2a:76:f4:60 (SSID='18-B-PARVATIYA' freq=2437 MHz) Authentication with 00:1e:2a:76:f4:60 timed out. Trying to associate with 00:1e:2a:76:f4:60 (SSID='18-B-PARVATIYA' freq=2437 MHz) Authentication with 00:1e:2a:76:f4:60 timed out. Trying to associate with 00:1e:2a:76:f4:60 (SSID='18-B-PARVATIYA' freq=2437 MHz) Authentication with 00:1e:2a:76:f4:60 timed out. ---->8---->8---- I've tested my wireless NIC working fine in Gentoo GNU/Linux with ath_hal 0.10.5.6. And in FreeBSD 8.0-CURRENT, I've tried both versions of ath_hal (i.e. 0.10.5.6 and 0.10.5.10), but no success. BtW, I've loaded wlan_tkip, wlan_ccmp, and wlan_wep kernel modules. Any ideas how to get this wireless NIC working in FreeBSD 8-CURRENT ? TIA Ashish -- ·-- ·- ···· ·--- ·- ···- ·- ·--·-· --· -- ·- ·· ·-·· ·-·-·- -·-· --- -- () ascii ribbon campaign - against HTML e-mail /\ www.asciiribbon.org - against proprietary attachments --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjUJlIACgkQHy+EEHYuXnS9FgCg2HTJa/2XkmJDQH7+UEphVX/W iz8AoIgzz0/jLRqyLoMi9z4qx1OJS0om =QiDJ -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 22:33:47 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99F4A106564A; Fri, 19 Sep 2008 22:33:47 +0000 (UTC) (envelope-from jb@what-creek.com) Received: from what-creek.com (what-creek.com [66.111.37.70]) by mx1.freebsd.org (Postfix) with ESMTP id 656F68FC0C; Fri, 19 Sep 2008 22:33:47 +0000 (UTC) (envelope-from jb@what-creek.com) Received: by what-creek.com (Postfix, from userid 102) id 8EF4074202; Fri, 19 Sep 2008 22:33:46 +0000 (GMT) Date: Fri, 19 Sep 2008 22:33:46 +0000 From: John Birrell To: Daniel Gerzo Message-ID: <20080919223346.GA29436@what-creek.com> References: <20080917101013.GA90749@freebsd.org> <20080918211652.GB19958@what-creek.com> <20080919114528.5yzyki2ry8044g4s@0x20.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Lars Engels , Roman Divacky , jb@FreeBSD.org, current@FreeBSD.org Subject: Re: dtrace status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 22:33:47 -0000 On Fri, Sep 19, 2008 at 12:53:55PM +0200, Daniel Gerzo wrote: > > Hello guys, > > > Are there any FreeBSD specific docs on this? Maybe a short article for > > /usr/share/doc or a new chapter for the handbook? :-) > > I think Tom Rhodes is working on the Handbook chapter in collaboration with > John. This is true. Tom has sent me a draft to review. I'm about to get on a plane to the US and am scrambling to finish the things I need to present while I'm there. It'll be a few days before I can do anything FreeBSD related. -- John Birrell From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 22:35:24 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C838E106566C for ; Fri, 19 Sep 2008 22:35:24 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 8607D8FC08 for ; Fri, 19 Sep 2008 22:35:24 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m8JMZNA1039940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Sep 2008 15:35:24 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <48D4292B.3010908@freebsd.org> Date: Fri, 19 Sep 2008 15:35:23 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: =?windows-1252?Q?Ashish_Shukla_=3F=3F=3F=3F_=3F=3F=3F=3F=3F?= References: <87bpyjkc6p.fsf@chateau.d.lf> In-Reply-To: <87bpyjkc6p.fsf@chateau.d.lf> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: freebsd-current@freebsd.org Subject: Re: Setting up atheros (168c:001c) wireless NIC in FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 22:35:24 -0000 Ashish Shukla ???? ????? wrote: > Hi all, > > I've just booted with 8.0-CURRENT :) . And expecting my Atheros 802.11 > a/b/g Wireless NIC to work with the latest HAL and driver, but to my > surprise it isn't even able to scan :( . > > ----8<----8<---- > % pciconf -l > hostb0@pci0:0:0:0: class=0x060000 card=0x30d9103c chip=0x2a008086 rev=0x03 hdr=0x00 > vgapci0@pci0:0:2:0: class=0x030000 card=0x30d9103c chip=0x2a028086 rev=0x03 hdr=0x00 > vgapci1@pci0:0:2:1: class=0x038000 card=0x30d9103c chip=0x2a038086 rev=0x03 hdr=0x00 > hdac0@pci0:0:27:0: class=0x040300 card=0x505114f1 chip=0x284b8086 rev=0x03 hdr=0x00 > pcib1@pci0:0:28:0: class=0x060400 card=0x30d9103c chip=0x283f8086 rev=0x03 hdr=0x01 > uhci0@pci0:0:29:0: class=0x0c0300 card=0x30d9103c chip=0x28308086 rev=0x03 hdr=0x00 > uhci1@pci0:0:29:1: class=0x0c0300 card=0x30d9103c chip=0x28318086 rev=0x03 hdr=0x00 > uhci2@pci0:0:29:2: class=0x0c0300 card=0x30d9103c chip=0x28328086 rev=0x03 hdr=0x00 > ehci0@pci0:0:29:7: class=0x0c0320 card=0x30d9103c chip=0x28368086 rev=0x03 hdr=0x00 > pcib2@pci0:0:30:0: class=0x060401 card=0x30d9103c chip=0x24488086 rev=0xf3 hdr=0x01 > isab0@pci0:0:31:0: class=0x060100 card=0x30d9103c chip=0x28158086 rev=0x03 hdr=0x00 > atapci0@pci0:0:31:1: class=0x01018a card=0x30d9103c chip=0x28508086 rev=0x03 hdr=0x00 > atapci1@pci0:0:31:2: class=0x010601 card=0x30d9103c chip=0x28298086 rev=0x03 hdr=0x00 > none0@pci0:0:31:3: class=0x0c0500 card=0x30d9103c chip=0x283e8086 rev=0x03 hdr=0x00 > ath0@pci0:1:0:0: class=0x020000 card=0x137b103c chip=0x001c168c rev=0x01 hdr=0x00 > rl0@pci0:2:1:0: class=0x020000 card=0x30d9103c chip=0x813910ec rev=0x10 hdr=0x00 > > % dmesg|tail -11 > ath_hal: 0.10.5.6 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, RF2425, RF2417) > ath0: mem 0x91300000-0x9130ffff irq 16 at device 0.0 on pci1 > ath0: [ITHREAD] > ath0: WARNING: using obsoleted if_watchdog interface > ath0: mac 14.2 phy 7.0 radio 10.2 > ath0: detached > ath_hal: 0.10.5.10 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, RF2425, RF2417) > ath0: mem 0x91300000-0x9130ffff irq 16 at device 0.0 on pci1 > ath0: [ITHREAD] > ath0: WARNING: using obsoleted if_watchdog interface > ath0: mac 14.2 phy 7.0 radio 10.2 > > % ifconfig ath0 > ath0: flags=8843 metric 0 mtu 2290 > ether 00:1f:3a:1a:50:b3 > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) > status: no carrier > > % sudo ifconfig ath0 scan > Password: > ifconfig: unable to get scan results > > % sudo ifconfig ath0 bgscan > ifconfig: SIOCS80211: Invalid argument > > % sudo ifconfig wlan create wlandev ath0 > wlan0 > > % sudo wpa_supplicant -Dbsd -iwlan0 -c/etc/wpa_supplicant.conf > Trying to associate with 00:1e:2a:76:f4:60 (SSID='18-B-PARVATIYA' freq=2437 MHz) > Authentication with 00:1e:2a:76:f4:60 timed out. > Trying to associate with 00:1e:2a:76:f4:60 (SSID='18-B-PARVATIYA' freq=2437 MHz) > Authentication with 00:1e:2a:76:f4:60 timed out. > Trying to associate with 00:1e:2a:76:f4:60 (SSID='18-B-PARVATIYA' freq=2437 MHz) > Authentication with 00:1e:2a:76:f4:60 timed out. > Trying to associate with 00:1e:2a:76:f4:60 (SSID='18-B-PARVATIYA' freq=2437 MHz) > Authentication with 00:1e:2a:76:f4:60 timed out. > Trying to associate with 00:1e:2a:76:f4:60 (SSID='18-B-PARVATIYA' freq=2437 MHz) > Authentication with 00:1e:2a:76:f4:60 timed out. > ---->8---->8---- > > I've tested my wireless NIC working fine in Gentoo GNU/Linux with > ath_hal 0.10.5.6. And in FreeBSD 8.0-CURRENT, I've tried both versions > of ath_hal (i.e. 0.10.5.6 and 0.10.5.10), but no success. BtW, I've > loaded wlan_tkip, wlan_ccmp, and wlan_wep kernel modules. > > Any ideas how to get this wireless NIC working in FreeBSD 8-CURRENT ? > amd64 or i386? Sam From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 22:43:23 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5E4D1065673 for ; Fri, 19 Sep 2008 22:43:23 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by mx1.freebsd.org (Postfix) with ESMTP id 5C99F8FC12 for ; Fri, 19 Sep 2008 22:43:22 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so684190fgb.35 for ; Fri, 19 Sep 2008 15:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=wTYytnkuCLtx+9HVfRz/pOHao4+3wB5ohEM+f7zUuJ4=; b=QCK5HcAUlW8AU2jUG/gb/PwhCq+tksOtPvAvJHQYr9KOepJH1QB7Dfd1fhYpC0t9ob zU69NtYFu9RSJ/0KC8U21BgqP05uwT5LbNYWfCvW7dwFICX5buR2gUpn4raGn6Bhk+u4 uV2GiGKGZY7lDEB3O52BWQKa6IOemC1DPTStU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=xqvRsKeEzugi4hpe2nlseBBapJZlHJJmMvUcsIKeRMwWbBnizJXR0p+l1UUOtBRSQw pauSHrUAyhpeRJi956Kf7S2fUHSJGAKdUM6aSc3jZ7uHdRttatVb9kAkIiDkzar1UsMg BVkdvPhMySi2MLyYOpkGjgKk5SmpkGczzT0iA= Received: by 10.86.98.10 with SMTP id v10mr2578227fgb.46.1221864201536; Fri, 19 Sep 2008 15:43:21 -0700 (PDT) Received: by 10.86.62.1 with HTTP; Fri, 19 Sep 2008 15:43:21 -0700 (PDT) Message-ID: Date: Fri, 19 Sep 2008 15:43:21 -0700 From: "Maksim Yevmenkin" To: "Alexey Shuvaev" In-Reply-To: <20080919203310.GA34131@localhost.my.domain> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1342_5580332.1221864201515" References: <48D2F942.4070801@FreeBSD.org> <20080919084201.GD44330@wep4035.physik.uni-wuerzburg.de> <48D38DFF.8000803@FreeBSD.org> <20080919203310.GA34131@localhost.my.domain> Cc: freebsd-current@freebsd.org Subject: Re: Interface auto-cloning bug or feature? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 22:43:23 -0000 ------=_Part_1342_5580332.1221864201515 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline [....] >> That what has caused me to look into this issue. You can find patch for >> security/vpnc to prevent unbounded interface cloning here: >> >> http://sobomax.sippysoft.com/~sobomax/vpnc.diff >> > Ok, the patch prevents interface cloning, but I think it doesn't solve > the actual problem. > Let's wait for Maksim :) ok, how about attached patch. i put it together *very* quickly and only gave it a light testing. its for tap(4), because i could compile it as a module and tun(4) is compiled into kernel by default, but the idea should identical for tun(4). should be even simpler for tun(4) because it does not have to deal with 2 kind of devices (i.e. tap and vmnet). give it a try, and see if it works. please try both cloning paths, i.e. 1) cat /dev/tap (/dev/vmnet) with and/or without unit number and 2) ifconfig tapX (vmnetX) create/destroy in the mean time i will prepare something similar for tun(4). thanks, max ------=_Part_1342_5580332.1221864201515 Content-Type: text/plain; name=if_tap.c.diff.txt Content-Transfer-Encoding: base64 X-Attachment-Id: f_flbe63da0 Content-Disposition: attachment; filename=if_tap.c.diff.txt LS0tIGlmX3RhcC5jLm9yaWcJMjAwOC0wOS0wOCAxNzoyMDo1Ny4wMDAwMDAwMDAgLTA3MDAKKysr IGlmX3RhcC5jCTIwMDgtMDktMTkgMTU6MzU6MDIuMDAwMDAwMDAwIC0wNzAwCkBAIC05NCw2ICs5 NCw3IEBACiBzdGF0aWMgaW50CQl0YXBpZmlvY3RsKHN0cnVjdCBpZm5ldCAqLCB1X2xvbmcsIGNh ZGRyX3QpOwogc3RhdGljIHZvaWQJCXRhcGlmaW5pdCh2b2lkICopOwogCitzdGF0aWMgaW50CQl0 YXBfY2xvbmVfbG9va3VwKHN0cnVjdCBjZGV2ICoqLCB1X3Nob3J0KTsKIHN0YXRpYyBpbnQJCXRh cF9jbG9uZV9jcmVhdGUoc3RydWN0IGlmX2Nsb25lICosIGludCwgY2FkZHJfdCk7CiBzdGF0aWMg dm9pZAkJdGFwX2Nsb25lX2Rlc3Ryb3koc3RydWN0IGlmbmV0ICopOwogc3RhdGljIGludAkJdm1u ZXRfY2xvbmVfY3JlYXRlKHN0cnVjdCBpZl9jbG9uZSAqLCBpbnQsIGNhZGRyX3QpOwpAQCAtMTc2 LDYgKzE3NywyOCBAQAogREVWX01PRFVMRShpZl90YXAsIHRhcG1vZGV2ZW50LCBOVUxMKTsKIAog c3RhdGljIGludAordGFwX2Nsb25lX2xvb2t1cChzdHJ1Y3QgY2RldiAqKmRldiwgdV9zaG9ydCBl eHRyYSkKK3sKKwlzdHJ1Y3QgdGFwX3NvZnRjICp0cDsKKworCW10eF9sb2NrKCZ0YXBtdHgpOwor CVNMSVNUX0ZPUkVBQ0godHAsICZ0YXBoZWFkLCB0YXBfbmV4dCkgeworCQltdHhfbG9jaygmdHAt PnRhcF9tdHgpOworCQlpZiAoKHRwLT50YXBfZmxhZ3MgJiAoVEFQX09QRU58ZXh0cmEpKSA9PSBl eHRyYSkgeworCQkJKmRldiA9IHRwLT50YXBfZGV2OworCQkJbXR4X3VubG9jaygmdHAtPnRhcF9t dHgpOworCQkJbXR4X3VubG9jaygmdGFwbXR4KTsKKworCQkJcmV0dXJuICgxKTsKKwkJfQorCQlt dHhfdW5sb2NrKCZ0cC0+dGFwX210eCk7CisJfQorCW10eF91bmxvY2soJnRhcG10eCk7CisKKwly ZXR1cm4gKDApOworfQorCitzdGF0aWMgaW50CiB0YXBfY2xvbmVfY3JlYXRlKHN0cnVjdCBpZl9j bG9uZSAqaWZjLCBpbnQgdW5pdCwgY2FkZHJfdCBwYXJhbXMpCiB7CiAJc3RydWN0IGNkZXYgKmRl djsKQEAgLTM1Myw4ICszNzYsMTggQEAKIAogCS8qIFdlJ3JlIGludGVyZXN0ZWQgaW4gb25seSB0 YXAvdm1uZXQgZGV2aWNlcy4gKi8KIAlpZiAoc3RyY21wKG5hbWUsIFRBUCkgPT0gMCkgeworCQlp ZiAodGFwX2Nsb25lX2xvb2t1cChkZXYsIDApKSB7CisJCQlkZXZfcmVmKCpkZXYpOworCQkJcmV0 dXJuOworCQl9CisKIAkJdW5pdCA9IC0xOwogCX0gZWxzZSBpZiAoc3RyY21wKG5hbWUsIFZNTkVU KSA9PSAwKSB7CisJCWlmICh0YXBfY2xvbmVfbG9va3VwKGRldiwgVEFQX1ZNTkVUKSkgeworCQkJ ZGV2X3JlZigqZGV2KTsKKwkJCXJldHVybjsKKwkJfQorCiAJCXVuaXQgPSAtMTsKIAkJZXh0cmEg PSBWTU5FVF9ERVZfTUFTSzsKIAl9IGVsc2UgaWYgKGRldl9zdGRjbG9uZShuYW1lLCBOVUxMLCBU QVAsICZ1bml0KSAhPSAxKSB7Cg== ------=_Part_1342_5580332.1221864201515-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 22:45:04 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8A651065688 for ; Fri, 19 Sep 2008 22:45:04 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id 357538FC1E for ; Fri, 19 Sep 2008 22:45:03 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so684580fgb.35 for ; Fri, 19 Sep 2008 15:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=d2ofeDKXwIAMXJimDdGsmYtiE5QcHkwfBaIt/h+HaOA=; b=FSfo49mIvz2m76Ml2BJgwxObvI9AqNdpMwrlUjxdAGodkX6VfYI0Fz34O20KOIp0wc BgJbIDtjN58OczVA7WdKOgoAaU9lQAoPK0qQB0RMWRCLrGarqf9Wx9G1Hq3sKiP2MFgF PkwQeSOZSo7MjHj7sTIL7nhjDgqfg+D9yZ/Hs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=G38XRe4aANQ04lwBhB5YkEqhB81UbNkHY7DWxdZATbHg50wStdkv26sT50TTiZasVe 2PAXQuB8c6t0g1ykYuFi3M0HN9hijJakPBvgH4rjZx9PdiIdyt2FmIL3WlWMRujBmuub ZUs8fErg174AsW+NCXVIaK6/oide5whpsHudc= Received: by 10.86.1.11 with SMTP id 11mr2570332fga.27.1221862691834; Fri, 19 Sep 2008 15:18:11 -0700 (PDT) Received: by 10.86.62.1 with HTTP; Fri, 19 Sep 2008 15:18:11 -0700 (PDT) Message-ID: Date: Fri, 19 Sep 2008 15:18:11 -0700 From: "Maksim Yevmenkin" To: "Alexey Shuvaev" In-Reply-To: <20080919203310.GA34131@localhost.my.domain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48D2F942.4070801@FreeBSD.org> <20080919084201.GD44330@wep4035.physik.uni-wuerzburg.de> <48D38DFF.8000803@FreeBSD.org> <20080919203310.GA34131@localhost.my.domain> Cc: freebsd-current@freebsd.org Subject: Re: Interface auto-cloning bug or feature? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 22:45:04 -0000 On 9/19/08, Alexey Shuvaev wrote: > On Fri, Sep 19, 2008 at 04:33:19AM -0700, Maxim Sobolev wrote: > > Alexey Shuvaev wrote: > >>> [root@sp1 /usr/home/sobomax]# ifconfig -a > >>> tun0: flags=8010 mtu 1500 > >>> tun1: flags=8010 mtu 1500 > >>> tun2: flags=8010 mtu 1500 > >>> tun3: flags=8010 mtu 1500 > >>> > >> Me too. > >> I have seen that using ppp(8) and security/vpnc. > > > > That what has caused me to look into this issue. You can find patch for > > security/vpnc to prevent unbounded interface cloning here: > > > > http://sobomax.sippysoft.com/~sobomax/vpnc.diff > > > > Ok, the patch prevents interface cloning, but I think it doesn't solve > the actual problem. > Let's wait for Maksim :) yes, i got distracted by real job :( it will take me a little longer. sorry about that. max From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 22:51:33 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC00F1065683 for ; Fri, 19 Sep 2008 22:51:33 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id 33A188FC23 for ; Fri, 19 Sep 2008 22:51:32 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so686187fgb.35 for ; Fri, 19 Sep 2008 15:51:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=8f03q2bSyahcLaDXD98Zr/+LeEU3hHNmxLCMDGqJhM8=; b=TzENi3+oH62axMpenFjten7qyLoj/6U92EmO1aNkM4tE8h0JH3i36+ROpGKv9UtVnd 4w62Kg/3s7oA3uyTdAZeMu0lswe+UknHJZubCmC80tIG5wXGDmimVdM3X9BO+GjlQrU9 qePfCGlN5XRvlFroNMCuzcU0OdlglFDZG32pc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=Xa47w2huNuffaVXW5tyCbhlcRMThvqWlGO6keFE46fdh1yDtfu5ox0+CVqVCysol3f HgHN0ekSR+ZsayS6j6q3jiFVZlagZhJrg3e0yHMJVgfijFuQEPQfUpYjA6KAbmJPSSdi FGJGXhi7ZjYtNG80I/DerZPbU1Hq6HHoFu0gQ= Received: by 10.86.79.19 with SMTP id c19mr2574657fgb.67.1221864691356; Fri, 19 Sep 2008 15:51:31 -0700 (PDT) Received: by 10.86.62.1 with HTTP; Fri, 19 Sep 2008 15:51:31 -0700 (PDT) Message-ID: Date: Fri, 19 Sep 2008 15:51:31 -0700 From: "Maksim Yevmenkin" To: "Alexey Shuvaev" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1383_28216885.1221864691344" References: <48D2F942.4070801@FreeBSD.org> <20080919084201.GD44330@wep4035.physik.uni-wuerzburg.de> <48D38DFF.8000803@FreeBSD.org> <20080919203310.GA34131@localhost.my.domain> Cc: freebsd-current@freebsd.org Subject: Re: Interface auto-cloning bug or feature? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 22:51:34 -0000 ------=_Part_1383_28216885.1221864691344 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Fri, Sep 19, 2008 at 3:43 PM, Maksim Yevmenkin wrote: > [....] > >>> That what has caused me to look into this issue. You can find patch for >>> security/vpnc to prevent unbounded interface cloning here: >>> >>> http://sobomax.sippysoft.com/~sobomax/vpnc.diff >>> >> Ok, the patch prevents interface cloning, but I think it doesn't solve >> the actual problem. >> Let's wait for Maksim :) > > ok, how about attached patch. i put it together *very* quickly and > only gave it a light testing. its for tap(4), because i could compile > it as a module and tun(4) is compiled into kernel by default, but the > idea should identical for tun(4). should be even simpler for tun(4) > because it does not have to deal with 2 kind of devices (i.e. tap and > vmnet). give it a try, and see if it works. please try both cloning > paths, i.e. > > 1) cat /dev/tap (/dev/vmnet) with and/or without unit number > > and > > 2) ifconfig tapX (vmnetX) create/destroy > > in the mean time i will prepare something similar for tun(4). attached is similar patch for tun(4). i only made sure it compiles :) rebuilding kernel now... thanks, max ------=_Part_1383_28216885.1221864691344 Content-Type: text/plain; name=if_tun.c.diff.txt Content-Transfer-Encoding: base64 X-Attachment-Id: f_flbenwdo1 Content-Disposition: attachment; filename=if_tun.c.diff.txt LS0tIGlmX3R1bi5jLm9yaWcJMjAwOC0wNi0yMCAxNjo0NTowNy4wMDAwMDAwMDAgLTA3MDAKKysr IGlmX3R1bi5jCTIwMDgtMDktMTkgMTU6NDc6NTUuMDAwMDAwMDAwIC0wNzAwCkBAIC0xMjksNiAr MTI5LDcgQEAKIAkJICAgIHN0cnVjdCBydGVudHJ5ICpydCk7CiBzdGF0aWMgdm9pZAl0dW5zdGFy dChzdHJ1Y3QgaWZuZXQgKik7CiAKK3N0YXRpYyBpbnQJdHVuX2Nsb25lX2xvb2t1cChzdHJ1Y3Qg Y2RldiAqKik7CiBzdGF0aWMgaW50CXR1bl9jbG9uZV9jcmVhdGUoc3RydWN0IGlmX2Nsb25lICos IGludCwgY2FkZHJfdCk7CiBzdGF0aWMgdm9pZAl0dW5fY2xvbmVfZGVzdHJveShzdHJ1Y3QgaWZu ZXQgKik7CiAKQEAgLTE3NCw2ICsxNzUsMjggQEAKIH07CiAKIHN0YXRpYyBpbnQKK3R1bl9jbG9u ZV9sb29rdXAoc3RydWN0IGNkZXYgKipkZXYpCit7CisJc3RydWN0IHR1bl9zb2Z0YyAqdHA7CisK KwltdHhfbG9jaygmdHVubXR4KTsKKwlUQUlMUV9GT1JFQUNIKHRwLCAmdHVuaGVhZCwgdHVuX2xp c3QpIHsKKwkJbXR4X2xvY2soJnRwLT50dW5fbXR4KTsKKwkJaWYgKCh0cC0+dHVuX2ZsYWdzICYg VFVOX09QRU4pID09IDApIHsKKwkJCSpkZXYgPSB0cC0+dHVuX2RldjsKKwkJCW10eF91bmxvY2so JnRwLT50dW5fbXR4KTsKKwkJCW10eF91bmxvY2soJnR1bm10eCk7CisKKwkJCXJldHVybiAoMSk7 CisJCX0KKwkJbXR4X3VubG9jaygmdHAtPnR1bl9tdHgpOworCX0KKwltdHhfdW5sb2NrKCZ0dW5t dHgpOworCisJcmV0dXJuICgwKTsKK30KKworc3RhdGljIGludAogdHVuX2Nsb25lX2NyZWF0ZShz dHJ1Y3QgaWZfY2xvbmUgKmlmYywgaW50IHVuaXQsIGNhZGRyX3QgcGFyYW1zKQogewogCXN0cnVj dCBjZGV2ICpkZXY7CkBAIC0yMTMsNiArMjM2LDExIEBACiAJCXJldHVybjsKIAogCWlmIChzdHJj bXAobmFtZSwgVFVOTkFNRSkgPT0gMCkgeworCQlpZiAodHVuX2Nsb25lX2xvb2t1cChkZXYpKSB7 CisJCQlkZXZfcmVmKCpkZXYpOworCQkJcmV0dXJuOworCQl9CisKIAkJdSA9IC0xOwogCX0gZWxz ZSBpZiAoZGV2X3N0ZGNsb25lKG5hbWUsIE5VTEwsIFRVTk5BTUUsICZ1KSAhPSAxKQogCQlyZXR1 cm47CS8qIERvbid0IHJlY29nbmlzZSB0aGUgbmFtZSAqLwo= ------=_Part_1383_28216885.1221864691344-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 23:13:35 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A44031065671 for ; Fri, 19 Sep 2008 23:13:35 +0000 (UTC) (envelope-from wahjava@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.184]) by mx1.freebsd.org (Postfix) with ESMTP id 0E72F8FC25 for ; Fri, 19 Sep 2008 23:13:34 +0000 (UTC) (envelope-from wahjava@gmail.com) Received: by ti-out-0910.google.com with SMTP id d27so328633tid.3 for ; Fri, 19 Sep 2008 16:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:cc:subject:x-face :references:x-uptime:x-url:x-openpgp-id:x-openpgp-fingerprint:x-os :x-mailer:x-mail-morse:x-attribution:organization:from:date :in-reply-to:message-id:user-agent:face:mime-version:content-type :sender; bh=l68lYl3F4XwhQLRi8bgfkvRF0rtMVC0RJD8v/XB5vmQ=; b=ZQ9sqG6As2duGE0ZszYtXxp5kimWyIjNSGphHyj7ISH0gZfHJaXGMtrmq3XUlh0N+k y0PzT29UrEM6F+5P4CrsqTKFYo/PlV+OsjHoEx5GAZbbYKI3uX6aXWU1pD0y0L/6cUnF YqEG6tp7zVSMrlLN8FslEvrqluZ5j4dpTJhyI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:cc:subject:x-face:references:x-uptime:x-url:x-openpgp-id :x-openpgp-fingerprint:x-os:x-mailer:x-mail-morse:x-attribution :organization:from:date:in-reply-to:message-id:user-agent:face :mime-version:content-type:sender; b=ocIm1UHquhuxi++DZ4MIxfdS/81AVZXaNZGdMdHhUva86anzpIn2heVaZgrAbM2NWG aGC9UFX/bKe5lHE4iGm7nWWsEouXwvwS11oWupZX+syhwzRtMA7+bzmRhB54kZHp8FC0 w+nr3DStUEM3xj9x5x0m0Qkmho1svsis7X8TI= Received: by 10.110.103.5 with SMTP id a5mr1144234tic.2.1221866013722; Fri, 19 Sep 2008 16:13:33 -0700 (PDT) Received: from chateau.d.lf ( [122.163.146.62]) by mx.google.com with ESMTPS id w12sm3710080tib.1.2008.09.19.16.13.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Sep 2008 16:13:32 -0700 (PDT) To: Sam Leffler X-Face: )vGQ9yK7Y$Flebu1C>(B\gYBm)[$zfKM+p&TT[[JWl6:]S>cc$%-z7-`46Zf0B*syL.C]oCq[upTG~zuS0.$"_%)|Q@$hA=9{3l{%u^h3jJ^Zl; t7 References: <87bpyjkc6p.fsf@chateau.d.lf> <48D4292B.3010908@freebsd.org> X-Uptime: 04:42:11 up 17:31, 1 user, load average: 0.00, 0.02, 0.05 X-URL: http://wahjava.wordpress.com/ X-OpenPGP-ID: 762E5E74 X-OpenPGP-Fingerprint: 1E00 4679 77E4 F8EE 2E4B 56F2 1F2F 8410 762E 5E74 X-OS: GNU/Linux on Linux 2.6.25-gentoo-r7 kernel on x86_64 architecture X-Mailer: Gnus/5.11 (Oort 5.11) Emacs/22.3.1 (x86_64-pc-linux-gnu) X-Mail-Morse: .-- .- .... .--- .- ...- .- .--.-. --. -- .- .. .-.. .-.-.- -.-. --- -- X-Attribution: =?utf-8?B?4KSG4KS24KWA4KS3?= Organization: alt.religion.emacs From: wahjava.ml@gmail.com (Ashish Shukla =?utf-8?B?4KSG4KS24KWA4KS3IA==?= =?utf-8?B?4KS24KWB4KSV4KWN4KSy?=) Date: Sat, 20 Sep 2008 04:43:39 +0530 In-Reply-To: <48D4292B.3010908@freebsd.org> (Sam Leffler's message of "Fri\, 19 Sep 2008 15\:35\:23 -0700") Message-ID: <873ajvk9uk.fsf@chateau.d.lf> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJ1BMVEWpqal/f39tbW1jY2Md HR2goKCenp6UlJROTk7////9/f35+fnT09ORJdieAAACVklEQVQ4jXXUP2vbQBQA8AvUTkgz5OzY Z0iGWhpS6BSrkECn0mvx0MEJ6AjtYrfoBCVDlD8naJYmNlRfwZq8+mkKlIZaGpJSYmP7Q/XkJDrJ Td8i/H68u3vHPaPufwLdf32AMA4A6GcAgvAamY1pOJiDIFqicTwLswDhfr3uxfFtkAY/GFHPMwzD 8zpnACmIOnE6js7rQb+v4NJrG9od0C+QgpHMy5jBewV+UDSMWiw1Y4fWfyV7+NGFzDsYa3pth9LJ Q4XvXxFHcJRvHOmygn5NAEabnDcQQguarnfoiwSCJ99jmKKcphsZONmWsDK9Ro7cvZOCtQdg8nje egLhc2LNlkLmsezzTFUUy5w18ocox/f0LaLgJy0zO75zk+9pp85GAj36xjqhdI0y3tq2m4dqqcWX zQWBTz8L1irvolXV4J+3q7eCDgVnttjNq6X8H+9KOZsuNk1uCzx8pSp+E9HImfJOTLdcGqo+YKnG EIovizkEn48V7BO+ch2DXcD4ENSpWiU+q8hjjbgTBZCXnZtyj0Ws4Q1Q0B2WXFtYZo65Bbyeeldw RS6qFueM80LlLA29YlVwGRYvFD+kwI/0O+A2PlpOP9GwslUVciHuYGechuBTp922YiDZCrghTknm XSyOM+D3aoRZlo0Jb42zY7DN4p2x4AeZ+QAYutx1sHwTHzMT5cMNduQ9yW3GczN4KZ86kb0c9O8T yXDeFqpl2fryPEAYGXIlezAPXYh2NgVr/gvdoHIuDwuPwOhcWE8f8mmICq41eATkn8x0kuRTIKcB wE9+/QUtiiAnYcaN7wAAAABJRU5ErkJggg== MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: =?UTF-8?B?4KSG4KS24KWA4KS3IOCktuClgeCkleCljeCksiBBc2hpc2ggU2h1a2xh?= Cc: freebsd-current@freebsd.org Subject: Re: Setting up atheros (168c:001c) wireless NIC in FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 23:13:35 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Sam Leffler writes: > amd64 or i386? sorry, I forgot to mention, I'm running FreeBSD 8.0-CURRENT on amd64 architecture built from a /usr/src checked out few hours ago. > Sam Ashish -- ·-- ·- ···· ·--- ·- ···- ·- ·--·-· --· -- ·- ·· ·-·· ·-·-·- -·-· --- -- () ascii ribbon campaign - against HTML e-mail /\ www.asciiribbon.org - against proprietary attachments --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjUMiYACgkQHy+EEHYuXnTU9QCeNkzf9F/aVqW3xu7EQ90D8OsP kYwAnRKVb4i8K9mvJIYZRs+aW4skvmHH =yOqJ -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 23:21:01 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3D5A106566C; Fri, 19 Sep 2008 23:21:01 +0000 (UTC) (envelope-from wessels@life-gone-hazy.com) Received: from life-gone-hazy.com (life-gone-hazy.com [12.160.37.4]) by mx1.freebsd.org (Postfix) with ESMTP id 78EC48FC17; Fri, 19 Sep 2008 23:21:01 +0000 (UTC) (envelope-from wessels@life-gone-hazy.com) Received: from life-gone-hazy.com (localhost [127.0.0.1]) by life-gone-hazy.com (8.14.2/8.13.4) with ESMTP id m8JN2aZd021824; Fri, 19 Sep 2008 16:02:36 -0700 (PDT) (envelope-from wessels@life-gone-hazy.com) Received: (from wessels@localhost) by life-gone-hazy.com (8.14.2/8.14.2/Submit) id m8JN2a00021821; Fri, 19 Sep 2008 16:02:36 -0700 (PDT) (envelope-from wessels) Date: Fri, 19 Sep 2008 16:02:36 -0700 (PDT) From: Duane Wessels <0ac5@packet-pushers.com> X-X-Sender: wessels@life-gone-hazy.com To: freebsd-net@freebsd.org In-Reply-To: <4734a3ed0809150659n438a5b20r59278908f4032a45@mail.gmail.com> Message-ID: <20080919155900.P29264@life-gone-hazy.com> References: <20080828002919.GA54169@alpha.local> <4734a3ed0809150659n438a5b20r59278908f4032a45@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (life-gone-hazy.com [127.0.0.1]); Fri, 19 Sep 2008 16:02:36 -0700 (PDT) Cc: freebsd-current@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: HEADS UP: ath_hal updated to 0.10.5.10 -- PLEASE TEST X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 23:21:01 -0000 On Mon, 15 Sep 2008, Henri-Pierre Charles said: > I've tried 7.1-BETA and 8.0-CURRENT-200809 on my eeepc model 701 > > 7.1 does not recognize ath0, as expected, but 8.0-CURRENT does. For the record, the same is true for my Acer Aspire One. After updating sys/contrib/dev/ath to HEAD I now have a working ath0. hooray! Duane W. From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 00:21:26 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3948106567F; Sat, 20 Sep 2008 00:21:25 +0000 (UTC) (envelope-from frank@exit.com) Received: from tinker.exit.com (tinker.exit.com [206.223.0.1]) by mx1.freebsd.org (Postfix) with ESMTP id A759A8FC14; Sat, 20 Sep 2008 00:21:25 +0000 (UTC) (envelope-from frank@exit.com) Received: from jill.exit.com (jill.exit.com [IPv6:2001:470:80f4:0:2e0:81ff:fe33:7e9a]) by tinker.exit.com (8.14.2/8.14.2) with ESMTP id m8JNqUGZ012478; Fri, 19 Sep 2008 16:52:30 -0700 (PDT) (envelope-from frank@exit.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=exit.com; s=tinker; t=1221868350; bh=Fllz97wfc8ghZZigyxtVUOMEPhWL25nMv6CYHcroaEY=; h=Subject:From:Reply-To:To:Cc:In-Reply-To:References:Content-Type: Content-Transfer-Encoding:Date:Message-Id:Mime-Version; b=kiBCmOBf XuavatYnQjP9HbkTN4ScrEu8qkIlH6kb0Fj2F+wood7pPTlPL8pv0GQXO1e6bvKxiRt Gs5mD5WXPEwOHBB1+MaX3kEBmXjsn85derVvVbKC5F96AyWTcahTfA/jk787tHdEc+B ct0RkgpljHP88BYBJvZYICMi8ImJw= Received: from jill.exit.com (localhost [127.0.0.1]) by jill.exit.com (8.14.2/8.14.2) with ESMTP id m8JNqaSO063319; Fri, 19 Sep 2008 16:52:36 -0700 (PDT) (envelope-from frank@exit.com) Received: (from frank@localhost) by jill.exit.com (8.14.2/8.14.2/Submit) id m8JNqaHO063318; Fri, 19 Sep 2008 16:52:36 -0700 (PDT) (envelope-from frank@exit.com) X-Authentication-Warning: jill.exit.com: frank set sender to frank@exit.com using -f From: Frank Mayhar To: Duane Wessels <0ac5@packet-pushers.com> In-Reply-To: <20080919155900.P29264@life-gone-hazy.com> References: <20080828002919.GA54169@alpha.local> <4734a3ed0809150659n438a5b20r59278908f4032a45@mail.gmail.com> <20080919155900.P29264@life-gone-hazy.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Exit Consulting Date: Fri, 19 Sep 2008 16:52:35 -0700 Message-Id: <1221868355.63110.2.camel@jill.exit.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-Virus-Scanned: ClamAV 0.93.3/8289/Fri Sep 19 13:42:07 2008 on tinker.exit.com X-Virus-Status: Clean Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: HEADS UP: ath_hal updated to 0.10.5.10 -- PLEASE TEST X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: frank@exit.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2008 00:21:26 -0000 On Fri, 2008-09-19 at 16:02 -0700, Duane Wessels wrote: > > On Mon, 15 Sep 2008, Henri-Pierre Charles said: > > > I've tried 7.1-BETA and 8.0-CURRENT-200809 on my eeepc model 701 > > > > 7.1 does not recognize ath0, as expected, but 8.0-CURRENT does. > > For the record, the same is true for my Acer Aspire One. After > updating sys/contrib/dev/ath to HEAD I now have a working ath0. > hooray! On the other hand, mine doesn't. I have a brand new Lifebook E8420 and I believe the Atheros wireless chipset is an a/g/n chipset. It lists as: none0@pci0:32:0:0: class=0x028000 card=0x147c10cf chip=0x002a168c rev=0x01 hdr=0x00 I read somewhere that this chipset is supported by the new ath9k Linux driver but, of course, I run FreeBSD. -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ http://www.zazzle.com/fmayhar* From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 00:34:25 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DA841065673; Sat, 20 Sep 2008 00:34:25 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id C9ED48FC15; Sat, 20 Sep 2008 00:34:24 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id E931FA06DB; Sat, 20 Sep 2008 02:34:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id DC776A06D8; Sat, 20 Sep 2008 02:34:22 +0200 (CEST) Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id C8B67A06D4; Sat, 20 Sep 2008 02:34:22 +0200 (CEST) Received: from localhost.my.domain ([80.129.180.100]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2) with ESMTP id 2008092002342212-35504 ; Sat, 20 Sep 2008 02:34:22 +0200 Received: by localhost.my.domain (sSMTP sendmail emulation); Sat, 20 Sep 2008 02:38:44 +0200 Date: Sat, 20 Sep 2008 02:38:43 +0200 From: Alexey Shuvaev To: Maksim Yevmenkin , Maxim Sobolev Message-ID: <20080920003843.GA2710@localhost.my.domain> References: <48D2F942.4070801@FreeBSD.org> <20080919084201.GD44330@wep4035.physik.uni-wuerzburg.de> <48D38DFF.8000803@FreeBSD.org> <20080919203310.GA34131@localhost.my.domain> MIME-Version: 1.0 In-Reply-To: Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.18 (2008-05-17) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.0.2|August 07, 2008) at 09/20/2008 02:34:22 AM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2|August 07, 2008) at 09/20/2008 02:34:22 AM, Serialize complete at 09/20/2008 02:34:22 AM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: freebsd-current@freebsd.org Subject: Re: Interface auto-cloning bug or feature? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2008 00:34:25 -0000 On Fri, Sep 19, 2008 at 03:51:31PM -0700, Maksim Yevmenkin wrote: > On Fri, Sep 19, 2008 at 3:43 PM, Maksim Yevmenkin > wrote: > > [....] > > > >>> That what has caused me to look into this issue. You can find patch for > >>> security/vpnc to prevent unbounded interface cloning here: > >>> > >>> http://sobomax.sippysoft.com/~sobomax/vpnc.diff > >>> > >> Ok, the patch prevents interface cloning, but I think it doesn't solve > >> the actual problem. > >> Let's wait for Maksim :) > > As for vpnc-script, yes I also think using kldstat to check if the module is present is more correct than stat-ing /dev/tun. Actually I have commented these lines out in my previous mail instead of applying the patch %-) > > ok, how about attached patch. i put it together *very* quickly and > > only gave it a light testing. its for tap(4), because i could compile > > it as a module and tun(4) is compiled into kernel by default, but the > > idea should identical for tun(4). should be even simpler for tun(4) > > because it does not have to deal with 2 kind of devices (i.e. tap and > > vmnet). give it a try, and see if it works. please try both cloning > > paths, i.e. > > > > 1) cat /dev/tap (/dev/vmnet) with and/or without unit number > > > > and > > > > 2) ifconfig tapX (vmnetX) create/destroy > > > > in the mean time i will prepare something similar for tun(4). > > attached is similar patch for tun(4). i only made sure it compiles :) > rebuilding kernel now... > Ok, I have tried both patches and in both cases 'cloning bug' is went away. I have tried cat /dev/tap (creates only /dev/tap0) cat /dev/tapX (creates exactly /dev/tapX) stat /dev/[tun|tap|vmnet] (creates only '0' device) and also running unpatched security/vpnc. Everything works fine! Thanks! Alexey. From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 00:57:35 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB05E106567F; Sat, 20 Sep 2008 00:57:35 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id ADCCC8FC0C; Sat, 20 Sep 2008 00:57:35 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m8K0vJ8q040725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Sep 2008 17:57:21 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <48D44A6F.1020408@freebsd.org> Date: Fri, 19 Sep 2008 17:57:19 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: frank@exit.com References: <20080828002919.GA54169@alpha.local> <4734a3ed0809150659n438a5b20r59278908f4032a45@mail.gmail.com> <20080919155900.P29264@life-gone-hazy.com> <1221868355.63110.2.camel@jill.exit.com> In-Reply-To: <1221868355.63110.2.camel@jill.exit.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: freebsd-net@freebsd.org, Duane Wessels <0ac5@packet-pushers.com>, freebsd-current@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: HEADS UP: ath_hal updated to 0.10.5.10 -- PLEASE TEST X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2008 00:57:36 -0000 Frank Mayhar wrote: > On Fri, 2008-09-19 at 16:02 -0700, Duane Wessels wrote: > >> On Mon, 15 Sep 2008, Henri-Pierre Charles said: >> >> >>> I've tried 7.1-BETA and 8.0-CURRENT-200809 on my eeepc model 701 >>> >>> 7.1 does not recognize ath0, as expected, but 8.0-CURRENT does. >>> >> For the record, the same is true for my Acer Aspire One. After >> updating sys/contrib/dev/ath to HEAD I now have a working ath0. >> hooray! >> > > On the other hand, mine doesn't. I have a brand new Lifebook E8420 and > I believe the Atheros wireless chipset is an a/g/n chipset. It lists > as: > > none0@pci0:32:0:0: class=0x028000 card=0x147c10cf chip=0x002a168c rev=0x01 hdr=0x00 > > I read somewhere that this chipset is supported by the new ath9k Linux > driver but, of course, I run FreeBSD. > That's a merlin part (aka 9280); I've got untested changes to support it. Unfortunately I don't have a card so it may take a while to get something out. Unfortunately it's not feasible for me to send out test code to try until I can actually work w/ a card. Sam From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 01:36:36 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27FC31065674 for ; Sat, 20 Sep 2008 01:36:36 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.186]) by mx1.freebsd.org (Postfix) with ESMTP id 9B1538FC15 for ; Sat, 20 Sep 2008 01:36:35 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by ti-out-0910.google.com with SMTP id d27so344013tid.3 for ; Fri, 19 Sep 2008 18:36:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=WaqUaaBUcO2QqVwK1tdenDI9WXVlhJwL++yCmo4c9qo=; b=w1Pdx0mCInbbJzmuxFpTHJ/lKty+vibj1u5T1sg7TvlMkrFLYVQpLosWtqk1jSAxCW GZJsEBnLvNLkPY5WG6MJOZxnQXmZ7c5nHHnp+B0N4rKey6vjd70WIal6gVAjzT/pJ5pa 9Met++ap7s2n4FtKsg9M4uZQAs+WT6EFFff6w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=i61ddH+hUSveRfYA5MVxyMLhX25kD1+9FZoyTsHnQJz9M6Pve80mJPdDJDR4evoZgD +UnNax6zqWW4VEaKOFSlqALPiG5unaV0oU0OskW6n7ZKUOBkrwgempq1XIs9Zm+CSW18 N5v6AFZ5B1TK7HjndWYZwGKwx/h5RxuonyiwY= Received: by 10.110.52.1 with SMTP id z1mr1299181tiz.19.1221874594477; Fri, 19 Sep 2008 18:36:34 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id i6sm6443826tid.16.2008.09.19.18.36.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Sep 2008 18:36:32 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m8K1YZYB019076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Sep 2008 10:34:35 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m8K1YY6h019075; Sat, 20 Sep 2008 10:34:34 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Sat, 20 Sep 2008 10:34:34 +0900 From: Pyun YongHyeon To: Ian Freislich Message-ID: <20080920013434.GB18734@cdnetworks.co.kr> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="+g7M9IMkV8truYOl" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: msk(4) issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2008 01:36:36 -0000 --+g7M9IMkV8truYOl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Sep 17, 2008 at 10:16:29AM +0200, Ian Freislich wrote: > Hi > > I'm having an issue with the msk hardware in my laptop. It stops > transmitting or recieving sometimes, always triggered by periods > of intense network load. > > Sep 16 18:39:31 apple kernel: msk0: watchdog timeout (missed Tx interrupts) -- recovering > Sep 16 18:40:35 apple kernel: msk0: watchdog timeout (missed Tx interrupts) -- recovering > Sep 16 18:41:41 apple kernel: msk0: watchdog timeout (missed Tx interrupts) -- recovering > > But it never recovers. > > mskc0@pci0:2:0:0: class=0x020000 card=0x532111ab chip=0x436211ab rev=0x22 hdr=0x00 > vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > device = '88E8053 Marvell Yukon 88E8053 PCI-E Gigabit Ethernet Controller' > class = network > subclass = ethernet > > Ian > Would you try attached patch? -- Regards, Pyun YongHyeon --+g7M9IMkV8truYOl Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="msk.watchdog.diff" Index: if_msk.c =================================================================== --- if_msk.c (revision 183165) +++ if_msk.c (working copy) @@ -244,6 +244,9 @@ static int msk_handle_events(struct msk_softc *); static void msk_handle_hwerr(struct msk_if_softc *, uint32_t); static void msk_intr_hwerr(struct msk_softc *); +#ifndef __NO_STRICT_ALIGNMENT +static __inline void msk_fixup_rx(struct mbuf *); +#endif static void msk_rxeof(struct msk_if_softc *, uint32_t, int); static void msk_jumbo_rxeof(struct msk_if_softc *, uint32_t, int); static void msk_txeof(struct msk_if_softc *, int); @@ -783,7 +786,12 @@ return (ENOBUFS); m->m_len = m->m_pkthdr.len = MCLBYTES; - m_adj(m, ETHER_ALIGN); + if ((sc_if->msk_flags & MSK_FLAG_RAMBUF) == 0) + m_adj(m, ETHER_ALIGN); +#ifndef __NO_STRICT_ALIGNMENT + else + m_adj(m, MSK_RX_BUF_ALIGN); +#endif if (bus_dmamap_load_mbuf_sg(sc_if->msk_cdata.msk_rx_tag, sc_if->msk_cdata.msk_rx_sparemap, m, segs, &nsegs, @@ -840,7 +848,12 @@ return (ENOBUFS); } m->m_pkthdr.len = m->m_len = MSK_JLEN; - m_adj(m, ETHER_ALIGN); + if ((sc_if->msk_flags & MSK_FLAG_RAMBUF) == 0) + m_adj(m, ETHER_ALIGN); +#ifndef __NO_STRICT_ALIGNMENT + else + m_adj(m, MSK_RX_BUF_ALIGN); +#endif if (bus_dmamap_load_mbuf_sg(sc_if->msk_cdata.msk_jumbo_rx_tag, sc_if->msk_cdata.msk_jumbo_rx_sparemap, m, segs, &nsegs, @@ -1041,14 +1054,16 @@ { int next; int i; - uint8_t val; /* Get adapter SRAM size. */ - val = CSR_READ_1(sc, B2_E_0); - sc->msk_ramsize = (val == 0) ? 128 : val * 4; + sc->msk_ramsize = CSR_READ_1(sc, B2_E_0) * 4; if (bootverbose) device_printf(sc->msk_dev, "RAM buffer size : %dKB\n", sc->msk_ramsize); + if (sc->msk_ramsize == 0) + return (0); + + sc->msk_pflags |= MSK_FLAG_RAMBUF; /* * Give receiver 2/3 of memory and round down to the multiple * of 1024. Tx/Rx RAM buffer size of Yukon II shoud be multiple @@ -1412,6 +1427,7 @@ sc_if->msk_if_dev = dev; sc_if->msk_port = port; sc_if->msk_softc = sc; + sc_if->msk_flags = sc->msk_pflags; sc->msk_if[port] = sc_if; /* Setup Tx/Rx queue register offsets. */ if (port == MSK_PORT_A) { @@ -1976,6 +1992,7 @@ struct msk_rxdesc *jrxd; struct msk_jpool_entry *entry; uint8_t *ptr; + bus_size_t rxalign; int error, i; mtx_init(&sc_if->msk_jlist_mtx, "msk_jlist_mtx", NULL, MTX_DEF); @@ -2107,9 +2124,16 @@ goto fail; } + rxalign = 1; + /* + * Workaround hardware hang which seems to happen when Rx buffer + * is not aligned on multiple of FIFO word(8 bytes). + */ + if ((sc_if->msk_flags & MSK_FLAG_RAMBUF) != 0) + rxalign = MSK_RX_BUF_ALIGN; /* Create tag for Rx buffers. */ error = bus_dma_tag_create(sc_if->msk_cdata.msk_parent_tag,/* parent */ - 1, 0, /* alignment, boundary */ + rxalign, 0, /* alignment, boundary */ BUS_SPACE_MAXADDR, /* lowaddr */ BUS_SPACE_MAXADDR, /* highaddr */ NULL, NULL, /* filter, filterarg */ @@ -2918,6 +2942,23 @@ return (0); } +#ifndef __NO_STRICT_ALIGNMENT +static __inline void +msk_fixup_rx(struct mbuf *m) +{ + int i; + uint16_t *src, *dst; + + src = mtod(m, uint16_t *); + dst = src - 3; + + for (i = 0; i < (m->m_len / sizeof(uint16_t) + 1); i++) + *dst++ = *src++; + + m->m_data -= (MSK_RX_BUF_ALIGN - ETHER_ALIGN); +} +#endif + static void msk_rxeof(struct msk_if_softc *sc_if, uint32_t status, int len) { @@ -2955,6 +2996,10 @@ } m->m_pkthdr.rcvif = ifp; m->m_pkthdr.len = m->m_len = len; +#ifndef __NO_STRICT_ALIGNMENT + if ((sc_if->msk_flags & MSK_FLAG_RAMBUF) != 0) + msk_fixup_rx(m); +#endif ifp->if_ipackets++; /* Check for VLAN tagged packets. */ if ((status & GMR_FS_VLAN) != 0 && @@ -3008,6 +3053,10 @@ } m->m_pkthdr.rcvif = ifp; m->m_pkthdr.len = m->m_len = len; +#ifndef __NO_STRICT_ALIGNMENT + if ((sc_if->msk_flags & MSK_FLAG_RAMBUF) != 0) + msk_fixup_rx(m); +#endif ifp->if_ipackets++; /* Check for VLAN tagged packets. */ if ((status & GMR_FS_VLAN) != 0 && @@ -3677,7 +3726,7 @@ /* Configure hardware VLAN tag insertion/stripping. */ msk_setvlan(sc_if, ifp); - if (sc->msk_hw_id == CHIP_ID_YUKON_EC_U) { + if ((sc_if->msk_flags & MSK_FLAG_RAMBUF) == 0) { /* Set Rx Pause threshould. */ CSR_WRITE_1(sc, MR_ADDR(sc_if->msk_port, RX_GMF_LP_THR), MSK_ECU_LLPP); @@ -3790,6 +3839,8 @@ int ltpp, utpp; sc = sc_if->msk_softc; + if ((sc_if->msk_flags & MSK_FLAG_RAMBUF) == 0) + return; /* Setup Rx Queue. */ CSR_WRITE_1(sc, RB_ADDR(sc_if->msk_rxq, RB_CTRL), RB_RST_CLR); Index: if_mskreg.h =================================================================== --- if_mskreg.h (revision 183165) +++ if_mskreg.h (working copy) @@ -2158,6 +2158,7 @@ #define MSK_TX_RING_CNT 256 #define MSK_RX_RING_CNT 256 +#define MSK_RX_BUF_ALIGN 8 #define MSK_JUMBO_RX_RING_CNT MSK_RX_RING_CNT #define MSK_STAT_RING_CNT ((1 + 3) * (MSK_TX_RING_CNT + MSK_RX_RING_CNT)) #define MSK_MAXTXSEGS 32 @@ -2307,6 +2308,7 @@ uint32_t msk_coppertype; uint32_t msk_intrmask; uint32_t msk_intrhwemask; + uint32_t msk_pflags; int msk_suspended; int msk_clock; int msk_msi; @@ -2348,6 +2350,8 @@ int msk_phytype; int msk_phyaddr; int msk_link; + uint32_t msk_flags; +#define MSK_FLAG_RAMBUF 0x0010 struct callout msk_tick_ch; int msk_watchdog_timer; uint32_t msk_txq; /* Tx. Async Queue offset */ --+g7M9IMkV8truYOl-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 01:55:50 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 724EB106566C; Sat, 20 Sep 2008 01:55:50 +0000 (UTC) (envelope-from bsd@fluffles.net) Received: from mail.fluffles.net (fluffles.net [80.69.95.190]) by mx1.freebsd.org (Postfix) with ESMTP id 387DB8FC1A; Sat, 20 Sep 2008 01:55:50 +0000 (UTC) (envelope-from bsd@fluffles.net) Received: from [10.10.0.2] (cust.95.160.adsl.cistron.nl [195.64.95.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: info@fluffles.net) by mail.fluffles.net (Postfix) with ESMTP id F0DA0B2A1F1; Sat, 20 Sep 2008 03:41:43 +0200 (CEST) Message-ID: <48D4552A.6080502@fluffles.net> Date: Sat, 20 Sep 2008 03:43:06 +0200 From: "fluffles.net" User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: =?UTF-8?B?QXNoaXNoIFNodWtsYSDgpIbgpLbgpYDgpLcg4KS24KWB4KSV4KWN4KSy?= References: <87bpyjkc6p.fsf@chateau.d.lf> <48D4292B.3010908@freebsd.org> <873ajvk9uk.fsf@chateau.d.lf> In-Reply-To: <873ajvk9uk.fsf@chateau.d.lf> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Sam Leffler , freebsd-current@freebsd.org Subject: Re: Setting up atheros (168c:001c) wireless NIC in FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2008 01:55:50 -0000 Ashish Shukla आशीष शुक्ल wrote: > Sam Leffler writes: > > >> amd64 or i386? >> > > sorry, I forgot to mention, I'm running FreeBSD 8.0-CURRENT on amd64 > architecture built from a /usr/src checked out few hours ago. > I've been having the same problems with Dell 167G USB Wlan dongle using the "rum" driver. Also recent 8-CUR amd64. I cannot do a SSID scan because it returns me: ifconfig: unable to get scan results Just like you. So this appears not to be related to the actual ath driver. Hope any knows about a workaround or solution. Regards, Veronica From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 02:21:53 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34C191065677; Sat, 20 Sep 2008 02:21:53 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id AED9F8FC1A; Sat, 20 Sep 2008 02:21:52 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 878E1198E9B; Sat, 20 Sep 2008 04:21:51 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 79BEE198E95; Sat, 20 Sep 2008 04:21:51 +0200 (CEST) Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 53A60198E90; Sat, 20 Sep 2008 04:21:51 +0200 (CEST) Received: from localhost.my.domain ([80.129.188.193]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2) with ESMTP id 2008092004215070-35617 ; Sat, 20 Sep 2008 04:21:50 +0200 Received: by localhost.my.domain (sSMTP sendmail emulation); Sat, 20 Sep 2008 04:26:12 +0200 Date: Sat, 20 Sep 2008 04:26:12 +0200 From: Alexey Shuvaev To: Marcel Moolenaar , xcllnt@mac.com Message-ID: <20080920022612.GA4934@localhost.my.domain> References: <20080829205313.GA30330@wep4017.physik.uni-wuerzburg.de> <3a142e750808291416o25b6678bm2b6fa75d0f8e4714@mail.gmail.com> <20080831103555.GA12957@wep4017.physik.uni-wuerzburg.de> MIME-Version: 1.0 In-Reply-To: <20080831103555.GA12957@wep4017.physik.uni-wuerzburg.de> Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.18 (2008-05-17) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.0.2|August 07, 2008) at 09/20/2008 04:21:50 AM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2|August 07, 2008) at 09/20/2008 04:21:51 AM, Serialize complete at 09/20/2008 04:21:51 AM Content-Type: multipart/mixed; boundary="DocE+STaALJfprDB" Content-Disposition: inline X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: freebsd-current@freebsd.org Subject: Re: Booting from gpt on i386/amd64? [PATCH] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2008 02:21:53 -0000 --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Aug 31, 2008 at 12:35:55PM +0200, Alexey Shuvaev wrote: > On Fri, Aug 29, 2008 at 11:16:07PM +0200, Paul B. Mahol wrote: > > On 8/29/08, Alexey Shuvaev wrote: > > > Hello list! > > > > > > I have tried to install a system with pure gpt partitioning, > > > but haven't managed to boot from it. > > > > > > Partition table: > > > > > > => 34 976773101 ad6 GPT (500.1GB) > > > 34 1571840 1 freebsd-ufs (804.8MB) > > > 1571874 8388608 2 freebsd-swap (4.3GB) > > > 9960482 1024 3 freebsd-boot (524.3KB) > > > 9961506 8388608 4 freebsd-ufs (4.3GB) > > > 18350114 524288 5 freebsd-ufs (268.4MB) > > > 18874402 134217728 6 freebsd-ufs (68.7GB) > > > 153092130 823681005 - free - (421.7GB) > > > > > > All necessary files are already installed (ad6p1 = /, ad6p4 = /var, and > > > so on). The system is 8.0-CURRENT from 8 August (bootable usb flash). > > > Computer is Core2Duo E8400 3.0 GHz, 4 Gb RAM, ICH9, 500 GB SATA. > > > What have been done: > > > > > > gpart bootcode -b /path/to/pmbr ad6 > > > [Successful] > > > > > > gpart bootcode -p /path/to/gptboot -i 3 ad6 > > > gpart: /dev/ad6p3: Invalid argument > > > > > > I have tried to 'newfs /dev/ad6p3' and then mounting it and copying > > > gptboot into 'boot' directory on ad6p3, but looking at the sources it > > > seems to be wrong. > > > > > > Then I tried to 'dd if=gptboot of=/dev/ad6p3 bs=512', > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > This command writes gptboot only partially!!! > I have padded gptboot to nearest sector boundary and dd-ed it to ad6p3. > After that the system booted successfully. > As I have expected GENERIC kernel is enough. > > > > but in all cases during the boot the blinking cursor moves 1 line down > > > and computer freezes here. > > > > The remaining question is what is the correct way to put gptboot to > 'freebsd-boot' partition? > It seems that this functionality was in gpt(8) but is missing in > gpart(8). Any work in progress? While I am here should I look at it? > Ok, I have digged the sources a little bit and ended with this simple patch. Actually, the code is taken from gpt(8) utility. It adds automatic padding of gptboot bootcode to the nearest sector boundary. Alexey. --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=patch-gpart --- sbin/geom/class/part/geom_part.c.orig 2008-08-08 18:14:25.000000000 +0200 +++ sbin/geom/class/part/geom_part.c 2008-09-20 04:13:15.000000000 +0200 @@ -386,6 +386,8 @@ struct ggeom *gp; struct gprovider *pp; const char *s; + char *buf; + off_t bsize; int error, fd; s = gctl_get_ascii(req, "class"); @@ -421,7 +423,17 @@ errx(EXIT_FAILURE, "%s: not enough space", dsf); if (lseek(fd, 0, SEEK_SET) != 0) err(EXIT_FAILURE, "%s", dsf); - if (write(fd, code, size) != size) + + /* + * When writing to a disk device, the write must be + * sector aligned and not write to any partial sectors, + * so round up the buffer size to the next sector and zero it. + */ + bsize = (size + pp->lg_sectorsize - 1) / + pp->lg_sectorsize * pp->lg_sectorsize; + buf = calloc(1, bsize); + bcopy(code, buf, size); + if (write(fd, buf, bsize) != bsize) err(EXIT_FAILURE, "%s", dsf); close(fd); } else --DocE+STaALJfprDB-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 05:12:13 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D94EC106566C; Sat, 20 Sep 2008 05:12:13 +0000 (UTC) (envelope-from frank@exit.com) Received: from tinker.exit.com (tinker.exit.com [206.223.0.1]) by mx1.freebsd.org (Postfix) with ESMTP id 79E578FC08; Sat, 20 Sep 2008 05:12:13 +0000 (UTC) (envelope-from frank@exit.com) Received: from jill.exit.com (jill.exit.com [IPv6:2001:470:80f4:0:2e0:81ff:fe33:7e9a]) by tinker.exit.com (8.14.2/8.14.2) with ESMTP id m8K5BUWm016210; Fri, 19 Sep 2008 22:11:30 -0700 (PDT) (envelope-from frank@exit.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=exit.com; s=tinker; t=1221887491; bh=XwVgMcLjYaJKgmpOVuKojVUPQOKUcHFtVWNa3QXMWVw=; h=Subject:From:Reply-To:To:Cc:In-Reply-To:References:Content-Type: Content-Transfer-Encoding:Date:Message-Id:Mime-Version; b=ePKitSUQ 0jiO7m5AttimKrFlFic13gyNkIhKHhXEU3aAlipvc/L8qp05T7xK497GL7Cc2BYR04m wrGKrmngQLJeC/YThqN1bOLrncbAmcO7XJNZtyPb69WkOdhMqEjvoSbq2201jh5zaz3 zhVxgD/ZLFPgVnj0OTsmVXfLHmiq0= Received: from jill.exit.com (localhost [127.0.0.1]) by jill.exit.com (8.14.2/8.14.2) with ESMTP id m8K5BfnV064542; Fri, 19 Sep 2008 22:11:41 -0700 (PDT) (envelope-from frank@exit.com) Received: (from frank@localhost) by jill.exit.com (8.14.2/8.14.2/Submit) id m8K5BeDM064541; Fri, 19 Sep 2008 22:11:40 -0700 (PDT) (envelope-from frank@exit.com) X-Authentication-Warning: jill.exit.com: frank set sender to frank@exit.com using -f From: Frank Mayhar To: Sam Leffler In-Reply-To: <48D44A6F.1020408@freebsd.org> References: <20080828002919.GA54169@alpha.local> <4734a3ed0809150659n438a5b20r59278908f4032a45@mail.gmail.com> <20080919155900.P29264@life-gone-hazy.com> <1221868355.63110.2.camel@jill.exit.com> <48D44A6F.1020408@freebsd.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Exit Consulting Date: Fri, 19 Sep 2008 22:11:39 -0700 Message-Id: <1221887499.64423.1.camel@jill.exit.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-Virus-Scanned: ClamAV 0.93.3/8290/Fri Sep 19 18:23:09 2008 on tinker.exit.com X-Virus-Status: Clean Cc: freebsd-net@freebsd.org, Duane Wessels <0ac5@packet-pushers.com>, freebsd-current@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: HEADS UP: ath_hal updated to 0.10.5.10 -- PLEASE TEST X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: frank@exit.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2008 05:12:14 -0000 On Fri, 2008-09-19 at 17:57 -0700, Sam Leffler wrote: > Frank Mayhar wrote: > > On Fri, 2008-09-19 at 16:02 -0700, Duane Wessels wrote: > > > >> On Mon, 15 Sep 2008, Henri-Pierre Charles said: > >> > >> > >>> I've tried 7.1-BETA and 8.0-CURRENT-200809 on my eeepc model 701 > >>> > >>> 7.1 does not recognize ath0, as expected, but 8.0-CURRENT does. > >>> > >> For the record, the same is true for my Acer Aspire One. After > >> updating sys/contrib/dev/ath to HEAD I now have a working ath0. > >> hooray! > >> > > > > On the other hand, mine doesn't. I have a brand new Lifebook E8420 and > > I believe the Atheros wireless chipset is an a/g/n chipset. It lists > > as: > > > > none0@pci0:32:0:0: class=0x028000 card=0x147c10cf chip=0x002a168c rev=0x01 hdr=0x00 > > > > I read somewhere that this chipset is supported by the new ath9k Linux > > driver but, of course, I run FreeBSD. > > > That's a merlin part (aka 9280); I've got untested changes to support > it. Unfortunately I don't have a card so it may take a while to get > something out. Unfortunately it's not feasible for me to send out test > code to try until I can actually work w/ a card. I would happily pay for a card if that would help. Just pick out the one you want and let me know. -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ http://www.zazzle.com/fmayhar* From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 09:28:18 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 427FF106564A for ; Sat, 20 Sep 2008 09:28:18 +0000 (UTC) (envelope-from trebestie@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by mx1.freebsd.org (Postfix) with ESMTP id 141778FC1B for ; Sat, 20 Sep 2008 09:28:12 +0000 (UTC) (envelope-from trebestie@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so845407wfg.7 for ; Sat, 20 Sep 2008 02:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=o+ADP/KCWKFUC4AD4bBXLoX7moZns7T/6cKlATQ28Gk=; b=KIcS08LbOzG2cCrqFfHs+e3qjle88sxkI7I5JlFgpLJSPyi0DZr1yU5ltT8Bfhr8OU omVBji1puOnj0aVzYOZcv32JIBwyuN0odgZih4dVr/R3SZvknASBkdSNQt5M8cS9K4aa cHXHByimaxioLmTELiqqkZtBYJWQdSrGulYvw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=XrLY66bUltRkZbaOgJJFKnPgUJ7vbA3NLG7Yxkse+swh/qjZbR/Qqah0NCeJ2akow3 5sQQVWmmuNbVwJU4iS9/vFNG8S5XuFGYDGVesj8FqaFHFarA+IeWI/kVZ1hKw6VCL+NA mZJ0viR8tOxoC9lM+b+JoOvNMTC5biMpdGtu0= Received: by 10.142.180.19 with SMTP id c19mr426171wff.263.1221901129152; Sat, 20 Sep 2008 01:58:49 -0700 (PDT) Received: by 10.142.141.16 with HTTP; Sat, 20 Sep 2008 01:58:49 -0700 (PDT) Message-ID: <83e5fb980809200158h4650ad2ci55883ef93e69d1d8@mail.gmail.com> Date: Sat, 20 Sep 2008 10:58:49 +0200 From: "Diego Depaoli" To: freebsd-current MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Today build breaks nvidia driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2008 09:28:18 -0000 Hi all, I've some trouble building nvidia driver after today world/kernel. Here's the log: ===> Configuring for nvidia-driver-173.14.12 ===> Building for nvidia-driver-173.14.12 ===> src (all) @ -> /usr/src/sys machine -> /usr/src/sys/i386/include awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h cc -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\"173.14.12\" -D__KERNEL__ -DNVRM -UDEBUG -U_DEBUG -DNDEBUG -O -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c nvidia_ctl.c cc -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\"173.14.12\" -D__KERNEL__ -DNVRM -UDEBUG -U_DEBUG -DNDEBUG -O -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c nvidia_dev.c cc -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\"173.14.12\" -D__KERNEL__ -DNVRM -UDEBUG -U_DEBUG -DNDEBUG -O -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c nvidia_linux.c cc -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\"173.14.12\" -D__KERNEL__ -DNVRM -UDEBUG -U_DEBUG -DNDEBUG -O -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c nvidia_os.c cc1: warnings being treated as errors nvidia_os.c: In function 'os_is_administrator': nvidia_os.c:168: warning: implicit declaration of function 'suser' nvidia_os.c:168: warning: nested extern declaration of 'suser' *** Error code 1 Stop in /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-173.14.12/src. *** Error code 1 Stop in /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-173.14.12. *** Error code 1 Stop in /usr/ports/x11/nvidia-driver. *** Error code 1 Stop in /usr/ports/x11/nvidia-driver. Thanks in advance -- Diego Depaoli From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 10:26:40 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA5E9106566B for ; Sat, 20 Sep 2008 10:26:40 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mta4.srv.hcvlny.cv.net (mta4.srv.hcvlny.cv.net [167.206.4.199]) by mx1.freebsd.org (Postfix) with ESMTP id 7A2338FC21 for ; Sat, 20 Sep 2008 10:26:40 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from flosoft.no-ip.biz (ool-435559b8.dyn.optonline.net [67.85.89.184]) by mta4.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K7H00ELZP0FXFZ0@mta4.srv.hcvlny.cv.net> for freebsd-current@freebsd.org; Sat, 20 Sep 2008 06:26:39 -0400 (EDT) Received: from flosoft.no-ip.biz (localhost [127.0.0.1]) by flosoft.no-ip.biz (8.14.3/8.14.3) with ESMTP id m8KAPfPO001282; Sat, 20 Sep 2008 06:25:41 -0400 Date: Sat, 20 Sep 2008 06:25:41 -0400 From: "Aryeh M. Friedman" In-reply-to: <83e5fb980809200158h4650ad2ci55883ef93e69d1d8@mail.gmail.com> To: Diego Depaoli Message-id: <48D4CFA5.5050905@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <83e5fb980809200158h4650ad2ci55883ef93e69d1d8@mail.gmail.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080918) Cc: freebsd-current Subject: Re: Today build breaks nvidia driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2008 10:26:40 -0000 Just to poijnt out this has existed for the last week or so on -CURRENT Diego Depaoli wrote: > Hi all, > I've some trouble building nvidia driver after today world/kernel. > Here's the log: > ===> Configuring for nvidia-driver-173.14.12 > ===> Building for nvidia-driver-173.14.12 > ===> src (all) > @ -> /usr/src/sys > machine -> /usr/src/sys/i386/include > awk -f @/tools/makeobjops.awk @/kern/device_if.m -h > awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h > awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h > awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p > awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q > awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h > cc -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\"173.14.12\" > -D__KERNEL__ -DNVRM -UDEBUG -U_DEBUG -DNDEBUG -O -Werror -D_KERNEL > -DKLD_MODULE -std=c99 -nostdinc -I/src -I. -I@ -I@/contrib/altq > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -fno-common -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -ffreestanding -fstack-protector -fstack-protector -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -c nvidia_ctl.c > cc -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\"173.14.12\" > -D__KERNEL__ -DNVRM -UDEBUG -U_DEBUG -DNDEBUG -O -Werror -D_KERNEL > -DKLD_MODULE -std=c99 -nostdinc -I/src -I. -I@ -I@/contrib/altq > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -fno-common -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -ffreestanding -fstack-protector -fstack-protector -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -c nvidia_dev.c > cc -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\"173.14.12\" > -D__KERNEL__ -DNVRM -UDEBUG -U_DEBUG -DNDEBUG -O -Werror -D_KERNEL > -DKLD_MODULE -std=c99 -nostdinc -I/src -I. -I@ -I@/contrib/altq > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -fno-common -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -ffreestanding -fstack-protector -fstack-protector -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -c nvidia_linux.c > cc -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\"173.14.12\" > -D__KERNEL__ -DNVRM -UDEBUG -U_DEBUG -DNDEBUG -O -Werror -D_KERNEL > -DKLD_MODULE -std=c99 -nostdinc -I/src -I. -I@ -I@/contrib/altq > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -fno-common -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -ffreestanding -fstack-protector -fstack-protector -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -c nvidia_os.c > cc1: warnings being treated as errors > nvidia_os.c: In function 'os_is_administrator': > nvidia_os.c:168: warning: implicit declaration of function 'suser' > nvidia_os.c:168: warning: nested extern declaration of 'suser' > *** Error code 1 > > Stop in /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-173.14.12/src. > *** Error code 1 > > Stop in /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-173.14.12. > *** Error code 1 > > Stop in /usr/ports/x11/nvidia-driver. > *** Error code 1 > > Stop in /usr/ports/x11/nvidia-driver. > > Thanks in advance > From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 10:29:59 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8FE71065676 for ; Sat, 20 Sep 2008 10:29:59 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.191]) by mx1.freebsd.org (Postfix) with ESMTP id C907D8FC1F for ; Sat, 20 Sep 2008 10:29:58 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fk-out-0910.google.com with SMTP id k31so773236fkk.11 for ; Sat, 20 Sep 2008 03:29:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=iZKR0T9XhX//q7qvxFVgoL2Id32D3yM3sLmc61oo6Ls=; b=jaeWcnx4RB5HrKYGZmsa0lnv0I5KxykLAVxcFw8QzS28/x1efIO69PtWgszwgHzZ+G 1Gb06Po8/XSc+KKv2aSIws11eAydD7YPxsZjQXhbkudHtYcUNbTK+2EWktj9Ek0eWbrG SixKwTEkH6srxeEuu+b6PhjhaNVBcP2q/pBIM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=i+H8qRNbKwOTTjF4A2XoB6hYU/LGhNz7HgXEaMCrUwvhsA3zrBOxB3n+HQqKfkJQSa ApOyCgQxf2nt0/YccGcm0xyjLMvrJJdQszgU6KlGgxoI3y4mhtw65XQg435+Qr8wjxgZ SUh1xBqkzjIrmpLjlVu0cK8vxhwKWJOnXe148= Received: by 10.103.218.19 with SMTP id v19mr901450muq.110.1221906596433; Sat, 20 Sep 2008 03:29:56 -0700 (PDT) Received: by 10.103.239.14 with HTTP; Sat, 20 Sep 2008 03:29:56 -0700 (PDT) Message-ID: <3bbf2fe10809200329g273400d5g20d61feb8dd6241d@mail.gmail.com> Date: Sat, 20 Sep 2008 12:29:56 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Diego Depaoli" In-Reply-To: <83e5fb980809200158h4650ad2ci55883ef93e69d1d8@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <83e5fb980809200158h4650ad2ci55883ef93e69d1d8@mail.gmail.com> X-Google-Sender-Auth: ff3f639b0af834ef Cc: freebsd-current Subject: Re: Today build breaks nvidia driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2008 10:30:00 -0000 2008/9/20, Diego Depaoli : > Hi all, > I've some trouble building nvidia driver after today world/kernel. > Here's the log: > ===> Configuring for nvidia-driver-173.14.12 > ===> Building for nvidia-driver-173.14.12 > ===> src (all) > @ -> /usr/src/sys > machine -> /usr/src/sys/i386/include > awk -f @/tools/makeobjops.awk @/kern/device_if.m -h > awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h > awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h > awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p > awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q > awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h > cc -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\"173.14.12\" > -D__KERNEL__ -DNVRM -UDEBUG -U_DEBUG -DNDEBUG -O -Werror -D_KERNEL > -DKLD_MODULE -std=c99 -nostdinc -I/src -I. -I@ -I@/contrib/altq > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -fno-common -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -ffreestanding -fstack-protector -fstack-protector -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -c nvidia_ctl.c > cc -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\"173.14.12\" > -D__KERNEL__ -DNVRM -UDEBUG -U_DEBUG -DNDEBUG -O -Werror -D_KERNEL > -DKLD_MODULE -std=c99 -nostdinc -I/src -I. -I@ -I@/contrib/altq > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -fno-common -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -ffreestanding -fstack-protector -fstack-protector -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -c nvidia_dev.c > cc -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\"173.14.12\" > -D__KERNEL__ -DNVRM -UDEBUG -U_DEBUG -DNDEBUG -O -Werror -D_KERNEL > -DKLD_MODULE -std=c99 -nostdinc -I/src -I. -I@ -I@/contrib/altq > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -fno-common -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -ffreestanding -fstack-protector -fstack-protector -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -c nvidia_linux.c > cc -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\"173.14.12\" > -D__KERNEL__ -DNVRM -UDEBUG -U_DEBUG -DNDEBUG -O -Werror -D_KERNEL > -DKLD_MODULE -std=c99 -nostdinc -I/src -I. -I@ -I@/contrib/altq > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -fno-common -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -ffreestanding -fstack-protector -fstack-protector -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -c nvidia_os.c > cc1: warnings being treated as errors > nvidia_os.c: In function 'os_is_administrator': > nvidia_os.c:168: warning: implicit declaration of function 'suser' > nvidia_os.c:168: warning: nested extern declaration of 'suser' > *** Error code 1 > > Stop in /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-173.14.12/src. > *** Error code 1 > > Stop in /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-173.14.12. > *** Error code 1 > > Stop in /usr/ports/x11/nvidia-driver. > *** Error code 1 > > Stop in /usr/ports/x11/nvidia-driver. > > Thanks in advance This port needs to be fixed with switching to priv_check() privileges checking model. The __FreeBSD_version can be used in order to maintain old code for older version of FreeBSD, if the maintainer thinks it is necessary. The maintainer can work with me or Robert Watson in order to do that. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 11:04:38 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2AF21065676 for ; Sat, 20 Sep 2008 11:04:38 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 0A12B8FC1B for ; Sat, 20 Sep 2008 11:04:37 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 20 Sep 2008 10:37:54 -0000 Received: from 85-127-94-178.dynamic.xdsl-line.inode.at (EHLO taxman.pepperland) [85.127.94.178] by mail.gmx.net (mp064) with SMTP; 20 Sep 2008 12:37:54 +0200 X-Authenticated: #16703784 X-Provags-ID: V01U2FsdGVkX1+OMdBUyXWOORKMzd4WWeyKlmVSNRDxArUBvsEDqT 0L+8s21asSrYKt From: Stefan Ehmann To: freebsd-current@freebsd.org Date: Sat, 20 Sep 2008 12:37:48 +0200 User-Agent: KMail/1.10.1 (FreeBSD/7.1-PRERELEASE; KDE/4.1.1; i386; ; ) References: <83e5fb980809200158h4650ad2ci55883ef93e69d1d8@mail.gmail.com> In-Reply-To: <83e5fb980809200158h4650ad2ci55883ef93e69d1d8@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809201237.48903.shoesoft@gmx.net> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5600000000000001 Cc: Diego Depaoli Subject: Re: Today build breaks nvidia driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2008 11:04:38 -0000 On Saturday 20 September 2008 10:58:49 Diego Depaoli wrote: > Hi all, > I've some trouble building nvidia driver after today world/kernel. > cc1: warnings being treated as errors > nvidia_os.c: In function 'os_is_administrator': > nvidia_os.c:168: warning: implicit declaration of function 'suser' > nvidia_os.c:168: warning: nested extern declaration of 'suser' > *** Error code 1 Ran across this problem yesterday: As a quick hack you can change one line in nvidia_os.c: BOOL NV_API_CALL os_is_administrator(PHWINFO pDev) { - return suser(CURTHREAD) ? FALSE : TRUE; + return priv_check(CURTHREAD, PRIV_DRIVER) ? FALSE : TRUE; } From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 11:05:16 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A49FC1065683 for ; Sat, 20 Sep 2008 11:05:16 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id DEB898FC2E for ; Sat, 20 Sep 2008 11:05:15 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 20 Sep 2008 11:05:14 -0000 Received: from 85-127-94-178.dynamic.xdsl-line.inode.at (EHLO taxman.pepperland) [85.127.94.178] by mail.gmx.net (mp002) with SMTP; 20 Sep 2008 13:05:14 +0200 X-Authenticated: #16703784 X-Provags-ID: V01U2FsdGVkX18P5zY7UV0PX/pGUw2cUrxUzZPMudZszifzUNgn43 xqrqSxgd9CR/te From: Stefan Ehmann To: freebsd-current@freebsd.org Date: Sat, 20 Sep 2008 13:05:12 +0200 User-Agent: KMail/1.10.1 (FreeBSD/7.1-PRERELEASE; KDE/4.1.1; i386; ; ) MIME-Version: 1.0 Message-Id: <200809201305.13339.shoesoft@gmx.net> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57,0.57 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: prvxxx: cxm_iic attach fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2008 11:05:16 -0000 Hello, I'm using the port from http://usleepless.110mb.com/pvrxxx_port.tgz for my PVR-150 card. I get this error on kldload cxm: Sep 20 12:07:48 taxman kernel: cxm0: mem 0xd8000000-0xdbffffff irq 18 at device 15.0 on pci0 Sep 20 12:07:48 taxman kernel: cxm_iic0: on cxm0 Sep 20 12:07:48 taxman kernel: cxm_iic0: could not attach iicbb Sep 20 12:07:48 taxman kernel: device_attach: cxm_iic0 attach returned 6 Sep 20 12:07:48 taxman kernel: cxm0: could not attach cxm_iic Sep 20 12:07:48 taxman kernel: device_attach: cxm0 attach returned 6 Build fails on recent current because minor(9) is now a macro. The cause is this define in cxm.h # define dev_t struct cdev * I added this ugly hack to get it build. Not sure if it's correct but I don't think it's the cause of the problem. #undef minor #define minor(d) ((d) ? (d)->si_drv0 : -1) Haven't tested previously on CURRENT. But the card is working on RELENG_7: Sep 20 12:38:50 taxman kernel: cxm0: mem 0xd8000000-0xdbffffff irq 18 at device 15.0 on pci0 Sep 20 12:38:50 taxman kernel: cxm_iic0: on cxm0 Sep 20 12:38:50 taxman kernel: iicbb0: on cxm_iic0 Sep 20 12:38:50 taxman kernel: iicbus0: on iicbb0 master- only Sep 20 12:38:50 taxman kernel: iicbus0: at addr 0 Sep 20 12:38:50 taxman kernel: iicbus0: at addr 0 Any ideas? Thanks, Stefan From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 12:41:12 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0ECF1065671 for ; Sat, 20 Sep 2008 12:41:12 +0000 (UTC) (envelope-from scott@bqinternet.com) Received: from mail.bqinternet.com (mail.bqinternet.com [69.9.32.203]) by mx1.freebsd.org (Postfix) with ESMTP id AB3658FC17 for ; Sat, 20 Sep 2008 12:41:12 +0000 (UTC) (envelope-from scott@bqinternet.com) Received: from localhost (mail [69.9.32.203]) by mail.bqinternet.com (Postfix) with ESMTP id 62F672C6C34 for ; Sat, 20 Sep 2008 12:15:54 +0000 (GMT) Received: from mail.bqinternet.com ([69.9.32.203]) by localhost (mail.bqinternet.com [69.9.32.203]) (amavisd-new, port 10024) with ESMTP id gNLDuhFagO25 for ; Sat, 20 Sep 2008 12:15:52 +0000 (GMT) Received: from scott-burnss-macbook-air.local (mail [69.9.32.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bqinternet.com (Postfix) with ESMTP id 352D02C6A65 for ; Sat, 20 Sep 2008 12:15:52 +0000 (GMT) Message-ID: <48D4E974.2020008@bqinternet.com> Date: Sat, 20 Sep 2008 08:15:48 -0400 From: Scott Burns User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: ZFS panic in zone_dataset_visible X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2008 12:41:13 -0000 Hello, I am running several servers using Pawel's July 27 ZFS patchset, applied against 8-current source from the same day. I have seen a similar panic on two different servers: Server #1: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x570 fault code = supervisor write data, page not present instruction pointer = 0x8:0xffffffff802d60a5 stack pointer = 0x10:0xfffffffec89f3280 frame pointer = 0x10:0xfffffffec89f3290 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 95276 (ftpd) [thread pid 95276 tid 100432 ] Stopped at _mtx_lock_flags+0x15: lock cmpxchgq %rsi,0x18(%rdi) db> bt Tracing pid 95276 tid 100432 td 0xffffff010b3cc000 _mtx_lock_flags() at _mtx_lock_flags+0x15 zone_dataset_visible() at zone_dataset_visible+0x94 zfs_mount() at zfs_mount+0x3e5 domount() at domount+0x216 zfsctl_snapdir_lookup() at zfsctl_snapdir_lookup+0x3ba VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x40 lookup() at lookup+0x518 namei() at namei+0x515 kern_statat() at kern_statat+0x92 lstat() at lstat+0x2a syscall() at syscall+0x264 Xfast_syscall() at Xfast_syscall+0xab --- syscall (190, FreeBSD ELF64, lstat), rip = 0x800d9153c, rsp = 0x7fffffffa5c8, rbp = 0x6581d0 --- db> Server #1 (again): Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x570 fault code = supervisor write data, page not present instruction pointer = 0x8:0xffffffff802d60a5 stack pointer = 0x10:0xfffffffec8b3d280 frame pointer = 0x10:0xfffffffec8b3d290 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 87967 (sftp-server) [thread pid 87967 tid 100498 ] Stopped at _mtx_lock_flags+0x15: lock cmpxchgq %rsi,0x18(%rdi) db> bt Tracing pid 87967 tid 100498 td 0xffffff00a4c81700 _mtx_lock_flags() at _mtx_lock_flags+0x15 zone_dataset_visible() at zone_dataset_visible+0x94 zfs_mount() at zfs_mount+0x3e5 domount() at domount+0x216 zfsctl_snapdir_lookup() at zfsctl_snapdir_lookup+0x3ba VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x40 lookup() at lookup+0x518 namei() at namei+0x515 kern_statat() at kern_statat+0x92 lstat() at lstat+0x2a syscall() at syscall+0x264 Xfast_syscall() at Xfast_syscall+0xab --- syscall (190, FreeBSD ELF64, lstat), rip = 0x800d1c53c, rsp = 0x7ffffffea5b8, rbp = 0x630020 --- db> Server #2: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x570 fault code = supervisor write data, page not present instruction pointer = 0x8:0xffffffff802d60a5 stack pointer = 0x10:0xfffffffec8813280 frame pointer = 0x10:0xfffffffec8813290 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2851 (sh) [thread pid 2851 tid 100336 ] Stopped at _mtx_lock_flags+0x15: lock cmpxchgq %rsi,0x18(%rdi) db> bt Tracing pid 2851 tid 100336 td 0xffffff004f0cf000 _mtx_lock_flags() at _mtx_lock_flags+0x15 zone_dataset_visible() at zone_dataset_visible+0x94 zfs_mount() at zfs_mount+0x3e5 domount() at domount+0x216 zfsctl_snapdir_lookup() at zfsctl_snapdir_lookup+0x3ba VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x40 lookup() at lookup+0x518 namei() at namei+0x515 kern_statat() at kern_statat+0x92 stat() at stat+0x2a syscall() at syscall+0x264 Xfast_syscall() at Xfast_syscall+0xab --- syscall (188, FreeBSD ELF64, stat), rip = 0x80099855c, rsp = 0x7fffffffe868, rbp = 0x1 --- db> Has anyone else encountered this panic? -- Scott Burns System Administrator BQ Internet Corporation From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 13:27:09 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90D1D1065670 for ; Sat, 20 Sep 2008 13:27:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 3104B8FC14 for ; Sat, 20 Sep 2008 13:27:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Kh2UM-000HyM-U2; Sat, 20 Sep 2008 16:27:06 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m8KDR3Ug087167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Sep 2008 16:27:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m8KDR3IW001129; Sat, 20 Sep 2008 16:27:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id m8KDR3O7001127; Sat, 20 Sep 2008 16:27:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 20 Sep 2008 16:27:03 +0300 From: Kostik Belousov To: Maksim Yevmenkin Message-ID: <20080920132703.GG47828@deviant.kiev.zoral.com.ua> References: <48D2F942.4070801@FreeBSD.org> <20080919084201.GD44330@wep4035.physik.uni-wuerzburg.de> <48D38DFF.8000803@FreeBSD.org> <20080919203310.GA34131@localhost.my.domain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Sw7tCqrGA+HQ0/zt" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1Kh2UM-000HyM-U2 37c5a57f2777565e84c8d6124645e2bf X-Terabit: YES Cc: Alexey Shuvaev , freebsd-current@freebsd.org Subject: Re: Interface auto-cloning bug or feature? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2008 13:27:09 -0000 --Sw7tCqrGA+HQ0/zt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 19, 2008 at 03:43:21PM -0700, Maksim Yevmenkin wrote: > [....] >=20 > >> That what has caused me to look into this issue. You can find patch for > >> security/vpnc to prevent unbounded interface cloning here: > >> > >> http://sobomax.sippysoft.com/~sobomax/vpnc.diff > >> > > Ok, the patch prevents interface cloning, but I think it doesn't solve > > the actual problem. > > Let's wait for Maksim :) >=20 > ok, how about attached patch. i put it together *very* quickly and > only gave it a light testing. its for tap(4), because i could compile > it as a module and tun(4) is compiled into kernel by default, but the > idea should identical for tun(4). should be even simpler for tun(4) > because it does not have to deal with 2 kind of devices (i.e. tap and > vmnet). give it a try, and see if it works. please try both cloning > paths, i.e. >=20 > 1) cat /dev/tap (/dev/vmnet) with and/or without unit number >=20 > and >=20 > 2) ifconfig tapX (vmnetX) create/destroy >=20 > in the mean time i will prepare something similar for tun(4). >=20 > thanks, > max > --- if_tap.c.orig 2008-09-08 17:20:57.000000000 -0700 > +++ if_tap.c 2008-09-19 15:35:02.000000000 -0700 > @@ -94,6 +94,7 @@ > static int tapifioctl(struct ifnet *, u_long, caddr_t); > static void tapifinit(void *); > =20 > +static int tap_clone_lookup(struct cdev **, u_short); > static int tap_clone_create(struct if_clone *, int, caddr_t); > static void tap_clone_destroy(struct ifnet *); > static int vmnet_clone_create(struct if_clone *, int, caddr_t); > @@ -176,6 +177,28 @@ > DEV_MODULE(if_tap, tapmodevent, NULL); > =20 > static int > +tap_clone_lookup(struct cdev **dev, u_short extra) > +{ > + struct tap_softc *tp; > + > + mtx_lock(&tapmtx); > + SLIST_FOREACH(tp, &taphead, tap_next) { > + mtx_lock(&tp->tap_mtx); > + if ((tp->tap_flags & (TAP_OPEN|extra)) =3D=3D extra) { > + *dev =3D tp->tap_dev; > + mtx_unlock(&tp->tap_mtx); > + mtx_unlock(&tapmtx); > + > + return (1); > + } > + mtx_unlock(&tp->tap_mtx); > + } > + mtx_unlock(&tapmtx); > + > + return (0); > +} > + > +static int > tap_clone_create(struct if_clone *ifc, int unit, caddr_t params) > { > struct cdev *dev; > @@ -353,8 +376,18 @@ > =20 > /* We're interested in only tap/vmnet devices. */ > if (strcmp(name, TAP) =3D=3D 0) { > + if (tap_clone_lookup(dev, 0)) { > + dev_ref(*dev); > + return; What would prevent two concurrent threads from selecting the same device there ? First thread could look up the device, unloc tapmtx and be preempted. Then second thread is put on CPU, do the same selection. Now you have a problem. --Sw7tCqrGA+HQ0/zt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkjU+iYACgkQC3+MBN1Mb4g78wCfddJKStzNj9xTz79XbtUJ8do0 zqkAoJY/J9EELGG2kCa1Lz++C7/U7Gwg =t1a/ -----END PGP SIGNATURE----- --Sw7tCqrGA+HQ0/zt-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 15:53:02 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2275106566C for ; Sat, 20 Sep 2008 15:53:02 +0000 (UTC) (envelope-from trebestie@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by mx1.freebsd.org (Postfix) with ESMTP id 746788FC08 for ; Sat, 20 Sep 2008 15:53:02 +0000 (UTC) (envelope-from trebestie@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so925551wfg.7 for ; Sat, 20 Sep 2008 08:53:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=5ul1CHwZHe+Gfvv43dIlhNATtPvWyMHBA7proa5mbog=; b=nSzfs4ePdednqCuxJNFTWq82uc1HKYNCXeF6MXvmO1OP0x2iR5Ak5JA/AcvL8w485x w1OfPSmztuzXTzfFrDKKiSjP9inImMwub5SHZeZkXj6IY0UblktFoHRixM0xE69zVXlM 5ggZE9NJYcLSk9m/ZENsfjxU6+j3K3BLF+wSs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Aexn3afCUhSEEgJRF0QqpsR6ourFwZ9dpcAFX9zHPoXzX3A5XSwAp3fQRxWH+ku+iy w4L6z0V08e73viyRqxrKrWEoy4Qk7x4T/OfptOVBMRmbrpJLc4qaXafGP57N8IqjhrEW PmzpttqAoTGijgocltfyh38mmGTxXnev5qxY0= Received: by 10.142.140.15 with SMTP id n15mr561635wfd.168.1221925981992; Sat, 20 Sep 2008 08:53:01 -0700 (PDT) Received: by 10.142.141.16 with HTTP; Sat, 20 Sep 2008 08:53:01 -0700 (PDT) Message-ID: <83e5fb980809200853s2e1bbb19i7c0821776936ab46@mail.gmail.com> Date: Sat, 20 Sep 2008 17:53:01 +0200 From: "Diego Depaoli" To: "Stefan Ehmann" In-Reply-To: <200809201237.48903.shoesoft@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <83e5fb980809200158h4650ad2ci55883ef93e69d1d8@mail.gmail.com> <200809201237.48903.shoesoft@gmx.net> Cc: freebsd-current@freebsd.org Subject: Re: Today build breaks nvidia driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2008 15:53:02 -0000 2008/9/20 Stefan Ehmann : > On Saturday 20 September 2008 10:58:49 Diego Depaoli wrote: >> Hi all, >> I've some trouble building nvidia driver after today world/kernel. > >> cc1: warnings being treated as errors >> nvidia_os.c: In function 'os_is_administrator': >> nvidia_os.c:168: warning: implicit declaration of function 'suser' >> nvidia_os.c:168: warning: nested extern declaration of 'suser' >> *** Error code 1 > > Ran across this problem yesterday: > > As a quick hack you can change one line in nvidia_os.c: > > BOOL NV_API_CALL os_is_administrator(PHWINFO pDev) > { > - return suser(CURTHREAD) ? FALSE : TRUE; > + return priv_check(CURTHREAD, PRIV_DRIVER) ? FALSE : TRUE; > } It works. Many thanks -- Diego Depaoli From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 17:14:52 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45EC01065673 for ; Sat, 20 Sep 2008 17:14:52 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id F11648FC0C for ; Sat, 20 Sep 2008 17:14:51 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id F25D241C66F; Sat, 20 Sep 2008 18:55:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id SUdq3YAJD3O2; Sat, 20 Sep 2008 18:55:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 9A79841C65F; Sat, 20 Sep 2008 18:55:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 9870C44487F; Sat, 20 Sep 2008 16:52:18 +0000 (UTC) Date: Sat, 20 Sep 2008 16:52:18 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Diego Depaoli In-Reply-To: <83e5fb980809200853s2e1bbb19i7c0821776936ab46@mail.gmail.com> Message-ID: <20080920165125.B65801@maildrop.int.zabbadoz.net> References: <83e5fb980809200158h4650ad2ci55883ef93e69d1d8@mail.gmail.com> <200809201237.48903.shoesoft@gmx.net> <83e5fb980809200853s2e1bbb19i7c0821776936ab46@mail.gmail.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, Stefan Ehmann Subject: Re: Today build breaks nvidia driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2008 17:14:52 -0000 On Sat, 20 Sep 2008, Diego Depaoli wrote: > 2008/9/20 Stefan Ehmann : >> On Saturday 20 September 2008 10:58:49 Diego Depaoli wrote: >>> Hi all, >>> I've some trouble building nvidia driver after today world/kernel. >> >>> cc1: warnings being treated as errors >>> nvidia_os.c: In function 'os_is_administrator': >>> nvidia_os.c:168: warning: implicit declaration of function 'suser' >>> nvidia_os.c:168: warning: nested extern declaration of 'suser' >>> *** Error code 1 >> >> Ran across this problem yesterday: >> >> As a quick hack you can change one line in nvidia_os.c: >> >> BOOL NV_API_CALL os_is_administrator(PHWINFO pDev) >> { >> - return suser(CURTHREAD) ? FALSE : TRUE; >> + return priv_check(CURTHREAD, PRIV_DRIVER) ? FALSE : TRUE; >> } that should be conditionalized with __FreeBSD_version as Attilio had said (just mentioning again before this patch hits ports@ ;) -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 19:15:24 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49390106567B for ; Sat, 20 Sep 2008 19:15:24 +0000 (UTC) (envelope-from wahjava@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.189]) by mx1.freebsd.org (Postfix) with ESMTP id A21078FC0A for ; Sat, 20 Sep 2008 19:15:23 +0000 (UTC) (envelope-from wahjava@gmail.com) Received: by ti-out-0910.google.com with SMTP id d27so494482tid.3 for ; Sat, 20 Sep 2008 12:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:cc:subject:x-face :references:x-uptime:x-url:x-openpgp-id:x-openpgp-fingerprint:x-os :x-mailer:x-mail-morse:x-attribution:organization:from:date :in-reply-to:message-id:user-agent:face:mime-version:content-type :sender; bh=pkB5OqGBu8c9H4PhqzT3ffv1eNExeJCemnCMoyIepNY=; b=CAWcURsROsC4+r4f2PgWbX1RItWsXUt9uU/gyRLRc9CjpERQ/ygrKVfrNHHAI907P1 idPQFCFMf4Pe1ztR114AVVwTT9dh6gQPUYVkLWKWH/N0/ORxdxY6zTuqK1dElaXYxODg URp3/Q1/t9NO8dJp77nYwzmMLYt2W5GUNuDDo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:cc:subject:x-face:references:x-uptime:x-url:x-openpgp-id :x-openpgp-fingerprint:x-os:x-mailer:x-mail-morse:x-attribution :organization:from:date:in-reply-to:message-id:user-agent:face :mime-version:content-type:sender; b=nsuGxAD6Cckf8Ng+EN3RWksPVc39hU2BABfPxfeY8yDhF3FO2/+fUZrRuEzSf6LL+S IcaJU0xJz1oic7PuKZJVK5EmMTLdnQ+agIGdwUYWY+xlJH+mJooTjUihaC5rShDAbHCh 0mPnLeM6LPXXxUxVrZvxlcReNSjYejNPIWFDA= Received: by 10.110.7.18 with SMTP id 18mr2582649tig.32.1221938121996; Sat, 20 Sep 2008 12:15:21 -0700 (PDT) Received: from chateau.d.lf ( [122.162.55.173]) by mx.google.com with ESMTPS id 22sm7170341tim.10.2008.09.20.12.15.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 20 Sep 2008 12:15:20 -0700 (PDT) To: "fluffles.net" X-Face: )vGQ9yK7Y$Flebu1C>(B\gYBm)[$zfKM+p&TT[[JWl6:]S>cc$%-z7-`46Zf0B*syL.C]oCq[upTG~zuS0.$"_%)|Q@$hA=9{3l{%u^h3jJ^Zl; t7 References: <87bpyjkc6p.fsf@chateau.d.lf> <48D4292B.3010908@freebsd.org> <873ajvk9uk.fsf@chateau.d.lf> <48D4552A.6080502@fluffles.net> X-Uptime: 00:24:14 up 18 min, 1 user, load average: 0.04, 0.25, 0.26 X-URL: http://wahjava.wordpress.com/ X-OpenPGP-ID: 762E5E74 X-OpenPGP-Fingerprint: 1E00 4679 77E4 F8EE 2E4B 56F2 1F2F 8410 762E 5E74 X-OS: GNU/Linux on Linux 2.6.25-gentoo-r7 kernel on x86_64 architecture X-Mailer: Gnus/5.11 (Oort 5.11) Emacs/22.3.1 (x86_64-pc-linux-gnu) X-Mail-Morse: .-- .- .... .--- .- ...- .- .--.-. --. -- .- .. .-.. .-.-.- -.-. --- -- X-Attribution: =?utf-8?B?4KSG4KS24KWA4KS3?= Organization: alt.religion.emacs From: wahjava.ml@gmail.com (Ashish Shukla =?utf-8?B?4KSG4KS24KWA4KS3IA==?= =?utf-8?B?4KS24KWB4KSV4KWN4KSy?=) Date: Sun, 21 Sep 2008 00:45:28 +0530 In-Reply-To: <48D4552A.6080502@fluffles.net> (fluffles net's message of "Sat\, 20 Sep 2008 03\:43\:06 +0200") Message-ID: <87bpyi4oj3.fsf@chateau.d.lf> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJ1BMVEWpqal/f39tbW1jY2Md HR2goKCenp6UlJROTk7////9/f35+fnT09ORJdieAAACVklEQVQ4jXXUP2vbQBQA8AvUTkgz5OzY Z0iGWhpS6BSrkECn0mvx0MEJ6AjtYrfoBCVDlD8naJYmNlRfwZq8+mkKlIZaGpJSYmP7Q/XkJDrJ Td8i/H68u3vHPaPufwLdf32AMA4A6GcAgvAamY1pOJiDIFqicTwLswDhfr3uxfFtkAY/GFHPMwzD 8zpnACmIOnE6js7rQb+v4NJrG9od0C+QgpHMy5jBewV+UDSMWiw1Y4fWfyV7+NGFzDsYa3pth9LJ Q4XvXxFHcJRvHOmygn5NAEabnDcQQguarnfoiwSCJ99jmKKcphsZONmWsDK9Ro7cvZOCtQdg8nje egLhc2LNlkLmsezzTFUUy5w18ocox/f0LaLgJy0zO75zk+9pp85GAj36xjqhdI0y3tq2m4dqqcWX zQWBTz8L1irvolXV4J+3q7eCDgVnttjNq6X8H+9KOZsuNk1uCzx8pSp+E9HImfJOTLdcGqo+YKnG EIovizkEn48V7BO+ch2DXcD4ENSpWiU+q8hjjbgTBZCXnZtyj0Ws4Q1Q0B2WXFtYZo65Bbyeeldw RS6qFueM80LlLA29YlVwGRYvFD+kwI/0O+A2PlpOP9GwslUVciHuYGechuBTp922YiDZCrghTknm XSyOM+D3aoRZlo0Jb42zY7DN4p2x4AeZ+QAYutx1sHwTHzMT5cMNduQ9yW3GczN4KZ86kb0c9O8T yXDeFqpl2fryPEAYGXIlezAPXYh2NgVr/gvdoHIuDwuPwOhcWE8f8mmICq41eATkn8x0kuRTIKcB wE9+/QUtiiAnYcaN7wAAAABJRU5ErkJggg== MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: =?UTF-8?B?4KSG4KS24KWA4KS3IOCktuClgeCkleCljeCksiBBc2hpc2ggU2h1a2xh?= Cc: Sam Leffler , freebsd-current@freebsd.org Subject: Re: Setting up atheros (168c:001c) wireless NIC in FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2008 19:15:24 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 fluffles net writes: [...] > I've been having the same problems with Dell 167G USB Wlan dongle using > the "rum" driver. Also recent 8-CUR amd64. > I cannot do a SSID scan because it returns me: > ifconfig: unable to get scan results Have you created a 'wlan0' interface, as mentioned in a posting[1] in freebsd-mobile@ . References: [1] - http://lists.freebsd.org/pipermail/freebsd-mobile/2008-June/010773.html I'm not sure if 'rum' also requires the same stuff as 'ath'. HTH Ashish -- ·-- ·- ···· ·--- ·- ···- ·- ·--·-· --· -- ·- ·· ·-·· ·-·-·- -·-· --- -- () ascii ribbon campaign - against HTML e-mail /\ www.asciiribbon.org - against proprietary attachments --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjVS9MACgkQHy+EEHYuXnTItwCgmxOE7QLfD8TKgGjbJEI3smPv 2b0An132TZPxpVyMIcQOUV6M3TlW8JI9 =WLSr -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 19:22:25 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADB8A1065676 for ; Sat, 20 Sep 2008 19:22:25 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [216.101.162.50]) by mx1.freebsd.org (Postfix) with ESMTP id 84B538FC1A for ; Sat, 20 Sep 2008 19:22:25 +0000 (UTC) (envelope-from null@pozo.com) Received: from T41p.pozo.com (t41p.pozo.com [192.168.0.4]) (authenticated bits=0) by pozo.com (8.14.3/8.14.3) with ESMTP id m8KJMMS4027619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 20 Sep 2008 12:22:22 -0700 (PDT) (envelope-from null@pozo.com) Message-Id: <200809201922.m8KJMMS4027619@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 20 Sep 2008 12:22:17 -0700 To: freebsd-current@freebsd.org From: Manfred Antar Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-101.4 required=5.0 tests=ALL_TRUSTED,MISSING_MID, USER_IN_WHITELIST autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on pozo.com X-Virus-Scanned: ClamAV 0.94-exp/8293/Sat Sep 20 10:19:54 2008 on pozo.com X-Virus-Status: Clean Cc: lulf@freebsd.org Subject: fdisk bsdlabel compile broken on Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2008 19:22:25 -0000 I can't compile fdisk or bsdlabel on current without adding -lbsdxml -lsbuf to the Makefile Is anyone else seeing this ? Doing a buildworld on current i386 it stops at : /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x1f1): In function `geom_xml2tree': : undefined reference to `XML_ParserCreate' /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x22d): In function `geom_xml2tree': : undefined reference to `XML_SetUserData' /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x245): In function `geom_xml2tree': : undefined reference to `XML_SetElementHandler' /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x255): In function `geom_xml2tree': : undefined reference to `XML_SetCharacterDataHandler' /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x27b): In function `geom_xml2tree': : undefined reference to `XML_Parse' /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x28d): In function `geom_xml2tree': : undefined reference to `XML_ParserFree' /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x4ed): In function `EndElement': : undefined reference to `sbuf_finish' /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x4fc): In function `EndElement': : undefined reference to `sbuf_data' /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x51e): In function `EndElement': : undefined reference to `sbuf_delete' /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x864): In function `StartElement': : undefined reference to `sbuf_new' /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0xd74): In function `CharData': : undefined reference to `sbuf_bcat' *** Error code 1 Stop in /usr/src/sbin/fdisk. *** Error code 1 ================================== || null@pozo.com || || Ph. (415) 681-6235 || ================================== From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 19:26:13 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C7EB1065673 for ; Sat, 20 Sep 2008 19:26:13 +0000 (UTC) (envelope-from wahjava@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.189]) by mx1.freebsd.org (Postfix) with ESMTP id 6A9408FC0C for ; Sat, 20 Sep 2008 19:26:12 +0000 (UTC) (envelope-from wahjava@gmail.com) Received: by ti-out-0910.google.com with SMTP id d27so495224tid.3 for ; Sat, 20 Sep 2008 12:26:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:subject:x-face:references :x-uptime:x-url:x-openpgp-id:x-openpgp-fingerprint:x-os:x-mailer :x-mail-morse:x-attribution:organization:from:date:in-reply-to :message-id:user-agent:face:mime-version:content-type:sender; bh=Bm4qVHuvf/2Ah4r6RXiWNvIOWvXbHyfJ+G0+7y5ovCQ=; b=lNz3bGmYEB/K/3ZTbkBDBLEYeCeyWKu1ymOg5ZWd2N73Z0EKXrkGZvZAB7VrczwYE6 Z6g0XVabduUGkvyH7SQwf7aRqqula9Sv+qE2LSMh4Os196vrW9X1Mg5HmV8YyQBGrTQA aLDr1TiTBsCstAx0ikog/PhqFiGyGmPzTIheE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:subject:x-face:references:x-uptime:x-url:x-openpgp-id :x-openpgp-fingerprint:x-os:x-mailer:x-mail-morse:x-attribution :organization:from:date:in-reply-to:message-id:user-agent:face :mime-version:content-type:sender; b=Us2kDG9KA6SMySh/R3ACV9IqHmtR71TCAXFmJlEW5SbavlSYJ4Eu5BAltHsbRb19Ll B6r5IhZNRJceZ1I127F7vfTdrrpbdYpaViH4xPZR8ve4ObzrpGaPN16QrxNY2hBV9Ho9 b8P9uG0r7m7TdIl3AmuzEC45qauHVpQbeqstg= Received: by 10.110.95.15 with SMTP id s15mr2576380tib.40.1221938771040; Sat, 20 Sep 2008 12:26:11 -0700 (PDT) Received: from chateau.d.lf ( [122.162.55.109]) by mx.google.com with ESMTPS id u8sm7069007tia.6.2008.09.20.12.26.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 20 Sep 2008 12:26:10 -0700 (PDT) To: Sam Leffler , freebsd-current@freebsd.org X-Face: )vGQ9yK7Y$Flebu1C>(B\gYBm)[$zfKM+p&TT[[JWl6:]S>cc$%-z7-`46Zf0B*syL.C]oCq[upTG~zuS0.$"_%)|Q@$hA=9{3l{%u^h3jJ^Zl; t7 References: <87bpyjkc6p.fsf@chateau.d.lf> <48D4292B.3010908@freebsd.org> <873ajvk9uk.fsf@chateau.d.lf> X-Uptime: 00:51:33 up 45 min, 1 user, load average: 0.00, 0.02, 0.05 X-URL: http://wahjava.wordpress.com/ X-OpenPGP-ID: 762E5E74 X-OpenPGP-Fingerprint: 1E00 4679 77E4 F8EE 2E4B 56F2 1F2F 8410 762E 5E74 X-OS: GNU/Linux on Linux 2.6.25-gentoo-r7 kernel on x86_64 architecture X-Mailer: Gnus/5.11 (Oort 5.11) Emacs/22.3.1 (x86_64-pc-linux-gnu) X-Mail-Morse: .-- .- .... .--- .- ...- .- .--.-. --. -- .- .. .-.. .-.-.- -.-. --- -- X-Attribution: =?utf-8?B?4KSG4KS24KWA4KS3?= Organization: alt.religion.emacs From: wahjava.ml@gmail.com (Ashish Shukla =?utf-8?B?4KSG4KS24KWA4KS3IA==?= =?utf-8?B?4KS24KWB4KSV4KWN4KSy?=) Date: Sun, 21 Sep 2008 00:56:18 +0530 In-Reply-To: <873ajvk9uk.fsf@chateau.d.lf> ("Ashish Shukla =?utf-8?B?4KSG?= =?utf-8?B?4KS24KWA4KS3IOCktuClgeCkleCljeCksiIncw==?= message of "Sat\, 20 Sep 2008 04\:43\:39 +0530") Message-ID: <871vze4o11.fsf@chateau.d.lf> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJ1BMVEWpqal/f39tbW1jY2Md HR2goKCenp6UlJROTk7////9/f35+fnT09ORJdieAAACVklEQVQ4jXXUP2vbQBQA8AvUTkgz5OzY Z0iGWhpS6BSrkECn0mvx0MEJ6AjtYrfoBCVDlD8naJYmNlRfwZq8+mkKlIZaGpJSYmP7Q/XkJDrJ Td8i/H68u3vHPaPufwLdf32AMA4A6GcAgvAamY1pOJiDIFqicTwLswDhfr3uxfFtkAY/GFHPMwzD 8zpnACmIOnE6js7rQb+v4NJrG9od0C+QgpHMy5jBewV+UDSMWiw1Y4fWfyV7+NGFzDsYa3pth9LJ Q4XvXxFHcJRvHOmygn5NAEabnDcQQguarnfoiwSCJ99jmKKcphsZONmWsDK9Ro7cvZOCtQdg8nje egLhc2LNlkLmsezzTFUUy5w18ocox/f0LaLgJy0zO75zk+9pp85GAj36xjqhdI0y3tq2m4dqqcWX zQWBTz8L1irvolXV4J+3q7eCDgVnttjNq6X8H+9KOZsuNk1uCzx8pSp+E9HImfJOTLdcGqo+YKnG EIovizkEn48V7BO+ch2DXcD4ENSpWiU+q8hjjbgTBZCXnZtyj0Ws4Q1Q0B2WXFtYZo65Bbyeeldw RS6qFueM80LlLA29YlVwGRYvFD+kwI/0O+A2PlpOP9GwslUVciHuYGechuBTp922YiDZCrghTknm XSyOM+D3aoRZlo0Jb42zY7DN4p2x4AeZ+QAYutx1sHwTHzMT5cMNduQ9yW3GczN4KZ86kb0c9O8T yXDeFqpl2fryPEAYGXIlezAPXYh2NgVr/gvdoHIuDwuPwOhcWE8f8mmICq41eATkn8x0kuRTIKcB wE9+/QUtiiAnYcaN7wAAAABJRU5ErkJggg== MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: =?UTF-8?B?4KSG4KS24KWA4KS3IOCktuClgeCkleCljeCksiBBc2hpc2ggU2h1a2xh?= Cc: Subject: Re: Setting up atheros (168c:001c) wireless NIC in FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2008 19:26:13 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Quoting from a thread[1] in freebsd-mobile: > For some reason I had to do the following to assign: > > # ifconfig ath0 down > # ifconfig ath0 ssid "yourssid" > # ifconfig ath0 up > > Works fine with an Atheros AR5BXB63. As mentioned mentioned, I'm wondering if I've to assign ssid and up/down to 'ath0' instead of 'wlan0', hmm...? As, I'm having the same AR5BXB63 PCI-Express card, in my HP Compaq Presario A900 series[2] notebook. References: [1] - http://lists.freebsd.org/pipermail/freebsd-mobile/2008-June/010777.html [2] - http://h10010.www1.hp.com/wwpc/me/en/ho/WF06a/1770577-1770863-1771313-1771313-1771313-81143316.html TIA Ashish -- ·-- ·- ···· ·--- ·- ···- ·- ·--·-· --· -- ·- ·· ·-·· ·-·-·- -·-· --- -- () ascii ribbon campaign - against HTML e-mail /\ www.asciiribbon.org - against proprietary attachments --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjVTlwACgkQHy+EEHYuXnRRgwCgqe3QPI3WdVifTeMlzOyGuM/y 2NEAn0g0+ZBs6aEpsQTIGWoH95yuXAoO =X8Uu -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 21:24:20 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 236D8106566C for ; Sat, 20 Sep 2008 21:24:20 +0000 (UTC) (envelope-from lulf@freebsd.org) Received: from bene1.itea.ntnu.no (bene1.itea.ntnu.no [IPv6:2001:700:300:3::56]) by mx1.freebsd.org (Postfix) with ESMTP id 2B0B08FC0C for ; Sat, 20 Sep 2008 21:24:19 +0000 (UTC) (envelope-from lulf@freebsd.org) Received: from localhost (localhost [127.0.0.1]) by bene1.itea.ntnu.no (Postfix) with ESMTP id 263901769C0; Sat, 20 Sep 2008 23:24:17 +0200 (CEST) Received: from carrot.studby.ntnu.no (unknown [IPv6:2001:700:300:3::184]) by bene1.itea.ntnu.no (Postfix) with ESMTP id 507B916C632; Sat, 20 Sep 2008 23:24:16 +0200 (CEST) Date: Sat, 20 Sep 2008 23:27:20 +0200 From: Ulf Lilleengen To: Manfred Antar Message-ID: <20080920212720.GA3082@carrot.studby.ntnu.no> References: <200809201922.m8KJMMS4027619@pozo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200809201922.m8KJMMS4027619@pozo.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-Virus-Scanned: Debian amavisd-new at bene1.itea.ntnu.no Cc: freebsd-current@freebsd.org Subject: Re: fdisk bsdlabel compile broken on Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2008 21:24:20 -0000 On Sat, Sep 20, 2008 at 12:22:17PM -0700, Manfred Antar wrote: > I can't compile fdisk or bsdlabel on current without adding -lbsdxml -lsbuf to the Makefile > Is anyone else seeing this ? > > Doing a buildworld on current i386 it stops at : > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x1f1): In function `geom_xml2tree': > : undefined reference to `XML_ParserCreate' > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x22d): In function `geom_xml2tree': > : undefined reference to `XML_SetUserData' > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x245): In function `geom_xml2tree': > : undefined reference to `XML_SetElementHandler' > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x255): In function `geom_xml2tree': > : undefined reference to `XML_SetCharacterDataHandler' > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x27b): In function `geom_xml2tree': > : undefined reference to `XML_Parse' > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x28d): In function `geom_xml2tree': > : undefined reference to `XML_ParserFree' > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x4ed): In function `EndElement': > : undefined reference to `sbuf_finish' > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x4fc): In function `EndElement': > : undefined reference to `sbuf_data' > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x51e): In function `EndElement': > : undefined reference to `sbuf_delete' > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x864): In function `StartElement': > : undefined reference to `sbuf_new' > /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0xd74): In function `CharData': > : undefined reference to `sbuf_bcat' > *** Error code 1 > > Stop in /usr/src/sbin/fdisk. > *** Error code 1 I saw another reference to this the other day, but it seems strange. Nothing is changed in the APIs or the makefiles/includes whatever. Are you sure you're doing a proper buildworld? Also, these error messages have no connection to the last commits, which was in different files. -- Ulf Lilleengen From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 22:01:12 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E5011065812; Sat, 20 Sep 2008 22:01:12 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [216.101.162.50]) by mx1.freebsd.org (Postfix) with ESMTP id 57D378FC29; Sat, 20 Sep 2008 22:01:11 +0000 (UTC) (envelope-from null@pozo.com) Received: from T41p.pozo.com (t41p.pozo.com [192.168.0.4]) (authenticated bits=0) by pozo.com (8.14.3/8.14.3) with ESMTP id m8KM10Yk005739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 20 Sep 2008 15:01:00 -0700 (PDT) (envelope-from null@pozo.com) Message-Id: <200809202201.m8KM10Yk005739@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 20 Sep 2008 15:00:55 -0700 To: Ulf Lilleengen From: Manfred Antar In-Reply-To: <20080920212720.GA3082@carrot.studby.ntnu.no> References: <200809201922.m8KJMMS4027619@pozo.com> <20080920212720.GA3082@carrot.studby.ntnu.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-101.4 required=5.0 tests=ALL_TRUSTED,MISSING_MID, USER_IN_WHITELIST autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on pozo.com X-Virus-Scanned: ClamAV version 0.94, clamav-milter version 0.94-exp on pozo.com X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: fdisk bsdlabel compile broken on Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2008 22:01:12 -0000 At 02:27 PM 9/20/2008, Ulf Lilleengen wrote: >On Sat, Sep 20, 2008 at 12:22:17PM -0700, Manfred Antar wrote: >> I can't compile fdisk or bsdlabel on current without adding -lbsdxml -lsbuf to the Makefile >> Is anyone else seeing this ? >> >> Doing a buildworld on current i386 it stops at : >> /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x1f1): In function `geom_xml2tree': >> : undefined reference to `XML_ParserCreate' >> /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x22d): In function `geom_xml2tree': >> : undefined reference to `XML_SetUserData' >> /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x245): In function `geom_xml2tree': >> : undefined reference to `XML_SetElementHandler' >> /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x255): In function `geom_xml2tree': >> : undefined reference to `XML_SetCharacterDataHandler' >> /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x27b): In function `geom_xml2tree': >> : undefined reference to `XML_Parse' >> /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x28d): In function `geom_xml2tree': >> : undefined reference to `XML_ParserFree' >> /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x4ed): In function `EndElement': >> : undefined reference to `sbuf_finish' >> /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x4fc): In function `EndElement': >> : undefined reference to `sbuf_data' >> /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x51e): In function `EndElement': >> : undefined reference to `sbuf_delete' >> /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0x864): In function `StartElement': >> : undefined reference to `sbuf_new' >> /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o)(.text+0xd74): In function `CharData': >> : undefined reference to `sbuf_bcat' >> *** Error code 1 >> >> Stop in /usr/src/sbin/fdisk. >> *** Error code 1 >I saw another reference to this the other day, but it seems strange. Nothing >is changed in the APIs or the makefiles/includes whatever. Are you sure >you're doing a proper buildworld? > >Also, these error messages have no connection to the last commits, which was >in different files. > >-- >Ulf Lilleengen cd /usr/src make buildworld if i do cd /usr/src//lib/libgeom make obj make depend all install then: cd /usr/src/sbin/fdisk make obj make depend all install it fails as the above message The last full make world I was able to do where fdisk was built was around Sept 5th. This morning I deleted all of /usr/src and did a cvsup. Tried again and still failed. I'm puzzled as no one else is seeing this. I can try to cvs checkout from around Sept 5th and see if it builds. I wonder if I have stray includes being picked up somewhere. Why will it build if I add -lbsdxml -lsbuf to the Makefile ? Manfred ================================== || null@pozo.com || || Ph. (415) 681-6235 || ================================== From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 22:51:07 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0439B106564A; Sat, 20 Sep 2008 22:51:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id C02BB8FC18; Sat, 20 Sep 2008 22:51:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m8KMp3us071596; Sat, 20 Sep 2008 18:51:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id m8KMp3vU025215; Sat, 20 Sep 2008 18:51:03 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A75E273039; Sat, 20 Sep 2008 18:51:03 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080920225103.A75E273039@freebsd-current.sentex.ca> Date: Sat, 20 Sep 2008 18:51:03 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.94, clamav-milter version 0.94 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2008 22:51:07 -0000 TB --- 2008-09-20 22:49:46 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-20 22:49:46 - starting HEAD tinderbox run for i386/i386 TB --- 2008-09-20 22:49:46 - cleaning the object tree TB --- 2008-09-20 22:50:24 - cvsupping the source tree TB --- 2008-09-20 22:50:24 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2008-09-20 22:50:32 - building world (CFLAGS=-O -pipe) TB --- 2008-09-20 22:50:32 - cd /src TB --- 2008-09-20 22:50:32 - /usr/bin/make -B buildworld >>> World build started on Sat Sep 20 22:50:34 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.bin/ar/acpyacc.y:505: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_mlist2argv': /src/usr.bin/ar/acpyacc.y:621: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:622: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_free_argv': /src/usr.bin/ar/acpyacc.y:631: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:632: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:634: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /src/usr.bin/ar. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-20 22:51:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-20 22:51:03 - ERROR: failed to build world TB --- 2008-09-20 22:51:03 - tinderbox aborted TB --- 18.22 user 6.34 system 77.20 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 22:52:17 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F17A1065676; Sat, 20 Sep 2008 22:52:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 56A278FC13; Sat, 20 Sep 2008 22:52:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m8KMqFZI071631; Sat, 20 Sep 2008 18:52:15 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id m8KMqFQ3029016; Sat, 20 Sep 2008 18:52:15 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 3220F73039; Sat, 20 Sep 2008 18:52:15 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080920225215.3220F73039@freebsd-current.sentex.ca> Date: Sat, 20 Sep 2008 18:52:15 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.94, clamav-milter version 0.94 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2008 22:52:17 -0000 TB --- 2008-09-20 22:51:03 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-20 22:51:03 - starting HEAD tinderbox run for i386/pc98 TB --- 2008-09-20 22:51:03 - cleaning the object tree TB --- 2008-09-20 22:51:40 - cvsupping the source tree TB --- 2008-09-20 22:51:40 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2008-09-20 22:51:46 - building world (CFLAGS=-O -pipe) TB --- 2008-09-20 22:51:46 - cd /src TB --- 2008-09-20 22:51:46 - /usr/bin/make -B buildworld >>> World build started on Sat Sep 20 22:51:48 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.bin/ar/acpyacc.y:505: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_mlist2argv': /src/usr.bin/ar/acpyacc.y:621: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:622: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_free_argv': /src/usr.bin/ar/acpyacc.y:631: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:632: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:634: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /src/usr.bin/ar. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-20 22:52:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-20 22:52:15 - ERROR: failed to build world TB --- 2008-09-20 22:52:15 - tinderbox aborted TB --- 17.96 user 6.21 system 71.38 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 22:53:33 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B5971065682; Sat, 20 Sep 2008 22:53:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id D6B048FC14; Sat, 20 Sep 2008 22:53:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m8KMrUKP071672; Sat, 20 Sep 2008 18:53:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id m8KMrUr4033787; Sat, 20 Sep 2008 18:53:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 92A7673039; Sat, 20 Sep 2008 18:53:30 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080920225330.92A7673039@freebsd-current.sentex.ca> Date: Sat, 20 Sep 2008 18:53:30 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.94, clamav-milter version 0.94 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2008 22:53:33 -0000 TB --- 2008-09-20 22:52:15 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-20 22:52:15 - starting HEAD tinderbox run for ia64/ia64 TB --- 2008-09-20 22:52:15 - cleaning the object tree TB --- 2008-09-20 22:52:55 - cvsupping the source tree TB --- 2008-09-20 22:52:55 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2008-09-20 22:53:01 - building world (CFLAGS=-O -pipe) TB --- 2008-09-20 22:53:01 - cd /src TB --- 2008-09-20 22:53:01 - /usr/bin/make -B buildworld >>> World build started on Sat Sep 20 22:53:03 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.bin/ar/acpyacc.y:505: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_mlist2argv': /src/usr.bin/ar/acpyacc.y:621: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:622: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_free_argv': /src/usr.bin/ar/acpyacc.y:631: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:632: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:634: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /src/usr.bin/ar. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-20 22:53:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-20 22:53:30 - ERROR: failed to build world TB --- 2008-09-20 22:53:30 - tinderbox aborted TB --- 18.44 user 5.32 system 75.20 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 22:54:34 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFBBF1065687; Sat, 20 Sep 2008 22:54:34 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id A69DD8FC14; Sat, 20 Sep 2008 22:54:34 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m8KMsWZn071717; Sat, 20 Sep 2008 18:54:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id m8KMsW4g034411; Sat, 20 Sep 2008 18:54:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9D40673039; Sat, 20 Sep 2008 18:54:32 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080920225432.9D40673039@freebsd-current.sentex.ca> Date: Sat, 20 Sep 2008 18:54:32 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.94, clamav-milter version 0.94 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2008 22:54:35 -0000 TB --- 2008-09-20 22:53:30 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-20 22:53:30 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-09-20 22:53:30 - cleaning the object tree TB --- 2008-09-20 22:54:00 - cvsupping the source tree TB --- 2008-09-20 22:54:00 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-09-20 22:54:06 - building world (CFLAGS=-O -pipe) TB --- 2008-09-20 22:54:06 - cd /src TB --- 2008-09-20 22:54:06 - /usr/bin/make -B buildworld >>> World build started on Sat Sep 20 22:54:07 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.bin/ar/acpyacc.y:505: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_mlist2argv': /src/usr.bin/ar/acpyacc.y:621: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:622: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_free_argv': /src/usr.bin/ar/acpyacc.y:631: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:632: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:634: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /src/usr.bin/ar. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-20 22:54:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-20 22:54:32 - ERROR: failed to build world TB --- 2008-09-20 22:54:32 - tinderbox aborted TB --- 17.92 user 5.62 system 61.86 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 22:55:46 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D93D106566C; Sat, 20 Sep 2008 22:55:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id EA4BF8FC2D; Sat, 20 Sep 2008 22:55:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m8KMtb9L047309; Sat, 20 Sep 2008 18:55:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m8KMtbt1047480; Sat, 20 Sep 2008 18:55:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8DCD573039; Sat, 20 Sep 2008 18:55:37 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080920225537.8DCD573039@freebsd-current.sentex.ca> Date: Sat, 20 Sep 2008 18:55:37 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2008 22:55:46 -0000 TB --- 2008-09-20 22:54:32 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-20 22:54:32 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-09-20 22:54:32 - cleaning the object tree TB --- 2008-09-20 22:55:03 - cvsupping the source tree TB --- 2008-09-20 22:55:03 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-09-20 22:55:09 - building world (CFLAGS=-O -pipe) TB --- 2008-09-20 22:55:09 - cd /src TB --- 2008-09-20 22:55:09 - /usr/bin/make -B buildworld >>> World build started on Sat Sep 20 22:55:10 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.bin/ar/acpyacc.y:505: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_mlist2argv': /src/usr.bin/ar/acpyacc.y:621: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:622: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_free_argv': /src/usr.bin/ar/acpyacc.y:631: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:632: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:634: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /src/usr.bin/ar. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-20 22:55:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-20 22:55:37 - ERROR: failed to build world TB --- 2008-09-20 22:55:37 - tinderbox aborted TB --- 18.34 user 5.29 system 64.80 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 22:56:41 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B22201065676; Sat, 20 Sep 2008 22:56:41 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 799948FC16; Sat, 20 Sep 2008 22:56:41 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m8KMud2U071843; Sat, 20 Sep 2008 18:56:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id m8KMud9M037373; Sat, 20 Sep 2008 18:56:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 706DA73039; Sat, 20 Sep 2008 18:56:39 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080920225639.706DA73039@freebsd-current.sentex.ca> Date: Sat, 20 Sep 2008 18:56:39 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.94, clamav-milter version 0.94 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2008 22:56:41 -0000 TB --- 2008-09-20 22:55:37 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-20 22:55:37 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-09-20 22:55:37 - cleaning the object tree TB --- 2008-09-20 22:56:06 - cvsupping the source tree TB --- 2008-09-20 22:56:06 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-09-20 22:56:12 - building world (CFLAGS=-O -pipe) TB --- 2008-09-20 22:56:12 - cd /src TB --- 2008-09-20 22:56:12 - /usr/bin/make -B buildworld >>> World build started on Sat Sep 20 22:56:14 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.bin/ar/acpyacc.y:505: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_mlist2argv': /src/usr.bin/ar/acpyacc.y:621: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:622: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_free_argv': /src/usr.bin/ar/acpyacc.y:631: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:632: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:634: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /src/usr.bin/ar. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-20 22:56:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-20 22:56:39 - ERROR: failed to build world TB --- 2008-09-20 22:56:39 - tinderbox aborted TB --- 17.95 user 5.16 system 61.70 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full